Everyone would prefer to have all Order Management System (OMS) functionality in a single system. It eliminates programming and support costs and reduces the need to deal with multiple vendors and potential data problems. Whether that’s possible depends on your requirements and the size and complexity of your company. We find that even the smallest companies often have some interfaces.
An interface allows you to move data between one or more systems in one or more directions. Think of an interface or integration as a pipe or the conduit to move data. Usually, the OMS becomes the system of record and the website is the secondary user. The inventory availability shown on the website as a customer orders can be an on-line real time integration. Or it can be uploaded periodically through an interface (e.g. hourly with updated product totals).
When you look at integrations, each type of transaction becomes an integration point.
In the multichannel industry, vendors have developed standard data mappings between commonly used applications. Some examples: OMS and Inventory Forecasting Systems (e.g. Direct Tech); WMS (e.g. Manhattan & Associates or Red Prairie); vendor drop ship (e.g. VendorNet); credit processors (e.g. Chase or Litle & Co.); OMS data conversion between systems and business intelligence tools (e.g. Taurus Software).
Here’s how to develop requirements:
Determine what data is to be exchanged at a subsystem and data field level between the proposed systems. Start out by developing a high level data flow diagram of the prospective interfaces between systems. A simple example would be exchanging products’ SKU demand, sales, returns, cancellations, purchase orders, receipts, inventory adjustments, etc. between the forecasting system and OMS.
Then take each transaction to lower and lower levels of detail design. Develop the data field attributes for transactions from the OMS to the Inventory systems. Ultimately, this process will give you the detail requirements for your design document to discuss with vendors.
What direction does the data flow in between systems?
What is the frequency and schedule of the data availability? Will the data need to be on-line, real time; scheduled batch, or quasi-on-line?
Do the vendors have thoroughly documented Application Program Interfaces (APIs) to design your data mapping and programming around? Does the vendor have a similar interface or module interfaced to other systems that can be modified for your use?
Make sure that all your research gets documented and signed off by your staff and the vendors’ integration team.
For larger projects with dozens of interfaces you may be able to justify licensing software tools that ease the initial programming and maintenance of interfaces.
Systems testing between a critical on-line provider (e.g. credit processor) and your OMS, you may have to schedule one or more tests and receive their certification or sign-off before putting into production.
If you don’t have the internal skills to take on the necessary interface/integration, it’s a good way to use consultants or the vendor’s analysis on a contract basis.
Remember, the “devil is in the details”. The more diligent your research, the more accurate the estimates for time, costs and schedules.
Curt Barry ([email protected]) is president of F. Curtis Barry & Co., a multichannel operations and fulfillment consulting firm.