The Process Everyone Bypasses

It helps to be precise about what is being described, because the word process gets used loosely. A process is not a document. A process is a decision that has already been made, in advance, by somebody who was not there at the time, so that the people who are there do not have to make it. The document is only the residue of the decision. When the document stops matching what happens, what has lapsed is the decision, not the paperwork.

That framing matters for a practical reason. The usual response to a process nobody follows is to remind people about it, to add a signature, or to escalate it to the owner. All three treat the gap as disobedience. But if the gap exists because the written step is more expensive than the thing it prevents, then every one of those responses adds cost to a decision that has already been made, and the gap will simply move somewhere less visible.

The visible symptom is usually mild. Deliveries arrive. Invoices go out. Customers complain occasionally and are handled. Nothing is on fire, which is exactly why the divergence can run for years. The process is not a bottleneck; it is a piece of paper that has stopped describing reality while continuing to appear in every audit answer.

Every bypass has a mechanism, and the mechanisms are few enough to name. A process is designed at a comfortable time of day and executed at an uncomfortable one. It is designed for a complete set of facts and executed in the middle of a gap in the facts. It is designed around a person with authority and executed by whoever happens to be there. And it is designed once, written down, and never revised, while the work it describes changes underneath it.

The first mechanism is the common one. A check that costs two minutes at a desk becomes a five-minute negotiation at a gate at six in the evening, and the person at the gate is being measured on throughput. Nobody writes down the decision to skip it. It is simply not made, because making it would cost more than the thing it protects is worth on that particular evening. A rational person does not perform a ceremony for a risk that has not materialised yet.

The second mechanism is that a paper process can only record what its fields anticipated. The interesting variation, the one that actually distinguishes this dispatch from that one, does not fit in the box. So it goes in the margin, or on a separate note, or in the head of the person who noticed. Over a year the margin becomes the real record and the form becomes the summary, and then somebody asks to see the form.

The example is constructed, but the shape of it is extremely common. Six records exist. Six of them look like evidence of a control. Four of them actually are. The gap between those two numbers is the whole distance between having a process and having a control, and no report on any dashboard will ever show it, because every row in the report is technically complete.

It is worth being clear about why the record is not obviously broken. Nothing is missing from the system. A dispatch happened, an invoice went out, a document was signed. The system faithfully stored what it was given. The failure is upstream of storage: the process asked for a signature in a field, and a signature in a field is not a person.

The useful question is not why people are not following the process. It is what would have to be true about a process for the fastest, laziest, most tired person on shift to follow it, and then whether that version still does the job the process exists to do. Most written processes fail the first test, which is why the second test is usually never reached.

A process that is actually followed tends to have four properties, and none of them are about the length of the document. It happens where the work happens, at the moment the work happens, without requiring a person to leave their post. It asks for the smallest piece of information that makes the decision later possible. It produces a record that is specific to one event rather than a signature that could belong to any of fifty. And it has a named fallback for the case when it cannot be performed, so that skipping it is a recorded decision instead of a silent one.

This is the reframe that makes the problem tractable. When an owner asks why a process is not being followed, the useful reframe is: the process has been making a claim about reality for some time, and the records do not support the claim. That moves the conversation from enforcement to evidence, which is a much easier conversation to have and produces a decision rather than a warning.

The distinction also decides what to do about it. If the gap is obedience, the answer is a reminder. If the gap is evidence, the answer is one of three things: fix the process so the fast version is the correct version, store enough of the process that the fast version is still attributable, or accept the practice and stop describing it as the process. That third option is underrated. A business that decides a check is not worth its cost can delete it honestly, and the resulting record is worth more than a control that is asserted and never evidenced.

It would be dishonest to imply that software closes this gap by itself, so here is the boundary plainly. What a system can do is store the event, the time, the named person, and the values that were checked, in a place that a later reader can look at. What it cannot do is make a person perform a step they have decided is not worth performing, and no product in the world can. If a check is genuinely not worth its cost, the correct outcome is a smaller process that is actually followed, not a larger one that is quietly bypassed.

The limits on the platform side matter too. A scope change is a NEW quote raised on the same project, not an amendment to a stored scope record: there is no change-request record, no milestone record, no deliverable record, no contract editor and no e-signature, so a process that depends on capturing an agreed change in the moment has to be built around raising a quote, not around editing a record. There is no timesheet record and no payroll module, so a process that depends on capturing effort per person has nowhere to put it. Expenses live in Nox-Billings only, and purchasing and stock movement live in Commerce, so a process that spans spending has to cross two products. Nothing here files GST returns or any other statutory return, so a process whose output is a filing is not a process this platform completes.

Two more limits are worth stating in an article about adoption, because adoption is precisely the context in which people assume self-serve. Duplicate detection flags candidates and a person reviews them; nothing merges automatically, and match rules and merge behaviour are a setup decision. And shift close and day-end reconciliation are assisted-setup maturity rather than switches you flip yourself. A business that expects to turn on a

There is also no onboarding team, no implementation project, no change-management programme, no training course and no data-cleaning service, and no dedicated support tier beyond the documented platform support. Migration is scoped work. Getting a business to actually use a system is work that somebody has to do, and no product removes that work, only changes its shape. The first week of using a new system is where most of that work happens, and there is a separate piece on what that week actually looks like: What to Do in the First Week with a New System.

There is a way to retire a bypassed process that does not involve a notice period. Start from a record rather than from the wall. Pick one event the process claims to cover, list what the system actually holds about it, and write down the difference. In the dispatch example that difference is two lines long: no named checker, no record of the substitution. You now have a specific, small, arguable claim about your own business, and a specific record to change.

Then decide which of the three outcomes you want, and write that decision down where the next person will read it. Either the check is worth its cost, in which case it gets a named fallback and a name field and a defined exception, or it is not worth its cost, in which case it is deleted from the written process and the risk it carried is recorded as accepted. The second outcome is not a failure. An honest, smaller process with real evidence is worth more than a documented one that four people have quietly rewritten.

The habit that follows from all of this is small and unglamorous: write processes the way you would write records, in terms of what a later reader can check, and revise them when the work changes rather than when somebody remembers. A process that names a person, a time and a thing is a control. A process that names a step is a description. Owners confuse the two constantly, and the gap between them is where the quiet divergence lives.

For the reporting side of the same problem, where a process becomes a number that nobody can take apart, the underlying argument is in The Number Nobody Can Trace Back. For the approvals case, where a step exists that nobody knew they needed, see The Approval Nobody Knew They Needed.