Difference between revisions of "Identifying and Understanding Problems and Opportunities"

From SEBoK
Jump to: navigation, search
(Hard Problem Exploration)
(Byline)
 
(132 intermediate revisions by 15 users not shown)
Line 1: Line 1:
==Introduction==
+
----
Jenkins according to (Checkland, 1999, p. 140) states that the first step in the Systems Approach is “the recognition and formulation of the problem”.  In a [[Hard System (glossary)]] approach we start from the assumption that there is a problem to be solve. We have used the phrase "problem or oppourtunity" in this topic to recognise the fact that the "problem" need not be a negative one, but could represent a positive oppourtunity to develop a system.  In the sense the "problem" is that we do not have a system to take advantage of this new oppourtunity.
+
'''''Lead Author:''''' ''Rick Adcock'', '''''Contributing Authors:''''' ''Brian Wells, Scott Jackson, Janet Singer, Duane Hybertson, Bud Lawson''
 +
----
 +
This topic is part of the [[Systems Approach Applied to Engineered Systems]] knowledge area (KA).  It describes knowledge related to the identification and exploration of {{Term|Problem (glossary)|problems}} or {{Term|Opportunity (glossary)|opportunities}} in detail. The problem situations described by the activities in this topic may form a starting point for [[Synthesizing Possible Solutions]].  Any of the activities described below may also need to be considered {{Term|Concurrently (glossary)|concurrently}} with other activities in the {{Term|Systems Approach (glossary)|systems approach}} at a particular point in the life of a {{Term|System-of-Interest (glossary)|system-of-interest}} (SoI).
  
The Systems Approach described in this knowledge area follows is predominantly a [[Hard System (glossary)]] approach.  The Analysis, Synthesis and Proving parts of the approach assume a problem or oppourtunity has been agreed and an Engineered System is needs to be developed against that need.
+
The activities described below should be considered in the {{Term|Context (glossary)|context}} of the [[Overview of the Systems Approach]] topic at the start of this KA.  The final topic 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 {{Term|Element (glossary)|elements}} of {{Term|Systems Engineering (glossary)|systems engineering}} (SE).
  
The Problem and Oppourtunity part of the approach has some overlaps with [[Soft System (glossary)]] approaches.  This is discussed in more detail below.
+
The phrase "problem or opportunity" used herein recognizes that the "problem" is not always a negative situation and can also be a positive opportunity to improve a situation.
  
This section will summarize problem and opportunity exploration as described by (Edson, 2008) and others.
+
==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 Guide to the SE Body of Knowledge (SEBoK) is predominantly a {{Term|Hard System (glossary)|hard system}} approach. The analysis, {{Term|Synthesis (glossary)|synthesis}}, and proving parts of the approach assume a problem or opportunity has been identified and {{Term|Agreement (glossary)|agreed}} upon and that a "new" {{Term|Engineered System (glossary)|engineered system (glossary)}} solution is needed.
  
==Soft Problem Exploration==
+
However, the systems approach does not have to apply to the development and use of a newly {{Term|Design (glossary)|designed}} and built technical {{Term|Solution (glossary)|solution}}. {{Term|Abstraction (glossary)|Abstract}} or experimental solutions to potential problems might be explored to help achieve agreement on a problem context. Solutions may involve reorganizing existing {{Term|System of Systems (SoS) (glossary)|system of systems}} (SoS) contexts or the modification or re-use of existing {{Term|Product (glossary)|products}} and {{Term|Service (glossary)|services}}. The problem and opportunity parts of the approach overlap with {{Term|Soft System (glossary)|soft system}} approaches. This is discussed in more detail below. 
  
[[Systems Thinking|Soft System Thinking]] does not look for "the problem", but considers a problematic situation.  Forming systems views of this situation can help stakeholders to better understand each other 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 does follow the basic principles of a systems approach: "analysing" conceptuals models of shared understanding; "synthesising" intervention strategies; and "proving" improvements in the problematic situation.
+
One thing that must be considered in relation to system {{Term|Complexity (glossary)|complexity}} is that the opportunity situation may be difficult to fully understand; therefore, system solutions may not solve the problem the first time, but is still useful in increasing the understanding of both problem issues and what to try next to work toward a solution.
  
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 (glossary)]] and [[enterprise (glossary)]] 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 releavnt examples of this, including (Checkland and Winters 2006).  Thus, we might expect Systems Engineering problems to be stated, solved and used as part of a predominately soft intervention.  The will place pressures on the speed of develoment needed for in the solution space.  This is discussed more fully in under [[Life Cycle Models]].
+
Hence, problem exploration and identification is often not a one-time process that specifies the problem, but is used in combination with solution synthesis and analysis to progress toward a more complete understanding of problems and solutions over time (see [[Applying the Systems Approach]] for a more complete discussion of the dynamics of this aspect of the approach).
  
The [[Critical Systems Thinking (glossary)]] and multimethodology 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 describe below is used we should consider the use of some of the soft system techniques (such as rich pictures, root definitions or conceptual models) within it.
+
==Problem Exploration==
  
==Hard Problem Exploration==
+
Soft system thinking does not look for "the problem", but considers a problematic situation. Forming systems {{Term|View (glossary)|views}} of this situation can help {{Term|Stakeholder (glossary)|stakeholders}} better understand each other's {{Term|Viewpoint (glossary)|viewpoints}} and provide a starting point for directed intervention in the current {{Term|System Context (glossary)|system context}}. If a full soft systems intervention is undertaken, such as a {{Term|Soft Systems Methodology (glossary)|soft systems methodology}} (SSM) (Checkland 1999), it will not include formal analysis, synthesis, and {{Term|Proving (glossary)|proving}}. However, the SSM method was originally based on hard methodologies, in particular one presented by Jenkins (1969). It follows the basic principles of a systems approach: "analyzing" {{Term|Concept (glossary)|conceptual}} {{Term|Model (glossary)|models}} of shared understanding, "synthesizing" intervention strategies, and "proving" improvements in the problematic situation.  
[[Systems Thinking|Hard System Thinking]] is based on the idea that a problem does exist, which can be state 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 you want to define? Sometimes a problem is known as a “need.” In short, a system cannot be defined unless you can define what it is supposed to accomplish.  
+
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 Holwell 1998). It is now agreed upon by many that while there is a role for a "pure soft system" approach, the {{Term|service (glossary)}} and {{Term|enterprise (glossary)}} problems now being tackled can only be dealt with successfully by a combination of soft problematic models and {{Term|Hard System (glossary)|hard system}} solutions. Mingers and White (Mingers and White 2009) give a number of relevant examples of this. In particular they reference "Process and Content: Two Ways of Using SSM" (Checkland and Winters 2006). It is likely in the future that engineered system problems will be stated, solved, and used as part of a predominately soft intervention, which will place pressure on the speed of development needed in the solution space. This is discussed more fully in the topic [[Life Cycle Models]].
  
According to (Edson, 2008, pp. 26-29), some of the questions that need to be asked are as follows:
+
The {{Term|Critical Systems Thinking (glossary)|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.
  
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.  
+
==Problem Identification==
*For tame problems, the solution may be well defined and obvious.
+
Hard system thinking is based on the premise that a problem exists and 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.
*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 may not be solvable using obvious approaches, so detailed attention should be given to them.  
 
  
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?
+
According to Blanchard and Fabrycky (Blanchard and Fabrycky 2006, 55-56), defining a problem is sometimes the most important and difficult step. In short, a {{Term|System (glossary)|system}} cannot be defined unless it is possible to clearly describe what it is supposed to accomplish.
  
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
+
According to Edson (Edson 2008,  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? The answer to this question will help define the tractability of the problem. Problems can be “tame,” “regular,or “wicked”:
 +
* 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, thus serious attention should be given to every aspect of them.
 +
*{{Term|Wicked Problem (glossary)|Wicked problems}} (Rittel and Webber 1973) cannot be fully solved, or perhaps even fully defined. Additionally, with wicked problems, it is not possible to understand the full effect of applying systems to the problem.
  
[[Operational Research (glossary)]] 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.
+
Next, who or what is impacted? There may be {{Term|element (glossary)|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 {{Term|Environment (glossary)|environment}} and what are the external factors that affect the problem? In examining these aspects, the tools and methods of {{Term|Systems Thinking (glossary)|systems thinking}} can be productively applied.
  
Traditional [[Systems Engineering (glossary)]] methods (Jenkins, 1969) tend to focus more on describing an abstract model of the problem we would like to solve in terms of the benfits stakeholder expect to see from a solution. The expectation is often that we will need to create a new solution, 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 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.
+
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, who stand to benefit from the system, or can be harmed by the system, are called stakeholders. Wasson (Wasson 2006, 42-45) provides a comprehensive list of stakeholder types. The use of soft systems models, as discussed above, can play an important part in 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.
  
==Problem Context==
+
{{Term|Operations Research (glossary)|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 asks questions about the limitation and {{Term|Cost (glossary)|cost}} of the current system to identify efficiency improvements that need to be made (Flood and Carson 1993).   
In the [[System Context]] topic we identify the concept by which a complex system situation can be resolved around a System of Interest. We can consider the inital identification of a "Problem Context" as the outcome of this part of the systems approach.   
 
  
If we can create an initially description of the Wider System of Interest and Environment this will form our problem or oppoutunity.  Desired stakeholder benefits are expressed a outcomes in the wider system and some initila expression of what the System of Interest is for may be identified. Jenkins (jenkins, 1969) defines a problem formulation approach in which we:
+
Traditional SE methods tend to focus more on describing an abstract model of the problem, which is then used to develop a solution that will produce the benefits stakeholders expect to see (Jenkins 1969). The expectation is often that a new solution must be created, although this need not be the case. Jenkins suggests that SE is just as applicable to a redesign of existing systems. A clear understanding of stakeholder expectations in this regard should produce a better understanding of part of the problem. 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 influence suggestions of solution alternatives, as discussed in the [[Synthesizing Possible Solutions]] article.
*state the aim of the System of Interest
 
*Define the Wider System of Interest
 
*Define the Ojectives of the Wider System of Interest
 
*Define the objectives of the system
 
*Define economic, information and other conditions
 
  
The practice of System Engineering described in the SEBOK should follow the important principle that all problems and oppourtunities exist in an engineered System Context.
+
An important factor in defining the desired stakeholder outcomes, benefits, and {{Term|Constraint (glossary)|constraints}} is the {{Term|Operational Environment (glossary)|operational environment}}, or {{Term|Scenario (glossary)|scenario}}, in which the problem or opportunity exists. Armstrong (Armstrong 2009, 1030) suggests two scenarios: the first is the descriptive scenario, or the situation as it exists now, and the second is the normative scenario, or the situation as it may exist sometime in the future.
  
==Linkages to other topics==
+
All of these aspects of problem understanding can be related to the concept of a system context.
  
Capturing of Stakeholder Needs in Systems Engineering.
+
==Problem Context==
 +
The [[Engineered System Context]] topic identifies a way by which a {{Term|Complex (glossary)|complex}} system situation can be resolved around a {{Term|System-of-Interest (glossary)|system-of-interest  (glossary)}} (SoI). The initial identification of a "problem context" can be considered as the outcome of this part of the systems approach.
  
==References==
+
The systems approach should not consider only soft or hard situations. More appropriately, a problem or opportunity should be explored using 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 SoI and required outcome can be defined.
Armstrong, Jr., James E., 2009. Issue Formualation. In: SAGE, A. P. & ROUSE, W. B. (eds.) Handbook of Systems Engineering and Management. Second ed. Hoboken, NJ: John Wiley & Sons.
 
  
Blanchard, B. & Fabrycky, W. J. 2006. Systems Engineering and Analysis, Upper Saddle River, NJ, Prentise Hall.
+
An initial description of the wider SoI and environment serves as the problem or opportunity problem {{Term|Scope (glossary)|scope}}. Desired stakeholder benefits are expressed as outcomes in the wider system and some initial expression of what the SoI is intended for may be identified. Jenkins (1969) defines a problem formulation approach where one:
 +
* states the aim of the SoI
 +
* defines the wider SoI
 +
* defines the objectives of the wider SoI
 +
* defines the objectives of the system
 +
* defines economic, informational, and other conditions.
  
Checkland, P. 1999. Systems Thinking, Systems Practice, New York, John Wiley & Sons.
+
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.
  
Checkland, P and Holwell, S. 1998.  Information, systems and Information Systems; making sense of the field, Wiley and Sons; Chichester.
+
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, it may include a conceptual model (Checkland 1999) which describes the logical elements of a system that resolve the problem situation and how they 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.
  
Checkland, P and Winter, M. 2006Process and content: two ways of using SSM. Journal of Operational Research Spciety 57 (12), 1435-1441.
+
In problem contexts with a strong {{Term|Coercive (glossary)|coercive}} dimension, the problem context should include an identification of the relative power and the importance of stakeholders.   
  
Edison, R. 2008. Systems Thinking. Applied. A Primer. In: ASYST INSTITUTE (ed.). Arlington, VA: Analytic Services
+
The problem context should include some {{Term|Boundary (glossary)|boundaries}} on the cost, time to deployment, time in use, and operational effectiveness needed by stakeholders. In general, both the full problem context and an agreed version of the problem to be tackled next are described. (see [[Applying the Systems Approach]]).
  
Flood, R. L., & Carson, E. R. 1993. Dealing with complexity: An introduction to the theory and application of systems science (2nd ed.). New York: Plenum Press.
+
==References==
 
 
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 Peters, G. (eds) Systems Behaviour (2nd ed.). New York; Harper and Row.
 
 
 
Mingers, J and Gill A. 1997. Multimethodology: Theory and Practice of Combining Management Science Methodologies.  Wiley; Chichester.
 
  
Mingers, J and White L. 2009. A review of recent contributions of Systems thinking to Operational Research and management Science, Working Paper 197. Kent Business School, Canterbury.
 
  
Wasson, C. S. 2006. System Analysis, Design, and Development, Hoboken, NJ, John Wiley & Sons.
+
===Works Cited===
  
  
===Citations===
+
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.
  
Armstrong, Jr., James E., 2009. Issue Formualation. In: SAGE, A. P. & ROUSE, W. B. (eds.) Handbook of Systems Engineering and Management. Second ed. Hoboken, NJ: John Wiley & Sons.
+
Checkland, P. 1999. ''Systems Thinking, Systems Practice.'' New York, NY, USA: Wiley.
  
Blanchard, B. & Fabrycky, W. J. 2006. Systems Engineering and Analysis, Upper Saddle River, NJ, Prentise Hall.
+
Checkland, P. and S. Holwell. 1998. ''Information, Systems and Information Systems: Making Sense of the Field''.  Hoboken, NJ, USA: Wiley.
  
Checkland, P. 1999. Systems Thinking, Systems Practice, New York, John Wiley & Sons.
+
Checkland, P. and M. Winter. 2006. "Process and Content: Two Ways of Using SSM".  ''Journal of Operational Research Society.'' 57(12): 1435-1441.
  
Checkland, P and Holwell, S. 1998. Information, systems and Information Systems; making sense of the field, Wiley and Sons; Chichester.
+
Edson, R. 2008. ''Systems Thinking. Applied. A Primer''. Arlington, VA, USA: Applied Systems Thinking (ASysT) Institute, Analytic Services Inc.
  
Checkland, P and Winter, M. 2006. Process and content: two ways of using SSM. Journal of Operational Research Spciety 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.
  
Edison, R. 2008. Systems Thinking. Applied. A Primer. In: ASYST INSTITUTE (ed.). Arlington, VA: Analytic Services
+
Jackson, M. 1985. "Social Systems Theory and Practice: The Need for A Critical Approach". ''International Journal of General Systems''. 10: 135-151.
  
Flood, R. L., & Carson, E. R. 1993. Dealing with complexity: An introduction to the theory and application of systems science (2nd ed.). New York: Plenum Press.
+
Jenkins, G.M. 1969. "The Systems Approach." ''The Journal of Systems Engineering.'' 1(1).
  
Jackson, M. 1985. Social systems theory and practice: the need for a critical approachInternational Journal of General Systems 10, 135-151.
+
Mingers, J. and A. Gill. 1997. ''Multimethodology: Theory and Practice of Combining Management Science Methodologies''Chichester, UK: Wiley.
  
Jenkins, G. M. 1969. The Systems Approach, in Beishon, J and Peters, G. (eds) Systems Behaviour (2nd ed.). New York; Harper and Row.
+
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.
  
Mingers, J and Gill A. 1997. Multimethodology: Theory and Practice of Combining Management Science Methodologies. Wiley; Chichester.
+
Rittel, H. and M. Webber. 1973. "Dilemmas in a General Theory of Planning." In ''Policy Sciences''. 4:155–169.
  
Mingers, J and White L. 2009. A review of recent contributions of Systems thinking to Operational Research and management Science, Working Paper 197. Kent Business School, Canterbury.
+
Wasson, C.S. 2006. ''System Analysis, Design, and Development.'' Hoboken, NJ, USA: Wiley.
 
 
Wasson, C. S. 2006. System Analysis, Design, and Development, Hoboken, NJ, John Wiley & Sons.
 
  
 
===Primary References===
 
===Primary References===
  
Blandhard, B. & Fabrycky, W. J. 2006. Systems Engineering and Analysis, Upper Saddle River, NJ, Prentise Hall.
+
Blanchard, B. & W.J. Fabrycky. 2006. ''[[Systems Engineering and Analysis]]''. Upper Saddle River, NJ, USA: Prentice Hall.
  
Edson, R. 2008. Systems Thinking. Applied. A Primer. In: ASYST INSTITUTE (ed.). Arlington, VA: Analytic Services
+
Edson, R. 2008. ''[[Systems Thinking. Applied.]] A Primer''. Arlington, VA, USA: Applied Systems Thinking (ASysT) Institute, Analytic Services Inc.
  
 
===Additional References===
 
===Additional References===
Flood R and Jackson M, 1991. Creative Problem Solving: Total Systems Intervention. Wiley; London.
+
None
  
Armstrong, Jr., James E., 2009. Issue Formualation. In: SAGE, A. P. & ROUSE, W. B. (eds.) Handbook of Systems Engineering and Management. Second ed. Hoboken, NJ: John Wiley & Sons.
+
----
  
Blanchard, B. & Fabrycky, W. J. 2006. Systems Engineering and Analysis, Upper Saddle River, NJ, Prentise Hall.
+
<center>[[Engineered System Context|< Previous Article]] | [[Systems Approach Applied to Engineered Systems|Parent Article]] | [[Synthesizing Possible Solutions|Next Article >]]</center>
 
 
Checkland, P. 1999. Systems Thinking, Systems Practice, New York, John Wiley & Sons.
 
 
 
Checkland, P and Holwell, S. 1998.  Information, systems and Information Systems; making sense of the field, Wiley and Sons; Chichester.
 
 
 
Checkland, P and Winter, M. 2006.  Process and content: two ways of using SSM. Journal of Operational Research Spciety 57 (12), 1435-1441.
 
 
 
Edison, R. 2008. Systems Thinking. Applied. A Primer. In: ASYST INSTITUTE (ed.). Arlington, VA: 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: 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 Peters, G. (eds) Systems Behaviour (2nd ed.). New York; Harper and Row.
 
 
 
Mingers, J and Gill A. 1997. Multimethodology: Theory and Practice of Combining Management Science Methodologies.  Wiley; Chichester.
 
 
 
Mingers, J and White L. 2009. A review of recent contributions of Systems thinking to Operational Research and management Science, Working Paper 197. Kent Business School, Canterbury.
 
 
 
Wasson, C. S. 2006. System Analysis, Design, and Development, Hoboken, NJ, John Wiley & Sons.
 
 
 
----
 
====Article Discussion====
 
  
[[{{TALKPAGENAME}}|[Go to discussion page]]]
+
<center>'''SEBoK v. 2.1, released 31 October 2019'''</center>
<center>[[Overview of the Systems Approach|<- Previous Article]] | [[Systems Approach|Parent Article]] | [[Systems Analysis Approach|Next Article ->]]</center>
 
  
==Signatures==
+
[[Category:Part 2]][[Category:Topic]][[Category:Systems Approach Applied to Engineered Systems]]
[[Category:Part 2]][[Category:Topic]]
 

Latest revision as of 00:24, 26 October 2019


Lead Author: Rick Adcock, Contributing Authors: Brian Wells, Scott Jackson, Janet Singer, Duane Hybertson, Bud Lawson


This topic is part of the Systems Approach Applied to Engineered Systems knowledge area (KA). It describes knowledge related to the identification and exploration of problemsproblems or opportunitiesopportunities in detail. The problem situations described by the activities in this topic may form a starting point for Synthesizing Possible Solutions. Any of the activities described below may also need to be considered concurrentlyconcurrently with other activities in the systems approachsystems approach at a particular point in the life of a system-of-interestsystem-of-interest (SoI).

The activities described below should be considered in the contextcontext of the Overview of the Systems Approach topic at the start of this KA. The final topic 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 elementselements of systems engineeringsystems engineering (SE).

The phrase "problem or opportunity" used herein recognizes that the "problem" is not always a negative situation and can also be a positive opportunity 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 Guide to the SE Body of Knowledge (SEBoK) is predominantly a hard systemhard system approach. The analysis, synthesissynthesis, and proving parts of the approach assume a problem or opportunity has been identified and agreedagreed upon and that a "new" engineered system (glossary)engineered system (glossary) solution is needed.

However, the systems approach does not have to apply to the development and use of a newly designeddesigned and built technical solutionsolution. AbstractAbstract or experimental solutions to potential problems might be explored to help achieve agreement on a problem context. Solutions may involve reorganizing existing system of systemssystem of systems (SoS) contexts or the modification or re-use of existing productsproducts and servicesservices. The problem and opportunity parts of the approach overlap with soft systemsoft system approaches. This is discussed in more detail below.

One thing that must be considered in relation to system complexitycomplexity is that the opportunity situation may be difficult to fully understand; therefore, system solutions may not solve the problem the first time, but is still useful in increasing the understanding of both problem issues and what to try next to work toward a solution.

Hence, problem exploration and identification is often not a one-time process that specifies the problem, but is used in combination with solution synthesis and analysis to progress toward a more complete understanding of problems 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 viewsviews of this situation can help stakeholdersstakeholders better understand each other's viewpointsviewpoints and provide a starting point for directed intervention in the current system contextsystem context. If a full soft systems intervention is undertaken, such as a soft systems methodologysoft systems methodology (SSM) (Checkland 1999), it will not include formal analysis, synthesis, and provingproving. However, the SSM method was originally based on hard methodologies, in particular one presented by Jenkins (1969). It follows the basic principles of a systems approach: "analyzing" conceptualconceptual modelsmodels 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 Holwell 1998). It is now agreed upon by many that while there is a role for a "pure soft system" approach, the serviceservice and enterpriseenterprise problems now being tackled can only be dealt with successfully by a combination of soft problematic models and hard systemhard system solutions. Mingers and White (Mingers and White 2009) give a number of relevant examples of this. In particular they reference "Process and Content: Two Ways of Using SSM" (Checkland and Winters 2006). It is likely in the future that engineered system problems will be stated, solved, and used as part of a predominately soft intervention, which will place pressure on the speed of development needed in the solution space. This is discussed more fully in the topic Life Cycle Models.

The critical systems thinkingcritical 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 premise that a problem exists and 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 (Blanchard and Fabrycky 2006, 55-56), defining a problem is sometimes the most important and difficult step. In short, a systemsystem cannot be defined unless it is possible to clearly describe what it is supposed to accomplish.

According to Edson (Edson 2008, 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? The answer to this question will help define the tractability of the problem. Problems can be “tame,” “regular,” or “wicked”:

  • 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, thus serious attention should be given to every aspect of them.
  • Wicked problemsWicked problems (Rittel and Webber 1973) cannot be fully solved, or perhaps even fully defined. Additionally, with wicked problems, it is not possible to understand the full effect of applying systems to the problem.

Next, who or what is impacted? There may be elementselements 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 environmentenvironment and what are the external factors that affect the problem? In examining these aspects, the tools and methods of systems thinkingsystems 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, who stand to benefit from the system, or can be harmed by the system, are called stakeholders. Wasson (Wasson 2006, 42-45) provides a comprehensive list of stakeholder types. The use of soft systems models, as discussed above, can play an important part in 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 researchOperations research is a hard systems method which concentrates on solving problem situations by deploying known solutions. The problem analysis step of a typical approach asks questions about the limitation and costcost of the current system to identify efficiency improvements that need to be made (Flood and Carson 1993).

Traditional SE methods tend to focus more on describing an abstract model of the problem, which is then used to develop a solution that will produce the benefits stakeholders expect to see (Jenkins 1969). The expectation is often that a new solution must be created, although this need not be the case. Jenkins suggests that SE is just as applicable to a redesign of existing systems. A clear understanding of stakeholder expectations in this regard should produce a better understanding of part of the problem. 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 influence suggestions of solution alternatives, as discussed in the Synthesizing Possible Solutions article.

An important factor in defining the desired stakeholder outcomes, benefits, and constraintsconstraints is the operational environmentoperational environment, or scenarioscenario, in which the problem or opportunity exists. Armstrong (Armstrong 2009, 1030) suggests two scenarios: the first is the descriptive scenario, or the situation as it exists now, and the second is the normative scenario, or the situation as it may exist sometime 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 topic identifies a way by which a complexcomplex system situation can be resolved around a system-of-interest (glossary)system-of-interest (glossary) (SoI). 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 only soft or hard situations. More appropriately, a problem or opportunity should be explored using 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 SoI and required outcome can be defined.

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

  • states the aim of the SoI
  • defines the wider SoI
  • defines the objectives of the wider SoI
  • defines the objectives of the system
  • defines economic, informational, 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, it may include a conceptual model (Checkland 1999) which describes the logical elements of a system that resolve the problem situation and how they 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 coercivecoercive dimension, the problem context should include an identification of the relative power and the importance of stakeholders.

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

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

Blanchard, 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

None


< Previous Article | Parent Article | Next Article >
SEBoK v. 2.1, released 31 October 2019