A fairly traditional document hierarchy, in line with ISO 9001 and other standards looks like this:
Document hierarchy
This process tends to support best an approach where there is a policy that states requirements to do X, a procedure that gives the who, what, when of X, and work instructions that provide the how of X, which results in a lot of records providing X was done.
But life is complicated, and there are sets of activities that combine the Xs in a wide variety, and in complicated environments there may be multiple ways to bundle the Xs.
This is why I add a layer between policy and procedure, called the program, which is a mapping requirement that shows the various ways to interpret the requirements to specific needs.
Document hierarchy with Programs
The program document level shouldn’t be a stranger to those in the GMP world, ICH Q11 control strategy and the Annex 1 (draft) contamination control strategy are two good examples. What this document does is tie together processes and demonstrates the design that went into it.
The beauty of this document is that it helps translate down from the requirements (internal and external) to the process and procedures (including technology), how they interact, and how they are supported by technical assessments, risk management, and other control activities. Think of it as the design document and the connective tissue.
A month back on LinkedIn I complained about a professional society pushing the idea of a document-free quality management system. This has got to be one of my favorite pet peeves that come from Industry 4.0 proponents, and it demonstrates a fundamental failure to understand core concepts. And frankly one of the reasons why many Industry/Quality/Pharma 4.0 initiatives truly fail to deliver. Unfortunately, I didn’t follow through with my idea of proposing a session to that conference, so instead here are my thoughts.
Fundamentally, documents are the lifeblood of an organization. But paper is not. This is where folks get confused. But fundamentally, this confusion is also limiting us.
Let’s go back to basics, which I covered in my 2018 post on document management.
When talking about documents, we really should talk about function and not just by name or type. This allows us to think more broadly about our documents and how they function as the lifeblood.
There are three types of documents:
Functional Documents provide instructions so people can perform tasks and make decisions safely effectively, compliantly, and consistently. This usually includes things like procedures, process instructions, protocols, methods, and specifications. Many of these need some sort of training decision. Functional documents should involve a process to ensure they are up-to-date, especially in relation to current practices and relevant standards (periodic review)
Records provide evidence that actions were taken, and decisions were made in keeping with procedures. This includes batch manufacturing records, logbooks and laboratory data sheets and notebooks. Records are a popular target for electronic alternatives.
Reports provide specific information on a particular topic on a formal, standardized way. Reports may include data summaries, findings, and actions to be taken.
The beating heart of our quality system brings us from functional to record to reports in a cycle of continuous improvement.
Functional documents are how we realize requirements, that is the needs and expectations of our organization. There are multiple ways to serve up the functional documents, the big three being paper, paper-on-glass, and some sort of execution system. That last, an execution system, united function with record, which is a big chunk of the promise of an execution system.
The maturation mind is to go from mostly paper execution, to paper-on-glass, to end-to-end integration and execution to drive up reliability and drive out error. But at the heart, we still have functional documents, records, and reports. Paper goes, but the document is there.
So how is this failing us?
Any process is a way to realize a set of requirements. Those requirements come from external (regulations, standards, etc) and internal (efficiency, business needs) sources. We then meet those requirements through People, Procedure, Principles, and Technology. They are interlinked and strive to deliver efficiency, effectiveness, and excellence.
So this failure to understand documents means we think we can solve this through a single technology application. an eQMS will solve problems in quality events, a LIMS for the lab, an MES for manufacturing. Each of these is a lever for change but alone cannot drive the results we want.
Because of the limitations of this thought process we get systems designed for yesterday’s problems, instead of thinking through towards tomorrow.
We get documentation systems that think of functional documents pretty much the same way we thought of them 30 years ago, as discrete things. These discrete things then interact through a gap with our electronic systems. There is little traceability, which complicates change control and makes it difficult to train experts. The funny thing, is we have the pieces, but because of the limitations of our technology we aren’t leveraging them.
The v-model approach should be leveraged in a risk-based manner to the design of our full system, and not just our technical aspects.
System feasibility matches policy and governance, user requirements allow us to trace to what elements are people, procedure, principles, and/or technology. Everything then stems from there.
A task is the steps for doing a particular piece of work.
Procedure are activities made up of a series of tasks.
A process is an upper level description of a series of activities required to accomplish an objective. Processes are made up of procedures or tasks. They have inputs and outputs.
Process
Procedure
Task
Flow of sequences of activities that transform input elements into results
Specific and required way to carry out a process
Describe the correct steps to perform a specific task
What we do By Whom Where it takes place When it happens
How the work must be performed
How to accomplish a specific task within a process with very detailed directions
Orchestration the work
Mandatory method
Mandatory guidance
Can link to 0, 1 or more procedures
It may consist of 0, 1 or more task instructions
Focus on the instructions of 1 task
Transversal by business units
Cross functional or only 1 business unit
Only 1 business unit
Participate more than one role
Participate more than one role
Participate only one role
Encapsulates activities
Explains how to do but doesn’t get to all the details of how it is done
All of the detail of all the steps to follow in an activity
Provides the workflow model at the highest level using BPMN
Document with both narrative and images, usually in the form of use cases and workflow diagrams
Document with the maximum detail that explains step by step the instructions that must be carried out in an activity
It is pretty standard advice that relevant references to other documents should be listed in a separate section of the procedure. The reasoning is that when some standard operating procedures are intimately linked to others – the information contained in more than one document is necessary to complete a task – it is useful to include a cross-reference section in each document. Many also say that this section reinforces the SOP’s authority.
Another fairly common piece of advice is to have this, or another, section in the procedure identify the documents used in the development of the procedure, such as regulatory documents or technical/validation reports.
My take is that neither belongs in a process/procedure (SOP/WI). We should be looking to streamline requirements documents, and these sections are just cruft.
If you have electronic document control systems then cross-references should be handled trough hyperlink. Users are quite comfortable with hyperlinks and will easily navigate between documents.
Listing of regulations and other requirements belongs in a separate design document (ideally part of the document control system), and again add little value to the execution of the document.
There are a lot of so-called “best practices” about documents that stem from the days where everything is paper, and it is okay to move beyond them.
The Process Owner defines the process, including people, process steps, and technology, as well as the connections to other processes. They are accountable for change management, training, monitoring and control of the process and supporting procedure. The Process Owners owns the continuous improvement of the overall process.
Quality is ultimately responsible for the decisions made and that they align, at a minimum, with all regulatory requirements and internal standards.
Functional Area Management represents the areas that have responsibilities in the process and has a vested interest or concern in the ongoing performance of a process. This can include stakeholders who are process owners in upstream or downstream processes.
A Subject Matter Expert (SME) is typically an expert on a narrow division of a process, such as a specific tool, system, or set of process steps. A process may have multiple subject matter experts associated with it, each with varying degrees of understanding of the over-arching process.
A Risk Based Approach
The level of review of a new or revised process/procedure is guided by three fundamental risk questions:
What might go wrong with the associated process? (risk identification)
What is the likelihood that this will go wrong? (risk analysis)
What are the consequences? How severe are they if this goes wrong? (risk analysis)
Conducting risk identification is real about understanding how complicated and complex the associated process is. This looks at the following criteria:
Interconnectedness: the organization and interaction of system components and other processes
Repeatability: the amount of variance in the process
Information content: the amount of information needed to interact with the process
What Happens During a Review of Process and Procedure
The review of a process/procedure ensures that the proposed changes add value to the process and attain the outcome the organization wants. There are three levels of review (which can and often do happen simultaneously):
Functional review
Expert review by subject matter experts
Step-by-step real-world challenge
Functional review is the vetting of the process/procedure. Process stakeholders, including functional area management affected by the change has the opportunity to review the draft, suggest changes and agree to move forward.
Functional review supplies the lowest degree of assurance. This review looks for potential impact of the change on the function – usually focused on responsibilities – but does not necessarily assures a critical review.
In the case of expert review, the SMEs will review the draft for both positive and negative elements. On the positive side, they will look for the best practices, value-adding steps, flexibility in light of changing demands, scalability in light of changing output targets, etc. On the negative side, they will look for bottlenecks in the process, duplication of effort, unnecessary tasks, non-value-adding steps, role ambiguities (i.e. several positions responsible for a task, or no one responsible for a task), etc.
Expert review provides a higher degree of assurance because it is a compilation of expert opinion and it is focused on the technical content of the procedure.
The real-world challenge tests the process/procedure’s applicability by challenging it step-by-step in as much as possible the actual conditions of use. Tis involves selecting seasoned employee(s) within the scope of the draft procedure – not necessarily a SME – and comparing the steps as drafted with the actual activities. It is important to ascertain if they align. It is equally important to consider evidence of resistance, repetition and human factor problems.
Sometimes it can be more appropriate to do the real-world test as a tabletop or simulation exercise.
As sufficient reviews are obtained, the comments received are incorporated, as appropriate. Significant changes incorporated during the review process may require the procedure be re-routed for review, and may require the need to add additional reviews.
Repeat as a iterative process as necessary.
Design lifecycle
The process/procedure lifecycle can be seen as the iterative design lifecycle.
Design Thinking: Determine process needs.
Collect and document business requirements
Map current-state processes.
Observe and interview process workers.
Design process to-be.
Startup: Create process documentation, workflows, and support materials. Review and described above
Investigations of a Dog 