Nominal process vs real process

The nominal process is how work is officially described. The real process is how work actually happens when constraints, exceptions, urgency, local workarounds and informal decisions enter the flow. The gap between the two is one of the most important diagnostic signals in an SME.

In brief

Most companies do not lack processes. They lack a reliable distinction between the process they believe they operate and the process people actually follow to get work done.

The nominal process appears in procedures, manuals, software workflows, quality documents and management explanations. The real process appears in emails, exceptions, side spreadsheets, repeated clarifications, informal approvals, handoffs and the way people behave under pressure.

The gap is not automatically a problem. A real process always adapts. The problem appears when the company manages, measures or digitises the nominal version while the real work happens elsewhere.

Operational definition

A nominal process is the declared route: the sequence that should be followed according to documentation, management expectation or system design.

A real process is the enacted route: the sequence actually followed across people, tools and decisions.

The difference between them becomes visible in three places.

First, in exceptions: cases that do not fit the official route but appear regularly.

Second, in workarounds: local practices invented to make the flow work despite missing information, unclear ownership or weak tools.

Third, in hidden decision points: moments where people ask, wait, escalate or decide informally, even though the official process does not mention a decision.

In practice, the distinction is close to the safety and operations distinction between work-as-imagined and work-as-done. The first is what planners, managers or documents assume. The second is what people do to produce the result in real conditions.

Why it matters for SMEs

In small firms, the nominal process is often light or absent. Work moves through proximity and mutual adjustment. That is efficient until growth makes it fragile.

As the company scales, the real process becomes distributed across people’s habits. The founder may still describe the nominal route, while operators follow a different one because they know where the route fails. New hires learn the real process by shadowing rather than by reading. Software then captures only part of the flow.

This matters because improvement projects often start from the nominal version. The company maps what should happen, automates what should happen, assigns KPIs to what should happen, and then wonders why the intervention does not change what actually happens.

For due diligence, the gap matters because it reveals how transferable the operating model is. If the official process and the real process diverge widely, the buyer is not buying a stable system. They are buying local knowledge embedded in people.

Observable signals

The first signal is contradiction. Three people describe the same flow in different ways, and each description is plausible from their position.

The second signal is the unofficial file: a spreadsheet, notebook or chat thread used to track what the official system does not show.

The third signal is exception frequency. If “exceptions” occur every week, they are not exceptions. They are part of the real process.

The fourth signal is repeated re-entry of information. People duplicate data because the nominal system does not support the real handoff.

The fifth signal is a phrase: “officially we do it this way, but in practice...” Everything after that phrase is diagnostic data.

Common mistakes

The first mistake is treating the nominal process as truth because it is documented. A procedure can be well written and still not describe the work.

The second mistake is treating the real process as misconduct. Workarounds often exist because people are trying to deliver despite structural gaps. They should be studied before being prohibited.

The third mistake is automating the nominal process without first checking the real one. This creates digital rigidity around a route that people will continue to bypass.

The fourth mistake is asking people in a group meeting how the process works. In front of hierarchy, people often describe the official version. Real process evidence requires recent cases, separate interviews and operational traces.

Operational example

A company describes its order flow as simple: sales confirms the order, technical office validates feasibility, production releases the job.

A review of 15 recent orders shows a different route. Sales often confirms before technical validation because customers expect speed. Technical office then requests missing specifications. Production waits because the order appears confirmed but is not executable. Meanwhile, one senior planner keeps a private spreadsheet to know which orders are truly ready.

The nominal process says the handoff is clean. The real process shows early confirmation, missing input, rework and hidden coordination.

The intervention is not a new procedure. It is a release gate: an order is not production-ready until three fields are complete and one role is accountable for them. The planner’s spreadsheet is not blamed; it becomes evidence of what the official flow failed to show.

Diagnostic questions

If three roles describe the process separately, do their descriptions match?

Where does the real flow leave the documented route, and how often?

Which unofficial tools exist to make the process work?

Which decisions are being made informally because the nominal process does not contain them?

If the company implemented software tomorrow, which process would it encode: the declared one or the real one?

Practical implications

The practical sequence is simple: observe the real process before improving the nominal one.

Start from 10 to 20 recent cases. Reconstruct what happened. Compare it with the declared rule. Mark deviations that repeat. Treat recurring workarounds as information, not noise.

Then decide: should the nominal process be changed to match the real one, should the real process be corrected to follow the declared one, or is a new process needed because both are inadequate?

This distinction prevents premature standardisation. It also prevents the common mistake of blaming people for keeping work alive through informal practices the organisation silently depends on.

MARTRO reading

In MARTRO’s reading, the gap between nominal and real process is one of the first places where organisational truth becomes visible. The gap often reveals role ambiguity, poor handoff design, missing decision rights, weak data ownership and hidden dependency on specific people.

The goal is not to punish the gap. The goal is to make it visible enough to decide what should be formalised, what should be corrected and what should be stopped.

When to go deeper

Go deeper when procedures exist but nobody trusts them, when software workflows do not match actual work, when new hires learn mostly by shadowing, or when recurring exceptions are treated as isolated cases.

Natural next steps are process mapping, rework, RACI and role gap.

Frequently asked questions

Is the real process always better than the nominal process? No. The real process may be adaptive or dysfunctional. The point is to observe it before judging it.

Why do people follow workarounds? Usually because the declared route does not handle a real constraint: missing information, time pressure, unclear decision rights or a tool gap.

Should every workaround be formalised? No. Some should become the new standard; others should be eliminated because they hide risk. The distinction requires evidence.

Can software reveal the real process? Sometimes. Logs and timestamps help, but they only show what happens inside the system. Many real-process moves happen outside it.

Why is this important before ERP or CRM implementation? Because the system will encode a process. If the company encodes the nominal version while the real work differs, the implementation creates resistance, customisation and bypasses.