Skip to content

EMI3News & insightInsight

Work deconstruction, not process abstraction

Most vendors digitise the description of the work. Taking the task apart at the machine produces something quite different, and it is why field adoption behaves the way it does.

Insight7 min read

The task as it exists at the machine, not as it reads on paper
The task as it exists at the machine, not as it reads on paper

There are two ways to build industrial software, and the choice is usually made without anyone noticing it was a choice.

The first is process abstraction. Take the SOP, the work order, the procedure manual (the description of the work) and digitise that. The result captures records about work without changing how work is performed. It is why so many rollouts fail to move reliability metrics: the system has visibility of the abstraction, not of the activity.

The second is work deconstruction. Take the task apart into its real, observable components at the machine. Zone. Sensory channel: what is seen, heard, smelled, felt. Role. Sequence. Physical access. Shift-time reality. Then rebuild the work as digital workflow with those components preserved.

Most industrial vendors model the process. EMI3 deconstructs the work.

Why it is hard to retrofit

The difference shows up in adoption. Software built from the description asks a technician to translate between what the screen says and what is physically in front of them. Software built from the work does not, because the sequence on the screen is the sequence at the machine.

This is the single hardest differentiator for a generic software team to acquire, because it does not come from user research. It comes from twenty years of standing on the deck of a haul truck and noticing which step gets skipped when the shift is running late.

Was this useful?

We read every response. It decides what we write next.