Think Systems: Cause Quality

It is always appropriate to reflect on the definition of “Quality” and what that means for us.

What is Quality?

Some definitions were predictable, and straightforward, and many could be boiled down to generalities depending on the responder’s role in the supply chain.

  • Consumers defined quality as having their functional and aesthetic expectations met for a low cost
  • Retailers defined quality as having satisfied their consumers
  • Engineers defined quality as increased efficiency and reduction of defects
  • Manufactures defined quality as having produced defect free product, on time, and for as high a profit margin as possible
  • Sales people and marketers defined quality almost entirely in terms of customer perception


The New Oxford American Dictionary defines Quality as:

“the standard of something as measured against other things of a similar kind; the degree of excellence of something.”

For those professionals functioning under Title 21, we have come to understand Quality as a measurable alignment of actualized events and processes to their associated requirements and specifications.

This is commonly referred to in a variety of ways:

  • Compliance
  • Conformance
  • Saying what we will do, and then doing what we said we would, the way we said we would do it


One thing is clear – all of these definitions vary,  but they all prove just one thing:

  • Quality is, above all else, subjective


We didn’t offer an alternative definition, and this blog won’t either. 

Where do we fall in the supply chain?  We’re systems people. 

Here’s a list of some things we don’t do:

  • Research new entities
  • Develop or formulate new products
  • Design new facilities
  • Engineer new manufacturing lines
  • Sell product or market services


Here a list of what we do, do:

  • Develop Systems
  • Implements Systems
  • Evaluate Systems
  • Improve Systems


Speaking in generalities, we create systems that have been designed to realize the clients’ definition of Quality.  At times, this begins by helping clients move their definition from general terms, to measureable terms.  Other times, the client has already defined the context of their Quality goal (i.e., they know precisely what they need to measure and how they must measure it).

However, where we start does not alter where we are going with each client.  We define for some, evaluate and improve for others, but our goal is always to leave them with adaptive and effective systems that have been engineered to give each client what they need to cause their definition of Quality to be realized, and sustained.

So instead of offering a definition of Quality that is specific to any particular industry or role within an industrial chain, this blog will instead address the fact that Systems Thinking is a critical component of meeting any Quality goal. We will also highlight some of the most common challenges that we face while trying to create, improve, or implement an effective system.  

What Causes Quality?

As systems people, we believe that any definition of quality will most likely be realized through the deployment of intelligent systems.  Because no matter the definition, or your place in the supply chain of any industry, it is our firm belief that…

“Quality has to be caused, not controlled.”
Phillip Crosby

Why do we believe that systems are so important to Quality? 

Why should manufacturers focus on building systems, instead of investing all of their energy just building their product?

Consider these facts:

  • An understanding of how components affect each other cannot be developed by knowing only the components
  • There are some issues and assets that effect all stages of manufacturing, including talent, knowledge, and tools
  •  Almost all quality improvement comes via simplification of design, manufacturing layout, processes, and procedures (~Tom Peters)
  • The quality of the decision making process will always be a function of the quality of the information we have


Sound and robust systems seek to:

  • Develop our understanding of the impact of our processes and the effects of our actions
  • Address and utilize universal issues and assets consistently
  • Identify trends and highlight relationships between upstream activities and downstream  results
  • Provide the most current, relevant, and objective information possible, allowing decision makers to make data driven decisions, geared toward the general goal of improvement.
  • Recognize that the supply chain is made up by 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?

The traditional definition of a system goes something like this:

System: A set of components that interact with one another and serve a common purpose or goal.


Systems generally have the following characteristics:

  • Purpose
  • Interrelated Components
  • Boundaries within an environment

o   Constraints within the boundary

  • Human Interfaces that allow us to interact with components and provide or produce:

o   Input

o   Output

Here is a simple illustration:




The illustration is simple, as are the basic fundamentals of the characteristics:

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

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


The environment both affects, and is affected by, all of the systems within it. 

Every individual system within the bounded space is comprised of powerful tools (or subsystems) 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 any one system are interrelated, together serving the larger purpose. 

Each component is designed to receive input and provide output; oftentimes, the output produced by one component is the input the system expects to be received by another component, of the same system or by another system.

Purpose of a Deviation Investigation system:

  • Recognizing and resolving deviations from routine operations 

Components of a deviation investigation system:

  • C1: Occurrence observation records

o   Input = observation from personnel, results of personnel interviews etc.

o   Output = Completed Observation report

  • C2: Root cause investigation procedures

o   Input = Completed Observation report, log books, operating data, batch records, training records, calibration records, analytical data

o   Output = Final Investigation Reports (Root Cause, Severity, Scope, Impact Statements)

  • C3: Reporting and Tracking Tools

o   Input = identification numbers, dates of occurrence, dates of closure

o   Output = in progress and terminal status assignments, final Investigation Reports, associated data

  • C4: Trending tools

o   Input = C3 reporting output over time

o   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. 

In this example:

Purpose of a Deviation System:

  • Recognizing and resolving deviations from routine operations

Purpose of a CAPA System:

  • Correct and Prevent operations deviations, AND Continually Improve the Operations Environment

Larger Purpose they serve together:

  • Efficiently produce product that meets all Quality Specifications, at the lowest possible cost

Constraints (on the process):

  • We cannot identify appropriate CAPAs for a deviation until the Deviation Investigation process completes successfully.

Limits (of authority):

  • We cannot implement those CAPAs without interacting with the Change Management System
  • We cannot release product affected by the deviation event after the implementation of the CAPAs until the Change Management process completes and without appropriate interaction with the Lot Release System


It seems simple enough….

However, as systems thinking is not the natural human condition, identifying and evaluating existing systems, or creating new ones,  is in itself a complex process and has its routine 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 blog will highlight a few of the universal challenges that we believe readers will likely recognize.

Acknowledging the existence of these challenges, and seeking first to understand them, is how we begin to move toward the implementation of systems that are capable of ensuring that Quality is built into every phase of the product lifecycle. 


Challenge 1: Systems That Aren’t Visible

Systems themselves are not always easy to see and, often times, their boundaries, constraints, and limits are even harder to see.  One of the largest challenges we see on a fairly regular basis is the difficulty people have in recognizing the system they find themselves interacting with, and seeing that system’s relationship to other systems. 

Not recognizing that we are interacting with a system can lead to the assumption that it is safe to treat an occurrence as a single event.  And even if we do recognize the system we are in, but we don’t recognize the need to interact at a point in that process with another system, we stand a great chance of exceeding the system’s limits of authority or violating the constraints that were 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 always see straight lines.  Systems require that we think cyclically, that we seek to identify non-linear relationships, and interpret 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. 

We can simplify a system to make it visible and understandable,
however, we cannot linearize it to make it predictable.

And we wouldn’t want to – because systems have to be adaptive – they must be able to deal with the non-routine – the unpredictable. 


Challenge 2: Systems That Aren’t Good

We have all seen the value of pro-actively 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. 

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

If the workforce complies consistently with components of a poor system, what is achieved?
Consistently poor quality.

Challenge 3: Systems That Don’t Improve

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

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.

Simply put, systems must be designed such that they recognize and interact with complimentary systems.   Boundaries between them must be clear, purposes must be aligned, and points of interaction must enable constraints to be imposed and provide limits that are difficult, if not impossible, to exceed.

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 actually occurred. 

Beware of this, because system thinkers know that:

We can’t always expect to see our cause and effect in the same space and time.

Analyzing system data shows us that cause is far more cyclical than linear, and finding a straight line between our fault and our cause will rarely, if ever, be the case.


How do we cause Quality? 

We implement Quality Systems that are visible and have been designed to include:

  • Boundaries (with constraints and limits)
  • Interrelated Components that use input and provide output
  • Critical Relationships, at appropriate points in time, with other systems


And 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, we at Coda believe that the following are inevitable:

  • Efficiency improvements
  • Real time control of operations
  • Consistent customer satisfaction
  • Quality product
  • Sustainable operating and profit margins

We hope that Mr. Borawski happens across this blog, and uses his considerable audience to ask a new question in 2013.

“When you attempt to meet your definition of Quality, do you use System Thinking?”

Coda will provide his first answer:



© Coda Corp USA 2013. All rights reserved.




Gina Guido-Redden

Chief Operating Officer

Coda Corp USA

[email protected]


“Quality is never an accident; it is the result of high intention, sincere effort, intelligent direction and skillful execution. It is the wisest of many alternatives.”



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>