Process mapping shows how work moves through tasks, decisions, handovers and exceptions. A documented procedure often describes the intended route and misses the delays, rework and informal decisions people encounter in practice. Marketways combines workshops with evidence about time, volume and failure to compare the designed process with the real one. This reveals whether improvement should address capacity, information, responsibility or the design of the work itself.
The decision this method supports
We use Process Mapping & Analysis to help clients answer: How does work currently move, and where does the current process lose time, quality or control?
How the method works
Process mapping represents how work moves through tasks, decisions and handoffs. Analysis adds evidence about time, volume, rework, failure and responsibility. The purpose is to understand the operating problem before proposing technology or organisational change.
A business example
An order may appear to require two approvals. Mapping can reveal that incomplete information sends many orders backwards several times. The main opportunity may be better information at intake rather than faster approval.
How the client uses the result
Process mapping helps managers see where work waits, returns, fails or changes hands. It can prevent investment in the wrong solution by showing whether the real problem lies in information, responsibility, approval or capacity.
What we deliver
We produce a current-state map, evidence about losses, a future workflow, architecture choices or control requirements. The result make ownership, handoffs, exceptions and implementation dependencies explicit.
Limits and complementary methods
A workshop map records the process people describe. Observation, operating data or process mining may be needed to establish what actually happens.
Selected methods and techniques
We select from these established methods according to the decision, evidence and operating conditions.
- Assumption mapping: Identify the explicit and implicit premises needed for a claim or recommendation to hold, then link each premise to the conclusions and other assumptions that depend on it. Mark ownership, evidence, uncertainty and testability where available. The map exposes dependency; it does not by itself test whether an assumption is true.
- Bottleneck / constraint analysis: Identify the resource, rule, dependency or demand condition that limits the throughput or service objective of a defined process. Specify the unit of flow and operating range, measure capacity, utilisation, queues, blocking and starvation, then test whether relieving the suspected limit increases total output or merely moves the restriction elsewhere. A busy stage or long local wait is not necessarily the binding constraint. The method establishes which limit governs system performance under stated conditions; a Bottleneck Map records locations and evidence, while a Constraint / Bottleneck Profile records tested capacity and slack.
- Bottleneck / throughput analysis: Analyse an end-to-end operating system to identify the resource, rule or dependency that currently limits the rate of completed good work. Define the flow unit, process boundary, period, demand condition, work in progress, stage capacities and observed throughput; distinguish local queues or high utilisation from a binding system constraint; and test whether relieving a candidate restriction would increase total throughput. The constraint may move when demand, product mix or capacity changes. The method identifies and tests limiting conditions; it does not assume that the busiest stage or longest queue is the bottleneck.
- BPMN process mapping: Apply Business Process Model and Notation to represent a defined process using valid activities, events, gateways, sequence flows, message flows and participant lanes. Establish the process boundary and whether the evidence describes current practice or a proposed design, collect steps and exceptions from suitable sources, construct the diagram and review it with process participants and available records. BPMN 2.0.2 supplies the notation rules, BPMN process mapping is the activity of applying them, and a BPMN Process Model is the populated output. A syntactically valid diagram is not evidence that the process is complete or operates as drawn.
- Capability mapping: Identify the capabilities an organisation needs to deliver its strategy, describe each in business rather than organisational terms, and map where each currently resides, how mature it is and which units depend on it. Capabilities are defined by what the organisation must be able to do, independently of which department does it. The map shows gaps, duplication and dependencies before structure is designed.
- Competency mapping: Derive the knowledge, skills and observable behaviours required for work from job and task evidence, operating standards and informed practitioner input. Define each competency and its proficiency levels, link it to relevant roles or job families, and state what evidence would demonstrate each level. Competency mapping creates the basis for a competency dictionary and framework; it does not assess whether particular people possess the competency or explain their performance.
- Cycle-time analysis: Measure how long cases take from a defined start event to a defined end event and separate active processing, waiting, transport, rework and other material intervals where the data permit. State the unit of analysis, time basis, treatment of weekends, missing timestamps and unfinished cases, and report the distribution and relevant groups rather than only an average. Cycle-time analysis describes when time is spent and where delay appears. Queueing or bottleneck analysis is needed to explain how demand and capacity create the delay, and a time difference alone does not prove its cause.
- Exposure mapping: Identify which people, assets, activities, contracts or values are subject to a specified hazard and through which locations or dependencies. State the unit, time period and possible overlap so exposed amounts are not double-counted. Exposure shows what can be affected; it is not the probability of the event or the amount that will be lost.
- Intervention mapping: Systematically link diagnosed barriers and determinants of behaviour to intervention functions, delivery methods and evaluation measures, recording the logic that connects each intervention to the change it should produce. It produces an explicit, testable plan rather than a list of activities. The mapped logic still needs to be tested in implementation.
- Journey mapping: Map how a defined customer group pursues a stated goal from an explicit starting point to an ending point. Identify stages, touchpoints, channels, actions, needs, questions, emotions, frictions, hand-offs and outcomes, and label whether each element comes from observation, customer report, operational data, stakeholder assumption or is still unknown. Include important variation between segments and paths instead of forcing one average journey. Journey mapping is the procedure, the Customer Journey Map is the reusable representation and a Customer Journey Heatmap is one populated analytical output. It follows the customer's goal across the organisation; internal process mapping instead describes how work is performed.
- Preference mapping: Relate people's liking or choices to a mapped space of product or sensory characteristics, showing which characteristics are associated with preference and how this differs by person or segment. Internal preference mapping derives the product space from preference ratings; external preference mapping relates preference to separately measured product attributes. The map shows association rather than cause.
- SIPOC: Apply the Suppliers, Inputs, Process, Outputs and Customers structure to agree the high-level boundary and interfaces of a defined process before detailed analysis. Identify the trigger and end point, the few major process stages, what each stage receives and produces, and who supplies or uses those items; resolve ambiguous terms and excluded work with process participants. SIPOC is the reusable scoping framework, while this method is the activity of populating and checking it for a particular process. It is not a detailed workflow map, performance analysis or proof that every listed interface works as intended.
Parent method family
Process, Workflow & Systems explains how this method connects to adjacent methods and relevant services.
Related service families
These service families contain business questions supported by this method. Service pages link to the wider method family so readers can understand the complete analytical approach.