Core processes directly contribute to the outputs an organisation delivers to its customers. Support processes enable that work through capabilities such as competence, equipment, information or purchasing support. These are useful management labels, but the exact classification depends on the organisation’s purpose and operating model.
The process management guide explains how process architecture supports control and performance. Classification should clarify contribution and relationships, not create a hierarchy in which support activities are assumed to be unimportant or excluded from the QMS.
Start with the organisation’s intended output
A delivery company may regard collection, transport and delivery as core work. A software business may use requirements, development and service support as major delivery processes. The same activity can have a different contribution in another organisation.
Maintenance can be a supporting capability for a manufacturer while being the core service of a maintenance business. Avoid classifying solely by the activity’s name or a generic process template.
Define what the process produces and who uses it. That provides a better basis for discussion than assuming that revenue-generating departments automatically contain every core process.
Understand enabling contribution
A support process supplies something that other work needs. Competence management can enable suitable task performance. Equipment maintenance can enable reliable operation. Information control can ensure that users obtain current requirements and instructions.
A failure in supporting work can have major consequences. An unsuitable measurement system may undermine acceptance decisions even when production appears well controlled. The label support does not imply a lower need for ownership, resources or evaluation.
Consider the recipient and acceptance of the supporting output. Training attended may not be the capability the receiving process needs. Equipment returned to service may require evidence of suitability, not only a completed maintenance task.
Distinguish management processes where useful
Some architectures separately identify processes that establish direction, allocate resources or evaluate performance. Strategy, management review and system improvement may fit that view.
The categories can help organise the system, but they are not a universal required set of boxes. An organisation can use another coherent arrangement if purposes, responsibilities and interactions remain understandable.
| Classification example | Contribution | Important relationship |
|---|---|---|
| Core delivery | Produces a customer-facing result | Uses agreed requirements and supporting resources |
| Support | Enables suitable operation | Supplies usable capabilities or information |
| Management | Directs and evaluates the system | Uses evidence and authorises relevant action |
This table is explanatory. It does not prescribe a fixed architecture for every ISO 9001 organisation.
Avoid using departments as the only boundary
One department can contribute to several processes. A process can cross multiple departments. Classifying the entire finance or operations department as one process may conceal important differences in purpose and handovers.
Follow real work to see what each activity produces. For example, purchasing can include supplier selection, order placement and resolution of supplier problems. The appropriate management boundaries depend on control needs rather than the organisation chart alone.
The process identification article explains how to choose a useful level of detail without turning every task into a standalone process.
Evaluate interactions before priorities
An organisation may prioritise improvement in a customer-facing process while missing the supporting failure that drives poor results. Repeated dispatch delays might arise from unreliable order information or unavailable approved packaging.
Examine dependencies and evidence before deciding which process needs action. A faster core activity can make the overall result worse if it passes incomplete work downstream or overwhelms a support capability.
Classification should not determine audit depth or resources automatically. Consider consequence, changes, variation and previous results alongside the process’s role.
Choose measures suited to the contribution
A delivery process may be evaluated through acceptance, timeliness and relevant rework. A support process needs evidence that its output is usable and available when required, not merely that its internal tasks were completed.
For competence management, counting courses can miss whether people can perform the work. For information control, counting approved documents can miss obsolete instructions at the point of use.
Connect local measures with the receiving process’s needs. This can reveal conflicting targets that make one team appear successful while the wider system suffers.
Review classifications when the business changes
Outsourcing, new services, acquisitions or technology can alter process relationships. A capability previously provided internally may become an external dependency that still requires suitable control.
Do not preserve an old category merely because it fits a familiar diagram. Review whether the architecture helps people understand responsibility and manage the intended results.
The useful distinction is functional: core work produces the organisation’s intended customer output, support work enables it and management arrangements direct and evaluate the whole. None of those contributions can be judged adequately in isolation from its relationships with the others.
Where a supporting capability is outsourced, the classification should not obscure responsibility for suitable control. The organisation still needs to understand what it receives, how suitability is established and who responds when that dependency fails.