WMS Systems Integration
There is at least one integration with every Warehouse Management System (WMS) Implementation project. It’s important to plan carefully and make sure you’ve got team members with integration experience as integration can often be where a WMS Implementation project hits delays. Here are the first four key items that need to be identified:
- All systems in the integration network
- Role of each system (i.e., host vs. slave) and the flow paths of messages and data (i.e., push vs. pull)
- Physical and systemic events that should trigger messages (transactions)
- Common primary data elements that drive the system (SSCC, order number, wave number, etc.)
Here are some tips in each area that will help lead to the successful design of a WMS systems integration:
- Identify all systems in the integration network – Yes this seems obvious, however, many WMS systems integration projects have surprises with this. Not only is it necessary to identify the systems, but the systems’ limitations also need to be understood. For example, your WMS might be able to handle an order line number and order sub-line number, but can your ERP or OMS do the same? Take the time to fully identify ALL of the systems that impact your integration upstream and downstream – and make sure to work within the design limitations of those identified systems.
- Identify the role of each system (i.e., host vs. slave) and the flow paths of messages and data (i.e., push vs. pull) – There is too much room here in this area to make incorrect assumptions. Not every system can be a “master” system and there needs to be an upfront understanding of which system is the host and which system is the slave. Keep in mind the roles can change based on transactions. For example, when it comes to the SKU master, often the ERP is the Host and the WMS is the Slave. But when it comes to the Inventory position, the roles are typically reversed. Another important aspect is determining if a system will push data or pull data. This can have dramatic effects on overall integration quality, as well as the ability of the business to meet Service Level Agreements.
- Identify the physical and systemic events that should trigger messages (transactions) – Interface mapping does not stop once all the fields have been identified and agreed upon. You must also consider when an event should fire. A great example here is if you plan to send a daily shipment reconciliation transaction to the ERP from the WMS. Make sure the reconciliation file only contains shipments that crossed the event that caused the original shipment confirmation transaction to fire. Having that clearly defined will help all parties to understand when data will arrive.
- Identify common primary data elements that drive the system (SSCC, order number, wave number, etc.) – There is data and then there is primary key data. It is very important to understand what fields are considered primary data elements (or keys) so that those pieces of data can be preserved and reported back correctly.