In Chapter 4 we looked at the need for support information based upon the needs of the organization and the business risks that it faces. The support information can come in many forms, and this chapter will look at procedures.
Procedures give the detailed ‘how to’ information that an organization feels it needs to ensure its people can effectively carry out the activities allocated to them. They are not written just because we do something, but because we fnd them useful and they minimize risk to an acceptable level.
Procedures are generally required where they are:
• mandatory in ISO 9001:2008;
• mandatory in other standards or frameworks you are following;
• mandatory or are required to meet legal and regulatory requirements;
• required to support your organization and reduce business risks;
• helpful to people carrying out activities or to defne standards to be achieved;
• needed to ensure added consistency in achieving deliverables.
Your organization may well have other reasons for having procedures, for example as training aids, although care should be taken not to use procedures for a purpose for which they were not designed. In this case there are a number of ways training can take place – writing training notes as procedures would be only one method to be adopted.
This leads to another aspect of procedure identifcation and design – competence. As you will see when you begin to identify the need for procedures, some activities will have procedures and others will not. Apart from the areas listed above, the main reason for this is often the level of competence of the people carrying out the task or activity. Where there is a low level of competence
Procedure design – Linking supporting information to processes
59
an organization may decide to have procedures with quite a high level of detail.
Where the competence of the people is high then either no procedures, or procedures with high-level detail only, or perhaps key points, may be required.
The decision on the extent and type of procedure is up to you, having frstly weighed up the needs, business risks and competence of the people involved.
As the organization is ever changing, and along with it the people involved, the need for procedures may change over time. For example, a high staff turnover would introduce a number of new staff into the organization, which may increase the risk of something going wrong. To manage this risk an organization may decide to introduce procedures and keep these until the new people become competent when the procedures could be removed or archived if surplus to requirements.
Another factor that may impact your decision on the need for procedures is what kind of other information is available. For example, ‘help’ functions on software programs or instruction manuals/leafets provided by suppliers of products and services. Likewise you can also reference information from other parts of the organization such as training materials, guidance documents and specifcations.
What about the mandatory procedures for ISO 9001:2008?
These are treated like any other procedure, and positioned as such in your system.
There are six mandatory procedures:
• preventive action;
• corrective action;
• audit;
• document control;
• management of quality records;
• control of non-conforming products and services.
You have complete freedom over how you create these mandatory procedures.
The need for any other procedures is down to you. The key thing is that they should be effective, and that everyone involved in using them should be able to understand and apply them.
How do I write a procedure?
A procedure can come in many forms based upon your needs. These include:
• text;
• pictorial;
• video;
• webcam;
• fow chart;
• hyperlink to website.
Whatever method or combination of approaches you decide to use the key point is to create them with the reader in mind. Procedures need to be simple and straightforward and to carry suffcient information to be useful to the people using them. They should also describe ‘how’ a particular activity is completed and not ‘what’ that particular activity is, which is described in the process.
Traditionally when writing procedures you will probably have started with a ‘scope’ and the details as to ‘who’ carries out the procedure. Of course, if you follow the approach outlined in the previous chapter this information is now shown in the process or sub-process so it is largely redundant at a procedural level. It is far better to simply refer to the process activity that the procedure supports, so that there is complete ‘linkage’ between them.
When creating a procedure, it is best to write it as if you are the person carrying out the task. This ensures the reader will fnd any instructions easy to understand. Other useful tips include:
• where appropriate, use bullet points rather than an extended paragraph;
• try to start the description of each step in the procedure with an active verb (e.g. decide, log, carry out, begin, close);
• be ruthless with the writing to ensure that words that do not add any value are excluded.
The procedure is there to defne the responsibilities that need to be completed for a task to be successful, so the steps should be written, displayed or otherwise represented to refect this.
This book outlines ‘system thinking’ and therefore what ISO 9001:2008 is all about.
In principle there is only one set of business processes for each organization, not one set for quality, another for health and safety and so on. This principle also applies at procedure level, where you will need to consider all of the requirements of the business in carrying out the activity effectively, from whatever standard, framework or other source they may arise. You can then assess which of these needs to be written into the procedure that supports it.
When writing procedures you should therefore include everything that you feel is needed by the typical user to consistently carry out the task, based on your assessment of the risk of it not being effectively completed. People carrying
Procedure design – Linking supporting information to processes
61
out tasks generally do not worry about what management discipline or standard is being applied, they just want to know what they need to do the job properly.
Just as there is only one set of business processes so there is only one set of procedures. An example of a written procedure could be as shown in Figure 5.1.
1 . Receive the job and requisition form.
2. Log the job on the print room database.
3. Place the job and requisition form on the work table in start of job time order if being completed in-house.
3.1 If any work is to be sent to AB print room make necessary notes on the database and job board in CD print room.
3.2 If outsourcing hand to supervisor or work-flow co-ordinator and make a note in “additional comments” section of database.
3.3 If there is a change to customer requirements stated on job requisition before or during processing, update job requisition on database, and either:
advise the operator of new requirements if job is being processed; or prioritize job on work table if not being processed.
__
Date: 31/07/2009BSI/PM: Siobhan FitzgeraldModifications: Approval of issue Operator: Nora Dawson (7769)Department:Modifications:Date:Signature:
File name: 2009-01 729_5.1 .eps BIP 201 4
Figure 5.1 Example of a written procedure
This could be shown in a number of different formats, and you will need to decide on the most appropriate one each time you decide that a procedure is needed. There is certainly no need to stick to a single approach or format every time – indeed, if you do this you are probably missing a real opportunity for clarity in many cases. And don’t be constrained by the way you have done it in the past. Think about what will help the user most and then do it that way. If they are involved, then so much the better, as they can decide for themselves.
The written procedure could be displayed as a fow chart as shown below in Figure 5.2.
Where you need to mention or reference other documents, forms or checklists, do so in the procedure. There should, however, be no need to explain how the form or checklist is completed in the procedure, as this would normally be self-evident from the form itself. If it is not, then perhaps you should look at
the design of the form. Also, don’t forget the level of competence of the people who will be using the procedures. Don’t try to include the things that their current level of competence should mean they already know. Many procedures of the past have been so detailed that they gave the impression that those using them had no competence at all, which was hugely demoralizing for the people involved.
Receive job and requisition form
Log job on the print room
database
Hand to supervisor or job co-ordinator
Who will complete the job?
Make note on database and job board
Place the job on work table in start-date order
Make note in job database
Receive change request
from customer
Update job request on database
Has job already started?
Advise operator of changes
required
Date: 31/07/2009BSI/PM: Siobhan FitzgeraldModifications: Approval of issue Operator: Nora Dawson (7769)Department:Modifications:Date:Signature:
File name: 2009-01 729_5.2.eps BIP 201 4
Figure 5.2 A fow-charted procedure
When you talked about identifying processes for the system you mentioned process owners. Who owns the procedures?
You will remember that processes are owned by process owners and as procedures are part of a process they also take overall ownership of the procedures that support them. This does not mean that they are responsible for creating, writing and updating them as they change and improve, but it does mean they are the ones who decide what is required. Often it is best to ask the process owner to agree what procedures are required and to confrm who should write/prepare
Procedure design – Linking supporting information to processes
63
them and approve their content once written. This approach keeps the ultimate responsibility with the process owner, but places responsibility for the detailed content at the appropriate level within the organization. The process owner will often delegate ownership of sub-processes, activities and procedures to the appropriate team member operating within the process. It should, however, be noted that by locking sub-processes and procedures within individual process steps, they are in effect being constrained because of where they sit within the overall process.
Having a process owner who takes overall responsibility does not, however, remove any of the responsibility from those people delegated to manage sub-processes and procedures. As we said in an earlier chapter, an effective process map will indicate who should take responsibility for each sub-process or procedure. This ensures that there is no confusion over who is responsible for what. In fact, this approach is a useful method of creating a real level of empowerment for these sub-process and procedure owners. Yes, people may feel constrained by where they sit within the process, but they can have complete ownership of how they achieve what they need to within their sub- process or activity.