Identifying and Understanding Problems and Opportunities

According to (Checkland 1999, p. 140), Jenkins states that the first step in the Systems Approach is “the recognition and formulation of the problem”. A hard system approach begins from the assumption that there is a problem to solve. The phrase "problem or opportunity" used herein recognizes that the "problem" need not be a negative one, but could represent a positive oppourtunity to develop a system. In a sense, the "problem" is that there is no system to take advantage of this new opportunity. This article will summarize problem and opportunity exploration as described by (Edson 2008) and others.

Introduction

The Systems Approach described in the SEBoK is predominantly a hard system approach. The Analysis, Synthesis and Proving parts of the approach assume a problem or opportunity has been agreed to and an Engineered System needs to be developed to address that need.

The Problem and Opportunity part of the approach has some overlaps with soft system approaches. This is discussed in more detail below. This article briefly discusses the nature of Problem and Opportunity exploration. Any of the activities described below may need to be considered concurrently through the systems' life, as discussed in the Applying the Systems Approach article.

Soft Problem Exploration

Soft System Thinking does not look for "the problem", but considers a problematic situation. Forming systems views of this situation can help stakeholders better understand each other's viewpoints, and provide a starting point for direct intervention in the current system context. If a full soft systems intervention, such as Soft Systems Methodology (SSM) (Checkland 1999), is undertaken, this will not include formal Analysis, Synthesis and Proving. However, the SSM method was originally based on hard methodologies, in particular (Jenkins 1969). It follows the basic principles of a systems approach: "analysing" conceptuals models of shared understanding; "synthesising" intervention strategies; and "proving" improvements in the problematic situation.

Often the distinction between hard and soft methods is not as clear cut as the theory might suggest. Checkland himself has been involved in applications of SSM as part of the development of Information System Design (Checkland and Howelwell 1998). It is now agreed by many that while there is a role for a "pure soft system" approach, the service and enterprise problems now being tackled can only be dealt with successfully by a combination of soft problematic models and hard system solutions. (Mingers and White, 2009) give a number of relevant examples of this, including (Checkland and Winters 2006). Thus, it might be expected that Systems Engineering problems will be stated, solved and used as part of a predominately soft intervention. The will place pressures on the speed of develoment needed in the solution space. This is discussed more fully in the article Life Cycle Models.

The critical systems thinking and multi-methodology approaches (Jackson 1985) take this further by advocating a "pick and mix" approach in which the most appropriate models and techniques are choosen to fit the problem rather than following a single methodology (Mingers and Gill 1997). Thus, even if the hard problem identification approach described below is used, some use of the soft system techniques (such as rich pictures, root definitions or conceptual models) should be considered within it.

Hard Problem Exploration

Hard System Thinking is based on the idea that a problem does exist which can be stated by one or more stakeholders in an objective way. This does not mean that hard systems approaches start with a defined problem. Exploring the potential problem with key stakeholders is still an importnat part of the approach.

According to (Blanchard and Fabrycky 2006, pp. 55-56), defining a problem is sometimes the most important and difficult step. Defining a problem is asking the questions: What needs to be improved? What is the purpose of the system to be defined? Sometimes a problem is known as a “need.” In short, a system cannot be defined unless it is possible to define what it is supposed to accomplish.

According to (Edson 2008, pp. 26-29), some of the questions that need to be asked are as follows:

First, how difficult or well understood is the problem? Problems can be “tame,” “regular,” or “wicked.” The answer to this question will help define the tractability of the problem.

For tame problems, the solution may be well defined and obvious.
Regular problems are those that are encountered on a regular basis. Their solutions may not be obvious, so serious attention should be given to all aspects of them.
wicked problems (Rittel and Webber 1973) cannot be fully solved or perhaps even fully defined and it is not possible to understand the full effect of applying systems on the problem.

The next factor that needs to be considered is who or what is impacted? There may be elements of the situation that are causing the problem, other elements that are impacted by the problem, and other elements that are just in the loop. Beyond these factors, what is the environment and what are the external factors that affect the problem?

Finally, what are the viewpoints to the problem? Does everyone think it is a problem? Perhaps there are conflicting viewpoints. All these viewpoints need to be defined. Persons affected by the system, stand to benefit from the system, or can be harmed by the system are called stakeholders. (Wasson 2006, pp. 42-45) provides a comprehensive list of stakeholder types. The use of soft systems models can as discussed above can form an important part of this. Describing a problematic situation view can be a useful model to help consider these issues, even if a single problem perspective is selected for futher consideration

operations research is a hard systems method which concentrates on solving problem situations by deploying known solutions. The Problem Analysis step of a typical approach (Flood and Carson 1993) asks questions about the limitation and cost of the current system, to identify efficiency improvements that need to be made.

Traditional systems engineering methods (Jenkins 1969) tend to focus more on describing an abstract model of the problem for which a solution is sought in terms of the benfits stakeholder expect to see from that solution. The expectation is often that a new solution must be created, although this need not be the case. Jenkins suggest that System Engineering is just as applicable to redesign of existing systems. An important factor in defining the desired benefits is the scenario in which the problem or opportunity exists. (Armstrong 2009, p. 1030) suggests two scenarios: The first is the descriptive scenario. This is the situation as it exists now. The second is the normative scenario. That is the situation as it may be some time in the future. Armstrong suggests that this may be the most difficult part of the problem or opportunity (Armstrong uses the term "issue") to define.

Problem Context

The System Context article identifies the concept by which a complex system situation can be resolved around a System of Interest. The inital identification of a "Problem Context" can be considered as the outcome of this part of the systems approach.

An initial description of the Wider System of Interest and Environment serves as the problem or opportunity. Desired stakeholder benefits are expressed as outcomes in the wider system, and some initial expression of what the System of Interest is for may be identified. Jenkins (Jenkins 1969) defines a problem formulation approach where one:

States the aim of the system of interest
Defines the wider system of interest
Defines the objectives of the wider system of interest
Defines the objectives of the system
Defines economic, information and other conditions

The practice of systems engineering described in the SEBoK follows the important principle that problems and opportunities exist in an engineered System Context.

Linkages to other topics

None.

References

Citations

Armstrong, Jr., James E., 2009. "Issue Formulation". In: SAGE, A. P. & ROUSE, W. B. (eds.) Handbook of Systems Engineering and Management (2nd ed.). Hoboken, NJ: Wiley.

Blanchard, B. & Fabrycky, W. J. 2006. Systems Engineering and Analysis, Upper Saddle River, NJ: Prentise Hall.

Checkland, P. 1999. Systems Thinking, Systems Practice, New York, NY, USA: Wiley.

Checkland, P and Holwell, S. 1998. Information, Systems and Information Systems: Making Sense of The Field. Wiley.

Checkland, P and Winter, M. 2006. "Process and Content: Two Ways of Using SSM". Journal of Operational Research Society, 57 (12), 1435-1441.

Edison, R. 2008. Systems Thinking. Applied. A Primer. Arlington, VA, USA: Analytic Services.

Flood, R. L., and Carson, E. R. 1993. Dealing with Complexity: An Introduction to The Theory and Application of Systems Science (2nd ed.). New York: Plenum Press.

Jackson, M. 1985. "Social Systems Theory and Practice: The Need for A Critical Approach". International Journal of General Systems. 10, p. 135-151.

Jenkins, G. M. 1969. "The Systems Approach", in Beishon, J and Peters, G. (eds) Systems Behaviour (2nd ed.). New York, NY: Harper and Row.

Mingers, J and Gill A. 1997. Multimethodology: Theory and Practice of Combining Management Science Methodologies. Chichester, UK: Wiley.

Mingers, J and White L. 2009. A Review of Recent Contributions of Systems Thinking to Operational Research and Management Science, Working Paper 197. Canterbury, UK: Kent Business School.

Rittel, H. and Webber, M. 1973. "Dilemmas in a General Theory of Planning," pp. 155–169, Policy Sciences. Vol. 4, Amsterdam, Netherlands: Elsevier Scientific Publishing Company.

Wasson, C. S. 2006. System Analysis, Design, and Development, Hoboken, NJ: Wiley.

Primary References

Blandhard, B. & Fabrycky, W. J. 2006. Systems Engineering and Analysis, Upper Saddle River, NJ, Prentise Hall.

Edson, R. 2008. Systems Thinking. Applied. A Primer. Arlington, VA, USA: Analytic Services

Additional References

Flood R. and Jackson M. 1991. Creative Problem Solving: Total Systems Intervention. London, UK: Wiley.

Armstrong, Jr., J.E. 2009. "Issue Formulation". In: SAGE, A. P. & ROUSE, W. B. (eds.) Handbook of Systems Engineering and Management (2nd Ed.). Hoboken, NJ, USA: John Wiley & Sons.

Blanchard, B. & Fabrycky, W. J. 2006. Systems Engineering and Analysis. Upper Saddle River, NJ: Prentise Hall.

Checkland, P. 1999. Systems Thinking, Systems Practice. New York, NY, USA: Wiley.

Checkland, P and Holwell, S. 1998. Information, Systems and Information Systems: Making Sense of The Field. Chichester, UK: Wiley.

Checkland, P and Winter, M. 2006. "Process and Content: Two Ways of Using SSM". Journal of Operational Research Society, 57 (12), p.1435-1441.

Edison, R. 2008. Systems Thinking. Applied. A Primer. Arlington, VA, USA: Analytic Services.

Flood, R. L., & Carson, E. R. 1993. Dealing with Complexity: An Introduction to The Theory and Application of Systems Science (2nd ed.). New York, NY, USA: Plenum Press.

Jackson, M. 1985. "Social Systems Theory and Practice: The Need for A Critical Approach". International Journal of General Systems, 10, p. 135-151.

Jenkins, G. M. 1969. "The Systems Approach", in Beishon, J and Peters, G. (eds) Systems Behaviour (2nd ed.). New York, NY, USA: Harper and Row.

Mingers, J and Gill A. 1997. Multimethodology: Theory and Practice of Combining Management Science Methodologies. Chichester, UK: Wiley.

Mingers, J and White L. 2009. A Review of Recent Contributions of Systems thinking to Operational Research and Management Science, Working Paper 197. Canterbury, UK: Kent Business School.

Wasson, C. S. 2006. System Analysis, Design, and Development. Hoboken, NJ, USA: Wiley.