The gap opens where the recommendation meets the shift floor
A food and beverage manufacturer can receive an excellent recommendation and still end up with a system the night shift will not use. The recommendation was built from documentation, a data extract and two sessions in a comfortable room. The plant it was written for takes orders only until ten in the morning, runs three shifts, and has a filling line that stops whenever the night supervisor cannot find a previous batch record on the terminal. Nothing in it is wrong. It describes a business that does not exist, and the operating manager who owns the outcome discovers that first.
The consulting fee is spent either way. What follows is the real expense: a system configured around an assumed process, a production team trained twice, and a period where the old and the new process run in parallel while the plant absorbs the difference in throughput and rework.
Remote advice is accurate about the process that can be described
Work done away from the business produces a description of the formal process, and the formal process is what the organisation agreed to put in writing. That description is not false, but it is incomplete in a specific way: the undocumented parts of the work are exactly the parts that hold the operation together, and the people best placed to describe them are rarely the people asked. A supervisor answers with the process they were trained on, a manager with the written one, a finance partner with the measurable one. None describes Tuesday.
Four constraints that exist only in the operating environment
- Timing constraints. Real work has windows. An order accepted after the cut-off may be valid and still worthless, and only the people on site know where the cut-off is and what happens to the work that misses it.
- Workarounds with a history. A workaround that looks like negligence from outside is usually a decision made once for a good reason nobody wrote down. An automated process that removes it also removes the reason it existed.
- Physical and material state. Product condition, machine behaviour, load and handling constraints inform decisions in ways a record of transactions never captures, and a system that ignores them will be correct and unusable.
- Authority and coverage. Decisions made on the night shift are often made by people the organisation has not formally authorised, and a control model designed for a nine-to-five approval chain has no answer for them.
A forward-deployed team is built to correct itself
The remedy is not more analysis at a distance. It is a team whose working method is designed to be corrected by contact with the work.
- Sit inside the process before writing anything. Watch the work being done for a full shift cycle, in the place where it happens, with the people doing it. The purpose is not to gather requirements; it is to be wrong in a way that is cheap to correct.
- Work from a single process and a single owner, not a domain. Depth in a narrow area is what makes the recommendation credible to the people who have to live with it.
- Keep the business owner inside the daily work, not at the monthly review. Decisions about what the system should do are made weekly, and the person carrying the operational consequence should be in the room when they are made.
- Record every difference between the documented and the observed process, with the reason. This log is the most valuable artefact of the early engagement, because it is the only place where the organisation's real operating rules appear in writing.
- Deliver something small and real within the first weeks. A working increment in front of the people who will use it produces corrections that no workshop ever will.
Saying the recommendation is wrong is part of the deliverable
A forward-deployed engagement should be able to conclude that a commissioned direction should not be pursued, and that some work it is asked to automate should not be automated at all. Not every repetitive activity suits a model: a fixed rule applied to a structured record is better served by ordinary software, and a judgement made from context no system holds should stay with a person. The alternative — defending a recommendation the evidence has undermined — produces a system the business works around. The related argument, that automation reproduces the judgement the process already contains, is in better business processes rather than more agents.
How to judge whether a team is genuinely inside the business
An executive can assess an engagement without a technical background, and a chief operating officer has reason to: the difference shows up in throughput and rework, not in a status report. The signs are behavioural, and visible in a week.
| Signal | Team is inside the business | Team is observing the business |
|---|---|---|
| Language | Uses local terms and argues about them. | Uses the documented process names. |
| Evidence | Cites observed shifts and specific records. | Cites documents and workshop notes. |
| Corrections | Records and applies them to the design. | Defends the original framing. |
| Schedule | Follows the site's rhythm, including the worst hours. | Works office hours and visits on request. |
The measure that follows is not a percentage but a sequence of questions asked at a review. How many assumptions in the original brief were withdrawn, and by whom. How many decisions were moved from an automated path to a named human because the floor insisted on it. How long the current process ran without an intervention. These figures are the honest evidence of what the engagement produced, and the method for gathering them is in the first thirty days of a forward-deployed engagement. The wider argument about sequencing engagement inside the operating environment is in our organisational transformation practice.