This blog post defines a general method and is the wrap-up of this series regarding Dissolution of problems in Complex Adaptive Systems.
- Define what the system is aimed for, what it needs to fulfil in its environment. Do not go into details. Our organisation for example needs to fulfil the needs of the market, i.e. to be fast and flexible.
- Define the agents that the system consists of and their interrelationship. The granularity is important, i.e. in our example with organisations, agents with interrelationships is too coarse. And when people are involved, the word People is a better word than Agent.
- If there is a history for our system within the environment, follow their interwoven history to get an understanding of changes in their interrelationship over time. This step is not mandatory, but gives a good understanding of when and when not the system could meet its aim, and makes it easier to find our set of principles.
- Define the principles, the what our system need to be able to do in order to meet the environment. When we have all principles needed, we have our set of principles needed for our system to do what it is aimed for.
- Negate the principles to become root causes, and negate the environment need to instead become the total problem description if we fail to fulfil any need. The latter is the start and the former the end of our Prefilled Root Cause Analysis Map.
- Ask why, why, why to get as many symptoms as possible within the Prefilled Root Cause Analysis Map. Finally, there will be symptoms connected to the root causes. A symptom can be connected to the problem description, another symptom or a root cause. Already performed root cause analyses done* for the system, are a great help here, to find the common symptoms. Try to find the most common symptoms within the system, since as you already found out, finding all symptoms in a complex adaptive system is impossible.
When the Prefilled Root Cause Analysis Map is filled in, it is easy to solve any problem within a malfunctioning system, by simply ask why, why, why, and find a symptom connected to the root cause(s) of the problem and change the system to instead fulfil the corresponding principle.
The hardest steps are the first ones, until our set of principles is defined.
Important to consider is that complex adaptive systems always need permeable boarders, making them flexible enough to adapt to changes in the environment it belongs to.
Dissolution of problems can also be seen as changing the complex adaptive system’s requirements and turning back the clock to zero and restart the system again. This means that it is not about closing a gap to a future state like in engineering metaphors. This is also Dr. Russell Ackoff’s thinking in one of his famous quotes about that neither trial-and-error or more depth on the scientific research on our organisations would help us find the solution to system problems, but dissolution of the problem will:
The best thing that can be done to a problem is to solve it.
The best thing that can be done to a problem is to dissolve it, to redesign the entity that has it or its environment so as to eliminate the problem. Such a design incorporates common sense and research, and increases our learning more than trial-and-error or scientific research alone can.”
– Russell Ackoff
This was the last blog post in this series. C u soon again.
Next “chapter” according to the reading proposal tree is the blog post about finding the root causes to queues.
*can also help to find the principles