Software engineering
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.
- 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.
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.
| 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” |