How do you map your business processes — and see where they depend on one person?

What does a process map show — and what does it usually miss?

A good map shows the flow: the trigger, the steps, the roles, the decision points, the hand-overs, and the loops back when something is wrong. That alone often explains why work waits. An input arrives incomplete, nobody owns the step in between, or two teams each think the other one decides.

What most maps miss is the knowledge that makes the steps work. A box says “check technical feasibility”. It does not say which site conditions mean a second visit, who decides when the rule does not fit, or what happened the last time it went wrong. That tacit knowledge usually sits with one or two people, which is why a process can look documented and still stop when they are away.

Maps also age. Drawn once for a project, without an owner or a moment to check them, they soon describe how the company used to work.

How do we map your processes?

Practically, and fit to your business. The questions matter more than the notation, so we use what works for you: a whiteboard in a workshop, state-of-the-art AI tools to structure what people tell us and draft a first flow, or the process tools you already have.

1. Scope one process. A one-page overview: who supplies what, which steps, what comes out, and for whom. It fixes where the process starts and where it ends.
2. Walk a real, recent case. With the people who did the work, from the first request to the final result — detours included.
3. Draw the flow as it really runs. Roles in lanes, decisions as forks, hand-overs and loops made visible. The ideal version comes later, and separately.
4. Attach the knowledge to every step. Who really knows this step, how the decision is taken, which exceptions occur, what “complete” means before the hand-over — and where each answer comes from.
5. Mark the gaps. Steps only one person can do, rules that exist nowhere but in someone's head, hand-overs that keep failing.
6. Give the map an owner. One person responsible for the process, and an agreed moment to check the map against reality.

Where does mapping fit in the MentX approach?

MentX captures how your company really works: the knowledge of your key people and the processes they run. We offer both a hands-on service approach — mapping your processes and capturing the knowledge behind them, from meetings, workshops and a guided intake — and our own personality-aware knowledge base, with full source attribution, in your own Knowledge Space. We build on the tools you already use and add best-practice solutions where they fit.

Mapping is step two of four. It works on its own — a clear picture of one process has value by itself — and it connects the other steps. It shows which expert knowledge to capture first, and it is the starting point to capture your operations digitally and make them ready for AI.

A short example

An installation company maps how a request becomes an order. Six steps: request in, site visit, technical check, price, quote, order confirmation. The flow itself is simple. The map shows something else: the technical check depends on one senior engineer's rules of thumb — which roofs need a structural calculation, which sites always need a second visit. When that engineer is away, quotes wait.

The first thing to capture is not the whole process. It is that one decision rule, with its exceptions, worked out together with the engineer and tried on the next request. (An illustrative example, not a client case.)

What process mapping with MentX is not

• Not a software rollout. You do not need a new system to map a process.
• Not a thick report. One process, mapped and owned, is worth more than a binder of every procedure.
• Not process mining. Mining reconstructs processes from system logs. Most SMEs do not have those logs, and logs do not record why a decision was taken.
• Not a redesign on paper. We map how work runs today before anyone proposes how it should run.

What do you get?

• An overview of your core processes and who owns them
• One process mapped end to end, as it really runs
• The knowledge behind every step, with its source
• A short list of what to capture first, and who holds it — a direct view of your key-person dependency
• An owner and a review moment, so the map stays true
• The map in a form your team keeps using, in the tools you already have