Run
Operating Procedures That Run Themselves
A written procedure that a machine executes, a second machine checks, and that raises its hand by name the moment it cannot do the job.
The buyer problem
Your company already has procedures. They are in a wiki nobody has opened since the person who wrote it left, in a checklist taped inside a cupboard, in a training deck that describes a system you have since replaced, and in the head of the one person everybody messages when something breaks.
None of that is anyone's fault. Writing a procedure down is work with no reward on the day you do it. The reward arrives months later, to somebody else, and only if the document is still true by then. So the writing gets deferred, and what is written is not maintained, and within a year the document and the work have quietly separated.
The separation is the expensive part. A new hire is trained on the document and corrected by a colleague, which teaches them that the document is not the authority. An audit asks for the procedure and gets a file written eighteen months ago. Two teams doing the same job do it differently and nobody notices until a customer does.
Then somebody leaves. It does not have to be dramatic. A director moves on and it turns out four processes named them as the owner, one of which nobody has run since. A procedure owned by a person rather than by a job is a liability the day it is written.
Automation on top of that is worse, not better. A workflow tool automates the documented path, the documentation is stale, and the exceptions land in a queue that nobody owns. The queue is discovered when it is large. Speed applied to an unowned process is how a small error becomes a big one quietly.
The underlying problem is not that people will not write things down. It is that writing, running, checking and maintaining a procedure are four different jobs, and a company only ever staffs the running.
Conditions for fit
This is for you if
- Work repeats. If the same job is done more than once, by more than one person, or by a person and a system, it is in scope.
- Somebody can name who should own each process, even if that person is currently the only person who knows it.
- Your systems can be read programmatically. A procedure that can only be executed by a human clicking through a screen can still be documented and checked, but it cannot be run for you until there is an interface.
- You can live with a staged rollout. The first runs of anything new are watched by a person on purpose, and that is not a phase to skip.
- You want the exceptions handled rather than hidden. The awkward cases are the work; a system that only handles the clean ones moves the cost rather than removing it.
This is not for you if
- You want a documentation project. A folder of beautiful procedures that nothing executes will rot on the same schedule as the one you already have.
- The process is still being argued about. Write it down after the argument, not during it, or you will automate the losing side.
- Nobody will own the output. A procedure with no accountable role is a procedure that degrades with nothing to catch it, and adding a machine to that only makes it degrade faster.
- What you actually need is one rule in one form field. That answer takes one call and costs you nothing.
We decline work that cannot clear its own benefit hurdle. If the arithmetic on your workflow does not show a return worth the fee, the answer is no, and you get that answer before you spend anything.
The questions we ask first
The diagnostic opens on these, in this order, before anything is proposed. If the answers do not exist, that is itself the finding.
- Which processes here happen more than once, and which of those has nobody written down?
- For each one, which job owns it -- not which person, which job?
- What happens today when the person who normally does it is away?
- How would you know, this week, if one of these processes silently stopped working?
- What is the proof that a run of this process actually succeeded, and can a machine see that proof?
- Which steps must never happen without a person saying yes, and who is that person by role?
- Where do two of your systems disagree, and who reconciles them today?
- When a procedure changes, how does the person doing the work find out?
- What did the last thing that went wrong here cost, and was the procedure at fault or its absence?
- If we wrote every one of these down and nothing else changed, what would still break?
Deliverables
A catalogue of the work you actually repeat
Built by reading your own systems rather than by asking people to remember: your project tool, your code, your message history, your mailboxes, your meeting recordings, your operational databases. What comes back is a list of the processes that exist, including the ones nobody has written down.
One procedure per process, in one shape
A header that names the owning role, the type, the version and the date it was last checked; the trigger; the inputs and the one place each comes from; numbered steps, one action each, in plain words; the proof each step worked; what to do when a step fails; and the checks that watch the whole thing. Nothing ships without all of it.
The same file, executable
The procedure a person reads and the procedure a machine runs are one artefact, not two. This is the only arrangement in which the documentation cannot drift from the work, because there is nothing for it to drift from.
Checks on every step, and watchers over the whole
A step check is proof you can see, produced every time the step runs. A watcher runs on a clock and compares two numbers that should agree: what went in against what came out, this result against what is normal for this process, the work spread across people and machines, and what was actually done against what the procedure says.
A second, independent check on every run
A different evaluation reads the evidence a run produced and passes or fails it before the work counts as done. Deliberately not the same pass that produced the work, for the same reason nobody marks their own homework.
Ownership that survives people leaving
Every procedure is owned by a role. The roles are resolved against your HR system on a schedule, so a job changing hands moves the ownership with it, and a job standing empty raises a flag instead of quietly becoming nobody's problem.
A monthly review that takes minutes
The owner gets a prepared brief: what ran, what failed, what a person overrode, what drifted, and what change is being proposed. Reviewing is confirming or correcting, not re-reading.
An alarm per procedure, on your monitoring, not ours
Each one carries its own signal, tested before it goes live by being deliberately failed and recovered. A red signal names the reason. A procedure that cannot be monitored does not go live.
A complete record of every run
What started it, every step, what each step produced, the independent verdict, what it cost and how long it took. Kept, not rotated away, so the question "what did we actually do on the twelfth" has an answer a year later.
Escalation that cannot park
Anything waiting on a person has a clock. When the clock runs out it moves up, and at the top of the ladder it resolves rather than waiting forever. A queue that depends on one person noticing is not a control.
Implementation steps
- Find the work before writing anything
We read your systems and produce the catalogue of repeated work. This is done first because a procedure programme scoped from a workshop covers only what people remembered in the room.
- Agree the standard, once
One document defines what every procedure must contain, who owns them, how they are approved, how often they are reviewed and what happens when one fails. Everything after this follows it, and a procedure that does not is refused rather than filed.
- Assign owning roles, and name the empty ones out loud
Every process gets a job that owns it. Where no job owns it, that is a finding rather than a blank, and it goes to a named decision-maker instead of being filled in by us.
- Write the first procedures with the people who do the work
A recording, a call, a handful of notes or an existing document is enough to start. The draft comes back with questions attached where it is missing something, and the person who does the job answers them.
- Prove each one against history before it runs anything
Replay the procedure over cases that already happened, including the ones that went wrong, and compare what it would have done with what was done.
- Run it watched, then run it alone
The first runs of anything new are checked by a person regardless of outcome. Only after that does it run unattended, and only with its checks and its alarm already live.
- Leave the catalogue running
The search for undocumented work does not stop at go-live. Work that repeats is found continuously, because new processes appear faster than anyone schedules a review to notice them.
Example measures
Examples of what gets instrumented. Each row is a definition: what gets counted, the unit and the period it is counted over, and the system that holds the authoritative figure. A number without those three is not a measure. The figures come from your baseline, measured on your data.
| Measure | Unit and period | Authoritative source |
|---|---|---|
| Repeated processes with a written, owned procedure | percent of those found | The catalogue, recounted on a schedule |
| Runs completed with no person touching them | percent of runs | The run record |
| Owner reviews completed in the month they were due | percent | The review record |
| Procedures whose owning role resolves to a person currently employed | percent | The role mirror against your HR system |
| Time from a run failing to a named person being told | minutes | The run record and the escalation log |
| Runs where a person overrode the outcome | count and rate | The run record; a rising rate is the signal that a procedure has drifted from reality |
Dependencies
What has to be true on your side. If one of these is missing, the engagement stalls and we will say so before it starts.
- Read access to the systems that hold the work. Read-only is enough to build the catalogue and most of the checks.
- An HR record we can resolve roles against. Ownership by role is the whole mechanism; without a source of who holds which job it degrades back into names in a document.
- A person who can approve a procedure into use, and who will still be there in six months.
- Somewhere the alarms can land that people already watch. We will use your monitoring rather than adding a second place to look.
- For anything that writes rather than reads: a decision, in writing, about which actions require a person to say yes first.
Limitations
What this work does not do. On the page, not in a footnote.
- This does not make a bad process good. A procedure that is wrong will be executed faithfully and quickly, which is worse than executing it slowly. That is precisely why every one carries its own checks and why a person still approves it before it runs.
- A machine cannot do a step that has no interface. Where the only way to do something is a person on a screen, the procedure documents it, checks that it happened, and tells someone when it did not -- but a person still does it.
- The catalogue finds work that leaves a trace in a system we can read. Work that happens entirely in conversation, on paper, or in a tool we cannot reach will not appear, and we will say so rather than implying the list is complete.
- Ownership by role is only as good as the HR record behind it. If job titles there are out of date, the mirror reports the conflict rather than resolving it, and somebody has to fix the record.
- The first month is heavier than the ones after it. Writing down work that was never written down surfaces disagreements about how it should be done, and those are decisions for your people, not for us.
The engagement path
- Sequenced after a baseline. Procedures are written against how the work actually runs, which means measuring it first. The Operating Diagnostic is the front door.
- Scoped by workflow family rather than by department, because a process that crosses three teams is one process.
- Delivered in stages: the catalogue, then the standard, then the first procedures running watched, then unattended.
- Managed afterwards if you want it managed. The alternative is a handover: the standard, the catalogue, the tooling and the training, and your team runs it.
- Your data is yours and export is guaranteed. The procedures we write for you are yours to keep, in a format you can read without us.