If this were reality, we could make perfect decisions every time.
In the real world of logistics operations where processes, people, facilities are varied and change daily it doesn’t work that way. Businesses rarely have the time or the data to work this way. Real questions facing managers and decision makers are far less defined and much more urgent.
"I need to know when our cool house is busy…. properly busy!! When it would make sense to send stuff offsite……I need a number”.
This is a real question I was asked recently by a client and is typical of the type of issue facing live operational environments. Here we had a director armed with plenty of anecdotal (and contradictory) evidence from the warehouses, but a desire to find if a tipping point did exist and how to use that to better plan operations.
These problems require a different approach. They are challenging, require a lot of lateral thinking and often the answer we end up with is not necessarily the one anticipated….
But they are also a lot of fun.
Practical modelling requires downstream data skills, getting to that point though needs a different skill set.
Understand the business
My approach is to spend time in the operation, on the warehouse floor. From here I can see how people behave. For me these are critical inputs to the modelling and they enable me to interpret data. For example, when looking at time clock data, I can match this to how I see people move between activities or change roles, it adds context to numbers.
It also has a more fundamental purpose, by understanding the operation I can ask better questions. This helps to adequately define the problem.
Defining the problem
In my client’s case…. what did “busy” mean?
Was it a measure of the headcount, delays in receiving or shipping, or rising costs? In discussion we worked out that it was when teams ‘felt’ busy. When the shifts reported being inefficient, disrupted, hassled or overloaded. That’s not a typical metric captured by any IT system and required a bespoke approach.
The solution here was to focus on and then define a measure of efficiency; if we could track this metric through busy shifts and quiet shifts we could expect to see change when teams were busy. Importantly, we could watch this metric in the build up to a tipping point to provide a method of forecasting or planning.
I explored several metrics with the client based on payroll cost and headcount before settling on a time-based metric that considered the number of seconds per operation. As a broad metric it would include a range of activities all of which would be affected by being ‘busy’. Time is also constant and unaffected by regional or shift rates. Again, time per activity is not something that can be pulled easily from one system, unlike cost which is often the primary measure of many activities.
Gather the data
Often the greatest challenge, there is never a single source of data.
Even in highly sophisticated operations data is often fragmented across multiple systems, even more so when separate business functions run independent systems. Some count pallets… some count SKU’s. Sometimes the data just isn’t there and you have to get creative such as hiring grads to sit on dock doors with stopwatches for a week.
For this particular problem, we were able to pull data from payroll (identifying working time), transport (volumes in and out), WMS (stock on hand) and buying (converting pallets volumes to warehouse activities).
Model the data
The relatively simple part of the process.
Explain the answer
Communicating the results in a way that explains the process and the answer requires careful design. Visualisation design for communicating data is a mixture of art and science but is a critical part of the process. I generally use Tableau.
It’s important to tell the story of the data to provide context; detailed enough for when someone wants to drill down, concise enough to quickly communicate the message, and complete enough to be useful in decision making.
As to this problem, I was able to provide a definitive answer as to “when” the operation was busy and in which DC’s this did or did not happen. The final model provided volume numbers that, when reached, would indicate the warehouse was ‘busy’ and productivity would begin to decline.
Interestingly, it also demonstrated how each DC across the network managed the ramp up differently, offering a great opportunity for internal discussion and learning. It also formed the basis of a forecasting tool; future buying volumes can potentially assist in early planning of escalation or offsite activities.
Developing practical models for clients that have real and tangible benefits to operations is hugely rewarding in exactly the same way as delivering a new facility or warehouse. I hope to be able to share some other interesting case studies that show how useful this approach can be in future posts.