Systems Thinking: Understanding the Whole and Not Just the Parts


I was very intrigued with this concept when I read it in the Business Analysis Body of Knowledge (BABOK). This concept is defined in the Underlying Competencies (chapter 8) of the BABOK. This concept is so powerful and if used more in organizations can produce remarkable events; however, I have found that Systems Thinking can only be utilized to its fullest potential if the culture of the organization allows for that. However, as business analysts this is a concept that we should have in our arsenal of tools as this concept can help to clearly identify the root cause of problems that need to be solved.

What is Systems Thinking?
According to the BABOK Systems Thinking is defined as: " Systems theory and Systems Thinking suggest that the system as a whole will have properties, behaviors and characteristics that emerge from the interaction of the components of the system, and which are not predictable from an understanding of the components alone. In the context of systems theory, the term system" is much broader than an IT system-it also includes the people involved, the interactions between them, the external forces affecting their behavior, and all other relevant elements and factors. " Most of the times as business analyst we think of systems as an IT system as we are typically writing requirements to either build a new system or enhance/alter an existing system. A system consist of interaction, interrelated and interdependent parts, I remember these are the 3 I's", that form a complex unified whole. To break that down more granularly is that a system consists of inputs into the system, resources and processes within the system, and outputs produced from the system. These are you interacting, interrelated and interdepending parts (refer to Figure 1 below).


Systems Thinking is not about just focusing on the parts of a system but rather focusing on the complex unified whole. This way of thinking is taking business analysts to the next level because it's not just about meeting deadlines to produce a result but rather how does that result you are producing fit into the organization as a whole.

Every system has a purpose, consists of parts that are arranged a certain way, can effectively react to change and for a system to be effective it must be stable. Systems Thinking is not just focusing on one part of the system but the entire system to ensure that it is a well-oiled machine. The danger of focusing on just one part of the system is that there is a potential of negatively impacting other parts of the system though the part being focused on is being improved. For example, in many of the industries I have worked in there a lot of systems that have band aids or some may call wrap around systems. Essentially what has happened is something has change in the organization and in order to accommodate that change a temporary system is built. The system built solves the problem at hand as a temporary solution; however, this solution becomes permanent because it's doing its job at hand. Therefore, no one goes back to the temporary solution to make the necessary changes to make it a permanent solution. After a while you end up with clusters of temporary systems to solve a permanent solution, which really doesn't solve the problem at all. Then you sit back and wonder, How did we get to this?" Well you got to it because no one thought about the consequences of not changing that temporary solution, the only thought was, we have a need now and we have to solve for it now. Systems Thinking is getting out of that way of thinking.

Systems Thinking allows organizations to:

  • understand the strategic vision of the organization as a whole

  • understand how the organization works and fits together as a whole

  • understand the problems in the systems and understand the consequences of how solutions to those problems can affect the whole system.

Systems Thinking is a wonderful way to understand the root cause of the problem. For example, if there is a town that continually has fire outbreaks just putting out the fires each time is not solving the root cause of why fires break out. The root cause could be that the town has no fire codes or the houses may not be equipped with smoke detectors. Putting out the fire is just a temporary solution but let's say the town implements fire codes this could potentially eliminate the fire breakouts. This is the beauty of Systems Thinking. It allows business analysts to determine the root cause of the problem and nip the problem at the root opposed to building out temporary solutions.

How can we apply this concept?
Let's take the example of the fire outbreaks:

  1. First, identify the event/problem. The event in this situation is the fire outbreak in the towns.

  2. Second, identify the patterns. By asking a series of questions patterns can be determined. For example, What similarities in the house are causing the fires?" What sections of the town are the fires breaking out?"

  3. Third, once the problems and patterns have been identified then determine what solution can rid of the problem.

Sounds pretty simple but it's amazing how often this is not done.

This is a powerful tool for business analysts to help implement better solutions. Start thinking about the projects you are working and ask yourself:

  1. Why are we doing this project?

  2. How does this project fit into the organization's strategic goals and long term vision?

  3. How will the solution I recommend or help build meet those strategic goals or long term vision?

  4. Am I solving for a temporary need and implementing a temporary solution, if so, what can I do as a business analyst to ensure that temporary solution doesn't turn into a long term solution? Or even better yet, why are we doing a short term solution for a long term goal? What's driving that need?

I do have to add that sometimes the answers to these questions are out of our control due to company culture but it never hurts to ask if your culture allows for that. In the long run you will be thanked.

Even if you have doing business analysis for years it's always good to step back and look at the projects you are working on and determine if the solution is really solving the root cause of the problem or just simply putting a band aid to get past an immediate need. Even if you have to put on a band aid for an immediate need it's good to go back and ensure that band aid has been removed and the long term solution is implemented.

Let's step our thinking up to the next level!!!!

Paula Bell, Business Analyst Certified, B2TAuthor: Paula Bell, Business Analyst Certified, B2T

Paula Bell is a Business Analyst, mentor and coach known for consistently producing exceptional work, providing guidance to aspiring business analysts (including those that just want to sharpen their skills), as well as providing creative and strategic ways to build relationships for successful projects. With 15 years in project roles to include business analyst, requirements manager, technical writer, project manager, developer, test lead and implementation lead, Paula has experience in a variety of industries including media, courts, carpet manufacturing, banking and mortgage. Paula has had the opportunity to speak on a variety of topics to include business analysis, project management, relationship building, diversity and software methodology.
[email protected]
The Journal of a BA and Much More

Like this article:
  8 members liked this article


Tony Markos posted on Friday, October 14, 2011 10:59 AM

This focus on systematic thinking really hits home! Focus not on stand alone requirements, but on the interrelationships between them. This is so foreign with alot of companie; but, ignoring such is very wasteful.

Essential interrelationships.....inputs/process/outputs. What, specifically, hands-on, are we talking about here? Let me say the dreaded words: Data Flow Diagrams. Only DFD's rigorously result in a systematic capture of input/process/output (the inputs and outputs are dataflows).

Interesting that you mention the BABOK. An information system can be composed of computers, people, or both. A requirements spec specifies the behavior of a system. The BABOK 2.0 specifies the behavior of a system consisting of one or more BA's accomplishing tasks. So, how does the BABOK specify the behavior of BA's? Answer: at a high level, with input/process/output diagrams (non-integrated).

Important Side Note: Unless specification is by INTEGRATED input/process/output diagrams (DFD's), the result is going to be very disjointed. This is what makes coming up with a systematic understanding of the behavior that the BABOK tries to communicate next to impossible.



Paula Bell, CBAP posted on Friday, October 14, 2011 7:32 PM
Thank you for comments Tony. I would have to agree that this is missed by so many organizations. I would also agree that DFD's can help us understand how those systems fit together.
zarfman posted on Tuesday, October 25, 2011 9:28 PM


Systems thinking is alive and doing very well in certain areas. The most
obvious examples are the aerospace industry, where control is required in
fly by wire positioning of ailerons, or in the optimal choice of trajectories in
space flight. The chemical industry requires good control designs to ensure
safe and accurate production of specific products, and the paper industry
requires accurate control to produce high quality paper.

I am asserting that applying systems thinking to an organization/economic entity is in general wishful thinking. I just don't see the necessary knowledge base.

Your figure 1 appears to be an open loop system. An example of an open loop system is an irrigation sprinkler system, programmed to turn on at set times could be an example of an open-loop system if it does not measure soil moisture as a form of feedback. Even if rain is pouring down on the lawn, the sprinkler system would activate on schedule, wasting water. Perhaps a better example would be a conventional washing machine, for which the length of machine wash time is entirely dependent on the judgment and estimation of the human operator.

What is required is a closed loop system. Consider a car's cruise control, a sensor monitors the system output (the car's speed) and feeds the data to a controller which adjusts the control (the throttle position) as necessary to maintain the desired system output (match the car's speed to the reference speed.) Now when the car goes uphill the decrease in speed is measured, and the throttle position changed to increase engine power, speeding the vehicle. Feedback from measuring the car's speed has allowed the controller to dynamically compensate for changes to the car's speed.

Organizations are dynamic systems with some form of feedback. Unfortunately, its components are made up of groups of individuals which are much harder to control than inanimate objects given politics,self interest and questionable competence . Moreover, organizations are highly suseptible to the infamous three part lag. First, one must discover the problem this may take days, weeks or months. Second, one must devise a solution this may take days, weeks or months. Third, did the solution work this may take days, weeks or months. If the solution fails go to step one.

Clearly, systems thinking relative to organizations has a long way to go.


Paula Bell, CBAP posted on Tuesday, October 25, 2011 9:56 PM
Thanks you for your comments Zarfman. Yes, I would agree that the full utilization of systems thinking is only as effective as how much an organizational culture will allow but I do believe it is a concept that business analyst can have in their toolkit to leverage to determine root cause. Also, my picture is depicting that systems have inputs into them, processes and resources within them and externally to them and outputs. There are also external factors that can impact that system in a variety of different ways and this is one way to understand the system as a whole.

I appreciate you reading the article and providing as I learn from these comments and different perspectives are great. 😊
Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC