Order Management System - Selecting the Right Software

   
For the past 20 years, major international IT surveys have shown that more than 50% of all large scale system projects - such as selecting and converting your business to a new Order Management System (OMS) -  are not delivered on-time and within budget and they fail to meet management expectations.  Some of the reasons include lack of project management;  failure to clearly identify the systems requirements and select appropriate solutions; failure to estimate accurately the total cost of ownership for the life of the system; and communications failures throughout the process. 
 
READ: How to Improve Your New Systems Selection and Implementation Process

This article identifies general IT industry practices which will help your company select the right Order Management System for your multichannel business. They have served our company well as we have worked with hundreds of multichannel companies.  The process works well for all major systems including Enterprise Wide Solutions, Warehouse Management Systems (WMS), Finance and e-commerce platforms.
 
Lastly we provide insights into the Benefits clients have derived from implementing an order management system. 

 

Establish Goals and Responsibilities

Top management should form a Steering Committee to set direction, review progress and resolve issues that arise.  Appoint Project Team representatives from each functional area of the business.  Select a person from this group to be the Project Manager or Coordinator giving the Team coordination on objectives, requirements and follow through with the vendors and outside resources.  Selecting and implementing an OMS should not be an IT project solely.  IT should be on the Team but we feel a manager from the user community should head up the project.  Balance selection of the OMS with what functionality the business needs to grow and what systems can provide WITH the technology aspects of the decision (hardware, database, operating system, program languages, etc.).  Formally agree on project direction and establish a Project Charter. 

As part of the Project Charter, the Steering Committee typically wants a reasonably accurate (+/- 10%) Project Cost and Timeline without spending months to do it. Unless your company has experience with OMS conversion it may be harder than you realize to establish these two goals with accuracy.  Vendor estimates are notoriously low and more aggressive than actual practice.     
 
To do a thorough assessment of the systems, select the finalist and plan the implementation typically takes 4 to 6 months.  From the point of contract signing, OMS conversions typically take 7 to 12 months to implement.  Can these time frames be reduced, sure?  But remember your staff has full time jobs and it takes considerable involvement in requirements process, vendor demonstrations, etc. 

Documentation of User Requirements

The objective is to draft the system requirements for the business and all departments using the OMS.  The typical functionality is for order entry and customer service; credit and payment processing; order processing; warehousing functions of receiving, checking, marking, put away, replenishment to forward picking; customer order processing of pick, pack, ship, and returns processing; DC inventory control and cycle counting; marketing; merchandising and management reporting.  OMS often do not have General Ledger and other accounting functionality. 
 
To collect and agree upon these requirements, interviews will need to be conducted by department.  Then department’s requirements are brought together into a single document.  Also collect key reports and analysis that are performed in the current system and use system data in data warehouses or spreadsheets. 
 
It is also helpful and often essential to flow chart the processes of the current business environment in the departments.  This will assist you in explaining what actually is happening rather than what you think is happening or used to happen.  They are also helpful to understand how a prospective system can fit in the current business environment or how the business processes need to be changed.  The user departments need to review the requirements and sign off on the work product and deliverables.  The Steering Committee should review and sign off also so that the system selection process meets their current and future business objectives. 
 
How detailed are the requirements?  Can we write an exception set of requirements rather than a full set?  Because of the broad range of functionality a complete set of OMS requirements may be between 1,500 to 2,000 requirements.  An exception set of requirements may be more like 500 to 900 requirements.  The concept of the exception set is to specify the more unique requirements for your business.  This assumes you know fairly well the functionality of the prospective vendors you’re sending the Request For Proposal to.  

 

Create Request For Proposal (RFP)

In this step, you convert your requirements into an RFP format.  Include your company  background, management objectives, expectations for total cost of their products and services including licenses, hardware, software, 3rd party hardware and software, services; training and conversion; annual maintenance support; methodology and project planning.  As much as 50% or more of the cost may come from professional services. Discuss how your team sees the project proceeding and your specific instructions for replying to the RFP. 

 

Send RFP to Vendor(s) and Get Written Proposal Responses

Pre-qualify vendors in advance that their system provides the functionality you are looking for. Create a short list of 3-4 vendors if at all possible.  Dealing with a larger number, answering questions, judging which to invite for demonstrations will be unmanageable for a larger group.  Set up Excel spreadsheet to compare vendors’ responses side by side.  Set up another spreadsheet with all the categories of cost and compare the bidding vendors. Allow 3-4 weeks for vendors to fully answer and return responses.

 

Vendor Demonstrations

From the side by side vendor comparisons of functionality and costs, determine which vendors to contact and schedule for demonstrations.  We would keep that number initially to the 2 or 3 that best serve your requirements.  We believe the best way to conduct the demonstrations is to script the demos and give the vendor time to prepare the demo with what you want to see rather than just letting the vendor demo it their way.  Order Management Systems, because of their broad range of function, require at least 6 to 8 hours to observe the functionality in detail.  This is an area where companies typically often spend a couple hours and think they have sufficient exposure to make a decision which is a mistake.  During the demos someone on the Team needs to keep track of the observations versus the way the vendor answered the RFP.  Adjust the vendor comparison with the Team’s observations.  During the demo there may be areas where modifications are necessary.  Keep track of these and follow up in detail the modifications with narrative, screen mock ups and other descriptions.  There should be a “to do” list for vendor follow up, potential modifications, questions, etc.  An additional demo and follow up may be necessary to get the list resolved.

 

Preliminary Vendor Selection Finalists

From the demos arrive at the two best potential vendors as finalists.  Take these two through the final steps in the negotiation.  This will end up with the best decision for your company.  Draw up a list of questions and interview as many references as you can. Then schedule at least one site visit for a couple members of the Team to businesses which are comparable to yours.  We also recommend visiting the vendor finalists headquarters to meet the management team, interview the potential project manager that you will be working with, understand their philosophy on R&D and if there is user group that recommends enhancements, etc.  Remember generally these systems have a longer life and take 8-12 months to install.  You have expended a lot of effort, don’t shortcut these final steps.

 

Specifications of Customizations (assumed minimal)

We believe that companies should do everything they can to initially not modify the systems.  Modifications add risk, cost and lengthen the schedule with specifications, programming and testing.  If modifications are necessary, detail the screens, reports, calculations, etc. of the necessary changes.  Put these in writing, ask the vendor to prepare an estimate of the hours, dollars and timeframe required.  Few vendors are going to do modifications fixed price.  Work with the vendor to give you a fair bid that has a certain level of accuracy unless you change the scope.  Don’t sign a license agreement without understanding as best you can the costs of modification. These costs can be major.  Your company and the vendor should sign off on the specifications and estimates. 
 
Implementation Planning

As part of the RFP ask the vendor and the Team to do the best possible planning for the implementation.  Most vendors will want to do the detail implementation planning in the implementation phase.  We advocate doing as much as you can before the decision is made and contracts are signed.  This will give you important observations and task lists of how much your process and business environment will change.  This should become part of the business decision process.  The objective is to identify the assumptions about what your company will be responsible for; all the processes and procedures that will change, what resources are necessary; a detail view of training process; and conversion of specific what files; and a realistic time frame for the project.  As we said earlier, over 50% of major projects are over budget and off schedule from the original assumptions. 

Final Vendor Selection

Evaluate the total picture – the total cost of ownership, the fit of the system; what the vendors’ customers say about their support; and observations from site visits, etc.  

 

Vendor Negotiation and Contracting

We believe that an attorney that specializes in intellectual property law should review the agreements.  Review of software licenses, professional services and support agreements.  Include all key decisions you have made including timeline, modification specifications, assumptions about services, etc.  should all be part of the agreements.   
 
A Word About Sign-Offs

Throughout this article we have mentioned places where vendors and the user community should sign off on deliverables, requirements, plans, etc.  Since the 1970s as general IT industry standards have evolved sign-off on key deliverables has become a standard.  It’s also the best way for you to get buy in from the management and department users. 

READ: 13 Information Technology Cost Reduction & Productivity Improvement Ideas 


Benefits

Most Teams can come up with a soft list of benefits for moving to an Order Management System.  In today’s business climate and with the competition for capital, CFOs we work with want to see a Return on Investment (ROI) within 18-24 months.  Frankly, this is one of the hardest steps in the process.    However, here are some areas to consider:

  • How will Customer Service be enhanced?  Is the on-line, closely coupled website to OMS business system essential to growing your business?
  • How will the new OMS improve inventory management resulting in higher initial order fill rates, improved turnover and reduction in aged inventory?  Inventory is the largest balance sheet asset.
  • How will the new OMS and resulting process reduction labor costs in the call center and fulfillment centers?  Eliminating process steps and touching product less times decreases costs.
  • How can bar code throughout all the steps inbound product and outbound customer fulfillment reduce costs?
  • How are errors reduced?  Studies on errors show they cost $35 to $50 and often loose customers in the process so you lose the Life Time Value forward.
  • What are the merits of the technology being proposed?  Does it allow you to adopt other alliance partner applications and websites that are not possible?  Is the change out necessary because expense and difficulty of supporting aging technology, data bases and languages?