When it comes to IT architecture, you might hear acronyms like SOA (Service Oriented Architecture) or BPM (Business Process Management). But I’ve often believed the most applicable acronym was MEGO – My Eyes Glaze Over!
However, if you are contemplating buying a Warehouse Management System (WMS), the sad truth is that architecture does matter. So, here’s my (perhaps ambitious) attempt to tell you why it matters and what to look for, without causing your eyes to glaze over.
A WMS’ architecture affects its total cost of ownership, its flexibility, its ability to integrate with complementary solutions, and how quickly and easily a software vendor can enhance the application via its product development efforts.
One question to consider: How componentized is the solution? If the WMS solution is provided by an ERP vendor, is the WMS code tied to the larger ERP solution set, or has the WMS component been carefully segregated from other ERP components?
In Oracle’s case, the company is migrating towards the latter. Historically, major enhancements to their WMS solution were only made available when a new version of Oracle E-Business Suite was released. Even so, over the past few releases, their “cumulative feature count per release” has been increasing, a sign that the product development process for WMS has sped up. Moving forward, Oracle has targeted WMS for heavy R&D investment. Oracle EBS 12.1 will be generally available in 2009, and the standalone WMS will be available sometime after. A key advantage of a separate WMS component is that it will allow for more frequent WMS releases, giving users greater flexibility in deciding when they want to go through an upgrade process and garner the benefit of the most recent enhancements.
For a best-of-breed WMS, is the application one big piece of code, or has it been componentized? For example, the solution might have individual components for receiving, cross docking, quality assurance, put-away, picking, and so forth. Softeon is an example of a WMS vendor that has taken this approach. The company leverages object oriented programming for a highly-componentized architecture. When potential customers require a unique solution, 70 to 80 percent of the solution will often leverage off-the-shelf components, and the other 20 to 30 percent will use newly developed components with wrappers. The WMS itself is comprised of about 8 components. During upgrades, custom components are not touched, and often only the shipping and picking components need to be upgraded, as this is where process changes more often occur, making for quicker upgrade cycles.
Vanderlande is another company that has taken this approach. Vanderlande offers highly automated material handling solutions with supporting software. Their WMS solution is componentized to support “goods-to-man” as well as “man-to-goods” picking strategies. Their WMS does not support all manual picking methods (it wasn’t designed to), but it does provide good support for high-throughput hybrid warehouses that combine manual zone picking and automated picking strategies.
What’s interesting to me is that in highly-automated warehouses, the WMS/WCS (warehouse control system) is typically never upgraded. Many types of material handling equipment are inflexible-i.e., not easy to unbolt, move around, and bolt together in new configurations. Because of this physical inflexibility, many WCS suppliers were slow to adopt new software development methodologies to make their software more flexible. (As an aside, this is changing. WCS is becoming better architected, and not just at Vanderlande).
Vanderlande’s software is designed to be expandable, scalable from a material handling perspective, and flexible. In the area of expandability, their solution can support a particular picking process in one part of a DC today, and other picking processes in other zones at later points in time. When it comes to supporting material handling scalability, the software can support three stacker cranes now, for example, but more if you decide to expand down the road (assuming, of course, you’ve planned ahead and left space for the new cranes). And in terms of flexibility, as processes change, components can be upgraded or reconfigured to reflect those changes. In practice, considering the physical constraints of the material handling equipment, the components that are upgraded or reconfigured are more apt to be “man-to-goods” components instead of components for “goods-to-man” picking processes.
Componentization is not the only architectural feature a potential buyer should consider. But my goal was to prevent your eyes from glazing over. So, assuming I didn’t put you to sleep, I will save those other topics for another day.
