PFEP — Plan For Every Part. The foundation of an internal logistics audit

Before the first Milk Run train or autonomous transport robot appears in the facility, a single table has to be created that describes every part number: what it is, what packaging it travels in, how much is consumed per shift and where it moves from and to. This table is the PFEP — plan for every part. Without it, an internal logistics audit is based on impressions rather than numbers — and that is precisely why PFEP is the foundation from which we start every reorganisation of material flows.

PFEP, plan for every part — what it is and what data it contains

PFEP is a structured database of the materials handled in the facility. One row describes one part number, and the columns answer the questions that determine how deliveries should be designed. In practice we divide them into five blocks:

• Identification — part number, name and a photo of the packaging. A photograph with the label visible saves hours of asking around on the shop floor.
• Packaging — packaging type, dimensions (length, width, height in mm), the number of pieces per package and the weight of the full package in kg.
• Flow — the material pick-up location, the delivery location at the line (Point of Use) and the means of transport (forklift, manual transport, Milk Run train).
• Consumption — how many pieces are consumed per shift or per hour, and the length of the shift.
• Analytics — the calculated coverage in hours, i.e. how long the stock at the line lasts.

This data is not an add-on to the project — it is the project. Only with the packaging dimensions and weights can you calculate trailer capacity and turning radii. Only by knowing consumption can you set the loop frequency. Only by seeing the pick-up and delivery locations can you draw the route.

Gemba Walk — we collect data on the shop floor, not from behind a desk

PFEP is filled in through two channels. Some of the data comes from systems (layout, list of part numbers, production plan), but the critical part is only produced during the Gemba Walk — literally "go and see". This is a walk around the facility during which we measure aisles, observe the real transport routes, check the condition of the packaging and identify traffic conflict points.

Why is this so important? Because the ERP tells you how much there should be, not how much is actually standing at the line. A buffer set aside "just in case" does not exist in any system. Nor will you see in a table the empty packaging that is blocking an aisle. A PFEP built solely on system data is convenient, but it describes a facility that does not exist.

Pareto analysis — we do not map everything

A typical facility handles hundreds, sometimes thousands, of part numbers. Trying to describe each of them with the same level of detail leads nowhere. That is why the first step of the analysis is Pareto: we select the TOP 50–100 part numbers that generate most of the traffic, and build the core of the PFEP on them.

The same principle applies to flow maps. On the layout we draw the main flows, marking them in colours — inbound (deliveries from suppliers), internal, outbound (finished goods) and semi-finished products. A few main streams account for the lion's share of trips, and they are what determine where to design the stop points of the Milk Run loop.

Converting buffers into hours — a numerical argument

The strongest effect of a well-built PFEP is converting the stock at the line into time. Instead of saying "there is a lot of this material", we say "this buffer covers 14 hours of production". That changes the conversation, because it shows directly how much time and how much space is frozen in stock.

We calculate it simply, without sophisticated tools. When we know consumption per shift, coverage in hours is the product of the number of packages in the buffer, the pieces per package and the shift length, divided by consumption per shift. When we know consumption per hour, it is enough to multiply the number of packages by the pieces per package and divide by hourly consumption. The result immediately points to the zones where stock is acting as a warehouse and where there is not enough space for safe routes.

The AS-IS map — the starting point for every change

The data collected adds up to a map of the current state (AS-IS): how material flows today and how the replenishment signal is generated. Without this map, every improvement proposal is guesswork. With it, you can see in black and white where routes cross, where buffers occupy aisles and where the decision to "top up" material is taken by feel rather than according to a standard.

The whole piece of work follows the DMAIC framework — define, measure, analyse, improve, control. This is not theory for its own sake but an order of work: facts and measurements first, decisions only after that. PFEP and the AS-IS map are the "measure" and "analyse" stages; without them, the "improve" stage has nothing to rely on.

How PFEP prepares the facility for Milk Run and AGVs

Regular Milk Run deliveries and autonomous transport require predictability. A trailer with a defined capacity, a loop with a set frequency and stop points in fixed places — all of this can only be designed if the packaging, consumption and locations have been calculated beforehand. PFEP supplies exactly these inputs.

The same applies to autonomous vehicles. AGV and AMR robots need defined routes, repeatable packaging and unambiguous pick-up and drop-off points. A chaotic flow in which the operator decides everything on the fly cannot be automated. Organising the stock at the line and standardising packaging — for example on the basis of the CS system and line-feeding trolleys — is a prerequisite, not a side effect, of an AGV implementation. First we recover space by reducing buffers, then we put repeatable transport on it.

The most common mistakes when building a PFEP

Two mistakes recur most often, and both result from haste.

A desk-based audit. Building a PFEP solely from system exports, without going out onto the shop floor, produces a table that looks nice in Excel and is detached from reality. Packaging dimensions may be out of date, pick-up locations have changed, and nobody has recorded buffers set aside manually. The Gemba Walk is not a formality — it is a verification.

ERP data without checking. Consumption in the system is often a planned or averaged value rather than the actual one. The weight of a full package is sometimes entered as an approximation. If we base trailer capacity and loop frequency on these figures, the error will grow with every subsequent calculation. That is why we confirm the key fields — consumption, dimensions, weight — on site, even if only on a sample.

Checklist — where to start

• Prepare an up-to-date layout of the facility with docks, warehouse, buffers and lines.
• Select the TOP 50–100 part numbers using the Pareto method — this is the core of the first version of the PFEP.
• Collect the five blocks of data for them: identification, packaging, flow, consumption, analytics.
• Verify the key figures on the shop floor during the Gemba Walk, not just in the system.
• Convert the buffers into hours and identify the zones with the greatest potential for reduction.
• Assemble all of this into an AS-IS map, and only then design Milk Run loops and AGV routes on it.

FAQ

Does the PFEP have to be built for all part numbers at once?

No. We start with the TOP 50–100 items identified by the Pareto method, because they account for most of the traffic in the facility. We add the remaining part numbers gradually, once the core of the database is working and producing decisions.

How long does it take to build the core of the PFEP?

The core for the key part numbers, together with the AS-IS map, a spaghetti diagram of the main flows and the buffer conversion, can be built in a single workshop day on the shop floor, provided the layout and the list of part numbers are prepared in advance. These two inputs are exactly what is critical — we fill in the rest on site.