What happens when you get a couple of WMS architects together over dinner? Well, besides showing themselves as the true execution system geeksthey are, inevitably the discussion turns to “What’s your approach to this?” or “How do you handle that?”.
Not so long ago, I had lunch with the president of one WMS software company, a person whom I think is one of the smartest guys in the WMS space.It didn’t take long for our conversation to get into the guts of how we think about these systems from a fundamentalsperspective.While in days gone by we might have dwelled on technical matters of architecture, most of the products successful in this space now are at a sufficient level where that is no longer a huge differentiator.Instead, this conversation was completely about the blocking and tackling fundamentals of execution systems in general and WMS in particular.
It’s hard to imagine I suppose, if you aren’t into the nuts and bolts of these systems, why we’d have spent an hour talking about how and when to lock locations during allocations, picking and exception handling – but this exact conversation led me to an insight (no, not that we are even bigger geeks than I estimated).It’s really that conversation about how a WMS does it’s work that has changed.
The “How”’ question used to focus largely on the technical aspects of a WMS design (programming approach, etc). But now with many of the WMS offerings either supporting or fully embracing Services Oriented Architectures (SOAs), that conversation is somewhat moot.
Now, the “How” question needs to be about the approach to the Execution problem. In our case, we discussed how and when place a location lock, for how long, and why.But really when it comes to WMS design, there are hundreds of fundamental decisions like this, some more important and some less,adding up to how a system acts and how (and how well) it performs.
I fear many of the consultants and customers going through a WMS acquisition exercise are still stuck a bit in a mode where: (1) they are too caught up in the technical matters (important to be sure – but no longer as big of an issue in my opinion); (2) have their spreadsheet of functions and busily checking the functionality off the list without worrying too much about the How question; (3) Don’t properly weight critical aspects of the operation in the decision making process; (4) Don’t deal with the How question at all.
Why?
Diving into the How question for an entire WMS is just not feasible. Nor is it a worthwhile exercise.
Instead, take my approach to really analyzing those small numbers of things that must absolutely be done a certain way for the operation to work. Every operation has some small number of these – just ask an operations guy, he’ll tell you exactly what they are. Dive into the top 5-10 things that you can define as the things that if not done 100% correctly the installation will not be successful.
These critical items must not only be functionally correct, but philosophically correct. In other words, the How of handling these items is nearly as critical as the fact that the functionality works.
Why? Well, if the functionality has to be cobbled together with non-standard components or by using components in a way they weren’t meant to be used, it will not result in a robust implementation. Nor will you be very safe in the future.
Getting to the root of the How question for the most important aspects of your operation yields some big benefits.
(1) It gives you an insight to the philosophy what the WMS is doing to solve the problems at hand.
(2) Provides you with a measure of the robustness of the WMS beyond just functionality.
(3) Understanding the How gives you a notion of what’s going to happen when the process changes, needs to adapt, of is combined with other processes.
In the end, understanding just some of the How question may go a long way to extending the lifetime of your system.
|