Design Problem Solving into the Process

Good processes and systems have ways designed into them to identify when a problem occurs, and ensure it gets the right rigor of problem-solving. A model like Art Smalley’s can be helpful here.

Each and every process should go through the following steps:

Define those problems that should be escalated and those that should not. Everyone working in a process should have the same definition of what is a problem. Often times we end up with a hierarchy of issues that are solved within the process – Level 1 – and those processes that go to a root cause process (deviation/CAPA) – level 2.
Identify the ways to notice a problem. Make the work as visual as possible so it is easier to detect the problem.
Define the escalation method. There should be one clear way to surface a problem. There are many ways to create a signal, but it should be simple, timely, and very clear.

These three elements make up the request for help.

The next two steps make up the response to that request.

Who is the right person to respond? Supervisor? Area management? Process Owner? Quality?
How does the individual respond, and most importantly when? This should be standardized so the other end of that help chain is not wondering whether, when, and in what form that help is going to arrive.

In order for this to work, it is important to identify clear ownership of the problem. There always must be one person clearly accountable, even if only responsible for bits, so they can push the problem forward.

It is easy for problem-solving to stall. So make sure progress is transparent. Knowing what is being worked on, and what is not, is critical.

Prioritization is key. Not every problem needs solving so have a mechanism to ensure the right problems are being solved in the process.

Enabling the Process Owner to Drive Improvement

The process owner is a central part of business process management yet is often the one we take for granted. In this session, the speaker will share through case study how organizations can build strong process owners and leverage them to drive improvement in a highly regulated environment. Participants in this session will learn: ~how to identify process owners and competencies for success, ~how to build a change management program that leverages process owners as the guiding coalition, and ~how to create and execute a training program for process owners
2022 ASQ WORLD CONFERENCE ON QUALITY & IMPROVEMENT

The presentation I gave at the 2022 World Conference on Quality & Improvement.

Slides
Process Owner Competency Framework
Process Definition Document
Process Owner Deliverables
Posts from this blog on the Process Owner

Common Ownership Challenges

Governance and ownership challenges often arise in an organization for four reasons:

Business stakeholders who resist assuming ownership of their own processes, data and/or knowledge, or have balkanized/siloed accountability
Turf wars or power struggles between groups of stakeholders
Lack of maturity in one or more areas
Resistance to established governance rules

The Business Struggles with Accountability

Processes often have a number of stakeholders, but no apparent owners. This results in opportunity costs as compulsory process changes (e.g. legislative requirements, systems capacity, or company structural changes) or process improvements are not implemented because the business process owner is unaware of the change, or no clear business process owner has been identified which leads to an increase in risk.

Sometimes processes have a number of stakeholders who all think they are the owners of parts of the process or the whole process. When this overlap happens, each supposed owner often identifies their own strategy for the process and issues their own process change instructions to conform to their understanding of the purpose of the business process. These conflicting instructions lead to frustration and confusion by all parties involved.

Lack of accountability in process and system leads to inefficient processes, organizational disharmony, and wasted energy that can be better spent on process improvements.

Turf Wars

Due to silo thinking there can be subdivided processes, owned by different parts of the organization. For example, count how many types of change control your organization has. This requires silos to be broken down, and this takes time.

Lack of Maturity

Governance is challenging if process maturity is uneven across the organization.

Failure to Adhere to Governance

It can be hard to get the business to apply policy and standard consistently.

Process Owner Deliverables

Process Owner implementations require a lot of work, but when used can drive maturity in an organization. To ensure success, it is important to have clear deliverables. Below are a few recommendations:

Task	Demonstrated by
Ensuring process objectives are met	Gap Assessment against relevant external (e.g. regulations, standards, benchmarks) and internal (e.g. policy, strategy) obligations Process Definition Document and Resource Requirements Plan
Developing, deploying, and managing process documentation	Process and procedure documented (e.g. SOP, WI, etc)
Determine training requirements	Role-based curricula in place
Determining, implementing and monitoring metrics	Metrics plan in place and in use
Improving process performance	Improvement plan in place and in use
Representing Process to Leadership	Communication plan in place and in use
Representing the process during internal audits and third-party audits and inspections	Inspection readiness plan in place and in use

The Program Level in the Document Hierarchy

A fairly traditional document hierarchy, in line with ISO 9001 and other standards looks like this:

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.

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.