System Dynamics: Systems Thinking and Modeling for a Complex World

[SQUEAKING]

[RUSTLING]

[CLICKING]

JAMES PAINE: Hi, everybody.

My name is James Paine.

I'm with the System Dynamics Group here at MIT.

I'll give you a little bit more background on myself

in a few minutes.

But just to be sure everyone's where they're supposed to be,

this is System Dynamics--

Systems Thinking and Modeling for a Complex World.

This is a three-hour IAP overview session.

Just making sure no one stands up and walks out at this point.

OK, good, yes.

I'm doing pretty good.

A little overview of what we're doing today.

So right now, we're in the middle

of the welcome, which is nice.

We're going to do a quick overview

of What is Systems Thinking?

And I'm going to try to emphasize this

throughout the day, that there is

a subtle difference between system dynamics, the method

set, and system thinking, the concept and field.

And they overlap, and they flow in and out of each other,

but they are subtly different.

Additionally, because this is only a three-hour overview,

we won't have the time to dive into a lot

of the specific tools, and methods, and nitty gritty.

Happy to discuss that in more detail,

or maybe even I'm thinking about planning a future session

with that.

So one of the things we thought about-- what's

the way that we can get people engrossed in this material

as quickly and efficiently as possible?

And our thought there is, we're going to do something

that we like to do quite a bit which is a management flight

simulator.

So that's going to take up a good chunk

of the middle of the afternoon.

I hope everyone has been receiving my emails.

I'm sorry for all of them.

But we need essentially one laptop

per about three to five people in the entire group.

So I think we're good with that.

So that will give us an opportunity

to get hands-on with the system dynamics-fueled simulator,

and then afterwards, we're going to sit down and talk about how

the lessons from that simulation tied into some of our earlier

concepts.

And finally, end with an overview

of some additional resources for those of you who are interested

not only in system dynamics but specifically

System Dynamics here at MIT.

So who am I?

I'll say this, I was not realizing

that the screen was so big, because my face is

very large up there.

Yeah.

My name is James Paine.

I'm a second-year PhD student in the System Dynamics Group.

My path here to MIT was torturous, to say the least.

I worked for approximately 10 years in various industry

settings as a chemical engineer at GE-Hitachi nuclear energy,

as an industrial engineer and Lean Six Sigma specialist

at a company called Inmar, which does

reverse logistics, and then, finally,

as a product manager at HanesBrands on the Maidenform

and Playtex 18 Hour brands.

So all over the place.

One of the reasons, actually, why I found

the System Dynamics Group specifically

was when I decided to go back into academia as a career.

The System Dynamics Group was one

of the few places when, during my interviews

with different folks, when I said

I've worked on everything from nuclear reactors to bras,

their response was, OK, that makes sense.

And then, my response to that was, well,

that doesn't really make sense to me,

I'm curious about why that makes sense to you.

And then, we kind of dove into it from there.

And we'll get more into that sole idea of systems level

thinking.

My specific research interests are focused primarily

on this concept of behavioral operations management.

So some of you in here might be familiar with operations

management as a concept behavioral OM that specifically

looks at the decision making processes that

come about as a result of human beings

existing within a supply chain and either trying

to work around or with that.

My constant line and refrain for all this

is, within behavioral OM, the presence of people

is not a bug, it's a feature, and what can you

do to kind of plan not only around but with that.

So a little bit more about the System Dynamics Group

specifically at MIT here.

Here are our faculty members.

We have John Sterman, Nelson Repenning, Hazhir Rahmandad,

and David Keith.

John Sterman is a big presence in the system dynamics

field at this point.

He is the author of-- and I'll talk about this later on-- this

lovely textbook right here, which is a big, old sucker--

Business Dynamics.

This has become the de facto textbook of the field

at this point.

There's a number of different resources out there.

I'll talk about, again, this at the very end of the class,

but given limited time and limited resources,

my suggestion would to be grab one of the copies out

of the Dewey Library over here and read the first two

chapters.

That greatly overlaps what we're going

to talk about today, and in my opinion,

covers a lot of the fundamental concepts of system dynamics

and systems thinking.

So very brief history of system dynamics.

System dynamics is, at its core, an MIT, sort of, founded field.

It came about out of the mind of this man right here,

Jay Forrester, and its origins are in control theory.

So this is-- I want to say--

I want to preface this by saying this is my view of system

dynamics, and this is coming from the standpoint of someone

whose background is all sort of engineering and operations

management.

I've used system dynamics as control theory

applied to social systems.

And again, you might have some slight disagreement

from different people in the group,

but that's at least my one-sentence summary of all

that system dynamics is.

So the real, seminal work of all this

was in 1958 when he published Industrial Dynamics, which

was sort of the first formalization of these concepts

that we're going to be talking about today.

Jay Forrester himself-- if anyone here

has a background in electrical engineering,

you might recognize his name.

He's the original inventor of RAM.

So his background is primarily around computers.

He was involved in the WHIRLWIND I,

which was MIT's first multipurpose, digital computer.

So he did a lot of work in digital computing,

a lot of work in the electronic space.

Actually, if you go up to the fourth floor--

room 450-- it's the Jay Forrester Conference Room.

In there, there are pictures of him on his ranch

that he grew up on.

There's pictures.

There's chunks of memorabilia from his history of system

dynamics.

There's also an original piece of hand-woven RAM shoved up

there.

So if you have any interest in early computing history,

that's kind of a fun bookshelf to wander through and touch

and feel.

So, really, how this started was, he came to Sloan

and had this idea of what can I do

to take my background in engineering

and apply it to business systems.

And this was born out of his view

that, often, when faced with a problem in this space,

you could get so far with treating it as a purely

engineering problem.

And ultimately, you would end up running into social issues,

you run into bureaucratic issues,

you run into structural issues inside the organization that

are ultimately trying to implement the solution that

have to become part of the solution in and of itself.

So he asked himself, how can I broaden and apply

some of this theory that I've already learned and developed

over the course of my life to this wider

concept of social systems?

His real test of that came in two forms.

One was an early project with General Electric

at an appliance plant, and they noticed

that they had this three-year cycle, specifically

with regards to their employment history.

It was sort of boom and bust.

Have a whole bunch of people coming on board-- onboarding,

onboarding, onboarding-- and then mass

quits every three years.

And the question was, where is this coming from,

what's happening?

So he sat down and hand coded one of the first--

what we consider to be--

system dynamics models within this field and presented it.

And that led to his work in Industrial Dynamics--

A Major Breakthrough for Decision Makers.

Where this got a lot of attention and spread

beyond our group here at MIT was when

he was invited to the Club of Rome

and started applying some of this work

to larger social systems in his WORLD2 simulation.

This led to a book later on--

I'm sure you guys have heard--

called The Limits To Growth, which

is, in and of itself, a fundamental book within system

dynamics but also a little bit controversial

in the form of that it was semi-misconstrued as making

concrete predictions for the future.

Instead, it was trying to make some comments

about the overarching social structures we live in

and the limits of resource renewal and regeneration.

So that's kind of my quick background of where we are

and how we are.

What's interesting is, that what that's led to is,

a group here that has a wide, wide background.

So these are the current PhD students in our group, with me

down there in the middle again.

We have two other members in the room.

We have Jose back there in the corner.

We have TY sitting over here.

Just going to call him out.

Yeah.

But if you look up here, the reason I

have this up here partially so you can hunt us all down

later on if you have questions.

And then, also, for this little line below,

where we all came from and how we all got here.

And you'll notice that it's kind of all over the place.

We have some engineering, we have some aeronautics,

we have electrical.

We also have biology.

We have geophysics.

We have applied mathematics.

So folks come to system dynamics through a variety

of different means and methods, but ultimately, what--

at least my opinion on this is-- it's from someone

taking a systematic approach and noticing

that a systematic approach by its very nature

must exist within a system and how can we

apply that more widely.

So just to give you an idea of where this can kind of lead,

I'm going give you two examples of some research

that I'm currently working on.

I'll get back to this later on.

This one is one that I would consider to be more traditional

system dynamics, in the sense that-- notice this lovely,

little diagram, which we'll talk more about later on--

stock and flow diagram compartmental model.

This is applying concepts of systems thinking

that we'll talk about a little bit more later on,

this idea of nonprofit organizations and decision

making within that space, and specifically

how nonprofits within the performance

landscape in which they operate are

subject to unique and different pressures

that for-profits are not subject to.

And this is-- none of you should be surprised by that sentence.

That's not a crazy thing, but by its very nature,

you create this--

and by outcome of this paper--

this performance landscape that says that not only is it

more difficult to be a nonprofit in certain settings,

it is structurally impossible for you

to achieve certain types of goals.

So that's something that's in the whole line

with this is like why is it so difficult to be

a nonprofit manager under certain circumstances.

That's kind of where it came from.

Totally different chain of research

here is this idea of multi-echelon supply chains

and inventory oscillation.

This is built on a classic model within this space.

Has anyone here ever played the Beer Game?

Beer Game?

We got a couple of hands.

So this is ultimately looking at the Beer Game

and me being frustrated and saying,

we've been talking about the Beer Game for 60 years,

like, why are we still talking about it?

What's going on in this space?

So this is taking, again, the idea of people being people,

letting their order behavior be what it is,

and talk about what can we do for an algorithmic approach

to control mechanisms that exist within a supply chain

with delays.

So in this case, I'm not really doing a lot

with what one would consider to be traditional system dynamics

tools, but I'm spending a lot of time in TensorFlow,

I'm spending a lot of time in Python,

I'm spending a lot of time doing optimization

within these spaces.

And that still is within this larger concept of system

dynamics and systems thinking.

So let's dive in a little bit more.

I've been saying system dynamics and systems thinking a lot.

And you guys are in a three-hour overview session,

so I'm assuming that most of you guys

don't necessarily have a strong background on this.

Actually, that's a good question to ask right now.

Has anyone here taken any of the system dynamics classes

here at MIT already?

OK, good.

Because otherwise, this will be really repetitive for you,

so that's great, OK.

So who here has ever seen a diagram that looks like this?

Does this look familiar?

You have a problem, you identify the problem, you gather data,

you evaluate alternatives, you select a solution,

and you implement it.

Anyone here ever worked in project management?

Anyone here ever worked in that sort of environment?

Yeah.

So my background is Lean Six Sigma--

once upon a time-- and this is a highly-simplified version

of the idea of like DMAIC.

Though, for those of you who have a background in Lean Six

Sigma and know DMAIC, don't jump ahead of me

because I'm going to get to something important here.

So within this concept of identifying a problem,

finding a solution, and implementing it,

ultimately what we're talking about is

that we have some sort of goal, we want to fix a problem.

We're going to make some sort of decision.

By making that decision, we're going

to change the state of our system.

Great, we did it.

Congratulations.

I'm assuming-- partially given away by the title of this

section of the slides--

you can kind of tell that this is not complete.

Also, just by the nature of how I've arranged these variables

on this board, I'm kind of giving away where

I'm going with some of this.

Because at the end of the day, this

is not true in and of itself.

This is all embedded in a larger system

that matters in the short term.

So when you change the state of your system,

your decisions have to change.

Suddenly, when you've changed how you might implement

or control a specific structural process within, I don't know,

your supply chain, the way that you

go about managing that supply chain on a daily basis

is now different.

Additionally, because of that change,

maybe now your goals are a little bit different.

Before, you were trying to-- again,

I'm going to talk in the language of supply chain--

you were shooting for that semi-arbitrary number

of 3.4 defects per million opportunities-- which

I have a whole other soapbox about why that number is not

the appropriate number to choose.

And now you've done it, so now you want to do something else,

so now your goals have changed.

But now, all of a sudden, by you doing this,

you suddenly realize that you're affecting not only your one

process but other processes, other things

within your system.

And that can lead to this thing we call side effects.

But however, maybe by me changing

the state of my system, suddenly a supplier

has to change how they're acting for me.

Suddenly, maybe an order stream has to change.

Somebody outside of myself and my team

has to change their decisions based

upon the state of the system.

And additionally, that state of the system

feeds in right there.

So you can see where I'm kind of going with this.

And additionally, when everything is said and done

and you've built this lovely process up,

with everyone at their own side effects

and building off everything else like that--

here's the fun bit-- none of this happens instantaneously.

There are delay after delay after delay after delay.

So you, making a choice today that affects your system

and achieves that goal within that open loop thinking model,

ultimately can come right back around and affect

that original input again.

This is the fundamental concept of systems level thinking.

No decision you make exists in isolation.

No process that you affect exists in isolation.

The only difference is the boundaries of your system.

In fact, I go so far as to say there are no such thing as side

effects, there are simply effects that you have not

thought about yet.

So what is a system?

A system is any set of interdependent parts

with a common purpose.

Now, that common purpose--

I'll be honest-- is a bit of a caveat,

because as you can probably tell from this,

if you take the systems level concept

and apply it ad nauseum, suddenly you

have a system of every atom of the universe,

and that ultimately is not feasible.

You do eventually have to draw a boundary around your system.

So for our purpose, very generally,

we're going to say that define a purpose,

and then your system is all those parts

that exist within that purpose.

And-- I put my animations out of order there apparently-- social

and economic systems are highly complex.

They are dynamic, tightly-coupled-- and by that,

what I mean is, when one thing happens,

you can trace it to another thing occurring somewhere

else--

governed by feedback.

Ultimately, the decision you make

affects something that then affects that same decision

process in the future.

Non-linear, limited information, and there's ambiguity.

And typically, they're more complex than

human-made, physical systems.

And so, ultimately, when you take a lovely, little diagram,

like this of one thing-- kind of water flowing down,

water flowing down, water flowing down-- the part

that people often forget is that feedback loop

that goes right back up to the top again.

So when we talk about systems thinking and system dynamics,

it's really a framework to help close the loops.

I talked about, before, this idea of open loop thinking.

That's our method of taking that process and saying,

what are the processes that I make downstream, what

are the choices I make downstream,

and how do they come back and affect

that first starting point at the beginning of the day.

Ultimately, what we try to do within system dynamics,

we have a general framework for figuring this sort of process

out as best we can.

A big part of it is eliciting mental models.

And mental models in that sense is saying-- walking up

to somebody and saying, I know you're acting rationally,

I know the choices that you make are the ones that you think

are best for the information set that you have right now,

I want to know why.

I want to build a model of your mental process

that when I run it and I look at it, it makes complete sense,

and then take that model and then

pop it in the context of a larger system

and see how those decisions start coming back and affecting

the outcome.

And then-- that's exactly right--

taking that mental model and expanding it outwards

and saying, OK, now you've made choices,

how can we bring feedback into account?

Simulation.

So this is one thing-- for those of you

who might have a small inkling of the System Dynamics Group

here at MIT, a huge chunk of what we do is simulation.

Because at the end of the day, it's a heck of a lot

cheaper, quicker to simulate a social process, and changes,

and tweaks, or impacts, or effects

than actually going out there and doing it directly

on social systems.

It turns out that takes a long time

and often makes people grumpy if you do it directly.

So simulation is really, really helpful.

So simulation helps also improving mental models

by presenting folks with people, also as a teaching tool,

showing folks self-contained models and simulations

of a process that both shows how their mental model fits

and makes sense and is perfectly rational,

but then also, in a larger context,

can affect and have feedback.

So this is the big one.

The simulation's purpose is not to be right.

I put this up here partially for my own edification

and my own learning.

I spend way too much time building these models,

both within the core system dynamics tools

that we'll talk about a little bit later

and also within my own side environments of saying, OK, I

want to get this simulation to match some reference

mode of data as closely as possible.

And the question there is, though, being right

is not the same as being useful.

So you want to make sure that you're

identifying the high-leverage policy choices

within your model, the portions of that multi-loop mode

of thinking we talked about earlier that actually affect

the outcome that you care about, not necessarily

have a simulation that directly matches the physical universe

around us.

These are next-- what I consider to be some of the three core

points of systems thinking and systems dynamics,

and this is the big one.

Structure generates behavior.

If you walk into a system dynamics conference,

if you walk into any room with enough people

who do system dynamics for more than five minutes,

eventually someone's going to say this.

Structure generates behavior.

And I'm going to spend a little more time

on this in a few minutes.

The whole idea of structure generates

behavior is that the actions that people take

are possible, feasible, and rational because

of the universe in which they exist,

and it's important to realize that.

And that actually then goes into that mental models

matter a lot.

So physical structure-- when we talk about structure,

it's not just the physical structure of your system,

it's the structure that exists within people's heads.

It's the choices that they make when they take an input

and then do an output.

Again, my background is all process control and process

engineering.

So one way you can think of this as little tiny PID controllers

floating around in the universe taking inputs and outputs.

However, figuring out what those inputs and outputs are

and how people convert that information

is difficult and should not be casually assumed away.

And then, finally, the fundamental attribution error.

This is something that I added back in here,

because this idea that our first instinct is

to blame the people and not the system--

and this goes back to this idea of structure

generates behavior.

So like, for example, if you're on the highway and suddenly

someone cuts you off, what's your initial reaction?

Screw that guy!

What the heck!

Honk, honk, honk.

Now suddenly, you're on the highway and--

I don't know-- you're late to get somewhere-- for me,

I got a call that my kid is throwing up at preschool,

I got to get there in the next 10 minutes--

what do I do?

I cut somebody off saying, sorry, it's OK, and I zoom off.

So in that situation-- that first situation, when I'm honk,

honk, honk, that guy-- that guy who just cut me off--

what's wrong with them?

Something is wrong with that person.

No.

There's an underlying reason, there's

an underlying rationality behind what they're doing.

I will argue that there might be rationality

or that person is just really bad at driving,

but hopefully, that's not it.

But the idea that the fundamental attribution error

is that our first instinct is to blame the people and not

the system.

Back to structure generates behavior.

It is the structure of the system that matters

less so than the behavior.

And even within our own group here at MIT,

we have to remind ourselves of this idea

of the fundamental attribution error.

And we try to break away from it, we're not perfect at it.

This is written on the whiteboard up in our room.

This is one of the first things I saw when I walked up

to that group, and at the time, I just

thought it was a nice saying and I

didn't realize this was actually addressing

one of the fundamental decision-making fallacies

that we have to overcome as system dynamisists.

So this is the basic assumption.

"We believe that everyone in this community

is intelligent and capable, cares about doing their best,

and acts with integrity, and wants to learn."

So the assumption is that, every person

you meet, every person you sit down with

has this operating in the background

and you have to assume that they are rational,

caring human beings who are doing what they think is best.

And the moment that you accept that, then, suddenly, it's

not the person you have to change,

it's the system in which they're operating that needs to get

shifted.

So this some more, kind of, burning

into this whole structure generates behavior.

You have patterns of behavior-- so events are the most visible.

Underneath events, you have patterns of behavior.

Under that, you have structure.

So when you look out into the universe and you see something,

those are the events.

You see those things happening over and over again,

those become patterns of behavior.

And then, the system under which it's generating it

is the actual structure.

So here's an example.

This is all about oil prices.

"Drunk trader caused a spike in oil prices."

"Oil prices keep falling-- this is why."

"OPEC rumors continue to pull oil prices higher."

OPEC turns for high oil prices.

"Another sign of economic worry-- tumbling oil prices."

Oil prices after tanker attack in the Gulf of Oman.

So in this case, each one of these ones,

you notice they're talking about oil prices jumping up,

oil prices going down, oil prices jumping up,

oil prices going down.

These are the events that you see.

These are the points of data.

The pattern is a little bit more interesting.

You take each one of those effects,

you can't just draw a line out ad infinitum,

you want to look at something like this.

So in this case, you can see the oil prices--

and I would see this as sort of a stereotypical boom and bust

pattern.

It goes up, it goes down for quite some time.

Goes up, and then goes down.

Goes up, and then goes down.

I would actually even boil in here

and say that it looks like the amount of noise

around this up-and-down pattern is increasing

over time, which in and of itself

is a little bit interesting.

But ultimately, it's that structure

in the background that matters.

There's the physical structure, there's the information

availability, and then there's also

the actual mental model of the actors involved in the process.

So we talk about this.

This is a whole thing.

Whenever you talk about mental models within this space,

one of the things that's easy to say

is, OK, well, you tell people about this.

You tell them to consider feedback,

you tell them to incorporate this information around them,

that that'll fix it, that'll fix it.

No.

It is incredibly difficult to learn and change

in a dynamically-complex environment,

and these are just some of the information--

some of the reasons why.

I'm not going to walk through all of these.

I think everyone in this room, probably,

is on the same page with me on this one.

One thing I'll point out, right there,

is limited information and time delays.

Gigantic reason.

People can only make the decisions

given the information they have available to them

in the structure in which they're able to operate.

To expect someone to operate otherwise

is to expect them to be omniscient in some way, shape,

or form, and ultimately, that is not feasible within a larger

system.

So system dynamics-- in my mind, the System Dynamics

Group here at MIT is really applied systems thinking.

It is not a method.

It's not a model necessarily.

It is taking the concepts of systems thinking and applying

them in ways where we can get research outputs that

ultimately improve some sort of social system for the world.

So now having said all that about systems thinking,

I'm now going to dive into some specific, actual tools

that we can go ahead and use here within this space.

Let me make sure how we're doing here with time.

We're doing great.

All right.

So systems thinking, ultimately, and system modeling

is iterative approach.

There is no right answer at the very beginning,

there is only the answer that you

think is good enough to solve or address

the problem you care about.

It's a spiral approach.

Just like everything else we'll talk about with open loop

thinking, the process of building a system dynamics

model is an attempt to close the loop.

And it's not just compartmental models.

So when people talk about system dynamics models--

if you hear that phrase-- what they're likely talking about

is this lovely thing over here.

This is from one of my papers, and I'm

working on it right now.

We'll talk about this in more detail in a second.

It's called a stock and flow diagram or compartmental model.

This is often confounded with system dynamics, the field.

It's partially because this is the go-to modeling

choice for many people in system dynamics,

and this is also the first modeling choice

back in the '50s, '60s, and '70s when approaching

these sort of systems.

And then, of course, that says all models are wrong,

but some models are useful at the end of the day.

So when you're taking a spiral approach

to systems modeling, what you want to do

is you pick something within this setup.

You think, OK, what's a reference mode.

So by reference mode, I mean what is a mode of behavior

that you can observe and pin down.

This person made this decision when exposed to these inputs

and had this output.

Great, we have a reference mode.

Can I build a model that reflects that reference mode?

Awesome.

Now that I've done that, let's go ahead

and add a new reference mode.

Can I make this reference mode exist

within my existing diagram?

Nope.

Let's go ahead and add more structure.

And as you add that more structure, maybe it comes back

and it feeds back into itself and you

have to go back and kind of rework from the very beginning.

This is where this concept of simulation

becomes really, really helpful, because when

you interview somebody--

as I've done with some of the work in the, especially,

non-profit space--

you might get six different stories describing

three different outcomes across two different possible modes

of behavior.

And the question there is, how the heck

do I incorporate this all into a dynamic model

at the very beginning?

My argument there is, you don't.

Pick one.

Pick one to model it, then when you're done, pick another one

and model that one and then see, OK,

how do they overlap, how do they fit into each other,

how can you make this one, unified model?

And the big thing is, as you're going

through this whole process, doing your sensitivity analysis

and you're testing, you're going back through

and updating your own assumptions and mental models

about what you think the problem was to begin with.

This idea of spiral approach.

So, OK, now we're actually going to jump into some actual--

I said before that system dynamics are not

compartmental models.

I'm now going to teach you guys about compartmental models

because we use them a lot in system dynamics.

Heh.

So this is fun.

So causal links.

A causal link is a fundamental tool.

So causal link is simply saying, if one thing

changes, another thing changes.

This is super simple.

So let's start with this one.

You have production, you have inventory,

and you have shipments.

If I increase my production of a good,

what should happen to my inventory?

This is not a trick question.

AUDIENCE: Goes up.

JAMES PAINE: It's going to go up.

Woo!

If I increase my shipments of a good,

what's going to happen to my inventory?

It's going to go down.

You guys are-- woo!

You guys are great.

So there you go.

So these are causal loops, or causal links, similarly.

Let's say I have orders booked--

and now, you could argue that there's

some missing components in here, but we're

keeping this really high-ended.

If I have more salesforce in general,

what do you think would happen to the number of orders

I have booked?

Increase, yep.

If I increase my price, how many orders

do you think I'm going to get?

They're going to go down, exactly, yeah.

Pretty straightforward.

One more and then I'll leave you guys alone with this one.

Population.

More people are born, it's going to go up.

More people die, it's going to go down.

Great.

Causal links, straightforward.

Where it gets a little tricky is when you have an ambiguity.

If all of a sudden you say to yourself,

well, you know, salesforce, I don't know about that.

Maybe if I hire too many people with my salesforce,

then suddenly they start conflicting with each other.

Maybe they start going after each other.

Maybe they start overlapping, and maybe customers

get annoyed because they get too many calls,

so maybe it will go down.

The moment you have this idea that that causal sign could

be a plus or minus, that implies that there's

something in the middle.

That means that that loop does not exist in and of itself,

there is structure that you have missing that you need to add.

Now, something also, too, kind of the same idea--

causal thinking.

And some of you guys might have seen this already.

Causal thinking is truly causal thinking.

It needs to be causal, not purely corollary.

So ice cream-- so this is generally

true-- as ice cream sales goes up, so does the murder rate.

So next time they open up a new Baskin-Robbins,

we should maybe change towns.

I guess that's what that means.

Now, as you guys can probably guess, what that really means

is that there's something missing.

This is not truly causal, instead

we have the average temperature.

As the average temperature goes up,

people start interacting with each other more,

they start going outside more.

Just the amount of incidents of people kind of interacting

goes up, murder rate happens to go up.

Additionally, people want more ice cream.

So there.

In that case, we have something in between.

So something to keep in mind when you build a causal loop

diagram is that word causal, when

you're putting this together.

And then, if you have time, I would

encourage you guys to go just like, I'm going to try--

I'm going to run these slides by the faculty

and make sure there's nothing in here

that I'm not supposed to share, but assuming I can,

I'm going to send this out to everybody as well so you'll

have access to these slides.

One of my favorite websites, Spurious Correlations.

They have all sorts of fun little things like that.

So, now, bringing it all together into a loop.

So in this case, we have a basic loop of employee skill

versus customer satisfaction, complaints,

manager's time spent resolving customer issues,

and manager time spent coaching employees.

I'm going to walk through this really quickly.

Again, we only have a few hours to talk.

So normally, this would be a little-- if you guys end up

taking one of the system dynamics classes,

we step through this very carefully.

Yeah.

AUDIENCE: What do you mean by causal?

JAMES PAINE: So causal, in and of itself--

you raise an excellent point.

Causal, in and of itself, is the degree to which

you have confidence on it.

So at the end of the day, causality

is the realm of mathematicians and physicists, in my opinion.

True, true unresolved causality.

So causality in the sense that, if one thing occurs,

the other thing if, and only--

one thing occurs if, and only if, the other thing

occurs, that they truly are connected in time and space.

When one happens, the other one follows.

Corollary is that that may still hold true,

but the reason they're happening is

because of an in-between mechanism that is driving both.

So where this gets kind of tricky is,

the lines of causality become blurred

when you start talking about macro-social systems.

And ultimately, this is the same idea that all models are wrong,

but some models are useful.

There's a certain point of time where

you have to pump the brakes and say,

all right, this is causal enough for my purposes

and I'm going to move on.

But the same thing-- when you said the moment you

have a time where that loop polarity

can shift or, suddenly, something increasing causes

another thing to increase.

Now, suddenly, that same thing increasing

is causing everything to decrease.

Those are no longer causally-related in space

and time.

There's something in between.

There's some mechanism in between

that's causing that thing to go up in this direction

causes this other thing to go up and/or down

depending upon some in-between circumstance.

The moment that degree of specificity

is necessary, then suddenly that causal link needs to get

split out into more detailed structure.

Maybe I'm diving into too much detail.

Is that helpful?

Kind of?

AUDIENCE: [INAUDIBLE] you mentioned

physics, but like there's a perspective of physics

in which you actually look at the physics equations,

there is no real such thing as causality,

there are just states of the universe that

are mathematically consistent and states of the universe that

are not, so causality-- so it's like, causality really

depends on the assumptions of your system.

Like, you're assuming that things

could have been different, but in reality, they couldn't have.

So I guess I was--

the operational definition of [INAUDIBLE]..

JAMES PAINE: You're completely right.

Is your background either physics or mathematics?

AUDIENCE: Yeah, physics.

JAMES PAINE: Aha, there we go.

So yeah.

No, no, you raise an excellent point,

because I had the same conversation

with a couple of other folks in the physics group.

And within our-- what it boils down to-- within our social

system modeling, our definition of causality is loose at best--

but ultimately, it boils down to,

if one thing moves in one direction,

another thing moves in the same direction

consistently every time.

The moment that you can't say the phrase consistently

every time, then that concept of causality breaks down.

Just so you...

Yeah.

AUDIENCE: So when you're dealing with social systems,

does it become a little bit less [INAUDIBLE]

and more statistical?

JAMES PAINE: Yeah.

To be very honest with you, I have

to be careful because I think some folks in the group

might disagree with me on this.

But again, my background coming from control theory

and operations management is that the realm of causality

and the realm of correlation are degrees of convenience

at the end of the day.

This is a gigantic asterisk in the top corner.

This is the opinion of James Paine.

Please do not necessarily tell other faculty that that's me.

But yes, it is a division of convenience.

And ultimately, what it boils down to me,

is that, if you shove something in one direction,

does another thing constantly move

the same way every single time?

The moment that it doesn't, then they're no longer

coupled within these systems.

That's the very, sort of, hand-wavy, simplistic way

of approaching it.

AUDIENCE: All else being equal.

JAMES PAINE: All else being equal.

That's a good point.

All else being equal.

So here.

I'm going to go through these loops real quick.

This is good.

So this, I think, is pretty straightforward.

This is the whole idea that, as your employee skill-- this

is, again, very general-- employee skill goes up,

your customer satisfaction goes up.

Customer satisfaction goes up, complaints go down.

Times that your manager now spends

resolving customer issues goes down,

so now the manager has more time to coach employees.

So guess what?

Employee skill goes up.

This is an example of a causal loop.

You start at one variable, yet work your way

all the way around to the same variable again.

Now, I'm speeding up here just a little bit

for the sake of time, but let's just

go ahead and say that we somehow exogenously increased

the amount of time that managers can

spend coaching their employees.

I don't know, we somehow give them extra time in their day.

What does that mean?

Well, this would imply that our employee

skill you'd expect to go up.

And if our employee skill expects to go up,

then we expect our customer satisfaction to go up.

We'd expect our complaints to correspondingly go down,

based upon these causal diagrams.

If our complaints go down, then the manager time

spent resolving issues goes back up, which suddenly means

that the amount of time they have available to them

goes back up again.

We've gone all the way back up the loop,

we've increased one variable by a little bit,

and we've gotten a positive gain around that loop.

If any of you have any experience with control theory,

this will look familiar.

This is a positive gain or reinforcing loop.

This is a loop that, essentially, runs away

in one direction or another.

When one variable starts going a little bit up or a little

bit down, by its action, it causes a cascade

of events that causes it to go more up or more down

within that space.

Correspondingly, we can have something--

I think you guys can tell where this

is going-- called the balancing loop, to get ahead

of myself a little bit.

So in this case, the general attractiveness of your market

goes up, the number of competitors within that space--

you could imagine-- would go up.

Your product price-- this is due to competitive interactions--

might go down.

This is an example of an aggregated causal diagram.

I think you can make a really strong argument that those

are not necessarily perfectly causally-related,

but for our conversation, it's good enough.

Product price goes down.

Your profits, all else being equal,

you'd imagine would go down.

That's-- OK.

I think I did that one a little backwards.

We'll find out.

Anyway, balancing loop.

So the whole idea with the balancing loop

is that a small--

these are loops where they tend to balance themselves out.

You have some sort of external stimuli

that pokes a variable up or pokes a variable down,

it will act in a way to return back to its initial position.

A good example of a balancing loop that comes up a lot

is called the goal-seeking loop.

In this case, you have some sort of desired performance out

in the universe and your system will

act to close a gap relative to that.

I'm showing you guys a structure kind of relatively

quickly to give you some chunks of system dynamics

compartmental models that you might see frequently.

So the right way to tell if you have a balancing or reinforcing

loop is you trace the behavior, like we did before.

You pick a variable, you kick it in a direction--

plus or minus--

and you see what happens when you loop it all the way around.

There's a quick way to do it, which is count the negative.

If there is an even number, then it

is a reinforcing loop, zero or even.

If it is an odd number, then it's a balancing loop.

The part where that gets a little wonky is that if you

mislabeled it in some way, shape, or form, then suddenly

that no longer makes sense.

So that's my little asterisk in the top corner there.

Stocks and flows.

So stocks and flows, ultimately--

I'm going to skip ahead a little bit here-- are anything that--

a stock is anything that has memory within this space.

So if you go back to the origins of system dynamics

and its applications in control theory,

a stock is anything whose value depends

upon the instantaneous or the accumulation of change

of two other variables.

So how we tend to show this in our space

is as a bucket with some pipes.

So you have an inflow coming in, you

have some sort of accumulation in the middle,

and you have some outflow coming out of the back end

right there.

This right here, now, allows your system to have memory.

This is what your system has when you talk about number

of employees, you talk about number

of units in your inventory, something else

that has sort of stickiness in time,

something that instantaneously doesn't disappear or change

within one unit of delta time but rather exists and persists.

So we use something called the hydraulic metaphor.

This picture-- the quality of it is really low,

and I should remake it.

It's the idea of a bathtub.

So you have your pipe coming in, you have your pipe coming out.

And ultimately, you can't get rid of something in the middle

unless you take it out of the back end

or turn down the amount of inflow on the front end.

So a good example of this is greenhouse gases

in the atmosphere.

What do you do about it?

There's really only two options at the end of the day.

You have to either increase net removal

or decrease net emissions.

Those are your two choices.

So that's the one thing we talk about.

A stock is something that accumulates over time.

So this is a good example right here.

This is just some stocks versus flows.

Your balance sheet versus your cash flow statement.

Wealth versus income and expenditures per unit time.

CO2 emissions, vehicle production-- those

are all flows.

Part of this-- you can tell-- is based

upon how you define the variables

at the end of the day, so you have

to be a little bit careful.

But I will give you this.

Here's one that I kind of consider a little bit

tricky-- interest rate.

What would you consider to be an interest

rate, a stock or a flow?

AUDIENCE: [INAUDIBLE]

JAMES PAINE: I called it tricky, so you can probably

think, like, oh, take what you think it is

and then just flip the answer.

That's what I would do.

So it has the word rate in it, which immediately

makes me think flow, but it's actually a rate on money--

it is a price.

It is something that says that, if you give me

x number of dollars, I will give you

back x number of dollars over some period of time elapsing.

In that case, it is a price, it is a sticky quantity,

it is a stock, so the word rate there is misleading.

I'm going very quick guys because I want to give you

guys time for the simulation.

So that right there is really quick system dynamics

in a nutshell, in terms of both systems thinking and concepts

and also some of the fundamental tools

that we use within stock and flow diagrams.

What I wanted to do next was transition into actually a very

large group project that will give us some time

to really experience some of this firsthand,

and then ultimately, tie it back in.

But before I do that, I want to give us a few minutes

to talk about this.

Anyone have any questions about either System Dynamics Group

at MIT-- and we'll have some more time

at the end of this-- or system dynamics and systems

thinking as methodology at this point?

Yeah.

AUDIENCE: When do you think-- or when

is a problem too complicated for you to say

system dynamics is useful?

What are the bounds on usefulness

of applying this to a problem?

JAMES PAINE: Well, the weird thing

is, I won't necessarily say-- complicated

is not the right word.

I would say that system dynamics is

a poor predictor of the future when it comes to precision.

So like, there's an example of system dynamics, I think,

is good at making models that predict modes of behavior

but not necessarily point predictions in the future.

So like, a good example would be an oscillatory mode.

If this is your idea of-- this is like your mode of behavior

of something over time--

I don't know-- this is like some price of something over time,

and you make a model that ultimately shows

that, given some period, some set of inputs,

I can do something like affect the amplitude and periodicity

of this scale but ultimately does show something that kind

of changes with time, but for some reason

my model is just a little bit off.

The question is, which is useful--

knowing that I have this sort of up-and-down amplitude

and here are the things or features

that either predict a change in that amplitude and frequency,

or is it more useful to know that the price is

going to be this versus this at this time in the future?

And the issue with any sort of systems model

is, the moment you move far enough away from whatever

your current sort of stab in space

is, you can be just as wrong as you can possibly

be when it comes to point predictions in the future.

So my argument is that system dynamics

is good at coming up with models where you can start looking

for these modes of behavior and identifying

the chunks of structure that have a large policy

impact on affecting or adjusting these modes of behavior,

not necessarily figuring out am I going to be

here or here at time this.

So that's-- yeah.

I got to use the whiteboard, so that's fun.

OK, cool.

So what we're going to do-- this is another bit of bread

and butter of the MIT System Dynamics Group--

a management flight simulator.

This is the whole idea of working on mental models.

Ultimately, getting someone's hands dirty with something

like this and getting an opportunity

to experience it firsthand is one of the best ways

to teach concepts from system dynamics and systems thinking.

So Fishbanks.

Fishbanks was originally developed quite a number

of years ago as a board game--

and I think you guys will figure out

very quickly what it's trying to elicit out of you all.

This is a smart group of folks.

But it has now been turned into kind

of this interactive simulation.

So for the next hour and some change as we go through this--

I know everyone here has different backgrounds,

different businesses, different things you've been exposed to,

but this is going to be your business.

Your business is going to be deep sea and coastal fisher

people.

Your job is to go out there and catch fish as best you can

and make as much money.

You are all endowed with your own small fleet

of boats and your own commercial fishing operation.

Congratulations, welcome aboard.

So that's all I'm going to say about Fishbanks.

Again, there's a lot more stuff to say about this,

but I'm going to go ahead and wrap this up,

because, again, we only have three hours in total.

Before I do that, any final questions about the simulation

itself?

Any accusations that I rigged the whole thing

and made it impossible?

Or anything fun like that?

Yeah.

AUDIENCE: One of the major, like, one of the teams

also found out that their change happened too fast,

and I think that's because we didn't understand

the system or the equations behind it, the model.

Was that information left out intentionally?

JAMES PAINE: To a degree.

So one interesting way to run this simulation-- and it's been

done, but it hasn't been done for a long time--

is to essentially run this whole thing again with you.

Like, essentially let every person in this room

play the game again, but understandably,

with slightly different parameters,

like so you can't just set it straight to what you

want to do right off the bat.

So the argument here is that information is imperfect,

but it is still present and some information

is better than no information.

So the constant question is, what

happens when you guys know this information ahead of time?

I'd be curious about that.

For those who did the beer game, one of the things

that came out of that that's interesting,

the beer game is this multi-echelon supply chain.

The ultimate thing about it is that information matters,

information is helpful.

When you play the beer game with people who have played the beer

game, you still get the exact same outcome no matter

how many times you do it.

And one of the classic examples is

we had a beer game, like, championship here at MIT

some years ago where not only was it people who played before

but it was professors who teach the beer game in the same room.

And we also gave information.

So typically in the beer game, there's some--

AUDIENCE: [INAUDIBLE]

JAMES PAINE: I know, yeah.

[INAUDIBLE] But even the folks who teach the beer game didn't

escape the beer game.

So part of this is that as long as--

and this is the whole idea of structure yields behavior.

The structure is still there.

The underlying structure still exists.

It is real hard to break your behavior patterns

when you don't change that underlying structure.

So if you want more, we're all up on the fourth floor,

for one thing.

So at least, I don't lock my door, so come on in.

I'll talk your ear off.

For classes here at MIT, a lot of what we just talked about

is covered really in much more detail in 15.871, Introduction

to System Dynamics.

I would say 15.871's primary purpose

is to get these ideas of systems thinking in your head.

You'll be spending a lot of time in that class

up on a chalkboard, sort of talking through problems,

saying, OK, well, let's talk about what happens when you

increase consumer satisfaction.

What does that mean?

And start drawing these lovely causal loop diagrams

and think to ourselves, OK, well, what happens

if we snip this loop here?

And what would it take to do that?

So it's much more about how to get yourself

thinking from linear direction into more of a looping

direction.

15.872 dives a lot more into now taking those thought processes

and applying them to sort of much more realistic scenarios

and situations and getting more comfortable with modeling

tools.

Both involve you using software sets,

which I'll talk about a little bit later, that are commonly

used within system dynamics.

But 15.872 kind of takes the training wheels off.

And there is no-- there is no right

there is no wrong answer as long as you can figure out

a good self-contained simulation that gets the conclusion you

think is interesting.

This one is relatively new, 15.873.

This is somewhere that sits in between 15.871 and 872.

This is one who's, I like to think, has more of an emphasis

on business and policy.

I have this example down here.

This is the Vasa, which I'm now giving away

a slide from, I think, 15.872.

The Vasa was an incredible ship that

was built by some of the best ship designers of its day,

was launched, and then promptly tipped completely upside down

and sunk to the bottom of the ocean.

And the reason was because, at the last minute,

there were several late design adds.

Someone decided they wanted to build the captain's

lodge a little bit larger.

They wanted to add a few more sails.

They wanted to add a ton more cannons.

They wanted to make it more and more impressive.

It became hydro dynamically unstable, promptly tipped over.

So the idea being here that--

I emphasize that one for this idea

that you have unintended consequences.

There are no side effects.

There are simply effects that you didn't plan for.

And that's kind of emphasized a little bit more

in 15.872, 15.873.

In terms of books, I brought a few with me.

Again, I mentioned this at the beginning of the class.

This has become sort of the bible of system

dynamics, business dynamics.

The first couple of chapters cover

a lot of what we talked about.

Later on, it gets really specific.

There's an opening in here that says, essentially,

if you have a background in math, that's great.

If you don't, that's great.

But later on, it starts talking about the specific differences

between choosing modes of feedback and behavior,

how to model specific things, really

how to get your hands dirty for primarily compartmental models.

If you want something a little more general,

there is the Fifth Discipline Field Book.

I wouldn't necessarily recommend the whole book

unless that's your thing.

But part two is called systems thinking.

It does a great job of summarizing the work

that we talked about here.

Both of these books are in the Dewey Library.

I checked earlier today.

I think this is one of the two copies of this book.

Sell or return it right after this class.

But there's lots of copies of John's book on business

dynamics.

If you want to know a little bit more

about sort of the history of this, Limits to Growth

is a book that I recommend because it has a strong history

in system dynamics.

It also has a bit of a controversial history,

if you dive into it.

This was one of those first books that

applied the ideas of overshoot and collapse to the earth,

and saying that we as a species are headed towards this,

and we need to manage our resources

and we need to be a little bit more careful with our choices.

The simulations in there had some specific dates

that ultimately were held up as sort

of the how why point prediction is

difficult in system dynamics.

So if you read it, this is not a prediction for the future.

It's discussing the mode of behavior.

It's talking about the structure that we currently

have that can lead to overshoot and collapse

within shared resources.

Articles, if you get a chance, it's my personal favorites.

System Dynamics at Sixty: The Path Forward, I think,

does a great job of kind of saying where

is system dynamics right now.

A lot of material that you get out there

talks about where system dynamics

was 20, 30, even 40 years ago.

I think this one does a great job of saying, that's great.

What are we doing from now?

This is essentially the article that says,

system dynamics is not compartmental models.

System dynamics is a mode of thinking.

Choose the software that you need to.

Choose the methods of communication you need to.

I am, again, someone who does a lot of operations management.

So most of these choices up there

about compatibility traps and sort of operational failure,

that's kind of where I'm coming from.

But that being said, this one right here,

the third one on the list, Making the Numbers,

applies a classic operations management concept

of a capability trap to valuation of stocks.

And I think that's a great little connection right there.

If you happen to be on MIT'S network,

these are all free and accessible.

The worst case scenario, I'll print out a copy for you

because I think these are good articles.

Other websites.

Some personal favorites here.

Creative Learning Exchange, this is

one-- it's primarily K through 12 education-focused.

But there's a lot of fun little tools on there.

It uses a lot of animations, make things very approachable,

especially if you're used to looking

at sort of cold, black and white diagrams.

Clicking around on there just kind of makes me happy,

like it has lots of pink fluid flowing back and forth,

and you like-- you attach the little things together.

They have some fun iOS and Android applications.

Tom Fiddaman's MetaSD website is fantastic.

He has-- that man will just model anything

that he thinks is interesting.

So if you have a blank piece of software in front of you

and you don't know what to click and you want something

as an example, he has one about sort

of the self-reinforcing nature of UFO sightings.

So he essentially thinks to himself,

this is an interesting behavior I have observed.

I wonder what structure could have yielded it?

And then he makes it and puts it on his website.

So that's just a fun one to click around on.

This one, the self-study website,

that is dense, to be honest.

But it's a good spot to start.

This systematically walks you through the fundamentals

of system dynamics from open concept to detailed modeling

systematically.

And is free and open for anyone to use.

I run, right now, the Journal Club.

So that's my plug right there.

Stop on by.

Every other Friday, once the semester starts,

or every Friday once the semester starts,

we have a seminar series that's systematic-focused up

on the fourth floor.

If there's not a seminar scheduled,

then I just kind of run the discussion and talk

about something I feel like talking about.

And then of course, the System Dynamics Society.

That's kind of our group society.

I would be remiss if I did not at least mention them

in passing.

It's a lot of information, but I think especially

those first two are not ones that you

see a lot are recommended.

Software.

We didn't talk at all about software.

If this had been a longer course, that probably would

be the next thing I'd do is I'd dive into some software

with you guys.

Unfortunately, we don't have the time.

So I want to point you in these--

towards these guys right here, Vensim and Stella Architect.

Vensim especially has a free academic license.

If you also have an MIT email address,

you can get more or less the full commercial version

for free, which is nice.

The difference between the personal learning

edition and the commercial edition

is minimal until you hit it.

And then once you hit it, you really

want that commercial version for being

able to just do some stuff.

So if you have an MIT email address,

I suggest spending the three minutes

to get a Vensim professional license.

Stella Architect is less used in our group, but definitely used

in general.

They have a great storytelling mode,

this idea of building up your models progressively

without scaring people away, kind of.

And also have a lot of nice visuals.

I'm still getting used to that software myself,

but I like what I see.

Also, off to the side there, NetLogo.

Not used a lot in our group necessarily,

but I use it a lot.

It's a good old agent-based model.

So sometimes it's useful to think, OK,

I know what a person would do or an agent

or an entity in the setup.

I can wrap my head around that.

I don't know what the system is, but I

can wrap my head around one person wandering through space.

This lets you, essentially, model that person

and then put a whole bunch of them in a room

and see what happens.

If anyone has done any sort of agent-based modeling

with any sort of scripting language, MATLAB, R, anything

else like that, this is kind of the same concept

with a nice little pretty wrapper

around the outside of it.

Speaking of which, in terms of software,

we use all sorts of software.

It's not just Vensim and Stella.

These are just what I have upstairs on my machine

right now.

Actually, they're on my machine right now

and what I use on more or less a daily basis.

We're not just compartmentalize models.

We're a mode of thinking.

So if you have a tool that gets the job done,

than good for you.

It's possible to do a good causal diagram using Excel

if you're really motivated.

Oh yeah, and a whiteboard.

Whiteboard definitely gets the job done.

That's actually-- he raises a great point.

The best use is just standing in front of our whiteboard

and starting writing some things down.

People often ask the question, what do you do?

Like, how do you start?

Like, what's the first thing you do?

I'd say walk up to a whiteboard, think

about the thing you care about.

I don't know, it's CO2 in the atmosphere,

car deaths, number of people quitting from a non-profit.

Write that on a board.

Just write it smack dab in the middle of the board.

Then think to yourself, what would cause that thing

to go up or down?

Write it off to the side.

Draw an arrow, put a plus or a minus next to it.

And just keep going and see what happens.

And let those loops come back around.

And that's a good spot to start.

So that's-- we have a few minutes.

I'm going to click this one thing right here

for another example of system dynamics in action.

If anyone is familiar with the policy interactive,

this is an idea too of what's the most complicated model sort

of idea and what can you do.

This is En-ROADS.

This is a policy simulator for the climate.

So this right here has a full-blown climate simulation

running on the back.

But its job at the end of the day

is again, not point prediction.

Its job is policy.

So again, this is one kind of a fun thing

to click around and kind of see system dynamics in action.

This is simply saying, what are we doing right here?

What's our predicted temperature change over time?

What are the choices that we can make as a society, as a group,

as a series of countries to change this outcome?

This is being used right now in conversations with members

of our own government in order to help elicit mental models

and get people on the same page about climate

action in the future.

And so this is something else where

there is a big compartmental model running

in the background.

But this is an example of using system dynamics

to hopefully elicit real policy change in the near term.

So you can start clicking around, seeing what happens.

I'll be honest, I'm really bad at this one.

I click around and I realize I'm really bad at figuring out

how to fix the climate, which is why I do operations

and supply chain management, I suppose, at the end of the day.

So yeah, I'd encourage you guys to click around on that.

So that, essentially, is where we are.

Thank you guys very much.

I loved sharing system dynamics with you,

and I hope to see some of you guys in the future.

Thank you.

[APPLAUSE]