SCDigest Editorial Staff

Service Oriented Architecture, or SOA, is changing the way a Warehouse Management System (WMS) will run, offering users new levels of efficiency through increased system intelligence.

Though the topic of SOA often puts operations managers to sleep the reality is an SOA-based WMS, if properly developed, can result in a system that is based on thousands of discrete pieces of functionality or services, rather than different specific applications (receiving, putaway, etc.) that may be linked but that must behave in limited and usually inflexible ways.

With SOA, these capabilities can be linked together to create a more flexible and intelligent WMS, one that can react to events in the DC to further optimize distribution performance.

In distribution and broader logistics operations, processes involve nothing more than a sequence of events, decisions and actions. These events can be normal, expected, predictable - but at times they can be unusual, unexpected, variable, or random.

Using the event-driven WMS model, it is the occurrence of specific events, rather than application code, that triggers functionality and subsequent action. For example, consider a cross dock application, as illustrated in the figures below. Let’s suppose that an inbound shipment was planned for cross docking, but at unload time the outbound door or trailer is not yet available.

In a traditional system, this would likely require several manual decisions and processing – a supervisor observing the lack of the available door, directions to dock workers to put the inbound goods in a temporary staging location, additional directions when the door becomes available to start loading the outbound truck, all these activities primarily conducted outside the logistics system itself.

The event-driven system approaches this situation in an entirely different way (see graphic below). The WMS scans the dock environment when the inbound truck arrives and recognizes the outbound trailer is not yet available, triggering system direction (via handheld terminal or workstation) to move the goods to an available staging area.

In the middle of this process, when the event of the outbound door becoming available occurs, the system recognizes this changing condition and both directs goods from the truck into the outbound trailer, as well as creates tasks to move the staged goods.

This is a fundamentally different way of handing WMS system development, and has enormous potential benefits for improving efficiencies and optimizing logistics flows.

Yes, there are many existing functional parallels to this cross docking example – but the result is usually achieved by a different and much less robust means. For example, in many systems when an order picker is unable to pick an item due to a discrepancy between what the WMS system thinks is the inventory quantity in a location and what the operator finds, that “event” will trigger a task to do a cycle count of the location.

However, to achieve this effect, the WMS provider must hard code this logic into the picking application. If there are multiple scenarios that could trigger a cycle count, this functionality is achieved by replicating the logic in different application areas, and/or writing a long series of “if/then” statements into a specific piece of code. This significantly limits flexibility to make future changes, and is an approach that can be used for a relatively small number of event-action sequences.

In the true event-driven approach, the cycle count function is not tied to a specific piece of application code, but is linked to or triggered by any number of different events. It is independent of a specific hard-coded application, and therefore can be easily augmented or changed based on new processing requirements. This flexibility makes it easy to craft event-driven processing in an unlimited number of logistics scenarios.

(Distribution Article - Continued Below)

So let’s consider other examples of the way an event driven-system might intelligently handle specific exceptions or conditions in the logistics flow. The system could look forward into downstream packing and consolidation areas for congestion, and reroute or delay releasing work until the “event” of a work area freeing up occurs. Perhaps the DC is using an automated material handling system, and a photo eye on the conveyor becomes blocked or disabled.

The WMS recognizes this unexpected event, triggering the use of alternate paths along the system, or a more manual mode of order consolidation. At a broader logistics system level, the “event” of an exception notification from a truckload or LTL carrier that a shipment is going to be late might trigger that a small quantity of the item be picked and shipped via overnight to ensure the customer has enough of the needed item until the scheduled shipment arrives.

This dynamic Event-Decision-Action model, conforming so naturally to the way logistics functions really operate, is possible with the event-driven logistics system because it occurs without any specific logistics application program getting involved. The event-driven approach in turn is really dependent on an SOA-based WMS architecture to enable it.

This event-driven model will also improve the ability of the WMS to work with different sorts of DC automation systems, and increasingly allow the WMS to act like a “proxy supervisor” that monitors and manages what is happening in the DC at even greater levels than today’s vary sophisticated WMS solutions. As adoption of RFID continues, the event-driven approach becomes even more important, as the WMS must react to RFID reads wherever that are encountered, rather than to expected bar code scans within a specific application.

SOA may be mostly in the realm of the IT wizards, but it has already changed how WMS and other logistics applications are deployed and used today – and will have an even more profound impact in the coming years. Logistics managers need to get at least a little smart about SOA and what it can do for them in WMS.

What are your thoughts on the event-driven WMS process model? How can you see it improving DC operations? Let us know your thoughts at the Feedback button below.

SCDigest is Twittering!

Follow us now at https://twitter.com/scdigest