Writing a process description for ISO 9001: structure, example and common mistakes

What is the process approach of ISO 9001?

The process approach means that you see your organisation as a set of connected processes that together deliver what the customer expects, instead of a sum of departments. A process turns input into output through a series of activities. ISO 9001 asks you to determine the processes of your quality management system, define their sequence and interaction, control them and improve them (clause 4.4).

The standard does not prescribe how you describe processes. A diagram, a table, a checklist or a short text is fine, as long as your organisation works with it and you can show that the process runs as intended. Record only what is needed to control the process. The description is a means, not a goal.

Which processes does an organisation have? Management, core and support

A process map divides your processes into three kinds. Management processes give direction and monitor the whole. Core processes deliver directly to the customer. Support processes make sure the core processes can run. For an installation company it could look like this:

Start with the processes that determine customer value and risk. An SME often manages with around ten processes at map level. If many more appear, you are probably dividing too finely and describing activities that are really part of a larger process.

• Management: strategy and policy, objectives and KPIs, internal audits, management review and improvement
• Core: quotation, preparation and planning, execution on site, handover and aftercare
• Support: purchasing, personnel and training, equipment maintenance, ICT and document control

How to write a process description: the approach in five steps

Do not write a process description from behind a desk. The process lives with the people who carry it out, and a description they do not recognise will not be used. Start with the process that causes the most risks or complaints and learn from it for the rest. Follow this sequence:

Have the owner discuss the first draft with two or three people who do the work and ask them where it differs from practice. Then adjust it and record it under document control. That produces a description everyone agrees on.

• Define the process and its boundaries: where it starts and ends, and who the customer of the process is
• Appoint the owner, preferably as a role and not as a person
• Sketch the current way of working with the people who do the work, first roughly in five to twelve steps
• Fill in the rest: input, output, responsibilities, resources, risks and indicators
• Test the description in practice, adjust it and have the owner approve it

What does a process description contain?

Use the same layout for all processes, so employees and auditors know where to find things. The standard names the elements you determine for each process: the required input and expected output, the sequence and interaction, how you measure and monitor, the resources, the responsibilities and the risks. This is the minimum content:

Add a version number, date and approver, so the description falls under document control and you can show which version applied when. Choose two or three performance indicators that really say something about the result of the process, instead of ten that nobody tracks.

• Name and purpose: why the process exists and what it delivers to the customer or another process
• Owner: the role that monitors and improves the process
• Start and end: what sets the process in motion and when it is finished
• Input and output: what you receive from which process or customer and what you deliver to whom
• Steps: the main activities in sequence
• Responsibilities: who carries out, who decides, who is consulted and who is informed
• Resources and documents: systems, forms, work instructions and records that belong to it
• Risks and controls: what can go wrong and what you do about it
• Performance indicators: how you measure whether the process runs well, with a target value

Process description example: from quotation to handover (illustrative)

The example below describes the core process 'From quotation to handover' of a fictional installation company with its own project organisation. All deadlines and target values are illustrative and meant to show the layout. Your own process, roles and indicators will differ.

Note what the example does not contain: the actions within a step. How the foreman hands over an installation or a fitter tests a connection is set out in a work instruction that you link to step 5 or 6. That keeps the process description short and keeps the instruction where the work happens.

• Purpose: give every request a suitable quotation within five working days and hand over the work as agreed
• Owner: the role of projects manager
• Start: a customer request by email, phone or tender. End: signed handover note and recorded aftercare
• Input: customer request, drawings, price lists and available capacity. Output: quotation, order confirmation, completed work and handover file
• Step 1: register the request (sales). Step 2: assess feasibility and risks (work planner). Step 3: draw up the quotation, with approval for a deviating margin (sales, manager)
• Step 4: confirm the order and schedule the project (planner). Step 5: carry out according to work instructions (foreman, fitters). Step 6: final check and handover (foreman, customer). Step 7: aftercare and customer satisfaction (sales)
• Resources and documents: quotation template, project file, work instructions and handover checklist
• Risks: unclear customer request, tight planning, missing permits or certificates. Controls: have the scope confirmed, check the planning, check the competence of the team
• Performance indicators: percentage of quotations within five working days, number of snag items per project and customer satisfaction. You set the target values yourself

Flowchart, swimlane or text, and how detailed?

Choose the form that helps your people. A flowchart shows the sequence of steps and decision points at a glance. A swimlane diagram places each step in the lane of the role that carries it out, which makes handovers between departments visible. A table or numbered list is enough for a linear process with few handovers.

Combine them: a diagram for the flow and short text underneath for what a diagram does not show, such as the criteria at a decision point. Keep the diagram on one page. If a step needs more explanation, make it a subprocess or a work instruction instead of expanding the diagram.

Describe the process at the level where control is needed. The greater the risk of errors and the consequences for the customer, safety or the environment, and the more people involved, the more detail. A routine process with experienced staff needs no more than half a page. Actions such as 'tighten the bolt' belong in a work instruction, not in the process description.

Linking processes: input, output and handover

Processes do not stand alone. The output of one process is the input of the next: the order confirmation from sales is the input of project preparation. Record these handovers, with what is handed over and in what form. Errors often arise there, because nobody feels responsible for what falls between two departments.

Also link the processes to the rest of the management system: which objectives and indicators belong to which process, which risks, which documents and which requirements of the standard. That way you see in an audit what belongs to each process, and with a change which other processes are affected.

Common mistakes when describing processes

Many mistakes come from the question of who you are writing for. Write for the people who carry out and manage the process, not for the auditor: an auditor wants to see that the process works, and you can only show that if the description is used in daily work. Watch out for these pitfalls:

• Too detailed: a description of twenty pages that nobody reads and that is outdated after every change
• Written for the auditor: the document shows how it should go and not how it goes
• The owner is missing or is a name instead of a role, so nobody maintains it
• Only steps, without input, output or indicator, so the process cannot be managed
• The link with risks and objectives is missing, so the process stands apart from the management system
• Every process described in a different layout and with different terms
• The document kept outside document control, so several versions circulate

How to keep process descriptions up to date

A process description becomes outdated as soon as the work changes. Give every description a review date with the process owner as responsible person, and also review after an incident or complaint, an internal audit, a new system, a changed law or a reorganisation. Treat a change to the process as a change you introduce in a controlled way.

Use the signals the process itself gives. If the indicators miss their target, the same deviations keep arising or employees bypass a step, then either the description or the process no longer fits. Adjust it, note the reason for the change briefly and have the employees involved confirm the new version.

How BrydgeOne supports this

In the Processes module you record the process map with management, core and support processes. A wizard asks for name, purpose, start and end, input, output and interaction. You build the process steps with normal steps, decision points, approvals and subprocesses, and link documents, work instructions, measurement plans and risks to each step. You export the process file as a PDF.

The process owner is a role and not a person. Who does what you record in the RACI matrix of Roles & responsibilities, and in Objectives & KPIs you link measurable objectives and indicators to what the process must deliver. That gives you evidence that processes are monitored. The judgement on your system stays with you and with the certification body.