Identify QMS processes by starting with the results the system needs to achieve and the work that produces or enables them. A department list can help locate people, but it does not automatically describe the flow of work or the interactions that determine quality outcomes.
The process management guide explains how an inventory becomes a managed system. The method below is a practical way to develop that inventory, not a mandatory ISO naming convention or required number of processes.
Start with scope and intended results
Understand which activities the QMS covers and which requirements matter to their outputs. An organisation delivering maintenance services may need to manage enquiry, requirement review, planning, service delivery and acceptance, with supporting capabilities behind them.
Identify recipients and expected outcomes. A process called administration is difficult to manage if its purpose is unclear. Accepted order to workable service plan provides a more informative result and interface.
Do not define boundaries solely to match managers’ job titles. Several departments may contribute to one result, and one department may perform parts of several processes.
Follow actual cases
Select recent work and trace how it began, moved and ended. Include relevant people from the activities and receiving functions. Examine information, material, decisions and evidence, not only the formal procedure.
A fictional installation case might begin with a customer requirement and end with an accepted installation record. Along the route, the team may identify planning, purchasing and technical review decisions that were absent from a high-level organisation chart.
Compare more than one case where variation matters. Different services, sites or exception routes can expose processes or interfaces that a straightforward case misses.
Identify enabling and management work
Delivery processes rely on resources, competence, equipment, information and external providers. Management activities establish direction and use evidence to make decisions. Include relevant relationships rather than treat these activities as outside the system because they do not directly deliver a product.
The core and support process article explains useful classification choices. The labels should clarify contribution, not create a hierarchy in which supporting work is assumed to be less important.
Some enabling work may be managed as a distinct process; some may be appropriately integrated into another arrangement. Choose the design that makes control and responsibility understandable.
Set a meaningful level of detail
A process should have an identifiable purpose and boundaries useful for management. Do not create a standalone process for every click or form field. Those may be activities within a larger route.
Equally, avoid combining so much work that ownership and performance become vague. Order to delivery can provide a high-level view while defined subprocesses support detailed control.
| Boundary question | Why it helps |
|---|---|
| What triggers the work? | Establishes a meaningful start |
| What result ends it? | Clarifies completion and acceptance |
| Who receives the output? | Identifies requirements at the interface |
| Who coordinates performance? | Tests practical ownership |
| Which differences matter? | Reveals whether separate arrangements are needed |
These questions support judgement rather than produce one universally correct process count.
Test the inventory for gaps and duplication
Check whether every important intended result has a process route and whether enabling dependencies are visible. Look particularly at customer changes, exceptions, outsourced activities and follow-up after problems.
A gap may occur where each department assumes another owns the handover. Duplication can occur where two process descriptions claim authority for the same decision without explaining the relationship.
Do not create one process per ISO clause as the default solution. Requirements can apply across processes, and a clause-based list can conceal how the work actually happens.
Agree ownership and interactions
Discuss the proposed inventory with relevant managers and users. Confirm that boundaries and responsibilities reflect actual authority and the ability to coordinate across interfaces.
An owner does not need to perform every task. The role needs a clear responsibility for the process result and a route to resolve issues involving other functions.
Identify the information needed to describe and operate the process. Existing instructions and system arrangements may already provide part of it; avoid unnecessary duplication solely to create matching documents for every inventory row.
Validate against use and change
Ask people to explain a real case using the proposed structure. Can they identify the process, current input requirements, receiving activity and exception route? Where the structure fails, revise it through suitable review.
Maintain the inventory when scope, services, sites or operating arrangements change. A process architecture that remains untouched through substantial business changes can become a misleading picture of the system.
A good inventory is manageable and complete enough to support decisions. It shows how relevant work and dependencies produce intended results, with boundaries that clarify responsibility rather than merely organise names on a page.
Before approving the inventory, ask who uses each listed output and what would happen if it were unavailable. This can expose duplicate labels or a missing enabling relationship more effectively than comparing the list only with a generic process architecture.