Processes and SOPs
Documenting processes as SOPs or work instructions
The editorial team for ISO/IEC 27041 and 27042 spent a lot of time thinking about how best to design investigations and came up with a concept that the standards call "atomic processes". In spite of the name it's a simple idea that can pay dividends whenever you have to design processes which can be validated within any quality system - even ISO 17025.
The name comes from the old scientific concept of the atom as something which is indivisible - i.e. it cannot be broken down any further. In this context, atomic processes are simple, re-usable processes which fit together to build up a more complex system. Generally speaking they contain no decision points and no optionality, but simply perform a single function from beginning to end. Each process has very well defined inputs and well defined outputs.
Decision points and merge points
If it looks like a process needs to have a decision point, where a decision is taken about how the process proceeds next, then that point probably marks where one process can lead into at least two others. There will be a single process up to the decision point. Then the decision will be taken. Then one of the alternative processes will follow the decision.
If the alternatives merge back together, somewhere further down the processing chain, to use some common processing again, then the merge point probably also marks the end of each of the alternative processes and the beginning of a new process for the common element.
Why use atomic processes ?
There are several reasons, and our top 3 are listed below :
1. Ease of validation
We've previously written about validation (and probably will write about it again). The smaller something is, the easier it is to validate. There are fewer inputs and outputs and fewer choices to be made. As a result, the definition of success, in terms of requirements, is easier to write and it's much easier to define what constitutes success or failure.
In any manufacturing or building environment, it is well known that the same module or component can be used in several different environments - as long it has been well designed. By keeping modules (processes, in this case) simple, we can produce a library of processes which can be re-used easily and quickly to generate a new system, introducing new processes only where we absolutely have to.
Again, this helps with cost by reducing the time required to develop any new processes and reducing the total amount of new validation which is required.
3. Re-validation after change
When a new method is introduced, or a new tool, or something is upgraded, every process in which that thing participates will have to undergo re-validation. By using a large set of well-defined atomic processes, we can limit the scope of impact of that change, and hence reduce the amount of re-validation which is required. Only those processes which are directly affected by the change need to be considered and, as we said above, because they are small and well-defined the validation can, itself, be smaller and easier.
How to document atomic processes
Individual processes should be documented as work instructions [WI] or standard operating procedures [SOP] (depending on which quality system you are implementing). These are simple, step by step instructions which any competent person, who is not necessarily familiar with equipment, tools or local practices, should be able to follow in order to complete the task.
If there are any points where errors or exceptions may occur, the written instructions must include details of what to do when those errors or exceptions arise (usually by referring to another WI or SOP - remember the advice about decision points).
These instructions should be version controlled documents which must be approved prior to use and should be subject to regular review and re-approval to ensure that they either continue to be fit for purpose or are retired when they become obsolete.
No documented process should be used until its validation is complete - although there may be exceptional circumstances when a non-validation process has to be used. If a non-validated process is used, this should be made clear in any resulting analysis or report and validation should be carried out as soon as possible after the process has been used.
Within the process, there should be a way of recording how the process has been followed so that objective evidence of its use can be preserved in case of audit, inspection or challenge to results.
Integrating atomic processes
In our experience, once the individual processes have been documented, a flow chart, showing how they fit together, is often the easiest way to represent the complete processing system - including decision and merge points. A chart like this can show which are the critical processes which are most used and most likely to have an impact on results or the business.
If you have any thoughts on this, or would like help with preparing for or conducting investigations, please contact n-gate ltd. now.