Recently we had a chance to follow up with a client and vendor on the outcome of their seven-month 
implementation negotiated last year. There are some unique lessons learned about making modifications to an order management system; or an ERP or warehouse management system 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 their wholesale business to business 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 demos were conducted using scripted demos with each vendor.
While in the negotiations with the order management system vendor finalist, the vendor 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 the license and services agreements and pay the deposit, which can be 50% of the total license cost and a deposit on the professional services, 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 were the following:
- 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 order management system 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 owner was deeply involved in the design and implementation. There has to be a sense of trust between the two parties for any implementation to be completed successfully; 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 the functionality. In a lot of cases the modifications you thought you needed are not 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 an order management system is 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.
SHARE