Six Sigma and more: Systems thinking

David SchwinnDavid Schwinn ruminates this month about the impact of various historical approaches to systems thinking, and the ways that a robust set of perspectives lead to process and system improvement.

The map is not the territory…Alfred Korzybski

This column is a tribute primarily to a long-time teacher, mentor, colleague, and friend, Jamshid Gharajedaghi. My wife Carole and I recently visited our friend while in Philadelphia doing a presentation for the International Society for Performance Improvement on our new book, The Transformative Workplace: Growing People, Purpose, Prosperity and Peace (Minneapolis: Transformations Press Unltd., 2015).

Our journey in search of knowledge and skill around continual improvement, of course, began with Dr. W. Edwards Deming. He taught us about the Chain Reaction, the 14 Points, the Deadly Diseases, and Profound Knowledge. He also taught us how to quantitatively improve a system. We continue to think he knew more about how to improve a system than anyone. As we began our practice of trying to help others learn how to improve their own systems, we, from time to time, ran up against a system that was in such bad shape that it really deserved to be blown up and reinvented (think American health care and K-12 education in the 90s). While Dr. Deming acknowledged the importance of innovation as part of the tool kit necessary for transformation, he provided little help in being grandly innovative.

Carole and I went in search of someone who might help us understand how best to design or redesign a system rather than just improve it. We went to Peter Senge who added much to our knowledge of systems but hardly anything about design itself. We spent time with Gerald Nadler, a true systems thinker who also knew how to design or redesign a system, but were uncomfortable thinking about how to personally apply and teach his methodology to others. Finally, we shared our frustration with an old colleague from my days at Ford, Vic Leo. Vic suggested we contact Russ Ackoff. We did. Russ said he was too tied up in the immediate future to help, but that his partner, Jamshid Gharajedaghi, might be willing to help. We said WHO? We went ahead and contacted Jamshid and began a most wondrous nearly 20-year friendship. Jamshid and Russ had jointly created a technology called Interactive Design and Management. Jamshid taught it to us and helped us teach it to and apply it with several clients. Carole and I believe it continues to be the best technology out there for designing and redesigning a system. See Jamshid’s book, Systems Thinking: Managing Chaos and Complexity (Boston: Butterworth-Heinemann, 1999) for the best published summary of the details.

Before I continue, however, I must talk about systems because the word holds so many meanings. When I first went to school, systems to me represented mechanical/electrical feedback systems. In graduate school, systems became shorthand for matrix management. These days, it seems systems mean digital, data processing systems. Jamshid and Russ take a much broader view. For them and for Carole and me, a system is a set of interdependent components forming a complex/intricate whole. Furthermore, the systems Jamshid discusses are alive and social and have purpose, boundaries, inputs, and outputs. There is much more.

The most common examples of these systems are organizations, enterprises, teams, communities, departments, sectors, governmental bodies, and on it goes. Hopefully, you get the idea.

The first thing Jamshid points out is it is not possible to fully understand a complex social system. The best way to attempt to get a partial, yet useful understanding of such a system is to look at it from as many perspectives as possible. He and Russ offer a few.

Context

To begin to understand the context within which the system lies, we might, for example, ask:

  • Who are the stakeholders?
  • What are their needs and expectations?
  • Who are the competition and what are they up to?
  • What does the world that is holding the system look like and how is it changing?

Mission

To begin to understand the mission of the system, we might, for example, ask:

  • What purpose does the system serve for the customer?
  • What purpose does the system serve for all the other external stakeholders?
  • What purpose does the system serve for the internal stakeholders?

Functions

Beginning fulfilling the mission to the external customers and moving to fulfilling the mission to the internal customers:

  • What does the system do to serve customers?
  • What specific products does the system provide?
  • What specific services does the system provide?

Processes

Using a deployment or, in some instances, a more appropriate flow charting technique, describe, in detail, with special emphasis on actual rework, inspection, bottlenecks, and decisions (these four characteristics provide particularly pregnant opportunities for improvement), these primary processes:

  • Throughput
  • Decision-making
  • Control, learning, and improvement including what metrics are important to track and improve

Structure

Describe the system structure in these three ways:

  • What does the organization chart look like?
  • What are the system’s physical structures such as land, buildings, equipment, and tools?
  • What software is used and how is it used?

Dimensions

Five dimensions are generated and disseminated in any system. How robustly and widely are each of these dimensions generated and disseminated?

  • Wealth
  • Truth
  • Values
  • Power
  • Beauty including natural, built, celebratory, and connection beauty

These characteristics of a system are just a start, but they do provide a relatively broad and robust set of perspectives for describing, examining, and improving a system. Since they are all, obviously interconnected, I suggest you start your Six Sigma work by taking a brief look at these perspectives and any other you think relevant for the system you are attempting to improve. Use this little exercise as a way to further operationally define the boundaries of the system on which you are working. Unclear system boundaries are yet another common cause for failed improvement efforts. Once you understand what they are and how they interact, at least at a superficial level, then you can start the PDSA or DMAIC cycle.

As always, I treasure your comments and questions.