The more WMS provider’s clients twist, bend, and otherwise contort their software, the more likely support-heavy issues will arise.  This is not only costly in terms of supporting clients, but can also potentially affect the reputation of their product.  Customers aren’t deviating from standard product for no reason of course, as they have their “own way” of doing things that is either better overall than the recommended route or “must be done BECAUSE X” – where X can be anything from an array of additional serial numbers to Irving not wanting to use one of those “newfangled scanners.”  There are certainly plenty of valid – as well as invalid – cases to be made for modifying your WMS.  In this blog article we’ll highlight a process to help determine if a particular WMS modification (AKA customization) is worth it, in order to help you sift through those “must haves”, “nice-to-haves”, and everything in-between.

Cosmetic changes are usually low risk, like adding a customer logo to a packing slip.  However even the smallest functionality and/or data modification can drastically alter everything in an enterprise application, including future upgrades and integrations.  This in-turn creates pitfalls for both technical teams and business users, and the added technical debt makes testing (preferably test automation) even more critical.

Integrations are much easier these days thanks to APIs.  System vendors realized that integrators need a universal standard, and so everything shifted towards API rather than traditional integration methods which can be tricky to maintain.  If you need to integrate your WMS with another system there very likely exists an out-of-the-box option.  Blue Yonder for example has a product called Robotics Hub that enables the quick and easy integration of multiple robotics vendors, with visibility into them provided via a single, unified dashboard.

With warehouse management systems moving to the cloud we might one day lose the ability to customize outside of vendor-supplied options, but while we are able to do it…There MUST be a process in place to determine if a proposed modification is worth its salt.  If we have identified no alternative solutions or workarounds and have a proposed functionality or data customization change for an already-implemented WMS, then your team will need to determine if the mod in question is truly necessary.  ALL stakeholders should be involved in these discussions as modding your WMS is serious and should not be based around the whims of one finicky, demanding WMS user.  Let’s use the following checklist:

Do we really need it?

Can we handle the customization via the configuration route rather than customization?  Blue Yonder WMS offers workflows that can be configured to trigger before or after standard functions, so for example if you need to auto-print a bill-of-lading after loading this can be setup without code-customization.

Is this customization a must-have or a nice-to-have?

Can an existing process be altered to get the same or similar result, and so in-turn we no longer actually need the customization?

Providers such as Blue Yonder invest a lot in R&D, and already provide an optimized suite of functionality for several different types of verticals…so if it is not included as stock, are we sure we haven’t found another way of skinning a cat?

What’s the ROI?

Is the customization going to result in a medium-to-large increase in operational efficiency?  If possible, assign a dollar value over the course of years to the post-mod improvement.  This could be man-hours, a new customer that results from the change, etc…

What is the current cost to implement the customization?

It is no longer enough to consider only the current cost, but your team must also consider any future cost for maintaining and upgrading the customization…so what is the projected future cost?

Now your team should do the math on the ROI, and then further consider…

What’s your WMS vendor’s take?

If the WMS vendor receives the same customization request from many of their clients, would they consider adding it as a stock option?

Is the WMS flexible enough to handle the customization?

Do they charge additional fees to support customizations?

What are the risks?

Is the support cost likely to increase down the road?

Will future upgrades and testing be more expensive?

Is it going to break something else, now or later?

Ideal Example: The warehouse needs an extra field to keep track of a key customer’s proprietary PO number.  The WMS vendor works with your IT and super users to ensure that new field is properly added to the system and printed on the customer’s label.  More importantly, they work together to ensure that future updates and integrations don’t break.  After a healthy amount of testing and the relevant users are trained, the field is added and the customer is happy.

Horror Story Example:  The warehouse needs an extra field to keep track of a key customer’s proprietary PO number.  Your warehouse manager assigns the intern to handle it since its just a single field that is only used for one customer.  The intern makes the addition to the WMS, and abruptly leaves the company before doing any real testing.  Shortly afterwards the weekly automatic export to the accounting system breaks, the latest WMS update fails, and because the intern forgot to add the field to the barcode on the client’s label there is now an annoyed key customer – thus creating costly internal and external headaches.

If your team is moving ahead with the mod, then you will need to determine exactly how and when to apply it to your WMS.  Proper change management also dictates that users should be trained on any new process flows.

We can’t in good faith advocate for zero customizations because we know that warehouses aren’t all exactly the same, but certainly going overboard with them gets risky.  We advocate that you carefully consider the ROI and risks, confer with every stakeholder, and make an informed decision.  If your team needs help determining if a WMS customization makes sense, feel free to drop us a line.