Collaborative Solution Discovery

Focused Representations Help With Understanding Complex Systems

Understanding and creating complex systems, obviously, depends on the ability to represent what we are trying to understand or create. That’s necessary for our own understanding, and for supporting communication among members of the team working on the problem. The kinds of representations chosen are important. Just any old representation will not do. We need to focus on aspects of the problem that need our attention while holding other aspects in background. Representations are also tools for cracking the problems we face. A verbal representation may be accurate but nevertheless it may obscure the path to solving a problem,whereas a graphical representation of the same situation may make the answer obvious. If our problem is finding the shortest route from A to B, a verbal description of all the streets and roads we might take would contain all the information we need, but in a form difficult to analyze. A map of the same territory would be much more useful.

Focused representations include views that present selected aspects of the system while excluding others, various graphic and otherwise symbolic representations, as well as text and tables. All of these are tools for untangling complexity. This branch is a brief introduction to a vast field. Search available resources and use your imagination to expand the list.

Views

Views are representations of a system (Problem System, Solution-Discovery System, Solution-System, and so on) which emphasize one aspect of the system (or perhaps a few) while moving all the rest into background. This is helpful for understanding and communicating about a system because, in general, a system is characterized by many aspects, and having those all visible at once can be overwhelmingly confusing. Common views include those below and many more. Use discrimination in identifying possible views for your particular project and deciding which views are important. Select a set of views that is sufficiently complete, but sparse; that contains what is needed to fully describe the system, but nothing extraneous.

• Functions (What the system does)
• Form or Structure Elements (The entities of which the system is composed)
• Operating Scenarios
• Supporting Facilities
• Logistics
• The Operate-Evaluate-Assess-Improve Cycle
• System Life-Cycle (Design-Build-Operate-Improve-Dispose)
• System Processing Load vs. Capability (more below)

The “System Processing Load vs. Capability” view (above) is an illustration of views through the example of an Integrated Social Services Delivery System. That system is a prospective solution to the problem in a community where many people need a variety of assistance services but the availability of these services is fragmented among many government and non-profit delivery agencies. This makes it difficult for a potential client, who may need a combination of several services, to find where they can be accessed and then to put together an personalized program to deliver those services. The base of the system is a network assembled from the existing service providers in the community. To provide the needed level of service to clients, functions are added to the network of providers.

• Welcome potential clients at any of the service-provider locations where the client may show up.
• Assess the client’s need for services and create a program for their delivery
• Assemble the team of service providers who will serve the client.
• Assist the client’s progress through the specially tailored service program
• Monitor the client’s progress and make adjustments as needed

The effectiveness of this system depends in part on the capacity to serve clients being matched to the number and needs of the clients in the community. Ideally there will be neither bottlenecks nor excess unused capacity. Thus having a view displaying what the processing load and corresponding capacity are throughout the network is important. During solution design, a model of the expected client load, based on available data, would serve as a requirement to be met in establishing the service-provider network. During operation, the same view would be a metric of system performance, indicating where adjustments and improvements would be desirable.

Networks

A Network is a representation of a system in which the nodes or blocks represent entities in the system and lines or arrows between blocks represent directed. interconnections. A text description of the entity represented by a block can be displayed in the block, and a description of the interconnections can be attached to the line or arrow representing each interaction. Often this representation is used as a Flow Chart representing the functional architecture or the dynamic behavior of a system.

In a Flow Chart representing functional behavior, a four-interface format for the function blocks can be useful. The four interfaces are listed below and shown in the figure:

• Input products to the functional block (usually on the left).
• Output products from the block (usually on the right)
• Supervisory direction of control input (usually on the top)
• Energy and resource inputs (usually on the bottom)

A Flow Chart is often used in developing a model of a system. The various behaviors of the system being modeled are represented by the blocks in the flow chart, and the effects of each behavior on the others are represented by the interconnecting lines.

N-Squared Chart

The N-Squared Chart is a structured graphic for displaying all the interrelationships among N entities of similar type. The entity names, and perhaps descriptions as well, are entered in the blocks on the diagonal from upper left to lower right. The interrelationships are entered in the off-diagonal blocks as indicated by the blue arrows in the figure below. The effect of A on C, below, is indicated by the blue arrow in row A and column C.

An N-Squared chart is logically equivalent to a Flow Chart. It is particularly useful for depicting a system of many objects, each involved in many interrelationships with other objects. It is useful for analyzing the structure or architecture of a system by rearranging the order in which objects appear along the diagonal of the chart (see figure below) such that certain tell-tale patterns emerge. On the other hand, it is usually not as good as the Flow Chart for illustrating the dynamics of a system.

The two charts N-squared charts above represent the same system, with different ordering of the 7 entities on the diagonal. This illustrates an analysis of system structure. On the left, above, is a chart as initially laid out showing interrelationships among seven entities, A through G. In this version the interrelationships are scattered about and show no particular pattern. On the right, re-arranging the order of the entities on the diagonal reveals important system structure. Entities D, G and B make up a closely interdependent sub-system. A, C and E are a process flow sequence Entity F is an interfacing element connecting sub-system D – G – B with process sequence A – C – E.

If an N-Squared chart is constructed on a spreadsheet, a simple procedure can be used to switch places of any two entities on the diagonal, as a move in searching for identifiable patterns in the N-Squared chart.. Let’s say you want to interchange entities C and E on the chart above, left.

1. Create a blank square on the diagonal where entity E currently is, by inserting a new row and column through that blank square. The sequence of entities on the diagonal will now be A – B – C- D – Blank -E – F – G.
2. Move the row and column containing entity C to the new blank row and column. That creates a blank row and column where entity C used to be, and puts C between D and F.
3. Move row and column containing entity E to the new blank row and column that was just created.by moving C.
4. Delete the remaining blank row and column.

A macro can be created in the spreadsheet application to do this.

The Problematique

The Problematique is a Flow Chart (can also be an N-Squared chart) displaying all the causal factors that contribute to a problem, along with all the interrelationships among those factors. It is constructed by, first, compiling a list of all the contributing causal factors. Then all the causal relationships among causal factors are identified (of the form “Factor A contributes thusly to change of Factor B”). Each causal factor and each causal relationship is named and described. The Problematique may be displayed in either Flow Chart or N-squared Chart format.

The benefits of the Problematique are:

• Support to developing a complete and accurate understanding of the problem.
• A means to analyze the problem to locate the most effective points at which corrective effort may be applied in order to extinguish the problem.

The Problematique can also be used to map the relationships in the Definition of Success , supporting or conflicting, among the interests of the stakeholders. See Solution Search Path Step 2 for more on the Definition of Success.

Problematique: A Powerful Tool for Building Group Coherence

Creating the Problematique, as a group exercise among all the stakeholders in a complex, contentious issue such as border security can be very beneficial. Usually the various stakeholders have a rather narrow view of the problem, focusing on their own interests and dismissing or being ignorant of the interests of others. The process of building the Problematique can open eyes and build bonds of respect that have major benefit for the effort to find a good solution, that is, one that is both effective and enjoys broad support.

Hierarchies

Systems, in the Form or Structure view, generally appear as hierarchies. This web site is arranged in a hierarchy of branches, which you can explore in the sidebar at left by clicking on branch titles or up/down arrows.

A hierarchy has a single entity at the top, with several subordinate entities beneath it. The subordinate entities typically have several entities subordinate to each of them, and so on, as in the sketch below.

The relationship of a subordinate entity to the one just above can be one of two types: Subordinate-To, or Part-Of. The relationships in an organization chart for a large corporation are of the Subordinate-To type. The heads of various divisions of the corporation are subordinate to the C-Suite. The managers of departments in the divisions are subordinate to the Division Heads. On the other hand, the parts of a physical system like a car are of the Part-Of variety. The body and engine are each parts of the whole car. The block, crankshaft and pistons are part of the engine, and so on.

A hierarchy can be shallow or deep, broad or narrow, in various combinations. A shallow hierarchy has few levels while a deep one has many. A broad hierarchy has many elements in the level below each entity above, and a narrow hierarchy has few. When describing an existing system, there is little choice. The representation is determined by what is there, with some discretion about how a higher level is dis-aggregated into the level below.

When designing a system, the depth and breadth of the hierarchy are at the designer’s discretion, in order to achieve desired attributes of the product. Keeping a hierarchy narrow means the so-called “span of control” is small. That means an entity in a level above has few entities below it to keep track of. However, that choice may also fore the hierarchy to be deep, with many levels between top and bottom. In that situation communications up and down the hierarchy may be delayed, distorted or lost. A broad and shallow hierarchy has the opposite situation.

Cross-Links in a Hierarchy

Pure hierarchies are seldom found. More usually, there are cross links among elements at the same level, and up and down levels on different branches. In a large organization, cross-links among members at low levels are often forged informally for convenience and efficiency. Worker A in department 1 needs assistance from worker B in department 2, several branches away. The official path is for worker A to send a request up the hierarchy to the point where branches 1 and 2 originate, and then down to worker B. This takes time and often gets garbled or lost on the way. If workers A and B know each other, they can make an informal agreement and get the job going while formal authorization is pending. Wise management looks the other way when this helps the performance of the organization, while remaining on guard to avoid something negative.

Cross-links that also jump levels can be very complex and have interesting outcomes, both beneficial and detrimental. This often results in inversion of the hierarchy’s authority structure, and also can produce feedback loops that engender unanticipated emergent behaviors.

The Matrix

The Matrix is useful for depicting the interdependencies between two separate sets of entities. The Function-Element Matrix is one example. This matrix is constructed by labeling the rows of the matrix with the names of the Functions performed by the system, and labeling the columns with the names of the Form Elements of the system (or it could be the other way around). At the intersection of any Function-row with any Element-column, enter the contribution of that Element to performing that Function.

Graphs and Charts

The full variety of types of graphs and charts – line graphs,pie charts, bar charts, histograms, area charts scatter charts, bubble charts – the list is endless, are useful as both analytic tools and media for communicating information.

Project Management Tools

Graphic tools are useful for supporting project management. Common ones are Time-Task or Gantt charts for laying out a project schedule as a sequence of interconnected tasks, and Critical Path charts.

The Time-Task chart or Gantt chart is laid out with calendar time on the horizontal axis and the individual tasks spread out vertically. Tasks are represented by horizontal bars of length equal to the planned duration of tht task. The chart is built starting with the earliest or initial task at upper left. Subsequent tasks are added in order of the calendar time at which they start. Outputs from earlier tasks to later tasks are indicated by vertical arrows. A simple example is shown below.

For Critical Path management of a project, first build a task flow chart with inputs to each task coming in at left and outputs going out at right. In general, arrange tasks with time flowing from left to right, as with a Gantt chart. However, task durations are not shown graphically but are entered into each task block. Rigid adherance to time flow from left to right can be violated if it makes it easier to see the various paths through the entire project. For each possible pathway through the project, add up the sum of task durations on that path. Identify the longest duration path through the project’s task network. That path is the shortest time in which the project can be completed (think about it) and is called the Critical Path. Project management focuses on two goals: (1) making sure the longest or critical path does not grow in duration, and (2) making sure that other paths do not grow in duration to become longer than the current critical path.