From the thread to the guide: why the record of a breakdown should write the procedure

The procedure already exists. It is just in the wrong format.

Watch a breakdown get solved on a packing line. A technician reports it, with a photo. Another asks what changed. Somebody remembers a similar case in March. A technician checks the belt, then the relay, then the program. Twenty minutes later the machine runs, and the technician says, out loud or into a phone, what it was and what fixed it.

Everything a procedure needs is in that sequence: the symptom, the things that were ruled out and why, the cause, the action, and the check that confirmed it. What is missing is not information. What is missing is the act of writing it down in a shape the next person can follow — and that act is the one nobody has time for, because the next breakdown has already started.

Most plants respond to this with a process: after the fact, someone with the title and the calendar space is asked to convert the closed incident into a work instruction. It is a reasonable process. It is also why most plants have a handful of beautifully written procedures for the failures that happened three years ago, and nothing for the ones that happened last week.

The cost of the conversion is the whole problem

If turning a fix into a procedure costs an hour of a senior person’s time, it will be done for one fix in twenty. If it costs a two-day workshop with the plant’s best operator in a room, it will be done once a year, for the failures that were most painful rather than the ones most likely to recur. The knowledge base that results is real, and it is also a museum: it reflects what the organisation could afford to document, not what it knows.

This is why the phrase “every issue becomes knowledge” is worth treating with suspicion, whoever says it. It is true only if the conversion is nearly free. Otherwise it describes an aspiration and a backlog.

Make the thread the record, and the record the source

The change that matters is small to describe. First, the conversation in which the breakdown is solved happens on the machine’s own record, not in a chat group that belongs to nobody. Second, closing the incident means saying what it was — a cause, an action, a verification — and those fields are proposed from what was said in the thread, so confirming them takes a tap rather than a form. Third, the draft of the procedure is written from the closed thread by a model that has read it, with the photos and the manual page it cited, and is put in front of a person to approve.

Notice what this does to the cost. The technician does the work they were already doing: fixing the machine and saying what they found. The draft is free. The one deliberate act left is approval, and it is done by the person who should be doing it anyway — the maintenance lead who is responsible for what the plant treats as standard — in a few minutes, on a draft that already reads like a procedure.

The plant does not need its technicians to write. It needs someone to stand behind what they found.

Where the guide lives decides how far it travels

A procedure filed under a line, an area or a site reaches the people who look there. A procedure attached to the model of machine reaches every unit of that model, on every line and in every site, including the one that will be installed next year. That is the difference between a document library and a memory: the memory knows which machines a lesson applies to.

It also gives approval a meaning it does not have in a folder. Approving a guide on the model says: this is true for every unit we run of this machine. Where a unit has been modified and the guide is only true there, it is pinned to that unit. Where the manual and the field disagree, the guide is the place the disagreement is written down, versioned, and superseded when it changes again.

What to measure

Two numbers say whether this is working. The first is the share of closed incidents that carry a structured cause and a verified resolution — if it is low, the record is thin and no draft will save it. The second is the number of later incidents that reused an earlier resolution: a guide that was read at the machine, a thread that was opened before anyone was phoned. The first number is about capture. The second is the only reason to capture anything.

What is not worth measuring is the size of the knowledge base. Two hundred procedures nobody opens are a cost. Twelve that get read at 03:00 are a memory.

Where Norlan is on this

The thread as the machine’s record, closure with a cause and the manual as a cited source are in the product. The closure proposed from the thread is being validated in pilots. The guide drafted from the closed thread, and the panel that shows the earlier fix when a similar incident opens, are product direction and are labelled as such on the guides page. We would rather you know which is which.