In last mile, Pareto and 5 Why were not presentations. They were part of the daily analysis of the KPIs, especially for delays, damage, incomplete orders and loading time. But precisely for that reason I want to describe them the way I used them, not the way they look on a slide.

The most documented case I have kept is a delay report from one day in August 2025, with 19 cases. The causes were not all the same. The report shows missing bags. A full trolley that was missing. Bags with the wrong label. A bag placed or loaded in the wrong place. Disorganised trolleys or mixed bags. Trolleys that were not ready, where the driver had to do the scanning himself. Many trolleys and long loading. Damaged bags that had to go back to the warehouse. Orders with heavy crates and checks that took time. Traffic and parking problems. Long stops. A payment problem.

The data came from the day's operational cases and the concrete reasons for the delays, not from a theoretical survey. And here I want to be precise: I did not keep the original Pareto table, with the number of cases per category and the cumulative percentage. So in this essay you will not find a sentence like "42% of delays came from missing bags". A number like that would look professional, but it would not be documented.

What I can say for certain is this: when we split the delays by cause, patterns started to appear. Missing bags and problems with trolleys and loading show up several times in that report. And many of the problems that ended up as "driver delay" had started before the driver left the ramp.

That is why Pareto is such a strong tool, and such a dangerous one. Pareto does not give you the truth if the data you feed it does not describe the truth. If on the dashboard an incident ends up as "driver delay", while on the floor the delay had started in the warehouse with a missing bag, a trolley that was not ready or a wrong load, then the chart is mathematically correct, but the operational conclusion is wrong. The wrong category leads you, with great confidence, to the wrong cause.

Something similar happens with 5 Why.

I have a real case, but only the start of the chain. The problem: a wrong bag had been loaded. Why was there a problem with the delivery? Because the wrong bag had been loaded. Why had the wrong bag been loaded? Because the bag had been put in the wrong place during loading. A corrective action came out of the analysis: the loading had to be checked twice. Beladung doppelt prüfen. And one more thing mattered: the problem was classified as caused by the warehouse and loading, not automatically as the driver's fault.

That much is documented. I do not have the third, fourth and fifth why written down. I could fill them in now with sentences that sound good. It would be a beautiful 5 Why on paper, but not necessarily the one I actually did. And that is exactly what I want to avoid: 5 Why is not asking "why" five times to fill in a form.

Its purpose is different. It is to move from the question "who did it?" to the question "what in the process allowed this to happen, and what can we change?"

People stop at the person very easily. "The driver took the wrong bag." If you stop there, you have found someone to blame, not necessarily a cause. The next question is the one that matters. Why was it possible for the driver to take the wrong bag? Was the bag in the wrong trolley? Were the bags mixed? Was the label wrong? Was a check missing before departure? Was the loading process so unclear that the same mistake could happen again with another driver?

When the answer of an analysis is only "the employee was careless", very often the analysis has ended too early. Because if tomorrow you put another employee into the same process and the mistake can happen again, you have not changed the system. You have only changed the name in the report.

From that case and from other cases in the same period came concrete measures. Double-checking the loading. Bags not mixed in the same trolley or box. Trolleys organised by route. Clearer control of loading. Following the scanning process. Final completeness checks. Ramp audits. Clearer standards for the drivers and for dispatch. Operational responsibility was shared between the shift structure, dispatch and the people responsible for each process, and as a manager I followed the KPIs and the problems with the Shift Leaders and the dispatchers.

In that period, damage came down from roughly 3% to 1%. But I see that as the result of the team's work and of a wider system of controls, not as the result of a single 5 Why. I have no proof that this particular case caused that drop, and I do not want to present it as if I had.

If I had to sum all this up into something a manager can use tomorrow, it would be three things. Check the categories before you trust the chart. Do not stop the analysis at a person's name. And write down only as many "whys" as you have really asked, then keep asking on the floor, not on the form.

An analysis padded to look good is more dangerous than an incomplete analysis that admits its own limit.