The process approach follows how results are produced
The process approach in quality management means understanding work as connected activities that turn inputs into intended outputs. It asks how those activities interact as a system, rather than assuming that effective departments automatically produce an effective overall result.
As one of the seven quality management principles, it helps expose handover failures, unclear decisions and local targets that damage wider performance. A map can support this thinking, but the principle does not prescribe a particular diagram, software package or number of documented processes.
A useful process description lets someone explain what starts the work, what successful completion looks like, who can make decisions and what happens when the normal route cannot be followed.
Choose a meaningful boundary
Start with an intended result and work backwards to the inputs needed to achieve it. A process called administration is difficult to examine because its purpose and boundaries are vague. A route from accepted order to confirmed delivery gives a clearer outcome and interfaces.
Avoid making every minor task a separate management process. Equally, do not describe the whole business in one box if that conceals important dependencies. The appropriate level depends on complexity, risk, responsibility and the decisions people need to make.
Identify a starting trigger, an ending condition and the recipient of the output. The recipient may be an external customer or the next internal process. Confirm what that recipient needs to proceed without rework or guesswork.
Describe the work people actually perform
Bring together people from the activities being examined. Follow a recent case and compare the formal procedure with actual practice. Workarounds can reveal either an outdated instruction or a useful adaptation that needs careful evaluation.
Capture enough information to operate and assess the process:
| Element | Practical question |
|---|---|
| Purpose | What result is this process expected to achieve? |
| Input | What must be available before work can begin? |
| Responsibility | Who coordinates performance and resolves interfaces? |
| Resources | What people, information and equipment are needed? |
| Control | Which decisions prevent an unacceptable output? |
| Output | What does the recipient need to accept or use it? |
| Evidence | How will we know whether the process worked? |
Some answers may already exist in working instructions, schedules or system fields. Link useful information rather than reproducing it repeatedly in a decorative map.
Examine handovers as decisions
A handover is more than transferring a file. It often transfers responsibility, assumptions and the authority to act. Ask what the receiving person must know, how they recognise an incomplete input and how they resolve a disagreement.
Watch for silent acceptance. If purchasing receives an ambiguous specification but proceeds to protect a deadline, the process may create an error that only becomes visible during installation. The originating activity might report timely completion while the delivery route performs poorly.
Agree a proportionate acceptance rule at important interfaces. Straightforward inputs may need a simple completeness check. Complex work may require technical review or clarification with the customer. The rule should prevent foreseeable confusion without turning every handover into an approval bottleneck.
Hypothetical example: a service handover
A hypothetical maintenance business measures technicians on jobs closed each day. Office staff later discover that several closed jobs lack information needed to invoice correctly or schedule further work. Technicians regard the visit as complete; office staff regard the case as incomplete.
The team defines completion more clearly: the visit record must state work performed, relevant findings and any further action. It tests a shorter record format and confirms that technicians can complete it at the worksite. Office staff check whether the revised information supports the next activity.
The team reviews the whole route, including record accuracy, customer follow-up and time to complete administration. It avoids declaring success merely because technicians close more jobs. This hypothetical example illustrates a decision about interfaces, rather than a required record format.
Measure the result and the process
Choose measures that help explain both the outcome and its causes. Delivery accuracy tells you something about the result. Incomplete inputs, rework and waiting at an interface may explain why that result varies.
Define measures consistently. A completion rate calculated before downstream rework will differ from one calculated after final acceptance. Record denominators and exclusions so that comparisons retain meaning. The article on evidence-based decision making explains why measure definitions deserve attention before conclusions.
Review interactions before changing one activity. Speeding up approvals can overload the next team; buying cheaper material can increase inspection and rejection. Assess the net effect on the intended result and important constraints.
A proportionate mapping review
After describing a process, test the description against ordinary work and an exception. Ask an employee to use it to explain what happens when an input is missing or an acceptance condition is uncertain.
- Are the start and finish understandable?
- Can the receiving activity use each important output?
- Is responsibility clear when work crosses departments?
- Are critical decisions supported by available information?
- Do measures reveal rework and relevant delays?
- Is there a route for investigating and improving recurring failure?
Revise the description where it fails these tests. The value of process thinking is clearer decisions and more reliable coordination. The appearance of the map matters less than whether it helps people understand, operate and improve the route to the required result.