Both ISO 9001 and AS9100 have adopted the “process approach” to management, and it’s caused some level of confusion ever since it launched in 2000. This article won’t go into every method of implementing the process approach (buy my book for that), but I do want to tackle the problem of process-related documentation.
Process ≠ Procedure
First, let’s get one nuisance hurdle out of the way. “Process” and “procedure” do not mean the same thing, at least in the context of quality management systems. A process is an activity you perform, usually high level, and often it sounds a lot like a department. It exists just because you do it. Sleeping, eating, skateboarding in church… all these are processes.
OK, that’s no helpful, so let’s pare it down a bit.
The official ISO definition (or one of them, at least) also says that a process “converts inputs into outputs.” So that means it’s not just something you do, but something that converts inputs into outputs. Still not very useful, as anything you can think of doing in some way converts inputs into outputs. Eating, for example: the input is that juicy steak, and the output is… well, you know.
So let’s go one step further. Anything you call a “process” under ISO 9001 or AS9100 must be measured. That helps pare down the list dramatically. So don’t call “opening the mail” a process unless you want to strap a lot of metrics onto that activity.
In the end, your process list will (as I said) look a lot like your department list. Things like “purchasing” and “manufacturing” and “sales” are often processes.
But they exist whether you write them down or not.
Documentation Time
A “procedure,” on the other hand, is a document. In fact, ISO used to refer to these under the term “documented procedures.” So a single process might have many procedures defining how to do things, or it may have none. There is no requirement that every process have supporting procedures. You decide that, based on the complexity of the work done within that process.
Under ISO 9001 and AS9100, anything labeled a process must be managed by all the bullet points in clause 4.4. As I said, one of those is that the process be measured. But another says that you shall determine process inputs and outputs. This implies — but does not require — a process map for each process. But there are a million ways to skin that cat.
Technically, you don’t have to document anything since the authors of ISO 9001 have developed an allergy to all documentation, but let’s agree that ISO is an idiot, they have no real idea how QMS’s work, and that the best way to ensure consistency is to develop documents that people will read and follow.
So having said all that, you have to tailor the level of documentation related to your processes, based on the complexity and size of your company and the QMS. Tiny companies should develop much tinier QMS document sets, while larger companies can expect to have substantially more documents.
Tiny Companies
First, let’s also assume you aren’t taking the militaristic position against a Quality Manual. Customers like them, and they are great training tools for new employees, so I am going to continue to promote them.
For a tiny company of, say, 20 employees or less, your process-related documentation should be small. Likewise, the number of QMS processes is likely to be small, too. I typically find that companies of this size can break their activities down to about six processes.
As a result, I suggest creating a Quality Manual that includes a “Process Definition Table” in its text. This table defines the process, process owner, inputs, outputs, controls, and objectives. You can add more columns, too, if you want to highlight key risks or some other factors. Once done, that single table may only add a page or two to the Quality Manual, and yet fully satisfies ISO 9001 and AS9100.
Below that Manual, then, you’d have your documented procedures, defining how certain tasks are to be done. For this article, I’m combining the concepts of “procedures” and “work instructions” into a single concept because I think making those kinds of fine distinctions is a waste of time. But you get the idea.
So, for these tiny companies, the documentation would look like this:
Medium Companies
For medium-sized companies, let’s say with 100 employees or less, the picture might change a bit. At that size, the number of processes usually increases, making a single table more difficult to use as a full description of the processes. I also find that companies of this size now start approaching 8 to 10 top-level QMS processes.
So instead of the single Process Definition Table, I suggest adding sections to the Quality Manual that define each process in greater detail. I also prefer to structure the entire Quality Manual so that it features each process as a “chapter,” really emphasizing the process approach.
This creates a lot more pages in the Quality Manual, however, making it a much larger document. A QM with process chapters can start to go over 30 pages, and hit as many as 40. But it’s easier to digest when readers know they only have to read the section related to their process… not the entire thing.
Because the process language is included in the manual, this keeps the overall number of separate documents lower. But, as I said, it makes the Quality Manual itself beefier.
Then, again, below that are your more detailed procedures:
Large Companies
For companies above 100 employees, things get a bit too complicated to make the Quality Manual do all the lifting. Here I suggest keeping the Quality Manual slim and then creating a level of documents that sit between the Manual and the procedures, which I call Process Definition Documents.
(There is a PDD template available in both the ISO 9001 and AS9100 free template kits, here on the Oxebridge site.)
These PDDs define each process in greater detail, and act as a bridge between the high-level language of the Quality Manual, and the detailed procedures and work instructions. The PDD has sections on process purpose, objectives, owner(s), risks, opportunities, and key process steps. It then points to the lower-level documents, and you can even throw in a process map.
What you won’t find is a turtle diagram because I don’t think the planet is filled with morons. (Want to know why I hate turtles? Again, buy the book.)
This increases the number of documents to manage, but (as I said) keeps the Quality Manual itself more manageable.
Giant Mega-Corporations
But what if you’re Jeff Bezos, and that hooker in your bed suggests you implement ISO 9001? I mean, if there are two groups of people we should be most concerned about, it’s billionaires and hookers, right?
Well, here is where things get complicated and not so easy to define via a single method. In such cases, I suggest the same approach as for Large Companies above, but the middle level of process-specific definition documents can grow into a “suite” of documents that sit above the procedures and work instructions.
This suite might include both high-level process documents, like a PDD, or more detailed documents such as a Process Charter (defining its purpose and stakeholders), a Process Owners Manual (essentially a high-level training document on the process), a Metrics Definition (defining the various quality objectives and process metrics data to be gathered, and the analysis methods). Then you can go nuts and do all those things you read about on the internet: SWOT analysis, PESTLE analysis, FMEA risk assessments, SIPOC, Zug-Zug, and yes… even a Turtle diagram if you never had that brain injury fixed, and still think Turtles serve any useful function.
With companies of this size, estimating that level of process documentation is difficult, but typically so are their processes. So I’m just offering super-broad strokes here. If you’re Bezos and want to hire Oxebridge to hammer this out more clearly, our rate is $750,000 an hour, and we don’t accept hookers as payment.
Conclusion
So, to wrap up, it’s crucial to document your processes to the level appropriate for your company. This means taking into account your size, number of employees, number of processes, and overall complexity of your operations. No one rule fits all — a small company might have incredibly complex processes, and a large one might have a handful — but at least you have a rough blueprint on how to manage this.
Christopher Paris is the founder and VP Operations of Oxebridge. He has over 30 years’ experience implementing ISO 9001 and AS9100 systems, and helps establish certification and accreditation bodies with the ISO 17000 series. He is a vocal advocate for the development and use of standards from the point of view of actual users. He is the writer and artist of THE AUDITOR comic strip, and is currently writing the DR. CUBA pulp novel series. Visit www.drcuba.world
