1. Many WMS will hinder your ability to differentiate.
Supply chain and logistics executives are typically interested in two simple things. First, they want to ensure that the product gets to the customer. in a way that meets the customer’s expectations (on time and in full). Second, they want to do this at the lowest possible cost to the operations they manage.
Your differentiation can be found in how—and how well—you can accomplish these goals. The catch, however, is that customer requirements and expectations are always changing. And you have no idea what will be required of your operations in six months, much less a few years. Ongoing success requires that you have a WMS that will help you meet your functional needs today, while responding quickly to unforeseen changes. When evaluating WMS, is it safe to simply assume that a vendor’s features and functions will help you meet changing needs in a way that will help you differentiate your offering? In any case, why would you risk your ability to accomplish these goals—even a little—when the stakes are so high?
Standard WMS functionality that incorporates industry best practices can be useful for most facets of your operations, but it isn’t enough for you to truly differentiate your operations from the competition. A WMS that enables agile response to change can be a competitive weapon. The problem is that most WMS take a flawed approach to addressing change. These systems feature a wealth of functionality option switches in an effort to keep up with their customers’ changing needs. However, no system can possibly include all the functionality options necessary because every business has different needs. In these types of systems, anything beyond the functionality offered with these switches must be incorporated with the addition of expensive custom coding, most often performed by the vendor. This code is added during the original system implementation to bridge the gap between the standard product and your company’s unique needs.
As new requirements arise, you’ll either have to contact the vendor to make expensive changes, or you can make do with the options in the switches. In an effort to control costs, many companies ultimately forego making necessary changes (as well as upgrading, discussed in secret 2), slowly settling for the standard functionality of their WMS. They opt not to incorporate innovative processes that could help them differentiate their business. Your order profile, business strategy and unplanned events will change, requiring fast action if you are to succeed. When you need to change your WMS, you need a system agile enough to incorporate your new processes—quickly and cost-effectively. You know better than any WMS vendor out there what makes your operations and your customers tick. It’s key to implement a system that will truly enable your ability to take every possible advantage of new operational ideas.

What you can do:
• Ask your vendor to give detailed demonstrations of how changes are made in the system.
• Talk to customer references to find out how quickly they can respond to new requirements and how expensive these changes were. Ask how much change orders have added to the price of implementation and how much they cost on a recurring basis.
• Find a consultant who is experienced in business evaluation and system selection. These firms provide strong guidance when it comes to performing operational assessments and carrying out vendor searches.

2. WMS upgrades can be a nightmare.
The WMS industry has largely been driven by providing services to customers, not developing agile software products. Many WMS vendors generate a great deal of revenue from customizing their standard solutions. These applications are not supportable over the long term. They can hold you captive to the vendor not only for ongoing changes necessary to keep up with new business needs, but often more importantly, the technological advances the vendor offers in the form of upgrades.

Why can such an undertaking paralyze your operations and your profitability?The reason: many conventional systems contain a shortcoming in their design in that many changes can only be accomplished through switches. Change
requests that go beyond these switches require custom coding, which doesn’t carry forward with an upgrade. As mentioned in secret 1, this custom code is added during the original system implementation to bridge the gap between the standard product and your company’s unique needs. As further needs develop, more code is added. In some situations, this reaches an extreme where so many changes have been made that any new modifications become a major undertaking, effectively reducing or even paralyzing the system’s ability to be altered at all. Upgrading these types of warehouse management systems with additional code-level changes leads to a potentially disastrous spiral of exorbitant costs, extended timeframes, and system and operational risk. All previous codebased modifications have to be re-applied when the system is upgraded. For you this could mean a never-ending process that results in loss of competitive advantage and possibly irreparable damage to key customer relationships. At some point it could become difficult to recognize any return on investment because the upgrade process contains nothing but negative outcomes. The upgrade nightmares have been told. Companies today are becoming smarter in their technology choices and expectations. However, the WMS industry overall has been slow to respond to these needs with the right kind of solutions. Companies want to have upgradeable solutions and the autonomy to make solution changes without spending a lot or waiting for an opening in their vendor’s schedule. Because of this, a culture shift is going on as the industry moves from its vendor-centric, service-driven roots to more customer-centric, flexibility-driven enablement.

What you can do:
• Evaluate the total cost of ownership for the system over several years and track this metric with vendor’s customers. Have users been able to make system changes themselves or was the vendor always involved?
• Ask vendors for customer references to learn about the time, cost and overall approach to upgrades. Did changes carry forward or did they require re-application? Was custom code involved?

3. The so-called “service-oriented architectures” of many WMS will probably make you change your business practices to fit the software.
Demands for more flexible business software and emerging technologies such as XML, WSDL and SOAP have driven the adoption of serviceoriented architectures (SOA). And for good reason. SOA allows for cost savings and faster system changes. It drives low total cost of ownership by putting flexibility in the hands of the system owner. However, for the SOA to deliver these benefits, the applications must embrace flexible software intrinsically from the beginning of their development. Many software providers have taken legacy code bases and exposed elements of these code bases as services. While this does provide additional flexibility, it does not provide the level of flexibility that most businesses require. This approach lacks flexibility for two reasons. First, the company is completely dependent on the vendor’s decisions about which business functions are exposed as services. This means that flexibility will always be constrained by the software provider’s product roadmap. Second, this approach makes an invalid assumption that users will never need to change the underlying behavior of a service. A software provider with a truly flexible SOA will allow users to change the underlying behavior of a service to support unique business requirements.
The most important thing to remember is that legacy systems can be migrated to SOA, but this may have little positive benefit other than chasing a technology story or market requirement. An SOA is not a monolithic system constructed from inflexible, dated technology that has been patched to work with the latest standards. This approach is akin to retrofitting a Model T to operate on today’s roads. The resulting car will be “street legal,” but it would not contain the performance characteristics that most drivers expect. A true SOA is actually capable of manipulating the behavior of the system itself. Because of this capability, it will allow you to embrace the changes your business will face over the long term. You won’t have to change your business practices to fit your software.

What you can do:
• Consider the cost advantage of true flexibility and evaluate the vendor’s business model accordingly. Learn how to distinguish vendors’ SOA claims—whether they differentiate technology for the sake of marketing, or clearly communicate an enduring strategic direction.
• Ask vendors to demonstrate system changes and give specific examples of how customers have made changes. Option switches are not always an effective way to handle change.
• Ask about how upgrades are carried out. Do previous changes automatically carry forward, or must the vendor or a consultant re-apply them to the new version?

4. Vendors’ idea of “meeting your requirements” can result in a messy hodgepodge of systems.

The following scenario has become common during WMS selections—in fact, you might have experienced it. Many companies go through the exercise of understanding their order profile and documenting their functional requirements across the business to gain a clear picture of the type of features required. They even gain budget approval and support from key decision-makers in their organization to begin the software project. So they send a request for proposal (RFP) to several vendors in the space, most of whom have been in the industry for more than 10 years. Almost all vendors answer that their systems are capable of providing the functionality requested. And yet...there are still horror stories of cost overruns and failed projects.

How can this be?

How SOAs Work A service-oriented architecture enables solutions to be constructed from pieces of business functionality exposed as services. These services span business logic, devices and all manner of business technology. They may be run separately and/or assembled in various ways to create business processes. If business needs dictate change, the services may be re-orchestrated to adapt to the change without involving costly edits to underlying code—in essence, customizations. If an architecture is truly an SOA, it should allow for upgrades without extensive consulting projects to bring system changes into the latest version. It should provide for a “platform” in conjunction with the operating system and a unique development environment that optimizes the behavior and assembly of the services rendering the solution. 4 Many companies wind up in this situation because they do not require vendors to give responses based on a single, deliverable WMS. The vendor might indicate that it meets all requirements, yet its response mixes functionality from several WMS—which doesn’t paint an accurate picture of what can actually be implemented. In fact, many vendors have multiple WMS offerings due to acquisition/consolidation. It is also impossible to document your specifications to the point of eliminating scope creep. You will want to change the system to meet your requirements. Features and functions do not save money and do not mitigate risk. The only thing that saves you money and mitigates risk is a system that matches your business needs today and can adapt to meet future requirements.

What you can do:
• Demand the vendor stick with one specific WMS throughout the evaluation cycle—for RFP responses, demonstrations and customer references given. Vendors with multiple systems may respond positively for RFP questions and give demonstrations based on functionality contained in different systems. You don’t want to receive an RFP response that looks favorable given your requirements only to discover later you’d need to buy three separate WMS to actually have the right breadth.
• Ask about the vendor’s license-to-services ratio to see if you’re buying a solid software product or simply services to tweak your system continually over the long term.
• It is also important to consider the cost-to-benefit ratio: buying a WMS is not about gaining ROI over 18 months. It is about total cost of ownership over a multi-year period. The biggest cost of a system is likely not purchasing the software or even the services to initially implement it. It is usually forced upgrades and making ongoing changes, which can often surpass the cost of license fees.

5. Most supply chain execution suites aren’t really sweet.
The typical supply chain execution (SCE) suite is comprised of systems that manage warehousing (WMS), transportation (TMS), yard operations (YMS), labor (LMS) and have some sort of application to link them together. Optionally, this family may even extend to supplier enablement and other applications. Order management and supply chain planning are typically seen as supply chain management or advanced planning and scheduling solutions, not supply chain execution.
What makes a suite truly valuable is clear visibility to material flows in a boundary-less state. This requires a single, scalable technology structure that spans all applications—one platform, one database, one user interface and one set of tools. In the 1990s, ERPs had to have each of these elements (and a few others) to be considered an ERP. As these requirements were adopted, they rendered silos of functionality and technology obsolete (i.e., material requirements planning (MRP) vs. order management vs. financials). The integration of MRP with order management, finance, DRP, CRM, etc. was predicated on an integrated database that could scale. But is this the case in SCE suites today? Not usually. Many vendors have pieced together their suites through acquisition. Some even have multiple WMS applications which they market as being “industry-specific.” However, these applications typically reside on different platforms. They rarely share data at a common platform level; instead they rely on merely interfacing disparate modules. In addition, they are typically developed by different teams that use different technologies and focus on contending business objectives. These are not suites. They really are different software products sold by a single vendor. This poses many risks to buyers. You may select a product that is soon to be discontinued or that will become secondary to other solutions in the vendor’s long-term product development plan. You may also have to spend considerable hardware dollars to make applications work together. It is not uncommon for some supply chain execution vendors to require a mixture of AS/400®, UNIX® and Windows® servers to run the entire suite of applications. Additionally, there may be a mix of core technologies such as Java®, .NET and legacy code (RPG, COBOL) running across this collection of disparate servers. This inconsistent approach requires your internal staff to be fluent across hardware and technologies that are not core to your IT strategy. The deployment may also be problematic (if you try to launch them together) or expensive (because you’ll most likely phase them in).

What you can do:
• Evaluate platform and interface requirements closely. Ask vendors if they built the application or bought it. If they built it, are all solutions based on a single execution platform? Do they share a common data model or rely on interfacing their modules?
• Ensure that your maintenance finances will go toward R&D or investment in the platform your purchased; you don’t want to be funding the continued development of another technology (or technologies) with no benefit to your own system.

Conclusion
Purchasing a WMS is an important decision for your business. A great deal of productivity in the United States over the past two decades has beenbased upon WMS applications. WMS software vendors are able to drive ROI better than most other software industry players. You can boost your company’s ability to realize its own ROI by understanding the nature of the industry and demanding more from the vendors you evaluate.