Procedures nobody read, because they sat in a binder

Every company that passes a quality or safety audit has a full set of procedures. The question is whether anyone outside the quality department knows about them.

What it looked like before

The usual arrangement: work instructions in a binder, the current version on a shared drive, the previous version printed and pinned up on the shop floor, and the knowledge of which is which inside one person’s head. Training logged in a separate spreadsheet. Near misses reported verbally and written down when someone remembers.

At audit time all of it has to be assembled within a fortnight. Worse, between audits nobody uses it, so the procedures describe how the work was done three years ago while the floor works differently today.

Inosa, a Norwegian consultancy, sells the tool that ties this together. We have been building it with them since 2017.

What we built

Documents with versions. An instruction has one binding version, visible to everyone, with a change history. “Is this the current one” stops being a question.

Competence management. Who is trained, on what, and until when. When a procedure changes, it is clear who needs retraining.

Incident reporting. An accident, near miss or non-conformance is reported from a phone, on the spot, at the moment it happens. It reaches the responsible person immediately.

Model processing and visualisation. Technical documentation is presented in a form that works on a screen, not only on an A3 printout.

What changes day to day

The point of this system is not that documents live in the cloud. It is that procedures, training and incidents are linked to each other.

When someone reports that the same thing happens twice a month at one machine, it is immediately clear which procedure covers it and who was trained on it. Changing the procedure produces the list of people to retrain. Without that link each of those things lives in its own spreadsheet and nobody puts them side by side outside audit season.

The second effect is simpler. A report that takes a minute from a phone actually gets filed. A report that requires a form on an office computer almost never does.

Why we built it this way

The system has been in development since 2017, and that is the key fact here. Regulations, customer requirements and Inosa’s own way of working all changed over that period. An application meant to survive that horizon has to be changeable in pieces – hence the split into modules and a mobile version built from the same codebase as the web one.

Multi-year development is also a different kind of engagement than a six-month project. A team that remembers why a decision was made does not rebuild the same thing every year over a question that was already settled.