Systems World

See "Advanced Systems Thinking, Engineering and Management," and "Putting Systems to Work," both by the author.

See also an INCOSE Tutorial, using RSM to Explore a National Nuclear Energy/Power Issue

The Nature of Problems

Problems come in many forms. Some, a very few, are of the type to which there is a correct, mathematical or scientific answer. Most, and the kind this section will address, are complex, multifaceted, and difficult to understand and analyze, let alone solve. Social and cultural problems are of this second kind. If a solution is supposedly found, then chances are that it will prove difficult to prove that the solution, if applied, will be guaranteed to solve the problem. And the problem is constantly changing.

It is in the nature of complex problems that they generally emerge from dynamic situations, so that potential solutions, to be effective, must be both dynamic and applied at the appropriate moment. The right solution at the wrong time will not work. Worse, it may exacerbate the issue and create distrust of the problem solving method/approach.

It gets worse! If a complex problem is multifaceted, then it is likely that any solution will be multifaceted, too. Human nature encourages problem solvers, once they have identified a plethora of problem facets, to prioritize and address (what they see as) the more important aspects first. Unfortunately, this often fails, as the many aspects must be addressed at the same time, else the problem simply changes nature and emerges in an altered form. This is an example of counterintuitive behavior, common in real-world, complex situations. See Forrester, J.W. (1972) Understanding the Counterintuitive Behavior of Systems, Systems Behavior, Paul Chapman Publishing

The Rigorous Soft Method (RSM):

• is a method for addressing problems or issues, using hierarchies of issue "symptoms."
• is a systems method, i.e. it addresses whole systems at once, rather than working piecemeal to address particular aspects of issues or problems.
• Identifies and characterizes the sources of complex issues and generates requirements for problem/issue resolution
• employs techniques, tools and methods to:
  • elicit issue "symptoms"
  • identify possible causes of those symptoms
  • group possible causes to identify higher level "themes
  • accommodate complexity, reduce entropy
• addresses the most complex/abstract/obscure of issues
• is suitable for team-based working
• is mathematically provable (sic!)

The Method

The figure above shows the method at high level, as a seven-step process. Each step invokes the use of particular techniques that are so chosen that the output from one technique forms the input required by the following technique. This moves the process forward. Each technique may also have an associated tool, perhaps to accommodate and handle information, perhaps to simulate/model developing systems and interactions.

Step 1. Nominate Issue and Issue Domain. It is helpful to avoid being too specific in naming the Issue. The Issue domain is the broad subject, area, region, category, etc., in which the Issue resides. In practice, it is sometimes necessary to enlarge the domain once the symptoms have been elicited

Step 2. Identify Symptoms and Factors. Symptoms are discernible changes from a previously satisfactory state. Factors are evident contributors to, or existing within, the Issue

Step 3. Generate Implicit Systems. Each symptom and factor implies that an imbalance has arisen between previously balanced systems. These are Implicit Systems

Step 4. Group into Containing Systems, Implicit systems are mutually related, since they form part of the same, overall Issue. Grouping the Implicit Systems, to form Containing Systems simplifies the Issue and moves the process to a higher level.

Step 5. Understand Containing System Interactions, Imbalances. Examine, model, the static and dynamic behavior of the Containing Systems

Step 6. Propose Containing System Imbalance Resolution. The Containing Systems and Interactions have captured the overall issue both at macro and at micro levels. Using the model as a guide, propose optional approaches to solve/resolve/dissolve the whole Issue. Trade off between the options by judging which addresses the imbalances and shortfalls most effectively.

• This step may involve creative thinking, together with simple logic and/or dynamic simulation to predict effectiveness, according to complexity and time available.

Step 7. Verify Proposals against Original Symptoms. An accounting process to ensure all the original symptoms have been addressed.

The figure above, then, summarizes the RSM, but there is rather more to it.

N.B. RSM was formerly known as the Hierarchical Issue Method (HIM), and is so referred to in "Putting Systems to Work."

Example Issues and Different Viewpoints

Before going into the RSM method, it is useful to understand the kinds of issues or problems that RSM might be used to address.

1. Concern about an organization's morale, but no obvious culprit. This is a vague concern, ideal for RSM
2. High-level parliamentary briefing required urgently, rebutting detailed criticism of a project. RSM automatically generates briefing material, essential in many situations to back-up or present findings
3. Partnership at risk of breaking up owing to lack of shared vision. RSM is well suited to addressing human issues
4. Differing views of causes for lack of organizational performance / effectiveness / efficiency. Conducting RSM is a team-bonding activity, resulting in rational consensus viewpoints
5. Complex equipment presents inconsistent fault symptoms. Although RSM is predominantly used to address "soft" issues, it works for complex hard problems too
6. Whether or not there should be a standing European Multinational Force.
   • RSM is invaluable for tackling such politically charged issues, since it provides an entirely rational, traceable solution and audit trail. Of course, the decision emerging from the use of RSM may not be politically or culturally acceptable, but at least the rational answer becomes clear.

This last bullet indicates why a method for addressing issues is so important. Those making difficult and important decisions need rational advice and support. They may choose to do something quite different, but at least that choice is made in the light of good knowledge

The Structure of RSM

RSM is made up from a number of simple techniques strung together. The choice of techniques is crucial to resolve vague issues

• each technique must move the process forward
• the output from the first must feed smoothly into second, and so on
• none should eliminate useful information
• each should encourage new ideas, understanding, especially that developing during the RSM process
• the whole must provide a clear audit trail
• the whole must exhibit rigor, i.e. clear, comprehensive, rationale
• ·yet, the whole must also encompass eclectic viewpoints, information, cultures

RSM Techniques

• System models. These provide simple hierarchy frameworks. Hierarchical system models reveal the relevance, significance and relationship between elements of information.
• Interpretive Structural Modeling, a technique for finding the relationships between objectives, attributes, projects, etc., using Saaty's pairwise comparison method, with computer support
• Cause-effect analysis works from Issue symptoms back to causes.
• Causal Loop Modeling, systems thinking technique, interrelates symptoms, promotes completeness, provides basis for computer simulation
• POETIC Politics, Organization, Economics, Technology, Inertia/Inactivity, Culture. The acronym identifies the various types of common causes of Issues, and is used for promoting completeness.
• Dynamic Systems Modeling object-oriented systems thinking, using computer simulation
• N2 and ©CADRAT: Organizational structure analysis and hierarchy shifting, with computer support
• System Diagramming high-level presentation technique

Each of the techniques is useful on its own, and may be used in other contexts. Strung together in the correct order, they provide a powerful suite of techniques for addressing the most complex of issues rigorously. Other techniques can be plugged-in, with care, e.g. Nominal Group Technique, particularly to assist with eliciting and structuring the issue symptoms at the start of the RSM process.

Warnings

• It does not follow that there is always a resolution to an Issue
• Using the full RSM takes time, patience and (ideally) a team of people with complementary backgrounds
• Those unfamiliar with such techniques may experience culture shock on meeting them for the first time, therefore
• Do not show all your analysis to a customer, unless they either ask, or challenge your results

Top of the page

System Models

Systems models are simple, yet powerful ways to organize information and perceive relationships. Perhaps the simplest system idea is that systems are made up of other systems.

• Systems exist within systems exist within systems ad infinitum
• Babushka Russian Dolls fit one inside one inside one
• In general, systems fit several related subsystems inside one system

The System Model

The figure below - often called the poached-egg model - shows the first system model, defining hierarchy, relationship, containment, environment, etc. A System of Interest is seen at bottom right, containing 3 intra-connected subsystems within a contained environment. The System of Interest (SOI) has 3 sibling systems, i.e. they are at the same level of hierarchy and within the same Containing System. All 4 siblings are interconnected, directly or indirectly through another sibling. They coexist within an Operating Environment. The Containing System exists itself within a wider environment, and is interconnected to other Containing Systems, not shown.

Organizing things, or information about things, into systems diagrams greatly reduces perceived complexity and may, in some cases, even be sufficient to resolve an Issue.

A hard view of the world places any system uniquely in one Containing System.

• module in subassembly, subassembly in assembly, assembly in unit, and so on...
• letter in a word, word in a page, page in a book, book in a library...
• soldier in a platoon, platoon in a regiment, regiment in a devising

On the other hand, a soft view of the world allows "simultaneous multiple containment" in more than one Container. For example, a bus driver driving a bus may be contained within,

• a social group within the bus,
• his/her trade union
• his/her family,
• the local church,
• an ethnic group.

Any or all of these Containers may influence the bus driver's thoughts and actions.

The figure below shows a developed view of the rigorous Soft Method using the terms from the poached egg model.

 

How does RSM work? The General Practitioner Approach

The underlying reason why RSM works can be explained by analogy to the way in which a doctor diagnoses patient illnesses. If a patient feels out of sorts, but has no specific idea of what is wrong, the doctor faces a dilemma. The human body is extremely complex, with many interconnected and interacting organs, so that symptoms often occur where the problem isn't (sic!). Moreover individual symptoms may have a plethora of possible causes. Spots on the chest could indicate heat rash, food poisoning, an infection, allergic reaction to some unguent, and so on. How does the doctor sort things out?

A visit to the doctor might go something like this:

"Doc, I don't know what's wrong, but I feel out of sorts"

The doctor looks for symptoms

• "What do you do, what has happened to you recently?" i.e.
• checks for environmental factors and recent changes, pains, breathlessness, etc.
• checks for deficiencies, excesses, out of balances
• urine, blood, electrolytes, sugar levels, etc.
• spots, discoloration, temperature, bloodshot eyes, etc.

The greater the variety of symptoms, the greater prospect of accurate diagnosis

One way in which the doctor might work is as follows

• postulate potential causes for each symptom on its own, e.g. which organs might have been affected/upset
• hen look for organs which are common to several or all symptoms
• hence locate the most likely focus of the problem, and
• formulate a diagnosis
• verify that the diagnosis explains all the symptoms (if not, then either the diagnosis may be wrong or the patient may have more than one problem)
• using his/her knowledge of the human body, this patient in particular and the effects of possible medications/surgical procedures, proceed to recommend a treatment, or
• refer the patient to a consultant

Hence diagnosis emerges, not from one symptom, but from many. The more symptoms, the more likely is it that a sound diagnosis and treatment will Emerge.

RSM operates on similar lines. Essentially, each symptom emanates from a different problem space within the overall Issue Space. Several symptoms indicate different problem spaces, some of which may overlap. The more symptoms, the more refined and confirmed becomes the area of overlap, indicating the validity of the diagnosis. In keeping with the diagnostic analogy, symptoms are considered to result from imbalances between "organs", or implicit systems

The meaning of "Implicit"

Implicit systems, those implied by symptoms, may exist in practice, but need be neither tangible nor coincident with an organizational boundary. For example

• A system for maintaining discipline
• A system for marketing
• A system for supplying power
• A system for leading the team
• A system for fomenting disorder

Related implicit systems are implied by the symptom

• "low efficiency" implies a system for undertaking work and a system for judging the effort expended against some norm.
• "Lack of plans" implies a system for planning and a system for requiring/using plans

Practice shows that starting the description of an implicit system with the words: "A system for" results in a useful, soft description of a purposeful/purposive system

Getting started - finding Issue Symptoms

Symptoms are indications of change from a previous, supposedly satisfactory state

Symptoms can be found by:

• asking questions,
• interviewing,
• reports,
• statistics
• observation
• intelligence

Some symptoms arise from lack of cooperation (synergy) between the various people/parts in a complex system where, perhaps, cooperation previously existed. Lack of cooperation may extend to antagonism.

Other symptoms arise from culture - people caught in the trap of their experience, unable/unwilling to see other viewpoints

Symptoms Arise where the Problem Isn't

The figure below shows why working from individual symptoms to causes may prove difficult, as any doctor will confirm. At the left of the figure are two diagrams indicating that, when systems provide outflows to other systems, changes in the upstream system reveal themselves, not at source, but in the downstream system.

The diagram at the right shows graphically that, with a set of interconnected systems, it is possible for the symptom to emerge just about anywhere. Diagnosis difficulty is compounded when it is realized that the diagram represents a dynamic system, with all the inflows and outflows varying continually even when there is no problem.

Scientists and engineers diagnose faults by isolating each expected subsystem, feeding test inputs and checking for expected outputs. In the real social and political world, it is not possible to isolate, to stop the action and perform tests. Diagnoses have to be made on the fly during live action.

Symptoms appear where the problem isn't

What causes symptoms?

As the figure indicates, symptoms often occur where the problem isn't

• Pain in left arm from heart attack
• Poor performance from lack of training
• Poor reception from weak transmission

Symptoms arise due to an imbalance between previously balanced system pairs:

• Pain from imbalance between system for supplying blood and system for energizing muscles
• Poor performance from imbalance between system for setting training needs and system for training
• Poor reception from imbalance between system for generating signals and system for receiving signals

One symptom may arise from several causes/imbalances

• Pain in left arm from imbalance between system for sensing pain and system for suppressing pain
• Poor performance from imbalance between system for directing personnel and system for following directions
• Poor reception from imbalance between system for amplifying signals and system for suppressing noise interference

The "How-can-we"s

Symptom categories emerge according to question posed.

• "How can we?" elicits perceived current barriers to improving group situation/performance/effectiveness, efficiency, quality, etc. This is generally helpful in understanding how to improve situations
• "What do you think is wrong?" elicits parochial views, cultural perceptions, pet cures. Some of these may be unhelpful and inaccurate - but it is difficult to be sure.

Responses convert to symptoms

• "How can we become more efficient?" - perceived low efficiency
• "How can we improve morale?" - perceived low morale
• But - "I think that the management doesn't know what it is doing" - lack of confidence, low morale?
• and - "I think we should change our suppliers - they're hopeless!" - pet cure, may be incorrect diagnosis, but worth following up?

The Five Whys

Popular in Japan - ask why up to five times

• Why are you inefficient? Because we waste effort
• Why do you waste effort? Because we don't plan carefully
• Why don't you plan carefully? Because we are in too much of a hurry
• Why are you in too much of a hurry? We're trying to do too much with too few people in too little time
• Why are you trying to do too much? We underestimate the amount of work needed to address tasks properly

Real causes of inefficiency:

• overstretched resources - imbalance between resource estimation and tasks

Locus of Possible Causes

For any given symptom there may be several potential causes - generally, it is impossible to be sure. It is important, therefore, to identify all possible causes, treat all as suspect - hence, there is a "locus of possible causes" within which the real cause(s) must lie.

This suggests that there may be redundant information in the process: later RSM steps will sort probables from possibles.

Top of the pageRôles for CLM

Causal Loop Modeling is a powerful technique with uses beyond RSM. However, within RSM, CLM has three main rôles

• Rôle A: Developing CLMs from laundry lists of possible causes identifies additional possible causes
• Rôle B: Developing CLMs from pejorative possible causes. produces Ideal World models directly.
• Rôle C: CLM is ideal start point for iThink™/STELLA™ or similar dynamic modeling tools

Laundry Lists and CLMs

The two figures show a Laundry List example. If asked, what is the cause of perspiration. Most people would produce a list of possible causes, referred to as a "laundry list." As the figure indicates, the possible causes may not be mutually independent - we are missing something

From Laundry Lists to CLMs

Because the causal factors for perspiration are not independent, their relationship may be identified and used to form Figure 9. Seeing the relationships can add greatly to understanding. Given the causal loop model, we may even be able to answer questions:

Q. Should a marathon runner about to run in a humid climate drink more or less water than usual?

A. From the CLM, higher humidity means less evaporation, i.e. more sweat lost as droplets without extracting latent heat of evaporation (vaporization). Hence the marathon runner will need more water in the humid environment, since some of the body water lost to perspiration is unable to do its job of cooling the body.

Creating CLMs

Causal loop models are straightforward to produce, provided simple rules are observed:

1.     Identify the symptom

2.     Establish a Laundry List of contributing factors, including organizational, technological, cultural, political, economic, etc., according to Issue

3.     Develop a series of simple CLMs combining contributing factors, using nouns or noun phrases only and dropping any features from the Laundry List which suggest bias, such as 'low', 'heavy', 'poor', 'hot', etc.

4.     Integrate the set of simple CLMs into a fuller single version, including the Entity to be modeled.

Difficulty may arise if, instead of starting with several simple loops, the novice tries to combine all factors in a single loop from a standing start.

Exploring CLMs, if Necessary

Causal Loop Models are all very well but they have limits. For instance:

• how long does it take to go round?
• can behavior represented by loops be unstable?
• interactions between loops can be difficult to interpret

Sometimes it is helpful to dig deeper

iThink™/STELLA™ is a convenient tool for next-level analysis - there are may others

STELLA™ and the Control CLM Archetype

The figure presents an analysis of the archetypal control CLM. The Stella™ version of the CLM is shown at top right. It consists of two reservoirs, one each for Resources and Performance Level; the assumption must be that applying a remedy invokes the use of some resource. In the STELLA™ model, the gap is represented as a difference between some desired performance level and the level in the Performance reservoir as it rises, drawing upon Resources via some (resource) Allocation Rate, which is proportional to the Gap.

The graph at the bottom of the figure may seem surprisingly complicated. The reason for this is that the large initial gap causes the Resources to run dry. As Resources are replenished from some external source, they are instantly allocated to Performance Level, which rises until the Allocation Rate is less than the Resupply Rate. From that point on, the Gap is reduced without restriction to zero.

So, the "behavior" of the simple control CLM, as revealed using STELLA™, turns out to be not so simple as might be anticipated. This, of course is the value of using STELLA™: It reveals the likely behavior of systems, dispelling overly simplistic expectations.

From Symptom to Implicit Systems

Sometimes it is straightforward to go from a symptom direct to the implicit systems that must be in some state of imbalance either within themselves or in their mutual interchanges

• e.g. low power may be caused by inadequate generation or excessive consumption

At other times it is less obvious,

• e.g. locus of possible causes for low morale, poor performance, inefficiency

In latter cases, a method for "thinking aloud" is useful. This method will be using the symptom "low efficiency" as an example. First, it is important to put sensible limits on depth and detail, to avoid excessive analysis.

If a symptom appears to emerge from within a single system, rather than from between two systems, the decomposition is insufficient

• e.g. symptom - "power failure". It may be inadequate to say it emanates from a single system for supplying power. Dependent on context, this is likely to give inadequate diagnosis.
• e.g. symptom - "power failure". Causes might be an imbalance between a system for generating power and a system for conveying power, or between a system for supplying energy (mains, battery, petrol engine, etc.) and a system for generating power. This approach gives diagnosis which may be sufficient in context

Identifying imbalance between pairs of implicit systems determines minimum analysis depth

Template for Generating the Locus

Since the process of generating implicit systems via the Laundry List and the CLM is so important, a template is useful to guide and standardize the work that might be done in parallel by team members working on an Issue.

P.O.E.T.I.C. Likely Causal Agents

The Template shows the term POETIC at the left-hand side. This acronym is used as a guide, or aide memoire, to suggest the likely origin of possible causes. When trying to conceive possible causes of any symptom, it helps to run through the elements of POETIC to jog ideas and memories. Figure 18 amplifies the various elements of the acronym and shows how the various factors interrelate. At the center is Culture, perhaps the most intractable of all causes.

Top of the page

Tackling the Complexity

At this stage in any RSM process it is likely that a large number of implicit systems will have been generated. This may provide a rich picture of the Issue, but it is highly unlikely that such variety and profusion of implicit systems and likely causes can be sensibly addressed by normal intelligence.

The complexity problem is tackled by grouping implicit systems, and their symptomatic imbalances into groups and by identifying those groups as individual Containing Systems. This represents a hierarchy shift from detail to macro-view.

With many fewer groups (Containing Systems), it may be practicable to appreciate, understand, and propose sensible resolution of the Issue.

Synthesis by Hierarchical Aggregation

The figure shows the rationale behind the hierarchy shift. At the Lower Level in the figure, the implicit systems are shown shaded. They have been generated by Issue Symptoms, which are shown as arrows between their respective Implicit systems - ;since the symptoms represent an imbalance. At right and left are systems to which the Implicit Systems may be connected, but which are not directly impacted by the Issue.

At the Higher Level, the plethora of implicit systems has been aggregated into just 3 Containing Systems, by identifying groups of implicit systems that form themes. The greatly reduced number of Containing Systems still contain all the original symptoms and their probable causes, but appear in much simpler form - ;one which, perhaps, a person or team can understand and address sensibly, without being confused by complexity.

Grouping and Clustering Implicit Systems

It is possible to group implicit systems using simple, obvious techniques such as the so-called "blob method" - ;see figure.

At top left, 6 implicit systems, A to F, are shown with their connections. At bottom right, they have been simply rearranged, without any change in connection logic. As a result of the rearrangement, it is evident that there are two distinct, but joined, groups, ABC and DEF. Putting a boundary around these two groups and naming them enables the complexity to be reduced from 6 interacting systems to only 2 interacting systems.

Unfortunately the blob method becomes unwieldy above 7 to 10 blobs. Moreover, the simple example shown in the figure divided conveniently into two groups. Real situations may have dozens of implicit systems, and the manner of their grouping may be neither obvious nor unique. A scientific approach is needed to deal with this situation.

As an alternative to the blob method, it is useful to employ the N2 Chart, on which Interacting systems can be presented as square matrices. Imbalances then appear in off-diagonal squares. This provides a matrix structure offering major reduction in perceived complexity

From Imbalanced Systems to N2 Chart

The figure shows how the example of corporate efficiency, above, looks when plotted into an N2 chart.

Measuring Disorder, Evolving Order

The figure illustrates how the N2 chart may be used to reduce Configuration Entropy, i.e. simplify the pattern of implicit systems. This is how the hierarchical shift shown above can be effected scientifically and mathematically. The figure is explained as follows,

• At top left is a notional collection of interacting, imbalanced implicit systems, A to F.
• These systems and interconnections are mapped into an automated N2 chart, top right
• At bottom right, the N2 chart has been reconfigured, using a genetic algorithm to minimize the disorder in the pattern. That the pattern is more ordered is visible to the eye and, indeed, it is quite straightforward to order the pattern without the genetic algorithm - ;that simply makes the process quicker.
• At center left, the N2 chart has been mapped back into the systems domain, where the degree of simplification is obvious by comparison with the original above it.
• Finally, at bottom left, it is possible to identify 3 inter-linked Containing Systems, so achieving the simplifying hierarchy shift from top left to bottom left of the diagram
• The N2 matrix is scored by multiplying the value in each interface by its distance in squares from entity
  • Upper matrix scores 86
  • Lower matrix scores 28, less than one third.

Interpreting Clusters as Sets - the Node or Nexus

The figure shows one of several archetypal patterns which interfaces may reveal in an N2 chart. Interfaces are shown as shaded, and the set of shaded interfaces forms a cross, centered on System D in the figure. This is the node or nexus: all systems have an interface (imbalance) with System D, and only with D. In some ideal case, System D would be the sole Issue source (c.f. the one organ to which all symptoms point)

The node always forms a cross on the N2 chart - the members of the cross form a Containing System. Where an N2 chart forms a partial cross, i.e. there are interfaces missing, it may be that the gaps identify a weakness in the analysis of symptoms, which can then be rectified.

Interpreting Clusters as Sets - Other Patterns

The figure shows another common archetypal pattern formed in N2 charts.

• Functionally-bound blocks have all (or most) of their mutual interfaces active each system is mutually interdependent on the others. The locus of possible cause may exist within the set, but there is no node.
• Waterfalls characterize suspect chains of command and reporting
• System C is a (suspect) "post-office" between two functionally-bound blocks

• Systems A and B form a functionally-bound pair or perhaps form a continuation of the waterfall
• Where a functionally bound block has some missing interfaces in a largely filled-in block, there is a suggestion that something has been overlooked in the symptom analysis. This can be examined and rectified at this stage.

Clustering the N2 chart, then, is not simply a matter of reducing configuration entropy. It is also an opportunity to detect and correct errors and omissions.

Disjoint Sets

The figure shows one further important pattern, disjoint sets. The figure shows two blocks, but there are no connections between the blocks. This suggests that there are two independent sets of implicit systems, which may indicate that some of the original symptoms referred to a different Issue. This would not be unusual: symptoms may be gathered willy-nilly, or without particular care or understanding at the outset.

Alternatively, it may be that the symptoms all correspond to the one Issue, but that the analysis has somehow been inadequate. Summarizing,

• A,B,C  and E,F,G are disjoint sets (no interfaces/connections) Either
• a relationship between sets is missing, or
• Either two sets are at different hierarchy levels, or possibly
• A symptom has been addressed which does not relate to this Issue

Containing Systems

The figure shows a practical example of a clustered N2 chart. The example is taken from a genuine business partnership. The program limits title lengths. The number '2' arises where an interface has been identified twice. As can be seen, the pattern of interfaces in the N2 chart does not form perfect archetypal patterns. There are no disjoint elements. However, partial nodes are evident, together with several incomplete functionally bound blocks. A partial node is evident at position 13, and a lesser structure is formed around B and D as a pair. On the other hand, 18, 19 and 20 evidently form a clean grouping, as only one pair of interfaces connects them to the rest.

The dotted horizontal lines delineate the Containing Systems. While the lower line is unarguable, the upper line is less so. Its placing is decided by observing the best association between the implicit systems

Wherever the lines are placed, they form Containing Systems, which are then given titles that sensibly describe the nature of the respective grouping. Interfaces that cross the horizontal lines signify connections between Containing Systems.

Modeling Containing Systems

Having achieved the hierarchy shift, each Containing System can now be modeled in its turn, using its implicit systems as symptoms - remembering that implicit systems are those with suspect problems. From the figure, for example: -

• Marketing/selling "inadequate marketing and selling"
• Group synergy "inadequate group synergy"
• Skills diversity "inappropriate skills diversity"
• Team Training "inadequate team training"

For each Containing System, convert implicit systems into a laundry list of possible Issue Causes

• System for coordination - (suspect) poor coordination as cause of (In)efficiency
• "System for waste reduction" - (suspect) excessive waste as cause of (In)efficiency

Then execute the same process as for each implicit system

• model each Containing System to understand how it works
• use CLM -;closure for completeness of symptom
• Back up with STELLA™ if needed
• Link Containing Systems to develop SID
  • identifying links between clusters on N2
  • creating links to represent perceived deficiencies
  • Two interaction (deficiencies) are v. likely to exist between each and every pair of Contained Systems - each identified/reasoned interaction should be represented

Top of the pageSystem Interaction Diagram

Having explored each Containing System, it is now possible to develop the Systems Interaction Diagram, which shows the interacting Containing Systems.

The example concerns itself with some military force providing Air Support. There have been problems of untimely weapon delivery, inaccuracies and Blue-on-Blue casualties. Three Containing Systems have been identified, complete with their shortfalls and interaction deficiencies. The whole SID presents a catalogue of problems, or (taking a more positive attitude) a list of requirements which, if met, should greatly improve the overall provision of Air Support.

Establishing the Requirements

The SID summarizes (likely) Issue sources. Each of the statements in the SID expresses a deficiency,

• Containing Systems deficiencies propose their own remedies
• Interaction deficiencies between Containing Systems propose their own remedies
• A matched set of Issue-resolving requirements emerges
• Optional remedies are proposed - there are generally many ways to skin a cat(!)
• Each of the optional remedies is tested against original symptoms to verify satisfactory outcomes, completeness and relevance

N.B. All requirement need to be met - to meet only some is to risk counterintuitive response from Issue systems. It may be the case that many of the deficiencies have to be remedied in parallel, rather than in sequence according to some arbitrary priority scheme. At other times, it may be evident that there are key deficiencies which, if remedied, will result in a domino resolution of other deficiencies.

Where such doubts exist, it is useful to develop a dynamic simulation from the SID. This is done using the Containing Systems' CLMs as a precursor to the dynamic simulation. Once the simulation is in place, different remedies can also be simulated, applied and compared. That which best meets satisfies the original symptoms is the preferred remedy.

What happened to the Uncertainty?

The locus of possible causes encompassed all possible sources of Issue, including some which were probably not at fault. The hierarchy shift focuses on Containing Systems, and their interaction: this is a perspective shift from (e.g.) tactical to strategic, from micro to macro. Requirements, which are generated at macro-level, should address underlying weaknesses and shortcomings. They are unlikely to concentrate on specific and incorrect  cause, but they could overlook some genuine, detailed cause.

Verification against initial symptoms therefore ensures requirements are-

a. necessary

b. sufficient

Interestingly, this also means that RSM is forgiving of minor errors, particularly in the early stages

Conclusions

We have introduced the Rigorous Soft method RSM is a powerful, heavyweight tool, to unravel substantial issues. As with any advanced tool, it takes practice to become familiar with RSM. The method works well with heterogeneous teams, whose members bringing a broad background to the table. Team members take time to bond, so first results may fall short of expectations.

In fact, of course, RSM is a context-free method, so that the outputs from it are governed to a major extent by the data fed in by team members. Choosing the right team to use RSM may be a key issue in its own right.

Top of the page

Updated 2007

http://www.hitchins.net