Beware of Unneeded OMS, ERP, WMS Modifications

Enterprise Resource Planning, OMS, order management system, warehouse management system, WMS, ERPRecently we had a chance to follow up with a client and vendor on the outcome of their seven-month system implementation negotiated last year. There are some unique lessons learned about making modifications to order management, ERP and warehouse management systems for all of us.

The prospective client felt strongly that it needed to hard allocate inventory because of the size and timing issue associated with its B2B customers. They agreed that for the direct customers, soft allocation would be better but because of the size and growth of the B2B business they needed hard allocation too.

I want to emphasize that an exception list of requirements was answered by several vendors, and two days of scripted demos were conducted with each.

In negotiations with the vendor finalist, they agreed to several unique approaches. The vendor liked the client’s ideas and agreed to handle the modification as a no-charge item if the client attended week-long first-level classes so both sides could better understand how the current system worked. This also allowed the vendor to better understand the scope of the issue and suggest options. If the client did not like the design outcome, they would be released from the contract and refunded their deposit.

I want to point out how unique this approach is. In almost all cases once you sign license and services agreements and pay the deposit, which can be 50% of the total license cost and a deposit on the professional service, you’re committed.

If the vendor had made the programming changes as first designed and estimated, the modification would have required 300 hours for design, programming and testing. By completing the education and having the extended discussion, the parties were able to find an acceptable compromise that delivered most of the desired functionality while avoiding negative consequences.

The results:

  • Programming took around 120 hours vs. the original estimate of 300.  At a programming rate of $150/hour, this saved $27,000;
  • The vendor did not have to make unwanted changes to the software application’s core structure;
  • The vendor is confident the application can now better handle both B2B and B2C operations, and the client got most of the changes it felt were needed;
  • The modification was added to the application for all users and did not create support issues with future releases;
  • The project was completed on schedule and the go-live date was met.

We have often seen clients demand many changes without completely understanding functionality. In this case the client was deeply involved in design and implementation. There has to be a sense of trust between the parties for any successful implementation, with both understanding each other’s issues before making unnecessary program changes.

We advise against any modifications that make the new system look or function like the old one. Use the new system for six months or more, if possible, to better understand its functionality. In a lot of cases the modifications you thought you needed aren’t necessary, as the “vanilla” version works fine and requires just minor changes to your business processes. Most of all, there is always room for some creative, open-minded solutions.

One of the biggest reasons for go-live delays and cost overruns is modifications, which happen for a number of reasons. Some of the most common involve an incomplete or insufficient requirements definition. These modification specs need to be defined in detail and signed off on internally by vendor and client management. Delays are also caused by a lack of testing to ensure the modification is working according to the spec definition and can support the business process. It not only needs to be unit tested, but should be incorporated into your conference room pilot testing to make sure it hasn’t adversely affected any other functionality.

Because ERP, WMS and OMS systems are so complex, you can’t always understand the functionality by just reading documents or seeing demos. Neither will this help you fully understand the potential effects of modifications on other system functions.

Curt Barry is president of F. Curtis Barry & Company