In 2006, I interviewed 22 companies that had implemented or upgraded a Warehouse Management System (WMS) solution at a single site or across many sites. These interviews clearly suggested that the architecture of the solution affected its Total Cost of Ownership (TCO).

I looked at the type of WMS solution that was implemented—traditional configuration versus Business Process Modeling (BPM) configuration. The latter should really be described as “micro BPM” because the workflows are not used to integrate different applications together; they are used to configure a single application. Some folks refer to the micro-BPM style solution as a toolkit solution. A traditional WMS has a configuration tool based on drop-down menus that provide various process choices through certain flags or check boxes. WMS solutions based on BPM configuration tools have a toolbar with a variety of warehouse objects that reflect sub-processes in the larger warehouse workflow. The objects are dragged onto a workbench and “snapped” together to create the desired warehouse process flow.

I won’t get into the methodology of the study (see “What Type of WMS is Right for Your Company?” for more details, available to ARC clients only), but I did find that WMS solutions based on a micro-BPM architecture did have greater agility than traditional solutions. Agility has different dimensions: the speed of the initial implementation; the speed of subsequent implementations; the ability to make ongoing changes to the system without outside help; and the speed with which upgrades can be performed.

On the first dimension, speed of implementation at an initial site, there was limited evidence that the newer, BPM-style WMS implemented faster than traditional solutions if they were being implemented at sites of similar complexity. In other words, the complexity of the warehouse impacted the speed of implementation more than the type of WMS selected.

Similarly, respondents were no more likely to say that the initial implementation of a micro-BPM style WMS solution was on time, on budget, or less expensive than those of a traditional WMS solution. Regardless of architecture, subsequent implementations of a WMS were quicker and easier than the first implementation.

There was evidence that subsequent implementations of micro-BPM style solutions were faster than traditional solutions at sites of similar complexity. Micro-BPM style solutions also rated significantly better than traditional WMS solutions in the area of speed of upgrade, and they were easier to make ongoing configuration changes to. 

I bring up these research results because Manhattan Associates (an ARC client) has come out with a WMS with a hybrid architecture—part traditional drop-down, menu-driven implementation, part micro-BPM style. Manhattan argues that prebuilt solutions include best practices. The company also believes that for very high-volume warehouses the drop-down style solution is better because quality assurance (QA) is critical in systems with very high transactions. And, Manhattan says, QA is easier in traditional rules-based systems. So in areas that require a high number of transactions (e.g., the waving process), Manhattan continues to use rules-driven drop-down menus. However, the company recognizes that certain warehouse processes are much more likely to change over time, particularly processes linked to customers (e.g., value-added services) or suppliers (e.g., quality assurance).  For these processes, Manhattan offers the micro-BPM style configuration tool.

To support its new WMS workflow-style configuration options, Manhattan has also released SCOPE Test Director that allows users to test the system’s performance, manage multi-site and multi-tenant configuration on an ongoing basis, and maintain data and process integrity for upgrades.

Manhattan’s work to improve its architecture is not just focused on its WMS application. The company has taken a major step in developing a “Supply Chain Platform” that supports process changes across its suite of applications. As part of this platform, Manhattan’s WMS now shares a variety of common components with the other products on the platform (e.g., Transportation Planning and Execution, Distributed Order Management, Supply Chain Visibility, and Supply Chain Intelligence).  These components include:

• Common master data (items, vendors, carriers, customers, facilities, users, etc.);
• Common transactional data (PO’s, ASNs, Distribution Orders, etc);
• Common business objects (parcel, appointment scheduling, etc); 
• Common technological components (presentation services (user interface), security framework, reporting, framework, etc).

Just as the WMS solution offers tools that help Manhattan test its process extensions, the company’s Supply Chain Platform has a series of tools that allow customers to engage in what Manhattan calls “responsible extensibility.” Manhattan’s SCOPE Studio offers a wide variety of ways to extend the software, through cross application workflows, service enablement of common business objects, and other means. 

But again, if you want to introduce process changes, you need to make sure those changes don’t create any adverse and unexpected effects to any underlying applications. Manhattan complements the extensibility offered by SCOPE Studio with SCOPE Management Center, a series of tools that allow customers to quickly regression test a new extension, manage the deployment and configuration of an extension, and monitor system health to determine any adverse and unexpected effects of the change.    

Manhattan argues that it has the perfect architecture, one that both scales and is highly agile.  I will have to talk to several customers that choose to implement this new style WMS before I can verify this clam. Based on my past research, however, I suspect that Manhattan has significantly improved the agility and TCO of its solutions.      

In short, for most people, software architecture is a boring topic that makes their eyes glaze over. But if you care about Total Cost of Ownership, software architecture is very important.