Introduction
This is a short book about taking the step from preparation of a workflow map to producing a dynamic model of one or more processes. An appropriate place to start a volume like this one is to examine the state of our knowledge. We can begin construction of a dynamic model of our company or organization from nearly any state of prior preparation— we may have done a preliminary workflow analysis and decided that more thorough investigation of a process is needed, we may have already changed the workflow process because there was a glaring need to do so, or we may have done nothing. Ideally, I would prefer the situation where we have done a Workflow Mapping and Analysis (WFMA) project using the Kmetz method, of course, but that often will not be the case.
In most of what I will present in the following chapters, such a WFMA project will be assumed to have been done, so that we have some preliminary knowledge of how a process is constructed and what role tacit knowledge plays in it. The absence of that information, however, does not prevent moving ahead with modeling—it only prevents us from having a broader range of variables to investigate at the beginning of our effort. Ultimately, we will be very likely to end up with the same understanding of the system.
This chapter will focus on several examples of early modeling efforts that I either learned of, was involved in, or both. In reviewing these, I hope to persuade the reader that there is great value in system dynamic (SD) modeling, and that the practice of it can yield great rewards.
Much of what is presented in this volume draws heavily on other sources. I have chosen this approach to achieve two results: one is to make some of the most important points that other authors have made in very succinct terms; the other is to acknowledge the significant work that has already been done in the field, to encourage further study and mastery of it by the reader.
The functioning of the human mind has long been a source of fascination and study by many observers. One of the most important things learned in this quest is that humans tend to use a “simplified model of reality” in conceptualizing the world.1 This is not necessarily a bad thing, in that it prevents us from having to evaluate every sensory input we receive from the environment around us, and thus literally prevents us from experiencing “paralysis by analysis.” But a cost of this simplification is that we tend to be very poor at conceiving and dealing with more complex models, and this has been noted by dynamic modelers many times;2 we will return to this point presently.
Early Simulation Modeling Awareness and Experience
The Curious Case of the Old Saturday Evening Post
One of my first and most influential encounters with SD modeling came in late 1976, when I discovered an article written a few months earlier by Roger Hall.3 This was a major breath of fresh air at the time, since I had become quite disillusioned with the status of the academic literature, and this article was in an academic journal, Administrative Science Quarterly.4 In this paper, Hall described his research on the demise of the old Saturday Evening Post, a magazine which was once among the top three magazines in the United States, had a wide following and readership, and traced its origins to the Pennsylvania Gazette, first published by Benjamin Franklin. My parents had a subscription to it for many years, and I remember reading it as a boy.
His initial observations about the demise of not only the Post, but also several other similar magazines were enough to hook me:
Considerable interest has been generated in the plight of the large publishing firms. For instance, the Curtis Publishing Company was eclipsed in 1969 with the death of the Saturday Evening Post after a series of panic measures that included canceling subscriptions to reduce production costs (author references). The Cowles Communications Inc. announced a planned reduction in circulation and advertising rates of the Look magazine following a period of financial loss (author reference) and stopped publication in 1971. A similar move was made by the Time Inc. over its magazine, Life, following a poor reported financial performance (author reference) before Life also was discontinued. Conflicting reasons have been given for the demise of these magazines: competition with other media, such as TV, sharply rising printing and postal costs, substantial increases in the cost of acquiring additional readers, lost touch with readers, erratic behavior of advertisers, and plain bad management (author references).
At the time of its initial crisis, each of these magazines reported its highest circulation and largest revenue. There must be an explanation for such a paradoxical situation wherein a record circulation and revenue is associated with poor profit performance. It is hardly credible that a large number of the leading magazines were being mismanaged simultaneously. These magazines continued to grow in spite of keen competition with other large circulation magazines and other mass communications media until they reached a critical point in their history. This suggests that the pathology of magazine publishing is, perhaps, a complex phenomenon.
Hall’s investigation of the demise of the magazine would not have been possible without SD simulation software. In the next several pages of his paper, he described the development of his model and the use, at the time, of Dynamo, a dedicated SD programming language, to assemble it. There were four clusters of variables in the model: (1) accounting information flows; (2) measures of performance; (3) managed variables; and (4) relationships with the environment. Interlinking all of these were feedback loops, and as Hall noted, “Complex systems with many feedback loops can give rise to counter-intuitive situations, whereby the intuitive judgmental decisions made by people in the system may, on occasion, not correct an out-of-control situation and may even make it worse ….” (Readers of Volume I of this series should immediately recognize some of these terms and concepts.) He then went on to test the model by both validating the assumptions the model was built on, and demonstrating that it could produce measures of performance consistent with the past history of the magazine for the last 20 years of its life.
We should note that many of the variables in the model, in fact most of them, were not under control of management decisions. The management knew the measures of performance, which were (1) relative growth of revenue; (2) the profit margin; and (3) the relative growth of readers. Management could also control its managed variables, which were (1) the subscription rate charged to subscribers; (2) the advertising rate charged to advertisers, and (3) the circulation promotion expense. Two additional variables in this group were largely determined by standard industry practice, and therefore not under immediate control of top management: (4) the advertising selling expense, and (5) the magazine volume in pages per year. The latter two variables could be changed if management felt the need to do so, but would likely trigger retaliatory changes from the industry, and thus were treated as highly constrained.
Having created and validated his model, Hall then embarked on a series of experiments to see what would happen to the Post under different conditions for a simulated period of 20 years of operations. These experiments yielded a series of unsustainable declines in the profit margin, with increasing rates of decline after 10 simulated years. In all cases except the final experiment, where the lessons learned from the first experiments were applied as management decisions, the magazine failed.
What was responsible for the failures? In short, what was discovered was a positive (“hot”) feedback loop in the variables influencing the number of pages in the magazine, and hence its cost, to the number of readers; the “hot” designation means that the loop feeds back upon itself, so that change is exponential, not linear—growth in readers caused rapid and increasing growth; similarly, decline in readers led to rapid and increasing decline. Neither this feedback loop nor the relationships with managed variables, which they controlled and which affected it, were directly visible to management. Further, since the loop caused exponential change, immediate reaction to the managed variables would have only limited effect on performance measures, and the much greater changes were lagged and did not come into effect (or become visible) until years later. Those lagged changes then came as a great surprise, usually leading to an overreaction by management, and unintentionally setting the stage for the next disaster.
In his final experimental run, Hall held the subscription rate and circulation promotion expense constant, but adjusted the advertising rate per thousand readers each year to hold it constant. This is not an intuitive strategy at all, and requires a deeper understanding of the complex relationships in the industry, the nature of the hot feedback loop, and the time lags inherent in the impact of changes to the managed variables on the performance measures. The net effect results in a profit-maximizing system behavior rather than a revenue-maximizing behavior, and if it had been followed, the Post might have survived.
This was not a one-time event. Hall used his methodology to more broadly investigate policy failures in general, and specifically in the Manitoba curling club, Canada.5 In the latter case, his work was able to illustrate the causes of decline in the club membership, suggest options for change in club rules and memberships, and became the basis for the club managers to make significant changes that resulted in revitalization and survival of the club. The detailed report he produced is required reading for all new club directors.
A fundamental point, and one that I will repeat many times, is that one of the major purposes of modeling is to learn from it. Hall’s work, and that of many others in SD modeling, shows the potential for such modeling to enable that result. It does not guarantee that management will make the right policy decisions—the right to fail is not excluded by such efforts. But if we assume that most managers who take on control of an organization do not intend to fail, modeling becomes a powerful tool to help them learn how to achieve that.
The problem with the development of SD modeling software, up to this point, was that while it had become somewhat easier to master, it still required some major effort to learn, and was beyond the reach of anyone not interested in becoming a specialist. I had the good fortune to meet Roger Hall at a conference in West Berlin in 1978, and we talked about that; he admitted that while the Dynamo language made programming SD simulations easier, it was not, in absolute terms, “easy.” In fact, truly “easy” may be too much to expect, but we have come much closer in the nearly 40 years since that time. We will expand on this issue presently.
Modeling the Naval Avionics Maintenance Workflow
My next major engagement with SD modeling came as an outgrowth of my U.S. Naval Air Systems Command (NAVAIR) study, which began in 1976. Described in more detail in Volume I, that study was concerned with the apparent failure of the Navy’s Versatile Avionics Shop Test (VAST) system to meet its performance expectations at sea, and keep the Cold War Naval Air Force in a state of operational readiness. When aircraft carriers went to sea and began running regular air operations, the on-board stocks of major avionics components that VAST was supposed to maintain were instead quickly depleted, meaning that a large fraction of the air wing was not operational (often approaching 50 percent on some ships). The VAST shops began to accumulate large backlogs of repairs, and it seemed they could not keep up with demand. However, when examined closely, VAST was found to not only be meeting but exceeding its performance specifications: whether evaluated on Operational Availability (uptime); Mean Time Between Failure; Mean Time Between Unscheduled Maintenance Actions; Mean Time to Repair; or any of a large number of more specific measures, VAST was working well. Not only was this a major conundrum, but it was a grave concern to the Navy.
I became engaged in this study during my time with the University of Southern California’s (USC) Systems Management Center, and my initial role was to evaluate the Navy’s management practices in the VAST repair cycle. Having studied a number of works on systems theory and information processing in organizations,6 I began by analyzing the flows of information through the system, in addition to practices of general management.7 NAVAIR managers soon realized that the problem was bigger and more complex than they had realized, and my role was changed to be a “floater” who had license to go anywhere in the maintenance system to investigate possible causes of systemic problems.
In this capacity I soon met John Gray, who was not only a graduate of the USC program I taught in, but was in charge of a particular unit at the Patuxent River Naval Air Station. That unit was named the Aircraft Intermediate Maintenance Support Office (AIMSO), so named because it sounded rather like a third-tier staff office that had little role in operations and was therefore not a threat to anyone’s career or other aspirations. In fact, AIMSO was a creation of the Chief of Naval Operations (CNO), who had become so frustrated with the conflicting reports on VAST that he basically trusted no one in the line Navy; AIMSO was therefore tasked with getting to the bottom of the problem, reported directly to the CNO, and was exclusively accountable to him. John Gray and I were both believers in systems theory, and immediately became sympatico.
A large part of my work during this period was to statistically analyze data on the functioning of the VAST shops. The Navy had never done this, and also had never developed any standard times for individual component repair; thus, there were no data to allow either relative or absolute comparisons to a standard. Through the statistical analysis, we found that many of the components were processed in a relatively short time, but that for a variety of reasons some took much longer, and several components were consistently “bad actors” in terms of ease of troubleshooting and repair. The immediate benefit was that we were able to set limits on the time that a component would be allowed to “cook” on a VAST station, and if repair was not effected in that time, the component was removed from the station and another put in its place.
In my “floater” role I had found several instances of both Navy and civilian personnel taking initiatives to resolve informational problems that had been found to create difficulties in managing the VAST workflow.8 While working with John Gray and AIMSO, we were able to communicate directly with these individuals and begin to assemble what they had learned into a larger model that could encompass all VAST operations, and when that was achieved, be able to optimize them. While I did not have to program any of my inputs to this system, I was able to add what I had found, and some of what I suspected, to the model.
Many of those inputs were the kind of system feedbacks that Hall had found in his work with magazine publishing, that is, feedback loops that were not fully understood or appreciated in terms of their effects on performance. Given the objectives of the AIMSO work, these were mostly focused on small and subtle feedbacks that collectively had significant impact on VAST production. For example, lengthy item codes for replacement parts had to be entered onto a five-part shop data-collection form; these could be entered mistakenly, or simply be not legible for those who had to work with part five. The AIMSO model automated this process, and also accumulated an exhaustive listing of parts used for all VAST repairs, so that if a sailor mistakenly transposed two figures for a part, the terminal would not accept it and would force correct data entry; this had immediate benefits in terms of properly maintaining spare-parts inventories as well as correct data on which parts were actually involved in a component failure. In another case, tracking personnel training through the model to ensure that every shift was staffed with personnel having both VAST maintenance skills and component repair skills reduced the already low amount of VAST downtime even more, which meant production stayed up. This also helped identify training needs and improved the overall skill level of the VAST shop. Discovery of one feedback often led to successive ones—personnel whose training had not been successful were identified and retrained to prevent errors of component diagnosis, maintenance diagnosis, or even things as mundane as the care of cables. These effects were cumulative for both the carriers and shore sites, since carrier crews regularly rotated through the U.S. shore-based VAST shops when a cruise ended, and thus still another feedback that enhanced VAST performance was uncovered and exploited. Success quickly fed back to create further success.
While the effect of many of these individual feedbacks was small, their cumulative effect was major. By the end of 1983, the maintenance-workflow model that resulted was not only able to prevent VAST from becoming overloaded, but enabled it to expand its workload, so much so that when President Reagan decided to build five new aircraft carriers, it was not necessary to restart the VAST production line. VAST stations were taken from other sites and carriers where they had become redundant and placed on the new carriers; this saved, in 2016 terms, between USD 800 million and 1.2 billion.9
Programming, however, was still a specialist activity in the early 1980s, and a task of this magnitude required a relatively large group of programmers to code and document the program. Since this was a military application, documentation was especially important—the assumption was that if key personnel were lost for any reason, documentation would allow anyone with reasonable programming skills in that language to learn how the program worked and keep it going. Microcomputers had only begun to be available, and their ubiquity in the workplace was not yet established.10
Simulating the Naval Avionics Maintenance Workflow for the Next Generation of Testers
Following the work with AIMSO, I next supported the original VAST contractor, Harris Corporation, to help develop a model of the VAST workflow as part of a proposal for the successor to VAST, the Consolidated Support System (CSS). The Navy had now learned that its avionics repair process was much more complex than they had initially believed and, as a result, required all contractors who wanted to bid on the CSS project to develop an SD model of the repair process and operate that model with a Navy-supplied set of test conditions. Failure to successfully operate the model would be taken as evidence that the contractor did not understand the workflow, and would therefore be disqualified from bidding on the CSS contract.
The Navy test consisted of a visit from a team of knowledgeable test and logistics personnel, both Navy and civilian, who would visit the bidders sites and present them with several scenarios that could occur on a carrier under conditions of full operations. Three days were allowed for the tests to run, and model outcomes were then compared to the results of a secure Navy model as well as to the judgment of the team, using a standardized scoring rubric. Two teams of five companies and one of four competed in the SD modeling phase.
The Harris modeling effort was headed up by an extremely capable mathematician and programmer. As before, the program had to be documented extensively to meet military specifications, and that took as long, or longer, than writing the code. This model was written in FORTRAN, which was very compact but required considerable time and effort to learn if one was to be proficient.
In this effort, I was responsible for providing guidance to the programming team regarding actual operational practices and variations in them. In my earlier work with NAVAIR, I had visited seven shore sites and seven carriers on both the Atlantic and Pacific coasts, and had become very knowledgeable of how VAST shops operated; no two were the same, and only one strictly followed the procedures prescribed by the Navy. I worked with the programming team to inform them of various conditions they might encounter in an operational environment, and these were built into the program as it progressed. We now understood the importance of the feedbacks in the repair system, including many that went beyond the immediate avionics repair cycle itself, and these were incorporated into the SD model.
Unlike the AIMSO program or any of the individual partial models that contributed to it, the models developed for the CSS proposal were required to be comprehensive of the entire repair cycle, and flexible enough to respond well to what would now be called “stress tests.” The AIMSO model was developed to manage VAST and several other electronic testers successfully as they were now deployed, and while it had many dynamic properties, it was better conceived of as a major decision support system. In contrast, the CSS proposal SD models had to assume some design differences in the testers themselves, based on Navy information given to all potential bidders, and be prepared to cope effectively with the temporary loss of some test and repair capabilities during the run. This was a more difficult job than modeling a system already in place that had been operating for nearly a decade.
When the model was built and the test team arrived, the modeling team was understandably tense about the functioning of the SD model. They had essentially been working in the dark about several aspects of the operating environment, and it is not in the nature of programmers to simply unleash a program without testing it first. That, however, is what had to be done. The short version of the outcome was almost anticlimactic— the model ran, the results were very much in line with what both the team and the Navy personnel expected, and there were no bad surprises. After an exhausting three days, the model had achieved what it needed to do, which was to establish the credibility of Harris to bid on CSS. The actual proposal effort was still months off—it was August, so we all went to the beach with our families to recover.11
I was very impressed with the SD model the team had built, and pleased that what I had learned about the VAST workflow processes was able to contribute to the next generation of testers through support of the model builders. But what impressed me most was the ability of SD models to capture, manipulate, and test the essential variables in a system, such that when one identified the causes of variation, whether individual variables or the relationships between them, those could be identified with confidence. Even those with enormous operating experience often did not see these relationships and typically singled out those variables that were most familiar to them, whether they were the actual cause of the problems or not. Hall’s discovery of a hot feedback loop in magazine publishing, operating exponentially over the years and unseen by management, was never far from my mind.12
Two types of feedbacks factored importantly into the dynamics of this simulation. The first was external to the avionics workflow that CSS would take over, and included “soft” variables such as the belief that avionics repair failures would increase the degree of cannibalization of other avionics in the repair queue. This was a thorny problem, affecting everyone involved in the repair system; first, if squadron maintainers, the first people to detect a failed component on an aircraft, believed that a spare part might not be available when demanded, they would hoard such components themselves. While contrary to Navy rules, this behavior would nevertheless keep aircraft mission capable in the short term, but at the cost of holding these components from the repair system, under-reporting the level and frequency of failures, and delaying demand for spare parts for the components. Second, within the repair cycle, those in charge of holding components awaiting parts were constantly under pressure to allow held components to be cannibalized for their parts, on the assumption that future replacements were homogenous (they often were not), and again reporting false data into the system. The false data were a problem in their own right—for a service like the Navy, operating worldwide, accurate data on repair demands was essential, even though the locally optimal decision to fly aircraft now and report maintenance needs later was always compelling. At the height of the perceived VAST problem, this behavior reached such extremes that the first aircraft to fly onto a deploying carrier were pushed into a corner of the hangar deck and immediately torn apart to build the stock of spare parts; these poor aircraft did not fly again until the carrier returned to port, and were referred to by the moniker “hangar queens.”
Applying SD Insights to the Royal Canadian Air Force
This knowledge of dynamic feedback relationships became key in 1990, when the Harris Corp. was contacted by the Royal Canadian Air Force (RCAF) to help them resolve an apparent performance problem with their avionics testers. The RCAF had replaced a Cold War mixture of fighter aircraft with the (then) McDonnell-Douglas F/A-18; this was a U.S. Navy design, and its avionics were supported by a tester which was an advanced generation of VAST (and known, not surprisingly, as mini-VAST, even though its official designation was the Automatic Test Shop Version 1, or ATS V1). The RCAF had begun to encounter the same backlogs of components whenever it operated at or near its theoretical maximum of sorties—ATS V1 appeared unable to keep up. I was asked to go to Canada and examine their operations, and author a guide to avionics shop operations and turn it over to the RCAF.
I did this, and in 1991 we convened the logistics managers of the Canadian Forces at the master jet base at Cold Lake, Alberta, and I spent several days going through my findings and recommendations. During a tour of the avionics maintenance facilities there, a repeated plea from the military personnel was for more spare components and parts; this was sufficient to persuade two of the logistics managers in my groups that the real reason for the backlog accumulations was lack of spares, and that my effort had been for naught. By explaining relevant details of the Harris Corp. and AIMSO models, I was able to show them why they needed to focus on the true causes of the backlogs and deal with those. In our earlier research, we had learned the importance of prioritizing components in the repair queue, and the impact this had on performance. Most importantly, the Canadians needed to define their pool of spare parts as not only the components in inventory, but also those deployed on operating aircraft, plus those awaiting maintenance in the repair queue; when a failure occurred on an aircraft, that information had to be entered into the system immediately, not when the component arrived at turn-in for failed items. In the end, the model demonstrated the value of being able to look at a system not only from the level of its details (the shop), but from a higher level as well (the system). Using both, the impact of intangible feedbacks like repair prioritization and the scope of the component pool became visible and appreciated.
All through this period of experiences with SD models, I was both fascinated and frustrated. On the one hand, seeing the potential for models to enhance learning about systems I had examined was fascinating, to say the least. The potential to experiment with variables and find out what happened to a system under different conditions was tantalizing and stimulating. At the same time, these possibilities were a source of frustration—I had, for example, acquired a hard-copy version of a model that was a competitor to the AIMSO model. This was purely experimental and was focused on the immediate needs of the maintenance system with its currently installed hardware, but was also built to allow exploration of changes in testers. It had been developed by the Naval Air Engineering Center shortly after work on the AIMSO model had been given full support for development. Partly because of that, it never achieved much visibility or use in the Navy. I had attempted to use it for a university-based research model, but it was written in a version of the Pascal language that was not supported on my campus. Given my international and other commitments on campus, I was never able to get the model running, nor did I have time to concentrate on the language so that I could learn it in sufficient depth to operate the model on my own. This was the problem at the time—one could do this kind of work, but only if you first learned Fortran, SLAM, Dynamo, or any one of a large number of computer languages first; and since many people in industry, like me, had other priorities, this simply never happened. The potential for modeling remained just that—a future potential.
Software Evolution
When the microcomputer revolution began in earnest, many of these frustrations were also being felt by others in the SD modeling community. Whether it was users who wanted the ability to write and run models on their own machines (a good way to spend time in airports, for example), or simply observers like me, who could see the possibilities for such models but could not devote the time needed to create them, genuine efforts to develop user-friendly languages began; the software needed to create such models underwent major evolutionary changes. With the advent and wide scale adoption of microcomputers in the 1980s, software began to be developed to run on these.13 Within roughly 10 years, iThink software was first published and made available to the public.14
The examples and discussion of software components focuses on the iThink program for the remainder of this volume. The breakthrough with iThink was its ability to translate graphics into equations. The “graphics” have to be drawn by a set of rules that are interpreted by the program to write the equations. Anyone with adequate knowledge of the mathematics underlying a model can easily open an “equations” window and manipulate the mathematics directly; those with little or no mathematical training, however, can just as easily cause the correct equations to be written by drawing adequate pictures of the process and following the rules of the program. iThink places as much importance on the modeler’s ability to envision relationships as to explain them mathematically.
This dramatic change quickly enabled the growth of users from many arenas, including those interested in using a general-systems approach to learning. iThink, and its close counterpart Stella, quickly developed a global following and have generated a set of global partners to implement dynamic modeling and systems thinking more generally.15 The iseesystems.org website offers a full range of products and support, and for those inclined toward a tryout, there is a save-disabled version of the iThink software (along with Stella and Stella Professional) available for download on the website, each of which operates for 30 days. We have considerably more to say about iThink in Chapter 2.
The current development in this software is XMILE, which enables iThink to integrate “Big Data” sets in the formulation of models. This is a development effort with OASIS (Organization for the Advancement of Structured Information Standards), the international open standards consortium. Since this gets into technical matters that are not in the purview of this book, I will leave it for interested readers to pursue the development of software on their own.
The Importance of Systems Thinking
One of the most important lessons learned from these experiences and my continuing study of systems theory is the importance of systems thinking. When one begins to work with SD modeling, systems thinking becomes both a necessary precursor to it and a product of it. Mere recognition of feedback loops and their multiple effects on the structures where they are found has effects on the way we see the world—what modelers often refer to as our “mental model.”16
I refer to systems thinking as both a precursor and a product, which it is. The reason for this dual identity is that there is a learning process involved in becoming able to see the obvious, and when that happens, it also produces changes in the way we envision many things around us. When the scales fall from our eyes, we realize that many of the factors that we consider to be causal to other factors are both cause and effect; that many of the things we see as linear are not; that many of the factors that act on other factors are interdependent, not independent; and more. Initial realization of these characteristics of reality open our eyes to still more, and forever modify the way we think about the world—our mental models are forever changed.
How important is this? Richmond has suggested three primary reasons for the flaws that exist in our mental models.17 First there is the content of them, which Richmond attributes to our early development as a species, and the need to pay attention to the immediate environment and the here-and-now events of the day. Failure to do so was failure to survive; survive we did, but we now have many embedded filters constantly screening information for its relevance and significance. This implies that boundaries are also placed around our information so that where we look is as constrained as what we look at. The combined effect is that we have a difficult time gaining access to the content we need to improve our mental models.
In the context of organizational decision-making, Simon argued that we are limited by “constrained rationality”;18 the constraints are three. First, we can only learn what we already know—we have limits placed on us by existing knowledge, so that going too far from our current information is very difficult for most of us because we have no way to bridge the gap between what we know and what we are trying to understand. As Arthur C. Clarke put it in his Third Law, “Any sufficiently advanced technology is indistinguishable from magic.”19 Very few human beings have the ability to escape these limitations to their rationality.
The second form of constraint that Simon identified was what he termed “reflexes” or “reflexive knowledge.” This is knowledge that is ingrained, embedded, practiced, and automatic. We have all had the experience of driving somewhere familiar and suddenly realizing, probably with a start, that we have no recollection of the last 30 miles; we have literally been “on autopilot” while processing some other matter with our conscious minds. Examples of this kind of knowledge abound, and it is arguable that we could not cope with daily events if we did not have a large stock of exactly this kind of information. Nevertheless, this also places limits on our ability to rationally extract information from the environment around us.
Finally, Simon argued that our values also constrain our ability to think rationally. Values, of course, place conditions such as rightness, morality, propriety, and others on information, and thereby limit our ability to process it neutrally or objectively. Given the nature of values, the limitations not only affect our own information processing, but make it difficult to work with others who do not share them.
An interesting study by Kampmann and Sterman confirmed many of the limitations of bounded rationality that Simon had articulated.20 In this paper, the authors used SD modeling to create both simple and complex environments in a simulated decision exercise, which had the advantage of allowing experimental manipulation of the environment. In brief, they found that particularly in complex environments, decision makers failed to see feedback loops and the dynamic properties of the decision variables, and that while market information tended to moderate misperceptions of feedback, they did not eliminate it.
We are thus constrained jointly by all three of these forces, and whatever content enters our personal mode of information processing must get through all of them. It is easy to see how these were functional for survival, and continue to be so; however, they form impediments to our acquisition of knowledge in many ways that are peculiar to the individual, and keep us focused on the immediate and local rather than the long-term and systemic.
The second of Richmond’s impediments to systems thinking is the way we represent the content that we include in our mental models. These reflect the “meta-assumptions” that are often submerged in our consciousness, and until we can force them to the surface we cannot deal with them. The two most common meta-assumptions are that factors producing an outcome of interest are independent of each other and act in one way, from cause to effect, in all cases. He illustrates the incorrectness of these through several popular management tools: Critical Success Factors, spreadsheet models, the popular Balanced Scorecard models, and “root cause” and “fishbone” diagrams. To this list, I would add many of the popular tools of Business Analytics courses and programs; while these are by no means standardized, most programs rely heavily on applications of relatively standard statistical procedures to big data.21 Linear regression modeling by any other name is linear regression modeling, and the potential to identify nonlinear relationships through regression is limited.
To these limitations, Richmond adds that we treat many “causal” variables as having instantaneous effect on outcomes, that is, that delays do not occur, and that the effect of such variables is not only linear, but linear and constant. Much experience from many aspects of life shows that these are simply not true—delays, especially, are a fact of life, and should be expected. We are aware of stimuli that “run out of steam” after a period of time, whether in the short term, like hunger; the intermediate term, like passion; or the long term, like economic returns versus quality of life. Yet we often fail to recognize these obvious truths when considering what the consequences of a change in a causal variable will be; the stock market, with its expectations of quarterly returns, is ample illustration of this.
Richmond’s third flaw in our mental models goes directly to this point—we do not have the common language or the tools to express what we can sometimes see, so we continue to create models that do not reflect reality. In particular, he proposes that while knowledge of details is necessary to construct models, we must also be able to back away and view the process of interest from “high altitude,” so that characteristics of the system not visible from the detailed level can be seen. He uses the example of a major highway system, where the view from the driver’s seat of a car stuck in traffic reveals very little, but from 10,000 meters we can see the cause of the backup and the response of traffic to it. This is the kind of insight that Hall found through his models,22 and that I was able to learn from putting my knowledge into the NAVAIR models. Richmond intends iThink to be a way to deal with these limitations and see relationships more clearly.
What Is “Simulation?”
I have referred to SD modeling, or simulation, a number of times in this chapter, and it is a good idea to explain exactly what it is before we leave it. “Simulation” covers a very broad range of activities, including things like disaster-training exercises, fire drills, and the like, and has long been used in engineering and the sciences, in the form of models and scale representations of physical objects, whether atoms or bridges. These simulations are often restricted to measures and quantifiable variables and the relationships between them over time. Computer simulations like these did not become feasible until roughly third-generation mainframe computers became available, in the 1960s and 1970s. In these early physical-system models, variables like employee motivation, innovation capabilities, and many other extremely important intangible properties of a system were either ignored or reduced to a limited approximation of the real thing.
That property has been entirely changed with present-day SD software. With iThink, we are no longer constrained to the objective, measurable properties of a system, but can investigate the impact of changes in both “hard-” and “soft-system” variables. The real difference between these variables is that the physical world can be measured, while the intangible world must be quantified. Given careful observation and thought, many of the important but intangible properties of companies and organizations can be part of an iThink SD model; the iThink modeling software has come a long way since the days of Dynamo.
The pioneer of present-day SD modeling is Jay W. Forrester, whom I have already referenced and who published Industrial Dynamics in 1961, followed by a series of books on systems theory and systems dynamics; he is widely considered to be the father of SD as a field of study. His publication of World Dynamics came at the end of this fruitful decade of work, and at the same time created major concern about the future of the planet, being written in an era when the Club of Rome had also published Limits to Growth, which made many dire predictions about what that future may be.23
Much of what Forrester accomplished during this era and later years was to bring the importance of understanding systems into focus while at the same time developing the capability of computers to model them. More importantly, what the computers enabled was the testing of our “mental model” of a system, as we discussed earlier. SD simulation, in its modern form, is capable of both testing and advancing mental models as well as a variety of physical ones. The advances in robotics, human prosthetics, self-guided systems such as drone aircraft and seagoing vessels, are all possible because of the increased power and mastery of computer models.
Validating SD Models
How do we know when a model is “correct”? This is a different question when put to academic inquiries, such as those by Hall or Forrester,24 as opposed to the models run for NAVAIR or for consulting purposes. In the former, the “what if” questions are typically asked in the spirit of discovery, often simply to know the answer; in the latter, failure to “verify, validate, trace, and test” a model may lead to serious policy failures and the consequent failure of an entire company.
Simulation is always caught between two opposing concerns, one of excessive simplification and the other of excessive complexity. One of the advantages of simulation models is that they allow us to take complex real entities and reduce them to their essentials, to then determine how much of the system’s outcomes and behaviors are due to those essentials, among other questions. If one attempts to add all possible variables to account for every source of variability in the system, the model then becomes complex and unwieldy, and so difficult to understand that even if it did produce accurate results, it might still lack credibility.
Experience with different types of simulations has shown that there are positive and negative outcomes that obtain to modeling. There is no question that simulations are generally cheaper, safer, faster, and more controllable than manipulation of real-world systems; in fact, they are often the only way to acquire insights into the behavior of many complex systems. The idea of the “long run” in decision making is untestable in the real world—there are many investment decisions that can only be made once, and if a negative outcome results, there is no future for a “long run” to happen. Simulations like Monte Carlo models, the use of Crystal BallTM to simulate project outcomes, and SD simulations are the only environments in which multiple trials of a potential decision that plays out over a long period of time can be evaluated. In many cases, such models are the only possibility of “replicating” outcomes like scientific and economic experiments.
At the same time, there are negatives associated with simulation, some of which are direct consequences of the fact that we can do them. The fact that simulation is the only source of information on the “long run” may convince us that any simulation result is an accurate substitute for real world results. We forget the ancient programming wisdom of “garbage in, garbage out,” and imbue simulation outputs with far more credibility than they deserve. The simplifications and assumptions necessary to build a model in the first place may be overlooked, and so what the computer does becomes “reality,” to the extent that disconfirming evidence from the real world is disregarded as incorrect when it disagrees with the results of the model. Such overconfidence in mathematical models was a major contributor to the meltdown of Long-Term Capital Management in 1998.
Nearer to the business world, the discipline of economics illustrates many of the problems inherent in the model-versus-reality versions of the universe. Economics has struggled with a major challenge over the centuries, which is how to explain the behavior of masses of producers and consumers in terms of presumably rational decisions and actions based on self-interest. From a basis of observation and insight, modern economics has evolved into an exercise in mathematics and modeling, requiring enormous energy and effort to yield results that appear to be consistent with the real world (so long as the word “assume” is allowed liberal usage in those explanations—I remember attending economics seminars with U.S. colleagues in Bulgaria in the early 1990s, and at the end of one of these one of the audience members said to me, with great exasperation, “I thought you Americans really knew how an economy works, but now I think that all you know is how to make assumptions!”). The economic and financial global meltdown of 2008–2009 shook much of economics to its roots, not least the redoubtable Alan Greenspan, who admitted to being “shocked” at the extent to which cherished assumptions about the nature of markets had failed to hold up. At the end of the day, this is a case where the mental models of economists, made tangible through computers and software, faced head-on confrontations with the realities of market behavior, and many of them still have difficulty accepting the shortcomings of their models.25
But at the same time, simulation may enable progress toward resolving essential questions about the mental models that describe many complex systems. One of the principal confrontations at present is the debate between economists who adhere to the rational model of economics and those who argue that actual human behavior does not follow the assumed rules of rationality in that model; the latter group are appropriately termed “behavioral economists.” Behavioral economics (and its close relative, behavioral finance) contends that human decision-making departs significantly from the narrow confines of pure self-interested rationality, and results in economic behavior that is often quite different from what traditional economics would predict. The mental model of the behavioral economists is very different from that of their rational-behavior colleagues, and it seems reasonable to expect that the contest between these schools of thought will be long and intense. The behavioralists point out that there is a long history of well-structured arguments to support their models. Recently, the recurring phenomenon of the economic “bubble” has become a focal point in this debate—in the mental models of many rationalists, there are no such things; in the models of the behavioralists, they are real and inevitable. For what it’s worth, my vote supports the behavioralists. As the work by Kampmann and Sterman shows,26 insights into decision making can come from application of SD models, which show that decision behavior in market economies is consistent with bounded rationality, and that inclusion of estimated rules based on bounded rationality reproduces key features of market dynamics.
The point of all this is that there is no simple way to resolve the problem of whether to believe a model or not. In many ways, the ultimate issue is simply the confidence one has in a model, and three tests are proposed for building confidence.27 First, one can test the structure of the model—are the variables in the model, the relationships between them, and the dynamic linkages in it consistent with what we observe in the real world? Deviations matter. Second, is the behavior of the model consistent with the behavior of the real system? Do the parameters of the model produce results consistent with time series and other data from the system? Third, do we learn from the model—do we gain insights from the model that inform us about previously unseen or unappreciated characteristics of the real system?
Aware of this, most commercial models used by consultants go through a rigorous verification-and-validation process; Coyle and Exelby report that the firm Exelby was associated with used 105 tests for this process. In contrast, academic authors may be willing to rely on much less stringent standards, in part because their interests are far broader than those of the consulting firm. Most of the readers of this volume will be nearer to the academic user in terms of objectives, and since their models will also tend to have smaller scope than those of a consultancy, general tests, such as consistency of structure and behavior, may be adequate. If unexpected outcomes and feedback relationships are discovered, that may be nature’s way of telling us to hire the professionals.
Summary
Let’s return to the beginning once again. This short chapter has introduced the reader to the next step beyond WFMA, and a step which will probably be part of the future for many forward-thinking mappers. That step is to use the static models of a workflow map as produced by the Kmetz method covered in Volume I of this series to prepare an SD model of the workflow. This is more than simply a minor progression from a workflow map for reasons we will see.
Unlike the WFMA methods we saw in Volume I, SD modeling is obviously a software-intensive undertaking, and is completely dependent on software support. Also unlike the mapping tools developed in Volume I, learning to use simulation software requires much more investment of time and energy, even though the software has progressed tremendously. The objective of this book is not to turn the reader into a dynamic modeler—it is to inform the reader of how WFMA enables taking the next step, that is, the potential to use SD modeling to test ideas about how things might transpire in a virtual mode, and thus illustrate the potential of simulation. If that appears to be the next step for the reader, it will also provide some initial guidance and ideas to do it. Going the full distance will require some additional reading and skill development.
For most professional readers, application of such dynamic modeling will have to be relegated to staff specialists or consultants. In this regard, this chapter is a departure from the norms of my WFMA method, but I am convinced that the future will see several types of dynamic modeling become as widespread as static modeling is now. Indeed, some of the complexity of business process mapping and related software packages is because these already include some elements of dynamic modeling. Ironically, I like that aspect of these packages, but I wish there were a clearer connection between process mapping as I think of it and simulation through dynamic modeling.
In the next two chapters, we explore some of the specifics of iThink SD modeling software. Chapter 2 reviews the main components of the program, and Chapter 3 offers some insights into how to apply these in an actual modeling effort. Chapter 2 is not intended to be a comprehensive account of either the components or their applications—rather, it is intended to give a summary inventory of them, and for those interested in applying them, some sites to visit and associated readings; I do not intend to duplicate those efforts here. However, I will give enough information on iThink that an interested reader will be able to follow online examples of rudimentary models. More advanced models will take more advanced study. Chapter 3 is a bit different, in that it provides a combination of ideas to start such an effort, and as such considers primarily the needs of beginning SD modelers.