Fralick Says: |
 |
| The idea of playing the functional-fit percentages and thinking that "Well, this will handle 99% of our requirements" can leave you dangerously short on the operational side of things. |
|
What Do You Say?
|
|
|
|
Some WMS vendors are pushing towards a more rapid model of system implementation. But it is a myth that these faster implementations are inherently a good thing.
I am back with a second in a series of columns on WMS myths. A few weeks ago, we started with myth number 1, that "Testing" is an Important Phase of a WMS Project." In that piece, I argued that testing, or what I call validation, should not be a distinct phase at the end of a WMS project but rather be embedded in the process from beginning to end.
That said, I get the appeal of these sort of "Fast-Path" or what sales types sometimes call "Slam Dunk" WMS implementations. Fast implementations it seems should lead to quicker ROI/more rapid time-to-value. It all sounds so great, so appealing - get in and get out of there.
The idea is that if you put in a base system and get it up and running, you can achieve value faster. It's sort of like playing the percentages on the functionality side of things - if we stay pretty basic - we know that the vast majority of things will work. When you think of it that way, playing the WMS functional-fit percentages, it sounds like grand plan.
Now, we talk about ROI all the time in our business and time-to-value is certainly a component of that. And, no question these sorts of "Fast Path" implementations can work for some customers. However, invariably, my experience with them is that it turns into a fast path to dissatisfaction (or worse).
The answer to the why question implicit in my previous statement has to do with one of the biggest things people forget about a WMS. That is: the SYSTEM NEEDS TO SUPPORT OPERATIONAL REQUIREMENTS. In all of the situations I've been in with these sorts of fast path WMS deployments, the project starts out with competing objectives. Often it is a situation where some sort of corporate directive to get the system in fast is at odds with the logistics requirement that the system will effectively manage the operation.
While it is certainly possible to work these objectives together, the conflicting goals often become a wedge in the project. Operations says, "Hey, we need to handle this process, and the project team says "Well, that is not standard so it is out of scope."
Let's get back to the idea of playing the percentages for a moment. We do a lot of WMS go-lives; I scorecard every one. The thing that most people do not understand about a go-live (of any kind) is that is not the 10,000 things you got right that people judge you by. It is the six things that you got wrong, maybe two things that operations really needs but did not work. So, the idea of playing the functional-fit percentages and thinking that "Well, this will handle 99% of our requirements" can leave you dangerously short on the operational side of things.
Now, I know people will come to me and say "Wait, you are the person that always says WMS is a PLATFORM choice as much as anything - a platform for continuous improvement, shouldn't we just try to get that platform in as soon as possible and then improve it over time?" In the abstract, that is absolutely correct. However, in real life where the performance of your operation directly impacts revenue and customer satisfaction, it is not the only priority. So, yes, you want to get the best platform for the long-haul in there. However, you cannot sacrifice the ability to ship.
 Wow, I just made it sound impossible to do fast-path WMS implementations. But, actually, given the functional state of current WMS' and their ability to tailor based on workflows, etc. it is very possible. We have been doing implementations from initial configuration to go-live week in 7-10 weeks. The success or failure of this sort of venture, in my opinion, hinges on two things: priorities and focus.
Let's first talk about priorities. The priority of any WMS has to be giving operations what it needs to run the operation. I've often been quoted as saying one of the things I always look in an operation is that small number of things that they might do uniquely. Unless you get these things right, no matter what else you get right, the system will fail. This is where the vast majority of the Fast-Path WMS fail (or push out). These things must be accounted for and worked into the schedule.
The other thing I mentioned is focus. The focus has to revolved around validation, as noted in part 1 of this series. One of the big downfalls we see in any implementation is when operations gets a system "handed over" to it without enough of their involvement. Validation is more than just testing, it speaks as much to how adequately operations s can run the business as it does if things break.
In order for this type if implementation, or any really, to work the project team has to be in a continuous validation/challenge/improvement loop. For example, the project team works with operations on a receiving configuration, it is handed over to operations for validation and the project team moves on to the next thing to prep for validation. Operations is responsible for either challenging the adequacy of the operational fit, which would then require some rework of flows and another validation round, or accepting it. Think of these as functional sprints, each sprint supporting the configuration, validate/challenge process. By the time you get to a Acceptance Testing phase, operations would have approved everything in the system.
Finally, the last big obstacle you face in these Fast-Path implementation has to do with the site's ability to accept a new system. Some of this is technical (new interfaces needing to be built, etc.) but most has to do with training. Countless times through the years, we have been in a situation where the system was ready but the site was not. This will the topic of my next article "Training: Our staff worked in the old WMS, they shouldn't need much training, right?"
So it's a myth that fast track WMS implementations are inherently a good thing. They can be, but only if we retain focus on the key capabilities a given facility needs to excel beyond a vanilla configuration, and with validation embedded deeply in the entire process.
Agree or disagree with our expert columnist? Send Feedback Below.
|
