Quality Management by SOP

There are constant references in the regulations to the Quality Management System, or QMS, expected to be in place at every GxP-compliant site. The QMS is generally described in the Quality Manual and reflected in approved, controlled Standard Operating Procedures (SOPs).
Note the use of the word ‘reflected’ here. Should the SOPs not be used to help define the QMS? Let me explain.
At the majority of pharmaceutical businesses I have visited, SOPs are generally created, and sometimes managed, on a departmental basis. One department’s SOP will describe its role in what is often a cross-functional process. Another department will also have an SOP describing its role in that very same process. For example, at a site where products are labelled, the warehouse or materials management might have an SOP for dispensing the labels, the labelling department will typically have an SOP for the labelling process itself, and QC/QA will have their SOP for checking and releasing the products after labelling. It’s not uncommon to find discrepancies between these SOPs at points where the process crosses from one department to another.
SOPs tend to be written initially to describe what is done, then new requirements are added over time on the back of an audit comment or GxP deviation until the documents become structureless and hard to follow. New SOPs are added over a number of years, until an SOP system that started off with a reasonable number of documents within it grows unchecked until it reaches a state where the contents of different documents overlap, repeat items of information, miss others altogether and all too often contradict one another.
Does this sound familiar? If so, your SOPs almost certainly do not help define your QMS.  
Let’s go back to where we started – the Quality Management System. The QMS can be broken down into a number of elements or subsystems – i.e. those processes that are used or followed in order to maintain control and ensure that regulatory requirements are met. These will vary depending on which area of the industry you are in, but some, such as document management, training, change control, deviation and CAPA management, will be common to all.
Now, if you can identify and define the processes within your QMS, try taking your list of SOPs and arranging them by process, instead of by department. Do they all fit into your QMS? (If not, maybe you need to adjust it a little.) Do you have multiple SOPs for some processes and none for others? This exercise can be quite an eye-opener. I recently did this for one site and found no fewer than 15 different SOPs for document management – despite the fact that all controlled documents were managed in more or less the same way. At another site each department had its own SOP for deviation management.
Perhaps it’s time for a revamp.  

We want to end up with a set of SOPs that clearly describe the processes followed in order to maintain control and meet the expectations of regulatory authorities. We’ve already defined these processes as elements of our QMS; the next step is to work out which SOPs we actually need. The simplest way to do this is to map each process cross-functionally, making sure that each function that plays a part in the process is involved in the mapping session. This achieves several things:
• it identifies inconsistencies and gaps where processes are handed from one department to the next;
• it identifies loose ends and open loops
• it provides a basis for identifying the SOPs required
• it provides an excellent starting point for actually writing those SOPs.
Some processes, such as CAPA management, can easily be described in a single SOP. Others, such as material control or management of adverse event reports, may need several, but you can use the process map to ensure that any interactions between the different parts of the process are completely and consistently covered by the resulting documents. And, of course, you should check that the process eventually described in your new SOP meets all the expectations of the regulatory authorities.  
It is almost certain that, within your existing documentation system, there are a number of SOPs that have no process as such, but describe how to operate a particular item of equipment or perform a particular task. I would argue that these should not be SOPs at all, but another document type such as User Guides or Work Instructions. I have heard so many complaints about the burden of periodically reviewing vast numbers of SOPs – this burden becomes much smaller if these task-describing documents are taken out of the system. They can still be controlled, but via a different system such as equipment change control – why would there be a need to revise a document describing how to operate an item of equipment if the equipment itself doesn’t change? Your QMS helps to identify which documents should actually be SOPs (how we operate as opposed to how to operate) – they are simply the documents that describe and define the elements of your quality system and how you maintain control of the processes within those elements.
It may take a couple of years to completely change your SOPs from reflecting to defining your quality system, but it will be well worth the effort. At the end you should have a very clear, specific set of documents, with no repetition, gaps or inconsistencies. If you also maintain the flowcharts and assign a process owner to each QMS element, making them signatories to the SOPs describing their process, you may even be able to keep it that way.