Mind the gap(s) in your conference room pilot
So you have followed our advice and created fantastic WMS Conference Room Pilot scripts. Your scenarios are based on the integrated business requirements document and current state description as reflected by your future state description. You are confident that you understand the needs of the business (requirements), how the business conducts its operations today (current state), and how you will continue to satisfy those needs and conduct business with the new solution (future state). You have exercised your software and configuration several times and you know the system is working well. You’re ready for your Conference Room Pilot (CRP).
Prepare for the “what ifs.”
While delivering your first focused session of the CRP covering a topic with the right people in the room, someone raises their hand. Then comes the dreaded words, “That’s great, but what about when this happens?” Hopefully, you can respond with a workaround or pre-planned exception process that will solve this new scenario that has come to light. However, there will be some questions that either uncover a new requirement or invalidate assumptions about an existing one that creates a new scenario that cannot be solved by the current software or configuration, or processes. These are what we call gaps.
During these discussions, it is critical that one of the core project team members is documenting every possible thing about the gaps (writing down the name of the person who raised it, documenting the process, capturing reference materials, etc. It’s important to give the gap a reference number and make a first pass at documenting its severity. Typically, severity classifications will be critical for go-live, workaround possibilities, or nice-to-haves. Gaps can ultimately be solved by process changes, workarounds for exceptions, software configuration, software modifications, or changing the requirements. Let’s take a look at each of these possibilities in more detail with some examples.
Sometimes gaps can simply go away by revisiting the requirements
We have seen many requirements that were leftover relics of some procedure or process that was once necessary, but no longer is justifiable. Be very suspicious if the best justification for the requirement is “We’ve just always done it that way.” If gaps are rooted in an unclear, undefined, or mystical requirement, you need to dig deep because most likely it is not really a requirement at all.
Don’t be afraid to stop doing obsolete business processes.
One of the more benign gaps to solve is the one that goes away with a simple configuration change. A good example of this is a requirement to track inventory in a special status or disposition that was not originally configured by the core project team. Typically, adding additional inventory status or dispositions to a WMS is trivial and if this gap can be justified by requirements, configuration changes should be made. Keep in mind, though, that configuration changes usually require a full regression test of the system again, so they are not to be taken lightly. Often it’s the unexpected knock-on effects like testing that create delays and scope creep. For example, if another inventory status or disposition is added, did we consider the impact on the interfaces going back to the host and EDI systems?
Sometimes a simple change to a process can resolve a gap
For example, we often see that having mixed parts in a location creates some sort of gap or at least drives inefficiencies. Often we find out that the parts are mixed in the location not due to a business requirement, but by choice. So by changing the business process to not mix parts in the locations, we may have eliminated a potential software gap, as well as increased picking efficiency. It is always important to challenge the process and make sure we are doing things because we have to versus the way it’s always been done.
Mind the exceptions
Many gaps are due to an exception scenario that was not uncovered during the current state review and future state design. We like to be careful about exceptions because they should be rare. We once had a client who had a great philosophy that you automated the process and managed the exceptions. This is a good philosophy and we try to see if we can perform a manual workaround to solve gaps that are related to resolving exceptions. You can often buy a lot of Wite-Out to correct an exception on a bill of lading for what it might cost in custom programming, maintenance, and support. Of course, if the exception or manual workaround becomes the normal process, then you probably need to revisit this topic and find a better process.
Personalization & modification gaps
The final category of gaps is something that we truly want to minimize. These gaps will drive a change to the software. We think it is important to classify potential software changes into 2 categories; personalization and modification.
A great example of personalization is a packing list, shipping label, or bill of lading. Most WMS solutions are designed in a way to make it easy to do personalization without impacting upgrade and maintenance costs. Sure these are all changes to the software or new software components that will add some customization to your WMS; however, they are also simply necessary for you to do business. Don’t get too hung up on these kinds of changes, but don’t go overboard either. Try to consolidate and simplify wherever you can. For example, we have seen clients who have created a custom packing list or shipping label for each customer served. As part of our project, we can usually consolidate and minimize the number of individual variations of a label or report or even standardize on something like a VICS bill of lading.
The kinds of software gaps that are classified as true modifications are the ones you must really put under a microscope. You must understand that most likely you will be paying for your modifications not just once, but every time you upgrade, take a system patch, pay your annual maintenance and support contract, etc. Therefore, we think it is critical that you only allow modifications that either creates a competitive advantage to your business or are necessary for legal or compliance reasons. Based on our experience in WMS upgrades, we find that somewhere between 40%-60% of all modifications were ultimately unnecessary once the client better understood how to use the system. While no one ever truly goes plain vanilla, try to limit your modifications to things that are necessary for legal or compliance and/or give you a serious competitive advantage. The latter can easily be justified by increased ROI.
Now that we have our gap list, classified each one, and hopefully eliminated many, we now need to prioritize the gaps and get quotes. Generally, we find putting them into some sort of matrix works well so you can sort them based on several criteria and come up with a gap plan. If the necessary gaps are within your budget, then you are good to go. If they exceed it, you will have to get more funding or go back and reexamine what you have considered critical.
This is also a good time to go back and revisit your project plan to see if the gaps will have an impact on your overall project milestones and dates. Most likely they will. If any of the gaps were showstoppers, you may also need to consider a second Conference Room Pilot to demonstrate the new processes, configurations, software, etc. to the business. And finally, if you have found that the gaps have increased your costs significantly, you might need to go back and revisit your business case and vendor selection and determine if going forward still makes sense.
In the last post, we stressed how important it is to have good CRP scripts and to be prepared for your CRP in order to be successful. Other foundation pieces mentioned were the business requirements and current state understanding. Having a firm grasp on those two is another critical variable for having a great CRP and in our next post, we will talk about why. Click here to read Part 3.