Archetypes of Systems
Introduction
We live in a world of millions of variables, billions of people, and trillions of possibilities. Yet despite all these variables, people, and possibilities, we can reduce the number of symptomatic descriptions to 10 basic models, or archetypes.
Yes, 10 basic systems models. While a system contains different variables, products, people, languages and many other factors, those differences are not important to the definition of the underlying structure of the system, of how the variables work together. The basic models have existed from the dawn of time, before our ancestors crawled out of the primordial soup. Examples of the models exist in nature. Surely, some of our earliest human ancestors recognized the patterns that appear in life, and started to develop a way to communicate ideas about what they saw.
The models are man’s definition of the patterns that are visible in nature. The effort to define these patterns is ancient, dating to the days of Plato and Socrates. Plato’s Theory of Forms (ideas) is some of the early fundamental work behind the systems archetypes. My aim here is not to teach philosophy, but to highlight that these archetypes are the distillation of the ideas of perhaps millions of people. I did not create the archetypes. The archetypes exist in many books and publications. What I do here is present unique examples to help you better understand how the models work, how they go wrong, and how to get them to go right.
So what is an archetype? Archetypes are patterns of behavior that can be copied, repeated, and used to prototype other behavior. A systems archetype is the behavior pattern of a system. The most basic concept is cause creates effect; that is, the effect is the feedback loop of the cause.
Over the past month, my articles have used a series of diagrams to illustrate concepts. These feedback loop illustrations helped define the systems in that part of the story. These causal loop diagrams help define the systems in motion, illustrating the efforts, the influences, the actions, and the reactions in the system. The looping patterns illustrate the feedback-repetitive nature of the system.
While many of us with industrial engineering training know how to draw out complex process flow charts, and many of us who practice know how to draw value-chain process charts, we will not find many causal loop diagrams employed in lean-process projects.
My Own Use
I don’t remember when I started to draw causal loop diagrams. I know that I was drawing cause-and-effect loops in my electronics coursework in college, and using feedback loops to help develop ways to improve my film processing in high school. Eventually I started to use cause-and-effect loops to help define the processes inside a distribution center.
The first real project for which I remember using causal loop diagrams was in the late 1980s. For this project, my team used loop diagrams to help identify the root causes of repetitive motion injuries and carpal tunnel syndrome (CTS) in a large distribution center. In our initial work, we focused on ergonomic factors, such as the weight of the objects, the motions used, and the position of the hands. We considered physiological factors, such as the general health of the employees — their weight, and whether they smoked or were on medication.
Investigating the data, we noticed that about half of the claims involved a single doctor making a CTS diagnosis. While the risk management team investigated this angle, the IE team spent time on the operations floor watching the work. About half of the claims were concentrated in a picking operation, while the rest involved various non-picking jobs around the warehouse. Part of our routine included having conversations with the people we observed, not only to tell them what we were doing, but also to gain insight into what they thought about the work and the operations. Our IE team got an earful from the non-pickers, who savaged the upper management team of the DC.
A few weeks into the fieldwork we started to understand that the high rate of CTS claims was an indicator of a much larger problem. In our interviews and meetings with the DC managers, we found in the managers a surprising animosity toward the employees on the floor. A few managers spoke openly about how they thought the CTS claims were bogus, and how the employees wanted to make trouble for management. The managers danced around the issue of unionization (this was a non-union operation), showing their fear of the issue.
The corporate HR department brought in an outside consultant who agreed that some of the CTS claims were legitimate. In his opinion, however, the majority of the claims arose from incorrect diagnoses. That consultant reported his opinions to our team, and then in a formal report to the corporate VP of HR, putting more pressure on the DC management team, fueling the DC managers’ arguments that the employees were out to get management.
As part of the IE team, it was clear to me that there was more than one cause. It became clear to us that a specific group of pickers were in pain. This group had made the first claims. In these cases, the employees' personal doctors diagnosed CTS as one of the potential causes of their pain, along with tendonitis, arthritis, and “tennis elbow.” The tennis elbow diagnosis led our ergonomics consultant to tell the IE team a story at lunch.
A man comes into the doctor with pain in his bicep, elbow and lower arm. While examining him, the doctor asks the patient about his activities — does he play tennis, racquetball, or squash? The patient does not play any sports. The doctor asks about work, and learns that the man works at a desk all day, in a job that would not cause this kind of pain. In exasperation, the doctor asks the man if he masturbates. Sheepishly the patient answers that he does. The doctor asks how often, to which the patient answers several times a day.
The doctor’s prescription: switch hands. Use the left hand every other time.
Right after that lunch, we went to the tapes and the motion study data we captured. In our process, we used video cameras to record our observations. We set up a cameras in the work areas and recorded each area for the same two hours while we engaged in other observation activities. We could later watch the tapes to perform timings, to figure out what products the workers handled, and establish a pacing for the observations. Setting up multiple cameras allowed us different views of the same work area, or views of different areas in the same time span. From the tapes, we learned that the workers used their right hands for almost 90 percent of all motions. We also found the root cause of our real CTS claims.
But what about our not-so-legitimate claims? That afternoon the IE team drew causal loop diagrams on the white board, for both the real and the suspect claims. As we drew more of what we observed, we started to see patterns emerge. With the HR consultant’s report in hand, we drew in the actions and reactions between DC management, Corporate HR, and the employees with the suspect claims.
We saw examples of shifting the burden, escalation, and fixes that fail in our diagrams. It became clear to us that there were two different problems: one real CTS problem that the IE team could fix, and one morale problem that management would need to fix. The management team was partly right; the CTS claims outside of the pick module were an attempt to get attention, but not to get management in trouble. The other areas had ergonomic issues, just not CTS. But the real issue was the relationship between the floor and the operation manager for the area, not the ergonomics.
What’s Next?
Understanding the 10 basic systems models is a form of pattern recognition. If you can recognize the pattern, you can detect the early warnings that people in the system give you, alerting you that the pattern exists. Knowing the archetypes, you can prepare and practice tactical actions that help others see the patterns, the first step toward a solution.
Articles in This Series
Call Us! 877-674-7495 info@dksco1.com