Identifying and Understanding Problems and Opportunities

From SEBoK
Jump to navigation Jump to search

This article considers the activities of the systems approach related to the identification and exploration of problem or oppourtunites in detail. Any of the activities described below may need to be considered concurrently with activities of in the Systems Approach. The final article in this knowledge area, Applying the Systems Approach, considers the dynamic aspects of how these activities are used as part of the Systems Approach and how this relates in detail to elements of Systems Engineering.

The phrase "problem or opportunity" used herein recognizes that the "problem" need not be a negative one, but could represent a positive oppourtunity to improve a situation.

Introduction

According to (Jenkins 1969) the first step in the Systems Approach is “the recognition and formulation of the problem”. 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 identified and agreed upon and a "new" engineered system solution is needed.

However, the systems approach does not have to apply to the development and use of a newly designed and built technical solution. Abstract or experimental solutions to potential problems might be explored to help agree on a problem context. Solutions may involve reorganizing existing system of system contexts, or the modification or re use of existing products and services. Hence the Problem and Opportunity part of the approach has some overlaps with soft system approaches. This is discussed in more detail below.

Hence Problem Exploration and Identification is often not a one off process of problem specification, but is used in combination with solution synthesis and analysis to progress towards a more complete understanding of problem and solutions over time (see Applying the Systems Approach for a more complete discussion of the dynamics of this aspect of the approach).

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 directed 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: "analyzing" conceptual models of shared understanding; "synthesizing" 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 future Engineered System problems will be stated, solved and used as part of a predominately soft intervention, placing pressures on the speed of development 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 chosen 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.

Problem Identification

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 important part of the approach.

According to (Blanchard and Fabrycky 2006, pp. 55-56), defining a problem is sometimes the most important and difficult step. In short, a system cannot be defined unless it is possible to clearly describe what it is supposed to accomplish.

According to (Edson 2008, pp. 26-29), there are three kinds of questions that need to be asked to ensure we fully understand a problem situation. 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.

Second, who or what is impacted? There may be elements of the situation that are causing the problem, elements that are impacted by the problem, and elements that are just in the loop. Beyond these factors, what is the environment and what are the external factors that affect the problem? In examining these aspects the tools and methods of Systems Thinking can be productively applied.

Finally, what are the various viewpoints of 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, as discussed above, can form an important part of this. Describing a problem using situation views can be useful when considering these issues, even if a single problem perspective is selected for further 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, which is then used to develop a solution in terms of the benefits stakeholders expect to see. The expectation is often that a new solution must be created, although this need not be the case. Jenkins suggests that System Engineering is just as applicable to redesign of existing systems. A clear understanding of stakeholder expectations in this regard should form part of the problem understanding. Do stakeholders expect a new solution or modifications to their existing solutions; or are they genuinely open to solution alternatives which consider the pros and cons of either. Such expectations will inform the suggestion of solution alternatives as discussed in the Synthesizing Possible Solutions article.

An important factor in defining the desired stakeholder outcomes, benefits and constraints is the operational environment, or scenario, in which the problem or opportunity exists. (Armstrong 2009, p. 1030) suggests two scenarios: The first is the descriptive scenario - the situation as it exists now. The second is the normative scenario - the situation as it may exist some time in the future.

All of these aspects of problem understanding can be related to the concept of a system context .

Problem Context

The Engineered System Context article identifies a way by which a complex system situation can be resolved around a System of Interest (glossary). The initial identification of a "Problem Context" can be considered as the outcome of this part of the systems approach.

The Systems Approach should not consider strictly Soft or Hard situations. More properly, a problem or opportunity will have aspects of both. In general, the application of the Systems Approach with a focus on engineered system contexts will lead to hard system contexts, in which an identified System of Interest and required outcome can be defined.

An initial description of the Wider System of Interest and Environment serves as the problem or opportunity problem scope. 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

In a hard system problem context a description of a logical or ideal system solution may be included. This ideal system cannot be implemented directly, but describes the properties required of any realizable system solution.

To support this problem or opportunity description a soft context view of the SoI will help ensure wider Stakeholder concerns are considered. If a soft system context has been defined this may include a Conceptual Model (Checkland 1999) which describes the logical elements of a system to resolve the problem situation and how these are perceived by different stakeholders. Unlike the hard system view, this does not describe the ideal solution, but provides an alternative view on how aspects of any solution would be viewed by potential stakeholders.

In problem contexts with a strong coercive dimension the problem context should include identification of the relative power and importance of stakeholders.

The problem context should include some boundaries on the cost, time to deployment, time in use and operational effectiveness needed stakeholders. In general we are describing both the full problem context, and an agreed version of the problem to be tackled next (see Applying the Systems Approach).

Linkages to other topics

None.

References

Works Cited

Armstrong, Jr., J.E., 2009. "Issue Formulation." In A.P. Sage and W.B. Rouse (eds.). Handbook of Systems Engineering and Management, 2nd edition. Hoboken, NJ, USA: Wiley.

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

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

Checkland, P. and S. Holwell. 1998. Information, Systems and Information Systems: Making Sense of the Field. Hoboken, NJ, USA: Wiley.

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

Edson, R. 2008. Systems Thinking. Applied. A Primer. Arlington, VA, USA: Applied Systems Thinking (ASysT) Institute, Analytic Services Inc.

Flood, R. L. and E.R. Carson 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: 135-151.

Jenkins, G. M. 1969. The Systems Approach. The Journal of Systems Engineering 1 (1).

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

Mingers, J. and L. White. 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 M. Webber. 1973. "Dilemmas in a General Theory of Planning." In Policy Sciences. 4:155–169.

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

Primary References

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

Edson, R. 2008. Systems Thinking. Applied. A Primer. Arlington, VA, USA: Applied Systems Thinking (ASysT) Institute, Analytic Services Inc.

Additional References

Armstrong, Jr., J.E., 2009. "Issue Formulation." In A.P. Sage and W.B. Rouse (eds.). Handbook of Systems Engineering and Management, 2nd edition. Hoboken, NJ, USA: Wiley.

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

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

Checkland, P. and S. Holwell. 1998. Information, Systems and Information Systems: Making Sense of the Field. Hoboken, NJ, USA: Wiley.

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

Flood, R. L. and E.R. Carson 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: 135-151.

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

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

Mingers, J. and L. White. 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.


<- Previous Article | Parent Article | Next Article ->