Specify the operation before you specify the stack
Most failed operational software starts as a technology conversation. The ones that last start as a work-order conversation.
When a plant, a field organisation, or a quality office asks for software, the first instinct is still to name tools: a CMMS, a low-code platform, an agent, a new ERP module. That instinct is expensive. The stack is a consequence. The work is the specification.
What “specified to the operation” actually means
It means the unit of design is not a screen. It is a closed loop: who raises the demand, what evidence is required, who is allowed to change state, what happens when parts are missing, and how the record will be read in an audit six months later.
If you cannot walk a work order from request to history without leaving the system, you do not have a system. You have a form with a database.
The useful questions are operational, not architectural. What is late this week, and why. Who can start a job, and who can close a critical one. What counts as a record: the asset, the labour, the parts, the signature — not a forwarded email.
| Question | Poor answer | Useful answer |
|---|---|---|
| What is late? | “Everything” | “Corrective WOs waiting on seals, North Plant” |
| Who decides? | “The supervisor” | “Shift lead can start; reliability closes critical” |
| What is the record? | “We keep emails” | “Asset + labour + parts + signature” |
A practical sequence
Discovery is not a workshop to collect wishes. It is a structured reading of the current operation: shadow a shift, sample the last fifty exceptions, and write the state machine that already exists — even if it currently lives in WhatsApp and a shared spreadsheet.
- Name the asset, the crew, and the constraint before naming the framework.
- Draw permissions as part of the workflow, not as an afterthought in settings.
- Treat integrations as contracts: what event, what payload, what failure.
- Keep a human in the loop wherever a state change has safety or legal weight.
Only then does the stack become a decision. Sometimes the right answer is a product we already run. Sometimes it is a custom system. Either way, the software is a specification of the work — not a catalogue of modules waiting to be configured.
