How many processes belong on a process map?

In companies with 10 to 250 employees, roughly twelve to twenty processes on the top layer have proven workable (project experience). The number is not an end in itself but a consequence of readability: what can no longer be made out on a printed sheet in landscape format will not be used day to day. Anyone wanting to fit in more workflows should summarise rather than shrink and move the fine detail into the description of the individual process.

What is the difference between a process map and a process description?

The map shows which processes exist, who owns them and how they connect — on one page for the whole company. The process description sets out a single process in its sequence, with trigger, steps, outcome, systems involved and handover points. The two documents have different readers and different rates of change, which is why they should stay separate even when they are stored in the same place.

Do we need a process map if we are not certified?

The benefit does not depend on certification. As soon as a company is large enough that not everyone involved can survey the complete workflow, coordination effort arises that an overview reduces. That typically applies to companies from around twenty employees or those with several sites (project experience). Without a link to a standard the map usually turns out even shorter, because no evidence purpose has to be considered.

Who should maintain the process map — management, quality management or IT?

Maintenance belongs to a role with a view of the whole company; in smaller firms that is often the managing director or the commercial lead, in larger ones the quality owner. IT is the wrong address, because the map describes workflows rather than systems. The separation matters: one person holds the document, while responsibility for the content of an individual process stays in the area that carries it out.

How often does a process map have to be revised?

A fixed annual date is enough in most companies, supplemented by trigger events: system change, new interface, new department or role, recurring faults and audit preparation. The annual date can be tied to an occasion that exists anyway, such as annual planning. In a well-maintained state the effort is around one hour per year (project experience).

Which tool is suitable for creating the map?

For the creation itself, cards on a wall are sufficient, because rearranging has to stay possible. For the digital version any tool works that several people can open and change and that produces printable output — a table, a text file or a simple graphic. What matters is not the tool but that the file is not tied to a single person or a specialist licence.

A process map for mid-size firms: one page that gets used

Plenty of companies own a process map. It sits in a folder, was drawn up years ago for an audit and has not been touched since. A map that is actually used day to day looks different: it fits on one sheet, shows roughly twelve to twenty processes (project experience), names an owner for each one and has a fixed date for its next revision. Around 99 percent of companies in Germany are small and medium-sized enterprises (Statistisches Bundesamt) — very few of them have a dedicated organisation department. This article describes how such an overview is created in a company with 10 to 250 employees, how deep it should go, who maintains it and where quality management requirements end.

Key takeaways

A process map arranges a company's workflows on a single sheet into management, core and supporting processes; it does not replace a process description but shows which workflows exist, who owns them and how they connect.
The level of detail stays deliberately limited: around twelve to twenty processes on the top layer, each described in one sentence — anything finer belongs in the description of the individual process, not in the overview.
Without named process owners and a fixed revision date the map becomes outdated within months; an annual date plus trigger events such as a system change, a new department or a recurring fault has proven workable.
Quality management standards require the necessary processes and their interactions to be determined; a map satisfies that in passing, but it should be built for internal steering rather than for the audit folder.
The practical benefit shows in onboarding and prioritisation: the map reveals which process crosses system boundaries, where data is captured twice and which digitisation project should be tackled first.

What a process map should deliver — and what it should not

A process map is a one-page overview. It answers three questions: which workflows exist in this company, who is responsible for each one, and in what order do they interlock? Nothing more. It deliberately does not answer how an individual workflow works in detail, which fields are filled in which screen or which exception applies to which customer. That separation is the actual trick, and ignoring it is the most common reason maps fail: press both into one picture and you get a poster nobody reads.

In practice you therefore work with three kinds of document. The map shows the processes and their relationships. The process description sets out the sequence for each process, with trigger, outcome and the systems involved. The work instruction explains a single task for the person carrying it out. How these three layers interact and how they can be maintained with reasonable effort is covered in detail under process documentation.

The benefit appears wherever people need orientation. A new colleague sees within five minutes where her task sits in the whole. During a complaint it is clear which workflow is affected and who should be involved. Before choosing a system it can be stated which processes the new system would touch. And when the question comes up of what to digitise first, a shared list is finally on the table instead of a collection of individual opinions.

Three layers, three purposes

Map: which processes exist, who owns them, how they connect — one page for the whole company. Process description: how a process runs, with trigger, steps, outcome and systems — one or two pages per process. Work instruction: how to carry out a specific task — as short as possible, available at the workplace. Mix the layers and you end up maintaining none of them.

The three layers: management, core, support

The common structure divides workflows into three groups. Core processes create the service the customer pays for: from enquiry through quotation, planning and delivery to invoicing and after-sales service. Supporting processes keep the company able to work, for example purchasing, stock, people, maintenance and IT operations. Management processes determine the direction of work and how success is measured: annual planning, steering by key figures, improvement and the handling of faults.

This division is not an end in itself. It forces a decision that is rarely spoken out loud in daily business: what actually creates value here? In a trades business, site scheduling is a core process; in wholesale it is not. For a service provider, staff scheduling can become a core process because it decides the margin. The industry pages are a useful starting point for the sector-specific cut, but the classification itself cannot be made from the outside.

Management processes

Annual planning, steering by key figures, improvement and fault handling. They create no service for the customer but decide which service is delivered. The data behind them comes from metrics and reporting.

Core processes

Everything between customer requirement and delivered service: enquiry, quotation, order, planning, execution, records, invoicing, service. This chain belongs in the middle of the map and is read from left to right.

Supporting processes

Purchasing, stock, people, onboarding, maintenance, IT operations, document filing. They are frequently underestimated even though in practice they cause many of the queries and waiting times inside the core processes.

Limiting the level of detail on purpose

The hardest work on a process map is leaving things out. As soon as the first round starts, every department reports further workflows and the overview turns into a collection. The rule of thumb is: one layer, one sheet. If the map is still readable on a printed sheet in landscape format, the depth is right. If it is not, you summarise rather than shrink the font.

A process on the top layer has a clear trigger, a clear outcome and a responsible role. If the outcome cannot be stated in one sentence, the cut is probably wrong. A typical mistake is listing activities as processes: writing a quotation is an activity, enquiry to order is a process. Just as often the same thing appears twice because two departments use different names for it — reconciling the wording is a result of the exercise, not a precondition for it.

A simple test helps with the depth: can a person who knows the company but does not work in that area read the process name correctly? If a name only makes sense internally, it needs either an explanation or a rename. Abbreviations from your own systems have no place on the map.

Set the upper limit before collecting. Around twelve to twenty processes on the top layer (project experience); anyone who records more loses the overview and with it the purpose of the document.
One sentence per process. Trigger, outcome, responsible role. If the description does not fit into one sentence, the process is cut too large or there are in fact two.
No system names in process names. The process is called goods receipt, not after the screen it is entered in today. Systems change, processes last longer.
Roles, not people. The owner is operations management or scheduling, not a named individual. Otherwise the map is outdated at the next personnel change.
Leave out exceptions. Special cases are the reason maps become unreadable. They belong in the description of the process concerned.

How the map is created in a single morning

The effort for the first version is usually overestimated. In a company of this size, one morning with four to eight people is enough if the group is staffed correctly: one person each from sales or order intake, from delivery, from administration and from management. What matters is that the people who carry out the workflow every day are present — not only those who could describe it. Surveys on digitisation in mid-size companies regularly name lack of time and lack of staff as the most common obstacles (Bitkom); half a day with a clear result is therefore more realistic than a project running for weeks.

The work is done with cards on a wall, not on a screen. That sounds old-fashioned but has a practical reason: rearranging must be cheap. As soon as something sits in a drawing program it is defended rather than moved. The digital version takes thirty minutes afterwards. Anyone who wants to run the assessment systematically and make the results reliable will find the detailed approach under process analysis.

Step 1

Step 1: lay out the core chain

The group jointly describes the path of a typical order from the first customer enquiry to the paid invoice. Every station gets a card. Discussions about exceptions are written on a separate list and not resolved inside the chain.

Who maintains it and when it is revised

No name, no maintenance — that is the experience from practically every project. A map nobody is responsible for ages quietly. Responsibility usually sits with one person from management or administration who holds the document, collects changes and calls the review. That person is not responsible for the processes running well — that stays with the individual process owners. They are responsible for the picture being accurate.

A fixed annual date has proven itself, sensibly tied to an occasion that exists anyway: annual planning, the management review or the preparation of an audit. Added to that are trigger events where the map is updated immediately, because otherwise several months are worked with a wrong picture. The effort stays small when it recurs regularly: one hour a year is enough in most companies (project experience), provided the map was kept small.

Maintenance also means a visible version stamp. A document without a date is assumed to be current, and precisely that creates misunderstandings. Status, version number and the date of the next planned revision belong on the sheet — not in the file properties where nobody sees them.

Occasion	What is checked	Who decides
Fixed annual date	Are all processes still accurate, are any missing, has a cut grown too large?	Management together with the process owners
System change or new interface	Which processes does the project touch, do responsibilities shift?	Project lead with the IT owner
New department or new role	Who will own the affected processes, does a process disappear?	Management
Recurring fault or complaint	In which process does the error arise, is a handover point missing?	Process owner of the area concerned
Audit preparation	Do the map and the practice actually lived up match?	Quality owner

Setting it apart from quality management requirements

Many companies associate the term process map with certification. That is understandable but often leads to a document built for auditors rather than for the company. The standard for quality management systems requires in clause 4.4 that the necessary processes be determined and their sequence and interaction established (DIN EN ISO 9001:2015). It does not prescribe a particular form of presentation — the term process map does not appear there as an obligation.

The organisation shall determine the processes needed for the quality management system and shall determine their sequence and interaction. How this is presented is left to the organisation.

Paraphrased from DIN EN ISO 9001:2015, clause 4.4

One practical consequence follows: you build the map for internal steering, not for the audit folder. An overview that is used day to day passes an audit anyway, because it matches the practice actually lived. Conversely, a map that exists only for the inspection stands out at the latest during conversations with employees — there the question is how things really run, not what the folder says.

The same applies to companies without certification. Even without a standard, a growing company needs a shared understanding of which workflows exist. Where a certification is coming up or sector-specific requirements apply, expert review of the individual case is indispensable; interpreting a standard for a specific company belongs with the bodies responsible for it, not in a blog article.

Separate the standard from the benefit

If the map is also meant to serve an audit purpose, add references to the relevant records — not additional boxes. The overview stays in the language of the company, while the mapping to clauses sits next to it in a simple table. That keeps one document serving both purposes without becoming unreadable for either.

From the map to the order of projects

The most common immediate benefit is prioritisation. Once every process is on one sheet, three questions can be put to each of them: how often does it run, how many system boundaries does it cross, and how often does manual work arise that has already been captured elsewhere? Processes with high frequency and several media breaks tend to head the list, because that is where the time gained becomes noticeable fastest.

This turns a collection of wishes into a reasoned order. That matters, because digitisation projects in mid-size companies are predominantly small in volume and financed from operating funds (KfW Research). Anyone working in small steps has to take those steps in the right order. Which projects are technically worthwhile at all, and where manual work sensibly remains, is then clarified under process automation.

The map does not replace an assessment

A process map shows which workflows exist — it says nothing about what a case costs or how long it takes. Those figures only emerge from measurement inside the individual process. Deriving the order purely from gut feeling in front of the map improves the overview but does not yet provide a basis for decisions.

Why maps disappear into the folder

The patterns repeat. Almost every failed map shows one of the following traits, and none of them has to do with the ability of the people involved. They are decisions about scope, ownership and effort that are taken casually at the start and take their revenge later.

The counter-approach is unspectacular: start small, hang it up visibly, touch it once a year. A map that hangs in three places in the company and sits in the onboarding folder gets corrected as soon as it no longer matches. A map on a network drive whose path only two people know does not.

Drawn too finely. Sixty boxes on one sheet are not an overview. The map is then read only by the person who drew it.
Created from outside. A map produced without the people doing the work describes the target state from the org chart rather than the workflow that actually takes place.
No owner per process. Without a role on every box, the person who would report a deviation is missing. The map then ages quietly.
No date for revision. What has no date does not happen. The date belongs in the calendar, not in a statement of intent.
Stored digitally only. A document you have to open is looked at less often than one hanging on the wall. Both together is the cheapest arrangement.
Tied to one tool. If only one person can open the file, a holiday decides whether the map gets maintained.

Format, storage and access

The format is secondary as long as two conditions are met: several people must be able to open and change the file, and there has to be a printable version. A drawing program is not required. A table with three blocks and a graphic derived from it are sufficient; in many companies a plain text version is even more practical, because it can be changed faster and stays readable in any filing system.

It makes sense to store the map where the process descriptions live and to cross-reference them. Anyone digitising documents anyway should file the map in the same structure rather than in a separate folder beside it. The text version below shows how brief a complete map can be.

Process map as a text version (extract)

Process map — status 05/2026, version 4

M  Management processes
   M1  Strategy and annual planning    Management          annual
   M2  Steering by key figures         Management          monthly
   M3  Quality and improvement         Operations lead     ongoing

C  Core processes
   C1  Enquiry and quotation           Order intake        ongoing
   C2  Planning and dates              Scheduling          daily
   C3  Delivery and records            Operations lead     daily
   C4  Invoicing and after-sales       Administration      weekly

S  Supporting processes
   S1  Purchasing and stock            Purchasing          ongoing
   S2  People and onboarding           Administration      as required
   S3  IT operations and documents     IT owner            ongoing

Next revision: 05/2027, earlier if a system changes

What changes in daily work

The first visible effect concerns conversations. Discussions about responsibilities get shorter because a shared picture exists that people can point at. The second effect concerns onboarding: new employees understand the company faster when they can see their own place in the workflow. Both are hard to measure and are still the reason companies keep the map going after the first year.

The third effect shows up in projects. Before every purchase, every interface and every changeover there is a list against which it can be checked which workflows are affected and who has to be involved. That prevents the familiar situation in which a department learns about a change after it has happened. A process map should deliver no more than this shared picture — and it should deliver no less.

This article is based on data from: DIN EN ISO 9001:2015 (clause 4.4, quality management systems), Statistisches Bundesamt (structure of companies in Germany), Bitkom (surveys on digitisation in mid-size companies), KfW Research (digitisation report on mid-size companies) and project experience from digitisation work in companies with 10 to 250 employees.