Structure of a WMS.

Should the Warehouse Management System (WMS) module be a ‘reasonable or acceptable’ fit within your ‘integrated’ ERP system or an application that meets your business and operational requirements, but is interfaced to the ERP system?

This is the question raised in my last blog, Interfacing or integrating supply chain IT applications, concerning software application used in Supply Chains. Now, the discussion will be for a specific (and critical) piece of Logistics software. The objective of a WMS is to assist in the management of customer orders, receipts and inventory movements within a warehouse or distribution centre (DC) and to link with internal and external applications (or modules) that generate data and information required for an effective WMS.

The diagram illustrates the main modules within a WMS. The Operations Control module shows both Scheduling tasks and Execution. This assumes that Warehouse Control is a part of the WMS, however it could also be shown as an interface from separate systems. Warehouse Control refers to the increasingly smarter equipment used in a warehouse, which includes:

• Materials handling equipment (MHE), operating in: receiving (includes returns), put-away, storage, picking, packing, labelling, sortation and shipping activities.
• Instruments and programmable logic controllers (PLC) used in machine to machine (M2M) and Internet of Things (IoT) systems
• Automatic identification and data capture devices (AIDC) used to monitor the flow of items through the warehouse or DC. These include barcode scanners, optical character recognition (OCR) and radio frequency identification devices (RFID)

The Warehouse Control units capture and relay data in real time via wireless transmission to an application that interprets the data into information. It then provides reports for action by schedulers concerning orders and inventory movements; or instructions provided directly to the scheduling system. The more automated the warehouse or DC, the more comprehensive the equipment. At some point in the selection process for a WMS, the equipment factor moves from being about stand alone pieces of equipment that provide ad-hoc data, to integrated sub-systems with their own control systems. These must be integrated or interfaced into the overall WMS.

Specifying your requirements for a WMS

If the WMS system is not purchased from the ERP supplier, there are interfacing issues to consider, as there are no standard interfaces to ERP systems. Also, if the Warehouse Control system(s) has not been supplied by the WMS supplier, it will have to be interfaced to the WMS, . Examples of other interfaces that are potentially required are also shown in the above diagram, including system to system links or portal type access, such as customer order status.

This situation illustrates that, as with other Supply Chain applications, a WMS comprises elements that will most likely be interfaced with other applications, rather than ‘integrated’ within one large ERP system. As this will become the more typical situation, it is preferable to select the WMS that fits your business needs, rather than just accepting a less than perfect WMS offered by the ERP supplier.

The structure of Supply Chain applications in your organisation should therefore be viewed with the ERP system as the backbone of a fishbone diagram, as shown above. The ERP contains the audit trail of transactions for sales order and receipts (‘quote to cash’), purchase orders and payments (‘procure to pay’), plus HR records and payroll and the accounting function. The bones of the diagram illustrate the selected Supply Network Analysis and Planning (SNAP) applications, interfacing with the ERP backbone to exchange data and information. In turn, the real time streaming data applications (Operations Scheduling and Control) interface with the SNAP applications.

As previously noted, in addition to interfacing with the ERP system and a Procurement system (to form your organisation’s Supply Network) there could be links from the WMS to other applications, such as a Transport Management Systems (TMS) and Global Trade Management (GTM) system. This enlarged and more sophisticated Supply Network will be even more dependent on information and analytics. Together with the  ‘always-on’ objective of some organisations, these factors increase vulnerability or the risk of shut down in the Network through security breaches or hacking. The levels of security required of the WMS must be identified, as part of a larger Supply Network.

This discussion has identified the need to identify the structure and operations of a WMS within the Supply Network. If sales staff from software companies are introduced too early in the process, the discussions quickly becomes one of comparing features and benefits of particular applications. Instead, take time to define the business and operational objectives and what role the IT applications play (in this case, a WMS). Commence with a description of your business requirements and role of the warehouse(s) and distribution in satisfying customer needs. Only after the business needs have been addressed, should specific warehouse operations and processes be defined.