Warehouses of tomorrow need to be highly process driven rather than people driven. Unlike what used to applytwo decades back, industries have transformed and what warehouses must do now has changed. This has radically altered the vision of what warehouse software must do. Steve Mulaik, Director, Crimson & Co, through this very informative analysis highlights the new alternatives and how they can be used to up a firm's profitability quotient.
As a company grows, so must its warehouse. As a warehouse expands and the activity inside increases, the efficiency envelope of the operation depends less on proper management and more on the software used to operate the site. This is not to propose that bad management cannot wreck a warehouse; it can, but it has been proven time and again that the warehouses that perform better than average have better software than average. This may be even more true today than it was 20 years ago.
This is an important point for logistics executives because for the first time in my 30 years’ career helping companies select & install warehouse software, there are some new choices. I don’t mean there are new WMS packages or vendors. I mean there are new types of warehouse software beyond the classic WMS package that companies typically install. I use this term ‘new type’ because this software is architected quite differently and it provides additional benefits that the classical WMS products will be hard pressed to duplicate.
Is this hype? I don’t think so. What we are seeing in the marketplace is the established players of the classic WMS products slowly losing market share in arenas they used to win regularly. Why? It’s due to these new entries that offer new value propositions. If your company is looking to upgrade its software or purchase new software for the warehouse, I recommend you look beyond the regular suspects.
To understand what is different, we must first explain the warehouse software market up until 3 or 4 years ago. Up until about 1998, most warehouse management packages weren’t packages. They were a conglomeration of code snippets from past projects that vendors would take ‘off the shelf’ and glue together to meet the specific needs of a customer. This meant each customer ran a little different code set making upgrades impossible and it was a lot of work to transfer functionality from one customer to the next. Projects were thus expensive. It was very difficult for smaller companies to purchase warehouse software. Big companies spent huge sums implementing these systems.
At the start of the new millennium, the market changed. The functionality offered didn’t generally change but the architecture of the products did. The ‘shelfware approach’ was replaced by the ‘package approach’ and WMS products started getting designed so that most features and functions were selectable via switches in the software. They also became rule-based; an expert could configure rules that would control the decision logic that the software used to make decisions that warehouse workers formerly made such as where to put something upon receipt or how to pick an order. Of even greater importance, generic-modifications needed by customers were designed with the idea that a) they would be rolled into the base code for future customers to activate and b) they wouldn’t impact existing customers who did not need the functionality. Finally, the vendors created points in their code where they thought customer-specific mods might be common to allow customers the best of both worlds, i.e., they could modify the code but still stay on the upgrade path.
This was a bonanza for small companies. It dropped the price of these systems dramatically. Lots of smaller vendors entered into the market to cater to this segment and the larger software companies constructed products aimed exclusively at smaller companies. This was perfectly timed as the Internet-craze created lots of small firms who needed such software. Third party warehousing also grew as a result, because now these firms could offer sophisticated warehousing to their customers without having to spend a fortune gluing-together WMS software for each new customer; they could just configure their existing software to the flows needed by each new customer. Also, because many of the larger, generic modifications to these packages were getting back into the base code, the functionality offered in these packages to new customers got a little better each year.
This shift gave rise to a new marketplace. It’s important to point out that many of the biggest vendors in 1999 disappeared because they couldn’t make the shift effectively. Furthermore, because it takes 3 or 4 programmers a year and a half to create something that ‘looks like’a package-WMS and because most WMS companies do not speculate on new functionality but add functionality that new customers pay them to create, the traditional WMS Package marketplace became composed of three types of vendors:
Vertical specific specialists or Tier I
Less expensive, slightly less functionally rich Tier II firms
Fly-by-night firms or Tier III
This has been the marketplace for the last 15 years. Furthermore, the floor-level functionality that is offered by this group has not been too substantially different than that offered over the last 30 years. This is about to change.
These packages have worked great. They have worked so well that many firms ignored upgrading to newer versions of the software for as long as a decade; this was because the new functionality offered by their vendors didn’t really seem to add much value.
In 2012, however, we started seeing larger companies who were forced to upgrade. The scenario developed as follows. As the hardware these systems used became less reliable and aged out, customers were left with no alternative but to upgrade their hardware. The database companies these systems ran on top of would then refuse to support their old database running on the new hardware, and they would demand these same customers upgrade their database software too. This in turn led the WMS companies to tell these same customers that they must upgrade their WMS software to run on the newer versions of the database. It was a software revenue chain-reaction.
This was less of an issue at smaller companies who hadn’t made much in the way of customer-specific modifications to their software, but at larger operations with material handling equipment and lots of people, the customer-specific mods they made years ago became a huge problem even with the user exits.Ten years is a long time when it comes to technology. To solicit new customers who were interested in the latest and greatest, the vendors had wildly changed their data models, technology stack,reporting tools, and so forth over that period. This meant to convert an existing customer to the new version was going to be a lot of work. We know of instances where these ‘upgrades’ cost nearly as much as the original installation or buying a totally new system!
At the same time, over the last 10 years, warehousing got more complex. Warehouses who were used to simply shipping pallets or cases in and out to one channel suddenly needed different processes for retail, wholesale and e-commerce. Products could also be customized on their way out. Amazon motivated even more change by attracting large numbers of smart, creative people into this domain who thought about warehousing differently and they created more competitive pressure to rethink how your warehouse worked. All this added up to a lot of change. Warehouses stopped fitting a static design pattern; they needed to be flexible to new ideas. Yet changing the software that controlled them was risky and expensive in the package world; you had to go back to the vendor to do it who were often resource constrained or uninterested in using resources for old business.
Managing these operations to keep everyone busy and the product going out on time became much harder as well. Managers who were used to telling associate-Joe to ‘go over and work in the such and such area of the warehouse all day’ were suddenly forced to move people around multiple times a day in order to keep people busy and also meet the tight shipping schedules of these different channel customers. From our experience, it is not uncommon to find 30 to 40 per cent of the labour simply wasted in these multi-channel warehouses as a consequence. The same thing happens to a somewhat lesser degree in many mechanized warehouses as well.
Recently two new types of warehouse software have risen to meet these challenges. First is the Personalized WMS. At first glance, the product looks very similar to a classic WMS package. It has switches and rules that let experts deploy different functionality and business logic for a customer; however, it often doesn’t have the functional depth that the vertical specialists offer especially in some verticals, so to many prospects this class of warehouse software looks initially to be disadvantaged compared to more classic packages. We have found the experience of actual customers who purchased this software, however, to be quite different. When we interview existing customers for selection projects, we learn three things. The functional gaps can be closed very quickly at installation if you get the right vendor team and you retain or hire the right people to define how it should work. More importantly following installation, the customer can enhance the software on their own, generating additional return above what a classic package would deliver and making the company much more flexible to change. Furthermore, when it comes to upgrades, upgrading the software costs virtually nothing; these products break the software revenue chain reaction.
Is this for real? Yes. How does it work? It happens because these products are architected in a very different way from a classic WMS package. While they hate this comparison for marketing reasons, personalized WMS products are really at their core a data model and a software toolkit designed to build WMS packages. These vendors provide a macro-like language that may be used to construct warehouse software functionality. This language lets average programmers develop at 5 to 6 times the speed of traditional development languages used by WMS packages. When you purchase the software, the vendor gives you their WMS written in this language as a starting point. They will offer to write extensions to the base WMS product in order to provide you just what you need. During the installation, your staff usually learn the language too. (It is not too complicated to learn) After the vendor leaves, you add more and more functionality on your own. When upgrade time finally arrives, customers upgrade the language not the WMS package. This keeps the database companies happy and the CFO happy. It sounds like this should be every firm’s choice, but there are some caveats. It tends to work well in companies that have a strong commitment to innovation and process improvement. Without this, you will likely favor a vertical-specialist WMS package. You have to commit to keeping resources on staff to learn the development language so that they may continually enhance your application. It’s important to bring these people on board at the start of the project too. Furthermore, you need to complement these people with others who are creative and experienced in your vertical to help continuously uncover opportunities and close gaps.
The appeal of these applications also increases if you have multiple sites that can magnify the return on your customerspecific- changes if you have just one site, the value of these systems diminishes, unless you have a large workforce at that site and the upgrade costs of a packaged WMS would be significant. Finally, there is truth in the statement, ‘Too much of a good thing is bad’. It is true with these systems as well. It is so easy to make changes that things can get out of hand quite quickly. You must have some structure around how changes will be done, tested, documented and deployed or you can end up with a mess like we had in the 1980s with lots of homegrown WMS software that became unsupportable. To get value out of these systems, you need an organizational as well as technical plan.
The second new type of warehouse software is a Warehouse Execution System. This term has been one of the most misunderstood and highjacked terms in logistics in recent memory. The majority of the vendors offering a WES are simply MHE suppliers selling their old warehouse control system dressed in new clothes and extended to provide some of the outbound functionality seen in WMS packages. These products are functionally limited and usually around only to help these companies sell their core offerings of conveyors and mechanization without forcing their customers to buy an expensive WMS package from a traditional vertical specialist. This is not what we refer to as a WES.
The key ingredient to a true warehouse execution system, which in turn, makes their architecture quite different from WMS packages or warehouse control systems is operations research technology. The simplest way to figure out if you are dealing with a WES pretender or not is to ask them ‘How many OR PhDs or master degrees do you have on your staff?’ If you hear the sound of crickets or get blank stares, you are likely dealing with only a WCS provider.
Many people think that machines / robots will soon replace the floor workers in warehouses. However, I am beginning to think the first people to have a large portion of their jobs automated will be the frontline managers. This is especially true if warehouse execution systems catch on. These applications require you to turn over a large portion of the hour by hour direction of where people should be and what tasks they should perform to the WES. Unlike the WMS packages that more or less record what people do and help ensure the warehouse associates do it correctly, the WES does this and also chooses what work should be released & when, what work people should do and where they should work and when to move.
The rationale is the 30 to 40%+ of labor that is wasted each day because you don’t have the right people at the right place with the right product at the right time. The other motivating factor is ensuring faster and more consistent response to customer orders. This is because the scheduling problem has got so complicated at many multi-channel and mechanized distribution centers that one or even a group of humans cannot decide all the trade-offs fast enough to make sure everything comes together on time at the right place. In more and more operations, the management of flow has exceeded the ability of human brains to optimize. This sounds incredible, but I recently found some academic research done on behalf of Amazon at MIT. The document suggests this is exactly what they are doing inside their sites.
To address this complexity, operations research technology is used to solve the warehouse flow and scheduling problems. You will hear new terms like ‘Move Logic’or ‘Waveless Picking’ when dealing with a WES supplier. These concepts are aimed at the heart of the issue. Algorithms are designed and somewhat customized at every site to decide when to release what work and when to move people. Some of this logic is table-driven and some of it is ‘tuned’ in code. The installation is much different from a classic WMS package as a result. The vendor has to learn a great deal more about your operation.
These applications are also not for everyone. If your warehouse is simple, these make no sense. If you have verified with time studies that you run a tight ship and your orders go out on time and you are not in a ‘service war’ with competitors, then this is probably not for you as well. Like the personalized WMS, you need some upfront engineering work to decide if it is worth the investment or if the classic WMS package will do just fine. But we would encourage you to do that in 2017. For the first time in a long while, it is worth doing your homework to see if either of these new types might be suitable beyond the typical suspects. The payback could be quite significant.