A Proposal for an Environmental Decision Support System at the Regional Level: Concepts, Support Methodology, Tools and their Terminology

(1)

NOT FOR QUOTATION WITHOUT PERMISSION OF THE AUTHOR

A PROPOSAL

PDR

AN ENVIRONMENTAL DECISION SUPPORT SXWEX AT THE REGIONAL

LEVEL:

CONCEPTS, SUPPORT

~ O D O L O G Y , TOOLS AND

THEIR

TERMINOLOGY

A Griibler (IIASA) F. Katsonis (ILASA) B. Mazzoni (CSI) S. Wooding (CSI)

August 1984 CP-84-38

Collaborative Papers report work which has not been performed solely a t t h e International Institute for Applied Systems Analysis and which has received only limited review. Views o r opinions expressed herein do not necessarily represent those of t h e Institute, its National Member Organizations, or o t h e r organizations supporting t h e work.

INTERNATIONAL INSTITUTE FOR APPLIED SYSTEMS ANALYSIS 2361 Laxenburg, Austria

(2)

(3)

Arnulf Griibler and Francoise Katsonis a r e with t h e International Insti- t u t e for Applied Systems Analysis, A-2361, Laxenburg, Austria.

Bruno Mazzoni a n d S t u a r t Wooding a r e with t h e Center for Information Systems (CSI), Corso Unione Sovietica 216, 10134 Torino, Italy.

(4)

(5)

The financial support of t h e Consorzio p e r il Sistema Informativo (CSI) for t h i s study is gratefully acknowledged.

(6)

(7)

PREFACE

One of t h e goals of IIASA's r e s e a r c h activities in t h e a r e a of environ- m e n t a l quality modelling is t h e integration of d a t a and models i n a uni- fied framework t o assist decision m a k e r s with t h e m a n a g e m e n t of com- plex environmental systems.

Building o n IIASA's work undertaken within t h e WELMM (Water, Energy, Land, Materials a n d Manpower) project of t h e former Resources and Environment Area a n d t h e work on Decision Support Systems of t h e former Management and Technology Area, a conceptual framework for an environmental decision support system (EDSS) h a s been developed and i s presented in t h i s paper. The proposed EDSS h a s been developed with t h e i n t e r e s t a n d t h e financial support of t h e

CSI,

t h e Center for Information Systems of t h e Regional Government of Piemonte, Italy.

The main issue addressed by this paper i s t o devise a system assist- ing decision m a k e r s in tackling environmental problems a t t h e regional level. These decisions a r e typically c h a r a c t e r i z e d by a combination of both s f m c h r e d (formalizable, described in a quantitative model) a n d unstructured e l e m e n t s (incomplete information, undefined cause-effect relationships, influence of political objectives, public perception, con- sideration OF estethics, etc.).

(8)

The proposed EDSS enables the user to use models and data, of relevance to a particular task, which a r e embedded in t h e EDSS in the form of a process information system. The specific feature of this process information system is t h a t i t contains processes of anthropogenic nature (the socio-economic activities being the cause of environmental impacts like power plants, industrial production units, etc.) as well as natural processes determining t h e spatial/tempord distribution and the extent of environmental quality changes (like the dispersion and deposition of air pollutants and their effect on human population, vegetation and wildlife).

The system ensures t h a t the data and models, which have been developed in the context of specific EDSS applications a r e documented right from the outset and become thus equally available for further use.

This becomes especially important in view of the long-term effort to be put into t h e development of data and models dealing with the large number of environmental problems that governments, industry and academic institutions a r e confronted with a t the regional level.

Dr. Eliodoro Runca

Impacts of Human Activities on Environmental Systems

(9)

CONTENTS

1. INTRODUCTION

2. WHAT DO WE UNDERSTAND BY AN ENVIRONMENTAL DECISION SUPPORT SYSTEM (EDSS)?

2.1 Decision Support Systems

2.1.1 The Decision Making Process (Cycle)

2.1.2 Structured versus U n s t r u c t u r e d Tasks i n t h e Decision Making Process

2.1.3 Management Levels 2.1.4 EDSS User Community 2.2 EDSS lmplementation Strategies 2.3 Levels of t h e Tools of t h e EDSS

3. DOCUMENTATION LANGUAGE FOR THE DECISION MAKlNG PROCESS AND EDSS OPERATlON

(10)

4. TOOLS OF THE EDSS: DATA BASES 4.1 Types of information in the EDSS 4.2 What is a Process?

4.3 Process Data Base versus Resource Data Base 4.4 The EDSS Process Data Base

4.4.1 Concepts and Conventions for Development a n d lmplementation of Process Descriptions

4.4.2 Process Hierarchy a n d Process Aggregation a n d Disaggre- gation

4.5 Process Description in t h e EDSS Process Data Base 4.5.1 The Process Topography

4.5.2 Process Models

4.5.3 Process Model Data Base 4.5.4 Process Observations 4.6 Resource Data Base (RDB) 4.7 Bibliographic Data Bases

4.8 Some Thoughts on Other Tools of t h e EDSS

4.9 A Summary of EDSS Documentation Tools a n d their Conceptual Equivalences and Relation to Formal EDP Documentation

APPENDICES: ^.BACKGROUND MATERIAL, REFERENCES AND SYNONYMS RELATIVE TO THE EDSS

APPENDIX 1 : An Introduction t o t h e Region of Piemonte a n d t h e Organizational Environment in which t h e EDSS will be implemented

Appendix Al-1: The Region of Piemonte Appendix A1-2: The Public Administration

Appendix A1-2: The Center for Information Systems (CSI) References for Chapter 1 a n d Appendix 1:

(11)

APPENDIX 2: Decision Making Cycles and Decision Support Systems Appendix A2-1: An Introduction to Decision Support Systems

(DSS)

Appendix A2-2: Decision Support Systems (DSS), Management Information Systems (MIS) and Operational Research/Management Science (OR/MS)

References for Chapter 2 and Appendix 2

APPENDIX 3: EDSS Documentation Languages

Appendix A3-1: SADT a s a Decision Making Cycle Doumentation Language

Appendix A3-2: An Illustration

Rererences for Chapter 3 and Appendix 3

APPENDIX 4: Process Information Systems, Process Data Base Tools and Associated EDSS Software

Appendix A4-1: A Brief Discussion of Process Information Sys- t e m s with Reference to the IIASA Facility Data Base and t h e Process Encyclopedia Data Base of Statistics Canada

A4-1-1: The Facility Data Base of t h e b'ELMM Approach A4-1-2: The Process Encyclopedia Project of Statistics

Canada

A4-1-3: Conclusions on Process Infomation Systems Appendix A4-2: Process Data Base Tools: Examples for Process

Topographies, Process Model Documentation Language, Process Paradigms and other Proposed EDSS Tools

Appendix A4-3: The Process Model Documentation Language Appendix A4-4: A Reference to Some Other Software Tools of

Relevance to t h e EDSS References for Chapter 4 and Appendix 4

APPEhQIX 5 : Summary of Terms and (Partial) Synonyms of t h e EDSS

(12)

(13)

A PROPOSAL FOR AN ENVIRONMENTAL DECISION !3UPF'ORT S r S I X M AT THE REGIONAL IXVEL CONCEPTS. SUPF'OIZT

~ O D O L O G Y . TOOIS AND

THEIR

TEXMlNOlDGY

k Griibler (IIASA), F. Katsonis (IIASA), B. Mazzoni (CSI) and S. Wooding (CSl)

1. INTRODUCTION

The objective of this paper is t o propose a framework t o assist decision m a k e r s in t h e m a n a g e m e n t of environmental problems a t t h e regional level. The framework i s t o be i m p l e m e n t e d within an organizational environment, characterized by a classical electronic d a t a processing (EDP) background. in which t h e a r e a of Decision Support Systems (DSS) is a relatively new field. Therefore, some emphasis will be devoted t o t h e concepts of DSS, addressing s e m i - s t m c t u r e d problems (typical within t h e environmental a r e a ) , a s well a s how t h e DSS intervenes a t t h e various phases of t h e decision making process. For reasons of clarity we have refrained From discussing in depth many of t h e concepts introduced i n t h e paper. Instead, they a r e elaborated in t h e a p p e n d i c e s , which also c o n t a i n t h e references a n d l i t e r a t u r e sources, suggested for f u r t h e r

(14)

reading. With respect t o t h e tools proposed (as well a s t o t h e illustration of t h e proposed DSS t o a n applied study field), we would like t o s t r e s s t h a t t h e m a i n purpose is illustrative. However, t h e examples given show t h a t tools and methodologies supporting t h e proposed DSS, whether t h e y come from traditional EDP, from economic t h e o r y o r t h e applied n a t u r a l r e s o u r c e analysis field do exist and can provide direct input t o a DSS such a s t h a t outlined in t h e paper.

In s u m m a r y , t h e paper's p r i n c i p a l pu7pose is t o define a d e c i s i o n s u p p o r t m e t h o d o l o g y and a r e s u l t i n g s y s t e m of duta b a s e s , t o be used by t h e decision maker's s u p o r t o r g a n i z a t i o n (i.e. t h a t of t h e CSI

-

^see

appendix I), r a t h e r t h a n by t h e decision m a k e r himself. Thus, t h e design proposed was strongly influenced by t h e CSI's operational context (i.e.

type of application a r e a s addressed, methodologies a n d tools selected, etc.). Finally, we note t h a t the s y s t e m is "ad hoc" in t h a t i t was specifi- cally tailored t o t h e afore-mentioned operational context a n d ( a t present) is intended t o support policy formulation, implementation and evaluation in t h e environmental a r e a (hence, i t i s nominated a n Environ- m e n t a l Decision Support System (EDSS)). However, it is g e n e r a l i z e d in t h a t i t a i m s t o be relevant to (a) a wide range of s e c t o r specific environ- m e n t a l problems (each of which is characterized by i t s own "peculiar"

context a n d content) and (b) t h e interrelationships between s u c h s e c t o r specific problem areas. This feature in t h e context of a n environmental DSS s e e m s essential, a s t h e e n d user (i.e. t h e public sector, decision makers, t h e administrators, politicians, etc.) is, often, a s concerned with t h e credibility of his policies in a r e a s outside of h i s immediate sphere of influence a s with t h e i r efficacity in h i s "own" area. Further,

(15)

environmental management a t t h e regional scale (the scale discussed) often includes "global" decision making (e.g. to be banal, increase environmental exploitation to increase economic growth, improve social recreational facilities and decrease environmental degradation) t h a t is, by definition, both horizontal (i.e. crosses sector specific areas) and vertical (i.e. entails the analysis of sector specific areas in the effort to resolve issues such as conflicting objectives, limited resources, etc.) i n nature.

I t follows from t h e above, t h a t the paper is not addressed to DSS End Users. It .is p?-i?nariLy intended for technical support staff who a r e interested in building DSS frameworks (in particular, in t h e application area discussed), but have little experience of the DSS field. It is assumed that the reader has a certain familiarity vfith areas such as EDP, PIS (Process Information Systems), MIS (Management Information Systems), OR (Operational Research), MS (Management Science). etc.

,2.

WHAT

DO WE UNDEFCTAND I3Y AN ENVIRONMENTAL DECISION SUPPORI' S'YSI'EM (EDSS)?

By a decision support system (DSS) we understand an interactive computer based system t o assist a particular (group of) decision maker(s) to use data and models for solving specific tasks relative to t h e management of environmental problems a t t h e regional level.

We use t h e term environment in a wide sense, a s the DSS operates (contains data and models) a t three levels;

anthropogenic activities (i.e. the socio-economic activities changing t h e status of the environment, like industrial or energy production, agriculture or urbanization);

(16)

nafural p r o c e s s e s determining (a) the spatial and/or temporal evolution of environmental quality changes and possible transformations (e.g. chemical reactions in t h e air, water or soil) like the dispersion and deposition of air pollutants; and (b) determining the form and extent of their impacts (e.g. impacts on aquatic or terrestrial ecosystems or on human population);

s o c k t a l / o r g a n i z a f i o n a l s t m c t u r e s within which t h e DSS operates; whose decision making processes it documents and aims to improve. I t is a t this level t h a t formal (e.g. air quality standards) or judgemental (e.g. esthetics) criteria or societal values (e.g. public perception, political criteria) a r e formulated to assess and to evaluate the consequences and impacts described a t the levels of anthropogenic activities and natural processes.

2.1. Decision Support Systems

The concept of DSS (appendix A2 provides a more detailed discussion of DSS than that provided here) and especially how it relates and differs to t h e characteristics of operational research or management science (OR/MS), management information systems (MIS) or classical electronic data processing (EDP) can best be illustrated by looking a t DSS from the viewpoint of t h e decision makers/usersl. DSS are thus characterized by operating in a t h r e e - d i m e n s i o n a l f r a m e w o r k defined by: (a) the p h a s e s of the d e c i s i o n - m a k i n g p r o c e s s ; ( b ) the m a n a g e m e n t l e v e l ( s ) where the 'DSS from the viewpoint of the DSS designer/builder will be discussed in the later sectiom of the DSS tools. The third possible viewpoint, the so-celled "toolsrnitl~'~" or programmer's viewpoint will not be discussed in detail in this paper.

(17)

decision is made and (c) the t y p e of t a s k s to be performed in a decision- making process (see Figure 1).

DSS a r e defined to assist decision makers in (a) all phases of t h e decision making process and (b) a t all management levels based on a detailed understanding and description of t h e decision making process itself. Finally and most important, DSS a r e designed to support decision makers i n t h e context of semi-structured tasks2 (i.e. tasks which consist of s t r u c t u r e d (formalizable) and unstructured elements).

Of course, many of the concepts of DSS a r e also characteristics of

MIS

and the fields of OR/MS in general. Howeuer, DSSrepresent a distinct field f r o m

at

least t w o vieurpoints. f i r s t l y , in t e r n of approach; in particular. that the effective design of management oriented information systems m u s t be based on a detailed understanding of management decision processes u t i l i z i n g diugnostic and descriptive methodologies r a t h e r than the prescriptive and/or normative methods typical of OR/MS.

Sscondly, DSS are, d i s t i n c t in t e r m s of their i m p a c t on and relevance for managers/users. DSS imply the use of computer related technologies and sciences to:

1. support managers in relation to decision making in t h e context of semi-structured tasks;

2. aid managerial judgement r a t h e r than replace it;

' h r n the viewpoint of the decision maker/user we refer simply to hard or difficult prob- lems, as the concept of structure is heavily dependent on the decision maker's perception and performance in the pheses of the decision making process where the structured and un- structured elements of a task are defined.

(18)

Phases of the Decision Making Process

Intelligence (MIS)

Implementation

(MIS)

I

Management Operational Management Strategic

Control Control Planning

CI

?h

Type of Tasks

Acronyms: EDP : Electronic Data Processing DSS : Decision Support Systems MIS : Management Information Systems MS : Management Science

OA : Office Automation OR : Operational Research WP : Word Processing

Level

Figure 1.

DSS

as defined from the managersO/users' viewpoint.

(19)

3. improve the e f f e c t i v e n e s s of decision making as distinct from its e f f i c i e n c y . Here DSS are concerned with issues such a s managerial cognitive processes, learning methods, etc., a s opposed to cost or personal reduction or increase in turnaround times.

2.1.1. The Decision Making Process (Cycle)

Here we present a five level model of the phases of the d e c i s i o n mak- ing process to which diagnostic and descriptive methodologies3 can be applied.

These five phases may be summarized as follows:

-

intelligence (searching t h e environment for conditions calling for decisions). This phase is typically characterized b y u n s t m c - h r e d s e a r c h for raw data, its processing and analysis as well 4 as other structured and unstructured inputs (e.g. organizational procedures, legal standards, political objectives, and t h e like);

-

d e s i g n (inventing, developing and analyzing possible courses of action). I t is a t this phase in the process to understand the problem t h a t possible solutions are generated and tested and a first formulation of the structured and unstructured elements of t h e task is undertaken and fed back to t h e intelligence phase. The main emphasis of t h e EDSS in this phase will be on Here we refer the reader to the later sections of this paper dealing with the SADT stmctur- d analysis and design technique and its application to represent the decision making p r e

Oess and its phases.

Note the relationship to EDSS tools like a system thesaurus, hierarchical data access and filtering software and data base management systems (DBMS).

(20)

d o c u m e n t a t i o n of how t h e user perceives possible solutions (alternatives) to the problem u s i n g t h e s a m e r e p r e s e n t a t i o n t e c h n i q u e s as deployed in t h e intelligence phase. In addition, the user should have access to previously generated solutions (especially of other user communities) and to already existing formalizations of relevant natural and/or socio-economic processes 5

. .

-

choice ( s e l e c t i n g a p a r t i c ~ d a r c o u r s e of a c t i o n f r o m those m a i l - able). In this phase, t h e traditional normative/prescriptive methods of MS/OR have their prime use and form part of t h e EDSS. In addition, t h e EDSS must allow t h e user to interactively introduce subjective choice criterion complementing or replacing structured (formal) choice criteria. The choice phase feeds back to the design and intelligence phases.

-

i m p l e m e n t a t i o n : In this phase, t h e EDSS should allow a u s e r t o m o n i t o r t h e i m p l e m e n t a t i o n of t h e courses of action decided i n t h e choice phase (budget spending, acquisitions, etc.,) provid- ing t h u s a feedback concerning difficulties in t h e implementation and t h e formulation of additional problem areas for t h e intelligence phase.

-

e v a l u a f i o n : This is

-

although up t o now in the DSS literature not sufficiently recognized

-

a crucially important step 6

.

haluation i m p r o v e s , b y l e a r n i n g f r o m e z p e r i e n c e , t h e

"

Here we refer to the process and process model data base of the EDSS, discussed in more etail in the EDSS tools section.

'

Note that only through evaluation the decision maker can learn more about his effectiveness in t h e earlier phases of t h e decision making cycle and is able to improve his performance in them. A typical problem area in environmental studies is for example, t h a t t h e boundaries of the system analyzed are drawn in a too narrow way. Thus decisions solving one

(21)

execution and results of the four earlier phases in the decision making cycle. The main emphasis here is not on t h e EDSS as such (quality of access, speed of response, etc.,), but on the i m p r o v e m e n t of the decision m a k e r s prazis through use of the supportive tools forming the EDSS framework. Although many formal evaluation techniques (decision output tables, software records of user behaviour and the like) exist, the most impor- t a n t point to be considered is t h e EDSS seen a s a learning tool enabling t h e u s e r t o improve his effectiveness in the various phases of his decision making process. This also results in specific EDSS design and implementation strategies facilitating u s e r learning, feedbacks to modify his decision making model or the descriptive/functional models involved in t h e task, and enabling generally t h e improvement of his decisions. These strategies, referred to in t h e DSS literature as "adaptive approaches", "middle-out design", etc., will be discussed in more detail in t h e EDSS implementation strategy chapter.

2.1.2. Structured versus Unstructured Tasks in the Decision Making _Process

Here the t e r m s t r u c t u r e refers to the distinction of programmed and non-programmed tasks used in Management Science, i.e., t o their degree of formalization. S t r u c t u r e d tasks can be automated or routin- ized, t h u s replacing judgement, whereas unstructured tasks a r e purely judgemental and defy automization. S e m i - s t m c t u r e d tasks permit problem (e.g. reduction of air emissions through control devices) is creating another problem in a larger system (e.g. sludges and waste disposal, water pollution, economic impacts, etc.).

(22)

s y n t h e s i s of h u m a n j u d g e m e n t a n d c o m p u t e r c a p a b i l i t i e s .

Another d e f i n i t i o n of s t r u c t u r e lies in t h e d i f f e r e n t i a t i o n between observable (like electricity consumption, stack height, etc.,) and s u b j e c - live (non-observable) variables (e.g. esthetics) considered in a particular task, as for instance, the location of a power plant.

Typically, in a decision-making process the task s t a r t s as a s t r u c - t u r e d one (in considering only "hard" economic or engineering type of criteria) with "soft" o r subjective criteria being added successively until a final decision is reached. However, a task may s t a r t a t t h e strategic planning level a s an u n s t r u c t u r e d one (e.g. "do something about t h e public concern for environmental quality") and gets decomposed t o a number of s t r u c t u r e d or semi-structured tasks involving the lower management levels in t h e phases of the decision making process.

However, we have t o realize t h a t it is not always immediately clear whether structure i s simply perceptual o r intrinsic to a particular task.

Also, t h e degree of s t r u c t u r e of a task may be socially defined as well a s being perceptual t o the decision maker. An objective of the EDSS is t o assist the user in t h e structurization of his task(s) during t h e design phase of his decision making cycle (i.e. by way of the earlier mentioned documentation of his decision making process, access to earlier generated solutions, e t ~ . ) , and through t h e constraints ("disciplines") imposed on him by t h e EDSS tools available, in particular SADT, t h e process and the process model d a t a base, etc., as discussed later.

(23)

2.1.3. Management Levels

The l a s t dimension of t h e EDSS a r e the m a n a g e m e n t l e v e l b ) in which t h e decision i s made. Here we distinguish t h r e e basic levels: s t r a - t e g i c p l a n n i n g , i.e. t h e level of t h e r e l a t i o n s of a n organization with i t s environment (strategic planning of a n organization); m a n a g e m e n t c o n - trol (i.e. m a n a g e m e n t a n d coordination of different activities in view of t h e objectives defined a t the s t r a t e g i c planning level); a n d o p e r a t i o n a l c o n t r o l (i.e. t h e m a n a g e m e n t of a specific activity o r task).

2.1.4. EDSS User Community

l h e u s e r c o m m u n i . f y of t h e EDSS d i s a g g r e g a t e s i n t o t h r e e b a s i c c l a s s e s :

( a ) users/decision m a k e r s proper within t h e above defined t h r e e m a n a g e m e n t levels a n d t h e previously mentioned t h r e e prob- l e m type categories (i.e. degree of formalization of task). These u s e r types a r e a p p l i c a t i o n o r i e n t e d .

(b) technicians/"toolsmiths", responsible for t h e EDSS develop- m e n t a n d maintenance. These a r e analysts, programmers, etc., developing a n d using EDSS tools in relation t o specific c a s e s t u - dies.

( c ) consultants t h a t interface ( a ) with (b). These c o n s u l t a n t s (referred t o a s "facilitators" "DSS builders" or "DSS g e n e r a t o r s "

)have t h e fundamental objective of creating specific applications a n d to a s s u r e proper u s e r participation.

(24)

The DSS g e n e r a t o r can be regarded as an additional level of DSS introduced when a s p e c i f i c DSS a p p l i c a t i o n c a n n o t b e d e v e l o p e d with e x i s t i n g DSS t o o l s . The DSS generator is of particular importance because of t h e n e e d f o r a f l e x i b l e a n d a d a p t i v e d e s i g n s t r a t e g y necessary in view of (a) organizational and environmental changes and (b) t h e users inability t o define clearly in advance t h e functional requirements of t h e system. Thus, DSS a r e distinct from traditional system develop- m e n t strategies, which a r e a p o s t e r i o r i developments following t h e defin- ition of the users' decision making process and t h e resulting software requirements.

The principal objectives for t h e DSS "facilitator" or coordinator a r e to:

-

e n t e r into t h e decision making process and c r e a t e t h e possibil- ity for t h e decision maker to use DSS.

-

i m p l e m e n t t h e DSS, control the project, handle t h e relation- ships with t h e users, t h e organizational details, etc.

-

e v a l u a t e t h e results of t h e innovative solutions, and

-

e d u c a t e by using t h e results of his evaluation task, improving t h u s t h e general performance of t h e users and enhancing t h e possibilities available to them (see "enter" objective above) through DSS.

(25)

2.2.

EDSS

Implementation Strategies

The DSS system building approach emphasizes the u s e of unalyticul methods that are diagnostic and descriptive in nature ( f u r t h e r discussed in appendix A2-2). Another feature is t h a t of basing t h e EDSS system design on t h e s t r u c t u r e , context and t h e dynamics70f a decision making process and t h e task i t involves within t h e three-dimensional DSS framework outlined above (see Figure 1). As such, systems aim t o be relevant t o "the daily praxis" of specific decision making situations. Thus t h e y have t o be tailored t o such situations and we cannot think of "typical designs". For example, t h e DSS discussed in this paper is an ad hoc sys- t e m designed for dealing with certain classes of environmental problems.

I t follows from t h e above, t h a t the use of a label "support system" is meaningful only in situations where t h e "final" system emerges through an adaptive and interactive process of design and use! This point is of particular importance t o us. It represents a large (cultural) difference with respect t o the design and implementation strategies used in classic EDP o r MIS. This requirement for flexible a n d adaptive design/implementation strategies is strongly emphasized (both by experience and) throughout t h e whole DSS l i t e r a t u r e independent from t h e particular nomenclature used (middle-out design, evolutionary approach, adaptive design etc. as f u r t h e r discussed in appendix A2-1).

Let us illustrate this point again: A task may involve various types of management levels (either simultaneously or consecutively). The number of unstructured elements of a task determine the amount of effort to be put into the understanding of a particular problem (intelligence and design phases of the decision making process) and determine the methodologies t o be used in the choice phase (e.g. optimization, multicriteria optimization, environmental impact assessment, etc.). A t a11 these phases, formerly unstructured elements of a task may be translated into structured ones or additional unstructured elements in- fluencing a particular decision may be introduced. Thus no u priori design of the EDSS is possible, in view of the dynamics of a particular task within the DSS framework.

(26)

The proposed EDSS h a s a design a n d implementation s t r a t e g y based on t h e diagnosis, description a n d documentation of t h e decision making process as well rzs t h e tasks involved in i t s various phases. 7h-k principle of representation prior t o application is the m a i n constraint for the EDSS u s e r . The tools proposed for t h i s representation ((a) diagrams for t h e decision making process from t h e viewpoint of the decision m a k e r a n d from t h e viewpoint of t h e EDSS builder; (b) process a n d process model diagrams t o r e p r e s e n t s t r u c t u r e d phenomena involved in a particular task) r e p r e s e n t a c o n s t r a i n t for t h e EDSS builder. They also provide the n e c e s s a q basis to Link the EDSSwith the other analysis and design tech- niques of classical EDP being used (for o t h e r projects) in t h e organizational environmentB in which t h e DSS operates. Thus, t h e proposed EDSS aims at integrating tools, languages, d a t a base m a n a g e m e n t systems, etc. with which t h e u s e r community i s already familiar, even though some of these. i n t h e i r implementation within t h e EDSS might require hardware/software translation solutions.

As s t a t e d above, t h e principle of representation r e s u l t s in t h e neces- sity t o employ representational tools (i.e. pictorail/graphical techniques, languages, etc.

-

e a c h of which i s presented in detail l a t e r ) for t h e analytical description a n d diagnosis of (a) t h e decision making process (cycle), i t s tasks, activities, etc. ( t h e tool in question is nominated SADT) a n d (b) t h e socio-economic/natural phenomena considered in i t s ambit ( t h e tools in question a r e nominated process topography a n d process documentation language). Also, that their u s e (and t h e i n h e r e n t Note that the EDSS will be implemented in an environment with a principal mandate in classical EDP fields ; budget and salaries accounting for the public sector, organization and storage of census data, organization of library systems, etc.

(27)

characteristics of t h e tools themselves) is the main EDSS m e r s con- straint. However, in t h e context discussed, we use t h e t e r m "constraint"

more in the sense of "system discipline" t h a n in a constricted or repres- sive connotation. Further, i t is fundamental t o understand t h a t they are, a t t h e s a m e time, a constraint, a system discipline and the possibility for (a) building frameworks such as t h a t discussed and (b) regarded a s a

"language", a means for t h e user to coherently express, analyze and communicate his problems both vertically (i.e. between his management levels a n d with the EDSS framework support staff) and horizontally (i.e.

with related application areas, study disciplines, organizations, etc.).

Without pretending to discuss t h e m a t t e r exhaustively (such a debate is not t h e paper's purpose; however, for those interested, see t h e refer- e n c e d literature sources), we would like to make t h e following points t o clarify t h e above;

a prime purpose of their use is the analytical description and diagnosis of activities, processes, etc., according t o a standard metho- dology. In t h e vertical plane, such a standard is "only" desirable (i.e. between management levels, with t h e EDSS support organization, etc.). But, horizontally (i.e. in t h e context of environmental DSS systems involving many application sectors, study disciplines, organizations. etc.) i t is absolutely necessary. (This would n o t be t h e case for a single application a r e a DSS absent of multi- disciplinary/multi-organizational characteristics.)

Pragmatically, such a standard methodology is t h e basis for building certain essential components of a regional scale environmental EDSS (e.g. process data bases, process model data base, process

(28)

information system, etc., as discussed in detail data), not to men- tion organizational, didactical and dissemination tasks (i.e. division of labour, clarity of communication, project control, etc.).

2. a p r i m e p u 7 p o s e of any DSS .is t o a d d r e s s problems characterized by structured a n d n o n - s t r u c t u r e d e l e m e n t s . By implication (this subject m a t t e r is discussed in detail later), t h e r e a r e many problem areas, activities, tasks, etc., to be examined that, a t first sight, appear to be totally "fuzzy". The use of structural graphical techniques is a m e a n s to identify what elements of the "fog" a r e in fact, or can be, structured, (i.e. they a r e a means for, where possible, moving t h a t which was initially perceived as u n s t r u c t u r e d towards a structural state. This being valuable even if t h e resulting "struc- t u r e d state" simply evidences t h a t it contains many semi and/or unstructured components indeed in t h e context of DSS, this would be the typical result.

3. At last initially, t h e u s e o f such t e c h n i q u e s will not be t h e decision maker (DM) a s such, but t h e DSS c o n s u l t a n t t o whom the DM expresses his problem. In this context, t h e techniques represent an interactive tool between (a) the DM a n d t h e DSS consultant and (b) between the consultant and his support staff (also note that we have already mentioned their use as t h e basis to link the EDSS with the analysis and design techniques of the EDP area).

4. In summary, the prime responsibility for the integrity, maintenance, cataloguing a n d use of s u c h tools will, necessarily be collo- cated within t h e s a p p o r t o r g a n i z a t i o n building the EDSS framework (e.g. in the case discussed, the CSI). Here, we reiterate t h e need for

(29)

s t a n d a r d methodologies. That is, t h e support organization cannot satisfactorily perform its supportive a n d "pooling" role without a c o h e r e n t methodological strategy. We u s e t h e t e r m "pooling" t o emphasize t h e fact t h a t an EDSS such a s t h a t proposed (and t h e methodologies discussed) h a s little sense if t h e support organization is n o t acting as a n "aggregation point" for many decision makers, application types, information types and sources, etc.

2.3. Levels of the Tools of the

EDSS

There a r e two main guiding principles concerning t h e tools of t h e proposed EDSS:

(a) to use diagnostic/descriptive techniques (and t h e resulting documentation) a s t h e first step towards solution design, prior t o any implementation;

(b) to provide logical consistency (equivalence) between specific methodological tools, by amlying the concept of process i n representing t h e decision making cycle, t h e activities to be performed in it, a n d t h e socio-economic a n d n a t u r a l processes of relevance t o a particular t a s k

Regarding (a), t h e first analytical activity t o be pursued in a partic- u l a r t a s k will be t o develop a m a p (or as we will call i t l a t e r on, an activi- gram or a topography) of t h e task, activity or process, which is & s c r i p tive, not prescriptive in nature.

For this we propose t h e use of a s t r u c t u r a l analysis a n d design technique (SADT) (and t h e resulting "activigrams") for t h e representation of

(30)

t h e users' viewpoint of a particular decision. That is, (a) t h e phases of a decision making cycle, t h e management levels involved and t h e task st7-ucture (i.e. s t r u c t u r e d versus unstructured elements of a task), and (b) t h e representation of the activities and t h e tools required t o support t h e user's view of the decision making process, i.e., t h e EDSS b u i l d e r ( c o o r d i n a t o r ) v i e w p o i n t .

This approach finds an equivalence in t h e representational techniques proposed for t h e (a) definition and (b) description of socio- economic/natural phenomena or processes t h e decision process deals with, i.e. (a) t h e process topography and (b) t h e process model diagram.

This equivalence stems from:

(a) t h e correspondence of the analytical approach chosen. That is, the p r i n c i p l e of r e p r e s e n t a t i v e whether we are dealing with (a) t h e decision making cycle as such (is, by way of SADT) or (b) the socio-economic/natural phenomena t o which t h e decision making cycle refers (i.e. by way of a process topography and process model documentation language like t h a t developed a t Canada Statistics, and as discussed in detail later).

(b) t h e application of the c o n c e p t of p-rocess in relation to both t h e decision making cycle as such and t h e socio-economic/natural phenomena to which i t refers (appendix 4 provides a detailed discussion of process information systems).

In a general way a process may be conceived as a system:

(31)

-

separated from i t s environment through a definitional boundary;

-

connected t o t h e s a m e environment by way of input/output flows;

-

which may, or may not have an internal s t r u c t u r e determining (a) the relationship amongst these flows and/or (b) allowing t h e process t o be disaggregated into a number of subprocesses;

-

characterizing transformations of mass, service, energy or information flows i n t o other flows (in t h e case of mass and energy of course subject t o t h e laws of mass/energy conserva- tion). These transformations (or activities in t h e case of a decision making process) a r e controlled by service or information flows o r by properties (characteristics) of input flows going into t h e transformation.

From this general presentation of the concept of process i t becomes apparent t h a t we c a n describe both the decision making process and its related activities (e.g. introduction of abatement and control strategies) as well as socio-economic process (e.g. the operation of a power plant) and natural processes (e.g. diffusion of air pollutants) based on t h e above outlined concept.

The main differences, which call for two different analyses a n d documentation techniques are t h a t :

(a) the decision making process is defined as a semi-structured one consisting of a combination of s t r u c t u r e d a n d unstructured flows, whereas socio-economic or natural processes a r e con-

(32)

sidered as entirely structured (i-e. having only observable inpu t/output flows), and

(b) the decision making process is considered only descriptively.

This means that t h e decision maker determines or controls the transformations or activities in i t (e.g. through unstructured input or control flows) whereas the socio-economic/natural processes a r e considered both descriptively and e z p l i c a t i v e l y , in t h a t a formal mathematical model is established to explain how input/output flows relate to each o t h e r (i.e. in the form of a process model dealing only with s t r u c t u r e d observable flows).

In Figure 2 we give an overview of t h e relationship of the various tools of the EDSS (discussed in more detail in Chapters 3 and 4) to the various phases of t h e decision making cycle and t h e activities pursued in it.

As a summary, the EDSS physically consists of a s e t of formalized procedures (or methodologies) to analyze, design and to document how a particular user views his problem and is assisted in tackling it by way of EDSS tools. By t h e tools of the EDSS we understand data bases for numer- ical, relational and bibliographic type of information, related interactive data access and analysis tools (software), as well a s "off-the-shelf"

mathematical models (e.g. using t h e linear programming technique and other appropriate mathematical models). These tools are applied in a fZezible w a y to respond to the different task types in the phases of a decision making process a s well as to the user requirements for choice, and evaluation methodologies.

(33)

However, the above postulated flezibility has t o be regarded more as a final goal of t h e proposed s y s t e m t h a n i t s initial configuration. As i t will be constructed (models developed and/or implemented, data col- lected, etc.,) on t h e basis of specific environmental "pilot" c a s e studies (district heating system, air pollution, etc.). This implies t h a t t h e type of models a n d d a t a available will be oriented towards specific applications (or tasks) within the framework described. However, once developed, i t will be easy t o enlarge a n d e n r i c h i t t o include m o r e a n d m o r e socio- economic a n d o t h e r c r i t e r i a t o respond t o t h e dynamics of particular problem areas.

Let u s p u t a final emphasis on t h e documentation tools. They a r e n o t solely techniques b u t also form "final products", ( t h e "activigrams"

a n d the process topography a n d t h e process model diagram), t h a t become a n integral p a r t of t h e EDSS d a t a bases. Thus, "decision rules", elements a n d activities of e a r l i e r decisions a r e documented a n d available t o t h e EDSS u s e r (i.e. t h e decision maker) and t h e EDSS builder. The same applies t o t h e EDSS's process information system; earlier developed process descriptions a n d models may t h u s be u s e d again within a completely different decision situation. Thus, a n o t h e r important

"intrinsic" feature of t h e proposed EDSS is t h a t i t g e t s e n r i c h e d more and more, t h e more a n d more i t is used.

(34)

n Q) s

C m a

a' :'=

a m a

U C Y

o a a

P d W

-i ⁱⁱ-m-

w C W C

82

:.':

.d c 3 w E 0

e o o m a e r-4

0 P a

* e u w c

O Q ) P

.d I a u o e e

P I - r l 8 0

M * u 0 e 4 0.:

u m e

w *

0 Q)

-

m . 4 ^{- m}

m d d > h

c u 4 . d U m * > Y . Z m o w 0

C d p o

P m c u -

Y .rl

e A ;

:.:

8 0 a >

m c -

0 m u *

L I c a a c

a.*q C * m

E m l z 2 4

Figure 2. An overview of t h e tools of t h e EDSS and how t h e y r e l a t e t o t h e phases a n d activities of t h e decision making process

(35)

."

N pharer of decision activities purrued and development cycle uting procerr deri~n: feedback

uoer viewpoint first comparison, scenario genera- tion. formulation of requests to EDSS; access to data, procere data and models

I

EDSS builder viewpoint develop process descrip- tions, implementation in PDB

I 1

provide accesn linkage 4 to programer for implementation of models

I

proto type implementation of particular EDSS con- + figuration: documentation:derigner and proRramner view- points implementation (program-

1 ,

mer) improve implementation

'

linkage to formal EDP documents tion feedback feedback

EDSS toolr characterirtics name documentation topography 1 anguage process model diagram sof tware DBUS data bases RDB. PDB documentation SADT language sof tware "of E- the-she1 f" sof tware data bases RDB. PDB documen tat ion SADT language (9 functional analysis in e.g. DAFNE)

(36)

pharer of decirion activitioe purrrud urd devolopmont cycle EDSS toolr making procome viewpoint EDSS builder viovpoint charactorir ticr I implementation:

+

choore course of action, ure sys tem, enter analyze and record -criteria (rtruc- user behavior. tured L unrtruc- consult on formal tured)

I

choice me thode; user friendly roftvare development

-

decieion I formulation of EDSS provide linkage requirementr to to programer

-

rupport control of implementation

I 1 I - 1

control implementation, use rys tom I

fee

I

evaluate decirion

1

final evaluation of and itr implemonta- ryrtem; enter activi- tion gramr into data base

I

(i.0. record. of decirion rule.) I

ack aoftware library SASS BUDB, UINOS... + roftware interactive rof tware document. tion SAm language quer tionnairer intervievr, diary of event#

(37)

3. DOCWWXTATION LANGUAGE FDR THE DECISION MAKING

PROCESS AND

EDSS OPERATION

The proposed documentation language is based on a s t r u c t u r a l analysis a n d design technique (SADT), originally developed for functional analysis and system design. Some m o d i f i c a t i o n s in order t o respond to t h e specific requirements within a DSS h a v e b e e n i n t r o d u c e d (these a r e described in appendix A3-1). We can s u m m a r i z e t h e basic concepts underlying this documentation language a s follows:

1. A particular problem (task o r decision making process) is described b y building a m o d e l or a representation of t h e problem. The model is d e s c r i p t i v e (as opposed t o prescriptive) i n nature as i t is based on t h e decision makers' perception (model) of t h e particular problem. In order to achieve full documentation, the decision makers' model of w h a t t h e problem is, is supplemented by a second viewpoint of how t h e problem is tackled by t h e EDSS (i.e. t h e EDSS designersl/builders' viewpoint, ultimately also from t h e programmers' viewpoint) (see also point 3). The model i s comprehensive in t h a t i t includes t h e different viewpoints of a particular problem a n d i n t h a t the boundary of t h e problem a r e a is exactly described. 9 2. The descriptwn and analysis ^ist o p - d o w n , modulur, hierarchical

a n d s t r u c t u r e d . A particular decision i s disaggregated into its various phases (intelligence, design, choice, etc.), which a r e then f u r t h e r broken down into t h e tasks involved in t h a t phase.

'

Recall here the definition of process as presented in Chapter 2 and as discussed in more detail in Chapter 4.

(38)

Tasks a r e composed of activities (e.g. transformationsg of information flows) which a r e the "modules" for t h e description.

The decision making process, its phases (and t h e activities performed in them) is described in a hierarchical decomposition (see Figure 3). Finally t h e description i s called " s t r u c t u r e d in t h a t the connections between the various activities (see point 5) a r e complete, including t h e description of s t r u c t u r e d a n d unstructured data flowsg into (or controlg criteria on) the activities performed in a particular task.

In SADT we differentiate between the creation of first a d e s c r i p - t i v e m o d e l of the decision making process (i.e. t h e user's viewpoint) followed by a f u n c t i o n a l m o d e l of what functions the EDSS must perform (i.e. t h e EDSS builder's viewpoint) respond- ing to the descriptive model and finally a d e s i g n m o d e l of how the system will be implemented t o perform these functions. The design model may be part of t h e SADT functional model, (when based on the EDSS builder's viewpoint), or form an independent SADT model (i.e. the programmer's, or "toolsmith's" viewpoint.

4. The SADT models describe both t h i n g s (objects, documents, data) and h a p p e n i n g s (activities) a n d how they a r e related. In analogy to t h e definition of process in Chapter 2 and t h e doeu- mentation language for the process data base (see Chapter 4).

we s t a t e t h a t t h e SADT models describe activities (to be performed by men, software, computers, etc.) which have input Recall here the definition of process as presented in Chapter 2 and as discussed in more detail in Chapter 4.

(39)

a n d output flows (data, etc.). Activities transform flows and a r e controlled by additional s t r u c t u r e d or u n s t r u c t u r e d control flows (choice criteria, constraints, d a t a standards, etc.).

5. The SADT documentation language is a d i a g r a m m i n g t e c h n i q u e u s i n g c e r t a i n p r e d e f i n e d g r a p h i c r e p r e s e n t a t i o n s y m b o l s (see f i g u r e 4 10 ) t o show component parts, t h e interrelationships between t h e m and how they f i t into a hierarchic s t r u c t u r e (see f i g u r e 3). The documentation is complete in t h a t if i n c l u d e s both s t r u c t u r e d a n d u n s t r u c t u r e d i n p u t / o u t p u t o r c o n h o l f l o w s a n d t h e w p r o p e r r e l a t i o n s h i p s to t h e components of the

diagram (i.e. t h e activities pursued in a particular task).

It should b; noted t h a t t h e s e SADT d i a g r a m p o u i d e e q u a l l y Linkage t o o t h e r f o r m a l EDP d o c u m e n t a t i o n t o o l s ( e . g . DAFNE or t h e like). Once a particular decision making cycle is completed a n d t h e EDSS task gets transformed to a formal MIS system (documented and redesigned using classical EDP analysis and documentation methodologies) t h e SADT diagrams or "activigrams" (user, EDSS builder and equally programmer viewpoints) form p a r t of t h e functional analysis of a particular MIS system. At t h e e n d of Chapter 4 we will give a n overview of t h e conceptual and/or physical (tool) equivalance between (a) the documentation language

SADT

used for description of t h e EDSS operation, of (b) the documentation language used within the EDSS process data base and (c) classical EDP analysis a n d design techniques.

l o Note the modifications and additions t o the original SADT graphic conventions introduced in order to respond t o the specific documentation requirements of the EDSS.

(40)

Ultimately, t h e SADT diagrams will f o r m a special d a t a base1' (being equally part of t h e EDSS) documenting the decision d e s , task s t r u c t u r e , etc. of decisions in earlier addressed problem areas. This will enable t h e user (as well as the DSS builder) t o access and analyze earlier generated solutions in similar problem areas, forming t h u s a learning tool t o improve the effectiveness and performance of t h e decision m a k e r and t h e EDSS.

1

Degree of Detail

Parent a d Child Boxes

Figure 3.

SADT

s t r u c t u r e d decomposition

l 1 We note however, that this type of data base will be developed at a later step of the EDSS implementation, once a number of EDSS applications to u f e r e n t classes of environmental problems have been completed.

(41)

In order to illustrate b e t t e r t h e potential applications of a documentation language like SADT for case studies using t h e proposed EDSS, Kg- ures 5 t o ? p r e s e n t examples of case s t u d y documentations on t h e basis of a past IIASA study. aiming to develop a tool t o a s s i s t decision makers in a n indepth analysis of t h e consequences and i m p a c t s of t h e application of centralized versus decentralized solar e l e c t r i c systems a t t h e regional level. The complete s e t of SADT diagrams illustrating t h e EDSS builder's viewpoint of such a study is presented in Appendix 3, along with a brief introduction t o t h e problem a r e a and t h e c a s e study application performed a t IIASA Examples for process descripions according t o t h e proposed EDSS process data base conventions a r e presented in Appendix 4.

R g u r e 4. Proposed SADT graphical conventions

,

UM"ntur* = k t Farnalizable or not Observable

<

Output Flows

(

U-uaured Contrpl Flow

---

1e.g. W i l l i y n m to

Cooperate, Estetia) lnput

Aclivity Flows

entr_ol Flow 1e.g. Constraint)

C

w

-\

System 0oundary

LEVEL : C1 V I E W O I N T : USER

Unstructured Input Flow

-.--- +

(c-0. Design ^Activifyl or Choice)

Control Flow

t

1e.g. L+Sterds.

6 o i o Criteria)

(42)

For t h e purposes of our discussion of a documentation tool like SADT for the representation of decision making cycles, we would like t o draw particular attention t o t h e r e p r e s e n t a t i o n of u n s t r u c t u r e d ( c o n t r o l ) f l o w s going into t h e activities involved in a decision. The case study illustrates t h a t in t h e objective t o achieve higher regional energy self- sufficiency, t h e r e a r e a larger number of unstructured inputs to be considered, resulting in specific requirements (options) on the EDSS sys- t e m s configuration.

Questions like t h e reduction of political dependence from energy imports, creation of local jobs through decentralized energy systems, reduction of environmental pollution through development of renewable local energy resources are additional inputs to t h e structured (technical) elements of t h e task (system configuration, energy production having t o m e e t t h e quantitative and qualitative (energy services) require- m e n t s of t h e consumers, systems optimization, etc.). Thus, for instance, t h e u s e r has t o have t h e possibility t o design a n d t o assess the impacts of such a regional energy system, with a variety of EDSS options (including maximization of energy autonomy, systems cost optimization, sensitivity analysis, choosing alternative models describing1' the conversion technologies, etc.).

iZ Note that this is especially important in considering technologies not yet introduced on a large commercial scale.