One route for every delivery date: mapping a purchasing process

This case is illustrative: the company is invented. The pattern is one I keep running into - processes rarely break inside a department; they break where work is handed over.

The problem

A manufacturer kept stopping production for missing material. Every time, the order had been placed - often weeks before. Purchasing blamed suppliers, planning blamed purchasing, the warehouse said nobody had asked. The ERP showed the delivery date from the day the order was sent.

Nobody was careless. Each department knew a part of the truth, and no part of it reached the place where the others could see it.

How I mapped it

• As-is first, in the people’s own words. One short session per department: what do you receive, from whom, what do you do with it, whom do you tell.
• One map, swimlanes per department, the supplier as a separate pool. A swimlane makes every handover a visible line crossing a boundary. A message to or from the supplier is a dashed line leaving the company.
• A joint review of the map with everyone who appears on it. That’s usually the session where people see the problem for the first time - it’s on the wall between two lanes, not in anyone’s lane.

Four break points, four rules

The fix is never “be more careful”. Each break point became a rule with an owner, a route and a status the system can check - and each rule became a requirement for the ERP.

The new process

The whole purchasing process fits on one overview page: three blocks (need, order, delivery), six phases, each with its own detailed map. The numbers show where each rule lives.

The key phase is the one that didn’t exist before: every piece of information about a delivery date - a confirmation, a change, or silence - takes the same route and ends on the order line, compared with the order.

What the map gave the ERP project

• Statuses become the specification. Each step changes the status of a document - order sent and awaiting confirmation, line confirmed, demand at risk. That list is what the ERP has to support, in the order the business needs it.
• Rules have codes. “R2 - date, quantity and price as ordered?” can be traced into the fit-gap analysis: standard function, configuration, or a gap to solve.
• Open points live on the map, not in e-mail. “Who escalates when the supplier ignores the second reminder?” sits next to the step it blocks, until someone with the authority answers it.
• Every page says what changed against the previous version. A process map is a working document. If it can’t show its own history, it gets replaced by a new one nobody trusts.

Why BPMN - and why it isn’t the point

BPMN is a tool, not the result. I use it because a handful of symbols is enough for anyone to read the map after five minutes, and because lanes and message flows show exactly what usually stays invisible: who hands what to whom. A map that isn’t tied to statuses, rules and open points is wallpaper. Tied to them, it’s the cheapest specification an ERP project gets.