/Aristotl
Language
Back to use cases

Use case

Roll out a changed procedure to every site at once

A procedure is not changed on the day the document is approved. It is changed on the day the last picker on the last night shift at the smallest distribution centre does it the new way. Between those two dates sits everything that goes wrong: the PDF that landed in a mailbox nobody reads, the printout pinned next to a scanner with page four missing, the site that never heard about it because the person who normally forwards these things was on holiday.

Most operations teams have no reliable way to measure that gap. They know the revision date. They do not know the floor date.

Three changes that all look the same from the floor

The scanner software on the pick trucks is updated and the confirmation step moves from the end of the pick to the start. Six distribution centres, four shifts, a mix of permanent staff and agency workers.

A line procedure changes on a production site because a machine guard was replaced and the cleaning sequence now has an extra lockout step. Three plants run the same line, one of them on a different layout.

A handover protocol between shifts changes: what must be written down, what must be shown physically, who signs off. It touches every shift boundary in the company, which means it touches everyone.

Different departments own these three. From the worker's point of view they are the same event: something I do every day is now done differently, and nobody has told me clearly what changed or why.

The change itself is what the law points at

In Belgium this is not a matter of internal preference. Codex art. I.2-21 requires the employer to ensure that every worker receives sufficient and appropriate training in relation to their wellbeing at work, directed at their workpost or function. The article names the moments this is owed: on entry into service, on a change of function, and on the introduction of new work equipment or new technology. It adds that the training is repeated and adapted to evolving risks, that it happens during working hours, and that its cost is not borne by the worker.

Read that against the three examples above. A new scanner configuration is new technology. A replaced guard with a new lockout sequence is new work equipment. The obligation to instruct is not triggered by a calendar, it is triggered by the change. In the Netherlands the same pressure comes from Arbowet art. 8 lid 2, which requires instruction that is effective and adapted to the worker's distinct tasks. A generic annual session does not adapt to a task that changed last Tuesday.

VCA adds a practical route for certified companies: question 4.1 explicitly names changes in rules and procedures as a subject for toolboxmeetings. Useful, but a toolbox reaches the people in the room on the day it runs. A three shift operation across six sites is not one room.

Why the delay usually starts before the rollout

Ask an operations team why a change took five weeks to reach the floor and the answer is rarely "we forgot". It is that turning the revision into something trainable is slow. Someone has to read the new SOP, work out what actually differs from the old one, write a script, build slides, get them reviewed, translate them for the sites where Dutch is not the working language, and then find a moment in the schedule.

That work is real, and it is the bottleneck. It is also why the second and third changes of the quarter tend to go out as an email instead, which is how sites end up running different versions of the same procedure without anyone deciding that they should.

Aristotl takes the revised document you already maintain, in the format you already keep it in, and builds the course from it. The role of the person who owns the procedure shifts from author to reviewer: check that the module says what the SOP means, correct the wording on the steps that carry risk, approve, assign. When the procedure changes again, the source document changes and the module is regenerated. There is no re-recording and no rebuilding of a deck.

A module about what changed, not about the whole procedure

A rollout module is not a course on picking. The people receiving it already know how to pick. It is three to five minutes on a phone covering what is different, why it is different, and what the new sequence is, with knowledge checks tied to the change itself rather than to the general topic. Scenario questions ask what the worker would do at the point where the old habit and the new rule now conflict, which is the only place the change can fail.

That length is deliberate. It fits between a break and a shift start, which means it can be done on the floor rather than scheduled into an hour nobody has. It runs in the browser on the worker's own phone, without an app installation and without a laptop. Each worker gets it in their own language, automatically, which on a site running four languages is the difference between reading it and nodding at it.

The view HQ needs is not one number

A single completion percentage across the company is close to useless for deciding what to do next. What the operations director needs is the same record sliced: by site, so the regional conversation has an answer; by role, so you can see that the pickers are through but the reach truck drivers are not; and by version, so you can see who confirmed the current procedure and who is still on the previous one.

Every completion is registered with the person, the site, the role, the date and the version of the source document. That last field is what turns a training record into evidence. Six months later, when someone asks when the new handover protocol landed at plant two, the answer is a timestamped list per worker rather than a search through sent mail.

Site managers see the same view scoped to their own sites, so they can chase their own outstanding names without HQ acting as a switchboard.

Bring one procedure you changed in the last quarter to a demo, ideally one that did not land cleanly, and we will build the module your floor would have received and show you the record you would be holding now.

Bring one procedure to a demo