System Dynamics: a core Systems Engineering Capability (part 1 - SD basics)

Systems Engineering (SE) is moving from a document-based discipline to model-based systems engineering (MBSE). SE is also reaching out from its historic focus on physical systems to tackle wider issues in enterprise planning and management. Time-based simulation with System Dynamics (SD) is an ideal support for both these trends and is therefore a skill that every systems engineer should possess. After a brief summary of each field, a simple ‘Living Business Model’ shows how SD models work and their benefits. We then suggest how to start acquiring SD skills. Part 2, at sdl.re/LIPSESD2, explains how SD can model physical systems - construction projects, supply-chains, ageing assets ... - and include non-physical elements, such as workloads and costs. Part 3, at sdl.re/LIPSESD3, builds the simple example in part-1 into a model of a larger business initiative and explains the wider opportunities for SEs to exploit SD business models. (A conventional paper covering all three parts and offering more detail is at sdl.re/SESDpaper). 

What is Systems Engineering (SE)? ... for non-SE readers!

The professional body, INCOSE (incose.org) defines "a system" as ... a construct of different elements that together produce results not obtainable by the elements alone. Elements can include people, hardware, software, facilities, policies, documents; everything required to produce system-level behavior and performance. “Systems Engineering”, then, is ... an engineering discipline [for] creating and executing an interdisciplinary process to ensure that customer and other stakeholder's needs are satisfied in a high quality, trustworthy, cost efficient and schedule compliant manner throughout a system's entire life cycle.

SE has in recent decades widened its scope and is deployed for a wide range of organisational issues, and even for social, economic and environmental challenges. SE can also help 'engineer' and thus manage the continuing operations of enterprises, both the whole enterprise, and key functions or activities.

The SE body-of-knowledge or SEBoK (sebokwiki.org) explains that SE is moving from documentation-led approaches, which “suffer a lack of precision, inconsistencies between elements, and difficulties in maintaining and reusing the information”, to a more model-based discipline (SEBoK p.39). MBSE is “the formalized application of modeling to support system requirements, design, analysis, verification, and validation activities beginning in the conceptual design phase and continuing through development and later life cycle phases”. So far, INCOSE reports, MBSE is applied only in pockets within organizations and unevenly across industry sectors.

What is System Dynamics (SD)?

The International System Dynamics Society (systemdynamics.org) defines SD as "... a computer-aided approach to policy analysis and design. It applies to dynamic (time-based) problems in complex social, managerial, economic, or ecological systems." So SD simulates how any such system behaves over time. Here we focus on modeling enterprises (a commercial business, public service or non-profit organisation) or any initiative or issue that it takes on.

SD is one of three related dynamic modeling methods. Discrete-event simulation (DES) is very widely used to model how entities move through a process, such as queuing cases, production systems or supply-chains. Agent-based modelling (ABM) simulates the actions and interactions of autonomous agents, to assess their effects on a wider system. It is especially powerful with geo-spatial phenomena such as the spread of a disease.

SD, in contrast, is a continuous simulation method that captures interactions between populations of people, things or materials (more on these methods in Maidstone, 2012). This makes SD models compact and quick to build, but at a cost – SD models say nothing about individual entities. So, for example, service quality may be OK on average, but lousy for a specific customer. It can therefore be useful to combine SD with ABM or DES in hybrid models (Mustafee et al, 2015).

A sound SD model not only matches a system’s observed or likely performance – many techniques can fit trends and create forecasts – but like a good working model in any field, it should mimic the behaviour of everything in the system it portrays, albeit at some aggregate level.

Dynamic modeling is different from process modeling!

SD, DES and ABM all share the feature that they represent the "things and materials” that exist and interact, and that are created, leave or move through a system. Elements in a dynamic model are therefore nouns, such as people, customers, products, units, cash, data and so on. These methods also quantify those things and materials in the system and simulate how those quantities change over time.

In contrast, process modelling maps, qualitatively, the connected processes that act on those things and materials. Process model elements are therefore mostly verbs – hire people, develop products, receive cash, and so on. (See sdl.re/LIPprocessVdynamicModeling for more on this issue) 

Elements of an SD model are: [1] "accumulating stocks" or just Stocks – quantities of things or materials that exist and that define the state and rate-of-change of a system at each point in time, such as inventory, cash, staff, customers, machines. These are fundamental to how the real world works (see “What is an Asset-Stock and Why Should You Care?” at sdl.re/LIPstock.); [2] The "flow-rates" or simply Flows that cause Stocks to grow or decline, such as orders/day, cash-flow $/week, people/month; [3] all other items – constant parameters such as hours per working week, ratios like demand-supply balance, variables such as service quality, and performance results.

An SD model also includes the causal relationships between items that depend on each other. Most are simply arithmetical; for example, sales/month = customers * sales/month-per-customer. Other causal relationships are less readily formulated but can be “looked up”; for example, how sales/month-per-customer change with changing prices. This allows models to capture important threshold effects - for example, sales per customer may be near-zero at any price that is too high but escalate sharply as price falls to an acceptable threshold.  

Building SD models Reliable SD models are most easily built by a rigorous abductive process (Figure 1), explained at sdl.re/LIPagileSD or the paper at sdl.re/agileSD. This process starts from performance outcomes, and works back along chains of causality, validating each causal relationship in turn.

Figure 1: The agile process for developing SD models

Two other approaches to building SD models are common. First, we can start from well-established generic models that have been proven to match whole classes of system. Consultants in the field naturally exploit such templates by adapting them to each specific case.

There is also a style of model-building that starts by developing qualitative causal diagrams. Widespread consultation captures a shared mental model of how stakeholders believe the system works in the form of a causal-loop diagram (CLD) of relationships and feedback loops throughout the system. From this qualitative map, experts then develop the model. Many think, wrongly, that SD is such qualitative feedback work - the focus in this paper is on what quantified SD simulation models can offer. 

A simple SD project example

A team of staff is working to complete a project made up of a set of tasks, each requiring some person-weeks of effort to complete. Staff may leave but can be replaced by others who are hired and trained.

Figure 2 shows a small model-section in which changing numbers of staff drive changes over 20 weeks to both work capacity and staff cost. It compares a policy that reacts to staff losses rather late, and then only replaces those currently leaving (blue) with a policy that reacts earlier and replaces staff previously lost (green). Try this model for yourself at sdl.re/SEstaff.

Figure 2: How a Stock of staff changes over time

These models are not complicated! – Think of this image as a set of linked charts on top of a spreadsheet. Each item is a spreadsheet column with its name in the top cell and values for each week in the cells below. The arrows are like cell-references, showing what is calculated from what – so you can’t make cell-reference errors! The box for Staff and the thick arrows for staff added and lost simply highlight the unique mathematical relationship between a Stock and its Flows. Each item holds the formula for calculating its values from those it depends on – and that formula is in natural language, not Excel-code!

In figure 3, trained staff (only) are working through the Stock of project tasks. In the blue scenario, lost staff are replaced if there are fewer than 25 people in total. But new hires need 3 weeks’ training, so we have too few staff and the tasks are not done fast enough to complete the project in 20 weeks. In the green scenario, we react earlier to the staff shortage, hire faster, and continue hiring up to a larger total number. This is just enough to complete the project within 20 weeks, although of course at a higher cost. Explore the model at sdl.re/SEproject, trying to complete the model on time at minimum cost.

Figure 3: How changing staff numbers drive completion of a project.

This is of course a very simplified demo - SD models can add the many complexities needed to model real projects, and indeed SD has long been used for exactly this purpose – see for example, how Fluor Corp has used dynamic project models.

Want to start modeling?

First, see the part-2 article, which explains how SD models time-behaviour of physical systems, and the part-3 article which builds this simple project model into a bigger initiative for an organisation and explains the wider scope for SD models to contribute to enterprise-related work. We will also say more about how to start building SD modeling skills.

Although modeling the most complex cases is a demanding challenge, needing much experience, any reasonably numerate individual can acquire the basic skills in a short time. If you can build simple spreadsheet models, then you can build simple SD models! For the basic technical skill, see free online classes at sdl.re/modeling-getting-started/ - about 2.5 hours of video explanation and “follow-me” demonstrations.

References

Maidstone, R., 2012. Discrete event simulation, system dynamics and agent-based simulation: Discussion and comparison. System, 1(6).

Mustafee, N., Powell, J., Brailsford, S.C., Diallo, S., Padilla, J. and Tolk, A., 2015, Hybrid simulation studies and hybrid simulation systems: definitions, challenges, and benefits. In Winter Simulation Conference, 2015 (1678-1692). IEEE.