The majority of medium to large Warehouse Management systems (WMS) have been around for quite some time now in a variety of guises. There may have been multiple upgrades including major platform revisions, but the logic that drives specific processes is likely to have been based on that from the original design. In this article we will be exploring a number of key areas:
- Where it all goes wrong
- Understanding the need for change
- There are modification and Modifications!
During a WMS’s lifetime it will have received tens-of-thousands of man-hours of analysis, development and testing before being available for release, so where changes are made we have a core of industry experts advising and making these changes.
Occasionally, significant changes are required, usually to support industry initiatives (functionality to support the single item and consolidation challenges of e-fulfilment operations being a great example), however, the work behind these changes is significant and builds on the foundations that have supported the system for a long time. The (often adopted) alternative is not a path anyone should ever willingly choose to follow; dedicated customised functionality will definitely add cost, time (development plus testing) and risk to the implementation.
Additionally, remaining on an upgrade path becomes a cloudy topic. If a software supplier is reluctant to adopt a user enforced change there is usually a good reason; be it that the fundamental system rules are being compromised or that they just don’t have the correct development man-power to guarantee that the software and operational solution will be glitch free.
Why is it then that when purchasing and implementing a new solution we like to think that we are different, and in the early design phases we come up with a long list of modifications? Naturally, all warehousing operations have specific processes to cater for certain products, SKUs, suppliers or orders. Although fundamentally the same, the detail may differ. Some like to think of this as their unique operating advantage, and what makes them different from the competition.
However, the question one must ask is how different do we need to be to satisfy our customers’ requirements, and do these differences really need us to develop our own way of working? Obviously, there are cases where this is true, or at least partly true – we cannot treat all categories of SKU the same, and differing service levels will require different steps within a process or the timescales may need to be amended to facilitate a very fast turnaround.
Nonetheless, we should question whether we are truly unique, and to what level the uniqueness needs to be supported by a different process? A fundamental decision is required right from the beginning of the search for an appropriate solution.
This is an interesting (if not loaded) question: do we really think that we can design a WMS supported operational process better than a team of industry experts who have spent thousands of man-hours debating and developing logic? If the answer is yes, then either you do have something entirely unique which may be too valuable to share with a software supplier (as they may share it with all of their customers) or there is an easier, more logical way to carry out the same process.
If we follow through the broad steps of procurement through to implementation there appears to be a familiar pattern; high level processes are drawn up at the start of the procurement phase, where suppliers and their solutions are short-listed based on a combination of their ability to match these processes and their experience of real-life operations within the same industry sector. So far, so good. However, post selection is the ‘danger phase’ where operators with a greater depth of understanding of the current operation start to question the base functionality, comparing every aspect against the current process.
Most purchasers are not migrating from a modern WMS, instead they are moving away from an in-house or heavily modified package solution that just didn’t include the functionality required to support business changes since its initial implementation. These solutions have been updated over their lifetime to fit exactly the changes to process that the business has experienced, driving very diverse, dedicated functionality. It is these niche functions that are at the heart of the issue here, functions usually pieced together by a combination of operators and IT programmers working in an atmosphere when change needs to happen quickly in order to support an immediate business requirement. Purchasing a new solution is the perfect time to reflect on previous decisions, and ensure that operational processes are rational and fit for use both now and in the future.
Experience shows that once a business has decided that a modification is required that more will follow, therefore producing a long list of bespoke development. When looking objectively at WMS functionality we need to understand the root business operation which it supports, and understand if there is an easier or better way to do this. Analysis time and effort should objectively understand how the new WMS could be configured to best support this process. In parallel the software supplier should separately be requested to devise a process within their core application that can support your requirement. The key ingredient to achieving a solution within the base WMS functionality is an open mind and a willingness to compromise on the existing process.
The most effective tool to use within this process is a series of simple high level process maps; demonstrating the current operation and the proposed WMS operation. When broken down at this level it is far easier to understand how an operation can be slightly amended or the system could be used creatively in order to best support the contentious business process. This is the stage where a wide experience of applications and operations can prove invaluable; having the ability to think beyond the current constraints and apply the software to make the operation and the application work with little or no customisation.
In art, this expertise can be found within the WMS supplier project team who have vast experience of how flexible their system can be via the use of configuration tools. They will also have shared experience through many implementation teams (in some cases world-wide) who have been challenged to make their systems fit. However, intrinsic to their job role is an inward looking understanding of logistics operations, only really understanding the options that they have proposed via the use of their WMS. The addition of a neutral process design expert within the design team will ensure that decisions are appropriate, whilst also managing an expectation of minimal or no modifications.
There are modification and Modifications! Having built the case for modification free solutions it must be made clear that there are very few WMS implementations that have no modifications at all. Despite this being the target, each request needs to be reviewed on its own merit. It is therefore common to include changes to reports and labels, where there is any industry specific data requirement or where integration to mechanised solutions is required. Modifications to support interfacing is still common, despite the growing use of ‘out of the box’ integration modules which only support a limited range of host solutions. Most WMS providers have an expectation that their solutions will need to be customised in these areas.
Warehouse Management Systems have made significant progress as design teams have broadened their scope via development and acquisitions – as a result we now see a shorter list of software and solution suppliers than in the recent past. These guys are truly the warehouse management software experts. They build systems with a raft of flexibility and configuration options, allowing us to use the software itself to tailor our operation. Unless our business is significantly different we shouldn’t try to change this, instead we should direct our attention on ensuring we include a skilled WMS design lead who is knowledgeable of software. As an organisation you may want to ask yourself the question:
Are we prepared to change our existing processes to make best use of the software package we purchase, ensuring a safer implementation, or, are we prepared to add risk in order to preserve a process that has not been required by any of the other users of the software package we are purchasing?
If you are not confident about your WMS solutions please give The Logistics Business a call. We have the experience and would be delighted to help.