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.
50
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
Copyright
c
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
51
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
52
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
1
I
1,
T
1
I
2
and T
1
I
3
represent three
instances of type 1 scenario and the ellipse
containing Original represents the current instance
of type 1 scenario. These T
1
I
1,
T
1
I
2,
T
1
I
3
and original
instances
are compared and select the best plausible
scenario instance, which is T
1
I
3
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
2
I
3,
T
3
I
1,
T
4
I
2,
and T
n
I
1
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
53
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
1
I
3
, T
2
I
3
,
T
3
I
1
, T
4
I
2
, and T
n
I
1
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
yp
e
Scenario Type
Scenario T
yp
e 2
Scenario T
yp
e n
Note:
T – Scenario type
I – Scenario instance
T
1
I
1 –
Instance 1 of scenario
1
T
1
I
2 –
Instance 2 of scenario
T
1
I
1
T
1
I
2
Origin
Ori
g
i
T
2
I
2
T
2
I
1
T
3
I
3
T
3
I
2
Ori
g
in
T
4
I
1
T
4
I
3
Ori
g
i
T
n
I
3
Ori
g
i
T
n
I
2
T
2
I
3
T
3
I
1
T
4
I
2
Origina
T
n
I
1
T
1
I
3
Decisi
on
ICEIS 2005 - ARTIFICIAL INTELLIGENCE AND DECISION SUPPORT SYSTEMS
54
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
55
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
P
oo
l
Data
Pool
Solver
P
oo
l
Scenario Pool
Base Scenario
User Input
Integration
Kernel
Mapping
Runtime Scenario Pool
Scenario
1
Scenario
2
Scenario
3
Scenario
n
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
56
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
57