Think Systems: Cause Quality

What do all quality personnel have in common? 

We’re systems people.  Or at least, we should be.

Speaking in generalities, quality personnel create systems that have been designed to realize the definition of quality. The goal is always to define adaptive and effective systems that ensure our efforts cause quality to be realized and sustained.

How do we promote Quality?

As systems people, we believe that quality will be obtained through the deployment of intelligent systems.  We believe that quality is caused.

Systems People hold these truths to be self-evident:

  • An understanding of how components affect each other cannot be developed by knowing only the components ( the sum is greater than its parts)
  • There are some issues and assets that effect all stages of manufacturing, including talent, knowledge, and tools
  • The quality of the decision-making process will always be a function of the quality of the information we have

We believe that robust Quality Systems seek to:

  • Develop our understanding of the impact of our processes and the effects of our actions
  • Address issues and utilize assets consistently
  • Identify trends and highlight relationships between upstream activities and downstream results
  • Provide the most current, most relevant, and most objective information possible, allowing decision makers to make data-driven decisions
  • Recognize that the supply chain is made up of multiple and equally critical perspectives, and facilitate consensus between them by introducing each to the system at the appropriate point in time

What is a System?

 

 

 

 

System characteristics:

  • Purpose
  • Interrelated Components
  • Boundaries within an environment and constraints within the boundary
  • Human Interfaces that allow us to interact with components and provide or produce input and output

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The above graphic is simple, as are the basic fundamentals of the characteristics.  Let’s expand on this example.

All systems serve a purpose and operate in a bounded space within a larger environment.  The environment affects, and is affected by, all of the systems within it. The boundary contains the components, establishes limits of its use (imposes constraints), and separates it from other systems. Consider the following example:

  • Environment = Operations
  • System 1 = Deviation Reporting
  • System 2 = CAPA

Within the boundaries of each system are powerful tools called components.  Each component is independently functional (i.e., it can be changed without forcing a change to other components). However, the groups of components within the system are interrelated, together serving the larger purpose. 

Each component is designed to receive input and provide output, Oftentimes, the output produced by a component is the input received by another component of the same system, or by another system. Continuing with our example:

Purpose of a Deviation Investigation system:

  • Recognizing and resolving deviations from routine operations

Components (Cx) of a deviation investigation system:

  • C1: Occurrence documentation tools
    • Input = observation from personnel, results of personnel interviews, etc.
    • Output = completed observation report
  • C2: Root cause investigation tools
    • Input = completed observation report, log books, operating data, batch records, training records, calibration records, analytical data
    • Output = final investigation reports (root cause, severity, scope, impact)
  • C3: Reporting and tracking tools
    • Input = identification numbers, dates of occurrence, dates of closure
    • Output = in-progress and terminal status assignments, final investigation reports, associated data
  • C4: Trending tools
    • Input = C3 output reported over time
    • Output = trend reports (to be used as input to other systems such as CAPA, management review, continual improvement)

Groups of systems, within an environment, also must be designed to work together to serve an even larger purpose. 

Purpose of a Deviation Investigation System:

  • recognizing and resolving deviations from routine operations

Purpose of a CAPA System:

  • correcting and preventing deviations, and continually improving the environment

Larger Purpose they serve together:

  • efficiently producing product that meets all quality specifications, at the lowest possible cost

Constraints (on a theoretical process):

  • Deliverable completion constraint: CAPAs in system 2 can’t be identified for a deviation recorded within system 1, until the process within system 1 completes successfully

Limits (of authority):

  • System interactivity/ input limitation: CAPAs identified in System 2 can’t be implemented without interacting with the Change Management System (System 3) and the Training System (System 4)
  • System handoff limitation: Post CAPA implementation, affected product still can’t be released without appropriate interaction with the Lot Release System (System 5)

However, systems thinking is not the natural human condition. Identifying and evaluating existing systems, or creating new ones, is a complex process that presents challenges.

 

 

 

 

 

While some challenges may be unique to an industry, a type of technology, or particular realities of a singular organization, others seem to present themselves universally. This article will highlight a few of those universal challenges.

System Definition Challenge 1: Systems That Aren’t Visible

Systems are not always easy to see, and their boundaries, constraints, and limits are even harder to see.  Visibility may be the most common challenge – people can have difficulty recognizing the system they are interacting with, and seeing that system’s relationship to other systems. 

The danger in not recognizing that we are interacting with a system is it can lead to the assumption that it is safe to treat an occurrence as a single event.  Even if we do recognize the system we are in, but we fail to recognize the need to interact at a defined point with another system, we stand a great chance of exceeding the systems’ limits of authority – violating constraints that are meant to be imposed.

This is the challenge presented by our general inclination to think in a linear fashion.  Essentially, human beings are linear thinkers; we see straight lines.  Systems require that we think cyclically, seeking to identify non-linear relationships and interpreting their meaning in complex environments.

The reality that systems people understand?  There are no singular events.

Every event is a function of other events, every outcome is a flow of some stock, which over time becomes the stock for another flow.


To overcome this challenge, we start by trying to simplify the systems that do exist in order to make them, and their relationships to each other, easier to recognize. 

 

 

 

 

 

Systems Definition Challenge 2: Sub-par Systems

We have all seen the value of proactively defining systems, recognized only after the lack of a robust system (or set of systems) has caused serious issues.  This usually occurs when there is an over focus on local compliance and information is siloed. 


If compliance with local systems is the only priority, there is no guarantee of a Quality output.

 

 

 

 

Systems Definition Challenge 3: Systems That Don’t Improve

In order to fully meet the definition of a system, our components must include links and loops – driving constant improvement.

A link can be represented as an arrow that indicates influence and/or interaction between components of a system.

Loops are combinations of links that facilitate interdependencies between systems.  Within a looping system, every element could, at one point, be considered a cause and at another, an effect.


Effectively designed, looping components produce output that becomes input to another component or other systems.  Systems that are designed to cause quality use loop output to evaluate the downstream effect of the system.

 

 

 

 

 

Systems Definition Challenge 4: Systems That Aren’t Given Time to Work (because immediate issues seem to be outside of them)

If we think of a system as a story, the system archetypes would be the classic story that is seen over and over again.  Once we identify the archetype, we can measure expectations against the reality.  If that measurement is taken in the short term only, results can be misleading.


This is the classic tale of the short-term fix, put in place to solve an immediate issue, without first using system data to construct a data-driven understanding of what occurred. To ensure a happy

 

 

 

 

ending and overcome this, consider an appropriate amount of data in building the system, and give the new/ modified system an appropriate amount of time (with an appropriate amount of measurable data) to determine system success.

 

Summary

How do we cause Quality? 

We implement effective Quality Systems in a way that makes them visible, designing them to include:

  • boundaries, constraints, and limits
  • interrelated components that use input and provide output
  • critical relationships, at appropriate points in time, with other systems

We give them adequate time to provide feedback to other systems, and we use that feedback to improve them until:

  • effectiveness becomes measurable
  • processes become more efficient
  • results become easier to control
  • predictive change becomes more typical than reactive change
  • solutions last longer

Once we have created these types of systems, implemented them, and given them time to function and improve each other, the following are inevitable:

  • efficiency improvements
  • real time control of operations
  • consistent customer satisfaction
  • quality product
  • sustainable operating and profit margins

 

 

 

 


This article can also be seen at Master Control/gxp-lifeline/.


This image has an empty alt attribute; its file name is Gina-GuidoRedden_Headshot-e1596639531113-150x150.jpg
 

Gina Guido-Redden is a quality and regulatory professional with over 25 years of domestic and international industry experience. She is the co-founder and chief operations officer of Coda Corp USA, which provides consultancy services to pharmaceutical, biologics and medical device firms.

Guido-Redden’s history specializes in the areas of facility start up, regulatory compliance and remediation, quality system development, mentorship and training, quality system design, and implementation and management.

She is also a quality systems subject matter expert (SME), frequent seminar presenter, and content contributor to industry publications, including GAMP’s White Paper on Part 11, The Journal of Validation Technology, New Generation Pharmaceuticals, Computer Validation Digest, and MasterControl’s GxP Lifeline. Coda Corp USA is an enterprise partner of MasterControl.

 
Post a comment or leave a trackback: Trackback URL.

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>