Business process mapping: method, example and use in a BIA

Business process mapping is the representation of everything an organisation does, broken down into connected processes: a one-page overview, supplemented by one sheet per process. Born in quality management, it now goes well beyond it: it is the starting point of a business impact analysis (BIA) and of risk analysis, because you can only protect well what you can describe. Here is the method, a worked example and how to use the map for continuity and risk.

A process is a sequence of activities that turns inputs into an intended result: an order received becomes a parcel delivered, an application becomes an onboarded employee. It has a purpose, an owner, beneficiaries and resources. ISO 9001 popularised this view as the process approach: it requires you to determine the processes needed, their sequence and interaction, their inputs and outputs, their owners, and the resources and indicators that keep them under control.

The map is usually built at three levels:

• the overview, on one page, grouping processes into families and showing their main exchanges;
• one sheet per process, setting out its purpose, owner, inputs, outputs, activities, resources and indicators;
• activity detail, as a flowchart, kept for the processes that warrant it.

It should not be confused with information system mapping, which describes applications, servers and networks, nor with risk mapping, which positions risks by severity and likelihood. The three complement each other, and process mapping comes first: it says what matters, the other two say what it relies on and what threatens it.

Most maps group processes into three families. Names vary between organisations; what matters is that every process fits clearly in one.

On the map, management often sits at the top, core processes in the middle, running left to right from customer needs to customer satisfaction, and support at the bottom. Core processes are the ones that create value; they are also, almost always, the ones whose disruption costs the most.

1. Scope. Set the perimeter (whole organisation, a subsidiary, a site), the goal (quality, continuity, risk, compliance) and the level of detail. A sponsor in senior management stops the map becoming one department's exercise.
2. List. In interviews or workshops with business owners, list what each department does, using action verbs: “prepare orders”, not “logistics”. Start from existing documents: organisation chart, procedures, customer contracts.
3. Group and name. Group activities into processes, then processes into families. Aim for fifteen to thirty processes for a mid-sized organisation: beyond that, the map becomes unreadable.
4. Describe. For each process, a one-page sheet: purpose, owner, beneficiaries, inputs and outputs, main activities, resources (people, applications, premises, providers), indicators.
5. Link. Draw the exchanges between processes: what comes out of one goes into another. This is where hidden dependencies appear, such as a core process waiting every day for a file from finance.
6. Validate and maintain. Have management validate the map and each owner validate their sheet, then set an annual review and an update at every reorganisation.

ISO's note on the ISO 9001 process approach recommends applying the plan-do-check-act cycle to each process: the sheet is not a static document but the basis for monitoring its indicators.

Take a distributor of medical supplies with 120 staff, delivering to clinics and pharmacies (a fictitious example). Its map has three management processes, four core processes and four support processes. The diagram below builds it, then expands the “Prepare and deliver orders” process.

The sheet for the expanded process fits in a few lines:

Two lessons emerge at this stage. The process depends on a single provider, the carrier, which falls under third-party risk management. And it depends on an application whose role nobody had measured: without the warehouse management software, pickers no longer know where products are stored.

ISO 9001 imposes no format: ISO's note on documented information even states that a formal process map is not required, as long as processes are under control. Three levels of formality coexist:

• boxes and arrows, on a whiteboard or drawing tool: enough for the overview and for a BIA;
• the suppliers, inputs, process, outputs, customers table (SIPOC), handy for filling in a sheet without missing an exchange;
• BPMN notation, standardised by the OMG then adopted by ISO as ISO/IEC 19510, useful for describing an activity in detail, especially before automating it.

For continuity and risk, the level of the map and sheets is almost always enough. Detailing every task in BPMN before running a first BIA is the surest way never to finish.

A business impact analysis (BIA) (guide in French) measures, activity by activity, what a disruption would cost and after how long it would become unacceptable. ISO 22301 makes it a prerequisite for any continuity strategy, and ISO devotes specific guidelines to it, ISO/TS 22317. France's SGDSN continuity planning guide also recommends starting from activities and their continuity needs.

Process mapping gives it three things:

• the list of activities to assess, complete, including those that do not rely on IT;
• each activity's resources (people, premises, applications, providers), which become the critical resources to protect;
• dependencies between processes: if “Prepare and deliver” stops, “Invoice and collect” stops a few days later too.

In the example, the BIA sets for “Prepare and deliver” a maximum tolerable period of disruption of 24 hours, after which clinics turn to a competitor, and a maximum tolerable data loss of 4 hours. These two values (close to the recovery time and recovery point objectives, RTO and RPO) dictate the recovery strategy for the warehouse management software and the paper-based fallback procedure. Our article on the business continuity plan covers what comes next.

Risk analysis always starts with the question: what are we trying to protect? ANSSI's EBIOS Risk Manager method answers it in its first workshop with business assets, which are essential processes or information, and the supporting assets they rely on. An up-to-date process map directly provides the former; the resources listed in the sheets point to the latter, which information system mapping details. ANSSI's mapping guide makes the same link through its business view.

The financial sector has made it an obligation: Article 8 of DORA requires firms to identify and document all business functions supported by information and communication technology (ICT), the assets supporting them and their dependencies. For each business asset, security needs are then rated for availability, integrity, confidentiality and traceability (see our article on CIAP), and scenarios are placed on a risk matrix.