Systemplanung. Planung und Realisierung von Informatik-Projekten: Band 1: Der Prozeß der Systemplanung, der Vorstudie und der Feinstudie [7., korrigierte Auflage. Reprint 2018] 9783486791723, 9783486239256

Citation preview

Wirtschaftsinformatik

Systemplanung Planung und Realisierung von Informatik-Projekten Band 1

Der Prozeß der Systemplanung, der Vorstudie und der Feinstudie

Von

Dr. Lutz J. Heinrich o. Professor für Betriebswirtschaftslehre und Wirtschaftsinformatik an der Universität Linz

7., korrigierte Auflage

R. Oldenbourg Verlag München Wien

Die Deutsche Bibliothek - CFP-Einheitsaufnahme Systemplanung : Planung und Realisierung von InformatikProjekten/ von Lutz J. Heinrich. - München ; Wien : Oldenbourg. (Wirtschaftsinformatik) NE: Heinrich, Lutz J.: Burgholzer, Peter Bd. 1. Der Prozeß der Systemplanung, der Vorstufe und der Feinstufe. - 7., korrigierte Aufl. - 1996 ISBN 3-486-23925-2

© 1996 R. Oldenbourg Verlag GmbH, München Das Werk einschließlich aller Abbildungen ist urheberrechtlich geschützt. Jede Verwertung außerhalb der Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Bearbeitung in elektronischen Systemen. Gesamtherstellung: R. Oldenbourg Graphische Betriebe GmbH, München ISBN 3 - 4 8 6 - 2 3 9 2 5 - 2

Vorwort zur siebten Auflage Seit Erscheinen der sechsten Auflage im Herbst 1994 haben sich keine wesentlichen Änderungen ergeben, sodaß sich der Autor auf die Fehlerkorrektur sowie auf die Aktualisierung einiger Literaturquellen beschränken konnte. L. J. H.

Aus dem Vorwort zur sechsten Auflage "Systemplanung" wird weiterhin als bündige Kurzfassung für eine Reihe von möglichen Bezeichnungen für einen umfangreichen Lehrstoff verwendet, die alle den Nachteil haben, nicht sehr stabil zu sein. So hat dieses Lehrbuch bereits mehrere Untertitel geführt, und ab dieser Auflage wird als Untertitel "Planung und Realisierung von Informatik-Projekten" verwendet. Damit folgt der Autor der vorherrschenden Sprachregelung in den geltenden "Studienplan-Empfehlungen Wirtschaftsinformatik" in Deutschland und in Österreich, die ein Fach mit dieser Bezeichnung vorsehen und damit die sprachlich falsche Bezeichnung "Systemanalyse" endlich verschwinden lassen. Beide Wortbestandteile sind so umfassend, daß "Systemplanung" fast zeitlos ist. Dabei mögen die Systeme als "Informationssysteme", "Informations- und Kommunikationssysteme" und "Informations- und Steuerungssysteme" oder Subsysteme davon - wie "BüroInformationssysteme", "Personal-Informationssysteme" oder "Umwelt-Informationssysteme" oder Teile davon (wie z.B. "Anwendungssysteme") - bezeichnet werden, und unter Planung mag nur der Prozeß des "Vordenkens" oder alle Maßnahmen, Methoden, Techniken und Werkzeuge verstanden werden, die mit dem Erkennen des Bedarfs für ein neues oder grundlegend verändertes System bis zu seiner produktiven Verwendung im Zusammenhang stehen - "Systemplanung" umschließt alle diese Facetten. Systemplanung ist ein kooperativer und kreativer Arbeitsprozeß. Aus der Sicht der klassischen Sozial- und Wirtschaftswissenschaften wird dieser Prozeß primär als ein Verhandlungsprozeß zwischen den beteiligten Systemplanern und Benutzern angesehen und untersucht, der sich auch ingenieurwissenschaftlicher Methoden bedient. Aus ingenieurwissenschaftlicher Sicht steht der Einsatz von Methoden, Techniken und Werkzeugen im Vordergrund; das Verhalten der Personen und Gruppen, die diesen Prozeß vorantreiben, rückt dagegen in den Hintergrund. Es kann als ein wesentliches Merkmal der Wirtschaftsinformatik als einer modernen sozial- und wirtschaftswissenschaftlichen, mit ingenieurwissenschaftlichem Denken durchsetzten Disziplin angesehen werden, daß sie beide genannten Sichtweisen zusammenfaßt und integriert. Es ist eines der Anliegen der sechsten Auflage von "Systemplanung", dieser Tatsache besser als in den vorangegangenen Auflagen Rechnung zu tragen. Systemplanung ist nicht identisch mit Software-Entwicklung oder Software Engineering, sondern wesentlich umfassender. Da Software Engineering in einschlägigen Lehrbüchern abgehandelt wird und meist Gegenstand besonderer

2

Vorwort

Lehrveranstaltungen ist, wird in diesem Buch nicht vertieft darauf eingegangen. "In letzter Zeit setzt sich die Erkenntnis durch, daß vor dem Entwurf einer Anwendung die betrieblichen (gegenwärtigen und zukünftigen) Informationsflüsse des Unternehmens zu analysieren sind", ist in einem 1992 erschienenen Lehrbuch "Modelle der Software-Entwicklung" zu lesen. Diese Aussage weist auf die heute vorherrschende, auf die Erstellung eines Software-Objekts abgegrenzte Sichtweise des Software Engineering hin. Für die Systemplanung hat diese enge Sichtweise nie gegolten. So ergänzen sich also Systemplanung einerseits und Software-Entwicklung bzw. Software Engineering andererseits. Seit der ersten Auflage dieses Buches wurde die Bezeichnung "Methoden und Werkzeuge" verwendet. Sie war anfangs in einem sehr allgemeinen Sinn gemeint und sollte alles umfassen, was geeignet war, die Aufgaben der Systemplanung zu unterstützen. Heute wird mit "Werkzeug" eine sehr präzise Vorstellung verbunden. Gemeint sind Software-Produkte, insbesondere solche, welche die Aufgaben der Software-Entwicklung unterstützen. Methoden und Techniken werden als systematisierte Vorgehensweisen und Verfahren zum Entwerfen, Analysieren, Entwickeln, Beschreiben usw. aufgefaßt, die in Werkzeugen implementiert sind oder ohne Werkzeugunterstützung verwendet werden. Da dieses Lehrbuch kein Produktbuch sein soll, kann auf Werkzeuge nicht im einzelnen eingegangen, sondern nur in Einzelfällen auf bestimmte Werkzeuge exemplarisch verwiesen werden. Unabhängig davon wird in der Lerneinheit WERSP die Werkzeugunterstützung der Systemplanung zusammenfassend dargestellt. Im einzelnen behandelt werden nicht Werkzeuge, sondern Methoden und Techniken, die in Werkzeugen implementiert sein können. Der objektorientierte Ansatz der Systemplanung, der nicht nur "objektorientierte Programmierung" meint, hat seit Erscheinen der fünften Auflage stark an Bedeutung gewonnen. Über eine kurze Beschreibung im Zusammenhang mit der Methodik der Systemplanung (Lerneinheit ZAMSP) hinaus, wird er daher in einer eigenen Lerneinheit (OBOSP - Objektorientierte Systemplanung) behandelt. Neu gegenüber der fünften Auflage ist auch Lerneinheit NETZP - Netzplantechnik, da die bisher nur knappen Hinweise in anderen Lerneinheiten (insbes. in Lerneinheit DARST) ihrer Bedeutung für die Systemplanung nicht gerecht werden konnten. Alle Lerneinheiten wurden überarbeitet und - wo notwendig und vom Umfang her möglich - ergänzt. Aus lernpsychologischer Sicht ist es empfehlenswert, die verwendeten Kernbegriffe für einen Lerntext jeweils vor einer Lerneinheit anzuordnen. Dadurch können sich die Lernenden soweit mit ihnen vertraut machen, daß sie die spezifische Fachsprache der Lerneinheit kennen, bevor sie sich mit dem Lernstoff selbst auseinandersetzen. Der seit der zweiten Auflage dieses Lehrbuchs jeder Lerneinheit (nach der Angabe der Lernziele) vorangestellte Abschnitt "Definitionen und Abkürzungen" wurde daher weiter ausgebaut. Dieses Vorgehen hat auch den Vorteil, den Sachinhalt der Lerneinheit von definitorischen Ausführungen, die manches Lehrbuch füllen und fast "unlernbar" machen, fast völlig zu befreien. Was also in jeder Lerneinheit nach dem Abschnitt "Definitionen und Abkürzungen" wiedergegeben wird, ist "Inhalt zur Lerneinheit" und nicht Erklärung von Fachsprache.

3

Vorwort

K. Kurbel hat in e i n e r v e r g l e i c h e n d e n B u c h b e s p r e c h u n g in der Z e i t s c h r i f t WIRTSCHAFTSINFORMATIK diesem L e h r b u c h w e i t g e h e n d e inhaltliche Vollständ i g k e i t b e s c h e i n i g t ; w a s als fehlend a n g e m e r k t wird, wird im w e s e n t l i c h e n im B a n d " I n f o r m a t i o n s m a n a g e m e n t " behandelt. Die didaktische A u f b e r e i t u n g (Lernziele, D e f i n i t i o n e n , K o n t r o l l f r a g e n , Q u e l l e n - und Vertiefungsliteratur) wird als g u t e E i g e n s c h a f t h e r v o r g e h o b e n . Z u r e c h t kritisiert w i r d die d r u c k t e c h n i s c h e A u f m a c h u n g ; sie ist mit der vorliegenden A u f l a g e drastisch verbessert w o r d e n . W i e a u s d i e s e m V o r w o r t h e r v o r g e h t , v e r w e n d e t der A u t o r das h e r k ö m m l i c h e M a s k u l i n u m u n d verzichtet auf u m s t ä n d l i c h e , n e u d e u t s c h e K o n s t r u k t i o n e n f ü r eine "geschlechtsneutrale F o r m u l i e r u n g " . G a n z u n a b h ä n g i g v o m G e s c h l e c h t sind aber alle, L e s e r i n n e n u n d Leser, v o m A u t o r a u s d r ü c k l i c h a n g e s p r o c h e n . W o m ö g l i c h , w u r d e eine F o r m u l i e r u n g v e r w e n d e t , die auf einen G e s c h l e c h t e r b e z u g ü b e r h a u p t verzichtet. L. J. H.

Aus dem Vorwort zur vierten Auflage S o w o h l in d i e s e m Lehrtext "Systemplanung" als auch im Lehrtext "Informationsm a n a g e m e n t " wird das Projektportfolio als die Schnittstelle zwischen der S y s t e m p l a n u n g u n d d e m strategischen I n f o r m a t i o n s m a n a g e m e n t angesehen. D a m i t stellt sich d i e F r a g e , a u f g r u n d w e l c h e r I n f o r m a t i o n e n d a s P r o j e k t p o r t f o l i o g e b i l d e t wird u n d w i e i n s b e s o n d e r e die im Projektportfolio enthaltenen Projekte g e o r d n e t w e r d e n . Hier wird die T h e s e vertreten, d a ß f ü r die Bildung des P r o j e k t p o r t f o l i o s I n f o r m a t i o n e n e r f o r d e r l i c h sind, die nur durch eine V o r s t u d i e ermittelt w e r d e n k ö n n e n . Daraus folgt, daß zwischen der S y s t e m p l a n u n g und d e m strategischen Inf o r m a t i o n s m a n a g e m e n t e i n e enge Interaktion erforderlich ist. Die V o r s t u d i e erhält d e s h a l b e i n e n w e s e n t l i c h h ö h e r e n S t e l l e n w e r t , als ihr b i s h e r z u g e m e s s e n wurde. V o n d i e s e n Ü b e r l e g u n g e n a u s g e h e n d , h a b e n die A u t o r e n in der v o r l i e g e n d e n v i e r t e n A u f l a g e i n s b e s o n d e r e das Kapitel "Der P r o z e ß der Vorstudie" g r ü n d l i c h überarbeitet. Sie h a b e n d a b e i auch die Absicht verfolgt, die N o t w e n d i g k e i t einer systematischen V o r g e h e n s w e i s e in dieser f r ü h e n P h a s e der S y s t e m p l a n u n g besser zu v e r d e u t l i c h e n . Es wird j a heute allgemein anerkannt, daß gerade in d e n f r ü h e n P h a s e n d e r S y s t e m p l a n u n g die e n t s c h e i d e n d e n W e i c h e n f ü r die e r f o l g r e i c h e D u r c h f ü h r u n g eines P r o j e k t s der P l a n u n g und Realisierung eines I n f o r m a t i o n s und K o m m u n i k a t i o n s s y s t e m s gestellt w e r d e n , und d a ß die Beseitigung v o n nicht e r k a n n t e n M ä n g e l n der S y s t e m p l a n u n g u m s o schwieriger und a u f w e n d i g e r ist, j e f r ü h e r diese M ä n g e l im P r o z e ß der S y s t e m p l a n u n g auftreten und j e später sie erkannt werden.

Aus dem Vorwort zur zweiten Auflage D e r v o r l i e g e n d e T e x t ist S e m i n a r e n mit Praktikern planung" waren zunächst lehre gedacht, w e l c h e die

aus d e m B e g l e i t m a t e r i a l v o n V o r l e s u n g e n s o w i e v o n entstanden. Die V o r l e s u n g e n unter d e m Titel "Systemausschließlich f ü r S t u d e n t e n der B e t r i e b s w i r t s c h a f t s B e s o n d e r e Betriebswirtschaftslehre B e t r i e b s i n f o r m a t i k

4

Vorwort

studieren. Später erweiterte sich der Hörerkreis insbesondere auf Studenten des Studienversuchs Betriebs- und Verwaltungsinformatik bzw. seit 1985 auf Studenten des Studiums Wirtschaftsinformatik. Darüber hinaus zählen heute Studenten verschiedener anderer Studiengänge (so z.B. des Wirtschaftsingenieurwesens) zu den Hörern der Vorlesungen "Systemplanung". Die Vorbereitung und Durchführung zahlreicher Seminare mit Praktikern als Teilnehmer ... führten die beiden Autoren zusammen. Dabei war es ihr Ziel, Lehrunterlagen zur Verfügung zu stellen, welche die Theorie und die Praxis der Planung von Informations- und Kommunikationssystemen so zusammenfassen, daß die Studenten auf ihre spätere berufliche Tätigkeit vorbereitet werden, daß aber auch den Praktikern eine Ergänzung ihres im Berufsleben erworbenen Wissens angeboten werden konnte. Das Ergebnis dieser Absichten ist eine Unterlage, welche inhaltlich weder als eine wissenschaftliche Veröffentlichung, noch als ein Rezeptbuch für die Praxis zu bezeichnen ist. Vielmehr stellt sie nach Auffassung der Autoren eine gesunde Mischung aus beidem dar. Formell steht der Charakter eines Lehrbuchs deutlich im Vordergrund. Deshalb haben die Autoren besonderen Wert darauf gelegt, den Stoff gut zu strukturieren und auch optisch faßbar aufzubereiten. Die getrennte Behandlung der Planungsaufgaben auf der einen Seite und der Planungsmethoden und Planungswerkzeuge auf der anderen Seite hat sich in der Lehre als zweckmäßig erwiesen. Man kann so den Planungsprozeß für Informations- und Kommunikationssysteme relativ geschlossen darstellen und die Methoden und Werkzeuge besser ordnen. Man sieht so unter anderem deutlich, daß zur Durchführung einzelner Planungsaufgaben (noch) keine, für andere mehrere alternative Methoden und Werkzeuge zur Verfügung stehen. Man begreift dadurch die Notwendigkeit sowohl der Methoden- und Werkzeugentwicklung bzw. -anpassung als auch der Bewertung und Auswahl von Methoden und Werkzeugen. Dabei wird der Methoden- und Werkzeugbegriff weit ausgelegt und umfaßt auch Prinzipien, Grundsätze und Vorgehensweisen.

Inhaltsverzeichnis Alphabetisches Verzeichnis der Lerneinheiten

7

Grundlagen

9

EINSP ZAMSP SYSTE PROSP OBOSP PROTY WERSP AUTER

-

der

Systemplanung

Einführung in die Systemplanung Ziel, Aufgaben und Methodik der Systemplanung Systemtechnik und Systemplanung Prozeß der Systemplanung Objektorientierte Systemplanung Prototyporientierte Systemplanung Werkzeugunterstützung der Systemplanung Aufgabenträger der Systemplanung

Methoden und Techniken der Systemplanung ENTAB HIPO SADT DAFLU PENET MATRX WERTA WIRTA NUTZW SIMUL PRAET DARST NETZP TESTM DOKUM

-

Entscheidungstabellen-Technik Hierarchy plus Input-Process-Output Structured Analysis and Design Technique Datenflußdiagramme Petri-Netze Matrixanalyse Wertanalyse Wirtschaftlichkeitsanalyse Nutzwertanalyse Simulation Präsentationstechniken Darstellungstechniken Netzplantechnik Testmethoden Dokumentationsmethoden

11 21 32 39 47 57 68 80 89 91 99 107 116 127 138 144 152 162 174 185 192 205 215 227

Der Prozeß der Vorstudie

239

Aufgaben der Vorstudie

241

ZAMVS SACHZ FORMZ GRUND PROPL

241 248 257 268 275

-

Ziel, Aufgaben und Methodik der Vorstudie Festlegen der Sachziele Festlegen der Formalziele Entwerfen der Grundkonzeption Durchführen der Projektplanung

6

Inhaltsverzeichnis

Methoden und Techniken der Vorstudie

283

ANFOA TECHA KREAT KONSA PROME

283 296 305 314 322

-

Anforderungsanalyse Technikanalyse Kreativitätstechniken Konsequenzanalyse Methoden des Projektmanagements

Der Prozeß der Feinstudie

329

Aufgaben der Feinstudie

331

ZAMFS ERIST ANIST AFEIN

331 338 345 354

-

Ziel, Aufgaben und Methodik der Feinstudie Erfassen des Istzustands Analysieren des Istzustands Auswerten der Feinstudie

Methoden und Techniken der Feinstudie

359

VFEIN ISTER ZERFA ISTAN KOMAN

359 366 374 380 387

-

Vorgehensweise bei der Feinstudie Methoden der Istzustandserfassung Methoden der Zeiterfassung Methoden der Istzustandsanalyse Methoden der Kommunikationsanalyse

Literaturverzeichnis

395

Schlagwortverzeichnis

402

Alphabetisches Verzeichnis der Lerneinheiten Das Verzeichnis bezieht sich auf die 6. Auflage von Band 1 und die 4. Auflage von Band 2.

AFEIN ANFOA ANIST AUSAN AUTER

-

BTECH

Auswerten der Feinstudie Anforderungsanalyse Analysieren des Istzustands Durchführen der Ausschreibung Aufgabenträger der Systemplanung

-

354 283 345 101 80

- Bestimmen des Technikbedarfs

2 -

84

DAFLU DAKON DAMOD DARST DOKUM DURIN

-

Datenflußdiagramme Methoden der Datenkonvertierung Datenmodellierung Darstellungstechniken Dokumentationsmethoden Durchführen der Installierung

1 2 2 1 1 2

-

116 345 119 192 227 338

EAORG EDASY EINSP EINTE EMESY ENTAB ERIST ESICH ETRAN

-

Entwickeln der Arbeitsorganisation Entwickeln des Datensystems Einführung in die Systemplanung Integration der Systementwicklung Entwickeln des Methodensystems Entscheidungstabellen-Technik Erfassen des Istzustands Entwickeln des Sicherungssystems Entwickeln des Transportsystems

2 2 1 2 2 1 1 2 2

-

202 184 11 234 192 91 338 225 215

FORMZ

- Festlegen der Formalziele

1 - 257

GRUND

- Entwerfen der Grundkonzeption

1 - 268

HIPO

- Hierarchy plus Input-Process-Output

1 -

ISTER ISTAN

- Methoden der Istzustandserfassung - Methoden der Istzustandsanalyse

1 - 366 1 - 380

KOMAN KONSA KREAT KRYPT

-

1 1 1 2-

MATRX

- Matrixanalyse

Methoden der Kommunikationsanalyse Konsequenzanalyse Kreativitätstechniken Kryptographische Verschlüsselungssysteme

1 1 1 2 1

99

387 314 305 310

1 - 138

NETZP - Netzplantechnik NUMSY - Nummernsysteme NUTZW - Nutzwertanalyse

1-205 2 - 128 1 - 162

OBOSP

- Objektorientierte Systemplanung

1 -

PAORG

- Prinzipien der Arbeitsorganisation

2 - 139

47

8

Alphabetisches Verzeichnis der Lerneinheiten

PAPER PENET PFLIC PINTE PKOER PRADA PRAET PROME PROPL PROSP PROTY PSOFT

-

SACHZ SADT SIMUL SMEBA SPLAN SPROM

-

-

293 127 93 148 302 351 185 322 275 39 57 245

1 1 1 22-

248 107 174 272 282

SYSTE

Festlegen der Sachziele Structured Analysis and Design Technique Simulation Software-Entwicklung mit Methodenbanken Software-Entwicklung mit Planungssprachen Software-Entwicklung mit höheren Programmiersprachen - Software-Entwicklung mit Sprachen der vierten Generation - Systemtechnik und Systemplanung

TECHA TESTM

- Technikanalyse - Testmethoden

1 - 296 1 - 215

VFEIN VGROB VINST VORIN

-

Vorgehensweise bei der Feinstudie Vorgehensweise bei der Grobprojektierung Vorgehensweise bei der Installierung Vorbereiten der Installierung

1 - 359 2 - 12 2 - 325 2 - 331

WAORG WDASY WERSP WERTA WINTE WIRTA WMESY WTRAN WSICH

-

Entwerfen der Arbeitsorganisation Entwerfen des Datensystems Werkzeugunterstützung der Systemplanung Wertanalyse Integration der Systementwürfe Wirtschaftlichkeitsanalyse Entwerfen des Methodensystems Entwerfen des Transportsystems Entwerfen des Sicherungssystems

2 2 1 1 2 1 2 2 2

ZAMFP ZAMFS ZAMGP ZAMIN ZAMSP ZAMVS ZERFA

-

Ziel, Aufgaben und Methodik der Feinprojektierung Ziel, Aufgaben und Methodik der Feinstudie Ziel, Aufgaben und Methodik der Grobprojektierung Ziel, Aufgaben und Methodik der Installierung Ziel, Aufgaben und Methodik der Systemplanung Ziel, Aufgaben und Methodik der Vorstudie Methoden der Zeiterfassung

2 1 2 21 1 1 -

SVIER

Prinzipien der Arbeitsplatzergonomie Petri-Netze Erstellen des Pflichtenhefts Integrationsprinzipien Prinzipien der Kommunikationsergonomie Methoden der Programmadaption Präsentationstechniken Methoden des Projektmanagements Durchführen der Projektplanung Prozeß der Systemplanung Prototyporientierte Systemplanung Prinzipien der Software-Entwicklung

2 1 2 2 2 2 1 1 1 1 1 2

2 - 255 2 - 263 1 - 32

- 44 - 22 - 68 - 144 - 76 - 152 - 32 - 55 - 67 179 331 7 319 21 241 374

Grundlagen der Systemplanung

10

Grundlagen der

Systemplanung

In diesem Kapitel werden die Grundlagen der Systemplanung behandelt. Damit ist das Wissen gemeint, das bekannt sein oder erarbeitet werden sollte, bevor mit dem Studium von Einzelheiten zu den Methoden und Techniken sowie zu den Phasen der Systemplanung begonnen wird. Nach der Einführung, die ein erstes Verständnis darüber vermittelt, worum es bei der Systemplanung überhaupt geht, werden ihre charakteristischen Merkmale behandelt. Beispiele dafür sind ihr Ziel, ihre Aufgaben und ihre Methodik, ihre Verwandtschaft zur Systemtechnik und ihr Prozeßcharakter. Das Verstehen der Systemplanung als einen kooperativen und kreativen Arbeitsprozeß ist ein wichtiges Anliegen dieses Kapitels. Ebenso wichtig ist jedoch, Systemplanung als ingenieurwissenschaftlich orientierten Entwicklungsprozeß zu verstehen. Dem dienen Erläuterungen zur Objektorientierung, zur Prototyporientierung und zur Werkzeugunterstützung.

Grundlagen der Systemplanung EINSP ZAMSP SYSTE PROSP OBOSP PROTY WERSP AUTER

-

Einführung in die Systemplanung Ziel, Aufgaben und Methodik der Systemplanung Systemtechnik und Systemplanung Prozeß der Systemplanung Objektorientierte Systemplanung Prototyporientierte Systemplanung Werkzeugunterstützung der Systemplanung Aufgabenträger der Systemplanung

11 21 32 39 47 57 68 80

EINSP - Einführung in die Systemplanung Lernziele Sie können den Lernstoff "Systemplanung" in Wissenschaftsdisziplinen und in Lehrgebiete einordnen. Sie können die grundlegenden Begriffe "System" und "Planung" sowie das daraus gebildete Konstrukt "Systemplanung" mit Bezug auf Informations- und Kommunikationssysteme erläutern. Sie kennen die Eigenschaften, die diese Systeme kennzeichnen. Sie kennen die Struktur, in welcher der Lernstoff in diesem Lehrbuch aufbereitet und dokumentiert wird. Definitionen und Abkürzungen Aufgabe (task) = jede aus dem betrieblichen Leistungsprogramm abgeleitete Teilleistung der Struktureinheiten bzw. der in diesen tätigen Aufgabenträger im Sinn von Aufforderungen, an bestimmten materiellen oder immateriellen Objekten ("Aktionsobjekte") bestimmte körperliche oder geistige Verrichtungen ("Aktionsarten") durchzuführen. Beziehung (relationship) = der innere Zusammenhang und das wechselseitige Verhältnis zweier oder mehrerer Dinge zueinander. Element (element) = ein durch Zerlegung bestimmter Teil eines Systems, der im betrachteten Zusammenhang nicht weiter zerlegt werden kann. Graph (graph) = im Sinn der Graphentheorie eine endliche, nicht leere Menge V von p Knoten mit einer Menge X von q zweielementigen Teilmengen von V. interagieren (interact to) = das sich wechselseitige Beeinflussen des Handelns zwischen den Elementen eines Systems durch Kommunikation. IuK = Abkürzung für Information und Kommunikation. Kante (edge) = die Darstellung einer Beziehung zwischen zwei Elementen in einem Graphen. Knoten (node) = die Darstellung eines Elements in einem Graphen. Komplexität (complexity) = die Eigenschaft eines Systems, die durch die Anzahl seiner Elemente und durch die Anzahl der Beziehungen zwischen den Elementen ("Beziehungsreichtum") gekennzeichnet ist. Kompliziertheit (difficulty) = die Eigenschaft eines Systems, die durch die Anzahl und die Unterschiedlichkeit seiner Elemente gekennzeichnet ist. K o m p o n e n t e (component) = ein durch Zerlegung bestimmter Teil eines Systems. MAT-System = Abkürzung für Mensch/Aufgabe/Technologie-System. Technologie (technology) = die Gesamtheit der Technik und die in der Technik anwendbaren und tatsächlich angewendeten Verfahren. Wissenschaftsdisziplin (scientific discipline) = ein mehr oder weniger in sich abgeschlossenes Gebiet der Wissenschaft, das ein durch Forschung, Lehre und Schrifttum geordnetes, begründetes und als sicher erachtetes Wissen umfaßt. Zerlegung (decomposition) = das methodische Zergliedern eines Systems in Teilsysteme. Synonym: Dekomposition. Zustand (state) = die zu einem bestimmten Zeitpunkt oder in einem bestimmten Zeitraum bestehende Beschaffenheit eines Systems.

12

Grundlagen der

Grundlegende

Systemplanung

Begriffe

Generell wird unter System der ganzheitliche Zusammenhang von Teilen, Einzelheiten, Dingen oder Vorgängen, die voneinander abhängig sind, ineinandergreifen oder zusammenwirken, verstanden. Allgemeiner gesagt besteht ein System aus einer Menge von Elementen, die in bestimmter Weise miteinander in Beziehung stehen (miteinander interagieren). Der Beziehungszusammenhang zwischen diesen Elementen ist deutlich dichter als der zu anderen Elementen, sodaß sich Systeme von ihrem Umsystem abgrenzen lassen. Mit anderen Worten: Ein System ist ein Tripel, bestehend aus einer Menge von Elementen, einer Menge von Verbindungen und einer Zuordnungsvorschrift der Verbindungen auf die Elemente. Systeme dienen in der Regel bestimmten Zwecken, die durch adjektivische Begriffszusätze ausgedrückt werden (z.B. Verkehrssystem, Versorgungssystem, Computersystem, Datensystem, Methodensystem). Die Zusätze Information und Kommunikation sollen verdeutlichen, daß die Zwecke eines "Informations- und Kommunikationssystems" (abgekürzt: IuK-System) Information und Kommunikation sind. • Information ist handlungsbestimmende Kenntnis über historische, gegenwärtige oder zukünftige Zustände der Wirklichkeit oder Vorgänge in der Wirklichkeit. Zweck eines IuK-Systems ist es, dieses Handlungspotential durch die datenmäßige Abbildung der Wirklichkeit und durch Methoden zur Verknüpfung dieser Daten dem Handelnden zur Verfügung zu stellen. • Kommunikation ist der Austausch von Information zwischen den Elementen eines Systems und zwischen offenen Systemen. Zweck eines IuK-Systems ist es, Information zwischen den Elementen des Systems und zwischen dem System und seiner Umwelt auszutauschen. Information und Kommunikation stellen also zwei Aspekte eines Objekts dar: Ohne Information keine Kommunikation und ohne Kommunikation keine Information. Dieser "siamesische Zwillingscharakter" beider macht es notwendig, sie in einem IuK-System miteinander verbunden zu betrachten. Dabei ist es korrekt, von "Informationssystem" zu sprechen, wenn sich das Hauptaugenmerk auf "Information" richtet, und die Bezeichnung "Kommunikationssystem" zu verwenden, wenn sich das Hauptaugenmerk auf "Kommunikation" richtet. Damit wird eine unterschiedliche Sicht auf ein- und dasselbe Objekt benannt. In der Wirtschaftsinformatik hat es sich allerdings weitgehend eingebürgert, die Bezeichnung "Informationssystem" zu verwenden, was damit erklärt werden kann, daß es im betriebswirtschaftlichen Sinn letztlich um Information geht und Kommunikation sozusagen "nur" das Vehikel zur Information ist. Daher werden nachfolgend neben der Langfassung "Informations- und Kommunikationssystem" die Bezeichnungen IuK-System und Informationssystem synonym verwendet. Die in der Wirtschaftsinformatik heute weit verbreitete, aus dem Amerikanischen übernommene Bezeichnung Anwendungssystem (engl.: application system) als Synonym für Informationssystem vermeidet zwar das erwähnte Bezeichnungsproblem, ist aber sprachlich ganz falsch, schwer erklärbar und daher auch mißverständlich. "Application" ist daraus hergeleitet, daß Informations- und Kom-

EINSP - Einführung

in die

Systemplanung

13

munikationstechnologie zur Unterstützung betrieblicher Aufgaben eingesetzt (also: "angewendet") wird; die Technologie-Sicht, die für die Wirtschaftsinformatik von sekundärer Bedeutung ist, steht im Vordergrund. Dagegen wird die spezifische Sicht der Wirtschaftsinformatik auf den Systemzweck, also darauf, die Informationsversorgung für Aufgabenträger zu unterstützen, überhaupt nicht angesprochen. Trotzdem, da es der weitverbreitete Sprachgebrauch so will, wird im folgenden Text auch die Bezeichnung "Anwendungssystem" verwendet, aber nicht bedeutungsgleich mit "Informationssystem", sondern im Sinn von "Teil eines Informationssystems". Informationssysteme sind offene Systeme. "Offen" sind Systeme, deren Elemente (einzelne oder mehrere) mit ihrer Umwelt in Beziehung stehen (mit ihr "interagieren"); Systeme, die das nicht tun, sind "geschlossen". Informationssysteme sind auch dynamische Systeme, weil sich durch die Interaktion ihrer Elemente ihre Eigenschaften verändern ("Zustandsänderung"), mit anderen Worten: Der Zustand Z t d e s Systems ist nicht identisch mit dem Zustand Z t +i. Schließlich sind Informationssysteme komplexe Systeme, das heißt Systeme mit einer großen Anzahl von Elementen und einer großen Anzahl von Beziehungen zwischen den Elementen ("Beziehungsreichtum"). Dieser Lernstoff befaßt sich nicht mit Informationssystemen im allgemeinen, sondern mit Informationssystemen in Wirtschaft und V e r w a l t u n g , also mit Informationssystemen, deren Zweck Information (und Kommunikation) in Betriebswirtschaften ist (daher häufig auch kurz: "betriebliche Informationssysteme" genannt). Schließlich ist auch die Art der Befassung mit betrieblichen Informationssystemen in diesem Lernstoff eine besondere, nämlich die, wie derartige Systeme geplant und realisiert werden. Unter Planung wird die systematische, nach bestimmten Regeln ablaufende, gedankliche Vorwegnahme zukünftiger Zustände und Ereignisse verstanden. Im Zusammenhang mit Absatzplanung, Fertigungsplanung, Kostenplanung und ähnlichen Begriffen wird in der Betriebswirtschaftslehre unter Planung meist "Vorausschau" verstanden, also das Setzen von Zielen und das Festlegen von Maßnahmen zur Erreichung der Ziele. Dabei handelt es sich im allgemeinen um zyklische Prozesse, also um Prozesse, die sich in einer Betriebswirtschaft routinemäßig wiederholen; für die Planung betrieblicher Informationssysteme ist diese routinemäßige Wiederholung jedoch nicht typisch. Die Planung eines Informationssystems ist eine komplizierte Aufgabe, die durch einen definierbaren Anfang und durch einen definierbaren Abschluß beschrieben werden kann und die den Einsatz von Produktionsfaktoren für die einzelnen, miteinander verbundenen und voneinander abhängigen Tätigkeiten erfordert, um die der Aufgabe vorgegebenen Ziele zu erreichen. Mit anderen Worten: Die Planung eines Informationssystems ist ein Projekt und kein zyklischer Prozeß. Planung wird hier als vorausschauendes, systematisches Durchdenken und Formulieren von Zielen, Verhaltensweisen und Handlungsalternativen, als das Auswählen optimaler Alternativen sowie das Festlegen von Anweisungen zur Realisierung optimaler Alternativen im Rahmen eines Projekts verstanden.

14

Grundlagen

der

Systemplanung

Das Konstrukt S y s t e m p l a n u n g meint eine so verstandene Vorgehensweise in bezug auf Informationssysteme. Objekte der Systemplanung sind also Informationssysteme (oder "Anwendungssysteme" als Teile von Informationssystemen) in Betriebswirtschaften. Z u r E i n o r d n u n g in Wissenschaftsdisziplinen Zur Einordnung der Systemplanung in Wissenschaftsdisziplinen ist eine weitere Präzisierung dessen nötig, was unter betrieblichen I n f o r m a t i o n s s y s t e m e n zu verstehen ist, was also ihre Elemente und die zwischen diesen bestehenden Beziehungen sind. Werden betriebliche Informationssysteme auf einer relativ abstrakten Ebene zerlegt, so ergeben sich die folgenden drei Komponenten: • die Aufgabenträger in Betriebswirtschaften ("Menschen"); • die betriebliche Aufgabe ("Aufgabe"); • die Informations- und Kommunikationstechnologie ("IuK-Technologie"). Daraus folgt, daß betriebliche Informationssysteme "Aufgabenträger/betriebliche Aufgabe/Informations- und Kommunikationstechnologie-Systeme", kürzer ausgedrückt: Mensch/Aufgabe/Technologie-Systeme (kurz: "MAT-Systeme") sind. Abbildung EINSP-1 zeigt die Grundstruktur von MAT-Systemen mit den genannten K o m p o n e n t e n auf der ersten Gliederungsebene als Knoten. Sie zeigt auch die B e z i e h u n g e n zwischen den Komponenten, die - im Sinn eines vollständigen Graphen - zwischen allen Komponenten bestehen.

M A T

= Mensch = Aufgabe = Informations- und Kommunikationstechnologie = Methoden, Techniken und Werkzeuge der Systemplanung

Abb. EINSP-1: Abstrakte Grundstruktur eines Informationssystems

Die D y n a m i k des Systems zeigt sich daran, daß sich die Betrachter - Studierende, Wissenschaftler und Praktiker der Wirtschaftsinformatik - ganz besonders f ü r das interessieren, was - verursacht durch die Interaktionen zwischen den Komponenten - auf den Kanten des Graphen passiert, viel mehr als f ü r das, was in seinen Knoten geschieht. So veranschaulicht der Pfeil von T nach A die Beeinflussung der betrieblichen Aufgabe durch die Informations- und Kommunikationstechnologie; die Aufgabe kann also durch IuK-Technologie verändert werden. Der Pfeil von T nach M zeigt die Beeinflussung der Aufgabenträger durch die IuK-Technologie, indem z.B. der Handlungsspielraum der Aufgabenträger durch die IuK-Technologie verändert, nämlich eingeengt oder erweitert wird. Der Pfeil vom M nach A schließlich macht deutlich, daß sich durch Menschen (als Technologieverwender) veränderte Sichten auf die A u f g a b e

EINSP - Einführung

in die Systemplanung

15

ergeben können, indem z.B. einzelne Aufgaben verschwinden, andere Aufgaben neu entstehen. Die Beispiele bestätigen vor allem den Charakter von Informationssystemen als dynamische Systeme; zur Verdeutlichung ihres Charakters als offene und komplexe Systeme bedürfte es einer weiter ausholenden Argumentation. Es soll aber nicht Gegenstand einer Einführung in die Systemplanung sein, Informationssysteme umfassend zu erklären. Dies ist Aufgabe einer wissenschaftstheoretischen Analyse der Wirtschaftsinformatik, zu deren Erkenntnisobjekt Informationssysteme gehören (vgl. den Band "Wirtschaftsinformatik - Einführung und Grundlegung"). Wie immer Abbildung EINSP-1 betrachtet wird, Wirtschaftsinformatik richtet ihre Sicht auf MAT-Systeme primär an der Aufgabe aus, dann an den Personen, welche die Aufgabe ausführen ("Aufgabenträger") und erst zuletzt an der Technologie, die der Unterstützung der Aufgabenausführung dient. Wirtschaftsinformatik ist also primär aufgaben-orientiert und dann mensch-orientiert, keinesfalls primär technologie-orientiert. Der Kreis in Abbildung EINSP-1 soll keine Abgeschlossenheit andeuten. Er deutet - über die weiter oben erläuterten Beziehungen hinaus - das gesamte Beziehungsgefüge zwischen den drei Basiskomponenten von Informationssystemen sowie die Gesamtheit dessen an, was zur Planung und Realisierung dieser Systeme erforderlich ist, also die Aufgaben, die Methoden und Techniken sowie die Werkzeuge der Systemplanung. Damit können aus Abbildung EINSP-1 folgende Teilgebiete der Wirtschaftsinformatik abgeleitet werden: der Mensch, die Aufgabe, die IuK-Technologie und die Systemplanung. • Erstes Teilgebiet der Wirtschaftsinformatik: der Mensch als Komponente von Informations- und Kommunikationssystemen mit seiner Beeinflussung der Aufgabe und der Technologie sowie mit seiner Beeinflussung durch die Aufgabe und durch die Technologie. • Zweites Teilgebiet der Wirtschaftsinformatik: die Aufgabe als Komponente von Informations- und Kommunikationssystemen mit ihrer Beeinflussung des Menschen und der Technologie sowie mit ihrer Beeinflussung durch den Menschen und durch die Technologie. • Drittes Teilgebiet der Wirtschaftsinformatik: die IuK-Technologie als Komponente von Informations- und Kommunikationssystemen mit ihrer Beeinflussung des Menschen und der Aufgabe sowie mit ihrer Beeinflussung durch den Menschen und durch die Aufgabe. • Viertes Teilgebiet der Wirtschaftsinformatik: die Systemplanung als der Prozeß der Planung und Realisierung von Informations- und Kommunikationssystemen, also der Verknüpfung von Mensch, Aufgabe und IuK-Technologie. Ein fünftes, aus Abbildung EINSP-1 nicht ersichtliches Teilgebiet der Wirtschaftsinformatik ist das Informationsmanagement (vgl. dazu den Band "Informationsmanagement"). Der vorliegende Lernstoff befaßt sich nur mit dem vierten Teilgebiet der Wirtschaftsinformatik, der Systemplanung; innerhalb dieses Teilgebiets ist eine weitere Abgrenzung notwendig.

16

Grundlagen der

Systemplanung

Betrachtet m a n die Komponente Aufgabe näher, dann stellt sich die Frage, um welche Aufgabe es sich handelt. Ist damit beispielsweise eine "Produktionsplanung und -Steuerung" in einem Industriebetrieb oder eine "Patientenabrechnung" in einem Krankenhaus oder eine "Budgetplanung" in einer politischen Gemeinde oder eine "Einsatzplanung" bei der Polizei oder eine "Stundenplanerstellung" in einer Schule gemeint? Die Beispiele deuten die Unterschiedlichkeit der Aufgabe an und legen es nahe, die Zweckbestimmung eines Informations- und Kommunikationssystems entsprechend der Art der Aufgabe zu differenzieren. Aus diesem Grund wurde oben bereits von "betrieblichen" Informations- und Kommunikationssystemen gesprochen. Dies kann so präzisiert werden, daß es sich um solche Systeme handelt, bei denen "Aufgabe" betriebliche Aufgabe oder Aufgabe in Betriebswirtschaften bedeutet. Die Wissenschaft, die sich primär mit dieser Art von Aufgabe befaßt, ist die Betriebswirtschaftslehre. Die aufgabenorientierte Zwecksetzung von Informationssystemen kann zu einer systematischen Gliederung der Wissenschaftsdisziplin Wirtschaftsinformatik verwendet werden, indem alle an die Art der Aufgabe gebundenen Probleme, mit deren Lösung sich diese Wissenschaftsdisziplin beschäftigt, Besonderen Wirtschaftsinformatiken zugewiesen werden. Die allen Besonderen Wirtschaftsinformatiken gemeinsamen Probleme sind Teil einer Allgemeinen Wirtschaftsinformatik. Abbildung EINSP-2 zeigt das Ergebnis dieser Überlegungen.

Abb. EINSP-2: Gliederung der Wirtschaftsinformatik in Teildisziplinen

Für das Teilgebiet Systemplanung gilt, daß es für alle Besonderen Wirtschaftsinformatiken von Bedeutung ist, was nicht ausschließt, daß Besonderheiten bestehen, die beispielsweise nur Gegenstand der Betriebsinformatik sind. Der hier dokumentierte Lernstoff ist also im wesentlichen in die Allgemeine Wirtschaftsinformatik einzuordnen.

EINSP - Einführung

in die Systemplanung

17

Zur Einordnung in Lehrgebiete Die Überlegungen zur Einordnung der Systemplanung in Wissenschaftsdisziplinen ermöglichen es, Aussagen über die Einordnung dieses Lernstoffs in Lehrgebiete zu machen. Dabei ist von folgenden Alternativen, Wirtschaftsinformatik an deutschsprachigen Universitäten und Hochschulen zu studieren, auszugehen: • Wirtschaftsinformatik als Diplomstudiengang; • Wirtschaftsinformatik (oder eine Besondere Wirtschaftsinformatik, wie etwa Betriebsinformatik) als Wahlpflichtfach oder als Wahlfach im Rahmen anderer Diplomstudiengänge (z.B. der Betriebswirtschaftslehre); • Wirtschaftsinformatik (oder in der Regel nur Teile davon, in erster Linie das Teilgebiet Informations- und Kommunikationstechnologie) als Pflichtfach, Wahlpflichtfach oder Wahlfach im Rahmen anderer, insbesondere wirtschaftswissenschaftlicher Studiengänge (diese Alternative kann bei der weiteren Erörterung unbeachtet bleiben, da "Systemplanung" nicht zu ihrem Stoffumfang gehört). In erster Linie ist der Lernstoff "Systemplanung" in das Lehrgebiet der Diplomstudiengänge Wirtschaftsinformatik einzuordnen, wie sie derzeit an Universitäten und Fachhochschulen im deutschsprachigen Raum angeboten werden. Das Ausbildungsziel dieser Studiengänge kann so beschrieben werden: Absolventen sind in der Lage, sowohl auf der Seite der Anbieter (Hersteller, Systemund Software-Häuser), als auch auf der Seite der Anwender Informations- und Kommunikationssysteme zu planen und zu realisieren. Studierende werden folglich - neben anderen Lehrgebieten - die fünf genannten Teilgebiete der Wirtschaftsinformatik intensiv bearbeiten müssen, also auch und insbesondere Systemplanung (in den Studienplänen häufig mit "Systemanalyse" bezeichnet). In zweiter Linie ist der Lernstoff "Systemplanung" in das Lehrgebiet der Diplomstudiengänge Betriebswirtschaftslehre einzuordnen, die - zumeist im zweiten Studienabschnitt bzw. im Hauptstudium - Wirtschaftsinformatik oder Betriebsinformatik als Wahlpflichtfach oder als Wahlfach vorsehen. Das Ausbildungsziel dieses Vertiefungsfachs kann so beschrieben werden: Absolventen dieser Studiengänge werden in der Praxis vor allem als Benutzer von Informations- und Kommunikationssystemen auftreten. Sie bestimmen weitgehend die Anforderungen an die Gestaltung dieser Systeme, und sie wirken in der Regel auch an der Systemplanung aktiv mit (Benutzerbeteiligung, vgl. Lerneinheit BEBET im Band "Informationsmanagement"). Der Lernstoff "Systemplanung" geht weit über das hinaus, was man als Benutzer wissen muß. Auf der anderen Seite ist er zur Erreichung des genannten Ausbildungsziels durch Grundkenntnisse über die Informations- und Kommunikationstechnologie zu ergänzen; die Grundkenntnisse zu anderen Teilgebieten der Wirtschaftsinformatik (also Mensch und Aufgabe) sind aus den Lehrgebieten des Hauptstudiums bekannt. Schließlich soll darauf hingewiesen werden, daß der Lernstoff "Systemplanung" erfahrungsgemäß eine sinnvolle Ergänzung zu sonstigen Studienrichtungen darstellt (etwa in Form von Wahl- und Freifächem). Beispiel dafür ist die Informatik, wenn Studierende einen Studienschwerpunkt in Richtung Anwendungsin-

18

Grundlagen der Systemplanung

formatiken suchen. Allerdings zeigt sich hier häufig, daß den Studierenden ausreichende Grundkenntnisse zu den Teilgebieten der Wirtschaftsinformatik "Mensch" und "Aufgabe" fehlen, sodaß das Verstehen von "Systemplanung" sehr erschwert wird. Zur Gliederung des Lernstoffs Der Lernstoff ist zunächst in einzelne Kapitel gegliedert, welche dem Phasenmodell der Systemplanung (vgl. Lerneinheit ZAMSP) folgen. Die Teile des Lernstoffs, die für alle Phasen von Bedeutung sind, werden gewissermaßen "vor die Klammer" gezogen. Dies ergibt folgende Struktur bezüglich der Kapitel: • • • • • • •

Erstes Kapitel: Grundlagen der Systemplanung Zweites Kapitel: Methoden und Techniken der Systemplanung Drittes Kapitel: Der Prozeß der Vorstudie Viertes Kapitel: Der Prozeß der Feinstudie Fünftes Kapitel: Der Prozeß der Grobprojektierung Sechstes Kapitel: Der Prozeß der Feinprojektierung Siebentes Kapitel: Der Prozeß der Installierung

Auf der zweiten Gliederungsebene wird folgende Struktur verwendet: Im Kapitel "Grundlagen der Systemplanung" werden - nach dieser Einführung - zunächst das Ziel, die Aufgaben und die Methodik der Systemplanung behandelt (Lerneinheit ZAMSP) und ihre systemtechnische Orientierung erläutert (Lerneinheit SYSTE). Davon ausgehend wird der Charakter der Systemplanung als Prozeß herausgearbeitet (Lerneinheit PROSP). Dann wird auf zwei Methodik-Aspekte der Systemplanung vertieft eingegangen, auf die Objektorientierung (Lerneinheit OBSP) und auf das Prototyping (Lerneinheit PROTY). Anschließend wird die Werkzeugunterstützung der Systemplanung (Lerneinheit WERSP) und zum Abschluß dieses Kapitels werden die Aufgabenträger der Systemplanung behandelt (Lerneinheit AUTER). Das zweite Kapitel behandelt die Methoden und Techniken der Systemplanung, die nicht nur einzelnen Phasen zugeordnet werden können; sie sind also für mehrere oder für alle Phasen der Systemplanung von Bedeutung. Methodenhinweise finden sich in den einzelnen Lerneinheiten. Angesichts der Vielzahl dessen, was als Methode und Technik zur Darstellung, zur Analyse und insbesondere zum Entwurf von Informations- und Kommunikationssystemen angeboten wird (und was trotzdem in vielfältiger Hinsicht unvollkommen und unbefriedigend ist), war eine Auswahl notwendig; in 15 Lerneinheiten werden die ausgewählten Methoden und Techniken dargestellt. Die Kapitel drei bis sieben behandeln je eine Phase der Systemplanung und haben folgende Struktur: • Zunächst werden das Ziel, die Aufgaben und die Methodik jeder Phase behandelt. • Daran schließt sich eine Darstellung der Aufgaben jeder Phase an. • Schließlich werden für jede Phase die phasenspezifischen Methoden und Techniken behandelt.

E1NSP - Einführung

in die Systemplanung

19

Der Lernstoff ist in einzelne Lerneinheiten gegliedert; jede dieser Lerneinheiten hat folgende Struktur: • erster Abschnitt: Lernziele; • zweiter Abschnitt: Definitionen und Abkürzungen, die in der betreffenden Lerneinheit verwendet werden, wobei auch die Übersetzung ins Englische angegeben wird (was in Anbetracht der häufigen Verwendung von Anglizismen in der Wirtschaftsinformatik der Verbesserung der Verständlichkeit dienen kann); • dritter Abschnitt: Stoffinhalt der Lerneinheit, der in Teilabschnitte untergliedert ist; • vierter Abschnitt: Forschungsbefunde zum jeweiligen Stoffinhalt; • fünfter Abschnitt: Aufgabenverweise (bei Lerneinheiten, die Methoden und Techniken zum Inhalt haben) bzw. Methodenverweise (bei Lerneinheiten, die Aufgaben zum Inhalt haben); • sechster Abschnitt: Kontrollfragen zum jeweiligen Stoffinhalt; • siebter Abschnitt: Quellenliteratur, also die Literatur, aus welcher der Stoffinhalt entnommen wurde, soweit es sich nicht um Allgemeingut bzw. um Arbeitsergebnisse des Autors handelt; • achter Abschnitt: Vertiefungsliteratur, beispielsweise zu den Forschungsbefunden, die ein weitergehendes Selbststudium ermöglichen soll; • neunter Abschnitt: Normen. Viele Lerneinheiten enthalten am Ende des dritten Abschnitts ein Demonstrationsbeispiel. Forschungsbefunde, Vertiefungsliteratur und Normen finden sich nicht in allen Lerneinheiten. Kontrollfragen 1. 2. 3. 4. 5.

Aus welchen Komponenten besteht die abstrakte Grundstruktur eines betrieblichen Informationssystems? Welche typischen Eigenschaften von Systemen treffen auf Informationssysteme zu? Welches sind die fünf Teilgebiete der Wirtschaftsinformatik? Wie kann Wirtschaftsinformatik als Wissenschaft in Teildisziplinen gegliedert werden? Welche Unterschiede und Gemeinsamkeiten bestehen zwischen Betriebsinformatik und Verwaltungsinformatik?

Quellenliteratur Heinrich, L. J.: Wirtschaftsinformatik in Forschung und Ausbildung. In: Information M a n a g e ment 1/1986, 63 - 6 9 Heinrich, L. J.: Wirtschaftsinformatik - Einführung und Grundlegung. Oldenbourg Verlag, M ü n chen/Wien 1993 Heinrich, L. J. et al.: Informations- und Kommunikationstechnik f ü r Betriebswirte und Wirtschaftsinformatikcr. 4. A., Oldenbourg Verlag, München/Wien 1994 Heinrich, L. J. und Roithmayr, F.: Wirtschaftsinformatik-Lexikon. 5. A., Oldenbourg Verlag, München/Wien 1995 Mertens, P. et al. (Hrsg.): Studien- und Forschungsführer Wirtschaftsinformatik. 5. A., Springer Verlag, Berlin et al. 1996 Mertens, P. et al.: G r u n d z ü g e der Wirtschaftsinformatik. 3. A., Springer Verlag, Berlin et. al. 1995

20

Grundlagen der Systemplanung

Vertiefungsliteratur Heinrich, L. J.: Wirtschaftsinformatik als Wissenschaft - Entwicklung, Stand und Perspektiven. In: Heinrich, L. J. und Lüder, K. (Hrsg.): Betriebswirtschaftslehre und Unternehmensführung. Verlag Neue Wirtschaftsbriefe, Herne/Berlin 1985, 35 - 59 Scheer, A. W.: EDV-orientierte Betriebswirtschaftslehre. 4. A., Springer Verlag, Berlin et al. 1990 Schneeweiß, Ch.: Planung 1 - Systemanalytische und entscheidungstheoretische Grundlagen. Springer Verlag, Berlin et al. 1991

ZAMSP - Ziel, Aufgaben und Methodik der Systemplanung Lernziele Sie kennen die Bedeutung der Ziele für die Systemplanung und können diese zum Ausgangspunkt der Zielsystembildung für IuK-Projekte verwenden. Sie können die Aufgabe der Planung und Realisierung eines IuK-Systems in Teilaufgaben gliedern und als Phasenmodell beschreiben. Sie erkennen, daß die Methodik der Systemplanung eine Mischung verschiedener Methodikansätze ist. Definitionen und Abkürzungen Aufgabenanalyse (task analysis) = die systematische Zerlegung einer Aufgabe in Teilaufgaben, Tätigkeiten usw. mit dem Ziel, den Möglichkeitsraum der Aufgabenzerlegung zu bestimmen. Aufgabensynthese (task synthesis) = die systematische Zusammenfassung von Teilmengen des durch die Aufgabenanalyse bestimmten Möglichkeitsraums der Aufgabenzerlegung zu Arbeitsaufgaben. Informationsfunktion (information function) = die Gesamtheit der Aufgaben, die sich mit Information und Kommunikation als wirtschaftliches Gut befassen. Informationsinfrastruktur (information infrastructure) = die Einrichtungen, Mittel und Maßnahmen, welche die Voraussetzung für die Produktion von Information und Kommunikation schaffen. Methode (method) = ein auf einem System von Regeln aufbauendes Problemlösungsverfahren (z. B. ein Algorithmus). Methodik (methodology) = die Lehre von den Methoden und ihrer planmäßigen wissenschaftlichen Anwendung. Synonym: Methodologie. Modell (model) = eine vereinfachende Abbildung eines Ausschnitts der Wirklichkeit oder eines Vorbilds für die Wirklichkeit. Planungsziel (planning goal) = ein Ziel, das der Systemplanung vom strategischen Informationsmanagement vorgegeben ist. Projekt (project) = ein zielgerichtetes, klar definiertes, zeitlich begrenztes, durch Größe, Bedeutung, Komplexität, Neuartigkeit, Einmaligkeit, Kosten und Risiko aus dem üblichen Geschehen herausragendes Vorhaben. Rückkopplung (feedback) = ein Prinzip, das einen geschlossenen Wirkungskreislauf herstellt, sodaß der Ausgang eines Systems einen Eingang dieses Systems beeinflußt. zeitlicher Bezug eines Ziels (reference time of goal) = der Zeitraum, bis zu dessen Ende das angestrebte Zielausmaß erreicht sein soll. Zielausmaß (goal domain) = die Vorschrift, mit welcher der Entscheidungsträger angibt, welche Quantität des Zielmaßstabs er anstrebt. Zielinhalt (goal content) = der Gegenstand, auf den sich das Streben des Entscheidungsträgers richtet. Zielmaßstab (goal Standard) = eine Vorschrift, die angibt, wie der Zielinhalt zu dimensionieren und - wenn möglich - zu quantifizieren ist. Zielsystem (goal system) =eine Menge von Zielen, die miteinander in Beziehung stehen, wobei die Beziehungen - idealtypisch betrachtet - komplementär, konfliktär oder indifferent sind.

22

Grundlagen der Systemplanung

Ziele der Systemplanung Generell ist ein Ziel ein Ort, ein Punkt oder ein Zustand, den man erreichen will. Im betriebswirtschaftlichen Sinn ist ein Ziel eine normative Aussage eines Entscheidungsträgers, die einen anzustrebenden und damit zukünftigen Zustand der Wirklichkeit beschreibt. Ein Ziel lenkt die Auswahl von Alternativen, indem die prognostizierten Wirkungen der Alternativen mit der normativen Aussage verglichen und damit beurteilbar gemacht werden. Jedes Ziel hat mehrere Dimensionen, nämlich Zielinhalt, Zielmaßstab, Zielausmaß und zeitlicher Bezug. Jedes Handeln - und so auch die Planung und Realisierung eines Informations- und Kommunikationssystems - wird von mehreren Zielen, die sich zueinander indifferent, komplementär oder konfliktär verhalten können, bestimmt. Ziele werden von Menschen gesetzt. Ziele der Systemplanung sind sowohl Organisationsziele als auch Individualziele. Die Organisationsziele entstehen dadurch, daß die für die Informationsfunktion zuständigen Entscheidungsträger Ziele verbindlich festlegen und vorgeben. Individualziele sind die Ziele einzelner Personen oder Gruppen, die Mitglieder der Organisation sind. Ein Zielsystem kann sich nur dann bewähren, wenn es gelingt, die Organisationsziele und die Individualziele insgesamt so zu gestalten, daß sie sich letztlich komplementär verhalten. Ziele sind entweder Sachziele oder Formalziele. Sachziele der Systemplanung können so beschrieben werden: Sie haben Zielinhalte, die auf eine Definition des Zwecks des Informations- und Kommunikationssystems ausgerichtet sind. Sachziele beschreiben also, welche betrieblichen Aufgaben unterstützt werden sollen. Sachziele der Systemplanung im einzelnen können daher nur im Kontext eines konkreten IuK-Projekts präzisiert werden. Das generelle Sachziel der Systemplanung besteht darin, ein produktiv verwendbares Informations- und Kommunikationssystem für einen Anwender zur Verfügung zu stellen; daraus ergeben sich die Aufgaben der Systemplanung. Formalziele der Systemplanung können so beschrieben werden: Sie haben Zielinhalte, welche die Qualität oder die Güte, die das Informations- und Kommunikationssystem besitzen soll, definieren. Empirische Belege dafür, welche Organisationsziele und welche Individualziele als Formalziele verwendet werden, liegen nicht in einem Umfang vor, der es ermöglicht, ein geschlossenes Formalzielsystem der Systemplanung anzugeben. Dieses wäre auch lediglich ein modelltheoretisches Konzept, das aber als Orientierungsgröße bei der Zielsystembildung in der Praxis verwendet werden könnte. Die Zielbildung für ein konkretes Projekt der Systemplanung ist zeitverbrauchend und arbeitsaufwendig, sodaß sie häufig nicht oder mit nicht ausreichender Gründlichkeit durchgeführt wird. Das Zielsystem der Systemplanung ist eine Teilmenge des umfassenderen Ziels y s t e m s der Informationsfunktion einer Organisation, das folgendermaßen gegliedert werden kann:

ZAMSP - Ziel, Aufgaben und Methodik der Systemplanung

23

• strategische Ziele, deren Inhalte die Informationsfunktion als Ganzes betreffen; • administrative Ziele, deren Inhalte Teile der Informationsfunktion betreffen (z.B. einzelne IuK-Systeme); • operative Ziele, deren Inhalte die Benutzung von IuK-Systemen betreffen. Eine projektbezogene Präzisierung der Sachziele und der Formalziele erfolgt im Zusammenhang mit der Erläuterung der Aufgaben der Vorstudie (vgl. Lerneinheiten SACHZ und FORMZ). Aufgaben der Systemplanung Generelle Aufgabe ("Sachziel" oder "Zweck") der Systemplanung ist es, dem Auftraggeber ein produktives Informationssystem zur Verfügung zu stellen. Da es sich häufig um ein Teilsystem handelt, kann auch gesagt werden, daß es Sachziel oder Zweck der Systemplanung ist, dem Auftraggeber ein produktives Anwendungssystem zur Verfügung zu stellen. "Produktiv" ist es dann, wenn es nach Durchführung aller Tests (Abnahmetest mit Funktionstest und Leistungstest sowie Integrationstest) - im Echtbetrieb eingesetzt werden kann. Zerlegt man die generelle Aufgabe der Systemplanung entsprechend der Aufgabenanalyse in Teilaufgaben, die Teilaufgaben in Tätigkeiten usw., dann erhält man die Menge der Aufgaben, deren Bearbeitung erforderlich ist, um das Sachziel der Systemplanung zu erreichen. Faßt man entsprechend der Aufgabensynthese einzelne Aufgaben zu Aufgabenklassen zusammen, so ergibt sich eine sinnvolle Ordnung der Aufgaben der Systemplanung. Orientiert sich die Aufgabensynthese an idealtypischen Phasen der Systemplanung, dann ist ihr Ergebnis ein Phasenmodell. In einem weiteren Schritt kann man den Phasen Methoden und Techniken zuordnen, mit denen ihre Planung und Realisierung unterstützt werden kann. Der Aussagewert (und damit auch die praktische Brauchbarkeit) des Phasenmodells wird oft mißverstanden. Ein Mißverständnis liegt z.B. vor, wenn im Phasenmodell eine allgemeingültige und praktisch anwendbare Vorgehensweise (d.h. ein Vorgehens Schema oder Vorgehensmodell) für die Systemplanung oder eine allgemeingültige Methodik der Systemplanung gesehen wird. Beispielsweise gibt das Phasenmodell keine eindeutige zeitliche Ordnung der Phasen und ihrer Aufgaben an. Man darf sich den Prozeß der Systemplanung nicht als eine lineare Abfolge der einzelnen Phasen vorstellen. Vielmehr überlappen sich die Phasen, und sie sind durch Rückkopplung untereinander vernetzt. Auch sind verschiedene Methoden und Techniken in mehreren oder gar allen Phasen anwendbar. Deshalb lassen sich allgemeingültige und praktisch anwendbare Aussagen nur bezüglich einer groben Struktur machen. Die Feinstruktur des Prozesses der Systemplanung ist viel stärker von dem spezifischen Kontext abhängig und wird durch die Projektplanung festgelegt (vgl. Lerneinheit PROPL). Der Wert des Phasenmodells ist vor allem didaktischer Art. Mit der durch das Phasenmodell vorgenommenen Ordnung der Aufgaben, einschließlich der Zuordnung von Methoden und Techniken, läßt sich die Gesamtaufgabe der Systemplanung übersichtlich darstellen und verständlich machen. Das Phasenmodell als genereller Ordnungsrahmen für die Systemplanung existiert in Literatur und Praxis in vielen, nur im Detail voneinander abweichenden Varianten. In diesem

24

Grundlagen der Systemplanung

Lehrtext wird ein Phasenmodell verwendet, das sich von anderen dadurch unterscheidet, daß die Wartung eines installierten und produktiv benutzten IuKSystems keine Phase der Systemplanung ist (weil sie dem hier verfolgten projektorientierten Verständnis der Systemplanung nicht entspricht); diese Aufgabe ist dem Anwendungssystem-Management zugeordnet (vgl. Lerneinheit ANWEN im Band "Informationsmanagement"). Es unterscheidet sich auch dadurch, daß der Systemtest keine Phase ist, sondern daß das Testen der Analyse-, Entwurfs- und Entwicklungsergebnisse in alle Phasen integriert ist (vgl. Lerneinheit TESTM). Das gilt analog für die Dokumentation, also für das Dokumentieren des gesamten Prozesses der Systemplanung und seiner Ergebnisse (vgl. Lerneinheit DOKUM). Jedes Phasenmodell der Systemplanung leistet im wesentlichen nicht mehr, als eine Ordnung der Aufgaben der Systemplanung unter dem Gesichtspunkt vorzunehmen, gleichartige Aufgaben einer Phase zuzuordnen (und gegebenenfalls in einem weiteren Schritt einzelnen Phasen bestimmte Methodikansätze sowie Methoden und Techniken zuzuordnen). Jede Phase beschreibt demnach in erster Linie Klassen von Aufgaben der Systemplanung (und gegebenenfalls auch bestimmte Methodikansätze sowie Methoden und Techniken). Die Phasen stellen also die erste Gliederungsebene der top-down zerlegten Aufgabe der Systemplanung dar, nämlich: dem Anwender ein produktives IuK-System zur Verfügung zu stellen. Abbildung ZAMSP-1 zeigt das in diesem Lehrtext verwendete Phasenmodell mit den dazugehörenden Phasenzielen und den verwendeten Methodikansätzen. Das Phasenmodell sowie der Prozeß der Systemplanung anhand dieses Phasenmodells werden in Lerneinheit PROSP erläutert. Phase

Phasenziel

Verwendete M e t h o d i k a n s ä t z e

Vorstudie

Grundkonzeption

Sollzustandsorientierung

Feinstudie

Angepaßte Grundkonzeption

Istzustandsorientierung u n d Sollzustandsorientierung im R a h m e n der G r u n d k o n z e p t i o n

Grobprojektierung

Logisches Modell Sollzustand

Sollzustandsorientierung, Datenorientierung, Inside-Out-Ansatz, Prototyping

Feinprojektierung

Physisches Modell Sollzustand

wie Grobprojektierung

Installierung

Produktives Informationssystem

Sollzustandsorientierung, Systemintegration, Umstellungsmethoden

Abb. Z A M S P - 1 : Phasenziele und Methodikansätze im Phasenmodell

Methodik der Systemplanung Generell wird unter M e t h o d i k die Lehre von den Methoden und ihrer planmäßigen, wissenschaftlichen Anwendung verstanden. In der Wirtschaftsinformatik ist unter Methodik eine Arbeitsweise zu verstehen, die bezüglich der Art des

ZAMSP - Ziel, Aufgaben und Methodik der Systemplanung

25

Vorgehens systematisiert und festgelegt ist. Die Methodik der Systemplanung regelt daher das systematische, wissenschaftlich orientierte Vorgehen bei der Planung und Realisierung von IuK-Systemen. Sie ist, mit anderen Worten, der prinzipielle Leitfaden zur systematischen Lösung der Aufgabe, IuK-Systeme zu schaffen, die produktiv verwendbar sind. Neben einem Denkansatz für die Systemanalyse soll sie insbesondere eine Vorgehenssystematik für die Systementwicklung enthalten; sie soll aber auch bei der Systemeinführung Hilfestellung leisten, kurz: sie soll möglichst alle Aufgaben der Systemplanung umfassen. Eine allgemein akzeptierte, wissenschaftlich begründete, leistungsfähige und in der Praxis anwendbare Methodik der Systemplanung gibt es nicht. Der diesbezüglich zu beobachtende Methodikstreit, in den immer wieder "neue" Ansätze eingebracht werden, ist auf zwei Mißverständnisse zurückzuführen: • Erstens auf die Annahme, daß es die eine Methodik der Systemplanung geben könne; dies ist angesichts der Komplexität des Objekts der Systemplanung unmöglich. Die Methodik der Systemplanung muß daher eine Mischung verschiedener Methodikansätze sein. • Zweitens auf die Annahme, daß die Methodik der Systemplanung vom Planungskontext unabhängig ist; dies ist angesichts der Unterschiedlichkeit der Planungsaufgaben in Wirtschaft und Verwaltung (und hier in den unterschiedlichen Aufgabengebieten), der Unterschiedlichkeit der Teilobjekte der Systemplanung (z.B. Datensystem, Methodensystem und Arbeitsorganisation) und der Unterschiedlichkeit der Persönlichkeit und Qualifikation der Aufgabenträger der Systemplanung unwahrscheinlich. Methodikansätze der Systemplanung Im folgenden wird der erste Gesichtspunkt weiterverfolgt, und es wird in Kurzform erläutert, welches die verschiedenen Methodikansätze sind, die zu einer systematischen Vorgehensweise verknüpft werden müssen. Dabei wird auf Lerneinheiten hingewiesen, in denen eine vertiefte Behandlung erfolgt (zum Erreichen der Lernziele dieser Lerneinheit reichen die Kurzerläuterungen aus). Davon ausgehend wird zusammenfassend festgestellt, was bezüglich der Methodik der Systemplanung "herrschende Meinung" ist, mit anderen Worten: was als Paradigma der Systemplanung angesehen werden kann. Folgende Methodikansätze der Systemplanung sind erwähnenswert: • • • • • • • •

Systemansatz (auch: systemtechnischer Ansatz), Phasenmodell (auch: Phasenschema oder Lebenszyklus-Modell), istzustandsorientierter/sollzustandsorientierter Ansatz, Outside-in-ZInside-out-Ansatz, funktionsorientierter/datenorientierter Ansatz, objektorientierter Ansatz, logisches Modell/physisches Modell, prototyp-orientierter Ansatz.

Der Systemansatz führt das aus der Systemtheorie und der Systemtechnik stammende Systemdenken in die Systemplanung ein (vgl. Lerneinheit SYSTE). Sein Grundgedanke ist folgender: Ein gegebener Untersuchungsbereich soll so lange

26

Grundlagen der Systemplanung

ausgeweitet werden, bis er so umfassend ist, daß alle Ursachen von Wirkungen auf den ursprünglichen Untersuchungsbereich und alle Folgen von Wirkungen aus dem ursprünglichen Untersuchungsbereich erfaßt worden sind. Das Phasenmodell gliedert die Gesamtaufgabe der Systemplanung in Phasen und unterstellt einen Phasenablauf, der vom Generellen zum Detail verläuft; innerhalb der Phasen werden Problemlösungszyklen durchlaufen, welche sich in Zielsuche, Lösungssuche und Auswahl gliedern (vgl. Lerneinheit PROSP). Methoden und Techniken zur Unterstützung der Problemlösung stehen für die Aufgaben in allen Phasen in mehr oder weniger großem Umfang zur Verfügung. Wesentliches Merkmal eines modernen Verständnisses des Phasenmodells ist die Verwendung der Grundkonzeption als konzeptuelles Modell, das nicht als Endergebnis der Analyse angesehen wird und dennoch erste Entwurfsergebnisse enthält. Die Grundkonzeption bildet die Grundlage für die Kommunikation zwischen Auftraggebern und Auftragnehmern; sie wird während der weiterführenden Analyse- und Entwurfsarbeiten verfeinert (Prinzip der schrittweisen Verfeinerung), ist also keine starre Größe, die nur als Ganzes verworfen oder akzeptiert werden könnte. Der istzustandsorientierte Ansatz ist durch die Vorgehensweise: erst Istzustandserfassung, dann Istzustandsanalyse und dann Entwicklung des Sollzustands gekennzeichnet. Seine entscheidende Schwäche besteht in der Gefahr einer zu starken Gegenwarts- oder sogar Vergangenheitsorientierung. Im Unterschied dazu ist der sollzustandsorientierte Ansatz durch die Vorgehensweise: erst Entwicklung eines groben Sollkonzepts, dann Istzustandserfassung, dann Korrektur des Sollkonzepts solange, bis es im gegebenen Kontext als Idealkonzept zu bezeichnen ist, gekennzeichnet. Seine entscheidende Schwäche besteht in der Gefahr, den Istzustand nur aus der Sicht eines, möglicherweise unzweckmäßigen, Sollkonzepts zu betrachten. Der Outside-in-Ansatz und der Inside-out-Ansatz bilden das Objekt und die Teilobjekte der Systemplanung als Schalenmodell (auch: Zwiebelmodell) ab. Der Outside-in-Ansatz ist dadurch gekennzeichnet, daß bei der Systemplanung von den Bedingungen des Umsystems ausgegangen und dann schrittweise ("Schale für Schale") nach innen, also zum Zentrum hin gearbeitet wird. Der Inside-out-Ansatz beginnt im Zentrum, und man bewegt sich schrittweise ("Schale für Schale") bis zu den Bedingungen des Umsystems nach außen. Der funktionsorientierte Ansatz (auch: ablauforientierter Ansatz oder prozeßorientierter Ansatz) bildet die Anforderungen der realen Welt in eine funktionsorientierte Modellwelt ab, indem eine Aufgabe - zusammen mit ihren Eingabedaten und Ausgabedaten - systematisch solange in Teilaufgaben ("Funktionen") zerlegt wird, bis so präzise Beschreibungen der realen Welt entstehen, die letztlich in ein Anwendungsprogramm umgesetzt werden können. Der datenorientierte Ansatz (auch: Datenflußmethode) bildet die Anforderungen der realen Welt als Datenstruktur (Datenobjekte und Beziehungen zwischen den Datenobjekten), also in eine datenorientierte Modellwelt der Aufgabe ab. Die Datenstruktur wird solange verfeinert, bis sie in ein physisches Datenmodell für die betreffende Aufgabe umgesetzt werden kann. Der Objekttypen-Ansatz ist eine spezielle Ausprägung des datenorientierten Ansatzes. Er bildet die im Sachziel

ZAMSP

- Ziel, Aufgaben

und Methodik

der Systemplanung

27

der Systemplanung beschriebene Aufgabe als "elementare Objekttypen" (von Daten) und als "komplexe Objekttypen" (von Daten) ab, stellt anschließend den "Strukturzusammenhang" zwischen den Objekttypen her und ergänzt diesen Entwurf mit der Festlegung der Attribute zu den Objekttypen. Wesentliche Schwäche dieser Ansätze ist die Tatsache, daß sie entweder primär funktionsorientiert oder primär datenorientiert vorgehen. Zur Modellierung einer Aufgabe sind aber beide Sichten von gleicher Bedeutung; sie müßten idealerweise in einem Ansatz berücksichtigt werden. (Die Vorteilhaftigkeit des datenorientierten Ansatzes wird in Lerneinheit VGROB begründet.) Der objektorientierte Ansatz ist die Integration des funktionsorientierten mit dem datenorientierten Ansatz. Er verwendet als zentrale Entwurfskomponenten Objekte in Form "gekapselter" Methoden und Daten. Der objektorientierte Ansatz wird seit Mitte der 80-er Jahre diskutiert; er gewinnt zunehmend an Bedeutung (vgl. Lerneinheit OBOSP). Logische Modelle sind Systemabbildungen, die vollständig von einer bestimmten Form der Implementierung abstrahieren; sie haben keine physischen Attribute. Physische Modelle sind Systemabbildungen, die eine bestimmte Form der Implementierung zum Gegenstand haben; sie sind also mit physischen Attributen belegt. Bei der Systemanalyse wird zunächst der Istzustand erhoben und als physisches Modell abgebildet. Im Verlauf der Systemanalyse werden die physischen Attribute sukzessiv entfernt, sodaß ein logisches Modell des Istzustands entsteht. Das logische Modell des Istzustands wird dann bei der Systementwicklung zunächst in ein logisches Modell des Sollzustands überführt, das dann sukzessiv mit physischen Attributen einer bestimmten Implementierung belegt wird, sodaß das physische Modell des Sollzustands entsteht. Abbildung ZAMSP-2 veranschaulicht den "Weg vom physischen Modell des Istzustands zum physischen Modell des Sollzustands", der über die logischen Modelle des Istzustands und des Sollzustands führt.

Vorstudie

Feinstudie

Grobprojektierung

Feinprojektierung

Abb. ZAMSP-2: Der Weg zum logischen und zum physischen Modell

28

Grundlagen der

Systemplanung

Der prototyp-orientierte Ansatz umfaßt eine Reihe von Vorgehensvarianten (wie exploratives, experimentelles und evolutionäres Prototyping). Im Mittelpunkt des Ansatzes steht der Prototyp im Sinn einer schnell verfügbaren Vorabversion des zu schaffenden Produkts. Er durchläuft kurze Planungszyklen, die jeweils Analyse-, Entwurfs- und Entwicklungsaktivitäten, einschließlich der Bewertung durch die Benutzer, umfassen. Bei der Bewertung steht die Funktionalität (und nicht die Leistung) im Vordergrund (vgl. Lerneinheit PROTY). Paradigma der Systemplanung Aus der Darstellung der Methodikansätze ist ersichtlich, daß ihnen das Denken in Modellen zugrunde liegt und daß - daraus folgend - das Verwenden von Modellen für die Systemplanung typisch ist. Die Notwendigkeit zum Denken in Modellen und zum Verwenden von Modellen folgt aus der Tatsache, daß die betriebliche Wirklichkeit so komplex und kompliziert ist, daß sie ohne Vereinfachung nicht erfaßt und gestaltet werden kann. Diese Notwendigkeit ergibt sich auch aus der Tatsache, daß an größeren IuK-Projekten in der Regel mehrere Personen beteiligt sind (vgl. Lerneinheit AUTER), die meist unterschiedliche Sichten auf die gleichen Phänomene der Wirklichkeit haben, die offengelegt und zum Ausgleich gebracht werden müssen. Dies ist nur möglich, wenn die unterschiedlichen Sichten auf die Wirklichkeit in Modellen vereinfachend abgebildet werden. Ein wesentliches Merkmal der Methodik der Systemplanung ist daher ihre Modellorientierung. Die verschiedenen Methodikansätze müssen zu einem Methodik-Mix als Planungsmethodik kombiniert werden. Welchem Methodik-Mix der Vorzug gegeben wird, hängt vom Planungskontext ab und ist auch eine Frage der persönlichen Präferenzen der an einem IuK-Projekt beteiligten Aufgabenträger. Erfahrungsgemäß folgt die Planungsmethodik primär einem systemtechnisch orientierten Phasenmodell; alle anderen Methodikansätze, die verwendet werden, lassen sich in das Phasenmodell einordnen. Die vorherrschende Methodik der Systemplanung (ihr Paradigma) ist eine schrittweise präzisierende, systematisch auf Zwischenergebnissen aufbauende und doch möglichst ganzheitliche Vorgehensweise, eine Folge von aufeinander aufbauenden Planungszyklen. Sie ist mit dem Stockwerk für Stockwerk, vom Rohbau bis zur Fertigstellung und im Rahmen eines Gesamtentwurfs ablaufenden Bau eines Hauses vergleichbar. Daß dieses Paradigma unzulänglich ist, liegt auf der Hand. Ansätze zu seiner Überwindung sind nicht bekannt. Aus heutiger Sicht ist eine Planungsmethodik am zweckmäßigsten, die folgende Merkmale miteinander vereinigt: • die Verwendung eines aus dem Phasenschema abgeleiteten Vorgehensmodells; • das Entwerfen einer Grundkonzeption als konzeptuelles Modell, von dem ausgehend eine schrittweise Verfeinerung erfolgt; • die Orientierung am Systemansatz; • die konsequente Unterscheidung zwischen logischen und physischen Modellen; • die Datenorientierung oder - wo möglich - die Objektorientierung; • das Prototyping.

ZA MSP - Ziel, Aufgaben und Methodik der Systemplanung

29

Methoden, Techniken und Werkzeuge Mit dem Einsatz von M e t h o d e n und T e c h n i k e n der Systemplanung soll in erster Linie die Planungsmethodik umgesetzt und damit die Erreichung der Ziele der Systemplanung unterstützt werden, beispielsweise: • • • •

die Erreichung der geplanten Qualität der Planungsergebnisse; die Schaffung der Transparenz des Planungsprozesses; die Einhaltung von geplanten Terminen und Kosten; die Unabhängigkeit der Planungsergebnisse von den an der Planung beteiligten Personen; • die Wirksamkeit und die Wirtschaftlichkeit im Umgang mit den Planungsressourcen; • die Akzeptanz der Planungsergebnisse durch Auftraggeber und Benutzer.

Die zur Erreichung dieser Ziele wünschenswerten, in der Regel aber heute nicht oder nicht vollständig vorhandenen Eigenschaften der Methoden und Techniken sind: formaler Ansatz, Methoden- und Werkzeugintegration, Problemadäquanz, Durchgängigkeit und Beherrschbarkeit. Da viele Methoden und Techniken manuell nur umständlich, bei größeren IuK-Projekten teilweise überhaupt nicht anwendbar sind, werden sie in W e r k z e u g e n implementiert (vgl. Lerneinheit WERSP); diese sollen die Wirksamkeit und Wirtschaftlichkeit der Verwendung von Methoden und Techniken wesentlich verbessern bzw. ermöglichen. Systemplanung und Informationsmanagement Charakteristisch für die Systemplanung ist die Betrachtung von einzelnen Unternehmensteilen, herkömmlicherweise primär funktionsorientiert (wie z.B. Personalwesen, Produktionsplanung und -Steuerung, Vertrieb), neuerdings primär prozeßorientiert (wie z.B. Logistik), für die ein IuK-System geschaffen werden soll. Charakteristisch für die Systemplanung ist weiter, daß sie immer projektorientiert ist. Charakteristisch für das Informationsmanagement ist die unternehmensweite, ganzheitliche Orientierung; für das Unternehmen als Ganzes soll eine Informationsinfrastruktur geschaffen (unter anderem durch die IuK-Projekte der Systemplanung), aufrechterhalten und genutzt werden. Die ganzheitliche Betrachtung erfordert auch die Berücksichtigung der informationswirtschaftlichen Phänomene im Umsystem des Unternehmens. Aus der Charakteristik der Systemplanung und des Informationsmanagements ergibt sich bezüglich ihres Zusammenhangs folgendes: Die Systemplanung vollzieht sich in einem durch das Informationsmanagement vorgegebenen Handlungsspielraum; sie ist das Instrument, mit dem die Ziele des Informationsmanagements in IuK-Systeme umgesetzt werden. Abbildung ZAMSP-3 veranschaulicht diesen Zusammenhang. Die als "Planungsziele" und als "Planungsergebnisse" bezeichneten Schnittstellen zwischen dem strategischen Informationsmanagement und der Systemplanung einerseits, sowie zwischen der Systemplanung und der Informationsinfrastruktur andererseits, können wie folgt beschrieben werden: • Schnittstelle Planungsziele: Nach dem Festlegen der strategischen Ziele und dem Entwickeln von Strategien zur Planung der Informationsinfrastruktur

30

Grundlagen der Systemplanung

wird im Zuge der strategischen Maßnahmenplanung festgelegt, welche IuKSysteme mit welchen Funktionen und Leistungen (Sachziele) in welcher Zeit, mit welchen Kosten, mit welcher Qualität usw. (Formalziele) durch die Systemplanung zu realisieren sind. (Einzelheiten dazu finden sich in den Lerneinheiten SACHZ und FORMZ.) • Schnittstelle Planungsergebnisse: Nach dem Abschluß aller Vorbereitungsarbeiten zur Installierung werden die durch die Systemplanung geschaffenen Produkte so in die bestehende Informationsinfrastruktur eingefügt, daß sie produktiv genutzt werden können. (Einzelheiten dazu finden sich in Lerneinheit DURIN im Band 2 "Systemplanung".)

Planungsergebni sse Abb. ZAMSP-3: Zusammenhang zwischen Systemplanung und Informationsmanagement

Kennzeichnend für beide Schnittstellen ist die enge Zusammenarbeit zwischen dem Informationsmanagement und der Systemplanung. Das Erarbeiten des Projektportfolios durch das Informationsmanagement ist ohne Durchführung der Vorstudie (vgl. Kapitel "Der Prozeß der Vorstudie") nicht möglich; erst durch die Vorstudie können Aussagen über die Kosten und den Nutzen von neuen IuKSystemen gewonnen werden. Die Beurteilung installierter IuK-Systeme als "produktiv" kann nicht den Systemplanern allein überlassen werden; sie erfordert die Zusammenarbeit mit den Aufgabenträgern des Informationsmanagements. Forschungsbefunde H. G. Penzel versucht, durch systematisches Vorgehen zu klären, welche Entwurfsmethoden Alternativen sind, welche sich ergänzen und in welcher Folge sie im Rahmen des Phasenmodells der Systemplanung eingesetzt werden können. Dies geschieht auf der Grundlage einer Reihe von Methodenmerkmalen, die allen Methoden gemeinsam sind, die jedoch bezüglich ihrer Ausprägung ("Merkmalswerte") unterschiedlich sein können. Bekannte Entwurfsmethoden werden daraufhin untersucht, welche Merkmalswerte ihnen zuzuordnen sind, womit eine Beantwortung der Fragen möglich ist, welche Entwurfsmethoden sich ergänzen und welche Alternativen sind. Ausgangspunkt für die Beantwortung der Frage, in

ZAMSP - Ziel, Aufgaben

und Methodik

der Systemplanung

31

welcher Folge die Entwurfsmethoden im Phasenmodell eingesetzt werden können, ist es festzustellen, welche Anforderungen die Phasen des Entwurfsprozesses an die Merkmalswerte stellen, damit eine optimale Zuordnung von Entwurfsmethoden auf Entwurfsphasen ermöglicht wird. Diese und ähnliche Befunde müssen bei der Konstruktion eines Vorgehensmodells berücksichtigt werden. Kontrollfragen 1. 2. 3. 4. 5.

Wie können die Ziele der Systemplanung gegliedert werden? Welche Phasen der Systemplanung werden nach dem hier verwendeten Phasenmodell unterschieden? Welche Ziele werden in welchen Phasen der Systemplanung verfolgt? Was wird unter "Methodik der Systemplanung" verstanden? Warum gibt es nicht "eine" Methodik der Systemplanung, die lediglich von einem der möglichen Methodikansätze ausgeht?

Quellenliteratur Haberfellner, R.: Organisationsmethodik. In: Grochla, E. (Hrsg): Handwörterbuch der Organisation. 2. A „ Poeschel Verlag, Stuttgart 1980, 1701 - 1710 Heinrich, L. J.: Zur Methodik der Systemplanung in der Wirtschaftsinformatik. In: Schult, E. und Siegel, Th. (Hrsg.): Betriebswirtschaftslehre und Unternehmenspraxis. Schmidt Verlag, Berlin 1986, 83 - 99 Heinrich, L. J.: Der Prozeß der Systemplanung und -entwicklung. In: Kurbel, K. und Strunz, H. (Hrsg.): Handbuch der Wirtschaftsinformatik. Poeschel Verlag, Stuttgart 1989, 199 - 214 Heinrich, L. J.: Informationsmanagement. Planung, Überwachung und Steuerung der Informationsinfrastruktur. 5. A., Oldenbourg Verlag, München/Wien 1996 Heinrich, L. J. und Roithmayr, F.: Wirtschaftsinformatik-Lexikon. 5. A., Oldenbourg Verlag, MünchenAVien 1995 Vertiefungsliteratur Fitzgerald, J. et al.: Fundamentals of Systems Analysis. 2. Ed., John Wiley & Sons, N e w York et al. 1981 Hice, G. F. et al.: System Development M e t h o d o l o g y . North Holland Publishing C o m p a n y , Amsterdam et al. 1979 Olle, T. W . et al.: Information Systems Methodologies. A Framework for Understanding. 2. Ed., Addison-Wesley, W o k i n g h a m e t al. 1991 Penzel, H. G.: Ein systematischer Vergleich von Entwurfsverfahren für betriebliche Informationssysteme. Dissertation Universität Mainz, Mainz 1983

SYSTE - Systemtechnik und Systemplanung Lernziele Sie kennen das Ziel und die Arbeitsprinzipien der Systemtechnik. Sie können die systemtechnische Planungsmethodik beschreiben. Sie können für die Problemlösungsstufen der Planungsmethodik geeignete Methoden angeben. Sie erkennen die Bedeutung der Systemtechnik für die Methodik der Systemplanung. Definitionen und Abkürzungen Empfindlichkeitsanalyse (sensibility analysis) = eine Methode, mit der die Wirkung geringfügiger Änderungen der Parameter auf das prognostizierte Ergebnis ermittelt wird. Hierarchie (hierarchy) = eine Systembeziehung mit der elementespezifischen Zuordnungsvorschrift "Element A ist Element B über- bzw. untergeordnet". Komplexität (complexity) = der Zustand eines Systems, der durch die Anzahl unterscheidbarer Relationen zwischen seinen Teilsystemen beschrieben wird. Kybernetik (cybernetics) = eine Interdisziplin, die sich mit der Beschreibung und Erklärung von dynamischen (kybernetischen) Systemen beschäftigt, deren gemeinsames Kennzeichen das Prinzip der Regelung und Steuerung durch Aufnahme, Verarbeitung und Übertragung von Information ist. Modelltyp (model type) = die Art der Darstellung des Strukturkonzepts eines Modells (z.B. physikalisches, mathematisches, graphisches Modell). Prinzip (principle) = eine Regel oder eine Richtschnur für das Denken, Handeln und/oder Verhalten. Synonym: Grundsatz. Prognose (forecasting) = die Voraussage einer zukünftigen Entwicklung auf der Grundlage systematisch ermittelter Daten. Prüfliste (checklist) = eine Methode zur Überprüfung von Systemeigenschaften, deren Zweck es ist, Stärken und Schwächen aufzudecken. Regelung (feedback control) = eine Maßnahme, welche die Einhaltung eines systemextern definierten Zielzustands eines Systems durch systeminterne Eingriffe ermöglicht. Regressionsanalyse (regression analysis) = eine Methode zum Messen von Zusammenhängen zwischen metrisch skalierten Variablen. Steuerung (control) = eine Maßnahme, welche die Einhaltung eines systemextern definierten Zustands durch systemexteme Eingriffe ermöglicht. System (system) = der ganzheitliche Zusammenhang von Teilen, Einzelheiten, Dingen oder Vorgängen, die voneinander abhängig sind, ineinandergreifen oder zusammenwirken. Systemtechnik (systems engineering) = eine auf bestimmten Denkmodellen und Prinzipien beruhende Vorgehensweise zur zweckmäßigen und zielgerichteten Gestaltung komplexer Systeme. Teilsystem (subsystem) = das Ergebnis der Zerlegung eines Systems nach einer bestimmten Zerlegungsprozedur (Teilsystembildung); z.B. ein Teilprojekt. Übersystem (upper system) = die Zusammenfassung mehrerer Systeme zu einem System.

SYSTE - Systemtechnik und Systemplanung

Prinzipien der

33

Systemtechnik

Systemtechnik ist eine auf bestimmten Prinzipien beruhende Vorgehensweise zur zweckmäßigen und zielgerichteten Gestaltung komplexer Systeme. Ziel der Systemtechnik ist die Reduktion der Komplexität bei der mehrdimensionalen, zielorientierten Analyse, Konzipierung, Auswahl und Realisierung von Systemen. Die vier Prinzipien der Systemtechnik ergänzen einander in ihrer Problemlösungsfunktion und werden daher in der Regel zusammen angewendet. • Das Prinzip der hierarchischen Strukturierung geht von der Erkenntnis aus, daß die Untersuchung komplexer Systeme schwierig, wenn nicht unmöglich ist, und daß ihre Komplexität durch Zerlegung in Teilsysteme reduziert werden kann. Die Zerlegung in Teilsysteme erfolgt stufenweise "von oben nach unten" in Form einer Hierarchie. "Zerlegen" bedeutet also Abgrenzen eines Teilsystems von einem direkt nachgeordneten oder direkt übergeordneten Teilsystem und Definieren der Beziehungen zwischen den Teilsystemen. Das Zerlegen soll so erfolgen, daß die Teilsysteme bezüglich der verfolgten Ziele möglichst homogen sind. • Das Prinzip des Schwarzen Kastens (auch: Black-Box-Prinzip) empfiehlt, bei der Untersuchung eines Systems von den Vorgängen innerhalb des Systems zu abstrahieren und sich auf die wirkungsspezifischen Eingänge und Ausgänge an den Systemgrenzen, also auf die Vorgänge zwischen dem betrachteten System und seiner Umwelt ("Umsystem") zu konzentrieren. Von der Kenntnis der System/Umwelt-Beziehungen wird auf Systemeigenschaften geschlossen. Da klare Systemgrenzen nur selten vorgegeben sind, müssen sie erarbeitet werden. Dieser Prozeß kann als das Suchen nach einem Optimum verstanden werden, bei dem die positiven Konsequenzen (insbes. Reduzierung der Anpassungskosten) und die negativen Konsequenzen (insbes. Erhöhung der Planungsund Realisierungskosten) der Erweiterung gegeneinander abgewogen werden. • Das kybernetische Prinzip fordert die Anwendung der Grundsätze der Regelung und Steuerung als spezifische Form des Verhaltens eines Systems. Damit soll der Systemzweck auch unter Störeinwirkungen erreicht oder beibehalten, das System also "im Gleichgewicht gehalten" werden. • Das Modell-Prinzip empfiehlt, ein System in ein Modell abzubilden und anhand des Modells zu untersuchen. Dazu werden verschiedene Modelltypen verwendet. Für die Systemplanung ist das graphische Modell (z.B. als EntityRelationship-Modell zur Modellierung des Datensystems) von besonderer Bedeutung (vgl. Lerneinheit ERMOD). Systemtechnische

Planungsmethodik

Die systemtechnische Planungsmethodik ist die logische Schrittfolge zur Erarbeitung von Problemlösungen. Sie orientiert sich einerseits an der Notwendigkeit einer wirtschaftlichen Problemlösung, indem mehrere Systemphasen bei der Lösungserarbeitung voneinander abgegrenzt werden. Andererseits werden verschiedene Problemlösungsstufen innerhalb der Systemphasen unterschieden, die sich an der Struktur kognitiver Prozesse der Informationsverarbeitung orientieren. Abbildung S Y S T E - 1 zeigt die Grundstruktur des systemtechnischen Planungsprozesses.

34

Grundlagen der

Systemplanung

USW.

Abb. SYSTE-1: Grundstruktur des systemtechnischen Planungsprozesses (Quelle: Zangemeister)

Abb. SYSTE-2: Typische Systemphasen im Zeitablauf (Quelle: Zangemeister)

Abbildung SYSTE-2 zeigt die typischen Systemphasen im Zeitablauf; sie können wie folgt erläutert werden: • In der Systemphase 1 Programmstudie werden die generell angestrebten Ziele und die antizipierten Lösungskonzepte eines Systemproblems festgelegt.

SYSTE - Systemtechnik

und

Systemplanung

35

• Gegenstand der Systemphase 2 Systemvorstudie ist die Analyse der technisch-organisatorischen Durchführbarkeit und der Wirtschaftlichkeit alternativer Lösungskonzepte. Die Menge der weiter zu untersuchenden Lösungskonzepte wird reduziert. • In der Systemphase 3 Systemhauptstudie erfolgt die Auswahl der optimalen Lösungsalternative und deren detaillierter Entwurf. • Die Systemphase 4 Systemerstellung umfaßt die überwiegend materielle Systemgestaltung. • In der Systemphase 5 Systemeinführung erfolgt die Installierung der optimalen Lösungsvariante und deren Inbetriebnahme. • Die Systemphase 6 Systembetrieb umfaßt auch die Pflege und Verbesserung eines eingeführten Systems. • Zweck der Systemphase 7 Systemwechsel ist der planmäßige Austausch eines Systems durch ein verbessertes System. Zwischen den Phasen 1 und 2, 2 und 3 sowie 3 und 4 sind Meilensteine festgelegt, die sicherstellen sollen, daß voraussichtlich nicht erfolgreiche Vorhaben abgebrochen werden.

Abb. SYSTE-3: Problemlösungsstufen im systemtechnischen Planungsprozeß (Quelle: Zangemeister)

Ziele und Methoden der Problemlösungsstufen Innerhalb der einzelnen Systemphasen erfolgt die Problembearbeitung nach drei Problemlösungsstufen, die aus Abbildung SYSTE-3 mit ihren stufenspezifischen Bearbeitungsschritten ersichtlich sind. Abbildung SYSTE-3 zeigt auch, daß die Problemlösungsstufen bzw. ihre einzelnen Bearbeitungsschritte durch Rückkopp-

36

Grundlagen der Systemplanung

lungen miteinander vernetzt sind. Die in Abbildung SYSTE-3 gezeigten Problemlösungsstufen des systemtechnischen Planungsprozesses werden nachfolgend anhand ihrer Ergebnisse und Methoden erläutert. • Zustandsanalyse: Es liegen Informationen zur problemspezifischen Situation vor. Eine Abgrenzung der Bereiche, in denen Zustandsänderungen durch problemlösende Maßnahmen erreicht werden können, ist möglich. Neben den systemtechnischen Arbeitsprinzipien können Methoden der Istzustandserfassung (vgl. Lerneinheit ISTER), Methoden der Istzustandsanalyse (vgl. Lerneinheit ISTAN), Prognosemethoden, Regressionsanalysen und Kreativitätstechniken (vgl. Lerneinheit KREAT) angewendet werden. • Problemdefinition (Zielbildung): Es ist möglich, Aussagen darüber zu machen, was mit der Problemlösung im einzelnen erreicht werden kann und welche Schwierigkeiten dem entgegenstehen. Es handelt sich um die Analyse des Spannungsverhältnisses zwischen dem Istzustand und dem angestrebten Sollzustand. Dafür werden Ursachenanalyse, Zielbaumverfahren und Kreativitätstechniken (vgl. Lerneinheit KREAT) angewendet. • Konzeptentwurf (Systemsynthese): Mehrere alternative Problemlösungen liegen vor. Zur Generierung von Problemlösungen können Kreativitätstechniken (vgl. Lerneinheit KREAT) angewendet werden. • Konzeptanalyse (Systemanalyse): Die zielrelevanten Konsequenzen (Zielerträge) der alternativen Problemlösungen sind bekannt. Zu ihrer Ermittlung können Prognosemethoden und Simulationsmodelle (vgl. Lerneinheit SIMUL) angewendet werden. • Bewertung (Nutzwertanalyse): Die unter Kosten/Nutzen-Aspekten optimale Problemlösung ist bekannt. Eindimensionale Bewertungsmethoden (Investitionsrechnungsmethoden, vgl. Lerneinheit WIRTA), mehrdimensionale Bewertungsmethoden (Nutzwertanalyse, vgl. Lerneinheit NUTZW) und die Delphi-Methode können zur Unterstützung herangezogen werden. • Auswahlentscheidung: Es steht fest, welche der alternativen Problemlösungen optimal ist und den nachfolgenden Systemphasen zugrunde gelegt wird. Zur Auswahl können Entscheidungstabellen (vgl. Lerneinheit ENTAB), Abstimmregeln und Empfindlichkeitsanalysen angewendet werden. • Ausarbeitung (Entwicklungsplanung): Es ist bekannt, wie die optimale Problemlösung im Detail aussieht. Methoden zur Unterstützung der Entwicklungsplanung sind Prüflisten (vgl. Lerneinheit ANIST) und Netzplantechnik (vgl. Lerneinheit NETZP). • Ausführungsplanung: Die Maßnahmen zur Durchführung der Planungsergebnisse sind bekannt. Methoden zur Unterstützung der Ausführungsplanung sind Prüflisten und Netzplantechnik. Zusammenfassend betrachtet, verlaufen systemtechnisch orientierte Planungsprozesse wie in Abbildung SYSTE-4 dargestellt. Wie die Pfeile in den Feldern der Matrix andeuten, ist die Abbildung zeilenweise zu interpretieren.

Programmstudie

A n » »

Systemvorstudie Systemhauptstudie Systemerstellung

A21*—

•— •> A32 »>-

—

•

•—

—

•

—

- » A21

—

—

•

—

— > A32

•—

— • —

->A

37

Ausführungsplanung

Ausarbeitung (Entwicklungsplanung)

Auswahlentscheidung

Bewertung (Nutzwertanalyse)

und Systemplanung

4 2

> aS2

Systemeinführung Systembetrieb Systemwechsel

•— •— •—

Konzeptanalyse (Systemanalyse)

Phasen

Konzeptentwurf (Systemsynthese)

ProblemlösungsN. stufe

Problemdefinition (Zielbildung)

N.

Zustandsanalyse

SYSTE - Systemtechnik

A 7 1 » »

•— •—

— —

• •

— —

— —

• •

—

— •

—

•

—

—>A7I

—

— •

—

•

—

— > A n

Abb. SYSTE-4: Aktivitätenorientierte Planungsmorphologie systemtechnischer Problemlösung (Quelle: Zangemeister)

Demonstrationsbeispiel Es wird die Orientierung der Methodik der Systemplanung am Systemansatz (vgl. Lerneinheit ZAMSP) durch Gegenüberstellung der Phasen der systemtechnischen Vorgehensweise (Abbildung SYSTE-5, linker Teil) mit denen des Phasenschemas der Systemplanung (Abbildung SYSTE-5, rechter Teil) gezeigt. Die dem Systembetrieb und dem Systemwechsel der systemtechnischen Vorgehensweise entsprechende Nutzung und Wartung sowie die Neukonstruktion am Ende des Lebenszyklus von IuK-Systemen werden als nicht zum Phasenschema der Systemplanung gehörend betrachtet; sie sind dem Anwendungssystem-Management zugeordnet (vgl. Lerneinheit LEMAN im Band "Informationsmanagement"). Programmstudie

Vorstudie

Systemvorstudie

Feinstudie

Systemhauptstudie

Grobprojektierung

Systemerstellung

Feinprojektierung

Systemeinführung

Installierung

Systembetrieb Systemwechsel

Nutzung, Wartung und Neukonstruktion

Abb. SYSTE-5: Zuordnung der Phasen der systemtechnischen Vorgehensweise zum Phasenschema der Systemplanung

38

Grundlagen der Systemplanung

Kontrollfragen 1. 2. 3. 4. 5.

Worin besteht das Ziel der Systemtechnik? Welches sind die Arbeitsprinzipien der Systemtechnik? Welche Phasen des systemtechnischen Planungsprozesses werden unterschieden? In welche Problemlösungsstufen kann eine Systemphase zerlegt werden? Welche Unterschiede bestehen zwischen den Phasen der systemtechnischen Vorgehensweise und dem Phasenschema der Systemplanung?

Quellenliteratur Zangemeister, Ch.: Systemtechnik. In: Grochla, E. (Hrsg.): Handwörterbuch der Organisation. 2. A., Poeschel Verlag, Stuttgart 1980,2190 - 2204 Vertiefungsliteratur Daenzer, W. F. (Hrsg.): Systems Engineering. Leitfaden zur methodischen Durchführung umfangreicher Planungsvorhaben. 6. A., Hanstein Verlag, Köln und Verlag Industrielle Organisation, Zürich 1988 Zangemeister, Ch.: Nutzwertanalyse in der Systemtechnik. 4. A., Wittemann'sche Verlagsbuchhandlung, München 1976

PROSP - Prozeß der Systemplanung Lernziele Sie können die Aufgabe der Systemplanung in Teilaufgaben gliedern und diese zu Phasen ordnen. Sie können die wichtigsten Aufgaben der einzelnen Phasen der Systemplanung angeben. Sie sind in der Lage, den Input und den Output jeder Phase zu beschreiben. Sie erkennen den Prozeßcharakter der Systemplanung und können die konstitutiven Merkmale dieses Arbeitsprozesses erläutern. Definitionen und Abkürzungen Feinprojektierung (detailed systems design) = die Phase der Systemplanung, deren Zweck die Überführung des logischen Modells des Sollzustands in ein physisches Modell des Sollzustands ist. Synonyme: Systementwicklung, Systemimplementierung. Feinstudie (detailed systems study) = die Phase der Systemplanung, deren Zweck die Anpassung der Grundkonzeption aufgrund einer Untersuchung (Erhebung und Analyse) des Istzustands ist. Synonyme: Istzustandsuntersuchung, Detailstudie. Grobprojektierung (general systems design) = die Phase der Systemplanung, deren Zweck die Überführung der (angepaßten) Grundkonzeption in ein logisches Modell des Sollzustands ist. Synonym: Systementwurf. Grundkonzeption (preliminary design) = der umrißartige, grobe Entwurf des zu schaffenden IuK-Systems anhand seiner wichtigsten Eigenschaften, der das IuK-System auf einer globalen Ebene möglichst vollständig beschreibt, die Realisierungswege im einzelnen aber offen läßt. Installierung (installation) = die Phase der Systemplanung, deren Zweck die Überführung des physischen Modells des Sollzustands in ein produktives IuKSystem ist. Synonym: Systemeinführung. Kooperation (Cooperation) = ein sozialer Prozeß zwischen mehreren Aufgabenträgem zur Erreichung gemeinsamer Ziele. Koordination (coordination) = die Abstimmung der Tätigkeiten verschiedener Aufgabenträger, die kooperativ zusammenarbeiten. Kreativität (creativity) = die Fähigkeit des Menschen, schöpferisch zu sein, eigene Ideen entwickeln zu können, einfallsreich und erfinderisch zu sein. physisches Modell (physical model) = eine Systemabbildung, die mit physischen Attributen belegt ist. Planungsziel (planning goal) = ein Ziel, das der Systemplanung vom strategischen Informationsmanagement vorgegeben ist. Projektziel (project goal) = ein Ziel, das zur Planung, Überwachung und Steuerung eines IuK-Projekts verwendet und aus den Planungszielen abgeleitet wird. Vorstudie (initial study) = die Phase der Systemplanung, deren Zweck der Entwurf der Grundkonzeption ist, die aus mehreren alternativen Systemkonzepten als die optimale bestimmt wurde. Synonyme: Grobstudie, Voruntersuchung, Durchführbarkeitsstudie, Machbarkeitsstudie.

40

Grundlagen der Systemplanung

Phasenschema der Systemplanung Die generelle Aufgabe der Systemplanung, dem Anwender ein produktives IuKSystem zur Verfügung zu stellen, wurde entsprechend der Aufgabenanalyse in Teilaufgaben zerlegt und entsprechend der Aufgabensynthese wieder zu Aufgaben zusammengefaßt, die auch als Phasen bezeichnet werden. Ergebnis dieser analytischen und synthetischen Tätigkeiten ist das Phasenschema (auch: Phasenmodell) der Systemplanung (vgl. Lerneinheit ZAMSP) mit folgenden Aufgaben oder Phasen: • • • • •

erste Aufgabe der Systemplanung: Vorstudie; zweite Aufgabe der Systemplanung: Feinstudie; dritte Aufgabe der Systemplanung: Grobprojektierung; vierte Aufgabe der Systemplanung: Feinprojektierung; fünfte Aufgabe der Systemplanung: Installierung.

Vorstudie und Feinstudie werden im allgemeinen unter der Bezeichnung Systemanalyse (weil es sich dabei vornehmlich um analysierende Tätigkeiten handelt), Grobprojektierung und Feinprojektierung unter der Bezeichnung Systementwicklung (weil es sich dabei vornehmlich um Entwurfs- und letztlich um Entwicklungstätigkeiten handelt) zusammengefaßt. Die Ziele und die (Teil-) Aufgaben der Phasen werden an anderer Stelle erläutert (vgl. Lerneinheiten ZAMVS, ZAMFS, ZAMGP, ZAMFP und ZAMIN), und es wird auf die Methoden und Techniken zur Unterstützung der Aufgabendurchführung eingegangen. Zum besseren Verständnis des Phasenschemas wird nachfolgend eine Kurzbeschreibung der Aufgaben der Phasen gegeben. Aufgaben der Phasen Aufgaben der Vorstudie (auch Grobstudie, Voruntersuchung, Durchführbarkeitsstudie oder Machbarkeitsstudie genannt) sind: • das Festlegen der Sachziele und der Formalziele ("Anforderungen"), ausgehend von den vorgegebenen Planungszielen (vgl. Lerneinheit SACHZ und Lerneinheit FORMZ); • das Entwerfen von alternativen Systemkonzepten und die Auswahl des optimalen Systemkonzepts als Grundkonzeption (vgl. Lerneinheit GRUND); • das Durchführen der Projektplanung (vgl. Lerneinheit PROPL). Aufgaben der auf dem Ergebnis der Vorstudie (Grundkonzeption) aufbauenden Feinstudie (auch Istzustandsuntersuchung oder Detailstudie genannt) sind: • das Erfassen des Istzustands ("Istzustandserfassung", vgl. Lerneinheit ERIST); • das Analysieren des Istzustands ("Istzustandsanalyse", vgl. Lerneinheit ANIST); • das Optimieren des Istzustands ("Istzustandsoptimierung") und das Anpassen der Grundkonzeption auf Grund der Ergebnisse der Istzustandsanalyse (vgl. Lerneinheit AFEIN).

PROSP - Prozeß der Systemplanung

41

Aufgaben der auf dem Ergebnis der Feinstudie (angepaßte Grundkonzeption) aufbauenden Grobprojektierung (auch Systementwurf oder logischer Modellentwurf genannt) sind: • das Strukturieren des in der Grundkonzeption abgebildeten Gesamtsystems in Teilprojekte ("Systemgliederung", vgl. Lerneinheit VGROB); • das Entwerfen des Sollkonzepts der Teilprojekte ("Systementwurf", vgl. Lerneinheiten WDASY, WMESY, WAORG, WTRAN und WSICH); • die Integration der Systementwürfe zu den Teilprojekten zum Gesamtsystem ("Systementwurfsintegration", vgl. Lerneinheit WINTE); • das Bestimmen des quantitativen und qualitativen Technikbedarfs für den Systementwurf ("Systemauswahl") und das Beschaffen der Techniksysteme (vgl. Lerneinheiten BTECH und PFLIC). Beim Strukturieren des in der Grundkonzeption abgebildeten Gesamtsystems in Teilprojekte hat sich die Systemgliederung in Datensystem, Methodensystem, Arbeitsorganisation, Transportsystem und Sicherungssystem als zweckmäßig erwiesen. Aufgaben der auf dem Ergebnis der Grobprojektierung (logisches Modell Sollzustand) aufbauenden Feinprojektierung (auch Systementwicklung oder Systemimplementierung genannt) sind: • das Entwickeln des Datensystems (vgl. Lerneinheit EDASY); • das Entwickeln des Methodensystems, insbesondere Software-Entwicklung (vgl. Lerneinheit EMESY); • das Entwickeln der Arbeitsorganisation, sowohl der Strukturorganisation als auch der Ablauforganisation (vgl. Lerneinheit EAORG); • das Entwickeln des Transportsystems (vgl. Lerneinheit ETRAN); • das Entwickeln des Sicherungssystems (vgl. Lerneinheit ESICH); • die Integration der Entwicklungsergebnisse der Teilprojekte zum Gesamtsystem ("Systementwicklungsintegration", vgl. Lerneinheit EINTE). Aufgaben der auf den Ergebnissen aller Planungsphasen, insbesondere auf dem Ergebnis der Feinprojektierung (physisches Modell Sollzustand) aufbauenden Installierung (auch Systemeinführung genannt) sind: • das Vorbereiten der Installierung (vgl. Lerneinheit VORIN); • das Durchführen der Installierung (vgl. Lerneinheit DURIN). Dabei hat sich eine Strukturierung der Vorbereitungsaufgaben in personelle, organisatorische, räumliche, gerätetechnische, programmtechnische und datentechnische Aufgaben als zweckmäßig erwiesen. Bei der Durchführung der Installierung stehen die Aufgaben im Vordergrund, die den Übergang vom Istzustand zum geplanten Sollzustand so bewirken, daß das installierte IuK-System produktiv verwendet werden kann; dies schließt seine Bewertung anhand der Planungsziele sowie, wenn Abweichungen bestehen, seine Anpassung ein.

42

Grundlagen der Systemplanung

Prozeßcharakter des Phasenschemas Das Phasenschema ist primär ein grober Ordnungsrahmen für die Aufgaben, für die Methodik und für die Methoden der Systemplanung. Für die praktische Anwendung stellt es eine wichtige Orientierung dar, die in mehrfacher Hinsicht präzisiert werden muß, zum Beispiel die Aufgabenplanung (d.h. die Festlegung der Art der Aufgaben, die durchzuführen sind, und des Aufgabenumfangs). Darüber hinaus sind die technologische Abhängigkeit zwischen den Aufgaben und der Zeitbedarf für die Durchführung der Aufgaben zu bestimmen. Erst auf der Grundlage dieser planenden, projektbezogenen Tätigkeiten kann der Prozeß der Systemplanung im Detail beschrieben werden (vgl. dazu Lerneinheit PROPL). Das Phasenschema kann also für die planenden, überwachenden und steuernden Tätigkeiten des Projektmanagements nicht unmittelbar verwendet werden. Es zeigt aber eine deutliche Prozeßorientierung, indem die Inputs (Voraussetzungen) und die Outputs (Ergebnisse, Meilensteine) der Phasen definiert werden und durch ihre Anordnung deutlich gemacht wird, welche Ergebnisse welcher Phasen Voraussetzung für welche anderen Phasen sind. Außerdem können im Phasenschema die wichtigsten Rückkopplungen angegeben werden. Abbildung PROSP-1 zeigt die prozeßorientierte Ordnung der Phasen der Systemplanung einschließlich ihrer Voraussetzungen bzw. Ergebnisse. Beispielsweise ist die G r u n d k o n z e p t i o n das Ergebnis der Vorstudie und die Voraussetzung für die Feinstudie. Mit anderen Worten: Die Durchführung der Feinstudie ist ohne den Abschluß der Vorstudie sinnlos. Damit wird aber nicht gesagt, daß die Grundkonzeption als das Ergebnis der Vorstudie "festgeschrieben" werden muß und unveränderlich ist. Dies gilt analog für die anderen Phasen der Systemplanung. Weiter: Beispielsweise ist das physische Modell des Sollzustands das Ergebnis der Feinprojektierung und die Voraussetzung für die Installierung. Dies heißt jedoch nicht, daß nicht bestimmte, vom Vorliegen des physischen Modells unabhängige Aufgaben der Installierung vor dem vollständigen Abschluß der Feinprojektierung bearbeitet werden können (z.B. die meisten Aufgaben der Vorbereitung der Installierung). Diese Beispiele verdeutlichen noch einmal die Notwendigkeit der Projektplanung auf der Grundlage des Phasenschemas. Aus diesen Darlegungen wird deutlich, daß eine dem Phasenschema folgende Systemplanung primär der Top-down-Strategie folgt, indem von globalen Projektzielen ausgehend "von oben abwärts" über die Analyse, den Entwurf und die Implementierung bis zur Installierung präzisierend fortgeschritten wird. Charakter des Planungsprozesses Der Prozeß der Systemplanung ist ein Arbeitsprozeß, in dem Systemplaner und Benutzer zusammenwirken müssen. Die Notwendigkeit dieses Zusammenwirkens ergibt sich aus der Tatsache, daß es den Systemplanern nicht möglich ist, die Anforderungen an die Gestaltung des zu schaffenden IuK-Systems allein aus der Beobachtung und Analyse des Istzustands zu gewinnen oder aus eigener Sachkenntnis einzubringen. Mit dem Zusammenwirken von Systemplanern und Benutzern wird die Trennung zwischen der Herstellung des IuK-Systems und der Benutzung des IuK-Systems aufgehoben. Da das Zusammenwirken zwischen Systemplanern und Benutzern zur Herstellung eines den Planungszielen entspre-

PROSP - Prozeß der Systemplanung

43

chenden, benutzbaren Produkts die gegenseitige Abstimmung erfordert, ist der Planungsprozeß durch Kooperation bestimmt. Daraus wird die Forderung abgeleitet, daß Werkzeuge der Systemplanung die Kooperation unterstützende Eigenschaften haben sollten (vgl. Lerneinheit AUTER).

Abb. PROSP-1: Der Prozeß der Systemplanung

Da Systemplanung immer darauf ausgerichtet ist, einen bestimmten Ausschnitt der Wirklichkeit betrieblicher Arbeit neu zu gestalten, ist das Produkt der Systemplanung zu Beginn des Planungsprozesses weitgehend unbekannt; es kann nur sukzessiv durch Planungsentscheidungen präzisiert werden. Viele dieser Planungsentscheidungen können nur auf der Grundlage geistig-schöpferisch geschaf-

44

Grundlagen der Systemplanung

fener Entwurfsalternativen gefällt werden, sodaß Kreativität - neben Kooperation - das zweite wesentliche Kennzeichen des Arbeitsprozesses Systemplanung ist (vgl. Lerneinheit KREAT). Systemplaner und Benutzer müssen dabei ihre Kenntnisse und Fähigkeiten verändern und vor allem erweitern, damit ihnen das Wissen "zuwächst", das sie zur Gestaltung eines neuen IuK-Systems benötigen ("Lernprozeß"). Kooperation und Kreativität können nur dann in ein Produkt umgesetzt werden, wenn die an einem IuK-Projekt Beteiligten ihre Handlungen koordinieren. K o o r d i n a t i o n kann aber nur stattfinden, wenn die Beteiligten über Möglichkeiten der Kommunikation verfügen. Kooperation, Kreativität, Koordination und Kommunikation sind die vier konstitutiven Merkmale des Prozesses der Systemplanung. Phasenschema und Vorgehensmodell Aus dem Phasenschema wird ein Vorgehensmodell, wenn die auszuführenden Tätigkeiten und die aus den Tätigkeiten entstehenden Resultate konkret beschrieben werden (Einzelheiten dazu in Lerneinheit WERSP). In das Vorgehensmodell können dann Methoden und Techniken und die sie unterstützenden Werkzeuge "eingehängt" werden. Das Vorgehensmodell ist universell, wenn es nur eine Grobstruktur der Tätigkeiten und Resultate und damit des Vorgehens vorgibt und dem Systemplaner die Verfeinerung, die situativ gewählt wird (z.B. in Abhängigkeit von dessen Qualifikation), überläßt. Für einzelne Teile des Systemplanungsprozesses gibt es verschiedene Methodikansätze (z.B. datenorientierter Ansatz versus funktionsorientierter Ansatz beim Systementwurf, vgl. Lerneinheit ZAMSP). Ein Vorgehensmodell kann verschiedene Teilmodelle für diese Ansätze anbieten, und je nach IuK-Projekt wird das Teilmodell gewählt, das besser "paßt". Ein weiterer Grund für die Verwendung von Teilmodellen statt eines geschlossenen Gesamtmodells ist, daß manche Aktivitäten so unabhängig voneinander sind, daß die entsprechenden Modellteile bei Bedarf ausgetauscht werden können. Benutzung und Wartung des Vorgehensmodells werden erleichtert, wenn statt eines "monolithischen Modells" Teilmodelle verwendet werden. Ein Vorgehensmodell ist daher in der Regel eine Kombination aus mehreren Teilmodellen. Ergebnis des Planungsprozesses Durch das generelle Sachziel der Systemplanung, ein "produktives IuK-System" zu schaffen, wird das Ergebnis des Planungsprozesses auch als ein P r o d u k t gekennzeichnet. Dieses Produkt kann in Kernprodukt, erwartetes Produkt, erweitertes Produkt und potentielles Produkt gegliedert werden. Abbildung PROSP-2 veranschaulicht die Produktstruktur als Schichtenmodell. • Das Kernprodukt stellt den Grundnutzen des Produkts dar, indem es die zur produktiven Verwendung unbedingt erforderlichen Funktionen und Leistungen bietet. In der Regel hat ein Standardprodukt (z.B. StandardAnwendungssoftware) die Eigenschaften eines Kernprodukts. • Das erwartete Produkt bietet über das Kernprodukt hinausgehende Funktionen und Leistungen. Erwartet ein Anwender über das Kernprodukt hinausgehende Funktionen und Leistungen, dann kommt es nur dann zur produkti-

PROSP - Prozeß der Systemplanung

45

ven Verwendung, wenn das Ergebnis der Systemplanung zumindest das erwartete Produkt ist. Ein Standardprodukt muß daher in der Regel um Funktionen und Leistungen ergänzt werden, um produktiv verwendbar zu sein. • Das erweiterte Produkt bietet Funktionen und Leistungen, die über das hinausgehen, was der Anwender erwartet, normalerweise braucht oder gewöhnt ist. Dabei handelt es sich meist nicht um Hauptfunktionen und deren Leistung, sondern um Nebenfunktionen und deren Leistung (vgl. Lerneinheit WERTA). • Das potentielle Produkt stellt die zukünftige Perspektive des Produkts dar, indem ohne grundlegende Änderung neue Funktionen und Leistungen zur Verfügung gestellt werden können.

Kernprodukt erwartetes Produkt erweitertes Produkt potentielles Produkt Abb. PROSP-2: Schichten eines IuK-Systems als Produkt (nach Lamprecht/Jackson)

Forschungsbefunde Platz/Schmelzer bezeichnen das Phasenschema ("Phasenorganisation", "Life-Cycle-Modell") als die logische Strukturierung des Projektablaufs, die auf dem technischen Prozeß der Systemplanung ("Systementwicklung") aufbaut und Einzelphasen mit definierten Ergebnissen ("Meilensteine") liefert. Die Phasenorganisation bildet die Grundlage für alle Fragen der Planung, Abwicklung und Steuerung in Projekten; sie ist damit die zentrale Festschreibung der Ablauforganisation des Projekts. Folgende Phaseneinteilung (in Klammem Ergebnis/Phaseninhalt) wird für F&E-Projekte verwendet: Vorphase (Lastenheft/Problembeschreibung, Auswahl des Vorhabens); Analysephase (Pflichtenheft/Problemanalyse, Projektzielsetzung); Konzeptphase (Leistungsbeschreibung/Erarbeiten des fachlichen Konzepts, Machbarkeitsuntersuchungen, Auswahl von Alternativen); Spezifikationsphase (Spezifikation, Design/Erarbeiten des technischen Gesamtkonzepts, Spezifikation der Komponenten); Entwicklungsphase (Prototyp Nullserie/Erstellen der Komponenten, Zusammenfügen der Komponenten, Test des Gesamtsystems); Herstellphase (Produkt/Serienreifmachen, Nullserie). Kontrollfragen 1. 2. 3. 4. 5.

Welches sind die fünf Aufgaben (Phasen) der Systemplanung? Wie können der Input und der Output jeder Phase beschrieben werden? Worin besteht der Unterschied zwischen logischem Modell und physischem Modell? Welche Eigenschaften bestimmen den Prozeßcharakter des Phasenmodells? Wie kann das Produkt der Systemplanung als Schichtenmodell beschrieben werden?

46

Grundlagen der Systemplanung

Quellenliteratur Heinrich, L. J.: Der Prozeß der Systemplanung und -entwicklung. In: Kurbel, K. und Strunz, H. (Hrsg.): Handbuch der Wirtschaftsinformatik. Poeschel Verlag, Stuttgart 1989,199 - 214 Lamprecht, M. und Jackson, I.: Strategische Planung des Informationsservice. In: Information Management 1/1989,28 - 35 Vertiefungsliteratur Avison, D. E. and Fitzgerald, G.: Information Systems Development - Methodologies, Techniques and Tools. Blackwell Scientific Publicatíons, Oxford et al. 1988 Chroust, G.: Modelle der Software-Entwicklung. Oldenbourg Verlag, München/Wien 1992 Platz, J . und Schmelzer, H. J.: Projektmanagement in der industriellen Forschung und Entwicklung - Einführung anhand von Beispielen aus der Informationstechnik. Springer Verlag, Berlin etal. 1986 Reisin, F.-M.: Kooperative Gestaltung in partizipativen Softwareprojekten. Verlag P. Lang, Frankfurt/M. et al. 1992

OBOSP - Objektorientierte Systemplanung Lernziele Sie kennen den Zweck, der mit der Objektorientierung verfolgt wird. Sie können die Merkmale der Objektorientierung bzw. des objektorientierten Ansatzes erläutern. Sie kennen Methoden der Objektorientierung und ihre Einordnung in die Methodik der Systemplanung. Sie erkennen die Notwendigkeit eines einheitlichen Beschreibungsmittels ("Notation") für die Methoden der Objektorientierung als Voraussetzung für die Erreichung des Zwecks der Objektorientierung. Definitionen und Abkürzungen Beziehung (relation) = der innere Zusammenhang und das wechselseitige Verhältnis zweier oder mehrerer Dinge (hier: Objektklassen) zueinander. Daten (data) = die Abbildung von Phänomenen der Wirklichkeit oder der Vorstellungswelt des Menschen, die nicht unmittelbar zweckorientiert ist. datenorientierter Ansatz (data-oriented approach) = eine Vorgehensweise, bei der der Entwurf der Daten und damit des Datensystems Ausgangspunkt des Systementwurfs ist. D O O P = Abkürzung für Design Method for Object-Oriented Programming. Funktion (function) = ein durch systematische Zerlegung entstandener Teil einer Aufgabe, im Grenzfall eine einzelne, nicht weiter zerlegbare Tätigkeit. Synonym (beim objektorientierten Ansatz): Methode, funktionsorientierter Ansatz (process-oriented approach) = eine Vorgehensweise, bei der der Entwurf der Funktionen und ihre Ordnung zu einem Prozeß oder Vorgang und damit der Entwurf des Methodensystems Ausgangspunkt des Systementwurfs ist. Synonym: ablauforientierter Ansatz, prozeßorientierter Ansatz. Schlußfolgern (inferencing) = das systematische Problemlösen mit den Methoden der mathematischen Logik. Methode (method) = im Sinn des objektorientierten Ansatzes ein Synonym für Funktion. Objekt (object) = ein Element (eine "Instanz") einer Objektklasse, das mit anderen Objekten über Nachrichten interagiert. Objektklasse (object class) = ein abstrakter Datentyp, der durch Variable ("Attribute") und Methoden ("Operatoren") beschrieben wird. Objektstruktur (object structure) = die vom Detail losgelöste, auf die wesentlichen statischen Merkmale eines Systems von Objekten reduzierte Darstellung, die den "Charakter" des Systems als Ganzes offenbart. Objektsystem (object system) = ein System, dessen Elemente Objekte und Beziehungen zwischen den Objekten sind. OOA = Akronym für Object-Oriented Analysis. OOD = Akronym für Object-Oriented Design. OOSD = Akronym für Object-Oriented Structured Design. S E R M = Akronym für Strukturiertes Entity-Relationship-Modell. SOM = Akronym für Semantisches Objektmodell.

48

Grundlagen

der

Systemplanung

Zweck der Objektorientierung Der objektorientierte Ansatz wird in der Systemplanung erst seit Mitte der achtziger Jahre verwendet; er gewinnt zunehmend an Bedeutung. Die Wurzeln für die Entwicklung des objektorientierten Ansatzes in der Systemplanung waren objektorientierte Programmiersprachen (wie z.B. SIMULA und Ada), von deren speziellen Konstrukten abstrahiert wurde, und klassische Entwurfsmethoden (wie z.B. Structured Analysis von T. DeMarco oder das Entity-Relationship-Modell von P. P.-S. Chen). Verbreitung hat die Objektorientierung bislang in der Programmierung gefunden; sie wird in einigen Unternehmen im Rahmen von Prototyping-Projekten eingesetzt (vgl. Lerneinheit SOBOP). Von der Programmierung her entwickelt sich die Ausbreitung der Objektorientierung "rückwärts"; es wird angenommen, daß sie in einigen Jahren auch in den frühen Phasen eines IuK-Projekts praktische Bedeutung erlangen kann (objektorientierter Entwurf, objektorientierte Analyse). Mit Objektorientierung werden verschiedene Zwecke im Detail verfolgt, die sich alle auf die Forderung zurückführen lassen, die Produktivität der Systemplanung zu verbessern. Ob dies tatsächlich möglich ist, konnte bislang empirisch nur für die Programmierung nachgewiesen werden, doch sprechen einige der grundlegenden Eigenschaften der Objektorientierung für die Annahme, daß dies auch für andere Aufgaben der Systemplanung der Fall ist. Daraus den Schluß zu ziehen, daß allein Objektorientierung die Produktivität der Systemplanung sichern kann, ist jedoch verfehlt. Nach wie vor kommt es primär auf einen guten fachlichen Entwurf ("Fachkonzept") an; Objektorientierung hilft (besser als andere Methodikansätze, vgl. Lerneinheit ZAMSP), aus dem Entwurf eine gut strukturierte Spezifikation für die Entwicklung abzuleiten. Verschiedene Maßnahmen der Systemplanung stehen zur Produktivität in einer Mittel/Zweck-Beziehung, insbesondere Maßnahmen, die geeignet sind, bereits entwickelte Komponenten eines IuK-Systems (z.B. Komponenten eines Anwendungsprogramms) wiederzuverwenden, da Mehrfachverwendung zur Senkung der Zeit und der Kosten der Systemplanung beiträgt ("Prinzip der Mehrfachverwendung"). Um Mehrfachverwendung zu erreichen, müssen folgende organisatorische und methodische Voraussetzungen erfüllt sein: • eine das einzelne Projekt übergreifende, systematische und klassifizierende Dokumentation (vgl. Lerneinheit DOKUM); • ein gezielter und schneller Zugriff auf die vorhandenen Produkte und Teilprodukte durch ein komfortables Auskunftssystem; • festgelegte Konventionen und Standards für die Struktur und die Beschreibung der Produkte und Teilprodukte; • ein modularer Aufbau der Produkte und Teilprodukte mit festgelegten, exakt definierten Schnittstellen. Die Merkmale der Objektorientierung, nämlich Klassenbildung, Generalisierung, Spezialisierung und insbesondere V e r e r b u n g (siehe weiter unten), sind zur Schaffung dieser organisatorischen und methodischen Voraussetzungen gut geeignet. Ergebnis einer objektorientierten Systemplanung soll ein System als eine Menge von miteinander in Beziehung stehenden O b j e k t e n sein ("Objekt-

OBOSP - Objektorientierte Systemplanung

49

system"). In einem solchen Objektsystem ist der strukturelle Aufbau der Objekte und ihr Verhalten im System beschrieben. Für die formale Beschreibung von Objektsystemen sind Beschreibungsmittel erforderlich. Die Beschreibung erfolgt zunächst auf der logischen Ebene. Die verwendeten Beschreibungsmittel sollen das Erkennen von Objekten und Objektbeziehungen aus der (im allgemeinen) verbalsprachlich formulierten Projektaufgabe unterstützen. Betrachtet man den für ein IuK-Projekt erforderlichen Aufwand in Abhängigkeit von der Projektgröße (z.B. gemessen als Umfang der Funktionalität), dann kann für eine Systemplanung ohne Objektorientierung ab einer bestimmten Projektgröße ein überproportionaler Verlauf des Aufwands angenommen werden, der mit Objektorientierung vermieden, zumindest deutlich abgeschwächt werden kann. Als bestimmende Einflußgrößen können drei Eigenschaften der Objektorientierung angenommen werden: bessere Modellierung der Wirklichkeit, höhere Wiederverwendbarkeit von Systemkomponenten und leichtere Änderbarkeit des Systems ohne grundlegenden Neuaufwurf. Objektorientierung und objektorientierter Ansatz Die Betrachtung eines Systems aus der Sicht der in diesem System agierenden Menge von Objekten heißt "Objektorientierung"; die Vorgehensweise, welche die Objektorientierung verwendet, wird als "objektorientierter Ansatz" bezeichnet. Da die Objekte - je nach betrachtetem System - unterschiedlich sind, hat auch die Objektorientierung eine systemspezifische Bedeutung, wenn auch die formale Objektsicht bei allen objektorientierten Ansätzen gleich ist. Generelles Problem der Objektorientierung ist es, die systemspezifische Objektbedeutung herauszuarbeiten und somit das festzulegen, was zweckmäßigerweise als Objekt verwendet werden soll (z.B. bei der objektorientierten Benutzeroberfläche, bei der objektorientierten Datenbank, bei der objektorientierten Fertigung oder bei der objektorientierten Programmierung). Die Aufzählung zeigt, daß objektorientierte Systemplanung kein bestimmtes Objekt zum Gegenstand hat, sondern daß sie - je nach Analyse-, Entwurfs- und Implementierungsaufgabe - in bezug auf bestimmte, in der Regel unterschiedliche Objekte "objektorientiert" sein kann. Davon unabhängig gibt es eine die Systemplanung in allen Phasen dominierende Objektorientierung, deren reales Objekt Daten, Funktionen und Interaktionen und deren Modellobjekt (Objekt im Sinn der Objektorientierung) Daten, Methoden und Nachrichten sind; auf diese Art Objektorientierung wird im folgenden näher eingegangen. Objektorientierung ist in der betriebswirtschaftlichen Organisationslehre und damit in der Wirtschaftsinformatik nichts grundlegend Neues; sie wurde aber nicht zu einem objektorientierten Ansatz entwickelt. Im Zusammenhang mit der Gestaltung der A r b e i t s o r g a n i s a t i o n ist das O b j e k t p r i n z i p als ein Prinzip bekannt, bei dem die materiellen oder immateriellen Aktionsobjekte (oder kurz: Objekte), an denen körperliche oder geistige Verrichtungen durchzuführen sind, im Vordergrund der Gestaltung stehen; den Aktionsobjekten werden Verrichtungen zugeordnet. Im Gegensatz dazu steht das Verrichtungsprinzip, bei dem die körperlichen oder geistigen Verrichtungen, die an materiellen oder immateriellen Aktionsobjekten durchzuführen sind, im Vordergrund der Gestaltung

50

Grundlagen der

Systemplanung

stehen; den Verrichtungen werden Aktionsobjekte zugeordnet. Eine grundlegende Änderung der Objektorientierung im Sinn einer weitergehenden Bedeutung erfolgte im Zusammenhang mit der Entwicklung der Programmierung, als deren Ergebnis von objektorientierter Programmierung gesprochen wird. Ihre Konzepte sind eine der beiden Wurzeln objektorientierter Systemplanung. Merkmale der Objektorientierung Zentrale Entwurfskomponenten sind Modellobjekte (kurz: Objekte), in denen Daten und Methoden "gekapselt" (auch: "verkapselt") sind. Mit ihnen werden Daten und Funktionen realer Objekte abgebildet. Durch diese Objektsicht wird die einseitige Orientierung auf Daten (beim datenorientierten Ansatz) bzw. auf Funktionen (beim funktionsorientierten Ansatz) überwunden. Grundprinzip der Objektorientierung ist die Verbindung von Daten und Funktionen, sodaß sich eine Trennung von Datenmodell und Funktionenmodell verbietet. Die zentralen Begriffe des objektorientierten Ansatzes sind: Klasse (bzw. Klassenbildung), Generalisierung, Spezialisierung und Vererbung. • Klasse (auch: Objektklasse) ist eine Menge von Objekten mit gleichen Eigenschaften (Attributen). Jedes konkrete Objekt einer Klasse wird als Instanz, seine Attribute werden als Instanzvariable bezeichnet. Eine Oberklasse ist eine Klasse übergeordneter, abstrakterer Objekte. Eine Unterklasse oder Subklasse ist eine Klasse, deren Objekte aus einer Klasse (oder aus mehreren Klassen) abgeleitet wurden; diese ist dann Oberklasse (auch: Superklasse). Jedes Objekt ist genau einer Klasse als Instanz zugeordnet; alle Instanzen besitzen den gleichen strukturellen Aufbau, der durch die Instanzvariablen beschrieben wird. Zu jeder Klasse gehört eine Menge von Methoden (Operatoren), die auf den Instanzen ausführbar sind. Jede Klasse hat einen Namen. • Generalisierung ist die Zusammenfassung gleichartiger Objekte zu abstrakteren Objekten, das heißt zu einer Oberklasse; Generalisierung ist das Gegenteil von Spezialisierung. • Spezialisierung ist die Ableitung gleichartiger Objekte aus abstrakteren Objekten, das heißt die Bildung einer Unterklasse; Spezialisierung ist das Gegenteil von Generalisierung. • Vererbung ist die Fähigkeit eines Objekts als Komponente einer Objektstruktur, Daten und Methoden an Objekte einer untergeordneten Objektklasse (einer Subklasse) übertragen zu können bzw. der Vorgang der Übertragung. In der Subklasse können Daten und Methoden hinzugefügt, modifiziert oder eliminiert werden. Die Instanzen der einzelnen Klassen interagieren mit Hilfe von Nachrichten. Jeder interpretierbaren Nachricht ist über ein Methodenverzeichnis eine Methode zugeordnet. Empfängt ein Objekt eine Nachricht, wird anhand des Methodenverzeichnisses eine Methode zur Behandlung der Nachricht ausgewählt, die dann auf dem Empfängerobjekt ausgeführt wird. Eine Methode kann während ihrer Ausführung auf einem Objekt Nachrichten an andere Objekte senden. Nachrichten sind mit Argumenten parametrisierbar. Jede Nachricht wird durch eine Antwort quittiert. Die Klasseninstanz repräsentiert die Klasse selbst. Sie dient dazu, Nachrichten an eine Klasse zu senden, um dort Klassenmethoden auszulösen (z.B. Erzeuge.Instanz ). Klasseninstanzen besitzen keine Instanzvari-

OBOSP - Objektorientierte

Systemplanung

51

ablen und damit keinen nach außen sichtbaren Zustand; ihnen entsprechen also keine realen Objekte. Klassen werden als Spezialisierungen (Subklassen) einer allgemeineren Klasse (Superklasse) beschrieben. Auf diese Weise entsteht eine Klassenhierarchie. Jede Superklasse vererbt alle Attribute und Methoden an ihre Subklassen. Bei einfacher Vererbung übernimmt eine Klasse die Attribute und Methoden von einer Superklasse, bei multipler Vererbung von mehreren Superklassen, gegebenenfalls unter Berücksichtigung spezieller Vererbungsregeln. Das Prinzip der Vererbung ermöglicht es, Methoden für mehrere Klassen gemeinsam zu beschreiben. Eine Subklasse kann die ererbten Attribute erweitern und/oder verändern. Empfängt ein Objekt eine Nachricht, die im Methodenverzeichnis seiner Klasse nicht enthalten ist, dann wird im Methodenverzeichnis der entsprechenden Superklasse gesucht. Wenn die Nachricht auch dort nicht gefunden wird, wird sie als "nicht ausführbar" zurückgemeldet. Eine Nachricht, die an Objekte verschiedener Klassen gesendet wird, kann dort unterschiedliche Auswirkungen haben ("Polymorphie"). Ein weiteres Merkmal des objektorientierten Ansatzes ist die Wiederverwendbarkeit von Objekten. Bestehende Objekte werden daher in einer Klassenbibliothek gesammelt. Modellierung von Informationssystemen Informationssysteme sind Abbildungen von Ausschnitten der Wirklichkeit ("Domänen") von Organisationen in Wirtschaft und Verwaltung, für die sie geschaffen und von denen sie verwendet werden. Zur Schaffung von Informationssystemen wird ein Modell dieser Wirklichkeit gebraucht. Zur Entwicklung eines solchen Modells der Wirklichkeit bietet sich der objektorientierte Ansatz aus folgenden Gründen besonders an: • Er bietet gute Voraussetzungen dafür, eine Domäne in dem Sinn realitätsnah abzubilden, daß Objekte des Modells mit realen Objekten korrespondieren (können). • Verkapselung unterstützt den modularen Aufbau und die Flexibilität von Informationssystemen. • Die Bildung anwendungsnaher Klassen unterstützt die Integration auf einem hohen Abstraktionsniveau und ist eine wichtige Voraussetzung für das Schlußfolgern. • Vererbung unterstützt die Reduktion von Redundanz, bietet eine wirkungsvolle Anpassung durch Spezialisierung und ist ein mächtiges Instrument der Systemwartung. Die Modellierung von Informationssystemen mit Hilfe von Objekten, die realweltlichen Sachverhalten entsprechen, eröffnet Möglichkeiten für die Kommunikation zwischen verschiedenen Anwendungen. Während traditionell Nachrichten aus Instanzen elementarer Datentypen (im Extremfall aus Bytes) zusammengesetzt sind, können Anwendungen nun Nachrichten versenden, die sich auf wirklichkeitsnahe Objekte bzw. Klassen beziehen.

52

Grundlagen der Systemplanung

Einordnung in die Informationssystem-Architektur Die in diesem Lehrbuch verwendete Systematik der Systemplanung, die nach heutigem Sprachgebrauch auch als Informationssystem-Architektur bezeichnet wird, beschreibt ein Informationssystem aus drei Sichten, nämlich Gesamtsicht ("Grundkonzeption"), Datensicht ("Datenmodell") und Funktionensicht ("Methodenmodell"). Die Verbindung zwischen der Datensicht und der Funktionensicht wird durch die Ablaufsicht hergestellt (vgl. Abbildung OBOSP-1). Datensicht, Funktionensicht und Ablaufsicht werden jeweils in die Beschreibungsebenen "logisches Modell" und "physisches Modell" zerlegt. Die für die Objektorientierung typische Kopplung von Daten und Funktionen wird mit der Ablaufsicht abgebildet. Diese Erklärung zur Einordnung der Objektorientierung ermöglicht jedoch noch keine spezifische Vorgehensweise, welche die Objektorientierung unterstützt; sie ist kein objektorientierter Ansatz. Datensicht

Ablaufsicht

Funktionensicht

Abb. OBOSP-1: Modell der Informationssystem-Architektur

Methoden der Objektorientierung Methoden der Objektorientierung beschreiben Vorgehensweisen bei der Systemplanung, die geeignet sind, Objektorientierung zu unterstützen (häufig, aber sprachlich falsch, als "objektorientierte Methoden" bezeichnet). Dazu gehören insbesondere folgende Methoden, die alle Basiskonzepte der Objektorientierung umfassen (in Klammern die Kurzbezeichnungen, die Namen der Methodenentwickler und das Jahr des erstmaligen Erscheinens von Publikationen dazu): • • • • •

Object-Oriented Structured Design (OOSD, Wasserman et al. 1989), Design Method for Object-Oriented Programming (DOOP, Pun/Winder 1989), Object-Oriented Analysis (OOA, Coad/Yourdon, 1990), Semantisches Objektmodell (SOM, Ferstl/Sinz 1990), Object-Oriented Design (OOD, G. Booch 1991).

Alle Methoden sind unabhängig von bestimmten Programmiersprachen und daher grundsätzlich in allen objektorientierten Entwicklungsumgebungen verwendbar. Die von Coad/Yourdon eingeführte Bezeichnung für eine systematische, in fünf Phasen gegliederte Vorgehensweise zur Anwendung der Objektorientie-

OBOSP - Objektorientierte

Systemplanung

53

rung, eine Methodik, die vom Entitäten-Struktur-Diagramm und von den Prinzipien der objektorientierten Programmierung ausgeht, hat im wesentlichen für alle Methoden Gültigkeit. Die fünf Phasen sind: • Identifizieren der Objektklassen; • Herausarbeiten der Beziehungen zwischen den Objektklassen ("Objektstruktur"); • Zusammenfassen gleichartiger Objektklassen (Generalisierung); • Festlegen der Attribute der Objektklassen; • Zuordnen von Methoden auf die Objektklassen. Ob eine objektorientierte Vorgehensweise überhaupt möglich ist, kann - von diesen Phasen ausgehend - durch die Beantwortung der folgenden Fragen überprüft werden: • • • •

Können Können Können Können

Objekte identifiziert werden? Attribute identifiziert und auf Objekte zugeordnet werden? Methoden identifiziert und auf Objekte zugeordnet werden? Objektklassen gebildet werden?

Bei der Beantwortung dieser Fragen können die folgenden Überlegungen helfen: Die Sach- und Formalziele, die bei der Systemplanung verfolgt werden ("Anforderungen") resultieren letztlich aus den Geschäftsvorfällen, deren Bearbeitung das zu schaffende IuK-System unterstützen soll. Für jeden Geschäftsvorfall ist (mindestens) eine Funktion eines Objekts zu spezifizieren. Aufgabe der Benutzeroberfläche ist es, zu erkennen, welchen Geschäftsvorfall der Benutzer bearbeiten will und die dafür benötigte Objektfunktion ausführen zu lassen. Ein eigenständiges Datenmodell hat in der Objektorientierung "eigentlich" keinen Platz; es ist jedoch zweckmäßig, mit der Datenmodellierung zu beginnen. Entitäten bilden häufig die Ansatzpunkte für Objekte, weil sie erkennen lassen, welche Funktionen die Daten verwenden. Auf diese Weise kann das Datenmodell - durch schrittweises Ergänzen mit Funktionen - zu einem Objektmodell weiterentwickelt werden. Semantische Objektmodellierung Ferstl/Sinz haben einen methodischen Rahmen für eine ganzheitliche Modellierung betrieblicher Informationssysteme in objektorientierter Form entwickelt. Modellierungskonzept ist ein semantisches Objektmodell (SOM), wobei "semantisch" die Nähe des Begriffssystems im Modell zur Wirklichkeit betonen soll. Nachfolgend werden die Grundzüge des SOM erläutert. Die Modellierung erfolgt in zwei Ebenen, der Modellierung von Objekten ("Objektmodellierung", die wiederum in den zwei Stufen "Objektsystementwurf' und "Objektentwurf" erfolgt) und der Modellierung von Vorgängen ("Vorgangsmodellierung" oder "Vorgangsentwurf'). Objektsystementwurf, Objektentwurf und Vorgangsentwurf sind ohne Werkzeugunterstützung nicht durchführbar. • Gegenstand der konzeptionellen Objektmodellierung sind die betrieblichen Objekttypen und deren Beziehungsstruktur. Der Aufbau der Objekttypen wird im Objektentwurf, die Beziehungsstruktur der Objekttypen wird im Objekt-

54

Grundlagen

der

Systemplanung

systementwurf modelliert. Der Objektsystementwurf grenzt das Objektsystem von seiner Umwelt ab und legt die Klassen des Objektsystems sowie die Beziehungsstruktur der Klassen fest. Die Schlüsselreferenzen zwischen den Objekttypen (Datensicht) bilden gleichzeitig die Interaktionskanäle für den Austausch von Nachrichten (Interaktionssicht) und erhalten auf diese Weise eine zusätzliche, funktional auswertbare Semantik (Funktionssicht). Neben dem Austausch von Nachrichten ("interacts-with") verwendet SOM die in objektorientierten Ansätzen üblichen Abstraktionsmechanismen Generalisierung ("is-a") und Aggregation ("is.part-of"). Das Ergebnis wird in einem konzeptionellen Objektschema beschrieben. • Gegenstand der Vorgangsmodellierung ist die Definition betrieblicher Abläufe in Form von Vorgangsobjekttypen. Dabei werden die an einem Vorgang beteiligten betrieblichen Objekttypen und deren Beziehungsstruktur anhand des konzeptionellen Objektschemas ermittelt und die zulässigen Abläufe festgelegt. Konzeptionelle Objektmodellierung wird als objektorientierte Erweiterung der konzeptionellen Datenmodellierung verstanden. Die methodischen Wurzeln von SOM sind daher ein semantisches Datenmodell ("Basis-Datenmodell") und ein Objektmodell ("Basis-Objektmodell"). Als Basis-Datenmodell wird das Strukturierte Entity-Relationship-Modell (SERM), eine Weiterentwicklung des Entity-Relationship-Modells (ERM), verwendet. Das Basis-Objektmodell orientiert sich weitgehend am Objektmodell von Smalltalk. Das Datenmodell verwendet die Grundbegriffe Datenobjekttyp (auch kurz: Objekttyp), Datenobjekt (auch kurz: Objekt), Attribut und Beziehung. Das Objektmodell verwendet die Grundbegriffe Klasse (auch: Objekttyp), Instanz (auch: Objekt), Instanzvariable (auch: Attribut), Kommunikationsweg (auch: Interaktionskanal). Die Vorgangsmodellierung erfordert eine Zerlegung betrieblicher Vorgänge, die im Ergebnis der "Granularität" des konzeptionellen Objektschemas als Ergebnis der Objektmodellierung entspricht. Alle zu einem Aufgabenkomplex gehörenden Vorgänge werden durch einen Vorgangsobjekttyp modelliert. Ein Vorgangsobjekttyp steuert das Zusammenwirken mehrerer konzeptioneller (Daten-) Objekttypen zur Durchführung eines Aufgabenkomplexes. Ein Vorgang ist daher eine Instanz eines Vorgangsobjekttyps. Vorgangsobjekttypen werden in Analogie zu den konzeptionellen (Daten-) Objekttypen durch Attribute, Nachrichten und Methoden beschrieben. Aufgabe eines Vorgangsobjekttyps ist es, Nachrichten an konzeptionelle (Daten-) Objekte zu generieren und die Empfänger für die von konzeptionellen (Daten-) Objekten ausgehenden Nachrichten festzulegen. Demonstrationsbeispiel Am Beispiel eines Auftragsverwaltungs- und Vertriebssystems wird die Beantwortung der vier Fragen zur Überprüfung der A n w e n d b a r k e i t des objektorientierten Ansatzes ausschnittsweise gezeigt. • Erste Frage: Können Objekte identifiziert werden? Antworten: Objekt ist KUNDE mit den Rollen als BESTELLER, als WARENEMPFÄNGER und als FAKTURENEMPFÄNGER. Objekt ist GESCHÄFTSFALL als EXPORTGESCHÄFT, als INLANDSGESCHÄFT, als

OBOSP - Objektorientierte Systemplanung

55

GARANTIEFALL und als SPEDITIONSAUFTRAG. Objekt ist TRANSAKTION als ANGEBOT, als AUFTRAG, als LIEFERSCHEIN, als FAKTURA und als BUCHUNGSANZEIGE. • Zweite Frage: Können Attribute identifiziert und auf Objekte zugeordnet werden? Antworten: Attribute für das Objekt BESTELLER sind z.B.: Kundennummer, Kundenname, Straße, Ort, PLZ, Kundengruppe, Telefon, Kontaktperson. Attribute für das Objekt WARENEMPFÄNGER sind z.B.: Kundennummer, Kundenname, Straße, Ort, PLZ, Kundengruppe, Telefon, Kontaktperson, Lieferkondition, Lieferort. Attribute für das Objekt FAKTURENEMPFÄNGER sind z.B.: Kundennummer, Kundenname, Straße, Ort, PLZ, Kundengruppe, Telefon, Kontaktperson, Zahlungskondition, Rechnungsanschrift. • Dritte Frage: Können Methoden identifiziert und auf Objekte zugeordnet werden? Antworten: Methoden des Objekts BESTELLER sind: BESTELLER anlegen, BESTELLER ändern, BESTELLER löschen, BESTELLER nach Matchcode suchen, BESTELLER drucken. Methoden des Objekts WARENEMPFÄNGER sind: WARENEMPFÄNGER anlegen, WARENEMPFÄNGER ändern, WARENEMPFÄNGER löschen, WARENEMPFÄNGER nach Matchcode suchen, WARENEMPFÄNGER drucken. Methoden des Objekts FAKTURENEMPFÄNGER sind: FAKTURENEMPFÄNGER anlegen, FAKTURENEMPFÄNGER ändern, FAKTURENEMPFÄNGER löschen, FAKTURENEMPFÄNGER nach Matchcode suchen, FAKTURENEMPFÄNGER drucken. • Vierte Frage: Können Objektklassen gebildet werden? Antworten: Es wird versucht, Objekte mit gleichen Attributen und ähnlichen Methoden zu lokalisieren. Es ist erkennbar, daß die Objekte BESTELLER, WARENEMPFÄNGER und FAKTURENEMPFÄNGER diese Bedingungen erfüllen. Daher wird die Objektklasse KUNDE gebildet. Attribute der Objektklasse KUNDE sind: Kundennummer, Kundenname, Straße, Ort, PLZ, Kundengruppe, Telefon, Kontaktperson. Methoden der Objektklasse KUNDE sind: KUNDE anlegen, KUNDE ändern, KUNDE löschen, KUNDE nach Matchcode suchen, KUNDE drucken. BESTELLER, WARENEMPFÄNGER und FAKTURENEMPFÄNGER werden durch Spezialisierung als Subklassen aus der Objektklasse KUNDE abgeleitet; KUNDE ist daher für die Objektklassen BESTELLER, WARENEMPFÄNGER und FAKTURENEMPFÄNGER Oberklasse oder Superklasse. Die Subklassen BESTELLER, WARENEMPFÄNGER und FAKTURENEMPFÄNGER erben die Attribute und Methoden ihrer Oberklasse KUNDE. Die Attribute der Subklasse WARENEMPFÄNGER werden um die Attribute Lieferkondition und Lieferort, die Attribute der Subklasse FAKTURENEMPFÄNGER werden um die Attribute Zahlungskondition und Rechnungsanschrift ergänzt. Forschungsbefunde HeßtScheer berichten über Ergebnisse eines logisch-konzeptionellen Methodenvergleichs von OOD, OOSD, DOOP, OOA und SOM. Sie gehen dabei von der impliziten Annahme aus, daß die Notation (das verwendete Beschreibungsmittel)

56

Grundlagen

der

Systemplanung

und das Vorgehensmodell die wesentlichen Eigenschaften einer Methode sind, die für Akzeptanz beim Anwender und Ergebnisqualität von Bedeutung sind. Bezüglich Notation wurden folgende Vergleichskriterien verwendet: Existenz von Klassen, Beziehungen zwischen Klassen, Zuordnung von Attributen zu Klassen, Zuordnung von Methoden zu Klassen, Zustandsübergänge eines Objekts, Nachrichtenaustausch zwischen Objekten und Modularisierung (Clusterbildung). Vollständig erfüllt werden die Vergleichskriterien nur durch OOD. Die von den Programmiersprachen abgeleiteten Methoden (wie OOSD) weisen Darstellungsmängel bei der Spezifizierung von Instanzvariablen und bei den Beziehungen zwischen den Klassen auf. Die von der Datenmodellierung abgeleiteten Methoden (wie SOM) verfügen über keine Darstellungsmittel, mit denen der Nachrichtenaustausch zwischen Objekten veranschaulicht werden kann. Bezüglich des Vorgehensmodells wird festgestellt, daß - abgesehen vom eng an die Datenmodellierung angelehnten SOM - die Methoden eine sehr ähnliche, durch die folgenden Arbeitsschritte gekennzeichnete Vorgehensweise verwenden: • • • • •

Ableiten der Objekte und Objektklassen aus der Projektaufgabe; Feststellen der Beziehungen zwischen den Objektklassen; Definieren von Attributen und von Methoden; Spezifizieren des Nachrichtenaustauschs; Festlegen von Moduln.

Aus dieser Feststellung schließen die Autoren, daß die Vorgehensweise von der verwendeten Methode der Objektorientierung und damit von der verwendeten Notation weitgehend unabhängig ist, worauf bereits Wasserman et al. ausdrücklich hingewiesen haben. Daraus wird auf die Möglichkeit der Schaffung eines Standards für die Notation geschlossen. Kontrollfragen 1. 2. 3. 4. 5.

Welcher Zweck wird mit der Objektorientierung der Systemplanung verfolgt? Welches sind die wesentlichen Merkmale des objektorientierten Ansatzes? Wie ist der objektorientierte Ansatz in die Methodik der Systemplanung einzuordnen? Welche fünf Beispiele für Methoden der Objektorientierung wurden genannt? Welche Bedeutung hat eine einheitliche Notation für Methoden der Objektorientierung?

Quellenliteratur Ferstl, O. K. und Sinz, E. J.: Objektmodellierung betrieblicher Informationssysteme im Semantischen Objektmodell (SOM). In: WIRTSCHAFT INFORMATIK 3/1990, 566 - 581 Heß, H. und Scheer, A.-W.: Methodenvergleich zum objektorientierten Design von Softwaresystemen. In: Theorie und Praxis der Wirtschaftsinformatik 165/1992, 117 - 137 Kreutzer, W.: Grundkonzepte und Werkzeugsysteme objektorientierter Systementwicklung. In: WIRTSCHAFTS INFORMATIK 3/1990, 2 ! 1 - 227 Vertiefungsliteratur Coad, P. and Y o u r d o n , E.: Object-Oriented Analysis. 2. Ed., Prentice Hall Int., E n g l e w o o d Cliffs, N.J. 1991 Dittrich, R.: Objektorientierte Datenmodelle als Basis komplexer Anwendungssysteme. In: WIRTSCHAFTSINFORMATIK 3/1990, 228 - 237 Shlaer, S. and Mellor, S. J.: Object-oriented Systems Analysis - Modelling the W o r l d in Data. Jourdon Press, London 1988

PROTY - Prototyporientierte Systemplanung Lernziele Sie kennen die Arten des Prototyping und die Arten von Prototypen, die beim Prototyping verwendet werden. Sie können den Zusammenhang zwischen Prototyping und Phasenschema beschreiben. Sie erkennen, daß die Beteiligung der zukünftigen Benutzer ein wesentliches Merkmal des Prototyping ist. Sie wissen, für welche Aufgaben der Systemplanung Prototyping primär anwendbar ist. Definitionen und Abkürzungen Anforderung (requirement) = eine Aussage über die von einem System geforderten Funktionen (Funktionsanforderungen), Leistungen (Leistungsanforderungen) und Schnittstellen (Schnittstellenanforderungen) sowie über die Qualität der Erfüllung der Funktions-, Leistungs- und Schnittstellenanforderungen. Anwendungsaufgabe (application task) = jede betriebliche Aufgabe, die Gegenstand eines IuK-Projekts oder eines IuK-Systems ist. Benutzerakzeptanz (user acceptance) = die Bereitschaft des Benutzers, das von einem IuK-System angebotene Nutzungspotential in Anspruch zu nehmen. Bewertung (evaluation) = die zielbezogene Beurteilung von Alternativen auf der Grundlage eines Systems von Beurteilungskriterien. Experiment (experiment) = ein wissenschaftlicher Versuch zur Aufstellung, Bestätigung oder Widerlegung von Hypothesen. Funktionalität (functionality) = die Eigenschaft eines Systems, alle Anforderungen bezüglich der geforderten Funktionen erfüllen zu können. Implementierung (implementation) = die Überführung eines logischen Modells in ein physisches Modell. Muster (pattern) = eine Vorlage oder ein Modell, nach dem etwas gefertigt werden soll. Prototyp (prototype) = ein schnell verfügbares und ausführbares Modell eines Endprodukts, das bestimmte Eigenschaften des Endprodukts erfüllt. P r o t o t y p i n g - Z y k l u s (prototyping cycle) = eine Folge von Arbeitsschritten, bestehend aus Verwenden, Bewerten und Modifizieren eines Prototypen. Qualitätssicherung (quality assurance) = alle planmäßigen Maßnahmen zur Erreichung der Gebrauchstauglichkeit eines Gutes für seinen beabsichtigten Verwendungszweck. Schichtenmodell (layer model) = die Darstellung eines Systems im Modell in Form mehrerer aufeinander aufbauender Teilmodelle. Spezifikation (specification) = die Erarbeitung, Festlegung und Beschreibung der Anforderungen an einen Systementwurf. Wartung (maintenance) = eine Menge von Maßnahmen, um ein System fehlerfrei zu halten (korrigierende Wartung), an veränderte Anforderungen anzupassen (Anpassungswartung) oder zu verbessern (Perfektionswartung). W i d e r s p r ü c h l i c h k e i t (inconsistency) = die Eigenschaft eines Objekts (z.B. eines Systementwurfs), in sich nicht logisch zu sein. Synonym: Inkonsistenz.

58

Grundlagen

der

Systemplanung

Phasenschema und Prototyping Die Orientierung der Systemplanung am P h a s e n s c h e m a brachte zwar mehr Ordnung und Nachvollziehbarkeit, aber auch einen erheblichen Zuwachs an Bürokratie. Dabei waren nach wie vor Widersprüchlichkeiten und Lücken bei der Definition der Anforderungen (vgl. Lerneinheiten SACHZ und FORMZ) sowie erhebliche Mängel bei Kosten- und Zeitschätzungen feststellbar. Diese wurden vor allem durch die aufwendigen Rückkopplungen aus späten in frühe Phasen der Systemplanung verursacht, wenn Planungsmängel "Nacharbeiten" erforderlich machten. Trotzdem war das Ergebnis der Systemplanung nur ein unfertiges Produkt, das nach der Installierung noch erheblicher Verbesserungen bedurfte, um produktiv verwendbar zu sein, hauptsächlich dann, wenn sich während des Planungsprozesses die Anforderungen geändert hatten. Planungsaufwand und Wartungsaufwand standen in keinem vernünftigen Verhältnis zueinander; die Produktqualität war zu gering. Aus diesen Kritikpunkten ergeben sich folgende Forderungen, die eine verbesserte Planungsmethodik erfüllen sollte: • Vernetzung von Analyse-, Entwurfs- und Implementierungsarbeiten; • Konstruktion des Gesamtsystems in kleinen Schritten und überschaubaren Einheiten; • Kommunikation zwischen Anwendern/Benutzern und Systemplanern während des gesamten Planungsprozesses; • Unterstützung der Bewertung von Modellen, soweit möglich durch Prototypen. Die Beachtung dieser Forderungen führte zum Prototyping. Die Idee stammt aus den Ingenieurwissenschaften. Dort ist es üblich, bei der Entwicklung eines neuen Produkts zunächst Versuchsmodelle zu erstellen, mit deren Hilfe Erfahrungen bezüglich Entwurf, Konstruktion und Verwendung gesammelt werden. Daß diese Idee für die Planung und Realisierung von IuK-Systemen erst spät aufgegriffen wurde, lag vor allem daran, daß für das - im Vergleich zum Endprodukt - wenig aufwendige Herstellen von Prototypen keine Werkzeuge zur Verfügung standen. Dieser Mangel ist heute - soweit es sich um Software-Systeme handelt - behoben (vgl. Lerneinheit WERSP). Prototyping ersetzt nicht das Phasenschema, sondern ergänzt es. Es ist daher angebracht, vom prototyping-orientierten Phasenschema zu sprechen. In diesem Phasenschema besteht eine Zweistufigkeit der Phasenpläne. Es gibt einen generellen Phasenplan für das gesamte IuK-Projekt, der dem traditionellen Phasenschema folgt ("Planung im Großen"), und - darin eingebettet - einen Phasenplan für das Prototyping ("Planung im Kleinen"). Die Phaseneinteilung bleibt erhalten. Die Rückkopplungen im Phasenschema werden durch die Einbettung des Prototyping intensiviert, insbesondere werden Analysearbeiten, Entwurfsarbeiten und Implementierungsarbeiten stärker vernetzt. Prototyping ist besonders für IuK-Projekte geeignet, in denen es um dialogorientierte Anwendungen geht, durch die viele zukünftige Benutzer betroffen sind und bei denen die Anforderungen zu Projektbeginn noch sehr unstrukturiert und vage sind, vice versa. Daraus folgt, daß IuK-Projekte nicht allein deshalb methodisch fragwürdig sein müssen, weil sie Prototyping nicht verwenden (insbes. dann nicht, wenn die Anforderungen gut strukturiert und sehr stabil sind). Auf eine kurze Formel ge-

PROTY - Prototyporientierte

Systemplanung

59

bracht kann gesagt werden: Ohne Prototyping wird "so spät wie möglich" (nämlich erst dann, wenn "alle" Anforderungen spezifiziert sind) implementiert, mit Prototyping wird "so früh wie möglich" (ein Prototyp) implementiert. Abbildung PROTY-1 zeigt die idealtypische Einordnung des Prototyping in das Phasenschema der Systemplanung. Sie verdeutlicht die Zweckmäßigkeit der Verwendung von Prototypen in allen Planungsphasen und veranschaulicht die Art und Weise, in der eine prototyporientierte Systemplanung die im Phasenschema erforderlichen Rückkopplungen verkürzt (z.B. die Rückkopplung zwischen der Implementierung in der Feinprojektierung und dem Festlegen der Anforderungen in der Vorstudie durch exploratives Prototyping). Prototyping ist folglich auch als eine Vorgehensweise zur Qualitätssicherung anzusehen, indem es das Einhalten definierter Qualitätsforderungen unterstützt (vgl. Lerneinheit QUALM im Band "Informationsmanagement").

Abb. PROTY-1: Integration des Prototyping in das Phasenschema

Arten von Prototypen Unabhängig davon, um welche Art von Prototyp es sich handelt, kann jeder Prototyp mit den folgenden Merkmalen beschrieben werden: • Er kann schnell und mit geringen Kosten entwickelt werden. • Er bietet dem zukünftigen Benutzer ein funktionales und ausführbares Modell der wesentlichen Teile des Systems vor dessen Implementierung. • Er ist flexibel, d.h. er läßt sich leicht modifizieren und erweitern. • Er bildet das System nicht notwendigerweise vollständig ab. • Er dient als Kommunikationsmittel zwischen den Entwicklern auf der einen und den Anwendern und Benutzem auf der anderen Seite. • Er läßt sich von allen am Planungsprozeß Beteiligten bewerten. Nach der Art des Prototypen wird zwischen vollständigem Prototyp, unvollständigem Prototyp, Wegwerf-Prototyp und wiederverwendbarem Prototyp unterschieden.

60

Grundlagen der Systemplanung

• Vollständiger Prototyp: Ein Prototyp, der alle wesentlichen Funktionen des zu schaffenden IuK-Systems vollständig verfügbar macht. Die bei der Planung und bei der Anwendung gemachten Erfahrungen und der Prototyp selbst bilden die Grundlage für die endgültige Systemspezifikation. • Unvollständiger Prototyp: Ein Prototyp, der es gestattet, die Brauchbarkeit und/oder die Machbarkeit einzelner Komponenten des zu schaffenden IuKSystems (z.B. die Benutzerschnittstelle) zu untersuchen. • Wegwerf-Prototyp: Ein Prototyp, der nur als ablauffähiges Modell dient; der Prototyp wird fiir das zu schaffende IuK-System nicht direkt verwendet. • Wiederverwendbarer Prototyp: Ein Prototyp, der alle geforderten Qualitätsmerkmale erfüllt und von dem wesentliche Teile in das zu schaffende IuK-System übernommen werden können. Eine andere Systematik, die primär vom Verwendungszweck des Prototypen ausgeht, unterscheidet zwischen Demonstrationsprototyp, Labormuster und Pilotsystem. • Der Demonstrationsprototyp unterstützt die Projektinitiierung bzw. die Projektakquisition; er soll den potentiellen Auftraggeber überzeugen, daß das gewünschte Endprodukt prinzipiell gebaut werden kann oder daß seine Handhabung dem entspricht, was sich die zukünftigen Benutzer vorstellen. Ein Prototyp für diesen Zweck hat daher die Eigenschaften des unvollständigen und in der Regel auch des Wegwerf-Prototypen. • Das Labormuster dient im wesentlichen der Klärung konstruktionsrelevanter Fragen; es wird aus dem Modell der Anwendungsaufgabe und aus einer bereits vorhandenen Spezifikation abgeleitet. Die Konstruktion des Endprodukts soll mit der des Labormusters im wesentlichen identisch, zumindest vergleichbar sein. Dies kann sich auf die Architektur und/oder auf die Funktionalität beziehen. • Beim Pilotsystem ist die strikte Trennung zwischen Prototyp und Endprodukt aufgehoben; ab einer bestimmten Reife wird der Prototyp eingesetzt (und produktiv an einzelnen Arbeitsplätzen verwendet) und weiterentwickelt. Der Prototyp ist zunächst unvollständig und wiederwendbar, ab dieser "Reife" vollständig. Bewerten von Prototypen Das Bewerten von Prototypen setzt voraus, daß es eine zwischen Systemplanern und Anwendern/Benutzern vereinbarte Bewertungsstrategie gibt; Prototypen müssen stets im Hinblick auf diese Bewertungsstrategie entwickelt werden. Die Bewertungsstrategie legt das Was und das Wie der Bewertung fest. Dies schließt Vereinbarungen darüber ein, in welchen zeitlichen Abständen geänderte Versionen des Prototypen zur Bewertung vorliegen sollen ("Bewertungszyklus"). Aus methodischer Sicht sind kurze Bewertungszyklen vorzuziehen, um schnell zu einer Stabilisierung der Anforderungen zu kommen. Dadurch wird die Kommunikation zwischen den Partnern intensiviert und die Benutzerbeteiligung gefördert. Das Was der Bewertung macht Aussagen darüber, welche Eigenschaften der Prototyp (insbes. bezüglich Funktionen, Leistungen und Schnittstellen) haben soll. Aus dem Was der Bewertungsstrategie ist zu erkennen, welche der Eigen-

PROTY - Prototyporientierte

Systemplanung

61

Schäften das geplante Endprodukt haben soll und welche für den Prototypen (bzw. für mehrere Versionen des Prototypen) spezifisch und damit nur vorläufig sind. Das Wie der Bewertung macht Aussagen darüber, nach welcher Bewertungsmethode vorgegangen werden soll, um zu einem von beiden Partnern akzeptierten Bewertungsergebnis zu kommen. Im allgemeinen zweckmäßig ist ein Vorgehen nach der Nutzwertanalyse (vgl. Lerneinheit NUTZW), das auf das Bewertungsobjekt und die Bewertungssituation abgestimmt ist. Dazu sind auch Vereinbarungen darüber erforderlich, wie unterschiedliche Bewertungen durch Anwender und Benutzer einerseits und Systemplaner andererseits zu behandeln sind. Ziel ist es, Übereinstimmung zu erreichen. Arten des Prototyping Art des Prototyping meint, warum Prototypen verwendet werden und wie bei ihrer Verwendung grundsätzlich vorgegangen wird. Danach wird zwischen explorativem, experimentellem und evolutionärem Prototyping unterschieden. Exploratives Prototyping: Ziel des explorativen Prototyping ist eine möglichst vollständige Spezifikation der Funktionsanforderungen des zu schaffenden IuK-Systems. Den Systemplanern soll ein Einblick in die Anwendungsaufgabe ermöglicht werden. Sie sollen mit den Benutzern verschiedene Lösungsalternativen diskutieren, um den "Denkhorizont" nicht verfrüht auf einen Ansatz einzuengen, und die Realisierbarkeit des zu schaffenden IuK-Systems in einem gegebenen organisatorischen Umfeld abklären zu können. Die zukünftigen Benutzer sollen in der Lage sein, den Prototypen anhand realer Arbeitssituationen zu beurteilen. Die Vorgehensweise des explorativen Prototyping ist dadurch gekennzeichnet, daß - ausgehend von ersten Vorstellungen über das zu schaffende IuKSystem - ein Prototyp entwickelt wird, der es erlaubt, diese Vorstellungen anhand konkreter Arbeitssituationen zu überprüfen und die geforderten Funktionen sukzessiv zu bestimmen. Im Mittelpunkt des Interesses steht nicht die Qualität des Prototypen, sondern seine Funktionalität und leichte Veränderbarkeit und die Kürze der Entwicklungszeit. Exploratives Prototyping unterstützt daher primär die Festlegung der Funktionsanforderungen (vgl. Lerneinheiten SACHZ und ANFOA). Der Einfluß des explorativen Prototyping auf das Phasenschema ist gering, da es im wesentlichen nur für die Anforderungsanalyse verwendet wird. Dies gilt besonders dann, wenn (nur) Wegwerf-Prototypen verwendet werden. Experimentelles Prototyping: Ziel des experimentellen Prototyping ist eine vollständige Spezifikation der Systemkomponenten. Zweck des experimentellen Prototyping ist es, die Tauglichkeit von Objektspezifikationen, von Architekturmodellen und von Lösungsideen für einzelne Systemkomponenten nachzuweisen. Die Vorgehensweise des experimentellen Prototyping ist dadurch gekennzeichnet, daß - ausgehend von ersten Vorstellungen über die Zerlegung des Systems - ein Prototyp entwickelt wird, der es erlaubt, die Wechselwirkungen zwischen den Systemkomponenten zu simulieren. Anhand konkreter Anwendungsbeispiele werden die Zweckmäßigkeit der Schnittstellen der einzelnen Systemkomponenten und die Flexibilität der Systemarchitektur im Hinblick auf Erweiterungen im Experiment erprobt. Für die Qualität des Prototypen gilt das beim explorativen Prototyping Gesagte. Experimentelles Prototyping unterstützt also primär das System- und Komponentendesign bei der Software-Entwicklung (vgl. Lern-

62

Grundlagen der

Systemplanung

einheiten EMESY und SPROM). Im Unterschied zum explorativen Prototyping sind die zukünftigen Benutzer nicht beteiligt. Experimentelles Prototyping verändert das Phasenschema stärker als exploratives Prototyping, da insbesondere Implementierungsarbeiten "nach vorn gezogen" und in Analyse- und Entwurfsarbeiten eingebunden werden. Dies gilt besonders dann, wenn ein wiederverwendbarer Prototyp benutzt wird. Manchmal wird das Verwenden von Prototypen durch die Benutzer als Grundlage für die Bewertung auch als "Experimentieren mit Prototypen" bezeichnet und daraus gefolgert, daß es sich um experimentelles Prototyping handelt. Evolutionäres Prototyping: Ziel des evolutionären Prototyping ist eine inkrementelle Systemplanung, das heißt eine sukzessive Planungsstrategie nach folgender Vorgehensweise: Entwicklung eines Prototypen für die leicht erkennbaren Anforderungen. Das Ergebnis ist Grundlage für den nächsten Planungsschritt, das heißt: Jeder Prototyp ist Spezifikationsgrundlage für den nächsten Prototypen bzw. letztlich für das Endprodukt. Im nächsten Planungsschritt werden weitere Anforderungen in den Prototypen integriert. Prototyp und IuK-System sind nicht mehr unterscheidbar; der Prototyp wird sukzessiv "hochgezogen" und schließlich als produktives IuK-System verwendet. Die Veränderung des Phasenschemas sind beim evolutionären Prototyping am deutlichsten; man kann sogar sagen: evolutionäres Prototyping und Phasenschema sind unverträglich. Vorgehensweise beim

Prototyping

Durch Prototyping ergibt sich eine das Phasenschema variierende, keineswegs aber substituierende Vorgehensweise. Dabei können exploratives und experimentelles Prototyping "vermischt" verwendet werden. Eine typische Vorgehensweise ist die folgende: Zunächst wird explorativ vorgegangen, wozu ein W e g werf-Prototyp erzeugt wird ("rapid prototyping", "quick and dirty"). Primäres Ziel ist die Minimierung des Zeitraums, in dem der erste Prototyp zur Verfügung steht. Wenn die Bewertung ergibt, daß die wesentlichen Anforderungen erfaßt und berücksichtigt wurden, wird der Prototyp nur noch zu Vergleichszwecken verwendet (z.B. um später überprüfen zu können, ob die wesentlichen Anforderungen fortgeschrieben wurden). Danach wird evolutionär vorgegangen, wofür ein wiederverwendbarer Prototyp entwickelt wird. Nach jeder Bewertung wird entschieden, was die Erreichung der Planungsziele besser unterstützt: den vorhandenen Prototypen zu modifizieren oder ihn wegzuwerfen. Wenn evolutionär vorgegangen und der Prototyp in jedem Falle wiederverwendet wird, dann können die folgenden Arbeitsschritte unterschieden werden: • • • • •

Erster Arbeitsschritt: Grobe Definition der Anforderungen. Zweiter Arbeitsschritt: Erzeugen eines Prototypen. Dritter Arbeitsschritt: Verwenden des Prototypen. Vierter Arbeitsschritt: Bewerten des Prototypen. Fünfter Arbeitsschritt: Modifizieren des Prototypen nach den Ergebnissen des dritten Arbeitsschritts, n-maliges Durchlaufen des dritten und vierten Arbeitsschritts.

Nach dem (n+l)-maligen Durchlaufen des dritten bis fünften Arbeitsschritts ("Prototyping-Zyklus") ist aus dem Prototypen das Endprodukt entstanden. Ein

PROTY - Prototyporientierte

Systemplanung

63

Prototyping-Zyklus kann planmäßig einem bestimmten Zweck dienen, so z.B. ein erster Zyklus dem Zweck "Initiierung". Hier geht es primär darum, daß sich die Beteiligten in die Projektaufgabe einarbeiten. Im ersten Prototypen werden daher nur wenige, den Entwicklern bereits bekannte Funktionen realisiert. Ein zweiter Prototyping-Zyklus kann der "Orientierung" dienen. Hier geht es darum, alle wesentlichen Anforderungen zu erfassen, die im Prototypen realisiert werden. Ein dritter Zweck schließlich ist "Stabilisierung". Hier geht es in erster Linie um die Verfeinerung und Ergänzung von Funktionen und um die Herstellung der geforderten Leistung. Späte Prototypen der "Neuorientierung" bzw. frühe der "Stabilisierung" befinden sich nahe dem Niveau des Endprodukts; sie können daher auch für Schulungszwecke verwendet werden. Wird Planung und Realisierung eines IuK-Systems als Schichtenmodell aufgefaßt, dann kann beim Prototyping entweder horizontal oder vertikal vorgegangen werden. Beim horizontalen Prototyping werden einzelne Schichten des Systems konstruiert (z.B. die Benutzeroberfläche oder die Funktionen); im allgemeinen ist mit horizontalem Prototyping die Konstruktion der Benutzeroberfläche gemeint. Beim vertikalen Prototyping wird ein ausgewählter Teil des Zielsystems "in aller Tiefe" implementiert. Diese Vorgehensweise ist zweckmäßig, wenn die Funktionalität des Gesamtsystems unbekannt und seine Realisierungsmöglichkeiten fraglich sind. Auswirkungen des Prototyping Systematische empirische Befunde über die Auswirkungen des Prototyping liegen nicht vor. Bezüglich der Kosten für einzelne Prototypen sprechen Erfahrungsberichte aus der Praxis von "5% bis 20%" der Kosten des Endprodukts. Bei derartigen Angaben bleibt offen, um welche Art von Prototyp bzw. Prototyping es sich handelte. Beides zu wissen ist für die Interpretation derartiger Befunde unerläßlich. Bezüglich der Kosten für das Prototyping behaupten Erfahrungsberichte aus der Praxis und Hypothesen aus der Forschung eine drastische Verbesserung der Kostensituation. Als Ursache dafür werden vor allem das frühe Erkennen von Fehlern und Inkonsistenzen sowie die bessere Motivierung der Benutzer genannt. Die bedeutsamste Auswirkung des Prototyping wird - nach weit verbreiteter Auffassung - in der drastischen Verbesserung des Nutzens des mit Prototyping hergestellten Endprodukts gesehen. Dieser ergibt sich insbesondere aus der verbesserten Zusammenarbeit zwischen Anwendern/Benutzern und Systemplanern, die zu einem Produkt führt, das durch eine auf die jeweilige Arbeitssituation besser abgestimmte Funktionalität und Benutzbarkeit gekennzeichnet ist. Die Akzeptanz des Produkts durch die Benutzer ist - auf Grund ihrer aktiven Mitwirkung bei der Produktentwicklung - deutlich besser als ohne Prototyping. Daraus kann auf eine verbesserte Kostensituation bei der Wartung geschlossen werden, die sich aus einem deutlichen Rückgang der Wartungsanforderungen ergibt. In einzelnen Fällen wird besonders darauf hingewiesen, daß durch die Bewertung von Prototypen das Projekt-Controlling unterstützt wird und daß daher zuverlässiger beurteilt werden kann, ob ein IuK-Projekt unverändert fortgeführt,

64

Grundlagen der Systemplanung

mit wesentlichen Veränderungen (z.B. drastischer Reduzierung des Funktionsumfangs) saniert oder abgebrochen werden sollte. A. Kieback et al. ziehen aus eigenen praktischen Erfahrungen mit sechs größeren industriellen Projekten, in denen die Verwendung von Prototypen explizit vorgesehen war (und nicht unbefriedigende Ergebnisse nachträglich als Prototypen deklariert wurden), die folgenden Schlüsse über spezifische Eigenschaften und Auswirkungen des Prototyping: • Auftraggeber wissen im allgemeinen nicht, welchen Nutzen Prototyping bringen kann und wo seine Grenzen liegen. • Prototyping setzt Wissen über die Anwendungsaufgabe voraus; es kann nicht allein auf der Basis schriftlicher Dokumente durchgeführt werden. • Die Benutzer müssen am Prototyping beteiligt sein; dies ersetzt nicht kreative Ideen und Lösungsvorstellungen der Systemplaner. • Prototyping ist ein Lernprozeß für alle beteiligten Gruppen; der direkte Kontakt zwischen diesen Gruppen ist erforderlich. • Prototyping verbessert die Planbarkeit des Projekts; es erfordert veränderte Formen der Vertragsgestaltung zwischen Auftraggeber und Auftragnehmer. • Ein Prototyp ist kein Ersatz für eine Dokumentation. • Einsatzmöglichkeiten und Nutzen von Demonstrationsprototypen werden unterschätzt. • Labormuster fördern die Kreativität und können zu innovativen Systemalternativen führen. • Die Vorgehensweise beim Prototyping muß an die situativen Bedingungen der Anwendungsaufgabe angepaßt werden. Demonstrationsbeispiel Es wird das P r o t y p i n g - W e r k z e u g DICE gezeigt, das Teil des Werkzeugkastens TOPOS (= TOolset for Prototyping-Oriented Software Development) ist. Abbildung PROTY-2 zeigt die Grobstruktur von TOPOS und die Einordnung von DICE. Der wichtigste Baustein einer DICE-Anwendung ist ein Fenster. Um ein leeres Fenster zu erhalten, wird der Button "Edit Window" im Bedienungspanel von DICE aktiviert (siehe Abbildung PROTY-3). Um Benutzerschnittstellenelemente in ein Fenster hinzuzufügen, wird das gewünschte Element im Bedienungspanel ausgewählt und im korrespondierenden Fenster an der gewünschten Stelle eingefügt. Neben den üblichen Schnittstellenelementen grafischer Benutzeroberflächen (Buttons, Text- und Zahlenfeldern, Popup-Menü-Elementen und Teilfenstem) gibt es zwei Gruppierungselemente - Cluster und Expander. Diese unterstützen die Spezifikation des Fenster-Layouts und des Verhaltens der Benutzerschnittstellenelemente, wenn die Größe des sie umgebenden Fensters verändert wird.

PROTY - Prototyporientierte Systemplanung

65

CMS

DICE

(Component Management System) unterstützt Dokumentenverwaltung

(Dynamic Interface Creation Environment) unterstützt Benutzerschnittstellen-Prototyping

S CT (System Construction Tool) unterstützt Architektur-I'rototyping

SMT

objektorientierte Datenbank

Sonstige Werkzeuge

(Software Maintenance Tool) unterstützt Dokumentation und Wartung

z.B. ein Prolog-Interpreter

Abb. PROTY-2: TOPOS-Grobstruktur (Quelle: Pomberger et al.)

•m

E

• c Empty Cluster

Action Button

Empty Subwindov

Empty Expander

Radio Button

T

Ei

Text Subwindov

St «.tic Text Field

Toggle Button

List Subvinclov

Editeble Text Field

LJ

S

I

Q

II •B Popup Item

»

Q

g) ""'

Enumeration Item Test Prototype Saue

Saue Hs

Label

Labeled Radio Button SJ

Label

Labeled Toggle Button Generate Code ...

3

Abb. PROTY-3: DICE's Bedienungspanel (Quelle: Pomberger et al.)

Innerhalb jedes Fensters stehen in DICE Editierfunktionen zur Verfügung, wie sie von gängigen WYSIWYG-Grafikeditoren bekannt sind: Die Elemente der Benutzerschnittstellen können (einzeln oder in Gruppen) verschoben oder in ihrer Größe verändert werden. Die "Cut/Copy/Paste-Metapher" wird innerhalb eines Fensters, zwischen den Fenstern eines Prototypen und zwischen verschiedenen Prototypen unterstützt. Die elementspezifischen Parameter werden über Dialoge

66

Grundlagen der Systemplanung

angegeben. Abbildung PROTY-4 zeigt beispielsweise die Attributspezifikation für einen Action Button.

8

m

Cash Dispenser

Welcome to the machine I

1 Stop "

^

F

I

F

Action Button P a r a m e t e r s R

T y p r y p r

Tent:

S P H

stop

•

"I

Default

r- Stretching Behaulour -, P Component Name •

horizontally fined

•

vertically flHed

StopButtoii

flEBH [ nu

Abb. PROTY-4: Beispiel für eine mit DICE spezifizierte Benutzerschnittstelle (Quelle: Pomberger et al.)

Ein Software-System ist insbesondere durch sein dynamisches Verhalten charakterisiert. Deshalb muß DICE neben der Spezifikation des statischen Aussehens der Benutzerschnittstelle auch Möglichkeiten bieten, das dynamische Verhalten auf hoher Abstraktionsebene zu definieren und zu simulieren. Um den Implementierungsaufwand hochinteraktiver, grafischer Benutzeroberflächen reduzieren zu können, ist es wichtig, die evolutionäre Weiterentwicklung des Prototypen zur fertigen Anwendung zu ermöglichen. Dazu bietet DICE verschiedene Möglichkeiten (die hier nicht erläutert werden). p.

\\

Message Editor

Target Objects:

Possible Messages:

Buttano

Open

Û

Close

CardButtan

Already Defined: Dlsable(->OkButton)

^ ^ ^ ^ ^ ^

Bisable(->CardButton)

tashUispenserllNndoiii XX

Display OkDutton StopButton 1 ÉSHWnjfl

_

M

f Belela Link! [öonej

Ih

,C

Abb. PROTY-5: Nachrichteneditor (Quelle: Pomberger et al.)

Den einzelnen Benutzerschnittstellenelementen sind bestimmte, vordefinierte N a c h r i c h t e n zugeordnet (z.B. einem Fenster die Nachrichten "Open" und "Close", einem Textfeld die Nachrichten "Enable", "Disable" und M SetText(...)" etc.). Betrachtet wird als Beispiel die Benutzerschnittstelle eines einfachen Geldausgabeautomaten ("Cash Dispenser") aus Abbildung PROTY-4. Es soll z.B. das

PROTY - Prototyporientierte

Systemplanung

67

"Cash Dispenser Fenster" geschlossen werden, wenn der Button "Stop" aktiviert wird. U m dieses dynamische Verhalten zu spezifizieren, aktiviert man den Button "Link" im Parameterdialog des Buttons "Stop" (siehe Abbildung PROTY-3). Mittels eines "Message-Editors" (vgl. Abbildung PROTY-5) wird das erwünschte dynamische Verhalten spezifiziert, nämlich daß die Nachricht "Close" an das "Cash Dispenser Fenster" gesendet wird, wenn der Button "Stop" gedrückt wird. Für jedes aktivierbare Element (das sind die verschiedenen Arten von Buttons und Menüeinträgen) kann eine beliebige Anzahl von Nachrichten definiert werden. Wenn der Prototyp simuliert wird (durch Aktivierung des Buttons "Test Prototype" im Bedienungspanel, siehe Abbildung PROTY-3), werden bei Aktivierung eines Elements die dafür definierten Nachrichten an die Empfänger abgesendet, was die spezifizierte Änderung der Benutzerschnittstelle bewirkt. Auf diese Weise kann rudimentäres dynamisches Verhalten des Prototypen ohne eine einzige Zeile Programmcode realisiert werden. Um den Prototypen evolutionär weiterentwickeln zu können, bietet DICE die Möglichkeit, Unterklassen von ET++ Klassen zu generieren. Diese Klassen ergeben nach der Übersetzung eine Anwendung, die mit dem in DICE spezifizierten Prototypen identisch ist. Der Quelltext der generierten Klassen muß nicht geändert werden, wenn zusätzliche Funktionalität hinzugefügt wird. Anwendungsspezifisches Verhalten wird in Unterklassen der generierten Klassen implementiert, indem entsprechende, dynamisch gebundene Methoden überschrieben werden. Kontrollfragen 1. 2. 3. 4. 5.

Welcher Zusammenhang besteht zwischen Phasenschema und Prototyping? Welche Ziele werden mit Prototyping verfolgt? Welche Arten des Prototyping werden unterschieden? Durch welche Arbeitsschritte ist die Vorgehens weise beim Prototyping gekennzeichnet? Welche Auswirkungen werden dem Prototyping zugeschrieben?

Quellenliteratur Kieback, A. et al.: Prototyping in industriellen Software-Projekten - Erfahrungen und Analysen. In: Informatik Spektrum 2/1992,65 - 77 Pomberger, G. und Blaschek, G.: Software Engineering. Prototyping und objektorientierte Software-Entwicklung. Hanser Verlag, München/Wien 1993 Pomberger, G. et al.: Methoden und Werkzeuge für das Prototyping und ihre Integration. In: Informatik Forschung und Entwicklung 7/1992,49 - 61 Vertiefungsliteratur Bischofberger, W. and Pomberger, G.: Prototyping-oriented Software Development. Concepts and Tools. Springer Verlag, Berlin et al. 1992 Budde, R. et al.: Prototyping. An Approach to Evolutionary System Development. Springer Verlag, Berlin et al. 1992 Hildebrand, K.: Repository-unterstütztes Prototyping. In: Theorie und Praxis der Wirtschaftsinformatik 161/1991, 107 - 116 Vonk, R.: Prototyping - The effective use of CASE Technology. Prentice Hall Int., Hempstead 1990

WERSP - Werkzeugunterstützung der Systemplanung Lernziele Sie kennen d e n Z w e c k der Werkzeugunterstützung der Systemplanung. Sie erkennen, durch welche Merkmale ein Werkzeug gekennzeichnet ist und wie es sich von Methode und Methodik unterscheidet. Sie wissen, was ein Vorgehensmodell ist und welche Bedeutung es für den Einsatz von CASE-Werkzeugen hat. Sie kennen die wichtigsten Eigenschaften von CASE-Systemen, die Vorgehensweise bei ihrem Einsatz und die Auswirkungen ihrer Anwendung. D e f i n i t i o n e n und

Abkürzungen

A D / C y c l e = Abkürzung für Application Development/Cycle; ein CASE-System der IBM. A D P S = Abkürzung f ü r Application Development Project Support; ein CASEWerkzeug der IBM. C A R E = Abkürzung f ü r Computer Aided Reengineering. C A S E = Abkürzung f ü r Computer Aided Software Engineering (auch: Computer Aided Systems Engineering). D O M I N O = eingetragenes Warenzeichen für ein CASE-System der SNI mit der Bezeichnung "Integrierte Verfahrenstechnik für die Entwicklung und Wartung informationsverarbeitender Systeme". G e n e r a t o r (generator) = ein Werkzeug zur Erzeugung eines Programms aus vorgegebenen Spezifikationen (z.B. ein Berichtsgenerator zur Erzeugung von Programmen für die Datenausgabe). I C A S E = Abkürzung f ü r Integrated Computer Aided Software Engineering. I E F = Abkürzung für Information Engineering Facility; ein CASE-Werkzeug von Texas Instruments. Maestro II = Bezeichnung f ü r ein CASE-Werkzeug der Softlab GmbH. Predict Case = Bezeichnung f ü r ein CASE-Werkzeug der Ploenzke Informatik und der Software AG. P r o t o t y p i n g (prototyping) = eine Vorgehensweise bei der Systemplanung mit ausgeprägter Benutzerbeteiligung unter Verwendung spezieller Werkzeuge. Repository (repository) = eine Datenbasis, die über den Inhalt eines Datenkatalogs hinausgehend auch Informationen über Prozesse, Methoden, Programme u.a.m. enthalten kann. R e s t r u k t u r i e r u n g (restructuring) = die Übertragung eines Systems von einer Repräsentationsform in eine andere, ohne das Verhalten des Systems oder die Funktionalität zu ändern. V e r i f i z i e r u n g (verification) = die Überprüfung von Entwurfs- oder Entwicklungsergebnissen auf Korrektheit mittels empirischer Methoden oder systematischer Vorgehensweisen (z.B. durch Entwurfsinspektion). V a l i d i e r u n g (Validation) = ein Verfahren, dessen Zweck es ist, die Validität eines Systems festzustellen. Validität (validity) = das Ausmaß, mit dem ein Qualitätsmaß die Eigenschaft, die es messen soll, auch tatsächlich mißt.

WERSP - Werkzeugunterstützung

der Systemplanung

69

Zweck der Werkzeugunterstützung Zweck der Werkzeugunterstützung der Systemplanung ist es, verschiedene Formalziele besser zu erreichen. Unter diesen Formalzielen stehen Produktivität und Qualität sowohl des Planungsprozesses als auch der Planungsergebnisse im Vordergrund. Durch Verbesserung der Produktivität soll vor allem der Zeitbedarf für ein IuK-Projekt verkürzt werden, sodaß Ergebnisse schneller produktiv verwendbar sind. Durch Verbesserung der Qualität soll vor allem erreicht werden, daß die Anforderungen so erfaßt werden, wie es der geplanten Arbeitssituation entspricht, und daß sie möglichst vollständig in das Endprodukt umgesetzt werden. Dadurch soll der Aufwand für die Wartung drastisch reduziert werden. Die Verbesserung von Produktivität und Qualität kann durch die Verwendung von Vorgehensmodellen und damit von Methoden erreicht werden, die auch ohne Werkzeuge bekannt waren. Vorgehensmodelle und Methoden ohne Werkzeuge müssen in Handbüchern abgelegt werden; die Methoden sollen verwendet werden. Die Erfahrung zeigte aber, daß dies nicht erfolgte; es bestand kein "Zwang" zur Methodenverwendung. Computerbasierte Werkzeuge zwingen zur Methodenverwendung. Durch die in den Werkzeugen integrierte Kommunikationskomponente wird der Austausch von Informationen zwischen den am Arbeitsprozeß Beteiligten erzwungen. Der "Methoden-Wirrwarr" wird systematisiert, womit versucht wird, die Anwendung aufeinander abgestimmter Methoden in allen Phasen der Systemplanung zu erreichen. Damit wird auch die Durchgängigkeit der Methoden in allen Phasen des Arbeitsprozesses bzw. für alle Tätigkeiten des verwendeten Vorgehensmodells angestrebt. Durch die Verwendung von Werkzeugen sollen vor allem die frühen Phasen der Systemplanung unterstützt werden, das heißt die Analyse und der Entwurf. So wird z.B. eine Unterstützung für die Anforderungsanalyse (vgl. Lerneinheit ANFOA) angestrebt, um schnell zu einer möglichst zuverlässigen Spezifikation zu kommen, die leicht geändert werden kann. Die Ergebnisse früherer Phasen sollen automatisch an nachfolgende Phasen weitergegeben werden. Die Verwendung von Werkzeugen ermöglicht auch die Änderung der Planungsmethodik so, daß sie den Bedingungen des Arbeitsprozesses besser angepaßt werden kann, beispielsweise durch Prototyping (vgl. Lerneinheit PROTY). Auch in den späten Phasen der Systemplanung können durch Werkzeugunterstützung Produktivität und Qualität verbessert werden, z.B. durch Code-Generatoren und Generierung von Testdaten. Methodik, Methode und Werkzeug Zur richtigen Einordnung und Beurteilung der Werkzeugunterstützung der Systemplanung ist es zunächst erforderlich, den Werkzeugbegriff zu präzisieren und in einen größeren Zusammenhang einzuordnen. Bei der Erläuterung der Ziele und Aufgaben der Systemplanung (vgl. Lerneinheit ZAMSP) wurde der Begriff Methodik (auch: Methodologie) verwendet, worunter die Lehre von den Methoden und ihre planmäßige wissenschaftliche Anwendung verstanden wird. Davon ausgehend wurden Methodik-Ansätze erläutert, die für die Systemplanung typisch sind. Sie beschreiben in ihrer Gesamtheit "die planmäßige wis-

70

Grundlagen der Systemplanung

senschaftliche Anwendung von Methoden" zur Lösung der Aufgabe der Systemplanung. Daraus folgt, daß die Methodik festgelegt sein muß, bevor Methoden gesucht, entwickelt und angewendet werden können. Methoden sind konkrete Handlungsvorschriften, die auf einem System von Regeln aufbauen und deren Zweck es ist, das Lösen eines Problems zu unterstützen oder sogar zu ermöglichen. Um eine bestimmte Methodik der Systemplanung verfolgen zu können, ist - angesichts der Anzahl und Unterschiedlichkeit der zu lösenden Probleme - eine Menge von Methoden erforderlich. ("Technik" im hier verwendeten Sinne soll im wesentlichen identisch sein mit "Methode".) Einfache Probleme können in der Regel mit einfachen Methoden gelöst werden; schwierige Probleme erfordern in der Regel komplexe Methoden, und häufig sind zur Lösung eines einzelnen Problems mehrere komplexe Methoden erforderlich. In Anbetracht der Anzahl, Unterschiedlichkeit und Komplexität der Probleme, die in ihrer Gesamtheit zur Bewältigung der Aufgabe der Systemplanung gelöst werden müssen, sind Hilfsmittel erforderlich, mit denen die Methodenanwendung und damit das Problemlösen unterstützt werden können. Computerbasierte Hilfsmittel, welche die Methodenanwendung bei der Systemplanung unterstützen, werden als Werkzeuge bezeichnet. Die Verwendung der Bezeichnung "Werkzeug" ist nicht unproblematisch, da sie (in Analogie zu einem Hammer, einer Zange usw.) suggeriert, daß es sich dabei um etwas handelt, mit dem man in jedem Fall etwas bewirken kann. (Was hier gemeint ist, muß eher mit einem Fahrrad verglichen werden; das würden wir aber nicht als Werkzeug bezeichnen.) Von CASE-Werkzeug (genauer gesagt: Upper CASE) wird dann gesprochen, wenn das Werkzeug PC-basiert und grafikorientiert ist und den frühen Phasen der Systemplanung dient. CASE-Werkzeuge, die nur die Programmierung unterstützen ("Programmierwerkzeuge"), werden im allgemeinen nicht unter CASEWerkzeuge subsumiert (oder ausdrücklich als Lower CASE bezeichnet). CASEWerkzeuge basieren methodisch im wesentlichen auf Structured Analysis (abgekürzt: SA); sie betonen die grafikorientierte Spezifikation durch Datenflußdiagramme (vgl. Lerneinheit DAFLU). Phasenschema und Vorgehensmodell Das Phasenschema liefert nur ein grobes Bild über die grundsätzliche Gliederung der Gesamtaufgabe der Systemplanung in Phasen und deren Teilaufgaben sowie der Methoden. Durch präzise Beschreibung der Aktivitäten sowie ihrer Voraussetzungen und Ergebnisse in allen Phasen des Phasenschemas entsteht ein Vorgehensmodell. Jede Aktivität eines Vorgehensmodells unterliegt grundsätzlich der Validierung und der Verifizierung. Viele Anwender verfügen über "ihr eigenes" Vorgehensmodell. Es soll den Arbeitsprozeß vereinheitlichen und langfristig möglichst stabil sein, um eine verläßliche Arbeitsgrundlage zu schaffen. Das Vorgehensmodell stellt im wesentlichen den Rahmen dar, innerhalb dessen der Arbeitsprozeß organisiert ist. Methoden und Werkzeuge entstehen meist unabhängig von bestimmten Vorgehensmodellen; jedenfalls sollen sie für unterschiedliche Vorgehensmodelle ver-

WERSP - Werkzeugunterstützung

der Systemplanung

71

wendbar sein. Sie müssen daher gewissermaßen in unterschiedliche Vorgehensmodelle "eingeklinkt" werden können. Idealerweise müßte der Anwender die Möglichkeit haben, beliebige Methoden und Werkzeuge in sein Vorgehensmodell "einzuklinken"; dies setzt genormte Schnittstellen in den Vorgehensmodellen voraus, die es heute nur in Ausnahmefällen gibt. Daher muß insbesondere überlegt werden: • Für welche Aktivität(en) des Vorgehensmodells soll die Methode/das Werkzeug eingesetzt werden? • Inwieweit passen die im Vorgehensmodell beschriebenen Daten auf die von den Methoden/Werkzeugen benötigten bzw. erzeugten Daten? • Wie erfolgt der Aufruf der Werkzeuge? Komplexe Vorgehensmodelle verwenden 100 und mehr Aktivitäten; die Aktivitäten können weiter zu Aktivitätstypen verfeinert sein. Für kleine IuK-Projekte sind diese Vorgehensmodelle ungeeignet. Manche CASE-Werkzeuge bieten daher einfache Vorgehensmodelle an; sie beschreiben den Arbeitsprozeß nur grob, was für kleinere IuK-Projekte ausreicht (z.B. IEF, Maestro II). Entscheidet sich der Anwender für Werkzeuge dieser Art, um zunächst kleine Projekte werkzeugunterstützt zu bearbeiten, muß er darauf achten, daß sie auch in Vorgehensmodellen verwendet werden können, die später für große Projekte verwendet werden sollen (z.B. können IEF und Maestro II in ADPS verwendet werden). Vorgehensmodelle können vereinfacht werden, indem sie (nur) auf bestimmte Teilaufgaben der Systemplanung ausgerichtet sind. Ein Vorgehensmodell, das (nur) für IuK-Projekte verwendet wird, bei denen es um die Veränderung bestehender Software-Systeme geht, wird einfacher sein als ein Vorgehensmodell, das darüber hinaus die Schaffung neuer Software-Systeme abdeckt. Ein CASE-Werkzeug kann daher auch mehrere Vorgehensmodelle für unterschiedliche Teilaufgaben anbieten (z.B. Predict Case). Werkzeugklassen Werkzeuge können unterschiedlichen Werkzeugklassen zugeordnet werden: • Editierende Werkzeuge gestatten die Eingabe von Daten per Hand. • Generierende Werkzeuge formen Resultate zu neuen Resultaten um. • Transformierende Werkzeuge formen Daten um; im Gegensatz zum Generieren können Transformationen nicht beliebig wiederholt werden, da - z.B. durch menschlichen Eingriff - neue Daten hinzugefügt wurden. • Darstellende Werkzeuge bringen ein bereits vorliegendes Resultat in eine andere Form (z.B. DRUCKEN, DISPLAY, DURCHBLÄTTERN). Eine Unterklasse sind Werkzeuge, die grafische Darstellungen von Resultaten schaffen; sie sind den generierenden Werkzeugen ähnlich. • Analysierende Werkzeuge ermöglichen Zusammenfassungen einzelner Resultate (z.B. Statusreporte, Abfragen, Wort- und Zeilenzähler). • Verwaltende Werkzeuge dienen der Handhabung von Resultaten (z.B. KOPIEREN, LÖSCHEN, AUSLAGERN, UMSPEICHERN). Der semantische Gehalt der Resultate bleibt erhalten.

72

Grundlagen der

Systemplanung

Charakteristisch für die Methoden und Werkzeuge ist deren meist isolierte Verwendung (z.B. in einzelnen Phasen oder für einzelne Aufgaben) und die dadurch fehlende funktionale Integration. So verwendet beispielsweise der Projektleiter die Netzplantechnik zur Terminplanung und Terminüberwachung sowie zur Kostenplanung und Kostenkontrolle, der Systemplaner Arbeitstagebücher zur Erfassung des Zeitbedarfs und Kommunikationsdiagramme zur Abbildung der Kommunikationsbeziehungen, und der Programmierer verwendet Werkzeuge wie Texteditoren, Datenverwaltungssysteme, Generatoren und Debugger. Es bestehen häufig Unsicherheiten darüber, welche Methoden und Werkzeuge in welcher Phase bzw. für welche Aufgaben am besten eingesetzt werden sollen. C A S E - W e r k z e u g und CASE-System Werden mehrere Werkzeuge so zusammengefaßt, daß ein System mit einem möglichst großen Funktionsumfang entsteht, wird von ICASE oder CASE-Systemen gesprochen. (Phasenübergreifende Systeme, die den gesamten Lebenszyklus abdecken, werden als Cross Lifecycle Tools bezeichnet.) Eine wesentliche Forderung ist, daß die sukzessiv erstellten Dokumente oder Zwischenergebnisse semantisch konsistent bleiben und durch inkrementelle Erweiterung oder durch Transformation auseinander entstehen. Für die Integration von CASE-Werkzeugen werden zwei Modelle verwendet, nämlich Kettenmodell und Sternmodell. • Beim Kettenmodell werden die Werkzeuge in der Reihenfolge der Ausführung aneinander gekettet. Für die Weitergabe der Ergebnisse an das nächste Werkzeug in der Bearbeitungsfolge sind Schnittstellen definiert oder andere Transformationsmöglichkeiten vorgesehen. Nachteilig ist, daß bei einer größeren Anzahl von Werkzeugen der Bedarf an Anpassungskomponenten sehr groß ist. Außerdem ist die Reihenfolge der Werkzeugnutzung nur im vorgeschriebenen Rahmen möglich. • Beim Sternmodell existiert ein zentrales Repository, das die Basis für die Werkzeugintegration bildet. Die funktionalen Anforderungen an das Repository sind vielfältig, da die verwalteten Objekte sehr unterschiedlich sein können (Datenelemente, Datenobjekte, Datenflüsse, Interaktionen, Code, Spezifikationen, Grafiken usw.). Für eine wirkliche Integration müssen daher alle Werkzeuge direkt mit dem Repository arbeiten, in dem ein einheitliches Datenmodell benutzt wird. Für die Einbindung von Fremdwerkzeugen und für den Datenaustausch mit anderen Systemen ("Offenheit") sind Schnittstellen und ein Datenaustauschformat erforderlich. Der Übergang von CASE-Werkzeugen zu CASE-Systemen ist fließend. Als Abgrenzungskriterien eignen sich der Grad und die Art der Werkzeugintegration. Ein CASE-System liegt nach herrschender Auffassung dann vor, wenn die Integration nach dem Sternmodell erfolgt, der gesamte Planungsprozeß werkzeugmäßig unterstützt wird, die Reihenfolge der Bearbeitungsschritte nicht durch die Werkzeuge vorgegeben oder eingeschränkt wird und für die Benutzung eine einheitliche Kommandosprache existiert.

WERSP - Werkzeugunterstützung

der

Systemplanung

73

Architektur von CASE-Systemen Ein CASE-System besteht idealerweise aus den folgenden Komponenten: • Datenbank, meist als Enzyklopädie oder Repository bezeichnet. Über die Datenbank erfolgt die Kommunikation zwischen den Arbeitsplätzen der beteiligten Entwickler; alle Arbeitsergebnisse werden in der Datenbank abgelegt. In der Datenbank abgelegt ist auch das Vorgehensmodell, das den Arbeitsprozeß steuert. Zur Zeit werden relationale, in Zukunft objektorientierte Datenbanksysteme verwendet. Von lokaler Enzyklopädie bzw. lokalem Repository wird gesprochen, wenn Teile von Arbeitsergebnissen auch auf einzelnen Arbeitsplätzen gehalten werden können. • Dialogsystem, repräsentiert durch einen grafischen Bildschirm, Drucker und/oder Plotter. • Werkzeuge, repräsentiert durch Anwendungsprogramme, mit denen die Methoden implementiert sind, zusammen mit syntaxorientierten Editoren. Sie können durch Sprachen der 4. Generation und Werkzeuge für das Prototyping ergänzt werden. • Grafikprogramme zur Diagrammerstellung, je nach Art und Anzahl der unterstützten Methoden in der Regel mehrere (z.B. zur Erzeugung von Datenflußdiagrammen, Entity-Relationship-Modellen und Funktionsbäumen). • Werkzeuge zur Generierung von Code und Masken sowie der Datenbank.

Abb. WERSP-1: Hardware-Architektur von CASE-Systemen

Abbildung WERSP-1 zeigt die für CASE-Systeme (wie z.B. IEF und Maestro II) übliche H a r d w a r e - A r c h i t e k t u r als verteiltes System. Sie nutzt sowohl die Vorteile von PCs bzw. Workstations (insbes. grafikorientierte Benutzeroberfläche mit Fenstertechnik), als auch die hohe Leistungsfähigkeit von Großrechnern (Mainframes) für zentrale Funktionen und als Server für die Arbeitsstationen. Auf den Arbeitsstationen werden die Werkzeuge für die grafikorientierten Analyse- und Entwurfsmethoden ("Front-End-Werkzeuge), auf dem Server die Werkzeuge für die Generierung von Code, Masken und Datenbank so-

74

Grundlagen der Systemplanung

wie für das Projektmanagement vorgehalten (Back-End-Werkzeuge). Die Datenbank wird zentral gehalten oder ist verteilt. Bei M a i n f r a m e - o r i e n t i e r t e n CASE-Systemen (z.B. Predict Case) liegt die Steuerung des Arbeitsprozesses beim Großrechner. Dokumente werden zur Bearbeitung auf den PC ausgelagert. Text wird auf dem Mainframe, Grafik auf dem PC editiert. Änderungen an den Entwicklungsdaten werden vom Werkzeug automatisch in die auf dem Großrechner geführte Datenbank gebracht. Entscheidender Nachteil dieses Konzepts ist das nicht stabile Antwortzeitverhalten. Diesen Nachteil vermeiden PC-orientierte CASE-Systeme. Die PCs arbeiten weitgehend selbständig und verfügen über eine eigene Datenbank. Die Übergabe von Arbeitsergebnissen an den Großrechner (wenn ein solcher überhaupt verwendet wird) wird vom Entwickler gesteuert. Code-, Masken- und Datenbank-Generierung können wahlweise auf dem PC oder dem Großrechner ablaufen. Ältere PCorientierte CASE-Systeme verwenden MS-DOS, moderne verwenden UNIX oder UNIX-Derivate; neuere Versionen älterer Produkte sind auch auf UNIX verfügbar (z.B. Maestro II). OS/2-basierte CASE-Systeme sind im Umfeld von AD/Cycle entstanden (z.B. IEF). Funktionalität von CASE-Systemen Folgende Aufgaben soll ein CASE-System unterstützen: • Basisaufgaben wie Textverarbeitung, Grafikverarbeitung und Kommunikation (Dialog Benutzer/Maschine und Benutzer/Benutzer); • Analyse- und Entwurfsaufgaben mit grafikorientierten Methoden; • Prototyping mit Sprachen der 4. Generation; • Generierung von Code, Masken und Datenbank; • Aufgaben des Reengineering (z.B. Restrukturierung, Redokumentation); • Querschnittsaufgaben im Projekt wie Dokumentation, Qualitätssicherung und Projektmanagement. Die Benutzeroberfläche sollte für alle verwendeten Werkzeuge einheitlich sein. Ein allgemein anerkanntes Referenzmodell, das die Architektur von CASESystemen beschreibt, existiert derzeit nicht. Eine gewisse Bedeutung hat das CASE Environment Framework Reference Model erlangt. In diesem Modell sind die folgenden Gruppen von Dienstleistungen vorgesehen: • Data Repository Services: Aufgabe dieser Dienstleistungen ist es, Entitäten bzw. Objekte zu verwalten. Die Ausführung und Steuerung von Prozessen wird ebenso unterstützt wie die physikalische Verteilung von Daten und Prozessen bei verteilten Systemen. • Data Integration Services: Diese Dienstleistungen unterstützen ein höheres semantisches Niveau für die Handhabung der Daten im Repository. Dazu gehören die Versions- und Konfigurationsverwaltung sowie der Datenaustausch mit anderen CASE-Systemen. Zudem können Metadaten verwaltet werden. • Tool Slots: Sie nehmen die Werkzeuge des CASE-Systems auf, wobei jedes Stück Software, das nicht Teil des Rahmens des CASE-Systems ist und das Dienstleistungen dieses Rahmens in Anspruch nimmt, ein Werkzeug ist.

WERSP - Werkzeugunterstützung

der

Systemplanung

75

Werkzeuge erweitern die allgemeinen Dienstleistungen, um spezielle Anwendungen zu unterstützen. • Task Management Services: Diese Dienstleistungen erlauben es dem Benutzer, auf der Ebene der zu erledigenden Aufgaben mit dem CASE-System zu kommunizieren. Aufrufsequenzen einzelner Werkzeuge können zusammengefaßt, Aufgaben können zusammengefaßt und definiert werden. • Message Services: Diese Dienstleistungen erlauben die Kommunikation zwischen Werkzeugen (intern oder extern über Import-/Export-Schnittstellen), zwischen Dienstleistungen des CASE-Systems sowie zwischen Werkzeugen und Dienstleistungen. • User Interface: Die Benutzungsschnittstelle erlaubt eine konsistente Bedienung des CASE-Systems; sie trennt die Bedienung von der Funktionalität. Für das Projektmanagement werden aus den meisten der genannten Komponenten Informationen erzeugt, die in einer Projektbibliothek abgelegt werden. Mit Hilfe von speziellen Werkzeugen der Projektplanung (vgl. Lerneinheit PROME) ist es dann möglich, permanent eine "Zustandskontrolle" des Projekts durchzuführen und so die Aufgaben der Projektplanung, Projektüberwachung und Projektsteuerung (vgl. Lerneinheit PROPL) besser wahrzunehmen. Geschlossene versus offene CASE-Systeme Ein CASE-System ist geschlossen, wenn die Werkzeuge, die verwendet werden können, fest definiert sind; meist wird für jede Phase im Arbeitsprozeß ein ganz bestimmtes Werkzeug verwendet. Weder können beliebige Werkzeuge verfügbar gemacht, noch können verfügbare Werkzeuge beliebig verwendet werden. Wichtigstes Integrationselement auf dem Weg zu offenen CASE-Systemen ist das zentrale Repository, in welchem das Format der Daten und Schnittstellen zum Anschluß beliebiger, aufeinander abgestimmter Werkzeuge festgelegt ist. Das Konzept der offenen CASE-Systeme läßt also für jede Phase unterschiedliche Werkzeuge zu. Dies ist sinnvoll, weil die Anforderungen an Werkzeuge bzw. die Eignung von Werkzeugen nicht für alle Situationen gleich sind (z.B. bezüglich Projektgröße und Qualifikation der Entwickler). Weiter unterscheiden sich CASE-Systeme darin, ob ein einzelnes, mächtiges Werkzeug oder eine Anzahl verschiedener Werkzeuge verwendet wird. Im ersten CASEFall spricht man von integrierten, im zweiten Fall von verbundenen Systemen. Die Benutzeroberfläche integrierter CASE-Systeme (z.B. DOMINO) ist einheitlich, kann aber sehr komplex sein. Bei Verbundsystemen (z.B. AD/Cycle) hat jedes Werkzeug seine eigene Benutzeroberfläche. Auswirkungen der

Werkzeugunterstützung

Einleitend wurde darauf hingewiesen, daß der primäre Zweck der Werkzeugunterstützung darin besteht, Produktivität und Qualität des Arbeitsprozesses der Systemplanung und seiner Produkte zu verbessern. Aus einer großen Anzahl von Erfahrungsberichten und Befragungen können die folgenden Schlüsse über Auswirkungen der Werkzeugunterstützung gezogen werden:

76

Grundlagen der

Systemplanung

• bessere methodische Unterstützung in allen Phasen der Systemplanung und damit eine größere Disziplin in der Einhaltung von Prinzipien, Regeln und Verfahren; • Entlastung von Routinearbeit und dadurch mehr Zeit für kreative Tätigkeiten; • Reduzierung des Schulungsaufwands für alle Projektmitarbeiter durch einheitliche Verwendung und Normierung von Methoden und Werkzeugen; • bessere Bewältigung der Komplexität durch die klare Strukturierung des Projekts und die Festlegung der dazu notwendigen Schnittstellen und Verantwortlichkeiten (für alle Projektmitarbeiter überschaubar); • Möglichkeit von Parallelarbeit in größeren Projektteams bei zentraler Koordination des Projekts, und - durch den Einsatz von PCs und Workstations - weitgehende Entkopplung der Arbeitsplätze von einem zentralen System; • präzise und einheitliche Darstellung, z.B. durch die automatische Erstellung von Strukturdiagrammen und strukturierte Dokumentation; • Reduzierung der Projektdauer und der Projektkosten, z.B. durch bessere Planungs-, Überwachungs- und Steuerungsmöglichkeiten des Projektfortschritts in bezug auf Termine, Kosten und benötigte Hilfsmittel; • Steigerung der Produktivität, z.B. durch die Senkung des manuellen Aufwands in allen Phasen und durch Entlastung von Routinearbeiten (Angaben zwischen Faktor 2 und Faktor 10); • Verbesserung der Produktqualität (Angaben bis zu 50%, gemessen in der Anzahl Fehler im Endprodukt). Einführung der Werkzeugunterstützung Auf der Grundlage dieser Erfahrungen (sowie der nachfolgenden Forschungsbefunde) können die folgenden Hinweise für die Einführung der Werkzeugunterstützung gegeben werden: • Entwicklung eines eigenen oder Übernahme eines Vorgehensmodells (wie es z.B. vom einzuführenden CASE-System verwendet wird); • Vermittlung des in den Werkzeugen verwendeten Methodenwissens an die Projektmitarbeiter vor Einführung der Werkzeugunterstützung; • Erfolge (insbes. drastische Verbesserung von Produktivität und Qualität) dürfen nicht kurzfristig erwartet werden; • Werkzeugunterstützung muß als Technologie-Investition zur grundlegenden Innovation von Arbeitsprozessen verstanden werden; • nachhaltige Unterstützung der Technologie-Investition durch das Management; • mit Pilotprojekten Erfahrung im Umgang mit der Werkzeugunterstützung sammeln (Lernkurve); • schnelle Klärung von Rückfragen an den Hersteller/Anbieter sicherstellen (Hot-Line). Als Schulungsaufwand zur Einarbeitung werden ein bis zwei Wochen angegeben. Die Schulung sollte beim Anwender erfolgen und alle potentiellen Benutzer einbeziehen.

WERSP - Werkzeugunterstützung

der Systemplanung

77

Demonstrationsbeispiel Es wird die Architektur des CASE-Systems Information Engineering Facility (abgekürzt: IEF) gezeigt. IEF unterstützt alle Phasen, von der strategischen Definition der Anforderungen über die Analyse- und Designphase bis zur automatischen Code-Generierung. IEF basiert auf einem von J. Martin entwickelten und als Information Engineering bezeichneten Vorgehen, das in die folgenden sieben Phasen gegliedert ist: • Information Strategy Planning: Entwicklungsrahmen und Entwicklungsplan; • Business Area Analysis: Darstellung der Geschäftsbereiche in bezug auf Daten, Funktionen und ihre Interaktionen; • Business System Design: Informationssystem-Entwürfe, bestehend aus Prozeduren, Dialogen, Transaktionen und Menüs; • Technical Design: Datenbank- und Modulentwurf; • Construction: Generierung von Anwendungsprogrammen und Datenbanken; • Transition: Ersetzen des alten Systems durch das neue System; • Production: Performance-Messungen und Tuning-Maßnahmen. PCs/Workstations Zentralrechner

Zentrales Kernsystem

zentrale Enzyklopädie offene Schnittstelle

MaskenGenerator CodeGenerator Kernsystem

DatenbankGenerator

VJl

andere Generatoren, Werkzeuge, usw.

Abb. WERSP-2: Architektur von IEF

IEF ist Mainframe-basiert; einige Teile - Phasen 1 bis 4 - sind auf dem PC verfügbar, die übrigen auf dem zentralen Großrechner. Die Analyse- und Entwurfsmodelle werden auf PCs erzeugt und bearbeitet, wobei hochauflösende Farbgrafik, Fenstertechnik, Pull-Down- und Pop-Up-Menüs in Verbindung mit Maussteuerung eingesetzt werden. Die übergreifende Integration, Freigabe und Generierung von Ergebnissen erfolgt auf dem Großrechner. Abbildung WERSP2 zeigt die Architektur von IEF. In der auf dem Großrechner geführten Entwicklungsdatenbank werden alle Projektdaten verwaltet. Die Enzyklopädie ist als DB2-Datenbank implementiert.

78

Grundlagen der

Systemplanung

Für die unterschiedlichen Sichtweisen auf das zu entwickelnde System (z.B. Daten, Prozesse, Interaktionen) stehen verschiedene Darstellungsmittel zur Auswahl; sie können zum Teil automatisch durch Transformationsbefehle ineinander übergeführt werden. Änderungen in einer Darstellung werden in der lokalen Enzyklopädie gespeichert. Alle Modelle, die auf dieser Enzyklopädie aufbauen, übernehmen diese Änderungen automatisch. Die Funktionalität des Systems ist auf folgende drei Komponenten aufgeteilt: • Planungskomponente für die Entwicklung und Darstellung der Informationsarchitektur (z.B. Organisationshierarchie, Datenmodelle, Funktionsdiagramme); • Analysekomponente für die Darstellung der Systemanforderungen (u. a. E/R-Diagramme, Procedure-Action-Diagramme, Hierarchie-Digramme, Konsistenzprüfung); • Designkomponente für die Detailspezifikation der Systemlösung (u.a. Dialogflußdiagramme, Bildschirmentwürfe, Prototyping). Forschungsbefunde G. H. Boone et al., CASE Research Corporation, berichten aus Befragungen von Anwendern unter anderem über die folgenden Nutzeffekte durch den Einsatz von CASE-Werkzeugen: Die Qualität wurde um fast 50%, die Produktivität um 17% verbessert. Die Kommunikation zwischen den am Arbeitsprozeß Beteiligten wurde um etwa 25% intensiviert. Die Einhaltung der Projekttermine wurde um etwa 2% verbessert. K. Jones, Butler Cox, berichtet über Anwendererfahrungen mit CASE-Werkzeugen (Befragung von 75 Unternehmen unterschiedlicher Wirtschaftszweige in Großbritannien und Untersuchung von 800 Projekten, Untersuchungszeitraum 1991) und vergleicht diese mit deren Erwartungen anhand von zehn potentiellen Nutzeffekten; im Ergebnis liegen bei neun potentiellen Nutzeffekten die Erfahrungen unter den Erwartungen, lediglich beim letzten der nachfolgend genannten potentiellen Nutzeffekte liegen die Erfahrungen über den Erwartungen. • • • • • • • • • •

Beschleunigung des Entwicklungsprozesses; Reduzierung der Entwicklungskosten; Verbesserung der Ergebnisqualität; Reduzierung des Wartungsaufwands; Verbesserung der Unterstützung strategischer Unternehmensziele; Standardisierung der verwendeten Methoden und Verfahren; Unterstützung des Information Engineering oder anderer Ansätze; Reduzierung der Mitarbeiteranzahl für die Systementwicklung; Gewinnung von Wissen über das Unternehmen und dessen Dokumentation; Verbesserung der Qualifikation des Entwicklungspersonals.

Aus diesen und anderen zitierten Befunden (z.B. Socrates Project at SERC Software Engineering Research Centre, Utrecht) werden die folgenden Schlußfolgerungen gezogen: CASE-Werkzeuge haben sich in einigen Unternehmen als nutzbringend erwiesen. Für die meisten Unternehmen haben sich insbesondere integrierte CASE-Werkzeuge als zu wenig flexibel und daher von begrenztem

WERSP - Werkzeugunterstützung

der Systemplanung

79

Nutzen erwiesen. Entweder sind die Anwender nicht ausreichend auf den Werkzeugeinsatz vorbereitet, oder die Werkzeuge sind nicht weit genug entwickelt, um den Anforderungen der Anwender entsprechen zu können. Jedenfalls erweist sich nach dieser Untersuchung die Annahme als unzutreffend, durch Investitionen in CASE-Werkzeuge die Informationssystem-Planung drastisch verbessern zu können. Kontrollfragen 1. 2. 3. 4. 5.

Welche Zwecke verfolgt die Werkzeugunterstützung der Systemplanung? Welcher Zusammenhang besteht zwischen Methodik, Methode und Werkzeug? Welcher Zusammenhang besteht zwischen Phasenschema und Vorgehensmodell? Welches sind die wesentlichen Eigenschaften von CASE-Systemen? W i e sollte bei der Einführung der Werkzeugunterstützung vorgegangen werden?

Quellenliteratur Balzert, H.: C A S E . Systeme und Werkzeuge. 4. A., BI Wissenschaftsverlag, Mannheim et al. 1992 Chroust, G.: Modelle der Software-Entwicklung. Oldenbourg Verlag, München/Wien 1992

Vertiefungsliteratur Bertram, H. et al.: C A S E in der Praxis. Softwareentwicklungsumgebungen en für Informationssysteme. Springer Verlag, Berlin et al. 1993 Hausen, H.-L., Müllerburg, M. und Sneed, H. M.: Software-Produktionsumgebungen. Verlagsgesellschaft Müller, Köln-Braunsfeld 1985 Jones, K. (Butler Cox): The lack of benefits realised through C A S E . Handouts, C o n f e r e n c e "CASE - Der Weg ist ein Ziel", März 1992 N o m i n a Information Services (Hrsg.): ISIS Software Report und ISIS Personal C o m p u t e r Report, jeweils aktuelle Auflage Österle, H. (Hrsg.): Anleitung zu einer praxisorientierten Software-Entwicklungsumgebung. Bd. 1, Erfolgsfaktoren werkzeugunterstützter Software-Entwicklung. AIT Verlag, H a l b e r g m o o s 1988

AUTER - Aufgabenträger der Systemplanung Lernziele Sie kennen die Personen und Gruppen ("Aufgabenträger"), die an einem Projekt der Systemplanung mitwirken. Sie können die Aufgaben der einzelnen Aufgabenträger beschreiben. Sie erkennen die Bedeutung des Zusammenwirkens der Aufgabenträger in der Projektgruppe und erkennen, warum Werkzeuge der Systemplanung die Gruppenarbeit unterstützen sollten. Sie wissen, warum bei der Bildung der Projektgruppe und bei der Zusammenarbeit in der Projektgruppe Probleme entstehen können. Definitionen und Abkürzungen Aufgabenträger (task bearer) = eine Person oder eine Gruppe, der eine Aufgabe verantwortlich zur Aufgabenerfüllung übertragen wird. Auftraggeber (orderer) = die Organisation (bei externer Auftragsvergabe) oder die Struktureinheit einer Organisation (bei interner Auftragsvergabe), die ein Projekt der Systemplanung in Auftrag gibt. Auftragnehmer (contractor) = die Organisation (bei externer Auftragsvergabe) oder die Struktureinheit einer Organisation (bei interner Auftragsvergabe), welche mit der Durchführung eines Projekts der Systemplanung beauftragt ist. Beteiligter (participant) = eine Person oder Gruppe, die nicht professionell mit der Systemplanung betraut ist oder die nicht deren Auftraggeber repräsentiert. C S C W = Abkürzung für Computer Supported Cooperative Work oder (besser) Computer Support for Cooperative Work. Groupware = Software zur Unterstützung von Gruppenarbeit. Kommunikation (communication) = der Austausch von Information zwischen den Elementen eines Systems und zwischen offenen Systemen. Kompetenz (competence) = der Handlungsspielraum eines Aufgabenträgers, der zur ordnungsgemäßen Aufgabenerfüllung erforderlich ist. Lenkungsausschuß (steering committee) = die organisatorische Instanz, welche die Planungsziele vorgibt und die IuK-Projekte unternehmensweit steuert. Produktmanager (product manager) = ein Aufgabenträger für die Aufgabe der Betreuung eines IuK-Systems über dessen gesamten Lebenszyklus hinweg, also mit der Initiierung eines IuK-Projekts beginnend. Projektgruppe (project team) = die für ein Projekt eingesetzte Anzahl von Personen, die von einem für die Projektdurchführung verantwortlichen Projektleiter geführt wird. Synonyme: Projektteam, Planungsgruppe. Projektorganisation (project Organization) = die Art und Weise, in der ein Projektleiter eine Projektgruppe führt und die projektbezogenen Aufgaben beeinflussen kann. Qualifikation (qualification) = die Gesamtheit des Wissens und des Könnens (Fähigkeiten und Fertigkeiten) einer Person oder Gruppe. Systemplaner (systems analyst) = ein Aufgabenträger, der eine besondere Qualifikation für die Aufgaben der Systemplanung besitzt. Synonym: Systemanalytiker.

A UTER - Aufgabenträger

der Systemplanung

81

Aufgabenträger der Systemplanung (Überblick) An einem Projekt der Systemplanung wirken mehrere Aufgabenträger als Personen und als Gruppen mit. Dazu gehören: • • • • •

der der die die der

Lenkungsausschuß, Projektleiter, Projektgruppe, Benutzer, Koordinator.

Außerdem sind Personen an einem IuK-Projekt beteiligt, die als Repräsentanten des Auftraggebers und als Repräsentanten des Auftragnehmers agieren (z.B. der Produktmanager als Repräsentant des Auftraggebers). Im folgenden werden die Aufgaben dieser Aufgabenträger erläutert. Wegen der großen Bedeutung, die Gruppen bei der Systemplanung zukommt, wird auf die Gruppenbildung und die Zusammenarbeit in Gruppen eingegangen. Lenkungsausschuß Personell gesehen ist der Lenkungssausschuß ein aus Mitgliedern des Top-Managements, des Fachabteilungsmanagements und des Managements der IKS-Abteilung ("EDV/ORG-Abteilung") bestehendes Gremium. Er ist für die strategische Planung der Informationsverarbeitung unternehmensweit zuständig. Der Lenkungsausschuß erstellt das Projektportfolio, gibt die Planungsziele für jedes IuK-Projekt vor und erteilt die Projektfreigabe. Neben den Planungszielen für jedes IuK-Projekt legt der Lenkungsausschuß die Nebenbedingungen für die Projektdurchführung fest (vgl. Lerneinheiten ZAMVS und PROPL); er bestimmt die Projektorganisation und ernennt den Projektleiter. Der Projektleiter berichtet an den Lenkungsausschuß. Projektleiter Unabhängig davon, welche Projektorganisation (vgl. Lerneinheit PROPL) verwendet wird, hat der Projektleiter die Aufgabe, ein Projekt zu planen, zu überwachen und - j e nach Projektorganisation in unterschiedlicher Weise steuernd einzugreifen, wenn der Projektablauf den Projektzielen nicht entspricht. Den vollen Aufgabenunifang der Planung, Überwachung und Steuerung eines Projekts hat der Projektleiter bei der reinen Projektorganisation und bei der Projektorganisation in Verbindung mit Linienfunktionen; davon wird im folgenden ausgegangen. Projektleitung umfaßt die folgenden Aufgaben: • • • •

das Projekt planen ("Projektplanung"); das Projekt überwachen ("Projektüberwachung"); das Projekt steuern ("Projektsteuerung"); die Erreichung der Projektziele gegenüber dem Auftraggeber und den Projektmitarbeitern verantworten ("Projektverantwortung"); • die Projektmitarbeiter führen ("Projektführung"); • das Projekt, die Projektmitarbeiter und den Auftragnehmer bzw. den Auftraggeber repräsentieren ("Projektrepräsentation").

82

Grundlagen der Systemplanung

Anforderungen an die Qualifikation des Projektleiters sind: Kontaktfreudigkeit, Geduld, Beharrlichkeit, Durchhaltevermögen, Kreativität, Sachkenntnisse, Menschenkenntnis, Organisationstalent, Unternehmens- und Fachabteilungskenntnisse. Bei einem Projekt mit zahlreichen Beteiligten und mit Durchsetzungsproblemen in den Fachabteilungen sind die persönlichen Fähigkeiten wichtiger als die fachlichen Kenntnisse; umgekehrt braucht man für ein Projekt mit einer kleinen Projektgruppe eher einen Projektleiter mit guten fachlichen Kenntnissen. Zweck der Projektgruppe IuK-Projekte scheitern erfahrungsgemäß seltener an der Schwierigkeit der Planungsaufgabe als an der mangelnden Bereitschaft oder Fähigkeit der beteiligten Personen. Um ein Projekt erfolgreich abwickeln zu können, sind daher in erster Linie die personellen Voraussetzungen zu klären, die zur Bildung einer Projektgruppe führen, welche bezüglich ihrer Zusammensetzung in quantitativer und in qualitativer Hinsicht den Projektzielen angemessen ist. Wichtige Eigenschaften der Projektgruppe sind: • • • • •

die die das die die

Identifikation der Mitglieder der Gruppe mit den Projektzielen; Fähigkeit zur Zusammenarbeit in der Gruppe; Fachwissen der Mitglieder der Gruppe; Führungsqualifikation des Projektleiters; Fähigkeit zur Kommunikation mit dem Auftraggeber.

Die Größe der Projektgruppe muß sorgfältig überdacht werden. Eine zu kleine Gruppe kann ebenso unzweckmäßig sein wie eine zu große Gruppe. Nach dem Brook'schen Gesetz steigt der Kommunikationsaufwand mit zunehmender Gruppengröße überproportional, sodaß jedes weitere Gruppenmitglied oberhalb der optimalen Gruppengröße abnehmende Beiträge zum Projektfortschritt liefert. Ein in Terminnot geratenes Projekt kann durch zusätzliche Gruppenmitglieder nicht gerettet werden; bis diese in der Lage sind, einen Beitrag zum Projektfortschritt zu leisten, wird der kritische Termin erreicht, und sie behindern bis dahin nur die Arbeit der "alten" Gruppenmitglieder. Merkmale der Projektgruppe "Gruppe" bezeichnet jedes kontinuierliche Zusammenwirken mehrerer Personen zur Erreichung bestimmter Ziele, hier also das Zusammenwirken der Mitglieder der Projektgruppe zu Erreichung der Projektziele ("Kooperation"). Kooperation erfordert Koordination, f ü r deren Abwicklung Kommunikation zwischen den Gruppenmitgliedern erforderlich ist. Darüber hinaus ist die Gruppe durch folgende Gruppenmerkmale gekennzeichnet: • das gemeinsame Verhaltensmotiv, das aus den gemeinsamen Zielen folgt; • ein System von Normen zur Regelung der Beziehungen zwischen den Mitgliedern der Gruppe; • das Vorhandensein eines Rollendifferentials, also eines zusammenhängenden Verhaltensschemas auf Grund von Position, Rolle und Status in der Gruppe; • ein mehr oder weniger komplexes Geflecht gefühlsmäßiger Wechselbeziehungen zwischen den Mitgliedern der Gruppe ("Wir-Gefühl").

AUTER - Aufgabenträger

der Systemplanung

83

Bei der Projektgruppe handelt es sich um eine Gruppe, die durch eine strenge Zielbezogenheit, durch einen hohen Grad an Organisiertheit und durch einen relativ hohen Grad an Unpersönlichkeit der Beziehungen zwischen den Mitgliedern gekennzeichnet ist. Entscheidend für den Gruppenerfolg (und damit für den Projekterfolg) sind Kommunikationsprozesse und wechselseitige Lernprozesse zwischen den Mitgliedern der Projektgruppe. Bilden der Projektgruppe Organisatorisch gesehen sind Gruppen Teilsysteme des Gesamtsystems "Organisation". Durch die Bildung von Gruppen kann bestimmten organisatorischen Erfordernissen besser Rechnung getragen werden, als dies ohne Gruppenbildung möglich wäre. Für die Gruppenbildung gibt es organisatorische Gliederungsprinzipien, insbesondere: • • • • •

nach nach nach nach nach

den Arbeitsergebnissen, der Art der Arbeitsaufgabe ("Verrichtung"), den individuellen Fähigkeiten und Kenntnissen, der Arbeitszeit, dem Arbeitsort.

Die Gliederungsprinzipien überschneiden sich in der Organisationspraxis. Bei der Bildung der Projektgruppe f ü r die Systemplanung steht das Gliederungsprinzip nach den Arbeitsergebnissen im Vordergrund. Dies ergibt sich aus dem Projektcharakter der Systemplanung. o o o o o o o o o o o o

Kann Leistungen vollbringen, die einem Einzelnen überhaupt nicht möglich sind Besseres Urteilsvermögen Bessere Möglichkeit der Informationsübermittlung Größere Kontaktintensität Verfügt über verschiedene Fähigkeiten und Kenntnisse, die sich ergänzen können Größere Kapazität für die Speicherung von Informationen Der Erhebungsaufwand für Informationen und ihre Abrufzeit sind geringer Mehr Kontrolle über die Zieleinhaltung Bessere Lernfähigkeit Bessere Möglichkeiten für den Einsatz von Hilfsmitteln Vorteil der kollektiven Kontrolle Anreicherung des kreativen Potentials, weil sich die Assoziationsfelder der Gruppenmitglieder ergänzen Abb. AUTER-1: Katalog möglicher Gruppenvorteile (Quelle: Schanz)

Systemplanung erfordert Gruppenbildung, da nur die Gruppe die Projektziele erreichen kann. Die Projektziele sind auch für eine Mehrzahl isolierter Individuen nicht erreichbar. Die Projektgruppe hat also eine instrumentelle Bedeutung. Abbildung AUTER-1 zeigt verschiedene Tatbestände, welche die über eine Menge von Individualleistungen hinausgehende Gruppenleistung begründen ("Gruppenvorteile"). Darüber hinaus gilt, daß Gruppen dem Individuum häufig ein "Modell richtigen Verhaltens" zur Verfügung stellen, an dem es sich orientieren kann ("Verhaltenskonformität durch Normenbildung"). Dieses "Lernen am Modell" spielt vor allem im Zusammenhang mit der Benutzerbeteiligung eine Rolle.

84

Grundlagen der

Systemplanung

Probleme der Projektgruppe Probleme bei der Bildung der Projektgruppe und bei der Zusammenarbeit in der Projektgruppe entstehen häufig durch: • personelle Engpässe, • unklare Kompetenzen und Aufgabenabgrenzungen, • mangelnde Kommunikationsbereitschaft der Systemplaner. Personelle Engpässe: Diese treten auf der Seite der Systemplaner deshalb auf, weil ein immer höherer Arbeitsanteil auf die Wartung installierter IuK-Systeme entfällt (in Einzelfällen wird von bis zu 80% der Arbeitskapazität berichtet). Die Systemplaner versuchen daher, Aufgaben in die Fachabteilungen zu verlagern und eine intensivere Benutzerbeteiligung zu erreichen. Diese Verlagerung setzt aber voraus, daß auf der Seite der Benutzer Arbeitskapazität verfügbar ist und daß die Benutzer auf Projektdauer oder für bestimmte Projektphasen zumindest teilweise von Fachabteilungsaufgaben freigestellt werden. Sie setzt weiter voraus, daß die Benutzer eine für die Systemplanung ausreichende Qualifikation haben. Häufig fehlt es an einer dieser Voraussetzungen oder auch an beiden. Unklare Kompetenzen und Aufgabenabgrenzungen: Die Zusammenarbeit zwischen Systemplanern und Benutzern setzt voraus, daß die Kompetenzen der beteiligten Abteilungen, und damit die Abgrenzung der Aufgaben im Projekt, klar geregelt sind. Dies wird durch die Tatsache erschwert, daß je nach Projekt und somit j e nach den beteiligten Fachabteilungen unterschiedliche Kompetenzregelungen und Aufgabenabgrenzungen erforderlich sind, die abhängig sind: • • • • •

von von von von von

der Komplexität des zu schaffenden IuK-Systems; den Fachbabteilungskenntnissen der Systemplaner; den Systemplanungskenntnissen der Benutzer; der in der Fachabteilung verfügbaren Zeit; den zur Verfügung stehenden Methoden und Werkzeugen.

M a n g e l n d e Kommunikationsbereitschaft verschiedene Erscheinungsformen, wie:

der Systemplaner: Diese hat

• Die Tendenz, aus der Systemplanung eine "Geheimwissenschaft" zu machen: "Dies zu erklären, hat keinen Sinn. Der Sachverhalt ist so kompliziert, daß Sie ihn doch nicht begreifen." • Die mangelnde Bereitschaft, das Gespräch mit der Fachabteilung zu suchen: "Das bringt nichts! Ich bekomme doch nur unsinnige Wünsche zu hören." • Die unverständliche Präsentation von Projektergebnissen: "Die Lösung ist so gut, daß sie keiner Begründung bedarf." • Die bewußte oder unbewußte Ausrede, daß die Arbeitsüberlastung einen intensiveren Kontakt nicht zuläßt. • Die mangelnde Bereitschaft, die Benutzer zu schulen. Bei der Bildung der Projektgruppe und bei der Gestaltung der Zusammenarbeit zwischen den Mitgliedern der Projektgruppe ist also darauf zu achten, daß Personalkapazität und Personalqualifikation in einem ausreichenden Umfang, sowohl auf der Seite der Systemplaner als auch auf der Seite der Benutzer, vor-

A UTER - Aufgabenträger

der Systemplanung

85

handen sind. Darüber hinaus sind die Kompetenzen im Systemplanungsprozeß klar abzugrenzen und damit die Aufgaben eindeutig auf Systemplaner und Benutzer zuzuordnen. Benutzer Benutzer ist jede Person oder Gruppe, die ein IuK-System bei der Aufgabenerfüllung unterstützend verwendet bzw. verwenden wird. Daß Benutzer an der Systemplanung beteiligt werden, ist heute unbestritten. Unterschiedliche Auffassungen bestehen über die Form der Benutzerbeteiligung. I n f o r m a t i k - S t r a t e g i e n machen auch Aussagen darüber, welche Rolle der Mensch als Komponente der Informationsinfrastruktur spielen soll (vgl. Lerneinheit STRAT im Band "Informationsmanagement"). Die organisatorische Umsetzung der definierten Rolle des Menschen erfolgt unter anderem durch Methoden der Benutzerbeteiligung. Diese Methoden zielen darauf ab, die (zukünftigen) Benutzer eines IuK-Systems in die Systemplanung so einzubeziehen, daß sie, bei ausreichender Berücksichtigung der von ihnen eingebrachten sozialen Ziele, die Erreichung der technischen und der betriebswirtschaftlichen Ziele unterstützen. Dies entspricht im Kern dem konsensorientierten Ansatz. Der konsensorientierte Ansatz geht davon aus, daß die Bewertung eines IuKSystems nicht allein nach technischen und betriebswirtschaftlichen Zielen erfolgen kann, sondern auch nach dessen Funktionsweise im Anwendungskontext erfolgen muß, also z.B. nach seiner Akzeptanz durch die Benutzer. Er setzt voraus, daß ein Interessensausgleich zwischen den Beteiligten (Informationsmanagement, Systemplaner, Fachabteilungsmanagement, Benutzer) möglich ist und daß dieser zu einer Systemalternative führt, die für alle Beteiligten von Vorteil ist. Systemplaner verstehen sich dabei primär als Berater und Vermittler, weniger als Interessensvertreter, der entweder die Benutzer bei der Erarbeitung von Lösungsalternativen unterstützt oder der diese selbst erarbeitet und zur Diskussion und Auswahl stellt (vgl. Lerneinheit BEBET im Band "Informationsmanagement".) Koordinator Eine Verbesserung der Zusammenarbeit zwischen Systemplanern und Benutzern wird durch den Koordinator (auch: "EDV-Koordinator") erreicht. Seine Aufgabe besteht darin, den Informationsfluß zwischen der IKS-Abteilung und der Fachabteilung, für die er zuständig ist, sowohl bezüglich der Aufgaben der Systemplanung als auch der Aufgaben der späteren Systemnutzung sicherzustellen. Verglichen mit den Benutzern ist er der Experte der Fachabteilung. Er ist entweder fachlich und disziplinarisch dem Leiter der IKS-Abteilung oder dem Leiter der Fachabteilung unterstellt, oder beide Abteilungsleiter führen den Koordinator gemeinsam. Aus der Sicht der Fachabteilung ist einer fachlichen und disziplinarischen Unterstellung des Koordinators unter den Leiter dieser Abteilung der Vorzug zu geben; sein Arbeitsplatz ist damit auch in der Fachabteilung. Für Projekte der Systemplanung, die Aufgaben seiner Fachabteilung betreffen, ist der Koordinator Mitglied der Projektgruppe.

86

Grundlagen

der

Systemplanung

Werkzeuge für Gruppenarbeit Gruppenarbeit ist unter anderem durch Kooperation gekennzeichnet; diese erfordert Koordination und setzt Kommunikation voraus. Werkzeuge für Gruppenarbeit ("Groupware") unterstützen daher die Koordination und stellen Kommunikationswege zur Verfügung. Für die Unterstützung von Projektgruppen sind jedoch weniger spezifische Groupware-Produkte (wie z.B. MeetingWare und GroupSystems) von Bedeutung, sondern mehr solche CASE-Werkzeuge (vgl. Lerneinheit WERSP), die neben den Sachaufgaben der Systemplanung die Koordination unterstützen und Kommunikationswege zur Verfügung stellen. Dies ist bei den heute verfügbaren Produkten im wesentlichen nicht der Fall (vgl. den Abschnitt Forschungsbefunde). Demonstrationsbeispiel Es werden die Struktur und inhaltliche Beispiele der Stellenbeschreibung für einen Projektleiter gezeigt. Projektbezeichnung: Vertriebsinformationssystem. Organisatorische Einordnung: • Der Projektleiter ist in allen Projektbelangen dem Lenkungsausschuß unterstellt. • Für die Projektdauer sind ihm folgende Mitarbeiter unterstellt: A, B, C, ... • Vom gesamten, das Projekt betreffenden Schriftverkehr ist der Projektleiter unaufgefordert zu informieren. • Der Projektleiter ist ermächtigt, sämtliche Außenkontakte in den Projektbelangen zu führen. Stellvertretung: • Der Projektleiter wird in allen Projektbelangen durch den Produktmanager vertreten. • Ist der Produktmanager verhindert, übernimmt die Projektleitung der Leiter der IKS-Abteilung. Kompetenzen und Aufgaben: • Der Projektleiter ist für die Projektdurchführung entsprechend den Planungszielen bezüglich Termine, Kosten und Leistungen verantwortlich. • Er führt alle Verhandlungen mit Auftragnehmern und Auftraggebern, die im Zusammenhang mit dem Projekt stehen. • Er wählt zusammen mit dem Produktmanager und den Leitern der Abteilungen Vertrieb und Marketing die Projektmitarbeiter aus. • Er entwickelt aus den Planungszielen die Projektziele, mit denen er das Projekt planen, überwachen und steuern wird, sowie in Zusammenarbeit mit den Abteilungen Vertrieb und Marketing alle notwendigen Planungsunterlagen. • Er hält die notwendigen Kontakte mit den Auftraggebern (Abteilungen Vertrieb und Marketing). • Er entscheidet in allen Projektbelangen über die Termine, die Kosten und die Leistungen, solange er sich im Rahmen der Planungsziele bewegt. • Er plant, überwacht und steuert die Termine, die Kosten und die Leistungen.

AUTER - Aufgabenträger

der Systemplanung

87

• Er berichtet regelmäßig dem Produktmanager sowie den Leitern der Abteilungen Vertrieb und Marketing über den Stand und den Fortgang des Projekts; er berichtet unverzüglich, wenn sich negative Abweichungen von den Projektzielen abzeichnen. • Er holt regelmäßig von den am Projekt beteiligten externen Stellen (z.B. von Software-Häusern) Informationen über den Projektstatus ein und überprüft sie. • Er beruft bei Bedarf Besprechungen zwischen den am Projekt Beteiligten ein. Forschungsbefunde L. J. Heinrich berichtet über empirische Befunde zur Frage, warum Projekte der Systemplanung scheitern oder notleidend werden, das heißt ihre Kosten-, Termin- und/oder Leistungsziele nicht erreichen (Untersuchungszeitraum 1986 bis 1987). Folgende Befunde bezüglich der Aufgabenträger wurden durch mit Moderationstechnik unterstützte Befragung von Seminarteilnehmern sowie durch die Untersuchung eines größeren Projekts erhoben (wegen weiterer Befunde zur Projektplanung vgl. Lerneinheit PROPL): • • • • •

Fluktuation der Projektmitarbeiter; fehlende Kompetenz und/oder Qualifikation des Projektleiters; unklare Aufgabenabgrenzung zwischen Auftraggeber und Auftragnehmer; mangelhafte Kommunikation zwischen Auftraggeber und Auftragnehmer; Zweifel der Projektmitarbeiter an der technischen Machbarkeit und an der eigenen Leistungsfähigkeit; • Meinungsverschiedenheiten in der Projektgruppe über die Yorgehensweise; • mangelnde Einbindung der Benutzer in das Projekt; • unterschiedliches Verständnis über die Planungs- und Projektziele bei Auftraggeber und Auftragnehmer sowie unter den Mitgliedern der Projektgruppe. Die häufigsten Nennungen beider Untersuchungen konzentrieren sich auf die Ursachen mangelhafte Qualifikation der Beteiligten und unklare A u f g a b e n a b grenzung zwischen Auftraggeber und Auftragnehmer. Qualifikationsdefizite sind bei allen Beteiligten festzustellen: beim Management, bei den Projektleitern, bei den Projektmitarbeitern und bei den Benutzern. Der wichtigste Ansatzpunkt für die Verringerung des Risikopotentials der Systemplanung ist folglich eine bessere Ausbildung aller Beteiligten, die sowohl eine Verbesserung der fachlichen Qualifikation als auch der Führungsqualifikation zum Ziel haben muß. Vessey/Sravanapudi kommen auf Grund einer Untersuchung von vier CASEWerkzeugen (Untersuchungszeitraum 1992) zu folgenden Ergebnissen bezüglich ihrer Eigenschaft, Gruppenarbeit zu unterstützen: CASE-Werkzeuge unterstützen nur wenige Funktionen, die typisch für Gruppenarbeit sind. Beispiele für Befunde sind: Am besten unterstützt wird die Kontrolle von Nebenläufigkeit; Zugriffskontrolle wird nicht gut unterstützt; die Aktivitäten der Werkzeugbenutzer werden nicht überwacht; das Verfolgen von Änderungen in der Datenbasis wird kaum unterstützt; Kommunikationsmöglichkeiten werden kaum zur Verfügung gestellt. Zusammenfassend wird festgestellt, daß die untersuchten CASEWerkzeuge auf den einzelnen Werkzeugbenutzer zugeschnitten sind; sie sind keine Mehrbenutzer-Werkzeuge.

88

Grundlagen

der

Systemplanung

M. Wollnik hat mit einer Erhebung von 29 IuK-Prozessen (Erhebungszeitraum nicht a n g e g e b e n , vermutlich Ende der 80-er Jahre) gefunden, daß nach weitgehend übereinstimmender Auffassung von Systemplanern und Leitern von Fachabteilungen die R o l l e n v e r t e i l u n g w e d e r projektspezifisch noch projektübergreifend f o r m a l geregelt ist; sie scheint vielmehr kraft allgemeiner, nicht projektbezogener Kompetenzen und Aufgabenstellungen typisch erwartet zu werden. Die am Projekt Beteiligten treten überwiegend so auf, daß diese Erwartungen bestätigt werden. Es scheint so, daß ein "Hintergrund informaler Erwartungen" den H a n d l u n g s s p i e l r a u m bei der Projektabwicklung einschränkt und f o r m a l e Regelungen möglicherweise abfälschen kann. Spinas/Weber haben mit einer empirischen Untersuchung zur B e n u t z e r b e t e i l i g u n g (Fragebogenerhebung bei 65 Benutzern, 61 Entwicklern und 31 Führ u n g s k r ä f t e n in z e h n Unternehmen; Untersuchungszeitraum nicht a n g e g e b e n , vermutlich 1989) den Projekterfolg h e m m e n d e und fördernde Faktoren der Zus a m m e n a r b e i t zwischen Entwicklern und Benutzern erhoben. H e m m e n d e Faktoren der Z u s a m m e n a r b e i t sind: Kommunikationsprobleme, Zeitdruck, zu große Projektgruppen, Konzeptlosigkeit, Sturheit und Arroganz der Entwickler, Nichtb e a c h t u n g von B e n u t z e r w ü n s c h e n . Fördernde Faktoren der Z u s a m m e n a r b e i t sind: frühzeitige, enge Kooperation, Qualifizierung der Benutzer, längere Vorbereitungszeiten, gute zwischenmenschliche Kontakte. Kontrollfragen 1. 2. 3. 4. 5.

Welche Warum Welche An wen Welche

Aufgabenträger sind an einem IuK-Projekt beteiligt? bedarf ein IuK-Projekt einer Gruppe als Aufgabenträger? Schwierigkeiten bereitet die Zusammenarbeit in der Projektgruppe? berichtet im allgemeinen der Projektleiter? Aufgaben hat ein Koordinator in der Projektgruppe?

Quellenliteratur Hansel, J. und L o m n i t z , G.: Projektleiter-Praxis - Erfolgreiche Projektabwicklung durch verbesserte Kommunikation und Kooperation. Springer Verlag, Berlin et al. 1987 Heinrich, L. J.: Schwachstellen und Risiken bei Softwareprojekten. In: Computer und Recht 7/1988, 584 - 587 Klein, H.: Partnerschaft zwischen Fachabteilung und EDV. In: Heilmann, H. (Hrsg.): Z u s a m menarbeit zwischen Fachabteilung und EDV. 9. Jahrbuch der E D V . Forkel Verlag, Stuttgart/ Wiesbaden 1980, 15 - 6 3 K u m m e r , W . et al.: Projekt-Management. Leitfaden zu Methode und Teamführung in der Praxis. 3. A., Verlag Industrielle Organisation, Zürich 1993 M a m b r e y , P. und Oppermann, R.: Benutzerbeteiligung bei der Systementwicklung - Einschätzung der Möglichkeiten durch Experten. In: Angewandte Informatik 3/1985, 1 1 1 - 1 1 9 Schanz, G.: Organisationsgestaltung - Struktur und Verhalten. Verlag Vahlen, München 1982, 211 - 2 3 2 Spinas, O. und W e b e r , D.: Benutzerbeteiligung aus der Sicht von Endbenutzern, Softwareentwicklern und Führungskräften mit Beteiligungserfahrung. In: Ackermann, D. und Ulich, E. (Hrsg.): Software-Ergonomie '91. Benutzerorientierte Software-Entwicklung. Verlag Teubner, Stuttgart 1 9 9 1 , 3 6 - 4 5 Vessey, I. and Sravanapudi, A. P.: Evaluation of Vendor Products: CASE-Tools as Collaborative Support Technologies. Unpublished Paper, Penn. State University 1992 Wollnik, M.: Implementierung computergestützter Informationssysteme. Verlag de Gruyter, Berlin et al. 1986 W o o d , J. and Silver, D.: Joint Application Development. 2. Ed., John Wiley & Sons, New York et al. 1995

Methoden und Techniken der Systemplanung

90

Methoden und Techniken der Systemplanung

In diesem Kapitel werden die Methoden und die Techniken der Systemplanung behandelt. Damit sind - ganz allgemein gesagt - Hilfsmittel gemeint, die geeignet sind, die erfolgreiche Bearbeitung der Aufgaben der Systemplanung zu erleichtern, man sagt auch: zu unterstützen. Die Methoden und Techniken, die in diesem Kapitel behandelt werden, sind so vielfältig verwendbar, daß sie nicht als typisch für eine bestimmte Phase oder gar für eine bestimmte Aufgabe einer Phase der Systemplanung angesehen werden können. Mit anderen Worten: Sie können zur Unterstützung vieler Aufgaben in mehreren Phasen verwendet werden. Deshalb ist es gut, wenn vor dem Einstieg in die Planungsaufgaben Wissen über Methoden und Techniken vorhanden ist. Dies ist gegeben, wenn die im folgenden dargestellten Methoden im wesentlichen bekannt sind. Dabei sollte immer von ihrem Zweck ausgegangen werden, also davon, was eine Methode oder Technik leisten kann. Dies schützt davor, unsystematisch vorzugehen, aber auch davor, das Problemlösungspotential der Methoden und Techniken zu überschätzen.

Methoden und Techniken der Systemplanung ENTAB HIPO SADT DAFLU PENET MATRX WERTA WIRTA NUTZW SIMUL PRAET DARST NETZP TESTM DOKUM

-

Entscheidungstabellen-Technik Hierarchy plus Input-Process-Output Structured Analysis and Design Technique DatenfluBdiagramme Petri-Netze Matrixanalyse Wertanalyse Wirtschaftlichkeitsanalyse Nutzwertanalyse Simulation Prasentationstechniken Darstellungstechniken Netzplantechnik Testmethoden Dokumentationsmethoden

..91 ,.99 .107 ,116 ,127 138 144 152 ,162 ,174 ,185 ,192 ,205 ,215 ,227

ENTAB - Entscheidungstabellen-Technik Lernziele Sie kennen den Zweck der Entscheidungstabellen-Technik und ihre Verwendung in der Systemplanung, die Syntax einer Entscheidungstabelle und die verschiedenen Arten von Entscheidungstabellen. Sie können Entscheidungstabellen aufbauen und diese auf Eindeutigkeit (Vollständigkeit und Redundanz) und auf Widersprüchlichkeit prüfen; Sie können Entscheidungstabellen konsolidieren und zergliedern. Sie kennen Weiterentwicklungen der Entscheidungstabelle und deren Verwendbarkeit beim Knowledge Engineering. Definitionen und Abkürzungen Aktion (action) = eine Maßnahme, die ausgelöst wird, wenn die reale Bedingungskombination mit der in der Entscheidungsregel spezifizierten Bedingungskombination übereinstimmt; Teil der Entscheidungsregel. Aktionsanzeiger (action pointer) = ein Zeichen, das bei begrenzten Entscheidungstabellen angibt, ob die in der gleichen Aktionszeile angegebene Aktion ausgelöst werden soll oder nicht (Aktionsanzeiger "X" oder blank). Aktionsteil (action part) = der Teil einer Entscheidungstabelle, der die Aktionen und die Aktionsanzeiger enthält. Bedingung (condition) = die Voraussetzung für die Auslösung einer Aktion oder einer Aktionsfolge; Teil der Entscheidungsregel. Bedingungsanzeiger (condition pointer) = ein Zeichen, das in begrenzten Entscheidungstabellen angibt, ob die in der gleichen Bedingungszeile angegebene Bedingung erfüllt sein muß ("J"), nicht erfüllt sein darf ("N") oder keinen Einfluß auf die auszulösende Aktion oder Aktionsfolge hat ("-"). Bedingungsteil (condition part) = der Teil einer Entscheidungstabelle, der die Bedingungen und die Bedingungsanzeiger enthält. ELSE-Regel (eise rule) = eine Entscheidungsregel, die bewirkt, daß die in ihr angegebene Aktion oder Aktionsfolge ohne Prüfung von Bedingungen dann ausgeführt wird, wenn keine der vorher angegebenen Entscheidungsregeln zutrifft; wird als letzte Entscheidungsregel der Entscheidungstabelle geschrieben. Entscheidung (decision) = der Prozeß der Auswahl einer Alternative aus einer Menge von Alternativen mit den Phasen Problemerkennung, Informationsgewinnung, Alternativenentwurf, Alternativenbewertung und Auswahl der optimalen Alternative. Entscheidungsregel (decision rule) = eine Regel, die angibt, wie die Auswahl einer Alternative aus einer Menge von Alternativen erfolgen soll. Redundanz (redundancy) = die Tatsache, daß mindestens zwei Entscheidungsregeln in keiner Bedingungszeile über ein Gegensatzpaar "J" - "N" verfügen und im Aktionsteil inhaltlich identisch sind. Unschärfe-Theorie (fuzzy theory) = ein Zweig der Mathematik, dessen Instrumentarium anstelle der klassischen Mengentheorie "unscharfe Mengen" sind. Widerspruch (contradiction) = die Tatsache, daß mindestens zwei Entscheidungsregeln in keiner Bedingungszeile über ein Gegensatzpaar "J" - "N" verfügen und im Aktionsteil inhaltlich verschieden sind.

92

Methoden und Techniken der Systemplanung

Zweck der Entscheidungstabellen-Technik Die Entscheidungstabellen-Technik ist ein Hilfsmittel zur Beschreibung komplexer und unübersichtlicher Entscheidungssituationen durch Entscheidungstabellen. Eine Entscheidungssituation ist komplex und unübersichtlich, wenn die auszuführenden Aktionen nicht sequentiell aufeinanderfolgen, sondern als Voraussetzung für ihre Ausführung zunächst geprüft werden muß, ob bestimmte Bedingungen erfüllt oder nicht erfüllt sind. Eine so gekennzeichnete Entscheidungssituation kann am besten durch die Angabe aller relevanten Entscheidungsregeln beschrieben werden. Die Entscheidungsregeln beinhalten Bedingungen oder Bedingungskombinationen, die anzeigen, wann bestimmte Aktionen oder Kombinationen von Aktionen ("Aktionsfolgen") ausgelöst werden sollen. Die Entscheidungstabellen-Technik kann in der Systemplanung in der Analyse-, Entwurfs- und Implementierungsphase verwendet werden. • In der Analysephase können mit Hilfe der Vollständigkeitsprüfung Sonderfälle der Verarbeitung, die in der Istzustandserhebung nicht erfaßt wurden, logisch abgeleitet werden. Als Beschreibungsmittel werden Entscheidungstabellen von den an der Systemanalyse Beteiligten erfahrungsgemäß akzeptiert. • In der Entwurfsphase unterstützt sie die eindeutige Beschreibung der Methoden bis hin zu Verarbeitungsalgorithmen; sie sichert dabei Vollständigkeit und logische Konsistenz in größerem Maße als andere Beschreibungsmittel (z.B. Programmablaufpläne). • In der Implementierungsphase können Entscheidungstabellen-Vorübersetzer verwendet werden; diese lösen das tabellarische Format der Entscheidungstabelle in eine sequentielle Folge von Anweisungen auf; dabei werden Eindeutigkeit und Vollständigkeit überprüft, und es werden Testhilfen bereitgestellt. Bedingungen, Aktionen und Aktionsanzeiger müssen zuvor manuell in die verwendete Programmiersprache übertragen werden. Der Vergleich der Beschreibung einer Entscheidungssituation durch Entscheidungstabellen mit einer verbalen Beschreibung oder mit einer Darstellung als Programmablaufplan (vgl. Lerneinheit DARST) zeigt, daß bei gleichem logischen Gehalt mit einer Entscheidungstabelle eine übersichtlichere und kompaktere Darstellung zu erreichen ist. Es gibt auch Methoden zur manuellen Codierung von Entscheidungstabellen (Codierung Regel für Regel, Verzweigungsmethode, Veinott-Methode, Binärmuster-Methode). Darüber hinaus ist eine automatische Übersetzung von Entscheidungstabellen in Quellprogramme durch Entscheidungstabellen-Vorübersetzer möglich; sie liefern jedoch meist keine optimalen Programme (z.B. bezüglich Laufzeit). Syntax der Entscheidungstabelle Eine Entscheidungstabelle ist in vier Quadranten gegliedert. Der linke obere Quadrant enthält die Beschreibung der Bedingungen, der rechte obere Quadrant enthält die Bedingungsanzeiger, die zur Definition aller Bedingungskombinationen ("WENN") benötigt werden. Im linken unteren Quadranten sind alle Aktionen beschrieben, und im rechten unteren Quadranten sind mit Hilfe der Aktionsanzeiger alle benötigten Aktionsfolgen ("DANN") definiert. Die in

ENTAB - Entscheidungstabellen-Technik

93

der rechten Hälfte der Entscheidungstabelle befindlichen Teile definieren zusammen alle Entscheidungsregeln. Jede Entscheidungsregel ordnet einer Bedingung oder Bedingungskombination genau eine Aktion oder Aktionsfolge zu. Abbildung ENTAB-1 zeigt das Standardformat der Entscheidungstabelle. Tabellenbezeichnung Legende:

Bi

Bj

Bezeichner der Bedingungen

Ak

Bezeichner der Aktionen

Rj

Bezeichner der Entscheidungsregeln

R

j

Rj — — —R

Bedingungen

Bedingungsanzeiger

Aktionen

Aktionsanzeiger

p

Bm

O & P -< U h SG £ S C £ D >-> 100 km) (>100 km) mittlungsstellen 1.5

0.18

2.07

0.69

Briefpost

Porto -.80 Zusatzgebühr für Eilzustellung 3.50 Einschreiben 2 (Rückschein 1.50)

1.40

Kostenfunktionen: Teletex = 20.50 + 0.18; Telefax Gruppe 2 = 10.37 + 2.07; Telefax Gruppe 3 = 19.37 + 0.69; Telex = 23.05 + 1.40; Briefpost = 0.80; Briefpost mit Eilzustellung = 4.30 Abb. WIRTA-2: Kostenvergleich alternativer Kommunikationsdienste (Quelle: Picot/Reichwald)

Unter Verwendung der Daten der Abbildung WIRTA-2 wurden die Kostenfaktoren für die Kostenkurven der alternativen Kommunikationsdienste ermittelt; sie sind in Abbildung WIRTA-3 dargestellt. Man kann daraus folgendes ablesen: Je nach Anzahl der abzuwickelnden Kommunikationsvorgänge sind unterschiedliche Kommunikationsdienste wirtschaftlich. Beispielsweise ist die Briefpost bis zu über 30 Vorgängen/Tag im Vergleich mit Teletex die wirtschaftliche Alternative. Forschungsbefunde R. Anselstetter hat die mit Datenverarbeitung erzielten Nutzeffekte daraufhin überprüft, inwieweit sie quantifizierbar sind und monetär bewertet werden können. Anhand von Beispielen werden quantifizierbare und monetär bewertbare Nutzeffekte mit den Kosten verglichen, um daraus den "Nettonutzen der Datenverarbeitung" zu bestimmen. Es werden Daten verwendet, die aus einschlägigen Publikationen entnommen wurden, sowie Daten einer Felduntersuchung in 39 Unternehmen. Für je ein "Beispielunternehmen" des Handels, der Industrie und

WIRTA - Wirtschaftlichkeitsanalyse

161

des Kreditgewerbes wird folgender Nettonutzen ermittelt: Handel 0,8 bis 1,8% vom Umsatz, Industriebetrieb 1,3 bis 3,7% vom Umsatz und Bankbetrieb 0,3 bis 0,6% der Bilanzsumme.

s Q oo CS H oUi a. crt O

10

20

30 Vorgänge pro Tag

Abb. WIRTA-3: Kostenkurven alternativer Kommunikationsdienste (Quelle: Picot/Reichwald) Kontrollfragen 1. 2. 3. 4.

W a n n ist ein Projekt der Systemplanung wirtschaftlich? Wie können die Kosten und wie kann der Nutzen gegliedert werden? Wie erfolgt die Analyse der Beziehungszusammenhänge zwischen Kosten und Nutzen? Wodurch unterscheiden sich statische von dynamischen Methoden der Wirtschaftlichkeitsrechnung?

5.

Was ist ein Wirtschaftlichkeitsmodell?

Quellenliteratur Anselstetter, R.: Betriebswirtschaftliche Nutzeffekte der Datenverarbeitung - Anhaltspunkte für Nutzen-Kosten-Schätzungen. 2. A., Springer Verlag, Berlin et al. 1986 Blohm, H. und Lüder, K.: Investition. 7. A., Verlag Vahlen, München 1992 Kargl, H.: Controlling im DV-Bereich. Oldenbourg Verlag, München/Wien 1993 Reichwald, R.: Ein mehrstufiger Bewertungsansatz zur wirtschaftlichen Leistungsbeurteilung der Bürokommunikation. In: Hoyer, R. H. und Kölzer, G. (Hrsg.): Wirtschaftlichkeitsrechnungen im Bürobereich. Verlag de Gruyter, Berlin 1987, 23 - 33 S c h u m a n n , M.: Wirtschaftlichkeitsbeurteilung für IV-Systeme. In: W I R T S C H A F T S I N F O R M A TIK 2/1993, 1 6 7 - 178 Vertiefungsliteratur Antweiler, J.: Wirtschaftlichkeitsanalyse von Informations- und Kommunikationssystemen. Datakontext, Köln 1995 B u x m a n n , P. und König, W.: Ein Entscheidungsmodell zur Bewertung von Investitionen in Standards - dargestellt am Beispiel von ISO-Standards und C C I T T - E m p f e h l u n g e n für eine o f f e n e Datenkommunikation. In: W I R T S C H A F T S I N F O R M A T I K 3/1994, 252 - 267 Heinrich, L. J.: Informationsmanagement - Planung, Überwachung und Steuerung der Informationsinfrastruktur. 4. A., Oldenbourg Verlag, München/Wien 1992 Niemeier, J.: Konzepte der Wirtschaftlichkeitsberechnung bei integrierten Informationssystemen. In: Horväth, P. (Hrsg.): Wirtschaftlichkeit neuer Produktions- und Informationstechnologie. Stuttgart 1988, 15 - 3 4 Picot, A. und Reichwald, R. (Hrsg.): Kommunikationstechnik und Wirtschaftlichkeit. CW-Publikationen Verlagsgesellschaft, München 1984 Schumann, M.: Betriebliche Nutzeffekte und Strategiebeiträge der großintegrierten Informationsverarbeitung. Springer Verlag, Berlin et al. 1992 Stickel, E.: Eine Erweiterung des hedonistischen Verfahrens zur Ermittlung der Wirtschaftlichkeit des Einsatzes von Informationstechnik. In: Zeitschrift für Betriebswirtschaft 7/1992, 743 - 7 5 9

NUTZW - Nutzwertanalyse Lernziele Sie kennen den Aufbau des Nutzwertmodells und die Vorgehensweise bei seiner Anwendung ("Nutzwertanalyse"). Sie können diese Vorgehensweise als "Arbeitsschritte der Nutzwertanalyse" beschreiben. Sie können die Nutzwertanalyse anwenden und aus einer Menge von Handlungsalternativen die optimale Alternative bestimmen. Sie kennen die verschiedenen Wahlprobleme, die dabei auftreten, und können sie lösen. Sie kennen weiterführende Varianten der Nutzwertanalyse. Definitionen und Abkürzungen Entscheidungsregel (decision rule) = eine Vorschrift, die für eine bestimmte Entscheidungssituation angibt, wie eine Menge von Zielwerten für eine Menge von Handlungsalternativen zum Gesamtnutzen aggregiert wird. Synonym: Aggregationsfunktion. Kriteriengewicht (criterion weight) = die relative Bedeutung eines Kriteriums für den Entscheidungsträger in einer gegebenen Entscheidungssituation ("Präferenzordnung"). Kriterium (criterion) = ein Ziel, das Endpunkt einer Zielkette der Zielhierarchie ist. Synonym: Zielkriterium. Nutzwert (value of benefit) = der subjektiv beeinflußte Wert einer Handlungsalternative zur Befriedigung eines definierten Bedarfs. P r ä f e r e n z (preference) = die Vorziehenswürdigkeit einer Alternative gegenüber einer anderen Alternative. P r ä f e r e n z o r d n u n g (preference order) = die durch den Entscheidungsträger vorgenommene Ordnung von Alternativen aufgrund bestehender Präferenzen. Ziel (goal) = die normative Aussage eines Entscheidungsträgers, die einen anzustrebenden und damit zukünftigen Zustand der Wirklichkeit beschreibt. Zielertrag (goal profit) = die Konsequenz einer Alternative bezüglich eines Zielkriteriums. Synonyme: Zielerreichungsgrad, Ausmaß der Zielerreichung. Z i e l e r t r a g s m a t r i x (goal profit matrix) = eine Matrix, die in den Zeilen die Alternativen und in den Spalten die Kriterien enthält; die Elemente der Matrix enthalten die Zielerträge. Zielhierarchie (goal hierarchy) = die stufenmäßig aufgebaute Ordnung der Elemente eines Zielsystems in Form einer Rangordnung mit von oben nach unten abnehmender Bedeutung. Zielkriterium (goal criterion) = siehe Kriterium. Zielwert (goal value) = die Abbildung eines Zielertrags auf einer nominalen, ordinalen oder kardinalen Skala ("Skalierung"). Synonym: Teilnutzen. Zielwertmatrix (goal value matrix) = eine Matrix, die in den Zeilen die Alternativen und in den Spalten die Zielkriterien enthält; die Elemente der Matrix enthalten die Ziel werte. Zielsystem (goal system) = eine Menge, deren Elemente Ziele sind, die untereinander in Beziehung stehen, wobei die Beziehungen - idealtypisch gesehen komplementär, konfliktär oder indifferent sind.

NUTZW - Nutzwertanalyse

163

Zweck der Nutzwertanalyse In der Problemlösungsstufe 5 "Bewertung" des systemtechnischen Planungsansatzes (vgl. Abbildung SYSTE-3) besteht die folgende Situation: Aus einer Menge von Handlungsalternativen soll die optimale Alternative unter Berücksichtigung mehrerer Ziele ("mehrdimensionales Zielsystem") bestimmt werden. Diese Bewertungssituation ist für die Systemplanung typisch, weil sie sehr häufig auftritt. Um die Auswahlentscheidung treffen zu können, müssen die Handlungsalternativen über einen zu ermittelnden Nutzwert nach ihrer Vorzugswürdigkeit geordnet werden. Dazu sind sie unter Beachtung der Präferenzen der Entscheidungsträger miteinander zu vergleichen. Aufgaben dieser Art können mit Hilfe einer systemtechnischen Vorgehensweise bearbeitet werden, für die sich die Bezeichnung "Nutzwertanalyse" durchgesetzt hat. Die Nutzwertanalyse ist keine "Entscheidungsrechnung" (wie die in Lerneinheit WIRTA dargestellten Methoden der Wirtschaftlichkeitsrechnung), sondern ein Rahmenkonzept für die systematische und nachvollziehbare Aufbereitung von Entscheidungsinformationen; das Rahmenkonzept muß an die Bedingungen der Entscheidungssituation und an die Präferenzen der Entscheidungsträger angepaßt werden. Die Nutzwertanalyse kann daher in nahezu allen komplexen Entscheidungssituationen zur Entscheidungsunterstützung herangezogen werden. Abbildung NUTZW-1 zeigt die Logik der Nutzwertanalyse. Vorgehensweise bei der Nutzwertanalyse Aus Abbildung NUTZW-1 kann folgende, in fünf Arbeitsschritte gegliederte Vorgehensweise bei der Durchführung der Nutzwertanalyse abgeleitet werden: Festlegen des Zielsystems, Ermitteln der Zielerträge, Ermitteln der Zielwerte, Bestimmen der Kriteriengewichte und Durchführen der Wertsynthese. Erster Arbeitsschritt: Festlegen des Zielsystems Im ersten Arbeitsschritt der Nutzwertanalyse wird das situationsrelevante Zielsystem festgelegt, das sich aus der Art der Entscheidungssituation und aus den Präferenzen der Entscheidungsträger ergibt. Eine allgemein akzeptierte Vorgehensweise zum Festlegen des Zielsystems liegt nicht vor, sodaß es "eher Kunst als Wissenschaft" ist, zu einem brauchbaren Arbeitsergebnis zu kommen. Wünschenswerte Eigenschaften eines Zielsystems sind Vollständigkeit, Operationalität, Zerlegbarkeit, Redundanzfreiheit und Minimierung der Zielanzahl. Empfehlenswert ist eine hierarchische Vorgehensweise (vgl. Lerneinheit SYSTE), bei der umfassende Ziele in Teilziele zerlegt bzw. Teilziele zu einem Oberziel zusammengefaßt werden. Ausgangspunkt der Zerlegung ist, dem Topdown-Ansatz folgend, der oberste Knoten des Zielsystems (mit "optimale Alternative" zu bezeichnen); er wird in mehrere, möglichst überschneidungsfreie Teilmengen zerlegt. Die so in der zweiten Hierarchiestufe des Zielsystems entstehenden Knoten werden wiederum in überschneidungsfreie Teilmengen gegliedert usw. Daraus ist ersichtlich, daß jedes Zielsystem beliebig tief gegliedert werden kann, wobei mit zunehmender Zerlegung Präzision und Operationalität zunehmen.

164

Methoden und Techniken der Systemplanung

NUTZW

- Nutzwertanalyse

165

Mit der Zerlegung steigt - bedingt durch die zunehmende Anzahl der Teilziele der Aufwand für die Ermittlung der Zielerträge. Der Zerlegungsprozeß sollte daher abgebrochen werden, wenn die Teilziele eine Präzision und Operationalität erreicht haben, die sie als Zielkriterien geeignet sein lassen. Als Zielkriterien geeignet sind Teilziele dann, wenn einer Handlungsalternative ein meßbarer Zielertrag bezüglich des betrachteten Zielkriteriums eindeutig zugeordnet werden kann; andernfalls muß der Zerlegungsprozeß fortgesetzt werden. Wird beim Bestimmen des Zielsystems eine Vorgehensweise nach dem Bottomup-Ansatz gewählt, dann sind Einzelbeobachtungen über entscheidungsrelevante Attribute der Handlungsalternativen Ausgangspunkt der Aggregation. Zusammengehörige Einzelbeobachtungen werden so zusammengefaßt, daß überschneidungsfreie Teilziele formuliert werden können. Mehrere zusammengehörige Teilziele werden dann zu einem Oberziel zusammengefaßt usw. Der Prozeß der Aggregation wird solange fortgesetzt, bis man bei einem gemeinsamen Knotenziel für alle Einzelbeobachtungen, die Ausgangspunkt der Aggregation waren, angelangt ist. Zweiter Arbeitsschritt: Ermitteln der Zielerträge Im zweiten Arbeitsschritt der Nutzwertanalyse werden die Zielerträge je Zielkriterium und je Handlungsalternative ermittelt. Dabei handelt es sich primär um einen Prozeß des Erfassens von Daten, dessen Art und organisatorische Gestaltung sowohl vom betrachteten Zielkriterium als auch von den konkreten Handlungsalternativen abhängen und der im Einzelfall aufwendige Ermittlungsverfahren erforderlich macht. Ergebnis des Arbeitsschritts ist die Zielertragsmatrix, in der jeder Zielertrag ejj durch seinen alphanumerischen Wert die erwartete Konsequenz bezüglich des Zielkriteriums kj für die Handlungsalternative Aj abbildet. Dritter Arbeitsschritt: Ermitteln der Zielwerte Im dritten Arbeitsschritt der Nutzwertanalyse werden die Zielerträge durch Skalieren bewertet und damit in Zielwerte überführt. Ein Zielwert ny bildet durch seinen numerischen Wert den Teilnutzen des Zielkriteriums kj für die Handlungsalternative Aj ab. Ergebnis des dritten Arbeitsschritts ist die Zielwertmatrix. Skalieren heißt also, den Zielerträgen ejj Zahlen zuordnen, welche die in aller Regel in nicht miteinander vergleichbaren Dimensionen gemessenen Zielerträge vergleichbar machen. Dazu ist zunächst - in Abhängigkeit von der Entscheidungssituation - das Skalenniveau festzulegen. Zur Wahl stehen nominale, ordinale und kardinale Skala. • Nominale Skala: Die Bewertung erfolgt durch "kategoriale Urteile", die angeben, in welche von zwei oder mehreren Wertkategorien eine Handlungsalternative in bezug auf ein Kriterium einzuordnen ist. Bei zwei Wertkategorien wird also festgestellt, ob eine Handlungsalternative ein gegebenes Zielertragsniveau ("Befriedigungsniveau") erfüllt oder nicht erfüllt; anschließend wird diese der Wertkategorie "erfüllt das Zielertragsniveau" oder "erfüllt das Zielertragsniveau nicht" zugeordnet. Dem Vorteil der leichten

166

Methoden

und Techniken

der

Systemplanung

Handhabung der nominalen Skala stehen die Nachteile des eingeschränkten Informationsgehalts und der mangelnden Entscheidungsrelevanz durch die meist willkürliche Festlegung des Befriedigungsniveaus gegenüber. Die nominale Skala eignet sich daher nur für eine Vorauswahl oder Grobauswahl. • Ordinale Skala: Die Bewertung erfolgt durch Herstellen einer Rangreihe n-ter Ordnung bei n Handlungsalternativen ("Rangordnung"). Das Herstellen der Rangordnung erfolgt durch Anwendung des "Rangordnungsverfahrens" (sämtliche Alternativen werden gleichzeitig zur Bewertung vorgegeben) oder des "vollständigen Paarvergleichs" (es werden jeweils zwei Alternativen zur Bewertung vorgegeben). Die Rangordnung gibt lediglich an, ob der Zielwert einer Handlungsalternative kleiner, gleich oder größer ist als der Zielwert einer anderen Handlungsalternative. Die absolute Differenz zwischen den Zielwerten bleibt unberücksichtigt. Das einzelne Bewertungsergebnis ist unabhängig vom angestrebten Zielertragsniveau. Insofern stellen ordinale Urteile geringere Anforderungen an das Urteilsvermögen und sind im Hinblick auf ihre individuelle Vergleichbarkeit befriedigender als nominale Urteile. • Kardinale Skala: Die Bewertung erfolgt durch quantitative Messung. Hinsichtlich des möglichen Skalenniveaus ist der Informationsgehalt kardinal skalierter Urteile am höchsten, doch hat man in der Regel erhebliche praktische Meßprobleme, weil geeignete Meßinstrumente nicht zur Verfügung stehen. Varianten der kardinalen Skala sind Intervallskala und Verhältnisskala. Die Intervallskala ("intervallfixierte Skala") besitzt die Eigenschaften einer nominalen Skala und einer ordinalen Skala; darüber hinaus repräsentieren gleiche Abstände auf der Skala gleiche Unterschiede der gemessenen Eigenschaft, die Intervalle können addiert und subtrahiert werden. Eine Verhältnisskala (auch: Ratio-Skala) besitzt zusätzlich zu den Eigenschaften der bisher genannten Skalen einen absoluten Nullpunkt ("absolut fixierte Skala") oder einen natürlichen Nullpunkt, der eine empirische Bedeutung hat ("nullpunktfixierte Skala"). Alle mathematischen Operationen sind auf ihr möglich. Vierter Arbeitsschritt: Bestimmen der Kriteriengewichte Da die Zielkriterien für die Entscheidungsträger in der Regel eine unterschiedlich große Bedeutung haben, werden sie mit Kriteriengewichten belegt, das heißt, es wird eine Präferenzordnung der Zielkriterien hergestellt. Die Präferenzordnung bewirkt, daß die Zielwerte ("Teilnutzen") bei der anschließenden Wertsynthese mit unterschiedlichem Gewicht in den Gesamtnutzen eingehen. Zur Herstellung der Präferenzordnung können verschiedene Verfahren verwendet werden; nachfolgend wird die Methode der sukzessiven Vergleiche (auch: Methode der paarweisen Vergleiche) anhand ihrer wichtigsten Arbeitsschritte erläutert. Die praktische Anwendbarkeit dieser Methode hängt von der Anzahl der Zielkriterien ab; sie wird mit "maximal sechs" angegeben. Mächtigere Zielmengen werden in Teilmengen zerlegt, und es wird innerhalb jeder Teilmenge so vorgegangen: • Herstellen einer Rangfolge der Zielkriterien ("Präferenzrelation") entsprechend ihrer relativen Bedeutung; jedes Zielkriterium erhält eine Rangziffer. • Bestimmen vorläufiger Kriteriengewichte, wobei das wichtigste Zielkriterium den Gewichtungsfaktor 1,0 erhält; die Gewichtungsfaktoren der anderen Ziel-

NUTZW - Nutzwertanalyse

167

kriterien müssen die Voraussetzung erfüllen, daß sie mit zunehmender Rangziffer abnehmen. • Den endgültigen Gewichtungsfaktor für das bedeutsamste Zielkriterium erhält man, indem man zunächst abschätzt, ob er größer, gleich oder kleiner als die Summe der restlichen Gewichtungsfaktoren sein soll; man formuliert eine entsprechende Bedingung. Wird diese Bedingung von den vorläufig festgelegten Gewichtungsfaktoren erfüllt, dann wird der Gewichtungsfaktor für das bedeutsamste Zielkriterium mit 1,0 endgültig fixiert. Andernfalls sind entweder der vorläufige Gewichtungsfaktor des bedeutsamsten Zielkriteriums oder die restlichen Gewichtungsfaktoren unter Einhaltung der Präferenzrelation so zu modifizieren, daß die formulierte Bedingung erfüllt wird. • Bei der Festlegung der endgültigen Gewichtungsfaktoren für die übrigen Zielkriterien wird entsprechend ihrer Rangfolge prinzipiell so vorgegangen, wie dies für das bedeutsamste Zielkriterium dargelegt wurde. Der nächste, endgültig festzulegende Gewichtungsfaktor wird stets mit der Summe der restlichen, noch nicht festgelegten Gewichtungsfaktoren verglichen. • Schließlich werden die ermittelten Gewichte auf 1 oder auf 100 normiert. Fünfter Arbeitsschritt: Durchführen der Wertsynthese Im fünften Arbeits schritt der Nutzwertanalyse werden die Teilnutzen je Handlungsalternative mit Hilfe einer Entscheidungsregel zum Gesamtnutzen (zum "Nutzwert") aggregiert. Die Auswahl der Entscheidungsregel ist vom verwendeten Skalenniveau abhängig, also davon, ob nominal, ordinal oder kardinal skalierte Zielwerte vorliegen. Wertsynthese bei nominal skalierten Zielwerten: Die wichtigsten Entscheidungsregeln sind "Regel der befriedigenden Lösung", "Regel der Befriedigung der großen Zahl" und "Regel der lexikografischen Ordnung". • Regel der befriedigenden Lösung (Simon-Regel): Eine Handlungsalternative ist dann optimal, wenn sie in allen Wertdimensionen befriedigende Zielerträge liefert. Durch die willkürliche Festsetzung des Befriedigungsniveaus ist diese Entscheidungsregel für eine Vorauswahl oder Grobauswahl geeignet. • Regel der Befriedigung der großen Zahl: Eine Handlungsalternative ist dann optimal, wenn die Anzahl der befriedigenden Wertdimensionen größer ist als die aller anderen Handlungsalternativen. Diese Entscheidungsregel bedingt die gegenseitige "Verrechnung" der von einer Handlungsalternative erreichten Bewertungen. Die Vorgehensweise impliziert kardinale Eigenschaften der nominal formulierten Zielwerte und ist daher spekulativ. • Regel der lexikografischen Ordnung: Eine Handlungsalternative ist dann optimal, wenn sie bezüglich des wichtigsten Kriteriums von allen Handlungsaltemativen am höchsten eingestuft wird. Sind mehrere Zielwerte bezüglich des wichtigsten Kriteriums gleich, so entscheidet das zweitwichtigste Kriterium über die Vorzugswürdigkeit usw. Voraussetzung für die lexikografische Ordnung ist, daß das nominale Urteilsschema aus mindestens drei Klassen besteht. Diese Entscheidungsregel eignet sich besonders zur rationalen Ausschöpfung des Informationsgehalts einer nominal skalierten Zielwertmatrix.

168

Methoden und Techniken der

Systemplanung

Wertsynthese bei ordinal skalierten Zielwerten: Die wichtigsten Entscheidungsregeln sind "Majoritätsregel", "Vorzugs-/Häufigkeitsregel" und "Rangordnungssummenregel". • Majoritätsregel: Eine Handlungsalternative ist dann optimal, wenn sie allen anderen Handlungsalternativen in mehr Wertdimensionen überlegen als unterlegen ist. • Vorzugs-/Häufigkeitsregel: Eine Handlungsalternative ist dann optimal, wenn sie allen anderen Handlungsalternativen in ihren Wertdimensionen häufiger vorgezogen wird. Diese Entscheidungsregel gliedert sich in die Varianten "Copeland-Regel", "Austin-Slight-Regel" und "Thurstone-Regel". • Rangordnungssummenregel: Eine Handlungsalternative ist dann optimal, wenn die Summe der ihr in den Wertdimensionen zugeordneten Rangplätze kleiner ist als die vergleichbare Summe aller anderen Handlungsalternativen. Diese Entscheidungsregel ist sehr operational und wird häufig angewendet. Abbildung NUTZW-2 zeigt die formale Struktur der Rangordnungssummenregel. Sie impliziert die Annahme, daß die Nutzendistanzen zwischen benachbarten Rängen gleich groß sind (was allerdings nur selten der Fall ist). m N - X n - g j j=l Legende:

N i ... Nutzwert der Alternative i n j j ... Zielwert der Alternative i bezüglich Kriterium j g j ... Gewicht des Kriteriums j

Abb. NUTZW-2: Formale Struktur Rangordnungssummenregel

Wertsynthese bei kardinal skalierten Zielwerten: Beispiele für Entscheidungsregeln sind: "Additionsregel" bei Intervallskalen und bei Verhältnisskalen; "Multiplikationsregel" bei Verhältnisskalen; verschiedene spieltheoretisch begründete Entscheidungsregeln bei Verhältnisskalen (wie "Maximin-Regel", "Maximax-Regel" und "Pessimismus/Optimismus-Regel"). Die größte praktische Bedeutung hat die Additionsregel, bei der - wie die Bezeichnung sagt - die gewichteten Zielwerte addiert werden, was aufgrund des Charakters von Intervallund Verhältnisskala problemlos möglich ist. A o p t = A; I Ni — • max ! A o p t = A; I N;

min !

Abb. NUTZW-3: Zielfunktion optimale Handlungsalternative

Ergebnis der Nutzwertanalyse Schließlich werden die Handlungsalternativen in eine widerspruchsfreie und vollständige Ordnung gebracht. Die Ordnung ergibt sich aus dem Vergleich der Nutzwerte der Handlungsalternativen. Die optimale Handlungsalternative ist die, deren Nutzwert maximal ist bzw. (wie z.B. bei der Rangordnungssummen-

NUTZW - Nutzwertanalyse

169

regel) minimal ist (vgl. Abbildung NUTZW-3). Ergebnis der Nutzwertanalyse ist die Ordnung der gegebenen Menge von Handlungsalternativen nach dem Nutzwert der einzelnen Handlungsalternativen (also nach ihrem "Gesamtnutzen"). Weiterführende Varianten der Nutzwertanalyse Die Ergebnisse der Nutzwertanalyse können mit den folgenden Methoden weiter untersucht werden: Empfindlichkeitsanalyse, Kosten/Nutzen-Technik und Berücksichtigung der Prognoseungewißheit. • Empfindlichkeitsanalyse (auch: Sensitivitätsanalyse): Mit der Empfindlichkeitsanalyse wird untersucht, welche Wirkungen Änderungen der Parameter Zielertrag, Skalenniveau, Kriteriengewicht und Entscheidungsregel auf den ermittelten Nutzwert hervorrufen. Je weniger die Ordnung der Handlungsaltemativen dadurch verändert wird, desto geringer ist das Entscheidungsrisiko. Gesucht wird z.B. nach den Werten der Parameter, bei denen die zunächst ausgewählte Alternative nicht mehr optimal ist ("kritische Parameterwerte"). • Kosteji/Nutzen-Technik: Obwohl es möglich ist, konkurrierende Ziele in die Vorgehensweise der Nutzwertanalyse einzubringen (insbesondere konkurrierende Ziele wie Kosten und Nutzen), wird bei der Kosten/Nutzen-Technik empfohlen, die Kosten einer Handlungsalternative zunächst nicht in das Zielsystem aufzunehmen. Nach der Ermittlung des Nutzwerts wird dieser mit dem Kostenwert in Beziehung gesetzt. Die Entscheidungsregel lautet: Eine Handlungsalternative ist dann optimal, wenn ihr Kosten/Nutzen-Verhältnis das kleinste aller Handlungsalternativen ist. Die Anwendung der Kosten/NutzenTechnik ist nur bei kardinal skalierten Zielwerten möglich. • Berücksichtigung der Prognoseungewißheit: Die Ungewißheit bei der Ermittlung zukünftiger Zielerträge kann in der Methodik der Nutzwertanalyse dadurch berücksichtigt werden, daß die eindeutigen, diskreten Zielerträge durch stetige Zielertragswahrscheinlichkeiten ersetzt werden. Ergebnis der Nutzwertanalyse ist dann die Ordnung der Handlungsalternativen nach Nutzwert-Wahrscheinlichkeitsverteilungen. Prämissen der Nutzwertanalyse Der Nutzwertanalyse liegen die folgenden Annahmen zugrunde, die bei der Konstruktion des Analysemodells und bei der Interpretation der Bewertungsergebnisse zu beachten sind: • Die Menge der Handlungsalternativen ist bekannt; sie enthält auch die gesuchte optimale Alternative. • Es existiert eine Nutzenfunktion, die durch das Zielsystem vollständig abgebildet wird. • Ein geringer Zielertrag eines Ziels kann durch einen hohen Zielertrag eines anderen Ziels auf Grund der Zielgewichtung kompensiert werden. • Die Zielinhalte sind disjunkt, sodaß keine Doppel- oder Mehrfachbewertungen auftreten. • Die Präferenzordnung der Entscheidungsträger bezüglich der Kriteriengewichte ist konsistent.

170

Methoden und Techniken der Systemplanung

Vorbehalte gegen die Anwendung der Nutzwertanalyse resultieren weniger aus diesen Annahmen als vor allem aus der subjektiv gestaltbaren Vorgehensweise. Dies ist dann ohne Bedeutung, wenn die Entscheidungssituation dadurch gekennzeichnet ist, daß nur durch Einbeziehung der subjektiven Präferenzen der Entscheidungsträger eine optimale Alternative bestimmt werden kann. Das Vorliegen dieser Voraussetzung ist im einzelnen Anwendungsfall zu überprüfen.

Abb. NUTZW-4: Zielkriterien für die Bewertung der Alternativen (Zielsystem)

Demonstrationsbeispiel Es wird die Anwendung der Nutzwertanalyse für das folgende Auswahlproblem gezeigt: Gegeben sind sieben alternative Methoden, mit denen die Aufgabe Zeiterfassung (vgl. Lerneinheit ZERFA) unterstützt werden kann; für das Projekt sind drei der sieben Methoden anwendbar: Arbeitstagebücher, Tätigkeitsberichte und Multimomentstudien. Gesucht ist die Methode der Zeiterfassung, die für das gegebene Projekt optimal ist. • Erster Arbeitsschritt: Festlegen des Zielsystems. Abbildung NUTZW-4 zeigt das Zielsystem als Ergebnis des ersten Arbeitsschritts. Die Enden der Zielketten sind als Zielkriterien (Kriterien) hervorgehoben. Jedes Kriterium wird operational beschrieben, also mit Zielinhalt, Messung des Zielertrags und Zieiüimension ("Meßmethode"). Dabei ist eine Anpassung generell verwendeter Beschreibungen der Zielinhalte (z.B. Genauigkeit) an die Auswahlsituation (hier: Genauigkeit der Zeiterfassung) erforderlich. Daraus folgt die Notwendigkeit der Anpassung allgemeiner Meßmethoden und Zieldimensionen an die Auswahlsituation (dies wird im Demonstrationsbeispiel nicht gezeigt). • Zweiter Arbeitsschritt: Ermitteln der Zielerträge. Auf Grund der operationalen Beschreibung der Zielkriterien wird der Zielertrag je Kriterium und je Alternative - unter Verwendung der Meßmethoden - ermittelt (der Ermittlungsprozeß kann im Demonstrationsbeispiel nicht gezeigt werden). Abbildung NUTZW-5 zeigt das Ergebnis des Ermitteins der Zielerträge als Zielertragsmatrix.

NUTZW - Nutzwertanalyse

Alternativen Kriterien Genauigkeit Planungsaufwand t-i Durchführungsaufwand 4SP -» beim Projektteam

1

3

2

3

2

1

Auswertungsaufwand

2

1

3

Akzeptanz

1

2

3

Kriterien

'

Durchführungsaufwand beim Aufgabenträger

.3

Abb. NUTZW-6: Zielwerte der Alternativen (Zielwertmatrix)

• Dritter Arbeitsschritt: Ermitteln der Zielwerte. Für die Bewertung der Zielerträge wird die ordinale Skala verwendet. Abbildung NUTZW-6 zeigt die

172

Methoden und Techniken der Systemplanung

Zielwerte der Alternativen für jedes Kriterium auf Grund der in Abbildung NUTZW-5 dokumentierten Zielerträge als Zielwertmatrix. • Vierter Arbeitsschritt: Durchführen der Wertsynthese. Als Entscheidungsregel wird die Rangordmingssummenregel verwendet. Sie bewirkt die Gewichtung der Zielwerte (vgl. Abbildung NUTZW-6) und ihre Aggregation zum Nutzwert. Dies zeigt Abbildung NUTZW-7. Die Alternativen werden nach dem Nutzwert geordnet. Danach ergibt sich folgende Rangordnung: 1. Zeiterfassung mit Multimomentstudien (optimale Alternative); 2. Zeiterfassung mit Tätigkeitsberichten; 3. Zeiterfassung mit Arbeitstagebüchern. "

Alternativen

Arbeitstagebücher

Kriterien

Tätigkeitsberichte

Multimoment- Gewichtungsvektor studien

Genauigkeit

60

40

20

20

Planungsaufwand

10

5

15

5

15

45

30

15

Durchführungsaufwand beim Aufgabenträger

90

60

30

30

Auswertungsaufwand

20

10

30

10

Akzeptanz

20

40

60

20

Nutzwert

215

200

185

100

Durchführungsaufwand beim Projektteam

i3

a

Abb. NUTZW-7: Teilnutzen und Gesamtnutzen der Alternativen

Forschungsbefunde Eisenführ/Weber berichten über die Ergebnisse einer empirischen Untersuchung (Laborstudie mit 261 Studierenden der Betriebswirtschaftslehre als Versuchspersonen in acht Gruppen, davon zwei Kontrollgruppen; Entscheidungsproblem: Arbeitsplatzwahl nach Studienabschluß), mit der die Auswirkung der Zerlegung von Zielen in Unterziele auf die Zielgewichte erkundet werden sollte. Ausgangsthese für die Untersuchung war, daß durch die Zerlegung eines Ziels in Unterziele die vom Entscheidungsträger empfundene relative Bedeutung dieses Ziels (relativ zu den übrigen Zielen im Zielsystem) vergrößert wird. Die untersuchten Hypothesen lauteten: • H l : Die Summe der Gewichte der Unterziele zerlegter Oberziele in einem linearen Modell ist größer als die Summe der Gewichte der nicht zerlegten Oberziele ("Splitting-Bias").

NUTZW - Nutzwertanalyse

173

• H2: Je höher die (subjektiv empfundene) Korrelation zwischen den durch Zerlegung entstehenden Unterzielen ist, desto größer ist der Splitting-Bias. Zur Ermittlung der Zielgewichte wurden vier Gewichtungsmethoden verwendet (Swing-Methode, Direct-Ratio-Methode, Conjoint-Methode und Multiple-Importance-Methode). H l wurde bei allen verwendeten Gewichtungsmethoden deutlich bestätigt. Zu H 2 waren die Ergebnisse widersprüchlich. Im Ergebnis kann festgehalten werden, daß mit einem Splitting-Bias generell gerechnet werden muß. Kontrollfragen 1. 2. 3. 4.

Welcher Unterschied besteht zwischen einem Ziel und einem Zielkriterium? Welches sind die bestimmenden Einflüsse beim Ermitteln des Zielsystems? Welcher Unterschied besteht zwischen Zielertrag und Zielwert? Was bewirkt die Gewichtung der Zielkriterien?

5.

Nennen Sie Beispiele für Entscheidungsregeln mit dem zugehörigen Skalenniveau.

Quellenliteratur Blohm, H. und Lüder, K.: Investition. 7. A., Verlag Vahlen, München 1992 Zangemeister, Ch.: Nutzwertanalyse in der Systemtechnik. 4. A., Wittemann'sche Verlagsbuchhandlung, München 1976 Vertiefungsliteratur Eisenführ, F. und Weber, M.: Zielstrukturierung: ein kritischer Schritt im Entscheidungsprozeß. In: Zeitschrift für betriebswirtschaftliche Forschung 11/1986,907 - 929 Weber, M.: Entscheidungen bei Mehrfachzielen. Verlag Gabler, Wiesbaden 1983 Zangemeister, Ch. und Bomsdorf, E.: Empfindlichkeitsanalyse in der Nutzwertanalyse. In: Zeitschrift für betriebswirtschaftliche Forschung 5/1983, 375 - 397

SIMUL - Simulation Lernziele Sie kennen die Anwendungsgebiete der Simulation in der Systemplanung und können ihre Stellung als Bindeglied zwischen der Analyse und dem Entwurf von Informationssystemen beschreiben. Sie können die Vorgehensweise beim Durchführen einer Simulationsstudie mit eigenen Worten wiedergeben. Sie können typische Simulationssprachen als wichtige Werkzeuge zur Simulation nennen. Definitionen und Abkürzungen Empfindlichkeitsanalyse (sensibility analysis) = ein Verfahren, mit dem festgestellt werden soll, welche Wirkung geringfügige Änderungen der Parameter auf das beobachtete Verhalten haben. Synonym: Sensitivitätsanalyse. Ereignisorientierung (event view) = die Steuerung und Kontrolle des zeitlichen Ablaufs einer Simulation primär als eine Folge von Ereignissen. Falsifikation (falsification) = der wissenschaftliche Versuch nachzuweisen, daß eine Annahme oder eine Hypothese nicht zutrifft. GPSS = Abkürzung für General Purpose Systems Simulator; eine von G. Gordon entwickelte, 1961 vorgestellte Simulationssprache. Iteration (iteration) = das schrittweise Vorgehen beim Problemlösen. Kalibrierung (calibration) = das sukzessive Anpassen eines Modells an die Wirklichkeit. Konsequenzanalyse (analysis of consequences) = eine systematische Vorgehensweise zur Ermittlung der Auswirkungen von Lösungsalternativen. Simulationsmodell (Simulation model) = ein computerbasiertes Modell zum Experimentieren, das verwendet wird, um Information über das Verhalten des realen Systems zu gewinnen. Modellieren (modeling) = die Tätigkeit des Abbildens eines Ausschnitts der Wirklichkeit in ein Modell. Prozeßorientierung (process view) = die Steuerung und Kontrolle des zeitlichen Ablaufs einer Simulation als eine Folge von Prozessen im Sinne häufig wiederkehrender Folgen von Ereignissen. Synonym: Zeitorientierung. SQL = Abkürzung für Structured Query Language; eine von IBM entwickelte, durch die ANSI-Norm X3.135-1986 standardisierte Abfragesprache, stochastisch (stochastic) = die Eigenschaft eines Prozesses, vom Zufall abhängig (also nicht deterministisch) zu sein. Transaktion (transaction) = eine Folge von Prozessen, die unter definierten Bedingungen durchgeführt werden. Transaktionsorientierung (transaction scanning) = die Steuerung und Kontrolle des zeitlichen Ablaufs der Simulation als eine Folge von Transaktionen. Validität (validity) = das Ausmaß, mit dem ein Modell die Wirklichkeit, die es abbilden soll, auch tatsächlich abbildet und mit dem das Modellverhalten auf die Wirklichkeit übertragen werden kann. Verifikation (verification) = der wissenschaftliche Versuch nachzuweisen, daß eine Annahme oder eine Hypothese zutrifft.

SIMUL - Simulation

175

Zweck der Simulation Simulation ist zielgerichtetes Experimentieren an Modellen. Das Erstellen der Modelle ("Simulationsmodelle") wird im allgemeinen als zur Simulation gehörend betrachtet, sodaß "Simulation" Modellieren der Wirklichkeit und Experimentieren an durch Modellieren entstandenen Modellen meint. Simulation besitzt im mathematischen Sinn keine zur optimalen Lösung führende Suchstrategie. Im Vordergrund stehen Heuristiken für die Auswahl der untersuchten Alternativen. Optimierung kann daher nicht das primäre Ziel der Simulation sein. Besonderes Kennzeichen der Simulation ist die ausdrückliche Problembezogenheit, das heißt, es wird ein konkretes Problem der Wirklichkeit untersucht. Simulationsmodelle sind daher meist stochastische Modelle. Simulation gilt als eine der mächtigsten Methoden zur wirklichkeitsnahen Untersuchung komplexer, dynamischer Systeme. Ihre entscheidende Stärke ist, daß sie das zu untersuchende System wirklichkeitsnah abbilden kann. Die Verfügbarkeit von Werkzeugen erleichtert ihre Anwendung. Eine Simulationsstudie ist dann zweckmäßig, wenn eine oder mehrere der folgenden Eigenschaften der Simulation für die Problemlösung von Bedeutung sind: • Die Wirklichkeit ist zu komplex und/oder zu kompliziert, um sie als ein geschlossen lösbares Formalproblem abbilden zu können; analytische und numerische Methoden versagen deshalb. • Modellieren und Experimentieren, das heißt Beobachten des Systemverhaltens am Modell, führen zu einem besseren Problemverständnis. • Durch analytische und numerische Methoden ermittelte Problemlösungen können durch Simulation überprüft (verifiziert bzw. falsifiziert) werden. • Durch Simulation kann auch das dynamische Verhalten eines Systems, das heißt sein Verhalten im Zeitablauf, beobachtet werden. • Durch Simulation können die Auswirkungen gezielter Veränderungen eines Parameters oder einer Kombination von Parametern auf bestimmte Eigenschaften des Systems untersucht werden. Probleme, die bei der Anwendung der Simulation auftreten können, sind: • Modellieren ist im allgemeinen mit einem relativ großen Aufwand verbunden. • Da jeder Simulationslauf ("Modellauf') eines stochastischen Simulationsmodells nur eine Ausprägung eines stochastischen Prozesses ist, müssen mehrere, oft sehr viele Simulationsläufe durchgeführt werden. • Der große Umfang an quantitativen Daten als Ergebnis einer Simulationsstudie erweckt den Anschein eines hohen Wahrheitsgehalts; dieser wird durch graphische Animation verstärkt. • Simulation ermittelt keine Problemlösung, sondern zeigt lediglich die Konsequenzen von Entscheidungsalternativen auf; sie hat eher Prognosefunktion als Problemlösungsfunktion. Einsatzgebiete der Simulation Wegen der genannten Eigenschaften und Probleme ist die Simulation keine Alternative zu anderen Untersuchungsmethoden. In erster Linie ist sie eine Me-

176

Methoden und Techniken der Systemplanung

thode zur Bestimmung der Systemauslegung und zur Bewertung von Systemalternativen, die mit anderen Untersuchungsmethoden erarbeitet wurden. In der Systemplanung ist das zu schaffende IuK-System oder einzelne seiner Komponenten, z.B. die vorhandenen oder zur Auswahl stehenden Techniksysteme (Hardware und Software), die Wirklichkeit und damit das insgesamt oder in Teilen zu modellierende System, an dessen Modell experimentiert wird. Konkrete Einsatzgebiete der Simulation in der Systemplanung sind: • das Bestimmen des Technikbedarfs für einen Systementwurf; • das Analysieren und Bewerten von Systementwürfen; • das Überwachen des Projektablaufs. Darüber hinaus gewinnt Simulation eine zunehmende Bedeutung im betrieblichen Methodensystem (vgl. Lerneinheit WMESY), insbesondere dann, wenn das zu schaffende IuK-System primär der Entscheidungsunterstützung dienen soll ("Entscheidungsunterstützungssystem"). Die Anwendung der Simulation in Entscheidungsunterstützungssystemen setzt unter anderem voraus: • ihre Integration in die unternehmensweite Methodenbasis zur Vermeidung von Stand-Alone-Lösungen; • das Vorhandensein von Schnittstellen zu Datenbasen, wenn das Simulationsmodell in eine größere Anwendungsumgebung eingebunden ist; • die Anpassung von Simulationsmodellen und von Modellierungskonzepten an unterschiedliche betriebliche Aufgaben; • die durchgängige Unterstützung des gesamten Simulationsprozesses; • die Gewährleistung der Transparenz des Simulationsprozesses. Wirklichkeit und

Simulationsmodell

Wirklichkeit im Sinn der Simulation ist immer ein System als eine Menge von real existierenden oder gedachten Objekten, zwischen denen Beziehungen bestehen. Objekte lassen sich durch Merkmale und Ausprägungen der Merkmale beschreiben. Beziehungen zwischen Objekten kommen dadurch zum Ausdruck, daß die Merkmale nicht beliebige Ausprägungen haben können, sondern daß sie sich gegenseitig so beeinflussen, daß ihre Ausprägungen in bestimmten Kombinationen auftreten. Die Gesamtheit der Merkmalsausprägungen, die ein System zu einem bestimmten Zeitpunkt hat, wird als sein Zustand bezeichnet. Das Verhalten des Systems wird durch eine Menge von Zuständen erfaßt; es kann durch Erzeugung von Zeitreihen, welche die Entwicklung der Merkmalsausprägungen darstellen, beschrieben werden. Merkmalsausprägungen können sich im Zeitablauf ständig (kontinuierliche Zustandsänderung) oder nur zu bestimmten Zeitpunkten (diskrete Zustandsänderung) verändern; diskrete Zustandsänderungen heißen auch Ereignisse. Ein Simulationsmodell beschreibt die Merkmale der Objekte des modellierten Systems mit Hilfe von Variablen. Die Variablenwerte geben den Zustand des Systems wieder. Durch Fortschreibung der Variablenwerte wird das Verhalten des Systems im Zeitablauf erfaßt. Die Fortschreibung der Variablen wird durch Simulationsprogramme erreicht; sie bilden die sachlichen und zeitlichen Beziehungen zwischen den Merkmalen der modellierten Objekte ab.

SIMUL - Simulation

111

Die Fortschreibung der Zeit erfolgt durch sog. Zeitmechanismen. Für kontinuierliche Zustandsänderungen werden Zeitmechanismen verwendet, die mit gleichbleibenden Zeitzuwächsen arbeiten. Die Variablenwerte werden dann in einem gleichmäßigen Zeittakt fortgeschrieben. Simulationen, die solche Zeitmechanismen verwenden, werden prozeßorientiert oder zeitorientiert genannt. Bei diskreten Zustandsänderungen wird die Zeit entsprechend den Eintreffzeitpunkten der Ereignisse fortgeschrieben; die Variablenwerte werden nur zum Eintreffzeitpunkt der Ereignisse erfaßt. Simulationen, die solche Zeitmechanismen verwenden, werden ereignisorientiert genannt. Bestimmen des Technikbedarfs Eine Aufgabe der Grobprojektierung ist es unter anderem, den Technikbedarf für Systementwürfe zu bestimmen (vgl. Lerneinheit BTECH). Diese Aufgabe kann häufig nur durch Simulation des Techniksystems oder einzelner Komponenten des Techniksystems gelöst werden. Insbesondere dann, wenn die Anforderungen an das Techniksystem zeitlich nicht vorhersagbar (z.B. die stochastische Ankunftsrate von Transaktionen bei einem Dialogsystem) und zeitkritisch sind, liefert eine Simulationsstudie wichtige Aussagen über das zeitliche Verhalten des Systems ("Antwortzeitverhalten"). Da das Antwortzeitverhalten für die quantitative Auslegung des Systems ein entscheidender Parameter ist, kann durch die Ergebnisse einer Simulationsstudie die Systemauslegung bestimmt werden. Analysieren und Bewerten von Systementwürfen Trotz des erheblichen Nutzens der Simulation beim Bestimmen des Technikbedarfs sollte eine Simulationsstudie nicht in einzelnen Phasen isoliert, sondern als Methode zur Unterstützung mehrerer Phasen der Systemplanung gesehen werden. So können die in der Vorstudie erarbeiteten alternativen Systemkonzepte (vgl. Lerneinheit GRUND) als Modelle des Gesamtsystems abgebildet und simuliert werden. Die Simulationsstudie kann Ergebnisse liefern, die Rückschlüsse auf das Verhalten des zu schaffenden IuK-Systems zulassen. Beispielsweise können Widersprüchlichkeiten und Unvollständigkeiten in den Systementwürfen erkannt werden. Entsprechen die Ergebnisse der Simulationsstudie nicht den Planungszielen oder Projektzielen, wird das Modell oder werden die Modelldaten modifiziert. Die Simulationsstudie durchläuft dann einen iterativen Prozeß solange, bis eine Lösung, die im Sinn der Planungsziele oder der Projektziele optimal ist, gefunden wird. Damit wird eine evolutionäre, mit dem Prototyping vergleichbare Methodik der Systemplanung unterstützt (vgl. Lerneinheit PROTY). Eine Fortsetzung findet die Anwendung der Simulation beim Analysieren und Bewerten von Systementwürfen in der Grobprojektierung. Hier bildet nicht mehr das Gesamtsystem die Modellgrundlage, sondern einzelne Teilsysteme, wie folgende Beispiele aus einem Teilprojekt Produktionsplanung und -Steuerung zeigen (in Klammern typische Untersuchungsfragen): • die Bewertung von Prioritätsregeln für die Maschinenbelegungsplanung (z.B. "Welche Prioritätsregel ist am besten geeignet, um minimale Durchlaufzeiten zu erzielen?");

178

Methoden und Techniken der Systemplanung

• die Dimensionierung von Materialfluß-Systemen (z.B. "Wieviele Gabelstapler werden in einem bestimmten Lager benötigt, u m bestimmte Ein- und Auslagerungszeiten einzuhalten?"); • die Untersuchung von alternativen Instandhaltungspolitiken (z.B. "Ist vorbeugende Instandhaltung zweckmäßiger als Reparatur bei Ausfall?"); • die Untersuchung von Lagerhaltungssystemen (z.B. "Welche Bestellmenge soll verwendet werden?"). Ü b e r w a c h e n des Projektablaufs In der Grobprojektierung und insbesondere in der Feinprojektierung, wenn bereits P l a n u n g s e r g e b n i s s e (z.B. Anwendungsprogramme) vorliegen, kann eine Simulationsstudie projektbegleitend fortgeführt werden. Mit ihr werden die Planungsergebnisse ("Ist") mit den Planungszielen oder Projektzielen ("Soll") verglichen, und es werden sukzessiv Annahmen über bestimmte Eigenschaften der Planungsergebnisse durch Meßwerte (z.B. die Laufzeit eines Anwendungsprogramms) ersetzt. Durch die damit erfolgende Kalibrierung des Simulationsmodells können Aussagen darüber gemacht werden, ob und inwieweit sich die mit der Simulationsstudie gewonnenen Ergebnisse mit der Wirklichkeit decken, und es kann der Projektfortschritt (vgl. Lerneinheit PROPL) verfolgt werden. Simulation z u m Analysieren und E n t w e r f e n Eine andere Systematik, die für die Beurteilung der Simulation als Methode der Systemplanung geeignet ist und die weitere Aussagen über die Einsatzgebiete der Simulation macht, verwendet die beiden Schwerpunkte systemplanerischer Tätigkeit, das Analysieren und das Entwerfen. Simulation kann als Bindeglied zwischen diesen zueinander inversen Tätigkeitsschwerpunkten der Systemplanung gesehen werden, wie Abbildung SIMUL-1 zeigt. Simulationsprobleme

/

Simulationsziele

Simulationssprachen

K

S

Realität Systempräzisierung Abgrenzung Erkennung Identifikation

i

H

i

Modellsimulation

Systemkonkretisierung! Realität

Modellbildung Interpretation Modellimplementierung Strukturierung Modelltest Integration Modellauf Modellaussagen

Analyse = zur Gestaltung inverser Vorgang

R

S' |

j j :

Gestaltung j = zur Analyse inverser Vorgang j

Abb. SIMUL-1: Integration der Simulation in eine Systemmethodik (Quelle: nach Bauer/Vieweg)

SIMUL - Simulation

179

Durch Abbilden sowohl der Strukturen (z.B. der Techniksysteme) als auch des dynamischen Verhaltens (z.B. der Anwendungssoftware) der Wirklichkeit in ein Modell wird eine Vereinfachung angestrebt, welche die Wirklichkeit transparenter, beherrschbarer und manipulierbarer macht; der Möglichkeit zum Manipulieren kommt dabei eine zentrale Bedeutung zu. Simulation in der Analysephase In Vorstudien werden im Rahmen von Erkennungsexperimenten der Umfang und die generelle Struktur des Simulationsmodells eruiert. Bei der Analyse eines bestehenden Anwendungssystems ist damit die Abgrenzung und die Erfassung des Istzustands gemeint. Wird ein neues Anwendungssystem entworfen, wird von den Anforderungen (vgl. Lerneinheiten SACHZ und FORMZ) ausgegangen. Damit wird die erforderliche Ausgangsinformation für die Simulationsstudie gewonnen. Identifikationsexperimente führen zur quantifizierten, das heißt mit Parametern belegten Modellformulierung. Für die Analyse eines Systems bedeutet dies, daß seine quantitativen Merkmale (z.B. die Belastung/Zeiteinheit) im Modell abgebildet werden. Analysierende B e r e c h n u n g s e x p e r i m e n t e verdichten auf Grund von "Ausrechnungen" und der Generierung konkreter, vergangener Zustandsgeschichten des Systems das dynamische Modellverhalten. Das Simulationsergebnis besteht in der Regel darin, eine interessierende Parameterbelegung des Modells und die daraus resultierende Änderung des Istzustands zu zeigen. Die Berechnungsexperimente bedeuten für die Analyse von Anwendungssystemen, daß versucht wird, deren Verhalten mit Modellen zu erklären. Mit Hilfe von Konsequenzanalysen und Empfindlichkeitsanalysen werden die Wirklichkeitstreue der berücksichtigten Modellteile sowie die Empfindlichkeit der Modellergebnisse bezüglich bestimmter Modelleinflüsse und Parametervariationen festgestellt. Simulation in der Entwurfsphase In der Entwurfsphase ist es erforderlich, unterschiedliche Modellaussagen zu gewinnen und gegenüberzustellen. In Optimierungsexperimenten werden alternative struktur- und verhaltensverändernden Parameterkombinationen so ausgewählt, daß sich das Modellergebnis gemäß einer vorgegebenen Zielfunktion sukzessiv verbessert. Durch Zusammenfügen, Weglassen oder Verändern einzelner Modellteile lassen sich simulativ-experimentell neue Modellstrukturen entwerfen. Für den Entwurf von Anwendungssystemen bedeutet dies, daß durch die sukzessive Ergänzung, das Weglassen oder die Veränderung einzelner Systemkomponenten oder durch die Veränderung von Parametern ein System so optimiert wird, daß es den Anforderungen besser gerecht wird. Der Modellentwurf wird einer Stabilitätsanalyse unterworfen, die Aufschluß über das Störverhalten des Systems gibt. Beim Entwurf eines Anwendungssystems sind darunter Falsifikationsversuche mit extremen Parametern zu verstehen. Bei hinreichend befundener Stabilität liegt ein ausgetestetes Modell vor, das - mit dem Vorteil eines verminderten Entwurfsrisikos - in die Wirklichkeit übertragen werden kann.

180

Methoden

und Techniken der

Systemplanung

Ablauf einer Simulationsstudie Der Ablauf einer Simulationsstudie kann mit den folgenden acht Arbeitsschritten dargestellt werden. Sie sind durch Rückkopplungen, welche der Systemplaner einleitet, gekennzeichnet. Damit hängt der Erfolg einer Simulationsstudie nicht nur von der fachlichen Einschätzung des Problems, sondern auch von den Kenntnissen und Fähigkeiten des Systemplaners im Umgang mit dem Modell im Simulationsprozeß ab. Abbildung SIMUL-2 zeigt den Ablauf einer Simulationsstudie in verkürzter Form; der mit Rückkopplung durchsetzte, iterative Charakter ist erkennbar. Daß es sich im Ergebnis nicht um ein Optimum im mathematischen Sinn handelt, wurde bereits weiter oben begründet.

Abb. SIMUL-2: Ablauf einer Simulationsstudie

• Erster Arbeitsschritt: Entscheiden, welche Modellträgerkonzeption (menschliches Gehirn, Sachmodell oder Computermodell) verwendet werden soll. Falls die Entscheidung zugunsten eines Computers als Modellträger fällt, ist eine geeignete Hard- und Software-Konfiguration auszuwählen. • Zweiter Arbeitsschritt: Definieren des Modells, indem die Variablen benannt, deren Beziehungen formuliert, die Modellperipherie organisiert und die Testdaten erstellt werden. • Dritter Arbeitsschritt: Implementieren des Modells, Durchführen formaler und logischer Modelltests sowie der formalen Konsolidierung des Modells durch Verbessern der Struktur und gegebenenfalls durch Reduzieren der Modellperipherie. • Vierter Arbeitsschritt: Validieren des Modells durch empirische Tests. Dazu dienen Erkennungs- und Identifikationsexperimente, gefolgt von empirischen Zuverlässigkeitstests.

SIMUL - Simulation

181

• Fünfter Arbeitsschritt: Durchführen von Gestaltungs- und Optimierungsstudien. • Sechster Arbeitsschritt: Überprüfen und Bewerten der Modellaussagen, die als Verhaltensprognosen des geplanten Systems aufgefaßt werden können, mit Konsequenzanalysen, Empfindlichkeitsanalysen und Stabilitätsanalysen. • Siebenter Arbeitsschritt: Sachlogisches und qualitatives Interpretieren der Modellaussagen sowie Dokumentieren des Modellzustands und der Modellergebnisse. • Achter Arbeitsschritt: Inhaltliches Stabilisieren und formales Konsolidieren des Modellzustands und der Modellergebnisse. Für das Durchführen der Gestaltungs- und Optimierungsstudien im fünften Arbeitsschritt können verschiedene Suchstrategien, mit denen systematisch nach verbesserten Alternativen gesucht wird, angewendet werden. • Totale Suche/partielle Suche: Bei der totalen Suche werden alle Modellparameter variiert, bei der partiellen Suche nur einzelne. • Kombinatorische Suche/mutative Suche: Kombinatorisches Suchen folgt nicht-zufälligen Gesetzen, während mutatives Suchen zufällig erfolgt. • Analytische Suche/interaktive Suche: Neben geschlossenen, analytischen Suchstrategien (z.B. Methode der kleinsten Quadrate) gibt es offene, interaktive Suchstrategien, bei denen der Systemplaner in den aktuellen Simulationsablauf steuernd eingreift. • Suche in kleinen Schritten/Suche in großen Schritten: Diese Unterscheidung bezieht sich auf das Ausmaß, in dem Parameter variiert werden. Eine Suche in kleinen Schritten bedeutet eine weitgehend kontinuierliche Evolution des neuen Modells, während ein Vorgehen in großen Schritten eher als Durchführbarkeitsstudie anzusehen ist. • Bottom-up-Suche/Top-down-Suche: Diese beiden Suchstrategien dienen zur Entscheidung der Frage, welche der hierarchisch organisierten Parameter eines Modells in die modifizierenden Simulationsstufen schwerpunktmäßig einbezogen werden sollen. Werkzeuge zur Simulation Die Implementierung eines Simulationsmodells als Programm ist Voraussetzung für eine Simulationsstudie. Das Programm kann in einer Universalsprache oder in einer Simulationssprache implementiert werden. Jede höhere Programmiersprache, die eine besondere Eignung zur Modellbildung hat, ist eine Simulationssprache. Entsprechend der Unterscheidung zwischen diskreten Systemen und kontinuierlichen Systemen eignet sich eine Simulationssprache entweder mehr für die Simulation diskreter Systeme (in denen Zustandsänderungen, die als Ereignisse bezeichnet werden, zu bestimmten Zeitpunkten stattfinden) oder mehr für die Simulation kontinuierlicher Systeme, oder sie stellt ein allgemeines Konzept zur Modellbildung zur Verfügung. Bezüglich der grundlegenden Form der Steuerung und Kontrolle des zeitlichen Ablaufs von Modellen diskreter Systeme unterstützt eine Simulationssprache entweder primär E r e i g n i s o r i e n t i e r u n g oder primär Prozeßorientierung als "Modellierungsphilosophie", oder sie unterstützt beide Orientierungen gleichermaßen. Beispiele für Simulationssprachen sind GPSS, SIMAN, SIMSCRIPT und SIMULA.

182

Methoden und Techniken der Systemplanung

• GPSS ist ein allgemeines Konzept zur Simulation diskreter und kontinuierlicher Systeme. GPSS setzt sich aus den Komponenten GPSS-Blocksymbole, GPSS-Sprache und GPSS-Simulator zusammen. Die GPSS-Blocksymbole dienen zur Modellbildung; sie erlauben eine kompakte, relativ leicht verständliche Modellierung. Die GPSS-Sprache besteht aus relativ mächtigen Befehlen. Der GPSS-Simulator übersetzt das in GPSS-Sprache formulierte Programm in ein Maschinenprogramm. • SIMAN ist eine von C. D. Pegden entwickelte, 1983 vorgestellte, auf FORTRAN als Gastsprache basierende Simulationssprache. SIMAN eignet sich zur Simulation diskreter, kontinuierlicher und gemischter Systeme. Die Simulation diskreter Systeme kann ereignisorientiert und/oder prozeßorientiert erfolgen. 1992 aktuell ist SIMAN IV, Version 1.11. • SIMSCRIPT ist eine von der Rand Corp. entwickelte, 1962 vorgestellte, ereignisorientierte Simulationssprache; sie eignet sich zur Simulation diskreter Systeme. • SIMULA ist eine zwischen 1965 und 1967 von O. J. Dahl, B. Myhrhang und K. Nygaard als eine Erweiterung von ALGOL 60 entwickelte, prozeßorientierte Simulationssprache zur Simulation diskreter Systeme. SIMULA hat einen Sprachumfang, der mit dem einer höheren Programmiersprache vergleichbar ist. SIMULA eignet sich daher nicht nur zur Simulation. Die Verwendung von Simulationssprachen zur Modellerstellung wird auch als sprachorientierter Modellierungsansatz - im Unterschied zum blockorientierten Modellierungsansatz - bezeichnet. Der sprachorientierte Ansatz erlaubt die flexible Gestaltung von Simulationsmodellen für die unterschiedlichsten Anwendungen. Der blockorientierte Ansatz stellt dem Anwender vordefinierte, parametrisierbare Bausteine ("Blöcke") zur Verfügung; mit ihrer Hilfe kann ein Modell schnell erstellt und leicht verändert werden. Nachteilig ist die Einschränkung der Verwendbarkeit der Bausteine auf bestimmte Anwendungen. Demonstrationsbeispiel E. Ambichl zeigt am Beispiel eines Warenwirtschaftssystems, wie mit Hilfe eines in SQLBench implementierten Simulationsmodells die Leistung eines dialogorientierten Datenbanksystems (gemessen als Antwortzeitverhalten, Durchsatzrate und Ausfallsicherheit) durch Simulation der zu erwartenden Arbeitslast zum Zeitpunkt des Systementwurfs bestimmt werden kann. Damit können alternative Systementwürfe des Datensystems ("Datenmodell") und des Transaktionensystems ("Transaktionenmodell") auf alternativen Hardware-/SystemsoftwareKonfigurationen unter den im Systembetrieb zu erwartenden Lastsituationen auf ihr Leistungsverhalten hin überprüft werden. Das Datenmodell besteht aus den Entitäten Artikelstamm, Lager, Kasse, Bestellung, Bestell-/Lieferposition, Lieferung und Lieferant mit ihren typischen Attributen. Aus den Aufgaben des Warenwirtschaftssystems werden das Transaktionenmodell und die Stapelverarbeitungsaufgaben abgeleitet, und zwar: • im Funktionalbereich Einkauf die Stapelverarbeitungsfunktion "Bestelliste" und die Transaktionen "Bestellung" und "Lagerbestand"; • im Funktionalbereich Lager die Transaktion "Wareneingang" mit den Aktionen "Zuordnen der Lieferpositionen zu den Bestellpositionen", "Einbuchen der

SIMUL - Simulation

183

Lieferungen in das Lager" und "Fortschreiben der offenen Bestellungen im Artikelstamm"; • im Funktionalbereich Verkauf die Transaktion "Kasse" mit den Aktionen "Erstellen Rechnung", "Abbuchen vom Lager" und "Fortschreiben Kassensumme". Für die Transaktionen "Bestellung", "Lagerbestand" und "Wareneingang" wird je ein Transaktionsprototyp, für die Transaktion "Kasse" werden drei alternative Transaktionsprototypen erstellt. Die Arbeitslast wird durch Datenmengen (Anzahl und Umfang der Datensätze der Entitäten) und Transaktionshäufigkeiten beschrieben. Es wird angenommen, daß beim Systembetrieb von zwei Benutzern die Transaktionen "Bestellung" und "Lagerbestand", von einem weiteren Benutzer die Transaktion "Wareneingang" und an acht Kassenarbeitsplätzen die Transaktion "Kasse" aufgerufen werden. Insgesamt sind also elf Benutzer an elf Arbeitsstationen beteiligt, die durch Simulatoren abgebildet werden. Da das Trägersystem nur über fünf Arbeitsstationen und nicht über ein multitasking-fähiges Betriebssystem verfügt, werden die Transaktionen "Bestellung", "Lagerbestand" und "Wareneingang" mit einem Simulator an einer Arbeitsstation und die Transaktion "Kasse" mit vier Simulatoren an vier Arbeitsstationen simuliert. Die Durchführung der Simulationsstudie beginnt mit dem Generieren der Testdaten für die Datenbank. Anschließend werden die Abarbeitung der Transaktionen und der Stapelverarbeitungsaufgabe simuliert. Bezüglich der Transaktion "Kasse" wurde folgendes festgestellt: Im Simulationsintervall von 60 Minuten wurden 1000 Transaktionen mit 6014 Artikel-Abbuchungen durchgeführt. Die Antwortzeit für das Erfassen eines Artikels betrug im Durchschnitt 0,1 Sekunden (mit 99% der Zugriffe unter einer Sekunde). Die Antwortzeit nach dem Erfassen des letzten Artikels einer Transaktion ergibt sich aus der Summe der Antwortzeiten für das Abbuchen aller Artikel eines Verkaufsvorgangs und für das Fortschreiben des Kassenbuchs, im Durchschnitt 0,73 Sekunden. Eine Bewertung der Simulationsergebnisse bezüglich Transaktion "Kasse" und Systemeigenschaft "Antwortzeit" führt zu dem Urteil, daß bei gegebener Arbeitslast und Systemauslegung ein flüssiger Arbeitsablauf am Verkaufspunkt möglich ist. Kontrollfragen 1. Welches sind typische Einsatzgebiete der Simulation bei der Systemplanung? 2. Wie wird die Wirklichkeit als Simulationsmodell abgebildet? 3. Welche Experimente werden in der Analysephase mit welchem Zweck angewendet? 4. Wie kann der Ablauf einer Simulationsstudie beschrieben werden? 5. Welche Strategien können bei der Suche nach Systemalternativen angewendet werden? Quellenliteratur Bauer, W. und Vieweg, W.: Simulation. In: Grochla, E. (Hrsg.): Handwörterbuch der Organisation. 2. A., C. E. Poeschel Verlag, Stuttgart 1980, 2063 - 2075 Breitenecker, F. et al. (Hrsg.): Simulationstechnik. Proc. 6. Symposium Simulationstechnik. Vieweg Verlag, Braunschweig 1990 Liebl, F.: Simulation. Problemorientierte Einführung. Oldenbourg Verlag, München/Wien 1992 Mertens, P.: Simulation. 2. A., Poeschel Verlag, Stuttgart 1982

184

Methoden und Techniken der Systemplanung

Vertiefungsliteratur Ambichl, E.: Leistungsbewertung dialogorientierter Datenbanksysteme in Client/Server-Architektur. Dissertation Universität Linz, Linz 1991 Berger, S. und Förster, U.: Diskrete Systemsimulation auf Personalcomputern mit SIMAN. Arbeitspapier der Universität Paderborn, Schwerpunkt Wirtschaftsinformatik & Operations Research, Paderborn o.J. Krcmar, H.: Gestaltung von Computer-am-Arbeitsplatz-Systemen, Entwicklung von Alternativen und deren Bewertung durch Simulation. Minerva Publikationen, München 1984 Tempelmeier, H.: Simulation mit SIMAN. Ein praktischer Leitfaden zur Modellentwicklung und Programmierung. Physica Verlag, Heidelberg 1991

PRAET - Präsentationstechniken Lernziele Sie kennen den Zweck der Präsentationstechniken und ihre Anwendungsgebiete in der Systemplanung. Sie kennen wichtige Prinzipien zur Gestaltung von Kommunikationsmitteln, die in Präsentationstechniken verwendet werden, und Prinzipien zur Gestaltung von Vorträgen. Sie können die Gestaltungsprinzipien anwenden, um Projektergebnisse prägnant zu kommunizieren. Definitionen und Abkürzungen Bildsymbol (picture symbol) = ein Bild, dem eine bestimmte Bedeutung beigemessen wird. Synonym: Sinnbild. Botschaft (news) = die vom Sender gewollte Bedeutung einer Nachricht. Einfachheit (simplicity) = die der Präsentationssituation angepaßte, möglichst geringe Komplexität einer Botschaft bezüglich Satzbau, Wortwahl und grafisch-visueller Darstellung. Farbassoziation (color association) = das Zuordnen bestimmter Bedeutungen auf bestimmte Farben. Grafik (graphics) = die zeichnerische, schematisierende, schaubildliche Darstellung von Informationen, die vereinfachte Form eines Bildes (z.B. ein Piktogramm). Synonym: grafische Darstellung, kognitiv (cognitive) = das Erkennen, Denken und Wahrnehmen betreffend. Leseleitzeichen (reading key mark) = ein Bildsymbol, das verwendet wird, um den Betrachter (z.B. eines Textes) auf bestimmte Objekte (z.B. bestimmte Textteile) nachdrücklich hinzuweisen. Nachricht (message) = eine Folge von Zeichen zur Übermittlung einer Botschaft bzw. Information auf Grund bekannter oder unterstellter Abmachungen zwischen Sender und Empfänger. Prägnanz (conciseness) = die der Präsentationssituation angepaßte Redundanzarmut einer Botschaft. Redundanz (redundancy) = der Teil einer Nachricht, der keine Information enthält. Rolle (role) = ein System von Verhaltensregeln, das an den Inhaber einer Position gerichtet ist. Schriftart (type face) = die Gestalt der auf einem Medium sichtbar gemachten Zeichen der gleichen Schriftfamilie (z.B. die Schriftarten Chicago, Geneva, M o n a c o und Times). Störung (interference) = eine nicht beeinflußbare, äußere Einwirkung auf ein System, die zu einem Fehlverhalten führen kann. Struktur (structure) = die innere Ordnung einer Botschaft als zielgerichtete Folge von aufeinander aufbauenden Teilaussagen zu einer Gesamtaussage; diese Ordnung ist durch die Gliederung der Botschaft erkennbar, zusätzliche Stimulanz (additional Stimulation) = der Einsatz von Maßnahmen, welche die Aufnahmebereitschaft des Empfängers erhöhen; die Aktivierung erfolgt durch physische, kognitive oder emotionale Reize.

186

Methoden und Techniken der Systemplanung

Zweck der Präsentationstechniken Zweck der Präsentationstechniken ist die Übermittlung einer projektbezogenen Botschaft. Die Botschaft wird auf einem Kommunikationskanal vom Sender (z.B. von der Projektgruppe) zum Empfänger (z.B. zum Auftraggeber) übertragen. Bei der Übertragung können Störungen auftreten, welche die inhaltliche Übereinstimmung von Botschaft und Information beeinträchtigen. Dies zeigt Abbildung PRAET-1. Sender

Kommunikationskanal

Empfänger

Vom Empfänger richtig verstandene Botschaft Abb. PRAET-1: Störungen der Kommunikation

Präsentationstechniken sind die formale "Verpackung" einer Botschaft mit dem Ziel, eine weitgehende Übereinstimmung von Botschaft und Information herbeizuführen; sie sind darüber hinaus die Menge aller mündlichen, schriftlichen oder grafischen Mittel, welche die beim Kommunikationsprozeß auftretenden Störungen kompensieren und somit die geistige Verarbeitung der Botschaft erleichtern sollen. Anwendungsgebiete von Präsentationstechniken Die Aufgabe, projektbezogene Botschaften von einem Sender zu einem Empfänger zu übermitteln, besteht während des gesamten Prozesses der Systemplanung. Sie beginnt mit der Übermittlung der Planungsziele vom Auftraggeber (z.B. vom Lenkungsausschuß) zum Auftragnehmer (in der Regel zum Projektleiter) und endet erst, wenn das Projekt abgeschlossen und das Projektergebnis (also das produktive Anwendungssystem) vom Auftraggeber abgenommen worden ist. Wichtigstes Anwendungsgebiet der Präsentationstechniken ist die Übermittlung der Zwischenergebnisse und Ergebnisse der Systemplanung von der Projektgruppe zum Auftraggeber, insbesondere an den Meilensteinen eines IuK-Projekts. Präsentationstechniken werden aber auch angewendet, um die Kommuni-

PRAET - Präsentationstechniken

187

kation zwischen den Mitgliedern der Projektgruppe (z.B. zwischen ihren Arbeitsgruppen) zu unterstützen. Gestaltungsprinzipien für Kommunikationsmittel Präsentationstechniken verwenden Kommunikationsmittel, die nach bestimmten Prinzipien gestaltet werden. Wichtige Gestaltungsprinzipien für Kommunikationsmittel sind Partnerbezogenheit und Neuheit. • Prinzip der Partnerbezogenheit: Die "Verpackung" der Botschaft soll an die Wahrnehmungs- und Verarbeitungsgewohnheiten des Empfängers angepaßt sein, um die Verständlichkeit zu unterstützen. Dimensionen der Verständlichkeit sind Struktur, Einfachheit, Prägnanz und zusätzliche Stimulanz. • Prinzip der Neuheit: Die Botschaft soll für den Empfänger einen Neuheitswert besitzen, also Information enthalten. Ist kein Neuheitswert vorhanden, wendet der Empfänger seine Aufmerksamkeit von der Botschaft ab und blockiert die weitere inhaltliche Aufnahme. Gestaltungsprinzipien der Vortragstechnik Der Vortrag ist das wichtigste Mittel zur Präsentation. Gestaltungsprinzipien zur Planung und Durchführung eines Vortrags sind: • • • • • • • • •

• • • • •

Präsentationsziel festlegen; Zusammensetzung des Teilnehmerkreises feststellen; Raumsituation feststellen; Struktur der Präsentation festlegen: strukturellen Leitfaden mit Einleitung, Hauptteil und Schlußdiskussion entwickeln; Stoff sammeln und auswählen; Zeitablauf detailliert planen; visuelle Kommunikationsmittel herstellen; "Lampenfieber-Maßnahmen" planen; Präsentationsraum vorbereiten: * Visualisierungsmedien und visuelle Kommunikationsmittel aufbauen und überprüfen * "Stolperfallen" vermeiden * physische Kommunikationsbarrieren (z.B. Tischbarrieren zwischen Sender und Empfänger) vermeiden * Sichtbarkeit der Kommunikationsmittel aus allen Blickwinkeln prüfen Probelauf durchführen und gegebenenfalls korrigieren; Teilnehmer begrüßen und aufnahmebereit machen ("Anwärmen"); Präsentationsziel erklären und visuell dokumentieren (Visualisierung während des Vortrags sichtbar halten); Verhaltensregeln vereinbaren; Präsentationsinhalt darstellen; dabei sind folgende Grundsätze zu beachten: * Vortrag unter Verwendung des strukturellen Leitfadens frei sprechend halten, eventuell die einleitenden Sätze vorformulieren * während des Vortrags Augenkontakt zu den Empfängern suchen, die Fixierung einzelner Personen durch Augenkontakt von bis zu 1,5 sec. Dauer erhöht deren Aufmerksamkeit

188

Methoden

und Techniken der

Systemplanung

* die wichtigsten Botschaften durch Visualisierung unterstützen; der verbale Vortrag soll im Vordergrund bleiben, daher sind Ablenkungswirkungen durch übertrieben auffällig gestaltete visuelle Kommunikationsmittel zu vermeiden * Gestik, M i m i k und Körpersprache an die Präsentationssituation anpassen und bewußt zur Erreichung des Präsentationsziels einsetzen, die Vorderseite des Körpers offen dem E m p f ä n g e r zuwenden * Sprachmelodie und Sprachrhythmus dynamisch einsetzen * optimale Sprechgeschwindigkeit (rund 100 bis 120 Wörter pro Minute) verwenden; diese relativ niedrige Sprechgeschwindigkeit unterstützt die Technik des "Sprechdenkens", das heißt des Weiterdenkens des Satzes während des Sprechens * positive Ausdrucksweise bevorzugen * Teilnehmer im Dialog mit Aufgaben beschäftigen * durch "Lampenfieber" verursachte Denkblockaden durch Orientierung am strukturellen Leitfaden überspielen, gegebenenfalls neu beginnen * bei Zeitdruck strukturellen Leitfaden verfolgen, dabei die Tiefe der Darstellung reduzieren • bei der Schlußdiskussion die Teilnehmer zu Stellungnahmen, Entscheidungen und Rückkopplungen auffordern; • die Ergebnisse in positiver Form zusammenfassen. Gruppenpräsentation Bei der G r u p p e n p r ä s e n t a t i o n sind zusätzliche K o o r d i n i e r u n g s a u f g a b e n bei der Planung und der Durchführung zu erfüllen: • die Definition der Rollenstruktur innerhalb der Präsentationsgruppe; • die Planung des Präsentationsablaufs; • die Integration der Pläne für die einzelnen Präsentationsteile. Für die Definition der Rollen sind die demokratische Rollenverteilung und die hierarchische Rollenverteilung als Alternativen denkbar. Bei der d e m o k r a tischen R o l l e n v e r t e i l u n g präsentieren die Gruppenmitglieder nacheinander j e einen Teil der G e s a m t b o t s c h a f t . Die h i e r a r c h i s c h e R o l l e n v e r t e i l u n g ist dadurch gekennzeichnet, daß es einen Moderator und mehrere Mitglieder der Präsentationsgruppe gibt. Alternativen der Rollenverteilung sind der Moderator als Regisseur, als Präsentator oder mit Bindefunktion: • Der Moderator als Regisseur agiert im Hintergrund und tritt im Präsentationsszenario nicht aktiv auf. • Der Moderator als Präsentator übernimmt die Einleitung und den Schlußteil. • Der Moderator mit Bindefunktion tritt zwischen den einzelnen Präsentationsteilen mit überleitenden Worten auf. Bei der Planung des Präsentationsablaufs werden die inhaltlichen Präsentationsteile zunächst den Mitgliedern der Präsentationsgruppe zur Bearbeitung zugeordnet. Dann werden die Teilergebnisse integriert und auf Widerspruchsfreiheit geprüft. Die D u r c h f ü h r u n g der Präsentation erfolgt unter der k o o r d i n i e r e n d e n

PRAET - Präsentationstechniken

189

Führung des Moderators. Aufgaben des Moderators sind hierbei die Ablaufund Diskussionssteuerung sowie die Zeitüberwachung. Gestaltungsprinzipien der

Visualisierungstechnik

Für die Visualisierung sind die Medien Overhead-Folie, Flipchart, Kreidetafel, Hafttafel (magnetisch oder Pinboard) sowie Dia und Film (Video oder Zelluloid) geeignet. Die Wahl des Mediums oder des Medienmixes ist vom Präsentationsziel und von der Präsentationssituation abhängig. Eine Überladung des Vortrags durch visuelle Kommunikationsmittel ist zu vermeiden. Die wichtigsten Funktionen der Visualisierung sind Aktivierung (Erhöhung des Aufmerksamkeitsgrads), verbesserte Wahrnehmung, Unterstützung der Lernwirkung und Übersichtlichkeit von Gesamtzusammenhängen. Die visuellen Gestalt u n g s v a r i a b l e n sind Form, Farbe und Menge der verwendeten Schrift- und Bildsymbole. Bewährte Gestaltungsprinzipien für visuelle Kommunikationsmittel sind Schriftart, Schriftgröße, Strichstärke und Farbe der Bildsymbole. Die optimale Schriftart ist die Druckschrift, also Groß- und Kleinbuchstaben mit deutlichen Ober- und Unterlängen. Die Schriftgröße wird in Abhängigkeit vom Abstand des Empfängers vom Kommunikationsmedium festgelegt (vgl. Abbildung PRAET-2). Die zweckmäßigste maximale Entfernung beträgt 5 m. Maximale Entfernung in Metern

Optimale Schriftgröße in Zentimetern

5

15 bis 20

10

20 bis 30

15

30 bis 40

Abb. PRAET-2: Optimale Schriftgröße

Farbe

Assoziationen

gelb

hell

heiter, freudig

orange

warm

froh, festlich, anreizend

rot

aktiv

stark, laut, aufreizend

violett

dunkel

würdevoll, stattlich

blau

kalt

stabil, treu, angenehm

grün

passiv

ruhig, natürlich, gelassen

Abb. PRAET-3: Beispiele für Farbassoziationen

190

Methoden

und Techniken der

Systemplanung

Die optimale Strichstärke beträgt 3 bis 4 mm. Hervorhebungen können über vergrößerte Schrift oder Farbdiskontinuität realisiert werden. Die Farbe von Bildsymbolen stellt über instinktive Assoziationsmechanismen die Verbindung zwischen Botschaft und Emotion her. Abbildung PRAET-3 zeigt Beispiele für Farbassoziationen. Die Zusammenhänge zwischen Helligkeit, Kontrast und Farbintensität sind zu beachten (vgl. z.B. die "Tabelle der Lesbarkeit" von Le Courier). Demonstrationsbeispiel Abbildung PRAET-4 zeigt Beispiele für Formen von Bildsymbolen in freien grafischen Darstellungen, die den Gestaltungsprinzipien von Kommunikationsmitteln entsprechen. Die Menge von sieben verschiedenen Bildsymbolen auf einem visuellen Kommunikationsmedium entspricht der durchschnittlichen simultanen Aufnahmekapazität des menschlichen Wahrnehmungsapparats. Abbildung PRAET-5 zeigt Beispiele für sogenannte Leseleitzeichen, deren Zweck es ist, die Aufmerksamkeit der Betrachter auf bestimmte Objekte (z.B. auf die jeweils wichtigsten Gesichtspunkte) zu lenken.

o Objekt

Kanal

W iI

Schnittmenge Aufbau

Abfolge

Richtung

Wirkung

Stufenfolge

(§) Problemkern

n

O

•

O

O

>•[>¡>0

A A Abb. PRAET-5: Beispiele für Leseleitzeichen Kontrollfragen 1. 2. 3. 4. 5.

Welcher Unterschied besteht zwischen Botschaft, Nachricht und Information? Was besagt das Prinzip der Partnerbezogenheit? Welche Gestaltungsprinzipien gelten für die Planung und Durchführung eines Vortrags? Was wird unter "demokratischer" und was unter "hierarchischer" Rollenverteilung bei der Definition der Rollenstruktur bei Präsentationsgruppen verstanden? Welche Bedeutung hat die Farbe von Symbolen; welche Farben lösen welche Assoziationen aus?

Quellenliteratur Bernstein, D.: Die Kunst der Präsentation. 2. A., Campus Verlag, Frankfurt/New York 1992 Bischoff, U. et al.: Schaubilder als Führungsinstrument. Technik und Methodik visueller Kommunikationshilfen. Verlag Moderne Industrie, München 1971

DARST - Darstellungstechniken Lernziele Sie kennen die formalen Unterscheidungskriterien der Darstellungstechniken und können deren Verwendung in der Systemplanung beurteilen. Sie kennen Darstellungstechniken der Aufbauorganisation und der Ablauforganisation. Sie sind in der Lage, typischen Sachverhalten der Systemplanung geeignete Darstellungstechniken zuzuordnen. Sie erkennen die Bedeutung der Verwendung von grafischen Hilfsmitteln und von standardisierten oder genormten Symbolen. Definitionen und Abkürzungen Ablauforganisation (process Organization) = die raum-zeitliche Gliederung der in einer Organisation zur Aufgabenerfüllung erforderlichen Tätigkeiten ("Arbeitsabläufe"); im Unterschied zu Aufbauorganisation. ASME-Symbolik (ASME symbolics) = eine von der American Society of Mechanical Engineers entwickelte Technik zur Darstellung von Belegflüssen und den zwischen ihren Teilen bestehenden Beziehungen. Aufbauorganisation (organizational structure) = die Gliederung einer Organisation in Struktureinheiten ("Stellen"); im Unterschied zu Ablauforganisation. Bild (picture) = eine Informationsart (neben Daten, Text und Sprache), die als eine Darstellung von Objekten auf einer Räche beschrieben werden kann. DFP = Abkürzung für Datenflußplan. Diagramm (diagram) = die grafische Darstellung von Abhängigkeiten zwischen zwei oder mehr als zwei Größen mit dem Ziel der besseren Sichtbarmachung und Verständlichkeit der Zusammenhänge. E C M A - S y m b o l i k (ECMA symbolics) = die von der European Computer Manufacturera Association entwickelten Symbole und Techniken, die weitgehend der DIN 66001 entsprechen. Formular (printed form) = eine arbeitsvorbereitende Drucksache, deren unveränderlicher inhaltlicher Teil ("Vordruck") mit veränderlichen Daten und veränderlichem Text vom Aufgabenträger ergänzt wird. Grafik (graphies) = die zeichnerische, schematisierende, schaubildliche Darstellung von Informationen; die vereinfachte Form eines Bildes. N-S-Diagramm (N-S chart) = Abkürzung für Nassi-Shneiderman-Diagramm. Nassi-Shneiderman-Diagramm = Synonym für Struktogramm. Notation (notation) = ein System von Zeichen zur Informationsdarstellung. Pseudo-Code (pseudo code) = ein einfaches Beschreibungsmittel, das aus einer Mischung von formal-sprachlichen und natürlich-sprachlichen Elementen besteht. Schau bild (chart) = die grafische Darstellung eines tatsächlichen oder eines gedachten Beziehungskomplexes oder einer Geschehensabfolge. Symbol (symbol) = ein Zeichen oder ein Wort, dem eine Bedeutung beigemessen wird. T a b e l l e (table) = die übersichtliche Darstellung von Text und Daten in der Form von Zeilen und Spalten.

DARST - Darstellungstechniken

193

Zweck der Darstellungstechniken "Darstellen" hat im allgemeinen die Bedeutung von "etwas beschreiben, wiedergeben, schildern". Im engeren Sinn ist die Wiedergabe in Bildform und/oder in Symbolform gemeint, also die Übertragung verbaler Beschreibungen in bildhafte und/oder in symbolhafte Beschreibungen. Daraus entwickelte Darstellungstechniken verbessern die Aussagekraft verbaler Beschreibungen. In der Systemplanung werden Darstellungstechniken als Mittel der Kommunikation zwischen den an einem Projekt der Systemplanung beteiligten Aufgabenträgern (vgl. Lerneinheit AUTER) und zur Dokumentation (vgl. Lerneinheit DOKUM) verwendet. Darstellungstechniken verdeutlichen Sachverhalte und erleichtern die Verständlichkeit und Klarheit von Ergebnissen der Systemplanung. Die Tendenz zur "Visualisierung" geht zum Teil so weit, daß die bild- und/oder symbolhafte Darstellung im Mittelpunkt steht; der Text dient nur noch der Erläuterung. Impliziert die angewendete Darstellungstechnik über die reine Darstellung hinaus eine spezifische Vorgehensweise, dann wird sie zur Entwurfsmethode und/oder zur Analysemethode. Solche "Darstellungstechniken" sind - soweit sie in diesem Lehrbuch behandelt werden - Entscheidungstabellen-Technik (vgl. Lerneinheit ENTAB), Hierarchical Input, Process and Output (vgl. Lerneinheit HIPO), Structured Analysis and Design Technique (vgl. Lerneinheit SADT), Datenflußdiagramme (vgl. Lerneinheit DAFLU), Petri-Netze (vgl. Lerneinheit PENET), Matrixanalyse (vgl. Lerneinheit MATRX), Netzplantechnik (vgl. Lerneinheit NETZP) und Kommunikationsanalyse (vgl. Lerneinheit KOMAN). Formale Unterscheidungskriterien der Darstellungstechniken Für die Darstellung organisatorischer Sachverhalte eignen sich grundsätzlich alle Formen einer systematischen mündlichen und schriftlichen Artikulation ("Sprache" im weitesten Sinn). Von der Art der Darstellung ausgehend werden verbale, tabellarische und grafische Darstellungstechniken unterschieden. Verbale Darstellungstechniken lassen sich in mündliche und in schriftliche unterteilen. Eine Präsentation oder ein Vortrag ist die durch Visualisierungstechniken unterstützte mündliche Darstellung (vgl. Lerneinheit PRAET). Schriftliche verbale Darstellungen können sein: Berichte, Beschreibungen, Anweisungen, Formeln, Programmausdrucke. Berichte, die z.B. in einem Projekt der Systemplanung in den einzelnen Phasen entstehen, werden über ihren verbalen Teil hinaus durch Schaubilder ergänzt. Beschreibungen enthalten über ihren deskriptiven Informationsgehalt hinaus häufig Informationen, die für die Bezugsperson Anweisungscharakter haben (z.B. eine Benutzerordnung, ein Katastrophen-Handbuch oder Organisations- und Arbeitsanweisungen). Verbale Darstellungen von Programmen sind für Dokumentationszwecke als Pseudo-Code oder als Programmlisten in einer bestimmten Programmiersprache üblich. Die Aussagekraft von schriftlichen verbalen Darstellungen läßt sich durch die Verwendung von Formularen verbessern. Um tabellarische Darstellungstechniken handelt es sich, wenn in zweidimensionaler Form in Spalten und Zeilen Wortbegriffe und/oder Zahlen systematisch angeordnet werden. In besonderen Fällen wird eine dreidimensionale Ord-

194

Methoden und Techniken der Systemplanung

nung der Elemente versucht, die durch einen perspektivisch gezeichneten Würfel dargestellt wird (vgl. als Beispiel Abbildung WSICH-3 in Band 2 "Systemplanung"). Eine spezielle Form der Tabelle ist die Matrix, in der die Zugehörigkeit jedes Elements zu einer Zeile und zu einer Spalte besonders hervorgehoben wird. In der Systemplanung werden Matrizen häufig zur Darstellung von Beziehungen zwischen den Elementen von zwei Mengen benutzt (vgl. Lerneinheit MATRX). Mit grafischen Darstellungstechniken können Strukturen von Ganzheiten (Elemente und Beziehungen zwischen Elementen) abgebildet werden. Die Beziehungen werden durch ungerichtete oder gerichtete Verbindungslinien dargestellt. Diagramme sind einfache, für den Betrachter relativ leicht überschaubare grafische Darstellungen. Netze sind grafische Darstellungen höherer Ordnung, mit denen komplexe Beziehungen abgebildet werden können (vgl. Lerneinheiten NETZP und PENET).

Darstellungsmethode

Abbildung DARST-1 gibt einen Überblick über die formalen Unterschiede der Darstellungstechniken und eine Reihe von Kriterien zur Beurteilung der Brauchbarkeit dieser Darstellungstechniken (z.B. Umfang, Übersichtlichkeit, Formalisierbarkeit, Vollständigkeit). Nach inhaltlichen Gesichtspunkten werden Darstellungstechniken danach eingeteilt, was mit ihnen (vornehmlich) dargestellt wird: Funktionen oder Stellen (also primär Sachverhalte der Aufbauorganisation) oder Abläufe (also primär Sachverhalte der Ablauforganisation).

Verbale Beschreibung Verbale Beschreibung mit Formularen

Beurteilungskriterium ÜbersichtBeFormaliUmfang lichkeit schreibung Auswertung sierbarkeit abhängig nein schwierig nein vom Verfasser groß ja

Tabellarische Darstellung

gelenkt

vereinfacht

ja

schwer erkennbar

Hinweise einheitlicher auf mögliche Rahmen Lücken gleiche Struktur

konkret klein

Grafische Darstellung

gelenkt

Vollständigkeit

anschaulich

Aufdecken verschiedene von Lücken Struktur

Abb. DARST-1: Beurteilung der Darstellungstechniken (Quelle: nach Rautenberg)

Darstellungstechniken der Aufbauorganisation Zu den verbalen Darstellungstechniken der Aufbauorganisation zählen Stellenbeschreibungen und Organisationsanweisungen. In Stellenbeschreibungen werden die weisungsbezogene und die kommunikative Einordnung von Stellen, Aufgaben und Kompetenzen der Aufgabenträger sowie die Anforderungen an die Aufgabenträger festgehalten. Sie dokumentieren Zuständigkeiten und Unterstellungsverhältnisse. Organisationsanweisungen sind schriftlich fixierte, verbindliche Regelungen, Richtlinien und Vorschriften. Sie enthalten z.B. Grundsatzentscheidungen zur Geschäftspolitik und die daraus resultierenden Ausführungsbestimmungen sowie die Festlegung von Ordnungsbegriffen (z.B. von

DARST - Darstellungstechniken

195

Nummernsystemen, vgl. Lerneinheit NUMSY im Band 2 "Systemplanung") und Formularen ("Formularwesen"). Aufbau und Einsatz von Organisationsanweisungen sollen einheitlich und in einem Organisationshandbuch zusammengefaßt dargestellt sein. Grafische und tabellarische Darstellungstechniken in der Aufbauorganisation werden zur Abbildung der Abteilungs- und Stellengliederung ("Organigramm"), zur Abbildung von Funktionen und ihrer Zerlegung in Teilfunktionen ("Funktionenbaum"), zur Abbildung von Funktionen und ihrer Zuordnung auf Stellen ("Funktionendiagramm"), zur Abbildung von Kommunikationsbeziehungen (vgl. Lerneinheit KOMAN) und zur Abbildung sozialer Beziehungen ("Soziogramm", "Soziomatrix") verwendet. Beim Organigramm ist eine hierarchische Anordnung der Elemente am weitesten verbreitet. Diese Darstellungsform hat den Nachteil, daß die Schaubilder "in die Breite" gehen. Schon ab der dritten oder vierten Ebene muß das Organigramm in Einzeldarstellungen aufgelöst werden. Dieser Nachteil wird durch die Darstellung in Säulenform gemindert. Dabei werden die ersten zwei bis drei Ebenen nach wie vor hierarchisch angeordnet, alle weiteren Ebenen werden vertikal untergliedert. Abbildung DARST-2 zeigt ein Organigramm in Säulenform. Andere Formen von Organigrammen sind die Darstellung in horizontaler Anordnung als Ringsegment-Organigramm, als Sonnen-Organigramm oder als Block-Organigramm. Welche Form der Darstellung von Organigrammen gewählt wird, hängt insbesondere davon ab, wieviele hierarchische Ebenen abgebildet werden müssen.

Abb. DARST-2: Organigramm in Säulenform (Quelle: Schmidt)

Werden statt der Struktureinheiten (Abteilungen und Stellen) Funktionen und ihre Zerlegung mit einem Organigramm abgebildet, heißt diese Darstellungsform Funktionenbaum. Hat der Baum einen beliebigen Inhalt, heißt eine Abbildung dieser Art Zerlegungsdiagramm, weil sie zeigt, wie ein Objekt von Ebene zu

196

Methoden und Techniken der Systemplanung

Ebene in Teilobjekte "zerlegt" wird. Der Inhalt eines Zerlegungsdiagramms kann verbal, also ohne Verwendung grafischer Symbole, als Aktionendiagramm abgebildet werden. Abbildung DARST-3 zeigt ein Zerlegungsdiagramm und das diesem äquivalente Aktionendiagramm; daraus ist ersichtlich, daß sich das Aktionendiagramm besonders gut für eine vertikale Ausdehnung eignet. —

Aufgabe - Funktion 1 _

E

TF 11 TF 12 TF 13

Funktion 2 TF 21 TF 22

Abb. DARST-3: Zerlegungsdiagramm (links) und äquivalentes Aktionendiagramm (rechts)

Stelle 1 Stelle 2 Stelle 3

•stteilen ai ö AuPv a^ gaben \ 00 Aufgabe A K E A Aufgabe B K X X Aufgabe C P Aufgabe D X

Stelle n

Das Funktionendiagramm (auch als Funktionenmatrix bezeichnet) ist die Verbindung von Organigramm und Aufgabengliederung in Form einer Matrix. In den Spalten werden die Stellen (Aufgabenträger), in den Zeilen die Aufgaben dargestellt. Im Schnittpunkt zwischen Spalten und Zeilen wird mit einem Symbol die Art der Aufgabe bzw. der Befugnisse angegeben. Abbildung DARST-4 zeigt ein Funktionendiagramm, in dem die Symbole K = Kontrolle, E = Entscheidung, A = Ausführung, P = Planung und X = Gesamtfunktion verwendet werden. Der Aussagewert des einfachen Funktionendiagramms kann durch das Einfügen weiterer Spalten (z.B. Spalten, die den Zeitverbrauch je Zeiteinheit und die Häufigkeit der Aufgabendurchführung je Zeiteinheit angeben) verbessert werden.

|

Aufgabe N

Abb. DARST-4: Funktionendiagramm

Mit einem Soziogramm werden die zwischen Individuen einer Gruppe bestehenden Beziehungen in Form einer Grafik abgebildet. Die Erstellung eines Soziogramms erfolgt in der Regel in der Gruppe, indem die Mitglieder der Gruppe zunächst ihre Sicht auf die bestehenden Beziehungen dokumentieren; die Ergebnisse werden zum Soziogramm zusammengefaßt. Mit Hilfe einer spezifischen

DARSI - Darstellungstechniken

197

Notation wird versucht, auch quantitative Eigenschaften sichtbar zu machen (wie z.B. die Anzahl der Sympathien und Antipathien). Abbildung DARST-5 zeigt ein Beispiel, in dem Dreiecke männliche Personen und Kreise weibliche Personen kennzeichnen. Die Eintragung im oberen Feld identifiziert die Person, die Eintragung im linken Feld die Anzahl der Sympathien und die Eintragung im rechten Feld die Anzahl der Antipathien; die gestrichelte Linie kennzeichnet Sympathie, die durchgezogene Linie kennzeichnet Antipathie.

Abb. DARST-5: Soziogramm (Quelle: nach Schilling)

Darstellungstechniken der Ablauforganisation Bei den Darstellungstechniken der Ablauforganisation wird zwischen verbalen Darstellungstechniken und grafischen Darstellungstechniken unterschieden. Bei verbalen Darstellungstechniken wird auf die Verwendung von grafischen Symbolen verzichtet; es werden lediglich die textlichen Aussagen in geeigneter Form gruppiert, womit der visuelle Zugang zur Information erleichtert wird. Die wichtigsten verbalen Darstellungstechniken sind die verbale Rasterdarstellung und die Darstellung als geblockte Texte. Mit Abbildung DARST-6 und Abbildung DARST-7 werden die Unterschiede zwischen der verbalen Rasterdarstellung und der Darstellung als geblockte Texte verdeutlicht. Abbildung DARST-6 zeigt den Arbeitsablauf einer Auftragsabwicklung als verbale Rasterdarstellung, Abbildung DARST-7 denselben Arbeitsablauf als geblockte Texte. Die verbale Rasterdarstellung hat gegenüber den geblockten Texten den Vorteil, daß die Zuständigkeiten für die Aufgaben besonders gut erkannt werden können. Der Vorteil geblockter Texte besteht in der größeren Kompaktheit der Aussagen.

198

Methoden und Techniken der Systemplanung

Arbeitsablauf Aufgenommen von: am: ArbeitsSchreibstufe Poststelle stelle

1

Versand

Lieferfähigkeit prüfen

3

1 Absage schreiben

4

6

Geprüft von: am: Berührte Stelle der Abteilung SachFaktu- Rechnungsprüfung bearbeitung rierung

Annahme Auftrag

2

5

Abteilung oder Bereich

U Versand Absage

7 8 9

Nicht lieferfähig: Absage

* Unterschrift Lieferfähig: Angaben prüfen Fehl .Angaben ergänzen/ nachfragen Bonität prüfen/Vermerk Re.o.Nachn.

* Rechnung schreiben

V

10

Rechnung prüfen

11

Rechnungssätze trennen

12

2. und 3. Kopie Original und 1. Kopie

V

Sendung zusammenstellen

Auftrag Nr.

Blatt: Abb. DARST-6: Verbale Rasterdarstellung (Quelle: Schmidt)

Buchhaltung

DARST - Darstellungstechniken

199

1. Aufträge abwickeln 1.1. Auftrag annehmen 1.1.1 Telefonische Aufträge

1.1.2 Fernschriftliche Aufträge

Internen Auftrag erstellen 1.2. Lieferfähigkeit prüfen nicht lieferfähig: 1.2.1 Absagen

1.1.3 Schriftliche Aufträge

Lieferfähig: 1.2.2 Weiterbearbeiten

1.3. Angaben auf Vollständigkeit prüfen 1.3.1 Angaben nicht vollständig 1.3.1.1 Angaben 1.3.1.2 Angaben nicht verfügbar: verfügbar: ergänzen fragen, ergänzen

1.3.2 Angaben vollständig

1.4. Bonität des Kunden prüfen 1.4.1 Bonität in Ordnung: Vermerk "Rechnung"

1.4.2 Bonität nicht in Ordnung: Vermerk "Nachnahme"

1.5. Bestellung weiterleiten an Fakturierung 1.6. Fakturieren 1.6.1 Rechnung erstellen 1.6.2 Rechnung prüfen 1.6.3 Rechnungssatz trennen 1.6.4 Weiterleiten 1.6.4.^^rigui^M^^^CM)iejmJ^rsand

| 1.6.4.2 2. und 3. Kopie an Buchhaltung

1.7. Versenden 1.7.1 Sendung zusammenstellen 1.7.2 Sendung verpacken 1.7.3 Sendung an Expedition weiterleiten Abb. DARST-7: Geblockte Texte (Quelle: Schmidt) Lfd. Nr.

1. 2. 3.

Arbeitsstufe Fakturierung Übergabe an Verkaufsabteilung Lagerung bis zum Postversand

Symbol •

M

Zeit D

V 1 h/Tag

O ^ D D V

10 min/Tag

O i = > D Ì I V

2 h/Tag

Menge

Bemerkung

100 Stück/Tag

Abb. DARST-8: Ausschnitt aus einer Arbeitskarte mit ASME-Symbolen (Quelle: Rautenberg) G r a f i s c h e D a r s t e l l u n g s t e c h n i k e n entstehen durch die V e r w e n d u n g von graf i s c h e n S y m b o l e n , d e n e n b e s t i m m t e B e d e u t u n g e n zugeordnet sind. Eine der ältesten g r a f i s c h e n Darstellungstechniken der A b l a u f o r g a n i s a t i o n ist die A r b e i t s a b l a u f k a r t e . Z u r Darstellung v o n Belegflüssen und der Beziehungen zwischen den K o m p o n e n t e n der Belegflüsse wird die A S M E - S y m b o l i k verwendet. Fünf A S M E - S y m b o l e sind üblich: Bearbeitung (Kreis), Kontrolle (Rechteck),

200

Methoden

und Techniken der

Systemplanung

Transport (Pfeil), Verzögerung ("D" für Delay) und Lagerung bzw. Ablage (auf der Spitze stehendes Dreieck). Mit der Arbeitsablaufkarte können einfache und verzweigte Abläufe an nur einem Objekt leicht verständlich und schnell abgebildet werden. Für die Darstellung von Zyklen und vielfachen Verzweigungen in Abläufen ist diese Technik nicht geeignet. Abbildung DARST-8 zeigt einen Ausschnitt aus einer Arbeitsablaufkarte mit ASME-Symbolen.

Abb. D A R S T - 9 : Systematisierter Datenflußplan nach D I N 66001

Das Blockdiagramm wird in der Systemplanung häufig verwendet; nach DIN 66001 gehören dazu der Datenflußplan und der Programmablaufplan. Ein Datenflußplan zeigt den "Fluß von Daten durch ein datenverarbeitendes System" in Form einer grafischen Darstellung der Strukturmerkmale des Datenflusses, die aus Symbolen mit zugehörigem Text und gerichteten Verbindungslinien besteht. Es wurden Symbole für Bearbeiten, für Ein-/Ausgeben und für Ablauflinien genormt. Abbildung DARST-9 zeigt einen nach DIN 66001 systematisierten Datenflußplan. Ein Programmablaufplan (PAP) besteht ebenfalls aus Sinnbildern mit zugehörigem Text und gerichteten Verbindungslinien. Hier stehen nicht die verwendeten Sachmittel und Datenträger im Vordergrund (wie beim Datenflußplan), sondern die Art und die zeitliche Reihenfolge der Operationen und die möglichen Verzweigungen eines Ablaufs in ihrer Abhängigkeit von Bedingungen (vgl. dazu Abbildung DARST-10, rechter Teil). Zum Entwerfen und Dokumentieren von Programmen eignen sich (nach einem Vorschlag von I. Nassi und B. Shneiderman) Struktogramme wesentlich besser als Programmablaufpläne. In Struktogrammen wird eine Symbolik angewendet, die sich an den Regeln der strukturierten Programmierung orientiert, insbesondere an der Forderung, den Steuerfluß eines Programms auf die drei Grundtypen

DARST - Darstellungstechniken

201

Reihung (Sequenz), Auswahl (Selektion) und Wiederholung (Iteration) zu beschränken. Abbildung DARST-10 zeigt die Grundtypen eines Struktogramms (linker Teil) im Vergleich mit den Symbolen eines Programmablaufplans (rechter Teil).

R e i h u n g (Sequenz)

SB 1 SB 2 SB 3 Auswahl (Selektion) ^s^edingung ja SB 1

\

nein SB 2

W i e d e r h o l u n g (Iteration) S B = Strukturblock Wiederholungsbedingung SB

Abb. D A R S T - 1 0 : Grundtypen des Struktogramms im Vergleich mit den Symbolen des Programmablaufplans

Vorteile des Struktogramms, insbesondere im Vergleich zum Programmablaufplan, sind: • Es unterstützt die Erstellung von "gut strukturierten" Programmen; das Steuerkonstrukt "Sprung" (GOTO-Anweisung) ist nicht darstellbar. • Es entspricht der Entwurfsmethode der schrittweisen Verfeinerung. • Es zeigt die logische Struktur des Ablaufs und ist daher von den Feinheiten der Implementierungssprache unabhängig. • Es zwingt auf Grund seiner Strukturierung in Blöcke zu einer überschaubaren Gliederung (Blockprinzip). Insgesamt gesehen eignen sich Struktogramme gut für die Darstellung von Programmen im Detail; sie lassen sich auch leicht in Programm-Code übertragen. Ungeeignet sind Struktogramme für die Abbildung größerer und gegliederter Zusammenhänge und der Beziehungen zwischen ihren Komponenten. Allein wegen des relativ hohen Änderungsaufwands sind Struktogramme nur dann verwendbar, wenn Erstellung und Pflege durch ein Werkzeug unterstützt werden. B a l k e n d i a g r a m m e (auch Gantt-Diagramme genannt) sind zweidimensionale Koordinatensysteme. Normalerweise werden auf der Abszisse ein Zeitmaß und

202

Methoden

und Techniken der

Systemplanung

auf der Ordinate die Bearbeitungsstellen oder Teilverrichtungen ("Auftragsfortschrittsplan") eingetragen. Die Länge der Balken gibt den Zeitverbrauch je Bearbeitungsstelle oder Teilverrichtung an. Die Lage der Balken zueinander zeigt die zeitlichen Folgebeziehungen. Balkendiagramme ermöglichen in einem sehr beschränkten Umfang ähnliche Aussagen wie Netzpläne (vgl. Lerneinheit NETZP); sie erlauben z.B. nicht die Darstellung von Abhängigkeiten zwischen den Tätigkeiten. Ein G r a p h ist eine (im allgemeinen endliche) Menge von Punkten, die durch eine (im allgemeinen endliche) Menge von Strecken miteinander verbunden sind. In der Graphentheorie werden die Punkte als Knoten oder Ecken, die sie verbindenden Strecken als Kanten bezeichnet. Wenn die Kanten einen bestimmten Richtungssinn haben, werden sie als gerichtete Kanten oder als Pfeile bezeichnet; man spricht dann von gerichteten Graphen; sonst handelt es sich um ungerichtete Graphen. Sind alle Knoten durch Kanten direkt oder indirekt miteinander verbunden, dann ist das ein zusammenhängender Graph; ein vollständiger Graph liegt vor, wenn alle Knoten direkt durch Kanten verbunden sind. Eine Folge von Pfeilen, bei der keine Abzweigungen auftreten, wird als Kette bezeichnet. Eine Folge von Pfeilen, bei denen der Endknoten des einen Pfeils der Anfangsknoten des folgenden Pfeils ist, heißt Weg. Ein Baum ist ein zusammenhängender Graph, bei dem von jedem Knoten zu allen anderen Knoten nur eine Kantenfolge führt. Eine Schleife ist ein Pfeil, der einen Knoten mit sich selbst verbindet. Ein Zyklus liegt vor, wenn ein Knoten über mehrere Pfeile mit sich selbst verbunden ist. Die Knoten können z.B. Aufgabenträger, Stellen, geografische Orte, Objekte, Aktivitäten oder irgendwelche Zustände eines Systems sein, während die Kanten die Beziehungen zwischen den durch die Knoten dargestellten Systemelementen veranschaulichen. Den Kanten können - mit Hilfe von Zahlen - Größen zugeordnet werden, z.B. Distanzen, Zeitdauern, Kosten und Kapazitäten ("bewertete Graphen"). Eine der am meisten verbreiteten Anwendungen der Graphentheorie ist die Netzplantechnik (vgl. Lerneinheit NETZP). Wird ein gerichteter Graph zur Darstellung des sequentiellen Ablaufs der Entscheidungsfindung verwendet, heißt er Entscheidungsbaum. Die Knoten des Entscheidungsbaums sind Entscheidungsknoten (Rechteck), Ereignisknoten (Kreis) oder Endknoten (Dreieck); die gerichteten Kanten sind Entscheidungskanten oder Ereigniskanten. Knoten und Kanten werden mit den abgebildeten Entscheidungen und Ereignissen bezeichnet. Das Polaritätsprofil ist eine Darstellungstechnik, die geeignet ist, skalierbare Eigenschaften von Objekten zu veranschaulichen. Mit einem Polaritätsprofil können mehrere Merkmale unterschiedlicher Objekte in einer Darstellung abgebildet werden. Dadurch wird das Vergleichen der abgebildeten Objekte vereinfacht. Das Polaritätsprofil kann z.B. im Rahmen der Durchführbarkeitsstudie (vgl. Lerneinheit GRUND) zur Darstellung der wichtigsten Eigenschaften bestehender Systeme, zur Darstellung der Bewertung verschiedener Systemkonzepte sowie zur Darstellung der Anwendungsbereiche von Techniken und Hilfsmitteln verwendet werden. Abbildung DARST-11 zeigt ein Polaritätsprofil für drei alternative Software-Produkte und sechs Eigenschaften.

DARST - Darstellungstechniken

203

Eine Abart des Polaritätsprofils sind die Polarkoordinaten ("Kiviath-Graph"). Die Strecken, die zur Abbildung der skalierbaren Eigenschaften dienen, sind strahlenförmig um ein Zentrum angeordnet. Die Koordinaten tragen den Maßstab, in dem die Zielerreichung gemessen wird. Abbildung DARST-12 zeigt einen Kiviat-Graph, mit dem Ziele und Zielerreichung am Beispiel von zwei Software-Produkten dargestellt sind. Zielkriterien

0%

Funktionsumfang Anwendungssoftware

Ausmaß der Zielerreichung 25 % 50 % 75 % t! :!

Softwarequalität

100 %

rji*-' Jr

Leistung Preis

^Na

Wartung und Unterstützung

SX

Vertragsgestaltung

A O"

szsmmmmmii Angebot A

Angebot B Abb. DARST-11: Polaritätsprofil

Durchsatzzeit 100

Systembelastung Abb. DARST-12: Kiviat-Graph

O

[V Ö ?

O Angebot C

204

Methoden und Techniken der Systemplanung

Kontrollfragen 1. 2. 3. 4. 5.

Durch welche formalen Kriterien unterscheiden sich die Darstellungstechniken? Welche Darstellungstechniken eignen sich zur Abbildung der Ablauforganisation? Welcher Unterschied besteht zwischen einem Datenflußplan, einem Programmablaufplan und einem Struktogramm? Was versteht man unter ASME-Symbolik, was unter ECMA-Symbolik? Für welche Darstellungsaufgaben kann ein Polaritätsprofil sinnvoll verwendet werden?

Quellenliteratur Haag, W.: Dokumentation von Anwendungssystemen aus der Sicht der Benutzer. Toeche-MittlerVerlag, Darmstadt 1981 Joschke, H. K.: Darstellungstechniken. In Grochla, E. (Hrsg.): Handwörterbuch der Organisation. 2. A„ Poeschel Verlag, Stuttgart 1980, 431 - 462 Rautenberg, K.-U. und Sova, O.: Dokumentation computergestützter Informationssysteme. Saur Verlag, München 1983 Schmidt, G.: Methode und Techniken der Organisation. 8. A., Verlag Schmidt, Gießen 1989 Vertiefungsliteratur Ardelt, E.: Soziogramm. In: Roth, M. (Hrsg.): Sozialwissenschaftliche Methoden. 2. A., Oldenbourg Verlag, München/Wien 1987,184 - 195 Martin, J. and McClure, C.: Structured Techniques. The Basis for CASE. Rev. Ed., Prentice Hall Inc., Englewood Cliffs, N.J. 1988 Nassi, I. and Shneiderman, B.: Flowchart Techniques for Structured Programming. In: ACM SIGPLAN Notices 8/1973,12 - 26 Normen DIN 44300 DIN 66001 DIN 66261

Informationsverarbeitung. Begriffe Informationsverarbeitung. Sinnbilder filr Datenfluß- und Programmablaufpläne Informationsverarbeitung. Sinnbilder für Struktogramme nach Nassi-Shneiderman

NETZP - Netzplantechnik Lernziele Sie kennen die Methoden der Netzplantechnik und können ihre Anwendung in der Systemplanung beurteilen. Sie können die Aufgabe der Projektplanung mit Hilfe der Netzplantechnik in Teilplanungen mit entsprechenden Analysen gliedern und die Vorgehensweise der Teilplanungen beschreiben. Sie kennen die drei Darstellungsformen für Netzpläne mit ihren Gemeinsamkeiten und Unterschieden. Sie können Netzpläne nach diesen Darstellungsformen entwerfen. Definitionen und Abkürzungen CPM = Abkürzung für Critical Path Method (Methode des kritischen Wegs). EKN = Abkürzung für Ereignisknotennetz. Ereignis (event) = ein Geschehnis, ein Vorkommen oder eine Begebenheit, die nicht zeitverbrauchend sind; das Eintreten eines bestimmten Zustands. GERT = Abkürzung für Graphical Evaluation and Review Technique. Graph (graph) = eine endliche, nicht leere Menge V von P Ecken oder Knoten mit einer Menge X von q zweielementigen Teilmengen von V. Knoten (node) = ein Verknüpfungspunkt im (grafischen) Netzplan, kritischer Weg (critical path) = die Folge von Vorgängen in einem Netzplan ("kritische Vorgänge"), welche die minimale Projektdauer bestimmen. MPM = Abkürzung für Metra Potential Method (Metra-Potential-Methode). Nachfolger (successor) = ein Vorgang, der sich an den betrachteten Vorgang unmittelbar anschließt und der beendet sein muß, damit der betrachtete Vorgang beginnen kann. NPT = Abkürzung für Netzplantechnik. PERT = Abkürzung für Program Evaluation and Review Technique. Pfeil (arrow) = die gerichtete Verbindung zwischen zwei Knoten in einem (grafischen) Netzplan. Synonym: gerichtete Kante. Projekt (project) = ein zielgerichtetes, klar definiertes, zeitlich begrenztes, durch Größe, Bedeutung, Komplexität, Neuartigkeit, Einmaligkeit, Kosten und Risiko aus dem üblichen Geschehen herausragendes Vorhaben. Puffer (buffer) = die Zeit, die ein nicht-kritischer Vorgang ("Vorgangspuffer") oder ein nicht-kritisches Ereignis ("Ereignispuffer") zusätzlich in Anspruch nehmen kann, ohne dadurch kritisch zu werden. Sammelknoten (collecting node) = ein Knoten, in dem mehrere Pfeile enden. Scheinvorgang (fictitious activity) = ein fiktiver "Vorgang" im Vorgangspfeilnetz ohne Zeitbedarf zur Darstellung von parallelen Vorgängen. Streuknoten (sprinkler node) = ein Knoten, von dem mehrere Pfeile ausgehen. VKN = Abkürzung für Vorgangsknotennetz. Vorgang (activity) = ein Geschehnis, ein Vorkommen oder eine Begebenheit, die zeitverbrauchend sind, also eine Tätigkeit. Synonym: Aktivität. Vorgänger (predecessor) = ein Vorgang, der dem betrachteten Vorgang unmittelbar vorausgeht und der beendet sein muß, damit der betrachtete Vorgang beginnen kann. VPN = Abkürzung für Vorgangspfeilnetz.

206

Methoden und Techniken der Systemplanung

Zweck der Netzplantechnik Die Netzplantechnik stellt Methoden zur Beschreibung, Planung, Überwachung und Steuerung von Projekten zur Verfügung. Die erste Methode wurde 1957 in den USA bei Dupont de Nemours entwickelt; sie ist unter der Kurzbezeichnung CPM bekannt geworden. Beim Bau der Polaris-Rakete wurde 1958 PERT entwickelt. Zur gleichen Zeit wurde von einer Gruppe von Beratungsfirmen namens METRA für den Reaktorbau MPM entwickelt. Allen Methoden gemeinsam ist die Verwendung eines grafischen Modells des Projektablaufs, das Netzplan genannt wird. Die genannten Methoden werden daher unter der Bezeichnung "Netzplantechnik" zusammengefaßt. Mathematische Grundlage der Netzplantechnik ist die Graphentheorie, ihr Darstellungsmittel ist der Graph (vgl. Lerneinheit DARST). In Netzplänen werden entweder Vorgangsgraphen (auch: Tätigkeitsgraphen) oder Ereignisgraphen verwendet. Die Überlegenheit der Netzplantechnik gegenüber früher verwendeten Methoden (z.B. Gantt-Diagrammen) resultiert vor allem daraus, daß sie die Abhängigkeiten zwischen Vorgängen explizit berücksichtigt und daß auf Grund des graphentheoretischen Kalküls die Überprüfung von Netzplänen auf formal-logische Fehler möglich ist. Die jüngste Entwicklung einer Planungsmethode, die auch als Netzplantechnik bezeichnet wird, ist GERT; sie verwendet ein Entscheidungsnetz (vgl. weiter unten). Die Abwicklung von Projekten verbraucht Zeit, verursacht Kosten und erfordert den Einsatz von Betriebsmitteln. Die Netzplantechnik stellt daher Methoden für die Zeitplanung ("Terminplanung"), die Kostenplanung und die Betriebsmittelplanung ("Kapazitätsplanung") zur Verfügung. Kernstück der Netzplantechnik ist die Zeitplanung; auf ihren Ergebnissen bauen die beiden anderen Teilplanungen auf. Die Zeitplanung geht von den Ergebnissen der Strukturplanung aus. Projektvoraussetzungen Projekte, die mit Unterstützung der Netzplantechnik geplant, überwacht und gesteuert werden sollen, müssen folgende Voraussetzungen erfüllen: • Die Projektaufgabe muß klar definiert sein. • Die Projektaufgabe muß in Tätigkeiten ("Vorgänge"), die in ihrer Gesamtheit die Erfüllung der Projektaufgabe ermöglichen, zerlegt werden können. • Die Vorgänge müssen eindeutigen Bedingungen bezüglich ihrer Reihenfolge genügen ("Projektlogik"); ein Vorgang kann z.B. nur unter der Bedingung beginnen, daß ein anderer Vorgang beendet ist oder mehrere andere Vorgänge beendet sind. • Es muß zu jedem Zeitpunkt der Projektdurchführung möglich sein, Soll-IstVergleiche durchzuführen, um Anpassungen der Plandaten an die Wirklichkeit vornehmen zu können. Insbesondere wegen der zuletzt genannten Voraussetzung eignet sich die Netzplantechnik in der Systemplanung primär zur Unterstützung der Vorstudie (vgl. Lerneinheit PROPL), in der es unter anderem darum geht festzustellen, mit welchen Konsequenzen die Durchführung eines Projekts verbunden sein wird (also

NETZP - Netzplantechnik

207

die Projektplanung im Vordergrund steht). Die geringere Eignung zur Überwachung und Steuerung ist vor allem auf die aufwendige Erfassung von Änderungen zurückzuführen. Dies gilt trotz der Tatsache, daß Werkzeuge für die Netzplantechnik zur Verfügung stehen. Teilplanungen Bei der Anwendung der Netzplantechnik für die Projektplanung wird von der folgenden Gliederung in Teilplanungen, einschließlich Analysen, ausgegangen: • Strukturanalyse und Strukturplanung (auch: Ablaufanalyse bzw. Ablaufplanung); • Zeitanalyse und Zeitplanung (auch: Terminanalyse bzw. Terminplanung); • Kostenanalyse und Kostenplanung; • Kapazitätsanalyse und Kapazitätsplanung. 1. Strukturanalyse und Strukturplanung Die Projektaufgabe wird vollständig in Vorgänge zerlegt; das Ergebnis wird in einer Vorgangsliste dokumentiert. Dabei stellt sich bei jedem Projekt die Frage, wie fein die Projektaufgabe in Vorgänge zerlegt werden soll. Sie kann nur vor dem Hintergrund des Informationszwecks der Planung beantwortet werden, also aus der Beantwortung der Frage, wieviel Information dem Netzplan entnommen werden soll (z.B. reicht bei einer "Meilensteinplanung" zur Information der Geschäftsleitung über ein IuK-Projekt eine schwache Zerlegung aus, während der Projektleiter des gleichen Projekts zur Projektsteuerung eine feine Zerlegung braucht). Werden mehrere unterschiedliche Informationszwecke verfolgt, sollten auch mehrere, unterschiedlich detaillierte Netzpläne erstellt werden. Häufig wird die Strukturanalyse - dem Projektfortschritt folgend - verfeinert. Umgekehrt können, von einer detaillierten Strukturanalyse ausgehend, Vorgänge zusammengefaßt werden. Vorgang

Vorgangsbezeichnung

Vorgänger

Zeitbedarf (Tage)

A

Sachziele festlegen

—

4

B

Formalziele festlegen

A

2

C

Anforderungen definieren

A, B

4

D

Machbarkeitsstudie durchführen

C

4

Abb. NETZP-1: Struktur der Vorgangsliste

Nach Ermittlung der Vorgänge werden die Abhängigkeiten zwischen den Vorgängen bestimmt. Dazu sind für jeden Vorgang sämtliche Vorgänger und Nach-

208

Methoden und Techniken der

Systemplanung

folger festzustellen sowie die Vorgänge, die parallel ausgeführt werden können. Sind die Abhängigkeiten nicht eindeutig, wird nach Zweckmäßigkeitsgesichtspunkten (z.B. nach Kapazitätsüberlegungen) eine Reihenfolge festgelegt; alternative Reihenfolgen können bei späteren Anpassungen verwendet werden. Die Vorgangsliste wird um die Abhängigkeiten zwischen den Vorgängen ergänzt. Weitere Informationen zu den Vorgängen (wie z.B. Zeitbedarf, Kosten, Betriebsmittelbedarf, verantwortliche Person/Stelle) werden in die Vorgangsliste eingetragen. Abbildung NETZP-1 zeigt die Struktur der Vorgangsliste. 2. Zeitanalyse und Zeitplanung Bei der Zeitplanung oder Terminplanung geht es um die Beantwortung der folgenden Fragen: • Wie lange braucht das Projekt mindestens, wie lang ist also die minimale Projektdauer, bzw. kann ein vorgegebener Termin eingehalten werden? • Von welchen Vorgängen hängt die minimale Projektdauer ab und zu welchen Zeitpunkten müssen diese Vorgänge spätestens beginnen, damit die errechnete minimale bzw. die vorgegebene Projektdauer erreicht wird? Mit anderen Worten: Welches ist der kritische Weg durch den Netzplan? • Welche Vorgänge können zeitlich verschoben oder wie weit ausgedehnt werden, ohne daß die minimale Projektdauer beeinflußt wird? Mit anderen Worten: Wo liegen Pufferzeiten und wie groß sind sie? Zur Beantwortung dieser Fragen ist es erforderlich, die Vorgangsdauern, das heißt die Ausführungszeiten für die Vorgänge, zu ermitteln, mit anderen Worten: die Zeitanalyse oder Terminanalyse durchzuführen. Dies erfolgt, je nach Vorgang, durch Schätzen oder Messen (z.B. durch Anwendung von Aufwandsschätzverfahren, vgl. Lerneinheit MEAUF im Band "Informationsmanagement"). Je nach angewendetem Verfahren der Netzplantechnik wird bei Schätzungen entweder nur eine Vorgangsdauer (so bei CPM und MPM) oder es werden mehrere Vorgangsdauern (z.B. drei bei PERT) verwendet. Die Ergebnisse der Schätzung oder Messung der Vorgangsdauern werden in der Vorgangsliste erfaßt. In Abbildung NETZP-1 wird, für den Fall der Schätzung, eine Einwerte-Schätzung unterstellt. 3. Kostenanalyse und Kostenplanung Nach Durchführung der Zeitplanung liegt ein wesentliches Ergebnis der Projektplanung vor. Für eine aussagefähige Projektplanung unter betriebswirtschaftlichen Zielen fehlen jedoch Informationen über die Kosten, insbesondere darüber, wie sich die Veränderung (Verlängerung oder Verkürzung) der Vorgangsdauer auf die Kosten auswirkt. Eine typische Fragestellung in einem IuK-Projekt ist folgende: "Wie kann ein vorgegebener Installationstermin, der kürzer als der durch die Zeitplanung ermittelte Fertigstellungstermin ist, durch Verkürzung der Dauer bestimmter Vorgänge eingehalten werden, und welche Auswirkungen haben alternative Verkürzungen auf Kosten und Betriebsmittel?" Dabei ist es meist von Interesse, sowohl die unterschiedliche Verkürzung gleicher Vorgänge als auch die Verkürzung verschiedener Vorgänge zu untersuchen. Diese Frage

NETZP - Netzplantechnik

209

und ähnliche Fragen können mit Weiterentwicklungen der klassischen Verfahren der Netzplantechnik beantwortet werden; darauf wird hier nicht eingegangen. 4. Kapazitätsanalyse und Kapazitätsplanung Zweck der Kapazitätsplanung ist es, den Bedarf an Betriebsmitteln mit den verfügbaren Betriebsmitteln ins Gleichgewicht zu bringen. Einerseits sollen Leerkosten vermieden werden, andererseits sind Kapazitätsüberschreitungen nicht zulässig. Bei der Kapazitätsplanung wird daher wie folgt vorgegangen: • Für jeden Vorgang wird der Kapazitätsbedarf nach Art und Menge geschätzt (z.B. Anzahl Mitarbeiter-Arbeitstage); aus dem Zeitplan läßt sich dann ein Kapazitätsbedarfsplan ("Einsatzplan") ableiten. Der Einsatzplan gibt an, welche Betriebsmittel zu welchen Zeitpunkten in welchen Mengen bereitgestellt werden müssen. Wenn für bestimmte Vorgänge verschiedene Betriebsmittel zu unterschiedlichen Zeitpunkten in unterschiedlichen Mengen gebraucht werden, ist es notwendig, diese Vorgänge kapazitätsorientiert zu zerlegen. • Der Kapazitätsbedarf wird der verfügbaren Kapazität gegenübergestellt und im Fall von Abweichungen wird versucht, einen Kapazitätsausgleich herzustellen (z.B. durch Verschiebung, Unterbrechung oder zeitliche Ausdehnung bzw. Komprimierung von Vorgängen). Wenn Anpassungen der Strukturplanung und/oder der Zeitplanung auf Grund der Kapazitätsplanung erforderlich sind und diese den Rahmen der Pufferzeiten überschreiten, kann eine Verlängerung der Projektdauer eintreten. Dies bereits im Planungsstadium zu erkennen, ist das wesentliche Ziel der Kapazitätsplanung. Methodisch erfolgt der Kapazitätsausgleich mit Verfahren der ganzzahligen Optimierung (theoretisch zweckmäßig) und mit heuristischen Verfahren, insbesondere mit systematischen Probierverfahren (in der Praxis verwendet).

Darstellungsform

Vorgangspfeilnetz

Vorgänge als Pfeile

Ereignisse als Knoten

Vorgänge als Knoten

X

Ereignisknotennetz Vorgangsknotennetz

verwendet bei

CPM X

PERT X

MPM

Abb. NETZP-2: Darstellungsformen von Netzplänen

Darstellungsformen von Netzplänen Das grundlegende Darstellungsmittel für alle Netzpläne ist der endliche, gerichtete G r a p h . Je nachdem, ob die Vorgänge durch Pfeile ODER durch Knoten dargestellt werden, wird zwischen dem pfeilorientierten Netzplan und dem knotenorientierten Netzplan unterschieden. Liegt das primäre Planungsinteresse bei der Betrachtung der Vorgänge UND werden die Vorgänge durch Pfeile dar-

210

Methoden und Techniken der Systemplanung

gestellt, hat man ein Vorgangspfeilnetz (bei CPM verwendet). Liegt das primäre Planungsinteresse bei der Betrachtung der Ereignisse UND werden die Ereignisse durch Knoten dargestellt, hat man ein Ereignisknotennetz (bei PERT verwendet). Liegt das primäre Planungsinteresse bei der Betrachtung der Vorgänge UND werden die Vorgänge durch Knoten dargestellt, hat man ein Vorgangsknotennetz (bei MPM verwendet). Abbildung NETZP-2 zeigt die drei Darstellungsformen der Netzpläne im Überblick; sie werden im folgenden näher erläutert.

a) Grundbeziehung

c) Streuereignis

b) mit Scheinvorgang

d) Sammelereignis

Abb. NETZP-3: Anordnungsbeziehungen im Vorgangspfeilnetz

Vorgangspfeilnetz: Zu jedem Vorgang (als Pfeil dargestellt) gehören ein Anfangsereignis und ein Endereignis (meist als Kreis dargestellt); die Ereignisse heißen auch Zeitpunkte. Diese Anordnungsbeziehung setzt voraus, daß jeder Vorgang abgeschlossen sein muß, ehe ein nachfolgender Vorgang beginnen kann. Abgesehen vom Startereignis und vom Zielereignis stellt jeder Knoten zugleich ein Anfangsereignis und ein Endereignis für verschiedene Vorgänge dar. Ein Ereignis kann mehrwertig sein, wenn es für mehrere Vorgänge Anfangsereignis ("Streuereignis") oder Endereignis ("Sammelereignis") ist; ein mehrwertiger Knoten heißt dementsprechend entweder "Streuknoten" oder "Sammelknoten". Da zwei Ereignisse nur durch einen Vorgang miteinander verbunden sein dürfen, werden Scheinvorgänge eingeführt, um die Parallelität von Vorgängen darstellen zu können. Die Verwendung von Scheinvorgängen ist auch dann erforderlich, wenn zwei oder mehrere Vorgänge mit verschiedenen Anfangs- und Endereignissen zusammenhängen. Ein Scheinvorgang wird als gestrichelter Pfeil dargestellt. CPM verwendet das Vorgangspfeilnetz. Mit Abbildung NETZP-3 werden typische Anordnungsbeziehungen (d.h. Beziehungen zwischen Ereignissen

NETZP - Netzplantechnik

211

und/oder Vorgängen) im Vorgangspfeilnetz gezeigt. Durch Anordnungsbeziehungen wird insbesondere die Reihenfolge zwischen zwei oder mehr Vorgängen angegeben. E r e i g n i s k n o t e n n e t z : So wie beim Vorgangspfeilnetz werden Vorgänge als Pfeile und Ereignisse als Knoten dargestellt. Im Unterschied zum Vorgangspfeilnetz gilt jedoch das Interesse primär den Ereignissen, weil für das Auftreten von Ereignissen Wahrscheinlichkeiten ermittelt werden. Die Anordnungsbeziehungen sind bei beiden Netzen identisch; im Sinn der Ereignisorientierung werden sie lediglich anders ausgedrückt. Abbildung NETZP-4 zeigt die beiden grundsätzlichen Arten der Beschreibung von Ereignisknoten. Das Ereignisknotennetz wird bei PERT verwendet. PERT erlaubt dreiwertige Schätzungen, weil ihm ein relativ kompliziertes mathematisches Modell zugrunde liegt. Die Datenausgabe enthält Größen wie Mittelwert, Streuung und Wahrscheinlichkeit; der wahrscheinlichkeitstheoretische Charakter der Ergebnisse muß bei ihrer Interpretation und praktischen Umsetzung beachtet werden. Wegen der identischen Anordnungsbeziehungen im Vorgangspfeilnetz und im Ereignisknotennetz können in gemischt-orientierten Netzplänen sowohl Vorgänge als Pfeile als auch Ereignisse als Knoten dargestellt werden. CPM und PERT erlauben die Berechnung gemischt-orientierter Netzpläne. Vorgang A abgeschlossen

ODER

Vorgang B begonnen

Abb. NETZP-4: Beschreibung von Ereignisknoten

Vorgangsknotennetz: Die Vorgänge werden durch Knoten (meist als Rechtecke mit gerundeten Ecken) dargestellt; Ereignisse werden nicht dargestellt. Im Unterschied zum Vorgangspfeilnetz und zum Ereignisknotennetz kann im Vorgangsknotennetz ein Vorgang bereits beginnen, wenn seine Vorgänger noch nicht vollständig beendet sind; es genügt ein gewisser "Fertigstellungsgrad" der Vorgänger. Die Pfeile geben die Abhängigkeitsbeziehungen der Vorgänge ("Reihenfolgebedingungen") an. Dabei handelt es sich um eine "Anfang-Anfang-Beziehung", das heißt zwei aufeinanderfolgende Vorgänge werden nach der StartStart-Kopplung verknüpft. Ein Vorgang muß also nur begonnen haben, bevor der nächste beginnen kann. Aus einem Strukturplan für ein Vorgangsknotennetz kann der Abschluß von Vorgängen nicht entnommen werden; diese Information liefert erst die Zeitplanung. Die Anordnungsbeziehungen stimmen im wesentlichen mit denen des Vorgangspfeilnetzes überein; Abweichungen ergeben sich aus den speziellen Darstellungsmöglichkeiten des Vorgangsknotennetzes. So wird allen Vorgängen, die innerhalb des Projekts nicht vom Beginn weiterer Vorgänge abhängig sind, ein Scheinvorgang "Start" vorangestellt, und den Vorgängen, die keinen weiteren Nachfolger haben, wird ein Scheinvorgang "Ende" nachgeordnet. "Scheinvorgang" in diesem Sinn ist nicht identisch mit "Scheinvorgang" im Sinn des Vorgangspfeilnetzes. Das Vorgangsknotennetz wird von MPM verwendet. Das Vorgangsknotennetz ist aus verschiedenen Gründen den beiden anderen Darstellungsformen überlegen, unter anderem aus den folgenden:

212

Methoden und Techniken der Systemplanung

• In den Knoten können alle wichtigen, den Vorgang betreffenden Informationen aufgenommen werden, ohne daß der Netzplan unübersichtlich wird. • Scheinvorgänge - abgesehen von "Start" und "Ende" - sind nicht erforderlich; die Übersichtlichkeit wird durch Scheinvorgänge nicht beeinträchtigt. • Strukturänderungen lassen sich einfach durchführen, da Pfeile entfernt und ergänzt werden können, ohne daß der Netzplan neu berechnet werden muß. Als entscheidender Vorteil des Vorgangspfeilnetzes gilt, daß durch Pfeile eine anschauliche Abbildung der Zeitdimension möglich ist. Weiterführende Varianten der Netzplantechnik Auf die weiterführenden Varianten der Netzplantechnik, die über die Zeitplanung hinausgehen und Kosten sowie Kapazitätsüberlegungen einbeziehen, wurde weiter oben schon hingewiesen. Ein grundsätzliches Problem der Strukturplanung, das diese weiterführenden Varianten nicht lösen, besteht in folgendem: Häufig ist der genaue Projektverlauf zum Zeitpunkt der Projektplanung nicht bekannt, insbesondere ist nicht bekannt, welche Vorgänge tatsächlich realisiert werden. Beispielsweise kann ein Vorgang von geplanten Projektergebnissen, die möglicherweise nicht erreicht werden, abhängig sein. Vorgänge dieser Art werden daher nur mit einer gewissen Wahrscheinlichkeit verwirklicht. Für die Behandlung solcher stochastischen Strukturen wurde eine Variante der Netzplantechnik entwickelt, die Entscheidungsnetzpläne verwendet. Entscheidungsnetzpläne können stochastische Entscheidungsknoten haben, deren Ausgänge mit bestimmten Wahrscheinlichkeiten belegt werden. Folgen in einem Netzplan solche Entscheidungsknoten aufeinander, dann hat man es mit einem Entscheidungsbaum zu tun. Mit einer anderen Weiterentwicklung wird versucht, die Mehrprojektplanung zu unterstützen. Mehrprojektplanung ist die netzplantechnische Koordinierung mehrerer mit Netzplantechnik bearbeiteter Projekte, die um gemeinsam benötigte Betriebsmittel konkurrieren. Die hierfür entwickelten mathematischen Verfahren haben bislang keine praktische Bedeutung erlangt. Bei einer mathematisch nicht unterstützten, heuristischen Vorgehensweise erfolgt die Koordinierung der zunächst getrennt geplanten, mit Prioritäten versehenen Projekte im Kapazitätsbelastungsplan. Nach Einplanung in den Kapazitätsbelastungsplan wird die Zeitplanung für die Projekte wiederholt, bei denen auf Grund der Belastungsplanung Vorgänge verändert wurden. Werkzeuge der Netzplantechnik Zur Unterstützung der Anwendung der Netzplantechnik gibt es eine Reihe von Werkzeugen, deren Funktionsumfang und Leistungsfähigkeit mit den folgenden Merkmalen beurteilt werden sollte: • Einprojektplanung oder Mehrprojektplanung und Anzahl der Projekte bei Mehrprojektplanung; • Planungsumfang (Zeitplanung/Kostenplanung/Kapazitätsplanung); • maximale Anzahl der Vorgänge je Projekt; • maximale Anzahl der Kapazitätsarten und Kalenderzeitraum (Anzahl Jahre);

NETZ? - Netzplantechnik

213

• Art und Anzahl unterschiedlicher Zeiteinheiten (z.B. Stunden, Tage, Wochen, Monate); • Numerierungsverfahren (lückenlos aufsteigend/wahllos und numerisch/alphanumerisch); • formal-logische Prüfverfahren (z.B. zur Aufdeckung von Schleifen); • Umfang und Lesbarkeit der Beschriftung; • Aufwand für den Änderungsdienst; • Hardware-Plattform und Betriebssystem; • Programmlaufzeiten. Demonstrationsbeispiel Es werden die Art der Notation (das Beschreibungsschema) für ein Vorgangspfeilnetz und ein entsprechend beschriebener Netzplan gezeigt. Abbildung NETZP-5 zeigt das Beschreibungsschema; die verwendeten Abkürzungen haben folgende Bedeutung: A 1 2 3 4 5

= = = = = =

Nummer oder Bezeichnung des Vorgangs laut Vorgangsliste, Vorgangsdauer in Zeiteinheiten (Tage, Wochen, Monate), voraussichtlicher Kapazitätsbedarf in Einheiten des benötigten Betriebsmittels, Ereignisnummer, frühester Anfangstermin des Vorgangs in Zeiteinheiten ab Projektstart, spätester Anfangstermin des Vorgangs in Zeiteinheiten ab Projektstart.

Abbildung NETZP-6 zeigt einen Netzplan mit elf Vorgängen (A bis L); alle wichtigen Anordnungsbeziehungen sind daraus erkennbar. Der frühest mögliche Endtermin von Vorgang L und damit des gesamten Projekts (Ereignis 12)

214

Methoden

und Techniken

der

Systemplanung

ist in Zeiteinheit 19, der späteste Endtermin ist in Zeiteinheit 24. Der Netzplan enthält vier Scheinvorgänge; sie sind gestrichelt (zwischen Ereignis 5 und Ereignis 6, zwischen Ereignis 7 und Ereignis 8, zwischen Ereignis 9 und Ereignis 10 sowie zwischen Ereignis 11 und Ereignis 12). Mehrwertige Ereignisse sind bei Projektbeginn zu erkennen (die Knoten 2, 3 und 4 haben den gleichen Vorgänger, nämlich Knoten 1), im Projektverlauf und bei Projektende (der Knoten 12 hat mit den Knoten 10 und 11 zwei Vorgänger). Der "kritische Weg", der lückenlos v o m Startereignis bis zum Zielereignis verläuft, ist durch eine dicke Linie hervorgehoben; er identifiziert alle kritischen Vorgänge, d.h. die Vorgänge, deren Puffer Null ist. Kontrollfragen 1. Welche Projektmanagementaufgabe kann mit Netzplantechnik am besten unterstützt werden? 2 . Welches Darstellungsmittel verwendet die Netzplantechnik; durch welche Merkmale ist es gekennzeichnet? 3. In welche Teilplanungen und Analysen wird eine Planungsaufgabe, die mit der Netzplantechnik unterstützt wird, zerlegt? 4 . Welche drei Formen von Netzplänen werden verwendet; welche Verfahren der Netzplantechnik setzen welche Form ein? 5. Welche weiterführenden Varianten der Netzplantechnik gibt es? Quellenliteratur Runzheimer, B.: Operations Research I. Lineare Planungsrechnung und Netzplantechnik. 5. A., Verlag Gabler, Wiesbaden 1990, 1 5 9 - 2 1 9 Schwarze, J.: Netzplantechnik. 6. A., Verlag Neue Wirtschaftsbriefe, Herne/Berlin 1990 Vertiefungsliteratur Haag, W . : Dokumentation von Anwendungssystemen aus der Sicht der Benutzer. Toeche-MittlerVerlag, Darmstadt 1981 Meyer, M. und Hansen, K.: Planungsverfahren des Operations Research. Verlag Vahlen, M ü n chen 1985, 7 9 - 1 4 6 Z i m m e r m a n n , W.: Operations Research. Quantitative Methoden zur Entscheidungsvorbereitung. 5. A., Oldenbourg Verlag, München/Wien 1990, 6 - 47 Normen DIN 69900: Netzplantechnik

TESTM - Testmethoden Lernziele Sie kennen den Zweck des Testens und der Testmethoden sowie eine Systematik der Fehler, die durch Testen aufgedeckt werden sollen. Sie können die Testarten nennen, die nach verschiedenen Gesichtspunkten gebildet werden. Sie können Testarten zu Testmethoden verbinden. Sie kennen die Teilaufgaben des Testens und ihr Zusammenwirken in einer Testmethodik. Sie erkennen den Zusammenhang zwischen Testen und Qualitätssicherung. Definitionen und Abkürzungen Abnahmetest (acceptance test) = ein Test, den Auftraggeber und Auftragnehmer vereinbaren, um zu überprüfen, ob das übergebene Produkt die geforderten Eigenschaften erfüllt. Entwicklungstest (development test) = ein Test, bei dem die Entwurfs- und Entwicklungsergebnisse unter der Verantwortung der Entwerfer/Entwickler überprüft werden. Synonym: Entwurfstest. Fehler (failure) = die negative Abweichung einer Größe von einem geplanten (z.B. theoretisch exakten) Wert. Funktionstest (function test) = ein Test, der nachweisen soll, daß das Produkt bezüglich der Funktionen die geforderten Eigenschaften erfüllt. Leistungstest (Performance test) = ein Test, der nachweisen soll, daß das Produkt bezüglich der Leistungen die geforderten Eigenschaften erfüllt. Test (test) = die nach einer vorab festgelegten, kontrollierbaren Methode durchgeführte experimentelle Untersuchung eines Objekts zur Feststellung bestimmter Eigenschaften. Testabdeckungsgrad (degree of test Performance) = eine Maßzahl für die Zuverlässigkeit eines Tests (z.B. das Verhältnis der Anzahl der ausgeführten Komponenten zur Anzahl der vorhandenen Komponenten). Testaufwand (test effort) = der zum Testen erforderliche Zeitbedarf, gemessen vom Beginn der Testplanung bis zum Ende der Testdokumentation. Testdaten (test data) = die zum Testen eines Testobjekts verwendeten Daten. Testobjekt (testling) = die Art des Produkts, das mit einer bestimmten Testmethode auf einem bestimmten Testsystem getestet wird. Synonym: Testling. Testtreiber (test driver) = eine Funktionseinheit, die den Ablauf der Testfälle am Testobjekt steuert und das Testobjekt mit Testdaten versorgt. Testsystem (test system) = eine Konfiguration aus Testobjekt, Testfällen mit Testdaten sowie organisatorischen, gerätetechnischen und softwaretechnischen Hilfsmitteln, deren Funktionsweise so spezifiziert ist, daß alle im Testobjekt vermuteten Fehler ("Fehlervorgabe") erkannt werden. Testwerkzeug (test tool) = ein Hilfsmittel zur Unterstützung des Testens (z.B. ein Programm), das Informationen für die Analyse und die Behebung von Fehlern bereitstellt. Ursachen-AVirkungsanalyse (cause/effectiviness analysis) = eine Analyse, deren Zweck darin besteht, ein Problem in einer kausalen Ursache/WirkungKette zu beschreiben und dadurch zu verstehen.

216

Methoden und Techniken der Systemplanung

Zweck der Testmethoden Testen in der Systemplanung ist der Vorgang des Überprüfens der Eigenschaften ihrer Produkte (Zwischenprodukte und Endprodukte) daraufhin, ob sie dem "Stand der Technik" sowie den definierten Sachzielen (vgl. Lerneinheit SACHZ) und Formalzielen (vgl. Lerneinheit FORMZ) entsprechen. Jede Abweichung einer Eigenschaft eines Produkts vom "Stand der Technik" und/oder von den definierten Funktionsanforderungen, Leistungsanforderungen und/oder Schnittstellenanforderungen sowie von der geforderten Produktqualität ist ein Fehler. Ziel des Testens ist es, möglichst viele Fehler im Testobjekt aufzudecken bzw. nachzuweisen, daß im Testobjekt angenommene Fehler nicht vorhanden sind. Das heißt, daß zum Testen Fehlervorgaben erforderlich sind, die aus Standards sowie aus den Planungszielen und den Projektzielen abgeleitet werden müssen, und daß durch Testen nicht alle in einem Testobjekt vorhandenen Fehler aufgedeckt werden können. In enger Beziehung zum Testen steht das Debugging ("Entwanzen"), dessen Zweck das Erkennen und Beheben von Fehlerursachen und das Beseitigen von Fehlern einschließlich der Überprüfung der Fehlerkorrektur ist. Diese Überprüfung erfordert die Wiederholung des Testens, um feststellen zu können, ob der Fehler tatsächlich korrigiert wurde und ob durch die Korrektur keine neuen Fehler "eingeführt" wurden ("Retesting"). Die Erfahrung zeigt, daß der Aufwand für das Finden eines Fehlers erheblich größer ist als der Aufwand für das Beseitigen desselben Fehlers (in etwa gilt die "80:20-Regel"). Auf den Projektaufwand bezogen kann der Testaufwand bis zu 50% betragen, was insbesondere von den definierten Qualitätsforderungen beeinflußt wird. Es ist daher zweckmäßig, vor der Testplanung verbindliche Testgrundsätze festzulegen (vgl. den Abschnitt "Testgrundsätze"). Zweck der Testmethoden ist es, das Testen so zu unterstützen, daß es möglichst wirksam und wirtschaftlich durchgeführt werden kann. Beim Testen und bei der Anwendung von Testmethoden gilt folgender Erfahrungsgrundsatz: Je früher im Prozeß der Systemplanung getestet wird, desto wirksamer und wirtschaftlicher können Fehler nachgewiesen und beseitigt werden. Testen muß daher bereits in der Vorstudie einsetzen; es endet erst dann, wenn das Ergebnis der Systemplanung produktiv verwendet wird. Testen ist also eine projektbegleitende Aufgabe; es ist keine Phase im Phasenmodell. Weiterführende Tests (z.B. Betriebstest und Wartungstest) sind Aufgabe des Anwendungssystem-Managements (vgl. Lerneinheit ANWEN im Band "Informationsmanagement"). Qualitätssicherung und Testen Aus dem bisher Gesagten ist die Bedeutung, welche das Testen für die Sicherung der Qualität der Produkte der Systemplanung im Rahmen von Validierung und Verifizierung hat, deutlich erkennbar. Die Bedeutung von Qualitätssicherung und Testen ist umso größer, je kritischer die Folgen von Qualitätsmängeln einzuschätzen sind. Folgende drei Risikoklassen für IuK-Projekte können z.B. verwendet werden:

TESTM - Testmethoden

217

• Risikoklasse A: Es besteht ein Risiko für Menschenleben sowie ein hohes Risiko für Sachwerte und daraus folgend für hohe wirtschaftliche Schäden. Empfohlen werden umfassende Verifizierung und Validierung durch mindestens zwei unabhängige Teams einschließlich aller sinnvollen Tests. • Risikoklasse B: Es besteht ein hohes Risiko für Sachwerte und daraus folgend für hohe wirtschaftliche Schäden. Empfohlen werden umfassende Verifizierung und Validierung durch ein Team einschließlich aller sinnvollen Tests. • Risikoklasse C: Es besteht kein hohes Risiko für Sachwerte. Empfohlen werden Prüfungen durch Tests. Der TÜV Rheinland empfiehlt die Verwendung von fünf Risikoklassen A bis E, wobei A als Klasse mit dem höchsten Risiko (Personenschäden) und E als Klasse ohne Risiko definiert ist. Zur Einordnung von Testobjekten in Risikoklassen muß eine Risikoanalyse durchgeführt werden (vgl. Lerneinheit RISKO im Band Informationsmanagement). Verifizierung meint dabei Prüfung der Übereinstimmung zwischen Spezifikation und Produkt, das heißt die Beantwortung der Frage: Wird das Produkt richtig hergestellt? Validierung meint dabei Prüfung der Verwendungsfähigkeit des Produkts, das heißt die Beantwortung der Frage: Wird das richtige Produkt hergestellt? Aus der Einschätzung der Risikoklasse ergibt sich auch die Größenordnung des Aufwands für die Qualitätssicherung und damit für das Testen. Fehlerarten Für die Erarbeitung einer Fehlervorgabe ist es zweckmäßig, von einer Fehlersystematik auszugehen, in der zu berücksichtigen sind: • der Fehlerort, das heißt in welcher Systemkomponente der Fehler auftritt; • die Fehlerart, das heißt ob es sich um einen Funktions-, Leistungs- oder Schnittstellenfehler handelt; • die Fehlerphase, das heißt ob es sich um einen Entwurfs-, Entwicklungs- oder Implementierungsfehler handelt; • die Fehlerquelle, das heißt ob es sich um einen produktimmanenten Fehler handelt oder ob der Fehler durch ein externes Ereignis ausgelöst wird; • die Fehlerdauer, das heißt ob es sich um einen permanenten Fehler handelt, der bis zu seiner Beseitigung ununterbrochen fortbesteht, oder um einen intermittierenden Fehler, der sporadisch auftritt; • die Fehlerhäufigkeit, das heißt die Anzahl der Fehler bezogen auf eine geeignete Bezugsgröße (z.B. Zeitabschnitt); • die Fehlerinterdependenz, das heißt ob es sich um einen isolierten Fehler handelt oder um einen Fehler, der durch andere Fehler ausgelöst wird bzw. der andere Fehler auslöst. Diese Struktur der Fehlerarten ist nur eine Grobgliederung; sie muß projektabhängig verfeinert werden.

218

Methoden

und Techniken der

Systemplanung

Testgrundsätze Grundsätze, von denen bereits bei der Testplanung ausgegangen werden sollte, sind insbesondere: • Dem Testen sollen immer definierte Testziele zugrundeliegen. • Die Testziele sollten so definiert sein, daß die Zielerträge immer meßbar und auch erreichbar sind. • Jeder Test muß durch ein zweckmäßiges "Endekriterium" begrenzt sein. • Die erwarteten Testergebnisse müssen von vornherein spezifiziert sein. • Die tatsächlichen Testergebnisse müssen in jedem Fall überprüft werden. • Testfälle müssen auch den Bereich der unerwarteten und ungültigen Daten abdecken (z.B. durch Grenzwertbildung). • Testen muß reproduzierbar sein. • Bei der Testplanung sollte immer von der Annahme ausgegangen werden, daß beim Testen Schwierigkeiten auftreten können. Der Testplan wird vom Projektleiter in Zusammenarbeit mit Vertretern des Auftraggebers festgelegt. Wenn möglich, sollte ein Testberater zugezogen werden, dessen primäre Aufgabe es ist, zwischen Auftraggeber und Auftragnehmer zu vermitteln mit dem Ziel, daß die Testergebnisse von allen Beteiligten getragen werden. Teilaufgaben des Testens Systematisches Testen mit Testmethoden umfaßt die Teilaufgaben Testplanung, Testdurchführung, Testkontrolle und Testdokumentation. • Die Testplanung umfaßt die Auswahl der Testobjekte, das Festlegen der Testziele (insbes. die Fehlervorgabe) und daraus abgeleiteter Testkriterien (z.B. Testabdeckungsgrad), das Festlegen der Testaktivitäten sowie die Auswahl und Verfügbarmachung aller für die Testdurchführung erforderlichen Personen und Hilfsmittel. Die Testplanung ist strategische Planung und operative Planung. Die strategische Testplanung befaßt sich mit der grundsätzlichen Vorgehensweise beim Testen; zu ihren Aufgaben gehört z.B. die Bestimmung der Testmethoden. Die operative Testplanung befaßt sich mit der Vorgehensweise beim Testen im Detail (z.B. die Abfolge der einzelnen Testaktivitäten). Ergebnis der Testplanung ist ein Testplan, mit dem die nachfolgenden Testaufgaben überwacht und gesteuert werden. • Die Testdurchführung umfaßt die Abwicklung der Testaktivitäten zur Erreichung der in der Testplanung formulierten Testziele. Sie gliedert sich in Testvorbereitung, Testausführung und Testauswertung. Zur Testvorbereitung gehört die Testfallermittlung. Die Testausführung erfolgt in der Regel in mehreren Testläufen. Bei der Testauswertung wird für jeden Testlauf festgestellt, ob die in den Testfällen beschriebenen Ausgabedaten mit den Ausgabedaten der Testfälle bei den Testläufen übereinstimmen und ob alle in den Testfällen beschriebenen Funktionen ausgeführt und Leistungen erreicht werden. Ergebnis der Testausführung ist das Testprotokoll (für jeden Testlauf), Ergebnis der Testauswertung der Testbericht.

TESTM - Testmethoden

219

• Die Testkontrolle dient der Überprüfung der Testdurchführung anhand der Testziele und aufgrund der Ergebnisse der Testauswertung. Werden Fehler festgestellt, wird versucht, sie zu lokalisieren und ihre Ursachen zu bestimmen; dabei ist ein modularer Aufbau des Testobjekts hilfreich. Die Ergebnisse der Testkontrolle werden dazu verwendet, Maßnahmen zur Fehlerkorrektur festzulegen. Dabei ist die Erfahrung zu berücksichtigen, daß die Korrektur eines Fehlers häufig zum Entstehen eines anderen Fehlers (oder mehrerer anderer Fehler) führt. Nach jeder Fehlerkorrektur müssen daher alle Testfälle wiederholt werden. • Die Testdokumentation beschreibt den Prozeß des Testens (Testplanung, Testdurchführung und Testkontrolle), insbesondere die verwendeten Testmethoden, Testfälle mit Testdaten und Testergebnisse. Die Testdokumentation dient nicht nur als Nachweis über das Testen, sondern auch als Kommunikationsmittel für die am Test beteiligten Personen. Sie erleichtert die Wiederholung von Tests während des Projekts und in der Nutzungsphase des Informationssystems ("Betriebstest", "Wartungstest"). Darüber hinaus liefert die Testdokumentation Informationen für zukünftige Projekte, insbesondere zur Fehlervermeidung. Testobjekte Eine allgemeine Struktur der Testobjekte kann, entsprechend dem Planungsprozeß, wie folgt angegeben werden (in Klammern die Bezeichnung der entsprechenden Tests): Anforderungen ("Anforderungstest"), Komponenten ("Komponententest") und Gesamtsystem ("Integrationstest"). Wegen der besonderen Bedeutung der Schnittstellen der Komponenten im Gesamtsystem und der Schnittstellen zwischen diesem und der Systemumwelt wird der Integrationstest auch als "Schnittstellentest" oder "Systemtest" bezeichnet. Manchmal wird zwischen Integrationstest einerseits und Systemtest andererseits unterschieden. Während beim Komponententest der Test der Funktionen im Mittelpunkt steht (deshalb auch "Funktionstest" genannt), konzentriert sich das Interesse beim Integrationstest (insbesondere beim Testen des Gesamtsystems) auf die Produktqualität, z.B. auf die Untersuchung von Zuverlässigkeit und Leistung ("Belastungstest", "Leistungstest"). Testziele dieser Art stehen auch beim Abnahmetest im Vordergrund des Interesses (vgl. Lerneinheit DURIN). • Anforderungstest: Die Anforderungsbeschreibung ("Spezifikation") ist Grundlage der Planung des Informationssystems und damit auch der Testplanung. Bevor mit dem Testen von Systemkomponenten begonnen wird, müssen die Verständlichkeit und die Vollständigkeit der Anforderungsbeschreibung überprüft werden. Zur Durchführung des Anforderungstests wird die Ursachen-/Wirkungsanalyse verwendet. Ursachen sind Eingabedaten oder Funktionen, die vorgegeben sind oder auftreten können; Wirkungen sind Funktionen oder Ausgabedaten. Der Anforderungstest soll zeigen, ob Ursachen (also Eingabedaten oder Funktionen) definiert wurden, für die keine Wirkungen (also Funktionen bzw. Ausgabedaten) vorhanden sind bzw. ob Wirkungen (also Funktionen oder Ausgabedaten) vorhanden sind, für die keine Ursachen definiert wurden. Die Schwierigkeit besteht darin, daß sich eindeutige Zuordnungen von Ursachen und Wirkungen nicht in jedem Fall finden lassen.

220

Methoden

und Techniken der

Systemplanung

• Komponententest: Beim Komponententest wird versucht, Abweichungen zwischen der Anforderungsbeschreibung und ihrer Realisierung bezüglich jeder einzelnen Komponente des Testobjekts zu erkennen. Da eine Komponente meist nicht allein ablauffähig ist, muß eine geeignete Testumgebung (ein "Testrahmen") geschaffen werden. Die Testumgebung ermöglicht es, jede Komponente einzeln aufzurufen, die Ergebnisse der Verarbeitung zu untersuchen und die Wirkung nicht vorhandener, aber benötigter Komponenten zu simulieren ("Simulation", vgl. Lerneinheit SIMUL). Abbildung TESTM-1 veranschaulicht die Einbettung des Testobjekts in eine Testumgebung. • Integrationstest: Beim Integrationstest werden mehrere Komponenten zu einem Teilsystem und dann mehrere Teilsysteme zu einem System zusammengefaßt, bis man schließlich zum Gesamtsystem gelangt. Getestet werden die Schnittstellen zwischen den Komponenten, zwischen den Teilsystemen usw. Die Vorgehensweise unterscheidet sich kaum von der Vorgehensweise beim Komponententest.

A b b . T E S T M - 1 : Testobjekt und Testumgebung (Quelle: nach Pomberger)

Teststrategien Beim Integrationstest kann nach verschiedenen Teststrategien vorgegangen werden, die sich zwei Gruppen zuordnen lassen: vorgehensorientierte Strategien und zielorientierte Strategien. Vorgehensorientierte Strategien sind Top-down-Strategie, Bottom-up-Strategie und Hardest-first-Strategie. Zielorientierte Strategien sind funktionsorientiert oder transaktionsorientiert. Es handelt sich - außer bei der transaktionsorientierten Strategie - um inkrementelle Strategien. Das bedeutet, daß je Testlauf immer nur eine Komponente hinzugefügt wird. Bei der nicht inkrementellen Strategie wird zunächst jede Komponente getestet, unabhängig von anderen Komponenten, und dann werden alle Komponenten gemeinsam getestet. Vorteile der inkrementellen Strategie gegenüber der nicht inkrementellen Strategie sind der geringere Testaufwand und die wirksamere Überprüfung der Schnittstellen; entscheidender Nachteil ist, daß ein paralleles Testen von Komponenten nicht möglich ist. Beim Top-down-Test wird mit der Komponente des hierarchisch gegliederten Testobjekts begonnen, die auf der obersten Ebene steht. Beim inkrementellen

TESTM - Testmethoden

221

Vorteile

Einbeziehen der Komponenten auf darunter liegenden Ebenen müssen die Komponenten, die von den zu testenden Komponenten aufgerufen werden, simuliert oder durch Platzhalter ersetzt werden. Die simulierten oder ersetzten Komponenten werden Komponente für Kompenente durch echte Komponenten ersetzt, bis man auf der untersten Ebene des Testobjekts angelangt ist. Beim Bottomup-Test wird mit den Komponenten des hierarchisch gegliederten Testobjekts begonnen, die sich auf der untersten Ebene befinden und keine weiteren Komponenten aufrufen. Die übergeordneten Komponenten, die zunächst nicht in das Testen einbezogen werden, müssen durch Testtreiber ersetzt werden. Abbildung TESTM-2 zeigt am Beispiel des Programmtests Vorteile und Nachteile der beiden Teststrategien. Top-down-Test

Bottom-up-Test

Die "oberen" Strukturblockebenen des Verfahrens werden häufiger getestet; sind dort schwerwiegende Fehler zu erwarten, ist es vorteilhaft, den Test so zu beginnen.

Die "unteren" Strukturblockebenen des Verfahrens werden häufiger getestet; sind dort schwerwiegende Fehler zu erwarten, ist es vorteilhaft, den Test so zu beginnen.

Werden Ein-/Ausgabefunktionen durch den Test in das Verfahren einmal eingebettet, ist die Erstellung der Testfälle einfach.

Die Bedingungen, unter denen der Test stattfinden soll, sind einfacher zu erfüllen (z.B. Testsystem bereitstellen).

Nachteile

Die Überwachung der Testergebnisse Bereitsfrühzeitigexistieren vollständige ist einfach. "Verfahrensgerüste", die nur noch ergänzt werden müssen. Das Erstellen von komplexen SubDas Erstellen von Testtreibern Moduln mit schwierigen Ein-/Ausgaben ist erforderlich. für Testfälle ist erforderlich. Das Verfahren existiert erst dann, wenn Die Überwachung der Testaufgaben der letzte Modul zugeführt wurde. bereitet Schwierigkeiten; der Verwaltungsaufwand ist hoch.

Abb. TESTM-2: Vergleich der Teststrategien beim Programmtest (Quelle: nach End et al.)

Testdaten und Testfälle Testdaten sind die zum Testen eines Testobjekts verwendeten Eingabedaten; ein Testfall wird durch die Angabe des Testobjekts, der Eingabedaten, der Funktionen, die getestet werden sollen, und der erwarteten Ausgabedaten beschrieben. Ein vollständiges Testen ist in der Regel nicht möglich, weil die Anzahl der Kombinationen der Eingabedaten - und damit die Anzahl der Testfälle - auch bei einfachen Testobjekten zu groß ist. Daher müssen die Testfälle sorgfältig festgelegt werden, was viel Erfahrung und Kreativität erfordert. Die Auswahl der Testdaten und Testfälle sollte in Zusammenarbeit mit den zukünftigen Benutzern erfolgen. Dabei muß die gewählte Testart bezüglich des Umfangs der Testausführung beachtet werden.

222

Methoden

und Techniken der

Systemplanung

Bei der Testausführung wird bezüglich der verwendeten Testdaten üblicherweise wie folgt vorgegangen: Im ersten Testlauf wird mit eigens für den Test erzeugten Testdaten ("Spieldaten") und daraus konstruierten Testfällen gearbeitet. In weiteren Testläufen werden die Spieldaten schrittweise durch reale Daten ersetzt, bis man bei den Daten angelangt ist, die später vom produktiven Informationssystem verarbeitet werden müssen. Diese Vorgehensweise verändert sich grundsätzlich, wenn Prototyping zur Anwendung kommt, insbesondere beim evolutionären Prototyping (vgl. Lerneinheit PROTY): Bereits zum Zeitpunkt der Verw e n d u n g des ersten Prototypen werden reale Daten erfaßt und verwendet, die auch f ü r Testzwecke zur Verfügung stehen; Spieldaten sind nicht erforderlich. Ein zweckmäßiges Darstellungsmittel der Testfallermittlung ist die T e s t f a l l m a trix (vgl. Abbildung T E S T M - 3 ) . Sie zeigt den Z u s a m m e n h a n g zwischen den Testfällen (in den Zeilen) und den Funktionen a bis d bzw. e bis h der Testbausteine A und B des Testobjekts (in den Spalten); die Eintragungen zeigen, welcher Testfall bzw. welche Testfälle welche Funktion(en) testet bzw. testen. A

Testbaustein a b

Funktion Testfall

1

X

f

g

h

X

3

5

c d e

X

2

4

B

X

X X

X X

X

Abb. TESTM-3: Testfallmatrix

Testarten Eine Systematik der Testmethoden kann nach folgenden Testarten gebildet werden: nach der Art der Testfallermittlung, nach der Art der Testausführung und nach dem U m f a n g der Testausführung. Die Testfallermittlung kann aufgabenorientiert oder produktorientiert erfolgen. • Bei der a u f g a b e n o r i e n t i e r t e n Testfallermittlung (auch: funktionale oder entwurfsorientierte Testfallermittlung) wird von der Gesamtheit der Funktionen ausgegangen, die zur Durchführung der Anwendungsaufgabe erforderlich sind und als Funktionsanforderungen definiert wurden. Die Struktur des Testobjekts, z.B. seine Ablaufstruktur, bleibt bei der Testfallermittlung unbekannt ("Black-Box-Test"). Mit dem Black-Box-Test können fehlende Funktionen sowie als bekannt unterstellte Fehler in den Funktionen erkannt werden (er wird deshalb auch als funktionaler Test oder Funktionstest bezeichnet). Nicht erkannt werden Fehler, die aus nicht definierten, aber vorhandenen Funktionen resultieren. Wird ausschließlich aufgabenorientiert getestet, müssen die Testfälle alle möglichen Dateneingaben umfassen. Da dies praktisch

TESTM - Testmethoden

223

unmöglich ist ("kombinatorische Explosion"), wird z.B. mit den Grenzwerten der Parameter getestet, die zwischen der Äquivalenzklasse der gültigen und der Äquivalenzklasse der ungültigen Parameterwerte liegen ("Grenzwertanalyse"). • Bei der produktorientierten Testfallermittlung wird von den im Testobjekt realisierten Funktionen ausgegangen; die Struktur des Testobjekts ist für die Testfallermittlung bekannt ("White-Box-Test"). Ziel des produktorientierten Testens ist es, alle im Testobjekt vorhandenen Vorgangsketten zu überprüfen; eine vollständige Testabdeckung ist jedoch nicht immer möglich (z.B. dann nicht, wenn aus der Ablaufstruktur eine große Anzahl von Pfaden resultiert). Im allgemeinen wird aber gegenüber dem aufgabenorientierten Testen eine Verringerung der Testfälle erreicht. Es liegt auf der Hand, daß durch fehlende Funktionen bedingte Fehler nicht erkannt werden. Im allgemeinen wird ein Kompromiß gesucht: Die Testfälle werden zunächst aufgabenorientiert formuliert und dann so weit wie möglich durch Testfälle ergänzt, die produktorientiert ermittelt werden. Bezüglich der Art der Testausführung wird zwischen statischem Testen ("statische Analyse") und dynamischem Testen ("dynamische Analyse") unterschieden. • Beim statischen Testen wird das Testobjekt anhand von Dokumenten über das Testobjekt (z.B. Programmausdrucke in Form von Umwandlungslisten beim Programmtest) analysiert; Testdaten werden nicht verwendet. Ziel dieser Testart ist das Aufdecken von formalen und logischen Fehlern (z.B. Abweichungen von einzuhaltenden Beschreibungsregeln). • Beim dynamischen Testen wird das Verhalten des Testobjekts untersucht; das Testobjekt wird mit Hilfe von Testdaten "zum Ablauf gebracht". Ziel dieser Testart ist das Aufdecken von Fehlern in der Ablauflogik des Testobjekts. Der U m f a n g der Testausführung wird durch die Art und die Anzahl der verwendeten Testfälle festgelegt. Danach wird zwischen repräsentativem Test, schwachstellen-orientiertem Test und schadensausmaß-orientiertem Test unterschieden. • Ein Test wird als repräsentativer Test bezeichnet, wenn Art und Umfang der Testfälle so ausgewählt werden, daß die Komponenten des Testobjekts entsprechend der Häufigkeit ihrer Verwendung getestet werden. • Ein Test wird als schwachstellen-orientierter Test bezeichnet, wenn Art und Umfang der Testfälle so ausgewählt werden, daß die Komponenten des Testobjekts entsprechend der vermuteten Fehlerhäufigkeit in den Komponenten getestet werden. • Ein Test wird als schadensausmaß-orientierter Test bezeichnet, wenn die Komponenten des Testobjekts, bei denen durch das Auftreten von Fehlern ein besonders hoher Schaden verursacht werden kann, intensiver getestet werden als die anderen Komponenten. Zur Einstufung der Testobjekt-Komponenten in Schadensklassen muß eine Risikoanalyse durchgeführt werden. Abbildung TESTM-4 zeigt den Zusammenhang zwischen den Testarten. Weitgehend identisch mit der Testart "statisches Testen" ist die Testart "logisches Testen", und weitgehend identisch mit der Testart "dynamisches Testen" ist die Testart "empirisches Testen". Beim logischen Testen (auch als "Schreib-

224

Methoden und Techniken der Systemplanung

tischtest" bezeichnet) wird das Testobjekt durch gedankliches Nachvollziehen seiner Funktionsweise getestet; beim empirischen Testen wird das Testobjekt auf einem Testsystem implementiert. aufgabenorientiertes Testen

statisches Testen

repräsentatives Testen

produktorientiertes Testen

Art der Testfallermittlung

dynamisches Testen

Art der Testausführung

schadensausmaßorientiertes Testen

schwachstellenorientiertes Testen

Umfang der Testausführung

Abb. TESTM-4: Zusammenhang zwischen den Testarten (Quelle: nach Schmitz et al.)

Werkzeuge zum Testen Die verschiedenen Testmethoden erfordern es, in Abhängigkeit von den Randbedingungen des Tests (insbes. von der Art des Testobjekts) eine sinnvolle Auswahl und Kombination vorzunehmen ("Testmethodik") und ihre Anwendung wo möglich durch Werkzeuge ("Testwerkzeuge") zu unterstützen. Für den Test von Programmen hat sich die folgende Methodik bewährt: • Durchführen eines Funktionstests (Black-Box-Test). Anhand der Modulspezifikation werden mit Hilfe einer Äquivalenzklassen- und Grenzwert-Analyse Testfälle ermittelt; die Struktur des Moduls wird nicht betrachtet. • Der zu testende Modul wird mit einem Zweigüberdeckungs-Werkzeug instrumentiert. Dazu werden automatisch in den Quellcode an den Verzweigungen Zähler eingefügt. Die vollständige Zweigüberdeckung (d.h. Testen aller Programmzweige) soll sicherstellen, daß alle Anweisungen des Moduls mindestens einmal ausgeführt werden. • Der instrumentierte Modul wird übersetzt und mit den ermittelten Testfällen ausgeführt. Die Testfälle werden vom Testwerkzeug protokolliert und in einer Datei abgelegt. Damit ist es bei Änderungen am Modul später möglich, alle Testfälle automatisch zu wiederholen ("Regressionstest"). • Nach Durchführung der Testfälle wird das Testprotokoll betrachtet; es folgt ein ergänzender Strukturtest (White-Box-Test). Für die noch nicht durchlaufenen Zweige werden anhand der Implementierung Testfälle ermittelt und ausgeführt. Ein Testwerkzeug muß sowohl Routinearbeiten (wie Eingabe und Verwaltung der Testfälle) unterstützen, als auch Informationen über den Testfortschritt und die Qualität des Tests (wie automatisches Ausweisen von Abweichungen zwischen erwarteten und tatsächlichen Testergebnissen) liefern. Für den Modultest gibt es eine Reihe von Werkzeugen; für den Integrationstest jedoch (noch) nicht. Für Testobjekte mit sehr hoher Risikoklasse werden Umgebungssimulatoren verwendet, die das Verhalten des Testobjekts in der realen Umgebung simulieren.

TESTM - Testmethoden

225

Sie werden benutzt, wenn das Testen in der realen Umgebung zu gefährlich oder zu aufwendig ist. Demonstrationsbeispiel Am Beispiel des statischen Testens wird der Einsatz einer computergestützten Qualitätssicherung mit Hilfe des Werkzeugs Softdoc (aus dem SoftwareEngineering-System Softing) für das Testen von Software-Produkten gezeigt. Softdoc kann in den Programmiersprachen Assembler, COBOL und PL/1 geschriebene Programme analysieren und daraus Informationen für die Qualitätssicherung gewinnen. Es werden vier Tabellen generiert: eine Datenbeschreibungs-Tabelle, eine Modulschnittstellen-Tabelle, eine Pseudocode-Tabelle und eine Testpfad-Tabelle. Mit den Informationen dieser Tabellen können folgende Überprüfungen computergestützt vorgenommen werden: • Überprüfung der Modularität (z.B. Ein-/Ausgabedaten eines Moduls, Anzahl der Anweisungen, Schnittstellen und Ablaufpfade eines Moduls); • Überprüfung der Strukturiertheit (z.B. Verwendung einer GOTO-Anweisung nur als Ausgang aus einem Strukturblock, Verschachtelung der Ablaufstruktur und der Schleifenstruktur; nur ein Eingang und ein Ausgang in einem Modul); • Überprüfung der Normierung des Programmierstils (z.B. Verwendung numerischer Konstanten, Verwendung laufzeithemmender Anweisungen, Definition unerlaubter Datentypen). Zur Ergänzung der maschinellen Programmprüfung generiert Softdoc Dokumente, die dem Tester bei einer "Sichtkontrolle" helfen. So werden z.B. auf Programmebene das Programmdesign durch einen Modulbaum, der Datenfluß durch EVA-Diagramme (vgl. Lerneinheit HIPO) sowie die Schnittstellen-Tabellen und die Daten durch einen Datenkatalog (vgl. Lerneinheit DAKAT im Band "Informationsmanagement") dargestellt. Softdoc kann auch als Werkzeug zur Redokumentation (vgl. Lerneinheit DOKUM) verwendet werden. Forschungsbefunde Bons/Mengen berichten über drei in den Jahren 1978 bis 1981 durchgeführte Untersuchungen über die Situation und die Entwicklungstendenzen des Testens in der Praxis. Festgestellt wurde: Es wird eine Systematisierung des Testens angestrebt, unter anderem eine stärkere Betonung der Testplanung und der Testkontrolle sowie die Unterstützung des Testens durch Konventionen, die eine frühzeitige und methodische Vorgehensweise sicherstellen; Testwerkzeuge allein können die Aufgabe des Testens nicht lösen; Testwerkzeuge werden, trotz Verfügbarkeit im Haus oder am Markt, vielfach nicht eingesetzt. Kontrollfragen 1. 2. 3. 4. 5.

Welchen Zweck haben das Testen und die Testmethoden? Wie können die Fehler, die beim Testen aufgedeckt werden sollen, systematisiert werden? In welche Teilaufgaben wird die Aufgabe des Testens gegliedert? Welche alternativen Teststrategien können beim Integrationstest angewendet werden? Welche Zusammenhänge bestehen zwischen den verschiedenen Ausprägungen der Testarten?

226

Methoden und Techniken der Systemplanung

Quellenliteratur Balzert, H.: CASE. Systeme und Werkzeuge. 4. A., BI Wissenschaftsverlag, Mannheim et al. 1992 End, W. et al.: Softwareentwicklung. Leitfaden für Planung, Realisierung und Einführung von DV-Verfahren. 7. A., Siemens AG, Berlin/München 1990 Pomberger, G.: Softwaretechnik und Modula-2. 2. A., Hanser Verlag, München/Wien 1987, insbes. Kapitel "Testen und Installation" Schmitz, P. et al.: Software-Qualitätssicherung - Testen im Software-Lebenszyklus. Verlag Vieweg, Braunschweig 1982 Vertiefungsliteratur Bons, H. und Mengen, R. van: Situation und Entwicklungstendenzen des Testens in der Praxis. In: Handbuch der Modemen Datenverarbeitung 105/1982, Forkel Verlag, Stuttgart/Wiesbaden 1982, 85 - 95 Liggesmeyer, P.: Modultest und Modulverifikation. State of the Art. BI Wissenschaftsverlag, Mannheim et al. 1990 Mengen, R. van und Bons, H.: Sicherstellung der Qualität von Programmsystemen durch systematisches Testen. In: Handbuch der Modernen Datenverarbeitung 105/1982, Forkel Verlag, Stuttgart/Wiesbaden 1982, 23 - 36 Sneed, H.: Software-Testen - Stand der Technik. In: Informatik Spektrum 11/1988, 303 - 311 Wallmüller, E.: Software-Qualitätssicherung in der Praxis. Hanser Verlag, München/Wien 1990, 167 - 202

DOKUM - Dokumentationsmethoden Lernziele Sie kennen den Zweck und die Objekte der Dokumentation in der Systemplanung. Sie können die Anforderungen an die Dokumentation erläutern und daraus Qualitätskriterien ableiten. Sie können die verschiedenen Zeitpunkte der Dokumentation beurteilen. Sie kennen die organisatorischen Voraussetzungen, die zur Erstellung der Dokumentation notwendig sind, und die für das Dokumentieren verfügbaren Methoden, Techniken und Werkzeuge. Definitionen und Abkürzungen Datenkatalog (data dictionary) = eine Datenbasis über Objekte wie Entitäten, Prozesse und Beziehungen ("Meta-Daten"). Bedieneranleitung (operator instructions) = der Teil der Dokumentation, der die Informationen enthält, die zur sachgerechten Bedienung der Betriebsmittel erforderlich sind. Synonym: Operatoranleitung. Benutzerdokumentation (user documentation) = der Teil der Dokumentation, der die Informationen enthält, die zur Benutzung eines Informationssystems erforderlich sind und dessen Zielgruppe die Benutzer sind. D o k u m e n t (document) = ein Informationsträger für alle Objekte, die sich inhaltlich beschreiben und formal identifizieren lassen. Dokumentieren (process of documentation) = der Vorgang des systematischen Erstellens einer Dokumentation. Hilfe-System (help system) = der Teil eines Informationssystems, der dem Benutzer Informationen zur Verfügung stellt, welche die Nutzung ermöglichen oder erleichtern. Hypertext-System (hypertext system) = ein Software-System zum Speichern, Verknüpfen und selektiven Suchen von Texten und Grafiken. Qualität (quality) = die Merkmale einer Tätigkeit oder des Ergebnisses einer Tätigkeit (z.B. einer Dokumentation), die sich auf deren Eignung zur Erfüllung definierter Anforderungen beziehen. Referenzmodell (reference model) = ein Modell, das einen gewollten oder geplanten Zustand eines Systems abbildet, an dem der gegenwärtige Zustand des Systems beurteilt werden kann. Synonym: Bezugsmodell. Repository (repository) = die Bezeichnung für einen Datenkatalog im Zusammenhang mit einer Software-Entwicklungsumgebung. Revision (auditing) = die auf die Vergangenheit gerichtete, fallweise Untersuchung bestimmter Prozesse durch prozeßunabhängige Personen, simultan (simultaneous) = der gleichzeitige Ablauf mehrerer Tätigkeiten, Vorgänge oder Ereignisse. Testdokumentation (testing documentation) = die Dokumente, in denen der Testprozeß, vom Testplan bis zum Testbericht, beschrieben ist. Standardisierung (standardization) = das Ausrichten des Handelns an einem allgemein akzeptierten und klar definierten Niveau, das als vorbildlich oder als mustergültig angesehen wird.

228

Methoden und Techniken der Systemplanung

Zweck der Dokumentation Dokumentieren ist das Sammeln, Erfassen, Beschreiben, Ordnen, Darstellen und Speichern von Daten in Dokumenten sowie deren Bereitstellung und Nutzbarmachung für Zwecke der Information; das Ergebnis dieses Prozesses wird als Dokumentation bezeichnet. Objekte der Dokumentation sind die Produkte der Systemplanung einschließlich der Tätigkeiten, die zur Entstehung der Produkte beigetragen haben und der Tätigkeiten, die nach der Entstehung der Produkte mit ihrer Nutzung und Wartung im Zusammenhang stehen. Die Dokumentation soll über ein Informationssystem informieren, insbesondere darüber: • • • • •

welche Aufgaben und welche Eigenschaften es hat; welche Voraussetzungen für die Nutzung gegeben sein müssen; wie, von wem, wann und unter welchen Bedingungen es entwickelt wurde; wie es installiert wurde bzw. wie es zu installieren ist; wie es genutzt und gewartet werden kann.

Die Dokumentation ist eine der Voraussetzungen für die Planung, Nutzung und Wartung eines Informationssystems; sie soll es von den Personen, die es entwickelt haben, unabhängig machen ("Personenunabhängigkeit"). Die Erstellung und Pflege der Dokumentation soll keine eigene Phase der Systemplanung, sondern eine phasenübergreifende Aufgabe während des gesamten Lebenszyklus sein (so wie die Qualitätssicherung und das Testen, vgl. Lerneinheit TESTM). Die Dokumentation dient während der Abwicklung eines IuK-Projekts der Kommunikation zwischen Auftraggeber, Auftragnehmer, Systemplanern und zukünftigen Benutzern; während des Systembetriebs dient sie zur Information über die Nutzung und Wartung. Daneben ist die Dokumentation Nachweismittel (manchmal auch Rechtfertigungsmittel) und Referenzmodell für die Bewertung eines IuK-Projekts und seiner Produkte. Mit der Dokumentation können weitere Zwecke verfolgt werden, wie beispielsweise die Unterstützung des Transfers von Programmen bei zentraler Entwicklung und dezentraler Anwendung, die Standardisierung betrieblicher Arbeitsabläufe sowie die Entwicklung und Bereitstellung von Unterlagen für die innerbetriebliche Schulung. Die Dokumentation soll auch dazu beitragen, daß im Katastrophenfall alle Unterlagen rekonstruiert werden können, die benötigt werden, um ein Informationssystem innerhalb einer definierten Zeitspanne wieder in Betrieb nehmen zu können (vgl. Lerneinheiten SICHM und KATAM im Band "Informationsmanagement"). In diesem Zusammenhang hat die Dokumentation eine Hilfsfunktion für die Sicherheit des Informationssystems. Schließlich ist die Dokumentation auch ein Hilfsmittel zur Erfüllung der gesetzlichen externen und der internen Revisionsvorschriften (vgl. Lerneinheit REVIS im Band "Informationsmanagement"). Dokumentationskrise In der Praxis wird der Dokumentation häufig nicht der ihr zukommende Stellenwert beigemessen ("Dokumentationskrise"). Häufig genannte Gründe für die Dokumentationskrise sind:

DOKUM - Dokumentationsmethoden

229

• Das Bestreben des Managements, ein IuK-Projekt möglichst schnell abzuwickeln und für die Herstellung eines produktiven Zustands scheinbar unwichtige Produktteile zu vernachlässigen. • Das Bestreben der Systemplaner, die Transparenz ihrer Tätigkeit nicht so weit zu entwickeln, daß sie ohne Schwierigkeiten nachvollziehbar und überprüfbar ist. • Die mangelnde Motivation der Systemplaner zum Dokumentieren, da die üblichen Anreizsysteme (z.B. Prämienzahlungen und Erfolgserlebnisse) das Dokumentieren nicht fördern. • Die Meinung vieler Systemplaner, daß das Dokumentieren überflüssig sei, da sie alles Wesentliche ohnehin "im Kopf' haben. • Die praktischen Schwierigkeiten beim Dokumentieren, vor allem dann, wenn Personalengpässe bestehen und wenn keine geeigneten Werkzeuge zur Verfügung stehen. • Die Tatsache, daß "Dokumentieren" kein Bestandteil der Fachausbildung ist. Zur Beseitigung der Dokumentationskrise sind daher eine Reihe von Maßnahmen erforderlich, die von der Motivation über die Schulung bis zur Nutzung von Dokumentationswerkzeugen reichen; in CASE-Systemen integrierte Werkzeuge zwingen die Werkzeuganwender zur Dokumentation (vgl. Lerneinheit WERSP). Objekte der Dokumentation Wird die Abwicklung eines IuK-Projekts vom Projektportfolio bis zur Integration des Projektergebnisses in die bestehende Informationsinfrastruktur betrachtet, so bezieht sich die Dokumentation auf folgende Objekte: auf den Prozeß der Systemplanung selbst, auf die Ergebnisse der Systemplanung und auf den Systembetrieb. Dokumentation des Planungsprozesses ("Projektdokumentation"): Dokumentiert werden die Aufträge (z.B. der Auftrag zur Projektdurchführung), die Ziele vor und während der Projektdurchführung (vgl. Lerneinheiten SACHZ und FORMZ), die Grundlagen und Bedingungen für Entscheidungen, die Besprechungsprotokolle ("Projekttagebuch"), die Meilenstein- und Abschlußberichte sowie die Unterlagen aller Phasen der Systemplanung, z.B. die Ergebnisse der Istzustandsuntersuchung (vgl. Lerneinheiten ERIST und ANIST), die Testdaten und Testergebnisse ("Testdokumentation", vgl. Lerneinheit TESTM) und die gesamte Projektplanung (vgl. Lerneinheit PROPL). Dokumentation der Ergebnisse der Systemplanung: Sie umfaßt die Arbeitsunterlagen, die in die Installierung übergehen und die für den Betrieb und die Nutzung erforderlich sind, die also das Informationssystem selbst dokumentieren ("Systemdokumentation"). Die Systemdokumentation enthält • • • •

die Aufgaben, die mit dem Informationssystem abgedeckt werden; den Aufbau und die Struktur der Komponenten des Informationssystems; die Schnittstellen zu anderen Informationssystemen; die Programmbeschreibungen und Programmablaufpläne und ein Verzeichnis aller Programme, Programmoduln und Tabellen; • die Vorgehensweise bei der Installierung ("Installationsanweisung");

230

Methoden und Techniken der Systemplanung

• die benötigte Hardware und Systemsoftware sowie die erforderlichen Dateien und technischen Betriebsmittel; • die Möglichkeiten der Änderung und Erweiterung des Informationssystems einschließlich der Testmöglichkeiten nach der Durchführung von Änderungen und Erweiterungen. Dokumentation des Systembetriebs: Sie enthält die aus den Planungsergebnissen abgeleiteten Anweisungen an die Benutzer ("Benutzerdokumentation") und Anlagenbediener ("Operatorhandbuch", "Operatoranleitung"). Die Benutzerdokumentation soll sicherstellen, daß das Informationssystem ohne Zuhilfenahme weiterer Informationen produktiv verwendet werden kann. Sie enthält sowohl Informationen, die ohne Nutzung des Informationssystems sichtbar sind ("Benutzerhandbuch"), als auch solche, die nur über eine Systemnutzung sichtbar gemacht werden (z.B. Nutzungshinweise in Masken, Hilfe-Systeme), insbesondere: • eine vollständige und eindeutige Darstellung der Funktionen und ihrer Zusammenhänge ("allgemeine Systembeschreibung"); • ausführliche und mit Erläuterungen versehene Anwendungsbeispiele für alle Funktionen des Informationssystems; • eine Beschreibung aller Belege sowie Hinweise auf organisatorische Abstimmund Kontrollmöglichkeiten der Belege; • ein Verzeichnis und eine Beschreibung aller Ausdrucke und Auswertungen; • ein Verzeichnis der Fehlermeldungen, deren Bedeutung und die möglichen Maßnahmen zur Fehlerbeseitigung; • Hinweise auf mögliche bzw. notwendige Benutzerreaktionen bei außergewöhnlichen Ereignissen (z.B. bei Störungen des Basissystems, bei Undefiniertem Verhalten des Informationssystems); • die Voraussetzungen zur Nutzung des Informationssystems, wie z.B. organisatorische Voraussetzungen, Restriktionen, Aufbewahrungsfristen und Terminpläne. Das Operatorhandbuch enthält alle zum Betrieb des Informationssystems notwendigen Informationen, wie • • • •

die Reihenfolge und Periodizität der Arbeitsabläufe; die Auftraggeber für Auswertungen und die Empfänger von Auswertungen; die Job-Control-Anweisungen; ein Verzeichnis der Konsolnachrichten mit ihren möglichen Ursachen und den notwendigen Reaktionen der Anlagenbediener; • Datensicherungsmaßnahmen (zeitliche Durchführung der Sicherungen, Aufbewahrungsfristen von Datenbeständen bzw. Datenträgem); • die Vorgehensweise bei der Wiederherstellung von Datenbeständen ("Wiederanlaufroutinen").

Anforderungen an die Dokumentation Aus dem Zweck der Dokumentation ergeben sich eine Reihe von Anforderungen, die bei der Erstellung und bei der Verwendung der Dokumentation berücksichtigt werden müssen. Die Anforderungen sind aus dem generellen Sachziel und den verschiedenen Formalzielen an die Dokumentation abzuleiten; sie können als

DOKUM - Dokumentationsmethoden

231

Kriterien verstanden werden, deren Erfüllung die Qualität der Dokumentation maßgeblich bestimmt ("Qualitätskriterien"). Im folgenden werden Beispiele für Qualitätskriterien erläutert. • Übersichtlichkeit: Es muß ein schneller Zugriff zu den Informationen der Dokumentation gewährleistet sein. Hierzu ist es notwendig, den Benutzem der Dokumentation Hilfen zu geben, wie z. B. Inhaltsverzeichnis, Stichwortverzeichnis und Begriffserläuterungen. • Änderbarkeit: Änderungen an der Dokumentation im Sinn von Veränderungen bestehender Inhalte und im Sinn von Erweiterungen der bestehenden Inhalte sollen ohne Schwierigkeiten durchgeführt werden können. • Anschaulichkeit: Es sollen Darstellungstechniken gewählt werden, die es den Benutzern der Dokumentation erlauben, den beschriebenen Sachverhalt schnell zu verstehen. • Einheitlichkeit: Begriffe und Darstellungstechniken müssen einheitlich verwendet werden. Soweit möglich, sollen allgemein übliche Standards eingehalten werden. Liegen keine Standards vor, ist es notwendig, "firmeninterne Standards" zu vereinbaren und zu verwenden. • Gleichartigkeit: Alle Exemplare der Dokumentation an den verschiedenen Aufbewahrungsstellen müssen inhaltlich identisch sein und deshalb zum gleichen Zeitpunkt gepflegt werden. • Strukturiertheit: Der gesamte Inhalt der Dokumentation und alle Teile der Dokumentation (z.B. die Programm-Dokumentation) sollen systematisch zerlegt und klar gegliedert sein. • Vollständigkeit: Formale Vollständigkeit liegt vor, wenn alle Bestandteile der Dokumentation, die in Verzeichnissen und Übersichten genannt sind, auch tatsächlich vorhanden sind. Inhaltliche Vollständigkeit ist gegeben, wenn Beschreibungen für alle Komponenten des Informationssystems in der Dokumentation enthalten sind; redundante Darstellungen sind zu vermeiden. • Aktualität: Die geltende Version des Informationssystems muß mit ihrer Beschreibung in der Dokumentation übereinstimmen. Ohne die ständige Anpassung der Dokumentation an Änderungen des Informationssystems, verliert sie schnell ihren Wert; dies kann zu Fehlern und Mißverständnissen führen. Jede Änderung des Informationssystems erfordert daher eine Änderung der Dokumentation. • Rechtzeitigkeit: Die Zeit zwischen dem Bedarf an einer Information und ihrer Bereitstellung durch die Dokumentation muß klein sein. Dies vor allem dann, wenn das Informationssystem in Betrieb ist. Der Benutzer braucht sofort eine Antwort (z.B. Hilfe-Funktionen bei Bildschirmarbeit), da sonst der Bearbeitungsvorgang unterbrochen oder sogar abgebrochen werden muß. • Benutzbarkeit: Die Dokumentation wird von Benutzern mit unterschiedlichem Bildungsstand und für unterschiedliche Zwecke verwendet. Alle Benutzer müssen jedoch in der Lage sein, mit der Dokumentation arbeiten zu können. Deshalb sind Informationen über den Inhalt, die Darstellungstechniken und die Handhabung der Dokumentation zu vermitteln und gegebenenfalls auf die Voraussetzungen unterschiedlicher Benutzergruppen abzustimmen. • Anpassungsfähigkeit: Erweiterungen und Änderungen müssen problemlos und mit geringem Arbeitsaufwand in die Dokumentation eingefügt werden

232

Methoden und Techniken der Systemplanung

können, ohne daß der erreichte Informationswert reduziert wird oder die Überschaubarkeit leidet. • Identifizierbarkeit: Alle Teile der Dokumentation müssen eindeutig "angesprochen" werden können; sie sollten den Namen des Bearbeiters, das Bearbeitungsdatum (Erstellung oder Änderung), den Änderungsstand usw. enthalten. • Widerspruchsfreiheit: Die Dokumentation soll keine sich widersprechenden Aussagen enthalten. • Wirtschaftlichkeit: Auch für die Dokumentation müssen Kosten und Nutzen in einem ausgewogenen Verhältnis stehen. Ein "zuviel" an Dokumentation verbessert nicht immer die Qualität des Informationssystems, die Kosten für die Erstellung und Pflege der Dokumentation werden aber erhöht. Mit Hilfe von Qualitätskriterien kann ein Qualitätsmodell der Dokumentation entwickelt werden. Dazu sind im Einzelfall die Qualitätskriterien festzulegen und soweit zu operationalisieren, daß es möglich ist, Qualität zu messen. (Es gibt erst wenige Ansätze zur Messung quantitativer Eigenschaften, die nicht allgemein akzeptiert sind, z.B. die Messung der Text-Verständlichkeit.) Bei der Entwicklung des Qualitätsmodells ist auf die Abhängigkeiten zwischen den Qualitätskriterien zu achten. Letztlich werden mit dem Qualitätsmodell Kenngrößen für Dokumentationsqualität definiert. Zu berücksichtigen sind auch externe Vorschriften ("Ordnungsmäßigkeit", vgl. Lerneinheit REVIS im Band "Informationsmanagement"). Überprüfungen der Dokumentation erfolgen unter Verwendung der definierten Qualitätskriterien durch formale Bewertungsprozesse ("Reviews") und durch Feldtests sowie durch die interne oder externe Revision. Zeitpunkt der Dokumentation Für die Erstellung der Dokumentation können grundsätzlich drei verschiedene Zeitpunkte gewählt werden. Danach werden die Dokumentationsarten Vorwärtsdokumentation, Simultandokumentation ("begleitende Dokumentation") und nachträgliche Dokumentation unterschieden. • Vorwärtsdokumentation: Es wird bereits vor der Durchführung bestimmter Tätigkeiten über diese Tätigkeiten dokumentiert. Grundlage für die Dokumentation sind vorhandene Unterlagen (wie interne und externe Richtlinien, Schlüsselverzeichnisse, Begriffsdefinitionen). • Simultandokumentation: Es wird während der Durchführung bestimmter Tätigkeiten über diese Tätigkeiten dokumentiert (auch: projektbezogene Dokumentation, schritthaltende Dokumentation). "Während" ist als "im unmittelbaren zeitlichen Zusammenhang" zu verstehen, nicht als vollständig zeitgleich. • Nachträgliche Dokumentation: Erst wenn bestimmte Tätigkeiten abgeschlossen sind, wird dokumentiert. Nur einzelne Dokumentationsteile können mit Vorwärtsdokumentation erstellt werden. Nachträgliche Dokumentation sollte möglichst vermieden werden. Anzustreben ist eine Simultandokumentation. Der Aufwand für das Dokumentieren wird erheblich reduziert, wenn für andere Zwecke erstellte Arbeitsdokumente als Dokumentationsteile verwendet und wenn geeignete Werkzeuge eingesetzt werden (vgl. weiter unten). Mit einer zweckmäßig aufgebauten, simultan erstellten Dokumentation können folgende Aufgaben wesentlich erleichert werden:

DOKUM - Dokumentationsmethoden

233

• Die Wartung des Informationssystems, weil eine aktuelle Dokumentation die Einarbeitung der Personen, welche die Wartungstätigkeiten durchführen sollen, ermöglicht. • Die Wiederverwendung von Planungsergebnissen, weil eine aktuelle Dokumentation alle vorhandenen Planungsergebnisse nachweist. • Die kooperative Weiterentwicklung des Informationssystems durch die Beteiligung der Benutzer (vgl. Lerneinheit AUTER und Lerneinheit BEBET im Band "Informationsmanagement"), da nach Aufgabenlogik und Technik gegliederte Dokumente eine klare Trennung zwischen Fachverantwortung und Systemverantwortung ermöglichen. Die Aufgabenlogik, das heißt die Beschreibung der maschinell durchzuführenden Aufgaben durch die Angabe von Verarbeitungsregeln, durch die Festlegung der erforderlichen Ein- und Ausgabedaten und durch die Bestimmung der vorgelagerten und der nachgelagerten Aufgaben, kann von den Mitarbeitern der Fachabteilungen entworfen und dokumentiert werden ("Fachverantwortung"). Im Zusammenhang mit dem Reengineering (vgl. Lerneinheit ANWEN im Band "Informationsmanagement") erlangt die nachträgliche Dokumentation unter der Bezeichnung Redokumentation eine große praktische Bedeutung. Objekt der Redokumentation ist meist die Systemdokumentation, seltener (auch) die Benutzerdokumentation. Oft ist Redokumentation die erste Maßnahme eines umfangreichen Reengineering-Prozesses, weil die Beurteilung eines Systems daraufhin, ob Reengineering sinnvoll ist, oft nur auf der Grundlage einer aussagefähigen Dokumentation möglich ist. Werkzeuge unterstützen das Redokumentieren (vgl. das Demonstrationsbeispiel in Lerneinheit TESTM). Dokumentationsverfahren Dokumentationsverfahren beschreiben die Vorgehensweise beim Dokumentieren als einen Prozeß und die in diesem Prozeß verwendeten Methoden, Techniken, Werkzeuge und sonstigen Hilfsmittel. Folgende Vorgehensweise ist beim Erstellen der Benutzerdokumentation üblich: • • • • •

Klären der organisatorischen Voraussetzungen; Entwickeln des Dokumentationskonzepts und seine Überprüfung; Entwerfen der Dokumentation; Revidieren und Überarbeiten des Entwurfs; Fertigstellen der Dokumentation.

Das Klären der organisatorischen Voraussetzungen umfaßt die Beantwortung der folgenden Fragen: • • • • • • • •

Welche Dokumente sind für ein Dokumentationsobjekt erforderlich? Wo sind diese Dokumente zu finden? Wie können die Dokumente beschafft werden? Was soll dokumentiert werden (inhaltliche Auslese)? Nach welchem Ordnungssystem soll die Dokumentation gegliedert werden? Welches Speichermedium soll genutzt werden? Wer wird die Dokumentation nutzen? Wie sollen die Informationen der Dokumentation den Benutzern zur

234

Methoden und Techniken der Systemplanung

Verfügung gestellt werden? • Wie wird die Dokumentation gewartet? Dokumentationstechniken Dokumentationstechniken sind Hilfsmittel zum Dokumentieren. Grundlegende Hilfsmittel sind natürliche und künstliche Sprachen. Hilfsmittel zum Dokumentieren sind grundsätzlich alle Darstellungstechniken (vgl. Lerneinheit DARST), darüber hinaus Entwurfs-, Beschreibungs- und Analysemethoden wie Hierarchy plus Input, Process and Output (vgl. Lerneinheit HIPO), Structured Analysis and Design Technique (vgl. Lerneinheit SADT), Entscheidungstabellentechnik (vgl. Lerneinheit ENTAB), Netzpläne (vgl. Lerneinheit NETZP), Petri-Netze (vgl. Lerneinheit PENET) und Datenflußdiagramme (vgl. Lerneinheit DAFLU).

X X X XXX T-

Dokumentationsklasse, z.B.: P = Projektdokumentation S = Systemdokumentation B = Benutzerdokumentation Dokumentationsart, z.B.: A = Anwendungs-/Systemdokumentation P = Programmdokumentation S = Schnittstellendokumentation I = Installationsanweisung T = Testdokumentation F = Fehlermeldungsverzeichnis 0 = Operatoranweisungen Dokumentationsphase, z.B.: V = Vorstudie F = Feinstudie G = Grobprojektierung P = Feinprojektierung 1 = Installierung Sachgebietsnummer, z.B.: Axx = Arbeitsgebiet Pxx = Projekt Sxx = System

Abb. D O K U M - 1 : Gliederung einer Dokumentationsnummer (Quelle: nach Heilmann)

Um eine Dokumentation, die meist aus vielen Dokumenten besteht, überschaubar zu halten und nutzbar zu machen, werden kleinere Dokumentationseinheiten geschaffen. Dafür gibt es verschiedene Möglichkeiten, insbesondere die Phasengliederung und die Sachgliederung. Bei der Phasengliederung richtet sich die Gliederung nach dem Phasenmodell, bei der Sachgliederung nach der Einteilung in Arbeitsgebiete, Teilprojekte, Daten usw. Meist werden beide Möglichkeiten miteinander kombiniert. Alle Dokumente werden mit einem Klassifizierungsschlüssel und einer Dokumentationsnummer geordnet; Abbildung DOKUM1 zeigt ein Beispiel.

DORUM - Dokumentationsmethoden

235

Dokumentationswerkzeuge Die Aufgaben der Dokumentation und die Anforderungen an die Dokumentation können nur erfüllt werden, wenn hinsichtlich Inhalt, Form und Wartung der Dokumentation eindeutige Richtlinien vorhanden sind und eingehalten werden. Die Einhaltung der Richtlinien kann durch Werkzeuge, die einen gewissen Dokumentationszwang ausüben, gesichert werden. Die "Werkzeuglandschaft" zum Dokumentieren ist vielfältig; sie beginnt schon bei einfachen Textverarbeitungssystemen und reicht bis zu anspruchsvollen Hypermedia-Systemen. Weitere Beispiele für Dokumentationswerkzeuge sind: • • • • • • • • • • •

Datenkataloge, Enzyklopädien und Repositories, Editoren, Suchhilfen ("Browser"), Generatoren (z.B. zum Generieren von Verzeichnissen und grafischen Darstellungen), Grafik-Software, Hypertext-Systeme, Rechtschreib-Prüfprogramme, Autorensysteme, Thesauri (z.B. zur Synonym-Prüfung), Archiv- und Dokumenten-Verwaltungssysteme, Projektmanagement-Software.

Abb. DOKUM-2: Hypertext-System als Dokumentationswerkzeug (Quelle: nach Wallmüller)

Dokumentationswerkzeuge sind schon in einfachen CASE-Werkzeugen integriert (vgl. Lerneinheit WERSP). CASE-Systeme verfügen über anspruchsvolle Werkzeuge, die das Dokumentieren unterstützen (Datenkatalog-Systeme, Enzyklopädien und Repositories). Wesentliche Verbesserungen versprechen HypertextSysteme, insbesondere für das Dokumentieren des Entwurfsprozesses und der Entwurfsergebnisse in den frühen Planungsphasen. In Abbildung DOKUM-2 sind mit den Knoten die Entwicklungsdokumente und mit den Linien die Verbindungen zwischen ihnen dargestellt. Mit dieser Form der Dokumentation ist es z.B. möglich, von einer bestimmten Stelle im Quellcode auf die relevanten Stellen in

236

Methoden und Techniken der Systemplanung

allen anderen Dokumenten zuzugreifen. Zunehmende Bedeutung gewinnen sogenannte Redokumentationswerkzeuge, mit denen aus vorhandenen Unterlagen über einzelne Dokumentationsobjekte (z.B. aus Quellprogrammen bei Software) eine aktuelle Dokumentation erzeugt werden kann, z.B. in der Form von Programmablaufplänen. Ein Beispiel für ein derartiges Werkzeug ist Softdoc (vgl. das Demonstrationsbeispiel in Lerneinheit TESTM). Demonstrationsbeispiel Es wird die Gliederung eines Benutzerhandbuchs gezeigt (nach W. Rupieta), mit der festgelegt wird, welche inhaltlichen Teile - neben dem sachlichen Inhalt zu einem Benutzerhandbuch gehören und in welcher Reihenfolge diese Teile angeordnet werden sollen. • Das Inhaltsverzeichnis stellt die Gliederung des gesamten Handbuchs, insbesondere des Sachinhalts, dar, indem es die Überschriften der einzelnen Kapitel und Abschnitte mit der jeweiligen Seitennummer des Beginns auflistet. Die Hauptüberschriften sollten dabei auch optisch deutlich hervorgehoben werden. Bei einem sehr umfangreichen Handbuch mit starker Unterteilung wird das Inhaltsverzeichnis leicht unübersichtlich und lang. In solch einem Fall werden in das Gesamtinhaltsverzeichnis nur die Hauptkapitel und deren direkte Unterabschnitte aufgenommen. Dafür wird dann jedem Kapitel ein eigenes detailliertes Inhaltsverzeichnis vorangestellt. • Ein Abkürzungsverzeichnis faßt die Abkürzungen, die im Text verwendet werden, zusammen und erläutert sie. Abkürzungsverzeichnisse werden alphabetisch sortiert. • Im Literaturverzeichnis werden Quellen für die Erstellung des Handbuchtextes und Hinweise auf ergänzende Unterlagen angegeben. Bei der Angabe von Quellen sind nur allgemein zugängliche Unterlagen anzugeben. Unternehmensinterne Dokumente wie Pflichtenhefte sind dem Leser in der Regel nicht zugänglich und nützen deshalb auch im Literaturverzeichnis nichts. • Ein Glossar enthält zusammengefaßt wichtige Begriffsdefinitionen, die für das Verständnis des Textes nötig sind. Glossare werden am besten alphabetisch sortiert und sind nach Art eines Lexikons aufgebaut. • Das Stichwortverzeichnis listet die wichtigsten Begriffe und die Stellen auf, an denen diese Begriffe im Text vorkommen. Es ist ein wichtiges Hilfsmittel für den Zugriff auf Informationen. Das Stichwortverzeichnis ist alphabetisch geordnet. Zu jedem Begriff gibt es mindestens eine Referenz auf eine Textseite, wo dieser Begriff definiert oder verwendet wird. Mehrere Verweise sind durchaus möglich und sinnvoll. Das Stichwortverzeichnis sollte möglichst vollständig alle für den Inhalt und für die Benutzer interessanten Begriffe enthalten. Das Stichwortverzeichnis muß sinnvolle Verweise enthalten, z. B. auf die Stelle, wo ein Begriff definiert wird. Nicht jedes Auftreten eines Begriffs muß im Stichwortverzeichnis dokumentiert werden (in einem Handbuch über Textverarbeitung müßten sonst z. B. sehr viele Verweise auf das Vorkommen des Begriffs "Text" stehen). Die Auswahl der Begriffe, die im Stichwortverzeichnis stehen, muß daher sehr sorgfältig unter dem Gesichtspunkt des Nutzens für den Leser erfolgen. Da die endgültigen Seitenzahlen erst nach Fertigstellung eines Benutzerhandbuchs feststehen, kann das Stichwortverzeichnis erst

DOKUM - Dokumentationsmethoden

237

dann sinnvoll erstellt werden. Auch wenn dem Entwurf bereits eine vorläufige Version des Stichwortverzeichnisses beigegeben wird, ist es für die endgültige Fertigstellung oft einfacher, ein neues Stichwortverzeichnis aufzustellen, als ein vorhandenes zu überarbeiten. Auch das Stichwortverzeichnis kann weiter unterteilt sein. Häufig kommen Einträge vor, in denen ein wichtiger Oberbegriff mehrfach auftaucht. In diesem Fall können alle Einträge zu einem solchen Oberbegriff zusammengefaßt werden, etwa in folgender Form: Datensatz 23,31,74-76 35, 73 * Ändern * Definieren 23 * Einfügen 34, 74 * Löschen 76 Das Stichwortverzeichnisse kann bei Verwendung von Textverarbeitungssystemen meist maschinell erstellt werden. Das setzt voraus, daß im laufenden Text die Begriffe markiert werden, die in das Stichwortverzeichnis aufgenommen werden sollen. Beim Formatieren oder Ausdrucken des Textes können dann die markierten Begriffe mit der zugehörigen Seitenzahl registriert und am Schluß sortiert und ausgegeben werden. • Weitere Verzeichnisse können Abbildungen, Tabellen, Beispiele etc. aufzählen. Sonstige Bestandteile eines Benutzerhandbuchs sind Vorwort sowie Erläuterungen zum Aufbau und Umfang des Handbuchs. Anhänge enthalten Materialien, die für die Erläuterungen im Text nicht unmittelbar benötigt werden. Alle diese Bestandteile können entweder vor oder hinter dem Sachinhalt plaziert werden. Kontrollfragen 1. 2. 3. 4. 5.

Welchen Zweck hat die Dokumentation, was sind ihre Objekte? Welche Anforderungen werden an eine Dokumentation gestellt? W i e kann die Wirtschaftlichkeit einer Dokumentation beurteilt werden? W a s sind die Vorteile und was die Nachteile der Simultandokumentation? Welche organisatorischen Voraussetzungen müssen geklärt sein, um eine Dokumentation erstellen zu können?

Quellenliteratur Haag, W.: Dokumentation von Anwendungssystemen aus der Sicht der Benutzer. Toeche-MittlerVerlag, Darmstadt 1981 Rautenberg, K.-U. und Sova, O.: Dokumentation computergestützter Informationssysteme. Saur Verlag, München 1983 Rupieta, W.: Benutzerdokumentation für Softwareprodukte. BI Wissenschaftsverlag, Mannheim et al. 1987 Scheibl, H.-J.: Wie dokumentiere ich ein DV-Projekt? Dokumentationsverfahren in Theorie und Praxis, expert verlag, Sindelfingen 1985 Wallmüller, E.: Software-Qualitätssicherung in der Praxis. Hanser Verlag, Müchen/Wien 1990, 98 - 106

238

Methoden und Techniken der Systemplanmg

Vertiefungsliteratur End, W. et al.: Softwareentwicklung. Leitfaden für Planung, Realisierung und Einführung von DV-Verfahren. 7. A„ Siemens AG, Berlin/München 1990 Hetzel, F.: Dokumentation mit System. Arbeitsgemeinschaft EDV, München 1982 Kuhlen, R.: Hypertext. Ein nicht-lineares Medium zwischen Buch und Wissensbank. Springer Verlag, Berlin et al. 1991 Rausch, H.: Grundsätze ordnungsmäßiger EDV-Dokumentation. Dissertation Universität Hamburg, Hamburg 1983 Normen DIN DIN DIN DIN DIN DIN

44300 66001 66200 66230 66232 66241

Informationsverarbeitung. Begriffe Informationsverarbeitung. Sinnbilder für Datenfluß- und Programmablaufpläne Teil 1, Betrieb von Rechensystemen. Begriffe, Auftragsabwicklung Informationsverarbeitung. Programmdokumentation Informationsverarbeitung. Datei- und Datendokumentation Informationsverarbeitung. Entscheidungstabellen, Beschreibungsmittel

Der Prozeß der Vorstudie Strategische Informationssystem-Planung

i Planungsziele | Der Prozeß der Vorstudie 77777777777777777777777777777*

Grundkonzeption Der Prozeß der Feinstudie

e a u

§

•a

o

Q G a vi

£ u

1

.60

1 | §

£

y,'»77JJ7W/7777J777J777J77JJX

i

Angepaßte % Grundkonzeption %

Der Prozeß der Grobprojektierung /////////^//////y///////////////;

^ Logisches Modell % ^ Sollzustand m Der Prozeß der Feinprojektierung ! Physisches Modélïp Sollzustand Û Der Prozeß der Installierung ; Produktives j • Informationssystem ;

'fffffffffffffffffffftffffffm

240

Der Prozeß der Vorstudie

Gegenstand dieses Kapitels ist der Teil des kooperativen und kreativen Arbeitsprozesses Systemplanung, der nach dem in diesem Lehrbuch verwendeten Phasenmodell als Vorstudie bezeichnet wird. Ausgehend vom Ziel der Vorstudie, werden im ersten Teil des Kapitels ihre Aufgaben entwickelt und die zur Unterstützung der Aufgabendurchführung verwendeten Methoden und Techniken charakterisiert. Anschließend werden die Aufgaben der Vorstudie im Detail erläutert. Im zweiten Teil des Kapitels werden die Methoden und Techniken der Vorstudie dargestellt. Die Zusammenhänge zwischen den Aufgaben der Vorstudie einerseits und ihren Methoden und Techniken andererseits werden durch Methodenverweise bzw. Aufgabenverweise verdeutlicht. Ergebnis der Vorstudie ist die Grundkonzeption des zu schaffenden Informationssystems; sie ist die Schnittstelle zur Feinstudie.

Aufgaben der Vorstudie ZAMVS SACHZ FORMZ GRUND PROPL

-

Ziel, Aufgaben und Methodik der Vorstudie Festlegen der Sachziele Festlegen der Formalziele Entwerfen der Grundkonzeption Durchführen der Projektplanung

,241 248 ,257 ,268 ,275

Methoden und Techniken der Vorstudie ANFOA TECHA KREAT KONSA PROME

-

Anforderungsanalyse Technikanalyse Kreativitätstechniken Konsequenzanalyse Methoden des Projektmanagements

,283 .296 .305 .314 .322

ZAMVS - Ziel, Aufgaben und Methodik der Vorstudie Lernziele Sie kennen das Ziel der Vorstudie und können daraus die Aufgaben der Vorstudie ableiten. Sie kennen die Schnittstellen der Vorstudie zur strategischen Informationssystem-Planung und zur Feinstudie. Sie wissen, welche Methoden und Techniken zur Unterstützung der Aufgaben der Vorstudie zur Verfügung stehen. Definitionen und

Abkürzungen

G r u n d k o n z e p t i o n (preliminary design) = die umrißartige, grobe Beschreibung des zu schaffenden IuK-Systems anhand seiner wichtigsten Eigenschaften (wie Funktionen, Leistungen, Sachmittel). H a n d l u n g s s p i e l r a u m (action scope) = ein mehrdimensionaler Begriff, der Entscheidungsspielraum, Tätigkeitsspielraum und Freiheitsspielraum umfaßt. Synonym: Aktionsspielraum. Heuristik (heuristics) = eine Vorgehensweise, die mit der Hoffnung auf, aber ohne G a r a n t i e von Erfolg zur Lösung einer k o m p l e x e n , nicht oder nur schlecht strukturierten Aufgabe eingesetzt wird. I s t z u s t a n d (current system) = die Gesamtheit der technischen, organisatorischen, personellen und sozialen Bedingungen und Regelungen eines bestehenden Informationssystems. N e b e n b e d i n g u n g (constraint) = eine den Handlungsspielraum begrenzende Vorgabe an die Systemplanung, die nicht als Planungsziel formuliert ist. Planungsziel (planning goal) = ein Ziel, das aus der strategischen Informationssystem-Planung abgeleitet und einem IuK-Projekt vorgegeben wird. P r o d u k t q u a l i t ä t (product quality) = die Menge von Eigenschaften und Merkmalen, mit denen die Qualität der Ergebnisse eines luK-Projekts beschrieben und gemessen wird. P r o j e k t p o r t f o l i o (project portfolio) = der systematisch, häufig nach Priorität geordnete Bestand an Projekten der Systemplanung. P r o z e ß q u a l i t ä t (process quality) = die Menge von Eigenschaften und Merkmalen, mit denen die Qualität der Abwicklung eines IuK-Projekts beschrieben und gemessen wird. Q u a l i t ä t (quality) = die Merkmale einer Tätigkeit oder des Ergebnisses einer Tätigkeit, die sich auf deren Eignung zur Erfüllung definierter Anforderungen beziehen. Sachziel (goal) = ein Ziel, dessen Zielinhalt auf eine Definition des Zwecks oder der Aufgabe eines Systems ausgerichtet ist. Schnittstelle (interface) = jede gedachte oder tatsächliche Verbindung zwischen zwei interagierenden Systemen. S o l l z u s t a n d (target system) = die Gesamtheit der technischen, organisatorischen, personellen und sozialen Bedingungen und Regelungen des zu schaffenden Informationssystems. S t a n d a r d (Standard) = ein allgemein akzeptiertes Niveau, das als vorbildlich oder mustergültig angesehen und an dem das Handeln ausgerichtet wird.

242

Aufgaben der Vorstudie

Ziel der Vorstudie Generelles Sachziel der Systemplanung ist es, dem Auftraggeber ein produktives Informationssystem zur Verfügung zu stellen. Dabei soll das Informationssystem einen akzeptablen Standard haben, der als eine tragfähige Basis für die nächste "Planungsrunde" dienen kann. Es soll also einerseits nicht versucht werden, ein perfektes Informationssystem zu schaffen (was in den meisten Fällen aus technischen und/oder aus wirtschaftlichen Gründen nicht möglich ist); andererseits soll aber die Struktur des Informationssystems so sein, daß es mehr als den ursprünglichen "Inhalt" bezüglich der Sachziele (Funktionen und Leistungen) und der Formalziele (Qualität oder Güte) tragen kann. Das Informationssystem soll also einer Vorgehensweise im Sinn des evolutionären Prototyping (vgl. Lerneinheit PROTY) zugänglich sein. Entsprechend der Phasengliederung der Systemplanung (vgl. Lerneinheit ZAMSP) werden aus dem generellen Sachziel der Systemplanung die Ziele ihrer Phasen abgeleitet, hier also das Ziel der Vorstudie. Davon ausgehend werden die Aufgaben der Vorstudie bestimmt sowie die Methoden und Werkzeuge zur Unterstützung der Aufgabendurchführung festgelegt. Um ein ausreichendes Verständnis für die Zweckmäßigkeit und die Notwendigkeit der Vorstudie zu entwickeln, muß man sich folgendes vor Augen halten: • Die Anzahl der Aufgaben, die durch ein Informationssystem unterstützt werden kann, ist in jeder Organisation groß und unübersichtlich. Bevor man also in eine detaillierte Untersuchung des Istzustands einsteigt und darauf aufbauend ein Sollkonzept entwickelt, ist zunächst einmal festzustellen, welche Aufgaben unterstützt werden sollen. • Die Menge der Informations- und Kommunikationstechniken, die zur Unterstützung der Aufgaben zur Verfügung steht, ist ebenfalls groß und unübersichtlich. Bevor man also in eine detaillierte Untersuchung dieses Angebots einsteigt und darauf aufbauend ein Sollkonzept entwickelt, ist zunächst festzulegen, welche Techniksysteme grundsätzlich geeignet sind. • Der Systemplaner weiß nicht, was der Anwender wirklich will, und der Anwender weiß nicht, was machbar ist. Beide haben also zunächst gemeinsam ein grundlegendes Verständnis darüber zu entwickeln, was der Anwender erwartet und was realisierbar ist; dazu sind Alternativen zu entwerfen. • Die Entwurfsalternativen sind zu bewerten, und es ist eine optimale Alternative auszuwählen. Die Optimumbestimmung kann nur vor dem Hintergrund ausreichend präziser Planungsziele erfolgen; diese sind auch für die nachfolgenden Phasen der Systemplanung erforderlich. • Ein IuK-Projekt kann sich über einen längeren Zeitraum hinziehen und erhebliche Ressourcen verbrauchen; deshalb muß sichergestellt sein, daß eine grundlegende Änderung des Istzustands tatsächlich zweckmäßig ist. Davon ausgehend kann das Ziel der Vorstudie so beschrieben werden: Sie soll in relativ kurzer Zeit und mit möglichst geringem Ressourceneinsatz Aussagen darüber liefern, ob der Istzustand verändert werden soll und - wenn ja - welches unter einer Reihe möglicher neuer Systemkonzepte das optimale ist ("Grundkonzeption").

ZAMVS - Ziel, Aufgaben und Methodik der Vorstudie

243

Daraus ergibt sich der Charakter der Vorstudie als Grobstudie (auch: Durchführbarkeitsstudie, Machbarkeitsstudie), die bezüglich ihrer Methodik primär einem sollzustandsorientierten Ansatz folgt (vgl. Lerneinheit ZAMSP). Der Istzustand wird nur insoweit erhoben, als er für den Entwurf und für die Bewertung alternativer Systemkonzepte und für die Auswahl der Grundkonzeption, auf deren Hintergrund später eine detaillierte Untersuchung des Istzustands erfolgt (vgl. Lerneinheit ZAMFS), erforderlich ist. Ohne eine derartige Vorentscheidung wäre eine ins Detail gehende Istzustandsuntersuchung, die zudem ohne zweckmäßige Abgrenzung der zu untersuchenden Aufgaben erfolgt, nur mit umfangreicher und letztlich nutzloser Mehrarbeit möglich. Schnittstellen der Vorstudie Schnittstellen der Vorstudie sind die Planungsziele (Input der Vorstudie) und die Grundkonzeption (Output der Vorstudie). Die Planungsziele bilden die Schnittstelle zwischen der strategischen Informationssystem-Planung und der Vorstudie (und damit der Systemplanung insgesamt); diese Schnittstelle wurde bei der Darstellung des Zusammenhangs zwischen Informationsmanagement und Systemplanung erläutert (vgl. Lerneinheit ZAMSP). Die Planungsziele haben für die Systemplanung (und damit zunächst für die Vorstudie) eine strategische Bedeutung; sie legen den Handlungsspielraum fest, in dem sich die Systemplanung bewegen kann. Die Planungsziele können, wie in Abbildung ZAMVS-1 gezeigt, zerlegt werden (wegen Einzelheiten vgl. Lerneinheiten SACHZ und FORMZ). Die Grundkonzeption bildet die Schnittstelle zwischen der Vorstudie und der Feinstudie; sie ist damit der Input der Feinstudie (vgl. Lerneinheit ZAMFS).

Abb. ZAMVS-1: Struktur der Planungsziele

Aus der Vorstudie erfolgt eine Rückkopplung zur strategischen Informationssystem-Planung, weil die Formulierung des Projektportfolios, und daraus folgend die Vorgabe der Planungsziele für ein IuK-Projekt, ohne eine Präzisierung von Projektideen nicht möglich ist; diese Präzisierung kann nur durch die Vorstudie erfolgen. Zwischen der Vorstudie und der strategischen Informationssystem-Planung besteht also ein enger, interaktiver Zusammenhang.

244

Aufgaben der Vorstudie

Aufgaben der Vorstudie Aus dem Ziel der Vorstudie, die Grundkonzeption für das zu schaffende Informationssystem zu bestimmen, ergeben sich folgende Aufgaben: • Erste Aufgabe der Vorstudie: Festlegen der Sachziele ("Sachzielplanung"). Entsprechend der Gliederung der Sachziele in Funktionsanforderungen, Leistungsanforderungen und Schnittstellenanforderungen werden die geforderten Funktionen, Leistungen und Schnittstellen festgelegt. Alle Anforderungen müssen sich im Rahmen des Handlungsspielraums, der von den Planungszielen bestimmt wird, bewegen (vgl. Lerneinheit SACHZ). • Zweite Aufgabe der Vorstudie: Festlegen der Formalziele ("Formalzielplanung"). Entsprechend der Gliederung der Formalziele in Anforderungen an die Prozeßqualität und Anforderungen an die Produktqualität werden die geforderten Qualitätsmerkmale für den Planungsprozeß und für das Planungsergebnis festgelegt. Prozeßanforderungen und Produktanforderungen müssen sich im Rahmen des Handlungsspielraums, der durch die Planungsziele gegeben ist, bewegen (vgl. Lerneinheit FORMZ). • Dritte Aufgabe der Vorstudie: Entwerfen der Grundkonzeption ("Entwurfsplanung"). Ausgehend von den als Sachziele und als Formalziele festgelegten Produktanforderungen an das zu schaffende Informationssystem werden alternative Systemkonzepte entworfen und bewertet, und es wird das optimale Systemkonzept als Grundkonzeption ausgewählt (vgl. Lerneinheit GRUND). • Vierte Aufgabe der Vorstudie: Projektplanung. Schließlich werden die Anforderungen an ein IuK-Projekt zur Realisierung der Grundkonzeption und die zur Erfüllung der Planungsziele erforderlichen technischen, personellen, finanziellen und zeitlichen Ressourcen durch die Projektplanung herausgearbeitet (vgl. Lerneinheit PROPL). Abbildung ZAMVS-2 zeigt die Aufgaben der Vorstudie als groben Arbeitsablauf und gibt die Lerneinheiten an, in denen die Aufgaben erläutert werden. Die zentrale Bedeutung der betrieblichen Aufgabe, die durch das zu schaffende Informationssystem unterstützt werden soll, kommt dadurch zum Ausdruck, daß die Sachzielplanung - und innerhalb der Sachzielplanung die Ermittlung der Funktionsanforderungen - Ausgangspunkt des gesamten Arbeitsprozesses ist. Charakter der Vorstudie Die Vorstudie ist ein kooperativer Prozeß, an dem insbesondere die zukünftigen Benutzer des zu schaffenden Informationssystems (als Vertreter des Auftraggebers) und die Systemplaner (als Vertreter des Auftragnehmers) beteiligt sind (vgl. Lerneinheiten PROSP und AUTER). Sie ist auch ein zyklischer Prozeß, der von den definierten Planungszielen ausgeht und zunächst eine grobe Beschreibung der Anforderungen durch den Auftraggeber bzw. durch die Benutzer erfordert. Wieviele Planungszyklen erforderlich sind, um das Ziel der Vorstudie zu erreichen, hängt von verschiedenen Faktoren ab, insbesondere von Umfang und Komplexität der betrieblichen Aufgabe, die Gegenstand des IuK-Projekts ist, aber auch von den Erfahrungen der Beteiligten sowie von den verfügbaren und tatsächlich verwendeten Methoden, Techniken und Werkzeugen.

ZAMVS - Ziel, Aufgaben und Methodik der Vorstudie

245

•^m^mmmmm.

p

Planungsziele

Festlegen der Sachziele SACHZ Festlegen der Formalziele FORMZ Entwerfen der Grundkonzeption GRUND Projektplanung PR OPL

Grundkonzeption ^

Abb. ZAMVS-2: Vorstudie

V / / / / / / / / / / / / / / / / / / / / / / / / / / Der / / MProzeß der

Nebenbedingungen der Vorstudie Außer den Planungszielen werden der Vorstudie in der Regel Nebenbedingungen vorgegeben. Dabei handelt es sich um Tatbestände, welche - wie die Planungsziele - den Handlungsspielraum der Systemplanung begrenzen, die aber nicht als Planungsziele formuliert werden oder die nicht als solche formulierbar sind. Beispiele für Nebenbedingungen sind: • die Beachtung grundlegender strukturorganisatorischer Gegebenheiten des Istzustands, z.B. die Abteilungsgliederung; • die Beachtung grundlegender personeller Gegebenheiten des Istzustands, z.B. die Personalfreisetzungen und Personalumsetzungen und die Bereitstellung von neuen Arbeitsplätzen; • die Beachtung grundlegender technischer Gegebenheiten für den Sollzustand, z.B. die einzusetzenden Techniksysteme (vgl. Lerneinheit TECHA); • die Ernennung eines Projektleiters (vgl. Lerneinheit AUTER); • die Verwendung einer bestimmten Projektorganisation (vgl. Lerneinheit PROPL); • die Beachtung von Projektstandards, z.B. Dokumentationsstandards, die in einem Projekthandbuch niedergelegt sind (vgl. Lerneinheit DOKUM). Methoden und Techniken der Vorstudie Da die Aufgaben der Vorstudie schlecht strukturiert raschend, daß es für die Durchführung der Vorstudie nur Methoden und Techniken gibt. Dies ist für den Erfolg besonderer Bedeutung, weil erfahrungsgemäß gerade

sind, ist es nicht überschwach unterstützende eines IuK-Projekts von in den frühen Phasen

246

Aufgaben der Vorstudie

schwerwiegende Fehler gemacht werden, die sich auf den Prozeß und auf die Ergebnisse der Systemplanung negativ auswirken können. Die Erfahrung zeigt auch, daß die Beseitigung der Fehler - sofern dies überhaupt möglich und nicht ein völliger "Neuaufwurf' erforderlich ist - erhebliche negative Konsequenzen zeitlicher, finanzieller und personeller Art hat, die sich so stark auswirken können, daß wichtige Projektziele (Terminziele, Kostenziele und/oder Leistungsziele) nicht erreicht werden und das Projekt notleidend wird oder scheitert. Die im Kapitel "Methoden und Techniken der Vorstudie" erläuterten Hilfsmittel sind wegen des Charakters der Aufgaben der Vorstudie weder umfangreich, noch gut operationalisiert; sie sind eher Heuristiken als Methoden ("heuristische Methoden"). Die wichtigsten Heuristiken sind: • Die Anforderungsanalyse für das Festlegen der Sachziele und der Formalziele; innerhalb der Anforderungsanalyse wird eine Reihe von allgemeinen Erhebungs- und Beschreibungsmethoden angewendet (vgl. Lerneinheit ANFOA). • Die Technikanalyse (vgl. Lerneinheit TECHA) und die Kreativitätstechniken (vgl. Lerneinheit KREAT) für das Entwerfen alternativer Systemkonzepte. • Die Konsequenzanalyse für das Bewerten alternativer Systemkonzepte und damit für das Bestimmen der Grundkonzeption (vgl. Lerneinheit KONSA); innerhalb der Konsequenzanalyse werden weitere Analysemethoden, wie die Wertanalyse (vgl. Lerneinheit WERTA) und die Wirtschaftlichkeitsanalyse (vgl. Lerneinheit WIRTA), verwendet. • Die Nutzwertanalyse für die Auswahl des optimalen Systemkonzepts, also für das Bestimmen der Grundkonzeption (vgl. Lerneinheit NUTZW). Anforderungsanalyse, Technikanalyse, Kreativitätstechniken und Konsequenzanalyse haben einen sehr engen Bezug zur Vorstudie; sie werden daher im Kapitel "Methoden und Techniken der Vorstudie" behandelt. Die anderen Methoden werden in verschiedenen Phasen der Systemplanung verwendet; sie wurden daher bereits im Kapitel "Methoden und Techniken der Systemplanung" erläutert. Dokumentation der Vorstudie Die Ergebnisse der Sachzielplanung und der Formalzielplanung werden in einem als Anforderungskatalog oder Anforderungsspezifikation bezeichneten Dokument beschrieben. Die Struktur dieses Dokuments kann etwa wie folgt sein: • Einführung: Ausgehend von einer konkreten Informationsnachfrage werden die Planungsziele für das zu schaffende Informationssystem bechrieben. • Systemumgebung: Es wird erläutert, wie das zu schaffende Informationssystem in die bestehende Informationsinfrastruktur einzuordnen ist. • Sachziele: Es werden die Funktions-, Leistungs- und Schnittstellenanforderungen dokumentiert. Die Zusammenhänge mit den Formalzielen werden kenntlich gemacht. • Formalziele: Es werden die Anforderungen an die Prozeßqualität und an die Produktqualität dokumentiert. Die Zusammenhänge mit den Sachzielen werden kenntlich gemacht.

ZAMVS - Ziel, Aufgaben und Methodik der Vorstudie

247

• Begriffserläuterungen: Alle in der Spezifikation verwendeten Fachbegriffe werden erklärt. • Quellen: Alle verwendeten Quellen und Personen, die an der Dokumentation beteiligt waren und die für Änderungen zuständig sind, werden identifiziert. • Index: Ein möglichst umfangreicher Index soll die Verwendung des Dokuments erleichtern. Kontrollfragen 1. 2. 3. 4. 5.

Wie kann das Ziel der Vorstudie beschrieben werden? Warum wird die Methodik der Vorstudie als primär sollzustandsorientiert bezeichnet? Welche Schnittstellen bestehen zwischen der Vorstudie und der strategischen Informationssystem-Planung einerseits sowie der Feinstudie andererseits? Welches sind die Aufgaben der Vorstudie? Welche Aufgaben der Vorstudie können mit welchen Methoden unterstützt werden?

Quellenliteratur Heinrich, L. J.: Schwachstellen und Risiken bei Softwareprojekten. In: Computer und Recht 7/1988, 584 - 587 Kargl, H.: Fachentwurf für DV-Anwendungssysteme. 2. A., Oldenbourg Verlag, München/Wien 1991

SACHZ - Festlegen der Sachziele Lernziele Sie kennen den Zweck des Festlegens der Sachziele ("Sachzielplanung") und den Zusammenhang zwischen dieser Aufgabe der Systemplanung und der Anforderungsanalyse. Sie können Sachziele in geeigneter Weise gliedern und Aussagen über die Zielinhalte und die Zielbeziehungen machen. Sie können eine Vorgehensweise für den Arbeitsprozeß der Sachzielplanung angeben. Definitionen und Abkürzungen A B C - A n a l y s e (inventory analysis) = die Kennzeichnung von Objekten durch ein Kriterium zur Herstellung einer eindeutigen Rangfolge zwischen den Objekten, soweit sie unterschiedlichen Klassen zugeordnet werden. Anforderung (requirement) = eine Aussage über die von einem System geforderten Funktionen, Leistungen und Schnittstellen sowie über die Qualität der Erfüllung der Funktions-, Leistungs- und Schnittstellenanforderungen. Anforderungsspezifikation (requirements specification) = die Abbildung der Anforderungen in ein formales Modell. Synonym: Anforderungskatalog. A u f g a b e (task) = die aus dem bestehenden oder geplanten Leistungsprogramm der Organisation (Gesamtaufgabe) abgeleiteten Teilleistungen. F u n k t i o n (function) = eine Aufgabe oder Teilaufgabe, die den mit ihr verfolgten Zweck konkret beschreibt. F u n k t i o n s a n f o r d e r u n g (functional requirement) = der Teil der Anforderungen an ein System, der sich auf die geforderten Funktionen bezieht. I n f o r m a t i o n s a n g e b o t (information supply) = die Art und der Umfang an Information, die von einem Informationssystem auf Grund seiner Datenbasis und Methodenbasis sowie der verwendeten IuK-Techniken bereitgestellt wird. Informationsnachfrage (information demand) = die Vereinigungsmenge von Informationsbedarf und Informationsbedürfnis. Leistung (Performance) = eine Aussage über die quantitativen Eigenschaften (Umfang und Häufigkeit) einer Funktion. L e i s t u n g s a n f o r d e r u n g (Performance requirement) = der Teil der Anforderungen an ein System, der sich auf die geforderten Leistungen bezieht. Merkmal (characteristic) = die Eigenschaft eines Objekts, die es kennzeichnet und von anderen Objekten unterscheidet. Objekt (entity) = ein individuelles Exemplar der realen Welt oder der Vorstellungswelt des Menschen oder eine Beziehung zwischen zwei Objekten, wenn diese eine Bedeutung hat. Objekttyp (entity type) = eine Klasse von Objekten mit gleichen oder ähnlichen Merkmalen. Synonym: Objektmenge. Vollständigkeit (completeness) = die Übereinstimmung der in einer Spezifikation beschriebenen mit den tatsächlich vorhandenen Anforderungen. Widerspruchsfreiheit (consistency) = die logische Richtigkeit der Abbildung der Wirklichkeit in einer Spezifikation. Synonym: Konsistenz.

SACHZ - Festlegen der Sachziele

249

Zweck des Festlegens der Sachziele Erste Aufgabe der Vorstudie ist es, aus den Planungszielen, die dem IuK-Projekt durch die strategische Informationssystem-Planung vorgegebenen sind, die Sachziele abzuleiten und festzulegen. Sachziele beschreiben den Zweck des Handelns oder des Handlungsergebnisses. Zweck im Sinn der Systemplanung sind die betrieblichen Aufgaben, für die ein IuK-Projekt abgewickelt wird. Die Sachziele beschreiben auch den Zweck des Ergebnisses der Systemplanung, also des IuKSystems, das durch ein IuK-Projekt geschaffen wird. Sachziele werden einem IuK-Projekt in der Regel als relativ grobe Beschreibungen der zu unterstützenden betrieblichen Aufgaben durch Planungsziele vorgegeben. Die Planungsziele müssen in der Vorstudie präzisiert werden. Zweck des Festlegens der Sachziele ist es also, konkrete Aussagen darüber zu machen, welche Funktionen der betrieblichen Aufgaben durch das zu schaffende Informationssystem unterstützt werden sollen, durch welche Leistungen die Funktionen gekennzeichnet sind und welche Schnittstellen zwischen den Funktionen und zum Umsystem der Aufgabe bestehen ("Anforderungen"). Die Sachziele können also zunächst wie folgt in Anforderungen gegliedert werden: • Anforderungen, welche die zu unterstützenden Aufgaben durch ihre Funktionen beschreiben ("Funktionsanforderungen"); • Anforderungen, welche die zu unterstützenden Aufgaben durch die Leistungen ihrer Funktionen beschreiben ("Leistungsanforderungen"); • Anforderungen, welche die zu unterstützenden Aufgaben durch ihre Schnittstellen beschreiben ("Schnittstellenanforderungen"). Auf den Charakter der Sachzielplanung als kooperativer und zyklischer Prozeß ist schon mehrfach hingewiesen worden (vgl. insbes. Lerneinheiten PROSP und AUTER). Diese Eigenschaften gelten in besonderem Maße für die Sachzielplanung. Das heißt, daß das Ermitteln und Festlegen der Anforderungen durch Auftraggeber und Auftragnehmer gemeinsam erfolgt und daß die Anforderungen - ausgehend von ersten groben Vorstellungen - in mehreren Planungsrunden so weit präzisiert werden, wie es dem jeweiligen Planungszweck entspricht. Funktionsanforderungen Eine Funktion kann durch Merkmale, die sie für den Zweck der Vorstudie kennzeichnen, näher beschrieben werden. Derartige Merkmale sind: • die Daten, die zur Funktionserfüllung erforderlich sind ("Datenanforderungen"); • die Methoden, die zur Funktionserfüllung erforderlich sind ("Methodenanforderungen"). Datenanforderungen beschreiben die wichtigsten Objekttypen des zukünftigen Datensystems (vgl. Lerneinheiten WDASY und EDASY). Methodenanforderungen beschreiben die wichtigsten Objekttypen des zukünftigen Methodensystems (vgl. Lerneinheiten WMESY und EMESY). Die Betonung liegt ausdrücklich auf "wichtig", weil es nicht Zweck der Vorstudie ist, die Präzisierung der

250

Aufgaben der Vorstudie

Funktionsanforderungen durch die Feinstudie (vgl. Kapitel "Der Prozeß der Feinstudie") und durch die Grobprojektierung (vgl. Kapitel "Der Prozeß der Grobprojektierung") vorwegzunehmen. Ganz im Gegenteil: Der Zweck der Vorstudie würde dadurch verfehlt werden. Die Wichtigkeit einer Funktion kann zunächst dadurch bestimmt werden, daß nur solche Funktionen betrachtet werden, die - im Sinn der Wertanalyse (vgl. Lerneinheit WERTA) - Hauptfunktionen sind. Die Wichtigkeit der einzelnen Hauptfunktionen kann abgeschätzt werden, indem gefragt wird, welche Bedeutung jede einzelne Funktion für die Erreichung der Qualitätsanforderungen (vgl. Lerneinheit FORMZ) hat. Dabei ist eine Ordnung der Hauptfunktionen nach der ABC-Analyse (vgl. Lerneinheit ISTAN) zweckmäßig. Anzustreben ist, den Aufwand für die Sachzielplanung mit dem Erreichen des Planungszwecks der Vorstudie ins Gleichgewicht zu bringen (d.h. weder zu grob, noch zu detailliert zu arbeiten). Leistungsanforderungen Die Funktionsanforderungen machen noch keine Aussage darüber, welchen Umfang die Funktionen haben und mit welcher Häufigkeit die Funktionen erfüllt werden müssen. Damit ist auch noch nichts über den Umfang bzw. die Häufigkeit der Datenanforderungen und der Methodenanforderungen ausgesagt. Mit Leistung (der Funktionen) werden diese quantitativen Angaben erfaßt. Typische Beispiele für Leistungsanforderungen sind: • • • •

die ungefähre Anzahl der Objekttypen der Daten; die ungefähre Anzahl der Objekttypen der Methoden; die ungefähre Anzahl der Objekte je Objekttyp der Daten und der Methoden; die ungefähre Anzahl des Zugriffs auf die Objekttypen der Daten und auf die Objekttypen der Methoden.

Die Betonung liegt ausdrücklich auf "ungefähr", weil es nicht Zweck der Vorstudie ist, die Präzisierung der Leistungsanforderungen durch die Feinstudie (vgl. Kapitel "Der Prozeß der Feinstudie") und die Grobprojektierung (vgl. Kapitel "Der Prozeß der Grobprojektierung") vorwegzunehmen. Es gilt das im Abschnitt Funktionsanforderungen Gesagte analog. Schnittstellenanforderungen Die wichtigsten Schnittstellen innerhalb des zu schaffenden Informationssystems (zwischen den Funktionen) sowie zwischen dem Informationssystem und seinem Umsystem (andere Informationssysteme und Benutzersystem) müssen festgestellt werden. Für die Erreichung des Zwecks der Vorstudie ist die Schnittstelle zum Benutzersystem ("Benutzerschnittstelle") von besonderer Bedeutung. Die Benutzerschnittstelle macht z.B. Aussagen über die Beziehungen zwischen der Informationsnachfrage (vgl. Lerneinheit ANFOA) und den Objekttypen der Daten und der Methoden, also darüber, ob die Informationsnachfrage durch die Datenanforderungen und die Methodenanforderungen befriedigt, das heißt in das Informationsangebot umgesetzt werden kann.

SACHZ - Festlegen der Sachziele

251

Die Betonung liegt auch hier ausdrücklich auf "wichtig", weil es nicht Zweck der Vorstudie ist, die Präzisierung der Schnittstellenanforderungen durch die Feinstudie (vgl. Kapitel "Der Prozeß der Feinstudie") und die Grobprojektierung (vgl. Kapitel "Der Prozeß der Grobprojektierung") vorwegzunehmen. Es gilt das im Abschnitt Funktionsanforderungen Gesagte analog. Abbildung SACHZ-1 zeigt das Ergebnis der Strukturierung der Sachziele.

Abb. SACHZ-1: Struktur der Sachziele

Zielinhalte der Sachziele Im Unterschied zu den Formalzielen (vgl. Lerneinheit FORMZ) können Zielinhalte für die Sachziele nur im Zusammenhang mit einem bestimmten I u K Projekt beschrieben werden. Zielinhalt der Funktionen meint den konkreten Zweck der Funktionen (z.B. die Funktion "Nettolohnermittlung" in einem Anwendungssystem der Lohn- und Gehaltsverrechnung, deren Zweck die Ermittlung des Nettolohns ist). Zielinhalt der Daten meint die konkrete Angabe der Objekttypen der Daten (z.B. der Objekttyp "Lohnempfänger" in einem Anwendungssystem der Lohn- und Gehaltsverrechnung, dessen Objekte die einzelnen Lohnempfänger sind). Zielinhalt der Methoden meint die konkrete Angabe der Objekttypen der Methoden (z.B. ein ganz bestimmter Algorithmus als Methode zur Ermittlung des Bruttolohns in einem Anwendungssystem der Lohn- und Gehaltsverrechnung). Zielinhalt der Schnittstellen meint die Benennung der zwischen den Funktionen (Insystem-Schnittstellen) und seinem Umsystem (Umsystem-Schnittstellen) bestehenden Zusammenhänge (z.B. die Schnittstelle zwischen der Lohn- und Gehaltsverrechnung und der Kosten- und Leistungsrechnung, mit der die Daten der Lohn- und Gehaltsverrechnung als Kosten beschrieben werden). Die Beispiele verdeutlichen die grobe Struktur der inhaltlichen Beschreibung der Sachziele. Es interessiert z.B. die Funktion "Nettolohnermittlung" als Teil der betrieblichen Aufgabe "Lohn- und Gehaltsverrechnung", es interessieren aber nicht die Teile der Funktion (z.B. nicht die Teilfunktion "Lohnsteuerermittlung"); es interessiert z.B. der Objekttyp "Lohnempfänger" und die ungefähre

252

Aufgaben der Vorstudie

Anzahl der Objekte des Objekttyps, es interessieren aber nicht die Attribute des Objekttyps; es interessiert z.B. der Objekttyp "Algorithmus zur Nettolohnermittlung", es interessieren nicht die Operationen des Algorithmus usw. Diese Aussagen gelten umso mehr, je strukturierter und standardisierter die betrachtete betriebliche Aufgabe ist (wie dies bei der Lohn- und Gehaltsverrechnung, der Finanzbuchhaltung, der Lagerbewirtschaftung weitgehend der Fall ist). Im Unterschied dazu erfordern IuK-Projekte, deren Zweck die Unterstützung schlecht strukturierter Aufgaben ist und deren Bearbeitung innovativ ist, präzisere Beschreibungen der Sachziele. Grund dafür ist, daß im ersten Fall die Anforderungen für jeden Fachmann weitgehend bekannt sind, im zweiten Fall aber weitgehend neuartig sein können. Zielbeziehungen So wie die Sachziele selbst, können auch die Zielbeziehungen zwischen den Sachzielen nur im Zusammenhang mit einem ganz bestimmten IuK-Projekt beschrieben werden; idealtypische Zielbeziehungen können nicht angegeben werden (im Unterschied zu den Formalzielen, vgl. Lerneinheit FORMZ). Zwischen Funktionsanforderungen, Leistungsanforderungen und Schnittstellenanforderungen bestehen zahlreiche Beziehungen, deren Aufdeckung im Projektzusammenhang für die Prüfung der Vollständigkeit und Widerspruchsfreiheit der Sachziele verwendet werden können (z.B. die Tatsache, daß bestimmte Methoden bestimmte Daten benötigen, um angewendet werden zu können). Aufgabe der Sachzielplanung ist es daher auch, die in einem konkreten IuK-Projekt bestehenden Beziehungen zwischen den Sachzielen aufzudecken. Vorgehen beim Festlegen der Sachziele Die zum Festlegen der Sachziele erforderlichen Tätigkeiten, deren Ergebnis die Spezifikation der Sachziele ist, können wie folgt zu Arbeitsschritten geordnet werden (vgl. Abbildung SACHZ-2): • Erster Arbeitsschritt: Festlegen der Funktionen. Das Festlegen der Sachziele beginnt damit, aus den vorgegebenen Planungszielen für die betrieblichen Aufgaben die wichtigsten Funktionen abzuleiten, die mit dem zu schaffenden IuK-System unterstützt werden sollen. Zum Festlegen der Funktionen gehört es, die für ihre Durchführung erforderlichen Objekttypen der Daten und Objekttypen der Methoden anzugeben. • Zweiter Arbeitsschritt: Festlegen der Leistungen. Für jede als wichtig bestimmte Funktion, jeden wichtigen Objekttyp der Daten und jeden wichtigen Objekttyp der Methoden werden der ungefähre Umfang bzw. die ungefähre Häufigkeit bestimmt. • Dritter Arbeitsschritt: Festlegen der Schnittstellen. Die wichtigsten Schnittstellen, die zwischen den wichtigsten Funktionen des zu schaffenden IuK-Systems sowie zwischen diesem und seinem Umsystem bestehen, werden bestimmt. • Vierter Arbeitsschritt: Prüfen auf Vollständigkeit und Widerspruchsfreiheit. Schließlich wird überprüft, ob die Funktionen mit ihren Daten und Methoden, die Leistungen (Umfang bzw. Häufigkeit) der Funktionen mit ihren

SACHZ - Festlegen der Sachziele

253

Daten und Methoden sowie die Schnittstellen des Insystems und des Umsystems vollständig beschrieben und die Beschreibungen untereinander widerspruchsfrei sind ("Verifizierung").

Je nachdem, wie umfassend oder wie eng Vollständigkeit und Widerspruchsfreiheit interpretiert werden, kann die Verwendung weiterer Prüfkriterien zur Verifizierung der Anforderungen verlangt werden, z.B. Korrektheit, Eindeutigkeit, Verständlichkeit und Änderbarkeit. • Korrektheit: Eine Spezifikation ist korrekt, wenn jede Anforderung aus anderen Anforderungen logisch ableitbar ist. • Eindeutigkeit: Eine Spezifikation ist eindeutig, wenn jede Anforderung nur eine Möglichkeit der Interpretation hat. • Verständlichkeit: Eine Spezifikation ist verständlich, wenn sie von einem sachverständigen Benutzer ohne Schwierigkeiten verwendet werden kann. • Änderbarkeit: Eine Spezifikation ist (leicht) änderbar, wenn Anforderungen aus ihr entfernt und/oder Anforderungen nachträglich in sie aufgenommen werden können. Diese Formulierungen sind wenig operational, sodaß es schwierig, wenn nicht sogar unmöglich ist, die genannten Prüfkriterien tatsächlich zu verwenden. Zudem sind einige der genannten Prüfkriterien miteinander konfliktär, sodaß es nicht möglich ist, sie alle gemeinsam zu maximieren (z.B. wird mehr Verständlichkeit durch weniger Eindeutigkeit erreicht, und Verständlichkeit wird umso mehr reduziert, je mehr Vollständigkeit erreicht wird).

254

Aufgaben der Vorstudie

Demonstrationsbeispiel Angenommen, das Sachziel der Systemplanung ist die Schaffung eines Personalinformationssystems. Es wird gezeigt, wie aus diesem Sachziel die Funktionsanforderungen (im Sinn der wichtigsten Funktionen), die Datenanforderungen (im Sinn der wichtigsten Objekttypen der Daten) und die Schnittstellenanforderungen (im Sinn der wichtigsten Beziehungen zwischen den Funktionen), die zur Erreichung dieses Sachziels erforderlich sind, abgeleitet und festgelegt werden. Dabei wird nicht von den Aufgaben der bestehenden Struktureinheit "Personalabteilung", sondern von der Menge der Aufgaben, die sich mit der menschlichen Arbeitskraft im betrieblichen Leistungsprozeß befaßt (und bei der betriebswirtschaftliche Fragestellungen auftreten), ausgegangen, also von den personalwirtschaftlichen Aufgaben. Die personalwirtschaftlichen Aufgaben werden in zwei Stufen in Funktionen zerlegt ("Aufgabenzerlegung"), die auch die Schnittstellen zwischen den Funktionen sichtbar machen. • Erste Stufe der Aufgabenzerlegung: Gliederung der personalwirtschaftlichen Gesamtaufgabe in Kernaufgaben, Uraufgaben und Einwirkaufgaben. • Zweite Stufe der Aufgabenzerlegung: Gliederung der Kernaufgaben in die Funktionen Ermitteln des Personalbedarfs, Beschaffen des Personals, Einsetzen des Personals, Erhalten des Personals, Entwickeln des Personals und Freistellen des Personals. Uraufgaben sind Funktionen zur Datenfindung für die Kernaufgaben. Sie werden in Uraufgaben des Personalbereichs sowie in Uraufgaben des Personalbereichs und anderer betrieblicher Bereiche (wie z.B. Fertigung, Absatz, Finanzen) zerlegt. Abbildung SACHZ-3 zeigt zur Erklärung eine Liste der Uraufgaben. U 1. U 2. U 3. U 4. U 5. U 6. U 7. U 8. U 9. U10. Uli. U12. U 13. U14. U15. U16.

Erforschen des Arbeitsmarkts Ermitteln des Leistungsprogramms Gestalten der betrieblichen Arbeitsorganisation Durchführen von Motivationsuntersuchungen Gesunderhalten des Personals Durchfuhren von Betriebsuntersuchungen Auswerten des betrieblichen Leistungsprozesses Durchführen von Leistungsbewertungen und Mitarbeiterbeurteilungen Führen von Einstellungsgesprächen Führen von Informationsgesprächen mit den Vorgesetzten der Mitarbeiter Bearbeiten von Mitarbeiterkündigungen Bearbeiten behördlicher oder gerichtlicher Anordnungen Auswerten gesetzlicher Bestimmungen und Verordnungen Gestalten und Auswerten tarifvertraglicher Vereinbarungen, Betriebsvereinbarungen und individueller Arbeitsverträge Übernehmen mitarbeiterindividueller Unterlagen Auswerten von Angeboten außerbetrieblicher Weiterbildungsveranstalter Abb. SACHZ-3: Personalwirtschaftliche Uraufgaben (Quelle: Heinrich/Pils)

Einwirkaufgaben stellen Funktionen bereit, deren Zweck die Veränderung (Beeinflussung und/oder Mitgestaltung) der personalwirtschaftlichen Umwelt (innerbetrieblich oder außerbetrieblich) und insbesondere der Uraufgaben ist, die

SACHZ - Festlegen der Sachziele

255

sowohl den Personalbereich als auch andere betriebliche Bereiche betreffen. Sie werden wie folgt gegliedert: • Einwirkaufgaben auf die betriebliche Umwelt; • Einwirkaufgaben auf andere betriebliche Aufgaben; • Einwirkaufgaben auf Uraufgaben (insbesondere auf das Ermitteln des Leistungsprogramms, auf das Gestalten der Arbeitsorganisation, auf das Gesunderhalten des Personals). Uraufgaben und Kernaufgaben werden im allgemeinen nicht synchron durchgeführt. So löst z.B. die Durchführung einer Uraufgabe nicht zwangsläufig und gleichzeitig die Durchführung einer Kernaufgabe aus. Daraus folgt, daß zwischen Uraufgaben und Kernaufgaben Speicheraufgaben angeordnet sind. Viele Kernaufgaben liefern Daten für die Durchführung von Einwirkaufgaben. Zur Durchführung von Einwirkaufgaben sind teilweise auch Daten durch Uraufgaben zu gewinnen. In analoger Weise wie für Uraufgaben und Kernaufgaben gilt für Uraufgaben und Einwirkaufgaben die Zweckmäßigkeit der Anordnung von Speicheraufgaben. Innerhalb der Uraufgaben, der Kernaufgaben und der Einwirkaufgaben sind ebenfalls Speicheraufgaben anzuordnen. Alle Speicheraufgaben im personalwirtschaftlichen Aufgabensystem lassen sich logisch zusammenfassen. Die Präzisierung der Speicheraufgaben führt zu den Objekttypen der Daten für das personalwirtschaftliche Aufgabensystem (z.B. MITARBEITER) und ihrer Leistungen (z.B. Häufigkeit der Objekte vom Objekttyp MITARBEITER). Das personalwirtschaftliche Aufgabensystem mit seinen Funktionen als Elemente und mit Schnittstellen zwischen den Funktionen kann, wie Abbildung SACHZ-4 zeigt, als grafisches Modell abgebildet werden. Bei der Interpretation des Modells sind die Details zu den vier Aufgabenklassen zu berücksichtigen.

256

Aufgaben der Vorstudie

Forschungsbefunde Die Schaffung innovativer Informationssysteme setzt Kenntnisse über die zugrunde liegenden Aufgabensysteme in Form "genereller Bebauungspläne" voraus, wenn davon ausgegangen wird, daß der Ausgangspunkt eines IuK-Projekts in Wirtschaft und Verwaltung immer die betriebliche Aufgabe ist. Bezüglich des personalwirtschaftlichen Aufgabenbereichs haben Heinrich/Pils festgestellt, daß die personalwirtschaftliche Literatur zwar ausführlich die verschiedenen personalwirtschaftlichen Aufgaben "beschreibt", daß sie aber keine systematische Darstellung des Aufgabensystems liefert, das für die Systemplanung verwendbar wäre. A.-W. Scheer berichtet über ähnliche Erfahrungen, insbesondere bei der Produktionsplanung und -Steuerung s o w i e im R e c h n u n g s w e s e n , und erhebt auf

Grund dieser Feststellung die Forderung nach mehr "EDV-Orientierung" der Betriebswirtschaftslehre. Im Zusammenhang mit der Entwicklung von Expertensystemen für Aufgaben der Büroarbeit wird über entsprechende Beobachtungen von P. Mertens berichtet. Aus diesen Befunden ist der Schluß zu ziehen, daß die systematische Aufbereitung der aus dem Leistungsprogramm einer Organisation abzuleitenden Aufgaben und ihre Zerlegung so, daß die wichtigsten Funktionen, Daten und Schnittstellen erkennbar sind, in der Betriebswirtschaftslehre aus der Sicht der Systemplanung unterentwickelt ist. Methoden verweise A n f o r d e r u n g s a n a l y s e (Lerneinheit A N F O A ) ; Prototyping (Lerneinheit P R O T Y ) ; W e r t a n a l y s e (Lerneinheit W E R T A ) .

Kontrollfragen 1. 2. 3. 4. 5.

Welcher Zweck wird mit d e m Festlegen der Sachziele verfolgt? W i e können Sachziele in geeigneter Weise gegliedert werden? Unter welchen Voraussetzungen können Zielinhalte und Zielbeziehungen präzisiert werden? W e l c h e Arbeitsschritte beschreiben den Arbeitsablauf beim Festlegen der Sachziele? W e l c h e Kriterien können zur Verifizierung der Sachziel-Spezifikation verwendet werden?

Quellenliteratur Heinrich, L. J. u n d Pils, M.: Betriebsinformatik im Personalbereich - Die Planung c o m p u t e r g e s t ü t z t e r P e r s o n a l i n f o r m a t i o n s s y s t e m e . P h y s i c a - V e r l a g , W ü r z b u r g / W i e n 1979, N a c h d r u c k 1983, 38 - 4 6 H o f f m a n n , F.: A u f g a b e . In: G r o c h l a , E. (Hrsg.): H a n d w ö r t e r b u c h der Organisation. Poeschel Verlag, Stuttgart 1980, 2 0 0 -207 Kargl, H.: Fachentwurf für D V - A n w e n d u n g s s y s t e m e . 2. A., Oldenbourg Verlag, M ü n c h e n / W i e n 1991 S c h e e r , A . - W . : E D V - o r i e n t i e r t e Betriebswirtschaftslehre. 4.A., Springer Verlag, Berlin et al. 1990

Vertiefungsliteratur Martin, C . F.: User-Centered Requirements Analysis. Prentice Hall Int., E n g l e w o o d C l i f f s , N.J. 1988 T h a y e r , R . H. and D o r f m a n , M.: System and S o f t w a r e R e q u i r e m e n t s E n g i n e e r i n g , C o m p u t e r Society Press, Los A l a m o s 1990

FORMZ - Festlegen der Formalziele Lernziele Sie kennen den Zweck des Festlegens der Formalziele ("Formalzielplanung") und den Zusammenhang dieser Aufgabe der Systemplanung mit der Anforderungsanalyse. Sie können Formalziele in geeigneter Weise gliedern und Aussagen über die Zielinhalte und die Zielbeziehungen machen. Sie können eine Vorgehensweise für die Formalzielplanung angeben. Definitionen und Abkürzungen Ablaufsteuerung (process control) = die zeitliche, örtliche und logische Abwicklung der in Arbeitsschritte ("Transaktionen") gegliederten Aufgaben, die mit einem Informationssystem unterstützt werden. Automatisierung (automation) = der Vorgang oder das Ergebnis der Einführung von Arbeitsgängen, die ohne unmittelbare menschliche Tätigkeit maschinell ausgeführt werden. Formalziel (quality goal) = ein Ziel, dessen Zielinhalt die Qualität oder die Güte eines Prozesses oder eines Systems definiert. Dialogisierung (interaction) = der Vorgang oder das Ergebnis der Einführung von Arbeitsgängen, die im Wechsel zwischen menschlichen Tätigkeiten und maschinellen Tätigkeiten ausgeführt werden. Innovation (innovation) = der Vorgang oder das Ergebnis der Änderung eines Informationssystems, die auf neuen Erkenntnissen beruht und die zu neuartigen Realisierungen führt. Integration (integration) = der Vorgang oder das Ergebnis der Herstellung oder der Wiederherstellung eines Ganzen durch Vereinigen oder Verbinden logisch zusammengehöriger Teile. Kooperation (Cooperation) = die Bearbeitung eines gemeinsamen Objekts nach vereinbarten Bearbeitungsregeln durch mehrere Aufgabenträger. Modularität (modularity) = die Eigenschaft eines Informationssystems, nach bestimmten Prinzipien gegliedert und dadurch unter anderem leichter wartbar zu sein. MTBF = Abkürzung für Mean Time Between Failures (mittlere Zeitspanne zwischen Fehlern); eine Maßzahl für Verfügbarkeit. MTBM = Abkürzung für Mean Time Between Malfunctions (mittlere Zeitspanne zwischen Fehlfunktionen); eine Maßzahl für Verfügbarkeit. MTTF = Abkürzung für Mean Time To Failure (mittlere Zeitspanne bis zu einem Fehler); eine Maßzahl für Verfügbarkeit. MTTR = Abkürzung für Mean Time To Repair (mittlere Zeitspanne bis zu einer Reparatur); eine Maßzahl für Verfügbarkeit. Prozeß (process) = eine Menge von Operationen, die einen Input in ein System, interne Funktionen und einen Output aus dem System beschreiben. Qualität (quality) = die Menge der Eigenschaften und Merkmale einer Tätigkeit oder des Ergebnisses einer Tätigkeit, die sich auf deren Eignung zur Erfüllung definierter Anforderungen bezieht.

258

Aufgaben der Vorstudie

Zweck des Festlegens der Formalziele Zweite Aufgabe der Vorstudie ist es, aus den von der strategischen Informationssystem-Planung vorgegebenen Planungszielen die Formalziele abzuleiten und festzulegen ("Formalzielplanung"). Formalziele beschreiben die Qualität oder die Güte, mit der die Sachziele (vgl. Lerneinheit SACHZ) erreicht werden sollen. So wie die Sachziele, werden einem IuK-Projekt in der Regel auch die Formalziele als relativ grobe Beschreibungen der Qualität oder der Güte der Sachzielerreichung als Planungsziele vorgegeben. Diese groben Beschreibungen müssen in der Vorstudie bezüglich aller drei Zieldimensionen (Zielinhalt, Ausmaß der Zielerreichung und zeitlicher Bezug) präzisiert werden. Zweck des Festlegens der Formalziele ist es also, die Anforderungen an die Qualität der Systemplanung als Arbeitsprozeß und an die Qualität der Ergebnisse dieses Arbeitsprozesses festzulegen. Die damit definierte Eignung von Prozeß und Produkt zur Erreichung der Sachziele dient auch der Qualitätssicherung. Die Formalziele können zunächst nach dem Objekt, auf das sie sich beziehen, wie folgt gegliedert werden (vgl. Abbildung ZAMVS-1; zur weiteren Zerlegung siehe weiter unten): • Formalziele, welche die Qualität oder die Güte des Arbeitsprozesses Systemplanung beschreiben ("Prozeßqualität"). • Formalziele, welche die Qualität oder die Güte der Ergebnisse dieses Arbeitsprozesses beschreiben ("Produktqualität").

Abb. FORMZ-1: Struktur der Formalziele

Auf den Charakter der Sachzielplanung als kooperativer und zyklischer Prozeß ist schon mehrfach hingewiesen worden (vgl. insbesondere Lerneinheiten PROSP und AUTER). Diese Eigenschaften gelten für die Formalzielplanung in einem geringeren Maße als für die Sachzielplanung, weil einige Formalziele (wie z.B. Wirksamkeit und Wirtschaftlichkeit) Planungsvorgaben sind, die weder einen Diskussionsprozeß erlauben, noch eine - wenn auch nur schrittweise - Annäherung an die Zielerreichung zulassen.

FORMZ - Festlegen der Formalziele

259

Formalziele für Prozeßqualität Formalziele, welche die Prozeßqualität beschreiben, können zunächst in Leistungs-, Termin- und Kostenziele zerlegt werden. Leistungsziele sind Ziele, welche die Erbringung von Zwischenergebnissen und Ergebnissen der Systemplanung beschreiben. Terminziele sind Ziele, welche die geplanten Zeitpunkte oder Zeiträume für die Erbringung von Zwischenergebnissen und Ergebnissen der Systemplanung beschreiben. Kostenziele sind Ziele, welche den geplanten und bewerteten Verbrauch an Gütern und Dienstleistungen für die Erbringung von Zwischenergebnissen und Ergebnissen der Systemplanung beschreiben. Weitere Formalziele zur Beschreibung der Prozeßqualität lassen sich ableiten, wenn die Beziehungen zwischen Leistungen, Terminen und Kosten präzisiert und wenn diese Beziehungen aus einem anderen Blickwinkel betrachtet werden (z.B. der Aufwand als mengenmäßiger Verbrauch an Gütern und Dienstleistungen und nicht die Kosten als bewerteter Verbrauch). Diese Betrachtung führt zu Formalzielen wie Produktivität, Wirtschaftlichkeit und Zuverlässigkeit (zur Erläuterung der Zielinhalte siehe weiter unten). Formalziele für Produktqualität Formalziele, welche die Produktqualität beschreiben, können in Nutzungsziele und Wartungsziele zerlegt werden. Nutzungsziele beschreiben die Qualität der Nutzung der Produkte der Systemplanung; sie können zusammenfassend mit Brauchbarkeit oder Gebrauchsgüte bezeichnet werden. Wartungsziele beschreiben Qualitätsmerkmale der Produkte der Systemplanung bezüglich ihrer Anpassung an veränderte Anforderungen (insbesondere an veränderte Sachziele, aber auch an veränderte Nutzungsziele); sie werden zusammenfassend als Wartbarkeit bezeichnet. Eine Präzisierung der Nutzungsziele kann nach den Qualitätsmerkmalen Akzeptanz, Benutzbarkeit, Produktivität, Sicherheit, Übertragbarkeit, Verfügbarkeit, Wirksamkeit, Wirtschaftlichkeit und Zuverlässigkeit (und gegebenenfalls weiterer Merkmale) erfolgen. Eine Präzisierung der Wartungsziele kann nach den Qualitätsmerkmalen Anderbarkeit (auch: Flexibilität), Testbarkeit und Verständlichkeit (und gegebenenfalls weiterer Merkmale) erfolgen (zur Erläuterung der Zielinhalte siehe weiter unten). Neben den Nutzungszielen und den Wartungszielen sind eine Reihe weiterer Formalziele, die Qualitätsanforderungen beschreiben, zu berücksichtigen. Sie werden unter der Bezeichnung Rahmenziele zusammengefaßt. Rahmenziele legen Qualitätsanforderungen fest, die auf alle anderen Formalziele einwirken. Sie beeinflussen damit entscheidend das Entwerfen alternativer Systemkonzepte (vgl. Lerneinheit GRUND). In vielen IuK-Projekten sind Innovation (ausgedrückt als "Innovationsgrad"), Automatisierung (ausgedrückt als "Automatisierungsgrad"), Integration (ausgedrückt als "Integrationsgrad"), Kooperation (ausgedrückt als "Kooperationsgrad") und Dialogisierung (ausgedrückt als "Dialogisierungsgrad") als Rahmenziele zu berücksichtigen.

260

Aufgaben der Vorstudie

• Der Innovationsgrad beschreibt, in welchem Umfang mit dem zu schaffenden Informationssystem, durch die Berücksichtigung neuer, bisher nicht oder nicht ausreichend beachteter Erkenntnisse und/oder verwendeter IuK-Techniken, neuartige Problemlösungen realisiert werden sollen. Er sollte auch Aussagen darüber machen, welche neuen Qualifikationen verlangt und welche Arbeitsplätze neu geschaffen werden. • Der Automatisierungsgrad legt fest, in welchem Umfang mit dem zu schaffenden Informationssystem menschliche Tätigkeit durch maschinelle Tätigkeit substituiert werden soll, welche Tätigkeiten also durch menschliche Aufgabenträger und welche Tätigkeiten durch Techniksysteme ausgeführt werden sollen. Er sagt in der Regel auch darüber etwas aus, welche Qualifikationen überflüssig werden und in welchem Ausmaß Arbeitsplätze wegfallen. • Der Integrationsgrad legt fest, in welchem Umfang mit dem zu schaffenden Informationssystem logisch zusammengehörige Teile (Funktionen, Daten und damit Arbeitsabläufe) zusammengefügt werden sollen. Damit wird die gewollte Arbeitsteiligkeit des Aufgabenvollzugs beschrieben. Den Objekten der Integration entsprechend, wird zwischen Funktionsintegration und Datenintegration unterschieden; beide gemeinsam bewirken Ablaufintegration. Der Integrationsgrad betont daher die Prozeßsicht; nicht einzelne betriebliche Aufgaben sollen letztlich besser unterstützt werden, sondern es sollen die Geschäftsprozesse durch Informationssysteme verändert werden. • Der Kooperationsgrad macht Aussagen darüber, wie intensiv Aufgabenträger bei der gemeinsamen Abwicklung von Arbeitsaufgaben durch Koordination und Kommunikation zusammenwirken. Er betont die Prozeßsicht und ist besonders in IuK-Projekten von Bedeutung, die Aufgaben mit einem hohen Kooperationspotential zum Gegenstand haben. • Der Dialogisierungsgrad beschreibt die Anforderungen an die Ablaufsteuerung des Informationssystems (Dialogbetrieb oder Stapelbetrieb) bzw. welche Teile des Informationssystems im Dialogbetrieb und welche im Stapelbetrieb abgewickelt werden sollen. Zielinhalte der Formalziele Im folgenden wird der Zielinhalt der in Abbildung FORMZ-1 genannten Formalziele zur Beschreibung der Prozeßqualität und der Produktqualität erläutert. Soweit möglich, werden Hinweise zur Messung von Zielerträgen gegeben, indem Maßgrößen angegeben werden. Mit der Nennung von Einflußgrößen wird auf Zielbeziehungen sowie auf weitere Eigenschaften, die als (Unter-)Ziele definiert werden können, hingewiesen. Anhand der Einflußgrößen wird beispielhaft auf typische Zielbeziehungen hingewiesen (vgl. dazu auch den nächsten Abschnitt). Die in Abbildung FORMZ-1 genannten Formalziele decken im wesentlichen, nicht aber vollständig die Merkmale ab, mit denen üblicherweise die Qualität von IuK-Prozessen und IuK-Systemen beschrieben wird. Formalzielen, die sowohl ein Merkmal der Prozeßqualität als auch der Produktqualität sind, kann im allgemeinen eine besondere Bedeutung für die Qualitätssicherung zugemessen werden.

FORMZ - Festlegen der Formalziele

Zielinhalt

Beschreibt Prozeßqualität

Beschreibt Produktqualität

Akzeptanz

X

Ändeibarkeit

X

Aufgabenbezogenheit

X

Benutzbarkeit

X

Produktivität

X

X

Sicherheit

X

Testbarkeit

X

Übertragbarkeit

X

Verfügbarkeit

X

Verständlichkeit

X

Wirksamkeit

261

X X

Wirtschaftlichkeit

X

X

Zuverlässigkeit

X

X

Abb. FORMZ-2: Formalziele für Prozeß- und Produktqualität

• Akzeptanz ist ein Merkmal der Produktqualität; es beschreibt die Eigenschaft eines Informationssystems, die Zustimmungsbereitschaft der durch dieses System Betroffenen (z.B. Benutzer, Mitarbeiter, Kunden, Lieferanten) zu finden. Eine speziellere Sichtweise von Akzeptanz beschreibt die Bereitschaft der zukünftigen Benutzer, das in einer konkreten Anwendungssituation vom Informationssystem angebotene Nutzungspotential zur Unterstützung der Aufgabendurchführung in Anspruch zu nehmen. Primäre Einflußgrößen der Akzeptanz sind Aufgabenbezogenheit und Benutzbarkeit (was z.B. heißt: je größer die Aufgabenbezogenheit, desto größer die Akzeptanz). • Anderbarkeit (auch: Flexibilität) ist ein Merkmal der Produktqualität; es beschreibt die Eigenschaft eines Informationssystems, Veränderungen (Änderungen, Erweiterungen, Reduzierungen) an einzelnen Systemteilen zuzulassen (z.B. bezüglich der Funktionalität), ohne daß die Struktur des Gesamtsystems geändert werden muß. Primäre Einflußgrößen der Änderbarkeit sind Testbarkeit und Modularität (was z.B. heißt: je größer die Modularität, desto größer die Änderbarkeit). • Aufgabenbezogenheit ist ein Merkmal der Produktqualität; es beschreibt die Eigenschaft eines Informationssystems, die vom Aufgabenträger benötigten Funktionen, Leistungen und Schnittstellen zur Verfügung zu stellen. Primäre

262

•

•

•

•

•

•

Aufgaben der Vorstudie

Einflußgröße der Aufgabenbezogenheit ist Wirksamkeit (was z.B. heißt: je größer die Wirksamkeit, desto größer die Aufgabenbezogenheit). Benutzbarkeit ist ein Merkmal der Produktqualität; es beschreibt eine Menge von Eigenschaften, die eine einfache, leicht erlernbare Benutzung des Informationssystems erlauben. Primäre Einflußgrößen der Benutzbarkeit sind Produktivität und Verständlichkeit (was z.B. heißt: je größer die Verständlichkeit, desto größer die Benutzbarkeit). Produktivität als Merkmal der Prozeßqualität beschreibt den mengenmäßigen Verbrauch an Gütern und Dienstleistungen (z.B. Anzahl Mitarbeiterstunden), die für die Systemplanung eingesetzt werden, im Verhältnis zum mengenmäßigen Ergebnis der Systemplanung (z.B. Anzahl programmierter und getesteter Funktionen). Produktivität als Merkmal der Produktqualität beschreibt den mengenmäßigen Verbrauch an Gütern und Dienstleistungen (z.B. Anzahl Prozessorminuten), die für die Systemnutzung eingesetzt werden, im Verhältnis zum mengenmäßigen Ergebnis der Systemnutzung (z.B. Anzahl durchgeführter Transaktionen). In Abhängigkeit von den gewählten Verbrauchs- und Ergebnismengen werden also verschiedene Prozeß- oder Produktphänomene festgelegt, an die Produktivitätsanforderungen gestellt werden. Primäre Einflußgrößen der Produktivität als Prozeßqualität sind Modularität, Personalqualifikation, Verfügbarkeit und Verwendung von Methoden und Werkzeugen und Verständlichkeit (was z.B. heißt: je größer die Verfügbarkeit und Verwendung von Methoden und Werkzeugen, desto höher die Produktivität des Prozesses). Primäre Einflußgrößen der Produktivität als Produktqualität sind Aufgabenbezogenheit, Benutzbarkeit und Sicherheit (was z.B. heißt: je größer die Benutzbarkeit, desto größer die Produktivität des Produkts). Sicherheit ist ein Merkmal der Produktqualität; es beschreibt die Eigenschaft eines Informationssystems, die Entstehung von Gefährdungszuständen vermeiden zu können. Primäre Einflußgrößen der Sicherheit sind Wirksamkeit und Vertraulichkeit (was z.B. heißt: je größer die Vertraulichkeit, desto größer die Sicherheit). Testbarkeit (auch: Prüfbarkeit) ist ein Merkmal der Produktqualität; es beschreibt die Eigenschaft eines Informationssystems, der Überprüfung seiner Funktionen, Leistungen und Schnittstellen leicht (insbesondere mit geringem Aufwand und geringen Kosten) zugänglich zu sein. Primäre Einflußgrößen der Testbarkeit sind Modularität und Verständlichkeit (was z.B. heißt: je größer die Verständlichkeit, desto größer die Testbarkeit). Übertragbarkeit (auch: Portabilität) ist ein Merkmal der Produktqualität; es beschreibt die Eigenschaft eines Informationssystems oder einzelner seiner Komponenten (insbes. die Eigenschaft der Anwendungssoftware), auf einem anderen als dem planmäßig vorgesehenen Verarbeitungssystem produktiv verwendbar zu sein. Primäre Einflußgröße der Übertragbarkeit ist die Offenheit der vorgesehenen Betriebsmittel (was z.B. heißt: je offener die verwendeten Betriebsmittel, desto besser die Übertragbarkeit). Verfügbarkeit ist ein Merkmal der Produktqualität; es beschreibt die durchschnittliche Zeitspanne, in der ein Informationssystem die vorhandenen Funktionen mit den geforderten Leistungen fehlerfrei ausführen kann. Als Meßgröße werden MTBF, MTTF und MTTR verwendet. Primäre Einflußgröße der Verfügbarkeit ist die Sicherheit (was z.B. heißt: je größer die Sicherheit, desto größer die Verfügbarkeit).

FORMZ - Festlegen der Formalziele

263

• Verständlichkeit ist ein Merkmal der Prozeßqualität und der Produktqualität; es beschreibt die Eigenschaft der Dokumentation, den Zweck, die Struktur und die Benutzung des Informationssystems offenlegen zu können. • Wirksamkeit ist ein Merkmal der Produktqualität; es beschreibt die Übereinstimmung zwischen den geplanten und den tatsächlich realisierten Funktionen. • Wirtschaftlichkeit als Merkmal der Prozeßqualität beschreibt den mit Kosten bewerteten Verbrauch an Gütern und Dienstleistungen (z.B. Personalkosten), die für die Systemplanung eingesetzt werden, im Verhältnis zum wertmäßigen Ergebnis der Systemplanung (z.B. Wert der programmierten und getesteten Funktionen). Wirtschaftlichkeit als Merkmal der Produktqualität beschreibt den mit Kosten bewerteten Verbrauch an Gütern und Dienstleistungen (z.B. Prozessorkosten), die für die Systemnutzung eingesetzt werden, im Verhältnis zum wertmäßigen Ergebnis der Systemnutzung (z.B. Wert der durchgeführten Transaktionen). In Abhängigkeit von den gewählten Kosten- und Wertgrößen werden also verschiedene Prozeß- und Produktphänomene festgelegt, an die Wirtschaftlichkeitsanforderungen gestellt werden. Primäre Einflußgröße der Wirtschaftlichkeit ist die Produktivität (was z.B. heißt: je höher die Produktivität, desto größer die Wirtschaftlichkeit). • Zuverlässigkeit als Merkmal der Prozeßqualität beschreibt die Wahrscheinlichkeit der Einhaltung von Leistungs-, Termin- und Kostenzielen bzw. von Produktivitäts- und Wirtschaftlichkeitszielen bei der Systemplanung. Zuverlässigkeit als Merkmal der Produktqualität beschreibt die Wahrscheinlichkeit der Einhaltung aller anderen Formalziele der Systemnutzung. Zielbeziehungen Mit der Nennung von Einflußgrößen bei der Erläuterung der Zielinhalte wurde bereits darauf hingewiesen, daß zwischen den Zielen Beziehungen bestehen ("Zielbeziehungen"). Zielbeziehungen sind idealtypisch betrachtet entweder komplementär oder konfliktär oder indifferent. • Zielkomplementarität: Zwei Ziele Zi und Z2 sind komplementär, wenn mit der Steigerung der Zielerreichung von Z\ die Zielerreichung von Z2 steigt. • Zielkonflikt: Zwei Ziele Zi und Z2 sind konfliktär, wenn mit der Steigerung der Zielerreichung von Z\ die Zielerreichung von Z2 sinkt. • Zielindifferenz: Zwei Ziele Zi und Z2 sind indifferent, wenn mit der Steigerung der Zielerreichung von Z\ die Zielerreichung von Z2 unverändert bleibt. Realtypisch betrachtet verändert sich häufig der Charakter der Zielbeziehungen in Abhängigkeit vom Ausmaß der Zielerreichung. Abbildung FORMZ-3 zeigt am Beispiel der beiden Ziele Produktivität (Zi) und Wirtschaftlichkeit (Z2), wie mit steigender Zielerreichung der Produktivität die zunächst komplementäre Zielbeziehung in eine indifferente Zielbeziehung und schließlich in eine konfliktäre Zielbeziehung übergeht. Abgesehen von dieser grundsätzlichen Erklärung und ähnlichen beispielhaften und leicht nachvollziehbaren Erklärungen ist bislang wenig über die Zielbeziehungen bekannt. Dies erschwert die Aufgabe der Projektplanung, die Zielerreichungsgrade unter Berücksichtigung der tatsächlich vorhandenen Zielbeziehungen realistisch festzulegen.

264

Aufgaben der Vorstudie

Vorgehen beim Festlegen der Formalziele Die zum Festlegen der Formalziele für die Prozeßqualität und für die Produktqualität erforderlichen Tätigkeiten, deren Ergebnis die Spezifikation der Formalziele ist, können wie folgt zu Arbeitsschritten geordnet werden (vgl. Abbildung FORMZ-4):

Festlegen des Zielausmaßes und des zeitlichen Bezugs Ermitteln der Zielbeziehungen

m m m m z m m m

I; Spezifikation Formalziele

Abb. FORMZ-4: Arbeitsschrine beim Festlegen der Formalziele

Erster Arbeitsschritt: Zielinhalte bestimmen. Das Festlegen der Formalziele beginnt damit, aus den vorgegebenen Planungszielen die Art der Anforderungen an die Prozeßqualität und an die Produktqualität abzuleiten, also die

FORMZ - Festlegen der Formalziele

265

Zielinhalte zu bestimmen. Bezüglich der Prozeßqualität ist dies eine Aufgabe des Projektleiters; sie ist im Rahmen der Projektplanung (vgl. Lerneinheit PROPL) zu erledigen. Bezüglich der Produktqualität ist dies eine Aufgabe, die von den Systemplanern gemeinsam mit dem Auftraggeber und den zukünftigen Benutzern durchgeführt wird. • Zweiter Arbeitsschritt: Zielausmaß und zeitlichen Bezug festlegen. Die Anforderungsanalyse umfaßt auch das Festlegen des Zielausmaßes und des zeitlichen Bezugs der Zielerreichung. Die Problematik besteht darin, daß für die meisten Zielinhalte keine meßbaren Zieldimensionen verfügbar sind, sodaß man sich im allgemeinen mit einer verbalen Beschreibung des Zielausmaßes zufrieden geben muß. Dies führt in konkreten Projekten häufig dazu, daß auf die Angabe des Zielausmaßes gänzlich verzichtet wird. Eine verbale Beschreibung gibt jedoch noch immer bessere Anhaltspunkte für die Formulierung des Geforderten und für die Überprüfung des Erreichten, als keine Beschreibung. • Dritter Arbeitsschritt: Zielbeziehungen bestimmen. Durch paarweisen Vergleich aller im ersten Arbeitsschritt bestimmten Zielinhalte mit ihrem im zweiten Arbeitsschritt festgelegten Zielausmaß und mit ihrem zeitlichen Bezug wird soweit wie möglich festgestellt, ob und wenn ja welche Zielbeziehungen bestehen. Werden Zielkonflikte aufgedeckt, muß in den zweiten Arbeitsschritt zurückgekehrt und Anpassungen müssen vorgenommen werden. So kann sich z.B. ergeben, daß das gewünschte (relativ hohe) Ausmaß der Zielerreichung für "Akzeptanz" bei dem zunächst festgelegten (relativ geringen) Ausmaß der Zielerreichung für "Benutzbarkeit" unrealistisch ist. Es muß daher entweder das Anspruchsniveau für Akzeptanz zurückgenommen oder es muß das Anspruchsniveau für Benutzbarkeit erhöht werden. Demonstrationsbeispiel Am Beispiel des Formalziels Zuverlässigkeit und einer Reihe weiterer Ziele werden die Zielbeziehungen gezeigt. In Abbildung FORMZ-5 bedeuten die durchgezogenen Linien (vermutlich, in der Quelle nicht erläutert) starke Zielbeziehungen, die gestrichelten Linien schwache Zielbeziehungen. Die Linien sind mit "+" bezeichnet, wenn sich die mit ihnen verbundenen Ziele "positiv beeinflussen" (also wenn sie komplementär sind); sie sind mit "-" bezeichnet, wenn sich die Ziele "negativ" beeinflussen (also wenn sie konfliktär sind). Nicht bezeichnete Linien bedeuten, daß die Zielbeziehungen indifferent sind. Abbildung FORMZ-5 enthält auch den Funktionsumfang als Sachziel. Dies weist darauf hin, daß nicht nur zwischen den Formalzielen, sondern auch zwischen diesen und bestimmten Sachzielen Zielbeziehungen bestehen, die bei der Anforderungsanalyse nicht unberücksichtigt bleiben dürfen. Forschungsbefunde Heinrich/Sterrer berichten über die Ergebnisse einer Feldstudie mit zwölf Fallstudien in oberösterreichischen Unternehmen und öffentlichen Verwaltungen (Untersuchungszeitraum 1986). Zweck der Studie war es unter anderem festzustellen, welche Formalziele bei IuK-Projekten in der Praxis verfolgt werden, wie ihr Zielinhalt definiert ist, wie die Zielerreichung gemessen wird und welche Zielbeziehungen berücksichtigt werden. Folgende Formalziele wurden

266

Aufgaben der Vorstudie

erhoben: Akzeptanz, Aufgabenbezogenheit, Benutzerorientierung, Integrationsfähigkeit, Koordinationsfähigkeit, Produktivität, Sicherheit, Wirtschaftlichkeit und Zuverlässigkeit. Bezüglich der Messung der Zielerreichung wurden zum Teil zwar brauchbare Vorstellungen geäußert, aber nur selten konnten die Befragten nachvollziehbare Vorgehensweisen angeben. Die Ergebnisse zu den Zielbeziehungen zeigen brauchbare Ansätze zur Entwicklung eines Zielsystems, reichen aber zur Zielplanung in keinem Fall aus. Die Ergebnisse der Studie zeigen auch, daß bezüglich der Sachziele wesentlich konkretere Vorstellungen bestehen als bezüglich der Formalziele. Ersatzkosten

Einsatzdaucr

AAAAA

+

Funktionsumfang

Benutzungskomfort

Effizienz

Zuverlässigkeit

^neutral + i bis i

Entwicklungskosten

Legende: + beeinflußt positiv - beeinflußt negativ

neutral

Änderbarkeit

Portabilität

i_JT

m

Wartungskosten

Abb. FORMZ-5: Beziehungen zwischen Zuverlässigkeit und anderen Zielen (Quelle: Pfadler) Methodenverweise Anforderungsanalyse (Lerneinheit ANFOA). Kontrollfragen 1. 2. 3. 4. 5.

Welchen Zweck hat das Festlegen der Formalziele? Wie können die Formalziele systematisch zerlegt werden? Welche Ziele können zur Beschreibung der Prozeßqualität verwendet werden? Welche Ziele können zur Beschreibung der Produktqualität verwendet werden? Wie kann beim Festlegen der Formalziele vorgegangen werden?

FORMZ - Festlegen der Formalziele

267

Quellenliteratur Heinen, E.: Grundlagen betriebswirtschaftlicher Entscheidungen. Das Zielsystem der Unternehmung. 3. A., Verlag Gabler, Wiesbaden 1976 Heinrich, L. J.: Informationsmanagement - Planung, Überwachung und Steuerung der Informationsinfrastruktur. 4. A., Oldenbourg Verlag, München/Wien 1992, insbes. Lerneinheit SZIEL Heinrich, L. J. und Sterrer, G.: Ziele von Informationssystemen - Ergebnisse einer empirischen Studie. In: Information Management 1/1987,48 - 53 Pfadler, W.: Mitschreitende Leistungskontrolle in EDV-Projekten. In: Molzberger, P. und Schelle, H. (Hrsg.): Software. Moderne Methoden zur Planung, Realisierung und Kontrolle der Entwicklung. Oldenbourg Verlag, München/Wien 1981,205 - 228 Vertiefungsliteratur Roithmayr, F.: Controlling von Informations- und Kommunikationssystemen. Oldenbourg Verlag, München/Wien 1988 Selig, J.: EDV-Management - Eine empirische Untersuchung der Entwicklung von Anwendungssystemen in deutschen Unternehmen. Springer Verlag, Berlin et al. 1986

GRUND - Entwerfen der Grundkonzeption Lernziele Sie kennen den Zweck des Entwerfern der Grundkonzeption ("Entwurfsplanung") und können die Bedeutung der Grundkonzeption für die Systemplanung richtig einschätzen. Sie wissen, in welchen Schritten die Grundkonzeption entworfen wird und können jeden dieser Schritte beschreiben. Sie erkennen, mit welchen Methoden das Entwerfen der Grundkonzeption unterstützt werden kann. Definitionen und Abkürzungen Alternative (alternative) = ein Element der Menge der Handlungsmöglichkeiten eines Entscheidungsträgers, das den Bedingungen der Entscheidungssituation entspricht. Alternativenbewertung (evaluation of alternatives) = die systematische Vorgehensweise zur Beurteilung der Zweckmäßigkeit oder Wünschbarkeit einer Menge von Alternativen auf der Grundlage eines gemeinsamen Zielsystems mit der Absicht, die optimale Alternative zu bestimmen. Aufgabenfunktion (task function) = die Gliederung einer Aufgabe in Anlehnung an den Ablauf des Informations- und Kommunikationsprozesses in Eingabe, Speicherung, Transport, Bearbeitung, Verarbeitung und Ausgabe. Auswirkung (impact) = die betriebswirtschaftlichen, personellen, technischen usw. Folgen der Anwendung eines Systemkonzepts. Beschreibungsmethode (description technique) = eine Anleitung zur Abbildung eines Systems mit seinen wesentlichen Eigenschaften. Durchführbarkeitsstudie (feasibility study) = der Teil der Vorstudie, der sich mit der Ermittlung der Konsequenzen der alternativen Systemkonzepte befaßt. Synonym: Machbarkeitsstudie. Entwerfen (design) = ein System in seinen groben Umrissen mit seinen wichtigsten Merkmalen konstruieren und beschreiben. Merkmal (characteristic) = die Eigenschaft eines Objekts, die es kennzeichnet und von anderen Objekten unterscheidet; die Eigenschaft ist wesentlich, d.h. sie kommt dem Objekt notwendigerweise zu. Planungsziel (planning goal) = ein Ziel, das aus der strategischen Informationssystem-Planung abgeleitet wird und der Systemplanung vorgegeben ist. Rückkopplung (feedback) = ein Prinzip, das einen geschlossenen Wirkungskreislauf herstellt, sodaß der Ausgang eines Systems einen Eingang dieses Systems beeinflußt. Systemkonzept (systems concept) = die umrißartige, grobe Beschreibung eines Informationssystems anhand seiner wichtigsten Merkmale (wie Funktionen, Leistungen, Schnittstellen und Sachmittel). Verfeinerung (refinement) = ein Entwurfsprinzip, das von einer abstrakten Beschreibung des Objektsystems ausgeht und die Abstraktion phasenweise auflöst. Synonym: schrittweise Verfeinerung. Zerlegung (decomposition) = das methodische Zergliedern eines Systems in Teilsysteme. Synonym: Dekomposition.

GRUND - Entwerfen der Grundkonzeption

269

Zweck des Entwerfens der Grundkonzeption Dritte Aufgabe der Vorstudie ist es, alternative Systemkonzepte zu entwerfen und zu bewerten und die Grundkonzeption als optimales Systemkonzept auszuwählen. Das Entwerfen und Bewerten alternativer Systemkonzepte erfolgt unter konsequenter Orientierung an den festgelegten Sachzielen (vgl. Lerneinheit SACHZ) und Formalzielen (vgl. Lerneinheit FORMZ) unter Berücksichtigung grundlegender Bedingungen des Istzustands und sonstiger, dem Projekt vorgegebener Nebenbedingungen (vgl. Lerneinheit ZAMVS). Die Planungsziele artikulieren einen Bedarf an einem Informationssystem; die alternativen Systemkonzepte beschreiben denkbare Wege zur Deckung dieses Bedarfs. Die Planungsziele ermöglichen es, die alternativen Systemkonzepte zu bewerten und damit die Grundkonzeption - also das unter den alternativen Systemkonzepten, welches den artikulierten Bedarf am besten deckt - zu bestimmen. Komplexität und Kompliziertheit der Aufgabe der Systemplanung machen es erforderlich, beim Systementwurf von einer relativ abstrakten Ebene auszugehen und eine mit Rückkopplungen durchsetzte, phasenweise Konkretisierung anzustreben. In diesem Sinn sind die alternativen Systemkonzepte und die Grundkonzeption, von der ausgehend die detaillierte Untersuchung des Istzustands (vgl. Kapitel "Der Prozeß der Feinstudie"), der Systementwurf (vgl. Kapitel "Der Prozeß der Grobprojektierung"), die Systementwicklung (vgl. Kapitel "Der Prozeß der Feinprojektierung") und schließlich die Installierung (vgl. Kapitel "Der Prozeß der Installierung") erfolgen, zu verstehen. Die Reduzierung der Komplexität erfolgt also durch ganzheitliches Planen auf einer abstrakten Ebene (dessen Zwischenergebnisse die alternativen Systemkonzepte sind und dessen Ergebnis in der Vorstudie die Grundkonzeption ist), mit einer anschließenden schrittweisen Verfeinerung bis zur Realisierung durch Analyse, Entwurf, Entwicklung und Installierung der systematisch gebildeten Komponenten dieser Ganzheit. Die Reduzierung der Kompliziertheit erfolgt durch systematisches Zerlegen des durch die Grundkonzeption gegebenen Gesamtsystems in die Teilsysteme Datensystem, Methodensystem, Transportsystem, Arbeitsorganisation und Sicherheitssystem bei der Analyse, beim Entwurf und bei der Entwicklung. Der Grundkonzeption kommt daher eine entscheidende Weichenstellung für den Prozeß der Systemplanung und für das durch die Systemplanung erarbeitete Ergebnis zu. Durch die Planungsziele wird zunächst ein relativ weiter Handlungsspielraum abgegrenzt, in dem die alternativen Systemkonzepte entworfen werden. Durch die alternativen Systemkonzepte wird der Handlungsspielraum verengt, und durch die Auswahl der Grundkonzeption als optimales Systemkonzept wird er weiter eingeschränkt und für die nachfolgenden Planungsphasen, zunächst also für die Feinstudie, festgelegt (vgl. Abbildung GRUND-1). Informationsgehalt der Grundkonzeption Die Grundkonzeption ist die Schnittstelle zwischen der Vorstudie einerseits und der Feinstudie andererseits, sie ist aber auch die Schnittstelle zur Rückkopplung von der Vorstudie zur strategischen Informationssystem-Planung (vgl. Lernein-

270

Aufgaben der Vorstudie

heit ZAMVS). Sie beschreibt als optimales Systemkonzept das zu schaffende Informationssystem anhand seiner wichtigsten Merkmale auf einer abstrakten Ebene möglichst vollständig, läßt aber die Realisierungswege im einzelnen bewußt offen. Da in der Regel in der Vorstudie verschiedene Randbedingungen des Systementwurfs noch nicht bekannt sind, besteht ein hohes Entwicklungsrisiko. Es kann also nie gesagt werden, daß die Grundkonzeption tatsächlich "alle wichtigen Eigenschaften vollständig" beschreibt.

(Quelle: nach Cava/Maymon)

Systemkonzepte und Grundkonzeption sollen sich nicht an bestehenden Grenzen betrieblicher Funktionalbereiche (z.B an Abteilungsgrenzen) orientieren, sondern an den Arbeitsprozessen, sodaß alle Funktions- und Leistungsanforderungen der Aufgaben (vgl. Lerneinheit ANFOA) dieser Prozesse und alle Funktions- und Leistungsmerkmale der in diesen Prozessen verwendeten Sachmittel (vgl. Lerneinheit TECHA) untereinander abgestimmt und integriert sein müssen. Die Generierung alternativer Systemkonzepte bedarf also primär eines Denkens in Zusammenhängen, nicht eines Denkens im Detail. Nachträgliche, grundlegende Änderungen der Funktions- und Leistungsanforderungen und der vorgesehenen Sachmittel sollten möglichst vermieden werden. Eine "Rückkehr" aus späteren Phasen in die Vorstudie soll daher idealerweise nicht möglich sein; sie bedeutet praktisch den Neuaufwurf des gesamten Konzepts, also ein anderes IuK-Projekt. Systemkonzepte und die Grundkonzeption sind nicht "technikfrei"; sie sind keine rein logischen Modelle. Damit begrenzt die Grundkonzeption nicht nur den Handlungsspielraum für den logischen Systementwurf in der Grobprojektierung, sondern sie steckt auch den groben Rahmen ab, in dem die physische Realisierung erfolgen soll. Die Frage, wie detailliert die Systemeigenschaften entworfen und in der Grundkonzeption beschrieben sein sollen, ist nur situationsabhängig zu beantworten. Manche Systemplaner neigen dazu, sehr viel Entwicklungsarbeit "vorwegzunehmen" und schon in der Vorstudie in die Tiefe zu gehen. Da die meisten Systemkonzepte verworfen werden und nur eines als Grundkonzeption weiter verfolgt wird, werden durch dieses Verhalten Planungsressourcen vergeudet.

GRUND - Entwerfen

der Grundkonzeption

271

Eine pragmatische Vorgehensweise geht dort mehr ins Detail, wo wenig Erfahrungswissen vorhanden ist, und geht dort weniger ins Detail, w o bereits viel Erfahrungswissen vorhanden ist. Innovative IuK-Projekte verlangen daher mehr Detailarbeit in der Vorstudie. Zuviel Planungsarbeit im Detail ist in der Vorstudie auch deshalb zu vermeiden, weil sie den Blick auf das Grundsätzliche, hier auf die alternativen Systemkonzepte, verstellt. Eine Richtzahl von fünf bis sieben Systemkonzepten hat sich als zweckmäßig erwiesen. In diesem Zusammenhang muß auch auf die Benutzerbeteiligung hingewiesen werden, die wegen der durch die Grundkonzeption bewirkten Weichenstellung im Projekt von zentraler Bedeutung ist (vgl. Lerneinheit AUTER und Lerneinheit BEBET im Band "Informationsmanagement"). Planungsziele

Informationsgewinnung

Generierung und Beschreibung von Lösungsalternativen

J Alternativenbewertung und -auswahl

Grundkonzeption

Abb. GRUND-2: Arbeitsablauf beim Entwerfen der Grundkonzeption

Arbeitsschritte beim Entwerfen der Grundkonzeption Aus dem bisher Gesagten lassen sich die einzelnen Arbeitsschritte ableiten, die beim Entwerfen der Grundkonzeption durchzuführen sind (vgl. Abbildung GRUND-2); die Arbeitsschritte werden nachfolgend erläutert:

272

Aufgaben der Vorstudie

• Erster Arbeitsschritt: Informationsgewinnung zur Präzisierung des Bedarfs an Systemplanung und der Möglichkeit der Bedarfsdeckung. • Zweiter Arbeitsschritt: Generierung und Beschreibung von alternativen Systemkonzepten zur Deckung des definierten Bedarfs. • Dritter Arbeitsschritt: Ermittlung der Auswirkungen der alternativen Systemkonzepte in bezug auf die Planungsziele. • Vierter Arbeitsschritt: Alternativenbewertung und Auswahl der optimalen Alternative, also das Bestimmen der Grundkonzeption.

rÄnfördei^gen'der Aufgaben||§ und Aufgabenträger ANFOA / S / / S / , S S / , / S S ,

Informationsgewinnung für das Entwerfen der Grundkonzeption

Merkmale der Techniksysteme TECHA .

Abb. GRUND-3: Informationsgewinnung beim Entwerfen der Grundkonzeption

Informationsgewinnung Mit dem ersten Arbeitsschritt werden die Informationen ermittelt, welche den Bedarf an Systemplanung bezüglich der Sachziele und der Formalziele präzisieren (Anforderungen der Aufgaben und Aufgabenträger) und welche die Möglichkeiten der Bedarfsdeckung durch den Einsatz von Techniksystemen angeben (Merkmale der Techniksysteme). Dies zeigt Abbildung GRUND-3. Als Methoden zur Unterstützung dieser Aufgabe werden die Anforderungsanalyse (vgl. Lerneinheit ANFOA) und die Technikanalyse (vgl. Lerneinheit TECHA) verwendet.

GRUND - Entwerfen der Grundkonzeption

273

Generierung von alternativen Systemkonzepten Ausgehend von den im ersten Arbeitsschritt ermittelten Informationen, werden im zweiten Arbeitsschritt alternative Systemkonzepte, die in geeigneter Weise zu beschreiben sind, generiert. Jedes generierte Systemkonzept muß den Bedarf an Systemplanung erfüllen, also den Planungszielen (Sachzielen und Formalzielen) genügen. Die Systemkonzepte sind aus der Sicht der Planungsziele zulässige Alternativen. Beim Generieren der Alternativen handelt es sich um einen kreativen Prozeß, der durch die Anwendung von Kreativitätstechniken methodisch unterstützt wird (vgl. Lerneinheit KREAT). Bevor Kreativitätstechniken angewendet werden können, ist festzulegen, welches die "wichtigen Merkmale" eines Informationssystems sind und wie das Informationssystem so in Entwurfsobjekte zerlegt werden kann, daß eine aussagefähige, das heißt für den nächsten Arbeitsschritt brauchbare Beschreibung der generierten Systemkonzepte möglich ist. Für jedes der festgelegten Merkmale ist für jedes Entwurfsobjekt eine Entwurfsentscheidung erforderlich. Da Ausgangspunkt eines Systementwurfs die mit den Sachzielen beschriebenen betrieblichen Aufgaben sind, stellen diese Aufgaben die Entwurfsobjekte dar. Die gewählte Aufgabengliederung (z.B. grobe Gliederung nach Aufgabentypen oder feine Gliederung nach den Tätigkeiten der Aufgaben) ist primär vom Aufgabenumfang des Projekts, der den Aufwand für die Generierung und die Beschreibung der alternativen Systemkonzepte maßgeblich bestimmt, abhängig; bei kleinen Projekten kann eine feinere Aufgabengliederung verwendet werden als bei großen Projekten. Unabhängig davon, wie die Aufgabengliederung erfolgt, kann jedes Entwurfsobjekt weiter in Aufgabenfunktionen zerlegt werden. Von diesen Überlegungen ausgehend, können für jedes Entwurfsobjekt die Entwurfsentscheidungen und die Beschreibung der alternativen Systemkonzepte, unter Verwendung verschiedener entwurfsunterstützender Beschreibungsmethoden, erfolgen. Dazu gehören z.B. HIPO (vgl. Lerneinheit HIPO), SADT (vgl. Lerneinheit SADT) und Petri-Netze (vgl. Lerneinheit PENET). Ermittlung der Auswirkungen Die im zweiten Arbeitsschritt generierten und beschriebenen alternativen Systemkonzepte führen insgesamt, aber nicht notwendigerweise bezüglich jeder Entwurfsdimension, zu verschiedenartigen Veränderungen der Aufgabenfunktionen, das heißt der formalen, inhaltlichen, zeitlichen und räumlichen Transformation von Informationen (als Daten, Text, Bild oder Sprache). Es wird also durch die Generierung von alternativen Systemkonzepten eine Menge von neuen, zumindest von veränderten Kombinationen von Funktionen entworfen. Diese wirken sich vermutlich auch in unterschiedlicher Weise auf die Strukturelemente und auf die Prozesse einer Organisation aus, die zu erfassen bzw. zu prognostizieren und so zu ordnen sind, daß sie für die nachfolgende Alternativenbewertung und -auswahl zugänglich sind. Unter der Annahme, daß die Planungsziele in ihrer Gesamtheit als Zielsystem alle Aussagen der Entscheidungsträger über den anzustrebenden Zustand des Informationssystems enthalten, können die Zielinhalte Ausgangspunkt für die

274

Aufgaben der Vorstudie

Konsequenzanalyse sein. Folglich ist je Planungsziel und für jedes alternative Systemkonzept der Zielertrag zu erfassen bzw. zu prognostizieren. Zur methodischen Unterstützung des dritten Arbeitsschritts dient die Konsequenzanalyse (vgl. Lerneinheit KONSA), in deren Rahmen weitere Methoden, wie die Wertanalyse (vgl. Lerneinheit WERTA) und die Wirtschaftlichkeitsanalyse (vgl. Lerneinheit WIRTA), angewendet werden. Alternativenbewertung und

Alternativenauswahl

Nachdem die Alternativen, die Ziele und die Zielerträge ermittelt wurden, sind im vierten Arbeitsschritt die Ziele zu gewichten, die Zielerträge in Zielwerte zu überführen (Skalierung) und eine geeignete Entscheidungsregel zur Wertsynthese auszuwählen und anzuwenden. Damit wird eine optimale Alternative bestimmt, die als Grundkonzeption in den folgenden Phasen der Systemplanung verwendet wird. Zur methodischen Unterstützung wird die Nutzwertanalyse (vgl. Lerneinheit NUTZW) angewendet. Forschungsbefunde H. Krcmar gibt eine umfassende Aufarbeitung der Diskussion um die Gestaltung von Systementwürfen, die durch eine deutliche Benutzerorientierung ("Computer-am-Arbeitsplatz-Systeme") gekennzeichnet sind. Dabei wird vor allem untersucht, welche alternativen Systemkonzepte bestehen und welche "Gestaltungsinstrumente" (das sind Instrumente zur Generierung und Beschreibung von alternativen Systemkonzepten) es gibt, und es wird ein auf CAPSIM aufbauendes Gestaltungsinstrument entwickelt. Die bei der Einführung von CAP-Systemen verfolgten Ziele, die Modellierung der Konsequenzen in Erklärungs- und Wirkungsmodellen und die Gestaltungsmöglichkeiten für CAP-Systeme werden behandelt. Die Anwendung des entwickelten Gestaltungsinstruments wird an einem Beispiel aus der Kraftfahrzeug-Zulieferindustrie demonstriert. Methoden verweise Anforderungsanalyse (Lerneinheit ANFOA); Technikanalyse (Lerneinheit TECHA); Kreativitätstechniken (Lerneinheit KREAT); HIPO (Lerneinheit HIPO); SADT (Lerneinheit SADT); PetriNetze (Lerneinheit PENET); Konsequenzanalyse (Lerneinheit KONSA); Wertanalyse (Lerneinheit WERTA); Wirtschaftlichkeitsanalyse (Lerneinheit WIRTA); Nutzwertanalyse (Lerneinheit NUTZW). Kontrollfragen I. 2. 3. 4. 5.

Welcher Zweck wird mit dem Entwerfen der Grundkonzeption verfolgt? Wie kann der Informationsgehalt der Grundkonzeption beschrieben werden? Welche Arbeitsschritte sind beim Entwerfen der Grundkonzeption zu durchlaufen? Mit welchen Methoden können die Arbeitsschritte unterstützt werden? Welche Struktur hat die Entwurfsmatrix?

Quellenliteratur Cave, W. C. and Maymon, G. W.: Leitfaden des Software-Projektmanagements. Forkel Verlag, Wiesbaden 1988 Krcmar, H.: Gestaltung von Computer-am-Arbeitsplatz-Systemen - Entwicklung von Alternativen und deren Bewertung durch Simulation. Minerva Publikationen, München 1984

PROPL - Durchführen der Projektplanung Lernziele Sie kennen den Zweck der Projektplanung und können daraus die Aufgaben, die beim Planen eines IuK-Projekts zu bearbeiten sind, ableiten und erläutern. Sie kennen alternative Strategien der Projektplanung. Sie erkennen den Zusammenhang zwischen Projektplanung und Projektüberwachung und -Steuerung. Definitionen und Abkürzungen Produktmanager (product manager) = ein Aufgabenträger für die Aufgabe der Betreuung eines IuK-Systems über dessen gesamten Lebenszyklus hinweg. Projekt (project) = ein zielgerichtetes, klar definiertes, zeitlich begrenztes, durch Größe, Bedeutung, Komplexität, Neuartigkeit, Einmaligkeit, Kosten und Risiko aus dem üblichen Geschehen herausragendes Vorhaben. Projektgruppe (project team) = die für ein Projekt eingesetzten Personen, die von einem Projektleiter geführt werden. Synonym: Projektteam. Projekthandbuch (project manual) = ein Dokument mit den unternehmensweit einheitlichen, für sämtliche Projekte geltenden Vorgaben für die Durchführung eines Projekts. Projektkoordinator (project coordinator) = Bezeichnung für den Projektleiter bei der Stabs-Projektorganisation. Synonym: Projektverfolger. Projektleiter (project manager) = ein Aufgabenträger für die Aufgabe, ein Projekt zu planen, zu überwachen und zu steuern mit dem Ziel, das Projekt in der geplanten Zeit erfolgreich durchzuführen. Projektmanagement (project management) = die zusammenfassende Bezeichnung für alle Aufgaben der Projektorganisation sowie der Projektplanung, -Überwachung und -Steuerung und die Bezeichnung für die Personengruppe, welche diese Aufgaben durchführt. Projektorganisation (project Organization) = die Art und Weise, in der ein Projektleiter eine Projektgruppe führt und die projektbezogenen Aufgaben beeinflussen kann. Projektplanung (project scheduling) = die vorausschauende Festlegung der Projektziele und der Projektanforderungen auf der Grundlage der Planungsziele für ein Projekt. Projektsteuerung (project Controlling) = die Maßnahmen und Eingriffe in einem Projekt, die auf Grund der Ergebnisse der Projektüberwachung zur Erreichung der Projektziele erforderlich sind. Projektüberwachung (project monitoring) = das Beobachten des Projektverlaufs bezüglich der Erreichung der Projektziele und das Feststellen von Abweichungen des Projektverlaufs von den Projektzielen. Stab (staff) = eine Struktureinheit zur spezialisierten Unterstützung von Struktureinheiten in der Linie. Synonym: Stabsstelle. Projektziel (project goal) = ein Ziel, das aus den Planungszielen abgeleitet und zur Planung, Überwachung und Steuerung eines Projekts verwendet wird.

276

Aufgaben der

Vorstudie

Zweck der Projektplanung Vierte Aufgabe der Vorstudie ist es, die mit Hilfe der Anforderungsanalyse (vgl. Lerneinheit ANFOA) aus den Planungszielen abgeleiteten Sachziele (vgl. Lerneinheit SACHZ) und Formalziele (vgl. Lerneinheit FORMZ) in Projektziele umzusetzen sowie die Realisierbarkeit der Grundkonzeption (vgl. Lerneinheit GRUND) und damit der Planungsziele zu prüfen. Bei der Prüfung der Realisierbarkeit der Planungsziele geht es in erster Linie um die Herausarbeitung der personellen, technischen, zeitlichen und finanziellen Ressourcen des Projekts ("Projektanforderungen"), die zur Erreichung der Planungsziele erforderlich sind. Das Durchführen der Projektplanung ist Aufgabe des Projektleiters, soweit nicht durch die Nebenbedingungen der Planungsziele (vgl. Lerneinheit ZAMVS) oder durch generelle Regelungen der strategischen Informationssystem-Planung (vgl. Lerneinheit PROMA im Band "Informationsmanagement") Projektvorgaben bestehen (z.B. die Vorgabe einer bestimmten Projektorganisation). Aufgabenträger für die Projektvorgaben ist im allgemeinen ein Lenkungsausschuß; er bestimmt auch für jedes gestartete Projekt den Projektleiter. Ist ein Lenkungsausschuß vorhanden, dann ist - in Abhängigkeit von der Projektorganisation - zu klären, ob der Projektleiter dem Lenkungsausschuß nur bezüglich der Projektmanagement-Aufgaben, oder auch bezüglich der projektbezogenen fachlichen Aufgaben sowie auch disziplinarisch unterstellt ist. Unabhängig von der Projektorganisation ist zumindest eine Unterstellung bezüglich der Projektmanagement-Aufgaben anzunehmen; insoweit besteht also seitens des Projektleiters Berichtspflicht an den Lenkungsausschuß. Sind mehrere IuK-Projekte offen, hat der Lenkungsausschuß auch die Funktion des Multi-Projektmanagements. Aufgabe des Lenkungsausschusses ist es auch, für jedes IuK-Projekt über die Zweckmäßigkeit der Benennung eines Produktmanagers (vgl. Lerneinheit AUTER) zu entscheiden und diesen zu benennen. Aufgaben der Projektplanung Aus dem Zweck der Projektplanung lassen sich ihre Aufgaben, die an den einzelnen Planungsobjekten eines IuK-Projekts orientiert sind, ableiten und die Projekt-Teilplanungen benennen; dies sind (vgl. Abbildung PROPL-1): • • • • • • • • • •

Festlegen der Projektorganisation ("Organisationsplanung"); Bilden der Projektgruppe ("Personalplanung"); Ableiten der Projektziele ("Zielplanung"); Bestimmen der Projektaufgaben ("Aufgabenplanung"); Ermitteln der Zeitbedarfe für die Projektaufgaben ("Zeitplanung"); Zuordnen von Projektaufgaben auf Aufgabenträger ("Personaleinsatzplanung"); Ermitteln von Zwischen- und Endterminen für die wichtigsten Tätigkeiten ("Terminplanung"); Festlegen der Methoden, Techniken und Werkzeuge und aller sonstigen Hilfsmittel ("Sachmittelplanung"); Ermitteln der Sachkosten und der Personalkosten ("Kostenplanung"); Festlegen der im Notfall zu ergreifenden Maßnahmen ("Notfallplanung");

PROPL - Durchfahren der Projektplanung

277

• sonstige Planungsobjekte wie Tests ("Testplanung"), Projektberichterstattung ("Berichtsplanung") und Projektdokumentation ("Dokumentationsplanung", vgl. Lerneinheit DOKUM).

Abb. PROPL-1: Planungsobjekte und Projekt-Teilplanungen (Überblick)

Im folgenden werden für jede dieser Teilplanungen kurze Erläuterungen gegeben. Daraus kann die Komplexität der Aufgabe "Projektplanung", die sich weniger aus den einzelnen Teilaufgaben als vielmehr aus der Vernetzung der Teilaufgaben untereinander ergibt, erkannt werden. Ohne Verwendung geeigneter Methoden und Werkzeuge (vgl. Lerneinheit PROME) kann diese Aufgabe daher nicht bewältigt werden. Organisationsplanung: Mit der Organisationsplanung wird die Form der Projektorganisation festgelegt: Stabs-Projektorganisation, reine Projektorganisation, Matrix-Projektorganisation oder Projektorganisation in Verbindung mit Linienfunktionen. • Bei der Stabs-Projektorganisation (auch als Projektorganisation mit Stäben bezeichnet) verfolgt der Projektleiter den Projektablauf, koordiniert die Tätigkeiten der Projektmitarbeiter (die ihm nicht unterstellt sind), bereitet Entscheidungen vor und berichtet an die für das Projekt verantwortlichen Linieninstanzen. Der Projektleiter wird auf Grund dieser Kompetenzen auch als Projektkoordinator oder Projektverfolger bezeichnet. Er kann für die Erreichung bzw. Nichterreichung der Projektziele nicht verantwortlich gemacht werden. • Bei der reinen Projektorganisation (auch als unabhängige Projektorganisation bezeichnet) werden die Projektmitarbeiter zu einer eigenen organisatorischen Einheit unter dem Projektleiter zusammengefaßt. Der Projektleiter trägt

278

Alfgaben der Vorstudie

die volle Verantwortung für die Erreichung bzw. Nichterreichung der Projektziele. • Die Matrix-Projektorganisation ist eine Kombination der Stabs-Projektorganisation und der reinen Projektorganisation. Der Projektleiter ist für die Projektplanung, -Überwachung und -Steuerung verantwortlich ("Vorgehensverantwortung"); für die projektbezogenen fachlichen Aufgaben sind die Linienvorgesetzten der Projektmitarbeiter verantwortlich. Personelle Entscheidungen werden in der Regel vom Projektleiter und dem Linienvorgesetzten gemeinsam getroffen. • Bei der Projektorganisation in Verbindung mit Linienfunktionen sind die Aufgaben des Linienvorgesetzten und des Projektleiters in einer Person vereinigt, nämlich in der des Linienvorgesetzten. Der Projektleiter trägt die volle Verantwortung für die Erreichung bzw. Nichterreichung der Projektziele. Personalplanung: Mit der Personalplanung werden die nach Anzahl und Qualifikation für die Projektdurchführung erforderlichen Mitarbeiter ("Personalbedarf") bestimmt und zur Projektgruppe zusammengefaßt (wegen Einzelheiten zur Projektgruppe vgl. Lerneinheit AUTER). Ein wesentlicher Einflußfaktor für die Ermittlung des Personalbedarfs ist die Entscheidung darüber, welche Projektaufgaben mit eigenen Mitarbeitern und welche Projektaufgaben durch externe Aufgabenträger (Berater, Softwarehäuser, Systemhäuser) durchgeführt werden ("Eigenfertigung oder Fremdbezug", vgl. Lerneinheit BTECH). Der Personalbedarf wird auch maßgeblich durch die Form der Projektorganisation, durch die zeitlichen Planungsziele und durch die zur Unterstützung der Aufgabendurchführung zur Verfügung stehenden Sachmittel bestimmt. Zielplanung: Mit der Zielplanung werden alle für die Überwachung und Steuerung des Projekts erforderlichen Zielinhalte (insbesondere Leistungsziele, Terminziele und Kostenziele) festgelegt. Der Entscheidungsspielraum für die Zielplanung ist durch die Planungsziele vorgegeben, denn alles, was die Planungsziele inhaltlich vorgeben, muß durch die Projektziele abgedeckt sein. Mit der Zielplanung werden die Planungsziele in Projektziele überführt, und zwar im Ergebnis so, daß sie zur Planung, Überwachung und Steuerung des Projekts geeignet sind. Die Vorgaben für das angestrebte Ausmaß und den zeitlichen Bezug der Zielerreichung werden - je nach Zielinhalt des Projektziels - durch die Aufgabenplanung, die Terminplanung und die Kostenplanung festgelegt. Aufgabenplanung: Mit der Aufgabenplanung wird die Gesamtaufgabe des Projekts systematisch in Teilaufgaben zerlegt; die Teilaufgaben werden gegebenenfalls weiter in Tätigkeiten gegliedert ("Aufgabenanalyse"). Dabei ist besonders darauf zu achten, daß die Teilaufgaben bzw. Tätigkeiten so präzise beschrieben werden, daß jeder Projektmitarbeiter aus der Beschreibung erkennen kann, was zu tun ist. Zeitplanung: Mit der Zeitplanung wird für jede Teilaufgabe bzw. Tätigkeit der für ihre Durchführung erforderliche Zeitbedarf ermittelt. Dabei sind der Umfang und der Schwierigkeitsgrad der Teilaufgabe bzw. Tätigkeit, die zur Unterstützung zur Verfügung stehenden Sachmittel (vor allem die verfügbaren Werkzeuge) sowie die Fähigkeiten und Fertigkeiten der für die Durchführung der Teilaufgabe bzw. Tätigkeit vorgesehenen Projektmitarbeiter zu berücksichtigen.

PROPL - Durchfahren der Projektplanung

279

Personaleinsatzplanung: Die durch die Aufgabenanalyse ermittelten Teilaufgaben bzw. Tätigkeiten werden unter Berücksichtigung der Fähigkeiten und Fertigkeiten der Aufgabenträger sowie des für die Aufgabendurchführung erforderlichen Zeitbedarfs zusammengefaßt ("Aufgabensynthese") und den Projektmitarbeitern zugeordnet. Terminplanung: Mit der Terminplanung werden für die wichtigsten Teilaufgaben bzw. Tätigkeiten Zwischen- und Endtermine ("Meilensteine") festgelegt. Die Terminplanung orientiert sich an dem Fertigstellungstermin des Projekts, der durch die Planungsziele vorgegeben ist. Fertigstellungstermin ist der Termin, zu dem das Informationssystem für den produktiven Einsatz zur Verfügung steht. Sachmittelplanung: Mit der Sachmittelplanung werden die zur Unterstützung der Aufgabendurchführung erforderlichen Methoden, Techniken, Werkzeuge und sonstigen Hilfsmittel (z.B. Rechner, Räume und Organisationsmittel) festgelegt, soweit sie auf Grund anderer Teilplanungen (z.B. der Kostenplanung) überhaupt verfügbar gemacht werden können. Kostenplanung: Mit der Kostenplanung werden die kostenmäßigen Konsequenzen aller bisher genannten Planungsbereiche, insbesondere die Personalkosten und die Sachmittelkosten, ermittelt. Ist der Projektplanung ein Budget vorgegeben, dann muß das Ergebnis der Kostenplanung mit dem Budget ins Gleichgewicht gebracht werden; bei Budgetüberschreitungen folgen daraus notwendige Anpassungen bei den Teilplanungen, welche Termin- und Leistungsziele betreffen. In diesem Fall sind die Kostenziele die unabhängige Planungsvariable, die Termin- und Leistungsziele die abhängigen Planungsvariablen. Sind die Terminund/oder die Leistungsziele die unabhängige(n) Planungsvariable(n), ergibt sich das Budget aus der Kostenplanung; die Kostenplanung ist dann die abhängige Planungsvariable. Notfallplanung: Mit der Notfallplanung werden Maßnahmen bestimmt, die für den Fall, daß das Projekt "notleidend" wird, ohne nennenswerte Verzögerung ergriffen werden können. Dazu ist festzulegen, unter welchen Umständen das Projekt den Status "notleidend" erreicht hat. Im allgemeinen ist dies dann der Fall, wenn die Erreichung von Kostenzielen oder von Zeitzielen drastisch überschritten oder die Erreichung von Leistungszielen drastisch unterschritten wird. Die Feststellung des Status "notleidend" ist eine Aufgabe der Projektüberwachung und -Steuerung. Die Entscheidung über den Status "notleidend" steht in der Regel nicht dem Projektleiter zu; sie fällt in die Kompetenz des Lenkungsausschusses. Bei größeren Projekten fehlen zum Zeitpunkt der ersten Projektplanung in der Vorstudie ausreichend genaue Informationen über alle Projektanforderungen. Bei der Projektplanung wird daher so vorgegangen, daß zunächst für das Gesamtprojekt nur eine Grobplanung und lediglich für die unmittelbar bevorstehenden Teilprojekte (z.B. für die nächste Phase der Systemplanung) eine detaillierte Planung durchgeführt wird. Daraus folgt, daß die Planung mit dem Projektfortschritt kontinuierlich verfeinert werden muß (also z.B. während der Phase n für die Phase n+1).

280

Aufgaben der Vorstudie

Realisierungsstrategien Bei der Projektplanung muß der Projektleiter festlegen, in welcher Reihenfolge die Aufgaben durchgeführt werden, soweit die Reihenfolge nicht durch den logischen Ablauf der Aufgabendurchführung gegeben ist. Dies kann nach einer der folgenden Strategien erfolgen: Hardest-first-Strategie oder Easiest-first-Strategie. • Die Hardest-first-Strategie geht davon aus, daß jene Aufgaben (Komponenten des Systems) als erste bearbeitet werden, welche die größten Schwierigkeiten bei der Realisierung verursachen. Diese Strategie wird vor allem dann angewendet, wenn die produktive Verwendbarkeit des Gesamtsystems ohne die Lösung dieser Aufgaben nicht gegeben ist. • Die Easiest-first-Strategie geht davon aus, daß zunächst die Aufgaben (Komponenten des Systems) bearbeitet werden, die ohne große Probleme sind und daher sehr schnell abgearbeitet werden können. Diese Strategie bietet sich an, wenn gewährleistet werden soll, daß möglichst viele Teile des Systems in einer begrenzten Zeit realisiert werden sollen. Es wird damit vermieden, daß für schwierige, aber nicht wesentliche Aufgaben zu viel Zeit aufgewendet wird, sodaß bei Projektende für einfach zu realisierende und wesentliche Aufgaben keine Zeit übrig bleibt. Projektüberwachung und Projektsteuerung Zweck der Projektüberwachung und der Projektsteuerung ist es nicht, nachträglich "Schuldige" für Mängel in der Projektdurchführung zu finden oder eine "planmäßige" Projektdurchführung nachträglich zu bestätigen. Sie soll vielmehr während der Projektdurchführung und möglichst schon in ihren Ansätzen Abweichungen von den Projektzielen erkennen und notfalls korrigierende Maßnahmen einleiten. Daraus ergeben sich folgende Aufgaben der Projektüberwachung und -Steuerung: • Beobachten des Projektverlaufs bezüglich der Erreichung der Projektziele; • Feststellen von Abweichungen des Projektverlaufs von den Projektzielen; • Ergreifen von Maßnahmen zur Erreichung der Projektziele, wenn die tatsächlichen von den geplanten Zielerreichungen negativ abweichen. Wichtigste Hilfsmittel der Projektüberwachung sind daher die Projektpläne als Ergebnis der Projekt-Teilplanungen (z.B. der Personalplan als Ergebnis der Personalplanung, der Kostenplan als Ergebnis der Kostenplanung) und die Fortschrittsberichte als Ergebnis der Projektberichterstattung. Forschungsbefunde L. J. Heinrich berichtet Uber empirische Befunde zur Frage, warum Projekte der Systemplanung scheitern oder notleidend werden, d.h. ihre Kosten-, Terminund/oder Leistungsziele nicht erreichen (Untersuchungszeitraum 1986 bis 1987). Folgende Befunde bezüglich der Projektplanung wurden durch Befragung von Seminarteilnehmern, die mit Moderationstechnik unterstützt wurde, ermittelt (wegen weiterer Befunde zu den Aufgabenträgem vgl. Lerneinheit AUTER):

PROPL - Durchführen der Projektplanung

• • • • • •

281

Planungsziele nicht oder nicht klar genug definiert; mangelhafte Projektorganisation; einseitige Kosten- und Terminorientierung (fehlende Leistungsziele); keine systematische Projektüberwachung; unzureichende Projektressourcen; häufige Änderung der Planungs- und Projektziele.

Mit einer 1987 durchgeführten Untersuchung eines großen Projekts wurden folgende Befunde erhoben: • Vernachlässigung der Organisationsentwicklung zugunsten der Software-Entwicklung; • Verwendung ungeeigneter Methoden und Werkzeuge; • nicht valide, wenn überhaupt vorhandene Qualitätsziele. Die häufigsten Nennungen beider Untersuchungen konzentrieren sich auf die Ursachen: unklare oder unvollständige Planungsziele, häufige Änderung der Planungsziele und Mängel in der Projektorganisation. Im Ergebnis zeigen beide Untersuchungen, daß mangelhafte Planung die Ursache von Projektrisiken ist. Meist sind die Planungsmängel auf Defizite in der Anwendung des Planungsinstrumentariums (Methodik, Methoden und Werkzeuge), nicht auf Defizite in der Verfügbarkeit des Planungsinstrumentariums zurückzuführen. Diese Befunde zeigen die Notwendigkeit einer besseren Ausbildung für alle an einem Projekt der Systemplanung Beteiligten (Management, Projektleiter, Projektmitarbeiter und Benutzer). Methodenverweise Methoden des Projektmanagements (Lerneinheit PROME); Netzplantechnik (Lerneinheit NETZP); Darstellungsmethoden (Lerneinheit DARST). Kontrollfragen 1. 2. 3. 4. 5.

Welchem Zweck dient die Projektplanung; welche Aufgaben leiten sich daraus ab? Welche Rolle spielt der Lenkungsausschuß bei der Projektplanung? Wie wird bei der Projektplanung darauf Rücksicht genommen, daß ein Projekt "notleidend" werden kann? Welcher Zusammenhang besteht zwischen Termin-, Kosten- und Leistungszielen? Welche Aufgaben hat die Projektüberwachung und -Steuerung?

Quellenliteratur Hansel, J. und Lomnitz, G.: Projektleiter-Praxis - Erfolgreiche Projektabwicklung durch verbesserte Kommunikation und Kooperation. Springer Verlag, Berlin et al. 1987 Heinrich, L. J.: Schwachstellen und Risiken bei Softwareprojekten. In: Computer und Recht 7/1988, 584 - 587 Platz, J. und Schmelzer, H. J.: Projektmanagement in der industriellen Forschung und Entwicklung - Einführung anhand von Beispielen aus der Informationstechnik. Springer Verlag, Berlin et al. 1986

282

Aufgaben der Vorstudie

Vertiefungsliteratur Cave, W. C. und Maymon, G. W.: Leitfaden des Software-Projektmanagements. Forkel Verlag, Wiesbaden 1988 Hofstetter, H.: Organisationspsychologische Aspekte der Software-Entwicklung. In: Schelle, H. und Molzberger, P.: Psychologische Aspekte der Software-Entwicklung. Oldenbourg Verlag, München/Wien 1983, 25 - 62

ANFOA - Anforderungsanalyse Lernziele Sie kennen den Zweck der Anforderungsanalyse und können eine Vorgehensweise bei der Anforderungsanalyse angeben. Sie können, ausgehend von einer geeigneten Gliederung der Anforderungen, die Quellen für das Erheben der Anforderungen nennen. Sie wissen, welche Methoden für das Erheben, das Beschreiben und das Verifizieren der Anforderungen zur Verfügung stehen. Sie kennen eine Gliederung für das Ergebnisdokument der Anforderungsanalyse. Definitionen und Abkürzungen Abstraktion (abstraction) = die wichtigen Aspekte von den unwichtigen Aspekten trennen und nur die wichtigen betrachten. Beschreibungsmethode (description technique) = ein Hilfsmittel zur Abbildung der Eigenschaften eines Systems mit einem bestimmten Grad der Formalisierung und mit einer bestimmten Art der Darstellung. Synonym: Beschreibung smittel. Beschreibungsregel (description rule) = eine Vorschrift zur Abbildung von Anforderungen mit einem bestimmten Beschreibungsmittel. Informationsbedarf (information requirement) = die für eine Aufgabe zur Aufgabenerfüllung erforderliche Information. Informationsbedürfnis (information need) = die von einem Aufgabenträger zur Aufgabenerfüllung für erforderlich gehaltene Information. Informationsnachfrage (information demand) = die Vereinigungsmenge von Informationsbedarf und Informationsbedürfnis. Informationsverhalten (information behavior) = das auf Information gerichtete Tun oder Unterlassen von Menschen; ein Einflußfaktor, der das Informationsbedürfnis bestimmt. Organisationsziel (organizational goal) = ein Ziel, dessen Zielinhalt die Organisation als Ganzes betrifft. Projektion (projection) = das Beschreiben eines Systems aus unterschiedlichen Sichten, von denen jede das Gesamtsystem mit einer Teilmenge seiner Eigenschaften abbildet. Qualitätssicherung (quality assurance) = alle planmäßigen Maßnahmen, die sicherstellen, daß definierte Systemeigenschaften durch die Planungsergebnisse erreicht werden. Spezifizieren (specification) = die Tätigkeit des Erhebens und Dokumentierens von Anforderungen. Strukturierbarkeit (structuring ability) = die Möglichkeit der vollständigen, systematischen Beschreibung und Zerlegung einer Aufgabe in Teilaufgaben und der eindeutigen Zuordnung von Methoden auf die Teilaufgaben. Validierung (validation) = die Überprüfung eines Systems gegen die im Ergebnisdokument der Anforderungsanalyse definierten Anforderungen. Verifizierung (verification) = das Prüfen von definierten Anforderungen auf Vollständigkeit und Widerspruchsfreiheit. Synonym: Verifikation.

284

Methoden und Techniken der Vorstudie

Zweck der Anforderungsanalyse Mit der Anforderungsanalyse ("Requirements Engineering") werden das Festlegen der Sachziele (vgl. Lerneinheit SACHZ) und das Festlegen der Formalziele (vgl. Lerneinheit FORMZ), also der Anforderungen an das zu schaffende IuKSystem, methodisch unterstützt. Ziel der Anforderungsanalyse ist es, die Voraussetzungen für die Validierung des zu schaffenden Systems herzustellen. Die Methoden der Anforderungsanalyse sollen die im Arbeitsprozeß der Systemplanung involvierten Gruppen (vgl. Lerneinheit AUTER) hinsichtlich der Ermittlung, der Änderung und der Verwendung der Anforderungen unterstützen, insbesondere: • Unterstützung des Auftraggebers/der Benutzer bei der Ermittlung der Anforderungen; • Unterstützung der Auftragnehmer/Systemplaner durch eine für den Einsatz in den einzelnen Planungsschritten geeignete Aufbereitung (Formulieren, Klassifizieren und Hierarchisieren); • Unterstützung der Kommunikation zwischen Auftraggeber/Benutzern und Auftragnehmer/Systemplanern; • Unterstützung der Qualitätssicherung, insbesondere bei der Validierung des Systems. Zur Erreichung dieser Ziele ist es erforderlich, einen letztlich vollständigen, konsistenten und verständlichen Anforderungskatalog während des Arbeitsprozesses zu gewährleisten. Im Idealfall sollten die Anforderungen daher quantifizierbar und leicht verifizierbar sein. Bedeutung der Anforderungsanalyse Die Bedeutung der Anforderungsanalyse ergibt sich insbesondere aus folgenden Tatsachen: • Die Anforderungen an ein neues Produkt sind zunächst immer vage, unvollständig und widersprüchlich. • Anhand der Anforderungen werden grundlegende Entwurfsentscheidungen in der Form alternativer Systemkonzepte (vgl. Lerneinheit GRUND) gefällt, von denen ausgehend die Grundkonzeption festgelegt wird. Mängel bei der Anforderungsanalyse (z.B. fehlende Funktionen) können in späteren Phasen der Systemplanung nur mit großem Aufwand behoben werden. Dies kann zu einem völligen "Neuaufwurf" führen, insbesondere dann, wenn das IuKSystem nicht ausreichend modular aufgebaut ist. Fehler beim Festlegen der Anforderungen werden erfahrungsgemäß weitgehend vermieden, wenn die folgenden Hinweise beachtet werden: • Es sollte ausreichend Zeit zur Verfügung stehen und jede nur mögliche Sorgfalt aufgewendet werden. • Wo irgend möglich, sollte das Erheben der Anforderungen methodisch unterstützt werden.

ANFOA • Anforderungsanalyse

285

• Die erhobenen Anforderungen sollten in einer verständlichen Form dokumentiert werden. • Die dokumentierten Anforderungen sollten systematisch überprüft werden. Methoden der Anforderungsanalyse Bei der Auswahl geeigneter Methoden der Anforderungsanalyse ist von folgenden Tatsachen auszugehen: • Es gibt keine Methoden, die speziell für das Erheben der Anforderungen geeignet sind. • Soweit allgemeinere Methoden für die Anforderungsanalyse angewendet werden können, eignen sie sich primär für das Festlegen der Sachziele und weniger für das Festlegen der Formalziele. Eine sehr allgemeine, für die Anforderungsanalyse aber brauchbare methodische Orientierung kann mit den Begriffen Abstraktion, Zerlegung und Projektion gegeben werden. Das heißt, daß sich die Anforderungsanalyse grundsätzlich der Abstraktion, Zerlegung und Projektion bedienen sollte. Für die Beantwortung der Frage, welche Methoden darüber hinaus für die Sachzielplanung geeignet sind, ist folgende Gliederung der Anforderungen zweckmäßig: • aufgabenbezogene, objektive Anforderungen ("Aufgabenanforderungen") und aufgabenträgerbezogene, subjektive Anforderungen ("Aufgabenträgeranforderungen" oder "Benutzeranforderungen"); • Funktionsanforderungen, Leistlingsanforderungen und Schnittstellenanforderungen (vgl. Lerneinheit SACHZ). Mit Hilfe dieser Gliederung werden die "Quellen" der Anforderungen offengelegt, und es ist möglich, die Methoden der Anforderungsanalyse an ihnen auszurichten. Es ist daher nicht sinnvoll, "Benutzeranforderungen" als Synonym für "Anforderungen" zu verwenden, denn Benutzer sind nur eine der möglichen Quellen der Anforderungen. Die Unterscheidung in Aufgabenanforderungen und Aufgabenträgeranforderungen ist darüber hinaus dann von Bedeutung, wenn das zu schaffende IuK-System neue oder wesentlich veränderte betriebliche Aufgaben unterstützen soll; für diese Aufgaben gibt es (noch) keine Aufgabenträger, die als Quellen für das Erheben der Anforderungen in Frage kommen. In diesem Zusammenhang muß auch bedacht werden, daß sich die Benutzer mit dem steigenden Niveau der IuK-Systeme gegenüber den Systemplanern eher angebotsorientiert ("Was kann Besseres geboten werden?") als nachfrageorientiert ("Was brauche ich?") verhalten. Es sollte daher Aufgabe der Systemplaner sein, Anforderungen für innovative Anwendungen in den Arbeitsprozeß einzubringen bzw. kooperativ mit den zukünftigen Aufgabenträgern festzulegen, wobei die Systemplaner eine Leitfunktion übernehmen sollten. Diese Leitfunktion können sie nur dann ausfüllen, wenn sie über gute Kenntnisse über die dem IuKProjekt vorgegebenen betrieblichen Aufgaben verfügen (was erfahrungsgemäß nur selten der Fall ist).

286

Methoden und Techniken der Vorstudie

Quellen der Anforderungen Quellen der Anforderungen sind die betrieblichen Aufgaben in Form der bestehenden, aber insbesondere in Form der geplanten Arbeitsorganisation und die Aufgabenträger in ihrer Rolle als Auftraggeber und in ihrer Rolle als Benutzer des zu schaffenden IuK-Systems. Die bestehende Arbeitsorganisation ("Istzustand") hat als Quelle der Anforderungen eine geringere Bedeutung als die Vorstellungen, die über die geplante Arbeitsorganisation bestehen, die mit den Planungszielen dokumentiert sind und die sich zunächst in der Grundkonzeption wiederfinden ("Sollkonzept"). Für die Anforderungsanalyse sind daher solche Methoden kaum geeignet, die sich mit der Beobachtung des Istzustands ("Beobachtungsmethode") oder gar mit der Untersuchung von Dokumenten, mit denen der Istzustand beschrieben ist ("Dokumenteanalyse"), befassen. Derartige Methoden sind mit der Sollzustandsorientierung der Vorstudie (vgl. Lerneinheit ZAMSP) nicht vereinbar. Für das Erheben der Aufgabenanforderungen sind Methoden erforderlich, die sich an den Zielen der Organisation ("Organisationsziele") orientieren und von daher "top-down" und systematisch bis zu den Anforderungen der Aufgaben führen. Eine Methode, die diesen Forderungen genügt, ist die Aufgabenanalyse (wegen Einzelheiten siehe weiter unten). Die Auftraggeber haben ihre Anforderungen bereits mit den Planungszielen global definiert. Diese Anforderungen bedürfen der Präzisierung und Abstimmung. Dabei stehen bestimmte Qualitätsziele (z.B. Wirtschaftlichkeit) sowie wichtige Funktionsanforderungen (also das, was das System unbedingt leisten soll) im Vordergrund des Interesses. Die Qualitätsziele und Funktionsanforderungen sind meist die Auslöser für den Bedarf an einem neuen oder einem grundlegend veränderten IuK-System. Da die Auftraggeber in der Regel mit den zukünftigen Benutzern nicht identisch sind, und da die Vorstellungen der Auftraggeber mit denen der zukünftigen Benutzer nicht immer übereinstimmen, sind auch die zukünftigen Benutzer eine wichtige Quelle für das Erheben der Anforderungen. Dabei stehen die Funktionsanforderungen und die Leistungsanforderungen sowie bestimmte Qualitätsziele (z.B. Benutzbarkeit) im Vordergrund des Interesses. Benutzerbeteiligung muß daher bereits in der Vorstudie einsetzen (wegen Einzelheiten vgl. Lerneinheit BEBET im Band "Informationsmanagement"). Schließlich sind auch die Systemplaner eine Quelle der Anforderungen, insbesondere für die Schnittstellenanforderungen. Beispielsweise können Systemplaner für das Ermitteln der Funktionsanforderungen und der Leistungsanforderungen nur eine beratende und unterstützende Rolle spielen, da ihnen in der Regel ausreichende Kenntnisse über die betrieblichen Aufgaben fehlen. Auftraggeber und Benutzer können beispielsweise zur Definition der Schnittstellenanforderungen kaum beitragen. Trotz dieser einschränkenden Aussage über die Rolle der Systemplaner beim Ermitteln der Funktions- und Leistungsanforderungen gilt als Ziel, daß sie möglichst viel Sachverstand über die zu unterstützenden betrieblichen Aufgaben in das Projekt einbringen sollten.

ANFOA - Anforderungsanalyse

287

Quellen der Q u a l i t ä t s a n f o r d e r u n g e n sind Auftraggeber, Benutzer und Systemplaner. Anforderungen an die Prozeßqualität und Wartungsanforderungen werden primär von den Systemplanern, Nutzungsanforderungen werden primär von den Benutzern und Rahmenanforderungen primär von den Auftraggebern oder von den Benutzern artikuliert. So sind z.B. die Auftraggeber für die Artikulierung der Rahmenanforderung "Innovationsgrad" und die Benutzer für die Artikulierung der Rahmenanforderung "Integrationsgrad" primär zuständig. Abbildung ANFOA-1 zeigt die Quellen der Anforderungen in dem Sinn, welche Aufgabenträger primär für das Erheben welcher Anforderungen fachlich zuständig und daher in den Arbeitsprozeß der Anforderungsanalyse einzubeziehen sind.

Auftraggeber

X

Benutzer

X

Systemplaner

Rahmenanforderungen

Wartungsanforderungen

Nutzungsanforderungen

Prozeßqualität

Formalziele

Schnittstellenanforderungen

Leistungsanforderungen

Funktionsanforderungen

Sachziele

X X

X X

X

X X

Abb. ANFOA-1: Quellen der Anforderungen

Ausgangspunkt der Anforderungsanalyse Ausgangspunkt der Anforderungsanalyse ist die I n f o r m a t i o n s n a c h f r a g e als "objektiver" Informationsbedarf der Aufgaben bzw. als "subjektives" Informationsbedürfnis der Aufgabenträger, soweit sie sich nicht bereits eindeutig aus der Beschreibung der Planungsziele ergibt (was nur bei kleinen, auf spezifische Bedarfe ausgerichteten Projekten der Systemplanung der Fall ist). Der Informationsnachfrage soll durch Schaffung oder Veränderung eines Informationssystems letztlich ein entsprechendes Informationsangebot gegenübergestellt werden ("Informationsgleichgewicht"). Zwischen dem I n f o r m a t i o n s b e d a r f und dem I n f o r m a t i o n s b e d ü r f n i s können folgende alternative Beziehungen bestehen: • der Informationsbedarf ist kleiner als das Informationsbedürfnis; • der Informationsbedarf und das Informationsbedürfnis sind identisch; • der Informationsbedarf ist größer als das Informationsbedürfnis. Abbildung ANFOA-2 veranschaulicht die Beziehungen zwischen Informationsbedarf und Informationsbedürfnis. Wenn der Informationsbedarf kleiner als das Informationsbedürfnis ist (Abbildung ANFOA-2 rechter Teil), besteht beim Aufgabenträger eine über den Informationsbedarf hinausgehende Informationsnachfrage, die sich aus seinem Informationsverhalten (Arbeits- und Entscheidungs-

288

Methoden und Techniken der Vorstudie

verhalten) ergibt. Die Befriedigung der über den Informationsbedarf hinausgehenden Anforderungen spielt insbesondere für die Erreichung von Formalzielen (wie z.B. Akzeptanz und Benutzbarkeit) eine Rolle. Wenn der Informationsbedarf größer als das Informationsbedürfnis ist (Abbildung ANFOA-2 linker Teil), besteht beim Aufgabenträger eine unter dem Informationsbedarf liegende Informationsnachfrage, die sich aus der nicht aufgabengerechten Qualifikation des Aufgabenträgers ergibt. In diesem Fall sind Qualifizierungsmaßnahmen erforderlich, um das Nachfragedefizit auszugleichen. Die für das Erheben der Anforderungen verwendeten Methoden müssen in beiden Fällen sowohl die Erfassung der Aufgabenanforderungen als auch die Erfassung der Benutzeranforderungen unterstützen.

Abb. ANFOA-2: Informationsbedarf und Informationsbedürfnis

Vorgehensweise bei der Anforderungsanalyse Eine systematische Vorgehensweise bei der Anforderungsanalyse umfaßt unter formalen Gesichtspunkten die drei in Abbildung ANFOA-3 genannten Phasen. Methodische Aspekte der Anforderungsanalyse beziehen sich auf alle drei Phasen der Vorgehensweise. Die Phasen werden sequentiell durchlaufen, jedoch meist in mehreren Iterationen verfeinert. Dadurch entstehen, wie im Phasenmodell, Rückkopplungen, die eine zyklische Anforderungsanalyse ermöglichen. Da sich Anforderungen während des Arbeitsprozesses verändern, neue hinzukommen und bereits formulierte nicht aufrechterhalten werden können, ist eine wesentliche Forderung an die Anforderungsanalyse die Möglichkeit zur leichten Änderung des Anforderungskatalogs. • Erste Phase: Planen der Anforderungsanalyse. In dieser Phase werden die Termine, Zeiten, Kosten, Aufgabenträger, Methoden und Werkzeuge usw., die zur Durchführung der Anforderungsanalyse eingesetzt werden sollen, festgelegt. Diese Phase ist Gegenstand der Aufgabe "Projektplanung" (vgl. Lerneinheit PROPL) und interessiert im vorliegenden Zusammenhang deshalb, weil es bei der Projektplanung auch um die Planung des Methodeneinsatzes geht. • Zweite Phase: Durchführen der Anforderungsanalyse. In dieser Phase werden die Anforderungen erhoben und beschrieben (formuliert, klassifiziert, hierarchisiert). Diese Phase ist Gegenstand der Aufgabe "Sachzielplanung" (vgl. Lerneinheit SACHZ) und der Aufgabe "Formalzielplanung" (vgl. Lerneinheit FORMZ) und interessiert im vorliegenden Zusammenhang deshalb,

ANFOA - Anforderungsanalyse

289

weil es auch um den Methodeneinsatz zum Erheben und Dokumentieren der Anforderungen geht. • Dritte Phase: Verifizieren der Ergebnisse der Anforderungsanalyse. In dieser Phase werden die erhobenen und dokumentierten Anforderungen auf Übereinstimmung mit einer Reihe formaler und sachlicher Eigenschaften (wie Vollständigkeit und Widerspruchsfreiheit) geprüft. Diese Phase ist Gegenstand der Aufgaben "Sachzielplanung", "Formalzielplanung" und "Projektplanung". Sie interessiert im vorliegenden Zusammenhang deshalb, weil es hier auch um den Methodeneinsatz zum Prüfen der Anforderungen geht.

Methoden zum Erheben der Anforderungen Beim Erheben der Anforderungen sollte nach dem Grundsatz "erst Sachziele, dann Formalziele erheben" vorgegangen werden. Beim Erheben der Sachziele sollte nach dem Grundsatz "erst Funktionsanforderungen, dann Leistungsanforderungen, dann Schnittstellenanforderungen erheben" vorgegangen werden. Die R a h m e n a n f o r d e r u n g e n sollten parallel mit den anderen Anforderungen erhoben werden. Beim Erheben der Funktionsanforderungen kann alternativ nach den Ansätzen "datenorientiertes Erheben" und "methodenorientiertes Erheben" vorgegangen werden.

290

Methoden

und Techniken der

Vorstudie

• Datenorientiertes Erheben heißt, daß zunächst die Daten festgelegt und davon ausgehend die Funktionen und Methoden, welche diese Daten verwenden, erhoben werden. • Methodenorientiertes Erheben heißt, daß zunächst die Methoden festgelegt und davon ausgehend die Funktionen und Daten, welche diese Methoden verwenden, erhoben werden. Voraussetzung in beiden Fällen ist, daß die Funktionen bekannt sind. Von den Funktionen ausgehend, werden die Daten und Methoden erhoben, die zur Funktionserfüllung erforderlich sind. Entsprechend der Unterscheidung der Anforderungen in Aufgabenanforderungen und Aufgabenträgeranforderungen (Benutzeranforderungen) können folgende Methodenhinweise für das Erheben der Anforderungen gegeben werden: Für das Erheben der A u f g a b e n a n f o r d e r u n g e n wird von den Aufgaben, die durch die Planungsziele des Projekts gegeben sind, ausgegangen. Durch systematisches Top-down-Zerlegen der Aufgaben werden die Funktionen ermittelt und daraus die Daten und Methoden abgeleitet, die zur Aufgabenerfüllung erforderlich sind. Mit Hilfe der Aufgabenanalyse wird also auch der Informationsbedarf ermittelt, soweit es sich um gut strukturierbare Aufgaben (oder Aufgabenteile) handelt, weil in diesem Fall der Informationsbedarf durch die Merkmale der Aufgabe gegeben ist. Bei schlecht strukturierbaren Aufgaben (oder Aufgabenteilen) müssen die Funktionen und damit die Daten und Methoden als Anforderungen, die nach Expertenauffassung zur Erfüllung dieser Aufgaben erforderlich sind, festgelegt werden; eine systematische Ableitung durch die Aufgabenanalyse ist nicht möglich. Rückschlüsse auf das Informationsbedürfnis können auch aus allgemeinen Kenntnissen über das Informationsverhalten gezogen werden, das primär durch Persönlichkeitsfaktoren (wie z.B. persönliche Kenntnisse, Fähigkeiten und Fertigkeiten) und durch situative Faktoren (wie z.B. Gruppenverhalten und Arbeitsplatzbedingungen) bestimmt wird. Die Schwierigkeit der Bestimmung des Informationsbedürfnisses weist auf die Zweckmäßigkeit hin, sich von aufgabenspezifischen Anforderungen durch den Einsatz technologische Hilfsmittel möglichst freizuhalten, wie dies bezüglich einfacher Methoden mit Hilfe einer Abfragesprache heute möglich ist. Für das Erheben von A u f g a b e n t r ä g e r a n f o r d e r u n g e n werden zunächst die Aufgabenträger, welchen die durch die Planungsziele beschriebenen Aufgaben zugeordnet sind, festgestellt. Diese Zuordnung ergibt sich aus dem Organigramm und aus den Stellenbeschreibungen. In der Regel sind die Aufgabenträger, die beim Erheben der Anforderungen mitwirken sollen, aus einem größeren Kreis von Aufgabenträgern auszuwählen, wenn die Anzahl der Aufgabenträger eine vollständige Beteiligung nicht erlaubt oder wenn mehrere Aufgabenträger gleiche oder ähnliche Aufgaben durchführen. Aufgabenträgeranforderungen werden durch Befragung der Aufgabenträger erhoben ("Befragungsmethode"). Bei der Befragung kann datenorientiert oder methodenorientiert vorgegangen werden. Mit dem Erheben der Aufgabenträgeranforderungen wird auch das I n f o r mationsbedürfnis festgestellt. Auf die Ermittlung der Informationsnachfrage abzielende Vorgehensweisen sind bei den Aufgaben nicht erforderlich, für die ein Systemzwang besteht. In bezug auf Aufgaben mit Systemzwang gibt es keine Willensentscheidungen der Auf-

ANFOA - Anforderungsanalyse

291

gabenträger, weil sie einen aufgaben- und verfahrensimmanenten Informationsbedarf haben, der durch einen allgemein akzeptierten (z.B. durch Handelsbrauch) oder durch einen von außen (z.B. durch den Gesetzgeber) vorgegebenen Informationsbedarf gekennzeichnet ist. Beispiele sind die Durchführung einer Inventur, einer Nettolohn-Abrechnung, einer Bilanzerstellung, einer Fakturierung und einer Gutschriftenerteilung. Mit zunehmender Formalisierung der Aufgaben (vgl. Lerneinheit WAORG) nimmt der Anteil der Aufgaben mit Systemzwang zu und der Arbeitsumfang der Anforderungsanalyse bezüglich der gut strukturierbaren Aufgaben ab. Unabhängig davon, um welche Art von Anforderung es sich handelt, hat das Prototyping (vgl. Lerneinheit PROTY), insbesondere das explorative Prototyping, eine große methodische Bedeutung für das Erheben der Anforderungen. Mit explorativem Prototyping wird das Problem und seine grundsätzliche Lösung gesucht. Ausgehend von ersten Vorstellungen des Auftraggebers werden Anforderungen erkundet, wobei alternative Systemkonzepte zur Auswahl stehen sollten. Dies ist genau der Zweck der Vorstudie, sodaß sich deren Absichten und die Ausrichtung des explorativen Prototypings gut miteinander vereinbaren lassen. Probleme der Anwendung des Prototypings ergeben sich aus der Tatsache, daß es sehr schwierig ist, Systemkonzepte in irgendeiner Weise "anfaßbar" oder "benutzbar" zu machen. Dafür am besten geeignet ist die Simulation (vgl. Lerneinheit SIMUL). Methoden zum Dokumentieren der Anforderungen Die Dokumentation der Anforderungen soll einer Reihe inhaltlicher und formaler Kriterien genügen (vgl. Lerneinheit SACHZ); insbesondere soll sie eine für den Entwurf alternativer Systemkonzepte geeignete Struktur aufweisen. Die Dokumentation soll durch Verwendung von Methoden und Techniken ("Beschreibungsmethode") sowie möglichst durch Werkzeuge unterstützt werden. Die Beschreibungsmethoden sollen eine "geeignete" Formalisierung und Darstellungsart ermöglichen. Was bezüglich der Formalisierung geeignet ist, ist noch unbeantwortet. Jedenfalls scheint weder eine vollkommen informale (natürlich-sprachliche, frei formulierbare), noch eine vollkommen formale (etwa rein mathematische) Beschreibung sinnvoll, sondern eher eine durch Regeln formalisierte Beschreibung mit der Möglichkeit der informalen Ergänzung (semiformale Beschreibung). Es ist zweckmäßig, den Grad der Formalisierung und die Art der Darstellung auch an den Einstellungen derer auszurichten, welche die Beschreibung durchführen. Ein Benutzer wird eine verbale, natürlich-sprachliche Beschreibung, ein mathematisch geschulter Systemplaner formale Sprachkonstrukte und grafische Darstellungen bevorzugen. Im einfachsten Fall werden die Anforderungen im Anforderungskatalog verbalsprachlich formuliert, klassifiziert und hierarchisiert. Diese Form der Beschreibung wird dann durch grafisch orientierte Beschreibungsmethoden ergänzt. Dafür kommen grundsätzlich alle entwurfsunterstützenden Methoden wie HIPO (vgl. Lerneinheit HIPO), SADT (vgl. Lerneinheit SADT), Datenflußdiagramme (vgl. Lerneinheit DAFLU) und Petri-Netze (vgl. Lerneinheit PENET) in Frage. Für die Beschreibung der Methodenanforderungen eignet sich besonders die Ent-

292

Methoden

und Techniken der

Vorstudie

scheidungstabellen-Technik (vgl. Lerneinheit ENTAB). Mit der Matrixanalyse (vgl. Lerneinheit MATRX) können Zusammenhänge zwischen Funktionsanforderungen, Datenanforderungen und Methodenanforderungen dokumentiert werden (z.B. welche Methoden welche Daten verwenden oder erzeugen). Bei der Anwendung dieser Beschreibungsmethoden ist darauf zu achten, daß sie entsprechend dem Ziel der Vorstudie (vgl. Lerneinheit ZAMVS) keine detaillierte Beschreibung verlangen. In der Literatur werden zahlreiche Beschreibungsmethoden angegeben; keine davon kann voll befriedigen. Kriterien für die Bewertung und Auswahl alternativer Beschreibungsmethoden sind: • leichte Erlernbarkeit und Anwendbarkeit; • vertrauter, mit den zu dokumentierenden Aufgaben identischer Sprachvorrat; • präzise Beschreibbarkeit durch exakte Festlegung der Syntax und der Semantik; • Erweiterbarkeit auf konzeptioneller Ebene. Die erstellten Dokumente sollen folgende Eigenschaften haben: • für alle Betroffenen verständlich sein; • auf Vollständigkeit und Widerspruchsfreiheit überprüft werden können; • Hilfen für den Entwurf alternativer Systemkonzepte und für die Auswahl der Grundkonzeption bieten; • als Grundlage fiir die der Vorstudie folgenden Planungsphasen verwendbar sein; • klar aussagen, was das Produkt in welcher Qualität tun soll. Für die Beschreibung der Anforderungen empfiehlt sich eine Systematisierung in unbedingt notwendige Anforderungen ("Mußanforderungen") und in wünschenswerte Anforderungen ("Wunschanforderungen"). Auf Wunschanforderungen kann gegebenenfalls verzichtet werden (z.B. wenn sich bei der Konsequenzanalyse herausstellt, daß diese nur mit einem nicht vertretbaren Aufwand realisiert werden können, oder wenn das Projekt notleidend wird). Außerdem sollte bei der Beschreibung darauf geachtet werden, daß die Zusammenhänge zwischen den Anforderungen sichtbar werden. Für die Beschreibung der Q u a l i t ä t s a n f o r d e r u n g e n stehen keine Beschreibungsmethoden zur Verfügung. Hier muß man sich auf eine verbale Beschreibung beschränken, die jedoch Aussagen zu allen Zieldimensionen enthalten muß, also zum Zielinhalt, zum angestrebten Ausmaß der Zielerreichung und zum zeitlichen Bezug. Ergänzend ist die Visualisierung der Qualitätsanforderungen (z.B. mit einem Kiviath-Graph, vgl. Lerneinheit DARST) möglich. Methoden zum Verifizieren der Anforderungen Beim Verifizieren der Anforderungen wird die Beschreibung zunächst auf formale, dann auf sachliche Fehler hin untersucht. Ein formaler Fehler liegt vor, wenn vorgegebene Beschreibungsregeln nicht eingehalten werden. Ein sachlicher Fehler liegt vor, wenn die Beschreibung der Anforderungen die real be-

ANFOA • Anforderungsanalyse

293

stehenden Anforderungen nicht korrekt abbildet. Es ist offensichtlich, daß das sachliche Prüfen außerordentlich schwierig ist und - im Gegensatz zum formalen Prüfen - kaum unterstützt werden kann. Immerhin wird die Wirksamkeit der Prüfung entscheidend durch das verwendete Beschreibungsmittel geprägt, vor allem dadurch, ob es werkzeuggestützt ist oder nicht. Praktisch bewährt hat sich die Form des Reviews, die durch den organisatorischen Ablauf des Reviews und die an der Prüfung Beteiligten klar definiert ist. Folgende Kriterien sollten beim Prüfen der Anforderungen besonders beachtet werden: • • • • •

Identifizierbarkeit und Verständlichkeit, Vollständigkeit und Konsistenz, Modifizierbarkeit/Änderbarkeit, Eindeutigkeit/Nachvollziehbarkeit, Durchführbarkeit/Realisierbarkeit.

Gliederung der Dokumentation Folgende Gliederung des Ergebnisdokuments der Anforderungsanalyse, dessen Kern der Anforderungskatalog ist, wird empfohlen: • Einführung: Sie beschreibt, warum ein Bedarf an einem neuen oder wesentlich veränderten IuK-System besteht, und nennt seine Hauptfunktionen. • Systemumgebung: In diesem Kapitel wird beschrieben, wie sich das geplante IuK-System in die bestehende Systemlandschaft einfügt; das System wird anhand eines Modells mit seinen Beziehungen zur Systemumgebung dargestellt. • Voraussetzungen: In diesem Kapitel werden die grundsätzlichen Annahmen, von denen bei der Systemplanung ausgegangen wurde, festgehalten. Es wird dokumentiert, wie sich diese Annahmen voraussichtlich entwickeln werden und welche Auswirkungen dies auf das zu schaffende IuK-System haben würde. • Anforderungskatalog: Hier erfolgt die verbalsprachliche Beschreibung der Anforderungen (z.B. nach der in Lerneinheiten SACHZ und FORMZ verwendeten Systematik) und in Ergänzung eine grafische Beschreibung des Gesamtsystems und seiner wichtigsten Komponenten. • Glossar: Alle Fachbegriffe, die in der Dokumentation verwendet werden, sind hier erläutert. • Quellen: Es werden Personen, die an der Entstehung und Veränderung der Dokumentation beteiligt waren bzw. sind, genannt. • Index: Die Dokumentation wird mit einem Index abgeschlossen. Demonstrationsbeispiel A. Kolb beschreibt ein W e r k z e u g für die Anforderungsanalyse, das für ein größeres Projekt auf der Basis eines relationalen Datenbanksystems entwickelt wurde, weil auf dem Software-Markt kein geeignetes Produkt gefunden werden konnte. Es werden der Aufbau der Datenbank anhand des Datenmodells (vgl. Abbildung ANFOA-4) und die Anforderungen an die Objekttypen REQUIREMENT, ABSCHNITT-ÄNDERUNG, KATALOG und ERFÜLLT-IN gezeigt.

294

Methoden und Techniken der Vorstudie

• Anforderungen an den Objekttyp REQUIREMENT sind: Eindeutige Identifizierung der Anforderung einschließlich der Möglichkeit zur Herstellung des hierarchischen Bezugs zu anderen Anforderungen; Vergabe eines Stichworts (Titel) für jede Anforderung; Vergabe eines Kennzeichens zur Klassifikation; Vergabe eines zusätzlichen Bearbeitungsvermerks (z.B. "noch abzuklären"). • Anforderungen an den Objekttyp ABSCHNITT-ÄNDERUNG sind: Herstellung des eindeutigen Bezugs der Anforderung zu einzelnen Dokumenten (z.B. Vertragsdokumente, Protokolle) einschließlich der vollständigen Änderungsgeschichte. • Anforderungen an den Objekttyp KATALOG sind: Enthält den zu einer Anforderung in der Phase der Formulierung zwischen Auftraggeber und Auftragnehmer abgestimmten Text. • Anforderungen an den Objekttyp ERFÜLLT-IN sind: Überwachung der Erfüllung bzw. des Bearbeitungszustands jeder Anforderung anhand der Referenz in den Dokumenten.

Erfahrungen mit der Anwendung des Werkzeugs in zwei Projekten haben gezeigt, daß es die Erfassung und Änderung der Anforderungen, die Durchführung von Analysen und Abfragen sowie die Generierung von Berichten unterstützen konnte; die formale Konsistenz der Anforderungen konnte sichergestellt werden. Forschungsbefunde 0. Strohm berichtet als Ergebnis empirischer Untersuchungen (Fragebogenmethode und Dokumenteanalyse, Untersuchungszeitraum nicht angegeben, vermutlich 1989, N = 74), daß Methoden zur Ermittlung und Analyse der Anforderungen in der Praxis kaum eingesetzt werden. Formale Methoden, die sich vorwiegend an Datenflüssen orientieren (z.B. Datenflußdiagramme) herrschen vor (61%). Aufgaben- und benutzemahe Methoden (wie z.B. Interview, Beobachtung, Arbeits- und Aufgabenbeschreibungen aus Benutzersicht), die sich stär-

ANFOA - Anforderungsanalyse

295

ker an der betrieblichen Aufgabe und der Arbeitsorganisation orientieren, werden viel seltener eingesetzt (19%). In 20% der untersuchten Projekte wurden "kein Methodeneinsatz" festgestellt. Aufgabenverweise Festlegen der Sachziele (Lerneinheit SACHZ); Festlegen der Formalziele (Lerneinheit FORMZ); Entwerfen der Grundkonzeption (Lerneinheit GRUND). Kontrollfragen 1. 2. 3. 4. 5.

Welcher Zweck wird mit der Anforderungsanalyse verfolgt? Welche Quellen sind für das Erheben der Anforderungen von Bedeutung? Mit welchen Arbeitsschritten kann bei der Anforderungsanalyse vorgegangen werden? Welche Methoden können zum Erheben der Anforderungen verwendet werden? Wie kann die Methodensituation, die bezüglich des Dokumentierens und des Verifizierens der Anforderungen besteht, gekennzeichnet werden?

Quellenliteratur Balzert, H.: Die Entwicklung von Software-Systemen. Bibliographisches Institut, Mannheim et al. 1982 Berthel, J.: Informationsbedarf. In: Frese, E. et al. (Hrsg.): Handwörterbuch der Organisation. 3. A„ Poeschel Verlag, Stuttgart 1992, 872 - 886 Kolb, A.: Ein pragmatischer Ansatz zum Requirements Engineering. In: Informatik Spektrum 6 / 1 9 9 2 , 3 1 5 - 322 Mittermeier, R.: Requirements Engineering. In: Kurbel, K. und Strunz, H. (Hrsg.): Handbuch Wirtschaftsinformatik. Verlag Poeschel, Stuttgart 1990, 237 - 256 Strohm, O.: Projektmanagement bei der Software-Entwicklung. Eine arbeitspsychologische Analyse und Bestandsaufnahme. In: Ackermann, D. und Ulich, E. (Hrsg.): Software-Ergonomie '91. Benutzerorientierte Software-Entwicklung. Verlag Teubner, Stuttgart 1991,47 - 58 Vertiefungsliteratur Partsch, H.: Requirements Engineering. Oldenbourg Verlag, München/Wien 1991 Tan, M.: Using Communication Theory for Systems Design: A Model for Eliciting Information Requirements. In: Avison, D. et al. (Ed.): Human, Organizational, and Social Dimensions of Information Systems Development. Elsevier Science Publishers, North-Holland et al. 1993 Timm, M.: Ein systematisches Vorgehensmodell zur Spezifizierung der Benutzeranforderungen. In: Angewandte Informatik 4/ 1985, 145 - 151

TECHA - Technikanalyse Lernziele Sie kennen den Zweck der Technikanalyse und ihre Bedeutung für die Vorstudie. Sie kennen eine Vorgehensweise zur Durchführung der Technikanalyse und können Techniksysteme durch ihre Eigenschaften beschreiben. Sie können mit eigenen Worten die Situation bezüglich der methodischen Unterstützung der Technikanalyse wiedergeben. Definitionen und Abkürzungen Anforderungsspezifikation (requirements specification) = die Abbildung der durch die Anforderungsanalyse erhobenen Anforderungen der Aufgaben und Aufgabenträger in ein formales Modell. Synonym: Anforderungskatalog. Ausschreibung (call for tender) = der Vorgang des Einholens von Angeboten für Techniksysteme (Hardware, Software und Dienstleistungen). Domäne (domain) = die durch die Funktion(en) im Informations- und Kommunikationsprozeß und durch die Informationsart(en) gekennzeichneten Eigenschaften eines Techniksystems, die für die Anwendung des Techniksystems üblich oder sogar typisch sind. Durchdringung (penetration) = das Ausmaß, in dem die Aufgaben der Organisation durch Techniksysteme unterstützt werden (z.B. die Art und Anzahl der vorhandenen Informationssysteme). Ergonomie (ergonomics) = eine Interdisziplin, deren Ziel die Anpassung der Arbeitsorganisation (insbesondere der Sachmittel) an die Eigenschaften und Bedürfnisse der menschlichen Aufgabenträger ist. Groupware (groupware) = ein in Anlehnung an Hardware und Software 1982 erstmals von P. Johnson-Lenz und T. Johnson-Lenz geprägter Begriff, der mit "Software für die Gruppe" oder "Software für Gruppenarbeit" übersetzt werden kann (was allerdings nicht gebräuchlich ist). Leistung (Performance) = eine Aussage über die Eigenschaft eines Techniksystems in quantitativer und/oder qualitativer Hinsicht. Leistungsspezifikation (Performance specification) = die Abbildung der durch die Technikanalyse erhobenen Leistungen der Techniksysteme in ein formales Modell. neue Technologie (new technology) = eine Technologie, deren Umsetzung in die konkrete Anwendung erst am Anfang steht. Pilotprojekt (pilot project) = ein Projekt, mit dem ein Informationssystem geschaffen werden soll, welches das Erlernen im Umgang mit neuen Technologien fördert, um so sukzessiv ein Nutzenpotential zu schaffen. Techniksystem (technology system) = ein auf dem Markt angebotenes Produkt der Informations- und Kommunikationstechnik. Techniktyp (technology type) = eine Klasse von Techniksystemen, die bezüglich wesentlicher Eigenschaften (z.B. bezüglich der Funktionalität) gleichartig sind.

TECHA - Technikanalyse

297

Zweck der Technikanalyse Zweck der Technikanalyse ist es, mit einer systematischen Vorgehensweise die Eigenschaften zu erheben, zu beschreiben und zu verifizieren, welche die Techniksysteme (Hardware und Software) erbringen können, soweit diese vor dem Hintergrund der Planungsziele eines IuK-Projekts von Interesse sind. Angesichts der Vielfalt des Angebots an Informations- und Kommunikationstechnik, einschließlich der "klassischen" Bürotechnik, muß sich der Systemplaner mit einer Systematisierung der Techniksysteme zu Techniktypen zunächst eine Orientierungshilfe schaffen, sofern er nicht auf vorhandene Systematisierungen zurückgreifen kann. In der Praxis wird der Technikanalyse in der Systemplanung kaum Aufmerksamkeit geschenkt. Im allgemeinen werden die Eigenschaften der Techniktypen in der Vorstudie nicht berücksichtigt; erst im Zusammenhang mit der Ausschreibung und der Angebotsanalyse werden die Erhebung, die Beschreibung und die Prüfung konkreter Technikangebote vorgenommen (vgl. Lerneinheiten BTECH und PFLIC). Diese Vorgehensweise geht davon aus, daß der Entwurf der Grundkonzeption "technikfrei" möglich ist. Andere Ansätze ordnen die Erhebung, Beschreibung und Verifizierung des Technikangebots in die Durchführbarkeitsstudie ein und damit in den Entwurf der Grundkonzeption, obwohl es unmöglich ist, konkrete Technikangebote zu bewerten, ohne einen bereits weit fortgeschrittenen Systementwurf als Bewertungsgrundlage zur Verfügung zu haben. Bei diesen Ansätzen wird die Technikanalyse als wesentliche Voraussetzung für den Entwurf alternativer Systemkonzepte und deren Bewertung vor dem Hintergrund der Planungsziele angesehen. In Anbetracht der Tatsache, daß sich die der Vorstudie folgenden Phasen der Systemplanung an der Grundkonzeption orientieren, ist die Einbringung systematisch erarbeiteter Ergebnisse der Technikanalyse ("Leistungsprofil") für den Erfolg der Systemplanung ebenso bedeutsam wie die Ergebnisse der Anforderungsanalyse ("Anforderungsprofil"). Dieser "Zwillingscharakter" von Leistungsprofil und Anforderungsprofil verlangt für die Technikanalyse und für die Anforderungsanalyse eine befriedigende methodische Vorgehensweise. Bezüglich der Anforderungsanalyse wurde diese Vorgehensweise an anderer Stelle bereits dargestellt (vgl. Lerneinheit ANFOA). In Analogie dazu kann die systematische Vorgehensweise bei der Technikanalyse entwickelt werden. Die Bedeutung der projektbezogenen Technikanalyse nimmt mit zunehmender Durchdringung der Unternehmen mit Techniksystemen und der damit einhergehenden Entwicklung des Technologiemanagements (vgl. Lerneinheit TECHM im Band "Informationsmanagement") ab, weil die für die Grundkonzeption bedeutsamen Entscheidungen über die Techniksysteme bereits gefallen sind; entweder sind die Techniksysteme im Unternehmen bereits verfügbar, oder ihre Verfügbarkeit ist auf Grund strategischer Entscheidungen zur Infrastruktur-Planung bereits eingeleitet worden. Ihren Stellenwert behält die Technikanalyse für solche IuK-Projekte, in denen für den Anwender "Neue Technologien" verwendet werden, deren Eigenschaften noch nicht ausreichend bekannt sind (z.B.

298

Methoden und Techniken der Vorstudie

Technologien zur Unterstützung für kooperatives Arbeiten) und die möglicherweise in Pilotprojekten zunächst erprobt werden sollen. Vorgehensweise bei der Technikanalyse Eine systematische Vorgehensweise bei der Technikanalyse umfaßt unter formalen Gesichtspunkten die drei in Abbildung TECHA-1 genannten Phasen. Methodische Aspekte der Technikanalyse beziehen sich auf alle drei Phasen der Vorgehensweise. Die Phasen werden sequentiell durchlaufen, jedoch meist in mehreren Iterationen verfeinert. Dadurch entstehen, wie im Phasenmodell, Rückkopplungen, die eine zyklische Technikanalyse ermöglichen. Die drei Phasen werden nachfolgend erläuert.

Planen der Technikanalyse Das Planen der Technikanalyse umfaßt das Festlegen von Zeiten und Kosten für die Durchführung der Technikanalyse sowie für die Strukturierung der Eigenschaften (insbesondere Funktionen und Leistungen) der Techniksysteme, für die Anwendung der Methoden zu ihrer Erhebung, für die Beschreibung und für die Verifizierung.

TECH A - Technikanalyse

299

In Anbetracht der bestehenden Vielfalt und des unterschiedlichen Charakters der IuK-Technik ist es schwierig, ein allgemeingültiges Schema zur Systematisierung zu finden, in das sich nicht nur die derzeit angebotenen, sondern auch die für die Zukunft schon erkennbaren Techniksysteme einordnen lassen. Entsprechend unterschiedlich und letztlich nicht zufriedenstellend sind die wenigen, in der Literatur dargestellten Systematisierungen. A. Picot betrachtet die Technikentwicklung und stellt die Verknüpfung der Endgeräte über Netze und Dienste in den Vordergrund einer Technik-Systematisierung. Dabei wird zwischen dem öffentlichen und dem privaten (innerbetrieblichen) Bereich von Netzen und innerhalb des öffentlichen Bereichs zwischen Vermittlungsnetzen und Verteilnetzen unterschieden. Innerhalb des privaten Bereichs wird zwischen zentraler Vermittlungsstruktur (Stern) und dezentraler Vermittlungsstruktur (Bus und Ring) unterschieden. In beiden Bereichen wird als nächstes Unterscheidungsmerkmal die schmalbandige bzw. die breitbandige Kommunikation verwendet. Darunter werden die jeweils verfügbaren Dienstbzw. Endgeräteangebote aufgeführt. Neben diesen "modernen" IuK-Techniken werden die "klassischen" Vermittlungstechniken eingeordnet. Auf die vielfältigen Integrationstendenzen wird verwiesen. Für die Technikanalyse hilfreicher ist ein übergreifendes Einordnungsschema, mit dem das gegenwärtige Angebot und die sich abzeichnenden Entwicklungslinien der IuK-Technik eingeordnet und diese miteinander verglichen werden können. Mit diesem Einordnungsschema soll folgendes möglich sein: • die wesentlichen Domänen unterschiedlicher Entwicklungslinien der IuK-Technik sichtbar zu machen; • die zu erwartenden Erweiterungen der einzelnen Techniktypen aufzuzeigen; • die Bereiche sichtbar zu machen, in denen es derzeit kein oder kein ausreichendes Technikangebot gibt. —^InformationsFunktion Eingabe/Ausgabe Speicherung Transport Bearbeitung Verarbeitung

Daten

Text

Bild

Sprache

Abb. TECHA-2: Einordnungsschema für Techniksysteme (Quelle: nach Picot/Reichwald)

Die erste Dimension der Systematisierung orientiert sich am Informationsund Kommunikationsprozeß und beschreibt den Bedarf an Techniksystemen anhand der Funktionen Eingabe/Ausgabe, Speicherung, Transport, Bearbeitung und Verarbeitung (siehe die Zeilen Abbildung TECHA-2). Die zweite Dimension der Systematisierung orientiert sich an den Aufgabentypen und beschreibt den aufgabenspezifischen Bedarf an Techniksystemen anhand der Informationsarten Daten, Text, Bild und Sprache (siehe die Zeilen Abbildung TECHA-2). Daraus ergibt sich das in Abbildung TECHA-2 dargestellte Einordnungsschema, nach

300

Methoden und Techniken der Vorstudie

dem idealtypisch zwanzig Techniktypen unterschieden werden können; jedes Feld der Matrix entspricht idealtypisch einem Techniktyp. Es ist liegt aber auf der Hand, daß die Domäne eines konkreten Techniksystems mehrere dieser Matrizenfelder ganz oder teilweise überstreichen kann; dies wird im Demonstrationsbeispiel gezeigt. Durchführen der Technikanalyse Das Durchführen der Technikanalyse umfaßt das Erheben und Beschreiben der Eigenschaften der Techniksysteme unter Verwendung der in der Planung festgelegten Systematisierung. Das Erheben der Eigenschaften beginnt, wenn feststeht, welche Techniktypen zur Erreichung der Planungsziele eingesetzt werden sollen. Informationsquellen für das Erheben der Eigenschaften von Techniksystemen sind: • Produktbeschreibungen der Hersteller/Anbieter; • Beschreibung und insbesondere Bewertung von Produkten, die in der einschlägigen Literatur dokumentiert sind; • Demonstration der Produkte, z.B. auf Messen; • Erfahrungsaustausch über die Produkte bei Anwendern. Für die Technikanalyse reichen nominale Aussagen, also Aussagen, die Angaben darüber machen, ob das Techniksystem eine bestimmte, geforderte Eigenschaft (z.B. die Fähigkeit zur Spracheingabe, zur Bildbearbeitung, zur Textverarbeitung usw.) hat oder nicht hat, nicht aus. Auf einer zweiten Gliederungsebene sind daher die Eigenschaften zu präzisieren. Dabei kann zunächst zwischen qualitativen und quantitativen Eigenschaften unterschieden werden. • Auf der Ebene der quantitativen Eigenschaften ist es für die Präzisierung wesentlich, welche Eigenschaften im einzelnen von Bedeutung sind. So ist z.B. die "Lesegeschwindigkeit" eine Eigenschaft, die für die Eingabe von Daten und Text mit bestimmten Techniksystemen (z. B. Markierungs- oder Belegleser) von Interesse ist; die "Zugriffszeit" ist eine Eigenschaft, die für die Speicherung (und Wiedergewinnung) aller Informationsarten mit bestimmten Techniksystemen (z.B. Magnetplattenspeicher, Diskette) von Interesse ist; die "Druckgeschwindigkeit" ist eine Eigenschaft, die für die Ausgabe von Daten, Text und Bild auf Papier von Interesse ist. • Auf der Ebene der qualitativen Eigenschaften sind Eigenschaften von Bedeutung, die in der Regel für mehrere der auf der ersten Ebene gebildeten Funktionen und Informationsarten gleichermaßen gelten. Beispiele hierfür sind ergonomische Eigenschaften, die sowohl für Eingabe und Ausgabe als auch für Daten, Text, Bild und Sprache gelten. Die quantitativen Eigenschaften der Techniksysteme sind primär technische Kriterien, insbesondere Mengengrößen pro Zeiteinheit (wie z.B. Zeichen/Sek., Seiten/Min.). Sie können teilweise relative problemlos erfaßt werden, weil die Techniksysteme in der Regel mit solchen Kriterien im Technikangebot (z.B. in den einschlägigen Datenblättern) beschrieben sind. Quelle für die quantitativen Eigenschaften sind daher die Produktbeschreibungen der Technikanbieter. Handelt es sich jedoch um Eigenschaften, deren Ausprägungen nur in Abhängigkeit

TECHA - Technikanalyse

301

von der Arbeitslast bestimmt werden können (z.B. Durchsatz, Transaktionen/Min.), dann sind aufwendige Ermittlungsverfahren erforderlich (z.B. Simulation und Benchmarks). Für den einzelnen Anwender und für ein konkretes IuK-Projekt ist der Aufwand dafür meist zu hoch; die Anwendung solcher Methoden ist mit dem Ziel der Vorstudie häufig nicht vereinbar. Hilfreich können Ergebnisse wissenschaftlicher Laborstudien sein, wie sie auch für die Konsequenzanalyse (vgl. Lerneinheit KONSA) herangezogen werden. Dies gilt insbesondere dann, wenn es sich um innovative Techniksysteme handelt (die Vertiefungsliteratur berichtet über einschlägige Beispiele mit verschiedenen Techniksystemen, die zum Zeitpunkt der Laborstudien innovativ waren). Die qualitativen Eigenschaften der Techniksysteme sind eine Kombination mehrerer technischer Kriterien, die in ihrer Auswirkung auch von der Umwelt des Techniksystems (also sowohl von anderen Techniksystemen, deren Verwendung geplant ist, als auch vom Aufgabensystem und von den Aufgabenträgern) abhängig sind. Qualitative Eigenschaften machen sich teilweise erst in der Qualität des Gesamtsystems (Aufgabensystem, Aufgabenträger und Techniksystem) bemerkbar. Ein Beispiel ist die Anpassungsfähigkeit oder Elastizität (mengenmäßige, qualitative, zeitliche und räumliche Anpassungsfähigkeit) des Techniksystems an sich ändernde Anforderungen. Die qualitative Eigenschaft "zeitliche Elastizität" ist ein Maß für den notwendigen Zeitraum der Anpassung des Techniksystems an veränderte Anforderungen; mit "räumliche Elastizität" wird gemessen, wie schnell örtliche Veränderungsmöglichkeiten des Techniksystems vollzogen werden können ("Mobilität"), was für betriebliche Aufgaben mit mobilen Prozessen von Bedeutung ist. Spezifische methodische Hilfsmittel für das Erheben der Eigenschaften der Techniksysteme können nicht angegeben werden, sodaß auf die Methoden zur Istzustandserfassung verwiesen werden muß (vgl. Lerneinheit ISTER). Bei der Anwendung dieser Methoden für die Technikanalyse ist zu beachten, daß die Detaillierung der Erhebung nur soweit erfolgen sollte, wie dies zum Entwerfen alternativer Systemkonzepte und dem Bestimmen der Grundkonzeption unbedingt erforderlich ist. Die Präzisierung der Erhebung erfolgt erst im Zusammenhang mit dem Bestimmen des Technikbedarfs auf der Grundlagen der Systementwürfe der Grobprojektierung (vgl. Lerneinheit BTECH). Die Beschreibung der Eigenschaften soll korrekt, verständlich und leicht prüfbar sein; sie soll eine für den Systementwurf geeignete Strukturierung unterstützen. Bezüglich Formalisierung und Darstellungsart gelten die gleichen Überlegungen wie zur Beschreibung der Anforderungen (vgl. Lerneinheit ANFOA). Praktikable Beschreibungsmittel, die die Voraussetzungen erfüllen, stehen nicht zur Verfügung. Verifizieren der Ergebnisse der Technikanalyse Ein systematisches Überprüfen der beschriebenen Eigenschaften wird durch das Fehlen von Beschreibungsmitteln erschwert. Das Überprüfen auf formale Unzulänglichkeit ist deshalb praktisch nicht möglich. Sachliche Unzulänglichkeit liegt vor, wenn die Beschreibung der Eigenschaften die real bestehenden Eigenschaften der Techniksysteme nicht korrekt abbildet. Das Überprüfen kann nur durch

302

Methoden und Techniken der Vorstudie

mehrmaliges Nachvollziehen der Beschreibung ganz oder stichprobenweise und möglichst durch verschiedene Personen erfolgen. Die Wirksamkeit der Überprüfung kann nur dann entscheidend verbessert werden, wenn es gelingt, eine zielorientierte, regelgesteuerte und rechnergestützte Beschreibung der Eigenschaften zu verwirklichen. Demonstrationsbeispiel Am Beispiel der Techniksysteme Speicherschreibmaschine, Fernkopierer und Bildschirmtext wird deren Zuordnung auf Techniktypen nach dem in Abbildung TECHA-2 gezeigten Einordnungsschema vorgenommen. Die Speicherschreibmaschine ist das einfachste Techniksystem unter den modernen Schreibsystemen. Sie besitzt in der Regel keinen Bildschirm und hat nur einen kleinen Arbeitsspeicher. Teilweise ist sie mit einem Zeilendisplay und einem externen Speicher (meist Diskette) ausgestattet. Ihre Domaine liegt in der Eingabe von Text (über Tastatur), der Ausgabe von Text (über Drucker) und der Speicherung von Text auf dem Datenträger Papier. Die Bearbeitung von Text ist - wegen des kleinen Arbeitsspeichers - nur eingeschränkt möglich. Transport und Verarbeitung können nicht unterstützt werden. Abbildung TECHA-3 zeigt die Domäne der Speicherschreibmaschine. ^^JnformationsFunktion — Eingabe/Ausgabe Speicherung Transport Bearbeitung Verarbeitung

Daten

Text

Bild

Sprache

¡¡¡IIP /¿//////m

Abb. TECHA-3: Domäne der Speicherschreibmaschine (Quelle: nach Picot/Reichwald)

--^JnformationsFunktion Eingabe/Ausgabe Speicherung Transport Bearbeitung Verarbeitung

Daten

Text

Bild

Sprache

WMMMM*

Abb. TECHA-4: Domäne des Fernkopierers (Quelle: nach Picot/Reichwald)

Der Fernkopierer ermöglicht die formatgetreue Eingabe, den Transport und die Ausgabe (auf Papier) von Festbildern (Zeichnungen, Abbildungen). Die weitere Entwicklung zielt auf einen kombinierten Betrieb von Bild- und Textübertragung ab, sodaß es möglich wird, zeichen- und faksimilecodierte Informationen

JECHA - Technikanalyse

303

gemeinsam zu übertragen. Abbildung TECHA-4 zeigt die Domäne des Fernkopierers. Bildschirmtext ermöglicht passive Abrufdienste (Informationen von Informationsanbietern und individuelle Informationen), aktive Informationseingabe (kommerziell und individuell) sowie interaktiven Abruf und Eingabe von Informationen (Dialog, Zugang zu Anwendungsprogrammen). Für die Anwendung zeichnet sich ab, daß große Teile des Daten-, Text- und Bildbereiches abgedeckt werden können, wie Abbildung TECHA-5 zeigt. ^-^hiformationsFunktion '— Eingabe/Ausgabe Speicherung Transport Bearbeitung Verarbeitung

Daten

Text

Bild

Sprache

W m M m t m m i m .

Í

' / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / A v / / / / / / / / / / / ) / / / / / / / / / / / / / / / ^ / / / / / A

Abb. TECHA-5: Domäne des Dienstes Bildschirmtext (Quelle: nach Picot/Reichwald)

Forschungsbefunde R. L. Nolan hat auf Grund empirischer Untersuchungen festgestellt, daß sich die Nutzung der Techniksysteme durch die Anwender auf einer Lernkurve vollzieht, die durch sechs Stufen gekennzeichnet ist: Initiation (Initiierung), Contagión (Ausbreitung), Control (Beherrschung), Integration, Data Administration (Datenorientierung) und Maturity (Reife). Nach dem Einsatz des ersten Computers (Initiierung) breitet sich dessen Nutzung schnell aus (Ausbreitung), bis in der dritten Stufe (Beherrschung) versucht wird, die steigenden Kosten in den Griff zu bekommen. Das Management ändert seine Einstellung zur IuK-Technik und rückt die Deckung der Informationsnachfrage in den Mittelpunkt des Interesses. In der vierten Stufe (Integration) werden die Techniksysteme miteinander verknüpft. In der fünften Stufe werden die Informationssysteme primär an der Datenbasis des Aufgabensystems ausgerichtet (Datenorientierung), bis sie in der sechsten Stufe ihre Reife erreichen. Sie ist insbesondere dadurch gekennzeichnet, daß alle Aufgaben im Unternehmen unterstützt werden, und daß sich in der Gesamtheit der Informationssysteme die Struktur und der Informationsfluß des Unternehmens widerspiegeln. Jedes Unternehmen nimmt eine bestimmte Position in diesem Stufenkonzept ein; es kann prinzipiell keine Stufe überspringen. Die ersten drei Stufen kennzeichnen den "Assimilationsprozeß" der IuK-Technik; in Stufe drei erfolgt der Übergang zu einem bewußten Informationsmanagement. Aufgabenverweise Entwerfen der Grundkonzeption (Lerneinheit GRUND).

304

Methoden und Techniken der Vorstudie

Kontrollfragen 1. 2. 3. 4. 5.

Wie ist die Technikanalyse in den Prozeß der Vorstudie eingeordnet? Welche Vorgehensweise ist für die Technikanalyse zweckmäßig? Welche beiden Dimensionen werden im Einordnungsschema verwendet? Wie wird die Domäne eines Techniksystems mit Hilfe des Einordnungsschemas beschrieben? Welche Methoden können beim Erheben der Leistungen verwendet werden?

Quellenliteratur Heinrich, L. J.: Informationsmanagement - Planung, Überwachung und Steuerung der Informationsinfrastruktur. 4. A., Oldenbourg Verlag, München/Wien 1992, insbesondere Lerneinheit TECHM Heinrich, L. J. et al.: Informations- und Kommunikationstechnik für Betriebswirte und Wirtschaftsinformatiker. 4. A., Oldenbourg Verlag, München/Wien 1994 Picot, A. und Reichwald, R.: Kommunikationstechnik für Anwender - Akzeptanzbarrieren, Bedarfsstrukturen, Einsatzbedingungen. CW-Publikationen Verlagsgesellschaft, München 1983 Vertiefungsliteratur Ambichl, E.: Leistungsbewertung dialogorientierter Datenbanksysteme in Client/Server-Architektur. Dissertation Universität Linz, Linz 1991 Ambichl, E. und Gappmaier, M.: Nicht vernetzte PCs versus lokale Netzwerke - eine Vergleichsstudie. In: Information Management 1/1989, 38 - 43 Ambichl, E. und Heinrich, L. J.: Leistungsbewertung dialogorientierter Datenbanksysteme in Client/Server-Architekturen. In: Information Management 3/1992,24-31 Heinrich, L. J. und Ambichl, E.: Ein Modell zur Unterstützung strategischer TechnologieeinsatzEntscheidungen. In: Information Management 3/1988,44 - 52

KREAT - Kreativitätstechniken Lernziele Sie kennen den Zweck von Kreativitätstechniken, ihre Anwendungsgebiete und die organisatorischen Voraussetzungen für ihre Anwendung. Sie können die Vorgehensweise bei der Anwendung der Kreativitätstechniken am Beispiel der WTechnik und des Brainstorming mit Osborn-Verfremdung erläutern. Sie kennen die Merkmale rationalen und kreativen Problemlösens. Definitionen und Abkürzungen Delphi-Methode (Delphi technique) = ein Mehrstufen-Rating und ein Mitteilungsrating, bei dem in mehreren Runden die Einzelurteile der Experten ausgewertet und gegebenenfalls kommentiert an die Experten zurückgemeldet werden, die darauf aufbauend ein weiteres Rating durchführen; nach mehreren Runden wird im allgemeinen eine Konvergenz der Ratingurteile erreicht, geschlossene Entscheidung (closed decision) = eine Entscheidung, bei der eine aus mehreren Handlungsalternativen unter der Voraussetzung auszuwählen ist, daß alle möglichen Handlungsalternativen, die Algorithmen zur Problemlösung und alle möglichen Handlungsergebnisse bekannt sind, gut strukturiertes Problem (well-structured problem) = eine Situation, in der ein unerwünschter Ausgangszustand durch Anwenden von Lösungsalgorithmen in einen erwünschten Endzustand transformiert werden kann. Kreativität (creativity) = die Fähigkeit des Menschen, schöpferisch zu sein, eigene Ideen entwickeln zu können, einfallsreich und erfinderisch zu sein, kreatives Problemlösen (creative problem solving) = die Fähigkeit des Menschen, Denkergebnisse hervorzubringen, die ihm oder seiner Umwelt neu sind. Methode 6.3.5. = eine Kreativitätstechnik, bei der sechs Teilnehmer sechs Mal je drei Lösungsvorschläge in jeweils fünf Minuten generieren, offene Entscheidung (open decision) = eine Entscheidung, bei der mindestens ein Merkmal der geschlossenen Entscheidung fehlt. Problem (problem) = eine Handlungssituation, die durch ein Defizit an Wissen gekennzeichnet ist. Problemlosen (problem solving) = die Fähigkeit des Menschen, durch kreatives oder durch rationales Vorgehen Denkergebnisse hervorzubringen, rationales Problemlösen (rational problem solving) = die Fähigkeit des Menschen, Denkergebnisse unter Verwendung bekannter Denkmechanismen hervorzubringen. schlecht strukturiertes Problem (ill-structured problem) = eine Situation, in der ein unerwünschter Ausgangszustand wegen fehlender Zielvorstellungen, komplexer Ausgangssituation oder fehlender Lösungsalgorithmen nur durch intuitive Probierverfahren in mehrere mögliche Endzustände transformiert werden kann. Szenario-Technik (szenario technique) = eine systematische Vorgehensweise zur Gewinnung von Information über zukünftige Entwicklungen von offenen Systemen für die Formulierung von Strategien.

306

Methoden und Techniken der Vorstudie

Zweck der Kreativitätstechniken Zur Bewältigung der Aufgaben der Systemplanung sind nicht nur fachliche Kenntnisse und Fähigkeiten der Aufgabenträger (z.B. zur Anwendung von Methoden und zur Nutzung von Werkzeugen) erforderlich, sondern auch schöpferische Fähigkeiten, also die Fähigkeit, kreativ zu sein. Kreativität ist besonders dann gefragt, wenn es gilt, Alternativen zu finden. Dies ist in den frühen Phasen der Systemplanung, insbesondere in der Vorstudie, häufiger der Fall als in ihren späten Phasen. In den frühen Phasen der Systemplanung ist der Handlungsspielraum groß; er nimmt mit dem Fortschreiten des Planungsprozesses ständig ab. Ein großer Handlungsspielraum läßt aber nicht nur mehr Raum für kreatives Handeln als ein kleiner Handlungsspielraum, sondern er muß auch ausgeschöpft werden, wenn die Planungsziele erreicht werden sollen. Kreatives Handeln wird durch die Anwendung von Kreativitätstechniken wirkungsvoll unterstützt.

Anwendungsgebiete der Kreativitätstechniken Es gibt zwei idealtypische Verhaltensmuster zum Problemlösen: rationales Problemlösen und kreatives Problemlösen. Zwischen diesen beiden gedanklichen Polen gibt es viele Mischformen, die Komponenten rationalen und kreativen Problemlösens enthalten. Rationales Problemlosen wird von Entscheidungstech-

KREAT - Kreativitätstechniken

307

nologen zum Lösen von wohlstrukturierten Problemen in geschlossenen Entscheidungssituationen empfohlen. Abbildung KREAT-1 zeigt den rationalen Problemlösungsprozeß. Wesentlich häufiger als wohlstrukturierte Probleme in geschlossenen Entscheidungssituationen sind schlechtstrukturierte Probleme in offenen Entscheidungssituationen anzutreffen. Hierfür ist kreatives Problemlösen charakteristisch. Abbildung K R E A T - 2 zeigt den kreativen Problemlösungsprozeß. Kreativitätstechniken sind Methoden zum Definieren und Lösen schlechtstrukturierter Probleme durch Anwendung intuitiver Probierverfahren. Aus diesen generellen Überlegungen zur Möglichkeit und zur Notwendigkeit kreativen Handelns und seiner Unterstützung durch Kreativitätstechniken ergibt sich, daß das wichtigste Anwendungsgebiet der Kreativitätstechniken in der Systemplanung das Generieren alternativer Systemkonzepte beim Entwerfen der Grundkonzeption in der Vorstudie ist (vgl. Lerneinheit GRUND).

Abb. KREAT-2: Kreativer Problemlösungsprozeß

Personelle und organisatorische

Voraussetzungen

Individuelle K r e a t i v i t ä t s h e m m n i s s e können im kognitiven Bereich liegen, zum Beispiel die Übernahme alter Gewohnheiten oder die Schwierigkeit, ein Problem in Teilprobleme zu zerlegen. Daneben können soziale und gesellschaftliche Faktoren die Kreativität hemmen. Von Bedeutung sind auch emotionale Hemmungen wie die Furcht, Fehler zu machen oder sich zu blamieren, Zeitdruck und Leistungsdruck sowie mangelndes Vertrauen in die eigenen Fähigkeiten.

308

Methoden

und Techniken der

Vorstudie

Kreativitätsfördernd sind persönliche Eigenschaften wie Originalität, geistige Beweglichkeit, konstruktive Unzufriedenheit, Beobachtungs- und Kombinationsgabe, Bereitschaft zur Abkehr von Erfahrungen und gewohnten Denkstrukturen. Kreative Fähigkeiten von Individuen können durch gruppendynamische Prozesse gefördert werden. Die meisten Kreativitätstechniken werden daher in Gruppensitzungen angewendet (gruppenorientierte Kreativitätstechniken im Unterschied zu individualorientierten Kreativitätstechniken). Die Gruppenmitglieder kommen in der Regel aus verschiedenen Tätigkeitsbereichen (z.B. Systemplaner und Benutzer) und verschiedenen hierarchischen Unternehmensebenen (z.B. Sachbearbeiter und Management); sie haben unterschiedliche Kenntnisse, Fertigkeiten und Fähigkeiten. Eine so zusammengesetzte Gruppe wird als interdisziplinäre Kreativgruppe bezeichnet. Eine interdisziplinäre Kreativgruppe ist organisatorisch dann ideal, wenn sie aus fünf bis zwölf Personen besteht. Ein Moderator steuert den Gruppenprozeß und dokumentiert die Ergebnisse der Gruppenarbeit (z.B. auf Flipchart). Die Sitzungsdauer sollte 30 Minuten nicht wesentlich überschreiten; in der Regel sind mehrere Sitzungen zum Lösen eines Problems erforderlich. In interdisziplinären Kreativgruppen der Vorstudie sollten die folgenden Aufgabenträger (vgl. Lerneinheit AUTER) vertreten sein: der Projektleiter, Mitglieder des Lenkungsausschusses (Management der auftraggebenden Fachabteilungen und der IKS-Abteilung), Sachbearbeiter als potentielle Benutzer des zu schaffenden Informationssystems, Koordinatoren der auftraggebenden Fachabteilungen, der Produktmanager sowie ein Aufgabenträger, der die Interessen des Controlling und der Revision vertritt. Die Kreativgruppe muß vor ihrer ersten Gruppensitzung mit den Kreativitätstechniken, die angewendet werden sollen, ausreichend vertraut gemacht werden. Arten von

Kreativitätstechniken

Wichtigstes gemeinsames Merkmal der Kreativitätstechniken ist die Nutzbarmachung individueller kreativer Eigenschaften und ihre Verstärkung durch gruppendynamische Prozesse. Weitere gemeinsame Merkmale der Kreativitätstechniken sind: • die Zerlegung des Problems in Teilprobleme, die Generierung von Lösungsvorschlägen zu den Teilproblemen, die Auswahl der besten Teillösungen und deren Synthese zur Problemlösung; • die Steuerung des Gruppenprozesses durch einen Moderator; • die Verwendung von Unterstützungstechniken (z.B. Metaplan-Technik). Eine Systematik der Kreativitätstechniken unterscheidet zwischen strategischen Kreativitätstechniken und operativen Kreativitätstechniken, womit ihre Eignung für das Problemlösen bei primär strategischen Aufgaben einerseits und primär operativen Aufgaben andererseits gemeint ist. Zur ersten Gruppe zählen die Szenario-Technik und die Delphi-Methode, zur zweiten Gruppe (die für die Vorstudie von größerer Bedeutung ist) gehören insbesondere: • Das in den zwanziger Jahren von A. F. Osborn entwickelte Brainstorming.

KREAT - Kreativitätstechniken

309

• Das aus dem Brainstorming entwickelte Brainwriting, bei dem das Problemlösen in Schriftform erfolgt (z.B. die von Rohrbach entwickelte Methode 6.3.5.); die Schriftform wird dann vorgezogen, wenn ein kritisches Problem zu bearbeiten ist, oder wenn die Gruppe im offenen Umgang miteinander nicht geübt genug ist, um kreativ arbeiten zu können. • Die in den fünfziger Jahren von W. J. J. Gordon und J. Prince entwickelte Synektik, zu deren Kennzeichen die Fragestellung "Wie kann man erreichen, daß ...?" gehört ("Wie-Technik" oder "Warum-Technik", abgekürzt: W-Technik), also: systematisches Verfremden und Suchen nach Analogien. • Die in den sechziger Jahren von F. Zwicky entwickelte Methode des morphologischen Kastens (kurz: "Morphologischer Kasten", auch als "Morphologische Matrix" bezeichnet). • Auch die Wertanalyse (vgl. Lerneinheit WERTA) wird häufig zu den Kreativitätstechniken gerechnet, obwohl in der Wertanalyse selbst wieder Kreativitätstechniken verwendet werden. Diese - und weitere - operative Kreativitätstechniken unterscheiden sich vor allem dadurch, daß sie entweder eher intuitiv (wie Brainstorming, Brainwriting und Synektik), oder eher systematisch (wie Morphologischer Kasten und Wertanalyse) sind. Nachfolgend werden die W-Technik zur Problemdefinition und das Brainstorming mit Osborn-Verfremdung zur Ideenfindung erläutert. WTechnik und Brainstorming mit Osborn-Verfremdung sind durch einen hohen Grad an Praktikabilität gekennzeichnet. Sie sind zum Lösen wenig komplexer Probleme gut geeignet. Sie können mit eingeschränkter Erfolgswahrscheinlichkeit auch von Einzelpersonen angewendet werden. Für Probleme mit höherer Komplexität eignen sich synektische und morphologische Methoden besser. In der Regel bestehen Abhängigkeiten zwischen der Qualität der Problemdefinition und der Qualität der gefundenen Problemlösungen. Je besser die Problemdefimtion ist, desto größer ist die Erfolgswahrscheinlichkeit der generierten Problemlösungen. W-Technik zur Problemdefinition Die W-Technik besteht aus fünf Arbeitsschritten: Spontandefinition, Umformulierung, Antworten, Problemdefinition sowie Eignungsprüfung und Rückkopplung. • Erster Arbeitsschritt: Spontandefinition. Das Problem wird spontan definiert, wie es zunächst symptomatisch wahrgenommen wird ("problem definition as seen"). Die Problemdefinition wird erleichtert, wenn sie mit "Wie kann ich erreichen, daß.." eingeleitet wird. • Zweiter Arbeitsschritt: Umformulierung. Die Spontandefinition wird zu einer Frage umformuliert. Die Frage wird mit "Warum.." eingeleitet. • Dritter Arbeitsschritt: Antworten. Zur Frage aus dem zweiten Arbeitsschritt werden durch freie gedankliche Assoziation drei einfache, griffige Antworten ermittelt. • Vierter Arbeitsschritt: Problemdefinition. Die drei Antworten aus dem dritten Arbeitsschritt werden zu neuen Problemdefinitionen unter Verwendung der Einleitung "Wie kann ich erreichen, daß .." umformuliert.

310

Methoden und Techniken der Vorstudie

• Fünfter Arbeitsschritt: Eignungsprüfung und Rückkopplung. Es wird geprüft, ob eine der im vierten Schritt gefundenen Problemdefinitionen geeignet ist, das Problem ausreichend operational zu definieren. Ist dies nicht der Fall, kann durch Verallgemeinerung einer oder mehrerer Problemdefinitionen aus dem vierten Arbeitsschritt eine Problemlösung gefunden werden. Wenn die so gewonnene(n) Problemdefinition(en) ebenfalls unbefriedigend ist (sind), wird eine neue Iteration mit den drei im vierten Arbeitsschritt generierten Problemdefinitionen durchgeführt. Hieraus ergeben sich neun neue Problemdefinitionen, die in der Regel mindestens eine brauchbare Problemlösung enthalten. Ist dies nicht der Fall, werden weitere Iterationen durchgeführt, wobei die Anzahl der Problemlösungen exponentiell steigt. Erfahrungsgemäß wiederholen sich immer mehr Problemlösungen bei Iterationen höherer Ordnung. Dies ist ein Indikator für die Konvergenz des W-Technik-Prozesses; die optimale Problemdefinition ist ermittelt, der Prozeß kann beendet werden. Brainstorming mit

Osborn-Verfremdung

Voraussetzung für die Durchführung von Brainstorming-Sitzungen ist, daß ein Problem mit geringer Komplexität vorliegt, für das es eine präzise Problemdefinition gibt. Die Problemdefinition ist Input für die zweite Stufe des kreativen Problemlösungsprozesses, die Ideengenerierung (vgl. Abbildung KREAT-2). Brainstorming mit Osborn-Verfremdung unterstützt die Ideengenerierung; diese ist in vorbereitende und nachbearbeitende Arbeitsschritte wie folgt geordnet: • Erster Arbeitsschritt: Vereinbarung der Grundregeln. Die Grundregeln des Brainstormings lauten: * Die positive Einstellung gegenüber eigenen und fremden Ideen; auch abwegig erscheinende Problemlösungen nicht kritisieren. * Die Betonung liegt zunächst auf der Quantität der zu produzierenden Ideen. * Die Problemlösungen sollen möglichst originell und neuartig sein. Vernunft und Logik sind zunächst nicht gefragt. * Durch Offenheit gegenüber Lösungsvorschlägen anderer, soll man sich zur Weiterentwicklung offenbarter Gedanken anregen lassen. Bei großen interdisziplinären Kreativgruppen empfiehlt es sich, situationsbezogene Verhaltensregeln zu vereinbaren, die zur Regelung des Gruppenprozesses beitragen. Beispiele sind: Andere Gruppenmitglieder nicht unterbrechen, zuhören können, Aggressionen vermeiden, Störungen sofort aufarbeiten. • Zweiter Arbeitsschritt: Ideengenerierung. In einem vorgegebenen Zeitraum (optimal sind zehn bis 15 Minuten in Abhängigkeit vom Problem) produziert die Kreativgruppe unter Einhaltung der vereinbarten Regeln eine vorgegebene Anzahl (Richtwert 50 bis 60) Ideen durch freie gedankliche Assoziation und Zurufe zum Moderator. Der Moderator dokumentiert die Ideen (z.B. auf Flipchart), motiviert und steuert den gruppendynamischen Prozeß. Das Ergebnis des zweiten Arbeitsschritts ist eine ungeordnete Menge von Ideen zur Problemlösung. Häufig ist eine Teilmenge der Ideen brauchbar. • Dritter Arbeitsschritt: Verfremdung. Die im zweiten Arbeitsschritt gewonnenen Ideen zur Problemlösung werden mit Hilfe der Osborn-Verfremdung verändert. Einzelne Ideen können miteinander kombiniert, angepaßt, neu angeordnet, ersetzt, vergrößert, verkleinert, umgekehrt oder anders verwendet

KREAT - Kreativitätstechniken

311

werden. Sowohl einzelne Verfremdungsmöglichkeiten als auch Kombinationen können angewendet werden. Abbildung KREAT-3 zeigt eine Prüfliste nach Osborn mit neun Basisfragen zur Verfremdung. • Vierter Arbeitsschritt: Ideenbewertung. Für die Bewertung alternativer Ideen zur Problemlösung werden Kriterien festgelegt, mit denen die Qualität der Ideen gemessen werden kann. Jede Idee wird in der Kreativgruppe unter der Leitung des Moderators verbal, ordinal oder durch Vergabe von Punkten anhand der Kriterien bewertet.

Abb. KREAT-3: Osborn-Verfremdung (Quelle: Kramer)

Demonstrationsbeispiel Es wird der Ablauf einer Kreativsitzung, unter Verwendung der Kreativitätstechniken W-Technik und Brainstorming mit Osborn-Verfremdung, zu einem Problem der Benutzerbeteiligung bei der Systemplanung (vgl. Lerneinheit BEBET im Band "Informationsmanagement") dargestellt. Problemdefinition mittels W-Technik • Erster Arbeitsschritt: Spontandefinition. "Wie kann ich erreichen, daß zukünftige Benutzer Teile ihrer Freizeit für die Beteiligung am Systemplanungsprozeß opfern?" • Zweiter Arbeitsschritt: Umformulierung. "Warum sollen Benutzer in ihrer Freizeit an einem Systemplanungsprozeß mitwirken?"

312

Methoden und Techniken der Vorstudie

• Dritter Arbeitsschritt: Antworten. Erste Antwort: "Weil sie ein langfristiges Mitspracherecht bei der Gestaltung des Informationssystems erwarten." Zweite Antwort: "Weil sie in den Genuß des Ansehens bei den nicht am Systemplanungsprozeß beteiligten Mitarbeitern kommen wollen." Dritte Antwort: "Weil sie ein Interesse an der Qualität des Anwendungssystems haben." • Vierter Arbeitsschritt: Problemdefinition (zur zweiten Antwort): "Wie kann ich erreichen, daß Benutzer zur Beteiligung motiviert werden?" • Fünfter Arbeitsschritt: Eignungsprüfung und Rückkopplung. Die Problemdefinition wird als ausreichend operational beurteilt. Es wird offengelassen, ob zu einem späteren Zeitpunkt die erste Antwort aus dem dritten Arbeitsschritt in die Problemlösung einbezogen wird. Ideenfindung mit Brainstorming und Osborn-Verfremdung • Erster Arbeitsschritt: Vereinbarung der Grundregeln. Die weiter oben genannten Brainstorming-Grundregeln und eine Reihe weiterer Verhaltensregeln werden als "Spielregeln" vereinbart. • Zweiter Arbeitsschritt: Ideengenerierung. Der gruppendynamische Prozeß ist in seiner Simultanität schriftlich nicht abbildbar. Aus Platzgründen wird auf eine taxative Aufzählung der Problemlösungsideen an dieser Stelle verzichtet. • Dritter Arbeitsschritt: Verfremdung. Durch Anwendung der Osborn-Technik werden unter anderem folgende drei Ideen erarbeitet: * Idee 1. "Den Beteiligten bestimmte Kompetenzen im Benutzerservice geben und ihnen Privilegien einräumen." * Idee 2. "Den Beteiligten eine Prämie zahlen und ihnen den kostenlosen Besuch von Weiterbildungsseminaren ermöglichen." * Idee 3. "Den Beteiligten die Möglichkeit geben, den anderen Mitarbeitern zweimal wöchentlich über den Fortgang des Projekts zu berichten und bei unterschiedlichen Auffassungen einen Mehrheitskonsens herzustellen." • Vierter Arbeitsschritt: Ideenbewertung. Es werden die Kriterien Zeitbedarf, Personalbedarf und Kosten vereinbart, und die drei Lösungsideen werden hinsichtlich dieser Kriterien ordinal bewertet. Die Anwendung der Rangordnungssummenregel (vgl. Lerneinheit NUTZW) ergibt eine Präferenz für Idee 1, die bei den Kriterien "Zeitbedarf' und "Kosten" den ersten, beim Kriterium "Personalbedarf den zweiten Rang erhalten hat. Abbildung KREAT-4 zeigt das Ergebnis der Ideenbewertung. Ideen Kriterien^^^

Idee 1

Idee 2

Idee 3

Zeitbedarf

1

3

2

Personalbedarf

2

1

3

Kosten

1

3

2

Summe

4

7

7

Abb. KREAT-4: Ergebnis der Ideenbewertung

KREAT - Kreativitätstechniken

313

Forschungsbefunde Cyert/March

wiesen schon 1963 empirisch folgendes nach:

• Erfolgreiches Verhalten prägt sich ein und wird beibehalten ("Routineverhalten"). • Neue Regeln werden gesucht, wenn sich die Umwelt verändert. • Die Suche nach neuen Regeln findet in der Nachbarschaft der alten Regeln und des alten Problemsymptoms statt. • Es wird eine befriedigende (nicht die optimale) Lösung gesucht. • Es werden die Erfahrungen anderer berücksichtigt. Die Aussagen verdeutlichen, daß kreatives Problemlösungsverhalten den Regelfall darstellt; sie weisen auf die Bedeutung kreativen Problemlösens und damit auf die Bedeutung von Kreativitätstechniken zum Problemlösen hin. Der Mediziner R. W. Sperry vom California Institute of Technology, Pasadena/USA, wies Anfang der sechziger Jahre folgendes nach: Im linken Teil des menschlichen Großhirns haben die intellektuellen Fähigkeiten, im rechten Teil hat die Kreativität ihren Sitz. Die linke Gehirnhälfte arbeitet mit Begriffen und kann sich verbal mitteilen; die rechte dagegen ist sprachlos und arbeitet mit Bildern und Analogien. Diese Tatsache erklärt, warum in der Vergangenheit menschliche Intelligenz mit Sprachintelligenz gleichgesetzt wurde, während die Bedeutung der nicht-sprachlichen Formen der Intelligenz kaum wahrgenommen wurde, und daß Kreativität nur durch ganzheitliches Denken gefördert werden kann. Hilfsmittel dazu sind Kreativitätstechniken. Aufgaben verweise Entwerfen der Grundkonzeption (Lerneinheit G R U N D ) . Kontrollfragen 1. 2. 3. 4. 5.

Wodurch unterscheiden sich rationales und kreatives Problemlösen? Welche Aufgaben der Vorstudie sind gut strukturiert? Mit welchen Arbeitsschritten geht die W-Technik zur Problemdefinition vor? Welches sind die vier Grundregeln des Brainstormings? W o z u dienen die Verfremdungsmöglichkeiten nach Osborn?

Quellenliteratur Cyert, R. M. and March, B.: Behavioral Theory of the Firm. Englewood Cliffs/N.J. 1963 H o f f m a n n , H.: Kreativitätstechniken für Manager. 2. A., Verlag M o d e r n e Industrie, Landsberg 1987 Kramer, F.: Produktinnovation - Die Orientierung Band 66. Schweizerische Volksbank, Bern 1 9 8 4 , 8 7 - 102 Vertiefungsliteratur Brandstätter, H.: Problemlösen und Entscheiden in Gruppen. In: Roth, E. (Hrsg.): Enzyklopädie der Psychologie, Band Organisationspsychologie. Verlag Hogrefe, Göttingen 1989, 505 - 528 Liebele, H.: Zur Praxis der Kreativitätstechniken - Anwendungserfahrungen bei der Produktinnovation. In: Die Betriebswirtschaft 6/1988, 777 - 785

KONSA - Konsequenzanalyse Lernziele Sie kennen den Zweck der Konsequenzanalyse und können die Vorgehensweise bei der Konsequenzanalyse beschreiben. Sie kennen die grundlegenden Methoden, die für das Ermitteln der Konsequenzen alternativer Systemkonzepte angewendet werden. Sie können die Zweckmäßigkeit dieser Methoden in bezug auf bestimmte Planungsziele beurteilen. Definitionen und Abkürzungen Befragung (questioning) = ein zielgerichteter, sozialer Vorgang der Interaktion zwischen Individuen (Frager und Befragter) zur Erhebung von Daten in einem bestimmten Kontext. Beobachtung (Observation) = die Erhebung von Daten über die Realität durch einen Beobachter ohne gewollten Eingriff in die Realität; man unterscheidet Dauerbeobachtung und unterbrochene Beobachtung. Beobachtungsexperiment (Observation experiment) = ein Experiment, das -im Unterschied zu einem Laborexperiment - unter "Feldbedingungen" stattfindet und sich der Beobachtung als Erhebungsmethode bedient. D u r c h l a u f z e i t (througput time) = der Zeitraum zwischen dem Zeitpunkt des Prozeßanstoßes und dem Zeitpunkt der Fertigstellung der Informationsleistung für bürowirtschaftliche Aufgaben; eine Maßzahl für Produktivität. Experiment (experiment) = das zielgerichtete Experimentieren an der Realität ("Feldexperiment") oder an einem physischen Modell der Realität ("Laborexperiment"). Experte (expert) = ein gut informierter Fachmann, der zum Befragungsthema über fundierte Kenntnisse verfügt und der eine verläßliche Meinung hat. Konsequenz (consequence) = die Auswirkung, das Ergebnis, die Folge usw. einer Alternative bezüglich eines Planungsziels, dargestellt als Zielertrag. Matrix (matrix) = ein orthogonales, in Zeilen und Spalten strukturiertes Schema; die m Zeilen und n Spalten bestimmen die Dimension ("Typ") der Matrix. Nutzwertanalyse (value benefit analysis) = eine Methode zur mehrdimensionalen Bewertung von Alternativen und zur Auswahl der optimalen Alternative. R a t i n g - M e t h o d e (rating technique) = ein Schätzverfahren, bei dem Experten zur Abgabe von Urteilen und zu deren Abbildung auf einer meist ordinalen Skala veranlaßt werden. Simulation (Simulation) = das zielgerichtete Experimentieren an einem logischen Modell der Realität. Vorgangsbearbeitungssystem (workflow management system) = ein Anwendungssystem zur Unterstüzung von Arbeitsabläufen, die durch einen hohen Anteil an Kooperation gekennzeichnet sind. Zielertrag (goal profit) = die Konsequenz einer Alternative bezüglich eines Zielkriteriums. Synonyme: Zielerreichungsgrad, Ausmaß der Zielerreichung.

KONSA - Konsequenzanalyse

315

Zweck der Konsequenzanalyse Mit der Konsequenzanalyse werden die Auswirkungen, die Ergebnisse, die Folgen usw. von Alternativen bestimmt. In der Vorstudie sind die entworfenen, alternativen Systemkonzepte (vgl. Lerneinheit GRUND) die zu untersuchenden Alternativen. Mit der Konsequenzanalyse werden für jedes alternative Systemkonzept Ai und für jedes Planungsziel Zj (vgl. Lerneinheiten SACHZ und FORMZ) Konsequenzen als Zielerträge kjj ermittelt, um letztlich zu einem Gesamturteil über jedes untersuchte Systemkonzept im Hinblick auf die vorgegebenen Planungsziele zu gelangen. Abbildung KONSA-1 veranschaulicht die Struktur der Konsequenzanalyse in Form einer Matrix.

Alternative Systemkonzepte

k ij = Konsequenz der Alternative i bezüglich Planungsziel j

Planungsziele

Ai

Zj

kij

Abb. K O N S A - 1 : Struktur der Konsequenzanalyse

Aufgabenträger für die Durchführung der Konsequenzanalyse sind in erster Linie die Systemplaner; sie ermitteln mit einer geeigneten Vorgehensweise und unter Anwendung bestimmter Methoden die Konsequenzen der alternativen Systemkonzepte. Zweckmäßig ist die Hinzuziehung des Controllers und des Revisors (vgl. Lerneinheiten CONTR und REVIS im Band "Informationsmanagement"), damit die alternativen Systemkonzepte auch unter Controlling- und Revisionszielen beurteilt werden können. Vorgehensweise bei der Konsequenzanalyse Die Vorgehensweise bei der Konsequenzanalyse beschreibt "die Art und Weise", in der die Konsequenzen der alternativen Systemkonzepte ermittelt werden. Sie entspricht im wesentlichen der Nutzwertanalyse (vgl. Lerneinheit NUTZW). Die zu bewertenden Alternativen liegen als Zwischenergebnis der Aufgabe "Entwerfen der Grundkonzeption" (vgl. Lerneinheit GRUND) vor, das Zielsystem liegt als Ergebnis der Aufgaben "Sachzielplanung" (vgl. Lerneinheit SACHZ) und "Formalzielplanung" (vgl. Lerneinheit FORMZ) vor. Im Mittelpunkt der Konsequenzanalyse stehen die Methoden und Techniken, mit denen die Zielerträge ermittelt werden ("Zweiter Schritt der Nutzwertanalyse"). In Abhängig-

316

Methoden und Techniken der Vorstudie

keit davon, wie präzise die Planungsziele vorgegeben sind, können zwei Varianten zum Ermitteln der Zielerträge unterschieden werden. • Erste Variante: Sind die Planungsziele nur bezüglich des Zielinhalts (also nicht bezüglich des Ausmaßes und des zeitlichen Bezugs der Zielerreichung) definiert, dann geht es lediglich um die relative Ordnung der alternativen Systemkonzepte und letztlich darum, welches in dem nach Zielinhalten der Planungsziele vorgegebenen Zielsystem das optimale Systemkonzept ("Grundkonzeption") ist. Folglich sind relative Urteile für die Bewertung der Alternativen im Zielsystem ausreichend; der Aufwand für die Ermittlung der Konsequenzen wird drastisch reduziert. Dies schließt aber nicht aus, Zielerträge auch zu messen und auf der Grundlage von Meßergebnissen relative Urteile zu fällen. (In der Konsequenzanalyse, die im Demonstrationsbeispiel gezeigt wird, wurde so vorgegangen; durch Anwendung einer Entscheidungsregel auf die in Abbildung KONSA-4 nominal skalierten Werturteile kann die optimale Alternative bestimmt werden.) • Zweite Variante: Sind die Planungsziele nicht nur bezüglich des Zielinhalts, sondern auch bezüglich des Ausmaßes und des zeitlichen Bezugs der Zielerreichung definiert, dann ist nicht die relative Ordnung der Alternativen im Zielsystem von primärem Interesse, sondern es sind Aussagen über das vorgegebene Ausmaß und den zeitlichen Bezug der Zielerreichung der Alternativen erforderlich. Nur wenn mehrere Alternativen das vorgegebene Ausmaß und den zeitlichen Bezug der Zielerreichung für alle Ziele erfüllen, ergibt sich das bei der ersten Variante genannte Ordnungsproblem. Für den Fall, daß keine der untersuchten Alternativen das vorgegebene Ausmaß und den zeitlichen Bezug der Zielerreichung für alle Ziele erfüllt, müssen entweder weitere Alternativen entworfen werden, oder es muß das definierte Anspruchsniveau reduziert werden. Methoden der Konsequenzanalyse Daß für das Festlegen der Planungsziele in der Vorstudie die Angabe des Zielinhalts nicht ausreichend ist, wurde an anderer Stelle erläutert (vgl. Lerneinheit ZAMVS). Daraus folgt, daß eine Vorgehensweise nach der zweiten Variante zu bevorzugen ist. Unabhängig davon, welche Vorgehensweise angewendet wird, sind M e t h o d e n erforderlich, mit denen die Konsequenzen der Alternativen in bezug auf jedes Planungsziel ermittelt werden können. Welche Methoden für die Konsequenzanalyse verwendet werden können, hängt in erster Linie von der Art der zu untersuchenden Alternativen und vom Inhalt des Planungsziels, für das die Konsequenzen zu ermitteln sind, ab. Da die Art der zu untersuchenden Alternativen im vorliegenden Zusammenhang festliegt ("Systemkonzepte" eines Informationssystems), wird die Methodenauswahl primär v o m Inhalt des Planungsziels bestimmt. Stehen für die Ermittlung der Konsequenzen für den Inhalt eines Planungsziels mehrere alternative Methoden zur Verfügung, können formale Auswahlkriterien verwendet werden. Beispiele für formale Auswahlkriterien sind: • die Genauigkeit der Methode; • der Zeitbedarf für die Methodenanwendung;

KONSA - Konsequenzanalyse

317

• die für die Methodenanwendung erforderliche Personalqualifikation; • die Kosten der Methodenanwendung; • die Verfügbarkeit von Werkzeugen zur Erleichterung der Methodenanwendung. Folgende Methoden werden bei der Konsequenzanalyse angewendet: Beobachtung, Befragung, Experiment und Simulation. • Beobachtung: Konsequenzen von alternativen Systemkonzepten können durch Beobachtung ermittelt werden, wenn die Alternativen oder Teile der Alternativen bereits realisiert (z.B. in anderen Unternehmen installiert) und der Beobachtung zugänglich sind. • Befragung: Konsequenzen von alternativen Systemkonzepten können mit Befragung ermittelt werden, wenn die Alternativen oder Teile der Alternativen von Experten beurteilt werden können ("Expertenbefragung"). Eine Expertenbefragung kann mit den verschiedenen Formen des Ratings methodisch unterstützt werden ("Rating-Methode"), insbesondere mit der Delphi-Methode. Für bestimmte Planungsziele sind auch die Aufgabenträger der Systemplanung (vgl. Lerneinheit AUTER) Experten, z.B. die Benutzer für das Planungsziel Benutzerakzeptanz. • Experiment: Konsequenzen von alternativen Systemkonzepten können mit Laborexperimenten ermittelt werden, wenn die Alternativen oder Teile der Alternativen implementiert und als Labormodelle zur Verfügung gestellt werden können. Der Experimentator beherrscht und kontrolliert die im Labormodell abgebildete Realität vollständig; er kann alle Variablen verändern. Feldexperimente kommen in der Regel nicht in Frage. • Simulation: Konsequenzen von alternativen Systemkonzepten können mit Simulation ermittelt werden, wenn die Alternativen oder Teile der Alternativen modelliert und als Simulationsmodelle zur Verfügung gestellt werden können (vgl. Lerneinheit SIMUL). Typisch für die Konsequenzanalyse ist die kombinierte Anwendung mehrerer der genannten Methoden, zum Beispiel Beobachtung und Experiment ("Beobachtungsexperiment"). In der Konsequenzanalyse, über deren Ergebnisse in den Forschungsbefunden berichtet wird, wurde mit allen genannten Methoden gearbeitet. Als methodischer Rahmen für die Vorgehensweise bei der Konsequenzanalyse und als Methode für die Methodenauswahl kann die N u t z w e r t a n a l y s e (vgl. Lerneinheit NUTZW) verwendet werden. Unter Beachtung der Ziele der Vorstudie (vgl. Lerneinheit ZAMVS) sollten Methoden bevorzugt werden, die bei einer ausreichenden Genauigkeit mit einem möglichst geringen Einsatz an Zeit, Personal, Kosten usw. verwendet werden können. Dies weist auch darauf hin, daß die Entwicklung von Methoden oder die grundlegende Veränderung von Methoden für einzelne IuK-Projekte im allgemeinen unzweckmäßig ist. Geringfügige Anpassungen vorhandener Methoden sind in der Regel vorzuziehen. Insbesondere dann, wenn die Systemkonzepte die Verwendung einer neuen Technologie vorsehen (z.B. Vorgangsbearbeitungssysteme), ist der Rückgriff auf Forschungsbefunde der einzig gangbare Weg, um zu verläßlichen Aussagen über die Konsequenzen zu bestimmten Planungszielen (z.B. die Durchlaufzeit für einen Vorgang) zu kommen.

318

Methoden und Techniken der Vorstudie

Methodenauswahl

Sicherheit

Wirksamkeit

Produktivität

X

X

Experiment Simulation

X

X

Beobachtung Befragung

Flexibilität

Methoden

Benutzbarkeit

Ny Planungsziele

Akzeptanz

Angenommen, für die in den Spalten der Matrix von Abbildung KONSA-2 genannten Planungsziele sollen die Konsequenzen ermittelt werden, und die in den Zeilen der Matrix von Abbildung KONSA-2 genannten Methoden stehen zur Verfügung. Die nominalen Eintragungen zeigen das Ergebnis der Methodenauswahl. Die Eintragungen bedeuten, daß primär mit der bezeichneten Methode zum bezeichneten Planungsziel Konsequenzen ermittelt werden; dies schließt Beiträge durch andere Methoden nicht aus. So werden Konsequenzen zum Planungsziel "Benutzbarkeit" primär durch Beobachtung ermittelt; ergänzende Aussagen können durch Befragung erfaßt werden. Konsequenzen zum Planungsziel "Produktivität" können im allgemeinen nur durch Experimente verläßlich ermittelt werden; zusätzliche Aussagen, die durch Expertenbefragung gewonnen werden, sind denkbar. Für die Ermittlung von Konsequenzen zum Planungsziel "Flexibilität" eignet sich die Simulation am besten; Aussagen zu diesem Planungsziel können auch durch Experimente gewonnen werden.

X

X

Abb. K O N S A - 2 : Eignung der Methoden für bestimmte Planungsziele

Demonstrationsbeispiel Es werden Ergebnisse eines Laborexperiments gezeigt, mit dem die Konsequenzen von zwei alternativen Systemkonzepten auf die Sachziele Funktionen ("Verfügbarkeit von Funktionen") und Leistungen ("Leistung von Funktionen") sowie auf die Formalziele Wirksamkeit, Flexibilität, Produktivität, Akzeptanz, Kosten und Wirtschaftlichkeit ermittelt wurden. Dabei wurde auch versucht, die Beziehungen zwischen diesen Zielen im Zielsystem zu erfassen. Zusätzlich zum Experiment wurde die Befragung verwendet, da im Experiment auch mit "Versuchspersonen" als Aufgabenträger gearbeitet wurde. Abbildung KONSA-3 zeigt das Zielsystem für die Konsequenzanalyse. Die aus den Komponenten Techniksystem, Strukturorganisation, Ablauforganisation und Aufgabenträger bestehenden alternativen Systemkonzepte unterschieden sich im wesentlichen durch die Art des Techniksystems. Systemkonzept A verwendete nicht vernetzte Arbeitsstationen ("Stand-alone-System"), Systemkonzept

KON SA - Konsequenzanalyse

319

B lokal vernetzte Arbeitsstationen ("LAN-System"). Abbildung KONSA-4 zeigt die Ergebnisse der Konsequenzanalyse.

Abb. KONSA-3: Zielsystem für die Konsequenzanalyse (Quelle: nach Heinrich/Ambichl)

Stand-Alone-System

LAN-System

geringer

höher

höher

geringer

Wirksamkeit

geringer

höher

Flexibilität

geringer

höher

etwa gleich hoch

etwa gleich hoch

höher

geringer

geringer

höher

höher

geringer

Ziele Verfügbarkeit von Funktionen Leistung von Funktionen

Produktivität Akzeptanz Kosten Wirtschaftlichkeit

Abb. KONSA-4: Ergebnisse der Konsequenzanalyse (Quelle: nach Heinrich/Ambichl)

320

Methoden und Techniken der Vorstudie

Die Bewertungsergebnisse beziehen sich auf konkrete Alternativen, können also z.B. nicht in dem Sinn verallgemeinert werden, daß ein LAN-System im Vergleich zu einem Stand-alone-System generell weniger wirtschaftlich ist. Folgende Schwachstellen des untersuchten LAN-Systems wurden durch das Laborexperiment identifiziert: • die Verwendung nicht voll kompatibler Arbeitsstationen (negativer Einfluß auf die Verfügbarkeit); • die nicht vorhandene Mailbox-Funktion (negativer Einfluß auf Flexibilität und Wirksamkeit); • die langen Durchlaufzeiten und die hohen Ausfallraten bei der Verwendung der Datenbankfunktionen (negativer Einfluß auf Leistung und Akzeptanz). Forschungsbefunde AmbichllHeinrich berichten über Befunde von Konsequenzanalysen, mit denen zwei Systemkonzepte in Client/Server-Architektur, nämlich File-Server und Datenbank-Server, im Laborexperiment untersucht wurden; als Untersuchungsmethoden wurden auch Simulation und Benchmarks verwendet. Zusammenfassend wird folgendes festgestellt: Bei hoher Arbeitslast sind die A n t w o r t zeiten des File-Servers um 187% länger als die Antwortzeiten des DatenbankServers, und die Durchsatzraten des Datenbank-Servers sind um 179% höher als die Durchsatzraten des File-Servers. Diese Überlegenheit des Datenbank-Servers gegenüber dem File-Server wird jedoch nur dann erreicht, wenn gespeicherte SQL-Befehle verwendet werden. Ohne Verwendung von gespeicherten SQL-Befehlen ist die Leistung des Datenbank-Servers nur um 32% höher als die Leistung des File-Servers. Während der File-Server bei allen durchgeführten Versuchen nicht ausfiel, kam es beim Datenbank-Server bei hoher Arbeitslast und fünf aktiven Arbeitsstationen zu einem Ausfall. Die Ausfallsicherheit des Datenbank-Servers ist damit geringer als die des File-Servers. Abbildung KONSA-5 visualisiert beispielhaft die Befunde zu den Antwortzeiten. 3,50 3,00 2,50

2,57

2,51

2,00

O File-Server

1,50

B - Datenbank-Server

1,00 ih 0,50

0,00 AS

2 AS

3 AS

4 AS

5 AS

aktive Arbeitsstationen Abb. KONSA-5: Vergleich der Antwortzeiten (relativ)

KONSA - Konsequenzanalyse

321

Aufgabenverweise Entwerfen der Grundkonzeption (Lerneinheit GRUND). Kontrollfragen 1. 2. 3. 4. 5.

Welchen Zweck hat die Konsequenzanalyse? Welche Vorgehensweise kann bei der Konsequenzanalyse angewendet werden? Welche Methoden zur Ermittlung von Konsequenzen gibt es? Für welche Planungsziele eignen sich welche Methoden zur Ermittlung der Konsequenzen für diese Planungsziele. Welche Methoden wurden bei der in den Forschungsbefunden referierten Konsequenzanalyse verwendet?

Quellenliteratur Ambichl, E. und Heinrich, L. J.: Leistungsbewertung dialogorientierter Datenbanksysteme in Client/Server-Architekturcn. In: Information Management 3/1992,24 - 31 Ambichl, E. und Gappmaier, M.: Nicht vernetzte PCs versus lokale Netzwerke - eine Vergleichsstudie. In: Information Management 1/1989, 38 - 43 Heinrich, L. J. und Ambichl, E.: Ein Modell zur Unterstützung strategischer TechnologieeinsatzEntscheidungen. In: Information Management 3/1988,44 - 52 Vertiefungsliteratur Ambichl, E.: Leistungsbewertung dialogorientierter Datenbanksysteme in Client/Server-Architektur. Dissertation Universität Linz, Linz 1991 Heinrich, L. J. und Reindl, M.: Leistungsbewertung von Datenbank-Server-Systemen. In: Frisch, W. und Taudes, A. (Hrsg.): Informationswirtschaft. Aktuelle Entwicklungen und Perspektiven. Physica Verlag, Heidelberg 1993, 231 - 246 Roth, M. (Hrsg.): Sozialwissenschaftliche Methoden. 2. A., Oldenbourg Verlag, München/Wien 1987

PROME - Methoden des Projektmanagements Lernziele Sie kennen Methoden des Projektmanagements, die geeignet sind, die Projektplanung, Projektüberwachung und Projektsteuerung zu unterstützen und die Methoden der Netzplantechnik zu ergänzen. Sie können die Zweckmäßigkeit der Anwendung dieser Methoden beurteilen. Sie erkennen die Notwendigkeit und Möglichkeit, mit geeigneten Methoden die Zusammenhänge zwischen Terminzielen, Kostenzielen und Leistungszielen darzustellen. Sie können mit Hilfe dieser Methoden einen Projektzustand beurteilen. Definitionen und Abkürzungen Abweichung (deviation) = der Unterschied zwischen dem geplanten Grad der Zielerreichung ("Soll") und dem tatsächlichen Grad der Zielerreichung ("Ist"). Arbeitswert (work Standard) = ein Leistungsziel, das zu einem bestimmten Plantermin und mit bestimmten Plankosten erreicht werden soll. Brook'sches Gesetz (Brook's law) = "Adding manpower to a late Software project makes it later". - Das Hinzuziehen weiterer Bearbeiter zu einem in Terminnot geratenen Software-Projekt verzögert es noch mehr. Diagramm (diagram) = die grafische Darstellung der Beziehungen zwischen zwei oder mehreren Größen mit dem Ziel der besseren Veranschaulichung und Erkennbarkeit der Zusammenhänge. Kontrolle (audit) = ein Soll/Ist-Vergleich durch prozeßabhängige Personen oder durch maschinell bzw. mechanisch wirkende Verfahren. Netzplan (network model) = das grafische Modell des Projektablaufs, dessen Darstellungsmittel der Graph ist. Netzplantechnik (network modeling technique) = die zusammenfassende Bezeichnung für die Methoden zur Beschreibung, Planung, Überwachung und Steuerung von Projekten mit Hilfe von Netzplänen. Projektbibliothek (project library) = ein Werkzeug zur Unterstützung der Systemplanung, insbesondere der Entwicklung von Software, mit den Funktionen Produktverwaltung und Information für das Projektmanagement. Projektdokumentation (project documentation) = der Projektplan und die Angaben über den Projektverlauf ("Projekttagebuch"). Projektrisiko (project risk) = die Wahrscheinlichkeit des Nichteinhaltens von Projektzielen, insbesondere von Termin- und Kostenzielen. Risiko (risk) = die Wahrscheinlichkeit des Eintretens eines unerwünschten Ereignisses in einem bestimmen Zeitraum und der mit diesem Ereignis verbundene Schaden. Steuerung (control) = eine Maßnahme, welche die Einhaltung eines systemextem definierten Zustands durch systemexteme Eingriffe ermöglicht. Überwachung (monitoring) = die in die Teilaufgaben Revision und Kontrolle gegliederte betriebliche Aufgabe der Beobachtung und Beurteilung, deren Zweck es ist, Präventiv-, Korrektur- und Sicherheitswirkungen zu erzielen.

PROME - Methoden des Projektmanagements

323

Zweck der Methoden des Projektmanagements Aufgabe der Projektplanung ist die Prüfung der Realisierbarkeit der Anforderung an ein IuK-Projekt und die Herausarbeitung der organisatorischen, technischen, personellen und wirtschaftlichen Konsequenzen (vgl. Lerneinheit PROPL). Zweck der Methoden des Projektmanagements ist es, die Durchführung dieser Aufgabe sowie die davon ausgehenden Aufgaben der Projektüberwachung und Projektsteuerung zu unterstützen. IuK-Projekte sind im allgemeinen durch folgende Merkmale gekennzeichnet: • geringer Projektfreiheitsgrad, da die Projektziele durch die vorgegebenen Planungsziele bestimmt werden; • relativ kurze Projektlaufzeit (idealerweise wenige Wochen bis maximal ein Jahr); • hohes Zeitrisiko (Einhaltung von Terminzielen); • hohes Kostenrisiko (Einhaltung von Kostenzielen); • Konkurrenz zu anderen IuK-Projekten in bezug auf Ressourcen zur Projektabwicklung (Personal und Betriebsmittel); • keine isolierte Betrachtungsweise, sondern meist Schnittstellen zu anderen IuK-Projekten oder zu vorhandenen Informationssystemen. Je methodischer und systematischer IuK-Projekte geplant, überwacht und gesteuert werden, umso erfolgreicher wird deren Durchführung sein. Neben einer den ganzen Planungsprozeß begleitenden Projektdokumentation (vgl. Lerneinheit DOKUM) stehen für die Planung, Überwachung und Steuerung eine Reihe von Methoden und Techniken, teilweise auch leistungsfähige Werkzeuge, zur Verfügung. Methodischer Schwerpunkt ist die Netzplantechnik, die wegen ihrer Bedeutung für die gesamte Systemplanung bereits an anderer Stelle ausführlich dargestellt wurde (vgl. Lerneinheit NETZP). Im folgenden werden einige die Netzplantechnik ergänzende Methoden erläutert, und zwar Prüfliste, Balkendiagramm, Belastungsdiagramm und Zeit/Kosten/Fortschrittsdiagramm. Der Vollständigkeit halber wird auch auf die Darstellungsmethoden verwiesen (vgl. Lerneinheit DARST), von denen einige bestenfalls zur Unterstützung der Planung, Überwachung und Steuerung von IuK-Projekten verwendet werden können. Prüfliste Eine Prüfliste (auch: Checkliste, Frageliste) im Sinn der Projektplanung, -Überwachung und -Steuerung ist eine Aufzählung der Tätigkeiten, die bei der Abwicklung eines IuK-Projekts üblicherweise zu erledigen sind. Durch Verwendung der Prüfliste soll sichergestellt werden, daß bei der Aufgabenplanung (Strukturanalyse oder Strukturplanung im Sinn der Netzplantechnik) keine wesentliche Tätigkeit, die für die Abwicklung eines IuK-Projekts typisch ist, unbeachtet bleibt ("Muß-Charakter" der Tätigkeit). Prüflisten können Standard-Charakter haben, das heißt, sie können für die Planung, Überwachung und Steuerung von Routinevorhaben verwendet werden (z.B. Prüflisten für den Integrationstest und für die Installierung), oder auch ad hoc für ein einmaliges Vorhaben entwickelt werden. Im zweiten Fall werden sie bei der Projektplanung erarbeitet und dienen dem Projektleiter als Instrument der Projektüberwachung und der Projektsteuerung.

324

Methoden und Techniken der Vorstudie

Der Begriff Prüfliste wird vielfach auch für eine Aufzählung von Tätigkeiten mit Kann-Charakter verwendet. Dabei handelt es sich um möglichst umfassende und vollständige Aufzählungen, die für bestimmte IuK-Projekte von Bedeutung sein können. Durch "Abchecken" dieser Art von Prüflisten sollen Ideen und Anregungen für ein IuK-Projekt vermittelt werden, z.B. bezüglich der Kriterien, die der Qualitätssicherung dienen.

0

2

4

8

10

12

14

16

18

20

22Tage

Abb. PROME-1: Projektlaufzeit im Balkendiagramm (Quelle: Kummer et al.)

Balkendiagramm Das Balkendiagramm ist ein Hilfsmittel zur Darstellung der zeitlichen Anordnung der einzelnen Tätigkeiten eines IuK-Projekts und damit der Projektlaufzeit. Sein Vorteil liegt in der großen Anschaulichkeit. Nachteil ist, daß die logischen Abhängigkeiten zwischen den Tätigkeiten nicht ersichtlich sind. Außerdem ist die Darstellung des aktuellen Projektzustands in Form eines Balkendiagramms relativ aufwendig. Deshalb empfiehlt sich die Verwendung des Balkendiagramms in Verbindung mit dem Netzplan. Ein Netzplan kann in ein Balkendiagramm transformiert werden (umgekehrt ist dies nicht möglich); die Information über die logischen Abhängigkeiten zwischen den Tätigkeiten geht dabei verloren. Abbildung PROME-1 zeigt die zeitliche Anordnung der Tätigkeiten und die Projektlaufzeit in Form eines Balkendiagramms. Die Tätigkeiten A bis L sind mit ihrer Zeitdauer über der Zeitachse zwischen 0 und 22 Tage nach dem frühest möglichen Beginnzeitpunkt angeordnet. Belastungsdiagramm Zur Kapazitätsplanung eines IuK-Projekts kann aus den Angaben des Netzplans (Anzahl der Betriebsmittel und Zeitbedarf je Tätigkeit) ein Belastungsdiagramm erstellt werden. Für jede Tätigkeit wird berechnet, wieviele Betriebsmittel erforderlich sind. Die Fläche aus dem Produkt Betriebsmittel mal Zeitbedarf wird in das Belastungsdiagramm eingetragen. Abbildung PROME-2 zeigt ein Beispiel.

PROME - Methoden des Projektmanagements

325

Abb. PROME-2: Belastungsdiagramm (Quelle: Kummer et al.)

Zeit/Kosten/Fortschritts-Diagramm Dieses Diagramm ist ein Hilfsmittel zur Darstellung der Terminsituation, der Kostensituation und des Arbeitsfortschritts in einem IuK-Projekt. Ein Zeit/Kosten-Diagramm allein ist wenig aussagekräftig, da es nur Aussagen über die Kosten liefert, die bis zu einem bestimmten Zeitpunkt entstanden sind, und nichts über den Arbeitsfortschritt aussagt. Mit anderen Worten: Mit einem Zeit/Kosten-Diagramm wird lediglich eine Beziehung zwischen Terminzielen und Kostenzielen hergestellt; zur Beurteilung des Projektzustands sind jedoch die Beziehungen zwischen Terminzielen, Kostenzielen und Leistungszielen erforderlich. Bei der Projektplanung werden daher die Beziehungen zwischen Termin- und Kostenzielen einerseits und Leistungszielen andererseit durch Arbeitswerte definiert. Ein Vergleich der tatsächlich erreichten Arbeitswerte mit den geplanten Arbeitswerten ermöglicht Aussagen über Abweichungen, die aus dem Zeit/Kosten/Fortschritts-Diagramm entnommen werden können.

326

Methoden und Techniken der Vorstudie

Abbildung PROME-3 zeigt ein Zeit/Kosten/Fortschritts-Diagramm. Die dick gezeichnete Linie stellt den geplanten Zustand als Arbeitswerte, die gestrichelte Linie die Ist-Kosten und die punktierte Linie den Ist-Zeitbedarf dar. Beispielsweise zeigt die Differenz zwischen A5 und A5' die Kostenüberschreitung und die Differenz zwischen A4 und A4' den Zeitverzug des Projekts zum Zeitpunkt Z5. Kontrolle der Projektqualität Zeiten, Kosten und Termine sind quantitative Größen und damit erfaßbar und kontrollierbar. Die Qualität der Projektarbeit entzieht sich jedoch einer quantitativen Erfassung. Orientierungsrahmen f ü r die Projektsteuerung und für die Projektkontrolle sind jene Qualitätskriterien, die im Rahmen der Projektplanung festgelegt worden sind. Für die Durchführung der Kontrollaufgaben gibt es folgende Möglichkeiten: die periodische Einblicknahme, die Entwurfsinspektion und das strukturierte Gruppengespräch. • Die periodische Einblicknahme wird vom Projektleiter selten konsequent durchgeführt. Häufig werden die Projektmitarbeiter nur mit den Worten "Na, wie steht's?" nach dem Projektzustand gefragt; eine weitere Einblicknahme unterbleibt. Die periodische Einblicknahme und die Diskussion von wesentlichen Arbeitsergebnissen ist Aufgabe des Projektleiters. • Die Entwurfsinspektion ist eine spezielle Form der Einblicknahme. Sie geht von der Annahme aus, daß eine Lösung umso besser ist, je weniger Planungsfehler sie enthält. Aus diesem Grund wird nach dem Systementwurf eine Entwurfsinspektion durchgeführt, bei der die Erfüllung der funktionalen Anforderungen, die Berücksichtigung von Fehlersituationen und Ausnahmebedingungen und die Güte des Entwurfs beurteilt werden. • Das strukturierte Gruppengespräch geht über die Entwurfsinspektion hinaus und verlangt vom Projektleiter, daß er allein oder zusammen mit Experten nach jeder Projektphase die Ergebnisse in strukturierter Form begutachtet. Das heißt, daß in der Projektplanung für jede Phase festgelegt werden muß, was wann zu überprüfen und damit Gegenstand des Gesprächs mit der Projektgruppe ist. Demonstrationsbeispiel Es wird die zentrale Bedeutung des Arbeitswerts erläutert, der in einem von der Telefunken Systemtechnik Ulm eingesetzten Projektmanagement-System verwendet wird. Mit Hilfe des Arbeitswerts ist es möglich, den Projektfortschritt in Beziehung zu den Projektkosten zu bringen und Abweichungen der Istwerte von den Planwerten rechtzeitig zu erkennen. Der Arbeitswert ist eine in Geldeinheiten ausgedrückte Größe, die auf der Basis von erbrachten Leistungen, unter Zuhilfenahme von Ist-Terminen oder realisierten Mengen, den Arbeitsfortschritt für ein Arbeitspaket zu einem bestimmten Stichtag anzeigt. Die Summe aller Arbeitswerte ergibt eine Aussage über den Projektfortschritt. Um den Arbeitswert ermitteln zu können, müssen zu Projektbeginn geplant werden: • die Aufgabe für das Arbeitspaket und das abzuliefernde Ergebnis; • das Budget für das Arbeitspaket und seine Aufteilung auf Kostenarten;

PROME - Methoden des Projektmanagements

• • • •

327

(wie Personal, Material, Hardware, Software); die Zeitdauer für das Arbeitspaket (Beginn- und Endetermin); die zeitliche Verteilung der Kostenarten in einem Monatsraster; die Methode der Arbeitswertermittlung; die Meldung der Istwerte.

Kosten in T D M

S = Soll (Soll-Kosten der geplanten Arbeiten) AW = Arbeitswert (Soll-Kosten der erledigten Arbeiten) 1 = Ist (Ist-Kosten der erledigten Arbeiten)

LA = Leistungsabweichung KA = Kostenabweichung

Abb. PROME-4: Arbeitswertdarstellung (Quelle: Zur)

Damit besteht ein geplanter Arbeitsfortschritt ("Soll"), der mit dem tatsächlichen Arbeitsfortschritt ("Arbeitswert") verglichen wird. Aus der Differenz ergibt sich die Leistungsabweichung. Ein Vergleich zwischen dem tatsächlichen Arbeitsfortschritt ("Arbeitswert") und den Ist-Kosten ergibt die Kostenabweichung. Herkömmliche Soll/Ist-Vergleiche sind lediglich eine Gegenüberstellung von Geldgrößen; sie verfälschen die Aussagen im Hinblick auf eine Frühwarnung vor Projektabweichungen und deren Umsetzung in die Projektsteuerung. Abbildung PROME-4 zeigt den Unterschied zwischen herkömmlichen Soll/Ist-Vergleichen und dem Arbeitswertverfahren. Insbesondere ist erkennbar: • Am Stichtag liegen die Ist-Kosten unter den Soll-Kosten und signalisieren eine nicht vorhandene Übereinstimmung des tasächlichen mit dem geplanten Projektverlauf.

328

Methoden und Techniken der Vorstudie

• Durch Einführung des Arbeitswerts wird deutlich, daß am Stichtag eine Leistungsabweichung vorliegt, die am Projektende zu einem Zeitverzug und zu einer Kostenüberschreitung führen wird. Aufgabenverweise Projektplanung (Lerneinheit PROPL). Kontrollfragen 1. 2. 3. 4. 5.

Welchen Zweck haben die Methoden der Projektplanung? Wie ergänzen sich Netzplan und Balkendiagramm? Welche Beziehungen werden durch ein Zeit/Kosten/Fortschritts-Diagramm aufgedeckt? Wie kann die Qualität in einem Projekt überwacht werden? Welche Informationen sind für einen Bericht über den Projektstatus unverzichtbar?

Quellenliteratur Daenzer, W. F. (Hrsg.): Systems Engineering. Leitfaden zur methodischen Durchführung umfangreicher Planungsvorhaben. 4. A., Hanstein Verlag, Köln, und Verlag Industrielle Organisation, Zürich 1985 Heilmann, H.: Das Management von Softwareprojekten. In: Handbuch der Modemen Datenverarbeitung 116/1984. Forkel Verlag, Stuttgart/Wiesbaden 1984, 3 - 22 Kummer, A., Spühler, R. W. und Wyssen, R.: Projekt Management. Leitfaden zu Methode und Teamführung in der Praxis. Verlag Industrielle Organisation, Zürich 1986 Zur, E.: Strukturierung komplexer Führungsaufgaben und Systemaufbau. In: Spremann, K. und Zur, E. (Hrsg.): Informationstechnologie und strategische Führung. Gabler Verlag, Wiesbaden 1989,81 - 105 Vertiefungsliteratur Cave, W. C. und Maymon, G. W.: Leitfaden des Software-Projektmanagements. Forkel Verlag, Wiesbaden 1988 Platz, J. und Schmelzer, H. J.: Projektmanagement in der industriellen Forschung und Entwicklung - Einführung anhand von Beispielen aus der Informationstechnik. Springer Verlag, Berlin et al. 1986 Wischnewski, E.: Modernes Projektmanagement - Eine Anleitung zur effektiven Unterstützung der Planung, Durchführung und Steuerung von Projekten. Vieweg Verlagsgesellschaft, Braunschweig 1991

Der Prozeß der Feinstudie Strategische Informationssystem-Planung

i Planungsziele | Der Prozeß der Vorstudie ^Grundkonzeption f//y Der Prozeß der Feinstudie ! Angepaßte m ; Grundkonzeption %

B

Der Prozeß der Grobprojektierung 9^77777777777777777777777777777^

M

% Logisches Modell w m C / / , , , , ,Sollzustand , , , , , , , , ( , , , , , , , , , , , , ,m ,///. Der Prozeß der Feinprojektierung

ha

1U C3

£

I Physisches Modell> Sollzustand ? Der Prozeß der Installierung 7777777777777777777777777777777^2

's, Produktives ip i Informationssystem^

330

Der Prozeß der Feinstudie

Gegenstand dieses Kapitels ist der Teil des kooperativen und kreativen Arbeitsprozesses Systemplanung, der nach dem in diesem Lehrbuch verwendeten Phasenmodell als Feinstudie bezeichnet wird. Ausgehend vom Ziel der Feinstudie, werden im ersten Teil des Kapitels ihre Aufgaben entwickelt und die zur Unterstützung der Aufgabendurchführung verwendeten Methoden und Techniken charakterisiert. Anschließend werden die Aufgaben der Feinstudie im Detail erläutert. Im zweiten Teil des Kapitels werden die Methoden und Techniken der Feinstudie dargestellt. Die Zusammenhänge zwischen den Aufgaben der Feinstudie einerseits und ihren Methoden und Techniken andererseits werden durch Methodenverweise bzw. Aufgabenverweise verdeutlicht. Ergebnis der Feinstudie ist die angepaßte Grundkonzeption des zu schaffenden Informationssystems; sie ist die Schnittstelle zur Grobprojektierung.

Aufgaben der Feinstudie ZAMFS ERIST ANIST AFEIN

-

Ziel, Aufgaben und Methodik der Feinstudie Erfassen des Istzustands Analysieren des Istzustands Auswerten der Feinstudie

331 338 345 354

Methoden und Techniken der Feinstudie VFEIN ISTER ZERFA ISTAN KOMAN

-

Vorgehensweise bei der Feinstudie Methoden der Istzustandserfassung Methoden der Zeiterfassung Methoden der Istzustandsanalyse Methoden der Kommunikationsanalyse

359 366 374 380 387

ZAMFS - Ziel, Aufgaben und Methodik der Feinstudie Lernziele Sie können die Zweckmäßigkeit der Feinstudie begründen und das Ziel dieser zweiten Phase der Systemplanung mit eigenen Worten wiedergeben. Sie können die Struktur der Feinstudie erläutern und ihre Aufgaben nennen. Sie können die Feinstudie anhand charakteristischer Merkmale beschreiben, insbesondere ihren interaktiven und dualen Charakter erklären. Sie kennen die Situation bezüglich der verfügbaren Methoden und Techniken in der Feinstudie. Definitionen und Abkürzungen Feinstudie (detailed systems survey) = die Untersuchung der organisatorischen, technischen, personellen und sozialen Bedingungen und Regelungen des bestehenden Informationssystems im Rahmen der Grundkonzeption. Istzustand (current system) = die Gesamtheit der technischen, organisatorischen, personellen und sozialen Bedingungen und Regelungen eines bestehenden Informationssystems. Istzustandsanalyse (current system analysis) = das zielorientierte Untersuchen des Istzustands durch Zerlegen und das kritische Beurteilen des durch Untersuchen Festgestellten daraufhin, ob es bekannten Sollvorstellungen entspricht. Istzustandserfassung (current system survey) = die Festlegung der Attribute, die Ermittlung der Attributewerte und die Ordnung und Dokumentation der Attribute und Attributewerte des Istzustands. Synonym: Istzustandserhebung. Istzustandsoptimierung (current system optimization) = die Erarbeitung und Realisierung von kurzfristig wirksamen Maßnahmen zur Bessergestaltung des Istzustands. istzustandsorientierter Ansatz (current system-based approach) = eine Methodik der Systemplanung, die durch die Vorgehensweise "erst Istzustandserfassung, dann Istzustandsanalyse, dann Grobprojektierung" gekennzeichnet ist. Istzustandsuntersuchung (current system study) = die zusammenfassende Bezeichnung für Istzustandserfassung und Istzustandsanalyse. logisches Modell (logical model) = die Abbildung eines Systems, die vollständig von einer bestimmten Form der Implementierung abstrahiert, also keine physischen Attribute enthält, physisches Modell (physical model) = die Abbildung eines Systems, die eine bestimmte Form der Implementierung zum Gegenstand hat, also mit physischen Attributen belegt ist. Stärken-/Schwächen-Katalog (list of systems strengths/weaknesses) = die systematische Dokumentation der Stärken und Schwächen in einem Dokument. Sollzustand (target system) = die Gesamtheit der technischen, organisatorischen, personellen und sozialen Bedingungen und Regelungen des zu schaffenden Informationssystems, sollzustandsorientierter Ansatz (planned system-based approach) = eine Methodik der Systemplanung, die durch die Vorgehensweise "erst Grobprojektierung, dann Istzustandserfassung, dann Entwurfsanpassung" gekennzeichnet ist.

332

Aufgaben der Feinstudie

Ziel der Feinstudie Das generelle Sachziel der Systemplanung besteht darin, dem Anwender ein produktives Informationssystem zur Verfügung zu stellen. Entsprechend der Phasengliederung der Systemplanung (vgl. Lerneinheit ZAMSP) werden aus dem generellen Sachziel der Systemplanung die Ziele ihrer Phasen abgeleitet, hier also das Ziel der Feinstudie. Davon ausgehend werden die Aufgaben der Feinstudie bestimmt sowie die M e t h o d e n , Techniken und Werkzeuge zur Unterstützung der Aufgabendurchführung festgelegt. Untersuchungsobjekt der Feinstudie ist der Istzustand, der zunächst erfaßt ("Istzustandserfassung"), dann analysiert ("Istzustandsanalyse") und schließlich ausgewertet wird. An diese Feststellung knüpft sich die Frage, warum es angesichts des erklärten Ziels der Systemplanung, ein neues Informationssystem zu schaffen, zweckmäßig oder gar notwendig ist, eine Istzustandsuntersuchung durchzuführen. Folgende Argumente, die teilweise für, teilweise gegen die Istzustandsuntersuchung sprechen, können helfen, ein ausreichendes Verständnis für die Feinstudie zu entwickeln: • Die Bezeichnung Ist lenkt den Blick der Systemplaner auf die Gegenwart oder sogar auf die Vergangenheit; es besteht daher die Gefahr, daß sie den "Blick für die Zukunft" verlieren. • Die Istzustandserfassung kann für unerfahrene Systemplaner in Beschäftigungstherapie ausarten; es werden Daten erfaßt und analysiert, die im Hinblick auf die Erreichung der Planungsziele nutzlos sind. • Es können Datenfriedhöfe entstehen, in denen die Systemplaner die Orientierung verlieren; "weniger" wäre also "mehr" gewesen. • Je detaillierter die Istzustandsuntersuchung ist, desto länger dauert sie in der Regel; damit steigt die Wahrscheinlichkeit, daß die Aktualität verlorengeht; die erhobenen Daten bilden den Istzustand nicht ausreichend genau ab, weil sich dieser inzwischen verändert hat. • Die von einer Istzustandsuntersuchung "betroffenen Aufgabenträger" können diese als Kontrolle empfinden, mit Befürchtungen und Ängsten reagieren und damit ein Verhalten zeigen, das dem Istzustand nicht entspricht. • Die Abbildung des Istzustands ist immer ein physisches Modell, und die physischen Attribute können beim Erkennen der Stärken und Schwächen des Istzustands hinderlich sein. • Die Tatsache, daß der Istzustand mit physischen Attributen belegt ist, erleichtert es den Systemplanern, die Wirklichkeit zutreffend abzubilden; sie können das physische Modell also dazu benutzen, ein logisches Modell herauszuarbeiten, indem sie die physischen Attribute sukzessiv entfernen. • Die Analyse des Istzustands ist überhaupt nicht möglich, wenn keine ausreichend genauen Vorstellungen über den Sollzustand verfügbar sind. • Auch ein neues Informationssystem kann nicht "auf der grünen Wiese" geschaffen werden; es muß sich in den vorhandenen organisatorischen Kontext einfügen, der nicht verändert werden kann oder soll; dazu sind gute Kenntnisse über den Istzustand erforderlich. • Auch für die Systemplanung gilt, daß der "Teufel im Detail" steckt; anspruchsvolle Systementwürfe können scheitern, wenn sie restriktiv wirkende Details über den Istzustand ignorieren, weil diese nicht bekannt sind.

ZAMFS - Ziel, Aufgaben und Methodik der Feinstudie

333

Von diesen Argumenten ausgehend, kann unter Berücksichtigung des Ergebnisses der Vorstudie das Ziel der Feinstudie wie folgt beschrieben werden: In dem durch die Vorstudie abgegrenzten Untersuchungsbereich, der durch die Grundkonzeption beschrieben wird, ist die Gesamtheit der technischen, organisatorischen, personellen und sozialen Bedingungen und Regelungen des bestehenden Informationssystems so weit im Detail zu erfassen und zu analysieren, wie dies zur Überprüfung der Zweckmäßigkeit der Grundkonzeption bzw. zu deren Anpassung notwendig ist. Man kann auch sagen: Wie dies notwendig ist, um mit der Präzisierung des Systementwurfs der Grundkonzeption aus der Vorstudie in der Grobprojektierung fortfahren zu können. Nicht mehr, aber auch nicht weniger. Die Methodik der Feinstudie folgt primär einem istzustandsorientierten Ansatz; sie folgt ihm jedoch nur im Rahmen der aus der Vorstudie vorgegebenen Grundkonzeption. Indem sie sich im Rahmen der Grundkonzeption bewegt, folgt die Feinstudie insoweit auch einem sollzustandsorientierten Ansatz (vgl. Lerneinheit ZAMSP). Die Istzustandsorientierung ist also nicht Selbstzweck, sondern auf die Planungsziele ausgerichtet; sie ergänzt die Sollzustandsorientierung und stellt insbesondere sicher, daß die für die Grobprojektierung geltenden Bedingungen des Istzustands (idealerweise vollständig) aufgedeckt werden.

Abb. ZAMFS-1: Der Prozeß der Feinstudie

Aufgaben der Feinstudie Aus dem Ziel der Feinstudie, die Grundkonzeption mit Hilfe der durch die Istzustandsuntersuchung gewonnenen Informationen anzupassen, ergeben sich folgende Aufgaben:

334

Aufgaben der Feinstudie

• Erste Aufgabe der Feinstudie: Istzustandserfassung. Erfassen des Istzustands in dem durch die Grundkonzeption gegebenen Untersuchungsbereich mit einem für die Analyse des Istzustands notwendigen Detaillierungsgrad (vgl. Lerneinheit ERIST). • Zweite Aufgabe der Feinstudie: Istzustandsanalyse. Analysieren des Istzustands zur Feststellung seiner Stärken und Schwächen (vgl. Lerneinheit ANIST). • Dritte Aufgabe der Feinstudie: Istzustandsoptimierung. Optimieren des Istzustands durch Erarbeiten und Realisieren von kurzfristig wirksamen Maßnahmen zum Bessergestalten, insbesondere durch das Beseitigen von Schwächen (vgl. Lerneinheit AFEIN). • Vierte Aufgabe der Feinstudie: Anpassen der Grundkonzeption auf Grund der Ergebnisse der Istzustandsuntersuchung, insbesondere auf Grund der erkannten Stärken und Schwächen des Istzustands (vgl. Lerneinheit AFEIN). Abbildung ZAMFS-1 zeigt die Aufgaben der Feinstudie als groben Arbeitsablauf und gibt die Lerneinheiten an, in denen die Aufgaben erläutert werden. Aus der Abbildung ist die zentrale Bedeutung des Stärken-/Schwächen-Katalogs im Arbeitsprozeß der Feinstudie deutlich erkennbar. Er ist Ergebnis der Istzustandsuntersuchung und beschreibt den Istzustand in Form von Stärken und Schwächen, an denen das Optimieren des Istzustands sowie das Anpassen der Grundkonzeption ausgerichtet wird. Charakter der Feinstudie Die Feinstudie ist neben der im Vordergrund stehenden Istzustandsorientierung durch die Interaktion zwischen Istzustandserfassung und Istzustandsanalyse, durch die Dualität zwischen vorgegebener und wahrgenommener Arbeitssituation sowie durch das zwischen Systemplanern und Benutzern latent vorhandene Konfliktpotential gekennzeichnet. Interaktiver Charakter der Feinstudie: Zwischen der Istzustandserfassung und der Istzustandsanalyse besteht ein enger, interaktiver Zusammenhang, der durch eine Reihe von Merkmalen gekennzeichnet ist. Aus diesen Merkmalen folgt, daß es nicht möglich ist, die Istzustandserfassung zunächst abzuschließen um dann, von ihren Ergebnissen ausgehend, die Istzustandsanalyse durchzuführen. (Dies wird in Abbildung ZAMFS-1 durch die parallele Anordnung von Istzustandserfassung und Istzustandsanalyse zum Ausdruck gebracht.) Es handelt sich um folgende Merkmale: • Die Istzustandserfassung ist kein Selbstzweck; sie ist immer auf den Zweck der Istzustandsanalyse ausgerichtet (was analysiert werden muß, muß erfaßt werden; was nicht analysiert werden muß, braucht nicht erfaßt zu werden). • Die Istzustandserfassung ist Voraussetzung für die Istzustandsanalyse; ohne Istzustandserfassung ist eine Istzustandsanalyse nicht möglich. • Beim Durchführen der Feinstudie lassen sich Istzustandserfassung und Istzustandsanalyse nicht deutlich voneinander abgrenzen; beide bilden einen vernetzten Prozeß mit abwechselnden, sich gegenseitig bedingenden Erfassungstätigkeiten und Analysetätigkeiten.

ZAMFS - Ziel, Aufgaben und Methodik der Feinstudie

335

• Zu Beginn der Feinstudie liegt der Arbeitsschwerpunkt auf der Istzustandserfassung, im Verlauf der Feinstudie verschiebt er sich zur Istzustandsanalyse. Abbildung ZAMFS-2 zeigt dies schematisch (wobei der Einfachheit halber ein linearer Zusammenhang zwischen Istzustandserfassung und Istzustandsanalyse angenommen ist); auf der Horizontalen ist der Zeitablauf in der Feinstudie, auf der Vertikalen sind die relativen Arbeitsanteile der Istzustandserfassung und der Istzustandsanalyse angegeben.

Ablauf der Feinstudie

•

Abb. ZAMFS-2: Arbeitsschwerpunkte bei der Feinstudie

Dualer Charakter der Feinstudie: Der duale Charakter der Feinstudie folgt aus der Tatsache, daß für die Beurteilung des Istzustands nicht nur die vorgegebene Arbeitssituation (auch: objektive Arbeitssituation), sondern auch die durch die Aufgabenträger wahrgenommene Arbeitssituation (auch: subjektive Arbeitssituation) von Bedeutung ist (vgl. dazu die Forschungsbefunde). Deshalb muß die Feinstudie sowohl bei der Erfassung als auch bei der Analyse des Istzustands beide Sichtweisen berücksichtigen. Nur eine duale Feinstudie ermöglicht es, die Stärken und Schwächen des Istzustands aufzudecken, weil Stärken und Schwächen sich wie folgt darstellen können: • Sie können auf Grund der vorgegebenen Arbeitssituation existieren und subjektiv durch die Aufgabenträger auch wahrgenommen werden. • Sie können auf Grund der vorgegebenen Arbeitssituation existieren, durch die Aufgabenträger aber nicht wahrgenommen werden. • Sie können auf Grund der vorgegebenen Arbeitssituation nicht existieren, aber subjektiv durch die Aufgabenträger wahrgenommen werden. Durch eine Erfassung und vergleichende Analyse der vorgegebenen und der wahrgenommenen Arbeitssituation können Abweichungen bewußt gemacht und bei der Projektierung berücksichtigt werden. Dies zeigt, daß insbesondere die Erhebungsmethoden so ausgerichtet sein müssen, daß beide Sichtweisen erfaßt werden können ("Methoden-Mix", vgl. Lerneinheit ISTER); deshalb ist die Befragung als Erhebungsmethode in der Regel unverzichtbar.

336

Aufgaben der Feinstudie

Konfliktcharakter der Feinstudie: Die Arbeitssituation in der Feinstudie, insbesondere bei der Istzustandsanalyse, ist besonders konfliktanfällig, weil zwischen Systemplanern einerseits und Benutzern in den Fachabteilungen andererseits häufig unterschiedliche Auffassungen darüber bestehen, ob eine Eigenschaft des Istzustands als Stärke oder als Schwäche einzustufen ist, und welche Konsequenzen dies für den Sollzustand hat. Dabei wirken Ängste und Befürchtungen der Benutzer kommunikationshemmend und spannungsfördernd. Ursachen können sein: • Das Projektergebnis wirkt sich tatsächlich oder nach Auffassung der Benutzer auf ihre Arbeitssituation negativ aus (im Extremfall als Arbeitsplatzverlust). • Die Kommunikation zwischen Systemplanern auf der einen Seite und Benutzem auf der anderen Seite funktioniert nicht. • Es bestehen bei den Benutzern falsche Vorstellungen über die Ziele und Aufgaben des Projekts, insbesondere bezüglich der Feinstudie. Diese Ursachen weisen sowohl auf die Notwendigkeit einer angemessenen Benutzerbeteiligung bei der Istzustandsuntersuchung (vgl. Lerneinheit BEBET im Band "Informationsmanagement"), als auch auf die Notwendigkeit der Schulung der Systemplaner im Umgang mit den Mitarbeitern in den Fachabteilungen hin (vgl. auch die Forschungsbefunde in Lerneinheit AUTER). Methoden und Techniken der Feinstudie Methoden und Techniken können insbesondere zur Unterstützung der Istzustandserfassung angegeben werden; hierzu liefert die betriebswirtschaftliche Fachliteratur brauchbare Hilfsmittel (vgl. Lerneinheit ISTER). In Lerneinheit ZERFA werden Methoden behandelt, die für die Erfassung des Zeitgerüsts des Istzustands eingesetzt werden können. Aufgabe der Sachmittelplanung im Rahmen der Projektplanung (vgl. Lerneinheit PROPL) ist es, aus diesem Methodenangebot einen "Methoden-Mix" zusammenzustellen, der auf die besonderen (insbes. organisatorischen und personellen) Bedingungen der Erhebungssituation in einem IuK-Projekt Rücksicht nimmt. Methoden und Techniken für die Unterstützung der Istzustandsanalyse sind wenig entwickelt. Unterstützt wird die Istzustandsanalyse vor allem durch eine klar gegliederte Dokumentation des Istzustands (vgl. Lerneinheit DOKUM), weshalb auf eine Reihe von Methoden und Techniken verwiesen werden kann, die im Kapitel "Methoden und Techniken der Systemplanung" behandelt wurden (vgl. die Lerneinheiten DARST, ENTAB, DAFLU, MATRX und WIRTA). Methoden und Techniken, die für die Istzustandsanalyse typisch sind, werden in Lerneinheit ISTAN erläutert. In Ergänzung dazu werden Methoden und Techniken der Kommunikationsanalyse behandelt, um die Bedeutung der Kommunikation, insbesondere die Mensch-Mensch- und die Mensch-Maschine-Kommunikation, bei der Entwicklung des Sollzustands berücksichtigen zu können (vgl. Lerneinheit KOMAN). Die Erfassung und Analyse der Kommunikation ist umso bedeutsamer, je arbeitsteiliger die Arbeitsprozesse sind, die im Istzustand untersucht werden, und je integrierter die Konzepte sind, die im Sollzustand vorgesehen sind (siehe dazu den "Integrationsgrad" in Lerneinheit FORMZ).

ZAMFS - Ziel, Aufgaben

und Methodik

der Feinstudie

337

Methoden und Techniken zur Unterstützung der dritten und der vierten Aufgabe der Feinstudie können nicht angegeben werden. Einer besonderen Betrachtung wert ist die Frage, wie bei der Feinstudie insgesamt, also unabhängig von ihren einzelnen Aufgaben und den verwendeten Methoden, vorgegangen werden sollte. Dazu wird eine Vorgehensweise entwickelt (vgl. Lerneinheit VFEIN). Forschungsbefunde Auwera/Mok haben mit einem Experiment die vorgegebene Arbeitssituation bezüglich des Routinecharakters der Aufgabeninhalte, unter Verwendung einer Prüfliste, eingestuft und die wahrgenommene Arbeitssituation mit einer Befragung der Aufgabenträger ("Befragte") erfaßt. Sie haben folgendes festgestellt: • Etwa 50% der Arbeitssituationen wurde als "wenig routinisiert" eingestuft und von den Befragten auch so wahrgenommen. • Weitere etwa 50% der Arbeitssituationen wurde als "stark routinisiert" eingestuft, von den Befragten jedoch als "wenig routinisiert" wahrgenommen. • Nur wenige Arbeitssituationen wurden als "stark routinisiert" eingestuft und von den Befragten auch so empfunden. • Keine Arbeitssituation wurde als "wenig routinisiert" eingestuft und von den Befragten als "stark routinisiert" empfunden. Diese Befunde zeigen, daß vorgegebene Arbeitssituationen von den Aufgabenträgern anders wahrgenommen werden können; sie stützen die Forderung nach einer dualen Feinstudie. B. Grupp kommt auf Grund von "Rundfragen in Organisationskursen" zu der Schlußfolgerung, daß die überwiegend ablehnende Haltung gegenüber der Istzustandsuntersuchung auf mangelnde Methodenkenntnisse zurückzuführen ist. Diese sind jedoch Voraussetzung dafür, eine Istzustandsuntersuchung "zukunftsorientiert, zeitsparend und mit klaren Zielsetzungen" abwickeln zu können. Kontrollfragen 1. 2. 3. 4. 5.

W e l c h e s Ziel wird mit der Feinstudie verfolgt? W e l c h e A r g u m e n t e sprechen für die Istzustandsuntersuchung? Ist die Methodik der Feinstudie primär istzustandsorientiert oder sollzustandsorientiert? In w e l c h e A u f g a b e n kann die Feinstudie gegliedert werden? W e l c h e Merkmale kennzeichnen den Charakter der Feinstudie?

Quellenliteratur Grupp, B.: M e t h o d e n der Istaufnahme und Problemanalyse. Arbeitstechniken für Mitarbeiter in E D V - und Büroprojekten. Forkel Verlag, Wiesbaden 1987 A u w e r a , F. van der and M o k , A.: T h e Politics of T e c h n o l o g y - Routinization and M a n a g e m e n t and U n i o n Strategies. In: Dunkerley, D. and Salaman, G. (Eds.): T h e International Y e a r b o o k of Organization Studies 1981, 145 - 160 Vertiefungsliteratur S y d o w , J.: Organisationsspielraum und Büroautomation. Verlag de Gruyter, B e r l i n / N e w York 1985

ERIST- Erfassen des Istzustands Lernziele Sie kennen den Zweck der Istzustandserfassung und können daraus die Aufgaben ableiten, die beim Erfassen des Istzustands zu bearbeiten sind. Sie können die Aufgaben zu einem Prozeß der Istzustandserfassung ordnen. Sie sind in der Lage, das Untersuchungsdesign für eine Istzustandserfassung zu entwickeln. Sie kennen eine zweckmäßige Struktur für die Iszustandsbeschreibung. Definitionen und Abkürzungen Attribut (attribute) = eine im jeweiligen Untersuchungszusammenhang als wesentlich angesehene Eigenschaft eines Systems. Attributewert (attribute value) = die Ausprägung einer Eigenschaft. Benutzermitwirkung (user Cooperation) = der Bereich der Partizipation, der auf dem Konsens der Beteiligten beruht. Synonym: Benutzerbeteiligung. Beziehung (relationship) = die Zuordnung von Objekten eines Systems auf Objekte eines anderen Systems. Easiest-first-Strategie (easiest-first strategy) = eine Strategie, bei der zuerst die Aufgaben bearbeitet werden, die schnell abgearbeitet werden können. Erfassung (survey) = die Festlegung der Attribute, die Ermittlung der Attributewerte und die Ordnung und Dokumentation der Attribute und Attributewerte. Synonyme: Erfassen, Erhebung, Erheben. Hypothese (hypothesis) = eine spekulative bis wissenschaftlich begründete Annahme zur Erklärung und Begründung sowie auch zur Gewinnung neuer Erkenntnisse. Synonym: Arbeitshypothese (working hypothesis). interaktiv (interactive) = das sich wechselseitige Beeinflussen der Elemente eines Systems, in der Regel durch Kommunikation. Istzustandsbeschreibung (current system description) = die Ordnung und Dokumentation der Attribute und Attributewerte des Istzustands, iterativ (iterative) = die Eigenschaft einer Vorgehensweise, die durch schrittweises Problemlösen gekennzeichnet ist. Prinzip des Schwarzen Kastens (black box principle) = eine Vorgehensweise, bei der man bei der Betrachtung eines Systems von den Vorgängen innerhalb dieses Systems abstrahiert und sich auf die wirkungsspezifischen Eingänge und Ausgänge an den Systemgrenzen konzentriert, relevante Systemumwelt (relevant systems environment) = die Phänomene, die bei der Systemplanung berücksichtigt werden, ohne daß sie zum betrachteten System gehören. Sachmittel (means) = der Teil der Organisationsmittel, der als Hilfsmittel für die Durchführung von Tätigkeiten eingesetzt werden kann. Schwäche (weakness) = die Tendenz eines Systems oder eines Systemteils, von einem definierten Standard negativ abzuweichen. Synonym: Schwachstelle. Stärke (strength) = die Tendenz eines Systems oder eines Systemteils, einem definierten Standard zu entsprechen oder positiv von ihm abzuweichen. Systemgrenze (systems barrier) = die Nahtstelle zwischen dem System, für das sich der Betrachter interessiert, und seiner Umwelt.

ERIST - Erfassen des Istzustands

339

Zweck der Istzustandserfassung Zweck der Istzustandserfassung ist es, die für die Istzustandsanalyse (vgl. Lerneinheit ISTAN) erforderlichen Informationen zu erarbeiten. Die Istzustandserfassung ist also ausdrücklich auf die Istzustandsanalyse hin ausgerichtet; sie hat keinen Selbstzweck. Da es der Zweck der Istzustandsanalyse ist, die Stärken und Schwächen des Istzustands herauszuarbeiten, muß die Istzustandserfassung die Informationen über den Istzustand liefern, welche die Herausarbeitung seiner Stärken und Schwächen bestmöglich unterstützen können. Die Ausrichtung der Istzustandserfassung am Zweck der Istzustandsanalyse erfolgt durch die Systemabgrenzung, durch die Festlegung der Breite und der Tiefe der Istzustandserfassung sowie durch die Auswahl der für die Istzustandserfassung verwendeten Methoden und Techniken (vgl. Lerneinheit ISTER). Da Systemplaner meist nicht über ausreichende Kenntnisse über den Istzustand verfügen, ist die Mitwirkung der Aufgabenträger, welche die betrieblichen Aufgaben im untersuchten Informationssystem durchführen, bei der Istzustandserfassung unabdingbar ("Benutzermitwirkung"). Benutzermitwirkung kann nicht durch die Rolle der Aufgabenträger als "Informationslieferanten" ersetzt werden; sie erfordert, daß die Aufgabenträger eine aktive Rolle im Arbeitsprozeß der Systemplanung spielen (vgl. Lerneinheit AUTER und Lerneinheit BEBET im Band "Informationsmanagement"). Die Istzustandserfassung folgt methodisch der Vorgehensweise, die als kombinierte Feinstudie bezeichnet wird (vgl. Lerneinheit VFEIN). Die kombinierte Feinstudie ist insbesondere dadurch gekennzeichnet, daß die Istzustandserfassung nach Struktureinheiten, mit einer Orientierung auf die zu untersuchenden Informationsverarbeitungskomplexe, erfolgt. Die nachfolgende Istzustandsanalyse erfolgt nach Informationsverarbeitungskomplexen. Beim Erfassen des Istzustands in den Struktureinheiten werden nur die betrieblichen Aufgaben untersucht, die auf Grund der definierten Sachziele (vgl. Lerneinheit SACHZ) Teil der Grundkonzeption (vgl. Lerneinheit GRUND) sind. Aufgaben der Istzustandserfassung Aus dem Zweck der Istzustandserfassung werden folgende Aufgaben abgeleitet: • • • • •

das das das das das

Festlegen der Systemgrenzen ("Breite der Istzustandserfassung"); Festlegen des Detaillierungsgrads ("Tiefe der Istzustandserfassung"); Festlegen der Attribute, die den Istzustand kennzeichnen; Ermitteln der Attributewerte; Ordnen und Dokumentieren der Attribute und Attribute werte.

Abbildung ERIST-1 zeigt die Aufgaben der Istzustandserfassung als groben Arbeitsablauf und gibt den Input und Output der Istzustandserfassung an. Festlegen der Systemgrenzen Durch das Festlegen der Systemgrenzen wird die Frage nach der Breite der Istzustandserfassung beantwortet, also danach, welche betrieblichen Aufgaben in die

340

Aufgaben der Feinstudie

Istzustandserfassung einbezogen werden sollen. Eine Antwort auf diese Frage ergibt sich bereits aus der Methodik der Systemplanung, insbesondere aus der Tatsache, daß sich die Feinstudie an der Grundkonzeption orientiert. Die Grundkonzeption beschreibt unter anderem die Sachziele der Systemplanung und damit die betrieblichen Aufgaben, für die ein neues Informationssystem geschaffen werden soll. In der Regel handelt es sich dabei um Aufgaben, für die ein Istzustand vorhanden ist. Wenn dies nicht der Fall ist (also bei völlig neuen betrieblichen Aufgaben), besteht kein Bedarf an einer Feinstudie. Grundkonzeption

-¿f////////////////////////////;

Festl egen der Systeingrenzen Festlegen des Detaillierungsgrads Festlegen der Attribute Ermitteln der Attributeweite Ordnen und Do iumentieren der Attribute und Attributeweite

i Istzustandsbeschreibung

Abb. ERIST-1: Der Prozeß Istzustandserfassung

^ / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / Jder

Ausgehend von dem durch die Grundkonzeption gegebenen System ("Informationssystem im Istzustand"), umfaßt das Festlegen der Systemgrenzen zwei Teilaufgaben, nämlich: • die Abgrenzung des Informationssystems im Istzustand von seiner Umwelt; • die Abgrenzung des für die Istzustandserfassung relevanten Teils der Umwelt von seinem nicht relevanten Teil. Die Nahtstelle zwischen dem Informationssystem im Istzustand und seiner Umwelt liegt dort, wo der Gestaltungseinfluß der Systemplaner auf Grund des Projektauftrags endet. Die Abgrenzung des für die Istzustandserfassung relevanten Teils der Umwelt von ihrem nicht relevanten Teil erfolgt durch Aussonderung der Teilsysteme der Umwelt, die in keiner Beziehung zum Informationssystem

ERIST - Erfassen des

Istzustands

341

im Istzustand stehen. Zur Sicherung der Zweckmäßigkeit der Systemabgrenzung sollte folgendes beachtet werden: • Der mit der Abgrenzung zusammenhängenden Umweltorientierung wohnt eine Tendenz zur Ausweitung der Systemgrenzen inne; in der Regel sind aber nicht alle denkbaren Beziehungen für die Erreichung der Planungsziele wesentlich. • Die Systemabgrenzung kann mit physischen oder organisatorischen Grenzen übereinstimmen, sie muß dies aber nicht (letzteres ist für IuK-Projekte, welche die Kommunikation mit Kunden, Lieferanten, Banken usw. zum Gegenstand haben, geradezu typisch). • Die Umwelt beeinflußt sowohl den Aufbau als auch den Ablauf des Untersuchungsobjekts. Umweltteile, die auf den Aufbau wirken, müssen nicht identisch sein mit Umweltteilen, die auf den Ablauf wirken. • Bisweilen genügt eine Black-Box-Betrachtung von relevanten Umweltteilen nicht, weil die Kenntnis des A u f b a u s und der inneren Abläufe dieser Umweltteile erforderlich ist. Festlegen des

Detaillierungsgrads

Durch das Festlegen des Detaillierungsgrads wird die Frage nach der T i e f e der Istzustandserfassung beantwortet, also danach, wie genau der Istzustand des bestehenden Informationssystems durch die Istzustandserfassung abgebildet werden soll. Entscheidungen über den Detaillierungsgrad gehen sowohl in das Festlegen der A t t r i b u t e als auch in das Ermitteln der A t t r i b u t e w e r t e ein: Je genauer (bzw. j e ungenauer) die Abbildung des Istzustands sein soll, desto mehr (bzw. desto weniger) Attribute müssen festgelegt werden. Der k o n s e q u e n t e n Orientierung der Istzustandserfassung an den A n f o r d e r u n g e n der Istzustandsanalyse folgend, gilt der G r u n d s a t z : Der Detaillierungsgrad der Istzustandserfassung sollte nicht geringer und nicht größer sein, als dies zum Erkennen der Stärken und Schwächen des Istzustands erforderlich ist. Die Ableitung konkreter Handlungsempfehlungen aus diesem Grundsatz ist nicht möglich. Die Beachtung der folgenden Hinweise kann beim Festlegen des D e t a i l l i e r u n g s g r a d s der Istzustandserfassung von Nutzen sein: Bei der Istzustandserfassung wird nach der E a s i e s t - f i r s t - S t r a t e g i e und iterativ vorgegangen. Das bedeutet bezüglich der Attribute, daß zunächst die Attribute festgelegt werden, deren B e d e u t u n g für das Erkennen von Stärken und Schwächen aus der Erfahrung bekannt ist. Bezüglich der A t t r i b u t e w e r t e heißt das, daß zunächst die Attributewerte ermittelt werden, die sich mit einem geringen A u f w a n d ermitteln lassen. Das so entstehende Zwischenergebnis der Istzustandsbeschreibung wird daraufhin überprüft, ob es den Anforderungen der Istzustandsanalyse genügt, ob es also ausreichend detailliert ist. W e n n nein, werden für eine zweite "Erhebungsrunde" weitere Attribute festgelegt, und es wird eine detailliertere Istzustandsbeschreibung erarbeitet. Damit wird so lange fortgefahren, bis man sich an einen ausreichenden Detaillierungsgrad herangearbeitet hat. Für die Ü b e r p r ü f u n g der Istzustandsbeschreibung ist die interaktive Vorgehensweise der Feinstudie hilfreich (vgl. Lerneinheit ZAMFS). Folgende Faktoren haben auf das Festlegen des Detaillierungsgrads der Istzustandserfassung einen Einfluß und sollten daher beachtet werden:

342

• • • •

Aufgaben der Feinstudie

die Kompliziertheit des Informationssystems im Istzustand; die Komplexität des Informationssystems im Istzustand; die Kenntnisse der Systemplaner über den Istzustand; der Umfang Mitwirkung der Aufgabenträger bei der Istzustandserhebung.

Kompliziertheit bezeichnet die Eigenschaft des untersuchten Informationssystems, die durch die Anzahl und die Unterschiedlichkeit seiner Elemente gegeben ist. Komplexität ist die Eigenschaft des untersuchten Informationssystems, die durch die Anzahl seiner Elemente und die Anzahl der Beziehungen zwischen den Elementen ("Beziehungsreichtum") gekennzeichnet ist. Mit anderen Worten: es geht hier um die Dynamik oder den Grad der Voraussagbarkeit des Verhaltens des untersuchten Informationssystems. Daraus ergibt sich unter anderem die folgende Hypothese: Je dynamischer das untersuchte Informationssystem ist, je geringer die Kenntnisse der Systemplaner über den Istzustand sind und je geringer der Umfang der Mitwirkung der Aufgabenträger bei der Istzustandserfassung ist, desto detaillierter muß die Istzustandserfassung angelegt werden. Aus der Hypothese kann auch auf die Maßnahmen geschlossen werden, die möglich und notwendig sind, um den Aufwand für die Istzustandserhebung so gering wie möglich zu halten (z.B. die Komplexität durch Zerlegung zu reduzieren). Festlegen der Attribute Zunächst werden für eine erste Erhebungsrunde die Attribute festgelegt, deren Bedeutung für das Erkennen von Stärken und Schwächen aus der Erfahrung bekannt ist. Typische Beispiele für derartige Attribute sind: • die für die Durchführung der untersuchten Aufgaben verwendeten Eingabedaten; • die aus der Durchführung der untersuchten Aufgaben entstehenden Ausgabedaten; • die zur Erzeugung der Ausgabedaten verwendeten Methoden; • die Beziehungen zwischen den Eingabedaten der untersuchten Aufgaben und anderen betrieblichen Aufgaben; • die Beziehungen zwischen den Ausgabedaten der untersuchten Aufgaben und anderen betrieblichen Aufgaben; • die an der Aufgabendurchführung beteiligten Aufgabenträger; • die an der Aufgabendurchführung beteiligten Struktureinheiten; • die verwendeten Nummernsysteme; • die verwendeten Sicherungsmaßnahmen. Im Verlauf der Istzustandserfassung und der interaktiv durchgeführten Istzustandsanalyse werden weitere Attribute erkannt, die für die Herausarbeitung der Stärken und Schwächen des Istzustands erforderlich sind. Sie werden in einer zweiten Erhebungsrunde verfolgt. Beispiele hierfür sind: • • • • •

der die die die der

Rang, die Phase und der Sachcharakter der untersuchten Aufgaben; zur Aufgabendurchführung angewendeten Verrichtungen; Art der Objekte, an denen die Verrichtungen durchgeführt werden; zur Durchführung der Verrichtungen verwendeten Sachmittel; zur Durchführung der Verrichtungen erforderliche Zeitbedarf;

ERIST - Erfassen des Istzustands

343

• die Art der verwendeten Eingabedaten (Primärdaten, Bestandsdaten und Stammdaten); • die Art der erzeugten Ausgabedaten (Bestandsdaten und Benutzerdaten). Ermitteln der Attributewerte Zunächst werden in einer ersten Erhebungsrunde nur die Attributewerte ermittelt, die sich mit geringem Aufwand ermitteln lassen. Typische Beispiele sind: • • • •

für das Attribut "verwendete Eingabedaten" die Datenfelder; für das Attribut "entstehende Ausgabedaten" die Datenfelder; für das Attribut "verwendete Methoden" die Bezeichnung der Methoden; für das Attribut "verwendete Nummernsysteme" die Art der Nummernsysteme; • für das Attribut "Objekte" die Anzahl der Objekte; • für das Attribut "Verrichtungen" die Häufigkeit der Durchführung der Verrichtungen. Im Verlauf der Istzustandserfassung und der interaktiv durchgeführten Istzustandsanalyse wird ein Informationsbedarf an detaillierten Attributewerten erkannt, die für die Herausarbeitung der Stärken und Schwächen des Istzustands erforderlich sind. Beispiele hierfür sind: • für das Attribut Datenfelder; • für das Attribut Datenfelder; • für das Attribut • für das Attribut

"verwendete Eingabedaten" der Wertebereich der "entstehende Ausgabedaten" der Wertebereich der "verwendete Methoden" die Abiaufschritte der Methoden; "verwendete Nummemsysteme" der Nummernaufbau.

Ordnen und Dokumentieren Die Ergebnisse der Istzustandserfassung werden für jede Erhebungsrunde geordnet und dokumentiert, sodaß durch schrittweise Verfeinerung aus den Zwischenergebnissen eine Istzustandsbeschreibung entsteht, die das Ergebnis der Istzustandserfassung ist. Da bei der Istzustandserfassung nach Struktureinheiten mit einer Orientierung auf die zu untersuchenden Informationsverarbeitungskomplexe vorgegangen wird, erfolgt auch die Ordnung der Ergebnisse in der Istzustandsbeschreibung primär nach Struktureinheiten und innerhalb der Struktureinheiten nach Informationsverarbeitungskomplexen. Innerhalb der Informationsverarbeitungskomplexe wird weiter geordnet, und zwar nach den untersuchten betrieblichen Aufgaben und innerhalb der Aufgaben nach Attributen mit ihren Attribute werten. Die Istzustandsbeschreibung sollte unter Verwendung eines vereinbarten Dokumentationsverfahrens (vgl. Lerneinheit DOKUM) und zweckmäßiger, möglichst werkzeugunterstützter Darstellungstechniken erfolgen. Methodenverweise Methoden der Istzustandserfassung (Lerneinheit ISTER); Darstellungstechniken (Lerneinheit DARST); Dokumentationsmethoden (Lerneinheit DOKUM).

344

Alfgaben der Feinstudie

Kontrollfragen 1. 2. 3. 4. 5.

Welchen Zweck verfolgt die Istzustandserfassung? Welche Aufgaben der Istzustandserfassung werden aus ihrem Zweck abgeleitet? Was sind typische Beispiele für Attribute der Istzustandserfassung? Warum wird beim Festlegen des Detaillierungsgrads der Istzustandserfassung nach der Easiest-first-Strategie vorgegangen? Wie sollte die Istzustandsbeschreibung gegliedert sein?

Quellenliteratur Wittlage, H.: Methoden und Techniken praktischer Organisationsarbeit. 2. A., Verlag Neue Wirtschafts-Briefe, Herne/ Berlin 1986

ANIST - Analysieren des Istzustands Lernziele Sie kennen den Zweck der Istzustandsanalyse und können daraus die Aufgaben ableiten, die beim Analysieren des Istzustands zu bearbeiten sind. Sie können die Aufgaben zum Prozeß der Istzustandsanalyse ordnen und ihren Zweck erläutern. Sie kennen die Bedeutung der Situationsanalyse und der Problemanalyse für das Erkennen der Symptome und Ursachen von Stärken und Schwächen. D e f i n i t i o n e n und

Abkürzungen

Analysezyklus (analyzing cycle) = das iterative Durchführen der Analyse, wobei mit jedem Zyklus ein anderer Analysezweck verfolgt wird. A r b e i t s o r g a n i s a t i o n (work Organization) = der Teil eines Systems, der die Struktur der Aufgaben und den Ablauf der Aufgabenausführung beschreibt. A u f g a b e n s t r u k t u r i e r b a r k e i t (task structuring ability) = die Abbildbarkeit einer Aufgabe durch eine geordnete Menge von Abiaufschritten. Datensystem (data system) = der Teil eines Informationssystems, dessen Zweck das Speichern von Informationen in Form von Daten ist. Falsifizierung (falsification) = der wissenschaftliche Versuch, empirisch nachzuweisen, daß eine Hypothese nicht zutrifft. Hypothese (hypothesis) = eine spekulative bis wissenschaftlich fundierte Annahme zur Erklärung und Begründung sowie zur Gewinnung neuer Kenntnisse. Methodensystem (method system) = der Teil eines Informationssystems, dessen Zweck das Gewinnen von Informationen aus Daten mit Hilfe von Methoden ist. O r g a n i s a t i o n s s p i e l r a u m (organizing scope) = die M e n g e organisatorischer Gestaltungsalternativen, die zur Erreichung definierter Ziele zur V e r f ü g u n g steht und die mit den situativen Bedingungen vereinbar ist. P r o b l e m a n a l y s e (problem analysis) = der Teil der Istzustandsanalyse, dessen Zweck das Erkennen der Ursachen f ü r das Entstehen der Symptome ist. S i c h e r u n g s s y s t e m (backup system) = der Teil eines Informationssystems, dessen Zweck es ist, die Beinträchtigung der Systemnutzung zu verhindern. S i m u l a t i o n s e x p e r i m e n t (Simulation experiment) = das zielgerichtete Experimentieren an Abbildungen der Realität, also an Modellen. Situationsanalyse (Situation analysis) = der Teil der Istzustandsanalyse, deren Zweck das Erkennen von Symptomen ist. S y m p t o m (symptom) = ein wahrnehmbares, objektiv feststellbares Zeichen der Abweichung eines Systems von einem Sollzustand. Testen (testing) = das nach einer vorab festgelegten, kontrollierbaren Methode durchgeführte experimentelle Untersuchen eines Systems zur Feststellung bestimmter Eigenschaften. T r a n s p o r t s y s t e m (communication system) = der Teil eines Informationssystems, dessen Zweck das Bewegen oder Weiterbewegen von Informationen in Form von Nachrichten ist. Synonym: Kommunikationssystem. U r s a c h e (cause) = die Voraussetzung, die Bedingung oder das Motiv für die Entstehung oder Veränderung einer Ordnung.

346

Aufgaben der Feinstudie

Zweck der Istzustandsanalyse Zweck der Istzustandsanalyse ist es, die Informationen über den Istzustand zu erarbeiten, die zur Überprüfung des in der Grundkonzeption beschriebenen Sollkonzepts geeignet sind. Informationen, die diese Eigenschaft haben, werden zusammenfassend mit Stärken und Schwächen des Istzustands bezeichnet. Input der Istzustandsanalyse sind formal gesehen die Ergebnisse der Istzustandserfassung in Form der Istzustandsbeschreibung. Da Istzustandserfassung und Istzustandsanalyse interaktiv erfolgen, wird der Output der Istzustandserfassung faktisch in viele Teile zerlegt und damit der Input der Istzustandsanalyse in vielen Teilen aufgenommen (vgl. Lerneinheit ZAMFS). Output der Istzustandsanalyse ist der Stärken-/Schwächen-Katalog. Da die Breite der Istzustandserfassung durch die Grundkonzeption (vgl. Lerneinheit GRUND) abgegrenzt ist, werden durch die Istzustandsanalyse die betrieblichen Aufgaben untersucht, die auf Grund der aus den Planungszielen abgeleiteten Sachziele (vgl. Lerneinheit SACHZ) durch die Grundkonzeption abgedeckt werden. Untersuchen der betrieblichen Aufgaben in Form der Istzustandsanalyse bedeutet, die Werte der Attribute, durch die der I s t z u s t a n d gekennzeichnet ist (vgl. Lerneinheit ERIST), zu validieren. Das Durchführen der Istzustandsanalyse setzt also voraus, daß Vorstellungen über einen erstrebenswerten Sollzustand bestehen. Da aber über den Sollzustand zunächst nur grobe, konzeptionelle Vorstellungen in Form der Grundkonzeption bestehen, die erst bei der Projektierung (vgl. Kapitel "Der Prozeß der Grobprojektierung" und Kapitel "Der Prozeß der Feinprojektierung") präzisiert werden, müssen die am Projekt beteiligten Systemplaner und Benutzer einschlägige Kenntnisse über den angestrebten Sollzustand in die Istzustandsanalyse einbringen bzw. im Verlauf der Istzustandsuntersuchung erarbeiten (vgl. Lerneinheit PROSP). Daraus folgt unter anderem, daß bereits während der Istzustandsanalyse Entwurfsüberlegungen angestellt und Entwurfsentscheidungen für die Projektierung vorbereitet werden. Die Istzustandsanalyse folgt der Vorgehensweise der k o m b i n i e r t e n Feinstudie (vgl. Lerneinheit VFEIN), die dadurch gekennzeichnet ist, daß die Istzustandserfassung nach Struktureinheiten mit Orientierung auf die zu untersuchenden Informationsverarbeitungskomplexe (vgl. Lerneinheit ISTER) erfolgt und daß die Istzustandsanalyse nach Informationsverarbeitungskomplexen ohne Rücksicht auf die Struktureinheiten vorgeht. Beim Analysieren eines Informationsverarbeitungskomplexes werden die betrieblichen Aufgaben aller anderen Informationsverarbeitungskomplexe, die auf den analysierten Informationsverarbeitungskomplex Einfluß haben oder von diesem beeinflußt werden, untersucht. Aufgaben der Istzustandsanalyse Aus dem Zweck der Istzustandsanalyse lassen sich folgende Aufgaben ableiten: • die formale Analyse des Istzustands ("formaler Analysezyklus"); • die inhaltliche Analyse des Istzustands ("inhaltlicher Analysezyklus"); • die Dokumentation der erkannten Stärken und Schwächen des Istzustands im Stärken-/Schwächen-Katalog.

ANIST - Analysieren

des Istzustands

347

Die nach formalen und nach inhaltlichen Gesichtspunkten durchgeführte Analyse des Istzustands führt zum Erkennen der Stärken und Schwächen ("Symptome") und zur Feststellung ihrer Ursachen. Abbildung ANIST-1 zeigt die Aufgaben der Istzustandsanalyse als groben Arbeitsablauf und gibt ihren Input und ihren Output an. ip

Istzustandsbeschreibung

|||

^^////////////////////////////////////////My

Formale Analyse des Istz ustands

Inhaltliche Analyse des Istzustands Ordnen und E)okumentieren der Analys Ergebnisse

Abb. ANIST-1: Der Prozeß ' • ¿ / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / der / / / / Istzustandsanalyse //Z.

\ Stärken-/Schwächenkatalog ^ Formaler

Analysezyklus

Der formale Analysezyklus basiert auf der symptomorientierten Situationsanalyse und auf der ursachenorientierten Problemanalyse. Die Situationsanalyse entspricht weitgehend der Zustandsanalyse im systemtechnischen Planungsansatz (vgl. Lerneinheit SYSTE). Die Situationsanalyse und die Problemanalyse werden solange durchlaufen, bis alle Symptome (Stärken und Schwächen) erkannt und ihre Ursachen ermittelt sind und ein ursachenorientierter Stärken-/SchwächenKatalog formuliert werden kann. Zweck der S i t u a t i o n s a n a l y s e ist es, mit Hilfe von Informationen der Istzustandserfassung Symptome zu erkennen. Das Erkennen von Symptomen wird erleichtert, wenn das untersuchte System in geeigneter Weise in Teilsysteme zerlegt wird und wenn die Analyse in einer zweckmäßigen Reihenfolge vorgenommen wird. Folgende Zerlegung und Reihenfolge sind für die Situationsanalyse deshalb besonders geeignet, weil sie auch für die nachfolgende Problemanalyse und darüber hinaus für die Projektierung verwendet werden: Datensystem, Methodensystem, Arbeitsorganisation, Transportsystem und Sicherungssystem. Durch diese Zerlegung und Reihenfolge kann der Zusammenhang zwischen Symptomerkennung und Ursachenerkennung sowie zwischen Ursachenbeeinflussung und Systembeeinflussung erfahrungsgemäß am besten gewahrt werden. Wie Symptome erkannt werden können, hängt insbesondere von der Qualifikation der am Projekt beteiligten Systemplaner und Benutzer sowie davon ab, mit

348

Aufgaben der Feinstudie

welchen Methoden der Istzustand erfaßt wird. Erfolgt die Istzustandserfassung z.B. durch Befragung der Aufgabenträger, dann wird von der Erfahrung ausgegangen, daß die Mitarbeiter am besten in der Lage sind, Anzeichen für das Abweichen des Istzustands vom Sollzustand wahrzunehmen. Im allgemeinen können die Aufgabenträger aber nur Beiträge zur Problemerkennung liefern, die überprüft und ergänzt werden müssen (z.B. durch Beobachtung). Bei der Problemerkennung sollten deshalb die erfaßten Attributewerte des Istzustands mit bekannten Attributewerten des Sollzustands ("Erfahrungswerte") verglichen werden. Werden Symptome festgestellt, die als unwichtig einzustufen sind, weil ihre Auswirkungen bekannt und gering sind, oder deren Ursachen bekannt oder sofort erkennbar sind, kann die Problemanalyse übersprungen werden. Die Istzustandsanalyse wird gleich mit der Herausarbeitung der Stärken und Schwächen fortgesetzt. Werden Symptome festgestellt, die als wichtig einzustufen sind, weil ihre Auswirkungen bekannt und erheblich oder nicht bekannt sind, wird die Problemanalyse eingeleitet. Das Gleiche gilt, wenn Symptome festgestellt werden, deren Ursachen nicht bekannt oder nicht sofort erkennbar sind.

Symptomumfeld definieren Symptom beschreiben

Abb. AN1ST-2: Arbeitsschritte der Problemanalyse

Zweck der Problemanalyse ist es, mit Hilfe der Informationen der Situationsanalyse die Symptome zu präzisieren, um die Ursachen für das Entstehen der

ANIST - Analysieren des

Istzustands

349

Symptome feststellen zu können. Die Problemanalyse läßt sich in sechs Arbeitsschritte gliedern, wie Abbildung ANIST-2 zeigt. • Erster Arbeitsschritt: Definieren des Symptomumfelds. Mit der Definition des Symptomumfelds wird festgestellt, unter welchen Voraussetzungen und Bedingungen das Symptom auftritt. Zur Unterstützung dieses Arbeitsschritts kann die W-Technik (vgl. Lerneinheit KREAT) angewendet werden. • Zweiter Arbeitsschritt: Beschreiben der Symptome. Das Beschreiben der Symptome erfolgt durch die Beantwortung der Fragen "was?", "wo?", "wann?" und "wieviel?". Durch die Beantwortung der Frage "was?" wird das Symptom als Stärke oder Schwäche (Fehler oder Störung, die zu einem Fehler führen können) erkannt und das Objekt, an dem das Symptom auftritt, wird lokalisiert. Durch die Beantwortung der Frage "wo?" werden der geographische Ort des Objekts und die Lage der Stärke oder Schwäche am Objekt festgestellt. Durch die Beantwortung der Frage "wann?" wird der Zeitpunkt oder der Zeitraum des Auftretens der Stärke oder Schwäche ermittelt. Die Beantwortung der Frage "wieviel?" gibt Auskunft über den Umfang der Stärke oder Schwäche, also über das Ausmaß der Abweichung des Istzustands vom geplanten Sollzustand. • Dritter Arbeitsschritt: Feststellen von Veränderungen. Jeder Istzustand ist einmal als Sollzustand installiert worden. Wenn Abweichungen des Istzustands vom geplanten Sollzustand festgestellt werden, müssen Veränderungen vorgegangen sein. Diese sind entweder Veränderungen des installierten Sollzustands (= Istzustand) oder Veränderungen (meist Erweiterungen) des Organisationsspielraums (meist durch Aufgabenveränderung oder durch Weiterentwicklung der Technologie). Für jede Stärke oder Schwäche wird festgestellt, welche Veränderung(en) für ihr Entstehen verantwortlich sind. • Vierter Arbeitsschritt: Bilden von Hypothesen. Von jeder einzelnen Veränderung und von jeder sinnvollen Kombination von Veränderungen wird behauptet, sie sei(en) Ursache für das Auftreten eines Symptoms oder mehrerer Symptome (Ursachen-/Symptom-Beziehung). Durch die Darstellung der Ursachen-/Symptom-Beziehungen in einer Matrix (vgl. Lerneinheit MATRX) kann die Hypothesenbildung veranschaulicht und der nachfolgende Hypothesentest erleichtert werden. • Fünfter Arbeitsschritt: Testen der Hypothesen. Mit jeder gebildeten Hypothese wird untersucht, ob die Ursache(n) das Symptom (die Symptome) vollständig erklärt (erklären), ob also der geplante Sollzustand durch das Beseitigen der Ursache(n) in den Istzustand überführt werden kann bzw. umgekehrt. • Sechster Arbeitsschritt: Falsifizieren der Hypothesen. Schließlich wird versucht, durch Experimente (z.B. durch ein Simulationsexperiment, vgl. Lerneinheit SIMUL) nachzuweisen, daß die Hypothesen nicht zutreffen. Es wird also versucht, die Hypothesen zu falsifizieren (weil es nicht möglich ist, sie zu verifizieren). Wegen des erheblichen Aufwands für experimentelle Untersuchungen sollte eine Konzentration auf die wichtigsten Hypothesen erfolgen. Die "wichtigsten Hypothesen" sind die Hypothesen, die Ursachen beschreiben, deren Erhaltung (Stärke-Symptome) bzw. deren Beseitigung (Schwäche-Symptome) für die Erreichung der Planungsziele von besonderer Bedeutung sind.

350

Aufgaben der Feinstudie

Inhaltlicher Analysezyklus Der inhaltliche Analysezyklus wird mit den Arbeitsschritten Grundsatzkritik (strukturelle Sichtweise) und Verfahrenskritik (prozedurale Sichtweise) durchgeführt. Bei der Grundsatzkritik wird die Frage nach der Notwendigkeit des Informationssystems und der durch das System unterstützten betrieblichen Aufgaben gestellt. Dabei wird nach der Top-down-Strategie vorgegangen. Vom Gesamtsystem ausgehend, werden alle Teilsysteme und alle Komponenten der Teilsysteme (jede Aufgabe, Teilaufgabe und Tätigkeit) nach den folgenden Fragen untersucht: • Sind sie zur Erfüllung der Unternehmensziele notwendig? • Welche Vorteile und welche Nachteile ergeben sich aus ihnen? • Kann auf sie verzichtet werden? Bei der Grundsatzkritik wird auch die Frage gestellt, ob Aufgaben nicht erfüllt werden, deren Erfüllung im Hinblick auf die Unternehmensziele erforderlich ist. Die Verfahrenskritik befaßt sich mit der Zweckmäßigkeit der zur Aufgabenerfüllung verwendeten Organisationsmittel und Sachmittel sowie der Eignung der Aufgabenträger. Dabei wird - wie bei der Grundsatzkritik - vom Gesamtsystem aus vorgegangen, und jedes Teilsystem und jede Komponente eines jeden Teilsystems (jede Aufgabe, Teilaufgabe und Tätigkeit) werden daraufhin untersucht, ob Organisationsmittel, Sachmittel und Aufgabenträger eingesetzt werden, welche die Erfüllung der Unternehmensziele bestmöglich unterstützen. Zur Beurteilung werden die Kenntnisse und Erfahrungen der Systemplaner und Benutzer über zweckmäßige Verfahren verwendet, soweit nicht schon die Grundkonzeption Aussagen darüber macht, welche Verfahren zweckmäßig sind. Die Auswirkungen neuer Verfahren auf die Planungsziele müssen prognostiziert werden. Dokumentieren der Stärken und Schwächen Der Verlauf und die Ergebnisse der Istzustandsanalyse werden mit geeigneten Dokumentationsmethoden dokumentiert (vgl. Lerneinheit DOKUM). Wichtigster Teil der Dokumentation ist der Stärken-/Schwächen-Katalog mit allen festgestellten Symptomen des Istzustands und den für die Symptome verantwortlichen Ursachen. Eine zweckmäßige, weil entwurfsunterstützende Gliederung des Stärken-/Schwächen-Katalogs kann den "Komponenten des Istzustands" folgen (siehe den nächsten Abschnitt). Neben dem Stärken-/Schwächen-Katalog sind alle bei der Istzustandsanalyse angestellten Entwurfsüberlegungen und vorbereitenden Entwurfsentscheidungen für die Projektierung wichtige Ergebnisse, die in einem Dokument beschrieben werden. Beide Dokumente sind Ausgangspunkt für das nachfolgende Auswerten der Feinstudie (vgl. Lerneinheit AFEIN). Komponenten des Istzustands Bei der Istzustandsanalyse wird das zu untersuchende System in der Regel in Komponenten zerlegt. Eine häufig verwendete, erfahrungsgemäß zweckmäßige Zerlegung ist die in Datensystem, Methodensystem, Arbeitsorganisation, Trans-

ANIST - Analysieren des Istzustands

351

portsystem und Sicherungssystem. Die Istzustandsanalyse wird in die Analyse des Datensystems ("Datenanalyse"), die Analyse des Methodensystems ("Methodenanalyse"), die Analyse der Arbeitsorganisation ("Arbeitsanalyse"), die Analyse des Transportsystems ("Kommunikationsanalyse") und die Analyse des Sicherungssystems ("Sicherheitsanalyse") zerlegt. • Datenanalyse: Zweck der Datenanalyse ist es, mit Hilfe der Informationen der Istzustandserfassung und der Vorstellungen über den Sollzustand die Stärken und Schwächen des Datensystems und deren Ursachen festzustellen. Eine typische Schwäche des Datensystems sind Inkonsistenzen, die z.B. durch Redundanz verursacht werden. Da die betrieblichen Nummernsysteme Teile des Datensystems sind, ist die Analyse der Nummernsysteme Teil der Datenanalyse (vgl. dazu das Demonstrationsbeispiel). • Methodenanalyse: Zweck der Methodenanalyse ist es, mit Hilfe der Informationen der Istzustandserfassung und der Vorstellungen über den Sollzustand die Stärken und Schwächen des Methodensystems und deren Ursachen festzustellen. Eine typische Schwäche des Methodensystems ist die zu starke Algorithmierung der Methoden im Hinblick auf die Strukturierbarkeit der betrieblichen Aufgaben. Obwohl eine wissensbasierte Implementierung notwendig wäre, wird mit prozeduraler Programmierung entwickelte Software verwendet. • Arbeitsanalyse: Zweck der Arbeitsanalyse ist es, mit Hilfe der Informationen der Istzustandserfassung und der Vorstellungen über den Sollzustand die Stärken und Schwächen der Arbeitsorganisation (Strukturorganisation und Ablauforganisation) und deren Ursachen festzustellen. Eine typische Schwäche der Strukturorganisation ist die starke Arbeitsgliederung ("Arbeitsteilung"); eine typische Schwäche der Ablauforganisation ist die unzureichende Koordinierung der durch Arbeitsteilung fragmentierten betrieblichen Aufgaben. Beide Schwächen können auf mangelhafte Qualifikation der Systemplaner, die den Handlungsspielraum für die Gestaltung der Arbeitsorganisation nicht ausgeschöpft haben, zurückgeführt werden. • Kommunikationsanalyse: Zweck der Kommunikationsanalyse ist es, mit Hilfe der Informationen der Istzustandserfassung und der Vorstellungen über den Sollzustand die Stärken und Schwächen des Transportsystems und deren Ursachen festzustellen. Eine typische Schwäche des Transportsystems ist eine zu lange Transportzeit, die z.B. auf die Verwendung ungeeigneter Transportmittel oder auf Medienbrüche zurückzuführen ist. • Sicherheitsanalyse: Zweck der Sicherheitsanalyse ist es, mit Hilfe der Informationen der Istzustandserfassung und der Vorstellungen über den Sollzustand die Stärken und Schwächen des Sicherungssystems und deren Ursachen festzustellen. Eine typische Schwäche des Sicherungssystems sind nicht ausreichend gegen Verlust oder unbefugtes Kopieren geschützte Datenbestände. Die Analyse der Komponenten erfolgt im wesentlichen in der genannten Reihenfolge, wobei - ähnlich dem interaktiven Charakter der Feinstudie (vgl. Lerneinheit ZAMFS) - die Analyse mit Interaktionen zwischen allen Komponenten durchgeführt wird. So erfolgt z.B. die Analyse des Datensystems für eine bestimmte Aufgabe und geht für diese Aufgabe in die Analyse des Methodensystems über, dann in die Analyse der Arbeitsorganisation usw., bis nach der

352

Aufgaben der Feinstudie

Analyse des Sicherungssystems für diese Aufgabe zum Datensystem zurückgekehrt und die nächste Aufgabe aufgegriffen wird. Demonstrationsbeispiel Es wird die Vorgehensweise bei der Analyse des Nummernsystems (vgl. Lerneinheit NUMSY) als Teil der Datenanalyse dargestellt. Einen ersten Überblick gibt das Nummernverzeichnis mit den Merkmalen, die für die Nummerung verwendet wurden. Die Analyse des Nummernsystems erfolgt in fünf Arbeitsschritten: Prüfen des Nummernaufbaus, Analysieren der Identifizierungsfunktion, Analysieren der Klassifizierungsfunktion, Analysieren der Nummernvergabe und Feststellen des Mengengerüsts. Erster Arbeitsschritt: Prüfen des Nummernaufbaus. Dazu sind folgende Fragen zu beantworten: • Wieviele Stellen hat die Nummer (Stellenanzahl)? • Ist die Stellenanzahl konstant? • Welche Stellen sind numerisch, welche alphanumerisch; welche Stellen haben Sonderzeichen? • Ist der Aufbau starr (eine bestimmte Stelle hat immer die gleiche Bedeutung) oder variabel? • Welche Stellen sind identifizierend, welche sind klassifizierend? • Welche Bedeutung haben die klassifizierenden Stellen? • Ist das Begriffssystem hierarchisch, nebengeordnet oder bereichsweise gegliedert oder wird eine kombinierte Gliederung verwendet? • Werden Gliederungsmittel (z.B. Punkt, Schrägstrich, Bindestrich) verwendet? • Ist die Schreibweise der Nummer bei allen Benutzern gleich? - Wie lange besteht das Nummernsystem schon und welche Änderungen wurden vorgenommen? Zweiter Arbeitsschritt: Analysieren der Identifizierungsfunktion. Dabei ist zu überprüfen: • Haben alle Nummerungsobjekte eine Identnummer? • Haben dieselben Nummerungsobjekte in Abhängigkeit von ihrer Verwendung, Herstellung usw. verschiedene Identnummem? • Werden für dieselben Nummerungsobjekte in verschiedenen Abteilungen verschiedene Identnummem verwendet? • Können auf Grund der Identnummer Nummerungsobjekte eindeutig und einfach zugeordnet werden? • Kann sich die Identnummer für ein Nummerungsobjekt während seiner Lebensdauer ändern? Dritter Arbeitsschritt: Analysieren der Klassifizierungsfunktion. Dabei ist zu überprüfen: • Hat die Klassifizierung einen systematischen Aufbau? • Werden unabhängige Merkmale auch durch unabhängige Nummernteile dargestellt? • Haben alle Nummerungsobjekte eine Klassifizierungsnummer? • Wird dasselbe Nummerungsobjekt mit verschiedenen Klassifizierungsnummern angesprochen?

ANIST - Analysieren des Istzustands

353

• Ist die Gruppenzuordnung eindeutig? • Mußten auf Grund des unterschiedlichen Wachstums einzelne Gruppen entgegen der Systematik "ausgelagert" werden? Vierter Arbeitsschritt: Analysieren der N u m m e r n v e r g a b e . Dabei interessiert vor allem: • Welche Hilfsmittel werden bei der Nummernvergabe verwendet? • Gibt es eine Arbeitsanweisung für die Nummernvergabe? • Werden Ident- und Klassifizierungsnummern von verschiedenen Abteilungen vergeben? - Wie lange dauert die Vergabe einer neuen Nummer? • Wie lange dauert das Umsetzen der Nummer in Klartext? • Werden Doppelbenummerungen verhindert? • Ist ein vollständiger Nummernschlüssel vorhanden? • Werden frei werdende Identnummern wieder verwendet? Fünfter Arbeitsschritt: Feststellen des Mengengerüsts. Dabei ist zu klären: • Wieviele Nummerungsobjekte gibt es? • Wieviele davon sind aktuell? • Wieviele Nummerungsobjekte kommen (jährlich oder monatlich) hinzu bzw. entfallen? • Wie stark ist die Belegung in den einzelnen Klassifizierungsgruppen? • Welche Erweiterungsmöglichkeiten bestehen bei der Klassifizierung? • Wieviele Klassifizierungsgruppen sind seit der Einführung neu hinzu gekommen? B e i der Beurteilung der Analyseergebnisse sollte beachtet werden, daß es in der Regel einfacher ist, ein bestehendes Nummernsystem zu verbessern, als es durch ein neues zu ersetzen. Methodenverweise Methoden der Istzustandsanalyse (Lerneinheit ISTAN); Methoden der Kommunikationsanalyse (Lerneinheit KOMAN); Matrixanalyse (Lerneinheit MATOX); Wertanalyse (Lerneinheit WERTA); Wirtschaftlichkeitsanalyse (Lerneinheit WIRTA); Nutzwertanalyse (Lerneinheit NUTZW); Kreativitätstechniken (Lerneinheit K R E A T ) ; Darstellungsmethoden (Lerneinheit D A R S T ) ; Dokumentationstechniken (Lerneinheit DOKUM). Kontrollfragen 1. 2. 3. 4. 5.

Welchen Zweck verfolgt die Istzustandsanalyse? In welche Aufgaben kann die Istzustandsanalyse gegliedert werden? In welchen Arbeitsschritten verläuft der formale Analysezyklus? Warum können die Hypothesen "Veränderungen/Symptome" nicht verifiziert werden? Welche Fragen werden mit der Grundsatzkritik beantwortet?

Quellenliteratur Schmidt, G.: Methode und Techniken der Organisation. 8. A., Verlag Schmidt, Gießen 1989 Wittlage, H.: Methoden und Techniken praktischer Organisationsarbeit. 2. A., Verlag Neue Wirtschafts-Briefe, Herne/Berlin 1986

AFEIN - Auswerten der Feinstudie Lernziele Sie kennen die Aufgaben der Systemplanung, die zusammen das Auswerten der Feinstudie ausmachen. Sie können daran nachweisen, daß eine ausschließliche Istzustandsorientierung der Feinstudie nicht zweckmäßig ist. Sie kennen Einflußfaktoren, mit deren Hilfe entschieden werden kann, welche Schwächen des Istzustands, unabhängig von der Schaffung eines neuen Informationssystems, durch Optimierungsmaßnahmen beseitigt werden sollen. Sie kennen Beispiele für Optimierungsmaßnahmen. Definitionen und Abkürzungen Abfragesprache (query language) = eine Programmiersprache zur Formulierung von Transaktionen für die Gewinnung von Informationen aus Datenbasen in Datenbanksystemen durch den Benutzer. Antwortzeit (response time) = die Zeit zwischen dem Ende einer Benutzereingabe und dem Zeitpunkt, zu dem die vollständige Antwort dazu vorliegt; ein Merkmal für Leistung. Benutzerberechtigung (user authority) = das Anrecht, der Anspruch oder die Befugnis eines Benutzers, auf bestimmte Teile der Methodenbasis oder der Datenbasis zugreifen zu können. Synonym: Zugriffsberechtigung. Berichtssystem (report system) = ein Anwendungssystem, bei dem die Ausgabe der Benutzerdaten zu vorgeplanten Zeitpunkten erfolgt, also nicht auf Grund einer vom aktuellen Informationsbedarf ausgelösten Anforderung durch die Benutzer. Funktionalität (functionality) = die Art und die Anzahl der Funktionen, die durch ein System abgedeckt werden. Synonym: Funktionsumfang. Leistungsfähigkeit (Performance ability) = die Fähigkeit eines Systems, in quantitativer oder qualitativer Hinsicht bestimmte Funktionen zu erfüllen (kurz: "Funktionserfüllung pro Zeiteinheit"). Merkmal (characteristic) = die Eigenschaft eines Objekts, die es kennzeichnet und von anderen Objekten unterscheidet. Optimieren (optimizing) = das Untersuchen und gegebenenfalls Anpassen eines Systems so, daß seine Funktionalität und/oder Leistungsfähigkeit verbessert wird, ohne das System grundlegend zu verändern. Optimierungsmaßnahme (optimization means) = jeder erfolgreiche Versuch, den Istzustand ohne grundlegende Systemänderung zu verbessern. Prüfmatrix (check matrix) = eine Matrix zur systematischen Darstellung von zwei Elementemengen und ihren Beziehungen mit dem Zweck der Überprüfung ihrer Beziehungen. Rationalisieren (rationalization) = das Bestreben, ein System so zu gestalten, daß es den gesetzten Zielen besser entspricht, retrograd (backward) = bei einer Untersuchung rückwärts gehen (z.B. am Ende eines Arbeitsablaufs beginnend); im Unterschied dazu: progressiv.

AFEIN - Auswerten der Feinstudie

355

Zweck des Auswertens der Feinstudie Das Auswerten der Feinstudie verfolgt zwei Zwecke, und zwar einen Hauptzweck und einen Nebenzweck: • Hauptzweck: Mit Hilfe der erkannten Stärken und Schwächen des Istzustands soll die Grundkonzeption überarbeitet ("angepaßt") werden. • Nebenzweck: Mit Hilfe der erkannten Stärken und Schwächen des Istzustands sollen kurzfristig wirksame Verbesserungsmaßnahmen durchgeführt, also der Istzustand optimiert werden. Input für das Auswerten der Feinstudie sind die Grundkonzeption, wie sie in der Vorstudie erarbeitet wurde (vgl. Lerneinheit GRUND), und der Stärken/Schwächen-Katalog, wie er als Ergebnis der Istzustandsanalyse vorliegt (vgl. Lerneinheit ANIST). Output des Auswertens der Feinstudie sind die angepaßte Grundkonzeption und ein Maßnahmenkatalog für die Istzustandsoptimierung. Dies veranschaulicht Abbildung AFEIN-1. W \

Grundkonzeption | | § | ] 2p

EStärken-/Schwächenkatalogj m m m m m w

Auswerten der Feinstudie •7777777777777^ Angepaßte | p Grundkonzeption

~^777777777777^7Xr7777777777777777^ p Maßnahmenkatalog Istzustandsoptimierung

Abb. AFEIN-1: Auswerten der Feinstudie

Den beiden Aufgaben kommt eine ähnliche Weichenstellung wie dem Entwerfen der Grundkonzeption in der Vorstudie zu. Sie zeigen, wie in der Feinstudie die von Rückkopplungen durchsetzte, phasenweise Konkretisierung des Systementwurfs fortgesetzt wird. Die Feinstudie, die bei oberflächlicher Betrachtung und nicht konsequenter Anwendung dieser Vorgehensweise durch eine ausschließliche Istzustandsorientierung gekennzeichnet ist, erweist sich damit auch als ein Instrument zur Entwicklung des Sollzustands. Dies setzt allerdings voraus, daß beim Durchführen der Feinstudie von den genannten Zwecken ausgegangen wird und retrograd der Aufgabenumfang der Istzustandsanalyse und daraus der Aufgabenumfang der Istzustandserfassung abgeleitet werden. Optimieren des Istzustands Optimieren des Istzustands heißt, kurzfristig wirksame Maßnahmen auszuarbeiten und durchzuführen, die eine Bessergestaltung des Istzustands bezüglich seiner Funktionalität und/oder Leistungsfähigkeit bewirken. Die Motivation für diese Aufgabe resultiert aus den folgenden Überlegungen: Entweder führt die Feinstudie insgesamt zu dem Ergebnis, daß die Grundkonzeption verworfen und

356

Aufgaben der Feinstudie

der Systemplanungsprozeß abgebrochen wird. In diesem Fall werden die Ergebnisse der Feinstudie nur für die Optimierung des Istzustands verwertet. Oder die Feinstudie führt zu dem Ergebnis, das Projekt fortzusetzen; in diesem Fall wird davon ausgegangen, daß bis zur Installierung des zu schaffenden Informationssystems positive Effekte durch eine Optimierung des Istzustands erreicht werden können. Weil bei der Optimierung des Istzustands dessen Grundkonzeption nicht verändert werden soll, müssen sich die Optimierungsmaßnahmen im wesentlichen darauf beschränken, bestimmte physische Attribute des Istzustands zu verändern; das logische Modell des Istzustands wird nicht verändert. Für die Beantwortung der Frage, welche Stärken durch Optimierungsmaßnahmen gefördert oder zumindest erhalten und welche Schwächen durch Optimierungsmaßnahmen beseitigt oder zumindest reduziert werden sollen, sind die folgenden Einflußfaktoren von Bedeutung: • Die Projektdauer zwischen dem Zeitpunkt des Abschlusses der Istzustandsanalyse und dem Zeitpunkt der produktiven Verwendbarkeit des Informationssystems, durch welche die Existenzdauer bestehender Schwächen maximal begrenzt wird. • Der Zeitraum, der bis zum Wirksamwerden der die Stärken fördernden bzw. die Schwächen reduzierenden Optimierungsmaßnahmen voraussichtlich vergehen wird. • Die mit der Realisierung der Optimierungsmaßnahmen verbundenen Kosten und der damit bewirkte Nutzen. • Die Verfügbarkeit der notwendigen (z.B. der personellen) Ressourcen für die Erarbeitung und Durchführung der Optimierungsmaßnahmen. Die Istzustandsoptimierung sollte immer als Nebenzweck der Systemplanung begriffen werden; eine zu starke Konzentration auf die Istzustandsoptimierung kann zu einer Ablenkung von den Planungszielen führen. Anpassen der Grundkonzeption Ergebnis der Vorstudie ist die Grundkonzeption des zu schaffenden Informationssystems, also die optimale Lösungsalternative zur Deckung des durch die Planungsziele definierten Bedarfs (vgl. Lerneinheit GRUND). Anpassen der Grundkonzeption heißt, mit den als Stärken und Schwächen des Istzustands vorliegenden Ergebnissen der Istzustandsanalyse die Grundkonzeption daraufhin zu überprüfen, ob V e r ä n d e r u n g e n erforderlich sind. Veränderungen sind dann erforderlich, wenn mit der Grundkonzeption wesentliche Stärken des Istzustands beseitigt oder deutlich reduziert werden und/oder wesentliche Schwächen des Istzustands durch die Grundkonzeption nicht beseitigt oder zumindest nicht reduziert werden. Möglicherweise können Veränderungen in einem Ausmaß erforderlich sein, das es notwendig macht, die Grundkonzeption insgesamt zu verwerfen und im Planungsprozeß zumindest in die Durchführbarkeitsstudie zurückzukehren, um ein anderes Systemkonzept als Grundkonzeption auszuwählen; bei einer gründlich durchgeführten Vorstudie wird dies nicht der Fall sein.

AFEIN - Auswerten der Feinstudie

357

Anpassungen der Grundkonzeption können sich auf alle wichtigen Eigenschaften des zu schaffenden Informationssystems, die in der Grundkonzeption abgebildet sind, beziehen. Die Anpassungen betreffen die beiden folgenden Bereiche: • das logische Modell des Systementwurfs, insbesondere das Aufgabensystem mit seinen Daten und Methoden; • das physische Modell des Systementwurfs, insbesondere die vorgesehenen Techniksysteme und ihre Zuordnung auf das Aufgabensystem. Mit Hilfe der erkannten Stärken und Schwächen des Istzustands und ihrer Symptome werden zunächst die Anforderungen (vgl. Lerneinheiten SACHZ und FORMZ) überprüft, und es wird die Auswirkung veränderter Anforderungen auf die Grundkonzeption ermittelt. Dabei wird versucht festzustellen, wie die Merkmale der Grundkonzeption die Stärken und Schwächen beeinflussen. Dies macht es erforderlich, sämtliche Entwurfsentscheidungen der Durchführbarkeitsstudie - unter Verwendung des Informationsgewinns der Feinstudie - nachzuvollziehen und daraufhin zu überprüfen, ob die Entwurfsergebnisse vor dem Hintergrund der Planungsziele weiterhin als optimal anzusehen sind. Falls nein, sind Anpassungen erforderlich. Häufig entziehen sich Systemplaner dieser Aufgabe mit der Begründung, daß ihre Durchführung die Erreichung der Projektziele nicht fördert. Bei einer nur kurzfristigen, auf "schnellen Projektfortschritt" angelegten Betrachtungsweise mag dies zutreffen; langfristig gesehen führt dies zu nur schwer korrigierbaren Mängeln des neuen Informationssystems. Zur systematischen Darstellung des Zusammenhangs zwischen den Stärken und Schwächen des Istzustands einerseits und den Merkmalen der Grundkonzeption andererseits kann ein analog zur Prüfmatrix (vgl. Lerneinheit ANIST) aufgebautes Analyseinstrument verwendet werden. Schreibt man die Ursachen der Stärken und Schwächen des Istzustands in die Zeilen und die Merkmale der Grundkonzeption in die Spalten der Prüfmatrix, kann mit Hilfe der Matrixanalyse (vgl. Lerneinheit MATRX) das Erkennen der Zusammenhänge zwischen den Ursachen der Stärken und Schwächen und den Merkmalen der Grundkonzeption herausgearbeitet und dargestellt werden. Demonstrationsbeispiel Es werden Beispiele für Schwächen des Istzustands genannt und erläutert. Unter Zugrundelegung der oben genannten Einflußfaktoren führen sie in der Regel zu Maßnahmen der Istzustandsoptimierung. Solche Maßnahmen werden beispielhaft angegeben. Die Gesamtheit solcher Optimierungsmaßnahmen wird in der Praxis oft als "kleine Lösung" oder als "kleiner Rationalisierungseffekt" bezeichnet (im Gegensatz zur "großen Lösung" oder zum "großen Rationalisierungseffekt", der durch die Schaffung des neuen Informationssystems erwartet wird). Die Schaffung eines neuen Informationssystems wird zum Anlaß genommen, den Istzustand sofort zu verbessern. Wie die nachfolgenden Beispiele unter anderem zeigen, handelt es sich häufig um Schwächen, die ohne das motivierende Ziel der Systemplanung, eine wesentlich veränderte bzw. eine neue Grundkonzeption zum Ausgangspunkt der Schaffung eines Informationssystems zu machen, nicht aufgedeckt würden.

358

A ufgaben der Feinstudie

• Beispiel 1: Der Informationsbedarf eines Aufgabenträgers wird inhaltlich nicht gedeckt, obwohl die zur Bedarfsdeckung erforderlichen Daten im Datensystem vorhanden sind und der Aufgabenträger einen direkten Zugriff auf die Daten haben könnte (Symptom). Ursache dieser Schwäche ist die nicht zweckmäßige Benutzerberechtigung. Optimierungsmaßnahme: Erweiterung der Benutzerberechtigung. • Beispiel 2: Symptom ist wie im Beispiel 1 der nicht gedeckte Informationsbedarf. Als Ursache wird festgestellt, daß der Aufgabenträger nicht qualifiziert ist, u m mit der ihm verfügbaren Abfragesprache umzugehen und so den Informationsbedarf zu decken. Optimierungsmaßnahme: Benutzerschulung. • Beispiel 3: Die Antwortzeiten bei der Verbuchung von Zahlungseingängen im Anwendungssystem Finanzbuchhaltung sind zu lang und behindern den Arbeitsablauf; sie sind insbesondere durch erhebliche Schwankungen gekennzeichnet (Symptom). Als Ursache werden Systemüberlastungen durch Programmtests festgestellt. Optimierungsmaßnahme: Verlagerung der Programmtests in Zeiten unterdurchschnittlicher Systemauslastung. • Beispiel 4: Statistiken werden zu festgelegten Berichtsterminen erstellt, auf Papier ausgedruckt und verteilt, ohne daß zu diesen Zeitpunkten ein Informationsbedarf der Aufgabenträger besteht (Symptom). Ursache ist die Verwendung eines zentralen Berichtssystems. Optimierungsmaßnahme: Umstellung der Statistikerstellung auf die Anforderungszeitpunkte der Aufgabenträger durch Verwendung der vorhandenen Abfragesprache. • Beispiel 5: Beschwerden von Teilnehmern an Besprechungen, die Protokolle verspätet erhalten (Symptom). Ursache: Die Kapazität der verwendeten Drucker reicht bei Spitzenbelastungen nicht aus, anderseits sind vorhandene Vervielfaltigungssysteme nicht ausgelastet. Optimierungsmaßnahme: Statt des mehrfachen Druckens entsprechend der Größe des Verteilers Umstellen auf Einfachausdruck und Vervielfältigen über vorhandene Kopiergeräte. • Beispiel 6: Die Durchlaufzeiten der Kundenaufträge sind zu lang, insbesondere die Bearbeitungszeiten in der Auftragserfassung (Symptom). Ursache: Geringe Arbeitszufriedenheit bei den Mitarbeitern der Auftragserfassung, welche die ihnen zugeordneten Tätigkeiten als gleichförmig und eintönig empfinden. Optimierungsmaßnahme: Arbeitsplatzwechsel. Methodenverweise Matrixanalyse (Lerneinheit MATRX); Methoden der Istzustandsanalyse (Lerneinheit ISTAN); Methoden der Kommunikationsanalyse (Lerneinheit KOMAN). Kontrollfragen 1. Welche Aufgaben umfaßt das Auswerten der Feinstudie? 2. Mit welchen Argumenten kann belegt werden, daß die Feinstudie nicht ausschließlich istzustandsorientiert ist? 3. Welche Motive können für die Notwendigkeit der Istzustandsoptimierung genannt werden? 4. Welche Einflußfaktoren können für die Beantwortung der Frage herangezogen werden, ob eine Schwäche des Istzustands bei der Istzustandsoptimierung beseitigt werden soll? 5. Warum ist die Matrixanalyse ein brauchbares methodisches Hilfsmittel beim Auswerten der Feinstudie?

VFEIN - Vorgehensweise bei der Feinstudie Lernziele Sie kennen verschiedene Vorgehensweisen bei der Istzustandsuntersuchung und können deren Zweckmäßigkeit anhand charakteristischer Eigenschaften beurteilen. Sie können eine geeignete Vorgehensweise für die Planung und Durchführung der Istzustandsuntersuchung in der Feinstudie festlegen. Definitionen und Abkürzungen Arbeitsablauf (operations sequence) = die Gliederung der zur Aufgabenerfüllung erforderlichen Tätigkeiten ("Objekt/Verrichtung-Kombinationen") in räumlicher, zeitlicher, logischer und mengenmäßiger Hinsicht. Informationsbeziehung (information relationship) = die Tatsache, daß die Ausgabedaten einer Aufgabe ganz oder teilweise Eingabedaten einer anderen Aufgabe sind (vice versa). Informationsfluß (information flow) = der Weg von Information durch ein System mit seinen sachlichen und zeitlichen Zusammenhängen. Informationsverarbcitungskomplex (information processing complex) = eine Menge von Aufgaben, deren Elemente bezüglich ihrer Phase gleichartig, bezüglich ihres Sachcharakters aber unterschiedlich sind. Integration (integration) = die Herstellung oder Wiederherstellung eines Ganzen durch Vereinigen oder Verbinden logisch zusammengehöriger Teile. Istzustandsuntersuchung (current system investigation) = die zusammenfassende Bezeichnung für Istzustandserfassung und Istzustandsanalyse. Methodenbeziehung (method relationship) = die Tatsache, daß die Verwendung einer Methode für die Durchführung einer Aufgabe die Methodenverwendung für die Durchführung einer logisch verbundenen Aufgabe beeinflußt. Organigramm (Organization chart) = die grafische Abbildung der Strukturorganisation in unterschiedlicher Form (meist als Baum). Phase (phase) = die formale Gliederung einer Aufgabe nach dem zeitlichen Ablauf der Verrichtungen (z.B. in Planen, Abrechnen, Analysieren). Prozeßsicht (process view) = die Betonung der ablauforganisatorischen gegenüber den strukturorganisatorischen Eigenschaften einer Aufgabe. Rang (rank) = die formale Gliederung einer Aufgabe nach der Kompetenzebene der Verrichtungen (z.B. in Entscheiden, Durchführen, Kontrollieren). Sachcharakter (subject) = die formale Gliederung einer Aufgabe nach dem Inhalt der Verrichtungen (z.B. in Planen des Personalbedarfs und Planen des Materialbedarfs). Struktureinheit (structural unit) = jedes Element der Strukturorganisation, unabhängig vom Aufgabenumfang und von der Aufgabenart (z.B. eine Stelle). Teilsystem (part system) = eine Menge von Aufgaben, deren Elemente bezüglich ihres Sachcharakters gleichartig, bezüglich ihrer Phase aber unterschiedlich sind (z.B. alle Personalaufgaben). Verrichtung (execution) = jede körperliche oder geistige Tätigkeit, die an einem materiellen oder immateriellen Objekt durchgeführt wird.

360

Methoden und Techniken der Feinstudie

Überblick über die alternativen Vorgehensweisen Für die Istzustandsuntersuchung gibt es folgende alternative Vorgehensweisen (vgl. Abbildung VFEIN-1): • das Vorgehen nach Struktureinheiten, also nach Stellen, Abteilungen usw. ("abteilungsorientierte Feinstudie"); • das Vorgehen nach dem Informationsfluß ("informationsflußorientierte Feinstudie"), bei dem zwei Varianten zu unterscheiden sind, und zwar das Vorgehen innerhalb von Informationsverarbeitungskomplexen und das Vorgehen innerhalb von Teilsystemen; • das kombinierte Vorgehen nach Struktureinheiten und nach dem Informationsfluß ("kombinierte Feinstudie"). Diese Vorgehensweisen werden nachfolgend dargestellt; es wird auf ihre wichtigsten Merkmale ("Vorteile" und "Nachteile") eingegangen.

Abb. VFEIN-1: Vorgehensweisen bei der Feinstudie

Abteilungsorientierte

Feinstudie

Bei der abteilungsorientierten Feinstudie erfolgen Erfassung und Analyse des Istzustands nach den Struktureinheiten, wie sie aus dem Organigramm (vgl. Lerneinheit DARST) entnommen werden können. Da Organigramme häufig nicht aktuell sind, ist es zweckmäßig, zunächst eine Aktualisierung vorzunehmen. Die Struktureinheiten werden als mehr oder weniger in sich abgeschlossene Teilsysteme betrachtet. In welcher Reihenfolge die Struktureinheiten untersucht werden, ist für die Kennzeichnung der Vorgehensweise nebensächlich, kann aber für die Durchführung einer Feinstudie von Bedeutung sein (z.B. bezüglich des Zeitaufwands). Die Reihenfolge der Untersuchung ergibt sich in der Regel aus der Verfügbarkeit der Struktureinheiten bzw. deren Mitarbeiter für die Durchführung der Feinstudie (Mitwirkungsbedarf bzw. Akzeptanz von Störungen). Vorteile der abteilungsorientierten Feinstudie sind: Jede Struktureinheit wird umfassend untersucht, die Erhebungsdaten sind daher relativ genau. Strukturorganisatorisch bedingte Stärken und Schwächen können leicht erkannt werden. Eine Bindung an eine bestimmte, z.B. durch den Arbeitsablauf vorgegebene logische Reihenfolge der Untersuchung der Struktureinheiten besteht nicht, sodaß Planung und Durchführung der Untersuchung erleichtert werden.

VFEIN - Vorgehensweise

bei der Feinstudie

361

Nachteile der abteilungsorientierten Feinstudie sind: Die mehr oder weniger in sich abgeschlossene Untersuchung einzelner Struktureinheiten führt zum Verlust des Zusammenhangs zwischen den einzelnen Aufgaben und zwischen den einzelnen Struktureinheiten, in denen diese Aufgaben verrichtet werden. Das Erkennen von abteilungsübergreifenden Prozessen wird erschwert; es besteht die Gefahr einer übertrieben detaillierten, über das Ziel der Feinstudie hinausgehenden Erhebung und Analyse des Istzustands. Für die Systementwicklung werden daher einerseits unvollständige Grundlagen geschaffen (z.B. fehlende Prozeßsicht, sodaß definierte Integrationsziele nicht erreicht werden können), andererseits werden Grundlagen mit einem Detaillierungsgrad erarbeitet, der nicht nur überflüssig ist, sondern auch zu Unübersichtlichkeit (z.B. durch detaillierte Erhebung von Werten physischer Attribute des Istzustands) führt und wesentliche Fakten und Zusammenhänge verdeckt. Die Zuordnung von Mitarbeitern der Planungsgruppe auf Projektaufgaben kann nicht in der Weise erfolgen, wie sie für die spätere Systementwicklung notwendig ist (bei der ausdrücklich nicht nach Struktureinheiten vorgegangen wird). Im allgemeinen überwiegen die Nachteile, sodaß eine ausschließliche Abteilungsorientierung der Feinstudie nicht zweckmäßig ist. Informationsflußorientierte Feinstudie innerhalb von verarbeitungskomplexen

Informations-

Bei der informationsflußorientierten Feinstudie innerhalb von Informationsverarbeitungskomplexen erfolgt die Erfassung und Analyse des Istzustands nach dem Informationsfluß innerhalb der zuvor gebildeten Informationsverarbeitungskomplexe (zur Bildung der Informationsverarbeitungskomplexe siehe das Demonstrationsbeispiel). Dabei werden nur die Struktureinheiten in die Untersuchung einbezogen, die an der Bearbeitung von Aufgaben innerhalb der definierten Informationsverarbeitungskomplexe beteiligt sind. In den Struktureinheiten werden wiederum nur die Aufgaben untersucht, die zu den definierten Informationsverarbeitungskomplexen gehören. In diesen Struktureinheiten und Informationsverarbeitungskomplexen wird bei der Untersuchung dem Informationsfluß gefolgt; es wird also in der Reihenfolge des Arbeitsablaufs prozeßorientiert vorgegangen (z.B. im Informationsverarbeitungskomplex "langfristige Planung" wird zuerst die Absatzplanung, dann die Fertigungsplanung und dann die Beschaffungsplanung untersucht). Vorteile der informationsflußorientierten Feinstudie innerhalb von Informationsverarbeitungskomplexen sind: Die schnelle und lückenlose Untersuchung aller Aufgaben eines weitgehend in sich abgeschlossenen Informationsverarbeitungskomplexes, unabhängig von den beteiligten Struktureinheiten, ist möglich. Die logischen Zusammenhänge zwischen den Aufgaben innerhalb eines Informationsverarbeitungskomplexes und zwischen den verschiedenen Informationsverarbeitungskomplexen werden gut erkannt. Die Zuordnung von Mitarbeitern der Planungsgruppe auf Projektaufgaben kann in der Feinstudie bereits in der Weise erfolgen, wie sie für die spätere Systementwicklung notwendig ist. Nachteile der informationsflußorientierten Feinstudie innerhalb von Informationsverarbeitungskomplexen sind: Das Erkennen von Zusammenhängen zwi-

362

Methoden und Techniken der Feinstudie

sehen den Aufgaben gleichen Sachcharakters (z.B. zwischen den Personalaufgaben), aber verschiedener Phasen (z.B. zwischen der Planung des Personaleinsatzes und der Abrechnung des Personaleinsatzes), wird erschwert. Die mehrmalige Untersuchung der gleichen Struktureinheiten ist notwendig, wenn - was die Regel ist - Struktureinheiten an der Bearbeitung von Aufgaben mehrerer Informationsverarbeitungskomplexe beteiligt sind; Überschneidungen im Untersuchungsgegenstand sind unvermeidlich. Im allgemeinen überwiegen die Vorteile; eine ausschließliche Informationsflußorientierung der Feinstudie innerhalb von Informationsverarbeitungskomplexen ist aber trotzdem nicht zweckmäßig. Informationsflußorientierte Feinstudie innerhalb von Teilsystemen Die Vorgehensweise der informationsflußorientierten Feinstudie innerhalb von Teilsystemen ist völlig analog zur informationsflußorientierten Feinstudie innerhalb von Informationsverarbeitungskomplexen; statt der Informationsverarbeitungskomplexe werden Teilsysteme als Untersuchungsbereiche verwendet. Vorteile der informationsflußorientierten Feinstudie innerhalb von Teilsystemen sind: Die schnelle und lückenlose Untersuchung aller Aufgaben eines in sich weitgehend abgeschlossenen Teilsystems, unabhängig von den beteiligten Struktureinheiten, ist möglich. Die logischen Zusammenhänge zwischen den Aufgaben innerhalb eines Teilsystems und zu anderen Teilsystemen werden gut erkannt. Besonders vorteilhaft ist, daß für die einzelnen Teilsysteme die Zusammenhänge zwischen den Informationsverarbeitungskomplexen (z.B. zwischen der Planung, Überwachung und Steuerung sowie der Abrechnung und Analyse) gleichartiger Aufgaben (z. B. Personalaufgaben) erkannt werden können; die Prozeßsicht wird hervorgehoben. Der gleichartige Sachcharakter der Aufgaben ermöglicht den Einsatz von Mitarbeitern der Planungsgruppe, die für diese Aufgaben besonders qualifiziert sind und die auch für die Systementwicklung innerhalb dieser Teilsysteme später eingesetzt werden sollen. Es bestehen gute sachliche Voraussetzungen für eine intensive Benutzerbeteiligung. Nachteile der informationsflußorientierten Feinstudie innerhalb von Teilsystemen sind: Das Erkennen von Zusammenhängen zwischen den Aufgaben gleicher Phase (z.B. zwischen den Aufgaben der Planung), aber verschiedenen Sachcharakters (z.B. zwischen den Aufgaben der Personalplanung und den Aufgaben der Fertigungsplanung) wird erschwert; diese Zusammenhänge sind aber erfahrungsgemäß sehr eng. Die Definition von Teilsystemen bereitet Schwierigkeiten (weil z.B. Aufgaben der Abrechnung und vor allem der Analyse über mehrere Teilsysteme greifen, so etwa die Abrechnung des Personaleinsatzes, des Materialeinsatzes und die Auftragsabrechnung). Die mehrmalige Untersuchung der gleichen Struktureinheiten ist dann erforderlich, wenn mehrere Struktureinheiten an der Bearbeitung von Aufgaben mehrerer Teilsysteme beteiligt sind. Wie bei der informationsflußorientierten Feinstudie innerhalb von Informationsverarbeitungskomplexen, überwiegen auch bei der informationsflußorientierten Feinstudie innerhalb von Teilsystemen die Vorteile; eine ausschließliche Informationsflußorientierung der Feinstudie innerhalb von Teilsystemen ist aber trotz-

VFEIN - Vorgehensweise bei der Feinstudie

363

dem nicht zweckmäßig (es sei denn, das Projekt umfaßt nur Aufgaben eines Teilsystems). Kombinierte Feinstudie Bei der kombinierten Feinstudie erfolgt die Istzustandserfassung nach Struktureinheiten mit einer Orientierung auf die zu untersuchenden Informationsverarbeitungskomplexe; die Istzustandsanalyse erfolgt nach Informationsverarbeitungskomplexen. Der Informationsflußorientierung innerhalb von Informationsverarbeitungskomplexen wird gegenüber der Informationsflußorientierung innerhalb von Teilsystemen deshalb der Vorzug gegeben, weil die logischen Zusammenhänge zwischen den Aufgaben gleicher Phase enger sind als die zwischen den Aufgaben gleichen Sachcharakters. (Die strukturorganisatorische Gliederung betrieblicher Aufgaben, also die Bildung der Struktureinheiten, folgt meist der Gliederung nach dem Sachcharakter der Aufgaben.) Die logischen Zusammenhänge zwischen den Aufgaben gleicher Informationsverarbeitungskomplexe bestehen nicht nur als Informationsbeziehungen, sondern auch als Beziehungen zwischen den Methoden der Aufgabendurchführung ("Methodenbeziehung"). So bestehen z.B. zwischen Materialplanung, Materialdisposition und Materialabrechnung im wesentlichen Informationsbeziehungen, während zwischen Materialplanung, Produktionsplanung und Personalplanung darüber hinaus auch Methodenbeziehungen bestehen (z.B. kann das Material nicht detaillierter geplant werden, als das Produktionsprogramm geplant wird). Die Istzustandserfassung nach Struktureinheiten orientiert sich an den zu untersuchenden Informationsverarbeitungskomplexen wie folgt: • Struktureinheiten, deren Aufgaben in keinem Zusammenhang mit den zu untersuchenden Informationsverarbeitungskomplexen stehen, werden nicht untersucht. • In Struktureinheiten, die lediglich Eingabedaten für die zu untersuchenden Informationsverarbeitungskomplexe liefern oder lediglich Ausgabedaten von diesen erhalten, werden nur die entsprechenden Arbeitsvorgänge untersucht. • In Struktureinheiten, in denen neben anderen Aufgaben nur einzelne Aufgaben der zu untersuchenden Informationsverarbeitungskomplexe bearbeitet werden, werden nur diese Aufgaben untersucht. • Nur die Struktureinheiten werden vollständig untersucht, deren Aufgaben überwiegend oder sogar ausschließlich zu den zu untersuchenden Informationsverarbeitungskomplexen gehören. Die Istzustandsanalyse erfolgt nach Informationsverarbeitungskomplexen, ohne Rücksicht auf die Struktureinheiten. Beim Analysieren eines Informationsverarbeitungskomplexes werden die Aufgaben aller anderen Informationsverarbeitungskomplexe, die auf den analysierten Informationsverarbeitungskomplex Einfluß haben oder von diesem beeinflußt werden, einbezogen (z.B. wird die Aufgabe "Fertigungsvorbereitung" im Informationsverarbeitungskomplex "kurzfristige Planung" von der Aufgabe "Leistungsstatistik der Produktion" im Informationsverarbeitungskomplex "Abrechnung und Analyse" beeinflußt; beide Aufgaben werden daher gemeinsam analysiert).

364

Methoden und Techniken der Feinstudie

Entscheidender Vorteil der kombinierten Feinstudie ist, daß die Zusammenhänge zwischen den Aufgaben innerhalb der Informationsverarbeitungskomplexe, aber auch die Zusammenhänge zwischen den Informationsverarbeitungskomplexen, zwangsläufig erkannt werden; die Prozeßsicht wird in den Vordergrund gerückt. Dies ist für die Systementwicklung von entscheidender Bedeutung, weil dadurch die Informationen erarbeitet werden, die für die Erreichung des geplanten Integrationsgrads (vgl. Lerneinheit FORMZ) erforderlich sind, und weil erfahrungsgemäß (häufig: nur) durch Ausschöpfen des vorhandenen Integrationspotentials nennenswerte Nutzenbeiträge realisiert und die ökonomischen Planungsziele (insbes. Wirtschaftlichkeit) erreicht werden können. Der Nachteil des höheren Aufwands für die Durchführung der Istzustandsuntersuchung - im Vergleich mit anderen Vorgehensweisen - ist demgegenüber von geringerer Bedeutung. Demonstrationsbeispiel Es wird eine Vorgehensweise dafür gezeigt, wie Aufgaben zu Informationsverarbeitungskomplexen geordnet werden können. Sie besteht aus den folgenden fünf Arbeitsschritten: • Erster Arbeitsschritt: Mit Hilfe des Organigramms werden die Struktureinheiten des Untersuchungsbereichs bestimmt; sie werden in die Zeilen einer Matrix "Struktureinheiten/Aufgaben" geschrieben. • Zweiter Arbeitsschritt: Mit Hilfe des Organigramms und der Stellenbeschreibungen werden für jede Struktureinheit alle Aufgaben bestimmt, die in den Struktureinheiten verrichtet werden; sie werden in die Spalten der Matrix "Struktureinheiten/Aufgaben" geschrieben. • Dritter Arbeitsschritt: Es wird eine Menge von Informationsverarbeitungskomplexen definiert, in einer ersten groben Gliederung etwa: Planung, Überwachung und Steuerung, Abrechnung und Analyse. • Vierter Arbeitsschritt: Es wird der erste der definierten Informationsverarbeitungskomplexe (im Beispiel "Planung") betrachtet, und es werden über alle Struktureinheiten die Aufgaben bestimmt und in der Matrix gekennzeichnet, die Planungsaufgaben sind (im Beispiel Absatzplanung, Materialbedarfsplanung, Kapazitätsterminierung usw.). • Fünfter Arbeitsschritt: Es wird der zweite bis n-te Informationsverarbeitungskomplex betrachtet, bis alle Aufgaben der Matrix auf Informationsverarbeitungskomplexe zugeordnet sind. Abbildung VFEIN-2 zeigt beispielhaft einen Ausschnitt aus der Matrix "Struktureinheiten/Aufgaben"; die dem Informationsverarbeitungskomplex "Planung" zuzurechnenden Aufgaben sind mit * gekennzeichnet. Die Istzustandserfassung für den Informationsverarbeitungskomplex "Planung" erfolgt in allen genannten Struktureinheiten. Beispielsweise werden in der Struktureinheit "Verkauf' die Absatzplanung, in der Struktureinheit "Lager" die Bedarfsplanung und in der Struktureinheit "Personal" die Arbeitskräfteplanung untersucht.

VFEIN - Vorgehensweise bei der Feinstudie

Struktureinheiten

Aufgiitx'n

Verkauf

Absatzplanung *

Vertriebssteuerung

Auftragsannahme

Lager

Bedarfsplanung *

Lagerdisposition

Materialausgabe

Produktion

KapazitätsInstandhaltungsterminierung * planung *

365

Leistungserfassung

Personal

Lohn und Gehalt

Arbeitskräfteplanung *

soziale Betreuung

Finanzen

Zahlungsverkehr

Kassenführung

Finanzplanung *

* Aufgaben für den Informationsverarbeitungskomplex "Planung" Abb. VFEIN-2: Bestimmen des Informationsverarbeitungskomplexes "Planung" Aufgaben verweise Erfassen des Istzustands (Lerneinheit ERIST); Analysieren des Istzustands (Lerneinheit ANIST). Kontrollfragen 1. Welche alternativen Vorgehensweisen bei der Feinstudie gibt es? 2. Worin besteht der Unterschied zwischen "Informationsverarbeitungskomplex" und "Teilsystem"? 3. Warum wird das Erkennen von Zusammenhängen zwischen den Aufgaben als wichtiges Teilziel der Feinstudie angesehen? 4. Welche der Vorgehensweisen bei der Feinstudie kann aus welchem Grund das Erkennen von Zusammenhängen zwischen den Aufgaben am besten sichern? 5. Wie sieht ein Informationsverarbeitungskomplex aus, der alle kurzfristigen Planungsaufgaben eines Industriebetriebs enthält?

ISTER - Methoden der Istzustandserfassung Lernziele Sie können einen Überblick über die Methoden der Istzustandserfassung geben. Sie können den Zweck jeder Methode nennen und ihre Konzeption erläutern. Sie können die Gemeinsamkeiten und Unterschiede der Methoden herausarbeiten und sind in der Lage, geeignete Methoden auszuwählen und anzuwenden. Definitionen und Abkürzungen aktive Beobachtung (active Observation) = eine Beobachtung, die während der Mitwirkung des Beobachters bei der Aufgabendurchführung erfolgt; im Gegensatz dazu: passive Beobachtung. Befragung (questioning) = ein zielgerichteter, sozialer Vorgang der Interaktion zwischen Individuen (Frager und Befragter) zur Erhebung von Daten in einem bestimmten Kontext; die zusammenfassende Bezeichnung für Interview ("mündliche Befragung") und Fragebogen ("schriftliche Befragung"). D a u e r b e o b a c h t u n g (continuous Observation) = eine Beobachtung, die über einen gewissen Zeitraum hinweg ununterbrochen durchgeführt wird; im Gegensatz dazu: unterbrochene Beobachtung, direkte Beobachtung (direct Observation) = eine Beobachtung, die durch den Beobachter persönlich und nicht durch ein Sachmittel erfolgt; im Gegensatz dazu: indirekte Beobachtung (z.B. Videobeobachtung), direkte Frage (direct question) = eine Frage, die den zu ermittelnden Sachverhalt unmittelbar anspricht; im Gegensatz dazu: indirekte Frage, harte Frage (hard question) = eine Frage, die in einen schnellen Fragenablauf eingebunden ist und deshalb zu spontanen Antworten zwingt; im Gegensatz dazu: weiche Frage. Istzustandserfassung (current system survey) = die Festlegung der Attribute, die Ermittlung der Attributewerte und die Ordnung und Dokumentation der Attribute und Attributewerte des Istzustands. Synonym: Istzustandserhebung. offene Beobachtung (open Observation) = eine Beobachtung, die für den Beobachteten erkennbar ist; im Gegensatz dazu: verdeckte Beobachtung, offene Frage (open question) = eine Frage, deren Antwortmöglichkeiten nicht vorgegeben sind; im Gegensatz dazu: geschlossene Frage. Synonym: nicht standardisierte Frage. Selbstaufschreibung (self-recording) = die Erstellung von Arbeitsberichten durch die Aufgabenträger, standardisierte Frage (standardized question) = eine Frage, deren Antwortmöglichkeiten vorgegeben sind; im Gegensatz dazu: nicht standardisierte Frage. Synonym: geschlossene Frage, strukturierte Beobachtung (structured Observation) = eine Beobachtung, die nach einem System festgelegter Beobachtungskriterien erfolgt; im Gegensatz dazu: unstrukturierte Beobachtung. Videobeobachtung (video Observation) = eine passive Beobachtung, welche die Videokamera (mit Mikrofon) als Sachmittel verwendet.

ISTER - Methoden der Istzustandserfassung

367

Zweck der Methoden der Istzustandserfassung Zweck der Methoden der Istzustandserfassung ist es, die Durchführung der Istzustandserfassung (vgl. Lerneinheit ERIST) zu unterstützen, insbesondere das Ermitteln der Attributewerte zu den definierten Attributen. Dem dualen Charakter der Feinstudie (vgl. Lerneinheit ZAMFS) entsprechend, müssen die Methoden der Istzustandserfassung in der Lage sein, sowohl die vorgegebene Arbeitssituation als auch die wahrgenommene Arbeitssituation zu ermitteln; deshalb ist die Befragung als Methode der Istzustandserfassung in der Regel unverzichtbar. Dem interaktiven Charakter der Feinstudie (vgl. Lerneinheit ZAMFS) entsprechend, sollen die Methoden der Istzustandserfassung auch in der Lage sein, möglichst interaktiv mit der Erfassung einzelner Phänomene auch die Analyse durchzuführen. Die in Abbildung ISTER-1 genannten Methoden stehen für die Istzustandserfassung zur Verfügung; innerhalb der genannten Methoden können graduell unterschiedliche Varianten unterschieden werden. Die genannten Methoden (einschließlich ihrer Varianten) sind kombinierbar; sie schließen sich nicht gegenseitig aus. Für die Erfassung des Teils des Istzustands, der den Zeitbedarf beschreibt, werden die Methoden der Zeiterfassung (vgl. Lerneinheit ZERFA) angewendet. Die Eigenschaften der Methoden, die konkrete Erfassungssituation in einem Projekt und die Präferenzen der am Projekt Beteiligten (z.B. auf Grund ihrer persönlichen Kenntnisse und Erfahrungen im Umgang mit den Methoden) bestimmen die Auswahl der Erfassungsmethoden für ein bestimmtes Projekt.

Abb. ISTER-1: Erfassungsmethoden

Jede Methode ist unter anderem dadurch ausgezeichnet, daß sie (nur) eine bestimmte Sicht auf die Wirklichkeit hat und damit (nur) einen Ausschnitt der Wirklichkeit erfassen kann. So kann z.B. ein Interview erfassen, wie Aufgabenträger ihre Arbeitssituation wahrnehmen, nicht aber, wie sie sich bei der Arbeit verhalten. Wie sich Aufgabenträger bei der Arbeit verhalten, kann dagegen gut durch Beobachtung ("Verhaltensbeobachtung") erhoben werden. Die Beobachtung trägt aber nicht dazu bei, Erkennmisse über die wahrgenommene Arbeitssituation zu gewinnen. Im folgenden werden die in Abbildung ISTER-1 genannten Methoden und einige ihrer Varianten erläutert. Daraus ergibt sich unter anderem, auf welche Sicht der Wirklichkeit sich die einzelnen Methoden konzentrieren.

368

Methoden und Techniken der Feinstudie

Interview Ein Interview ist die mündliche Befragung von Aufgabenträgern, die kompetente Auskunftspersonen zur Deckung des Informationsbedarfs (Attribute und Attribute werte, vgl. Lerneinheit ERIST) der Istzustandserfassung sind. Nach den folgenden Gesichtspunkten werden verschiedene Interviewformen gestaltet: • standardisierte, halb standardisierte oder nicht standardisierte Fragen; • harte oder weiche Fragen; • direkte oder indirekte Fragen. Welche Interviewform im Einzelfall gewählt wird, hängt insbesondere vom Untersuchungsbereich und von den zu befragenden Personen ab. Bezüglich des Standardisierungsgrads der Fragen, ist ein Interview anhand eines flexiblen Gesprächsleitfadens mit vornehmlich halb standardisierten Fragen am zweckmäßigsten. Nach der Anzahl der gleichzeitig befragten Aufgabenträger werden Einzelinterview und Gruppeninterview unterschieden. Eine Sonderform des Gruppeninterviews ist die Konferenz-Interview-Technik, bei der Aufgabenträger verschiedener hierarchischer Stufen, unter der Steuerung eines Moderators, gleichzeitig interviewt werden. Zur Anwendung des Interviews sind folgende Arbeitsschritte erforderlich: Vorbereiten, Durchführen und Auswerten des Interviews. • Erster Arbeitsschritt: Vorbereiten des Interviews * Fesüegen des Informationsbedarfs (vgl. Festlegen der Attribute und Attributewerte, Lerneinheit ERIST); * Auswählen der zur Deckung des Informationsbedarfs kompetenten Aufgabenträger; * Erstellen eines Interviewleitfadens; * Vereinbaren von Interviewort und Interviewtermin. • Zweiter Arbeitsschritt: Durchführen des Interviews * Einführungsphase: Versuchen, eine positive Interviewatmosphäre zu schaffen; * Befragungsphase: Ermitteln der Attributewerte; * Schlußphase: Versuchen, die Einstellung der Befragten zum Projekt in Erfahrung zu bringen. • Dritter Arbeitsschritt: Auswerten des Interviews * Vollständigkeitsprüfung: Prüfen der ermittelten Attributewerte nach Übereinstimmung mit dem Informationsbedarf; * Plausibilitätsprüfung: Prüfen der ermittelten Attribute werte auf Fehler; * Ergebnisprotokollierung: Dokumentieren der Interviewergebnisse. Folgende Prinzipien sollen beim Durchführen eines Interviews beachtet werden: • Offene Frageformulierungen unterstützen die Vollständigkeit der Beschreibung des Istzustands durch die Befragten. • Der Antwortfluß der Befragten soll nicht durch Zwischenfragen unterbrochen werden, auch wenn manche Aussagen zunächst unverständlich sind. • Suggestivfragen sind zu vermeiden.

ISTER - Methoden der Istzustandserfassung

369

• Die Aussagen der Befragten sollen vom Interviewer immer wieder zusammengefaßt werden, um Mißverständnissen vorzubeugen. Vorteile des Interviews sind die Möglichkeit zur Vertiefung der Befragung durch Zusatzfragen und Verständnisfragen sowie zur Motivation der Befragten. Im Interview können Erfassungs- und Analysetätigkeiten gut miteinander verbunden werden; Analyseerkenntnisse können sofort zu passenden Zusatzerhebungen verwendet werden. Diese Vorteile sind vor allem für das offene Interview zutreffend. Nachteile des Interviews sind der hohe Zeitaufwand, die hohen Anforderungen an die Qualifikation der Interviewer und die Störung der Befragten bei der Erfüllung ihrer Arbeitsaufgaben. Einsatzschwerpunkte, für die sich das Interview eignet, sind komplexe betriebliche Aufgaben und Arbeitsabläufe. Beobachtung Eine Beobachtung ist die Deckung des Informationsbedarfs durch sinnliche Wahrnehmungen der Beobachter im Untersuchungsbereich, ohne Beteiligung des beobachteten Aufgabenträgers. Nach den folgenden Kriterien werden verschiedene Beobachtungsformen unterschieden: • • • • •

offene oder verdeckte Beobachtung; strukturierte oder unstrukturierte Beobachtung; aktiv teilnehmende oder passive Beobachtung; Dauerbeobachtung oder unterbrochene Beobachtung; direkte oder indirekte Beobachtung.

Welche Beobachtungsform im Einzelfall gewählt wird, hängt insbesondere vom Untersuchungsbereich ab. Als zweckmäßig hat sich die Beobachtungsform erwiesen, die durch die Merkmale offen, strukturiert, passiv und unterbrochen gekennzeichnet ist. Alle diese Beobachtungsformen sind in der Regel direkte Beobachtungen. Werden für die Beobachtung Sachmittel eingesetzt (insbes. Videokamera und Mikrofon), ist die Beobachtung indirekt. Je nachdem, worauf das Analyseinteresse gerichtet ist, erfaßt die Beobachtung einen ganzen Arbeitsbereich, oder sie konzentriert sich auf eine bestimmte Person oder eine bestimmte Aufgabe bzw. einen bestimmten Arbeitsablauf. Beobachtungen müssen sorgfältig vorbereitet werden, um zuverlässig und objektiv zu sein. Eine Beobachtung ist zuverlässig, wenn der gleiche Beobachter zu ein- und demselben Ausschnitt der Wirklichkeit zu verschiedenen Beobachtungszeitpunkten (z.B. an zwei verschiedenen Tagen) übereinstimmende Daten liefert; sie ist objektiv, wenn verschiedene Beobachter zu ein- und demselben Ausschnitt der Wirklichkeit übereinstimmende Daten liefern. Diese Erklärungen machen deutlich, daß Zuverlässigkeit eher erreicht werden kann als Objektivität. Vorteil der Beobachtung ist, daß sie zum tatsächlichen Zeitpunkt bzw. im Zeitraum der Aufgabendurchführung erfolgt; sie ermöglicht den unmittelbaren und direkten Einblick des Beobachters in den Untersuchungsbereich. Der Vorteil der indirekten Beobachtung, insbesondere der Videobeobachtung, kommt bei der Analyse des Istzustands zum Tragen (vgl. Lerneinheit ANIST). Nachteile der Beobachtung sind der hohe Zeitaufwand (sowohl für die benötigte gründliche

370

Methoden und Techniken der Feinstudie

Vorbereitung als auch für die Durchführung), die psychische Belastung der Beobachteten (Beobachtungen können auch als Eingriff in die Privatsphäre aufgefaßt werden, was besonders auf die Videobeobachtung zutrifft) und die damit im Zusammenhang stehende Gefahr von Verhaltensänderungen der Beobachteten (Beobachter und Videokameras können allein durch ihre Anwesenheit verhaltensändernd wirken). Einsatzschwerpunkte, für die sich die Beobachtung eignet, sind die Erfassung der Arbeitsorganisation und der Arbeitsplatzgestaltung sowie die Ermittlung der Arbeitsbelastung. Die Eignung der Videobeobachtung wird besonders dort deutlich, wo der Untersuchungsbereich durch eine größere Anzahl von Personen, zwischen denen zahlreiche Interaktionen stattfinden, gekennzeichnet ist (also in stark arbeitsteiligen, kooperativen Arbeitssituationen). Fragebogen Ein Fragebogen ist eine geordnete Menge von Fragen, die von den Befragten schriftlich beantwortet werden soll; er ist das Arbeitsmittel für die schriftliche Befragung. Nach den folgenden Gesichtspunkten werden verschiedene Fragebogenformen gestaltet: • Individualfragebogen oder Gruppenfragebogen; • Fragebogen mit standardisierten, halb standardisierten oder nicht standardisierten Fragen. Ein Individualfragebogen wird von einzelnen Befragten und für einzelne Aufgabenträger beantwortet, während ein Gruppenfragebogen von einzelnen Befragten für eine Gruppe von Aufgabenträgern beantwortet wird. Für die Durchführung einer Fragebogenaktion sind im wesentlichen dieselben Arbeitsschritte erforderlich, wie sie für die Durchführung eines Interviews dargestellt wurden. Vorteile des Fragebogens sind die Verfügbarkeit von schriftlichen Ergebnissen, die Möglichkeit von statistischen Auswertungen und die vergleichsweise geringen Kosten. Nachteile des Fragebogens sind die meist geringe Rücklaufquote, die mangelnde Dialogmöglichkeit zwischen Systemplaner und Aufgabenträger und die aufwendige Auswertung der Antworten von nicht standardisierten Fragen. Einsatzschwerpunkte, für die sich der Fragebogen eignet, sind die Befragung einer Vielzahl von geographisch dezentralisierten Aufgabenträgern und ein einfacher, gleichförmiger Informationsbedarf. Selbstaufschreibung Selbstaufschreibung ist die Dokumentation von Information zur Deckung des Informationsbedarfs der Istzustandserfassung durch die Aufgabenträger selbst und ohne direkte Mitwirkung Dritter. Zur Anwendung der Selbstaufschreibung sind folgende Arbeitsschritte erforderlich: • • • •

Festlegen des Informationsbedarfs; Vorbereiten der Erfassung durch Gestalten der Erfassungsformulare; Schulen der Aufgabenträger; Durchführen der Selbstaufschreibung durch die Aufgabenträger;

ISTER - Methoden der Istzustandserfassung

371

• Auswerten der erfaßten Informationen. Vorteile der Selbstaufschreibung sind die Möglichkeit der Totalaufnahme und die Entlastung des Systemplaners. Nachteile der Selbstaufschreibung sind die Möglichkeit der bewußten Verfälschung und personelle Widerstände. Einsatzschwerpunkte sind die Feststellung von Aufgabenprofilen, die Ermittlung der Arbeitsbelastung und die Ermittlung des Zeitbedarfs (vgl. Lerneinheit ZERFA). Dokumenteauswertung Dokumenteauswertung ist die Deckung des Informationsbedarfs der Istzustandserfassung durch systematische Einsichtnahme in vorhandene Aufzeichnungen über den Untersuchungsbereich. Vorteile der Dokumenteauswertung sind der geringe Erfassungsaufwand, das Reduzieren der Erfassungsdokumentation und die NichtStörung der Aufgabenträger. Ein Nachteil der Dokumenteauswertung ist die notwendige inhaltliche Konsistenzprüfung auf Übereinstimmung der dokumentierten Daten mit der Realität zum Erfassungszeitpunkt. Einsatzschwerpunkt ist die Vorinformation über den Istzustand. Aufgabenanalyse Häufig sind den Systemplanern die betrieblichen Aufgaben und Arbeitsabläufe, welche das IuK-System im Istzustand umfaßt, im Detail unbekannt. Sie können dann die für die Istzustandserfassung erforderlichen Attribute nicht mit der notwendigen Breite und Tiefe aus eigener Kenntnis festlegen. In diesem Fall ist es notwendig, die Aufgabe mit einer Aufgabenanalyse "aufzubrechen", das heißt hierarchisch, von der Gesamtaufgabe ausgehend, über Hauptaufgaben und Teilaufgaben bis zu den Verrichtungen (Tätigkeiten) hinunter zu zerlegen. Die Gliederungsmerkmale für die Aufgabenanalyse zeigt Abbildung ISTER-2; sie sind überschneidungsfrei. Das bedeutet, daß durch Zerlegung nach einem Gliederungsmerkmal die anderen Gliederungsmerkmale nicht berührt werden.

Abb. ISTER-2: Gliedeningsmerkmale für die Aufgabenanalyse

Die Aufgabenanalyse nach der Verrichtung gliedert die Aufgaben nach Tätigkeitsarten. Die Aufgabenanalyse nach dem Objekt gliedert die Aufgaben nach der Art des Objekts, an dem die Verrichtung vorgenommen wird. Objekte können materiell oder immateriell sein. Die Aufgabenanalyse nach dem Rang glie-

372

Methoden und Techniken der Feinstudie

dert die Aufgaben in Entscheidungsaufgaben und in Ausführungsaufgaben. Die Aufgabenanalyse nach der Phase gliedert die Aufgaben in Planungsaufgaben, Durchführungsaufgaben und Kontrollaufgaben. Die Aufgabenanalyse nach dem Sachcharakter gliedert die Aufgaben nach den betrieblichen Funktionen. Demonstrationsbeispiel Es wird die Bedeutung der Aufgabenanalyse für das Festlegen von Attributen für die Istzustandserfassung gezeigt. In den Abbildungen ISTER-3 bis ISTER-8 wird die Teilaufgabe "Brief schreiben" nach den Gliederungsmerkmalen von Abbildung ISTER-2 vereinfacht dargestellt ("vereinfacht", weil nur ein Teil der Objekte und Verrichtungen berücksichtigt ist). Als Sachmittel wird ein PC mit einem Arbeitsplatzdrucker und einem Textverarbeitungsprogramm unterstellt.

Abb. ISTER-3: Gliederungsmerkmal "Verrichtung" für die Aufgabe "Brief schreiben"

Abb. ISTER-4: Gliederungsmerkmal "materielles Objekt" für die Aufgabe "Brief schreiben"

Abb. ISTER-5: Gliederungsmerkmal "immaterielles Objekt" für die Aufgabe "Brief schreiben"

Abb. ISTER-6: Gliederungsmerkmal "Rang" für die Aufgabe "Brief schreiben"

ISTER - Methoden der Istzustandserfassung

373

Abb. ISTER-7: Gliederungsmerkmal "Phase" fur die Aufgabe "Brief schreiben"

Abb. ISTER-8: Gliederungsmerkmal "Sachcharakter" für die Aufgabe "Brief schreiben" Aufgabenverweise Erfassen des Istzustands (Lerneinheit ERIST). Kontrollfragen 1. 2. 3. 4. 5.

Mit welchen Methoden kann die Istzustandserfassung unterstützt werden? Wie gehen Sie vor, wenn Sie das Interview als Erfassungsmethode anwenden? Wie gehen Sie vor, wenn Sie die Beobachtung als Erfassungsmethode anwenden? Welche Vorteile und welche Nachteile hat die Dokumenteauswertung als Erfassungsmethode? Was leistet die Aufgabenanalyse zur Unterstützung der Istzustandserfassung?

Quellenliteratur Atteslander, P. und Kopp, M.: Befragung. In: Roth, M. (Hrsg.): Sozialwissenschaftliche Methoden. 2. A., Oldenbourg Verlag, München/Wien 1987,144 - 172 Huber, O.: Beobachtung. In: Roth, M. (Hrsg.): Sozialwissenschaftliche Methoden. 2. A., Oldenbourg Verlag, München/Wien 1987,124 - 143 Vertiefungsliteratur Schmidt, G.: Methode und Techniken der Organisation. 8. A., Verlag Schmidt, Gießen 1989 Wittlage, H.: Methoden und Techniken praktischer Organisationsarbeit. 2. A., Verlag Neue Wirtschafts-Briefe, Herne/Berlin 1986

ZERFA - Methoden der Zeiterfassung Lernziele Sie kennen Methoden der Zeiterfassung und können diese anhand wichtiger Merkmale beschreiben. Davon ausgehend sind Sie in der Lage abzuschätzen, welche dieser Methoden im Einzelfall zweckmäßigerweise einzusetzen ist. Sie können mit den einfachen Methoden der Zeiterfassung (Arbeitstagebücher und Tätigkeitsberichte) selbständig arbeiten. Definitionen und Abkürzungen Genauigkeit (accuracy) = die Übereinstimmung der Ergebnisse einer Datenerhebung mit der Wirklichkeit, die in diesen Daten abgebildet werden soll. Häufigkeit (frequency) = die Anzahl der Fälle, in denen ein bestimmtes Merkmal beobachtet wurde; man unterscheidet absolute Häufigkeit und relative Häufigkeit. Maßstabtätigkeit (Standard work element) = eine Tätigkeit, die beim Schätzen des Zeitbedarfs von Tätigkeiten als Orientierungsgröße verwendet wird. Meßpunkt (measuring point) = der Ort an einem Meßobjekt, an dem eine Meßgröße erfaßt werden kann. Messen (measuring) = das Zuordnen von Zahlen zu Objekten oder Ereignissen nach einem festgelegten Verfahren (einer "Regel"). MMH = Abkürzung für Multimoment-Häufigkeits-Zählverfahren. MMZ = Abkürzung für Multimoment-Zeitmeßverfahren. Selbstaufschreibung (self-recording) = eine Methode der Datenerhebung, bei der die Personen für die Datenerhebung und für die Durchführung der Aufgabe, über die erhoben wird, identisch sind. Stichprobe (sample) = der Teil einer Grundgesamtheit, der nach einem bestimmten Auswahlverfahren festgelegt wird, meist nach dem der Zufälligkeit. System vorbestimmter Zeiten (time motion measurement) = eine Methode der Zeiterfassung, die aus Katalogen von Bewegungselementen mit den für die Durchführung dieser Bewegungen notwendigen Zeiten und einem Regelwerk für ihre Anwendung besteht. Tätigkeit (work element) = die aus einer zweckmäßigen Gliederung einer Aufgabe resultierende Teilaufgabe, die bei einem gegebenen Untersuchungszweck nicht weiter zerlegt werden soll. Tätigkeitskatalog (list of work elements) = eine Liste aller Tätigkeiten, die zur Durchführung der Aufgaben an einem Arbeitsplatz erforderlich sind; wesentliche Voraussetzung für die Anwendung der Methoden der Zeiterfassung. Zeitbedarf (time need) = der Zeitraum zwischen dem Beginn der Durchführung der ersten Tätigkeit einer Aufgabe und dem Abschluß der Durchführung der letzten Tätigkeit dieser Aufgabe. Zeitmessung (time measurement) = eine Methode der Zeiterfassung, bei der die Zeitdauer für die Durchführung der Tätigkeiten direkt und kontinuierlich mit Hilfe von Meßgeräten ermittelt wird.

ZERFA - Methoden der Zeiterfassung

375

Zweck der Methoden der Zeiterfassung Zweck der Methoden der Zeiterfassung ist es, in der Istzustandserfassung (vgl. Lerneinheit ERIST) die Ermittlung des Zeitbedarfs für die Durchführung der betrieblichen Aufgaben, die Objekte der Systemplanung und damit der Istzustandserfassung sind, zu unterstützen. Da im allgemeinen der Zeitbedarf nicht unmittelbar für die Aufgabe als Ganzes ermittelt werden kann, ist ihre Zerlegung in Teilaufgaben, in der Regel in Tätigkeiten, erforderlich. Die meisten Methoden der Zeiterfassung benötigen daher zu ihrer Anwendung einen Tätigkeitskatalog. Informationen über den Zeitbedarf der Aufgaben ermöglichen in der Istzustandsanalyse die Herausarbeitung von Stärken und Schwächen des Istzustands in bezug auf die zeitliche Dimension der Aufgabendurchführung. Mit diesen Informationen kann auch eine Konkretisierung der Wirtschaftlichkeitsanalyse erfolgen, wenn die Reduzierung des Zeitbedarfs für eine Aufgabe ein Planungsziel ist (vgl. Lerneinheiten FORMZ und WIRTA). Für die Erfassung des Zeitbedarfs gibt es verschiedene Methoden, im wesentlichen die folgenden: • die Selbstaufschreibung auf der Grundlage eines Tätigkeitskatalogs ("Zeiterfassung mit Arbeitstagebüchern"); • das Schätzen auf der Grundlage eines Tätigkeitskatalogs ("Zeiterfassung mit Tätigkeitsberichten"); • das Zählen (Multimoment-Häufigkeits-Zeitverfahren und MultimomentZeitmeßverfahren); • das automatische Ermitteln durch Zeitmeßgeräte, die in Arbeitsmittel eingebaut sind; • das Berechnen auf der Grundlage von technologischen Daten (z.B. Systeme vorbestimmter Zeiten); • das Messen durch Zeitnehmer mit Zeitmeßgeräten (Zeitmessung); • das Befragen der Aufgabenträger (Fragebogen und Interview). Die drei zuerst genannten Methoden werden im folgenden dargestellt; es werden Informationen vermittelt, die zur Abschätzung der Zweckmäßigkeit dieser Methoden herangezogen werden können. Die zuletzt genannte Methode wurde bereits an anderer Stelle behandelt (vgl. Lerneinheit ISTER). Auf Zeitmeßgeräte und Systeme vorbestimmter Zeiten wird nicht eingegangen. Zeiterfassung mit Arbeitstagebüchern Arbeitstagebücher sind auf Formularsätzen geordnete Aufzeichnungen der für die Durchführung einer Aufgabe erforderlichen Tätigkeiten, mit Angabe der Beginn-Uhrzeit und der Ende-Uhrzeit jeder Tätigkeit. Die Aufschreibung erfolgt durch die Aufgabenträger, welche die Aufgaben durchführen, also durch Selbstaufschreibung. Um eine ausreichende Genauigkeit der Zeiterfassung zu erreichen, müssen die Arbeitstagebücher über einen längeren Zeitraum hinweg geführt werden. Die Länge des Zeitraums ist in erster Linie von der Anzahl der an einem Arbeitsplatz zu verrichtenden Tätigkeiten abhängig; je mehr Tätigkeiten verrichtet werden, desto länger muß der Zeitraum sein, vice versa. Beim Auswerten der Arbeitstagebücher wird die Tätigkeitsdauer je Tätigkeit ermittelt und

376

Methoden und Techniken der Feinstudie

über die verwendete Benummerung der Tätigkeiten den untersuchten Aufgaben zum Ermitteln des Zeitbedarfs zugeordnet. Abbildung ZERFA-1 zeigt die Struktur des Arbeitstagebuchs. Tätigkeiten * Nummer/Bezeichnung

Beginn-Uhrzeit

Ende-Uhrzeit

Tätigkeitsdauer

* nach Tätigkeitskatalog Abb. ZERFA-1: Struktur Arbeitstagebuch

Vorteile der Zeiterfassung mit Arbeitstagebüchern sind: Der Aufwand ist relativ gering (verglichen mit der Zeitmessung etwa 10%). Durch die Selbstaufschreibung werden die Projektmitarbeiter von Projektaufgaben entlastet. Die Benutzerbeteiligung bei der Istzustandserfassung wird verstärkt, woraus eine gute Akzeptanz der Ergebnisse durch die Aufgabenträger folgt. Entscheidender Nachteil der Zeiterfassung mit Arbeitstagebüchem ist, daß über die Genauigkeit der Erfassung keine Vorhersagen gemacht werden können, diese aber vergleichsweise eher als gering einzuschätzen ist. Dies trifft umso mehr zu, je weniger kooperativ die Aufgabenträger sind, vice versa. Zeiterfassung mit Tätigkeitsberichten Tätigkeitsberichte sind auf Formularsätzen geordnete Aufzeichnungen der für die Durchführung einer Aufgabe erforderlichen Tätigkeiten, mit Angabe des geschätzten Zeitbedarfs, auf der Grundlage von Erfahrungen je Verrichtung jeder Tätigkeit und der Häufigkeit der Verrichtung jeder Tätigkeit. Tätigkeitsberichte werden gemeinsam von Projektmitarbeitern und den Aufgabenträgern, welche die Aufgabe durchführen, erstellt. Abbildung ZERFA-2 zeigt die Struktur des Tätigkeitsberichts. Der Arbeitsablauf bei der Zeiterfassung mit Tätigkeitsberichten kann wie folgt beschrieben werden: • Man kennt die Tätigkeiten der Aufgabe aus dem Tätigkeitskatalog und überträgt sie in den Tätigkeitsbericht. • Man bestimmt eine Tätigkeit als Maßstabtätigkeit, läßt den Zeitbedarf je Verrichtung der Maßstabtätigkeit sowie die Häufigkeit der Verrichtungen im betrachteten Zeitabschnitt (z.B. Monat) durch den Aufgabenträger schätzen und ermittelt daraus die Tätigkeitsdauer. • Man nimmt eine zweite Tätigkeit, läßt den Zeitbedarf usw. schätzen und stimmt die ermittelte Tätigkeitsdauer mit der Tätigkeitsdauer der Maßstabtätigkeit ab (man prüft also, ob die beiden Tätigkeitsdauern im Vergleich plausibel sind); die Schätzungen zur Maßstabtätigkeit und/oder zur gerade betrachteten Tätigkeit werden gegebenenfalls korrigiert. • Man nimmt dann die nächste Tätigkeit usw., bis für alle Tätigkeiten der Zeitbedarf geschätzt ist, und ermittelt daraus den Zeitbedarf für alle Tätigkeiten.

ZERFA - Methoden der Zeiterfassung

377

• Man stimmt den Zeitbedarf für alle Tätigkeiten mit der verfügbaren Arbeitszeit ab, die für die betrachtete Aufgabe an dem untersuchten Arbeitsplatz im angenommenen Zeitabschnitt insgesamt zur Verfügung steht. Bei Abweichungen geht man wieder auf die Maßstabtätigkeit zurück und durchläuft die Arbeitsschritte sooft, bis das Gesamtergebnis plausibel ist. Tätigkeiten * Nummer/Bezeichnung

X '

Zeitaufwand je Verrichtung

Häufigkeit der Verrichtung

Tätigkeitsdauer

* nach Tätigkeitskatalog Abb. ZERFA-2: Struktur Tätigkeitsbericht

Vorteile der Zeiterfassung mit Tätigkeitsberichten sind: Der Aufwand ist relativ gering (verglichen mit der Zeitmessung etwa 30%). Die Genauigkeit ist im allgemeinen ausreichend groß (die Abweichung von der mittleren Genauigkeit der Zeitmessung liegt im günstigsten Fall bei +/- 20%). Der Zeitraum für die Durchführung der Zeiterfassung ist relativ kurz (einige Stunden). Nachteile der Zeiterfassung mit Tätigkeitsberichten sind: Die Entlastung der Projektmitarbeiter ist im Vergleich zur Zeiterfassung mit Arbeitstagebüchern gering. Die Akzeptanz der Ergebnisse durch die Aufgabenträger ist nicht sehr hoch. Bei unkorrekter Durchführung der Zeiterfassung (z.B. wegen eines unvollständigen Tätigkeitskatalogs) wird keine ausreichende Genauigkeit erreicht (die Abweichung von der mittleren Genauigkeit der Zeitmessung liegt im ungünstigsten Fall bei +/- 100%). Zeiterfassung mit Multimomentstudien Die Multimomentstudie ist ein Stichprobenverfahren, das Aussagen über die prozentuale Häufigkeit bzw. über die Zeitdauer von vorwiegend unregelmäßig auftretenden Tätigkeiten liefert, und zwar bei frei wählbarer Genauigkeit und einer statistischen Sicherheit von 95%. Es gibt zwei Methodenformen: das Mult i m o m e n t - H ä u f i g k e i t s - Z ä h l v e r f a h r e n (MMH) und das M u l t i m o m e n t Zeitmeßverfahren (MMZ). Beiden gemeinsam ist die Art der Datenerhebung, nämlich bei Rundgängen zu unregelmäßigen Zeitpunkten zu beobachten und zu notieren. Während das MMH durch ein Zählen von Tätigkeiten an zufällig bestimmten Zeitpunkten Auskunft über die absolute und die relative Häufigkeit der Tätigkeiten gibt, werden mit dem M M Z durch ein zufallsbestimmtes Fixieren von Meßpunkten entsprechende Zeitdauern in Minuten oder Stunden ermittelt. Die Genauigkeit beider Methoden ist statistisch gesichert. Vorteile der Zeiterfassung mit Multimomentstudien sind: Die statistische Sicherheit der Ergebnisse, die frei gewählt werden kann (üblicherweise wird eine Sicherheit von 95% verwendet), womit auch der Beobachtungsumfang und damit eine wesentliche Einflußgröße auf den Aufwand bestimmt werden kann. Ver-

378

Methoden und Techniken der Feinstudie

glichen mit der Zeitmessung wird der durchschnittliche Aufwand für eine MMH mit 30% und für eine MMZ mit 35% angegeben, während die Abweichung von der mittleren Genauigkeit der Zeitmessung +/-10% beträgt. Nachteile der Zeiterfassung mit Multimomentstudien sind: Die personellen Voraussetzungen bei der Aufnahmegruppe in qualitativer und quantitativer Hinsicht sind relativ hoch (z.B. die erforderliche Personalschulung). Die notwendigen Vorarbeiten sind umfangreich. Die Datenauswertung ist zumindest dann aufwendig, wenn kein geeignetes Werkzeug zur Verfügung steht. Bei einer geforderten hohen Ergebnisgenauigkeit ist die Zeitdauer der Durchführung einer Multimomentstudie vergleichsweise lang. Demonstrationsbeispiel Es wird das Prinzip einer Multimomentstudie durch Gegenüberstellung einer üblichen Zeitmessung mit einer MMH anhand eines Zeitbalkenmodells erläutert. An zehn Arbeitsplätzen A bis K werden während eines achtstündigen Arbeitstags von 8 bis 12 und von 13 bis 17 Uhr (dargestellt durch je einen waagerechten Zeitbalken) vergleichbare, aber völlig unregelmäßig anfallende Tätigkeiten nj, x\2 und n3 mit den entsprechenden Zeitarten ti (z.B. Hauptzeit), t2 (z.B. Nebenzeit) und t3 (z.B. Verteilzeit) durchgeführt (vgl. Abbildung ZERFA-3). Beginn der Rundgänge

Arbeitszeit

Zeitmessung (in %)

08 h

Z-3 Abb. ZERFA-3: Zeitbalken-Modell einer MMH-Aufnahme (Quelle: Haller-Wedel)

Die durch Zeitmessung, z.B. mit Hilfe einer Stoppuhr, ermittelten prozentualen Anteile der drei Zeitarten an der Schichtzeit T für jeden einzelnen Arbeitsplatz und der Durchschnitt der prozentualen Anteile der drei Zeitarten an der Schicht-

ZERFA - Methoden der Zeiterfassung

379

zeit T für die gesamte Abteilung sind in Abbildung ZERFA-3 rechts ausgewiesen ti = p! = 60%, t2 = P2 = 30% und t3 = p3 = 10%. Besonderes Interesse verdienen die Maxima und Minima (eingekreist), die erhebliche Unterschiede zeigen. Daraus ist zu erkennen, wie ungenau die Zeitmessung gewesen wäre, wenn sie nur bei einem der zehn Arbeitsplätze durchgeführt worden wäre. Im Vergleich zur Zeitmessung besteht das Prinzip des MMH im Zählen der Zeitarten bei Rundgängen zu unregelmäßigen Zeitpunkten. Bei je fünf Rundgängen vormittags und nachmittags - in Abbildung ZERFA-3 durch schräge Linien dargestellt - wird die augenblicklich durchgeführte Art der Tätigkeit an jedem Arbeitsplatz - im Schnittpunkt mit dem Zeitbalken - festgestellt und notiert. Der Beginn der Rundgänge wird zufällig verteilt gewählt. Die Auswertung zeigt bei 100 Beobachtungen (10 Rundgänge an 10 Arbeitsplätzen) - die für eine hinreichend genaue Feststellung nicht genügen - bereits Ergebnisse, die - verglichen mit den Ergebnissen der Zeitmessung - einen erstaunlich geringen Unterschied aufweisen. Die Zeitart ti für Tätigkeit n j wurde beispielsweise vormittags 31 mal und nachmittags 28mal angetroffen, das heißt 59mal von 100 Beobachtungen oder 59%. Man sagt, der Ergebnisanteil (oder die mittlere Wahrscheinlichkeit) der Zeitart ti ist pi = 59%. Die mittlere Wahrscheinlichkeit der Zeitart tz ist P2 = 30%, die der Zeitart t3 ist p3 = 11%. Aufgabenverweise Erfassen des Istzustands (Lerneinheit ERIST). Kontrollfragen 1. 2. 3. 4. 5.

Was ist ein "Tätigkeitskatalog"; für welche Methoden der Zeiterfassung ist er erforderlich? Welche Struktur hat ein Arbeitstagebuch? Mit welchen Arbeitsschritten wird bei der Zeiterfassung mit Tätigkeitsberichten vorgegangen? Worin besteht der Unterschied zwischen MMH und MMZ? Welche Genauigkeit kann mit einer MMH im Vergleich zu einer Zeitmessung mit der Stoppuhr erreicht werden?

Quellenliteratur Haller-Wedel, E.: Das Multimomentverfahren in Theorie und Praxis. Hanser Verlag, München 1969 Wittlage, H.: Methoden und Techniken praktischer Organisationsarbeit. Verlag Neue WirtschaftsBriefe, Herne/Berlin 1980, 85 - 9 1

ISTAN - Methoden der Istzustandsanalyse Lernziele Sie können einen Überblick über die Methoden der Istzustandsanalyse geben. Sie können den Zweck jeder Methode nennen und ihre Konzeption erläutern. Sie können die Gemeinsamkeiten und Unterschiede der Methoden herausarbeiten. Sie sind in der Lage, für eine konkrete Analysesituation den Anforderungen der Analysesituation und Ihren persönlichen Präferenzen entsprechende Methoden auszuwählen und anzuwenden. Definitionen und Abkürzungen Abweichung (deviation) = der Unterschied zwischen dem Wert eines Attributs im Istzustand und dem Wert desselben Attributs im Sollzustand, der bei der Istzustandsanalyse festgestellt wird. A n a l y s e m e t h o d e (analysis technique) = eine Methode, mit der ein Ganzes durch Zerlegen in Teile und durch Untersuchen dieser Teile beurteilt wird. Beziehung (relationship) = die gegenseitige Abhängigkeit zwischen zwei oder mehreren Größen. Clusteranalyse (cluster analysis) = eine Methode zur Auffindung von Teilmengen aus einer Menge von Untersuchungsobjekten, deren Elemente homogene Entstehungsbedingungen haben, die sich von denen anderer Teilmengen unterscheiden. Kooperation (Cooperation) = ein sozialer Prozeß zwischen mehreren Aufgabenträgern zur Erreichung gemeinsamer Ziele. Korrelation (correlation) = die mit Methoden der mathematischen Statistik darstellbaren Zusammenhänge zwischen zwei oder mehreren Zufallsgrößen. Metaplan-Technik (metaplan technique) = eine Form der Kreativitätstechnik, bei der in Gruppendiskussionen zu einem definierten Problem Ideen zum Problemlösen erzeugt werden. Koordination (coordination) = die Abstimmung der Tätigkeiten verschiedener Aufgabenträger, die kooperativ zusammenarbeiten. P r ü f e n (checking) = das Vergleichen und Beurteilen von Attributewerten des Istzustands mit Attributewerten einer Sollvorstellung. Synonym: Verifizieren. Prüffrage (check question) = eine in Frageform formulierte Symptom/UrsacheBeziehung für eine Stärke oder Schwäche; Teil einer Prüfliste. Schwächesymptom (weakness Symptom) = ein Symptom, das auf eine Schwäche des Istzustands hinweist. S t ä r k e s y m p t o m (strength Symptom) = ein Symptom, das auf eine Stärke des Istzustands hinweist. S y m p t o m (symptom) = ein wahrnehmbares, objektiv feststellbares Zeichen der Abweichung eines Systems von einem Sollzustand. S y m p t o m / U r s a c h e - B e z i e h u n g (symptom/cause relationship) = der wechselseitige Zusammenhang zwischen Symptom und Ursache. U r s a c h e (cause) = die Voraussetzung, die Bedingung oder das Motiv für die Entstehung oder Veränderung einer Ordnung.

ISTAN - Methoden der Istzustandsanalyse

381

Zweck der Methoden der Istzustandsanalyse Zweck der Methoden der Istzustandsanalyse ist es, die Durchführung der Istzustandsanalyse (vgl. Lerneinheit A N I S T ) zu unterstützen, insbesondere das Erkennen der S t ä r k e n und Schwächen des Istzustands zu erleichtern. Die Leistungsfähigkeit der Methoden der Istzustandsanalyse ist allerdings gering; sie unterstützen im wesentlichen nur die Ordnung und Systematisierung der den Istzustand beschreibenden Attribute und Attributewerte; Schlüsse auf Stärken und Schwächen können letztlich nur von den Personen gezogen werden, welche die Istzustandsanalyse durchführen. Die in Abbildung ISTAN-1 genannten Methoden stehen für die Istzustandsanalyse zur Verfügung; innerhalb der genannten Methoden können graduell unterschiedliche Varianten unterschieden werden. Die genannten Methoden (einschließlich ihrer Varianten) sind kombinierbar; sie schließen sich nicht gegenseitig aus. Für die Analyse des Teils des Istzustands, der die Kommunikationsbeziehungen beschreibt, werden die Methoden der Kommunikationsanalyse (vgl. Lerneinheit K O M A N ) angewendet. Die Eigenschaften der Methoden, die konkrete Analysesituation in einem Projekt und die Präferenzen der am Projekt Beteiligten (z.B. auf Grund ihrer persönlichen Kenntnisse und Erfahrungen im Umgang mit den Methoden) bestimmen die Auswahl der Analysemethoden für ein bestimmtes Projekt. Analysemethoden

Prüfliste

Prüfmatrix

ABC-Analyse

Interaktionsanalyse

Wirtschaftlichkeitsanalyse

Matrix analyse

Abb. ISTAN-1: Analysemethoden

Von den in Abbildung ISTAN-1 genannten Methoden werden im folgenden Prüfliste, Prüfmatrix, ABC-Analyse und Interaktionsanalyse erläutert; wegen der anderen Methoden wird auf die Lerneinheiten W I R T A - Wirtschaftlichkeitsanalyse und M A T R X - Matrixanalyse verwiesen. Prüfliste Zweck der Prüfliste ist es, das Erkennen von Symptomen (Stärken und Schwächen) des Istzustands zu unterstützen und Hinweise auf die Ursachen der Symptome zu geben. Eine Prüfliste muß also Vorstellungen über die gewünschten Systemeigenschaften (d.h. über den Sollzustand) enthalten. Die Vorstellungen über den Sollzustand sind meist aus der Erfahrung der Personen gewonnen, welche die Prüfliste formuliert haben, sofern ihre theoriegeleitete Formulierung nicht möglich ist. Wegen nicht vorhandener theoretischer Grundlagen ist die theoriegeleitete Formulierung nur selten möglich. B e i der Anwendung einer Prüfliste werden die durch die Istzustandserfassung (vgl. Lerneinheit I S T E R ) erhobenen Attributewerte mit den Prüffragen "durchgeprüft". Trifft eine Prüffrage zu bzw. nicht zu (je nach Formulierung), dann wird angenommen, daß das in der Prüffrage enthaltene Symptom und die zuge-

382

Methoden und Techniken der Feinstudie

ordnete Ursache identifiziert sind. Diese Vorgehensweise zeigt, daß es auch möglich ist, P r ü f f r a g e n aus der Kenntnis typischer (im Sinn von erfahrungsgemäß häufig vorkommenden) Schwachstellen zu formulieren. Es wird zwischen allgemein verwendbaren Prüflisten und Prüflisten für bestimmte Untersuchungsbereiche unterschieden. A l l g e m e i n v e r w e n d b a r e Prüfliste: Eine Prüfliste ist allgemein verwendbar, wenn sie v o m Untersuchungsbereich unabhängig ist. Dies kann nur dann der Fall sein, wenn sich die Prüffragen auf Symptom/Ursache-Beziehungen beschränken, die erfahrungsgemäß in allen Untersuchungsbereichen auftreten und daher bei jeder Istzustandsanalyse von Bedeutung sind. Prüffragen, auf die dies zutrifft, können sich nur auf sehr allgemeine Symptome und Ursachen beziehen. Beispiele für Schwäche-Symptome, auf die dies zutrifft, sind: • • • • • •

mehrfache Erfassung von Daten; häufige Arbeitsrückstände; fehlende Informationen; verspätete Informationsweitergabe; schlechtes Betriebsklima; mangelhafte Koordination.

Wie die Beispiele zeigen, können mit einer allgemein verwendbaren Prüfliste keine Symptome und deren Ursachen erkannt werden, die für einen bestimmten Untersuchungsbereich typisch sind. Das Demonstrationsbeispiel gibt Auszüge aus einer allgemein verwendbaren Prüfliste. U n t e r s u c h u n g s b e r e i c h s p e z i f i s c h e P r ü f l i s t e : Eine Prüfliste ist f ü r einen spezifischen Untersuchungsbereich bestimmt, wenn sie Prüffragen enthält, die f ü r einen Untersuchungsbereich typisch sind. Mit ihrer Hilfe können die für diesen Untersuchungsbereich typischen Symptome und deren Ursachen erkannt werden. Eine relativ globale Gliederung der Untersuchungsbereiche kann nach den K o m p o n e n t e n Datensystem, Methodensystem, Arbeitsorganisation, Transportsystem ("Kommunikationssystem") und Sicherungssystem erfolgen. Eine spezielle Gliederung der Untersuchungsbereiche kann nach den untersuchten betrieblichen A u f g a b e n oder Arbeitsabläufen erfolgen (z.B. Auftragsbearbeitung, Lagerverwaltung, Kundenbedienung, Produktionsplanung und -Steuerung). Beide Sichtweisen können kombiniert werden (z.B. Datensystem für den Prozeß der Auftragsbearbeitung als Untersuchungsbereich). Prüflisten k ö n n e n entweder von den an einem Projekt Beteiligten selbst entwickelt werden ("Eigenentwicklung"), oder man kann auf allgemein verfügbare (z.B. in der Fachliteratur veröffentlichte) Prüflisten zurückgreifen ("Fremdbezug"). Bei der E i g e n e n t w i c k l u n g von Prüflisten wird von der Frage "Welches sind erfahrungsgemäß die Stärken und Schwächen des Untersuchungsbereichs und welches sind ihre Ursachen?" ausgegangen; daraus werden die Prüffragen abgeleitet. Das Fragesystem sollte hierarchisch gegliedert werden (vgl. Lerneinheit SYSTE). Die Fragen sollten so formuliert werden, daß sie mit Hilfe der erfaßten Attributewerte des Istzustands beantwortet werden können. Der Detaillierungsgrad der Fragen sollte zumindest so sein, daß sie mit nominalen Wertu r t e i l e n (z.B. ja/nein oder trifft zu/trifft manchmal zu/trifft nicht zu) beant-

ISTAN - Methoden

der lstzustandsanalyse

383

wortet werden können. Es ist zweckmäßig, die Fragen so zu formulieren, daß eine positive Beantwortung ("ja" oder "trifft zu") eine Stärke, eine negative Beantwortung ("nein" oder "trifft nicht zu") eine Schwäche anzeigt. Bei Fremdbezug müssen die Prüflisten in aller Regel an die situativen Bedingungen des Untersuchungsbereichs im Projekt angepaßt werden. Prüfmatrix Zweck der Prüfmatrix ist es, die Beziehungen zwischen den Symptomen (Stärken und Schwächen) und ihren Ursachen (Symptom/Ursache-Beziehung) klarer herauszuarbeiten, als das mit der Prüfliste möglich ist. Dies wird durch den vergleichsweise stärker systematisierten Aufbau der Prüfmatrix erreicht. Die Prüfmatrix ist daher keine Alternative zur Prüfliste, sondern eine Ergänzung der Prüfliste. Die Prüfmatrix ist eine Matrix P (S,U), in deren Zeilen (oder Spalten) die Symptome S und in deren Spalten (oder Zeilen) die Ursachen U der Symptome eingetragen werden. Das Element pjj von P ist 1, wenn zwischen dem Symptom Sj und der Ursache Uj eine Beziehung derart besteht, daß Sj durch Uj verursacht wird; sonst ist py = 0. Abbildung ISTAN-2 zeigt die Struktur der Prüfmatrix. ' Ursachen Symptome^

U|

Uj

Un

Si

Si

Pü

Sm Abb. ISTAN-2: Struktur der Prüfmatrix

Die Tatsache, daß eine S y m p t o m / U r s a c h e - B e z i e h u n g vorliegt, muß für die Anwendung der Prüfmatrix bekannt sein. Ihre systematische Darstellung in der Prüfmatrix ermöglicht es, jede einzelne Symptom/Ursache-Beziehung sowie insbesondere die Bündelung von Symptomen auf Ursachen (mehrere Symptome lassen sich auf die gleiche Ursache zurückführen) und die Bündelung von Ursachen auf Symptome (mehrere Ursachen bewirken ein Symptom) klar erkennen und analysieren zu können. Von besonderer Bedeutung ist, ob eine oder mehrere Ursachen sowohl Stärke-Symptome als auch Schwäche-Symptome hervorrufen. Ist dies der Fall, muß bei geplanten organisatorischen Veränderungen zur Beeinflussung der Ursachen nicht nur auf die Beseitigung der Schwäche-Symptome, sondern auch auf die Erhaltung der Stärke-Symptome geachtet werden. Dies erfordert Klarheit über die Korrelationen, die zwischen Symptomen und Ursachen bestehen.

384

Methoden und Techniken der Feinstudie

In Ergänzung zur Prüfmatrix kann die Metaplan-Technik angewendet werden, mit deren Hilfe in Gruppendiskussionen der Projektmitarbeiter und Benutzer symptom-orientierte und ursachen-orientierte "Problemlandschaften" aufgebaut werden. Eine symptom-orientierte Problemlandschaft faßt für jedes Symptom alle Ursachen, eine ursachen-orientierte Problemlandschaft für jede Ursache alle Symptome zu jeweils einem Cluster zusammen. Die Cluster sind Zeilen bzw. Spalten der Prüfmatrix. ABC-Analyse Zweck der ABC-Analyse ist es, durch die Zuordnung der untersuchten Symptome (Stärken und Schwächen) und Ursachen nach einem bestimmten Merkmal in wenige Objektklassen, eine eindeutige Rangfolge der Objekte herzustellen. Da im allgemeinen drei Objektklassen mit den Bezeichnungen A, B und C verwendet werden, wird diese Methode ABC-Analyse genannt. Als Ordnungsmerkmal für Symptome kann z.B. die Häufigkeit ihres Auftretens (A = sehr häufig, B = häufig, C = selten) oder die Anzahl der das Symptom bewirkenden Ursachen (A = viele, B = einige, C = wenige) verwendet werden. Beispiele für Ordnungsmerkmale von Ursachen sind die Anzahl der beeinflußten Stärke-Symptome und die Anzahl der beeinflußten Schwäche-Symptome (A = viele, B = einige, C = wenige). Die Beispiele zeigen, daß mit Hilfe der ABC-Analyse der Analyseschwerpunkt bestimmt werden kann, auf den sich die weitere Analysearbeit konzentrieren soll. Die ABC-Analyse unterstützt also das in der Praxis häufig zu beobachtende Verhalten von Entscheidungsträgern, die Aufmerksamkeit auf die Objekte mit dem größten Veränderungspotential zu lenken. Interaktionsanalyse Die Interaktionsanalyse geht von dem Erhebungsmaterial über den Istzustand aus, das mit Hilfe der Videobeobachtung (vgl. Lerneinheit ISTER) gewonnen wurde (deshalb auch: video-basierte Interaktionsanalyse). Sie konzentriert sich auf die Interaktionen zwischen den Aufgabenträgern im Untersuchungsbereich sowie zwischen diesen und den von ihnen verwendeten Sachmitteln. Die Vorteile der video-basierten Interaktionsanalyse sind: • Die Analyse kann von der Beobachtung zeitlich und räumlich abgekoppelt durchgeführt werden. • Das Analysematerial vermittelt auch die Dynamik des untersuchten Systems, da die Zeitpunkte des Eintreffens wesentlicher Ereignisse vorliegen. • Die Beobachtung des gleichen Ausschnitts der Wirklichkeit ist beliebig wiederholbar; die Analyse kann daher in mehrere Analysezyklen zerlegt werden. • An der Analyse können Experten verschiedener Fachrichtungen teilnehmen (z.B. Betriebswirte, Soziologen, Psychologen). Als Nachteil der Interaktionsanalyse muß der damit verbundene hohe Aufwand an Zeit und Personal gesehen werden. Der Ablauf einer Interaktionsanalyse kann wie folgt beschrieben werden: Zunächst wird eine Analyse des gesamten Videomaterials durchgeführt, deren Ziel

IST AN - Methoden der Istzustandsanalyse

385

es ist, einen ersten Überblick über die wichtigsten Ereignisse und ihre zeitliche Einordnung zu gewinnen. Dieser Überblick löst einen Prozeß der Suche nach besonderen Ereignissen, an die man sich erinnert, aus. Das Videomaterial wird erneut betrachtet, um diese Ereignisse gezielt zu beobachten. Dazu werden bestimmte Sequenzen des Videomaterials ausgesondert. Ein erster Schritt in Richtung einer vertieften Analyse besteht darin, eine wörtliche Abschrift dieser Sequenzen herzustellen. Die vokalen Äußerungen bleiben jedoch von zentralem Interesse. Das Interesse kann sich auch auf Blicke, Gesten und Körperhaltungen konzentrieren. Erkannte Symptome für Stärken und Schwächen werden systematisiert und dokumentiert. Eine Rückkehr in die Erhebung ist dann erforderlich, wenn neue und unbekannte Ereignisse auftauchen, für die ausreichende Erklärungen in dem vorhandenen Material und den bekannten Theorien nicht gefunden werden. Demonstrationsbeispiel Es wird ein Ausschnitt aus einer allgemein verwendbaren Prüfliste gezeigt (Quelle: Schmidt); man erkennt deutlich die mangelhafte Systematik und Präzision, die teilweise für dieses Beispiel kennzeichnend, teilweise aber auch methodisch bedingt sind. • Liegen im Normalfall dem Entscheidenden alle Informationen vor, die im Rahmen der üblichen Entscheidungsanlässe benötigt werden? Fehlen Informationen völlig oder kommen sie zu spät? • Ist klar geregelt, wer * vor einer Entscheidung gehört werden muß? * vor einer Entscheidung informiert werden muß? * nach einer Entscheidung informiert werden muß? • Wo befinden sich die breitesten Informationskanäle? Empfiehlt sich eine räumliche Zusammenlegung? • Sind wichtige Informationskanäle häufig verstopft? • Wie sieht das Verhältnis zwischen verbaler und schriftlicher Information aus? • Entsprechen die gewählten Informationsträger den Anforderungen an Schnelligkeit und Zuverlässigkeit sowie an Sicherheit vor Manipulation? • Sind die Informationsträger so gestaltet, daß wichtige Informationen besonders leicht zu erkennen sind? • Wird mit aussagekräftigen Vergleichsangaben gearbeitet? • Sollten Tabellen, Schaubilder bzw. graphische Darstellungen verwendet werden? • Ist ein ausreichend schneller Zugriff zu gespeicherten Informationen (Dokumentation, Ablage) möglich? • Welche Berichte sind überflüssig? Wer kann aus dem Verteiler ausgeschlossen werden? Werden alle eingehenden Berichte verarbeitet? • Welche Detailinformationen sind überflüssig? Genügt die Übermittlung des Ergebnisses ohne Detailinformationen? • Wie kann die Informationsaufnahme beim Empfänger beschleunigt werden? • Wie kann die Informationsabgabe beim Sender beschleunigt werden? • Gibt es neben informierenden auch motivierende Informationen der Leitungsstelleninhaber?

386

Methoden und Techniken der Feinstudie

• W i e groß ist der Zeitaufwand, der für bilateralen oder multilateralen Informationsaustausch anfällt? • Besteht d i e Koordinationsnotwendigkeit, deretwegen vorhandene Ausschüsse gebildet wurden, nach w i e vor? • S i n d die A u f g a b e n der K o l l e g i e n klar definiert? • Entspricht die zeitliche Belastung der Mitglieder der Bedeutung der A u f g a b e des K o l l e g i u m s ? • Reicht die Koordination durch ein K o l l e g i u m aus? Könnten die Aufgaben evtl. v o n Einzelpersonen oder Projektgruppen besser erledigt werden? Aufgabenverweise Analysieren des Istzustands (Lerneinheit ANIST). Kontrollfragen 1. 2. 3. 4. 5.

Mit welchen Methoden kann die Istzustandsanalyse unterstützt werden? Welcher Zweck wird mit Prüflisten und welcher Zweck wird mit Prüfmatrizen verfolgt? Welchen Vorteil hat die Prüfmatrix gegenüber der Prüfliste? Wie kann die ABC-Analyse die Istzustandsanalyse unterstützen? Welche Vorteile hat die video-basierte Interaktionsanalyse gegenüber den anderen Analysemethoden?

Quellenliteratur Henkel, K. und Schwetz, R.: Schwachstellenanalyse, Techniken der. In: Frese. E. et al. (Hrsg.): Handwörterbuch der Organisation, 3. Auflage, Poeschel Verlag, Stuttgart 1992, 2245 - 2255 Schmidt, G.: Methode und Techniken der Organisation. 8. A., Verlag Schmidt, Gießen 1989 Suchman, L. A. and Trigg, R. H.: Understanding Practice: Video as a Medium for Reflection and Design. In: Greenbaum, J. and Kyng, M.: Design at Work. Lawrence Erlbaum Associates, Publishers, Hillsdale/N. J. 1991, 65 - 89 Wittlage, H.: Methoden und Techniken praktischer Organisationsarbeit. 2. A., Verlag Neue Wirtschafts-Briefe, Herne/ Berlin 1986

KOMAN - Methoden der Kommunikationsanalyse Lernziele Sie kennen die Methoden der Kommunikationsanalyse. Sie können den Zweck jeder Methode nennen und ihre Konzeption erläutern. Sie können in einer konkreten Analysesituation durch Abwägen der Vorteile und der Nachteile der verfügbaren Methoden eine optimale Kombination der Methoden der Kommunikationsanalyse bilden und anwenden. Definitionen und Abkürzungen Adjazenzmatrix (adjacent matrix) = eine Matrix, deren Elemente 1 sind, wenn zwischen den beteiligten Struktureinheiten eine Beziehung besteht; besteht zwischen ihnen keine Beziehung, sind die Elemente 0. Analysemethode (analysis technique) = eine Methode, mit der ein Ganzes durch Zerlegen in Teile und durch Untersuchen der Teile beurteilt wird. Diagramm (diagram) = die graphische Darstellung der Beziehungen zwischen zwei oder mehreren Größen. Empfänger (receiver) = der Endpunkt einer transportierten Information, formale Kommunikation (formal communication) = jede Art der Kommunikation zwischen Struktureinheiten und Aufgabenträgern, die auf organisatorischen Regelungen beruht und der Aufgabenerfüllung dient, informale Kommunikation (informal communication) = die Art der Kommunikation zwischen Struktureinheiten und Aufgabenträgern, die ohne organisatorische Regelungen erfolgt und die auch der Aufgabenerfüllung dienen kann. Kommunikation (communication) = der Austausch von Information mit dem Zweck, das Handeln in bezug auf die gegebenen Ziele optimal zu gestalten. Kommunikationsart (communication kind) = die bei der Kommunikation verwendete Art der Informationsdarstellung (z.B. mündliche oder schriftliche Kommunikation). Kooperation (coopération) = ein sozialer Prozeß zwischen mehreren Aufgabenträgern zur Erreichung gemeinsamer Ziele; Zielidentität kann auf die Bearbeitung eines gemeinsamen Objekts nach vereinbarten Bearbeitungsregeln reduziert sein. Koordination (coordination) = die Abstimmung der Tätigkeiten mehrerer Aufgabenträger, zwischen denen Interdependenz besteht, die sich aus Arbeitsteilung ergibt. Matrix (matrix) = ein orthogonales, in Zeilen und Spalten strukturiertes Schema; die m Zeilen und n Spalten bestimmen die Dimension ("Typ") der Matrix. Organisationsstruktur (organizational structure) = die Gliederung einer Organisation in Subsysteme ("Stellenbildung"). Synonyme: Aufbauorganisation, Strukturorganisation. Sender (transmitter) = der Ausgangspunkt einer transportierten Information. Tabelle (table) = die Darstellung von Daten in Form von numerischen oder alphanumerischen Zeichen oder von Sonderzeichen in Zeilen und Spalten.

388

Methoden und Techniken der Feinstudie

Zweck der Methoden der Kommunikationsanalyse Zweck der Methoden der Kommunikationsanalyse ist es, in der Istzustandsanalyse (vgl. Lerneinheit ANIST) das Analysieren des Transportsystems ("Kommunikationssystem") zu unterstützen, insbesondere des Analysieren der Kommunikationsbeziehungen zwischen den Struktureinheiten (wie Abteilungen und Stellen) und den Aufgabenträgern. Dabei ist jede Sender/Empfänger-Beziehung des Istzustands, in der Information vermittelt wird, eine formale oder informale Kommunikationsbeziehung. Die Analyse der Kommunikationsbeziehungen ermöglicht die Herausarbeitung von Stärken und Schwächen des Istzustands in bezug auf verschiedene Dimensionen der Kommunikation, z.B. Art, Häufigkeit und Zeitbedarf für die Übermittlung von Information. Die Bedeutung der Methoden der Kommunikationsanalyse ergibt sich aus dem zunehmenden Stellenwert der Kommunikation in einem Informations- und Kommunikationssystem, insbesondere aus dem Nutzen, der durch Ausschöpfung des Kooperationspotentials der arbeitsteilig organisierten betrieblichen Aufgaben aktiviert werden kann. Das Wirksammachen von Kooperation setzt Koordination voraus, die ohne Kommunikation nicht möglich ist. Die Kommunikationsanalyse ist daher in solchen Arbeitssituationen von besonderer Bedeutung, in denen es um die Verbesserung der Zusammenarbeit zwischen den Aufgabenträgern geht (z.B. mit dem Ziel, die Durchlaufzeit von Bearbeitungsobjekten zu verkürzen). Die Leistungsfähigkeit der Methoden der Kommunikationsanalyse ist allerdings vergleichsweise gering; sie unterstützen im wesentlichen nur die Ordnung und Systematisierung der die Kommunikationsbeziehungen beschreibenden Attribute und Attributewerte; Schlüsse auf Stärken und Schwächen müssen die Projektbearbeiter selbst ziehen. Abbildung KOMAN-1 gibt einen Überblick über die Methoden der Kommunikationsanalyse. Die Methoden sind nicht primär als Alternativen, sondern als sich ergänzend zu sehen. Je nach Analyseobjekt und den subjektiven Präferenzen der Projektbearbeiter werden in einem Projekt Analysemethoden ausgewählt und verwendet.

Abb. KOMAN-1: Methoden der Kommunikationsanalyse

Allen Methoden haftet ein grundsätzlicher Mangel an: Zwar gelingt es, Mengen, Häufigkeiten, Richtungen, Wege, Mittel, Sender, Empfänger und Arten der Kommunikation darzustellen, aber diese Informationen sind nur für eine beschränkte Anzahl von Projektaufgaben von Bedeutung (etwa Raum- und Kommu-

KOMAN - Methoden der Kommunikationsanalyse

389

n i k a t i o n s m i t t e l - P l a n u n g s o w i e das E r k e n n e n v o n S t ö r u n g e n in K o m m u n i k a t i o n s b e z i e h u n g e n ) . Von w i r t s c h a f t l i c h e r B e d e u t u n g sind E r k e n n t n i s s e ü b e r den W e r t u n d die W i c h t i g k e i t der K o m m u n i k a t i o n . N u r auf G r u n d l a g e solcher Erkenntnisse kann entschieden werden, ob K o m m u n i k a t i o n s b e z i e h u n g e n überflüssig o d e r ü b e r d i m e n s i o n i e r t sind, oder o b K o m m u n i k a t i o n s b e z i e h u n g e n v o n g r o ß e m W e r t u n d hoher W i c h t i g k e i t unterentwickelt sind o d e r sogar fehlen. D i e s e Information liefern die M e t h o d e n der K o m m u n i k a t i o n s a n a l y s e aber nicht. Kommunikationstabelle Eine K o m m u n i k a t i o n s t a b e l l e dient zur Analyse der K o m m u n i k a t i o n s b e z i e h u n g e n z w i s c h e n Stellen in einzelnen Struktureinheiten. In einer K o m m u n i k a t i o n s t a b e l l e w e r d e n j e Stelle f o l g e n d e A t t r i b u t e tabellenartig abgebildet: • • • •

Kommunikationsarten, Kommunikationspartner, Kommunikationsdauer, Kommunikationshäufigkeit.

D i e K o m m u n i k a t i o n s t a b e l l e entsteht zeilenweise nach K o m m u n i k a t i o n s p a r t n e r n , s p a l t e n w e i s e nach K o m m u n i k a t i o n s a r t e n . In j e d e m Feld der Tabelle w i r d nach " A n z a h l der K o m m u n i k a t i o n s v o r g ä n g e " (h), " d u r c h s c h n i t t l i c h e Z e i t d a u e r je K o m m u n i k a t i o n s v o r g a n g " (t) u n d " Z e i t d a u e r j e K o m m u n i k a t i o n s a r t " ( T = A n z a h l der K o m m u n i k a t i o n s v o r g ä n g e x durchschnittliche Z e i t d a u e r je K o m m u n i k a t i o n s v o r g a n g ) u n t e r s c h i e d e n (vgl. A b b . K O M A N - 2 ) . D i e gleiche Tabellenstruktur kann verwendet werden, um die Kommunikationsarten ( m ü n d l i c h e / s c h r i f t l i c h e K o m m u n i k a t i o n oder e l e k t r o n i s c h e K o m m u n i k a t i o n ) abzubilden, i n d e m die H ä u f i g k e i t s a n g a b e n und die M e n g e n a n g a b e n durch Kürzel f ü r die einzelnen K o m m u n i k a t i o n s a r t e n ersetzt werden.

Kommunikationsbeziehungen der Stelle X mit den Stellen Y j bis Y m

Kommunikationsarten K,

Ki

K

n

h t T h t T h t T h t T h t T

Y i

Yi

Ym h = A n z a h l der K o m m u n i k a t i o n s v o r g ä n g e t = durchschnittliche Zeitdauer j e K o m m u n i k a t i o n s vorgang Abb. K O M A N - 2 : Kommunikationstabelle

T - h • t

390

Methoden und Techniken der Feinstudie

Vorteile der Kommunikationstabelle sind die einfache Handhabung und die universelle Einsetzbarkeit. Nachteile sind das Fehlen der Kommunikationsrichtung und damit das Fehlen des Überblicks über die Kommunikationsbeziehungen im Gesamtzusammenhang des Kommunikationssystems. Eine gute Eignung hat die Kommunikationstabelle für die stellenspezifische Kommunikationsanalyse. Kommunikationsdiagramm Ein Kommunikationsdiagramm hat den Zweck, den Inhalt mehrerer Kommunikationstabellen überblicksmäßig darzustellen. Bei der Erstellung eines Kommunikationsdiagramms ist es daher wesentlich, die Gesamtzusammenhänge des Kommunikationssystems herzustellen und die stellenbezogene Sichtweise der Kommunikationstabelle zu überwinden. Ein Kommunikationsdiagramm kann in Dreiecksform als Kommunikationsdreieck oder in Kreisform als Kommunikationsspinne dargestellt werden. Abbildung KOMAN-3 zeigt ein Kommunikationsdiagramm in Dreiecksform. Oberstes Leitungsorgan Konstruktion und Entwicklung Entwicklung Konstruktion Patentbüro Zeichnungsarchiv Fertigung Arbeitsvorbereitung Betriebsleitung Werkzeugbau Technische Revision Einkauf Materiallager Verkauf Fertigung und Versand Werbung Verkauf Inland Export Kundendienst Verwaltung Buchhaltung Finanzen Planung Personal Allgemeine Dienste Abb. KOMAN-3: Kommunikationsdiagramm in Dreiecksform (Quelle: Schmidt)

Zur Erstellung eines Kommunikationsdreiecks wird die Organisationsstruktur als Block dargestellt. Darauf wird die Dreiecksform errichtet. In die Felder des Dreiecks werden die Werte zu einem der folgenden Attribute eingetragen:

KOMAN - Methoden der Kommunikationsanalyse

391

• Kommunikationszeit oder Kommunikationshäufigkeit je Periode zwischen den Struktureinheiten, • vorwiegende Kommunikationsart, • Kommunikationsrichtung (einseitig und Richtung oder zweiseitig). Sollen mehrere Attribute abgebildet werden, müssen weitere Kommunikationsdiagramme erstellt werden. Bei der Kommunikationsspinne wird ebenfalls die Organisationsstruktur zugrundegelegt. Sie wird ringartig entlang eines Kreises eingetragen. Durch Zuordnung von verschieden starken Kanten, werden die Werte zu den Attributen "Kommunikationsdauer" oder "Kommunikationshäufigkeit" dargestellt. Durch die Verwendung von gerichteten Kanten kann die Kommunikationsrichtung angegeben werden. Abbildung KOMAN-4 zeigt ein Kommunikationsdiagramm in Kreisform. Maßstab der Strichstärke 1 - 5 Stunden

—

6 - 1 0 Stunden

• •

1 1 - 1 5 Stunden 1 6 - 2 0 Stunden 2 1 - 2 5 Stunden

•

26 - 3 0 Stunden

•

3 1 - 3 5 Stunden

Abb. KOMAN-4: Kommunikationsdiagramm in Kreisform (Quelle: Schmidt)

Nachteile des Kommunikationsdiagramms sind der Mangel an Genauigkeit und damit der Mangel an qualitativer Aussagekraft sowie die Unübersichtlichkeit bei komplexen Kommunikationsvorgängen. Einsatzschwerpunkt für ein Kommunikationsdiagramm ist die Kommunikationsanalyse mit niedrigem Detaillierungsgrad und hohem Abstraktionsgrad.

392

Methoden und Techniken der Feinstudie

Kommunikationsmatrix Bei der Abbildung von Kommunikationsbeziehungen mit einer Kommunikationsmatrix sind zwei Formen zu unterscheiden. Die erste Form der Kommunikationsmatrix dient zur Darstellung der Häufigkeit (h) und der Dauer (t) der Kommunikationsvorgänge, wobei in den Zeilen die Empfänger und in den Spalten die Sender eingetragen werden (oder umgekehrt). In den zweigeteilten Feldern der Matrix werden Häufigkeit und Dauer der Kommunikationsvorgänge erfaßt. Abbildung KOMAN-5 zeigt ein Beispiel. ^^^^

Sender

Empfänger

Unternehmensleitung h t

Unternehmensleitung

BeVerwaltung schaffung

Verkauf

Fertigung

h

t

h

t

h

t

h

t

10

3

30

15

20

10

10

5

100

50

10

3

60

25

200

50

30

10

20

5

Verkauf

50

30

Fertigung

30

20

120

40

Beschaffung

40

25

5

1

300

25

Verwaltung

15

10

30

10

60

15

15

3

Abb. K O M A N - 5 : Erste F o r m der Kommunikationsmatrix (Quelle: Wittlage)

Die zweite Form der Kommunikationsmatrix unterstützt über Strukturparameter den Entwurf von kommunikationsorientierten Organisationsstrukturen. Die Bezeichnungen der Zeilen und der Spalten sind dieselben wie bei der ersten Form der Kommunikationsmatrix. Die Feldwerte der zweiten Form sind 1 und 0, wobei 1 für "direkte Kommunikationsbeziehung vorhanden" und 0 für "keine direkte Kommunikationsbeziehung vorhanden" steht (vgl. Abbildung KOMAN-6). Xi X [ x2 x3 X4 X5 x6

-

1 1 0 1 0

X2

X3

X4

X5

X6

1

0 1

0 1 I

1 0 0 1

1 1 1 1 0 1

-

1 1 0 0

-

0 1 1

-

1 0

-

1

-

X i = Struktureinheiten A b b . K O M A N - 6 : Z w e i t e F o r m der Kommunikationsmatrix (Quelle: Wittlage)

Mit Matrizenoperationen kann die zweite Form der Kommunikationsmatrix in eine Adjazenzmatrix überführt werden, aus der folgende Informationen gewonnen werden können (wegen Einzelheiten vgl. das Demonstrationsbeispiel in Lerneinheit WTRAN):

KOMAN - Methoden der Kommunikationsanalyse

393

• • • •

der kürzeste Weg zwischen zwei Knoten; das Maß der "Kompaktheit" als Summe aller Entfernungen; die größte Entfernung (Diameter); das Kommunikationszentrum, für das die Summe aller Entfernungen minimal ist; • der entfernteste Knoten vom Zentrum (Radius); • die Anzahl der Zerlegungsknoten, bei deren Entfernung das Kommunikationssystem in mehrere Teilsysteme zerfällt. Die Ergebnisse der Kommunikationsanalyse mit Hilfe der zweiten Form der Kommunikationsmatrix ermöglichen die Messung einer "Differenz" zwischen einem optimalen Kommunikationssystem und dem bestehenden Kommunikationssystem. Vorteile der Kommunikationsmatrix sind die Möglichkeit zur detaillierten Darstellung der Kommunikationsrichtungen und - insbesondere in der zweiten Form - die Möglichkeit zur rechnerischen Gewinnung von Analyseaussagen. Der wesentliche Nachteil der Kommunikationsmatrix ist die Unmöglichkeit, wichtige Parameter, wie z.B. den Kommunikationsinhalt, abzubilden. Einsatzschwerpunkte, für die sich das Kommunikationsdiagramm eignet, sind ergänzende Analysen über die Kommunikationsrichtung. Kommunikationsnetz Mit einem Kommunikationsnetz können Werte zu den Attributen Häufigkeit, Menge und Richtung der Kommunikation sowie die Länge der Kommunikationswege dargestellt werden. In Anlehnung an die Netzplantechnik (vgl. Lerneinheit NETZP) werden die Organisationseinheiten als Knoten (Kreise), die Kommunikationsdauer und die Kommunikationshäufigkeit als gerichtete Kanten (Pfeile) dargestellt, wobei die Dicke der Kanten die Dauer oder die Häufigkeit der Kommunikation oder das Produkt aus Dauer und Häufigkeit wiedergibt. Ergänzend dazu kann die Länge der Kommunikationswege durch Zuordnung von Zahlen angegeben werden. Mit Hilfe der Methode des kritischen Wegs können kritische Wege berechnet werden. Abbildung KOMAN-7 zeigt ein Beispiel.

1 - 5 Stunden/Monat 6 - 1 0 Stunden/Monat 11-15 Stunden/Monat 16 - 20 Stunden/Monat Abb. KOMAN-7: Kommunikationsnetz (Quelle: Wittlage)

Vorteile des Kommunikationsnetzes sind die relativ gute Übersichtlichkeit und die Möglichkeit zur gleichzeitigen Berücksichtigung mehrerer Attribute. Kom-

394

Methoden und Techniken der Feinstudie

munikationsnetze eignen sich zur Darstellung nahezu aller Kommunikationssysteme. Aufgabenverweise Analysieren des Istzustands (Lerneinheit ANIST). Kontrollfragen 1. Für welche Arbeitssituation ist die Kommunikationsanalyse von besonderer Bedeutung? 2. Aus welchen Attributen besteht eine Kommunikationstabelle? 3. Welche quantitativen Aussagen können mit Matrizenoperationen aus Kommunikationsmatrizen gewonnen werden? 4. Welche Methoden der Kommunikationsanalyse eignen sich für die Darstellung von Kommunikationsarten? 5. Welche Unterschiede bestehen zwischen den beiden Formen des Kommunikationsdiagramms? Quellenliteratur Schmidt, G.: Methode und Techniken der Organisation. 8. A., Verlag Schmidt, Gießen 1989 Wittlage, H.: Methoden und Techniken praktischer Organisationsarbeit. Verlag Neue WirtschaftsBriefe, Herne/Berlin 1980 Vertiefungsliteratur Bössmann, E.: Die ökonomische Analyse von Kommunikationsbeziehungen in Organisationen. Springer Verlag, Berlin et al. 1967 Heinrich, L. J.: Zur rechnerischen Lösung von Organisationsproblemen mit Hilfe der Graphentheorie. In: Layer, M. (Hrsg.): Rechnungswesen und Betriebswirtschaftspolitik. Schmidt Verlag, Bielefeld 1969,169 - 179

Literaturverzeichnis Achatzi, G.: Praxis der strukturierten A n a l y s e - eine objektorientierte V o r g e h e n s w e i s e . Verlag Hanser, M ü n c h e n / W i e n 1991 Ambichl, E.: Leistungsbewertung dialogorientierter Datenbanksysteme in Client/Server-Architektur. Dissertation Universität Linz, Linz 1991 A m b i c h l , E. und Gappmaier, M.: Nicht vernetzte PCs versus lokale N e t z w e r k e - eine Vergleichsstudie. In: Information M a n a g e m e n t 1/1989, 38 - 43 A m b i c h l , E. u n d Heinrich, L. J.: L e i s t u n g s b e w e r t u n g dialogorientierter D a t e n b a n k s y s t e m e in Client/Server-Architekturen. In: Information Management 3/1992, 2 4 - 3 1 Anselstetter, R.: Betriebswirtschaftliche N u t z e f f e k t e der Datenverarbeitung - A n h a l t s p u n k t e für N u t z e n - K o s t e n - S c h ä t z u n g e n . 2. A., Springer Verlag, Berlin et al. 1986 Antweiler, J.: Wirtschaftlichkeitsanalyse von Informations- und K o m m u n i k a t i o n s s y s t e m e n . Datakontext, Köln 1995 Ardelt, E.: S o z i o g r a m m . In: Roth, M . (Hrsg.): Sozialwissenschaftliche M e t h o d e n . 2. A., Oldenbourg Verlag, M ü n c h e n / W i e n 1987, 1 8 4 - 1 9 5 Atteslander, P. und Kopp, M.: Befragung. In: Roth, M. (Hrsg.): S o z i a l w i s s e n s c h a f t l i c h e M e t h o den. 2. A „ O l d e n b o u r g Verlag, M ü n c h e n / W i e n 1987, 144 - 172 A u w e r a , F. van der and M o k , A.: T h e Politics of T e c h n o l o g y - Routinization and M a n a g e m e n t and Union Strategies. In: Dunkerley, D. and S a l a m a n , G. (Eds.): T h e International Y e a r b o o k of Organization Studies 1981, 1 4 5 - 160 A v i s o n , D. E. and Fitzgerald, G.: Information Systems D e v e l o p m e n t - M e t h o d o l o g i e s , Techniques and Tools. Blackwell Scientific Publications, Oxford et al. 1988 Balzert, H.: C A S E . S y s t e m e und W e r k z e u g e . 4. A., BI W i s s e n s c h a f t s v e r l a g , M a n n h e i m et al. 1992 Bauer, W . und V i e w e g , W.: Simulation. In: Grochla, E. (Hrsg.): H a n d w ö r t e r b u c h der Organisation. 2. A., C. E. Poeschel Verlag, Stuttgart 1980, 2 0 6 3 - 2 0 7 5 B a u m g a r t e n , B.: Petri-Netze. Grundlagen und A n w e n d u n g e n . Wissenschaftsverlag, M a n n h e i m et al. 1990 Bernstein, D.: D i e Kunst der Präsentation. 2. A., C a m p u s Verlag, F r a n k f u r t / N e w York 1992 B e r t r a m , H. et al.: C A S E in der Praxis. S o f t w a r e e n t w i c k l u n g s u m g e b u n g e n f ü r I n f o r m a t i o n s systeme. Springer Verlag, Berlin et al. 1993 B i s c h o f b e r g e r , W . and P o m b e r g e r , G.: Prototyping-oriented S o f t w a r e D e v e l o p m e n t . C o n c e p t s and Tools. Springer Verlag, Berlin et al. 1992 B i s c h o f f , U. et al.: Schaubilder als Führungsinstrument. T e c h n i k und M e t h o d i k visueller K o m munikationshilfen. Verlag Moderne Industrie, München 1971 B l o h m , H. und Lüder, K.: Investition. 7. A., Verlag Vahlen, M ü n c h e n 1992 B ö s s m a n n , E.: Die ö k o n o m i s c h e Analyse von K o m m u n i k a t i o n s b e z i e h u n g e n in Organisationen. Springer Verlag, Berlin et al. 1967 Bons, H. und M e n g e n , R. van: Situation u n d E n t w i c k l u n g s t e n d e n z e n des T e s t e n s in der Praxis. In: H M D 105/1982, Forkel Verlag, Stuttgart/Wiesbaden 1982, 85 - 95 Brandstätter, H.: Problemlösen u n d Entscheiden in G r u p p e n . In: Roth, E. (Hrsg.): E n z y k l o p ä d i e der Psychologie, B a n d Organisationspsychologie. Verlag Hogrefe, Göttingen 1989, 5 0 5 - 5 2 8 B r e i t e n e c k e r , F. et al. (Hrsg.): S i m u l a t i o n s t e c h n i k . Proc. 6. S y m p o s i u m S i m u l a t i o n s t e c h n i k . V i e w e g Verlag, Braunschweig 1990 B u d d e , R. et al.: Prototyping. An A p p r o a c h to Evolutionary S y s t e m D e v e l o p m e n t . Springer Verlag, Berlin et al. 1992 B u d d e , R. u n d Nieters, H.: E i n f ü h r u n g in die Netztheorie (Theorie der Petri-Netze). In: Regelungstechnik 3/1984, 7 6 - 80 und 4/1984, 107 - 113 B u x m a n n , P. u n d König, W.: Ein Entscheidungsmodell zur B e w e r t u n g von Investitionen in Standards - dargestellt a m Beispiel von ISO-Standards und C C I T T - E m p f e h l u n g e n für e i n e o f f e n e D a t e n k o m m u n i k a t i o n . In: W I R T S C H A F T S I N F O R M A T I K 3/1994, 252 - 267 C a v e , W . C. and M a y m o n , G. W . : Leitfaden des S o f t w a r e - P r o j e k t m a n a g e m e n t s . Forkel Verlag, Wiesbaden 1988 Chroust, G.: Modelle der Software-Entwicklung. Oldenbourg Verlag, M ü n c h e n / W i e n 1992 C o a d , P. and Y o u r d o n , E.: O b j e c t - O r i e n t e d Analysis. 2. Ed., Prentice Hall Int., E n g l e w o o d C l i f f s / N . J . 1991

396

Literaturverzeichnis

Corell, C. H. und Debest, X.: Untersuchungen über Maßnahmen zur Verbesserung der SoftwareProduktion - Teil 3: Einsatz von Methoden der Software-Produktion. O l d e n b o u r g Verlag, München/Wien 1980 Cyert, R. M. and March, B.: Behavioral Theory of the Firm. Englewood Cliffs/N.J. 1963 Daenzer, W. F. (Hrsg.): Systems Engineering. Leitfaden zur methodischen D u r c h f ü h r u n g umfangreicher Planungsvorhaben. 6. A., Hanstein Verlag, Köln und Verlag Industrielle Organisation, Zürich 1988 D e M a r c o , T.: Structured Analysis and System Specificaton. Prentice Hall, Englewood Cliffs/N.J. 1979 Dittrich, R.: Objektorientierte Datenmodelle als Basis k o m p l e x e r A n w e n d u n g s s y s t e m e . In: WRTSCHAFTSINFORMATIK 3/1990, 228 - 237 Dreßler, H.: Problemlosen mit Entscheidungstabellen. Oldenbourg Verlag, München/Wien 1975 Eisenführ, F. und Weber, M.: Zielstrukturierung: ein kritischer Schritt im Entscheidungsprozeß. In: Zeitschrift für betriebswirtschaftliche Forschung 11/1986, 907 - 929 Elben, W.: Entscheidungstabellentechnik - Logik, Methodik und Programmierung. Verlag de Gruyter, Berlin/New York 1973 E n d , W . et al.: Softwareentwicklung. Leitfaden für Planung, Realisierung und E i n f ü h r u n g von DV-Verfahren. 7. A „ Siemens AG, Berlin/München 1990 Ferstl, O. K. und Sinz, E. J.: Objektmodellierung betrieblicher Informationssysteme im Semantischen Objektmodell (SOM). In: WIRTSCHAFTS INFORMATIK 3/1990, 566 - 581 Fischbach, F. et al.: Entscheidungstabellen - Hilfsmittel zur Entscheidungsfindung, D o k u m e n t a tion und Programmierung. Verlagsgesellschaft Müller, Köln-Braunsfeld 1975 FitzGerald, J. and FitzGerald, A. F.: Fundamentals of Systems Analysis. Using Structured Analysis and Design Techniques. 3. Ed., Wiley & Sons, New York et al. 1987 Franconi, J. M. und Kandel, A.: A Software Engineering Tool for Expert System Design. In: IEEE E X P E R T , Spring 1988, 33 - 4 1 Gane, C. and Sarson, T.: Structured System Analysis: Tools and Techniques. Improved System Technologies, New York 1979 Genrich, H. J. et al.: Petri-Netze in der Praxis. In: Der GMD-Spiegel 4/1988, 55 Gierse, F. J.: Funktionen und Funktionen-Strukturen - zentrale Werkzeuge der Wertanalyse. In: VDI-Berichte 849, Düsseldorf 1990 Grünewald, U. und Koch, R.: Informationstechnik in Büro und Verwaltung. Berichte zur beruflichen Bildung des Bundesinstituts für Berufsbildungsforschung, Heft 32, Berlin 1981 Grupp, B.: Methoden der Istaufnahme und Problemanalyse. Arbeitstechniken für Mitarbeiter in E D V - und Büroprojekten. Forkel Verlag, Wiesbaden 1987 Haag, W.: Dokumentation von Anwendungssystemen aus der Sicht der Benutzer. Toeche-MittlerVerlag, Darmstadt 1981 Haberfellner, R.: Organisationsmethodik. In: Grochla, E. (Hrsg): Handwörterbuch der Organisation. 2. A„ Poeschel Verlag, Stuttgart 1980, 1 7 0 1 - 1710 Haag, W.: Dokumentation von Anwendungssystemen aus der Sicht der Benutzer. Toeche-MittlerVerlag, Darmstadt 1981 Haller-Wedel, E.: Das Multimomentverfahren in Theorie und Praxis. Hanser Verlag, München 1969 Hansel, J. und Lomnitz, G.: Projektleiter-Praxis - Erfolgreiche Projektabwicklung durch verbesserte Kommunikation und Kooperation. Springer Verlag, Berlin et al. 1987 Hatley, D. J. and Pirbhai, I. A.: Strategies for Real-Time Systems Specification. Dorset House Publ., New York 1987 Hausen, H.-L., Müllerburg, M. und Sneed, H. M.: Software-Produktionsumgebungen. Verlagsgesellschaft Müller, Köln-Braunsfeld 1985 H e i l m a n n , H.: Das M a n a g e m e n t von Softwareprojekten. In: H M D 116/1984. Forkel Verlag, Stuttgart/Wiesbaden 1984, 3 - 22 Heinen, E.: Grundlagen betriebswirtschaftlicher Entscheidungen. Das Zielsystem der Unternehmung. 3. A., Verlag Gabler, Wiesbaden 1976 Heinrich, L. J.: Zur rechnerischen Lösung von Organisationsproblemen mit Hilfe der Graphentheorie. In: Layer, M . (Hrsg.): Rechnungswesen und Betriebswirtschaftspolitik. Schmidt Verlag, Bielefeld 1969, 1 6 9 - 179 Heinrich, L. J.: C O S M A - Computerselektion mit Matrizenmodellen - Ein Verfahren zur Bewertung von Datenverarbeitungsanlagen der Mittleren Datentechnik. In: Zeitschrift für Betriebswirtschaft 3/1970, 1 6 3 - 1 8 2

Literaturverzeichnis

397

Heinrich, L. J.: Wirtschaftsinformatik als Wissenschaft - Entwicklung, Stand und Perspektiven. In: Heinrich, L. J. und Lüder, K. (Hrsg.): Betriebswirtschaftslehre und U n t e r n e h m e n s f ü h rung. Verlag Neue Wirtschaftsbriefe, Herne/Berlin 1985, 35 - 59 Heinrich, L. J.: Wirtschaftsinformatik in Forschung und Ausbildung. In: Information Management 1/1986, 63 - 6 9 Heinrich, L. J.: Zur Methodik der Systemplanung in der Wirtschaftsinformatik. In: Schult, E. und Siegel, Th. (Hrsg.): Betriebswirtschaftslehre und Unternehmenspraxis. Schmidt Verlag, Berlin 1986, 83 - 9 9 Heinrich, L. J.: Schwachstellen und Risiken bei S o f t w a r e p r o j e k t e n . In: C o m p u t e r und Recht 7 / 1 9 8 8 , 5 8 4 - 587 Heinrich, L. J.: Der Prozeß der Systemplanung und -entwicklung. In: Kurbel, K. und Strunz, H. (Hrsg.): Handbuch der Wirtschaftsinformatik. Poeschel Verlag, Stuttgart 1989, 1 9 9 - 2 1 4 Heinrich, L. J.: Informationsmanagement - Planung, Überwachung und Steuerung der Informationsinfrastruktur. 5. A., Oldenbourg Verlag, München/Wien 1996 Heinrich, L. J.: Wirtschaftsinformatik - Einführung und Grundlegung. Oldenbourg Verlag, München/Wien 1993 Heinrich, L. J. et al.: Informations- und Kommunikationstechnik für Betriebswirte und Wirtschaftsinformatiker. 4. A., Oldenbourg Verlag, München/Wien 1994 Heinrich, L. J. und Ambichl, E.: Ein Modell zur Unterstützung strategischer TechnologieeinsatzEntscheidungen. In: Information Management 3/1988, 44 - 52 Heinrich, L. J. und Gappmaier, M.: Das aktuelle Schlagwort: Computerunterstützung kooperativen Arbeitens (CSCW). In: WIRTSCHAFTSINFORMATIK 3/1992, 340 - 343 Heinrich, L. J. und Pils, M.: Betriebsinformatik im Personalbereich - Die Planung computergestützter P e r s o n a l i n f o r m a t i o n s s y s t e m e . Physica-Verlag, W ü r z b u r g / W i e n 1979, N a c h d r u c k 1983,38 - 4 6 Heinrich, L. J. und Reindl, M.: Leistungsbewertung von Datenbank-Server-Systemen. In: Frisch, W. und Taudes, A. (Hrsg.): Informationswirtschaft. Aktuelle Entwicklungen und Perspektiven. Physica Verlag, Heidelberg 1993, 231 - 246 Heinrich, L. J. und Roithmayr, F.: Wirtschaftsinformatik-Lexikon. 5. A., Oldenbourg Verlag, München/Wien 1995 Heinrich, L. J. und Sterrer, G.: Ziele von Informationssystemen - Ergebnisse einer empirischen Studie. In: Information Management 1/1987, 48 - 53 Henkel, K. und Schwetz, R.: Schwachstellenanalyse, Techniken der. In: Frese. E. et al. (Hrsg.): Handwörterbuch der Organisation, 3. Auflage, Poeschel Verlag, Stuttgart 1992, 2245 - 2255 Hentschel, B. und W r o n k a , G.: Personalinformationssysteme in der Diskussion. Datakontext Verlag, Köln 1983 Heß, H. und Scheer, A.-W.: Methodenvergleich zum objektorientierten Design von Softwaresystemen. In: Theorie und Praxis der Wirtschaftsinformatik 165/1992, 117 - 137 Hetzel, F.: Dokumentation mit System. Arbeitsgemeinschaft E D V , München 1982 Hice, G. F. et al.: System Development Methodology. North Holland Publishing C o m p a n y , Amsterdam et al. 1979 Hildebrand, K.: Repository-unterstütztes Prototyping. In: Theorie und Praxis der Wirtschaftsinformatik 161/1991, 1 0 7 - 116 H o f f m a n n , F.: A u f g a b e . In: Grochla, E. (Hrsg.): Handwörterbuch der Organisation. Poeschel Verlag, Stuttgart 1980, 200 -207 H o f f m a n n , H.: Wertanalyse - Ein W e g zur Erschließung neuer Rationalisierungsquellen. 2. A., Schmidt Verlag, Berlin 1983 H o f f m a n n , H.: Kreativitätstechniken für Manager. 2. A., Verlag Moderne Industrie, Landsberg 1987 Hofstetter, H.: Organisationspsychologische Aspekte der Software-Entwicklung. In: Schelle, H. und Molzberger, P.: Psychologische Aspekte der Software-Entwicklung. Oldenbourg Verlag, München/Wien 1983, 25 - 62 Huber, O.: Beobachtung. In: Roth, M. (Hrsg.): Sozialwissenschaftliche Methoden. 2. A., Oldenbourg Verlag, München/Wien 1987, 1 2 4 - 1 4 3 I B M (Hrsg.): HIPO. Eine Design-Hilfe und Dokumentationstechnik. IBM-Form GC20-1851 Jarschel, W. et al.: Modellierung von Fertigungssystemen mit dem Petri-Netz-Simulator PETSI. In: WIRTSCHAFTSINFORMATIK 5/1992, 535 - 544 Jehle, E.: Wertanalyse. In: Handwörterbuch der Betriebswirtschaft. 5. A., Poeschel Verlag, Stuttgart 1992 Jones, K. (Butler Cox): T h e lack of benefits realised through C A S E . Handouts, C o n f e r e n c e "CASE - Der Weg ist ein Ziel", März 1992

398

Literaturverzeichnis

J o s c h k e , H. K.: D a r s t e l l u n g s t e c h n i k e n . In Grochla, E . (Hrsg.): H a n d w ö r t e r b u c h der O r g a n i s a tion. 2. A., Poeschel Verlag, Stuttgart 1980, 431 - 4 6 2 Kargl, H.: F a c h e n t w u r f für D V - A n w e n d u n g s s y s t e m e . 2. A., Oldenbourg Verlag, M ü n c h e n / W i e n 1991 Kargl, H.: Controlling im DV-Bereich. Oldenbourg Verlag, M ü n c h e n / W i e n 1993 Katzan, H.: M e t h o d i s c h e r Systementwurf - Eine E i n f ü h r u n g in die H I P O - T e c h n i k . Verlagsgesellschaft Müller, Köln-Braunsfeld 1980 K i e b a c k , A. et al.: Prototyping in industriellen S o f t w a r e - P r o j e k t e n - E r f a h r u n g e n und A n a l y s e n . In: Informatik S p e k t r u m 2/1992, 65 - 77 Klein, H.: P a r t n e r s c h a f t z w i s c h e n Fachabteilung u n d E D V . In: H e i l m a n n , H. (Hrsg.): Z u s a m m e n a r b e i t z w i s c h e n F a c h a b t e i l u n g und E D V . 9. J a h r b u c h der E D V . Forkel V e r l a g , Stuttgart/Wiesbaden 1980, 1 5 - 6 3 K o l b , A.: Ein p r a g m a t i s c h e r A n s a t z z u m R e q u i r e m e n t s Engineering. In: I n f o r m a t i k S p e k t r u m 6/1992, 315 - 3 2 2 Körte, R.-J.: V e r f a h r e n der W e r t a n a l y s e - Betriebswirtschaftliche G r u n d l a g e n z u m Ablauf wertanalytischer Entscheidungsprozesse. Schmidt Verlag, Berlin 1977 K r a m e r , F.: P r o d u k t i n n o v a t i o n - D i e Orientierung Band 66. S c h w e i z e r i s c h e V o l k s b a n k , Bern 1984, 8 7 - 1 0 2 Krcmar, H.: Gestaltung von Computer-am-Arbeitsplatz-Systemen, Entwicklung von Alternativen und deren B e w e r t u n g durch Simulation. Minerva Publikationen, München 198 Kreutzer, W.: G r u n d k o n z e p t e und W e r k z e u g s y s t e m e objektorientierter S y s t e m e n t w i c k l u n g . In: WIRTSCHAFISINFORMATIK 3/1990, 211 - 227 K u h l e n , R.: Hypertext. Ein nicht-lineares M e d i u m z w i s c h e n Buch und W i s s e n s b a n k . Springer Verlag, Berlin et al. 1991 K u m m e r , W . et al.: P r o j e k t - M a n a g e m e n t . Leitfaden zu M e t h o d e und T e a m f ü h r u n g in der Praxis. 3. A., Verlag Industrielle Organisation, Zürich 1993 L a m p r e c h t , M. u n d Jackson, I.: Strategische P l a n u n g des I n f o r m a t i o n s s e r v i c e . In: I n f o r m a t i o n M a n a g e m e n t 1/1989, 28 - 35 Liebl, F.: Simulation. Problemorientierte Einführung. Oldenbourg Verlag, M ü n c h e n / W i e n 1992 L i g g e s m e y e r , P.: M o d u l t e s t und Modulverifikation. State of the Art. BI W i s s e n s c h a f t s v e r l a g , M a n n h e i m e t a l . 1990 M a m b r e y , P. und O p p e r m a n n , R.: Benutzerbeteiligung bei der Systementwicklung - Einschätzung der Möglichkeiten durch Experten. In: Angewandte Informatik 3/1985, 1 1 1 - 119 M a r c a , D. A. a n d M c G o w a n , C. L.: S A D T . S t r u c t u r e d A n a l y s i s and D e s i g n T e c h n i q u e . M c G r a w - H i l l Book C o m p a n y , N e w York et al. 1975 Martin, C. F.: U s e r - C e n t e r e d Requirements Analysis. Prentice Hall Int., E n g l e w o o d C l i f f s / N . J . 1988 Martin, J. and M c C l u r e , C.: Structured Techniques. T h e Basis for C A S E . Rev. Ed., Prentice Hall Inc., E n g l e w o o d Cliffs/N.J. 1988 M c M e n a m i n , St. M . u n d P a l m e r , J. F.: S t r u k t u r i e r t e S y s t e m a n a l y s e . V e r l a g e H a n s e r u n d Prentice-Hall International, München/Wien und London 1988 M e n g e n , R. van und B o n s , H.: Sicherstellung der Qualität von P r o g r a m m s y s t e m e n d u r c h systematisches Testen. In: H M D 105/1982, Forkel Verlag, Stuttgart/Wiesbaden 1982, 23 - 36 Mertens, P.: Simulation. 2. A., Poeschel Verlag, Stuttgart 1982 M e r t e n s , P. et al.: G r u n d z ü g e der W i r t s c h a f t s i n f o r m a t i k . 3. A., Springer V e r l a g , Berlin et. al. 1995 M e r t e n s , P. (Hrsg.): Studien- und Forschungsführer W i r t s c h a f t s i n f o r m a t i k . 5. A., Springer Verlag, Berlin et al. 1996 M e y e r , M . und H a n s e n , K.: Planungsverfahren des O p e r a t i o n s Research. Verlag V a h l e n , M ü n chen 1985, 7 9 - 146 M i t t e r m e i e r , R.: R e q u i r e m e n t s Engineering. In: Kurbel, K. und Strunz, H. (Hrsg.): H a n d b u c h Wirtschaftsinformatik. Verlag Poeschel, Stuttgart 1990, 237 - 2 5 6 Nassi, I. and S h n e i d e r m a n , B.: Flowchart T e c h n i q u e s for Structured P r o g r a m m i n g . In: A C M S I G P L A N Notices 8/1973, 12 - 2 6 Niemeier, J.: K o n z e p t e der Wirtschaftlichkeitsberechnung bei integrierten Informationssystemen. In: H o r v ä t h , P. (Hrsg.): Wirtschaftlichkeit neuer P r o d u k t i o n s - und I n f o r m a t i o n s t e c h n o l o g i e . Stuttgart 1988, 15 - 34 N o m i n a Information Services (Hrsg.): ISIS Software Report und ISIS Personal C o m p u t e r Report, jeweils aktuelle Auflage Olle, T. W . et al.: Information S y s t e m s Methodologies. A F r a m e w o r k for Understanding. 2. Ed., A d d i s o n - W e s l e y , W o k i n g h a m et al. 1991

Literaturverzeichnis

399

Österle, H. (Hrsg.): Anleitung zu einer praxisorientierten S o f t w a r e - E n t w i c k l u n g s u m g e b u n g . Erfolgsfaktoren werkzeugunterstützter Software-Entwicklung. AIT Verlag, Halbergmoos 1988 Partsch, H.: Requirements Engineering. Oldenbourg Verlag, München/Wien 1991 Penzel, H. G.: Ein systematischer Vergleich von Entwurfsverfahren für betriebliche Informationssysteme. Dissertation Universität Mainz, Mainz 1983 Peterson, L.: Petri Net Theory and the Modelling of Systems. Prentice Hall Inc., E n g l e w o o d Cliffs/N.J. 1981 Petri, A. C. (Hrsg.): Ansätze zur Organisationstheorie rechnergestützer Informationstheorie. Oldenbourg Verlag, München/Wien 1979 Pfadler, W.: Mitschreitende Leistungskontrolle in E D V - P r o j e k t e n . In: M o l z b e r g e r , P. und Schelle, H. (Hrsg.): Software. Moderne Methoden zur Planung, Realisierung und Kontrolle der Entwicklung. Oldenbourg Verlag, München/Wien 1981, 205 - 228 Picot, A. und Reichwald, R.: Kommunikationstechnik für Anwender - Akzeptanzbarrieren, Bedarfsstrukturen, Einsatzbedingungen. CW-Publikationen Verlagsgesellschaft, München 1983 Picot, A. und Reichwald, R. (Hrsg.): Kommunikationstechnik und Wirtschaftlichkeit. CW-Publikationen Verlagsgesellschaft, München 1984 Platz, J. und Schmelzer, H. J.: Projektmanagement in der industriellen Forschung und Entwicklung - Einführung anhand von Beispielen aus der Informationstechnik. Springer Verlag, Berlin et al. 1986 Pomberger, G.: Softwaretechnik und Modula-2. 2. A., Hanser Verlag, München/Wien 1987 P o m b e r g e r , G. und Blaschek, G.: S o f t w a r e Engineering. Prototyping und objektorientierte Software-Entwicklung. Hanser Verlag, München/Wien 1993 Rausch, H.: Grundsätze ordnungsmäßiger EDV-Dokumentation. Dissertation Universität Hamburg, H a m b u r g 1983 Rautenberg, K.-U. und Sova, O.: Dokumentation computergestützter Informationssysteme. Saur Verlag, München 1983 Reichwald, R.: Ein mehrstufiger Bewertungsansatz zur wirtschaftlichen Leistungsbeurteilung der Bürokommunikation. In: Hoyer, R. H. und Kölzer, G. (Hrsg.): Wirtschaftlichkeitsrechnungen im Bürobereich. Verlag de Gruyter, Berlin 1987, 23 - 33 Reisig, W.: Petri-Netze - Eine Einführung. 2. A., Springer Verlag, Berlin et al. 1986 Reisig, W.: Systementwurf mit Netzen. 2. A., Springer Verlag, Berlin et al. 1985 Reisin, F.-M.: Kooperative Gestaltung in partizipativen Softwareprojekten. Verlag P. Lang, Frankfurt/M. et al. 1992 Roithmayr, F.: Controlling von Informations- und Kommunikationssystemen. Oldenbourg Verlag, München/Wien 1988 Rosenstengel, B. und Winand, U.: Petri-Netze - Eine anwendungsorientierte Einführung. 4. A., Verlag Vieweg, Braunschweig und Wiesbaden 1991 Ross, D. T.: Structured Analysis Design Technique (SA): A language for communicating ideas. In: IEEE Transactions on Software Engineering, SE-3 1977, 1 6 - 3 4 Roth, M. (Hrsg.): Sozialwissenschaftliche Methoden. 2. A., Oldenbourg Verlag, München/Wien 1987 Rozenberg, G. (Hrsg.): Advances in Petri Nets. Proceedings, 10th International C o n f e r e n c e on Applications and Theory of Petri Nets 1990. Springer Verlag, Berlin et al. 1991 Runzheimer, B.: Operations Research I. Lineare Planungsrechnung und Netzplantechnik. 5. A., Verlag Gabler, Wiesbaden 1990 Rupieta, W.: Benutzerdokumentation für Softwareprodukte. BI Wissenschaftsverlag, Mannheim et al. 1987 Schanz, G.: Organisationsgestaltung - Struktur und Verhalten. Verlag Vahlen, München 1982 Scheibl, H.-J.: Wie dokumentiere ich ein DV-Projekt? Dokumentationsverfahren in Theorie und Praxis, expert verlag, Sindelfingen 1985 Scheer, A.-W.: EDV-orientierte Betriebswirtschaftslehre. 4.A., Springer Verlag, Berlin et al. 1990 Schmidt, Ch.: Petri-Netze - Ein Instrument zur Lösung logistischer Probleme im CIM-Bereich. In: WIRTSCHAFTSINFORMATIK 1/1992, 66 - 75 Schmidt, G.: Methode und Techniken der Organisation. 8. A., Verlag Schmidt, Gießen 1989 Schmitz, P. et al.: Software-Qualitätssicherung - Testen im S o f t w a r e - L e b e n s z y k l u s . Verlag Vieweg, Braunschweig 1982 Schneeweiß, Ch.: Planung 1 - Systemanalytische und entscheidungstheoretische Grundlagen. Springer Verlag, Berlin et al. 1991 Schumann, M.: Betriebliche Nutzeffekte und Strategiebeiträge der großintegrierten Informationsverarbeitung. Springer Verlag, Berlin et al. 1992

400

Literaturverzeichnis

S c h u m a n n , M . : Wirtschaftlichkeitsbeurteilung f ü r I V - S y s t e m e . In: WIRTSCHAFTS INFORMATIK 2/1993, 167 - 178 S c h w a r z e , J.: Netzplantechnik. 6. A., Verlag N e u e Wirtschaftsbriefe, Herne/Berlin 1990 Selig, J.: E D V - M a n a g e m e n t - Eine empirische Untersuchung der Entwicklung von A n w e n d u n g s systemen in deutschen Unternehmen. Springer Verlag, Berlin et al. 1986 Shlaer, S. and M e l l o r , S. J.: Object-oriented S y s t e m s A n a l y s i s - M o d e l l i n g the W o r l d in Data. Jourdon Press, L o n d o n 1988 Sneed, H.: S o f t w a r e - T e s t e n - Stand der Technik. In: Informatik Spektrum 11/1988, 303 - 311 Spinas, O. u n d W e b e r , D.: Benutzerbeteiligung aus der Sicht von E n d b e n u t z e r n , S o f t w a r e e n t wicklern u n d F ü h r u n g s k r ä f t e n mit Beteiligungserfahrung. In: A c k e r m a n n , D. u n d Ulich, E. (Hrsg.): S o f t w a r e - E r g o n o m i e '91. Benutzerorientierte S o f t w a r e - E n t w i c k l u n g . Verlag T e u b n e r , Stuttgart 1 9 9 1 , 3 6 - 4 5 Stay, J. F.: H I P O and Integrated Program Design. In: I B M Journal 15/1976, 143 Stickel, E.: Eine Erweiterung des hedonistischen Verfahrens zur Ermittlung der Wirtschaftlichkeit des Einsatzes von Informationstechnik. In: Zeitschrift für Betriebswirtschaft 7/1992, 743 - 759 Strunz, H.: Entscheidungstabellentechnik. Oldenbourg Verlag, M ü n c h e n / W i e n 1977 Strohm, O.: P r o j e k t m a n a g e m e n t bei der Software-Entwicklung. Eine arbeitspsychologische A n a lyse und B e s t a n d s a u f n a h m e . In: Ackermann, D. und Ulich, E. (Hrsg.): S o f t w a r e - E r g o n o m i e '91. Benutzerorientierte Software-Entwicklung. Verlag Teubner, Stuttgart 1991, 47 - 58 Strunz, H.: E n t s c h e i d u n g s t a b e l l e n t e c h n i k . In: Frese. E. et al. (Hrsg.): H a n d w ö r t e r b u c h der Organisation, 3. Auflage, Poeschel Verlag, Stuttgart 1992, 5 7 5 - 585 S u c h m a n , L. A . and Trigg, R. H.: Understanding Practice: V i d e o as a M e d i u m for Reflection and D e s i g n . In: G r e e n b a u m , J. and Kyng, M.: Design at W o r k . L a w r e n c e E r l b a u m Associates, Publishers, Hillsdale/N. J. 1991, 65 - 89 S y d o w , J.: O r g a n i s a t i o n s s p i e l r a u m und Büroautomation. Verlag de Gruyter, B e r l i n / N e w Y o r k 1985 T a n , M.: U s i n g C o m m u n i c a t i o n T h e o r y for Systems D e s i g n : A Model for Eliciting I n f o r m a t i o n R e q u i r e m e n t s . In: Avison, D. et al. (Ed.): H u m a n , Organizational, and Social D i m e n s i o n s of Information S y s t e m s Development. Elsevier Science Publishers, North-Holland et al. 1993 T e m p e l m e i e r , H.: Simulation mit S I M A N . Ein praktischer Leitfaden zur M o d e l l e n t w i c k l u n g und P r o g r a m m i e r u n g . Physica Verlag, Heidelberg 1991 T h a y e r , R. H. and D o r f m a n , M.: S y s t e m and S o f t w a r e R e q u i r e m e n t s E n g i n e e r i n g , C o m p u t e r Society Press, Los A l a m o s 1990 T i m m , M.: Ein systematisches Vorgehensmodell zur Spezifizierung der B e n u t z e r a n f o r d e r u n g e n . In: A n g e w a n d t e Informatik 4/ 1985, 145 - 151 Uebele, H.: Z u r Praxis der Kreativitätstechniken - A n w e n d u n g s e r f a h r u n g e n bei der Produktinnovation. In: D i e Betriebswirtschaft 6/1988,777 - 785 V D I - Z W A (Hrsg.): Wertanalyse. Idee - Methode - System. 4. A., VDI-Verlag, Düsseldorf 1991 Vessey, I. and Sravanapudi, A. P.: Evaluation of V e n d o r Products: C A S E - T o o l s as Collaborative S u p p o r t T e c h n o l o g i e s . Unpublished Paper, Penn. State University 1992 V o n k , R.: P r o t o t y p i n g - T h e e f f e c t i v e use of C A S E T e c h n o l o g y . Prentice Hall International, H e m p s t e a d 1990 Wallmüller, E.: Software-Qualitätssicherung in der Praxis. Hanser Verlag, M ü n c h e n / W i e n 1990 Weber, M.: Entscheidungen bei Mehrfachzielen. Verlag Gabler, Wiesbaden 1983 W i l l m e r , H. u n d Balzert, H.: Fallstudie einer industriellen S o f t w a r e - E n t w i c k l u n g . Bibliographisches Institut, M a n n h e i m et al. 1982 W i s c h n e w s k i , E.: M o d e r n e s Projektmanagement - Eine Anleitung zur e f f e k t i v e n U n t e r s t ü t z u n g der Planung, D u r c h f ü h r u n g und Steuerung von Projekten. V i e w e g Verlagsgesellschaft, B r a u n schweig 1991 Wittlage, H.: M e t h o d e n und Techniken praktischer Organisationsarbeit. 2. A., Verlag N e u e Wirtschafts-Briefe, Herne/ Berlin 1986 Wollnik, M.: I m p l e m e n t i e r u n g computergestützter Informationssysteme. Verlag de Gruyter, Berlin et al. 1986 W o o d , J. and Silver, D.: Joint Application Development. 2. Ed., John Wiley & Sons, N e w Y o r k et al. 1995 Y o u r d o n , E. a n d C o n s t a n t i n e , L. L.: Structured D e s i g n . F u n d a m e n t a l s of a D i s c i p l i n e of C o m p u t e r P r o g r a m and S y s t e m s Design. 3. Ed., Prentice Hall, E n g l e w o o d Cliffs/N.J. 1979 Z a n g e m e i s t e r , Ch.: N u t z w e r t a n a l y s e in der Systemtechnik. 4. A., W i t t e m a n n ' s c h e V e r l a g s b u c h handlung, M ü n c h e n 1976 Z a n g e m e i s t e r , Ch.: Systemtechnik. In: Grochla, E. (Hrsg.): H a n d w ö r t e r b u c h der Organisation. 2. A., Poeschel Verlag, Stuttgart 1980, 2190 - 2 2 0 4

Literaturverzeichnis

401

Zangemeister, Ch. und Bomsdorf, E.: Empfindlichkeitsanalyse in der Nutzwertanalyse. In: Zeitschrift für betriebswirtschaftliche Forschung 5/1983, 375 - 397 Zimmermann, W.: Operations Research. Quantitative Methoden zur Entscheidungsvorbereitung. 5. A., Oldenbourg Verlag, München/Wien 1990, 6 - 47 Zur, E.: Strukturierung komplexer Führungsaufgaben und Systemaufbau. In: Spremann, K. und Zur, E. (Hrsg.): Informationstechnologie und strategische Führung. Gabler Verlag, Wiesbaden 1989,81 - 105 Zurmühl, R.: Matrizen und ihre technischen Anwendungen. 4. A., Springer Verlag, Berlin et al. 1964

Schlagwortverzeichnis A B C - A n a l y s e 248; 2 50;384 A b f r a g e s p r a c h e 354 A b h ä n g i g k e i t 207 Ablauf 180; 194 A b l a u f o r g a n i s a t i o n 147; 192; 197 ablauforientierter Ansatz 47 Ablaufsicht 5 2 A b l a u f s t e u e r u n g 257 A b n a h m e t e s t 215; 219 Abstraktion 2 8 3 A b w e i c h u n g 216; 280; 322; 325; 335; 380 A D / C y c l e 68 A d j a z e n z m a t r i x 387; 392 administratives Ziel 23 A D P S 68 Aggregation 117; 165 A g g r e g a t i o n s f u n k t i o n 162 Aktion 91 f. A k t i o n e n d i a g r a m m 116; 196 Aktionsanzeiger 91 Aktionsfolge 9 2 A k t i o n s s p i e l r a u m 241 Aktionsteil 91 A k t i v i e r u n g s f o l g e 111 Aktivierungsregel 127 Aktivität 107f.; 205 Aktivitätenmodell 108; 112 Aktivitätensicht 111 Aktualität 231 f. A k z e p t a n z 261 Alternative 2 6 8 ; 273; 306; 316 alternative V o r g e h e n s w e i s e 3 6 0 Alternativenauswahl 2 7 4 Alternativenbewertung 268; 2 7 4 A m o r t i s a t i o n s r e c h n u n g 158 A n a l y s e 136ff.; 152ff. A n a l y s e k o m p o n e n t e 78 A n a l y s e m e t h o d e 380;387 A n a l y s e p h a s e 92; 149; 179 A n a l y s e z y k l u s 345 f o r m a l e r 347 inhaltlicher 3 5 0 analytische Suche/interaktive S u c h e 181 Änderbarkeit 231; 253; 261 A n f o r d e r u n g 57f.; 63; 149; 177ff.; 230; 248f.; 258; 284ff.; 289ff.; 357 A n f o r d e r u n g s a n a l y s e 69; 246; 2 7 2 ; 283ff. A n f o r d e r u n g s k a t a l o g 246; 248; 2 9 3 ; 2 9 6 A n f o r d e r u n g s s p e z i f i k a t i o n 246; 248; 2 9 6 A n f o r d e r u n g s t e s t 219 A n o r d n u n g s b e z i e h u n g 210; 2 1 3 A n p a s s u n g s f ä h i g k e i t 231; 301 A n p a s s u n g s w a r t u n g 144; 146 Anschaulichkeit 231 Antwortzeit 320; 354; 358 A n w e n d b a r k e i t 54

A n w e n d u n g 136; 281 A n w e n d u n g s a u f g a b e 57 Anwendungsgebiet 186; 306 A n w e n d u n g s s y s t e m 12 Arbeitsablauf 147; 359; 361; 376 Arbeitsablaufkarte 199 Arbeitsanalyse 351 Arbeitsergebnis 83 Arbeitsfortschritt 325 Arbeitshypothese 338 Arbeitslast 301 Arbeitsorganisation 49; 286; 345 Arbeitsphase 148 Arbeitsschritt 119; 140; 163; 271 Arbeitssituation 367 Arbeitstagebuch 375 Arbeitswert 322; 325; 326 Arbeitszeit 377 A S M E - S y m b o l i k 192 Attribut 55; 338; 341; 342; 389; 3 9 0 Attributewert 338; 341; 343; 367 Aufbauorganisation 192; 194; 387 A u f g a b e 11; 15; 16; 18; 86; 141; 242; 244; 248; 332; 333; 339; 346; 351; 364 A u f g a b e n a b g r e n z u n g 84; 87 A u f g a b e n a n a l y s e 21; 23; 286; 371; 372 A u f g a b e n a n f o r d e r u n g 285; 290 A u f g a b e n b e z o g e n h e i t 261 A u f g a b e n f u n k t i o n 268; 273 Aufgabenplanung 2 7 8 Aufgabenstrukturierbarkeit 345 Aufgabensynthese 21; 23 A u f g a b e n s y s t e m 256 A u f g a b e n t r ä g e r 80; 87; 141; 142; 308; 3 3 9 A u f g a b e n t r ä g e r a n f o r d e r u n g 285; 2 9 0 Aufgabentypen 299 Auftraggeber 80; 186; 286 A u f t r a g n e h m e r 80 A u f w a n d 284 Ausbildung 87 Ausbildungsziel 17 Ausfallsicherheit 3 2 0 A u s f ü h r u n g s p l a n u n g 36 Ausgabeblock 103 Ausgabedaten 107 Ausschreibung 296 Auswahlentscheidung 36 Auswahlkriterien 316 Auswirkung 268; 273 Automatisierung 257 Automatisierungsgrad 260 Autor/Gutachter-Zyklus 111 B a l k e n d i a g r a m m 201; 324 Basiskonzept 5 2 B a u m 202 Bedieneranleitung 227

Schlagwortverzeichnis Bedingung 9 I f f . Bedingungsanzeiger 9f. Bedingungskombination 92 Bedingungsteil 91 Befragung 290; 314; 317; 335; 348; 366ff. Belastungsdiagramm 324 Benutzbarkeit 144; 147; 231; 262 Benutzer 85; 2 8 6 Benutzerakzeptanz 57 Benutzerberechtigung 354 Benutzerbeteiligung 85; 88; 286; 336; 338 Benutzerdokumentation 227; 230; 233 Benutzerhandbuch 236 Benutzermitwirkung 338 Benutzerorientierung 274 Benutzerprofil 144 Beobachtung 286; 314; 317; 366ff. Beobachtungsexperiment 314 Beratungskosten 155 Berechnungsexperiment 179 Berichtssystem 354 Berichtstermin 358 Beschäftigungstherapie 332 Beschreibungsmethode 268; 273; 283 Beschreibungsmittel 49; 283 Beschreibungsregel 283 Beteiligter 80 betriebliche Aufgabe 16; 244 betriebliches Informationssystem 14 Betriebsmittel 209 Betriebsmittelkosten 155 Betriebswirtschaftslehre 17 Bewertung 36; 57; 63; 176 Bewertungsphase 149 Bewertungsstrategie 6 0 Beziehung 11; 14; 47; 101; 139; 176; 259; 338; 340; 380; 383 Beziehungszusammenhang 157 Bezugsmodell 227 Bild 192 Bildschirmtext 303 Bildsymbol 185; 190 Bindefunktion 188 Blockdiagramm 200 Botschaft 185; 186 Bottom-up-Suche/Top-down-Suche 181 Bottom-up-Test 221 Brainstorming 308; 309; 310; 311; 312 Brainwriting 309 Brook'sches Gesetz 322 C A R E 68 C A S E - S y s t e m 72; 74 Architektur von 73 geschlossenes 75 mainframe-orientiertes 7 4 offenes 75 PC-orientiertes 74 C A S E - W e r k z e u g 70; 72; 86 Client/Server-Architektur 320 Cluster 64; 138; 140;384 Clusteranalyse 380

403

Computer Support for Cooperative W o r k 80 Computer Supported Cooperative W o r k 80 C P M 205 Critical Path Method 205 C S C W 80 Darstellungsart 291 Darstellungsform 209 Darstellungstechniken 192ff. Datenanalyse 351; 352 Datenanforderung 249 Datenaspekt 132 D a t e n n u ß 99; 107; 108 Daten flußdiagramm 109; 116ff. Datenflußplan 192; 200 Datenkatalog 117; 227 Datenmodell 54; 109; 116 Datenobjekt 118; 119; 120; 141; 142 datenorientierter Ansatz 26; 47 datenorientiertes Erheben 290 Datenquelle 116; 118 Datensenke 116; 118 Datensicht 111 Datensystem 345 Debugging 216 Dekomposition 268 Delphi-Methode 305 Demonstrationsprototyp 60 Designkomponente 78 Detaildiagramm 101; 105 Detaillierungsgrad 341 Detailstudie 39 D F P 192 Diagramm 99; 108; 192; 194; 322; 387 Dialogisierung 257 Dialogisierungsgrad 260 Dialogsystem 73 Dokument 227; 286; 292 Dokumentation 120; 193; 228ff; 246; 293; 336 Dokumentationseinheit 234 Dokumentationskrise 228 Dokumentationsmethoden 227ff. Dokumentationstechnik 234 Dokumentationsverfahren 233 Dokumentationswerkzeug 229; 235 Dokumenteauswertung 371 Dokumentieren 227; 291; 343; 350 Domäne 296; 300 D O M I N O 68 D O O P 47 Durchdringung 296; 297 DurchführbarkeitsStudie 39; 268; 297 Durchgängigkeit 69 Durchlaufzeit 314; 358 Durchsatzrate 320 Dynamik 14 dynamische Methode 158 dynamisches System 13; 15 dynamisches Testen 223 dynamisches Verhalten 130; 135; 179 Easiest-first-Strategie 280; 338; 341

404

Schlagwortverzeichnis

Echtbetrieb 23 E C M A - S y m b o l i k 192 Effektivität 152 Eigenentwicklung 382 E i g n u n g s p r ü f u n g 310; 312 Eindeutigkeit 2 5 3 Eindeutigkeitsprüfung 95 Einfachheit 185 Eingabeblock 103 Eingabedaten 107 Einheitlichkeit 231 Einordnungsschema 299 Einwirkaufgabe 254 Einzel interview 368 E K N 205 Elementarprozeß 116 ELSE-Regel 91 Empfindlichkeitsanalyse 32; 169; 174; 179 empirisches Testen 224 Entscheidung 91 geschlossene 305 o f f e n e 305 Entscheidungsbaum 202; 212 Entscheidungsknoten 212 Entscheidungsmodell 159 Entscheidungsnetz 206 Entscheidungsnetzplan 212 Entscheidungsregel 91 ff.; 97; 162; 167 Entscheidungssituation 92 Entscheidungstabelle 92ff. einfache 93 komplexe 93 Konstruktion 95 unscharfe 97 unvollständige 94 vollständige 94 Entscheidungstabellen-Technik 91 f. Weiterentwicklung der 97 Entscheidungstabellen-Verbund 96 Entscheidungstabellen-Vorübersetzer 92 Entscheidungsunterstützung 176 Entwicklungstest 215 Entwurfsentscheidung 273 Entwurfsinspektion 326 E n t w u r f s m e t h o d e 30; 106 Entwurfsobjekt 273 Entwurfsphase 92; 131; 179 Entwurfsprinzip 128 Entwurfstest 215 Ereignis 127; 131; 205 Ereignisfolge 130 Ereignis graph 2 0 6 Ereignisknotennetz 2 lOf, Ereignisorientierung 174; 181 Ergonomie 296 Erhebung 338 Erhebungsphase 149 Erkennungsexperiment 179 Ermittlung 273 Ermittlungsmodell 158 Erstentwurf 103

evolutionäres Prototyping 62; 242 Experiment 57; 314; 317 experimentelles Prototyping 61 exploratives Prototyping 61; 291 Fachverantwortung 233 Falsifikation 174 Falsifikationsversuch 179 Falsifizieren 349 Falsifizierung 345 Farbassoziation 185 Fehler 215f.; 246; 292 Fehlerart 217 Fehler kor rektur 219 Feh lersystematik 217 Fehlervorgabe 216f. Feinentwurf 103 Feinprojektierung 39; 41; 118 Feinstudie 39f.; 33 Iff.; 355 abteilungsorientierte 360 Aufgaben der 3 3 I f f . Auswerten der 354ff. dualer Charakter der 335 informationsflußorientierte 361 f. kombinierte 339; 346; 363 Methoden und Techniken der 336 Prozeß der 329ff. Vorgehensweise bei der 359ff. Ziel, Aufgaben und Methodik der 331 Fenster 64 FEO-Diagramm 107 Fernkopierer 302 Flußdiagramm 123 Formalisierung 291 Formalziel 22; 69; 147; 244; 257ff.; 264f. Formalzielplanung 257ff. Formular 192 Forschungsbefunde 19; 30; 45; 55; 78; 87; 106; 114; 136; 160; 172; 225; 256; 265; 274; 280; 294; 303; 313; 320; 337 Fortschritts bericht 280 Fragebogen 370 Fragebogenform 370 Fremdbezug 383 Funktion 47; 50; 99ff.; 108; 114; 144ff.; 189; 194f.; 219; 248ff. Funktionalität 57; 61; 74; 354; 355 Funktionenbaum 195 Funktionendiagramm 196 Funktionsanalyse 146 Funktionsanforderung 248f. Funktionsart 146 Funktionsbaum 144; 147 Funktionsbereich 144; 148 Funktionsbeschreibung 144 Funktionsbündel 144 Funktionseinheit 107 Funktionsgliederung 147 Funktionsklasse 146 Funktionskosten 144 funktionsorientierter Ansatz 26; 4 7 Funktionssatz 144

Schlagwortverzeichnis F u n k t i o n s s t a m m b a u m 144 Funktionstest 2 1 5 Funktionsumfang 354 Funktionswertziel 148 geblockter Text 197 G e b r a u c h s g ü t e 259 G e m e i n k o s t e n 156 Genauigkeit 374 Generalisierung 50 Generierung 73; 2 7 3 G E R T 205 Geschüftsvorfall 53 Gestaltungsprinzip 187ff. Gestaltungsvariable 189 Gleichartigkeit 231 Gleichgewicht 116; 121 G P S S 174; 182 Grafik 185; 192 Grafikprogramm 73 Graph 11; 108; 202; 205f.; 209 Graphentheorie 206 G r o b p l a n u n g 279 Grobprojektierung 39; 41; 118 Grobstudie 39; 2 4 3 G r o u p w a r e 80; 2 9 6 G r u n d f u n k t i o n 116; I20f. G r u n d k o n z e p t i o n 39; 42; 146; 153; 241; 243f.; 2 6 8 f f . ; 284; 297; 307; 333; 340; 346; 355f. angepaßte 355 Anpassen der 334 E n t w e r f e n der 2 6 8 f f . Grundsatz 32; 341 Grundsatzkritik 3 5 0 G r u p p e n a r b e i t 88 G r u p p e n f r a g e b o g e n 370 Gruppeninterview 3 6 8 G r u p p e n m e r k m a l 82 Gruppenpräsentation 188 G r u p p e n s i t z u n g 308 Güte 2 5 8 Handlungs spiel räum 29; 241ff.; 269; 3 0 6 Hardest-first-Strategie 2 8 0 Hardware-Architektur 73 Häufigkeit 250; 374; 384 H a u p t f u n k t i o n 147; 250 Heuristik 175; 241; 2 4 6 Hierarchie 32; 120 Hierarchie-Ebene 101 H i e r a r c h i e d i a g r a m m lOOf. hierarchisches Zerlegen 110 Hierarchy plus Input-Process-Output 9 9 f f . Hilfe-System 227 H I P O 100 HIPO-Arbeitsblatt 99; 105 H I P O - D i a g r a m m 100 H I P O - P a k e t 99; 100; 103 horizontales Prototyping 63 H y p e r m e d i a - S y s t e m 235 Hypertext-System 2 2 7 Hypothese 338; 345; 349

405

I C A S E 68 I C O M - C o d e 107 I C O M - N o t a t i o n 109 I d e e n b e w e r t u n g 31 l f . Ideenfindung 312 Ideengenerierung 3 lOff. Identifikationsexperiment 179 Identifizierbarkeit 2 3 2 Identifizierungsfunktion 352 I E F 68; 77 I m p l e m e n t i e r u n g 57; 103 I m p l e m e n t i e r u n g s p h a s e 92 Individualfragebogen 370 Individualziel 2 2 Informatik 17 Informatik-Strategie 85 Information 12; 228; 272 I n f o r m a t i o n Engineering 77 Information Engineering Facility 7 7 Information M o d e l l i n g 123 Informations- und K o m m u n i k a t i o n s p r o z e ß 299 Informationsangebot 2 4 8 Informationsbedarf 2 8 3 ; 287; 290; 358 I n f o r m a t i o n s b e d ü r f n i s 283; 287; 2 9 0 I n f o r m a t i o n s b e z i e h u n g 359; 363 I n f o r m a t i o n s f l u ß 85; 359ff. I n f o r m a t i o n s f u n k t i o n 21 Informationsgehalt 2 6 9 Informationsgewinnung 272 Informationsinfrastruktur 21 I n f o r m a t i o n s m a n a g e m e n t 29 I n f o r m a t i o n s n a c h f r a g e 248; 250; 283; 2 8 7 Informationssystem 12; 51 Informationssystem-Architektur 52 In f o r m a t i o n s v e r a r b e i t u n g s k o m p l e x 339; 3 4 3 ; 359; 361; 364 Informationsverhalten 283; 2 9 0 Inkonsistenz 57 inkrementelle Strategie 220 inkrementelle S y s t e m p l a n u n g 62 Innovation 257 Innovationsgrad 2 6 0 Inside-out-Ansatz 2 6 Installierung 39; 41 Instanz 50; 54; 127; 128 Instanzvariable 50 Integration 72; 257; 3 5 9 Integrationsgrad 260; 364 Integrationstest 2 2 0 Interaktion 384 Interaktionsanalyse 3 8 4 Intervallskala 166 Interview 368 I n t e r v i e w f o r m 368 I P O - D i a g r a m m 103 Istzustand 117; 145; 241; 3 3 l f . ; 335; 3 4 6 ; 355 Analysieren des 345ff. Erfassen d e s 338ff.

406

Schlagwortverzeichnis

Istzustandsanalyse 118; 331; 334ff.; 339; 346; 3 6 3 ; 3 8 0 M e t h o d e n der 380ff. Istzustandsbeschreibung 338; 343 Istzustandserfassung 118; 331; 334ff.; 339; 363; 3 6 6 M e t h o d e n der 366ff. Is t z u s t a n d s e r h e b u n g 331; 3 6 6 Istzustandsoptimierung 3 3 1 ; 334 istzustandsorientierter Ansatz 26; 331 ff. Istzustands Orientierung 3 5 5 Istzustandsuntersuchung 39; 331; 359 Iteration 174 IuK-Projekt 251 IuK-System 12 I u K - T e c h n o l o g i e 15 Kalibrierung 174 Kanal 128; 129 Kante 11; 14 Kapazitätsanalyse 2 0 9 Kapazitätsausgleich 209 Kapazitätsbedarf 2 0 9 Kapazitätsbelastungsplan 212 Kapazitätsplanung 2 0 9 ; 3 2 4 kardinale Skala 140; 166 Kausalität 127 Kehrmatrix 138 Kennzahl 152; 157 K e r n a u f g a b e 254 Kernprodukt 44 Kettenmodell 7 2 Klasse 5 0 Klassenhierarchie 51 Klassifizierungsfunktion 352 Knoten 11; 133; 205 K n o t e n n u m m e r 110 Ko e f f i z i e n t 138 kognitiv 185 kombinatorische S u c h e / m u t a t i v e Suche 181 K o m m u n i k a t i o n 12; 44; 80; 193; 387 f o r m a l e 387 i n f o r m a l e 387 K o m m u n i k a t i o n s a n a l y s e 336; 351; 387 M e t h o d e n der 3 8 7 f f . K o m m u n i k a t i o n s a r t 387 K o m m u n i k a t i o n s b e z i e h u n g 388 K o m m u n i k a t i o n s d i a g r a m m 390 Kommunikationsdreieck 390 Kommunikationsmatrix 392 Kommunikationsmittel 187,219 K o m m u n i k a t i o n s n e t z 393 K o m m u n i k a t i o n s s p i n n e 390f. Kommunikationssystem 345 Kommunikationstabelle 389 K o m p e t e n z 80; 84 ; 86 K o m p l e x i t ä t 11; 32f.; 269; 277; 342 Kompliziertheit 11; 269; 3 4 2 Komponententest 220 K o n f e r e n z - I n t e r v i e w - T e c h n i k 368 konsensorientierter A n s a t z 85 K o n s e q u e n z 314

K o n s e q u e n z a n a l y s e 174; 179; 246; 314ff. Konsistenz 2 4 8 Konsolidierung 96 K o n t e x t d i a g r a m m 116; 120 Kontrolle 322; 326; 3 3 2 Kontrollfluß 107 Kontrollrechnung 157 Konvention 118 Konzeptanalyse 36 Konzeptentwurf 36 Kooperation 39; 43; 86; 144; 257; 380; 387 Kooperationsgrad 260 Kooperationspotential 388 Koordination 39; 44; 380; 387f. Koordinator 85 K o o r d i n i e r u n g s a u f g a b e 188 Korrektheit 2 5 3 Korrelation 3 8 0 Kosten 63; 148; 1 5 2 f . ; 2 0 8 Kosten- und Leistungssituation 153 K o s t e n / N u t z e n - A n a l y s e 152 Kosten/Nutzen-Technik 169 K o s t e n a b w e i c h u n g 327 Kostenanalyse 148; 2 0 8 Kosten art 155 Kostenplanung 208; 279 Kosten situation 153 Kostenstruktur 155 Kostenvergleichsrechnung 158; 160 Kostenziel 259 Kreativität 39; 44; 3 0 5 f . ; 3 1 3 Kreativitätshemmnis 307 Kreativitätsphase 149 Kreativitätstechniken 144f.; 246; 305ff. Kriteriengewicht 162; 166 Kriterium 162; 170; 292f. kritischer W e g 205; 2 0 8 Kybernetik 32 kybernetisches Prinzip 33 Laborexperi ment 318 Labormuster 60 Laborstudie 301 Laufzeit 9 2 Leistung 152; 248ff.; 2 9 6 Leistungsabweichung 327 L e i s t u n g s a n f o r d e r u n g 248ff. Leistungsfähigkeit 354f. Leistungssituation 153 Leislungsspezifikation 296 Leistungstest 2 1 5 Leistungsziel 2 5 9 L e n k u n g s a u s s c h u ß 80f.; 276 Lernkurve 303 Leseleitzeichen 185; 190 logisches Testen 223 logisches D a t e n f l u ß d i a g r a m m 116 lokale U m g e b u n g 130 Machbarkeitsstudie 39; 268 Maestro II 68 Majoritätsregel 168 M a r k e 127; 130

Schlagwortverzeichnis Markierung 130 Markierungssituation 131 Maßnahmenkatalog 355 Maßstabtätigkeit 374ff. MAT-System 11 Matrix 138ff.; 314; 387 Matrix-Projektorganisation 278 Matrixanalyse 138ff. 357 Matrizenmultiplikation 141 Matrizenoperation 140 Mechanismus 107 Medium 189 Mehrfachverwendung 48 Mehrprojektplanung 212 Meilenstein 35; 152f. Mengengerüst 353 Messen 374 Meßpunkt 374 Messung 166 Meßwert 178 Metaplan-Technik 380; 384 Methode 18; 21; 29; 47; 52; 55; 69f.; 145; 305; 242; 245; 249ff.; 285; 289; 291 ff.; 316; 323; 332; 367; 381; 388 Methode des morphologischen Kastens 309 des sukzessiven Vergleichs 166 6.3.5. 305 Methoden der Istzustandsanalyse 380ff. der Istzustandserfassung 366ff. der Kommunikationsanalyse 387ff. der Zeiterfassung 374ff. des Projektmanagements 322ff. Methodenanalyse 351 Methodenanforderung 249 Methodenauswahl 318 Methodenbeziehung 359 Methodenkenntnis 337 methodenorientiertes Erheben 290 Methodensystem 345 Methoden vergleich 55 Methoden verweis 19 Methodenverzeichnis 50 Methodik 21 ff.; 69; 145; 340 Methodik-Mix 28 Methodikansätze 25; 44 Methodikstreit 25 Methodologie 21 Metra Potential Method 205 M M H 374 M M Z 374 M n e m o 138 Modell 21; 28; 51; 175 konzeptuelles 2 6 logisches 27; 123; 145; 331; 357 physisches 27; 39; 42; 145; 331 f.; 357 stochastisches 175 Modell-Prinzip 33 Modellbildung 110; 127 Modellieren 119; 174

Modellierung 51; 127; 131 Modellierungskonzept 123 Modellkonzept 108 Modellobjekt 4 9 Modelltyp 32; 157 Moderator 189; 308 Modularität 225; 257 M P M 205 M T B F 257 M T B M 257 M T T R 257 Multimoment-Häufigkeits-Zähl verfahren 377 Multimoment-Zeitmeßverfahren 377 Multimomentstudie 377f. Muster 57 N-S-Diagramm 192 Nachfolger 205 Nassi-Shneiderman-Diagramm 192 Nebenbedingung 241; 245 Nebenfunktion 147 Nebenläufigkeit 127 Netz 127; 130; 194 Netzkosten 155 Netzplan 206; 209; 213; 322ff. Netzplantechnik 202; 205ff.; 322f. Neue Technologie 296 nominale Skala 139; 165 Norm 19; 82 normative Aussage 22 Normierung 225 Notation 56; 192; 213 Notfallplanung 279 NPT205 Nummernaufbau 352 Nummern vergäbe 353 Nutzeffekt 78; 160 Nutzen 63; 152ff. direkt monetär meßbarer 156 indirekt monetär meßbarer 156 nicht monetär meßbare 156 Nutzenfaktor 156 Nutzenstruktur 156 Nutzungsziel 259 Nutzwert 152; 162f.; 172 Nutzwertanalyse 162ff.; 246; 314f.; 317 Oberklasse 50 Objekt 47ff.; 54; 176; 229; 248; 371 Objektentwurf 53 Objektklasse 47; 55 Objektmenge 248 Objektmodell 53f. Objektmodellierung 53f. objektorientierte Systemplanung 47ff. objektorientierte Programmierung 50 objektorientierter Ansatz 27; 49 Objektorientierung 47ff. Objektprinzip 49 Objektstruktur 47 Objektsystem 47f. Objektsystementwurf 53

407

408

Schlagwortverzeichnis

O b j e k t t y p 248 Objekttypen-Ansatz 26 o f f e n e s System 13 OOA47 O O D 4 7 ; 56 O O S D 47 Operatoranleitung 227 Operatorhandbuch 230 O p t i m i e r e n 354f. O p t i m i e r u n g s e x p e r i m e n t 179 O p t i m i e r u n g s m a ß n a h m e 354 O R 152 ordinale Skala 139; 166 O r d n u n g s r a h m e n 23; 4 2 O r g a n i g r a m m 99; 195; 359f. Organisation 2 8 6 O r g a n i s a t i o n s a n w e i s u n g e n 194 O r g a n i s a t i o n s h a n d b u c h 195 O r g a n i s a t i o n s p l a n u n g 277 Orga n i s a t i o n s s p i e l r a u m 345 Organisationsstruktur 387 Organisationsziel 22; 283 O s b o r n - V e r f r e m d u n g 310f. Ou ts i d e - i n - A n s a t z 2 6 P A C E 132 P a r a d i g m a 25; 28 Parallelität 127 P a r a m e t e r 169 p e r i o d i s c h e E i n b l i c k n a h m e 326 P e r s o n a l e i n s a t z p l a n u n g 279 P e r s o n a l i n f o r m a t i o n s s y s t e m 112; 2 5 4 Personalkapazität 85 Personalkosten 155 P e r s o n a l p l a n u n g 278 Personalqualifikation 85 PERT 205 Petri-Netz-Theorie 128 Petri-Netze 127 ff. P f l i c h t e n h e f t 128 Phasen gliederung 2 3 4 P h a s e n m o d e l l 18; 23; 2 6 P h a s e n s c h e m a 40; 4 4 ; 58; 70 Pilotprojekt 2 9 6 Pilotsystem 6 0 P l a n u n g 13 P l a n u n g s e r g e b n i s 30; 178 P l a n u n g s g r u p p e 80 P l a n u n g s k o m p o n e n t e 78 P l a n u n g s m e t h o d i k 28 Planungs objekt 276 P l a n u n g s p r o z e ß 44; 2 2 9 P l a n u n g s r e c h n u n g 157 Planungsziel 29; 39; 81; 147; 186; 241 ff.; 2 4 9 ; 2 6 8 ; 273; 286; 3 1 6 ; 357 Polaritätsprofil 202 Polarkoordinaten 203 Prädikat/Transitionsnetz 127 P r ä f e r e n z 162 P r ä f e r e n z o r d n u n g 162 P r ä g n a n z 185 P r ä m i s s e 169

Präsentationssituation 189 Präsentationstechniken 185ff. Präsentationsziel 189 Predict C a s e 68 Prinzip 32f.; 107; 187; 368 Prinzip der hierarchischen Strukturierung 33 der Neuheit 187 der Partnerbezogenheit 187 des Schwarzen Kastens 33; 3 3 8 Prinzipien der Systemtechnik 33 Problem 305 Problemanalyse 345ff. Problem definition 36; 309ff. Problemlösen 305; 309 Problemlösungsstufe 35 Produktionsplanung und -Steuerung 177 Produktionsregel 97 produktives I n f o r m a t i o n s s y s t e m 23; 242; 332 Produktivität 48; 69; 75; 152; 2 6 2 P r o d u k t m a n a g e r 80; 275; 2 7 6 Produktnetz 131 produktorientierte Testfallermittlung 223 Produktqualität 2 4 I f f . Prognose 32; 152 Prognoseungewißheit 169 Program Evaluation and Review T e c h n i q u e 205 P r o g r a m m 224 Programmablaufplan 200 P r o g r a m m i e r u n g 106 P r o g r a m m s t u d i e 34 Projekt 13; 21; 205f.; 275 Projektablauf 178 Projektauftrag 340 Projektbezeichnung 86 Projektbibliothek 75; 3 2 2 Projektdokumentation 322f. Projektergebnis 186 Projektfortschritt 178 Projektgruppe 80ff.; 186; 275 Projekthandbuch 275 Projektion 283 Projektkoordinator 2 7 5 Projektlaufzeit 324 Projektleiter 81; 245; 275f. P r o j e k t m a n a g e m e n t 42; 75; 275; 322ff. Projektorganisation 80; 81; 245; 275, 277ff. Projektplan 2 8 0 Projektplanung 207; 244; 275ff. Projektportfolio 241; 2 4 3 Projektqualität 326 Projektrisiko 322 Projektstandard 245 Projektsteuerung 275; 2 8 0 Projektteam 80; 2 7 5 P r o j e k t ü b e r w a c h u n g 275; 2 8 0 Projektvoraussetzung 2 0 6 Projektziel 39; 275f. Projektzustand 324

Schlagwortverzeichnis Protokoll 358 Prototyp 57ff. Bewerten des 60 unvollständiger 60 vollständiger 6 0 W e g w e r f - 60; 6 2 wiederverwendbarer 60; 62 prototyp-orientierter Ansatz 28 Prototyping 57ff. 222; 291 Arten des 61 evolutionäres 62; 242 experimentelles 61 exploratives 61; 291 horizontales 63 vertikales 63 prototyping-orientiertes P h a s e n s c h e m a 58 Protyping-Werkzeug 64 Prototyping-Zyklus 57; 63 prototyporientierte S y s t e m p l a n u n g 57ff. Prozeß 42; 102; 116ff.; 233; 257; 334 der S y s t e m p l a n u n g 39 elementarer 131 g r u p p e n d y n a m i s c h e r 308 kooperativer 244; 249; 258 zyklischer 244; 249; 258 Prozeßcharakter des P h a s e n s c h e m a s 4 2 Prozeßkette 159 Prozeßmodell 117 prozeß orientier ter A n s a t z 4 7 Prozeßorientierung 42; 174; 181 Prozeßqualität 241; 259; 262f. Prozeßsicht 359; 3 6 4 Prüfen 252; 352; 3 8 0 P r ü f f r a g e 380 Prüfkriterium 253 Prüfliste 32; 323; 381; 385 allgemein v e r w e n d b a r e 382 untersuchungsbereichspezifische 3 8 2 Prüfmatrix 354; 357; 383 Pseudo-Code 192 Puffer 205 Pufferzeit 208 Qualifikation 80ff.; 87; 347 Qualität 69; 75; 2 1 6 ; 227; 231 ; 241 ; 2 5 7 ; 258; 326 Qualitätsanforderung 250; 287; 292 Qualitätsforderung 59 Qualitätsmodell 2 3 2 Qualitätssicherung 57ff.; 216; 225; 283; 324 R a h m e n a n f o r d e r u n g 289 R a h m e n k o n z e p t 163 Rahmenziel 259 Rang 359; 371 Rangfolge 384 R a n g o r d n u n g s s u m m e n r e g e l 168; 172 Rangreihe 166 Rating-Methode 3 1 4 Rationalisieren 3 5 4 Rationalisierung 144; 146 Rationali sierungs potential 148 Real T i m e Analysis 123

409

Realisierbarkeit 2 7 6 Realisierungsphase 150 Realisierungsstrategie 2 8 0 Rechtzeitigkeit 231 R e d o k u m e n t a t i o n 233 RedokumentationsWerkzeug 2 3 6 R e d u n d a n z 91; 185 Reengineering 233 Referenzmodell 74; 227 Regel 104; 291 der befriedigenden L ö s u n g 167 der B e f r i e d i g u n g der großen Zahl 167 der lexikografischen O r d n u n g 167 Regelung 32 Regressionsanalyse 32 R e i h e n f o l g e 93; 280 reine Projektorganisation 277 Relationennetz 131 Rentabilitätsrechnung 158 Repository 68; 2 2 7 Restrukturierung 68 Revision 227 Risiko 3 2 2 Rolle 185 Rollendifferential 82 Rollenverteilung 88 demokratische 188 hierarchische 188 Routinecharakter 337 R ü c k k o p p l u n g 21; 23; 42; 59; 180; 268; 2 6 9 ; 310; 312; 3 5 5 Sachcharakter 359; 372 Sachgliederung 2 3 4 Sachkosten 155 Sachmittel 338 Sachmittelplanung 279 Sachziel 22; 147; 241; 244; 249; 2 5 1 ; 252; 289 Festlegen 248ff. Sachziel planung 248ff; 285 S A D T - E i n h e i t 109 S A D T - N o t a t i o n 109 Sammelknoten 205 Schaltregel 127; 131; 135 Schaubild 192 S c h e i n v o r g a n g 205; 2 1 0 Schichtenmodell 57; 6 3 Schleife 9 6 Schlußfolgern 4 7 S c h l u ß f o l g e r u n g 78 Schnittstelle 29; 117; 241 ff.; 249; 250ff. Schnittstellenanforderung 2 5 0 ; 2 8 6 Schriftart 185 schrittweise V e r f e i n e r u n g 100; 105; 132; 269 S c h w ä c h e 152; 335f.; 338; 339; 3 4 6 ; 350; 357; 381 Schwächesymptom 380 Schwachstelle 152; 320; 338 Selbstaufschreibung 366; 370; 374f. semantische Objektmodellierung 53

410

Schlagwortverzeichnis

semantisches Datenmodell 54 semantisches Objektmodell 53 Sender 387 Sensitivitätsanalyse 174 Sequentialisierung 107 SERM 47 Sicherheit 262 Sicherheitsanalyse 351 Sicherungssystem 345 Sicht 110 S I M A N 182 Simon-Regel 167 S I M S C R I P T 182 S I M U L A 182 Simulation 174ff.; 291; 314; 317 Simulationsexperiment 345 Simulationsmodell 174; 176 Simulationsregel 127 Simulationssprache 181 Simulationsstudie 180 Simultandokumentation 232 Sinnbild 185 Situationsanalyse 345; 347 Skala 138; 139 Skalcnniveau 140 Skalieren 138 Software-Entwicklung 100 Sollzustand 145; 241; 331 f.; 346 sollzustandsorientierter Ansatz 26; 331; 333 S O M 47 Soziogramm 196 Speicheraufgabe 255 Speicherschreibmaschine 302 Spezialisierung 50 Spezifikation 57; 252; 264 Spezifizieren 283 Spieldaten 222 Spontandefinition 309; 311 S Q L 174 SQLBench 182 Stab 275 Stabilitätsanalyse 179 Stabs-Projektorganisation 277 Stabsstelle 275 Standard 241 Standardisierung 106; 227 Stärke 335f.; 338f.; 346; 350; 381 Stärken-/Schwächen-Katalog 331; 334; 350; 355 Stärkesymptom 380 Stelle 194 Stellenbeschreibung 86; 194 Stellvertretung 86 Sternmodel) 72 Steuerfluß 107f.; 111 Steuerflußdiagramm 123 Steuerung 32; 322 Steuerungsaktivität 107 Steuerungsdaten 107 Stichprobe 374 Stichprobenverfahren 377

Störung 185; 186 strategische Planung 81 strategische Testplanung 218 Streuknoten 205 Structured Analysis and Design Technique 107ff. Struktogramm 105; 200f. Struktur 17; 108; 138f.; 179; 185; 219; 291 Strukturanalyse 207 Struktureinheit 339; 343; 359f.; 364 Strukturierbarkeit 283 strukturierte Analyse 116f. strukturierte Systemanalyse 117 strukturiertes Gruppengespräch 326 Strukturiertheit 225; 231 Strukturorganisation 387 Strukturplanung 207; 212 Stufenkonzept 303 Subklasse 50 Suche 181 Suchstrategie 181 Symbol 118; 192 S y m p t o m 345; 349; 380f. Symptom/Ursache-Beziehung 380; 383 Symptomumfeld 349 Synektik 309 Syntax 92 System vorbestimmter Zeiten 374 Systemabgrenzung 341 Systemanalyse 40 Systemanalytiker 80 Systemansatz 25; 37 Systemauslegung 176 Systembetrieb 35; 230 Systemdokumentation 229 Systemeinführung 35; 39 Systementwicklung 39f.; 117 Systementwurf 39; 177; 332 Systemgrenze 119; 338ff. Systemhauptstudie 35 Systemimplementierung 39 Systemkomponente 128 aktive 127 passive 127 Systemkonzept 268f.; 273; 307 alternatives 273 optimales 316 Systemnetz 131 Systemphase 34 Systemplaner 80;84; 286 Systemplanung Aufgabenträger der 80 inkrementelle 62 objektorientierte 47 Phasenschema der 40 prototyporientierte 57 Prozeß der 39 Systemtechnik 32ff. systemtechnische Planungsmethodik 33 Systemumgebung 293 Systemverantwortung 233

Schlagwortverzeichnis Systemvorstudie 35 Systemwechsel 35 Systemzwang 290 Szenario-Technik 3 0 5 Tabelle 192; 3 8 7 Tätigkeit 323; 374f. Tätigkeitsbericht 3 7 6 Tätigkeitsdauer 376 Tätigkeitskatalog 3 7 4 f f . Technik 18; 29; 2 4 5 Technikanalyse 2 4 6 ; 272; 296ff. Technikbedarf 177 Techniksystem 296f.; 318 Techniktyp 2 9 6 ; 302 Technologie 11 Teilaufgabe 2 1 8 Teilnutzen 162 Teilplanung 2 0 7 Teilsystem 32; 112; 359; 362 Terminplanung 2 7 9 Terminziel 2 5 9 Test 215 Abnahmetest 215; 219 Anforderungstest 219 Bottom-up- 221 Entwicklungstest 215 Entwurfstest 2 1 5 Funktionstest 2 1 5 Integrationstest 2 2 0 Komponententest 220 Leistungstest 2 1 5 repräsentativer 223 schadensausmaß-orientierter 223 schwachstellen-orientierter 223 Top-down- 2 2 0 Testabdeckungsgrad 215 Testart 222 Testaufwand 215f. Testausführung 218; 223 Testauswertung 2 1 8 Testbarkeit 2 6 2 Testberater 2 1 8 Testbericht 2 1 8 Testdaten 215; 221 Testdokumentation 219; 227 Testdurchführung 218 Testen 216ff.; 224; 345; 349 empirisches 2 2 4 statisches 2 2 3 Test fall 221 Testfallermittlung 2 2 2 aufgabenorientierte 222 Testfall matrix 222 Testgrundsatz 2 1 8 Testkontrolle 2 1 9 Testlauf 222 Testling 215 Testmethode 2 1 5 f f . Testobjekt 2 1 5 ; 2 1 9 Testplan 218 Testplanung 2 1 8

Testprotokoll 218 Teststrategie 2 2 0 Testsystem 215 Testtreiber 215 Testumgebung 2 2 0 Testvorbereitung 218 Testwerkzeug 2 1 5 Textverarbeitungssystem 235 Top-down-Strategie 4 2 Top-down-Test 2 2 0 totale Suche/partielle Suche 181 Transaktion 174 Transaktionsorientierung 174 Transition 127 Transitionsregel 127 Transportsystem 345; 388 Übersichtlichkeit 231 Übersichtsdiagramm 101 Übersystem 32 Übertragbarkeit 262 Überwachung 322 Unschärfe-Theorie 91 Unsicherheit 153 Unterklasse 50 Unternehmensforschung 152 unvollständiger Prototyp 60 Ursache 345; 348; 380; 384 Ursachen-AVirkungsanalyse 215; 219 Validierung 68; 217; 283; 2 8 4 Validität 68; 174 Variable 127; 176 Variante 140 Vater-Sohn-Beziehung 121 Veränderung 349; 356 Verarbeitungsblock 103f. Verarbeitungsfolge 101 verbale Rasterdarstellung 197 Vereinbarung 310; 312 Vererbung 48; 50f. einfache 51 multiple 51 Verfahrenskritik 350 Verfeinerung 268 V e r f r e m d u n g 31 Off. Verfügbarkeit 262; 281 Verhalten 176f.; 342; 384 Verhaltensmotiv 82 Verhaltensregel 310 Verhaltensweise 145 Verhältnisskala 166 Verifikation 174; 283 Verifizieren 289; 292; 301; 3 8 0 Verifizierung 68; 217; 283 Verknüpfung 98 Vermögenswertmethode 158 Verrichtung 359; 371 Verrichtungsprinzip 4 9 Verschachtelung 96 Verständlichkeit 219; 253; 2 6 3 vertikales Prototyping 63 Verwaltung 13

412

Schlagwortverzeichnis

Verzweigung 96 Videobeobachtung 366; 369; 384 Visualisierungstechnik 189 VKN205 vollständiger Prototyp 60 Vollständigkeit 121; 231; 248; 252 Vollständigkeitsprüfung 96 Vorbereitungsphase 148 Vorgang 54; 205; 207 Vorgänger 205 Vorgangsbearbeitungssystem 314 Vorgangsdauer 208 Vorgangs graph 2 0 6 Vorgangsknotennetz 21 Of. Vorgangsmodellierung 54 Vorgangsobjekttyp 54 Vorgangspfeilnetz 210 vorgegebene Arbeitssituation 367 Vorgehensmodell 44; 56; 69f. Vorgehensweise 23; 52; 140; 163; 193; 288; 298; 315; 359 Vorstudie 39ff.; 206; 241 ff. Aufgaben der 241 ff. Methoden und Techniken der 283 Prozeß der 239ff. Ziel, A u f g a b e n und Methodik der 241 Vortrag 187 Vortragstechnik 187 Voruntersuchung 39 Vorwärtsdokumentation 232 Vorzugs-/Häufigkeitsregel 168 VPN 205 W-Technik 309; 311 w a h r g e n o m m e n e Arbeitssituation 367 Wahrscheinlichkeit 211 Walkthrough 99 Waren Wirtschaftssystem 182 Wart barkeit 259 Wartung 57; 2 3 3 Wartungsziel 259 Wech selb eziehung 83 Wegwerf-Prototyp 60; 62 W e r k z e u g 29; 68ff.; 117; 132; 181; 212; 224; 242; 293 für Gruppenarbeit 86 Werkzeugklasse 71 Werkzeugunterstützung 69; 76 Auswirkung der 80ff. der Systemplanung 68ff. Wert 144; 145 Wertanalyse 144ff.; 246 Wertanalyse-Arbeitsplan 144; 148; 150 Wertgestaltung 145 Wertkategorie 165 Wertsynthese 167f.; 172 Wertziel 144; 147f. Wertziel-Analyse 148 Widerspruch 91 Widersprüchlichkeit 57; 232 Widerspruchsfreiheit 248; 252

wiederverwendbarer Prototyp 60; 6 2 Wiederverwendbarkeit 51 Wiederverwendung 233 Wirklichkeit 51; 176; 332 Wirksamkeit 152; 263 Wirtschaft 13 Wirtschaftlichkeit 153; 232; 263 Wirtschaftlichkeitsanalyse 152ff.; 246; 375 Wirtschaftlichkeitsmodell 159 Wirtschaftlichkeitsrechnung 154; 157 Wissenschaftsdisziplin 11; 14ff. Zeit/Kosten/Fortschritts-Diagramm 325 Zeitanalyse 208 Zeitbedarf 374f. Zeiterfassung 170; 374ff. Methoden der 374ff. Zeitgerüst 336 Zeitmechanismus 177 Zeitmeßgerät 375 Zeitmessung 374; 378 Zeitorientierung 174 Zeitplanung 206ff.; 278 Zerlegung 11; 96; 100; 120; 144;163; 172; 268 Zerlegungsdiagramm 195 Ziel 18; 21; 162; 242; 332f. Zielausmaß 21; 265 Zielbeziehung 252; 263; 265 idealtypische 252 Zieldimension 292 Zielerreichung 263; 265; 3 1 6 Ausmaß der 162; 314 Zielerreichungsgrad 162; 314 Zielertrag 162; 165; 170; 274; 314f. Zielertragsmatrix 162; 165; 170 Zielertragswahrscheinlichkeit 169 Zielfunktion 168 Zielgewicht 172 Zielhierarchie 162 Zielindifferenz 263 Zielinhalt 21; 251; 260; 264f.; 273 Zielkomplementarität 263 Zielkonflikt 263 Zielkriterium 162; 165 Zielmaßstab 21 Zielplanung 278 Zielsystem 21; 22; 162f.; 170 Zielwert 162; 165; 171 kardinal skalierter 168 nominal skalierter 167 ordinal skalierter 168 Zielwertmatrix 162; 165; 172 Zinssatzmethode 158 Zugriffsberechtigung 142; 354 Zustand 11; 131; 176 Zustands-/Funktionsdiagramm 102 Zustandsanalyse 36 Zustandsübergangsdiagramm 123 Zuverlässigkeit 263 Zyklus 202