topic 12 - problem solving - murdoch universityftp.it.murdoch.edu.au/units/ict107/2002 lecture...

B107 Principles of Information SystemsTOPIC 11PROBLEM SOLVING

Objectives: To examine the basic problem solving model To clarify the relationship between problem solving and decision making To critique the problem solving model, questioning its applicability to real world

problem solving situations To introduce the Soft Systems Methodology as a technique for problem

definition applicable to IS development

Readings: Mason & Willcocks (1994) Systems Analysis, Systems Design Chpt 12. p237-243 Avison & Fitzgerald (1993) Information Systems Development, Section 6.7OR Chester & Athwell (2002) Basic Information Systems Analysis and Design,

Chapter 5.

The goals of problem solving

A 'problem' is whatever it is that lies behind the decision to do something. The word ‘problem’ in this context can be interpreted to include 2 situations: Real problems - things aren't going right! Opportunities - to improve something.Can be defined as: “a perceived difference between what is and what should be”.

The goal of problem solving is to find a solution to a problem. The solution must overcome the problem that has been recognised. And/or it must provide the benefits of the opportunities that have been

recognised.

Decision making is part of problem solving but not the full story. We are now going to focus on problem solving as a lead in to IS system development as a form of problem solving.

There is a systematic method to develop a good solution to a problem. The method can be described in a generic model suitable for all problem solving. This model divides the problem solving process into 3 basic stages:

1. Understand the problem2. Develop a solution3. Implement a solution.

This model is the foundation most systems development methodologies.

B107 Principles of Information Systems 1

THE PROBLEM SOLVING MODEL

Stage 1: Understand the problem

This stage includes the first 2 steps in the model: Defining the problem or opportunity. Gathering data that describes the problem.

The problem must be separated from the symptoms of the problem with which it manifests itself. It often helps to have an external person do this (e.g. an IS professional).

A wrongly identified problem can lead to the wrong solution being implemented.

Data must be gathered about the problem and about the possible solutions to the problem. This makes information available to decisions about the problem and the solution.

There must be sufficient data to be able to define the problem clearly and to design possible solutions. The nature of those data will vary with the nature of the problem being solved.

Constraints on possible solutions must be known to prevent unrealistic solutions being designed.

As the problem is being defined the problem boundaries become clear.


Stage 2: Develop a solution

This stage includes the next three steps: Designing or identifying alternative solutions Evaluating these solutions Selecting the best solution

This stage draws on the data/information previously gathered. Having several alternatives allow the most ideal solution to be sought.

Each alternative is a different approach (or in IS, implementation) to reach the same goal. Each possible solution must be studied for its feasibility.

So that the best solution can be chosen, the solutions must be evaluated by applying the same criteria to each.

The last step in this stage is to select a solution. The evaluations make this possible. However, this is often a difficult process involving a number of people with differing social and political interests.

Stage 3: Implement a solution

This stage involves Steps 6 and 7: Implementing the solution Evaluating the success of the solution.

Because the model is generic, it doesn’t specify the implementation process. But if you are implementing an IS it is called System Development. This is likely to be the largest and most complex step in the problem solving process.

The solution is evaluated after it has been implemented. This occurs after a period of monitoring its success and data gathered is used to measure the solution against the goals of the problem solving.

If the project really is a failure, then there is a new problem and the problem solving process begins over again.

Decision making in the problem solving process

Decision making is part of the problem solving process. It takes place in Stages 1 and 2.

In Step 5 we decide which of the alternative solutions to go ahead and implement. However, Steps 1-4 make it possible to make this decision using the information gathered.

This implies that by the time we start Stage 3 it is just a case of doing it. In fact, there is a great deal more to it than that.


Question

What are the stages of Simon’s decision making model?

What the model doesn't tell us?

While the model is basically useful, there are a number of things about which it tells us nothing.

The model tells us what steps to follow, but not when each step should be started. Must each step necessarily be completed before the next is started?

Frequently it is more efficient to carry out two steps at the same time and allowing each to inform the other.

It is also implied that each step is done once, finished and put aside. However, there are times when it is necessary to repeat steps.

Using this model by moving from step to step sequentially and never revisiting any step has not resulted in good problem solving in the past.

The model does not tell us anything about the involvement of stakeholders in the problem solving process.

Assumptions in the model

The model makes a number of assumptions that may not be very realistic:

The assumption that if enough information is provided, a feasible solution can be found.

The assumption that the stakeholders will make purely rational decisions.

The assumption that resources will be made available to the process.

The assumption that nothing changes during the problem solving project.

Risks in ‘real world’ problem solving

The problem may never get fully and clearly defined. The stakeholders may not be able to agree about the real nature of the

problem. The problem may be poorly defined so that a good solution cannot be

implemented.


The problem may not be capable of solution.

The best solution may not be selected from the alternatives. Selection is not the straight forward and rational process the model implies it is. The process can fail at this point for lack of a clear decision or the decision to

do nothing.

Those affected by the problem may reject the solution during the process or even after it has been implemented. The later in the process the failure occurs, the more costly the failure is.

The problem solving model and change

The model does not set the problem solving process within a time span. It implies that time is static during the process. In fact, the world is very dynamic, and business particularly so.

There is a risk that changes will occur during the process, which affect and change the process itself.

Environmental change - Change can occur within the environment of the project. This may impact on the problem solving process – eg business conditions change.

Stakeholders may change their minds about the solution, the timing of the implementation, how to define the problem.

Real life problem solving needs to be flexible enough to be able to accommodate this change.

Beyond the problem solving model

Successful systems development depends on understanding the problem to be solved - problem definition must identify the correct causes of a business problem

The systems analyst may conclude that a computer-based IS will assist in a situation, but if the problem is not purely a problem amenable to a solution using IT, this will not be sufficient

Management deficiencies, communication problems or conflicting goals require solutions that may or may not involve information systems

Often the analyst needs to examine an area that seems remote from the expertise of a “computer person”


Example

You might think that attempting to solve a problem such as “declining sales” is outside the realm of a systems analyst. This depends entirely on the underlying problem of which poor sales (in this example) may simply be a symptom.

If sales are declining due to a weak marketing strategy, an untrained sales staff, or an economic recession, the solution will lie primarily outside the realm of the analyst.

However, if customers are being lost due to inaccurate inventory, untimely marketing or poor customer information, an effective IS could well improve sales with the provision of an accurate inventory system or customer database.

How, then, do we determine the potential role of the IS within the overall problem area? We need to develop a deeper understanding of the problem in its general context.

Soft Systems Methodology - backgroundA problem may be relatively easy to define for an individual, but within an organisation or group there will be several or even many, different perceptions.

This often leads to the analyst obtaining conflicting requirements from different participants in the system.

It is important to obtain consensus within a group as to the nature of the problem to be solved. Consensus does not imply agreement, but at least an agreement to accept and support a problem statement as one that the group wishes to work on.

To address this very human problem, new methodologies such as the Soft System Methodology were developed.

What is Soft Systems Methodology?

In the 1980s, Checkland introduced the SSM to recognise some of the problems with the Problem Definition stage. This important methodology has very broad application both in the identification of the fundamental sources of problems, and in the reaching of consensus among systems participants.

The underlying theme is that "reality is socially constructed by humans and is not a given"

=> requirements are not objective or fixed for long and are partly shaped by the social and cultural aspects of the organisation

=> There is not necessarily one "target" system, and requirements determination should be via discussion and bargaining - so highly participative.

The SSM is very applicable to the development of ISs. However, it is useful for all problem solving situations.


Stages of SSM

Stage 1: The Problem Situation Unstructured (Real-World)This stage involves the preparation of some form of unstructured (natural language, not systems terminology) problem brief

It simply serves to give an outline of the problem domain and to allow the analyst to prepare for the next stage

Often there is some indication of the scope of the system problem - the boundary given

Stage 2: The Problem Situation Expressed (Real-World)In this stage the problem situation itself is represented

Checkland believes that in order to obtain a clear understanding and consensus among system participants, all participants must see the system and its problems in a similar manner

Using technical diagrams and formal computer systems notations at this point tends to stifle the ability of the non-IS personnel to contribute and reduces their opportunity to understand the problem

Rich pictures are commonly used, but any technique that can help to define the problem technique can be used

What are rich pictures?

Rich pictures are used to represent the real-world system using a simple drawing technique similar to a cartoon. Basically we draw everything we have identified and all activities on a (usually large) diagram called rich picture (RP)

We then discuss the RP with all participants - amending and adding/deleting as necessary until all participants agree that the “problem” is shown in its context in the picture


Example - draw a rich picture to represent the problem situation - passing B107

Stage 3: Root Definitions of Relevant Systems (Systems Thinking)We now seek to obtain agreement on a root definition - the fundamental definition of the system and its objectives etc - this will then be used to construct a conceptual (logical) model of the new system.

The root definition will normally identify and address the following components:

customers -The people who are affected by the system

actors - The people within the system who actually carry out its activities

transformation - The means by which inputs are converted into outputs

Weltanshauung - This is a German word that approximates to the chosen viewpoint of the system

owner - The owners of the system are the group responsible for the system and therefore have the ultimate power over the system

environment - The environment includes any external conditions which are of significance to the system

The acronym C A T W O E serves as a reminder of the components to address when creating a root definition (RD)

A root definition is a concise statement of the activities carried out by a system.


For example - fence painting:

A householder-owned and manned system to paint a garden fence, by conventional hand painting, in keeping with the overall decoration scheme of the property, in order to enhance the visual appearance of the property

When remembering what a RD should cover: “who is doing what for whom and to whom are they answerable, what assumptions are being made and where is this happening”.

In terms of CATWOE:Client is the “whom”Actor is the “who”Transformation is the “what”Weltanshauung is the “assumptions”Owner is the “answerable”Environment is the “where”

Another example:

A Health Department (Owner) Funded Hospital System which enables health care providers (Actors) to deliver and coordinate (Transformation processes) efficient and effective Health Care Services to inpatients and outpatients (Customers)- aimed at meeting the health needs of these patients (Weltenshauung)- within the environmental characteristics of (Environment)

• Budget• Health Department Policy and Procedure• Legislation• Changing political factors

What is Weltanshauung?It is relatively easy to see that a RD should define who does what for whom, to whom are they answerable and where is this done. The most common difficulty is knowing how to interpret the assumptions which have been made – for example:

Achieving a Hospital Root Definition

THE PATIENTClient MeActor The doctorTransformation My treatmentWeltanshauung I’ve paid my taxes so I’m entitled to itOwner ‘The system’ or maybe ‘the taxpayer’Environment The hospital

This can be expressed as:

A hospital is a place that I go to in order to get treated by a doctor. I’m entitled to this because I am a taxpayer and the system is there to make sure that taxpayers get the treatment that they need.


THE DOCTORClient PatientsActor MeTransformation Treating (probably by specialised equipment, services or

nursing care)Weltanshauung I’ll treat as many people as possible per working weekOwner Hospital administrationEnvironment Federal health scheme versus private practice. My work versus

my private life.


A hospital is a system designed to enable me to treat as many patients as possible with the aid of specialised equipment, nursing care, etc. Organisation decisions are made by the hospital administrators (who ought to try treating patients without the proper facilities) against a background of Heath Department politics and my visions of a lucrative private practice and regular weekends off with my family.

THE HOSPITAL ADMINISTRATORClient DoctorsActor MeTransformation To enable doctors to optimise patient waiting listsWeltanshauung Create a bigger, better hospital within cash limitsOwner Department of HealthEnvironment Politics


A hospital is an institution in which doctors (and other less expensive staff) are enabled by administrators to provide a service that balances the need to avoid long patient waiting lists with that to avoid excessive government spending. Ultimate responsibility rests with the Dept of health and the environment is very political.

Clearly these three “views” of essentially the same problem domain must be taken into account when preparing a model for a new system

Stage 4: Conceptual Models (Systems thinking)

In this stage a conceptual model based on the root definition can be built. This can be in a number of formats, frequently in the form of “bubble diagrams” showing the sequence of and relationship between activities

The model should assemble the minimum list of verbs covering the activities that are necessary in a system defined in the root definition, and structure the verbs in a logical sequence

Activities may be well-defined (“hard”) such as performing a clerical task, or may be unstructured (“soft”) such as making a decision


Stage 5: Comparison of Models and Reality (Real World)The conceptual model should then be compared against the perceptions of the people whose input contributed to the RP and to the RD to determine areas of difference

The proposed model should reflect - in a more abstract manner, what each person said, however it is a global model and each person’s view may only be part of the whole

This generates discussion about the model and its validity

Consensus is crucial as the agreed conceptual model forms the basis of the design for the new system.

Remaining SSM StagesThe remaining stages of the SSM are common to most methodologies and it is quite common to “switch” from SSM to a more structured methodology at this stage

The remaining stages of SSM are:

Stage 6: Determine Changes (Real World)To determine feasible and desirable changes which will enable the agreed activities to be performed

Various components in the new model are evaluated as to their desirability and costed

Divisions between humans and computers are considered and new technologies are frequently evaluated at this stage.

Stage 7: Take Action to Improve the Problem Situation (Real World)This is the implementation - the software development, equipment purchase, user training and installation etc..

Satisficing as a compromise

Satisficing means that decision makers may settle for a solution that satisfies the goals of the problem solving process, but sacrifices the ideal solution.

There are many reasons why decision makers might satisfice: Social and political negotiations make it necessary. The ideal solution is not cost effective. The ideal solution carries too much risk of failure and a safer solution is sought.


topic 12 - problem solving - murdoch universityftp.it.murdoch.edu.au/units/ict107/2002 lecture...

Documents