Understanding How to Organize Process

Process drives the work we do. We can evaluate processes on two axis – complexity and strategy – that help us decide the best way to manage and improve the processes.

Process complexity and dynamics are what types of tasks are involved in the process. Is it a simple, repetitive procedure with a few rules for handling cases outside of normal operation? Or is it a complex procedure with lots of decision points and special case rules? Think of this like driving somewhere. Driving to your local grocery is a simple procedure, with few possibilities of exceptions. Driving across the country has a ton of variables and dynamism to it.

While complexity can help drive the decision to automate, I strongly recommend that when thinking about it don’t ask if it can be automated, only ask what would be involved if a human were to do the job or how it is done with current technologies. Starting with the answer of automation leads to automation for automation’s sake, and that is a waste.

Dynamics is how much the process changes – some change rarely while others change rapidly to keep pace in response to changes in product or external factors (such as regulations).

Strategic importance asks about the value the process contributes to meeting requirements. Is the process a core competency, or an enabling process that needs to be accomplished to ensure that you can do something else that meets the core requirements? Needless to say, one company’s strategic process is another company’s routine process, which is why more and more we are looking at organizations as ecosystems.

Processes are in a hierarchy, and we use levels to describe the subdivision of processes. We’ve discussed the difference between process, procedure and task. At the process level we usually have the high-level process, the architecture level, which are the big things an organization does (e.g. research, manufacture, distribute), mid-level processes that are more discrete activities (e.g. perform a clinical study) to even more discrete processes (e.g. launch a study) which usually have several levels (e.g. select sites, manage TMF) to finally procedure and task.

Level of Process	Includes	Key Ways to Address
High-Level Process	How key objectives are met, highly cross functional	Organization design. System Design
Mid-level Process	How a specific set of departments do their major work blocks	Process Improvement
Low-level process	How individuals conduct their work in sub-blocks	Knowledge management, task analysis, training

Levels of Process

To truly get to this level of understanding of process, we need to understand just what our process is, which is where tools like the SIPOC or Process Scope diagram can come in handy.

To understand a process we want to understand six major aspects: Output, Input, Enablers, Controls, Process Flow, People.

Complex and Complicated as Tools for Process Understanding

Simple processes usually follow a consistent, well-defined sequence of steps with clearly defined rules. Each step or task can be precisely defined, and the sequence lacks branches or exceptions.

More complicated processes involve branches and exceptions, usually draw on many rules, and tend to be slightly less defined. Complicated processes require more initiative on the part of human performers.

Complex processes are ones that require a high level of initiative and creativity from people. These processes rapidly change and evolve as time passes. Successful performance usually requires a connection to an evolving body of knowledge. They are highly creative and have a large degree of unpredictability. Most complex processes are viewed at the system level.

Sources

Benedict, T. et al. BPM CBOK Version 4.0: Guide to the Business Process Management Common Body of Knowledge. ABMP International, 2019.
Harmon, Paul. Business Process Change. Morgan Kaufmann, 2019.
Nuland, Y. and Duffy, G. Validating a Best Practice. Productivity Press, 2020

SIPOC for Data Governance

The SIPOC is a great tool for understanding data and fits nicely into a larger data process mapping initiative.

By understanding where the data comes from (Suppler), what it is used for (Customer) and what is done to the data on its trip from supplier to the customer (Process), you can:

Understand the requirements that the customer has for the data
Understand the rules governing how the data is provided
Determine the gap between what is required and what is provided
Track the root cause of data failures – both of type and of quality
Create requirements for modifying the processes that move the data

The SIPOC can be applied at many levels of detail. At a high level, for example, batch data is used to determine supply. At a detailed level, a rule for calculating a data element can result in an unexpected number because of a condition that was not anticipated.

SIPOC for manufacturing data utilizing the MES (high level)

SIPOC diagrams

I am a huge fan of a SIPOC which stands for suppliers-inputs-process-outputs-customers. A SIPOC diagram is a quick broad overview of all the elements of a process and serves as a great visual tool.

Start with the process

Provide the key steps of the process in the middle column and briefly describe its key steps. A SIPOC diagram is a high-level process map and is designed to get a birds-eye overview of the process. Do not include decision points or feedback loops.

Identify the outputs of the process

Focus on the key outputs of the process. In this step, write down the three or more main outputs. Use nouns for the most part and avoid categorizing your outputs into good or bad ones – that’s not the point of the diagram.

Identify the customers

List the people who benefit from the process. These don’t have to be the literal “customers.” E.g., if you are working on a diagram for an internal process, the “customers” are your coworkers. Think of who benefits from this process. Who would be upset if the process is not complete?

List the inputs for the process

List the inputs required for the process to function properly. Just like with every previous step, focus on the most important ones. Three to six main inputs should do.

Identify the suppliers of the inputs

List the suppliers based on what inputs the process uses. Be sure to mention any specific suppliers whose input has a direct influence on the output.

The template I use is here.

Examples of SIPOCs:

Release control process sipoc

Google does not share search terms for privacy reasons, so it is rare that a search term stands out on my blog.

So here you go.

SIPOC for disposition

This is purposefully a high level process.

Quality Review of Records: Batch Record, Packaging Record, the like

Lot Assessment: Evaluation of deviations, of change control and test results; but also of other inputs such as Critical Utilities and Environmental Monitoring Review. Ideally a holistic view.

Lot Disposition: Decision that the product meets all requirements of the GMPs and the market authorization.

Some important regulatory requirements:

United States: 21 CFR 211.22(a); 211.22(d)
EU: 1.4(xv); 1.9(vii); EU Annex 16
World Health Organization: Annex 3-GMP 1.2(g); Annex 3-GMP 9.11, 9.13, 9.15

One of the drivers for digital transformation, and a concept at route of the ICHs, is the idea of release by exception. Our systems will be tight enough, our design space robust enough, that most products are automatically released and sent into the market.

Change Management and Document Control

“If it isn’t documented, it didn’t happen” is an often-repeated and heavily loaded phrase. One that I want to unpack in a lot of ways on this blog.

Here I want to focus on the interaction between change management and document control, as I think the two are closely intertwined, and that close relationship can confuse you.

Change Management is all about how we assess, control and release our changes. Document control is how we create, review, modify, issue, distribute & access documents. Document control is part of knowledge management (an enabler of the enabler), it is a tool for change control, and is often a deliverable, but it is important to understand that change management is broader than document control, and the principles of change management should enwrap and permeate a document control system.

Let’s start with a SIPOC.

SIPOC for document control

Change Management here is all about the how of the change:

Assess – What is the impact of our changes
Handle – Implementing our changes
Release- Using the change

All three of these are a risk-based approach, the amount of effort and rigor depends on how risky the change is. There are a few principles to keep in mind when developing that risk-based approach:

Changes come in different sizes
Keep your type of change control mechanisms to a manageable minimum.
Have a consistent way of performing that assessment and moving between your change control mechanisms.

When I review 483s and other inspection trends one of the consistent areas is changes not going through a rigorous enough change management. They faltered on assessment, handling and/or release. It is pretty easy to put everything in the document control system and then miss a lot. (For example, those specification changes that don’t end up being filed in all appropriate markets).

So what do I recommend?

Ensure change management sits around and through document control. Build a set of standardized decision-making principles that allow a document revision to end up in the right size change control process (which can just be a document change) and then ensure there is a way to document and review those decisions. This allows us to drive continuous process improvements in this decision making.