Case Study: Milkrun system implementation in the automotive industry

A milk run implementation rarely starts with the purchase of a tugger train. It starts with the question of why three or four forklifts are circulating around the facility of a European automotive components manufacturer at the same time, passing each other at the same crossings and running empty on half of their trips. This case study shows how a structured internal logistics audit turned "on-call" transport into a stable delivery loop served by a single tugger train.

The starting point: on-call transport instead of a process

The plant produced on several lines, and material reached the workstations in response to shortages. The line operator phoned when a container was almost empty, the warehouse sent a forklift, and it went back for the empty packaging on a separate trip. The effect was predictable:

• the forklifts drove varying routes "whenever someone phoned", rather than following the rhythm of production,
• collisions and stoppages occurred at narrow crossings, because traffic was highly variable,
• a significant share of the trips were empty — the forklift carried one load carrier in one direction and came back running idle,
• buffers at the lines grew "just in case", because the team did not trust that material would arrive on time.

This is the classic picture of the first level of logistics maturity: work based on reacting to shortages, without measured times and without a standard. As long as deliveries work on call, there is not yet a process that could be automated — there is a series of reactions to shortages.

The AS-IS audit: facts first, then decisions

We ran the work within the DMAIC framework (Define–Measure–Analyze–Improve–Control), i.e. from measurements and facts to a standard. In the definition phase we set a clear goal: to come down from the high buffer at the lines to a level that allows regular deliveries at a constant takt. The rest of the audit consisted of collecting data on the shop floor, not at a desk.

Gemba Walk and the spaghetti diagram

We walked the routes physically, with the layout and data in hand — because a CAD drawing almost always lies until you check the real width of the aisles with pallets, buffers and people. On printouts of the layout we marked the flows in colours (green — external deliveries, orange — internal flows, blue — finished goods, purple — semi-finished products) as well as the traffic conflict points: places where pedestrians, forklifts and material flow cross. This produced a spaghetti diagram showing the chaos of the routes in black and white.

Pareto and the PFEP database

We did not map "everything". Using Pareto analysis, we selected the TOP flows that account for most of the traffic, and for them we built a PFEP database (Plan For Every Part). This is a single table in which, for each material, we record: the type and dimensions of the packaging, the number of pieces in the load carrier, the weight of the full packaging, the pick-up location and the delivery point, and consumption per shift or per hour. Without PFEP it is impossible to calculate trailer capacity, loop frequency or operator workload.

Buffers converted into hours

The strongest argument turned out to be converting the stock at the lines into time. We calculate buffer coverage in hours simply: the number of packages multiplied by the pieces per load carrier, divided by consumption. Suddenly the "big stock just in case" turned into a specific number of hours during which cash sits in material and blocks the space needed for safe routes. This is a number, not an opinion — and it convinces the production team faster than any presentation.

The solution: loop, takt and stop points

Based on the AS-IS, we designed a single pilot milk run loop — not the whole plant at once. A milk run is a fixed delivery loop run by a tugger train along a fixed route, to the same points, at a fixed interval. The key design decisions followed directly from the data, not from a catalogue.

Logistics takt. For each critical part number we calculated how many minutes apart the line needs a new container (packaging capacity divided by consumption). We set the loop interval as a divisor of an hour — 15, 20, 30 or 60 minutes — because a loop "every 23 minutes" is mathematically correct but operationally difficult to sustain.

Loop cycle time. We added up loading in the supermarket, travel, station handling and a safety buffer, and compared the result with the takt. The rule is absolute: if the cycle time is longer than the logistics takt, the system is inefficient and the route has to be shortened or the loop split. There is no room here for "the operator will try harder".

The supermarket as the starting point. We organised the loop's starting zone: full load carriers ready before departure, arranged in the order of the stops, with a designated place for empties and a clear logic for their return. If there is a mess here, the train is late before it even sets off.

A Water Spider on the last metre. The train delivers material to the zone, and the "last metre" role — delivery to the specific workstation — was taken over by a Water Spider (Mizusumashi) working to a written standard: the service sequence, the round time and the logic for empties. This is not a helper but a role for experienced operators; without a standard it turns into a firefighter putting out fires.

The physical side of the implementation — the tractor, frames and trolleys matched to the exchange process at the station — was handled by a selection based on measurements of the load carrier, the exchange time and the station geometry. In this area we design and build trailers and platforms as part of the CS system, and the transport platforms themselves come from the range of CS system trolleys.

Results: one train instead of a fleet of forklifts

The most important effect is also the simplest to remember: a well-calculated milk run made it possible to replace three to four forklifts with a single tugger train. This is not a marketing promise but a consequence of loop mathematics — one round serves many stations and many part numbers at once, instead of carrying out single "one forklift, one trip" runs. The other changes were qualitative, but just as noticeable on the shop floor:

• Traffic became predictable. The train runs along a fixed route at low speed and to a fixed schedule, so the variability of traffic — the source of collisions at crossings — fell drastically.
• Empties return in the same round. Separate transport of empty packaging disappeared; load carriers return to the supermarket as part of the same loop, according to the "one in, one out" principle.
• Buffers at the lines shrank to the calculated level. The team stopped building stock "just in case", because departures have fixed time slots and punctuality is audited.
• Space was recovered. Reducing the buffers freed up space at the lines that had previously been blocked by stock acting as a warehouse.

Conclusions: how to plan a milk run implementation

This implementation confirmed several rules that recur in every facility:

1. You must not skip maturity levels. The path leads from order and standards, through a manual milk run, to a tugger train — and only then to AGVs. An AGV does not fix an unstable loop; it magnifies its problems.
2. Without PFEP we cannot calculate the loop; without Gemba we do not know the real times. The data must come from the shop floor, not from assumptions. A photo of the packaging with its label can save hours of questions.
3. The supermarket determines punctuality. Most train delays originate at the start of the loop, not along the route.
4. Start with one loop. A pilot in one area produces a stable standard that is then replicated across the rest of the plant — instead of automating chaos across the whole plant at once.

If material in your facility still travels "on call", the first step is not choosing a vehicle, but walking the route with the layout and PFEP in hand and converting the buffers into hours. The rest — takt, stop points, choice of frames and trolleys — follows from the data.

How long does such an audit take?

The core of the audit — agreeing the scope, measurements on the shop floor (Gemba Walk), maps of the TOP flows, converting buffers into hours and building a PFEP database for the key part numbers — fits into a single workshop day. The outcome is a map of the current state, a list of data gaps and a preliminary concept for the pilot loop.

Does a milk run always lead to AGVs?

No. The outcome of the process is not always automation. Sometimes the right decision is a manual milk run or a tugger train driven by an operator, and the conversation about AGVs is only taken up once the manual loop has been running stably and predictably for several weeks.