Processes and operations

Processes and operations connect the designed sequence of work with the real capacity, constraints and variability of execution. A process shows how work should move. Operations shows what the system can actually sustain.

In brief

A process can be well described and still perform poorly if operational constraints are ignored. The flow may be clear, but capacity may be insufficient, WIP may be too high, input may vary, or the bottleneck may sit in a decision point.

The link between process and operations is where many SME improvements succeed or fail.

Operational definition

A process defines the sequence from trigger to output. Operations defines the conditions under which that sequence runs: capacity, scheduling, workload, variation, buffers, tools, handoffs and constraints.

A process map without operational reading is incomplete. It shows the path but not the load the path can carry.

Why it matters for SMEs

SMEs often improve processes on paper while the operating system remains overloaded. The map says who does what, but the team has no capacity. The SOP says how to work, but exceptions consume the day. The ERP workflow exists, but WIP is uncontrolled.

Operations translates design into reality.

For growth, this distinction is essential. Scaling a process means knowing not only the steps, but the capacity and constraint of each step.

Observable signals

Look for clear processes that still miss dates.

Look for recurring overload at the same point.

Look for WIP growing even though the process is documented.

Look for buffers hidden in early starts or informal reserves.

Look for software workflows bypassed because the operating condition does not fit them.

Common mistakes

The first mistake is treating a mapped process as an operating system.

The second is ignoring capacity and variation.

The third is improving local activity without checking the bottleneck.

The fourth is standardising a routine before the operating condition is stable.

Operational example

A company maps its order process and clarifies responsibilities. The map is correct, but lead time remains unstable.

An operations reading shows why: too many orders are released at once, technical validation is the bottleneck and the planning buffer is hidden in early starts.

The next intervention is not another map. It is a WIP limit, protection of the constraint and a visible buffer.

Diagnostic questions

What is the flow?

What is the current throughput?

Where is the constraint?

How much WIP is open?

Where does variation enter?

Which buffer protects the commitment?

Is the process stable enough to standardise or digitise?

Practical implications

After mapping a process, add an operations layer: capacity, WIP, bottleneck, variation and buffer. Then choose the intervention.

Do not treat process design and operational capacity as separate conversations. The design must be executable under real conditions.

MARTRO reading

In MARTRO’s reading, processes and operations meet at the point where legibility becomes performance. The process shows structure; operations shows whether the structure can carry demand.

This is why MARTRO connects process mapping with WIP, bottlenecks, buffers and operational capacity.

Frequently asked questions

Is operations just execution? No. It is the system of capacity, constraints and variability through which execution happens.

Can a process be correct but operationally weak? Yes. The sequence may be clear while capacity, WIP or buffers are wrong.

What should follow process mapping? An operations reading: throughput, bottleneck, WIP, variation and buffer.

Why do SOPs fail operationally? Because the routine may be documented before the real operating condition is stable.

Why does this matter for scaling? Growth increases load. Without operational reading, the process may break at the first constraint.