By Peter Hilton
The supply chain industry is characterised by complex interlocking processes that span companies and continents. This article introduces one small example of a supply chain process: shipping products from a warehouse where product inventory is stored.
A pair of headphones, however small, covers a lot of ground between leaving the factory and you putting them on. One of the steps in this supply chain is the product manufacturer’s warehouse where they are stocked after manufacture. This is where they wait to be sold to the next distributor in the supply chain. The next step is to load parcels on to trucks.
Product manufacturers typically run warehouses that contain an inventory of their products, ready to be shipped. From the warehouse operations perspective, these products are passed on to a carrier whose trucks transport them to the next supply chain milestone.
Within the warehouse, there is a shipping process that handles customer orders from distributors, the next step in the supply chain. The warehouse is where a customer order – initially just information – results in physical activity and becomes associated with physical products.
The goal of this process is to ship the products for a customer order. The key tasks for achieving this are shown in this process overview diagram:
When a customer order arrives, the first task is to pick the products, which means finding the correct items from the product stock in the warehouse. The next task is to pack these items into one or more parcels ready for shipment. The final task is to load the parcels onto the carrier’s truck.
This is just a high-level overview, though: warehouse operations are more complex in practice. If you started with a simplified process like this, you would end up editing the process to add additional tasks.
Although it would be natural for a process model to start out simple, when first trying it out, it’s natural to add detail to the process to achieve process management goals. These might be to improve the quality of process results, to increase transparency about what’s happening to enable process management, to enable process improvement (re-engineering) or to automate process tasks.
At the start of the shipping process, you can add a process task to explicitly retrieve the customer order.
If the process is triggered automatically, perhaps from an email, then this could indeed be a user task to find the order in an external system. Alternatively, you might want to add this task as a prelude to automating it using a script task: if the order number is known when the process starts, then a script task could automatically fetch order details from an order management system.
Note that Effektif’s process editor has a neat way to insert tasks like the Retrieve customer order task that saves you from having to disconnect and reconnect the arrows.
First click the User task toolbar button to add a new user task to the diagram, and then drag it onto the sequence flow where you want to insert it into the process. When the sequence flow highlights in green, drop the task you are dragging, and Effektif inserts it into the sequence flow.
The next place to add more tasks is after packing the items into parcels, because additional work is required before the parcels are ready to be shipped. The parcels require shipping labels that will ensure that they reach their destination, and these labels require parcel weights (which affects shipment routes and costs).
You can add two more tasks for weighing parcels and printing labels:
These additional tasks might not be necessary in practice, because they could be included in the work for the Pack items into parcels task. However, as before, the additional tasks may help you achieve process management goals, such as tracking the weighing task separately or automating label printing.
The process ends with loading an order’s parcels onto a truck. Again, there are several tasks that you can make more explicit:
Two of these are quality management steps: checking the packing quality and the number of parcels. These mistakes are cheaper to correct here than later in the process, after the parcels have been loaded on the truck.
In this case, there may be an important disadvantage to extracting the two quality control checks – inspecting packing quality and counting parcels. In practice, warehouse staff may perform better if they can decide on a case by case basis whether these checks are necessary, and what order to do them in.
Instead of performing all four tasks in sequence, it may be reasonable to perform the three tasks before loading the parcels in parallel, perhaps by different people. Perhaps the earlier packing task records the number of parcels, in which case the process could skip the parcel count check when there is only one parcel, or when there are only a ‘small number’ of parcels.
Finally, there is more to completing the workflow than loading the parcels on to the truck. There are other tasks to complete at the same time:
These tasks are shown here as being performed in parallel, but this will not necessarily be the case. It might also be necessary to change this model, in practice, to avoid errors like updating the order status to ‘shipped’ even when some other problem prevents loading the parcels on the truck.
Two of these are updates to external systems to record the shipment – order status in the order management system, and stock level in the inventory management system. These are natural candidates for automation, to avoid errors. The other additional task is to forward order information, such as the delivery address, to the transporter who moves the order to the next step in the supply chain.
The result of adding tasks to the process model is a more complex workflow than the original overview:
Identifying these additional tasks may make the process seem more complete, but is not necessarily useful in practice. Perhaps the easiest way to discover the right balance is to actually run the process and evaluate the costs and benefits of each separated task, and adjust the process model accordingly.
Even if the real-world business process stays the same, there may still be opportunities for improvements to the model, especially simplifications. This is why it is important to see your process model in Effektif as something that you can and should change frequently. And of course, the real-world process will not actually stay the same, so there will often be changes to make.