Note: OGM Forum is no longer active. This is a static snapshot as of February 2022. You can browse the site to see posts, but the functional features of the site will not work. You can search or download a zip archive of the files from the site at github/OpenGlobalMind/

Systems Thinking is Alot More Than Feedback Loops

Much of current Systems Thinking literature equates Systems Thinking with feedback loops (i.e., Causal Loop Diagrams and their “cousin” Stock and Flow Diagrams).

But abstraction is also key. Feedback loops vary per level of abstraction. When looking at a complex organizational system, the feedback loops we see at the 20,000 foot level will be different than those we see at ground level. We therefore need to use a multi level modeling technique (DFDs) . Only then can we model causalities (via CLDs) per level of abstraction

Another system dynamic outside of feedback loops is state. The behavior of an activity is not only a direct consequence of its inputs, but it also depends on its preceding state.

To model the state of each activity across an organizational system, we need to first look at the bigger picture by modeling integrated input/activity/output via Data Flow Diagrams (DFDs). (Note: DFDs are for modeling any inputs/outputs, not just data.)

There are separate modeling techniques to then model the details of the state of a given activity, such as transition state diagrams.

Another dynamic we typically need to model for organizational systems is non-linear activity. In complex organizational systems, except at the very detail level, there are often relatively few linear activities. Any activity can “kick-off” at any point in time, provided that its prerequisite inputs are present.

Modeling the non-linear activity dynamics of an organization is also a task of DFDs.

The above are just some of Systems Thinking considerations outside of feedback loops. There are others.

Likely sounds very natural to software developers, as computers and their operations are an excellent environment for analyzing as well as constructing complex system architectures.

I would readily believe that the skillful navigation between abstraction and specialization is the main mechanism/tool for approaching complex systems, where it’s about recognizing the true boundaries of parts and their interconnectedness/interplay. These are never necessarily static, nor are they exclusive (systems can overlap and interconnect on multiple levels), and sometimes the model is incorrect as well (Gödel: always either wrong or incomplete).

Simulations, flows, system dynamics, are all fine as a tool, but probably not that accurate, especially as one can never know for sure if the data/numbers are actually correct, as they’re measured/observed by some other systems (that might be subject to manipulation, malfunction, or confused setup) and usually calculated by formal logic, so it’s in my mind less about precise projections, and instead more about the rough, general causes, effects, properties, behavior, and how these develop over time, as cybernetics suggest.

But there are surely other perspectives/views/opinions/approaches to that as well, maybe collect and compare them somewhere? :slight_smile:

Disclaimer, full disclosure: I don’t have any formal training in this, current view/working-model is entirely from practice/application.

Have long since perceived that the perspectives on what systems thinking is actually outnumbers the number of persons contemplating the thought. At one time I actually thoughts systems thinking was just a not very gown up version of system dynamics… fortunately the thought evolved… try this one on for size…

1 Like

If anyone is groves on the Jackson model you can download the book from here. No I don’t know how it got there.

Stephan, the essence of real understanding lies in the recursive application of one question… And? That’s all there really is though people seem to want to complicate it endlessly.

1 Like

Stephan, Our conversation tweaked a thought and I just posted this to my network on LinkedIn…

“Because you understand one you think you understand two because one and one is two, but first you much understand and.” – Old Sufi Saying

Based on this I now surmise that the process for understanding just about anything is…

Step 1: And?
Step 2: Repeat Step 1

1 Like

If you think it would be helpful, maybe a little explaination/demo of recursion, exponential functions, downward + outward spirals, feedback loops, amplifiers (all more or less basically the same thing, in terms of patterns/algorithms I guess) could be collected/produced (likely already exists somewhere in some form – if so, let’s list/map/review), but then let’s take it to another thread, as this “Action” thread is about helping Tony to review his slides and provide feedback (ironically), except he says that your contribution here is in scope for what he’s working on as well.

I am quite willing to review the slides. Are they posted here somewhere and I missed them or are they on their way?


The slides are in a Powerpoint available for download at www.tonymar1556@.


Thanks Tony. I will take a look and provide some comments.


Regarding Recursion: Per organizational systems, recursion is the repeated application of a repetitive procedure through multiple levels of abstraction. Per the Viable Systems Model (VSM), there are six functions (i.e.,processes) that repeat through each level of abstraction: Operations, Direction, Coordination, Audit, Planning, and Identify.

My slide show sample organization system only includes operation related processes. I purposely left out the other five types to limit scope. (The presentation was originally intended for high school students, so I really wanted to be minimal.)

But I can expand upon the model to demonstrate what I believe are the basics of Stafford Beer (creator of the VSM) is saying about recursion. Go to slide 38 and look at the process labeled “Wrap and Ship Candy”. I can edit slide 39 to, to not only include that operation functionality, but an associated planning function like “Plan the Wrapping and Shipping of Candy”, an associated direction function like “Direct the Wrapping and Shipping of Candy”. etc, etc for coordination, and auditing. (If course I would also need to edit in the additionally needed interrelationships.)

Next, in slide 39, I drill down into “Wrap and Ship Candy”. I can edit slide 39 to, not only include the operation functionality shown, but, for each operation on that diagram, a planning function like “Plan the Labeling of Boxes”, a direction function like “Direct the Labeling of Boxes”. etc, etc for coordination, and auditing.

As an aside, notice what we would have here after the edits. Not only a description of the essentials of the VMS but, more importantly, we clearly now see, as we look across all slides, how the concept of recursion integrates with the other Systems Thinking concepts like equifinality, feedback loops, non-linear activities, etc, etc.

Hi Gene:

Any comments on my latest posting to Steve about recursion and the VSM?

Tony Markatos

I’m not getting the connection between slides 37, 38 and 39 and Beer’s Viable Systems Model. Maybe a small part of it. All 5 systems of VSM repeat at all levels. Most attempts to diagram it are hopelessly convoluted and usually rather wrong. Here’s one by Beer that’s almost comprehensible.


Thanks for the feedback. I agree about the complexity of the

Do you argee that the VSM just consists of chunks of functionality and their relationships?

And would you agree that the labels of the chunks vary depending upon the system being modeled?

And that Each line represents: a type of relationship (what type depends on which line in the model it is).

From my understanding the types of relationships are information, material, and energy?


Everything consist of chunks of functionality and their relationships.

The labels for VSM are always System 1 though System 5

As for types of relationships what’s the difference between material and energy? There are relationships which deplete the source and those that don’t.

Gene said: Everything consist of chunks of functionality and their relationships.

I agree. Add an overriding goal and we have a system.

Gene said: The labels for VSM are always System 1 though System 5

This counters my understanding. I will have to do some more digging. If the labels for the chunks are always System 1 through 5, then how do we know the goals per chunk are?
Material is like raw materials and inventory. Energy can take many forms including heat, light, and electrical. Each of these can be an input to a process just as much as information can.

Regarding your comment that “There are relationships which deplete the source and those that don’t.”
I can see your point here, but I tend to see relationships, for activity-centric models as input and outputs

Tony, I went though the presentation and I think you might fare better having someone else looking at it. I just no longer dwell in the mire. It takes far too long to try to get people to understand it and they really don’t care to anyway. Just work with them to build stories that are meaningful to them and enable them to realize how smart they already are… and stop making them feel stupid.


When I work with the user community I use stories. The presentation is for presenting the concepts of systems thinking - a different audience. I am not making people feel stupid.

You say you’re not making people feel stupid, how would you know? And how would you put the presentation together as a story?

What’s your thought after you watch the video at…


The question you pose towards the end of the Moments video is “What is the [overriding] problem?” We have problem in achieving our underlying aim (i.e., underlying basis per Ackoff). I can not figure out what the overall aim for the underlying system in the example is. Can you tell me what it is?