Through the process of developing a system dynamics model, the modeler has created a complex map of interrelationships and a better understanding of how the system will behave over time under different policy scenarios. One of the great challenges of developing models is in trying to communicate the insights gained to people who did not develop the model. Presenting a report to a manager of all the things he or she should do differently from what someone else has learned in a model works only if the conclusions of the model were what they were planning to do in the first place.
But a model can provide more than just bullet point conclusions, it can also be used to create a simulated "practice field" where these managers and other people can try managing the system by making decisions themselves. We call these simulated worlds management flight simulators. Through these simulators they can learn about the model of the system and improve their own assumptions about the short and long term effects of different decisions.
In a management flight simulator, users of the model are placed in the position of managing the system. Each year (or month, or quarter) they must make decisions to try to meet some goal in the system. To help with this, a snazzy interface is typically run "on top of" the system dynamics model that makes the information more accessible. Generally, there are four kinds of information presented:
Decisions - There are typically four to six key management decisions the user must make, using the knobs, dials, and/or input boxes presented on the screen.
Reports - They provide the critical "snap-shot in time" to inform the users about the state of the system.
Graphs - During a model simulation, time series graphs allow the user to study system trends. As discussed earlier, studying the shape of a system's time paths is an important part of understanding the structure that lies beneath.
Initial Conditions - Because of the nature of system dynamics models, there are usually one or more key uncertainties that significantly impact the behavior of the simulation run. It is important to allow the user to set the value of these uncertainties as part of the experimentation process. An important part of model design and use is making hidden assumptions and parameters visible!
Management Flight Simulation Example
The Product Development Flight Simulator was developed by Daniel Kim and Don Seville at the Organization Learning Center at MIT to teach users the dynamics and highly complex nature of the product development cycle. The user had three primary objectives or requirements:
For this simulator, the product development project was separated into two categories of tasks: product engineering tasks (100 total tasks to complete), and process engineering tasks (100 total tasks to complete). Each category represented a stock of work (tasks) that would be drawn down at a particular work rate. The product engineers (PE) were responsible for product design and testing. Process engineers (PcE) were responsible for designing and building the manufacturing process to turn the design into a marketable product.
Figure 1 shows the basic layout of the product development flight simulator. During the simulation, each stock of work was gradually drawn down as the engineers worked. Regardless of whether all the engineering design and process work was completed, the product was manufactured and released into the market on the scheduled day. If the all or a majority of the work was completed, the quality of the product was high. However, if a significant amount of tasks remained, then the quality of the product was low on the day of release. Product sales depended heavily on whether the product was released by the target release date and was of a competitive quality.
Figure 1: Basic Layout of the Product Development Flight Simulator
As the "pilot" of this simulator, each week of the simulation the user was expected to decide how many engineers to hire or layoff, the number of work hours in a week, the scheduled completion date for each team, the amount of time spent coordinating between the two teams, and the quality "target" for the product. The choice for each of the system variables influences the rate at which the engineers accomplish their work, the resulting quality level, and the rate of engineer attrition due to stress and fatigue.
In this case, the flight simulator served as a laboratory in which a wide variety of different management strategies could be tested. More importantly, the consequences of various strategies could be explored systematically without risking "trial and error" learning on the real firm!Just for fun
In the box below, we provide you an opportunity to try out a sample simulator yourself. After reading the brief introduction to our Rocket Simulator, feel free to run the simulator by clicking on the animated figure.
|
|