SCENARIO MANAGEMENT: PROCESS AND SUPPORT

M. Daud Ahmed

Department of Computing and Information Technology, Manukau Institute of Technology, Auckland, New Zealand

Dr David Sundaram

Department of Information Systems and Operation Management, University of Auckland , New Zealand

Keywords: DSSG, Decision Making, Scenario Planning

Abstract: Scenario planning is a widely accepted management tool for decision support activities. Scenario planning,

development, organisation, analysis, and evaluation are generally quite complex processes. Systems that

purport to support these processes are complex and difficult to use and do not fully support all phases of

scenario management. Though traditional Decision Support Systems (DSS) provide strong database,

modelling and visualisation capabilities for the decision maker they do not explicitly support scenario

management well.

This paper presents an integrated life cycle approach for scenario driven flexible decision

support. The proposed processes help the decision maker with idea generation, scenario planning,

development, organisation, analysis, and execution. We also propose a generalised scenario evaluation

process that allows homogeneous and heterogeneous scenario comparisons. This research develops a

domain independent, component-based, modular framework and architecture that support the proposed

scenario management process. The framework and architecture have been validated through a concrete

prototype.

1 INTRODUCTION

In the decision sciences, scenarios have been defined

as a management tool for identifying a plausible

future (Alter, 1980; Porter

, 1985; Schwartz, 1991;

Tucker, 1999) and a process for forward-looking

analysis. Scenarios have also been defined in many

other ways e.g. it is a kind of story that is a focused

description of a fundamentally different future

(

Schoemaker, 1993); that is plausibly based on

analysis of the interaction of a number of

environmental variables (

Kloss, 1999); that improves

cognition by organising many different bits of

information (

De Geus, 1997; van der Heijden, 1996;

Wack, 1985); that is analogous to a "what if" story

(

Tucker, 1999). It can be a series of events that could

lead the current situation to a possible or desirable

future state. Scenarios are not forecasts (

Schwartz,

1991), future plans (Epstein, 1998), trend analyses or

analyses of the past. It is for strategy identification

rather than strategy development (

Schoemaker, 1993)

and to anticipate and understand risk

and to discover

new options for action. Ritson (1997) agrees with

Schoemaker (1995) and explains that scenario

planning scenarios are situations planned against

known facts and trends but deliberately structured to

enable a range of options and to track the key

triggers which would precede a given situation

within the scenario.

Decision makers have been using the concepts of

scenari

os for a long time, but due to its complexity,

its use is still limited to strategic decision making

tasks. Scenario planning varies widely from decision

maker to decision maker mainly because of lack of a

generally accepted principle for scenario

management. Albert (1983) proposes three

approaches for scenario planning, namely, Expert

scenario approach, Morphological approach and

Cross-Impact approach. Ringland (1998) describes

three-step scenario planning – namely

brainstorming, building scenarios, and decisions and

action planning. Schoemaker (1995) outlines a ten-

step scenario analysis process. Huss and Honton

(

1987) identify three categories of scenario planning.

The literature still lacks a suitable approach for

planning, developing, analysing, organising and

evaluating the scenario using model-driven decision

support systems. Currently available scenario

management processes are cumbersome and not

properly supported by the available tools and

technologies. Therefore, we introduce a life cycle

approach based scenario management guideline.

Generation of multiple scenarios and sensitivity

analysis exacerbate the deci

sion makers problem.

Daud Ahmed M. and Sundaram D. (2005).

SCENARIO MANAGEMENT: PROCESS AND SUPPORT.

In Proceedings of the Seventh International Conference on Enterprise Information Systems, pages 50-57

DOI: 10.5220/0002525600500057

 SciTePress

The available scenario planning tools are not

suitable for assessing the quality of the scenarios and

do not support well, the evaluation of scenarios

through a comparison process. We introduce an

evaluation process for comparison of instances of

homogeneous and heterogeneous scenarios that will

enable the user to identify the most suitable and

plausible scenario for the organization. Considering

the significance of scenarios in the decision-making

process, this research includes scenario as a

decision-support component of the DSS and defines

Scenario-driven DSS as an interactive computer-

based system, which integrates diverse data, models

and solvers to explore decision scenarios for

supporting the decision makers in solving problems.

Traditional DSS have been for the most part

data-driven, model-driven and/or knowledge-driven

but have not given due importance to scenario

planning and analysis. Some of the DSS have partial

support for sensitivity analysis and goal-seek

analysis but this does not fulfil the needs of the

decision maker. In most cases, the available scenario

analysis tools deal with a single scenario at a time

and are not suitable for development of multiple

scenarios simultaneously. A scenario impacts on

related scenarios but currently available tools are not

suitable for developing a scenario based on another

scenario. Generation of a scenario and its analysis

are not sufficient for decision support environment.

To address the problems and issues raised we

followed an iterative process of

observation/evaluation, theory building, and systems

development (

Nunamaker, Chen and Purdin, 1991).

Wherein we proposed and implemented a flexible

framework and architecture for a scenario driven

decision support systems generator (SDSSG). A

prototype was developed, tested and evaluated using

the evaluation criteria for quality and

appropriateness of scenarios (

Schoemaker, 1995) and

principles of DSSG framework and architecture

(

Collier, Carey, Sautter and Marjaniemi, 1999; Geoffrion,

1987

). The conceptual framework as well as the

prototype was modified on the basis of the findings

and the process continued until a satisfactory result

was achieved.

In the rest of this paper, we first introduce a life

cycle approach for management of scenarios

including a detailed discussion of handling

homogeneous and heterogeneous scenarios. We then

propose a scenario-driven flexible decision support

framework and follow this up with a discussion on

how it realises the scenario management process.

We then present an n-tiered architecture that details

the SDSSG framework. Finally we discuss the

implementation platform and domain within which

the proposed process, framework, and architecture

were validated.

2 SCENARIOS: A DEFINITION, AN

EXAMPLE, AND A

MECHANISM FOR

STRUCTURING SCENARIOS

2.1 Definition of a Scenario

The definitions given in the previous section do not

give a complete picture of scenario modelling as

they do not entail the exact scenario structure.

Therefore, we define a proper implementation level

definition that addresses the structure of the problem

situation and its dynamic behaviour. A scenario is a

situation that is comprised of one or more problem

instances. A change in one scenario might have

chain effects on related scenarios. The basic

structure and behaviour of the scenario is similar to

the decision support system components model and

solver respectively. Hence we define scenario as a

complex situation analogous to a model that is

instantiated by data and tied to solver(s). Data,

model and solver take part in a complex hierarchical

relationship in scenario planning.

2.2 An Example Scenario

Before we discuss, scenario management, we

discuss an example that will be used during the

discussion of implementation. For example, the

mortgage management includes a series of external

environment sensitive inter-related scenarios. AMP

(2001) describes a mortgage scenario wherein

median wage and home price increases and the

interest rate drops. What is the impact of this change

or any other changes on individual buyer as well as

on the mortgage market? The change in interest rate,

average income of the people, demand and supply of

the home, etc. highly influence the mortgage

markets.

This scenario broadly depends on several other

scenarios e.g. affordability scenario, loan scenario,

and payment scenario. Affordability scenario helps

in understanding the borrower’s eligibility to get a

loan and capacity to repay the loan. The loan

scenario analyses the cost of financing, loan amount,

and instalment. Depending on the loan type, this

analysis process can differ widely. The payment

scenario analyses instalment, interest payment,

principal repayment, and loan balance. The payment

scenario addresses the entire life cycle of the loan

repayment. Affordability scenario is a constraint to

the loan analysis scenario. Each of these scenarios

can again be disintegrated into several smaller

scenarios e.g. affordability scenario depends on the

income scenario and expense scenario while income

scenario may be sub-divided into personal income

SCENARIO MANAGEMENT: PROCESS AND SUPPORT

scenario and family income scenario. All these

scenarios are inter-related and the higher level

scenarios are dependent on the lower level scenarios.

Sensitivity analysis and goal-seek analysis of these

scenarios would greatly enhance the decision

making process.

2.3 Structuring Scenarios

In view of addressing the complexity and inter-

relatedness of scenarios, we propose to divide

larger scenarios into multiple simple scenarios

having independent meaning and existence. In this

context we identify three types of scenarios,

namely:

• Simple Scenarios – The simple scenario is not

dependent on other scenarios but completely

meaningful and usable.

• Aggregate Scenarios – The results from multiple

scenarios are combined/aggregated together to

develop a more complex scenario.

• Pipelining Scenarios – One scenario is an input to

another scenario in a hierarchical scenario

structure. In this type of scenario, lower-level

scenario can be tightly or loosely integrated with

the higher-level scenario.

The decision maker may combine simple as well as

complex scenarios together using pipelining and

aggregation to develop more complex scenarios.

3 SCENARIO MANAGEMENT: A

LIFE CYCLE APPROACH

We introduce a scenario management process using

life cycle approach that synthesises and extends

ideas from Ringland (1998, 2002), Schoemaker

(1995), Albert (1983), Huss and Honton (1987), van

der Heijden, (1996), and Wright, (2000). The

proposed life cycle approach for scenario

management process addresses a variety of problem

scenarios. The life cycle process starts with scenario

idea generation and finishes with the usage of

scenario for decision support as illustrated in Figure

1. The following sections present all the phases of

the life cycle approach for scenario management.

3.1 Idea Generation

The scenario planner foresees the key issues that

exist within the scenario and analyses the concerns

for identifying the influential driving forces and

parameters for the scenarios. In addition the planner

may also use the existing scenario from the scenario

pool. The leading factors, which could be either

internal and/or external, could lead to various

changes on the system. The decision maker as a

domain expert predicts the possible changes of the

indicators that would guide to the development of

ideas for scenario planning.

3.2 Scenario Planning, Development

and Analysis

Figure 1: Scenario management: A life cycle approach

In this phase, the decision maker will carry out the

tasks of scenario planning and organisation, scenario

development, scenario execution, and what-if

analysis. Existing scenarios could also act as inputs

to this phase apart from the ideas generated from the

previous phase.

3.2.1 Scenario Planning and Organisation

Scenario planning includes the activities of

identification of the structure and components of

scenarios, sequence of scenario development and

execution as well as selection of scenarios for

analysis. The scenario organisation activities include

making available of already developed scenarios at

runtime and storing and retrieval of scenarios for

future use.

The components of the scenario can be either

pre-customised or loosely coupled. For a pre-

customised scenario, the relationships between data,

model, and solver as well as with other dependent

scenarios are fixed which is defined during scenario

planning. So the scenario components are tightly

integrated and the relationships are not exposed for

the decision maker. For a loosely coupled scenario,

the scenario components namely, the data, model,

solver, and dependent scenarios remain independent.

A mapping component is used to define the

relationship at runtime during scenario development.

ICEIS 2005 - ARTIFICIAL INTELLIGENCE AND DECISION SUPPORT SYSTEMS

The existing and newly developed scenarios are

cached in a runtime pool for developing pipelining

or complex scenarios. The developed scenarios and

the executed scenarios are stored in a scenario pool

for future use.

3.2.2 Scenario Development

Scenario planning and scenario development stages

are highly dependent on each other. Scenario

development is the process of conversion and

representation of planned scenarios into fully

computer based scenarios. Chermack (2003) argues

that s

cenarios have rarely been applied to develop

alternative processes.

The proposed life cycle

approach supports development of alternative

process models and scenarios. In this stage, the

decision maker organises the related data, model,

solver, and dependent scenarios for constituting the

relationships among them to develop scenario(s).

The decision maker could potentially use pre-

customised and/or loosely coupled scenarios. The

scenarios are developed in mainly two steps. In step

1, the basic scenarios of the domain are developed,

and in step 2, scenarios related to what-if (goal seek

and sensitivity) analysis are developed.

3.2.3 Scenario Execution

Our proposed scenario development process ensures

that the scenario can be executed and analysed for

determining plausibility. The models are instantiated

with the data, and then the model instance is

executed using the appropriate solver(s). Model

selection is completely independent while one or

more solvers may be used for a model execution. A

flexible mapping process bridges the state attributes

of the model and solver to engage in a relationship

and to participate in the execution process. For a

complex scenario, the decision maker may need to

apply several models and solvers to analyse various

aspects of the scenario.

3.2.4 What-if Analysis

What-if analysis can be divided into two categories,

namely sensitivity analysis and goal-seek analysis.

Sensitivity analysis assesses the impact of an

increase or decrease in any parameter or scenario

value over other scenarios. Sensitivity analysis

allows changing one or more variables/scenarios at a

time and analyses the impact on the related

scenarios. The main objective of sensitivity analysis

is to identify and analyse the amount of impact on

the related scenarios. Goal-seek analysis

accomplishes a particular task rather than analysing

the changing future. This analysis is just a reverse or

feedback evaluation where the decision maker

supplies the target output and gets the required input.

3.3 Scenario Evaluation Process

Scenario evaluation is a challenging task (Chermack,

2002)

but some end-states are predetermined dependent

upon the presence of an interaction of identified events

(Wright, 2000) which can be used to devise an evaluation

process.

The decision maker can develop many

scenarios. The question is – do all these scenarios

represent a unique situation? Each scenario might

appropriately draw the strategic question; represent

fundamentally different issues; present a plausible

future; and challenge conventional wisdom.

Schwartz

(1991) and Tucker (1999) discourage too

many scenarios and advocate for the use of best-case

scenario, worst-case scenario and most-likely

scenario. The evaluation is done through scenario

execution and comparison of the executed results.

The comparison may take place among

homogeneous scenarios or heterogeneous scenarios

as shown in Figure 2. This two-phase comparison

process is detailed in the following sections.

3.3.1 Homogeneous Comparison

Homogeneous scenarios are a similar type of

scenario but the instances are quite distinct from one

another. The decision maker selects a scenario

instance on completion of each homogeneous

scenario comparison. For example, in Figure 2, five

outer ellipses represent five different scenarios while

small ellipses e.g. T

and T

represent three

instances of type 1 scenario and the ellipse

containing Original represents the current instance

of type 1 scenario. These T

and original

instances

are compared and select the best plausible

scenario instance, which is T

as shown in the

Figure 2

If none of the instances is plausible, or do

not have an optimal result, then the decision maker

can repeat the whole processes. From this

homogeneous scenario comparison, the decision

maker can select at least one scenario instance for

each type of scenario. In Figure 2, the selected

scenario instances are T

and T

for

scenario type 2, 3, 4 and n respectively.

3.3.2 Heterogeneous Comparison

Heterogeneous scenarios are different types but

inter-related scenarios as shown in the big middle

circle in Figure 2. It is almost impractical to

compare heterogeneous as the attributes of these

scenarios are widely varied from one another. The

decision maker can only compare them by

presenting the executed scenario outputs using some

SCENARIO MANAGEMENT: PROCESS AND SUPPORT

common attributes. If the decision maker finds that

a specific instance of the scenario is not suitable for

heterogeneous comparison, then the whole process

can be repeated to identify a new instance for that

scenario. This gives the decision maker an excellent

picture of the entire decision problem and the

probable solutions. For example as shown in the

Figure 2, instance of five scenarios i.e. T

, T

, and T

have been compared with the

instance of the current situation during

heterogeneous comparison.

Figure 2: Scenario Evaluation Process

3.4 Decision Support

The above described scenario planning,

development, and evaluation through comparative

analysis results in improved participant learning (de

Geus, 1988; Shoemaker, 1995; Godet, 2001) and

help decision makers re-perceive reality from

several point of view (der Heijden et al., 2002) and

thereby better support for decision making.

The following section proposes a framework that

realises the proposed scenario management process.

4 SCENARIO DRIVEN FLEXIBLE

DECISION SUPPORT SYSTEMS

FRAMEWORK

Few of the DSS frameworks emphasise fully

featured scenario planning, development, analysis,

execution, evaluation and their usage for decision

support. DSS components such as data, model,

solver, and visualisation have been extensively used

in many DSS framework design but they did not

consider scenario as a component of DSS. Scenario

plays such an important role in the decision-making

process that it is almost impractical to develop a

good decision modelling environment while leaving

out this component. Scenario systems need to be

modelled. So they are more closely related to model-

driven DSS but the scenarios are more complex than

models. Therefore, the scenario-driven DSS might

add scenario as an independent component in

addition to existing decision-support components of

data, model, solver and visualisation.

The scenario does not have a separate existence

without its base components. It means that every

scenario is built up from a unique nature of the

problem (model) that can have a number of

alternative unique instances (data) and each instance

can be interpreted, executed or implemented using

one or more alternative methods (solver).

Scenario

To overcome the problems and address the issues

mentioned above we propose a scenario-driven

decision support systems generator (SDSSG)

framework as illustrated in Figure 3. The SDSSG

components are separated into the following two

categories:

• Decision-support components (DSC) that include

the data, model, solver, scenario and visualisation.

These components have a direct relationship with

the data pool, model pool, solver pool, scenario

pool, and visualisation pool.

• Integration Components (IC) that include Kernel,

Component Set, Mapping, and Validation

Component.

In this framework, the DSCs and ICs are

independent of each other. The DSCs communicate

via the kernel component. Mapping component

develops the correct path of communication between

data and model, and model and solver, while the

validation component tests the correct matching of

the component interface and the proper

communication between the components.

The data, model, solver, scenario, and

visualisation can be stored in different component

pools as shown in Figure 3 and the framework

allows retrieving these components from the

component pools. The related model, data and solver

can be combined together to develop a scenario.

This scenario can be saved to the scenario pool for

future use. This also allows using the scenario(s) as

an input for developing a number of simple,

aggregate, and pipelined scenarios. Every instance

of the scenario can be termed as a specific decision

support system. Therefore, the framework is a

generator of scenarios as well as the decision

support systems.

Scenario T

Scenario Type

Scenario T

e 2

Scenario T

e n

Note:

T – Scenario type

I – Scenario instance

1 –

Instance 1 of scenario

2 –

Instance 2 of scenario

Origin

Ori

Origina

Decisi

ICEIS 2005 - ARTIFICIAL INTELLIGENCE AND DECISION SUPPORT SYSTEMS

Scenario information can be saved and retrieved

to and from the scenario pool and the same can

again be customised using models and solvers. The

scenario instances can be used as complex data for

input to the next level of model for further analysis.

Different scenarios can be computed simultaneously

and sensitivity and goal-seek analysis can be done

using different scenarios. The framework is suitable

for analysing internally coherent scenarios or

scenario bundles, and examining the joint

consequences of changes in the environment for

supporting the decision maker’s strategy.

5 REALISATION OF THE

SCENARIO MANAGEMENT

PROCESS USING THE SDSSG

FRAMEWORK

In this section we discuss and illustrate (Figure 4)

the mechanisms through which the Scenario

Management Process is realised using the SDSSG

framework. Specifically we discuss the means by

which the framework supports all the life cycle

phases of the proposed scenario management

process. The key features of this framework are as

follows:

• Supporting Idea Generation: Allows retrieving

the required data, model, solver, and scenario

from the respective pools. The decision maker

develops a scenario that uniquely represent an

instance of a scenario type through establishing

the relationships among these retrieved scenario

components. A problem can be represented by

different models and various solvers may be used

for their execution. Therefore it supports

generation of multiple instance of a scenario

through various combinations of constituent

components.

Figure 3: SDSSG framework

• Scenario Planning: Supports the planning of

modelling-based scenario structure, pre-

customised and loosely coupled scenario.

• Runtime Scenario Organisation: Incorporates a

runtime only temporary storage system named

Runtime Scenario Pool (RSP) to store the

completed scenarios. The completed scenario(s)

can be pulled from the RSP to develop complex

scenarios and this completed scenario can again be

stored in the RSP.

• Scenario Storing and Retrieving: Allows saving,

retrieving, updating or deleting the scenarios from

the scenario pool using the data access

component. The RSP is linked with the

component set through the Kernel and data

components. So the scenario can be saved to the

scenario pool of the component pool.

• Scenario Development: The basic scenario is

developed using building blocks such as data,

model, solver, and previously executed scenarios.

The sensitivity scenario and goal-seek scenario

analysis processes use the original data source,

user input data regarding the changes of scenario

parameter, dependent scenario values from the

runtime scenario pool with related sensitivity

model(s) and solver(s).

• Development of Aggregate and/or Pipelined

Scenarios: In a pre-customised pipelining system,

scenarios are pre-defined as a chain from lower

level to upper-level scenarios. The upper-level

scenarios directly receive the executed value of

the lower-level scenarios. But in loosely coupled

scenarios, a top-level scenario uses the values of

the lower-level scenario from the runtime scenario

pool.

• Scenario Selection: The framework allows the

user to select any scenario depending on the

suitability and appropriateness of the scenario.

• Scenario Execution: The framework facilitates

instantiation of model with the data and execution

of the instantiated model with appropriate solvers.

• Scenario Evaluation: The framework supports

evaluation of scenarios through visualising the

output of basic, sensitivity, and goal-seek

scenarios in a comparison table or graphs.

• Decision Support: The framework supports

Simon’s (1960) decision making phases. These

phases are comparable to scenario generation,

analysis, comparison, and selection of plausible

scenarios. Scenario analysis and evaluation using

the comparison process increase the cognitive

knowledge of users which in turn supports and

leads them towards the final decision.

SCENARIO MANAGEMENT: PROCESS AND SUPPORT

6 SDSSG ARCHITECTURE

In order to implement the SDSSG framework we

develop a component-based layered architecture as

shown in Figure 5 that is suitable for implementation

as an n-tiered system. The proposed architecture is

comprised of the user services tier, application tier,

and component base tier and the layers are user

services, integration, data access, decision support

services, application customisation, and component

pool. The component pool layer stores data, model,

solver, and scenario. The data access layer provides

components’ management services. The decision

support services layer provides the service of model,

solver, scenario, and visualisation. The integration

layer provides validation and mapping services

during integration, instantiation and execution of

decision support components.

The architecture separates the decision-support

components from the integration components. It

supports independent development and use of the

components, flexible scenario modelling, scenario

manipulation and integration, flexible mapping

between different DSS components, flexible

integration of DSS components, and finally scenario

analysis. Pre-customised and customisable

modelling system can be achieved through pre-

defined relationships and the mapping component

respectively. This mapping component facilitates

dynamic communication between model-data,

model-solver, and model-visualisation.

The architecture separates the decision-support

components from the integration components. It

supports independent development and use of the

components, flexible scenario modelling, scenario

manipulation and integration, flexible mapping

between different DSS components, flexible

integration of DSS components, and finally scenario

analysis. Pre-customised and customisable

modelling system can be achieved through pre-

defined relationships and the mapping component

respectively. This mapping component facilitates

dynamic communication between model-data,

model-solver, and model-visualisation.

7 IMPLEMENTATION 7 IMPLEMENTATION

The framework and architecture can be implemented

using any platform that supports component-based

development. Object-orientation is the central focus

of the SDSSG framework and architecture. Since

scenario planning has been centred on business cases

(Ringland, 2002), the SDSSG framework and

architecture were implemented and tested within the

context of the mortgage domain provided in section

2.2. We implemented base scenarios e.g.

affordability scenarios, lending scenarios, payment

scenarios, etc. We then explored a number of

alternative scenarios including the best-case and

worst-case scenarios through sensitivity analysis and

evaluated the executed instances of homogeneous or

heterogeneous scenarios through comparison.

The framework and architecture can be implemented

using any platform that supports component-based

development. Object-orientation is the central focus

of the SDSSG framework and architecture. Since

scenario planning has been centred on business cases

(Ringland, 2002), the SDSSG framework and

architecture were implemented and tested within the

context of the mortgage domain provided in section

2.2. We implemented base scenarios e.g.

affordability scenarios, lending scenarios, payment

scenarios, etc. We then explored a number of

alternative scenarios including the best-case and

worst-case scenarios through sensitivity analysis and

evaluated the executed instances of homogeneous or

heterogeneous scenarios through comparison.

Within each of these scenarios we explored

sensitivity and goal-seek analyses. The system was

tested and evaluated for sensitivity analysis for

refinancing from different lending sources, and

increase or decrease of the interest rate, loan

amount, initial payment, instalment, and pay period.

Apart from this we also explored sensitivity analysis

on complex interlinked scenarios which in turn were

Within each of these scenarios we explored

sensitivity and goal-seek analyses. The system was

tested and evaluated for sensitivity analysis for

refinancing from different lending sources, and

increase or decrease of the interest rate, loan

amount, initial payment, instalment, and pay period.

Apart from this we also explored sensitivity analysis

on complex interlinked scenarios which in turn were

Figure 5: SDSSG architecture

Component

Management

System

Component Set

(Data, Model,

Solver, Scenario)

Component Base

Model

Data

Pool

Solver

Scenario Pool

Base Scenario

User Input

Integration

• Kernel

• Mapping

Runtime Scenario Pool

Scenario

Sensitivity Scenario

Model

User Input

Solver

Visualization

Goal Seek Scenario

User Input

Visualization

Independent Model

Dependent Model

Independent Model

Instance

Solver

Figure 4: Realisation of the scenario management process using the SDSSG framework

ICEIS 2005 - ARTIFICIAL INTELLIGENCE AND DECISION SUPPORT SYSTEMS

made up of sub-scenarios. The prototype supports

different level of users. A DSS builder may

configure the SDSSG system and develop and store

different scenarios as well as specific DSS for future

use by the naïve users.

8 CONCLUSION

Current scenario planning and analysis systems are

very complex, not user friendly, and do not support

modelling and evaluating multiple scenarios

simultaneously. To overcome these problems we

propose a scenario management life cycle, and a

framework and architecture that support the

lifecycle. The lifecycle as well as the framework and

architecture are validated through a concrete

implementation of a prototype. Key phases of the

life cycle are idea generation, scenario planning,

organisation, development, execution, analysis,

evaluation, and finally decision support. The process

hides external factors and complexities of the

scenario and allows the seamless combination of

decision parameters for appropriate scenario

generation. This research also proposes a generalised

scenario evaluation process that allows

homogeneous and heterogeneous scenario

comparisons among the multiple instances of similar

and dissimilar scenarios respectively.

This research develops a generic scenario driven

flexible decision support systems generator

framework and architecture that supports the above-

mentioned scenario management processes. Scenario

has been introduced as a new DSS component.

REFERENCES

Albert, K. J., (1983). “The Strategic Management

Handbook”, McGraw-Hill.

Alter, S.L, (1980). “Decision Support Systems: Current

Practice and Continuing Challenge”, Addison-

Wesley.

AMP (2001), 18 July. “AMP Banking Survey – New

Zealand home affordability highest for two years”,

Retrieved on 10 October 2001 from

http://www.amp.co.nz.

Chermack T. J., (2003). A Methodology for Assessing

Performance-Based Scenario Planning,. Journal of

Leadership & Organizational Studies 10 (2): pp. 55

Chermack, T. J., (2002). The mandate for theory in

scenario planning. Futures Research Quarterly, 18(2),

25-28.

Collier, K., Carey, B., Sautter, D., and Marjaniemi C.,

(1999). “A Methodology for Evaluating and Selection

Data Mining Software”, Proceedings of the 32nd

Hawaii International Conference on System Sciences.

De Geus, A., (1997). “The Living Company: Habits for

Survival in a Turbulent Business Environment”,

Harvard Business School Press.

De Geus, A. (1988). Planning as learning. Harvard

Business Review, 66 (2), 70-74.

Epstein, J. H., (1998). “Scenario Planning: An

Introduction”, Futurist, 32(6): 50-51.

Geoffrion, A., (1987). An Introduction to Structured

Modelling, Management Science, 33 (5) pp. 547.

Godet, M., (2001). Creating futures: Scenario planning as

a strategic management tool. London: Economica

Publishing.

Huss, W.R., and Honton, E. J., (1987). Scenario Planning:

What Style Should You Use?, Long Range Planning,

April.

Kloss, L. L., (1999). “The Suitability and Application of

Scenario Planning for National Professional

Associations”, Nonprofit Management & Leadership,

10(1): 71-83.

Nunamaker, J. F. Jr., Chen, M., and Purdin, T.D.M.,

(1991). “Systems Development in Information

Systems Research”, Journal of Management

Information Systems, 7(3), pp. 89 – 106.

Porter, M., (1985). Competitive Advantage, New York,

Free Press.

Ringland, G., (1998). “Scenario Planning- Managing for

the Future”, John Wiley & Sons.

Ringland, G. 2002. Scenarios in business. New York: John

Wiley & Sons.

Ritson, N., (1997). “Scenario Planning in Action”,

Management Accounting, London, 75(11): 24-28.

Schoemaker, P. J H., 1995. “Scenario Planning: A Tool

for Strategic Thinking”, Sloan Management Review,

36(2): 25-40.

Schoemaker, P.J.H., (1993). “Multiple Scenario

Development: Its Conceptual and Behavioural

Foundation”, Strategic Management Journal, 14(3):

193-213.

Schwartz, P., (1991). “The Art of the Long View”, ISBN 0-

385-26731-2, Doubleday.

Simon, H.A., (1960). “The New Science of Management

Decision”, NY: Harper and Row, New York.

Tucker, K., (1999). “Scenario Planning”, Association

Management, 51(4): 70-75, April.

van der Heijden, K., (1996). “Scenarios, The Art of

Strategic Conversation”, Wiley.

van der Heijden, K., Bradfield, R., Burt, G., Cairns, G., &

Wright, G., (2002). The sixth seme: Accelerating

organizational learning with scenarios. New York:

John Wiley.

Wack, P., (1985). “Scenarios, Uncharted Waters Ahead”,

Harvard Business Review

Wright, A. D., (2000). Scenario planning: A continuous

improvement approach to strategy.

Total Quality

Management: 11 (4-6) pp. S433-438

SCENARIO MANAGEMENT: PROCESS AND SUPPORT