Process

A process is the repeatable path through which a request, order, issue or decision becomes a result. It exists even when nobody has written it down: it is simply how work actually moves through the company. The useful question for an SME is not whether it has processes. It does. The useful question is whether those processes are legible enough to be measured, delegated, improved and, in some cases, shown to an investor or buyer as evidence of transferability.

In brief

Every company has habitual paths: a customer request becomes a quote, an order becomes a delivery, a complaint becomes a correction. Those paths include activities, decisions, handoffs, waits and outputs. When they are visible, the company can intervene at a precise point. When they remain implicit, every problem is interpreted as a person problem: sales is slow, production is overloaded, administration is careless, the founder must check everything.

MARTRO uses process as a diagnostic surface. A process is not only something to optimise. It is where vague organisational problems become observable: unclear roles, missing inputs, decision delays, rework, excessive dependency on one person and premature digitisation.

Operational definition

A process can be identified by four elements.

First, there is a trigger: the event that starts the flow. It may be an order, a call, a deadline, a support ticket, a supplier delay or an internal request.

Second, there is a sequence of activities. These activities are not just tasks in the abstract; they are performed by recognisable roles, with information, tools and constraints.

Third, there are decision points. These are the moments where the flow can take different paths: approve or reject, escalate or continue, rework or release, prioritise now or postpone.

Fourth, there is an output. Someone receives and uses the result: a paying customer, another department, a manager, a supplier or an internal role. In process language this recipient is often called the customer of the process, even when the recipient is internal.

If one of these four elements is missing, the company is probably not describing a process but a generic activity. The difference matters. On a generic activity people can only say “work harder” or “be more careful”. On a process they can identify where the delay, error or ambiguity is produced.

“Sales is slow” is not yet a process statement. “Quotes wait an average of four days between commercial drafting and technical validation” is.

Why it matters for SMEs

Small firms coordinate through proximity. People talk, correct each other verbally and rely on memory. The founder sees most of what happens. This is not primitive; it is often the most efficient coordination mechanism at very small scale.

Growth breaks it quietly.

The first signal is not chaos. It is dependency. Every exception moves back to the founder. Every absence of a key person blocks a flow. Every new hire learns by shadowing because the knowledge is tacit rather than codified. What used to be flexible becomes fragile.

From the outside, this dependency is called key person risk. It affects valuation because a business that works only through a few specific people is harder to transfer, integrate or scale. A similar company with legible processes is less uncertain: its operating model can be verified, taught and improved.

Making a process legible is therefore not a bureaucratic exercise. It is a way to reduce dependence on memory, personality and proximity. For a company preparing for growth, acquisition or succession, it also turns a way of working into an asset that can be shown.

Observable signals

A process that is not legible leaves traces. These traces are usually more reliable than asking “how does the process work?”, because that question often produces the official version rather than the real one.

Look for duplicate entry: the same order entered in two systems by two people. This usually indicates a handoff that was never designed.

Look for urgent emails clustering at the same point in the flow. That point is a natural bottleneck candidate.

Look for quotes, files or orders going back and forth between two roles before being released. Each loop is rework: work repeated without adding value.

Look for the private spreadsheet kept by one person to know where cases actually are. That spreadsheet is rarely the problem. It is evidence that the official system does not answer the most basic flow question: where is this unit of work now?

Each signal can be measured with domestic means: count loops, measure waiting days, list exceptions for one month, compare the documented rule with recent cases. No large software system is needed to begin. The first tool is the decision to observe.

Common mistakes

The first mistake is mapping the desired process instead of the real one. The result is an elegant document that nobody recognises. The technical distinction is between the nominal process, which is how the process is declared, and the real process, which is how it happens. In SMEs the gap between the two is normal.

The second mistake is starting too wide. “Map the sales process” is usually too large. A better perimeter is “from customer request to quote sent” or “from confirmed order to release to production”. The narrower the flow, the more useful the map.

The third mistake is asking software to impose order that the organisation has not yet decided. A CRM or ERP can support a stable process. It cannot compensate for an unresolved sequence of responsibilities and decisions. Digitising an unstable flow often makes the disorder more expensive to change.

Operational example

A metalworking company with 30 employees and around 6 million euros in revenue complains about late deliveries. The founder assumes production is the problem. A reconstruction of 20 real orders shows something different.

Actual processing time is within the expected range. The delay appears between order confirmation and release to production. Bills of materials return incomplete twice on average, and each return creates waiting time. The problem is not the speed of work. It is lead time: the total elapsed time produced by work, queues and rework.

The intervention was not a new management system. It was a seven-point checklist before release, with one clearly accountable role. Average lead time fell by six days without investment.

The technical lesson is simple: cycle time is improved through efficiency; lead time is improved through structure. In SMEs the second is often the real constraint.

Diagnostic questions

Three questions reveal whether a process is legible.

If three people involved in the same flow describe the steps separately, do their descriptions match?

For a random unit of work, can the company say where it is, who owns it now and what it is waiting for?

When something goes wrong, does the discussion identify the step where the problem was produced, or does it immediately become a discussion about people?

If even one answer is negative, the process exists but is not yet governable. It can continue to work, but mostly through attention, memory and goodwill.

Practical implications

The order matters: make visible before optimising. Many improvement projects fail because they optimise a flow that nobody has observed clearly. The minimum practice is to choose one flow, follow 10 to 20 real cases, record steps, waits, loops and decisions, then select one intervention.

For the founder, the practical benefit is negotiation quality inside the company. Discussions move from “I think the problem is X” to “this is where it happens”. That shift is small but structural: it replaces opinion with shared evidence.

MARTRO reading

In MARTRO’s reading, a process is not an object to certify. It is a diagnostic surface: the point where different organisational conditions become visible without heavy interpretation. Role ambiguity, poor decision sequencing, unbalanced workload and hidden dependency all leave process traces.

This is why process mapping comes before work on RACI, KPIs, digital tools or governance. Not because of methodological orthodoxy, but because it is the cheapest way to replace narrative with evidence. It is also how a company begins to prepare itself for external evaluation: what is legible can be verified, and what can be verified is worth more.

When to go deeper

Go deeper when the same friction returns every week despite reminders and meetings. At that point the issue is probably not attention; it is flow architecture. Natural next steps are process mapping, nominal process vs real process, and bottleneck analysis.

Frequently asked questions

What is the difference between a process and a procedure? A process is the real flow of work across people and decisions. A procedure is the formal description of that flow. SMEs often have processes without procedures, and sometimes procedures without a corresponding real process.

Does a small SME need to map processes? Not always. Below a certain size, proximity coordination may be more efficient than documentation. Mapping becomes useful when dependency, rework, repeated delays or key person risk appear.

Do we need software to manage processes? Not to make them legible. Software can help at volume, but only after sequence, ownership and decision rights are clear. The reverse order usually digitises disorder.

Why do investors care about processes? Because legible processes mean results are more replicable without the current people. They reduce key person risk, accelerate integration and make the quality of earnings more defensible.