Management von Informatik-Projekten [Reprint 2018 ed.] 9783486792409, 9783486240467

Citation preview

Management von Informatik-Proj ekten Von

Dipl.-Ing. Dr. rer. pol. Lutz J. Heinrich o. Univ.-Professor für Betriebswirtschaftslehre und Wirtschaftsinformatik an der Universität Linz

R. Oldenbourg Verlag München Wien

Die Deutsche Bibliothek - CIP-Einheitsaufnahme Heinrich, Lutz J.: Management von Informatik-Projekten / von Lutz J. Heinrich - München ; Wien : Oldenbourg, 1997 ISBN 3-486-24046-3

© 1997 R. Oldenbourg Verlag Rosenheimer Straße 145, D-81671 München Telefon: (089) 45051-0, Internet: http://www.oldenbourg.de 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. Gedruckt auf säure- und chlorfreiem Papier Gesamtherstellung: R. Oldenbourg Graphische Betriebe GmbH, München ISBN 3-486-24046-3

Vorwort Grundlegende Veränderungen des Studienplans für das Studium der Wirtschaftsinformatik haben den Autor dazu veranlaßt, eine einschlägige Lehrunterlage für die Lehrveranstaltungen vorzulegen, die sich schwerpunktmäßig mit dem Management von Projekten befassen, deren Gegenstand die Konstruktion und Rekonstruktion von Informationssystemen ist. Dies war implizit auch Gegenstand der bereits in 7. Auflage ( B a n d 1) bzw. in 5. Auflage ( B a n d 2) erschienenen Lehrbücher "Systemplanung", sodaß mehrere Lerneinheiten - insbesondere von Band 1 - in dieses Lehrbuch übernommen werden konnten. S i e wurden vollständig überarbeitet, ergänzt und aktualisiert. Der spezifischen T h e m a t i k dieses Lehrbuchs entsprechend, wurden zahlreiche Lerneinheiten hinzugefügt, die in den bisher veröffentlichten Lehrbüchern des Autors nicht enthalten sind. V e r w e i s e auf andere, in dieses Lehrbuch nicht ü b e r n o m m e n e Lerneinheiten wurden beibehalten, um den Studierenden die Möglichkeit zu geben, ihr Wissen in dem Stoffgebiet zu vertiefen, in dem der Gegenstand von typischen Informatik-Projekten näher erläutert wird. Die Verweise beziehen sich vor allem auf Lerneinheiten, die in den beiden Bänden "Systemplanung", in wenigen Fällen auch a u f Lerneinheiten, die in dem B u c h "Informationsmanagement" (5. Auflage 1996) veröffentlicht sind. Unter "Management von Informatik-Projekten" werden die Aufgaben, Methoden, T e c h n i k e n und W e r k z e u g e verstanden, die zur Führung von Informatik-Proj e k t e n bearbeitet werden müssen bzw. diese unterstützen oder erst ermöglichen. "Führung" meint dabei Planung, Überwachung und Steuerung. Informatik-Projekte sind Projekte, deren Objekt oder Gegenstand Informatik-Mittel sind, die beschafft, hergestellt, evaluiert, saniert, migriert usw. werden sollen. "InformatikMittel" wird dabei sehr weit gefaßt, indem alles darunter verstanden wird, was Mittel zur Befriedigung von Informationsnachfrage in Organisationen der Wirtschaft und Verwaltung ist. I n f o r m a t i k - P r o j e k t e sind in der Praxis oft solche Projekte, die der Schaffung neuer oder wesentlich veränderter Informationssysteme dienen. S i e werden im folgenden als IuK-Projekte bezeichnet (IuK = Information und Kommunikation). Die Planung und Realisierung von IuK-Projekten ist ein kooperativer und kreativer Arbeitsprozeß. Aus der S i c h t der 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, T e c h n i k e n und Werkzeugen im Vordergrund; das Verhalten der Personen und Gruppen, die diesen Prozeß vorantreiben, rückt in den Hintergrund. Es ist ein wesentliches Merkmal der Wirtschaftsinformatik als einer modernen sozial- und wirtschaftswissenschaftlichen, mit ingenieurwissenschaftlichem Denken durchsetzten Disziplin, daß sie beide Sichtweisen zusammenfaßt und integriert.

2

Vorwort

E i n I u K - P r o j e k t ist nicht identisch mit e i n e m S o f t w a r e - P r o j e k t ; es ist viel u m f a s s e n d e r . D i e s e F e s t s t e l l u n g f o l g t aus der T a t s a c h e , d a ß S o f t w a r e nur ein T e i l , w e n n a u c h e i n w e s e n t l i c h e r Teil von I n f o r m a t i o n s s y s t e m e n ist. D a die B e s o n d e r heiten v o n S o f t w a r e - P r o j e k t e n in einschlägigen L e h r b ü c h e r n a b g e h a n d e l t w e r d e n u n d a u c h G e g e n s t a n d b e s o n d e r e r L e h r v e r a n s t a l t u n g e n sind, wird in d i e s e m L e h r b u c h nicht n ä h e r d a r a u f e i n g e g a n g e n . A u s l e r n p s y c h o l o g i s c h e r S i c h t wird e m p f o h l e n , K e r n b e g r i f f e j e w e i l s v o r d e r L e r n e i n h e i t a n z u o r d n e n u n d zu d e f i n i e r e n , in d e r sie v e r w e n d e t w e r d e n . D a d u r c h k ö n n e n sich die L e r n e n d e n soweit mit ihnen v e r t r a u t m a c h e n , d a ß sie die F a c h s p r a c h e d e r L e r n e i n h e i t k e n n e n , b e v o r sie sich mit d e m L e r n s t o f f a u s e i n a n d e r s e t z e n . D i e s e s V o r g e h e n hat auch den Vorteil, den S a c h i n h a l t der L e r n e i n h e i t v o n d e f i n i t o r i s c h e n A u s f ü h r u n g e n fast völlig f r e i zu halten. W a s a l s o in j e d e r L e r n e i n h e i t n a c h d e m A b s c h n i t t "Definitionen u n d A b k ü r z u n g e n " w i e d e r g e g e b e n wird, ist Inhalt z u r L e r n e i n h e i t u n d nicht E r k l ä r u n g v o n F a c h s p r a c h e . 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 , w i r d das h e r k ö m m l i c h e M a s k u l i n u m verw e n d e t u n d auf u m s t ä n d l i c h e K o n s t r u k t i o n e n f ü r e i n e " g e s c h l e c h t s n e u t r a l e F o r m u l i e r u n g " v e r z i c h t e t . U n a b h ä n g i g v o m G e s c h l e c h t sind alle, L e s e r i n n e n und 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 i r d eine F o r m u l i e r u n g v e r w e n d e t , die auf e i n e n G e s c h l e c n t e r b e z u g verzichtet. D e r D a n k d e s A u t o r s gilt a l l e n , die b e i m E n t s t e h e n d i e s e s n e u e n L e h r b u c h s , d e s s e n P r o t o t y p z w e i S t u d i e n j a h r e im L e h r b e t r i e b v e r w e n d e t w u r d e , m i t g e w i r k t h a b e n . N a m e n t l i c h seien g e n a n n t : Frau M a g . I. D a m s c h i k , Frau M a g . I. H ä n t s c h e l u n d H e r r Dr. G a p p m a i e r , d i e in den Ü b u n g e n z u r V o r l e s u n g mit d e m S k r i p t u m g e a r b e i t e t u n d zu s e i n e r V e r b e s s e r u n g b e i g e t r a g e n h a b e n , s o w i e Frau B. S t e i n k e l l n e r , die T e i l e d e r M a n u s k r i p t b e a r b e i t u n g ü b e r n o m m e n u n d die n e u h i n z u g e k o m m e n e n A b b i l d u n g e n a n g e f e r t i g t hat. M e i n b e s o n d e r e r D a n k gilt m e i n e r F r a u ; sie hat d u r c h m e h r m a l i g e s K o r r e k t u r l e s e n F e h l e r a u s g e m e r z t u n d v i e l e n T e x t t e i l e n e i n e v e r b e s s e r t e Lesbarkeit und Verständlichkeit g e g e b e n . Linz, im H e r b s t 1996

L.J.H.

Inhaltsverzeichnis Vorwort

1

Alphabetisches Verzeichnis der Lerneinheiten

5

Einführung in das Management von Informatik-Projekten

7

Grundlagen PROM A PRORG PROPL PRIPM

-

Projektmanagement Aufgaben des Projektmanagements Projektorganisation Projektplanung, -Überwachung und -Steuerung Prinzipien des Projektmanagements

17 19 25 32 46

Grundlagen IuK-Projekte

53

ZAMIP SYSIP PROIP ZIELP

55 65 72 80

-

Ziel, Aufgaben und Methodik von IuK-Projekten Systemtechnik und IuK-Projekte Prozeßcharakter von IuK-Projekten Zielplanung für IuK-Projekte

Mensch und Projektmanagement PROVE BEBET KREAT PROTY

-

Projektverantwortung und Projektgruppe Methoden der Benutzerbeteiligung Kreativitätstechniken Prototyping in IuK-Projekten

Projektphasen ZAMVS ZAMFS ZAMSE ZAMIM ZAMIN

-

Ziel, Ziel, Ziel, Ziel, Ziel,

99 101 114 123 132

143 Aufgaben und Methodik der Vorstudie Aufgaben und Methodik der Feinstudie Aufgaben und Methodik des Systementwurfs Aufgaben und Methodik der Implementierung Aufgaben und Methodik der Installierung

145 155 162 173 181

Planungsmethoden

193

PROME NETZP MEAUF WERIP

195 201 211 230

-

Methoden des Projektmanagements Netzplantechnik Methoden der Aufwandsschätzung Werkzeugunterstützung bei IuK-Projekten

4

Inhaltsverzeichnis

Beschreibungsmethoden

243

ERFAS DARST ENTAB DOKUM PRAET

245 257 269 278 290

-

Erfassungsmethoden Darstellungstechniken Entscheidungstabellen-Technik Dokumentationsmethoden Präsentationstechniken

Analysemethoden

299

WIRTA NUTZW WERTA MATRX INTER KOMAN

301 311 323 331 338 343

-

Wirtschaftlichkeitsanalyse Nutzwertanalyse Wertanalyse Matrixanalyse Interaktionsanalyse Kommunikationsanalyse

Entwurfsmethoden

353

SADT DAFLU PENET SIMUL

355 364 375 386

-

Structured Analysis and Design Technique Datenflußdiagramme Petri-Netze Simulation

Qualitätsmanagement

397

QUAMA TESTM REVAU NORMQ

399 408 419 427

-

Grundlagen Qualitätsmanagement Testmethoden Reviews und Audits Normen zum Qualitätsmanagement

Projektdiagnose

437

PFLIC PCONT PREVI CHECK

439 447 456 463

-

Pflichtenheft Projektcontrolling Projektrevision Checklisten

Fallbeispiele

471

VORMO

- Vorgehensmodell

472

PROHB

- Projekthandbuch

477

Literaturverzeichnis

481

Schlagwortverzeichnis

491

Alphabetisches Verzeichnis der Lerneinheiten BEBET

- Methoden der Benutzerbeteiligung

114

CHECK

- Checklisten

463

DAFLU DARST DOKUM

- Datenflußdiagramme - Darstellungstechniken - Dokumentationsmethoden

364 257 278

ENTAB ERFAS

- Entscheidungstabellen-Technik - Erfassungsmethoden

269 245

INTER

- Interaktionsanalyse

338

KOMAN KREAT

- Kommunikationsanalyse - Kreativitätstechniken

343 123

MATRX MEAUF

- Matrixanalyse - Methoden der Aufwandsschätzung

331 211

NETZP NORMQ NUTZW

- Netzplantechnik - Normen zum Qualitätsmanagement - Nutzwertanalyse

201 427 311

PCONT PENET PFLIC PRAET PREVI PRIPM PROHB PROIP PROMA PROME PROPL PRORG PROTY PROVE

-

447 375 439 290 456 46 477 72 19 195 32 25 132 101

QUAMA

- Grundlagen Qualitätsmanagement

399

REVAU

- Reviews und Audits

419

Projektcontrolling Petri-Netze Pflichtenheft Präsentationstechniken Projektrevision Prinzipien des Projektmanagements Projekthandbuch Prozeßcharakter von IuK-Projekten Aufgaben des Projektmanagements Methoden des Projektmanagements Projektplanung, -Überwachung und -Steuerung Projektorganisation Prototyping in IuK-Projekten Projektverantwortung und Projektgruppe

6

Alphabetisches

Verzeichnis

der

Lerneinheiten

SADT SIMUL SYSIP

- Structured Analysis and Design Technique - Simulation - Systemtechnik und IuK-Projekte

355 386 65

TESTM

- Testmethoden

408

VORMO

- Vorgehensmodell

472

WERIP WERTA WIRTA

- Werkzeugunterstützung bei IuK-Projekten - Wertanalyse - Wirtschaftlichkeitsanalyse

230 323 301

ZAMFS ZAMIM ZAMIN ZAMIP ZAMSE ZAMVS ZIELP

-

155 173 181 55 162 145 80

Ziel, Aufgaben und Methodik der Feinstudie Ziel, Aufgaben und Methodik der Implementierung Ziel, Aufgaben und Methodik der Installierung Ziel, Aufgaben und Methodik von IuK-Projekten Ziel, Aufgaben und Methodik des Systementwurfs Ziel, Aufgaben und Methodik der Vorstudie Zielplanung für IuK-Projekte

Einführung in das Management von Informatik-Projekten Lernziele Sie können den Lernstoff "Management von Informatik-Projekten" in Wissenschaftsdisziplinen und Lehrgebiete einordnen. Sie können die grundlegenden Begriffe Management, Informatik und Projekt sowie das Konstrukt InformatikProjekt erläutern. Sie kennen typische Gegenstände von Informatik-Projekten, insbesondere die (Re)Konstruktion von Informations- und Kommunikationssystemen. Sie kennen Eigenschaften, die Informations- und Kommunikationssysteme kennzeichnen. Sie kennen die Struktur, in welcher der Lernstoff in diesem Lehrbuch aufbereitet und dokumentiert wird. I n f o r m a t i k und Informatik-Mittel Im wissenschaftlichen Sprachgebrauch ist Informatik eine Wissenschaftsdisziplin. Die Verwendung dieser Bezeichnung, die aus den Worten /n/ormation und M.alhe,matik gebildet wurde, setzte sich im deutschprachigen Raum in den sechziger Jahren durch. Üblich ist eine Einteilung der Informatik in die Teildisziplinen Theoretische Informatik, Technische Informatik, Praktische Informatik und Angewandte Informatik. Die drei zuerst genannten Teildisziplinen werden zusammenfassend als Kerninformatik bezeichnet. Die Theoretische Informatik befaßt sich mit Phänomenen, die für die Informatik eine grundlegende Bedeutung haben, d.h. mit Theorieentwicklung. Dazu gehören die Automatentheorie, die Theorie Formaler Sprachen, die Theorie der Berechenbarkeit, die Komplexitätstheorie, die Algorithmenanalyse, die Theorie der Programmierung, die Automatische Programmsynthese und die Formale Semantik. In der Automatentheorie wird zum Beispiel untersucht, welche mathematischen Modelle dem Computer zugrundeliegen. Die Theorie der Berechenbarkeit macht Aussagen darüber, wie das Berechenbare vom Nichtberechenbaren abgegrenzt werden kann. Im Teilgebiet Formale Sprachen wird der strukturelle Aufbau von Programmiersprachen untersucht. Der Gegenstandsbereich der Technischen Informatik kann durch Phänomene wie Hardware-Komponenten, Schaltnetze, Prozessoren, Mikroprogrammierung, Rechnerorganisation und Rechnerarchitektur, Schnittstellentechnik und Rechnernetze gekennzeichnet werden. Die Erkenntnisse der Technischen Informatik sind Grundlage für die Entwicklung von Informations- und Kommunikationstechniken. Der Gegenstandsbereich der Praktischen Informatik ist durch Phänomene wie Algorithmen, Datenstrukturen und Programmiermethoden, Programmiersprachen und Compiler, Betriebssysteme, Software Engineering und MenschMaschine-Kommunikation gekennzeichnet. Er befindet sich in einem erheblichen Naheverhältnis zur Wirtschaftsinformatik, teilweise befindet er sich im gemein-

8

Einführung

s a m e n S c h n i t t der G e g e n s t a n d s b e r e i c h e b e i d e r Disziplinen. Ein t y p i s c h e s Beispiel d a f ü r ist "Mensch-Maschine-Kommunikation", ein Phänomen, das ganz offensichtlich organisatorische und damit betriebswirtschaftliche, arbeitsmedizinische und arbeitspsychologische Fragen berührt. Auch das Software Engineering wird häufig zu den Kerngebieten der Wirtschaftsinformatik gezählt; j e d e n falls gibt es d a f ü r einschlägige Wirtschaftsinformatik-Lehrstühle, und viele Forschungsarbeiten der Wirtschaftsinformatik sind diesem Gebiet zuzurechnen. Die A n g e w a n d t e I n f o r m a t i k ist im wesentlichen deckungsgleich mit Teilen anderer W i s s e n s c h a f t e n . Dies zeigen Bezeichnungen ihrer Teildisziplinen wie Informationssysteme (die primär Gegenstandsbereich der Wirtschaftsinformatik sind), Digitale Signal Verarbeitung (die zum Gegenstandsbereich der Nachrichtentechnik gehört), Textverarbeitung und Büroautomation (die lediglich Teilgebiete der Informationssysteme kennzeichnen), Simulation und Modellierung (die in einer R e i h e von Wissenschaftsdisziplinen als Forschungs- und E n t w u r f s methoden angewendet werden) und ganz besonders Bezeichnungen wie "Spezifische A n w e n d u n g e n in Wirtschaft und Verwaltung, Ingenieurwissenschaften, Naturwissenschaften, Medizin, Sozialwissenschaften, Geisteswissenschaften und Kunst". Soweit es sich hierbei um Wissenschaft (und nicht u m "Anwendungen") handelt, g e h ö r e n die genannten Gebiete zum Gegenstandsbereich der Wirts c h a f t s i n f o r m a t i k , der Medizinischen Informatik, der Rechtsinformatik usw., also von Wissenschaften, die aus den jeweiligen Problemwissenschaften heraus entwickelt wurden (das heißt aus den Wirtschaftswissenschaften, aus der Medizin, aus den Rechtswissenschaften usw.). Die z w e i t e und im vorliegenden Z u s a m m e n h a n g verwendete Bedeutung von I n f o r m a t i k meint I n f o r m a t i o n s - und Kommunikationsiec/im'fcen (kurz: IuKTechniken), also die technischen Hilfsmittel, mit denen Information und K o m munikation in Organisationen in Wirtschaft und Verwaltung unterstützt o d e r erst möglich gemacht wird (z.B. Computer-Hardware und -Software). In einem weiteren Sinn sind damit Informations- und Kommunikationsfec/iwo/ogi'en (kurz: IuK-Technologien) gemeint, also Verfahren und Methoden zur Anwendung und Nutzung von IuK-Techniken. Beide werden zusammenfassend häufig als Inform a t i k - M i t t e l bezeichnet. Informatik-Mittel sind also sowohl die I u K - T e c h niken als auch die Verfahren und Methoden zu ihrer Anwendung und Nutzung. Projekt und

Informatik-Projekt

Ein P r o j e k t ist ein Vorhaben, das im wesentlichen durch Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, wie (nach DIN 69901): • Zielvorgabe; • zeitliche, finanzielle, personelle oder andere Begrenzungen; • Abgrenzung gegenüber anderen Vorhaben; • projektspezifische Organisation (Struktur- und Ablauforganisation).

Einführung

9

Gegenstand von Informatik-Projekten ist die Beschaffung, Veränderung, Bewertung (Evaluierung), Sanierung usw. von Informatik-Mitteln zur Unterstützung oder Ermöglichung von Information und Kommunikation in Organisationen in Wirtschaft und Verwaltung. Typische Gegenstände von Informatik-Projekten sind daher die Schaffung neuer oder wesentlich veränderter Informationssysteme (vgl. die beiden Bde. "Systemplanung"), die Bewertung von Hardware, Software und Dienstleistungen als Aufgabe des Technologiemanagements (vgl. Lerneinheit TECHM im Bd. "Informationsmanagement") und die Migration von Software-Systemen (z.B. von SAP R/2 nach SAP R/3). Informatik-Projekte sind durch folgende Merkmale gekennzeichnet: • relativ kurze Projektlaufzeit (idealerweise wenige Wochen bis maximal ein Jahr); • mittlere bis große Anzahl beteiligter Personen und Institutionen; • Schnittstellen zu anderen Projekten oder Komponenten der Informationsinfrastruktur (z.B. zu bestehenden Informationssystemen), sodaß eine "isolierte" Sichtweise nicht möglich ist; • geringer Projektfreiheitsgrad, da die Projektziele durch die vorgegebenen Planungsziele bestimmt werden; • Ergebnisrisiko, weil zwar wahrscheinlich, aber nicht sicher ist, daß die Planungsziele erreicht werden; • Unsicherheiten bezüglich der Einhaltung von Termin- und Kostenzielen; • Wettbewerb um die Ressourcen für die Projektabwicklung mit anderen Projekten (insbes. um Budgets, Personal und Betriebsmittel). Management Unter Management wird im allgemeinen Sprachgebrauch das Führen einer Organisationseinheit verstanden (z.B. das Führen einer Abteilung, eines Geschäftsprozesses oder einer Projektgruppe), oder es wird damit die Personengruppe bezeichnet, die eine Organisationseinheit führt. In der Betriebswirtschaftslehre meint Management das Leitungshandeln in einer Organisationseinheit, mit dem sich insbesondere der betriebswirtschaftliche Wissenschaftsbereich der Managementlehre befaßt. Die Notwendigkeit zum Leitungshandeln besteht in jeder arbeitsteiligen Organisation. Arbeitsschwerpunkte der Managementlehre sind die Managementtechnik und die Menschenführung. Unter den verschiedenen Denk- und Erklärungsansätzen der Managementlehre ist der systemtheoretisch-kybernetisch orientierte Ansatz für die Wirtschaftsinformatik von besonderem Interesse. Er versucht, die begrifflichen und die forschungsmethodischen Instrumente der Systemtheorie und der Kybernetik für das Management nutzbar zu machen. Management als Führungsaufgabe meint eine Menge von Strukturierungs-, Koordinations- und Integrationsaufgaben, die für den Erhalt von arbeitsteilig organisierten Institutionen (z.B. Unternehmen) und Vorhaben (z.B. Projekten) notwendig sind. Sie sollen auf der materiellen Ebene eine zielorientierte Beschaf-

10

Einführung

fung, Kombination und Verwertung von Ressourcen sichern, sodaß Institutionen und Vorhaben leistungsfähig gemacht werden und bleiben. Management als Institution umfaßt alle Positionen in Organisationen, die mit Vorgesetztenfunktionen ausgestattet sind. Personen, die solche Positionen besetzen, werden als Manager bezeichnet (z.B. ein Projektleiter als Projektmanager). Projektmanagement Projektmanagement (abgekürzt: PM) ist nach DIN 69901 die Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mittein für die Abwicklung eines Projekts. PM wird daher auch als Führungskonzeption oder - weniger anspruchsvoll - als Führungsinstrument für die Koordination von Planung, Überwachung und Steuerung bei der Abwicklung fachübergreifender Aufgaben angesehen. Management von Informatik-Projekten (abgekürzt: MIP) ist folglich das Führungsinstrument für die fachübergreifende Koordination von Planung, Überwachung und Steuerung bei der Abwicklung von Informatik-Projekten. Die Unterscheidung zwischen Projektmanagement und Management von Informatik-Projekten geht von der Annahme aus, daß es Besonderheiten von Informatik-Projekten gibt, die eine spezifische Erklärung erfordern. Im folgenden wird erläutert, worin diese Besonderheiten bestehen. IuK-Projekte Projektmanagement ist eine allgemeine, vom Projektgegenstand unabhängige Erklärung über und Handlungsanweisung für Führungsaufgaben, -organisation, -techniken und -mittel der Planung, Überwachung und Steuerung bei der Abwicklung von Projekten. Präzisere Beschreibungen in der Literatur unterstellen bestimmte Projektgegenstände. Dabei handelt es sich meist um Planung und Bau von industriellen Großanlagen (z.B. Anlagen der Stahlindustrie wie Hochöfen und Walzwerke). Dies weist darauf hin, daß eine über die allgemeine Projektmanagement-Methodik hinausgehende Erklärung und Gestaltung ohne Berücksichtigung des Projektgegenstands nicht möglich ist. Präzisere Erklärungen des Projektmanagements und praktisch verwertbare Handlungsanweisungen für das Management von Informatik-Projekten erfordern Kenntnisse über den Projektgegenstand und seine Bearbeitung. Handelt es sich um Informatik-Projekte, dann sind damit Kenntnisse über die für Informatik-Projekte typischen Gegenstände einschließlich der Prinzipien, Verfahren, Methoden, Techniken und Werkzeuge gemeint, die zur Bearbeitung dieser Projektgegenstände erforderlich und verfügbar sind. Die Vielfalt der Gegenstände für Informatik-Projekte und damit der Prinzipien, Verfahren, Methoden usw. ist so groß, daß es nicht möglich ist, in einem Handbuch - wie in diesem Lehrbuch - alle zu berücksichtigen. Dieses Lehrbuch befaßt sich daher im wesentlichen "nur" mit Informatik-Projekten, deren Gegenstand die Konstruktion von Informations- und Kommunikationssystemen ist; sie werden kurz als IuK-Projekte bezeichnet. Damit wird nicht ausgeschlossen, daß

Einführung

11

vieles, was diese Lernunterlage enthält, auch für das Management anderer Informatik-Projekte von Bedeutung ist. Darauf wird in der Vorlesung hingewiesen und bei Bedarf auf Besonderheiten anderer Informatik-Projekte eingegangen (z.B. auf B e s c h a f f u n g s - und Evaluierungsprojekte des T e c h n o l o g i e m a n a g e ments). Informations- und

Kommunikationssysteme

Generell wird unter S y s t e m der ganzheitliche Z u s a m m e n h a n g von Teilen, Einzelheiten, Dingen oder Vorgängen, die voneinander abhängig sind, ineinandergreifen oder zusammenwirken, verstanden. Ein System besteht aus einer Menge von Elementen, die in bestimmter Weise miteinander in Beziehung stehen (miteinander interagieren) und einen bestimmten Zweck erfüllen. Der Beziehungszusammenhang zwischen den Elementen ist deutlich dichter als der zu anderen Elementen, sodaß sich Systeme von ihrer Umwelt (Umsystem) abgrenzen lassen. Formal ausgedrückt: Ein System ist ein Tripel, bestehend aus einer Menge von Elementen, einer M e n g e von Verbindungen und einer Zuordnungsvorschrift der Verbindungen auf die Elemente. Der Systemzweck wird durch adjektivische Begriffszusätze ausgedrückt (z.B. Verkehrssystem, Versorgungssystem, Computersystem, Datensystem, Methodensystem). Die Zusätze "Information" und "Kommunikation" verdeutlichen, daß der Zweck eines "Informations- und Kommunikationssystems" Information und Kommunikation ist. • I n f o r m a t i o n 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 V e r k n ü p f u n g dieser Daten dem Handelnden zur Verfügung zu stellen. • K o m m u n i k a t i o n 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" (nach N. Szyperski) beider Phänomene 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 I n f o r m a t i o n richtet, und die Bezeichnung K o m m u n i k a t i o n s s y s t e m zu verwenden, w e n n sich das H a u p t a u g e n m e r k auf K o m m u n i k a t i o n richtet. Damit wird eine unterschiedliche Sicht auf ein- und dasselbe Objekt benannt. In der Wirtschaftsinformatik hat es sich allerdings eingebürgert, die Bezeichnung Informationssystem zu verwenden, was damit erklärt werden kann, daß es im betriebswirtschaftlichen Sinn letztlich u m Information geht u n d Kommunikation sozusagen "nur" das Vehikel zur Information (d.h. Mittel z u m Zweck) ist. Daher werden nachfolgend neben der Langfassung

12

Einführung

Informations- und Kommunikationssystem die Bezeichnungen IuK-System und Informationssystem synonym verwendet. E i n o r d n u n g in die Wirtschaftsinformatik Z u r Einordnung von "Management von Informatik-Projekten" in die Wirtschaftsinformatik als Wissenschaft ist es notwendig, eine Vorstellung über ihre Gliederung in Teildisziplinen zu haben. Da es diesbezüglich noch kein Paradigma, also keine von der wissenschaftlichen Gemeinschaft mehrheitlich akzeptierte Vereinbarung gibt, soll die folgende Gliederung als möglich bezeichnet und als zweckmäßig verwendet werden: • Grundlagen (z.B. Gegenstandsbereich, Forschungsziele und -methoden, Begriffssystem, Informationsrecht, Grundphänomene wie Information und Kommunikation, Informations- und Kommunikationssystem, Informationsarchitektur und Informationsinfrastruktur); • Management von Informationsinfrastrukturen (kurz: IM = Information Management), also Strukturierungs-, Koordinations- und Integrationsaufgaben zur Führung von Informationsinfrastrukturen; • Konstruktion und Rekonstruktion von Informationsinfrastrukturen (kurz: IE = Information Engineering), also Prinzipien, Verfahren, Methoden, Techniken und Werkzeuge zur Schaffung und Veränderung von Informationsinfrastrukturen; • Management von Informationssystemen (kurz: ISM = Information Systems Management), also Strukturierungs-, Koordinations- und Integrationsaufgaben zur Führung von Informationssystemen; • Konstruktion und Rekonstruktion von Informationssystemen (kurz: ISE = Information Systems Engineering), also Prinzipien, Verfahren, Methoden, Techniken und Werkzeuge zur Schaffung und Veränderung von Informationssystemen.

"Management von Informatik-Projekten" ist offensichtlich zunächst dem Teilgebiet ISM zuzuordnen. Wenn aber davon ausgegangen wird, daß - wie weiter oben bereits begründet - das Management spezifischer Projekte bestimmte Kenntnisse über den Projektgegenstand und die Prinzipien, V e r f a h r e n , Methoden usw. erfordert, mit deren Hilfe der Projektgegenstand konstruiert oder rekonstruiert wird, dann umfaßt es neben ISM einen beachtlichen Teil von ISE; dies veranschaulicht Abbildung 1.

Einführung

13

Wird von der aufgabenorientierten Zwecksetzung von Informationssystemen ausgegangen, dann ergibt sich eine andere Gliederung, bei der alle an die Art der Aufgabe gebundenen Probleme, mit deren Lösung sich die Wirtschaftsinformatik beschäftigt, B e s o n d e r e n W i r t s c h a f t s i n f o r m a t i k e n zugeordnet werden. Die allen Besonderen Wirtschaftsinformatiken gemeinsamen Probleme sind Teil einer Allgemeinen Wirtschaftsinformatik. Abbildung 2 zeigt das Ergebnis dieser Überlegungen. Für das Management von Informatik-Projekten 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.

Abb. 2: Aufgabenorientierte Gliederung der Wirtschaftsinformatik

E i n o r d n u n g in Lehrgebiete Auf Grund der Überlegungen zur Einordnung von "Management von Informatik-Projekten" in die Wirtschaftsinformatik als Wissenschaft, können Aussagen über die Einordnung des Lernstoffs in Lehrgebiete gemacht werden. Dabei wird von folgenden Alternativen, Wirtschaftsinformatik an deutschsprachigen Universitäten und Hochschulen zu studieren, ausgegangen: • 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);

14

Einführung

• 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 "Management von InformatikProjekten" nicht zum Stoffumfang gehört). In erster Linie ist der Lernstoff "Management von Informatik-Projekten" in das Lehrgebiet der Diplomstudiengänge Wirtschaftsinformatik einzuordnen. Das Ausbildungsziel dieser Studiengänge kann so beschrieben werden: Absolventen sind in der Lage, sowohl auf der Seite der Anbieter (Hersteller, System- und Softwarehä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 "Management von InformatikProjekten". In zweiter Linie ist dieser Lernstoff in das Lehrgebiet der Diplomstudiengänge B e t r i e b s w i r t s c h a f t s l e h r e einzuordnen, die - zumeist im zweiten Studienabschnitt bzw. im Hauptstudium - Wirtschaftsinformatik oder Betriebsinformatik oder Fächer mit anderen Bezeichnungen (z.B. Informationswirtschaft) als Wahlpflichtfach oder als Wahlfach vorsehen. Das Ausbildungsziel dieses Vertiefungsfachs kann so beschrieben werden: Absolventen werden in der Praxis vor allem als Benutzer von Informationssystemen auftreten. Sie bestimmen daher entscheidend die Anforderungen an die Gestaltung dieser Systeme, und sie wirken deshalb an der Planung und Realisierung von IuK-Systemen und daher an Informatik-Projekten aktiv mit (Benutzerbeteiligung, vgl. Lerneinheit BEBET). Der Lernstoff "Management von Informatik-Projekten" geht aber weit über das hinaus, was Benutzer wissen müssen, um Benutzerbeteiligung erfolgreich praktizieren zu können. Zur Gliederung des Lernstoffs Der Lernstoff ist zunächst in einzelne Kapitel gegliedert, und zwar wie folgt: • • • • • • • • • • •

erstes Kapitel: Grundlagen Projektmanagement zweites Kapitel: Grundlagen IuK-Projekte drittes Kapitel: Mensch und Projektmanagement viertes Kapitel: Projektphasen fünftes Kapitel: Planungsmethoden sechstes Kapitel: Analysemethoden siebtes Kapitel: Entwurfsmethoden achtes Kapitel: Beschreibungsmethoden neuntes Kapitel: Qualitätsmanagement zehntes Kapitel: Projektdiagnose elftes Kapitel: Fallbeispiele

Einführung

15

Auf d e r zweiten Gliederungsebene ist der Lernstoff j e Kapitel in mehrere Lerneinheiten gegliedert. Jede dieser Lerneinheiten (außer das Kapitel Fallbeispiele) hat folgende Struktur: • erster Abschnitt: Lernziele • zweiter Abschnitt: Definitionen und Abkürzungen, die in der 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: Kontrollfragen zum jeweiligen Stoffinhalt • sechster Abschnitt: Quellenliteratur, also die Literatur, aus welcher der Stoffinhalt entnommen wurde, soweit es sich nicht um Allgemeingut bzw. um Arbeitsergebnisse des Autors handelt • siebter Abschnitt: Vertiefungsliteratur, beispielsweise zu den Forschungsbefunden, die ein weitergehendes Selbststudium ermöglichen soll • achter Abschnitt: N o r m e n Viele Lerneinheiten enthalten am Ende des dritten Abschnitts ein D e m o n s t r a tionsbeispiel. Forschungsbefunde, Vertiefungsliteratur und Normen finden sich nicht in allen Lerneinheiten. Kontrollfragen 1. Welche Bedeutungen hat "Informatik" und welche davon wird beim Konstrukt "Informatik-Projekt" verwendet? 2. Welche Bedeutungen haben "Management" und "Manager"? 3. Was ist ein Projekt und was ein Informatik-Projekt? 4 . Wie kann der Projektgegenstand "Informationssystem" beschrieben werden? 5. Wie kann "Management von Informatik-Projekten" in Lehrgebiete eingeordnet werden? Quellenliteratur Heinrich, L. J.: Wirtschaftsinformatik in Forschung und Ausbildung. In: Information Management 1/1986, 63 - 6 9 Heinrich, L. J.: Wirtschaftsinformatik - Einführung und Grundlegung. Oldenbourg, München/ Wien 1993 Heinrich, L. J. et al.: Informations- und Kommunikationstechnik für Betriebswirte und Wirtschaftsinformatiker. 4. A., Oldenbourg, München/Wien 1994 Heinrich, L. J./Roithmayr, F.: Wirtschaftsinformatik-Lexikon. 5. A., Oldenbourg, München/ Wien 1995 Mertens, P. et al. (Hrsg.): Studienführer Wirtschaftsinformatik. Vieweg, Braunschweig/Wiesbaden 1996 Schwarze, J.: Systementwicklung. Grundzüge der wirtschaftlichen Planung, Entwicklung und Einführung von Informationssystemen. Neue Wirtschaftsbriefe, Herne/Berlin 1996 Zielasek, G.: Projektmanagement. Erfolgreich durch Aktivierung aller Unternehmensebenen. Springer, Berlin et al. 1995

16

Einfährung

Vertiefungsliteratur Bauer, G.: Softwaremanagement. Analyse und Entwurf. Spektrum, Heidelberg et al. 1995 Heinrich, L. J.: Wirtschaftsinformatik als Wissenschaft - Entwicklung, Stand und Perspektiven. In: Heinrich, L. J. und Lüder, K. (Hrsg.): Betriebswirtschaftslehre und Unternehmensführung. Neue Wirtschaftsbriefe, Herne/Berlin 1985, 35 - 59 Rechenberg, P.: Was ist Informatik? Eine allgemeinverständliche Einführung. Hanser, München/ Wien 1991 Scheer, A. W.: EDV-orientierte Betriebswirtschaftslehre. 4. A., Springer, Berlin et al. 1990 Zehnder, C. A.: Informatik-Projektentwicklung. 2. A., Teubner, Zürich 1991 Normen Deutsches Institut für Normung (Hrsg.): DIN 69901 - Projektmanagement, Begriffe. Beuth, Berlin 1987

Grundlagen Projektmanagement Projektgruppe / Personalplanung Projektziele / Zielplanung Projektaufgaben / Aufgabenplanung Projektzeiten / Zeitplanung Projektaufgaben-Träger / Personaleinsatzplanung Zwischen- und Endtermine / Terminplanung Methoden und Werkzeuge / Sachmittelplanung Sach- und Personalkosten / Kostenplanung Notfallmaßnahmen / Notfallplanung Sonstige Planungsobjekte

18

Grundlagen

Projektmanagement

Mit dem Kapitel Grundlagen Projektmanagement sollen folgende Lernziele erreicht werden: P R O M A - Aufgaben des Projektmanagements Sie kennen die Aufgabe des Projektmanagements und die daraus abgeleiteten Teilaufgaben. Sie erkennen die Zweckmäßigkeit der Unterscheidung zwischen verschiedenen Projektmanagement-Ebenen. Sie können Planungsziele von Projektzielen unterscheiden. Sie wissen, nach welchem Modell oder Konzept die Projektführung erfolgen soll. Sie erkennen die Notwendigkeit der Technologieunterstützung für das Projektmanagement. P R O R G - Projektorganisation Sie kennen die Aufgabe des Projektmanagements und die daraus abgeleiteten Teilaufgaben. Sie kennen die Formen der Projektorganisation und können diese erläutern. Sie kennen die Aufbauorganisation innerhalb der Projektgruppe sowie die Bedeutung der Beteiligung der vom Projekt Betroffenen an der Projektarbeit. P R O P L - Projektplanung, -Überwachung und -Steuerung Sie können die Aufgabe der Projektplanung in Teilaufgaben zerlegen und die Teilplanungen beschreiben. Sie erkennen den Zusammenhang, der zwischen den Teilplanungen besteht. Sie können die Zweckmäßigkeit von Realisierungsstrategien für die Projektplanung beurteilen. Sie kennen die Bedeutung der Projektüberwachung und der Projektsteuerung für den Projekterfolg und können diese Aufgaben erläutern. P R I P M - Prinzipien des Projektmanagements Sie wissen, was Prinzipien sind und kennen ihren wissenschaftlichen Wert und ihre praktische Bedeutung. Sie können Prinzipien des Projektmanagements nennen und erläutern, insbesondere solche, die für Informatik-Projekte von Bedeutung sind. Sie erkennen, daß sich Prinzipien in ihren Aussagen überschneiden und manchmal auch widersprechen. Sie erkennen, daß Prinzipien nur nach gründlicher Prüfung bei der Projektarbeit verfolgt werden sollten.

PROMA - Aufgaben des Projektmanagements Lernziele Sie kennen die Aufgabe des Projektmanagements und die daraus abgeleiteten Teilaufgaben. Sie erkennen die Zweckmäßigkeit der Unterscheidung zwischen verschiedenen Projektmanagement-Ebenen. Sie können Planungsziele von Projektzielen unterscheiden. Sie wissen, nach welchem Modell oder Konzept die Projektführung erfolgen soll. Sie erkennen die Notwendigkeit der Technologieunterstützung für das Projektmanagement. Definitionen und Abkürzungen Kompetenz (competence) = der Handlungsspielraum eines Aufgabenträgers, der zur ordnungsgemäßen Aufgabenerfüllung notwendig ist. Meilenstein (milestone) = ein Hilfsmittel des Projektmanagements zur Orientierung über den Projektverlauf und zur Projektlenkung ("Weichenstellung"). Planungsziel (planning goal) = ein Ziel, das vom strategischen Informationsmanagement gesetzt und der Projektleitung vorgegeben wird. Projektcontrolling (project Controlling) = der Teil des Controlling im Sinn von "Informationsbeschaffung für Planung, Überwachung und Steuerung", dessen Objekt Projekte sind. Projektgruppe (project team) = die für ein Projekt eingesetzten Personen, die von einer Projektleitung geführt werden. Synonym: Projektteam. Projekthandbuch (project manual) = ein Dokument mit der unternehmensweit verbindlichen, für jedes Projekt geltenden Projektmanagement-Methodik. Projektleiter (project manager) = die für die Projektleitung verantwortliche Person. Projektleitung (project management) = die für die Dauer eines Projekts geschaffene Organisationseinheit, die für die Planung, Überwachung und Steuerung dieses Projekts verantwortlich ist. P r o j e k t o r g a n i s a t i o n (project Organization) = die Gesamtheit der Organisationseinheiten und der struktur- und ablauforganisatorischen Regelungen zur Abwicklung eines Projekts. Projektziel (project goal) = ein Ziel, das aus den Planungszielen abgeleitet und zur Planung, Überwachung und Steuerung eines Projekts verwendet wird. Stab (staff) = eine Struktureinheit zur spezialisierten Unterstützung von Struktureinheiten in der Linie. Synonym: Stabsstelle. Verantwortung (responsibility) = eine mit der Übertragung einer Aufgabe auf einen Aufgabenträger verbundene Verpflichtung. Vorgehensmodell (action model) = die aus einem Phasenschema abgeleitete, präzise Beschreibung der Tätigkeiten sowie ihrer Voraussetzungen und Ergebnisse zur Abwicklung von Projekten. Zielsystem (goal system) = eine Menge von (meist) hierarchisch geordneten Zielen, die aus einem Oberziel systematisch abgeleitet werden.

20

Grundlagen

Projektmanagement

Aufgabe des Projektmanagements Projektmanagement ist die Gesamtheit der Führungsaufgaben, -Organisation, -techniken und -mittel für die Abwicklung eines Projekts (nach DIN 69901). Im vorliegenden Zusammenhang sind solche Projekte von Interesse, deren Ziel die Schaffung oder die nachhaltige Änderung der Informationsinfrastruktur ist; sie werden als Informatik-Projekte bezeichnet (vgl. Kapitel Einführung). Generelle Aufgabe des Managements von Informatik-Projekten ist es, die Rahmenbedingungen zu schaffen, die zur Erreichung der Planungsziele, die ein Projekt begründen, erforderlich sind (Projektmanagement-Methodik). Die Projektmanagement-Methodik muß so allgemeingültig sein, daß sie für jede Art von Informatik-Projekt (z.B. unabhängig davon, ob es sich um Eigenentwicklung oder Fremdentwicklung, um Software- oder Hardware-Beschaffung handelt) verwendbar ist, und sie muß in geeigneter Weise dokumentiert sein (Projekthandbuch, vgl. Lerneinheit PROHB). "Geeignet" heißt dabei vor allem, daß die Methodik mit Hilfe des Projekthandbuchs von den Projektmitarbeitern "gelebt" werden kann. Aus dieser generellen Aufgabe des Projektmanagements ergeben sich die folgenden Teilaufgaben: • das Formulieren des Projektauftrags mit den Planungszielen sowie den Rahmenbedingungen und Auflagen für die Projektabwicklung (Projektdefinition); • das Festlegen der Form der Projektorganisation, das Ernennen der Projektleitung und das Festlegen ihrer Kompetenzen (Projektorganisation); • das Bestimmen des technisch möglichen und wirtschaftlich geeigneten Projektablaufs (Vorgehensmodell); • das Ableiten der Projektziele und Projektaufgaben aus den Planungszielen sowie das Festlegen der Projektphasen und der Meilensteine zwischen den einzelnen Phasen (Projektplanung); • das Beobachten des Projektverlaufs, das Feststellen von Abweichungen von den Projektzielen sowie das Festlegen der Projektberichterstattung und der Projektdokumentation (Projektüberwachung); • das Festlegen von Maßnahmen für den Fall, daß Abweichungen zwischen dem geplanten Projektverlauf und dem tatsächlichen Projektverlauf festgestellt werden sowie das Durchführen dieser Maßnahmen (Projektsteuerung); • die Motivation der Projektmitarbeiter und die Förderung der Zusammenarbeit zwischen allen an einem Projekt Beteiligten durch Teamarbeit und kooperative Führung (Projektführung). Ausgangspunkt für eine Systematik der Aufgaben des Projektmanagements sind die Planungsziele. Von den Planungszielen ausgehend, werden die Aufbauorganisation (Projektorganisation) und die Ablauforganisation (Vorgehensmodell) festgelegt. Mit der Projektorganisation wird eine zeitlich auf die Projektdauer befristete, der Projektaufgabe angemessene Aufbauorganisation mit auf konkrete Personen bezogenen Kompetenzen und Verantwortungen geschaffen. Zur Aufbauorganisation gehört im allgemeinen ein Projektsteuerungsgremium.

PROMA - Aufgaben des

Projektmanagements

21

Mit dem Vorgehensmodell wird die Ablauforganisation festgelegt. Bei Informatik-Projekten sollte das Vorgehensmodell jedoch nicht projektbezogen geschaffen, sondern als grundlegende Qualitätsmaßnahme im Unternehmen vorhanden sein und - je nach Projektgegenstand - angepaßt werden. Projektorganisation und Vorgehensmodell bilden die Grundlage für die Projektplanung, die Projektführung und das Projektcontrolling. Abbildung PROMA-1 veranschaulicht die Struktur der Aufgaben des Projektmanagements. Ablauforganisation: Bestimmung des technisch und wirtschaftlich geeigneten Projektablaufs mit eindeutigen Ergebnissen

Autbauorganisation: A u f b a u einer zeitlich befristeten, für d i e A u f g a b e geeigneten Projektorganisation mit personi fizierten Verantwortungen Planung:

Controlling: Laufende Ü b e r w a c h u n g und sofortige Steuerung bei A b w e i c h u n g e n f ü r alle Randbedingungen, Ziele und Ergebnisse

Planung von realistischen und abgestimmten Leistungen, Terminen, Kapazitäten und Kosten

Führung:

Motivation, E n g a g e m e n t und Zusammenarbeit aller Betroffenen (Teamarbeit, kooperative Führung)

A b b . P R O M A - 1 : Aufgaben des Projektmanagements (Quelle: nach Platz)

P l a n u n g s z i e l e und

Projektziele

Zur Unterscheidung zwischen den vom Auftraggeber dem Projekt vorgegebenen Zielen und den daraus von der Projektleitung abgeleiteten Zielen werden erstere als Planungsziele und letztere als Projektziele bezeichnet. Planungsziele sind in der Regel grobe, die Projektaufgabe als Ganzes betreffende Ziele (z.B. die Funktionalität als Leistungsziel, der Endtermin als Terminziel, die Gesamtkosten als Kostenziel). Projektziele sind aus den Planungszielen abgeleitete Ziele; sie sind Teilziele der Planungsziele (z.B. die Fertigstellungstermine für einzelne Komponenten des Projektgegenstands als Terminziele). Beim Ableiten der Projektziele aus den Planungszielen entsteht ein Zielsystem, das meist hierarchisch ist, aber auch die Form eines Netzes haben kann. Je feiner die Projektziele formuliert werden, desto straffer kann das Projekt überwacht und gesteuert werden, vice versa. Planungsziele müssen zwischen Auftraggeber und Auftragnehmer, Projektziele müssen zwischen Projektleitung und Projektmitarbeitern klar vereinbart und akzeptiert sein. Daher empfiehlt sich für Z i e l v e r e i n b a r u n g e n zwischen Auftraggeber und Auftragnehmer bzw. zwischen Projektleitung und Projektmitarbeitern ein partizipativer Prozeß. Wegen der speziellen Ausrichtung der Ziel-

22

Grundlagen

Projektmanagement

planung auf den Projektgegenstand, wird darauf im Zusammenhang mit IuKProjekten näher eingegangen (vgl. Lerneinheit ZIELP). Führungskonzept Für die Projektführung stellt sich die Frage, nach welchem Modell oder Konzept sie erfolgen soll. Bei der Erläuterung der Planungs- und Projektziele wurde bereits auf die Zweckmäßigkeit eines partizipativen Vorgehens bei Zielvereinbarungen zwischen Projektleitung und Projektmitarbeitern hingewiesen. Dieses Vorgehen ist das wesentliche Merkmal des Führungskonzepts Management by Objectives (Führung durch Zielvereinbarung). Weitere Voraussetzungen für die Wirksamkeit dieses Führungskonzepts sind, daß die vereinbarten Ziele: • • • •

mit übergeordneten Zielen nicht konfliktär sind; klar und nachvollziehbar formuliert sind; grundsätzlich erreichbar sind; flexibel sind, sodaß sie gegebenenfalls neu vereinbart werden können.

Aus Zielvereinbarungen dieser Art folgt für die Projektüberwachung und -Steuerung, daß Fremdüberwachung und Fremdsteuerung weitgehend durch Eigenüberwachung und Eigensteuerung ersetzt werden. Fremdüberwachung wird im wesentlichen auf Ergebnisüberwachung reduziert, während die Überwachung der Tätigkeiten und der zu ihrer Verrichtung verwendeten Verfahren, Regeln, Methoden, Werkzeuge usw. in die Verantwortung der Projektmitarbeiter fällt. Wegen der Vielfalt und Komplexität der genannten Aufgaben erfolgt eine vertiefte Darstellung in mehreren Lernheiten, und zwar wie folgt: • • • • • •

Zielplanung in Lerneinheit ZIELP; Projektorganisation in Lerneinheit PRORG; Projektverantwortung in Lerneinheit PROVE; Vorgehensmodell in Lerneinheiten WERIP und VORMO; Projektplanung, -Überwachung und -Steuerung in Lerneinheit PROPL; Projektcontrolling in Lerneinheit PCONT.

Erfolgsfaktoren des Projektmanagements Zweck der Projektmanagement-Methodik ist letztlich die Berücksichtigung aller die Projektabwicklung bestimmenden Einflußfaktoren so, daß die Projektziele mit einer kalkulierbaren Wahrscheinlichkeit erreicht werden. Diese Aussage veranschaulicht Abbildung PROMA-2, in der die im Kreis angeordneten Eigenschaften auf den im Zentrum angeordneten Projekterfolg (dort als "effiziente Projektbearbeitung" bezeichnet) verweisen. Eigenschaften der genannten Art werden daher als Erfolgsfaktoren des Projektmanagements bezeichnet.

PROMA - Aufgaben des

Projektmanagements

23

Abb. PROMA-2: Erfolgsfaktoren des Projektmanagements (Quelle: nach Zielasek)

Projektmanagement-System Projektplanung, -Überwachung und -Steuerung sowie dafür eingesetzte Sachmittel werden zusammenfassend als Projektmanagement-System bezeichnet. Sein besonderes Kennzeichen ist die Verwendung von bestimmten Methoden (z.B. Methoden der Netzplantechnik, vgl. Lerneinheit NETZP) und von Betriebsmitteln, die diese Methoden unterstützen (insbes. Software-Systeme). Erfolgreiches Projektmanagement ist ohne Technologieunterstützung - zumindest bei größeren Projekten - nicht möglich. Technologieunterstützung sollte dialogorientiert sein, sodaß die Projektmitarbeiter Daten selbst erfassen, Auswertungen selbst veranlassen und diese unmittelbar am Arbeitsplatz verfügbar haben können. Technologieunterstützung für größere Einzelaufgaben (z.B. das Plotten umfangreicher Netzpläne) kann im Stapelbetrieb erfolgen. Für kleinere Projektmanagement-Systeme reichen PCs und entsprechende Anwendungsprogramme aus; auf dem Informatik-Markt sind zahlreiche Produkte verfügbar (vgl. den ISIS-Katalog). Bereits mittlere Projektumfänge können die Leistungsfähigkeit dieser Betriebsmittel schnell übersteigen. Die meisten Projektmanagement-Systeme unterstützen Planungs-, Verwaltungsund Abrechnungsaufgaben, jedoch kaum die operativen Tätigkeiten bei der Projektabwicklung. Daher bietet sich die Ergänzung traditioneller Systeme durch eine C S C W - K o m p o n e n t e an. Typische Aktivität einer CSCW-Komponente ist das Abstimmen von Terminen und das Führen eines zentralen Terminkalenders

24

Grundlagen

Projektmanagement

und mehrerer dezentraler Terminkalender für die Mitglieder einer Projektgruppe. Kontrollfragen 1. 2. 3. 4. 5.

Wie kann die generelle Aufgabe des Projektmanagements beschrieben werden? Welche Teilaufgaben des Projektmanagements werden unterschieden? Was wird mit der Projektorganisation und was mit dem Vorgehensmodell festgelegt? Wodurch unterscheiden sich Planungsziele von Projektzielen? Was heißt "Führen durch Zielvereinbarung"?

Quellenliteratur Grün, O.: Projektorganisation. In: Frese, E. (Hrsg.): Handwörterbuch der Organisation, 3. A., Poeschel, Stuttgart 1992, 2 1 0 2 - 2 1 2 7 Haberfellner, R.: Projektmanagement. In: Frese, E. (Hrsg.): Handwörterbuch der Organisation, 3. A., Poeschel, Stuttgart 1992, 2090 - 2102 Heinrich, L. J.: Systemplanung 2 Bd. 6. A. (Bd. 1) bzw. 5. A. (Bd. 2), Oldenbourg, München/Wien 1994 Kummer, A. et al.: Projekt-Management. Leitfaden zu Methode und Teamführung in der Praxis. 3. A., Industrielle Organisation, Zürich 1993 Zielasek, G.: Projektmanagement. Erfolgreich durch Aktivierung aller Unternehmensebenen. Springer, Berlin et al. 1995 Zur, E.: Strukturierung komplexer Führungsaufgaben und Systemaufbau. In: Spremann, K. und Zur, E. (Hrsg.): Informationstechnologie und strategische Führung. Gabler, Wiesbaden 1989, 81 - 105 Vertiefungsliteratur Cave, W. C./Maymon, G. W.: Leitfaden des Software-Projektmanagements. Forkel, Wiesbaden 1988 Frühauf, K. et al.: Software-Projektmanagement und -Qualitätssicherung. 2. A., Teubner, Stuttgart 1991 Hansel, J./Lomnitz, G.: Projektleiter-Praxis - Erfolgreiche Projektabwicklung durch verbesserte Kommunikation und Kooperation. Springer, Berlin et al. 1987 Kurbel, K./Pietsch, W.: Projektmanagement bei einer Expertensystem-Entwicklung. In: Information Management 1/1988, 6-13 Kurbel, K./Dornhoff, P.: Mehr Flexibilität: Ein innovativer Ansatz für das Software-Projektmanagement. In: HMD - Theorie und Praxis der Wirtschaftsinformatik 170/1993, 111 - 127 Madauss, B. J.: Handbuch Projektmanagement. 4. A., Poeschel, Stuttgart 1991 Platz, J./Schmelzer, H. J.: Projektmanagement in der industriellen Forschung und Entwicklung Einführung anhand von Beispielen aus der Informationstechnik. Springer, Berlin et al. 1986 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. Teubner, Stuttgart 1991,47 - 58 Wischnewski, E.: Modernes Projektmanagement - Eine Anleitung zur effektiven Unterstützung der Planung, Durchführung und Steuerung von Projekten. Vieweg, Braunschweig/Wiesbaden 1991 Zehnder, C. A.: Informatik-Projektentwicklung. 2. A., Teubner, Zürich 1991 Normen Deutsches Institut für Normung (Hrsg.): DIN 69901 - Projektmanagement, Begriffe. Beuth, Berlin 1987

PRORG - Projektorganisation Lernziele Sie kennen die Aufgabe des Projektmanagements und die daraus abgeleiteten Teilaufgaben. Sie kennen die Formen der Projektorganisation und können diese erläutern. Sie kennen die Aufbauorganisation innerhalb der Projektgruppe sowie die Bedeutung der Beteiligung der vom Projekt Betroffenen an der Projektarbeit. Definitionen und Abkürzungen Kompetenz (competence) = der Handlungsspielraum eines Aufgabenträgers, der zur ordnungsgemäßen Aufgabenerfüllung notwendig ist. Konflikt (conflict) = eine durch Interessensgegensätze gekennzeichnete Beziehung zwischen Individuen oder Gruppen. Meilenstein (milestone) = ein Hilfsmittel des Projektmanagements zur Orientierung über den Projektverlauf und zur Projektlenkung ("Weichenstellung"). Planungsziel (planning goal) = ein Ziel, das vom strategischen Informationsmanagement gesetzt und der Projektleitung vorgegeben wird. Produktmanager (product manager) = ein Aufgabenträger für die Aufgabe der Betreuung eines IuK-Systems über dessen gesamten Lebenszyklus hinweg. Projektgruppe (project team) = die für ein Projekt eingesetzten Personen, die von der Projektleitung geführt werden. Synonym: Projektteam. Projekthandbuch (project manual) = ein Dokument mit der unternehmensweit verbindlichen, für jedes Projekt geltenden Projektmanagement-Methodik. Projektkoordinator (project coordinator) = die Bezeichnung für den Projektleiter bei der Einfluß-Projektorganisation. Synonym: Projektverfolger. Projektleiter (project manager) = die für die Projektleitung verantwortliche Person. Projektleitung (project management) = die für die Dauer eines Projekts geschaffene Organisationseinheit, die für die Planung, Überwachung und Steuerung dieses Projekts verantwortlich ist. P r o j e k t o r g a n i s a t i o n (project Organization) = die Gesamtheit der O r g a n i s a -

tionseinheiten und der struktur- und ablauforganisatorischen Regelungen zur Abwicklung eines Projekts. Projektziel (project goal) = ein Ziel, das aus den Planungszielen abgeleitet und zur Planung, Überwachung und Steuerung eines Projekts verwendet wird. Rückfallsystem (fallback system) = ein stabiler Projektstatus, auf den für den Fall zurückgekehrt werden kann, daß das Projekt notleidend wird und von dem aus eine erfolgreiche Projektfortführung möglich ist. Stab (staff) = eine Struktureinheit zur spezialisierten Unterstützung von Struktureinheiten in der Linie. Synonym: Stabsstelle. Verantwortung (responsibility) = eine mit der Übertragung einer Aufgabe auf einen Aufgabenträger verbundene Verpflichtung.

26

Grundlagen

Projektmanagement

Aufgabe der Projektorganisation Projektorganisation als Aufgabe des Projektmanagements meint das Festlegen der Form der Projektorganisation, das Ernennen der Projektleitung (Projektleiter oder Projektleitungsteam, vgl. Lerneinheit PROVE) und damit im Zusammenhang das Festlegen der Projektverantwortung. Mit der Projektorganisation werden die struktur- und die ablauforganisatorischen Merkmale des Projektmanagements bestimmt. Dazu gehören auch die Aufbauorganisation innerhalb der Projektgruppe sowie die Art der Beteiligung der vom Projekt Betroffenen (z.B. potentielle Benutzer eines Informationssystems als Produkt eines IuK-Projekts). Wesentliches ablauforganisatorisches Merkmal eines Projekts ist ein Vorgehensmodell, auf das kurz eingegangen und das an anderer Stelle exemplarisch für ein IuK-Projekt erläutert wird (vgl. Lerneinheit VORMO). Inhaltlicher Schwerpunkt der folgenden Darstellung sind die sog. Formen der Projektorganisation. Es werden folgende Formen unterschieden: Einfluß-Projektorganisation (auch: Stabs-Projektorganisation, Projektorganisation mit Stäben oder Projektkoordination), reine Projektorganisation (auch: unabhängige Projektorganisation oder Task Force), Matrix-Projektorganisation und Projektorganisation in Verbindung mit Linieninstanzen. Eine "lose Form" der Projektorganisation ist ein Arbeitskreis oder eine Kommission, der bzw. die aus ihrer Mitte einen Sprecher bestimmt.

Abb. PRORG-1: Einfluß-Projektorganisation (Quelle: Kummer et al.)

Einfluß-Projektorganisation Bei der Einfluß-Projektorganisation bleibt die funktionale Hierarchie im Unternehmen unverändert; die Projektgruppe besteht aus Mitarbeitern der bestehenden und vom Projekt betroffenen Organisationseinheiten (in Abbildung PRORG-1 mit 1, 2, 3 in den Abteilungen A, B, C gekennzeichnet). Die Unternehmensleitung kann die Projektarbeit entscheidend beeinflussen und auch im Detail darauf einwirken. Die Projektleitung (PL) berichtet an die Unternehmensleitung; sie hat lediglich beratende, koordinierende und entscheidungsvorbereitende Funktionen,

PRORG - Projektorganisation

27

ist also primär Projektverfolger und Projektkoordinator. Sie verfolgt und koordiniert den Projektablauf in sachlicher, terminlicher und kostenmäßiger Hinsicht und schlägt im Bedarfsfall den zuständigen Linieninstanzen Maßnahmen vor, deren Durchführung möglich oder notwendig ist. Der Projektkoordinator hat keine Entscheidungs- und Weisungsbefugnis; er kann daher für die Erreichung bzw. Nichterreichung der Projektziele nicht verantwortlich gemacht werden. Vorteile der Einfluß-Projektorganisation sind: • flexibler Personaleinsatz, da die Mitarbeiter sowohl im Projekt als auch in der Linieninstanz arbeiten und in verschiedenen Projekten mitarbeiten können; • geringer organisatorischer Aufwand, da keine Veränderung der bestehenden Strukturorganisation erforderlich ist. Nachteile der Einfluß-Projektorganisation sind: • Es fühlt sich niemand für das Projekt voll verantwortlich. • Die Reaktionsgeschwindigkeit bei der Bearbeitung von Projektabweichungen ist gering. • Das Bedürfnis der Projektmitarbeiter, Schwierigkeiten über Abteilungsgrenzen hinweg gemeinsam zu überwinden, ist gering.

Abb. PRORG-2: Reine Projektorganisation (Quelle: Kummer et al.)

Reine

Projektorganisation

Bei der reinen Projektorganisation bilden die Projektmitarbeiter eine Organisationseinheit unter der fachlichen und disziplinarischen Führung der Projektleitung, die volle Kompetenz in bezug auf Projektmitarbeiter, Betriebsmittel und Budget hat und volle Projektverantwortung gegenüber einer Leitungsinstanz (z.B. der Unternehmensleitung) trägt. Die Projektmitarbeiter (in der Regel eigene Mitarbeiter, gelegentlich auch Externe) arbeiten während der Projektdauer nur für das Projekt (in Abbildung PRORG-2 durch die eingeklammerten Ziffern 1, 2, 3 in den Abteilungen A, B, C gekennzeichnet). Sie erhalten Anweisungen nur von der Projektleitung. Vorteile der reinen Projektorganisation sind:

28

Grundlagen

Projektmanagement

• der einheitliche Wille durch die Linienautorität der Projektleitung; • die schnelle Reaktionsfähigkeit bei Abweichungen von den Projektzielen; • die hohe Identifikation der Projektmitarbeiter mit den Projektzielen. Schwierigkeiten können bei der reinen Projektorganisation bei der Rekrutierung der Projektmitarbeiter und ihrer Verwendung nach Projektende auftreten (Woher kommen sie bei Projektbeginn und wohin gehen sie, wenn das Projekt beendet ist?). Eine Klärung bzw. Vereinbarung über den Verbleib nach Projektende sollte bereits bei der Rekrutierung der Projektmitarbeiter erfolgen.

Matrix-Projektorganisation Die Matrix-Projektorganisation ist eine Kombination der Einfluß-Projektorganisation mit der reinen Projektorganisation. Die Projektleitung ist für die Projektplanung, -Überwachung und -Steuerung verantwortlich (Vorgehensverantwortung); für die projektbezogenen fachlichen Aufgaben sind die Linieninstanzen verantwortlich. Die Projektmitarbeiter werden temporär in die Projektgruppe delegiert; sie unterstehen fachlich der Projektleitung, disziplinär ihrem Linienvorgesetzten (in Abbildung PRORG-3 durch Pfeile auf die Mitarbeiter 1, 2, 3 in den Abteilungen A, B, C gekennzeichnet). Die Projektmitarbeiter bearbeiten die ihnen zugeordneten Projektaufgaben in ihren Struktureinheiten. Die Matrix-Projektorganisation schafft für die Projektdauer eine für die Projektkoordinierung zuständige Organisationseinheit. Die Funktionsfähigkeit dieser Organisationseinheit ist auf ein gut entwickeltes Organisations- und Führungsverständnis aller Beteiligten angewiesen. Vorteile der Matrix-Projektorganisation sind: • Die Projektleitung und die Projektmitarbeiter fühlen sich für das Projekt voll verantwortlich.

PRORG - Projektorganisation

29

• Ein flexibler Personaleinsatz ist - wie bei der Einfluß-Projektorganisation möglich. • Spezialwissen und besondere Erfahrungen können gezielt eingesetzt werden. • Die Projektmitarbeiter sind aus ihrer gewohnten Arbeitsumgebung nie ganz herausgelöst und können nach Projektende problemlos zurückkehren. Wesentlicher Nachteil der Matrix-Projektorganisation ist, daß es an den Schnittstellen zwischen dem projektbezogenen und dem funktionsbezogenen Weisungssystem ("Projekt" einerseits, "Linie" andererseits) zu Konflikten kommen kann (Weisungskonflikt). Die aus einem Weisungskonflikt resultierende Verunsicherung von Vorgesetzten (Verzicht auf Ausschließlichkeitsanspruch) und von Mitarbeitern ("Diener zweier Herren") kann nur durch eine klare Abgrenzung von Kompetenz und Verantwortung vermieden werden; Konfliktpotential ist trotzdem latent vorhanden. Ein geeignetes Darstellungsmittel zur Dokumentation der Abgrenzung ist die sog. Verantwortungsmatrix. In den Zeilen der Matrix stehen die Projektaufgaben, in den Spalten die Aufgabenträger; mit der Art der Eintragungen kann sichtbar gemacht werden, welche Verrichtungen die Aufgabenträger an den Projektaufgaben durchführen sollen (z.B. P = Planung, E = Entscheidung, A = Ausführung, M = Mitwirkung). Projektorganisation in Verbindung mit Linieninstanzen Bei dieser Form der Projektorganisation sind die Aufgaben des Linienvorgesetzten und die der Projektleitung in einer Person vereinigt, nämlich in der des Linienvorgesetzten. Der Projektleiter/Linienvorgesetzte hat alle notwendigen Kompetenzen und trägt die volle Projektverantwortung. Betroffenenbeteiligung Benutzerbeteiligung kann in unterschiedlichem Ausmaß, auf verschiedenen Managementebenen und in verschiedenen Phasen des Projekts erfolgen. Übliche Formen der Benutzerbeteiligung sind die frühzeitige und regelmäßige Information über die Projektaufgabe und den Projektablauf, die Befragung der Benutzer hinsichtlich ihrer Anforderungen, die Mitwirkung von Kontaktpersonen der Fachabteilungen (Koordinatoren) sowie die Mitarbeit der Benutzer selbst bzw. ihrer Repräsentanten in der Projektgruppe (wegen Einzelheiten vgl. Lerneinheit BEBET). Aufbauorganisation der Projektgruppe Für die Aufbauorganisation innerhalb der Projektgruppe sind die Größe der Gruppe und die Arbeitsteilung zwischen den Gruppenmitgliedern, einschließlich der Projektleitung, ausschlaggebend. Bei größeren Projektgruppen kann es zweckmäßig sein, Teilgruppen (Spezialistenteams) zu bilden, denen Teile des Projektumfangs zur weitgehend selbständigen Bearbeitung übertragen werden. Die Spezialistenteams müssen dann von einer übergeordneten Instanz koordiniert werden, wobei die Leiter der Spezialistenteams Mitglieder dieser Koordinie-

30

Grundlagen

Projektmanagement

rungsinstanz sein sollten. Der Leiter der Koordinierungsinstanz trägt die Gesamtverantwortung für das Projekt. Eine mögliche Organisationsform bei IuK-Projekten ist die des Chef-Programmierer-Teams. Mit dieser Organisationsform wird versucht, die Nachteile "klassischer Projektmodelle" zu vermeiden. Der Projektleiter ist beim Chef-Programmierer-Team nicht nur für alle Arbeiten verantwortlich, sondern er führt sie zum größten Teil auch selbst durch; die anderen Projektmitglieder assistieren ihm dabei. Ein nach diesem Modell organisiertes IuK-Projekt soll nicht mehr als zehn Mitarbeiter umfassen. Projekt-Vorgehensmodell Siehe dazu Abschnitt "Phasenschema und Vorgehensmodell" in Lerneinheit WERIP sowie Lerneinheit VORMO. Forschungsbefunde Kurbel/Pietsch zeigen, daß für die Entwicklung von Expertensystemen "konventionelle Vorgehensweisen" der Projektorganisation nicht zweckmäßig sind. Sie entwerfen eine auf die Anforderungen der Expertensystem-Entwicklung abgestimmte Projektorganisation. Weitergehende Forschungsarbeiten haben das Ziel, das Projektmanagement durch ein umfassendes, computergestütztes Werkzeug zu unterstützen. Kontrollfragen 1. 2. 3. 4. 5.

W a s wird mit der Projektorganisation geregelt? W e l c h e Formen der Projektorganisation gibt es? W e l c h e Vor- und Nachteile haben die verschiedenen Formen der Projektorganisation? Was wird mit Hilfe einer Verantwortungsmatrix dokumentiert? Worin besteht die Besonderheit eines Chef-Programmierer-Teams?

Quellenliteratur G r ü n , O.: P r o j e k t o r g a n i s a t i o n . In: Frese, E. (Hrsg.): H a n d w ö r t e r b u c h der Organisation, 3. A., Poeschel, Stuttgart 1992, 2 1 0 2 - 2127 Haberfellner, R.: P r o j e k t m a n a g e m e n t . In: Frese, E. (Hrsg.): H a n d w ö r t e r b u c h der Organisation, 3. A „ Poeschel, Stuttgart 1992, 2 0 9 0 - 2102 K u m m e r , A. 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., Industrielle Organisation, Zürich 1993 Kurbel, K.: Unterstützung kooperativen Arbeitens beim Softwareprojekt-Management. In: Information M a n a g e m e n t 4/1993, 50 - 58 Heinrich, L. J.: S c h w a c h s t e l l e n 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 R e c h t 7/1988,584 - 587 Heinrich, L. J.: S y s t e m p l a n u n g 2 Bd. 6. A. (Bd. 1) bzw. 5. A. (Bd. 2), O l d e n b o u r g , M ü n c h e n / Wien 1994 Z i e l a s e k , G.: P r o j e k t m a n a g e m e n t . Erfolgreich durch Aktivierung aller U n t e r n e h m e n s e b e n e n . Springer, Berlin et al. 1995

PRORG - Projektorganisation

31

Vertiefungsliteratur H a n s e l , J . / L o m n i t z , G.: P r o j e k t l e i t e r - P r a x i s - E r f o l g r e i c h e P r o j e k t a b w i c k l u n g d u r c h verbesserte K o m m u n i k a t i o n und K o o p e r a t i o n . Springer, Berlin et al. 1987 H o f s t e t t e r , H.: O r g a n i s a t i o n s p s y c h o l o g i s c h e A s p e k t e d e r S o f t w a r e - E n t w i c k l u n g . In: S c h e l l e , H. u n d M o l z b e r g e r , P.: P s y c h o l o g i s c h e A s p e k t e der S o f t w a r e - E n t w i c k l u n g . O l d e n b o u r g , M ü n chen/Wien 1 9 8 3 , 2 5 - 6 2 K u r b e l , K . / P i e t s c h , W.: P r o j e k t m a n a g e m e n t bei einer E x p e r t e n s y s t e m - E n t w i c k l u n g . In: I n f o r mation M a n a g e m e n t 1/1988, 6-13 Kurbel, K . / D o r n h o f f , P.: M e h r Flexibilität: Ein innovativer Ansatz für das 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 . In: H M D - T h e o r i e und Praxis der W i r t s c h a f t s i n f o r m a t i k 170/1993, 1 1 1 - 1 2 7 M a d a u s s , B. J.: H a n d b u c h P r o j e k t m a n a g e m e n t . 4. A., Poeschel, Stuttgart 1991 Platz, J . / S c h m e l z e r , H. J.: P r o j e k t m a n a g e m e n t in der industriellen F o r s c h u n g u n d E n t w i c k l u n g E i n f ü h r u n g anhand von Beispielen aus der Informationstechnik. Springer, Berlin et al. 1986 W i s c h n e w s k i , E.: M o d e r n e s P r o j e k t m a n a g e m e n t - Eine A n l e i t u n g zur e f f e k t i v e n U n t e r s t ü t z u n g der P l a n u n g , D u r c h f ü h r u n g u n d S t e u e r u n g von Projekten. V i e w e g , B r a u n s c h w e i g / W i e s b a d e n 1991 Z e h n d e r , C . A.: I n f o r m a t i k - P r o j e k t e n t w i c k l u n g . 2. A., T e u b n e r , Zürich 1991

Normen D e u t s c h e s Institut für N o r m u n g (Hrsg.): D I N 6 9 9 0 1 - P r o j e k t m a n a g e m e n t , B e g r i f f e . B e u t h , Berlin 1987

PROPL - Projektplanung, -Überwachung und -Steuerung Lernziele Sie können die Aufgabe der Projektplanung in Teilaufgaben zerlegen und die Teilplanungen beschreiben. Sie erkennen den Zusammenhang, der zwischen den Teilplanungen besteht. Sie können die Zweckmäßigkeit von Realisierungsstrategien für die Projektplanung beurteilen. Sie kennen die Bedeutung der Projektüberwachung und der Projektsteuerung für den Projekterfolg und können diese Aufgaben erläutern. Definitionen und Abkürzungen Arbeitspaket (work package) = eine Menge von Tätigkeiten, die durch Aufgabenanalyse und gegebenenfalls Aufgabensynthese ermittelt und einem Aufgabenträger zugeordnet wird. Lenkungsausschuß (steering committee) = die organisatorische Instanz, welche die Planungsziele vorgibt und die IuK-Projekte unternehmensweit steuert. Meilenstein (milestone) = ein markanter Zeitpunkt im Projektverlauf, meist am Anfang oder Ende einer Projektphase; ein Hilfsmittel zur Orientierung über den Projektverlauf und zur Projektlenkung ("Weichenstellung"). Nicht-Ziel (non-objective) = ein ausdrücklich nicht als Planungsziel vereinbartes Phänomen. Priorität (priority) = die Vorziehenswürdigkeit einer Handlung, einer Sache, eines Vorhabens usw. auf Grund der Beurteilung der Alternativen mit bestimmten Kriterien. Projektauftrag (project Order) = ein Dokument, in dem die Planungsziele und die Rahmenbedingungen zur Erreichung der Planungsziele beschrieben sind. Projekthandbuch (project manual) = ein Dokument mit der unternehmensweit verbindlichen, für jedes Projekt geltenden Projektmanagement-Methodik. Projektkontrolle (project audit) = die nachträgliche Beurteilung des Projektverlaufs und seiner Ergebnisse durch projektunabhängige Personen. Projektkoordinator (project coordinator) = die Bezeichnung für den Projektleiter bei der Einfluß-Projektorganisation. Synonym: Projektverfolger. Projektphase (project phase) = eine nach zeitlichen und logischen Gesichtspunkten gebildete Teilmenge der Projektaufgabe. Synonym: Projektabschnitt. Projektrisiko (project risk) = das Produkt aus Eintrittswahrscheinlichkeit der Nichterreichung eines Projektziels und der daraus folgenden Schadenshöhe. Projektumfang (project scope) = die Art und Menge der zur Erreichung der Projektziele zu bearbeitenden Projektaufgaben und ihre Komplexität. Rückfallsystem (fallback system) = ein stabiler Projektstatus, auf den für den Fall zurückgekehrt werden kann, daß das Projekt notleidend wird und von dem aus eine erfolgreiche Projektfortführung möglich ist. Spezifikation (specification) = ein Dokument, in dem die aus den Planungszielen abgeleiteten Projektanforderungen beschrieben sind.

PROPL - Projektplanung,

-Überwachung und -Steuerung

33

Aufgabe der Projektplanung Aufgabe der Projektplanung ist es, die zur Erreichung der Planungsziele erforderlichen Tätigkeiten einschließlich aller für ihre Abwicklung erforderlichen Hilfsmittel so vorwegzudenken, daß ihre Durchführung mit hoher Wahrscheinlichkeit zur Erreichung der Planungsziele führt. Projektplanung ist Voraussetzung für Projektüberwachung und -Steuerung und damit generell der Schlüssel zum Projekterfolg. Daher müssen alle für den Projekterfolg wichtigen Gesichtspunkte vorgedacht und ihre Vorgänge und Ereignisse mit - möglichst quantitativen - Planwerten, an denen sich die Projektabwicklung orientieren kann, belegt werden. Die Projektplanung muß die Planungsziele in Projektziele überführen und die Realisierbarkeit der Planungsziele überprüfen. Bei der Überprüfung der Realisierbarkeit der Planungsziele geht es in erster Linie um das Herausarbeiten der personellen, technischen, zeitlichen und finanziellen Ressourcen (Projektanforderungen), die zur Erreichung der Planungsziele erforderlich sind. Grundlage für die Projektplanung ist ein klar definierter, schriftlich dokumentierter Projektauftrag, der vom Auftraggeber der Projektleitung (bei einem internen Auftragnehmer) bzw. dem Auftragnehmer erteilt wird. Dieser kann für das gesamte Projekt oder phasenweise (d.h. jeweils für eine einzelne Projektphase) vereinbart werden. Je geringer der Informationsstand über die Projektaufgabe, je größer der Projektumfang und je komplexer das Projekt ist, desto mehr empfiehlt sich ein phasenweiser Projektauftrag (z.B. bei einem IuK-Projekt zunächst für die Vorstudie und nach der am Ende der Vorstudie getroffenen Grundsatzentscheidung für eine bestimmte Problemlösung für die nächste Projektphase oder auch für alle folgenden Projektphasen). Die inhaltliche Präzisierung des Projektauftrags erfolgt in einer Projekt-Vorphase, die als Spezifikationsphase bezeichnet wird. Ergebnis der Spezifikationsphase ist ein Pflichtenheft oder Lastenheft (vgl. Lerneinheit PFLIC). Projektstrukturierung Bei großem Projektumfang und hoher Projektkomplexität (z.B. gemessen an der Anzahl Beteiligter, an der Neuartigkeit und/oder am Schwierigkeitsgrad) empfiehlt sich eine Zerlegung in Teilprojekte. Sie kann primär funktionsorientiert nach Projektphasen oder primär objektorientiert nach Systemteilen oder gemischt erfolgen. Letzteres heißt, daß innerhalb der funktionsorientiert gebildeten Projektphasen objektorientiert nach Systemteilen zerlegt wird (z.B. bei einem IuK-Projekt in die Systemteile Datensystem, Methodensystem, Transportsystem und Sicherungssystem in der Projektphase Systementwurf). Die Zerlegung eines IuK-Projekts in Projektphasen wird in anderen Lerneinheiten ausführlich behandelt (vgl. insbes. Kapitel Projektphasen). Für jedes Teilprojekt ist ein Projektauftrag zu erteilen. Inhalte des Projektauftrags sind: Ausgangssituation, Planungsziele, Aufgabenabgrenzung, Form der Projektorganisation, Projektleitung, Zusammensetzung der Projektgruppe, Mei-

34

Grundlagen

Projektmanagement

lensteine, Berichtsinstanz, Projektergebnis. Da die Planungsziele von grundsätzlicher Bedeutung für das Verständnis der Projektaufgabe und damit auch für die Abschätzung des Projektumfangs sind, entsteht der Projektauftrag in der Regel als Ergebnis eines Diskussionsprozesses zwischen Auftraggeber und (potentiellem) Auftragnehmer. Ein Projektauftrag sollte weder vage noch sollte er so detailliert sein, daß er keinen Spielraum für Kreativität in der Projektgruppe bietet, sofern Kreativität nicht ausdrücklich vom Auftraggeber ausgeschlossen wird. Am Ende der Projektarbeit sollte eine Projektkontrolle im Sinn einer Manöverkritik stattfinden (Projektrückschau). Projektkontrolle darf nicht mit Projektüberwachung und -Steuerung (Projektcontrolling) verwechselt werden. In Ergänzung zu den Planungszielen sollten Nicht-Ziele vereinbart werden (z.B. Funktionen, die ein IuK-System ausdrücklich nicht haben soll). Damit wird der Projektauftrag präzisiert. Trotzdem verbleiben potentielle Ziele, die erst im Projektverlauf sichtbar werden und die weder ausdrücklich gefordert noch ausdrücklich ausgeschlossen wurden. Sie können Ursache für Konflikte zwischen Auftraggeber und Auftragnehmer sein. Form der Projektorganisation Die zuständige Leitungsinstanz für die Entscheidung Uber die Form der Projektorganisation (vgl. Lerneinheit PRORG), die für ein Informatik-Projekt verwendet werden soll, wird im allgemeinen als Lenkungsausschuß bezeichnet. Die Entscheidung orientiert sich an einer Reihe von Beurteilungskriterien. Abbildung PROPL-1 zeigt zehn Beurteilungskriterien mit Kriterienerträgen für drei Formen der Projektorganisation, die zur Auswahl der geeigneten Projektorganisation verwendet werden können. Daraus ist unter anderem ersichtlich, daß bei einem großen Projektumfang die Eignung der Einfluß-Projektorganisation gering, die der Matrix-Projektorganisation groß und die der reinen Projektorganisation sehr groß ist. Bei mittleren und großen Unternehmen sowie bei großen Projektumfängen hat sich die Matrix-Projektorganisation am stärksten durchgesetzt. Als Begründung wird im allgemeinen angegeben, daß diese Organisationsform die Eigenständigkeit der Beteiligten in einem partnerschaftlichen Verhältnis durch Kooperation und Koordination ermöglicht. Es kann zweckmäßig sein, die Form der Projektorganisation im Projektverlauf planmäßig zu wechseln. Dies ist dann der Fall, wenn einzelne Projektphasen oder Projektabschnitte deutlich unterschiedliche Anforderungen an die Projektorganisation stellen. So kann beispielsweise für die Vorstudie in einem IuK-Projekt ein Arbeitskreis ausreichend sein, während für die weiteren Projektphasen die reine Projektorganisation angebracht ist. In Abhängigkeit von der Projektorganisation ist zu klären, ob die Projektleitung der zuständigen Leitungsinstanz (z.B. dem Lenkungsausschuß) nur bezüglich der Projektmanagement-Aufgaben oder auch bezüglich der projektbezogenen fach-

PROPL - Projektplanung, -Überwachung und -Steuerung

35

liehen 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 der Projektleitung 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 Informatik-Projekt über die Zweckmäßigkeit der Benennung eines Produktmanagers (vgl. Lerneinheit PROVE) zu entscheiden und diesen zu benennen. Führungskräfte aus den vom Projekt betroffenen Organisationseinheiten und aus der IKS-Abteilung sind - neben dem für die Informationsverarbeitung im Unternehmen zuständigen Mitglied des Top-Managements - Mitglieder des Lenkungsausschusses.

Formen der Projektorganisation EinnußProjektorganisation

MatrixProjektorganisation

Reine Projektorganisation

Bedeutung für das U n t e r n e h m e n

gering

groß

sehr g r o ß

U m f a n g des Projekts

gering

groß

sehr g r o ß

Unsicherheit der Zielerreichung

gering

groß

sehr g r o ß

Standard

kompliziert

neu

gering

mittel

hoch

Projektdauer

kurz

mittel

lang

Komplexität

gering

mittel

hoch

mittel

groß

nebenamtlich (Stab)

Teilzeit (variabel)

vollamtlich

qualifizierter Projektleiter

sehr f ä h i g e r Projektleiter

Kriterien

Technologie Zeitdruck

B e d ü r f n i s nach zentraler Steuerung Mitarbeitereinsatz Projektleiterpersönlichkeit

wenig relevant

sehr g r o ß

A b b . P R O P L - 1 : Beurteilung der Projektorganisationsformen (Quelle: K u m m e r et al.)

Teilplanungen der Projektplanung Abbildung PROPL-2 zeigt die Planungsobjekte, in welche die Aufgabe der Projektplanung zerlegt werden kann, und die entsprechenden Teilplanungen. Kompetenz und Verantwortung für das Durchführen der Projektplanung hat die

36

Grundlagen

Projektmanagement

Projektleitung. Das Durchführen dieser Aufgabe sollte partizipativ erfolgen, d.h. gemeinsam mit den Projektmitarbeitern (vgl. Lerneinheit PROVE). Im folgenden werden für jede Teilplanung Erläuterungen gegeben. Daraus kann die Komplexität der Projektplanung, die sich weniger aus der Anzahl der Teilplanungen als vielmehr aus ihrer Vernetzung und gegenseitigen Abhängigkeit ergibt, erkannt werden (z.B. die Abhängigkeit der Sachmittelplanung von der Kostenplanung). Ohne Verwendung geeigneter Methoden und Werkzeuge kann die Aufgabe der Projektplanung nicht bewältigt werden (vgl. Lerneinheit PROME). Bei größeren Projekten fehlen zum Zeitpunkt der ersten Projektplanung ausreichend genaue Informationen über alle Projektanforderungen. Es wird daher so vorgegangen, daß zunächst für das Gesamtprojekt eine Grobplanung und lediglich für die unmittelbar bevorstehende Projektphase eine detaillierte Planung durchgeführt wird. Die Planung wird dann mit dem Projektfortschritt kontinuierlich verfeinert (z.B. während der Phase n für die Phase n+1).

A b b . P R O P L - 2 : O b j e k t e der Projektplanung und Teilplanungen

Mit der Personalplanung werden die nach Anzahl und Qualifikation für die Projektabwicklung erforderlichen Mitarbeiter bestimmt (Personalbedarf) und zur Projektgruppe zusammengefaßt (wegen Einzelheiten zur Bildung der Projektgruppe vgl. Lerneinheit PROVE). Ein wesentlicher Einflußfaktor für die Ermittlung des Personalbedarfs ist die Entscheidung darüber, welche Projektaufgaben mit eigenen Mitarbeitern und welche durch externe Aufgabenträger (z.B. Berater, Software-Häuser, System-Häuser) durchgeführt werden (Eigenfertigung oder Fremdbezug). Der Personalbedarf wird auch maßgeblich durch die Form der Projektorganisation, durch die Terminziele und durch die zur Unterstützung der Aufgabendurchführung verfügbaren Sachmittel bestimmt. Jedes Projekt stellt spezielle Anforderungen an die Qualifikation der Projekt-

PROPL - Projektplanung,

-Überwachung

und -Steuerung

37

mitarbeiter. In Abhängigkeit von der Projektaufgabe, von der Anzahl der verfügbaren Mitarbeiter und von deren Qualifikation sollte daher auch ein Fortbildungsplan als Teil der Personalplanung erstellt werden. Mit der Zielplanung werden alle für die Überwachung und Steuerung des Projekts erforderlichen Zielinhalte (insbes. Leistungen, Termine und Kosten) festgelegt (Projektziele). Der Entscheidungsspielraum für die Zielplanung ist durch die Planungsziele gegeben, denn alles, was die Planungsziele vorgeben, muß durch die Projektziele abgedeckt sein. Die Vorgaben für das angestrebte Ausmaß und den zeitlichen Bezug der Erreichung der Projektziele werden im wesentlichen von der Aufgabenplanung, der Terminplanung und der Kostenplanung beeinflußt. Die Feinheit der Zielplanung bestimmt entscheidend die Genauigkeit, mit der die Projektüberwachung erfolgen kann: Je gröber die Zielplanung, desto ungenauer die Projektüberwachung, vice versa. (Auf die spezifischen Leistungsziele für IuK-Projekte wird an anderer Stelle ausführlich eingegangen, vgl. Lerneinheit ZIELP.) Von besonderer Bedeutung für den Projekterfolg sind Zielinhalte, welche die Qualität des Planungsprozesses und die Qualität des Planungsergebnisses betreffen (Qualitätsziele), wie Benutzbarkeit, Flexibilität, Übertragbarkeit, Wartbarkeit und Zuverlässigkeit bei einem IuK-Projekt (vgl. Lerneinheit QUAMA). Qualitätsziele können als Teil der Leistungsziele oder als eigene Gruppe von Projektzielen bearbeitet werden (Dreieck oder Viereck der Projektziele). In der Aufgabenplanung sind die konstruktiven und die analytischen Maßnahmen festzulegen, die zur Vermeidung, Erkennung und Behebung von Fehlern beitragen und das Entstehen von Qualitätsmängeln verhindern helfen. Die auf die Erreichung von Qualitätszielen ausgerichteten Maßnahmen werden zu einem Qualitätsplan zusammengefaßt, der im Idealfall aus einem Unternehmensstandard für Qualitätspläne - unter Berücksichtigung der Qualitätsanforderungen des Projekts - abgeleitet wird. Die A u f g a b e n p l a n u n g ist Strukturplanung und Ablaufplanung. Mit der Strukturplanung wird die Gesamtaufgabe des Projekts (Projektaufgabe) systematisch in Teilaufgaben zerlegt, die Teilaufgaben werden weiter in Tätigkeiten zerlegt (Aufgabenanalyse). Mehrere Tätigkeiten können nach bestimmten Gesichtspunkten zu Arbeitspaketen zusammengefaßt werden (Aufgabensynthese). Bei der Strukturplanung ist besonders darauf zu achten, daß die Tätigkeiten so präzise beschrieben sind, daß die Aufgabenträger aus der Beschreibung erkennen können, was zu tun ist. Je besser und eindeutiger die Abgrenzung von Teilaufgaben gelingt, desto leichter können Koordinierungsprobleme, die während des Projektverlaufs auftreten, gelöst werden. Mehrere Teilaufgaben werden in der Regel unter sachlichen und terminlichen Gesichtspunkten zu Aufgabengruppen zusammengefaßt und definierten Projektphasen zugeordnet, die durch Meilensteine abgegrenzt werden. Voraussetzung für die Ablaufplanung ist die Herausarbeitung der Abhängigkeiten zwischen den Teilaufgaben bzw. Tätigkeiten. Ergebnisse der Aufgabenplanung sind der Projektstrukturplan und der Projektablaufplan.

38

Grundlagen

Projektmanagement

Die Ablaufplanung kann durch leistungsfähige Methoden gut unterstützt werden (z.B. Netzplantechnik, vgl. Lerneinheit NETZP). Mit der Zeitplanung wird für jede Projektphase, Teilaufgabe und Tätigkeit der für deren Durchführung erforderliche Zeitbedarf ermittelt. Dabei sind der Umfang und der Schwierigkeitsgrad der Aufgaben, die zur Unterstützung verfügbaren 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 (vgl. Lerneinheit MEAUF). Mit der P e r s o n a l e i n s a t z p l a n u n g werden die durch die Aufgabenanalyse ermittelten Teilaufgaben bzw. Tätigkeiten den Projektmitarbeitern zugeordnet (Aufgabenzuordnung). Dabei werden die Fähigkeiten und Fertigkeiten der A u f g a b e n t r ä g e r sowie der für die A u f g a b e n d u r c h f ü h r u n g erforderliche Zeitbedarf berücksichtigt. Mit der T e r m i n p l a n u n g wird aus dem Zeitbedarf für die Aufgabendurchführung, aus den Abhängigkeiten zwischen den Aufgaben und aus der Aufgabenzuordnung der Terminplan abgeleitet. Es werden Zwischen- und Endtermine für die wichtigsten Teilaufgaben und Tätigkeiten sowie Termine für die Projektphasen (Meilensteine) festgelegt. Die Terminplanung orientiert sich am geplanten Fertigstellungstermin des Projektgegenstands, der durch das zeitliche Planungsziel dem Projekt in der Regel vorgegeben ist. Fertigstellungstermin ist der Termin, zu dem das Projektergebnis für die geplante Verwendung (z.B. das Informationssystem für den produktiven Einsatz) zur Verfügung steht. Mit der S a c h m i t t e l p l a n u n g werden die für die Projektabwicklung erforderlichen Sachmittel (wie Hardware, Software, Geräte und Räume) festgelegt. Spezielle Hardware und Software (z.B. bisher nicht vorhandene Software, in das Produkt einzubauende Fremdsoftware) können unter Umständen zusätzlich benötigt und müssen beschafft werden. Zur Sachmittelplanung gehört daher auch die Beschaffungsplanung. Art und Umfang der erforderlichen Sachmittel ergeben sich insbesondere aus der Aufgabenplanung; sie können durch andere Teilplanungen (z.B. Kostenplanung) begrenzt werden. Die Sachmittelplanung umfaßt auch die Sachmittel f ü r die Projektplanung, Projektüberwachung und Projektsteuerung selbst (z.B. Projektmanagement-Software). Mit der Kostenplanung werden die kostenmäßigen Konsequenzen aller bisher genannten Teilplanungen ermittelt, insbesondere Personalkosten und Sachmittelkosten. Dabei wird von den in den Teilplanungen festgelegten Aufwänden ausgegangen, die mit Kosten bzw. bei Fremdbezug mit Preisen bewertet werden (vgl. Lerneinheit M E A U F ) . Bei der Festlegung der Kosten und Preise ist die Projektdauer und die mit ihr gegebenenfalls verbundene Veränderung (meist Erhöhung) der Wertansätze zu berücksichtigen. Ist der Projektplanung ein Budget vorgegeben, dann muß das Ergebnis der Kostenplanung mit dem Budget im Gleichgewicht sein; bei Budgetüberschreitungen sind Anpassungen bei den Teilplanungen, welche Termin- und Leistungsziele betreffen, erforderlich. In diesem

PROPL

- Projektplanung,

-Überwachung

und -Steuerung

39

Fall sind die Kostenziele die unabhängige Planungsvariable, die Termin- und Leistungsziele die abhängigen Planungsvariablen. Sind die Termin- und/oder die Leistungsziele die unabhängige(n) Planungsvariable(n), ergibt sich das Budget aus der Kostenplanung, die dann die abhängige Planungsvariable ist. Die Kostenplanung ist Grundlage für die Finanzierungsplanung, deren Ergebnis der Finanzplan ist. Mit der Notfallplanung werden Maßnahmen festgelegt, die für den Fall, daß das Projekt "notleidend" wird, ohne nennenswerte Verzögerung ergriffen werden können (z.B. Vorsorge durch ein Rückfallsystem). Dafür ist zu entscheiden, unter welchen Umständen das Projekt den Status "notleidend" erreicht hat bzw. wenn möglich - erreicht haben wird (Notstandsprognose), sodaß die Früherkennung des Projektnotstands möglich ist. Im allgemeinen wird ein Projekt dann notleidend, wenn Kostenziele oder Zeitziele im Vergleich zu Leistungszielen drastisch überschritten werden. Was "drastisch" im Einzelfall heißt, bedarf der Festlegung in der Notfallplanung. Die Feststellung des Status "notleidend" ist eine Aufgabe der Projektüberwachung und -Steuerung. Die Entscheidung über den Status "notleidend" steht in der Regel nicht der Projektleitung zu; sie fällt in die Zuständigkeit des Lenkungsausschusses. Mit den Ergebnissen der Aufgabenplanung, der Zeitplanung, der Terminplanung, der Sachmittelplanung und der Personaleinsatzplanung erfolgt zusammenfassend eine Kapazitätsplanung für Personal und Sachmittel. Sie dient der termingerechten Bereitstellung der notwendigen Personal- und Sachmittelkapazitäten. Weitere Teilplanungen können - j e nach Projektbedingungen zweckmäßig oder sogar notwendig sein, wie beispielsweise die Risikoplanung. Damit werden die Projektrisiken identifiziert und bewertet sowie Maßnahmen festgelegt, mit denen der Schadenseintritt verhindert bzw. das Schadensausmaß begrenzt werden kann. Schadenseintritt und Schadensausmaß werden von Risikofaktoren bestimmt, d.h. von Bedingungen des Projekts und der Projektumgebung, die negative Auswirkungen auf die Erreichung der Projektziele haben können (z.B. die Unerfahrenheit der Projektleitung, der Projektumfang, die Neuartigkeit der Projektaufgabe). Die typischen Fragestellungen des Risikomanagements sind daher: • • • • • •

Welche Risikofaktoren gibt es? Wann können die Risikofaktoren eintreten? Wie kann der Eintritt von Risikofaktoren überwacht werden? Welcher Schaden kann mit dem Eintritt von Risikofaktoren verbunden sein? Was kann getan werden, um den Schadenseintritt zu vermeiden? Was muß getan werden, um das Schadensausmaß zu begrenzen?

Ausgangspunkt und Kern des Risikomanagements ist also die Identifikation der Risikofaktoren sowie ihre Bewertung nach Risikoebenen (z.B. mit der Skala gering, mittel und hoch). Methodisch wird dies mit C h e c k l i s t e n (vgl. Lerneinheit CHECK) unterstützt, in denen aus der Erfahrung bekannte Risikofaktoren mit Risikofragen abgeprüft und den Risikoebenen zugeordnet werden.

40

Grundlagen

Projektmanagement

Realisierungsstrategien Bei der Ablaufplanung muß entschieden werden, in welcher Reihenfolge die Projektaufgaben durchgeführt werden, soweit sie 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 sowie Top-down-Strategie oder Bottom-up-Strategie. • Bei der Hardest-first-Strategie werden die Projektaufgaben als erste bearbeitet, welche die größten Schwierigkeiten bei der Realisierung verursachen. Diese Strategie wird vor allem dann angewendet, wenn das Projektergebnis ohne die Lösung dieser Aufgaben nicht verwendet werden kann. • Bei der Easiest-first-Strategie werden die Projektaufgaben als erste bearbeitet, die ohne große Probleme sind und daher schnell abgearbeitet werden können. Diese Strategie bietet sich an, wenn gewährleistet werden soll, daß für schwierige, aber nicht wesentliche Projektaufgaben nicht zu viel Zeit aufgewendet wird, sodaß bei Projektende für einfach zu realisierende und wesentliche Projektaufgaben keine Zeit mehr bleibt. • Bei der Top-down-Strategie wird zunächst ein grober Gesamtplan entwickelt, mit dem im Ergebnis die Gesamtdauer und die Gesamtkosten des Projekts ermittelt werden. • Bei der Bottom-up-Strategie werden nach Vorliegen des Strukturplans die Kosten und Termine der einzelnen Arbeitspakete ermittelt, die dann zur Gesamtdauer bzw. zu den Gesamtkosten aggregiert werden. Qualität

Projektdauer

Quantität

Kosten

Abb. PROPL-3: Teufelsquadrat (Quelle: nach Sneed)

In engem Zusammenhang mit den Realisierungsstrategien steht die Entscheidung darüber, welche der drei Zielgruppen (Leistungen, Kosten und Termine) bzw. der vier Zielgruppen (Quantität, Qualität, Kosten und Termine) im Fall von Zielkonflikten Priorität bei der Nutzung einer gegebenen Kapazität an Personal und Sachmitteln haben soll. Jede Inanspruchnahme von mehr Kapazität durch eine der Zielgruppen führt zu einer Reduzierung der für die anderen Zielgruppen verfügbaren Kapazität (sog. Teufelsdreieck bzw. Teufelsquadrat der Projektplanung). Welcher Zielgruppe auch immer Priorität eingeräumt wird, im Ergebnis führt dies zu negativen Abweichungen der Zielerreichung bei den anderen Zielgruppen.

PROPL - Projektplanung,

-Überwachung und -Steuerung

41

Projektüberwachung Zweck der Projektüberwachung ist es, während der Projektabwicklung, und zwar so zeitnah wie möglich, Abweichungen von den Projektzielen festzustellen und damit die Voraussetzung für die Projektsteuerung zu schaffen. "So zeitnah wie möglich" bedeutet, daß die Eingriffe durch die Projektsteuerung erfolgen können, die erforderlich sind, um das Projekt "auf Kurs" zu halten bzw. so schnell wie möglich wieder dahin zu bringen. Dies erfordert die Früherkennung drastischer Abweichungen von Termin- und Kostenzielen im Vergleich zu Leistungszielen. Die Aufgaben der Projektüberwachung sind daher: • den Projektablauf mit Hilfe geeigneter Instrumente zu beobachten; • den Projektstatus laufend festzustellen und zu dokumentieren; • durch Vergleich des Projektstatus mit den Projektzielen Abweichungen zu erkennen und an die für die Projektsteuerung zuständigen Instanzen (z.B. an den Lenkungsausschuß) zu berichten. Wichtigste Hilfsmittel der Projektüberwachung sind 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. Der Projekterfolg ist also auch von der Projektinformation abhängig. Daher ist ein aussagefähiges Projektberichtswesen (Projektberichterstattung und Projektdokumentation) einzurichten, das die zur Überwachung des Projekts erforderlichen Daten zur Verfügung stellt, aus denen Informationen über bestehende und sich abzeichnende Abweichungen gewonnen werden können. Einzelheiten zum Projektberichtswesen sind vom konkreten Projekt abhängig; Leitlinien für seine Gestaltung sind (vgl. auch Lerneinheit PCONT): • Alle für die Erkennung von Abweichungen relevanten Plan- und Istdaten müssen zur Verfügung gestellt werden. • Die Zugriffsberechtigung auf die Daten muß klar geregelt sein, insbesondere zwischen Linie und Projektgruppe. • Die Art und der Inhalt der Berichterstattung an Beteiligte (z.B. Auftraggeber) und Betroffene (z.B. zukünftige Benutzer) müssen festgelegt sein. • Innerhalb der Projektgruppe muß ein Koordinierungsinstrument vorhanden sein (z.B.: Wie informiert sich der Projektleiter und wie informiert er über das, was getan wird und was für andere von Bedeutung ist?). Die tatsächlichen Start-, Zwischen- und Endtermine von Projektaufgaben, die dafür verwendete Zeit, der Fertigstellungsgrad, die aufgetretenen Schwierigkeiten usw. müssen in kurzen Zeitabständen zuverlässig gemeldet werden. Das Problem der Datenerfassung liegt weniger darin, daß es für die Projektmitarbeiter aufwendig ist, als vielmehr in der mangelnden Akzeptanz der Aufgabe, Aufzeichnungen zu führen (vgl. den Abschnitt Projektmanagement-System). Grafische Darstellungen erleichtern es, den Projektstatus erkennen und mögliche Ab-

42

Grundlagen

Projektmanagement

weichungen von den Projektzielen im Hinblick auf ihren Einfluß auf den Projekterfolg beurteilen zu können (vgl. Lerneinheit PROME). Neben dieser formellen und meist stark formalisierten Projektberichterstattung und nicht alternativ dazu - ist eine informelle, nicht oder kaum formalisierte Berichterstattung zweckmäßig. Sie kann beispielsweise zwischen Projektleitung und Projektmitarbeitern in Form von wöchentlichen verbalen Kurzberichten über Vorgänge und Ereignisse, die sich negativ auf die Erreichung der Projektziele auswirken können, vereinbart sein ("brain dumps"). Projektdokumentation Projekte sollen vom Zeitpunkt der Erteilung des Projektauftrags bis zum Projektabschluß (z.B. bei IuK-Projekten bis zur Übergabe des produktiven Informationssystems) für die Projektleitung kontrollierbar und nachvollziehbar sein. Dies läßt sich nur durch eine projektbegleitende D o k u m e n t a t i o n verwirklichen (vgl. auch Lerneinheit DOKUM). Zur Unterstützung der projektbegleitenden Dokumentation wird eine P r o j e k t b i b l i o t h e k eingesetzt; ihre Aufgaben sind: • die Projektprodukte und ihre Beziehungen zueinander zu verwalten (einschließlich einer Verbindung zu einem Datenkatalog-System); • die Dokumente durch einfache Abfragen gezielt und schnell (möglichst online) zur Verfügung zu stellen (Dokumenteverwaltung); • den Projektstatus einfach und transparent darzustellen; • durch Auswertung von Projektdaten mögliche Probleme während der Projektlaufzeit und ihre potentielle Lösung vorwegzunehmen. Ein für die Projektleitung nützliches Hilfsmittel der Projektdokumentation ist ein Projekttagebuch. Dieses informelle und nicht-formalisierte Dokument dient der Aufzeichnung von Vorgängen und Ereignissen, die aus der Sicht der Projektleitung für den Projekterfolg wesentlich sind und die in der formellen Berichterstattung nicht erfaßt werden. Es soll nicht primär der Rechtfertigung bei Projektnotständen, sondern mehr zur Erklärung dafür dienen, aus welchen Gründen bestimmte Projektzustände eingetreten sind. Ein Projekttagebuch ist daher ein geeignetes Hilfsmittel, um aus Projekten für Projekte zu lernen. Projektsteuerung Die Projektsteuerung umfaßt alle Maßnahmen, die zur Durchsetzung der in der Projektplanung getroffenen Entscheidungen erforderlich sind. Neben der Projektplanung werden daher die Ergebnisse der Projektüberwachung für die Durchführung der Projektsteuerung benötigt. Die Maßnahmen zur Projektsteuerung im einzelnen hängen vom konkreten Projekt ab; sie können projektunabhängig den folgenden Maßnahmengruppen zugeordnet werden:

PROPL - Projektplcinung,

-Überwachung und -Steuerung

43

• Maßnahmen zur Überprüfung der von der Projektüberwachung festgestellten Abweichungen; • Maßnahmen zum Erkennen der Ursachen für Abweichungen; • Maßnahmen zum Beeinflussen der Projektabwicklung, die eine Verbesserung der Istwerte bewirken; • Maßnahmen zum Beeinflussen der Projektplanung, die eine Veränderung der Planwerte bewirken; • Maßnahmen, die das Koordinieren zwischen Auftraggeber und Projektgruppe sowie zwischen den verschiedenen Arbeitsgruppen im Projekt bewirken. Demonstrationsbeispiel Es wird die Struktur eines Projektauftrags gezeigt, wie sie für ein InformatikProjekt aus dem Bereich Technologiemanagement verwendet werden kann (z.B. für ein Migrationsprojekt); zu erklärungsbedürftigen Gliederungspunkten werden exemplarische Erläuterungen gegeben. 1 2 3 4

Projektbezeichnung Projektgegenstand Projektziele Vertragspartner 3.1 Auftraggeber 3.2 Auftragnehmer 5 Ausgangssituation 5.1 Darstellung der Ist-Situation 5.2 Bereits erledigte Vorarbeiten 6 Rahmenbedingungen (z.B. Verfügbarkeit von Personal und Budget) 7 Risikobetrachtung 7.1 Risikoanalyse (z.B. Abhängigkeit des Projekterfolgs von der Mitwirkung Externer) 7.2 Maßnahmen zur Minimierung des Projektrisikos (z.B. Dokumentation, Berichterstattung, Reviews) 8 Projektabgrenzung 8.1 Im Projekt (explizite Nennung aller auf jeden Fall durchzuführenden Arbeiten) 8.2 Nicht im Projekt (explizite Nennung aller auf keinen Fall durchzuführenden Arbeiten) 9 Arbeitsprogramm 9.1 Organisatorische Arbeiten (z.B. Überprüfen der Funktionalität bei einer Software-Evaluierung) 9.2 Technische Arbeiten (z.B. Einbindung des Software-Produkts in die bestehende Produktionsumgebung) 10 Termine 11 Angebotssumme bzw. Budget

44

Grundlagen

Projektmanagement

12 Arbeitsstruktur 12.1 Projektleiter 12.2 Entscheidungsinstanz beim Auftraggeber 12.3 Projektbeauftragter des Auftraggebers 12.4 Abstimmpartner beim Auftraggeber 12.5 Betroffene 13 Projektinformation 13.1 Berichtswesen an Auftraggeber (z.B. periodische Berichterstattung 14-tägig schriftlich; Abschlußpräsentation mündlich mit Übergabe Abschlußbericht) 13.2 Verteiler für Projektinformationen 14 Organisatorische Rahmenbedingungen 14.1 Spezielle Gegebenheiten (z.B. Hinweis auf die Notwendigkeit von Schulungen) 14.2 Leistungen des Auftraggebers (z.B. Art und Umfang der Mitwirkung/Mitarbeit) 15 Unterschriften der Vertragspartner Forschungsbefunde L. J. Heinrich berichtet über empirische Befunde zur Frage, warum IuKProjekte scheitern oder notleidend werden, d.h. ihre Kosten-, Termin- und/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ägern vgl. Lerneinheit PROVE): • • • • • •

Planungsziele nicht oder nicht klar genug definiert; mangelhafte Projektorganisation; einseitige Kosten- und Terminorientierung (fehlende Leistungsziele); keine systematische Projektiiberwachung; 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 Planungsin-

PROPL - Projektplanung, -Überwachung und -Steuerung

45

strumentariums (Methodik, Methoden und Werkzeuge), nicht auf D e f i z i t e in der Verfügbarkeit des Planungsinstrumentariums zurückzuführen. D i e s e B e f u n d e z e i g e n d i e N o t w e n d i g k e i t einer besseren A u s b i l d u n g für alle an e i n e m IuKProjekt Beteiligten (Management, Projektleiter, Projektmitarbeiter und Benutzer). Kontrollfragen 1. 2. 3. 4. 5.

Wie kann die A u f g a b e der Projektplanung beschrieben werden? Nach welchen Gesichtspunkten kann ein großer Projektumfang systematisch zerlegt w e r d e n ? Aus welchen Teilplanungen besteht die Projektplanung? Wie wird bei der Projektplanung berücksichtigt, daß ein Projekt notleidend werden k a n n ? Was ist ein Projekttagebuch und was ein brain d u m p ?

Quellenliteratur K u m m e r , A. 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., Industrielle Organisation, Zürich 1993 Heinrich, L. J.: S c h w a c h s t e l l e n 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 u n d R e c h t 7/1988, 584 - 587 Heinrich, L. J.: S y s t e m p l a n u n g 2 Bd. 6. A. ( B d . 1) b z w . 5. A. (Bd. 2), O l d e n b o u r g , M ü n chen/Wien 1994 Sneed, H. M.; Projektmanagement. Müller, Köln-Braunsfeld 1987 Zehnder, C. A.: Informatik-Projektentwicklung. 2. A., Teubner, Zürich 1991 Zielasek, G.: P r o j e k t m a n a g e m e n t . Erfolgreich durch A k t i v i e r u n g aller U n t e r n e h m e n s e b e n e n . Springer, Berlin e t a l . 1995 Vertiefungsliteratur Cave, W . C . / 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, W i e s b a d e n 1988 Franke, A.: Risikobewußtes Projektcontrolling. T Ü V Rheinland, Köln 1993 Hansel, J./Lomnitz, G.: Projektleiter-Praxis - Erfolgreiche Projektabwicklung durch verbesserte Kommunikation und Kooperation. Springer, Berlin et al. 1987 Hofstetter, H.: Organisationspsychologische Aspekte der S o f t w a r e - E n t w i c k l u n g . In: Schelle, H./ Molzberger, P.: Psychologische Aspekte der S o f t w a r e - E n t w i c k l u n g . Oldenbourg, M ü n c h e n / Wien 1 9 8 3 , 2 5 - 6 2 Madauss, B. J.: H a n d b u c h Projektmanagement. 4. A., Poeschel, Stuttgart 1991 Platz, J./Schmelzer, H. J.: Projektmanagement in der industriellen F o r s c h u n g und E n t w i c k l u n g E i n f ü h r u n g anhand von Beispielen aus der Informationstechnik. Springer, Berlin et al. 1986 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. Vieweg, B r a u n s c h w e i g / W i e s b a d e n 1991

PRIPM - Prinzipien des Projektmanagements Lernziele Sie wissen, was Prinzipien sind und kennen ihren wissenschaftlichen Wert und ihre praktische Bedeutung. Sie können Prinzipien des Projektmanagements nennen und erläutern, insbesondere solche, die für Informatik-Projekte von Bedeutung sind. Sie erkennen, daß sich Prinzipien in ihren Aussagen überschneiden und m a n c h m a l auch widersprechen. Sie erkennen, daß Prinzipien nur nach gründlicher Prüfung bei der Projektarbeit verfolgt werden sollten. D e f i n i t i o n e n und

Abkürzungen

K o n f i g u r a t i o n s v e r w a l t u n g (configuration management) = die Entwicklung und Verwaltung von einheitlichen und aktuellen, maschinell interpretierbaren Beschreibungen von Software-Produkten in ihrem Lebenszyklus. L e b e n s z y k l u s (life cycle) = eine bestimmte, in sich abgeschlossene Phase der gesamten Lebensdauer eines Produkts, aus der es keine Rückkehr in eine frühere Phase gibt (analog dem Lebenszyklus von Menschen). M e t h o d e (method) = eine auf einem System von Regeln aufbauende, intersubjektiv nachvollziehbare Handlungsvorschrift zum Problemlösen (z.B. ein Algorithmus). Prinzip (principie) = eine Regel oder eine Richtschnur für das Denken, Handeln und/oder Verhalten. Synonym: Grundsatz. P r o d u k t i v i t ä t (productivity) = ein Ziel, dessen Zielinhalt das Verhältnis zwischen dem mengenmäßigen Ertrag und dem mengenmäßigen Einsatz zur Erbringung dieses Ertrags ist (Output/Input-Verhältnis). Q u a l i f i k a t i o n (qualification) = die Gesamtheit des Wissens und des Könnens (Fähigkeiten, Fertigkeiten) einer Person oder einer Gruppe. Qualität (quality) = die Beschaffenheit einer Einheit bezüglich ihrer Eignung, die Qualitätsforderungen zu erfüllen (nach ISO 8402 und DIN 55350 Teil 11); Einheit ist jeder materielle oder immaterielle Gegenstand der Betrachtung. R e v i e w (review) = ein mehr oder weniger formaler, geplanter Prozeß, in dem Projektergebnisse zur Prüfung, Kommentierung und Genehmigung bzw. Zurückweisung einem Gutachter oder einem Team von Gutachtern präsentiert werden. S o f t w a r e Engineering (software engineering) = eine Teildisziplin der Wirtschaftsinformatik und der Angewandten Informatik, deren Ziel die Entwicklung und Bereitstellung von Methoden, Techniken und Werkzeugen zur wirtschaftlichen Herstellung von "guter" Software ist. V a l i d i e r u n g (Validation) = die Überprüfung der Verwendungsfähigkeit eines Produkts oder einer Dienstleistung, d.h. die Beantwortung der Frage: Wird das richtige Produkt hergestellt? V e r i f i z i e r u n g (verification) = die Überprüfung der Übereinstimmung zwischen einem Produkt oder einer Dienstleistung und ihrer Spezifikation, d.h. die Beantwortung der Frage: Wird das Produkt richtig hergestellt? V e r s i o n (versión) = ein ganz bestimmter Zustand eines Systems (z.B. eines Software-Produkts); jede Änderung am System führt zu einer neuen Version.

PRIPM - Prinzipien des Projektmanagements

AI

Zweck der Prinzipien Zweck der Prinzipien des Projektmanagements ist es, die Erreichung der Projektziele zu unterstützen (z.B. qualitativ gute Software mit einem wirtschaftlich vertretbaren Aufwand herzustellen). Um die Prinzipien umzusetzen, sind Methoden und Werkzeuge erforderlich, welche die Prinzipien berücksichtigen oder verwenden bzw. mit denen sie implementiert sind. Manche Prinzipien scheinen trivial zu sein. Die Schwierigkeit im Umgang mit Prinzipien liegt nicht darin, sie zu verstehen, sondern darin, sie anzuwenden. Zum Teil sind die Prinzipien wechselseitig miteinander verbunden oder sich gegenseitig voraussetzend; teilweise überschneiden sie sich und manchmal widersprechen sie sich in ihren Aussagen. Die methodische Qualität von Vorgehensweisen, welche sich an Prinzipien orientieren, ist relativ gering, ihre praktische Bedeutung ist erheblich. Prinzipien sind in der Organisationslehre stark verbreitet und spielen deshalb auch für das Management von Informatik-Projekten eine Rolle. Demonstrationsbeispiel Im folgenden werden Prinzipien wiedergegeben, die aus verschiedenen Quellen entnommen wurden. Sie werden hier nicht kommentiert und sollten in der Projektarbeit nur nach kritischer Hinterfragung verwendet werden. Die sieben Regeln des Software Engineering nach Boehm B.W. Boehm hat 1983 sieben Regeln formuliert, die nach seiner Auffassung notwendig und hinreichend sind, um alle Aspekte des Software Engineering abzudecken (mit Änderungen entnommen aus Frühauf et al.). 1. Manage using a phased life-cycle plan. So trivial die Forderung auch ist, ihre Mißachtung führt immer wieder zu Problemen, die ohne große Mühe hätten vermieden werden können. 2. Perform continuous Validation. Die traditionelle Validierungsmethode, der Test, kann erst beginnen, wenn das Software-Produkt so gut wie fertig ist. Validierung muß aber wesentlich früher einsetzen. Dafür kommen vor allem Reviews in Frage. 3. Maintain disciplined product control. Durch die Entwicklung verschiedener Varianten und aufeinanderfolgender Versionen entsteht beim Versuch, ein bestimmtes System zu konfigurieren, eine völlig unübersichtliche Situation. Nur durch gezielte, frühzeitig wirksame Maßnahmen (z.B. durch Konfigurationsverwaltung) kann diese Gefahr vermieden werden. 4. Use modern programming practices. Durch den Einsatz moderner Methoden und Verfahren steigt die Produktivität um etwa 50%. Über die in Frage kommenden Ansätze gibt es reichlich Literatur.

48

Grundlagen

Projektmanagement

5. M a i n t a i n clear accountability for results. Definitive Verantwortlichkeiten verbessern die Identifikation mit der Arbeit und erleichtern das Erkennen von Projektmitarbeitern, die der Schulung bedürfen oder die einfach am falschen Platz sind. Sinngemäß gilt das Gleiche für Gruppen. 6. Use better and fewer people. Gute Leute sind teurer als schlechte. Wird aber bedacht, daß die Entlohnung höchstens im Bereich 1 bis 2, die Leistungen aber im Bereich 1 bis 20 variieren, so wird der große Vorteil guter Mitarbeiter erkennbar. Außerdem gibt es in einem Projekt mit weniger Mitarbeitern weniger Verluste durch Kommunikation. 7. M a i n t a i n a c o m m i t m e n t to improve the process. Wenn, wo möglich durch Einsatz moderner Methoden, Sprachen und Werkzeuge, ein Projekt erfolgreich bearbeitet werden konnte, sollte ein Teil des Projekterfolgs für Investitionen (z.B. für Personalfortbildung) verwendet werden, um auch in Zukunft Verbesserungen zu erzielen. Regeln von Frühauf et al. 1. M a n a g e m e n t u n t e r s t ü t z u n g sicherstellen. Ohne Unterstützung durch das Management sind Verbesserungsmaßnahmen selten erfolgreich. Diese Unterstützung ist gefährdet in Umgebungen, in denen "Software-Probleme" willkommene und akzeptierte Entschuldigungen für Probleme aller Art sind (insbes. auch für Führungsmängel). Andererseits setzt die Unterstützung Verständnis und Vertrauen voraus. Dies führt zur Forderung nach Ausbildung, da Qualifikation Voraussetzung für Verständnis schafft. 2. D e f i n i e r e B e g r i f f e und vermeide Ä n d e r u n g e n der D e f i n i t i o n e n . Es ist wichtig, daß in einer Entwicklungsumgebung oder in einem Projekt alle das gleiche Verständnis der Methoden und des Entwicklungsablaufs haben. Dazu trägt eine saubere Definition der grundlegenden Begriffe wesentlich bei. Es genügt aber nicht, daß es irgendwelche Begriffsdefinitionen gibt, sie müssen über einen längeren Zeitraum konstant gehalten werden, selbst dann, wenn nach einiger Zeit Unzulänglichkeiten aufgefallen sind. Diese Konstanz ist auch Voraussetzung für die Sammlung vergleichbarer Daten, die eine echte Gegenüberstellung verschiedener Projekte zulassen und der Planung weiterer Projekte ohne Anpassungen zugrundegelegt werden können. 3. Halte das Projekt einfach. Diese Forderung umfaßt zwei Aspekte, den Projektumfang und die Projektstruktur. Beim Projektumfang sind die folgenden Empfehlungen zu beachten: Entwickle nur, was nötig ist, nicht, was Spaß macht. Alles was nicht entwickelt werden muß, verursacht keinen Aufwand, wenn es nicht entwickelt wird. Es ist deshalb gerechtfertigt, einigen Aufwand dafür zu treiben, daß die gesammelten Anforderungen (und später der Entwurf) daraufhin untersucht werden, was überflüssig oder was zu kompliziert ist. Dies ist die Tätigkeit, welche die Fähigkeiten des Ingenieurs anspricht, nämlich ein Problem auf seinen wesentlichen Kern zu bringen und einer einfachen, übersichtlichen Lösung zuzuführen.

PRIPM - Prinzipien

des

Projektmanagements

49

Halte die Anforderungen stabil. Wurden die Anforderungen auf einen klaren, notwendigen Umfang gebracht, darf das Resultat nicht durch laufende Änderung der Anforderungen zerstört werden. Eine Änderung der Anforderungen bedingt eine Überarbeitung der Planung. Argumente wie "die Lösung ist ja noch nicht realisiert und es ist gleich, ob dieser Teil rot oder grün wird" sind sehr gefährlich. Ob der Aufwand bei den beiden Varianten tatsächlich gleich ist, muß überprüft werden. Noch mehr Überraschungen bieten Änderungen der Anforderungen, "die durch die Hintertür" ins Projekt kommen, die also Mitarbeiter des Auftraggebers und/oder des Projektteams aus ihrer Teilsicht der Aufgabe vereinbaren, ohne daß die Projektleitung informiert wird. Um sich vor den negativen Auswirkungen von Änderungen zu schützen oder wenigstens die Kontrolle darüber zu behalten, muß ein komplizierter Anforderungsänderungsmechanismus (das Wort sagt alles!) zwischen Auftraggeber und Projekt etabliert und strikt eingehalten werden. Halte die Projektorganisation einfach. Die Forderung nach Einfachheit der Anforderungen und des Entwurfs gilt entsprechend für die Projektorganisation. Es leuchtet ein, daß jeder organisatorischen Einheit des Projekts ein mehr oder weniger abgeschlossener Beitrag zur Bearbeitung der Projektaufgabe zugeteilt wird. Sind unnötig viele Einheiten vorhanden, wird die Projektorganisation entsprechend überstrukturiert sein. 4. Erkannte Probleme nicht verdrängen (sie tauchen bestimmt im ungünstigsten Moment wieder auf). Verdrängt ein Projektleiter ein erkanntes Problem, so handelt er gegen seine eigenen Interessen. Probleme müssen so schnell wie möglich gelöst werden. Dabei ist es wichtig, nicht alle Probleme auf einmal lösen zu wollen - und damit keines wirklich zu lösen. Am zweckmäßigsten ist es, die bekannten Probleme zu gewichten und die zwei oder drei dringlichsten Probleme mit voller Aufmerksamkeit und Nachdruck anzugehen. 5. Klare Spielregeln bei der Führung von Mitarbeitern. Dabei sind die folgenden Empfehlungen zu beachten: Stelle klare Aufgaben. Wie im Großen, soll auch im Kleinen die Aufgabe klar mit Sachziel, Budget und Termin gestellt werden. Damit wird die Aufgabe explizit und die Aufgabendurchführung überprüfbar, Erfolg wie Mißerfolg können einfach zugeordnet werden. Lob und Tadel und Maßnahmen zur Verbesserung können richtig adressiert werden. Setze knappe, aber erreichbare Termine. Die Termine sollen knapp sein, damit sie als Ansporn dienen. Zu knappe Termine sind aber genauso schlecht wie zu großzügige. Zieltermine sind keine Prognosen. Ein sinnvoll knapper Zieltermin kann mit etwa 50% Wahrscheinlichkeit erreicht werden, ein prognostizierter Termin, von dem die Planung abhängt, sollte in 90% der Fälle erreicht werden. 6. Behalte den Überblick über das Projekt als Ganzes. Es ist nicht sinnvoll, den Istzustand zu erfassen, ohne gleichzeitig die noch zu erbringenden Leistungen zu erfassen. Jede Maßnahme muß in ihrer Auswirkung auf das Gesamtziel bewertet werden. Daher ist es angebracht, den Istzustand in bezug auf

50

Grundlagen

Projektmanagement

das Gesamtziel darzustellen, eben im Zusammenhang mit den noch offenen Leistungen. Behalte die Verbindung zu den Menschen im Projekt. Sachziele, Budgets und Termine sind die eine Seite des Projekts, die Aktiven des Projekts sind jedoch die beteiligten Personen. Es ist wichtig, auch Stimmungen im Team zu erkennen, um auf dieser Basis Aussagen richtig gewichten zu können und Maßnahmen in angepaßter Form und im geeigneten Zeitpunkt wirksam werden zu lassen. Dies bedingt die persönliche Anwesenheit des Projektleiters in guten und kritischen Phasen. "Per Telefon" kann ein Projekt nicht geleitet werden. 7. Vertritt Deine Anliegen durch Worte und durch Dein Verhalten! Kommunikation ist wichtig, denn was ich weiß, das wissen die Mitarbeiter noch keineswegs. Darum ist es Aufgabe der Manager, die Anliegen der Projektleitung usw. offensiv zu vertreten. Aber das ist nur der eine Teil. Nichts ist so glaubhaft wie ein Beispiel. Darum ist die Teilnahme des Projektleiters an Schulungsmaßnahmen (nicht nur symbolisch am ersten Tag) der beste Beweis dafür, daß das Interesse an Weiterbildung ernstgemeint ist. Dieses Prinzip gilt immer. Die Mitarbeiter wissen sehr gut, daß der Projektleiter andere Aufgaben hat als sie. Aber sie können erwarten, daß seinem Verhalten das gleiche Prinzip zugrunde liegt wie ihrem (z.B. die Bereitschaft, Kritik anzunehmen). Die 12 Schlüssel zur Qualität Einer Seminarunterlage von E. Wallmüller entnehmen wir dazu folgende Prinzipien für IuK-Projekte (ohne weitere Quellenangaben): 1. 2. 3. 4. 5. 6.

Qualitätsverbesserung ist ein Führungsgrundsatz. Konzentration auf die Erwartungen der Benutzer/Auftraggeber. Die richtige Aufgabe in der richtigen Art beim ersten Mal ausführen. Folge einer Entwicklungsmethodologie. Benutze Software-Engineering-Techniken und -Werkzeuge. Verlagere den Aufwand von der Qualitätsprüfung zur Verhütung von Qualitätsmängeln. 7. Verwende erprobte Techniken zur Projektplanung und -Steuerung. 8. Beziehe alle Mitarbeiter und Manager in den Verbesserungsprozeß ein. 9. Qualifiziere die Mitarbeiter durch Aus- und Fortbildung sowie durch Entwicklungspfade (Karrierewege). 10. Entwickle ein Verfahren zur Messung der Qualität. 11. Verwende einen formalen und konsequenten Testprozeß. 12. Verwende formale technische Reviews, um Fehler und Mängel früh zu erkennen und zu beseitigen. Kontrollfragen 1. 2. 3. 4. 5.

Was ist ein Prinzip, wie kann es definiert werden? Welchen wissenschaftlichen Charakter haben Prinzipien? Welche praktische Bedeutung haben Prinzipien? Worin besteht das Problem bei der Anwendung von Prinzipien? Welche der referierten Prinzipien sind typisch für Informatik-Projekte, welche gelten für jede Art von Projekt?

PRIPM - Prinzipien des Projektmanagements

51

Quellenliteratur Boehm, B. W.: Seven basic principles of Software Engineering. In: Journal of Systems and Software 3/1983, 3 - 24 Frühauf, K. et al.: Software-Projektmanagement und Qualitätssicherung. 2. A., Teubner, Stuttgart 1991 Heinrich, L. J.: Prinzipien der Software-Entwicklung. In: Systemplanung. Planung und Realisierung von Informatik-Projekten Bd. 2. 5. A., Oldenbourg, München/Wien 1994, 252 - 261 Vertiefungsliteratur Brodbeck, F. C./Frese, M. (Hrsg.): Produktivität und Qualität in Software-Projekten. Oldenbourg, München/Wien 1994

Grundlagen IuK-Projekte

54

Grundlagen

IuK-Projekte

Mit dem Kapitel Grundlagen IuK-Projekte sollen folgende Lernziele erreicht werden: ZAMIP - Ziel, Aufgaben und Methodik von IuK-Projekten Sie kennen die Bedeutung der Planungsziele und können diese als Ausgangspunkt für die Zielsystembildung von IuK-Projekten verwenden. Sie können die Aufgabe der Planung und Realisierung eines IuK-Systems in Teilaufgaben gliedern und als Phasenschema beschreiben. Sie erkennen, daß die Methodik für IuK-Projekte eine Mischung verschiedener Methodikansätze ist. SYSIP - Systemtechnik und IuK-Projekte 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 Projektmanagement-Methodik. PROIP - Prozeßcharakter von IuK-Projekten Sie können die Aufgabe eines IuK-Projekts in Teilaufgaben gliedern und diese zu Phasen ordnen. Sie können die wichtigsten Aufgaben der einzelnen Phasen angeben. Sie sind in der Lage, den Input und den Output jeder Phase zu beschreiben. Sie erkennen den Prozeßcharakter von IuK-Projekten und können die konstitutiven Merkmale dieses Arbeitsprozesses erläutern. ZIELP - Zielplanung für IuK-Projekte Sie kennen den Zweck der Planung der Sachziele und der Formalziele ("Zielplanung"). Sie können Sachziele und Formalziele in geeigneter Weise gliedern und Aussagen über die Zielinhalte und die Zielbeziehungen machen. Sie können Vorgehensweisen für den Arbeitsprozeß der Sachzielplanung und der Formalzielplanung angeben. Sie kennen den Zusammenhang zwischen der Zielplanung und der Anforderungsanalyse.

ZAMIP - Ziel, Aufgaben und Methodik von IuK-Projekten Lernziele Sie kennen die Bedeutung der Planungsziele und können diese als Ausgangspunkt für die Zielsystembildung von IuK-Projekten verwenden. Sie können die Aufgabe der Planung und Realisierung eines IuK-Systems in Teilaufgaben gliedern und als Phasenschema beschreiben. Sie erkennen, daß die Methodik für IuK-Projekte eine Mischung verschiedener Methodikansätze ist. Definitionen und

Abkürzungen

A u f g a b e n a n a l y s e (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. I n f o r m a t i o n s i n f r a s t r u k t u r (information infrastructure) = die Einrichtungen, Mittel und Maßnahmen, welche die Voraussetzung für die Produktion von Information und Kommunikation schaffen. Initialisierungsphase (initial phase) = die der Anregung eines Projekts dienenden Aufgaben, die daher nicht Teil eines Projekts sind. Synonym: Vorphase. M e t h o d e (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. P h a s e n s c h e m a (phase model) = die idealtypische Gliederung eines Vorhabens in Abschnitte logisch zusammengehöriger Aufgaben einschließlich der Methodik, Methoden und Techniken der Aufgabenlösung. Synonym: Phasenmodell. R ü c k k o p p l u n g (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. Z i e l a u s m a ß (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) = e i n e Menge von Zielen, die miteinander in Beziehung stehen.

56

Grundlagen

luK-Projekte

Ziele von IuK-Projekten 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. Als Ziele für IuK-Projekte sind sowohl Organisationsziele als auch Individualziele von Bedeutung. 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 für IuK-Projekte können so beschrieben werden: Sie haben Zielinhalte, die auf eine Definition des Zwecks des zu schaffenden IuK-Systems ausgerichtet sind. Sachziele beschreiben, welche betrieblichen Aufgaben unterstützt werden sollen. Das generelle Sachziel für IuK-Projekte besteht darin, dem Auftraggeber ein produktiv verwendbares IuK-System zur Verfügung zu stellen; daraus ergeben sich die in IuK-Projekten zu bearbeitenden Aufgaben. Formalziele für IuK-Projekte können so beschrieben werden: Sie haben Zielinhalte, welche die Qualität, die das IuK-System besitzen soll, beschreiben. Empirische Belege bzw. theoretische Aussagen darüber, welche Organisationsziele und welche Individualziele in der Praxis als Formalziele verwendet werden bzw. verwendet werden sollten, liegen nicht in einem Umfang vor, der es ermöglicht, ein geschlossenes Formalzielsystem für IuK-Projekte anzugeben. Dieses wäre auch lediglich ein modelltheoretisches Konzept, das aber als Orientierungsgröße bei der Zielsystembildung verwendet werden könnte. Die Zielbildung für ein IuKProjekt ist zeitverbrauchend und arbeitsaufwendig, sodaß sie nicht immer mit ausreichender Gründlichkeit durchgeführt wird. Eine projektbezogene Präzisierung der Sachziele und der Formalziele erfolgt im Zusammenhang mit der Zielplanung (vgl. Lerneinheit ZIELP). Aufgaben von IuK-Projekten Generelle Aufgabe ("Sachziel" oder "Zweck") von IuK-Projekten ist es, dem Auftraggeber ein produktives IuK-System zur Verfügung zu stellen. Da es

ZAMIP - Ziel, Aufgaben und Methodik von IuK-Projekten

57

sich häufig um ein Teilsystem handelt, kann auch gesagt werden, daß es Sachziel oder Zweck eines IuK-Projekts ist, dem Auftraggeber ein produktives Anwendungssystem zur Verfügung zu stellen. Produktiv ist ein IuK-System dann, wenn es - nach Durchführung aller Tests (Abnahmetest mit Funktionstest und Leistungstest sowie Integrationstest) - im Echtbetrieb verwendet werden kann. Die generelle Aufgabe eines IuK-Projekts wird entsprechend der Aufgabenanalyse in Teilaufgaben und diese werden weiter in Tätigkeiten zerlegt, deren Bearbeitung erforderlich ist, um das Sachziel zu erreichen. Werden entsprechend der Aufgabensynthese Teilaufgaben zu Aufgabenklassen zusammengefaßt, so ergibt sich eine sinnvolle Ordnung der Aufgaben eines IuK-Projekts. Erfolgt die Aufgabensynthese nach idealtypischen, vor allem nach logischen Gesichtspunkten (z.B. Gleichartigkeit der Verrichtungen wie "Analysieren" oder "Implementieren"), dann ist ihr Ergebnis ein Phasenschema (auch: Phasenmodell). In einem weiteren Schritt können den Phasen Methoden und Techniken zugeordnet werden, mit denen ihre Planung und Realisierung unterstützt werden kann. Auf diese Weise entsteht aus dem Phasenschema ein Vorgehensmodell. Der Aussagewert (und damit auch die praktische Brauchbarkeit) des Phasenschemas wird oft mißverstanden. Ein Mißverständnis liegt vor, wenn im Phasenschema eine allgemeingültige und praktisch anwendbare Vorgehensweise (d.h. ein Vorgehensschema oder Vorgehensmodell) oder eine allgemeingültige M e thodik für IuK-Projekte gesehen wird. Beispielsweise gibt das Phasenschema keine eindeutige zeitliche Ordnung der Phasen und ihrer Aufgaben an. Man darf sich den Prozeß der Projektabwicklung 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 wird durch die Projektplanung festgelegt (vgl. Lerneinheit PROPL). Das in diesem Lehrtext verwendete Phasenschema wird an anderer Stelle erläutert (vgl. Lerneinheit PROIP). Wie jedes Phasenschema, leistet es im wesentlichen nicht mehr, als eine Ordnung der Aufgaben unter dem Gesichtspunkt vorzunehmen, gleichartige Aufgaben einer Phase zuzuordnen (und gegebenenfalls in einem weiteren Schritt einzelnen Phasen bestimmte Methodikansätze sowie Methoden und Techniken). Jede Phase beschreibt in erster Linie Klassen von Aufgaben, die zur Herstellung des Produkts "IuK-System" bearbeitet werden müssen (und gegebenenfalls auch bestimmte Methodikansätze sowie Methoden und Techniken). Die Phasen stellen also die erste Gliederungsebene der top-down zerlegten Aufgabe dar, dem Auftraggeber ein produktives IuK-System zur Verfügung zu stellen. Abbildung ZAMIP-1 ordnet den Phasen die Phasenziele und die verwendeten Methodikansätze zu. Eine Initialisierungsphase wird in diesem Phasenschema nicht verwendet, da es sich dabei um Aufgaben handelt, die dem Informatik-Projekt vorgelagert sind (vgl. Lerneinheit SPLAN im Bd. "Informationsmanagement").

58

Grundlagen

luK-Projekte

Phase

Phasenziel

Verwendete Methodikansätze

Vorstudie

Grundkonzeption

Sollzustandsorientierung

Feinstudie

Angepaßte Grundkonzeption

Istzustandsorientierung und Sollzustandsorientierung im Rahmen der Grundkonzeption

Entwurf

Logisches Modell Sollzustand

Sollzustandsorientierung, Datenorientierung, Inside-Out-Ansatz, Prototyping

Implementierung

Physisches Modell Sollzustand

wie Entwurf

Installierung

Produktives IuK-System

Sollzustandsorientierung, Systemintegration, Umstellungsmethoden

Abb. ZAMIP-1 : Phasenziele und Methodikansütze im Phasenschema

Methodik für IuK-Projekte 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 Vorgehens systematisiert und festgelegt ist. Die Methodik für IuK-Projekte 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 Analyse soll sie eine Vorgehenssystematik für den Entwurf und die Implementierung enthalten. Sie soll aber auch bei der Installierung Hilfestellung leisten, kurz: sie soll möglichst alle Aufgaben umfassen. Eine allgemein akzeptierte, wissenschaftlich begründete, leistungsfähige und in der Praxis anwendbare Methodik 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 für IuK-Projekte geben könne; dies ist angesichts der Komplexität des Projektgegenstands unmöglich. Die Methodik muß daher eine Mischung verschiedener Methodikansätze sein. • Zweitens auf die Annahme, daß die Methodik für IuK-Projekte vom Projektkontext unabhängig ist; dies ist angesichts der Unterschiedlichkeit der Projektaufgaben in Wirtschaft und Verwaltung (und hier in den unterschiedlichen Anwendungsgebieten), der Unterschiedlichkeit der Teilobjekte der Projektaufgabe (z.B. Datensystem, Methodensystem und Arbeitsorganisation) und der Unterschiedlichkeit der Persönlichkeit und Qualifikation der Aufgabenträger in IuK-Projekten unwahrscheinlich.

ZAMIP - Ziel, Aufgaben und Methodik von IuK-Projekten

59

Methodikansätze für IuK-Projekte 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). Zusammenfassend wird dann erläutert, was bezüglich der Methodik für IuK-Projekte "herrschende Meinung" ist, mit anderen Worten: was als Paradigma angesehen werden kann. Folgende Methodikansätze sind erwähnenswert: • • • • • • • •

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

Der Systemansatz führt das aus der Systemtheorie und der Systemtechnik stammende Systemdenken für IuK-Projekte ein (vgl. Lerneinheit SYSIP). Sein Grundgedanke ist folgender: Ein gegebener Untersuchungsbereich soll so lange 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 Phasenschema gliedert die Gesamtaufgabe für IuK-Projekte 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 PROIP). 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 Phasenschemas ist die Verwendung der Grundkonzeption als konzeptuelles Modeil, 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 Ge-

60

Grundlagen

luK-Projekte

fahr, 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, daß sie in ein Anwendungsprogramm umgesetzt werden können. Der d a t e n o r i e n t i e r t e A n s a t z (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 eines IuK-Projekts 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 Vorteile des datenorientierten Ansatzes werden in Lerneinheit VGROB in Bd. 1 "Systemplanung" 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 in Bd. 1 "Systemplanung"). 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 Analyse wird zunächst der Istzustand erhoben und als physisches Modell abgebildet. Im Verlauf der Analyse werden die physischen Attribute entfernt, sodaß ein logisches Modell des Istzustands entsteht. Das logische Modell des Istzustands wird dann beim Entwerfen 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 ZAMIP-2 veranschaulicht den "Weg vom phy-

ZAMIP - Ziel, Aufgaben

und Methodik

von

luK-Projekten

61

sischen Modell des Istzustands zum physischen Modell des Sollzustands", der über die logischen Modelle des Istzustands und des Sollzustands führt.

Vorstudie

Feinstudie

Entwurf

Implementierung

Abb. Z A M I P - 2 : Der Weg zum logischen und z u m physischen Modell

Der prototyporientierte 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 Aus der Darstellung der Methodikansätze ist ersichtlich, daß ihnen das Denken in M o d e l l e n zugrunde liegt und daß - daraus folgend - das Verwenden von Modellen 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 PROVE), 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 für IuK-Projekte ist daher ihre Modellorientierung. Die verschiedenen Methodikansätze müssen zu einem Methodik-Mix kombiniert werden. Welchem Methodik-Mix der Vorzug gegeben wird, hängt vom Kontext ab und ist auch eine Frage der persönlichen Präferenzen der an einem IuK-Projekt beteiligten Personen. Erfahrungsgemäß folgt die Planungsmethodik primär einem systemtechnisch orientierten Phasenschema; alle anderen Metho-

62

Grundlagen

IuK-Projekte

dikansätze, die verwendet werden, lassen sich in das Phasenschema einordnen. Die vorherrschende Methodik für IuK-Projekte (ihr Paradigma) ist eine schrittweise präzisierende, systematisch auf Zwischenergebnissen aufbauende und doch möglichst ganzheitliche Vorgehensweise, eine Folge von aufeinander aufbauenden Zyklen. 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 ein MethodikMix am zweckmäßigsten, der 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. Methoden, Techniken und Werkzeuge Mit dem Einsatz von Methoden und Techniken soll in erster Linie die M e t h o d i k umgesetzt und damit die Erreichung der Projektziele unterstützt werden, beispielsweise: • • • • • •

die die die die die die

Erreichung der geplanten Qualität der Ergebnisse; S c h a f f u n g der Transparenz des Planungsprozesses; Einhaltung von geplanten Terminen und Kosten; Unabhängigkeit der Ergebnisse von den am Projekt beteiligten Personen; Wirksamkeit und die Wirtschaftlichkeit im Umgang mit den Ressourcen; Akzeptanz der Ergebnisse 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, D u r c h g ä n g i g k e i t und Beherrschbarkeit. D a viele Methoden und T e c h n i k e n manuell nur umständlich, bei größeren IuK-Projekten teilweise überhaupt nicht a n w e n d b a r sind, werden sie in W e r k z e u g e n implementiert (vgl. Lerneinheit W E R I P ) ; diese sollen die Wirksamkeit und Wirtschaftlichkeit der V e r w e n d u n g von Methoden und Techniken wesentlich verbessern bzw. ermöglichen. IuK-Projekt und

Informationsmanagement

Charakteristisch f ü r IuK-Projekte ist die Betrachtung von einzelnen Unternehmensteilen, h e r k ö m m l i c h e r w e i s e primär funktionsorientiert (wie z.B. Personalwesen, Produktionsplanung und -Steuerung, Vertrieb), neuerdings primär p r o z e ß o r i e n t i e r t (wie z.B. Logistik), für die ein IuK-System g e s c h a f f e n werden soll. Charakteristisch für das Informationsmanagement ist die unternehmensweite, g a n z h e i t l i c h e Orientierung; für das Unternehmen als G a n z e s soll eine Informationsinfrastruktur geschaffen (unter anderem durch IuK-Projekte), aufrechterhalten und genutzt werden.

ZAMIP - Ziel, Aufgaben

und Methodik

von IuK-Projekten

63

Die Planung und Realisierung von IuK-Projekten vollzieht sich in einem durch das Informationsmanagement vorgegebenen Handlungsspielraum; damit werden die Ziele des Informationsmanagements in IuK-Systeme umgesetzt. Abbildung ZAMIP-3 veranschaulicht diesen Zusammenhang. Die als Planungsziele und als Planungsergebnisse bezeichneten Schnittstellen zwischen dem strategischen Informationsmanagement und dem Projektmanagement einerseits sowie zwischen den IuK-Projekten 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 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) zu realisieren sind. • Schnittstelle Planungsergebnisse: Nach dem Abschluß aller Vorbereitungsarbeiten zur Installierung werden die durch IuK-Projekte geschaffenen Produkte so in die bestehende Informationsinfrastruktur eingefügt, daß sie produktiv genutzt werden können.

Abb. ZAMIP-3: Zusammenhang zwischen Projektmanagement und Informationsmanagement

Kennzeichnend für beide Schnittstellen ist die enge Zusammenarbeit zwischen Informationsmanagement und Projektmanagement. Das Erarbeiten des Projektportfolios durch das Informationsmanagement ist ohne Durchführung der Vorstudie (vgl. Lerneinheit ZAMVS) nicht möglich; erst durch die Vorstudie können Aussagen über die Kosten und den Nutzen von neuen IuK-Systemen gewonnen werden. Die Beurteilung installierter IuK-Systeme als "produktiv" kann nicht dem Projektmanagement allein überlassen werden; sie erfordert die Zusammenarbeit mit den Aufgabenträgern des Informationsmanagements.

64

Grundlagen

IuK-Projekte

Kontrollfragen 1. 2. 3. 4. 5.

W i e können die Ziele für IuK-Projekte gegliedert werden? W e l c h e Phasen für IuK-Projekte werden unterschieden? W e l c h e Ziele werden in welchen Phasen verfolgt? W a s wird unter "Methodik für IuK-Projekte" verstanden? W a r u m gibt es nicht die "eine" Methodik für IuK-Projekte?

Quellenliteratur Haberfellner, R.: Organisationsmethodik. In: Grochla, E. (Hrsg): Handwörterbuch der Organisation. 2. A., Poeschel, Stuttgart 1980, 1701 - 1710 Heinrich, L. J.: Z u r Methodik der Systemplanung in der Wirtschaftsinformatik. In: Schult, E. und Siegel, T h . (Hrsg.): Betriebswirtschaftslehre und Unternehmenspraxis. S c h m i d t , Berlin 1986, 83-99 Heinrich, L. J.: Der Prozeß der Systemplanung und -entwicklung. In: Kurbel, K. und Strunz, H. (Hrsg.): Handbuch der Wirtschaftsinformatik. Poeschel, Stuttgart 1989, 199 - 214 Heinrich, L. J.: I n f o r m a t i o n s m a n a g e m e n t . Planung, Ü b e r w a c h u n g und Steuerung der I n f o r m a tionsinfrastruktur. 5. A., Oldenbourg, München/Wien 1996 H e i n r i c h , L. J./Roithmayr, F.: W i r t s c h a f t s i n f o r m a t i k - L e x i k o n . 5. A., O l d e n b o u r g , M ü n c h e n / Wien 1995 S c h w a r z e , J.: S y s t e m e n t w i c k l u n g . Grundzüge der wirtschaftlichen P l a n u n g , E n t w i c k l u n g und E i n f ü h r u n g von Informationssystemen. Neue Wirtschaftsbriefe, Herne/Berlin 1996

Vertiefungsliteratur F i t z g e r a l d , J. et al.: F u n d a m e n t a l s of Systems Analysis. 2. Ed., John Wiley & Sons, N e w York et al. 1981 H i c e , G. F. et al.: S y s t e m D e v e l o p m e n t M e t h o d o l o g y . N o r t h Holland P u b l i s h i n g C o m p a n y , A m s t e r d a m et al. 1979 Olle, T. W . et al.: Information Systems Methodologies. A F r a m e w o r k for Understanding. 2. Ed., Addison-Wesley, W o k i n g h a m et al. 1991

SYSIP - Systemtechnik und IuK-Projekte 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 Projektmanagement-Methodik. Definitionen und Abkürzungen E m p f i n d l i c h k e i t s a n a l y s e (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. Problem (problem) = eine Handlungssituation, die durch ein Defizit an Wissen gekennzeichnet ist. 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 systemexterne 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).

66

Grundlagen

IuK-Projekte

Prinzipien der 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 IuK-Projekte ist das graphische Modell (z.B. als EntityRelationship-Modell zur Modellierung des Datensystems) von besonderer Bedeutung (vgl. Lerneinheit ERMOD in Bd. 2 "Systemplanung"). 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. A b b i l d u n g SYSIP-1 zeigt die Grundstruktur des systemtechnischen Planungsprozesses.

SYSIP - Systemtechnik

und IuK-Projekte

67

USW.

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

Planungsprozesses

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

Abbildung SYSIP-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.

68

Grundlagen

IuK-Projekle

• 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. SYSIP-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 SYSIP-3 mit ihren stufenspezifischen Bearbeitungsschritten ersichtlich sind. Die Abbildung zeigt auch, daß die Problemlösungsstufen bzw. ihre einzelnen Bearbeitungsschritte durch Rückkopp-

SYSIP - Systemtechnik

und IuK-Projekte

69

lungen miteinander vernetzt sind. Die in Abbildung SYSIP-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 in Bd. 1 "Systemplanung"), Methoden der Istzustandsanalyse (vgl. Lerneinheit ISTAN in Bd. 1 "Systemplanung"), 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 im engeren Sinn): 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 CHECK) 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 SYSIP-4 dargestellt. Wie die Pfeile in den Feldern der Matrix andeuten, ist die Abbildung zeilenweise zu interpretieren.

Prosrammstudie Systemvorstudie Systemhauptstudie Systcmerstellung

A n » » A-)|®—

Systemeinführung Systembetrieb Systemwechsel

•— •>

•— •— •—

•— •— •—

•— •—

• •

Ausführungsplanung

Ausarbeitung (Entwicklungsplanung)

Auswahlentscheidung

Bewertung (Nutzwertanalyse)

Konzeptanalyse (Systemanalyse)

Phasen

Konzeptentwurf (Systemsynthese)

ProblemlösungsN. stufe

luK-Projekte

Problemdefinition (Zielbildung)

Grundlagen

Zustandsanalyse

70

—> A^]

—

•

—

—

•

—

—

•

—

•

—

—

•

—

•

—

—

•

-»A

4 2

—

•

—

•

—>A7I —»An

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

Demonstrationsbeispiel Es wird die Orientierung der Projektmanagement-Methodik a m S y s t e m a n s a t z (vgl. L e r n e i n h e i t Z A M I P ) d u r c h G e g e n ü b e r s t e l l u n g d e r P h a s e n d e r s y s t e m t e c h n i s c h e n V o r g e h e n s w e i s e ( A b b i l d u n g S Y S I P - 5 , linker Teil) m i t d e n e n d e s Phasens c h e m a s f ü r I u K - P r o j e k t e ( A b b i l d u n g S Y S I P - 5 , r e c h t e r Teil) g e z e i g t . D i e d e m Systembetrieb und d e m Systemwechsel der systemtechnischen Vorgehensweise entsprechende Nutzung und Wartung sowie die Neukonstruktion am Ende des L e b e n s z y k l u s v o n I u K - S y s t e m e n g e h ö r e n nicht z u m P h a s e n s c h e m a f ü r I u K P r o j e k t e ; sie sind d e m L e b e n s z y k l u s - M a n a g e m e n t z u g e o r d n e t (vgl. L e r n e i n h e i t L E M A N im Band "Informationsmanagement"). Vorstudie Feinstudie Entwurf Implementierung Installierung N u t z u n g , W a r t u n g und Neukonstruktion Abb. SYSIP-5: Zuordnung der Phasen der systemtechnischen Vorgehensweise zum Phasenschema für IuK-Projekte

SYSIP - Systemtechnik

und

IuK-Projekte

71

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 für IuK-Projekte?

Quellenliteratur Zangemeister, Ch.: Systemtechnik. In: Grochla, E. (Hrsg.): Handwörterbuch der Organisation. 2. A„ Poeschel, Stuttgart 1980, 2190 - 2204 Vertiefungsliteratur Daenzer, W . F. (Hrsg.): Systems Engineering. Leitfaden zur methodischen D u r c h f ü h r u n g u m fangreicher Planungsvorhaben. 6. A., Hanstein, Köln und Industrielle Organisation, Z ü r i c h 1988 Zangemeister, Ch.: Nutzwertanalyse in der Systemtechnik. 4. A., Wittemann'sche V e r l a g s b u c h handlung, München 1976

PROIP - Prozeßcharakter von IuK-Projekten Lernziele Sie können die Aufgabe eines IuK-Projekts in Teilaufgaben gliedern und diese zu Phasen ordnen. Sie können die wichtigsten Aufgaben der einzelnen Phasen angeben. Sie sind in der Lage, den Input und den Output jeder Phase zu beschreiben. Sie erkennen den Prozeßcharakter von IuK-Projekten und können die konstitutiven Merkmale dieses Arbeitsprozesses erläutern. Definitionen und Abkürzungen E n t w u r f (systems design) = die Phase eines IuK-Projekts, deren Zweck die Überführung der (angepaßten) Grundkonzeption in ein logisches Modell des Sollzustands ist. Synonym: Systementwurf. F e i n s t u d i e (detailed systems study) = die Phase eines IuK-Projekts, deren Zweck die Anpassung der Grundkonzeption aufgrund der Ergebnisse einer Istzustandsuntersuchung ist. Synonym: Detailstudie. G r u n d k o n z e p t i o n (preliminary design) = der umrißartige, grobe Entwurf des zu schaffenden IuK-Systems anhand seiner wichtigsten Eigenschaften, die es auf einer globalen Ebene möglichst vollständig beschreibt, die Realisierungswege im einzelnen aber offen läßt. Implementierung (implementation) = die Phase eines IuK-Projekts, deren Zweck die Überführung des logischen Modells des Sollzustands in ein physisches Modell des Sollzustands ist. Synonym: Systemimplementierung. Installierung (installation) = die Phase eines IuK-Projekts, deren Zweck die Überführung des physischen Modells des Sollzustands in ein produktives IuKSystem ist. Synonym: Systemeinführung. K o o p e r a t i o n (Cooperation) = ein sozialer Prozeß zwischen mehreren Aufgabenträgern 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. Phase (phase) = eine nach zeitlichen und logischen Gesichtspunkten gebildete Teilmenge eines IuK-Projekts. physisches Modell (physical model) = eine Systemabbildung, die mit physischen Attributen belegt ist. Planungsziel (planning goal) = ein Ziel, das einem IuK-Projekt vom Auftraggeber vorgegeben ist. Projektziel (project goal) = ein Ziel, das zur Planung, Überwachung und Steuerung eines IuK-Projekts verwendet und das aus den Planungszielen abgeleitet wird. Vorstudie (initial study) = die Phase eines IuK-Projekts, deren Zweck der Entwurf der Grundkonzeption ist, die aus mehreren alternativen Systemkonzepten als das optimale Systemkonzept bestimmt wurde. Synonyme: Grobstudie, Voruntersuchung, Durchführbarkeitsstudie, Machbarkeitsstudie.

PROIP - Prozeßcharakter

von IuK-Projekten

73

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

erste Phase: Vorstudie; zweite Phase: Feinstudie; dritte Phase: Entwurf; vierte Phase: Implementierung; fünfte Phase: Installierung.

Vorstudie und Feinstudie werden im allgemeinen unter der Bezeichnung Systemanalyse (weil es sich dabei vornehmlich um analysierende Tätigkeiten handelt), Entwurf und Implementierung unter der Bezeichnung Systementwicklung (weil es sich dabei letztlich um Entwicklungstätigkeiten handelt) zusammengefaßt. Die vier Begriffe Analysieren, Entwickeln, Implementieren und Installieren bringen in Kurzform die wesentlich unterschiedlichen Aufgaben, die in einem IuK-Projekt zu bearbeiten sind, zum Ausdruck. Die Ziele der Phasen und die in den Phasen zu bearbeitenden Aufgaben werden an anderer Stelle erläutert (vgl. Lerneinheiten ZAMVS, ZAMFS, ZAMSE, ZAMIM und ZAMIN); dabei wird auch auf die Methoden und Techniken zur Unterstützung der Aufgabendurchführung eingegangen. Im folgenden werden die Aufgaben der Phasen in Kurzform dargestellt. Aufgaben der Phasen Aufgaben der Vorstudie sind: • das Festlegen der Sachziele und der Formalziele (Anforderungen), ausgehend von den vorgegebenen Planungszielen; • das Entwerfen von alternativen Systemkonzepten und die Auswahl des optimalen Systemkonzepts als Grundkonzeption; • das Durchführen der Projektplanung. Aufgaben der auf dem Ergebnis der Vorstudie, nämlich der Grundkonzeption, aufbauenden Feinstudie sind: • das Erfassen des Istzustands (Istzustandserfassung); • das Analysieren des Istzustands (Istzustandsanalyse); • das Optimieren des Istzustands (Istzustandsoptimierung) und das Anpassen der Grundkonzeption auf Grund der Ergebnisse der Istzustandsanalyse. Aufgaben des auf dem Ergebnis der Feinstudie, nämlich der angepaßten Grundkonzeption, aufbauenden Entwurfs sind:

74

Grundlagen

IuK-Projekte

• das Strukturieren des in der Grundkonzeption abgebildeten Gesamtsystems in Teilprojekte (Systemgliederung); • das Entwerfen des Sollkonzepts der Teilprojekte (Systementwurf); • die Integration der Systementwürfe zu den Teilprojekten zum Gesamtsystem (Systementwurfsintegration); • das Bestimmen des quantitativen und qualitativen Technikbedarfs für den Systementwurf (Systemauswahl) und das Beschaffen der Techniksysteme. 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 des Entwurfs, nämlich dem logischen Modell des Sollzustands, aufbauenden Implementierung sind: • das Entwickeln des Datensystems; • das Entwickeln des Methodensystems, insbesondere Software-Entwicklung; • das Entwickeln der Arbeitsorganisation, sowohl der Strukturorganisation als auch der Ablauforganisation; • das Entwickeln des Transportsystems; • das Entwickeln des Sicherungssystems; • die Integration der Entwicklungsergebnisse der Teilprojekte zum Gesamtsystem (Systementwicklungsintegration). Aufgaben der auf den Ergebnissen aller Planungsphasen, insbesondere auf dem Ergebnis der Implementierung (physisches Modell Sollzustand) aufbauenden Installierung sind: • das Vorbereiten der Installierung; • das Durchführen der Installierung. 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. Prozeßcharakter des Phasenschemas Das Phasenschema ist primär ein grober O r d n u n g s r a h m e n für Aufgaben, Methodik und Methoden von IuK-Projekten. Für die Projektarbeit stellt es eine wichtige Orientierung dar, die in mehrfacher Hinsicht präzisiert werden muß, insbesondere die Festlegung der Art der Aufgaben, die durchzuführen sind, und des Aufgabenumfangs (Strukturplanung). Darüber hinaus sind die technologische Abhängigkeit zwischen den Aufgaben und der Zeitbedarf für die Durchführung der Aufgaben zu bestimmen (Ablaufplanung). Erst auf der Grundlage dieser

PROIP - Prozeßcharakter

von luK-Projekten

75

planenden, projektbezogenen Tätigkeiten kann ein IuK-Projekt detailliert als Prozeß beschrieben werden (vgl. Lerneinheit PROPL).

Bereits das Phasenschema zeigt aber die Prozeßorientierung, indem die Inputs (Voraussetzungen) und die Outputs (Ergebnisse) der Phasen definiert werden und durch ihre Anordnung deutlich gemacht wird, welche Ergebnisse welcher Phasen Voraussetzung für welche anderen Phasen sind; die wichtigsten Rückkopplungen sind im Phasenschema angegeben.

76

Grundlagen

luK-Projekte

Abbildung PROIP-1 zeigt die prozeßorientierte Ordnung der Phasen einschließlich ihrer Voraussetzungen bzw. Ergebnisse. Beispielsweise ist die Grundkonzeption das Ergebnis der Vorstudie und die Voraussetzung für die Feinstudie. Die Durchführung der Feinstudie ist ohne Abschluß der Vorstudie sinnlos. Damit wird aber nicht gesagt, daß die Grundkonzeption als Ergebnis der Vorstudie "festgeschrieben" werden muß und unveränderlich ist. Dies gilt analog für die anderen Phasen. Beispielsweise ist das physische Modell des Sollzustands Ergebnis der Implementierung und Voraussetzung für die Installierung. Das heißt nicht, daß nicht bestimmte, vom Vorliegen des physischen Modells unabhängige Aufgaben der Installierung vor dem vollständigen Abschluß der Implementierung bearbeitet werden können. Die Beispiele verdeutlichen die Notwendigkeit einer Projektplanung auf der Grundlage des Phasenschemas. Aus dem Gesagten ist zu erkennen, daß eine dem Phasenschema folgende Projektplanung 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. In der Literatur werden auch andere Phasenmodelle diskutiert, insbesondere die unter den Bezeichnungen Wasserfallmodell und Spiralmodell bekannt gewordenen, 1950 bzw. 1986 von B. W. Boehm beschriebenen Modelle. • Wasserfallmodell: Ein Phasenmodell, dessen Bezeichnung auf die treppenförmig, von links oben nach rechts unten angeordnete Abfolge der Phasen sowie darauf zurückzuführen ist, daß "wie bei einem Wasserfall" die Ergebnisse einer Phase in die nächste Phase "fallen". Die Phasen werden entsprechend ihrer Anordnung sequentiell abgearbeitet; jede Phase endet mit einer Überprüfung der Phasenergebnisse. • Spiralmodell: Ein Phasenmodell, dessen Bezeichnung darauf zurückgeht, daß die einzelnen Phasen in einer durch die Projektplanung vorgegebenen, festen Abfolge mehrere Male durchlaufen werden. Wie beim Wasserfallmodell sind die einzelnen Phasen voneinander getrennt; ein neuer Entwicklungsabschnitt wird erst dann begonnen, wenn der vorhergehende abgeschlossen ist. Abbildung PROIP-2 veranschaulicht die Phasengliederung und den spiralförmigen Projektverlauf.

Projektverlauf Phase I\

Phase I

Phase III

Phase II Abb. PROIP-2: Spiralmodell

PR01P - Prozeßcharakter

von

luK-Projekten

77

Wasserfallmodell und Spiralmodell sind immer wieder kritisiert worden. Ersteres hat den Mangel, Rückkopplungen in frühere Phasen nicht explizit vorzusehen, letzteres hat darüber hinaus den Mangel, daß es mehrere "Runden" der Projektplanung und -realisierung unterstellt, ehe das geplante Produkt zur Verfügung steht. Beide Annahmen sind unrealistisch. Ein Vergleich der beiden Modelle mit dem in Abbildung PROIP-1 wiedergegebenen Phasenschema zeigt, daß hier die genannten Mängel vermieden sind: Die Projektaufgabe wird in einem von Rückkopplungen durchsetzten, phasenweise gegliederten Prozeß in einem Planungs- und Realisierungszyklus abgearbeitet. Dem Spiralmodell weitgehend ähnlich ist das zyklische Projektmodell; die Produktentwicklung wird als eine Folge von Entwicklungszyklen angesehen (auch als evolutionäre Systementwicklung bezeichnet). Jeder Entwicklungszyklus hat die Herstellung und den Einsatz einer Systemversion zum Gegenstand. Schon ein geringes Verständnis von Projektmanagement zeigt die Unvereinbarkeit einer solchen Vorgehensweise mit einer projektorientierten Entwicklungsarbeit: Jeder der geforderten Entwicklungszyklen entspricht einem Projektgegenstand; das zyklische Projektmodell ist eine Folge mehrerer unterschiedlicher Projekte. Charakter des Planungsprozesses Ein IuK-Projekt ist ein Arbeitsprozeß, in dem Systemplaner und Benutzer zusammenwirken müssen. Dies ergibt sich aus der Tatsache, daß es Systemplanern nicht möglich ist, die Anforderungen an die Gestaltung des zu schaffenden IuKSystems 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 und der Benutzung des IuK-Systems aufgehoben. Da das Zusammenwirken zur Herstellung eines den Planungszielen entsprechenden, benutzbaren Produkts die gegenseitige Abstimmung erfordert, ist ein IuK-Projekt wesentlich durch Kooperation gekennzeichnet. Da ein IuK-Projekt immer darauf ausgerichtet ist, einen bestimmten Ausschnitt der Wirklichkeit betrieblicher Arbeit neu zu gestalten, ist das Produkt zu Beginn des Arbeitsprozesses weitgehend unbekannt; es kann nur sukzessiv durch Planungsentscheidungen präzisiert werden. Viele dieser Planungsentscheidungen können nur auf der Grundlage geistig-schöpferisch geschaffener Entwurfsalternativen gefällt werden, sodaß Kreativität - neben Kooperation - das zweite wesentliche Kennzeichen dieses Arbeitsprozesses 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. Koordination kann aber nur stattfinden, wenn die Beteiligten über Möglichkeiten der Kommunikation verfügen. Kooperation, Kreativität, Koordination und Kommunikation sind daher die vier konstitutiven Merkmale des Arbeitsprozesses, der durch ein IuK-Projekt geplant und abgewickelt wird.

78

Grundlagen

IuK-Projekte

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 Lerneinheiten WERIP und VORMO). In das Vorgehensmodell werden Methoden und Techniken und die sie unterstützenden Werkzeuge "eingehängt". Das Vorgehensmodell ist also sowohl Produktionssystematik (Tätigkeiten, Ergebnisse, Tätigkeitsfolge, Termine, Kosten usw.) als auch Konstruktionssystematik (Methoden, Techniken, Werkzeuge). Das Vorgehensmodell ist universell, wenn es nur eine Grobstruktur der Tätigkeiten, Resultate, Methoden usw. und damit des Vorgehens angibt und dem Anwender die Verfeinerung, die situativ gewählt wird (z.B. in Abhängigkeit von dessen Qualifikation), überläßt. Für einzelne Phasen eines IuK-Projekts gibt es verschiedene Methodikansätze (z.B. datenorientierter Ansatz versus funktionsorientierter Ansatz beim Systementwurf, vgl. Lerneinheit ZAMIP). 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 Ziel eines IuK-Projekts, ein produktives IuK-System zu schaffen, wird das Projektergebnis als Produkt gekennzeichnet. Dieses Produkt kann in Kernprodukt, erwartetes Produkt, erweitertes Produkt und potentielles Produkt gegliedert werden. Abbildung PROIP-3 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 Kemprodukt hinausgehende Funktionen und Leistungen. Erwartet ein Anwender über das Kernprodukt hinausgehende Funktionen und Leistungen, dann kommt es nur dann zur produktiven Verwendung, wenn das Projektergebnis 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, sondern um Nebenfunktionen (vgl. Lerneinheit WERTA).

PROIP - Prozeßcharakter von IuK-Projekten

•

79

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. PROIP-3: Schichten eines !uK-Systems als Produkt (nach Lamprecht/Jackson) Kontrollfragen 1. 2. 3. 4. 5.

W e l c h e s sind die fünf Aufgaben (Phasen) eines IuK-Projekts? Wie können der Input und der Output jeder Phase beschrieben werden? Worin besteht der Unterschied zwischen logischem Modell und physischem Modell? W e l c h e Eigenschaften bestimmen den Prozeßcharakter des Phasenmodells? Wie kann das Projektergebnis als Schichtenmodell beschrieben werden?

Quellcnliteratur Heinrich, L. J.: Zur Methodik der Systemplanung in der Wirtschaftsinformatik. In: Schult, E. und Siegel, Th. (Hrsg.): Betriebswirtschaftslehre und Unternehmenspraxis. Schmidt, Berlin 1986, 83 - 99 Heinrich, L. J.: Der Prozeß der Systemplanung und -entwicklung. In: Kurbel, K. und Strunz, H. (Hrsg.): Handbuch der Wirtschaftsinformatik. Poeschel, Stuttgart 1989, 199 - 2 1 4 Heinrich, L. J.: S y s t e m p l a n u n g 2 Bd. 6. A. (Bd. I) bzw. 5. A. (Bd. 2), O l d e n b o u r g , M ü n chen/Wien 1994 L a m p r e c h t , M . / J a c k s o n , I.: S t r a t e g i s c h e 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 Management 1 / 1 9 8 9 , 2 8 - 3 5 Vcrtiefungsliteratur Avison, D. E./Fitzgerald, G.: Information Systems D e v e l o p m e n t - Methodologies, T e c h n i q u e s and Tools. Blackwell Scientific Publications, Oxford et al. 1988 B o e h m , B. W.: A Spiral M o d e l for S o f t w a r e Development and Enhancement. In: A C M Sigsoft S o f t w a r e Engineering Notes 11/1986, 22 - 42 Chroust, G.: Modelle der Software-Entwicklung. Oldenbourg, München/Wien 1992 Platz, J./Schmelzer, H. J.: P r o j e k t m a n a g e m e n t in der industriellen Forschung und Entwicklung E i n f ü h r u n g anhand von Beispielen aus der Informationstechnik. Springer, Berlin et al. 1986 Reisin, F . - M . : K o o p e r a t i v e G e s t a l t u n g in partizipativen S o f t w a r e p r o j e k t e n . P. Lang, Frankfurt/M. et al. 1992

ZIELP - Zielplanung für IuK-Projekte Lernziele Sie kennen den Zweck der Planung der Sachziele und der Formalziele (Zielplanung). Sie können Sachziele und Formalziele in geeigneter Weise gliedern und Aussagen über die Zielinhalte und die Zielbeziehungen machen. Sie können Vorgehensweisen für den Arbeitsprozeß der Sachzielplanung und der Formalzielplanung angeben. Sie kennen den Zusammenhang zwischen der Zielplanung und der Anforderungsanalyse. Definitionen und Abkürzungen Abstraktion (abstraction) = die wichtigen Aspekte von den unwichtigen Aspekten trennen und nur die wichtigen betrachten. 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. F u n k t i o n (function) = eine Aufgabe oder Teilaufgabe, die den mit ihr verfolgten Zweck konkret beschreibt. M T B F = 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. M T T F = 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. Objekttyp (entity type) = eine Klasse von Objekten mit gleichen oder ähnlichen Merkmalen. Synonym: Objektmenge. Projektion (projection) = das Beschreiben eines Systems aus unterschiedlichen Sichten, von denen jede das Gesamtsystem mit einer Teilmenge seiner Eigenschaften abbildet. 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. Spezifizieren (specification) = die Tätigkeit des Erhebens und Dokumentierens von Anforderungen. 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.

ZIELP - Zielplanung für luK-Projekte

81

Zweck der Zielplanung Aus den Planungszielen, die einem IuK-Projekt vom Auftraggeber vorgegeben sind, werden von der Projektleitung die Projektziele in Form von Leistungszielen, Terminzielen und Kostenzielen abgeleitet (vgl. Lerneinheit PROPL). Im folgenden wird zunächst auf die Planung der Leistungsziele, wie sie für IuKProjekte typisch sind, näher eingegangen. Dabei wird die übliche Gliederung von Zielen in Sachziele und Formalziele verwendet. Sachziele von IuK-Projekten sind die betrieblichen Aufgaben, die Teil des zu schaffenden IuK-Systems sein sollen. Zur Spezifikation der Sachziele ist ihre Gliederung in Teilziele erforderlich, um eine für die Projektrealisierung ausreichend genaue Beschreibung zu ermöglichen. Formalziele beschreiben die Qualität, mit der die Sachziele erreicht werden sollen. Auch für sie gilt, daß eine geeignete Gliederung in Teilziele erforderlich ist. Sachziele und Formalziele werden in einem IuK-Projekt zusammenfassend auch als Anforderungen bezeichnet. Verfahren, Methoden, Werkzeuge usw. zur systematischen Ermittlung der Anforderungen heißen zusammenfassend Anforderungsanalyse; dabei stehen die als Sachziele bezeichneten Anforderungen im Vordergrund. Zielplanung ist in besonders herausragender Weise ein kooperativer und zyklischer Prozeß. Das heißt, daß das Ermitteln und Festlegen der Anforderungen durch die Betroffenen (z.B. 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. Gliederung der Sachziele Sachziele können zunächst wie folgt gegliedert werden: • Anforderungen, welche die zu unterstützenden Aufgaben durch ihre Funktionen beschreiben; sie werden als Funktionsanforderungen bezeichnet; • Anforderungen, welche die zu unterstützenden Aufgaben durch quantitative Eigenschaften, wie Umfang und Häufigkeit der Funktionen, beschreiben; sie werden als Leistungsanforderungen bezeichnet; • Anforderungen, welche die zu unterstützenden Aufgaben durch ihre Schnittstellen beschreiben; sie werden als Schnittstellenanforderungen bezeichnet. Funktionsanforderungen. Eine Funktion kann durch folgende Merkmale präziser beschrieben werden: • durch die Daten, die zur Funktionserfüllung erforderlich sind (Datenanforderungen); • durch die Methoden, die zur Funktionserfüllung erforderlich sind (Methodenanforderungen). Datenanforderungen beschreiben die wichtigsten Objekttypen des geplanten Datensystems (vgl. Lerneinheiten WDASY und EDASY in Bd. 2 "Systemplanung"), Methodenanforderungen die wichtigsten Objekttypen des geplanten Methodensystems (vgl. Lerneinheiten WMESY und EMESY in Bd. 2 "System-

82

Grundlagen

luK-Projekte

planung"). Die Wichtigkeit einer Funktion kann durch Beantwortung der Frage bestimmt werden, ob sie - im Sinn der Wertanalyse (vgl. Lerneinheit WERTA) Hauptfunktion ist. Die Wichtigkeit jeder einzelnen Hauptfunktion kann abgeschätzt werden, indem ihre Bedeutung für die Erreichung der Planungsziele bestimmt wird. Leistungsanforderungen. Die Funktionsanforderungen machen keine Aussage darüber, welchen Umfang die Funktionen haben und mit welcher Häufigkeit sie erfüllt werden müssen. Mit den Funktionsanforderungen ist auch nichts über den Umfang bzw. die Häufigkeit der Datenanforderungen und der Methodenanforderungen ausgesagt. 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.

Schnittstellenanforderungen. Die wichtigsten Schnittstellen innerhalb des zu schaffenden IuK-Systems (zwischen den Funktionen) sowie zwischen dem IuKSystem und seinem Umsystem (andere IuK-Systeme und Benutzersystem) müssen geplant werden. Die Schnittstelle zum Benutzersystem (Benutzerschnittstelle) ist dabei von besonderer Bedeutung. Mit ihr werden beispielsweise Aussagen über die Beziehungen zwischen der Informationsnachfrage und den Objekttypen der Daten und der Methoden gemacht, also darüber, ob die Informationsnachfrage durch die Datenanforderungen und die Methodenanforderungen befriedigt, das heißt in das Informationsangebot umgesetzt werden kann.

Abb. ZIELP-1: Struktur der Sachziele

Die Betonung liegt bei allen drei Gruppen von Anforderungen ausdrücklich auf "wichtig" bzw. "ungefähr", weil es Zweck der Sachzielplanung ist, die Anforderungen so genau zu erfassen und zu beschreiben, wie es für die Projektplanung erforderlich ist; dies mag für den Systementwurf nicht ausreichen, sodaß im Projektverlauf eine Präzisierung notwendig ist. Abbildung ZIELP-1 zeigt das Ergebnis der Zerlegung der Sachziele.

Z1ELP - Zielplanung für luK-Projekte

83

Zielinhalte der Sachziele Zielinhalte für Sachziele können nur für ein bestimmtes IuK-Projekt angegeben werden. Zielinhalt der Funktionen meint den konkreten Zweck der Funktionen (z.B. die Funktion Nettolohnermittlung bei der Lohn- und Gehaltsverrechnung, deren Zweck die Ermittlung des Nettolohns ist). Zielinhalt der Daten meint die konkreten Objekttypen der Daten (z.B. der Objekttyp Lohnempfänger bei der Lohn- und Gehaltsverrechnung, dessen Objekte die einzelnen Lohnempfänger sind). Zielinhalt der Methoden meint die konkreten Objekttypen der Methoden (z.B. ein bestimmter Algorithmus zur Ermittlung des Bruttolohns bei der Lohnund 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). 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 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, j e 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 weitgehend bekannt sind, im zweiten Fall neuartig und daher weitgehend unbekannt sein können. 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 ZIELP-2): • Erster Arbeitsschritt: Festlegen der Funktionen. Das Festlegen der Sachziele beginnt damit, aus den Planungszielen 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 festgelegt.

84

Grundlagen

luK-Projekte

• Dritter Arbeitsschritt: Festlegen der Schnittstellen. Die wichtigsten Schnittstellen, die zwischen den Funktionen des zu schaffenden IuK-Systems sowie zwischen diesem und seinem Umsystem bestehen, werden festgelegt. • 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 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 P r ü f k r i t e r i e n zur Verifizierung der Anforderungen verlangt werden, etwa folgende: • 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. • Anderbarkeit: Eine Spezifikation ist (leicht) änderbar, wenn Anforderungen aus ihr entfernt und/oder Anforderungen nachträglich in sie aufgenommen werden können.

ZI ELP - Zielplcmung für

IuK-Projekte

85

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 Prüfkriterien miteinander konfliktär, sodaß es nicht möglich ist, alle zusammen 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). Gliederung der Formalziele Die Formalziele können zunächst nach dem Objekt, auf das sie sich beziehen, wie folgt gegliedert werden: • Formalziele, welche die Qualität oder die Güte des Arbeitsprozesses beschreiben (Prozeßqualität). • Formalziele, welche die Qualität oder die Güte der Ergebnisse dieses Arbeitsprozesses beschreiben (Produktqualität). Formalziele für Prozeßqualität können in Leistungs-, Termin- und Kostenziele zerlegt werden. Leistungsziele sind in diesem Zusammenhang die Qualitätsforderungen für die Sachziele, sodaß Leistungsziele sowohl Sachziele als auch Qualitätsziele sind (Viereck statt Dreieck der Projektziele, vgl. Lerneinheit PROPL). Terminziele sind Ziele, welche die geplanten Zeitpunkte für die Erbringung von Zwischenergebnissen und Ergebnissen festlegen. Kostenziele sind Ziele, welche den geplanten und bewerteten Verbrauch an Gütern und Dienstleistungen für die Erbringung von Zwischenergebnissen und Ergebnissen festlegen. Weitere Formalziele zur Beschreibung von 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 zur Beschreibung von Produktqualität können in Nutzungsziele und Wartungsziele zerlegt werden. Nutzungsziele beschreiben die Qualität der Nutzung der Ergebnisse; sie können zusammenfassend mit Brauchbarkeit oder Gebrauchsgüte bezeichnet werden. 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. Wartungsziele beschreiben Qualitätsmerkmale der Produkte bezüglich ihrer Anpassung an veränderte Anforderungen (insbes. an veränderte Sachziele, aber auch an veränderte Nutzungsziele); sie werden zusammenfassend als Wartbarkeit bezeichnet. Eine Präzisierung der Wartungsziele kann nach den Qualitätsmerkmalen Änderbarkeit (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ätsforderungen beschreiben, zu berücksichtigen. Sie werden

86

Grundlagen

IuK-Projekte

unter der Bezeichnung Rahmenziele zusammengefaßt. Rahmenziele legen Qualitätsforderungen fest, die auf alle anderen Formalziele einwirken. Abbildung ZIELP-3 zeigt das Ergebnis der Zerlegung der Formalziele.

Abb. ZIELP-3: Struktur der Formalzicle

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) typische Rahmenziele, die wie folgt erläutert werden können: • Der Innovationsgrad beschreibt, in welchem Umfang mit dem zu schaffenden IuK-System, durch die Berücksichtigung neuer, bisher nicht oder nicht ausreichend beachteter Erkenntnisse und/oder verwendeter IuK-Technologien, 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 IuK-System 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 IuK-System 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 IuK-Systeme verändert werden. • Der Kooperationsgrad macht Aussagen darüber, wie intensiv Aufgabenträger bei der gemeinsamen Abwicklung von Arbeitsaufgaben durch Koor-

ZIELP - Zielplanung für luK-Projekte

87

dination 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 IuK-Systems (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 ZIELP-3 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 ZIELP-3 genannten Formalziele decken im wesentlichen, nicht aber vollständig die Merkmale ab, mit denen üblicherweise die Qualität von IuKProzessen und luK-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. Die in Abbildung ZIELP-3 genannten Formalziele können wie folgt erläutert werden: • Akzeptanz ist ein Merkmal der Produktqualität; es beschreibt die Eigenschaft eines IuK-Systems, die Zustimmungsbereitschaft der durch das 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 IuK-System 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). • Änderbarkeit (auch: Flexibilität) ist ein Merkmal der Produktqualität; es beschreibt die Eigenschaft eines IuK-Systems, 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 IuK-Systems, die vom Aufgabenträger benötigten Funktionen, Leistungen und Schnittstellen zur Verfügung zu stellen. Primäre Einflußgröße der Aufgabenbezogenheit ist Wirksamkeit (was z.B. heißt: j e größer die Wirksamkeit, desto größer die Aufgabenbezogenheit).

88

Grundlagen

luK-Projekte

Zielinhalt

Beschreibt

Beschreibt

Prozeßqualität

Produktqualität

Akzeptanz

X

Änderbarkeit

X

Aufgabenbezogenheit

X

Benutzbarkeit

X

Produktivität

X

X

Sicherheit

X

Testbarkeit

X

Übertragbarkeit

X

Verfügbarkeit

X

Verständlichkeit

X

Wirksamkeit

X

X

Wirtschaftlichkeit

X

X

Zuverlässigkeit

X

X

A b b . Z I E L P - 4 : Formalziele für Prozeß- und Produktqualität

• Benutzbarkeit ist ein Merkmal der Produktqualität; es beschreibt eine Menge von Eigenschaften, die eine einfache, leicht erlernbare Benutzung des IuKSystems 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 ein IuK-Projekt eingesetzt werden, im Verhältnis zum mengenmäßigen Ergebnis eines IuK-Projekts (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 ein IuK-System eingesetzt werden, im Verhältnis zum mengenmäßigen Ergebnis des IuK-Systems (z.B. Anzahl durchgeführter Transaktionen). In Abhängigkeit von den verwendeten Verbrauchs- und Ergebnismengen werden also verschiedene Prozeß- oder Produktphänomene festgelegt, an die Produktivitätsforderungen 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

ZIELP - Zielplanung für luK-Projekte

89

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 IuK-Systems, 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: j e größer die Vertraulichkeit, desto größer die Sicherheit). Testbarkeit (auch: Prüfbarkeit) ist ein Merkmal der Produktqualität; es beschreibt die Eigenschaft eines IuK-Systems, 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 IuK-Systems 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 IuK-System die vorhandenen Funktionen mit den geforderten Leistungen fehlerfrei ausführen kann. Als Meßgröße werden MTBF, M T T F 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). 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 IuK-Systems offenlegen zu können. Wirksamkeit ist ein Merkmal der Produktqualität; es beschreibt die Übereinstimmung zwischen den im IuK-Projekt geplanten und den im IuK-System 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 das IuK-Projekt eingesetzt werden, im Verhältnis zum wertmäßigen Ergebnis des IuK-Projekts (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 Nutzung des IuK-Systems eingesetzt werden, im Verhältnis zum wertmäßigen Ergebnis der Systemnutzung (z.B. Wert der durchgeführten Transaktionen). 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 Projektabwicklung.

90

Grundlagen

IuK-Projekte

Zuverlässigkeit als Merkmal der Produktqualität beschreibt die Wahrscheinlichkeit der Einhaltung aller anderen Formalziele bei der Projektabwicklung. 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 ZIELP-5):

• Erster Arbeitsschritt: Ziclinhalte 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 Zielinhalte zu bestimmen. • 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.

ZIELP - Zielplanung für IuK-Projekte 91 • 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. Zielbeziehungen Zielbeziehungen zwischen den Sachzielen können nur im Zusammenhang mit einem bestimmten IuK-Projekt beschrieben werden; idealtypische Zielbeziehungen können nicht angegeben werden (im Unterschied zu den Formalzielen, vgl. weiter unten). 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). Aufgabe der Sachzielplanung ist es daher auch, die in einem konkreten IuK-Projekt bestehenden Beziehungen zwischen den Sachzielen aufzudecken. Mit der Nennung von Einflußgrößen bei der Erläuterung der Zielinhalte der Formalziele wurde bereits darauf hingewiesen, daß zwischen den Zielen Beziehungen bestehen (Zielbeziehungen). Zielbeziehungen sind, idealtypisch betrachtet, entweder komplementär oder konfliktär oder indifferent. • Z i e l k o m p l e m e n t a r i t ä t : Zwei Ziele Z\ und Z2 sind komplementär, wenn mit der Steigerung der Zielerreichung von Z\ die Zielerreichung von Z2 steigt. • Z i e l k o n f l i k t : Zwei Ziele Z] und Z2 sind konfliktär, wenn mit der Steigerung der Zielerreichung von Z| die Zielerreichung von Z2 sinkt. • Zielindifferenz: Zwei Ziele Z\ 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 A u s m a ß der Zielerreichung. Abbildung ZIELP-6 zeigt am Beispiel der Ziele Produktivität (Zj) 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.

92

Grundlagen

IuK-Projekle

Anforderungsanalyse Mit der Anforderungsanalyse (Requirements Engineering) wird die Zielplanung, also das Festlegen der A n f o r d e r u n g e n an das zu schaffende IuK-System, methodisch unterstützt. Die Methoden der Anforderungsanalyse sollen die im Arbeitsprozeß eines IuK-Projekts involvierten Gruppen (vgl. Lerneinheit PROVE) bei 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. 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 in Bd. 1 "Systemplanung") gefällt, von denen ausgehend die Grundkonzeption festgelegt wird. Mängel bei der Anforderungsanalyse (z.B. fehlende Funktionen) können in späteren Projektphasen nur mit großem Aufwand behoben werden. Dies kann zu einem völligen Neuaufwurf führen. Fehler bei der Anforderungsanalyse werden erfahrungsgemäß vermieden, wenn die folgenden Hinweise beachtet werden:

ZIELP - Zielplanung für luK-Projekte

93

• 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. • Die erhobenen Anforderungen sollten in einer verständlichen Form dokumentiert werden. • Die dokumentierten Anforderungen sollten systematisch überprüft werden. M e t h o d e n der Anforderungsanalyse Bei der Auswahl geeigneter Methoden der Anforderungsanalyse ist von folgenden Tatsachen auszugehen: • Es gibt keine Methoden, die speziell für die Anforderungsanalyse geeignet sind. • Soweit allgemeinere Methoden für die Anforderungsanalyse angewendet werden können, eignen sie sich primär für die Sachzielplanung und weniger für die Formalzielplanung. 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); • aufgabenträgerbezogene, subjektive Anforderungen (Aufgabenträgeranforderungen oder Benutzeranforderungen); • Funktionsanforderungen, Leistungsanforderungen und Schnittstellenanforderungen. 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 A u f g a b e n a n f o r d e r u n g e n und 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 ist auch 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 Benutzer mit dem steigenden Niveau der IuK-Systeme gegenüber 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 erfüllen, wenn sie über gute Kenntnisse über die dem IuK-Projekt vorgegebenen betrieblichen Aufgaben verfügen (was erfahrungsgemäß nur selten der Fall ist).

94

Grundlagen

luK-Projekte

Quellen der A n f o r d e r u n g e n 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 B e o b a c h t u n g 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 ZAMIP) nicht vereinbar. Für das Erheben der Aufgabenanforderungen sind Methoden erforderlich, die sich an den Organisationszielen 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. Die A u f t r a g g e b e r haben ihre Anforderungen bereits mit den Planungszielen global definiert. Diese bedürfen der Präzisierung und Abstimmung. Dabei stehen bestimmte Formalziele (z.B. Wirtschaftlichkeit) sowie wichtige Funktionsanforderungen (also das, was das System unbedingt leisten soll) im Vordergrund des Interesses. Die Formalziele und Funktionsanforderungen sind meist die Auslöser für den Bedarf an einem neuen oder einem grundlegend veränderten IuKSystem. 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 Formalziele (z.B. Benutzbarkeit) im Vordergrund des Interesses. Benutzerbeteiligung muß daher bereits in der Vorstudie einsetzen (wegen Einzelheiten vgl. Lerneinheit BEBET). 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. Quellen der Anforderungen bezüglich Qualität (Qualitätsforderungen) sind Auftraggeber, Benutzer und Systemplaner. Anforderungen an die Prozeßqualität und Wartungsanforderungen werden primär von den Systemplanern, Nutzungs-

Z1ELP - Zielplanimg

für luK-Projekte

95

anforderungen 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 ZIELP-7 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

Wartungsanforderungen Rahmenanforderungen

Nutzungsanforderungen

Prozeßqualität

Formalziele

Schnittstellenanforderungen

Leistungsanforderungen

Funktionsanforderungen

Sachziele

X X

X X

X

X X

Abb. ZIELP-7: Quellen der Anforderungen

V o r g e h e n s w e i s e bei der A n f o r d e r u n g s a n a l y s e Eine systematische Vorgehensweise bei der Anforderungsanalyse umfaßt unter formalen Gesichtspunkten die drei in Abbildung ZIELP-8 genannten P h a s e n . 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. Es 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 d e r Anforderungsanalyse. In dieser Phase werden die Anforderungen erhoben und beschrieben (formuliert, klassifiziert, hierarchisiert). Diese Phase ist Gegenstand der Zielplanung und interessiert im vorliegenden Zusammenhang deshalb, weil es auch um den Methodeneinsatz zum Erheben und Dokumentieren der Anforderungen geht.

96

Grundlagen

IuK-Projekte

• 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 Zielplanung. Sie interessiert im vorliegenden Zusammenhang deshalb, weil es hier auch um den Methodeneinsatz zum Prüfen der Anforderungen geht.

Demonstrationsbeispiel Am Beispiel des Formalziels Zuverlässigkeit und einer Reihe weiterer Ziele werden die Z i e l b e z i e h u n g e n gezeigt. In Abbildung ZIELP-9 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 ZIELP-9 enthält auch den Funktionsumfang als Sachziel. Dies weist darauf hin, daß nicht nur zwischen den Formalzielen, sondern auch zwischen diesen und be-

ZIELP

- Zielplanung

für

luK-Projekte

97

stimmten Sachzielen Zielbeziehungen bestehen, die bei der Anforderungsanalyse nicht unberücksichtigt bleiben dürfen. Ersatzkosten

Einsatzdauer

OTT

T W f J

+

Funktionsumfang

Benutzungskomfort

Effizienz

Zuverlässigkeit

neutral

Änderbarkeit

Portabilitiit

==neutral + | bis -

Entwicklungskosten

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

tfttt Wartungskosten

A b b . Z I E L P - 9 : B e z i e h u n g e n z w i s c h e n Z u v e r l ä s s i g k e i t und a n d e r e n Zielen (Quelle: P f a d l e r )

Forschungsbcfunde 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 F o r m a l z i e l e bei IuK-Projekten in der Praxis verfolgt werden, wie ihr Z i e l i n h a l t definiert ist, wie die Z i e l e r r e i c h u n g gemessen wird und welche Zielbeziehungen berücksichtigt werden. Folgende Formalziele wurden 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.

98

Grundlagen

¡uK-Projekte

Kontrollfragen 1. 2. 3. 4. 5.

Welcher Zweck wird mit der Zielplanung verfolgt? W i e können Sachziele und wie können Formalziele in geeigneter Weise gegliedert werden? W e l c h e Arbeitsschritte beschreiben den Arbeitsablauf beim Festlegen der Sachziele? WcIche Arbeitsschritte beschreiben den Arbeitsablauf beim Festlegen der Formalziele? W e l c h e Beziehungen zwischen Zielen können idealtypisch unterschieden werden?

Quellenliteratur H e i n e n , E.: Grundlagen betriebswirtschaftlicher Entscheidungen. Das Zielsystem d e r Unternehm u n g . 3. A., G a b l e r , Wiesbaden 1976 H e i n r i c h , L. J.: I n f o r m a t i o n s m a n a g e m e n t - Planung, Ü b e r w a c h u n g und Steuerung der Informationsinfrastruktur. 5. A., Oldenbourg, München/Wien 1996, insbes. Lerneinheit S Z I E L H e i n r i c h , L. J./Sterrer, G.: Ziele von I n f o r m a t i o n s s y s t e m e n - Ergebnisse einer empirischen Studie. In: Information Management 1/1987, 48 - 53 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, Stuttgart 1980, 2 0 0 -207 Kargl, H.: Fachentwurf für DV-Anwendungssysteme. 2. A., Oldenbourg, München/Wien 1991 Kolb, A.: Ein p r a g m a t i s c h e r Ansatz zum Requirements Engineering. In: Informatik Spektrum 6/1992, 315 - 322 P f a d l e r , W.: M i t s c h r e i t e n d e 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.): S o f t w a r e . Moderne M e t h o d e n zur Planung, Realisierung u n d Kontrolle der Entwicklung. Oldenbourg, München/Wien 1981, 205 - 228

Vertiefungsliteratur M a r t i n , 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 Cliffs NJ 1988 R o i t h m a y r , F.: C o n t r o l l i n g 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 . Oldenbourg, München/Wien 1988 T h a y e r , R. H . / D o r f m a n , M.: System and Software Requirements Engineering, C o m p u t e r Society Press, Los A l a m o s 1990 Selig, J.: E D V - M a n a g e m e n t - Eine empirische Untersuchung der Entwicklung von Anwendungssystemen in deutschen Unternehmen. Springer, Berlin et al. 1986 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.): Handbuch Wirtschaftsinformatik. Poeschel, Stuttgart 1990, 2 3 7 - 256 Partsch, H.: Requirements Engineering. Oldenbourg, München/Wien 1991 T i m m , M . : Ein systematisches Vorgehensmodell zur Spezifizierung der Benutzeranforderungen. In: Angewandte Informatik 4/ 1985, 145 - 151

Mensch und Projektmanagement

zulässige Alternativen

Bewertung und Auswahl

i keine zulässigen Alternativen vorhanden Anwendung einer anderen Kreativitätstechnik

optimale j Alternative i

100

Mensch und

Projektmanagement

Mit dem Kapitel Mensch und Projektmanagement sollen folgende Lernziele erreicht werden: P R O V E - Projektverantwortung Sie kennen die Personen und Gruppen, die an einem Informatik-Projekt mitwirken. Sie können die Aufgaben dieser Personen und Gruppen beschreiben. Sie erkennen die Bedeutung des Zusammenwirkens der Beteiligten in der Projektgruppe. Sie wissen, warum bei der Bildung der Projektgruppe und bei der Zusammenarbeit in der Projektgruppe Probleme entstehen können. B E B E T - Benutzerbeteiligung Sie können Benutzerbeteiligung in den größeren Zusammenhang der Partizipation einordnen. Sie kennen die verschiedenen Ansätze der Benutzerbeteiligung. Sie können die Vorgehensweise bei der Abwicklung eines IuK-Projekts mit Benutzerbeteiligung am Beispiel von ETHICS nachvollziehen. Sie können die praktische Brauchbarkeit von ETHICS beurteilen. K R E A T - Kreativitätstechniken 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. P R O T Y - Prototyping 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 in einem IuK-Projekt Prototyping primär anwendbar ist.

PROVE - Projektverantwortung und Projektgruppe Lernziele Sie kennen die Personen und Gruppen, die an einem Informatik-Projekt mitwirken. Sie können die Aufgaben dieser Personen und Gruppen beschreiben. Sie erkennen die Bedeutung des Zusammenwirkens der Beteiligten in der Projektgruppe. Sie wissen, warum bei der Bildung der Projektgruppe und bei der Zusammenarbeit in der Projektgruppe Probleme entstehen können. Definitionen und Abkürzungen A u f g a b e n t r ä g e r (task bearer) = eine Person oder eine Gruppe, der eine Aufgabe verantwortlich zur Aufgabenerfiillung übertragen wird. A u f t r a g g e b e r (orderer) = die Organisation (bei externer Auftragsvergabe) oder die Struktureinheit einer Organisation (bei interner Auftragsvergabe), die ein Projekt 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 beauftragt ist. Beteiligter (participant) = eine Person oder Gruppe, die nicht professionell an einem IuK-Projekt mitwirkt und nicht deren Auftraggeber repräsentiert. C S C W = Akronym für Computer Supported Cooperative W o r k 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 und mit einer Ablöse endend. Projektgruppe (project team) = die für ein Projekt eingesetzte Anzahl von Personen, die von einer für die Projektdurchführung verantwortlichen Projektleitung geführt wird. Synonyme: Projektteam, Planungsgruppe. P r o j e k t m i t a r b e i t e r (project collaborator) = eine Person, die einer Projektgruppe auf Dauer des Projekts oder bestimmter Projektteile zugeordnet ist. Projektpartner (project partner) = die zusammenfassende Bezeichnung für alle Personen und Gruppen, die an einem Projekt kooperativ mitwirken. 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 eines IuK-Projekts besitzt.

102

Mensch und

Projektmanagement

Ebenen der Projektverantwortung An einem Informatik-Projekt wirken auf politischer, administrativer und operativer Ebene mehrere Aufgabenträger als Personen und als Gruppen mit. Dazu gehören: • • • • • •

Auftraggeber und Auftragnehmer, Projekt-Steuerungsgremium (z.B. Lenkungsausschuß), Projektleitung (Projektleiter oder Projektleitungsteam), Projektgruppe und Projektmitarbeiter, Betroffene (z.B. Benutzer), sonstige Beteiligte (z.B. Koordinator).

Auf der politischen Ebene angesiedelt sind Auftraggeber und Auftragnehmer bzw. Personen, die als Repräsentanten des Auftraggebers und als Repräsentanten des Auftragnehmers agieren (z.B. der Produktmanager als Repräsentant des Auftraggebers). Der Auftraggeber bestimmt die Planungsziele, er ist Kunde; der Auftragnehmer realisiert die Planungsziele, er ist Lieferant. Der Auftraggeber entscheidet über den für die Projektrealisierung geeigneten Partner und vereinbart durch vertragliche Regelungen Leistungen, Kosten und Termine sowie alle notwendigen Rahmenbedingungen (z.B. Dokumentation, Zahlungsbedingungen, Mängelhaftung, Nutzungsrechte). Mit den Rahmenbedingungen wird auch festgelegt, in welcher Art und in welchem Umfang der Auftraggeber in die Projektrealisierung einbezogen ist (z.B. gemeinsame Reviews und Tests). Damit wird der Tatsache Rechnung getragen, daß letzlich der Auftraggeber das wirtschaftliche Projektrisiko trägt, unabhängig davon, durch welche Vereinbarungen mit dem Auftragnehmer er sich davor zu schützen sucht. Auf der administrativen Ebene geht es um die Projektleitung. Der Auftraggeber delegiert Kompetenz und Verantwortung zur Projektrealisierung an die Projektleitung. Die sich daraus ergebenden Aufgaben betreffen vor allem die Planung, Überwachung und Steuerung des Projekts (vgl. Lerneinheit PROPL). Die Projektleitung kann einer Person (Projektleiter) oder mehreren Personen gemeinsam (Projektleitungsteam) übertragen werden. Auf der operativen Ebene geht es um die Verantwortung für die Bearbeitung der Projektaufgaben, wie sie nach Maßgabe der Aufgabenplanung zur Erreichung der Projektziele erforderlich ist. Die Verantwortung für die planmäßige Bearbeitung der Aufgaben liegt - je nach Form der Projektorganisation (vgl. Lerneinheit PRORG) - nicht nur bei der Projektleitung, sondern auch bei den internen und externen Projektpartnern (z.B. Fachabteilungen als interne, Software- oder Systemhäuser als externe Projektpartner) und letzlich bei jedem einzelnen Projektmitarbeiter.

PROVE - Projektverantwortung

und Projektgruppe

103

Projekt-Steuerungsgremium Aufgabe des Projektsteuerungsgremiums ist es, die auf den drei Ebenen der Projektverantwortung agierenden Personen und Institutionen zu koordinieren. Es ist "Ansprechstelle" für alle Projektbeteiligten, insbesondere im Fall von Konflikten, die von den Projektbeteiligten nicht direkt gelöst werden können. Es ist auch Berichtsinstanz zu festgelegten Meilenstein-Terminen, um gegebenenfalls Projektnotstände frühzeitig erkennen und gegensteuern zu können. Im allgemeinen werden einem Projektsteuerungsgremuim mehrere, gegebenenfalls alle fachlich gleichartigen Projekte zur Steuerung zugeordnet (sog. Multi-Projektmanagement), beispielsweise alle Informatik-Projekte dem Lenkungsausschuß. Personell gesehen ist der Lenkungssausschuß ein aus Mitgliedern des Top-Managements, des Managements der Fachabteilungen bzw. Geschäftsprozesse (soweit diese von offenen Projekten betroffen, insbes. ihre Auftraggeber sind) und des Managements der IKS-Abteilung ("EDV/ORG-Abteilung") bestehendes Gremium. Über die Koordinierung offener Projekte hinaus ist er für die strategische Planung der Informationsverarbeitung unternehmensweit zuständig (vgl. Lerneinheit INSIM im Bd. "Informationsmanagement"). Er erstellt das Projektportfolio, gibt die Planungsziele vor und erteilt die Projektfreigabe bzw. den Projektauftrag. Er legt auch die Nebenbedingungen für die Projektabwicklung fest, bestimmt die Projektorganisation und ernennt die Projektleitung (vgl. Lerneinheit PRORG). Die Projektleitung berichtet an den Lenkungsausschuß. Auf Grund seiner Zusammensetzung fördert der Lenkungsausschuß die Zusammenarbeit zwischen der Linienorganisation und der Projektorganisation. Projektleitung Unabhängig davon, welche Projektorganisation (vgl. Lerneinheit P R O R G ) verwendet wird, hat die Projektleitung die Aufgabe, ein Projekt zu planen, die Projektdurchführung zu überwachen und - je nach Projektorganisation in unterschiedlicher Weise - steuernd einzugreifen, wenn der Projektablauf den Projektzielen nicht entspricht. Den vollen Aufgabenumfang der Planung, Überwachung und Steuerung eines Projekts hat die Projektleitung bei der reinen Projektorganisation und bei der Projektorganisation in Verbindung mit Linienfunktionen; davon wird im folgenden ausgegangen. Projektleitung umfaßt dann 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).

104

Mensch und

Projektmanagement

Die Projektleitung besteht entweder aus einer Person (Projektleiter) oder aus mehreren Personen (Projektleitungsteam); auch im Projektleitungsteam muß es jedoch einen Projektleiter geben, zumindest als primus inter pares. Die Anforderungen an die Qualifikation des Projektleiters sind fachlicher und menschlicher Art. Fachliche Qualifikationsanforderungen beziehen sich auf die Projektqualifikation (d.h. Kenntnisse, Fähigkeiten und Fertigkeiten des Projektmanagements) und die Aufgabenqualifikation (d.h. Kenntnisse, Fähigkeiten und Fertigkeiten, die sich auf die Projektaufgabe beziehen). Menschliche Qualifikationsanforderungen betreffen die persönliche Qualifikation (z.B. Kontaktfreudigkeit, Menschenkenntnis, Geduld, Beharrlichkeit, Durchhaltevermögen, Kreativität, Organisationstalent) und die Führungsqualifikation (z.B. Fähigkeit zum Anleiten, Motivieren, Erkennen von Konflikten, Delegieren). Ergänzend zu den Sachkenntnisse sind solche über das Unternehmen des Auftraggebers (z.B. über Produkte, Prozesse, Mitarbeiter, Kunden, Lieferanten) bei Informatik-Projekten von erheblicher Bedeutung. Bei einem Projekt mit zahlreichen Beteiligten und mit Durchsetzungsproblemen in der Linienorganisation ist die Erfüllung der menschlichen Qualifikationsanforderungen wichtiger als die der fachlichen; umgekehrt wird für ein Projekt mit einer kleinen Projektgruppe eher ein Projektleiter mit einer guten fachlichen Qualifikation gebraucht. Bezüglich der organisatorischen Herkunft des Projektleiters (Fachbereich oder IV-Bereich) wird in der Fachliteratur überwiegend dem Fachbereich der Vorzug gegeben.

Abb. PROVE-1: Qualifikationsanforderungen Projektleiter (Quelle: nach Zielasek)

Bei gemischten Projektgruppen mit Projektmitarbeitern von Auftraggeberitnd Auftragnehmerseite stellt sich die Frage, ob die Projektleitung von Auftraggeberseite oder Auftragnehmerseite wahrgenommen werden soll oder ob eine geteilte Projektleitung zweckmäßig ist. Geteilte Projektleitung heißt nicht gemeinsame Projektleitung, sondern Zuordnung der Projektleitung auf Auftrag-

PROVE - Projektverantwortung lind Projektgruppe

105

geber- bzw. Auftragnehmerseite je nach Projektphase oder Projektabschnitt. Dies erfordert eine klare Schnittstellendefinition für jeden Übergang der Projektverantwortung. Schließlich kann die Projektleitung einem Externen übertragen werden, was jedoch im allgemeinen nur für den Fall von Konfliktsituationen zweckmäßig ist. Projektmitarbeiter Kernaufgabe der Projektmitarbeiter ist die Durchführung der Tätigkeiten, die ihnen auf Grund der Projektplanung (insbes. der Personaleinsatzplanung) zugeordnet wurden. Darüber hinaus können folgende Aufgaben der Projektmitarbeiter genannt werden: • Mitwirkung bei der Projektplanung (vgl. Lerneinheit PROPL); • Erfassung der Istwerte der Projektziele; • Koordinierung ihrer Tätigkeit innerhalb der Projektgruppe und mit der anderer Projektpartner (z.B. in den Abteilungen bzw. Geschäftsprozessen mit Kunden und Lieferanten); • Information der Projektpartner, soweit vom formalen Berichtswesen vorgesehen bzw. für die Erreichung der Projektziele erforderlich; • Dokumentation der Arbeitsergebnisse; • Beratung und Hilfe für andere Projektmitarbeiter. Dem empfohlenen Führungskonzept entsprechend (vgl. Lerneinheit PROMA), sollte bei der Bewältigung dieser Aufgaben Selbststeuerung vor Fremdsteuerung stehen. Zweck der Projektgruppe Informatik-Projekte scheitern erfahrungsgemäß seltener an der Schwierigkeit der Projektaufgabe 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 qualitativer Hinsicht den Planungszielen angemessen ist. Wichtige Eigenschaften einer erfolgreichen Projektgruppe sind: • • • • •

die die das die die

Identifikation der Mitglieder der Gruppe mit den Planungszielen; Fähigkeit zur Zusammenarbeit in der Gruppe; Fachwissen der Mitglieder der Gruppe; Führungsqualifikation der Projektleitung; 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 B r o o k ' s c h e n Gesetz steigt der Kommunikationsaufwand mit zunehmender Gruppengröße überproportional, sodaß jedes weitere Gruppenmitglied oberhalb

106

Mensch und

Projektmanagement

der optimalen Gruppengröße abnehmende Beiträge zum Projektfortschritt liefert. Die Produktivität des einzelnen Gruppenmitglieds in einer Gruppe von 6 Personen ist beispielsweise viermal größer als in einer Gruppe von 33 Personen; der Zeitgewinn zur Verkürzung der Projektlaufzeit beträgt bei der größeren Gruppe aber nur etwa 30%. Die Erklärung dafür liegt im Umfang der Kommunikationsvorgänge, der mit der Gruppengröße überproportional steigt. Brooks hat diesen Zusammenhang mit der Formel N = n (n - l)/2 zum Ausdruck gebracht, mit N = Anzahl der Kommunikationsvorgänge und n = Anzahl der Gruppenmitglieder. Daraus folgt auch, daß ein in Terminnot geratenes Projekt nicht durch zusätzliche Gruppenmitglieder gerettet werden kann; 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. Eine Projektgruppe ist offene Projektgruppe, wenn im Projektablauf planmäßig weitere Mitglieder eintreten und bisherige Mitglieder gegebenenfalls ausscheiden; sonst ist sie geschlossene Projektgruppe. Eine offene Projektgruppe ist beispielsweise dann zweckmäßig, wenn für verschiedene Projektabschnitte unterschiedliche Qualifikationen erforderlich sind (z.B. bei einem IuK-Projekt in der Analysephase andere als in der Implementierungsphase). Eine Projektgruppe ist interne Projektgruppe, wenn ihr nur Mitarbeiter des Auftraggebers angehören; gehören ihr auch Externe an, ist sie gemischte Projektgruppe. Wird das Projekt fremd vergeben (z.B. an ein Software- oder Systemhaus), dann handelt es sich - aus der Sicht des Auftraggebers - um eine externe Projektgruppe. Je mehr ein Unternehmen Aufgaben der Informationsverarbeitung auslagert (Outsourcing, vgl. Lerneinheit STRAT im Bd. "Informationsmanagement"), desto weniger bedeutsam werden interne Projektgruppen und desto bedeutsamer die Frage, ob und in welcher Art und Weise durch gemischte Projektgruppen ein Einfluß auf die Projektrealisierung gewahrt werden soll und kann. Merkmale der Projektgruppe "Gruppe" bezeichnet jedes kontinuierliche Zusammenwirken mehrerer Personen zur Erreichung bestimmter Ziele, hier also das Zusammenwirken der Mitglieder der Projektgruppe zur Erreichung der Projektziele. Dieses Zusammenwirken wird als Kooperation bezeichnet. Kooperation erfordert Koordination, und zum Koordinieren ist Kommunikation zwischen den Gruppenmitgliedern erforderlich. Gruppenarbeit ist also Kooperation, die Koordination erfordert und Kommunikation voraussetzt. 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;

PROVE - Projektverantwortung

und Projektgruppe

107

• ein mehr oder weniger komplexes Geflecht gefühlsmäßiger Wechselbeziehungen zwischen den Mitgliedern der Gruppe (sog. Wir-Gefühl). 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 G l i e d e r u n g s prinzipien, insbesondere: • • • • •

nach nach nach nach nach o o o o o o o o o o o o

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

K a n n L e i s t u n g e n vollbringen, d i e e i n e m Einzelnen überhaupt nicht m ö g l i c h sind Besseres Urteilsvermögen B e s s e r e M ö g l i c h k e i t der Informationsübermittlung Größere Kontaktintensität V e r f ü g t über v e r s c h i e d e n e Fähigkeiten und Kenntnisse, die sich ergänzen k ö n n e n G r ö ß e r e Kapazität für die S p e i c h e r u n g v o n Informationen D e r E r h e b u n g s a u f w a n d für Informationen und ihre Abrufzeit sind geringer M e h r Kontrolle über die Zieleinhaltung B e s s e r e Lernfähigkeit B e s s e r e M ö g l i c h k e i t e n für den Einsatz v o n Hilfsmitteln Vorteil der kollektiven Kontrolle A n r e i c h e r u n g d e s kreativen Potentials, w e i l sich die Assoziationsfelder der Gruppenmitglieder ergänzen Abb. PROVE-2: Katalog möglicher Gruppenvorteile (Quelle: Schanz)

Die Gliederungsprinzipien überschneiden sich in der Organisationspraxis. Bei der Bildung der Projektgruppe für IuK-Projekte steht das Gliederungsprinzip nach den Arbeitsergebnissen im Vordergrund. Für IuK-Projekte ist Gruppenbildung erforderlich, da nur die Gruppe die Projektziele erreichen kann. Die Projektgruppe hat also eine instrumenteile Bedeutung. Abbildung PROVE-2 zeigt verschiedene Tatbestände, welche die über eine Menge von Individualleistungen hinausgehende Gruppenleistung begründen (Gruppenvorteile, vereinfachend ausgedrückt als 1 + 1=3). Darüber hinaus gilt, daß Gruppen dem Individuum häufig

108

Mensch und

Projektmanagement

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 (vgl. Lerneinheit BEBET). 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 Beteiligten. Personelle Engpässe treten auf Seite der Systemplaner häufig auf, weil ein hoher Anteil ihrer Kapazität auf die Wartung installierter IuK-Systeme entfällt (in Einzelfällen wird von bis zu 80% berichtet). Sie versuchen daher, durch intensivere Benutzerbeteiligung Aufgaben zu den Benutzern hin zu verlagern. Die 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 Projektarbeit ausreichende Qualifikation haben. Häufig fehlt es an einer dieser Voraussetzungen oder an beiden. Eine erfolgreiche Zusammenarbeit zwischen Systemplanern und Benutzern in der Projektgruppe setzt voraus, daß die Kompetenzen der Beteiligten und damit die Abgrenzung der Aufgaben im Projekt klar geregelt sind. Dies wird durch die Tatsache erschwert, daß - je nach Projekt und somit je nach Beteiligten - unterschiedliche Kompetenzregelungen und Aufgabenabgrenzungen erforderlich sind. In einem IuK-Projekt sind diese von folgendem abhängig: • • • • •

von von von von von

der Komplexität des zu schaffenden IuK-Systems; den Kenntnissen der Systemplaner Uber die Projektaufgabe; den Kenntnissen der Benutzer über die Projektarbeit; der bei den Benutzern verfügbaren Zeit; den zur Verfügung stehenden Methoden und Werkzeugen.

Erschwerend auf die Zusammenarbeit in der Projektgruppe wirkt sich die häufig mangelnde Kommunikationsbereitschaft der Systemplaner aus, die verschiedene Erscheinungsformen hat, wie: • Die Tendenz, aus der Bearbeitung eines IuK-Projekts 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 den Benutzern zu suchen: "Das bringt nichts! Ich bekomme doch nur unsinnige Wünsche zu hören."

PROVE - Projektverantwortung

und Projektgruppe

109

• 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, vorhanden sind. Darüber hinaus sind die Kompetenzen 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 Projektarbeit beteiligt werden, ist heute unbestritten. Informatik-Strategien (vgl. Lerneinheit STRAT im Bd. "Informationsmanagement") machen auch Aussagen darüber, welche Rolle der Mensch in der Informationsverarbeitung spielen soll. Die organisatorische Umsetzung der definierten Rolle erfolgt durch Methoden der Benutzerbeteiligung (vgl. Lerneinheit BEBET). Diese Methoden zielen darauf ab, die (zukünftigen) Benutzer eines IuK-Systems in die Projektarbeit 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. 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 Projektaufgaben als auch der Aufgaben der späteren Systemnutzung sicherzustellen. Verglichen mit den Benutzern ist er der Experte der Fachabteilung. Er ist fachlich und disziplinarisch entweder 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.

110

Mensch und

Projektmanagement

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 spezifische Groupware-Produkte (wie z.B. MeetingWare und GroupSystems) von geringerer Bedeutung als CASE-Werkzeuge (vgl. Lerneinheit WERIP), die neben den Sachaufgaben des Projekts die Koordination der Projektmitarbeiter unterstützen und Kommunikationsmittel zur Verfügung stellen. Dies ist bei den heute verfügbaren Produkten im wesentlichen nicht der Fall. Demonstrationsbeispiel Es werden die Struktur und inhaltliche Beispiele der Stellenbeschreibung für einen Projektleiter gezeigt. Projektbezeichnung: Entwicklung eines Vertriebsinformationssystems 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 der Leiter der IKS-Abteilung die Projektleitung. Kompetenzen und Verantwortung: • Der Projektleiter ist für die Projektdurchführung entsprechend den Planungszielen bezüglich Leistungen, Termine und Kosten 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 gemeinsam mit den Projektmitarbeitern 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 plant, überwacht und steuert die Leistungen, Termine und Kosten.

PROVE - Projektverantwortung

und

Projektgruppe

111

• Er schafft die Rahmenbedingungen dafür, daß die Fachleute in den Fachbereichen in die Projektarbeit eingebunden werden. • Er hält die notwendigen Kontakte mit den Auftraggebern (Abteilungen Vertrieb und Marketing). • Er entscheidet in allen Projektbelangen über die Leistungen, Termine und Kosten, solange er sich im Rahmen der Planungsziele bewegt. • 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 zeigt Konflikte auf und sorgt für deren Beseitigung. • Er beruft bei Bedarf Besprechungen zwischen den am Projekt Beteiligten ein. • Er ist Treiber und Katalysator. Forschungsbefunde L. J. Heinrich berichtet über empirische Befunde zur Frage, warum IuK-Projekte 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 eine mit Moderationstechnik unterstützte Befragung von Seminarteilnehmern sowie durch 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 Vorgehensweise; • 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 Aufgabenabgrenzung 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 Projektrisikos ist folglich eine bessere Ausbildung aller Beteiligten, die sowohl eine Verbesserung der fachlichen Qualifikation als auch der Führungsqualifikation zum Ziel haben muß.

112

Mensch und

Projektmanagement

Vessey/Sravanapudi kommen auf Grund einer Untersuchung von vier C A S E Werkzeugen (Untersuchungszeitraum 1992) zu folgenden Ergebnissen bezüglich deren Eigenschaft, Gruppenarbeit zu unterstützen: CASE-Werkzeuge unterstützen nur wenige Funktionen, die typisch für Gruppenarbeit sind. Beispiele für Befunde sind: A m 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 CASE-Werkzeuge auf den einzelnen Werkzeugbenutzer zugeschnitten sind; sie sind keine Mehrbenutzer-Werkzeuge. M. Wollnik hat mit einer Erhebung von 29 IuK-Prozessen (Erhebungszeitraum nicht angegeben, vermutlich Ende der 80-er Jahre) gefunden, daß nach weitgehend übereinstimmender Auffassung von Systemplanern und Leitern von Fachabteilungen die Rollenverteilung weder projektspezifisch noch projektübergreifend formal 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 Handlungsspielraum bei der Projektabwicklung einschränkt und formale 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ührungskräften in zehn Unternehmen; Untersuchungszeitraum nicht angegeben, vermutlich 1989) den Projekterfolg hemmende und fördernde Faktoren der Zusammenarbeit zwischen Entwicklern und Benutzern erhoben. Hemmende Faktoren der Zusammenarbeit sind: Kommunikationsprobleme, Zeitdruck, zu große Projektgruppen, Konzeptlosigkeit, Sturheit und Arroganz der Entwickler, Nichtbeachtung von Benutzerwünschen. Fördernde Faktoren der Zusammenarbeit 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

Personen und Gruppen 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 Elzer, P. F.: Management von Software-Projekten. In: Informatik Spektrum 1989, 181 - 197 Hansel, J./Lomnitz, G.: Projektleiter-Praxis - Erfolgreiche Projektabwicklung durch verbesserte Kommunikation und Kooperation. Springer, Berlin et al. 1987 Heinrich, L. J.: Schwachstellen und Risiken bei Softwareprojekten. In: Computer und Recht 7 / 1 9 8 8 , 5 8 4 - 587

PROVE - Projektverantwortung

und Projektgruppe

113

Klein, H.: Partnerschaft zwischen Fachabteilung und EDV. In: Heilmann, H. (Hrsg.): Zusammenarbeit zwischen Fachabteilung und EDV. 9. Jahrbuch der EDV. Forkel, Stuttgart/Wiesbaden 1980, 15 - 63 Reisin, F.-M.: Kooperative Gestaltung in partizipativen Softwareprojekten. P. Lang, Frankfurt/M. et al. 1992 Schanz, G.: Organisationsgestaltung - Struktur und Verhalten. Vahlen, München 1982, 211 - 232 Wood, J./Silver, D.: Joint Application Development. 2. Ed., John Wiley & Sons, New York et al. 1995 Zielasek, G.: Projektmanagement. Erfolgreich durch Aktivierung aller Unternehmensebenen. Springer, Berlin et al. 1995 Vertiefungsliteratur Berchtold, W.: Neue Anforderungen an das Projektmanagement im Bereich der Systemintegration. In: HMD - Theorie und Praxis der Wirtschaftsinformatik 187/1996, 69 - 77 Genuchten, M. van: Why is Software late? An Empirical Study of Reasons for Delay in Software Development. In: IEEE Transactions on Software Engineering 6/1991, 582 - 590 Mambrey, P./Oppermann, R.: Benutzerbeteiligung bei der Systementwicklung - Einschätzung der Möglichkeiten durch Experten. In: Angewandte Informatik 3/1985, 111 - 119 Spinas, O./Weber, 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. Teubner, Stuttgart 1991, 36-45 Vessey, I./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, de Gruyter, Berlin et al. 1986

BEBET - Methoden der Benutzerbeteiligung Lernziele Sie können Benutzerbeteiligung in den größeren Zusammenhang der Partizipation einordnen. Sie kennen die verschiedenen Ansätze der Benutzerbeteiligung. Sie können die Vorgehensweise bei der Abwicklung eines IuK-Projekts mit Benutzerbeteiligung am Beispiel von ETHICS nachvollziehen. Sie können die praktische Brauchbarkeit von ETHICS beurteilen. Definitionen und Abkürzungen Arbeitsorganisation (work organization) = das Ergebnis der Kombination von Produktionsfaktoren unter betriebswirtschaftlichen, technischen und sozialen Zielen. Arbeitszufriedenheit (job satisfaction) = ein emotional erlebter Zustand des Bewußtseins, der mit der Erfüllung von Erwartungen bzw. mit der Hoffnung auf deren Erfüllung zusammenhängt. Benutzerakzeptanz (user acceptance) = die Bereitschaft des Benutzers, das von einem Informationssystem angebotene Nutzungspotential in Anspruch zu nehmen. Betroffener (affected individual) = ein Individuum, dessen Interessen durch die Ergebnisse eines IuK-Projekts berührt werden. E T H I C S = Akronym für Effective Technical and Human Implementation of Computer-based Information Systems. Informatik-Strategie (I/S strategy) = eine Strategie, mit der Art und Richtung der Gestaltung der Informationsinfrastruktur durch das oberste Leitungsorgan des Unternehmens festgelegt wird. Input-Output-Analyse (input output analysis) = die Betrachtung von Informationsflüssen, die in ein System einfließen (Input), dort eine Umwandlung (z.B. durch Bearbeitung) erfahren und das System verändert verlassen (Output), konsensorientiert (consens-oriented) = die Art des Handelns, die auf den Ausgleich unterschiedlicher Interessen ausgerichtet ist. Partizipation (participation) = ein umfassender Begriff zur Bezeichnung der verschiedenen Ansätze der Teilnahme von Betroffenen an gesamt- und einzelwirtschaftlichen Entscheidungen. Schlüsselziel (key objective) = ein Ziel, welches das betrachtete System nach den gegenwärtig geltenden Vorstellungen unbedingt erfüllen soll. Schwachstelle (weakness) = die Tendenz eines Systems oder eines Systemteils, von einem definierten Standard im negativen Sinn abzuweichen. Schwachstellenanalyse (weakness analysis) = ein methodisch-formales Konzept zur systematischen Untersuchung von Schwachstellen. Schwachstellenmatrix (weakness grid) = eine Matrix mit den Bearbeitungsvorgängen in den Zeilen und in den Spalten und den Schwachstellen als Elemente; dient zur Feststellung sich gegenseitig beeinflussender Schwachstellen, soziotechnisch (socio-technical) = die Eigenschaft eines Systems, neben technischen und betriebswirtschaftlichen Zielen soziale Ziele zu berücksichtigen.

BEBET - Methoden

der

Benutzerbeteiligung

115

Informatik-Strategie und Benutzerbeteiligung Informatik-Strategien machen auch Aussagen darüber, welche Rolle der Mensch als Komponente der Informationsinfrastruktur einnehmen soll (vgl. Lerneinheit STRAT im Bd. "Informationsmanagement"). Die organisatorische Umsetzung der definierten Rolle des Menschen erfolgt durch Methoden der Benutzerbeteiligung. Diese haben insbesondere das Ziel, die (zukünftigen) Benutzer eines Informationssystems in die Projektarbeit so einzubeziehen, daß sie, bei ausreichender Berücksichtigung der von ihnen eingebrachten sozialen Ziele, die Erreichung der technischen und der betriebswirtschaftlichen Ziele unterstützen. Mit Partizipation werden die verschiedenen Ansätze der Teilnahme von Betroffenen an gesamt- und einzelwirtschaftlichen Entscheidungen bezeichnet. Dabei sind zwei Sichtweisen, welche die Art der Partizipationsgrundlage kennzeichnen, zu unterscheiden: informale und formale Partizipation. • Informale Partizipation (Benutzerbeteiligung) beruht auf dem Konsens der Betroffenen und ist in Strategien, Leitbildern, Unternehmensverfassungen oder Führungsrichtlinien festgeschrieben. • Formale Partizipation (Mitbestimmung) beruht auf kodifizierten, insbesondere gesetzlichen Regeln (z.B. Arbeitsverfassungsgesetz in Österreich, Betriebsverfassungsgesetz in Deutschland), auf Betriebsvereinbarungen oder kollektiv vertraglichen Vereinbarungen. Die allgemeine Begründung für Partizipation lautet: Da der Mensch einerseits gesellschaftlich bestimmt ist und andererseits die Gesellschaft mitbestimmt, er sich also dem sozialen Kontext nicht entziehen kann, ist Partizipation die notwendige Bedingung menschlicher Existenz. Der Einsatz von Informations- und Kommunikationstechnologien im Unternehmen führt zwangsläufig zu Veränderungen der Arbeitsorganisation. Daraus folgt für Arbeitnehmer als Benutzer und für den Betriebsrat als Interessensvertretung der Arbeitnehmer, zu versuchen, auf die Planung, Einführung und Nutzung von Informationssystemen Einfluß zu nehmen. Die nachfolgenden Erläuterungen beschränken sich auf die Benutzerbeteiligung (zur Mitbestimmung vgl. Lerneinheit RECHT im Bd. "Informationsmanagement"). Ansätze der Benutzerbeteiligung Die verschiedenen Modelle der Benutzerbeteiligung lassen sich in die Gruppen konsensorientierter Ansatz und gewerkschaftlicher Gegenmachtansatz gliedern. Der konsensorientierte Ansatz geht davon aus, daß die Bewertung eines Informationssystems nicht nur nach technischen Zielen erfolgen kann, sondern auch nach dessen Funktionsweise im Anwendungskontext erfolgen muß, also beispielsweise auch nach seiner Akzeptanz durch die Benutzer und nach seiner Wirtschaftlichkeit. Entsprechend wird versucht, durch Benutzerbeteiligung, Motivationsstrategien und akzeptanzfördernde Maßnahmen bessere Bedingungen für die Planung und Nutzung von Informationssystemen zu schaffen ("besser" im Sinn von z.B. rationeller). Diese betriebswirtschaftliche Perspektivenerweiterung über den technischen Kern hinaus wird durch die Anerkennung sozialer Ziele, die gleichberechtigt neben betriebswirtschaftlichen und technischen Zielen existieren,

116

Mensch und

Projektmanagement

fortgesetzt. Eine der prominentesten Vertreterinnen des konsensorientierten Ansatzes, der von ihr als soziotechnischer Ansatz bezeichnet wird, ist E. Mumford (vgl. dazu das Demonstrationsbeispiel). Der soziotechnische Ansatz ist konsensorientiert, weil er davon ausgeht, daß ein Interessensausgleich zwischen allen Beteiligten möglich ist und daß dies zu einer Systemalternative führt, die für alle Beteiligten von Vorteil ist. Der Systemplaner versteht sich dabei primär als Berater und Vermittler, weniger als Vertreter der Interessen des Auftraggebers, der entweder die Benutzer bei der Erarbeitung von Systemalternativen unterstützt oder der diese selbst erarbeitet und zur Diskussion und Auswahl stellt. Der konsensorientierte Ansatz führt also zu einer Perspektivenerweiterung, akzeptiert jedoch die herrschenden Machtverhältnisse im Betrieb. Diese werden vom gewerkschaftlichen Gegenmachtansatz nicht akzeptiert. Er konstatiert einen Interessensgegensatz zwischen technischen und betriebswirtschaftlichen Zielen einerseits und sozialen Zielen andererseits. Er strebt nicht nur eine Verbesserung der Arbeitsorganisation an, sondern auch die Verwirklichung "wirtschaftlicher Demokratie". Am konsensorientierten Ansatz wird kritisiert, daß er nur eine Befriedigungsfunktion habe. Der gewerkschaftliche Gegenmachtansatz verlangt vom Systemplaner das Aufgeben einer primär an technischen und betriebswirtschaftlichen Zielen orientierten Position; er soll sein Wissen so einbringen, daß die Planung "arbeitnehmerbezogener Informationssysteme" ermöglicht wird. Damit soll erreicht werden, daß nicht die Arbeitgeber, sondern die Arbeitnehmer die Planungsziele definieren und die IuK-Projekte betreiben; der Systemplaner soll sich unterstützend im Hintergrund halten. Konsensorientierter Ansatz und gewerkschaftlicher Gegenmachtansatz sollten nicht alternativ, sondern als sinnvolle Ergänzung gesehen werden. Dimensionen der Benutzerbeteiligung Benutzerbeteiligung kann unter verschiedenen Dimensionen betrachtet werden, deren unterschiedliche Merkmale die Formulierung von Methoden der Benutzerbeteiligung erlauben. Die Dimensionen sind Partizipationsausprägung, Partizipationsebene, Partizipationsform und Partizipationsphase. • Die Partizipationsausprägung reicht von der Information der Benutzer bis zur selbständigen Projektarbeit durch die Benutzer. • Die Partizipationsebene reicht vom einzelnen Arbeitsplatz über die Arbeitsgruppe und die Abteilung bis zum Unternehmen als Ganzes. • Die Partizipationsform kann direkt oder indirekt sein. Direkte Partizipation bedeutet persönliche Beteiligung der betroffenen Benutzer, indirekte Partizipation (repräsentative Partizipation) ersetzt diese durch Partizipation von gewählten Vertretern der Benutzer. • Die Partizipationsphase legt fest, in welcher Phase der einem Phasenschema folgenden Projektplanung und -abwicklung Partizipation stattfindet; dies kann in einer, in allen oder in einigen Phasen der Fall sein.

BEBET - Methoden

der Benutzerbeteiligung

117

Demonstrationsbeispiel Es wird das von E. Mumford entwickelte ETHICS gezeigt. Es beschreibt ein Modell zur Abwicklung von IuK-Projekten mit expliziter Beteiligung der Benutzer, stellt die erwähnte Perspektivenerweiterung um die sozialen Ziele durch die Benutzer in den Vordergrund und kann ablauforientiert durch 15 Arbeitsschritte beschrieben werden; sie werden nachfolgend erläutert. Arbeitsschritt 1: Bestimmen der Anlässe und der Ausgangssituation der organisatorischen Veränderung. Dient zur Klarstellung des "Warum?" der Planung eines neuen soziotechnischen Systems. Arbeitsschritt 2: Festlegen der Grenzen des soziotechnischen Systems. Klären, welche Teile des Unternehmens und seiner Umwelt betroffen sind. Wenn innerhalb der festgelegten Gestaltungsgrenzen mehrere Struktureinheiten des Unternehmens liegen, muß sich die weitere Vorgehensweise zunächst auf ein Gesamtkonzept konzentrieren. In einer zweiten Phase sind dann die verschiedenen Subsysteme im Detail zu gestalten. Arbeitsschritt 3: Durchführen einer Input-Output-Analyse des Istzustands. Grundlegendes Überdenken der Arbeitsorganisation und Gewinnen eines Verständnisses für die Funktionsweise des Istzustands durch eine Input-OutputAnalyse der Subsysteme anhand identifizierbarer Tätigkeiten. Arbeitsschritt 4: Klären der Basisfunktionen. Ordnen der identifizierten Tätigkeiten sowie Herausarbeiten erkennbarer Probleme bei der Funktionserfüllung der Tätigkeiten. Die Ordnung der Tätigkeiten erfolgt nach: • Ausführungsaktivitäten; • Aktivitäten zur Vermeidung oder Behebung von Problemen oder Schwachstellen; • Koordinationsaktivitäten; • Entwicklungsaktivitäten zur Verbesserung der Wirtschaftlichkeit und zur Anpassung an Veränderungen; • Steuerungs- und Kontrollaktivitäten. Arbeitsschritt 5: Festlegen der Schlüsselziele und Schlüsselaufgaben. Welche Schlüsselziele haben die Gruppen oder Struktureinheiten, die umgestaltet werden sollen, warum existieren sie, was sollten sie tun und warum weicht das, was sie tatsächlich tun, davon ab? Welche Schlüsselaufgaben muß die Gruppe oder Struktureinheit bearbeiten, um die Schlüsselziele zu erreichen? Dazu reicht zunächst eine grobe Beschreibung der Aufgaben aus. Arbeitsschritt 6: Bestimmen der Schlüsselinformationen. Mit Hilfe einer Input-Output-Analyse werden die Informationen bestimmt, die zur Ausführung der Schlüsselaufgaben erforderlich sind. Dabei sollte die in Arbeitsschritt 4 verwendete Gliederung der Arbeitsschritte benutzt werden. Arbeitsschritt 7: Durchführen der Schwachstellenanalyse. Notwendige Verbesserungen der Wirtschaftlichkeit lassen sich durch die Analyse von Schwachstellen bestimmen. Besondere Beachtung verdienen dabei die Schwach-

118

Mensch und Projektmanagement

stellen, die Probleme bei der Zusammenarbeit der Gruppen oder Struktureinheiten aufzeigen. Schwachstellen beeinflussen sich oft gegenseitig und ziehen sich so durch das gesamte soziotechnische System hindurch. Zur Aufdeckung solcher Zusammenhänge eignen sich Schwachstellenmatrizen. Arbeitsschritt 8: Diagnostizieren der A n f o r d e r u n g e n an die Arbeitssituation. Dazu gehört zunächst, daß jede Person, die von dem neuen soziotechnischen System betroffen ist, Art und Ausmaß der Zufriedenheit beschreibt, die ihre Arbeit idealerweise bieten sollte (Arbeitszufriedenheit). Es werden folgende Gruppen von Anforderungen unterschieden: • • • • •

Bedürfnisse bezüglich der Nutzung und Weiterentwicklung von Fähigkeiten; psychische Bedürfnisse; Bedürfnisse nach Unterstützung und Kontrolle; Bedürfnisse bezüglich der Aufgabenstruktur; ethische Bedürfnisse.

Informationen über die Arbeitszufriedenheit werden mit einem Fragebogen erhoben, den die Betroffenen selbst ausfüllen. Die Erhebungsergebnisse werden einer "möglichst demokratischen" Überprüfung unterzogen, d.h. mit den Betroffenen in kleinen Gruppen diskutiert. Ziel ist es, die Gründe für Unzufriedenheit mit der Arbeitssituation herauszufinden und Verbesserungsvorschläge zu entwickeln, deren Realisierung möglich erscheint. Während Bereiche mit schlechter Übereinstimmung (Schwachstellen) zwischen Arbeitsbedingungen, die Arbeitszufriedenheit gewährleisten können, und organisatorischen Erfordernissen bei der Reorganisation verbessert werden müssen, sind Bereiche mit guter Übereinstimmung (Stärke) bei der Reorganisation zu erhalten. Arbeitsschritt 9: Durchführen der Zukunftsanalyse. Umweltveränderungen begrenzen die Lebensdauer eines Systems; es muß daher möglichst flexibel sein, um sich ihnen anpassen zu können. Dazu ist es notwendig, Veränderungen zu prognostizieren. Arbeitsschritt 10: Festlegen der technischen, b e t r i e b s w i r t s c h a f t l i c h e n und sozialen Ziele. Diese werden in erster Linie aus der Schwachstellenanalyse, aus der Analyse der Arbeitszufriedenheit sowie aus der Zukunftsanalyse abgeleitet. Die Ziele werden von den Beteiligten aus allen Gruppen - Betroffene, Systemplaner, Management - gewichtet. In einem Verhandlungsprozeß werden die Ziele herausgearbeitet, welche der Systemgestaltung zugrundegelegt werden sollen. Arbeitsschritt 11: Entwickeln alternativer Lösungen. Ziel ist es, eine gute technisch-betriebswirtschaftliche Lösung mit einer Lösung zu kombinieren, die auch in organisatorisch-personeller Beziehung (Arbeitsorganisation und personelle Regelungen, welche die menschlichen Bedürfnisse erfüllen) befriedigt. Beide Lösungen sollten sich gegenseitig verstärken: Die zur Erfüllung der technischen Notwendigkeiten eingesetzten Verfahren sollten gute Möglichkeiten für Arbeitszufriedenheit bieten, während die Arbeitsorganisation zu hoher Wirtschaftlichkeit beitragen sollte. Dazu werden zunächst technisch-betriebswirtschaftliche Lösungen und organisatorisch-personelle Lösungen entwickelt, die

BEBET - Methoden der Benutzerbeteiligung

119

dann bewertet und selektiert werden. Die Bewertung orientiert sich an den in Arbeitsschritt 10 festgelegten Zielen. Arbeitsschritt 12: Entwickeln soziotechnischer Lösungen. Miteinander vereinbare technisch-betriebswirtschaftliche und organisatorisch-personelle Lösungen werden kombiniert. Danach verbleibende Alternativen werden nach folgenden Kriterien beurteilt: • In welchem Umfang erfüllen sie die vorrangigen betriebswirtschaftlichen und auf die Zukunft bezogenen Ziele? • In welchem Umfang erfüllen sie die vorrangigen sozialen Ziele? • In welchem Umfang erfüllen sie technische sowie andere betriebswirtschaftliche und soziale Ziele, die zwar nicht vorrangig sind, aber von mindestens einer Interessensgruppe als "sehr wichtig" eingestuft wurden? Bei der Beurteilung sind vorhandene Restriktionen (z.B. bezüglich der notwendigen finanziellen Mittel zur Realisierung) zu beachten. Die optimale Alternative wird ausgewählt. Arbeitsschritt 13: Ausgestalten der ausgewählten Alternative. Das Gestaltungsprinzip des soziotechnischen Ansatzes besteht darin, Personen oder Gruppen möglichst vollständige Aufgabeneinheiten zu übertragen und die Arbeit zusätzlich mit Problemlösungs-, Koordinations- sowie Kontroll- und Steuerungsaufgaben anzureichern (teilautonome Gruppen). Dementsprechend wird untersucht, welche abgrenzbaren und zusammenhängenden Tätigkeiten es gibt und zu welchen Aufgabeneinheiten sie zusammengefaßt werden können. Parallel mit der Ausgestaltung des organisatorisch-personellen Teils ist das technische Teilsystem zu entwickeln. Dabei handelt es sich um die Aktivitäten, die bei "herkömmlicher" Projektabwicklung im Vordergrund stehen. Arbeitsschritt 14: Implementieren des neuen Systems. Die Art der Veränderungen sowie die Funktionsweise des neuen Systems werden den betroffenen, aber nicht aktiv an der Informationssystem-Planung beteiligten Gruppenmitgliedern im Rahmen von Schulungsmaßnahmen verständlich gemacht. Diese müssen die eingeschlagene Veränderungsstrategie "gutheißen". Eine Veränderungsstrategie kann z.B. in einem stufenweisen Übergang bestehen, bei dem zunächst nur ein Teil der Betroffenen mit dem neuen System arbeitet. Dadurch können bei der nachfolgenden Umstellung des gesamten Bereichs bereits erfahrene Mitarbeiter die anderen Mitarbeiter anlernen. Arbeitsschritt 15: Bewerten des neuen Systems. Maßstab für die Beurteilung der Erreichung der technischen und der betriebswirtschaftlichen Ziele durch das neue System ist das Ausmaß, in dem die in der Diagnose (Arbeitsschritt 7) festgestellten Schwachstellen behoben oder verringert werden konnten, ohne daß neue Schwachstellen aufgetreten und ohne daß Stärken abgebaut worden sind. Bezüglich der sozialen Ziele ist zu überprüfen, wie sich die Arbeitszufriedenheit verändert hat. Dies erfolgt methodisch mit dem in Arbeitsschritt 8 entwickelten Fragebogen.

120

Mensch und

Projektmanagement

Forschungsbefunde Mambrey/Oppermann haben mit einem Explorationsleitfaden Systemplaner, Leiter von Fachabteilungen und Betriebs-/Personalräte mit dem Ziel befragt, Daten über das Ausmaß der Benutzerbeteiligung sowie darüber zu erheben, welche Gestaltungsspielräume bestehen, welche Qualifikationen für die Beteiligung für erforderlich gehalten werden, wie die Beteiligung organisiert wird, welche Ziele damit verfolgt werden und welche Effekte dabei entstehen. Die Ergebnisse sind je nach der Gruppe, die an einem IuK-Projekt beteiligt oder von ihm betroffen ist - unterschiedlich. Die Experten betrachten die Informationssystem-Planung zunächst als technische und dazu als organisatorische Aufgabe. Sie zeigen zwar Bereitschaft, auf Benutzeranforderungen einzugehen und sich daran zu orientieren, haben dabei aber primär die Benutzerakzeptanz und die Leistungsfähigkeit der Fachabteilungen im Auge. Personifiziert konzentriert sich ihre Vorstellung von Benutzerbeteiligung auf eine begrenzte Anzahl fachkompetenter Vertreter der Fachabteilung. Die Einbeziehung der Personalvertretung sehen sie als Politisierung ihrer Aufgabe an und stehen ihr reserviert gegenüber. Eine stärkere Benutzerbeteiligung wird durch den Mangel an geeigneten Methoden und Werkzeugen (z.B. Werkzeuge für den schnellen Probeentwurf) verhindert. Die Fachabteilungsleiter sehen Benutzerbeteiligung primär als Instrument zur Sicherung der Akzeptanz und damit zur Nutzung des Wirtschaftlichkeitspotentials der Informationssysteme. Die Personal-/Betriebsräte sehen die sozialen Folgen der Technikanwendung, wobei sie sich auf die Arbeitsplatzproblematik und den Kontrollaspekt (z.B. bei Personalinformations- und Betriebsdaten-Erfassungssystemen) konzentrieren. Sie sind nicht in der Lage, sich mit den vielen Einzelentwicklungen von Technikanwendungen und Reorganisationen zu befassen. Meist werden sie nicht oder zu spät informiert, oder das Informationsmaterial ist für eine Meinungsbildung ungeeignet. Zusammenfassend wird festgestellt, daß gegenwärtig von einem gemeinsamen Suchen nach Lösungen nicht gesprochen werden kann; die verschiedenen Akteure arbeiten nicht aufeinander zu. Auf Grund der unterschiedlichen Interessenslagen besteht dazu offensichtlich auch kein generelles Bedürfnis. Einzelne Gruppen zeigen in Einzelfällen Kooperationsbereitschaft und Rücksichtnahme, die jedoch kaum umgesetzt werden. The objective of a study conducted by Olson/Ives was to reexamine the relationship between user involvement and two types of user attitudes: user information satisfaction and satisfaction with the information systems group. The most significant finding from the study is the lack of agreement between the user and the information systems manager concerning the degree of user involvement. The belief that user involvement contributes to more satisfied users receives almost no support in this study. King/Rodriguez tested hypotheses concerning participative design using data describing the participation and performance of managers prior to, during, and after implementation of a participatively designed system. The study concludes that there is some effect of participation on the attitudes of participants, but no measurable effect on the amount of systems usage. The nature of system use was found to be related to inputs provided in the design process by participants. No advantage was found for participants in term of the quality of decision making.

BEBET - Methoden der Benutzerbeteiligung

121

J. J. Baroudi et al. kommen auf Grund empirischer Untersuchungen (Befragung von 200 Benutzern in gleichen Funktionen aus verschiedenen Unternehmen) zu dem Schluß, "that user involvement in system development leads to increased user information satisfaction and increased system usage." Spinas/Waeber berichten auf Grund empirischer Untersuchungen (Fragebogenerhebung bei 65 Benutzern, 61 Entwicklern und 31 Führungskräften in 10 Unternehmen, Untersuchungszeitraum nicht angegeben, vermutlich 1989) unter anderem: Die Einstellung zur Benutzerbeteiligung wird mit rd. 70% in allen Gruppen mit "zustimmend" eingeschätzt. Die Bereitschaft zur Beteiligung wird mit rd. 70% "Bereitschaft der Entwickler aus Benutzersicht" und rd. 60% "Bereitschaft der Benutzer aus Entwicklersicht" sehr hoch und im wesentlichen übereinstimmend beurteilt. Ein uneinheitliches Bild ergibt sich bezüglich der Partizipationsausprägung ("Grad der Partizipation" nach der Terminologie der Autoren). Rund 60% der Entwickler sehen die Benutzer primär als Informationslieferanten, nur 18% als Entscheider über die Funktionalität. Dagegen sehen nur 29% der Führungskräfte die Benutzer primär als Informationslieferanten, 46% sehen die Benutzer als Entscheider über die Funktionalität. Führungskräfte wünschen also eine wesentlich stärkere Partizipationsausprägung, als dies die Entwickler tun. Auch die Benutzer selbst geben ein uneinheitliches Bild: 31% sind mit der Rolle des Informationslieferanten zufrieden, ebenfalls 31% fordern eine wesentlich stärkere Partizipationsausprägung. T. Heinbockel ging der Hypothese nach, daß eine hohe Benutzerbeteiligung die Erreichung der Projektziele unterstützt und in einem positiven Zusammenhang mit der Prozeßqualität steht (Feldstudie, 29 Software-Projekte, Untersuchungszeitraum nicht angegeben); sie konnte nicht bestätigt werden. In 36% der Projekte mit hoher Benutzerbeteiligung konnten "niedrige Streßbedingungen" festgestellt werden; dagegen in 60% der Projekte mit niedriger Benutzerbeteiligung. In 36% der Projekte mit hoher Benutzerbeteiligung konnte eine "gute Interaktion im Team" festgestellt werden; dagegen in 67% der Projekte mit niedriger Benutzerbeteiligung. In 46% der Projekte mit hoher Benutzerbeteiligung konnte ein "guter Projekterfolg" festgestellt werden; dagegen in 69% der Projekte mit niedriger Benutzerbeteiligung. In 46% der Projekte mit hoher Benutzerbeteiligung konnte eine "gute Termin- und Kosteneinhaltung" festgestellt werden; dagegen in 62% der Projekte mit niedriger Benutzerbeteiligung. In 23% der Projekte mit hoher Benutzerbeteiligung konnte eine "hohe Teameffektivität" festgestellt werden; dagegen in 78% der Projekte mit niedriger Benutzerbeteiligung. Kontrollfragen 1. 2. 3. 4.

Wodurch ist der konsensorientierte Ansatz der Benutzerbeteiligung gekennzeichnet? Warum wird der konsensorientierte Ansatz von Gewerkschaftsseite abgelehnt? Welche Dimensionen der Benutzerbeteiligung können unterschieden werden? In welchen Arbeitsschritten von ETHICS wird die Perspektivenerweiterung um die sozialen Ziele deutlich sichtbar?

5.

Was bedeuten bei ETHICS Schwachstelle, Schwachstellenanalyse und Schwachstellenmatrix?

Quellenliteratur Baroudi, J. J. et al.: An Empirical Study of the Impact of User Involvement on System Usage and Information Satisfaction. In: Communications of the ACM 3/1986, 232 - 238

122

Mensch und

Projektmanagement

Gill, A.: Setting up Your Own Group Design Session. In: Datamation vom 15. 11. 1987, 87 - 92 Heilmann, H.: Modelle und Methoden der Benutzermitwirkung in Mensch-Computer-Systemen. 10. Jahrbuch der EDV. Forkel, Stuttgart 1981 Heinbockel, T.: Benutzerbeteiligung: Schlüssel zum Erfolg oder Hemmschuh der Entwicklung? In: Brodbeck, F. C. und Frese, M. (Hrsg.): Produktivität und Qualität in Software-Projekten. Oldenbourg, München/Wien 1994, 105- 124 M u m f o r d , E./Welter, G.: Benutzerbeteiligung bei der Systementwicklung. Schmidt, Bielefeld 1984 Oison, M . H./Ives, B.: User Involvement in System Design: An Empirical Test of Alternative Approaches. In: Information & Management 4/1981, 183 - 195 Spinas, O.AVeber, 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. Teubner, Stuttgart 1991, 36-45 Vertiefungsliteratur Galletta, G. F./Lederer, A. L.: Some Cautions on the Management of User Information Satisfaction. In: Decision Science Vol. 20, 419 - 438 Guimaraes, T./McKeen, J. D.: User Participation in Information System Development: Moderation in all Things. In: Avison, D. et al. (Ed.): Human, Organizational, and Social Dimensions of Information Systems Development. Elsevier Science Publishers, North-Holland et al. 1993, 171 - 192 King, W . R./Rodriguez, J. I.: Participative Design of Strategic Decision Support Systems: An Empirical Assesment. In: Management Science 6/1981, 717 - 726 Mambrey, P./Oppermann, R.: Benutzerbeteiligung bei der Systementwicklung - Einschätzung der Möglichkeiten durch Experten. In: Angewandte Informatik 3/1985, 111- 119 Morley, Ch.: Information Systems Development Methods and User Participation: A Contingency Approach. In: Avison, D. et al. (Ed.): Human, Organizational, and Social Dimensions of Information Systems Development. Elsevier Science Publishers, North-Holland et al. 1993, 127 142 Olson, M. H./Ives, B.: Chargeback Systems and User Involvement in Information Systems - An Empirical Investigation. In: MIS Quarterly 2/1982, 47 - 60 Rauterberg, M. et al.: Benutzerorientierte Software-Entwicklung. Konzepte, Methoden und Vorgehen zur Benutzerbeteiligung. Hochschulverlag ETH Zürich und Teubner, Stuttgart 1994 Reisin, F.-M.: Kooperative Gestaltung in partizipativen Softwareprojekten. P. Lang, Frankfurt/M. et al. 1992 Wood, J./Silver, D.: Joint Application Development. 2. Ed., John Wiley & Sons, New York et al. 1995

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, 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 Ausgangszustand durch Anwenden von Lösungsalgorithmen in einen erwünschten Endzustand transformiert werden kann, kreatives Problemlösen (creative problem solving) = die Fähigkeit des Menschen, Denkergebnisse hervorzubringen, die ihm oder seiner Umwelt neu sind. Kreativität (creativity) = die Fähigkeit des Menschen, schöpferisch zu sein, eigene Ideen entwickeln zu können, einfallsreich und erfinderisch zu sein. 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. Problemlösen (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 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.

124

Mensch und

Projektmanagement

Zweck der Kreativitätstechniken Zur Bewältigung der Projektarbeit 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 Projektphasen (insbes. in der Vorstudie) häufiger der Fall als in den späten Projektphasen. In den frühen Projektphasen ist der Handlungsspielraum groß; er nimmt mit zunehmendem Projektfortschritt ständig ab. Ein großer Handlungsspielraum ermöglicht mehr kreatives Handeln als ein kleiner Handlungsspielraum, der ausgeschöpft werden muß, wenn die Projektziele erreicht werden sollen. Kreatives Handeln wird durch die Anwendung von Kreativitätstechniken unterstützt. Anwendungsgebiete der Kreativitätstechniken Es gibt zwei idealtypische Verhaltensmuster zum Problemlösen: rationales Problemlösen und kreatives Problemlösen. Zwischen diesen Verhaltensmustern gibt es Mischformen, die Komponenten rationalen und kreativen Problemlösens enthalten. Rationales Problemlösen wird zum Lösen von wohlstrukturierten Problemen in geschlossenen Entscheidungssituationen empfohlen. Abbildung KREAT-1 zeigt den rationalen Problemlösungsprozeß.

KREAT-

Kreativitätstechniken

125

Häufiger als wohlstrukturierte Probleme in geschlossenen Entscheidungssituationen sind schlechtstrukturierte Probleme in offenen Entscheidungssituationen, für deren Bearbeitung kreatives Problemlösen charakteristisch ist. Abbildung KREAT-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 IuK-Projekten das Generieren alternativer Systemkonzepte beim Entwerfen der Grundkonzeption in der Vorstudie ist (vgl. Lerneinheit GRUND in Bd. 1 "Systemplanung").

Abb. KREAT-2: Kreativer Problemlösungsprozeß

Personelle und organisatorische Voraussetzungen Individuelle Kreativitätshemmnisse 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. 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.

126

Mensch und

Projektmanagement

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. Sie 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 PROVE) 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 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 (vgl. Lerneinheit SZENA im Bd. "Informationsmanagement") und die Delphi-Methode, zur zweiten Gruppe gehören insbesondere: • Das in den zwanziger Jahren von A. F. Osborn entwickelte Brainstorming. • 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.

KR FAT - Kreativitätstechniken

127

• Die in den fünfziger Jahren von W. J. J. Gordon und J. Prince entwickelte Synektik, zu deren Kennzeichen die Fragestellung "Wie kann erreicht werden, 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. Die genannten 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 B r a i n s t o r m i n g 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 Problemdefinition 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 umformuliert unter Verwendung der Einleitung "Wie kann ich erreichen, daß ...". • 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

128

Mensch und

Projektmanagement

gewonnene(n) Problemdefinition(en) ebenfalls unbefriedigend ist (sind), wird eine Iteration der 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 Idcengenerierung (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 zur Weiterentwicklung offenbarter Gedanken angeregt werden. 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 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

KREA T - Kreativitätstechniken

129

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.

$Jr

£ * ^ c «• £ a £ £ •„ c ^ n .c«TJff-T S o •'S J ö i i c 3 -

ll-fi-l

1

W a l toll w a g fallen? K o m p r i mierter? In M i n i a t u r ? Niedriger? Kurier? W e g lassen? Aufspalten ? Abschwächen ?

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

Demonstrationsbeispiel Es wird der Ablauf einer Kreativsitzung, unter Verwendung der Kreativitätstechniken W - T e c h n i k und B r a i n s t o r m i n g mit O s b o r n - V e r f r e m d u n g , zu einem Problem der Benutzerbeteiligung (vgl. Lerneinheit BEBET) dargestellt. P r o b l e m d e f i n i t i o n mittels

W-Technik

• Erster Arbeitsschritt: Spontandefinition. "Wie kann ich erreichen, daß zukünftige Benutzer Teile ihrer Freizeit für die Beteiligung am IuK-Projekt opfern?" • Zweiter Arbeitsschritt: Umformulierung. "Warum sollen Benutzer in ihrer Freizeit an einem IuK-Projekt mitwirken?" • Dritter Arbeitsschritt: Antworten. Erste Antwort: "Weil sie ein langfristiges Mitspracherecht bei der Gestaltung des IuK-Systems erwarten." Zweite Antwort: "Weil sie in den Genuß des Ansehens bei den nicht am Projekt beteilig-

130

Mensch und

Projektmanagement

ten Mitarbeitern kommen wollen." Dritte Antwort: "Weil sie ein persönliches Interesse an der Qualität des Projektergebnisses 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. I d e e n f i n d u n g 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

KREA T - Kreativitätstechniken

131

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 (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. 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? Wozu dienen die Verfremdungsmöglichkeiten nach Osborn?

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

PROTY - Prototyping in IuK-Projekten 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 in einem IuK-Projekt 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 der Benutzer, 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. Prototyping-Zyklus (prototyping cycle) = eine Folge von Arbeitsschritten, bestehend aus Verwenden, Bewerten und Modifizieren eines Prototyp. 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, die erforderlich sind, um ein System fehlerfrei zu halten (korrigierende Wartung), an veränderte Anforderungen anzupassen (Anpassungswartung) oder zu verbessern (Perfektionswartung). Widersprüchlichkeit (inconsistency) = die Eigenschaft eines Objekts (z.B. eines Systementwurfs), in sich nicht logisch zu sein. Synonym: Inkonsistenz.

PROTY - Prototyping

in luK-Projekten

133

Phasenschema und Prototyping Die Orientierung der Projektarbeit am Phasenschema 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 A n f o r d e r u n g e n (vgl. Lerneinheit ZIELP) sowie erhebliche Mängel bei Kosten- und Zeitschätzungen feststellbar. Diese wurden vor allem durch die aufwendigen Rückkopplungen von späten in frühe Projektphasen verursacht, wenn Planungsmängel Nacharbeiten erforderlich machten. Trotzdem war das Ergebnis der Projektarbeit 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 WERIP). 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-

134

Mensch und

Projektmanagement

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. Sie verdeutlicht die Zweckmäßigkeit der Verwendung von Prototypen in allen Projektphasen und veranschaulicht die Art und Weise, in der eine prototyporientierte Projektarbeit die im Phasenschema erforderlichen Rückkopplungen verkürzt (z.B. die Rückkopplung zwischen der Implementierung und dem Festlegen der Anforderungen in der Vorstudie durch exploratives Prototyping). Prototyping ist folglich auch als eine Vorgehensweise zur Realisierung der Qualitätsforderungen anzusehen (vgl. Lerneinheit QUAMA).

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 Benutzern auf der anderen Seite. • Er läßt sich von allen am Planungsprozeß Beteiligten bewerten. Nach der Art des Prototyp wird zwischen vollständigem Prototyp, unvollständigem Prototyp, Wegwerf-Prototyp und wiederverwendbarem Prototyp unterschieden.

PROTY - Prototypini;

in

luK-Projekten

135

• 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 Benutzeroberfläche) zu untersuchen. • Wegwerf-Prototyp: Ein Prototyp, der nur als ablauffähiges Modell dient; der Prototyp wird für das zu schaffende IuK-System nicht direkt verwendet. • Wiederverwendbarer Prototyp: Ein Prototyp, der alle Qualitätsforderungen erfüllt und von dem wesentliche Teile in das zu schaffende IuK-System übernommen werden können. Eine andere, primär vom Verwendungszweck des Prototyp ausgehende Systematik, unterscheidet zwischen Demonstrationsprototyp, Labormuster und Pilotsystem. • Der Demonstrationsprototyp unterstützt die Projektinitiierung bzw. die Projektakquisition; er soll den potentiellen Auftraggeber davon überzeugen, daß das gewünschte Endprodukt gebaut werden kann bzw. daß dessen 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-Prototyp. • 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 an einzelnen Arbeitsplätzen produktiv verwendet und weiterentwickelt. Er ist zunächst unvollständig und wiederwendbar, ab dieser Reife ist er 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 Prototyp 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 Eigenschaften das Endprodukt haben soll und welche für den Prototyp (bzw. für mehrere

136

Mensch und

Projektmanagement

Versionen des Prototyp) 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. E x p l o r a t i v e s 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 Prototyp anhand realer Arbeitssituationen zu beurteilen. Die Vorgehensweise des explorativen Prototyping ist dadurch gekennzeichnet, daß - ausgehend von ersten Vorstellungen über das zu schaffende IuK-System 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 stehen Funktionalität, leichte Veränderbarkeit und Kürze der Entwicklungszeit. Exploratives Prototyping unterstützt daher primär die Festlegung der Funktionsanforderungen (vgl. Lerneinheit ZIELP). Der Einfluß auf das Phasenschema ist gering, da exploratives Prototyping im wesentlichen nur für die Anforderungsanalyse verwendet wird. Dies gilt besonders dann, wenn (nur) Wegwerf-Prototypen verwendet werden. E x p e r i m e n t e l l e s Prototyping. Ziel des experimentellen Prototyping ist eine vollständige Spezifikation der Systemkomponenten, womit die Tauglichkeit von Objektspezifikationen, Architekturmodellen und Lösungsideen f ü r einzelne Systemkomponenten nachgewiesen werden soll. Die Vorgehensweise 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. Experimentelles Prototyping unterstützt also primär das System- und Komponentendesign bei der Software-Entwicklung. 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

PROTY - Prototyping

in IuK-Projekten

137

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 Projektarbeit, das heißt eine sukzessive Planungsstrategie nach folgender Vorgehensweise: Entwicklung eines Prototyp 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 Prototyp bzw. letztlich für das Endprodukt. Im nächsten Planungsschritt werden weitere Anforderungen in den Prototyp 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 ist beim evolutionären Prototyping am deutlichsten; es kann sogar gesagt werden: evolutionäres Prototyping und Phasenschema sind unverträglich. V o r g e h e n s w e i s e 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 w e r f P r o t o t y p 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, w o f ü r ein w i e d e r v e r w e n d b a r e r Prototyp entwickelt wird. Nach jeder Bewertung wird entschieden, was die Erreichung der Planungsziele besser unterstützt: den vorhandenen Prototyp 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 Prototyp. dritter Arbeitsschritt: Verwenden des Prototyp. vierter Arbeitsschritt: Bewerten des Prototyp. fünfter Arbeitsschritt: Modifizieren des Prototyp 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 Prototyp das Endprodukt entstanden. Ein Prototyping-Zyklus kann planmäßig einem bestimmten Zweck dienen, so z.B. ein erster Zyklus der Initiierung. Hier geht es primär darum, daß sich die Beteiligten in die Projektaufgabe einarbeiten. Im ersten Prototyp werden daher nur wenige, den Entwicklern bereits bekannte Funktionen realisiert. Ein zweiter PrototypingZyklus kann der Orientierung dienen. Hier geht es darum, alle wesentlichen An-

138

Mensch und

Projektmanagement

f o r d e r u n g e n zu erfassen, die im Prototyp 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 die Schulung der Benutzer verwendet werden. Werden 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 ist und seine Realisierungsmöglichkeiten fraglich sind. A u s w i r k u n g e n des Prototyping Systematische empirische Befunde über die Auswirkungen des Prototyping liegen nicht vor. Bezüglich der K o s t e n für einzelne Prototypen sprechen E r f a h rungsberichte 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 handelt. 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 Verbesserung des Nutzens des mit Prototyping hergestellten Endprodukts gesehen. Dies ergibt sich insbesondere aus der verbesserten Zusammenarbeit zwischen Anwendern und Benutzern auf der einen und Systemplanern auf der anderen Seite, die zu einem Produkt führt, das durch eine auf die Arbeitssituation besser abgestimmte Funktionalität und Benutzbarkeit gekennzeichnet ist. Die Akzeptanz des Produkts durch die Benutzer ist 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 B e w e r tung von Prototypen das Projekt-Controlling (vgl. Lerneinheit PCONT) unterstützt wird und daß daher zuverlässiger beurteilt werden kann, ob ein IuK-Projekt unverändert fortgeführt, 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

PROTY-

Prototyping

in IuK-Projekten

13 9

vorgesehen war, folgende 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 Prototyping-Werkzeug 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.

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

Der wichtigste Baustein einer DICE-Anwendung ist ein Fenster. Um ein leeres Fenster zu erhalten, wird der Button Edit Window im Bedienungspanel von

140

Mensch und

Projektmanagement

DICE aktiviert (siehe Abbildung PROTY-3). Um Benutzerschnittstellenelemente in ein Fenster einzufü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 Teilfenstern) gibt es zwei Gruppierungselemente - Cluster und Expander. Sie unterstützen die Spezifikation des Fenster-Layouts und des Verhaltens der Benutzerschnittstellenelemente, wenn die Größe des sie umgebenden Fensters verändert wird.

0k

•

P o i n t i n g Tool

E m p t y Cluster

Action Button

E m p t y Subwindow

E m p t y Expander

Radio Button

T

si

Text S u b w i n d o v

Static Text F i e l d

Toggle Button

List S u b w i n d o v

Editable Text Field

25 Popup Item

@

E n u m e r a t i o n Item

I

j

Q Label Labeled Radio Button

Bü Label Labeled Toggle Button

m j j j j j j ^ ^Test Prototypej ^Generate Code ... j •v ( \ \ Saue Sauefls... Abb. PROTY-3: DICE's Bedienungspane] (Quelle: Pombergeret 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 Prototyp und zwischen verschiedenen Prototypen unterstützt. Die elementspezifischen Parameter werden über Dialoge angegeben. Abbildung PROTY-4 zeigt beispielsweise die Attributspezifikation für einen Action Button. 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 Prototyp zur fertigen Anwendung zu ermöglichen. Dazu bietet DICE verschiedene Möglichkeiten (die hier nicht erläutert werden).

PROTY- Prototyping in IuK-Projekten

141

B

Cash Dispenser

W e l c o m e to the machine !

M LjlJM ili3 [ 2[ ] m >) '

)

Stop

00

Action Button Parameters Tewt:

J Stop

Stretching B e h a u i o u r

r

•

horizontally fined

•

uertically fiHed

•

r

Default

Component N a m e StopButtor{

S

A b b . P R O T Y - 4 : Beispiel für eine mit D I C E spezifizierte Benutzerschnittstelle (Quelle: P o m b e r g e r e t al.) Message Editor Target Objects: Button9 CardButton

LT

Passible M e s s a g e s :

Rlready Defined:

Open

0isable(->0kBuUon) Disable(->CardButton)

Display OkButton StopButton

Abb. P R O T Y - 5 : Nachrichteneditor (Quelle: P o m b e r g e r e t al.)

Den einzelnen Benutzerschnittstellenelementen sind bestimmte, vordefinierte Nachrichten zugeordnet (z.B. einem Fenster die Nachrichten Open und Close, einem Textfeld die Nachrichten Enable, Disable und SetText(...) etc.). Betrachtet wird als Beispiel die Benutzerschnittstelle eines einfachen Geldausgabeautomaten (Cash Dispenser) aus Abbildung PROTY-4. Es soll z.B. das Cash Dispenser Fenster geschlossen werden, wenn der Button Stop aktiviert wird. Um dieses dynamische Verhalten zu spezifizieren, wird der Button Link im Parameterdialog des Buttons Stop aktiviert (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 Akti-

142

Mensch und

Projektmanagement

vierung 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 Prototyp ohne eine einzige Zeile Programmcode realisiert werden. Um den Prototyp 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 Prototyp 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 Vorgehensweise 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 1992, 65 - 77 Pomberger, G./Blaschek, G.: Software Engineering. Prototyping und objektorientierte SoftwareEntwicklung. Hanser, 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./Pomberger, G.: Prototyping-oriented Software Development. Concepts and Tools. Springer, Berlin et al. 1992 Budde, R. et al.: Prototyping. An Approach to Evolutionary System Development. Springer, Berlin etal. 1992 Hildebrand, K.: Repository-unterstütztes Prototyping. In: HMD - Theorie und Praxis der Wirtschaftsinformatik 161/1991, 107 - 116 Vonk, R.: Prototyping - The effective use of CASE Technology. Prentice Hall Int., Hempstead 1990

Projektphasen

Strategische Informationssystem-Planung

10

Abb. MEAUF-2: Klassifizierung der Dateneingaben

Merkmale Anzahl Listenspalten unterschiedliche Datenelemente

mittel

komplex

1 bis 6

7 bis 15

>15

1 bis 5

6 bis 10

>10

einfach

1

2 bis 3

>3

Dateizugriffe Datenelemente für Druck aufbereiten

wenige keine

mehrere einige

viele viele

Anforderungen an die Performance

gering

mittel

hoch

4

5

7

Gruppenwechsel

Gewicht

Abb. M E A U F - 3 : Klassifizierung der Datenausgaben

MEA UF - Methoden der Aufovandsschätzung

Merkmale

einfach

mittel

Anzahl unterschiedliche Datenelemente

1 bis 20

21 bis 40

Anzahl Schlüsselbegriffe bzw. Satzarten Datenbestand vorhanden Datenstruktur wird verändert Gewicht

1

nein

komplex >40

2

>2

-

nein

ja

ja

-

10

7

221

15

Abb. MEAUF-4: Klassifizierung der Datenbestände

Merkmale

einfach

mittel

komplex

Anzahl unterschiedliche Suchbegriffe

1

2

>2

Logische Eingabeprüfung

leicht

mittel

schwer

Anforderungen an die Bedienerführung

gering

normal

hoch

Cursor-Handhabung

einfach

mittel

schwierig

3

4

6

Gewicht

Abb. MEAUF-5: Klassifizierung der Abfragen

einfach

Merkmale

mittel

komplex

Anzahl unterschiedlicher Datenelemente

R T

Anzahl Schlüsselbegriffe/Satzarten

R

1

2

>2

Dimension

T

1

2

>2

5

7

10

Gewicht

1 bis 20 21 bis 40 1 bis 5 6 bis 10

>40 >1

Abb. MEAUF-6: Klassifizierung der Referenzdaten

Dritter Arbeitsschritt: Berücksichtigen der Einflußfaktoren. Mit den Einflußfaktoren wird die Auswirkung des Anwendungsumfelds der Projektaufgabe auf den Projektaufwand berücksichtigt. Daher hängt es vom Anwendungsumfeld ab, welche Einflußfaktoren von Bedeutung sind. Die folgende Aufzählung hat nur exemplarischen Charakter. • Es bestehen Schnittstellen zu anderen DV-Systemen.

222

Planungsmethoden

• Datenverwaltung und -Verarbeitung werden dezentral durchgeführt. • Entwurf und Implementierung werden durch eine hohe Transaktionsrate beeinflußt. • Schwierige und komplexe Verarbeitungen werden erforderlich sein (z.B. Simulationen). • U m f a n g r e i c h e Kontrollroutinen zur Sicherstellung einer ordnungsgemäßen Verarbeitung werden notwendig sein. • Zahlreiche Ausnahmeregelungen, die technisch und organisatorisch bedingt sind, werden erforderlich sein. • Es liegt eine schwierige und komplexe Verarbeitungslogik vor. • Eine Wiederverwendbarkeit von Programmen in anderen DV-Systemen wird angestrebt. • Für die Konvertierung von Datenbestände sind bei Entwurf und Implementierung besondere Maßnahmen erforderlich. • Für die Benutzer sind besondere Erleichterungen für die Bedienung und den Änderungsdienst vorzusehen. Die W i r k u n g j e d e s Einflußfaktors auf den P r o j e k t a u f w a n d wird mit folgender S k a l a bewertet ( f ü r einzelne Einflußfaktoren mit einem überdurchschnittlich starken Einfluß auf den Projektaufwand kann eine Verdoppelung der Bewertung vorgesehen werden, also zwischen 0 und 10): • • • • • •

0 1 2 3 4 5

= = = = = =

kein E i n f l u ß gelegentlicher Einfluß mäßiger Einfluß mittlerer Einfluß bedeutsamer Einfluß starker Einfluß

Je nach A u s p r ä g u n g der Einflußfaktoren wird der P r o j e k t a u f w a n d verringert oder vergrößert. Vierter Arbeitsschritt: B e r e c h n e n d e r F u n c t i o n P o i n t s . Die Berechnung der Function Points F P erfolgt gemäß Formel (1) durch Multiplikation der Funktionszahl F Z mit dem Einflußgrad EG. Die Berechnung von F Z erfolgt g e m ä ß Formel (1.1), die von E G gemäß Formel (1.2). In Formel (1.1) bedeuten: Fjj die A n z a h l der F u n k t i o n e n der Funktionskategorie i, i = l ( l ) m , des K o m p l e xitätsgrads j, j = l ( l ) n , und gj das G e w i c h t des Komplexitätsgrads. In Formel (1.2) sind ci und C2 N o r m i e r u n g s k o n s t a n t e und ek ist der Einfluß j e Einflußfaktor k, k = 1(1 )z. c i und C2 werden auf Grund der gewünschten Streubreite von EG sowie des M i n i m u m s und des M a x i m u m s der S u m m e der E i n f l u ß f a k toren festgelegt (z.B. sind bei einer gewünschten Streubreite von EG von 30%, einem M i n i m u m von 0 und einem Maximum von 60 ci = 0,7 und C2 = 0,01). (1) FP = F Z « E G m (1.1) FZ = X i=l

n Zfij'gj j=l

MEA UF - Methoden der Außvandsschiitzung

223

z (1.2) E G =

+ c 2 * X ek k= 1

Cl

A b b i l d u n g M E A U F - 7 zeigt ein bei m a n u e l l e r E r m i t t l u n g der F u n c t i o n Points v e r w e n d b a r e s "Rechenblatt" mit b e i s p i e l h a f t e n Einträgen; der zweite bis vierte Arbeitsschritt k ö n n e n daran nachvollzogen werden. Funktionskategorie Dateneingaben

Datenausgaben

Abfragen

Datenbestände

Referenzdaten

Anzahl 36

Gewicht

Funktionszahl

einfach = 3

22

mittel = 4

17

komplex = 6

88 102

13

einfach = 4

20

mittel - 5

12

komplex = 7

84

20

60

5

einfach = 3 mittel -- 4

15

komplex = 6

90

-

einfach = 7

52 100

20 -

12

mittel = 10

120

9

komplex = 15

135

-

einfach = 5

15

mittel = 7

-

komplex = 10 Funktionszahl:

Einflußfaktoren

108

_ 105 -

1.064

1. Verflechtung mit anderen Verfahren

3

2. Dezentrale Datenverwaltung 3. Transaktionsrate

3 4

4. Schwierige Rechenoperationen 5. Umfangreiche Kontrollverfahren

8 4

6. Zahlreiche Ausnahmeregelungen

3

7. Komplexe Logik

5

8. Wiederverwendung

3 2

9. Datenkonvertierung 10. Benutzerbedienung Summe Einflußfaktoren:

4 39

Einflußgrad:

1,09

Funktionspunkte:

1.160

Abb. MEAUF-7: Rechenblatt Function-Point-Verfahren

224

Planungsmethoden

Fünfter Arbeitsschritt: Ermitteln des Projektaufwands. Der Projektaufwand wird durch Analogieschluß ermittelt. Dazu müssen aus abgeschlossenen Projekten die Function Points und der Projektaufwand, gemessen in Bearbeitermonaten, bekannt sein (Function-Point-Kurve). Abbildung MEAUF-8 zeigt ein Beispiel für eine F u n c t i o n - P o i n t - K u r v e . (Der schwach degressive Verlauf entspricht z.B. den Projekterfahrungen der Bayerischen Hypotheken- und Wechsel-Bank AG, München.) Der zu den Function-Points (FP) gehörende Projektaufwand in Bearbeitermonaten kann abgelesen bzw. durch Interpolation ermittelt werden (z.B. entsprechen 500 FP 46,1 Bearbeitermonaten, 2000 FP 283,7 Bearbeitermonaten und 3800 F P 658,1 Bearbeitermonaten). Die Function-Point-Kurve muß mit neuesten Erfahrungswerten fortgeschrieben werden. Die Erfahrungswerte sollten vorher überprüft und bereinigt werden, um die Auswirkung außergewöhnlicher Ausprägungen der Einflußfaktoren beseitigen zu können.

Abb. MEAUF-8: Schätzkurve für Function-Point-Verfahren (Quelle: Noth/Kretschmar)

Weiterentwicklungen des Function-Point-Verfahrens Praktische Erfahrungen zeigen, daß Function Points auch ein gutes Maß für die Schätzung des N u t z e n s sein können (vgl. Lerneinheit WIRTA). Auch für die Zurechnung von Gemeinkosten auf IuK-Projekte sind Function Points eine geeignete Basis. Mit der Begründung, daß ein Funktionenmodell - verglichen mit einem Datenmodell - erst relativ spät im Planungsprozeß vorliegt, schlägt R. Härten vor, die Aufwandsschätzung beim Function-Point-Verfahren zunächst auf der Grundlage des D a t e n m o d e l l s durchzuführen. Erst wenn Klarheit über die Funktionalität besteht, sollte die Schätzung auf Grundlage des Funktionenmodells verbessert werden. Unabhängig davon ist zu empfehlen, die Schätzgenauigkeit durch iteratives, mehrmaliges Schätzen mit zunehmendem Projektfortschritt zu verbessern (z.B. e r s t m a l s in der Vorstudie, dann nach Vorliegen des f a c h l i c h e n Grobkonzepts, erneut vor Beginn der Implementierung). Eine Verallgemeinerung dieser Weiterentwicklung führt zu der Forderung, die Schätzung auf der Grundlage von O b j e k t e n durchzuführen, also vom Function-Point-Verfahren zum O b j e c t - P o i n t - V e r f a h r e n fortzuschreiten.

MEA UF - Methoden der Aufwandsschätzung

225

Demonstrationsbeispiel Die Software AG verwendet im eigenen Haus und bei Kundenprojekten das Werkzeug ESTI-MATE zur Unterstützung der Aufwandsschätzung. Als Schätzverfahren wird Object Point verwendet, worunter ein Metaverfahren verstanden wird, "aus dem in Anpassung an gegebene Vorgehenskonzepte konkrete Schätzverfahren abgeleitet werden können". ESTI-MATE besteht aus einem Administrationsteil und einem Schätzteil. Der Administrationsteil dient zur Definition und Verwaltung konkreter Schätzverfahren, der Schätzteil unterstützt die Schätzung (und Nachkalkulation) auf Basis der verwendeten Schätzverfahren. Die im Administrationsteil verwalteten Schätzverfahren stellen die Metadaten dar, die festlegen, mit welchem konkreten Object Point geschätzt wird. Zur Entwicklung von ESTI-MATE wurde die Entwicklungsumgebung PREDICT CASE/ADAPT STANDARDS verwendet. Im wesentlichen steht daher in ESTI-MATE die Funktionalität von ADAPT STANDARDS zur Verfügung. Im folgenden wird auf den vom Schätzverfahren unabhängigen Schätzteil von ESTI-MATE näher eingegangen. Abbildung MEAUF-9 zeigt den Menübaum für den Schätzteil. Der typische Verlauf einer Arbeitssitzung sieht wie folgt aus: • Entscheidung zwischen Nachkalkulation und Schätzung. Im Rahmen der Aufwandsschätzung dient die Nachkalkulation dem Aufbau der Schätzkurve (vgl. Abbildung MEAUF-8); alle dazu erforderlichen Daten sind bereits vorhanden (wenn unterstellt wird, daß das nachkalkulierte Projekt auch geschätzt wurde). Alle Schätzobjekte und Einflußfaktoren können daher bewertet werden. Im Falle der Schätzung muß dagegen zunächst geprüft werden, ob die erforderlichen Daten zur Verfügung stehen. (Im folgenden werden beide Fälle als Schätzung bezeichnet.) Welche Daten vorliegen müssen, hängt vom verwendeten Schätzverfahren ab. • Auswahl des Schätzverfahrens. Schätzverfahren sollten auf das beim Anwender eingesetzte Vorgehensmodell abgestimmt sein. Für jedes im Verfahrensteil definierte Schätzverfahren muß festgelegt sein, an welchem Punkt im Lebenszyklus mit ihm geschätzt werden kann. Ein Schätzverfahren für die Schätzung am Ende der Phase x sollte daher nur solche Daten verlangen, die am Ende dieser Phase entsprechend dem Vorgehensmodell vorliegen müssen (Schätzbasis). Liegt die erforderliche Schätzbasis vor, kann mit der Schätzung begonnen werden. Jedes verwendbare Schätzverfahren sollte in einem Schätzleitfaden dokumentiert sein. • Projekt und Schätzversion anlegen. Ein Projekt wird mit einer Bezeichnung und einigen allgemeinen Informationen zum Projekt angelegt. Da es zweckmäßig sein kann, zu einem Projekt mehrere Schätzungen abzugeben, wird eine Schätzversion angelegt. Dabei muß angegeben werden, mit welchem Schätzverfahren gearbeitet werden soll. Zu einer Schätzversion gehören Schätzobjekte, Einflußfaktoren und (gegebenenfalls) Zusatzanforderungen; letztere können angelegt und bewertet werden. Die Einflußfaktoren werden bei der Definition der Schätzverfahren festgelegt; sie müssen daher nicht explizit angelegt, sondern nur bewertet werden. In welcher Reihenfolge Schätzobjekte, Einflußfaktoren und Zusatzanforderungen bewertet werden, ist von ESTIMATE nicht vorgegeben, doch sollte im allgemeinen mit den Schätzobjekten

226

Planungsmethoden

begonnen werden (weil der Schätzer daraus brauchbare Hinweise für die Bewertung der Einflußfaktoren und Zusatzanforderungen gewinnen kann).

Schätzung durchführen

Abb. MEAUF-9: Menübaum für Schätzteil von ESTI-MATE (Quelle: Software AG)

• Schätzobjekt(e) anlegen und bewerten. Die Schätzobjekte beschreiben Umfang und Komplexität des Projekts. Jedes Schätzobjekt gehört zu einem Schätzobjekttyp (z.B. das Schätzobjekt Kunde gehört zum Schätzobjekttyp Informationsobjekt). Im Schätzverfahren ist definiert, welche Schätzobjekttypen es gibt und durch welche Anforderungen ihre Komplexität näher beschrieben

MEA UF - Methoden der Aufwandsschätzung

•

•

• •

227

werden soll. Zur Gewinnung der Schätzobjekte muß die vorliegende Schätzbasis analysiert werden. Wenn alle Schätzobjekte erfaßt sind, erfolgt ihre Bewertung. Zur Bewertung werden vom Schätzer die im Administrationsteil zu jedem Schätzverfahren definierten Fragen beantwortet (durch Angabe von Mengen oder durch Auswahl von vorgegebenen Antworten) und mit einem Gewichtungsfaktor versehen. Aus diesen Angaben errechnet ESTI-MATE den Wert des Schätzobjekts in Object Points. Einflußfaktoren bewerten. Einflußfaktoren sind Bedingungen, Anforderungen usw., die sich nicht als Schätzobjekte erfassen lassen, da sie auf das Gesamtprojekt einwirken. Jeder Einflußfaktor wird durch einen oder mehrere Anforderungstypen beschrieben, die im Schätzverfahren festgelegt sind. Zusatzanforderungen verwalten. Zusatzanforderungen lassen sich weder als Schätzobjekt, noch als Einflußfaktor erfassen. Sie werden vom Schätzer direkt in Mitarbeitertagen geschätzt. Zur Unterstützung für den Schätzer wird im Administrationsteil eine Liste Zusatzanforderungen geführt, die im Sinn einer Checkliste verwendet werden kann; neue Zusatzanforderungen können hinzugefügt werden. Schätzergebnis ermitteln. Mit dieser Funktion wird der Gesamtwert der Schätzversion in Object Points berechnet und hierfür der geschätzte Aufwand in Mitarbeitertagen aus der Schätzkurve abgelesen und angezeigt. Alternativschätzung durchführen. Die Schätzversion oder Teile davon können - entsprechend den Unterschieden zwischen Projektalternativen - in eine neue Schätzversion überführt werden. Dazu kann die Schätzversion oder Teile davon kopiert werden.

Ein Werkzeug wie ESTI-MATE kann die Aufwandsschätzung unterstützen, indem der Zeitaufwand für die Schätzung reduziert und die Berücksichtigung von Schätzerfahrungen gesichert wird. Die kritische Auseinandersetzung mit dem Schätzergebnis kann damit nicht ersetzt werden. Dies ist vor allem dann der Fall, wenn die Aufwandsschätzung für Projekte erfolgt, die vor dem Hintergrund der bisherigen Schätzpraxis und damit der verfügbaren Schätzkurve bezüglich Schätzobjekte, Einflußfaktoren und Zusatzanforderungen untypisch sind. Forschungsbefunde Stahlknecht/Thienell stellen zur Akzeptanz und Ergebnisqualität von Schätzverfahren fest, daß formalisierte Vorgehensweisen weitgehend abgelehnt werden, obwohl die Schätzpraxis durch dramatische Abweichungen der Schätzwerte von den Istwerten gekennzeichnet ist. Noth/Kretzschmar ziehen aus derartigen Beobachtungen den Schluß, daß nicht die Entwicklung neuer Schätzverfahren erforderlich ist, sondern daß "flankierende Maßnahmen" für formal befriedigende Schätzverfahren entwickelt werden müssen. Sie bestehen darin, Erfahrungswissen aus Software-Entwicklungen zu sammeln, zu systematisieren und auszuwerten. R. Saalfrank et al. berichten über die Anwendung eines mit COKAL bezeichneten Schätzverfahrens, das im wesentlichen die Struktur von COCOMO hat, aber die Parameter neu quantifiziert. Vergleichende Schätzungen unter Verwendung der von B. W. Boehm angegebenen Datenbasis haben ergeben, daß die mittlere Summe der relativen Fehler beim Projektaufwand um 65,9% und bei der Projektdauer um 44,1 % kleiner ist.

228

Planimgsmethoden

Zum Function-Point-Verfahren liegen zahlreiche Forschungsbefunde vor, unter anderem folgende: S. Drummond beschreibt die Anwendung des FunctionPoint-Verfahrens bei 29 größeren Projekten mit 74 oder mehr Bearbeitertagen und einer Reihe von kleinen Projekten, die über einen Zeitraum von sechs Monaten abgewickelt wurden (Untersuchungszeitraum 1983). Er kommt zu dem Schluß, daß das Function-Point-Verfahren einen signifikanten Fortschritt in der Meß- und Schätztechnik ermöglicht. E. Rudolph berichtet über die Anwendung des Function-Point-Verfahrens bei 19 Projekten, die mit dem Ziel untersucht wurden, die Auswirkungen des Einsatzes einer Programmiersprache der 4. Generation auf die Produktivität der Software-Entwicklung zu ermitteln. Er stellt fest, daß das Function-Point-Verfahren ein wirksames Mittel zur Bestimmung derartiger Auswirkungen ist. Ch. R. Symons stellt auf Grund von Anwendungserfahrungen fest, daß das Function-Point-Verfahren mit der von ihm vorgeschlagenen Anpassung (Mark II) "still seem to offer one of the best lines of approach for an organization that wishes to study its trends in productivity and improve its estimating methods for the development and support of computerized business information systems."W. Haschke berichtet über die Ergebnisse der sog. DV-Controlling-Enquete 1993 (Stichprobenanalyse, Fragebogenerhebung mit anonymen Adressaten, N = "über 60", deskriptive und einfache quantitative Datenanalyse) bezüglich des Function-Point-Verfahrens, daß es "als unbestreitbar bestes Zeitaufwandschätzverfahren für die Softwareerstellung" bei 53% der Stichprobe nie, bei über 20% selten, bei 10% vorwiegend und nur bei 2% immer eingesetzt wird. Von über 80% der Anwender wird es im ersten Jahr, von über 10% seit zwei bis vier Jahren verwendet. Knapp 30% der Anwender verwenden es bereits in der Vorstudie, die anderen erst nach Erstellung des fachlichen Grobkonzepts. Kontrollfragen 1. 2. 3. 4. 5.

W e l c h e Methoden zur Aufwandsschätzung gibt es? W o d u r c h unterscheiden sich Schätzmethoden von Schätzverfahren? W e l c h e Rolle spielen Einflußfaktoren für die Aufwandsschätzung? W i e wird beim Function-Point-Verfahren aus den Funktionspunkten der A u f w a n d ermittelt? W a s besagen Forschungsbefunde zur Akzeptanz von Schätzverfahren und deren Ergebnisqualität?

Quellenliteratur H e r r m a n n , O.: Kalkulation von Softwareentwicklungen. Oldenbourg, München/Wien 1983 H e r r m a n n , O.: V e r f a h r e n zur A u f w a n d s s c h ä t z u n g bei der E n t w i c k l u n g von A n w e n d u n g s s y s t e men. In: Kurbel, K./Strunz, H. (Hrsg.): Handbuch Wirtschaftsinformatik. P o e s c h e l , Stuttgart 1990,419 - 4 3 4 Noth, T . / K r e t z s c h m a r , M.: A u f w a n d s s c h ä t z u n g von D V - P r o j e k t e n . 2. A., Springer, Berlin et al. 1986 Seibt, D.: Die Function-Point-Methode: Vorgehensweise, Einsatzbedingungen und A n w e n d u n g s erfahrungen. In: A n g e w a n d t e Informatik 1/1987, 3 - 1 1 S y m o n s , Ch. R.: Function Point Analysis: Difficulties and I m p r o v e m e n t s . In: I E E E T r a n s a c t i o n s on S o f t w a r e Engineering 1/1988, 2 - 1 1 Vertiefungsliteratur Albrecht, A. J.: Function points as a measure of productivity. In: Proc. IBM Applications Development Symp., IBM Corporation, Monterey/CA 1979, 83 D r u m m o n d , S.: M e a s u r i n g Application Development P e r f o r m a n c e . In: D a t a m a t i o n , July 1987, 1 0 2 - 108

MEA UF - Methoden der Aufwandsschätzung

229

Elzer, P. F.: M a n a g e m e n t von S o f t w a r e - P r o j e k t e n . In: I n f o r m a t i k - S p e k t r u m 1989, 181 - 197 F u c h s , N . : C O S M O S - C o s t M a n a g e m e n t with M e t r i c s of S p e c i f i c a t i o n . In: F e n t o n , N . / L i t t l e w o o d , B. (Ed.): S o f t w a r e Reliability and Metrics. Elsevier, Barking 1991, 176 - 184 H a s c h k e , W . : D V - C o n t r o l l i n g . P l a n u n g , S t e u e r u n g , Kontrolle. C o m p u t e r w o c h e , M ü n c h e n 1994 Hürten, R.: D a s D a t e n m o d e l l als G r u n d l a g e f ü r die A u f w a n d s c h ä t z u n g . In: T h e o r i e und Praxis der W i r t s c h a f t s i n f o r m a t i k 1 6 9 / 1 9 9 3 , 9 4 - 104 K n ö l l , H . - D . / B u s s e , J.: A u f w a n d s s c h ä t z u n g von S o f t w a r e - P r o j e k t e n in d e r Praxis. B.I. W i s s e n schaftsverlag, M a n n h e i m e t al. 1991 K o k , P.: N e w A p p r o a c h to S o f t w a r e C o s t E s t i m a t i o n . In: F e n t o n , N . / L i t t l e w o o d , B. ( E d . ) : S o f t w a r e Reliability and Metrics. Elsevier, Barking 1991, 162 - 175 K u r b e l , K . / D o r n h o f f , P.: A u f w a n d s c h ä t z u n g f ü r S o f t w a r e - E n t w i c k l u n g s p r o j e k t e m i t H i l f e fallbasierter W i s s e n s v e r a r b e i t u n g . In: Zeitschrift für Betriebswirtschaft 10/1993, 1047 - 1065 Oriolo, M . : S c h ä t z v e r f a h r e n in 4 G L - und C A S E - U m g e b u n g e n . Springer, Berlin et al. 1990 S a a l f r a n k , R. et al.: P r o d u k t i v i t ä t s e f f e k t e von A u f w a n d s e i n f l u ß g r ö ß e n bei der S o f t w a r e e n t w i c k lung. In: A n g e w a n d t e Informatik 3/1987, 95 - 103 Schultz, V.: P r o j e k t k o s t e n s c h ä t z u n g . K o s t e n e r m i t t l u n g in den f r ü h e n Phasen von t e c h n i s c h e n A u f t r a g s p r o j e k t e n . Gabler, W i e s b a d e n 1995 S n e e d , H . M . : S c h ä t z u n g der E n t w i c k l u n g s k o s t e n von o b j e k t o r i e n t i e r t e r S o f t w a r e . In: I n f o r m a t i k - S p e k t r u m 1996, 133 - 1 4 0 S t a h l k n e c h t , P . / T h i e n e l l , K.: E m p i r i s c h e E r h e b u n g ü b e r V e r f a h r e n z u r A u f w a n d s s c h ä t z u n g f ü r D V - P r o j e k t e . Bericht 8 2 1 0 des F a c h b e r e i c h s W i r t s c h a f t s w i s s e n s c h a f t e n der Universität O s n a b r ü c k , 1982

Informationsmaterial S o f t w a r e A G (Hrsg.): E S T I - M A T E B e n u t z e r h a n d b u c h . Uhlandstr. 12, D - 6 4 2 9 7 - D a r m s t a d t

WERIP - Werkzeugunterstützung bei IuK-Projekten Lernziele Sie kennen den Zweck der Werkzeugunterstützung bei IuK-Projekten. 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. Definitionen und Abkürzungen A D / C y c l e = Akronym für Application Development/Cycle; ein CASE-System der IBM. A D P S = Akronym für Application Development Project Support; ein CASEWerkzeug der IBM. C A R E = Akronym für Computer Aided ReEngineering. C A S E = Akronym 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 = Akronym für Integrated Computer Aided Software Engineering. I E F = Akronym für Information Engineering Facility; ein C A S E - W e r k z e u g 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. Prototyping (prototyping) = eine Vorgehensweise bei IuK-Projekten 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. Restrukturierung (restructuring) = die Übertragung eines Systems von einer Repräsentationsform in eine andere, ohne das Verhalten des Systems oder die Funktionalität zu ändern. V a l i d i e r u n g (Validation) = die Prüfung der Verwendungsfähigkeit des Produkts, d.h. die Beantwortung der Frage: Wird das richtige Produkt hergestellt? Validität (validity) = das Ausmaß, mit dem die im Produkt realisierten Eigenschaften mit den vom Produkt geforderten Eigenschaften übereinstimmt. V e r i f i z i e r u n g (verification) = die Prüfung der Übereinstimmung zwischen Produkt und Spezifikation mittels empirischer Methoden, d.h. die Beantwortung der Frage: Wird das Produkt richtig hergestellt?

WERIP - Werkzeugunterstützung bei IuK-Projekten

231

Zweck der Werkzeugunterstützung Zweck der Werkzeugunterstützung von IuK-Projekten ist es, verschiedene Merkmale der Prozeßqualität und der Produktqualität (vgl. Lerneinheit ZIELP) besser zu erreichen. Dabei stehen Produktivität als Prozeßmerkmal und Validität als Produktmerkmal 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 Validitä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 reduziert werden. Die Verbesserung von Produktivität und Validität kann durch die Verwendung von V o r g e h e n s m o d e l l e n und damit von Methoden erreicht werden, die auch ohne Werkzeuge verwendet werden können. Vorgehensmodelle und Methoden ohne Werkzeuge sind in Handbüchern abgelegt; die Methoden sollen verwendet werden. Anwendungserfahrungen zeigen, daß dies häufig deshalb nicht erfolgt, weil kein Zwang zur Methodenverwendung besteht. 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, sodaß die Anwendung aufeinander abgestimmter Methoden in allen Projektphasen erleichtert wird. Damit wird auch die D u r c h g ä n g i g k e i t der Methoden in allen Phasen des Arbeitsprozesses bzw. für alle Tätigkeiten des verwendeten Vorgehensmodells unterstützt. Durch die Verwendung von Werkzeugen sollen vor allem die frühen Projektphasen unterstützt werden, das heißt die Analyse und der Entwurf. So wird z.B. eine Unterstützung für die A n f o r d e r u n g s a n a l y s e (vgl. Lerneinheit ZIELP) 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 (z.B. durch Prototyping, vgl. Lerneinheit PROTY). Auch in den späten Projektphasen können durch Werkzeugunterstützung Produktivität und Validität verbessert bzw. gesichert werden (z.B. durch Code-Generatoren und durch Generierung von Testdaten). Methodik, Methode und Werkzeug Zur richtigen Einordnung und Beurteilung der Werkzeugunterstützung 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 von IuK-Projekten (vgl. Lerneinheit ZAMIP) wird der Begriff Methodik (auch: Methodologie) verwendet, worunter die Lehre von den Methoden und ihre planmäßige wissenschaftliche Anwendung verstanden wird. Davon ausgehend werden Methodik-Ansätze erläutert, die für IuK-Projekte typisch sind. Sie beschreiben in ihrer Gesamtheit die planmäßige, wissenschaftliche Anwendung von Methoden

232

Planungsmethoden

zur Lösung der Projektaufgabe. Daraus folgt, daß die Methodik festgelegt sein muß, bevor Methoden gesucht, entwickelt und angewendet werden können. M e t h o d e n sind konkrete Handlungsvorschriften, die auf einem System von Regeln aufbauen und deren Zweck es ist, das Lösen eines Problems zu unterstützen oder erst zu ermöglichen. Um eine bestimmte Methodik 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 Projektaufgabe 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 unterstützen, werden als W e r k z e u g e 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 C A S E - W e r k z e u g (genauer gesagt: Upper CASE) wird dann gesprochen, wenn das Werkzeug PC-basiert und grafikorientiert ist und den frühen Projektphasen dient. Werkzeuge, die nur die Programmierung unterstützen (Programmierwerkzeuge), werden im allgemeinen nicht unter CASE-Werkzeuge subsumiert (oder ausdrücklich als Lower CASE bezeichnet). CASE-Werkzeuge 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 Projektaufgabe in Phasen und deren Teilaufgaben. Durch präzise Beschreibung der Aktivitäten sowie ihrer Voraussetzungen und Ergebnisse in allen Phasen entsteht ein Vorgehensmodell. Jede Aktivität eines Vorgehensmodells unterliegt grundsätzlich der Validierung und der Verifizierung. Viele Anwender verfügen über "ihr eigenes" Vorgehensmodell (vgl. das Beispiel in Lerneinheit VORMO). 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 verwendbar sein. Sie müssen daher gewissermaßen in unterschiedliche Vorgehensmodelle eingeklinkt werden können. Idealerweise müßte der Anwender die Mög-

WERIP - Werkzeugunterstützung

bei

luK-Projekten

233

lichkeit haben, beliebige Methoden und Werkzeuge in sein Vorgehensmodell einzuklinken; dies setzt genormte Schnittstellen in den Vorgehensmodellen voraus, die es 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 A D P S verwendet werden). Vorgehensmodelle können vereinfacht werden, indem sie (nur) auf bestimmte Projektaufgaben ausgerichtet sind. Ein Vorgehensmodell, das (nur) für IuK-Projekte verwendet wird, bei denen es um die Veränderung bestehender SoftwareSysteme 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 T e i l a u f g a b e n 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 Eingriffe des Benutzers) neue Daten hinzugefügt wurden. • Darstellende Werkzeuge bringen ein bereits vorliegendes Resultat in eine andere Form (z.B. DRUCKEN, DISPLAY, D U R C H B L Ä T T E R N ) . 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, A U S L A G E R N , UMSPEICHERN). Der semantische Gehalt der Resultate bleibt erhalten. 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

234

Planungsmethoden

zur Kostenplanung und Kostenkontrolle, der Systemplaner verwendet 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 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, Codes, 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. 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

WERIP - Werkzeugunterstiitzung

• •

•

•

bei luK-Projekten

235

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. Die 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. W E R I P - 1 : Hardware-Architektur von CASE-Systemen

Abbildung WERIP-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 (sog. Front-End-Werkzeuge), auf dem Server die Werkzeuge für die Generierung von Code, Masken und Datenbank sowie 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 auto-

236

Planungsmethoden

matisch 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 R e f e r e n z m o d e l l , das die Architektur von C A S E Systemen 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. 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),

WERIP - Werkzeugunterstützung

bei luK-Projeklen

Tbl

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 P r o j e k t b i b l i o t h e k 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 Fall spricht man von integrierten, im zweiten Fall von verbundenen CASE-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 des Arbeitsprozesses und Validität der Arbeitsergebnisse zu verbessern. Aus Erfahrungsberichten und Befragungen können die folgenden Schlüsse über Auswirkungen der Werkzeugunterstützung gezogen werden: • bessere methodische Unterstützung in allen Projektphasen 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 klare Strukturierung des Projekts und Festlegung der dazu notwendigen Schnittstellen und Verantwortlichkeiten (für alle Projektmitarbeiter überschaubar);

238

Planungsmethoden

• 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 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 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 folgende 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; • Technologie-Investition muß durch das Management nachhaltig unterstützt werden; • Erfahrung im Umgang mit der Werkzeugunterstützung muß mit Pilotprojekten gesammelt werden (Lernkurve); • Rückfragen müssen durch den Hersteller/Anbieter schnell geklärt werden (Hot-Line). Als Schulungsaufwand für die Einarbeitung werden ein bis zwei Wochen angegeben. Die Schulung sollte beim Anwender erfolgen und alle potentiellen Benutzer einbeziehen. 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;

WERIP - Werkzeugunterstützung

bei IuK-Projekten

239

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/W orkstations Zentralrcchner Planungskomponente Analysekomponente Designkomponente

Kernsystem

i/1

I

lokale Enzyklopädie Kernsystem

Zentrales Kernsystem

zentrale Enzyklopädie offene Schnitt stelle

MaskenGenerator CodeGenerator

TTi

« oS

andere Generatoren Werkzeuge,

DatenbankGenerator

Abb. WERIP-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. Die Architektur von IEF zeigt Abbildung WERIP-2. In der auf dem Großrechner geführten Entwicklungsdatenbank werden alle Projektdaten verwaltet. Die Enzyklopädie ist als DB2-Datenbank implementiert. 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 die Ä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, Datenmodell,

240

Planungsmethoden

Funktionsdiagramm); • Analysekomponente für die Darstellung der Systemanforderungen (u. a. E/R-Diagramm, Procedure-Action-Diagramm, Hierarchie-Digramm, Konsistenzprüfung); • Designkomponente für die Detailspezifikation der Systemlösung (u.a. Dialogflußdiagramm, Bildschirmentwurf, 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 den 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 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.

WERIP - Werkzeugunterstützung

bei

IuK-Projekten

241

Kontrollfragen 1. 2. 3. 4. 5.

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

Quellenliteratur Balzert, H.: CASE. Systeme und Werkzeuge. 4. A., BI Wissenschaftsverlag, Mannheim et al. 1992 Chroust, G.: Modelle der Software-Entwicklung. Oldenbourg, München/Wien 1992 Vertiefungsliteratur Bertram, H. et al.: CASE in der Praxis. Softwareentwicklungsumgebungen für Informationssysteme. Springer, Berlin et al. 1993 Hausen, H.-L. et al.: Software-Produktionsumgebungen. Müller, Köln-Braunsfeld 1985 Jones, K. (Butler Cox): The lack of benefits realised through CASE. Handouts, Conference "CASE - Der Weg ist ein Ziel", März 1992 Österle, H. (Hrsg.): Anleitung zu einer praxisorientierten Software-Entwicklungsumgebung. Bd. 1, Erfolgsfaktoren werkzeugunterstützter Software-Entwicklung. AIT, Halbergmoos 1988 Informationsmaterial Nomina Information Services (Hrsg.): ISIS Software Report und ISIS Personal Computer Report, jeweils aktuelle Auflage

Beschreibungsmethoden Durchsatzzeit 100 Anpassungsfähigkeit 100

Funktionalität 100

100 Kosten

A k z e p t a n z 100

O

Produkt 1

•

Produkt 2

100 Benutzbarkeit

Dokumentation

100 Systembelastung

244

Beschreibungsmethoden

Mit dem Kapitel Beschreibungsmethoden sollen folgende Lernziele erreicht werden: ERFAS - Erfassungsmethoden Sie können einen Überblick über die Methoden geben, mit denen Istzustände von Systemen erfaßt werden. Sie können den Zweck jeder dieser Methoden nennen und ihre Konzeption erläutern. Sie kennen die Gemeinsamkeiten und Unterschiede der Methoden und sind in der Lage, für ein konkretes Projekt geeignete Methoden auszuwählen und anzuwenden. DARST - Darstellungstechniken Sie kennen die formalen Unterscheidungskriterien der Darstellungstechniken und können deren Verwendung im Projektmanagement beurteilen. Sie kennen Darstellungstechniken der Aufbauorganisation und der Ablauforganisation. Sie sind in der Lage, typischen Sachverhalten von IuK-Projekten geeignete Darstellungstechniken zuzuordnen. Sie erkennen die Bedeutung der Verwendung von grafischen Hilfsmitteln und von standardisierten oder genormten Symbolen. ENTAB - Entscheidungstabellen-Technik Sie kennen den Zweck der Entscheidungstabellen-Technik und ihre Verwendung in IuK-Projekten, die Syntax der Entscheidungstabellen und die verschiedenen Arten von Entscheidungstabellen. Sie können Entscheidungstabellen aufbauen und diese auf Eindeutigkeit (Vollständigkeit und Redundanz) und Widersprüchlichkeit prüfen. Sie können Entscheidungstabellen konsolidieren und zerlegen. Sie kennen Weiterentwicklungen der Entscheidungstabellen-Technik und deren Verwendbarkeit beim Knowledge Engineering. DOKUM - Dokumentationsmethoden Sie kennen den Zweck und die Objekte der Dokumentation. Sie können die Anforderungen an die Dokumentation erläutern und daraus Qualitätskriterien ableiten. Sie können die Zweckmäßigkeit der verschiedenen Zeitpunkte, zu denen im Projektverlauf dokumentiert werden kann, beurteilen. Sie kennen die organisatorischen Voraussetzungen, die zur Erstellung der Dokumentation erfüllt sein müssen, und für das Dokumentieren verfügbare Methoden, Techniken und Werkzeuge. PRAET - Präsentationstechniken Sie kennen den Zweck der Präsentationstechniken und ihre Anwendungsgebiete beim Projektmanagement. Sie kennen wichtige Prinzipien zur Gestaltung von Kommunikationsmitteln, die in Präsentationstechniken verwendet werden, sowie Prinzipien zur Gestaltung von Vorträgen. Sie können die Gestaltungsprinzipien anwenden, um Projektergebnisse prägnant zu kommunizieren.

ERFAS - Erfassungsmethoden Lernziele Sie können einen Überblick über die Methoden geben, mit denen Istzustände von Systemen erfaßt werden. Sie können den Zweck jeder dieser Methoden nennen und ihre Konzeption erläutern. Sie kennen die Gemeinsamkeiten u n d Unterschiede der Methoden und sind in der Lage, für ein konkretes Projekt geeignete Methoden auszuwählen und anzuwenden. D e f i n i t i o n e n und

Abkürzungen

aktive B e o b a c h t u n g (active Observation) = eine Beobachtung, die während der Mitwirkung des Beobachters bei der Aufgabendurchführung erfolgt; im Gegensatz dazu: passive Beobachtung. B e f r a g u n g (questioning) = ein zielgerichteter, sozialer Vorgang der Interaktion zwischen Individuen (Frager und Befragter) zur Erhebung von Daten in einem bestimmten Kontext. 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 B e o b a c h t u n g (direct Observation) = eine Beobachtung, die durch den Beobachter persönlich und nicht durch ein Sachmittel erfolgt; im Gegensatz dazu: indirekte Beobachtung, 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. M M H = Akronym für Multimoment-Häufigkeits-Zählverfahren. M M Z = Akronym für Multimoment-Zeitmeßverfahren. o f f e n e B e o b a c h t u n g (open Observation) = eine Beobachtung, die für den Beobachteten erkennbar ist; im Gegensatz dazu: verdeckte Beobachtung, o f f e n e Frage (open question) = eine Frage, deren Antwortmöglichkeiten nicht vorgegeben sind; im Gegensatz dazu: geschlossene Frage. Synonym: nicht standardisierte Frage. S e l b s t a u f s c h r e i b u n g (self-recording) = die Erstellung von Arbeitsberichten durch die Aufgabenträger, s t a n d a r d i s i e r t e Frage (standardized question) = eine Frage, deren Antwortm ö g l i c h k e i t e n vorgegeben sind; im Gegensatz dazu: nicht standardisierte Frage. Synonym: geschlossene Frage. S t i c h p r o b e (sample) = der Teil einer Grundgesamtheit, der nach einem bestimmten Auswahlverfahren festgelegt wird, meist nach dem der Zufälligkeit, strukturierte B e o b a c h t u n g (struetured Observation) = eine Beobachtung, die nach einem System festgelegter Beobachtungskriterien erfolgt; im Gegensatz dazu: unstrukturierte Beobachtung. V i d e o b e o b a c h t u n g (video Observation) = eine indirekte und passive Beobachtung, welche die Videokamera (mit Mikrofon) als Sachmittel verwendet.

246

Beschreibungsmethoden

Zweck der

Erfassungsmethoden

Zweck der Erfassungsmethoden ist es, die Durchführung der Istzustandserfassung (vgl. Lerneinheit ZAMFS) zu unterstützen. Dem dualen Charakter der Feinstudie entsprechend, müssen die Methoden der Istzustandserfassung in der Lage sein, sowohl die vorgegebene Arbeitssituation, als auch die wahrgenommene Arbeitssituation zu erkennen. Die Befragung als Methode der Istzustandserfassung ist daher in der Regel unverzichtbar. Dem interaktiven Charakter der Feinstudie entsprechend, sollen die Erfassungsmethoden auch in der Lage sein, möglichst interaktiv mit der Erfassung einzelner Phänomene auch die Analyse dieser Phänomene durchzuführen. Abbildung ERFAS-1 nennt die verfügbaren Erfassungsmethoden. Zu den einzelnen Methoden gibt es verschiedene Varianten. Die Methoden, einschließlich der Varianten, sind kombinierbar; sie schließen sich nicht gegenseitig aus. 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. ERFAS-1: Überblick Erfassungsmethoden

Jede Methode ist unter anderem dadurch gekennzeichnet, daß sie (nur) eine bestimmte Sicht auf die Wirklichkeit ermöglicht und damit (nur) einen Ausschnitt der Wirklichkeit erfaßt. So kann mit einem Interview erhoben werden, 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 (sog. Verhaltensbeobachtung) erhoben werden. Die Beobachtung trägt aber nicht dazu bei, Erkenntnisse über die wahrgenommene Arbeitssituation zu gewinnen. Zweck der Methoden der Zeiterfassung ist es, die Ermittlung des Z e i t b e d a r f s für die Durchführung der betrieblichen Aufgaben 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ätigkeitenkatalog. Informationen über den Zeitbedarf der Aufgaben ermöglichen die Herausarbeitung von Stärken und Schwächen des Istzustands in bezug auf die zeitliche

ERFAS - Erfassungsmethoden

247

Dimension der Aufgabendurchführung. Mit diesen Informationen kann auch eine Konkretisierung der Wirtschaftlichkeitsanalyse erfolgen, wenn die Reduzierung des Zeitbedarfs ein Planungsziel ist (vgl. Lerneinheiten Z I E L P und WIRTA). Interview Ein Interview ist die mündliche Befragung von Aufgabenträgern, die kompetente Auskunftspersonen zur Deckung des Informationsbedarfs (Attribute und Attributewerte) sind. Nach der Art der im Interview verwendeten Fragen werden verschiedene Interviewformen unterschieden: • Interview mit standardisierten, halb standardisierten oder nicht standardisierten Fragen; • Interview mit harten oder weichen Fragen; • Interview mit direkten oder indirekten Fragen. Welche Interviewform verwendet 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 G r u p p e n i n t e r v i e w unterschieden. Eine Sonderform des Gruppeninterviews ist die 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 , bei der Aufgabenträger verschiedener Hierachie-Ebenen, 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 * Festlegen des Informationsbedarfs * 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 Attributewerte auf Fehler * Ergebnisprotokollierung: Dokumentieren der Interviewergebnisse Folgende Prinzipien sollen beim Durchführen eines Interviews beachtet werden:

248

Beschreibungsmethoden

• Offene Fragen 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. • 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 Beobachtung ist die Deckung des Informationsbedarfs durch sinnliche Wahrnehmungen der Beobachter im Untersuchungsbereich, ohne Beteiligung des beobachteten Aufgabenträgers. Nach den folgenden Kriterien werden folgende 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 verwendet 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. Beobachtungsformen mit diesen Merkmalen 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.

ERFAS - Erfassungsmethoden

249

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 zum Tragen (vgl. Lerneinheit INTER). Nachteile der Beobachtung sind der hohe Zeitaufwand (sowohl für die benötigte gründliche 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 und Sachmitteln, 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; er ist das Arbeitsmittel für die schriftliche Befragung. Folgende Fragebogenformen werden unterschieden: • Individualfragebogen oder Gruppenfragebogen; • Fragebogen mit standardisierten, halb standardisierten oder nicht standardisierten Fragen. Ein I n d i v i d u a l f r a g e b o g e n wird von einzelnen Befragten und für einzelne Aufgabenträger beantwortet, während ein G r u p p e n f r a g e b o g e n 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 Projektbearbeiter 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

250

Beschreibungsmethoden

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; Auswerten der erfaßten Daten.

Vorteile der Selbstaufschreibung sind die Möglichkeit der Totalaufnahme und die Entlastung der Systemplaner. 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. weiter unten). 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. 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 A u f g a b e n a n a l y s e "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 ERFAS-2; sie sind überschneidungsfrei. Das bedeutet, daß durch Zerlegung nach einem Gliederungsmerkmal die anderen Gliederungsmerkmale nicht berührt werden. 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 gliedert 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.

ERFAS - Erfassungsmethoden

251

Abb. ERFAS-2: Gliederungsmerkmale für die Aufgabenanalyse

Zeiterfassung Für die Erfassung des Zeitbedarfs gibt es im wesentlichen folgende Methoden: • Selbstaufschreibung auf der Grundlage eines Tätigkeitenkatalogs (Zeiterfassung mit Arbeitstagebüchern); • Schätzen auf der Grundlage eines Tätigkeitenkatalogs (Zeiterfassung mit Tätigkeitsberichten); • Zählen (Multimoment-Häufigkeits-Zeitverfahren und MultimomentZeitmeßverfahren); • automatisches Ermitteln durch Zeitmeßgeräte, die in Arbeitsmittel eingebaut sind; • Berechnen auf der Grundlage von technologischen Daten (z.B. Systeme vorbestimmter Zeiten); • Messen durch Zeitnehmer mit Zeitmeßgeräten (Zeitmessung); • 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 Befragung wurde bereits weiter oben behandelt. Auf Zeitmeßgeräte und Systeme vorbestimmter Zeiten wird nicht eingegangen. Arbeitstagebücher 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 über die verwendete Benummerung der Tätigkeiten den untersuchten Aufgaben zum Ermitteln des Zeitbedarfs zugeordnet. Abbildung ERFAS-3 zeigt die Struktur des Arbeitstagebuchs.

252

Beschreibungsmethoden

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üchern 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. Tätigkeiten * Nummer/Bezeichnung

Beginn-Uhrzeit

Ende-Uhrzeit

Tätigkeitsdauer

Tätigkeitskatalog Abb. ERFAS-3: Struktur Arbeitstagebuch

Tätigkeitsberichte 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 ERFAS-4 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ätigkeitenkatalog 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. • 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 Abweichun-

ERFAS - Erfassungsmethoden

253

gen geht man wieder auf die Maßstabtätigkeit zurück und durchläuft die Arbeitsschritte sooft, bis das Gesamtergebnis plausibel ist. 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 nicht korrekter Durchführung der Zeiterfassung (z.B. wegen eines unvollständigen Tätigkeitenkatalogs) wird keine ausreichende Genauigkeit erreicht (die Abweichung von der mittleren Genauigkeit der Zeitmessung liegt im ungünstigsten Fall bei +/- 100%). Tätigkeiten * Nummer/Bezeichnung

Zeitaufwand je Verrichtung

Häufigkeit der Verrichtung

Tätigkeitsdauer

* nach Tätigkeitskatalog Abb. ERFAS-4: Struktur Tätigkeitsbericht

Multimomentstudie 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 MMZ 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. Verglichen 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.

254

Beschreibungsmethoden

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 n o t w e n d i g e n Vorarbeiten sind umfangreich. Die Datenauswertung ist zumindest dann a u f w e n dig, wenn kein geeignetes Werkzeug zur Verfügung steht. Bei einer geforderten h o h e n Ergebnisgenauigkeit ist die Zeitdauer für die D u r c h f ü h r u n g einer Multimomentstudie vergleichsweise lang. Im folgenden wird das Prinzip einer M u l t i m o m e n t s t u d i e durch Gegenüberstellung einer üblichen Zeitmessung mit einer M M H 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 ni, i\2 und n3 mit den entsprechenden Zeitarten ti (z.B. Hauptzeit), t2 (z.B. Nebenzeit) und t3 (z.B. Verteilzeit) durchgeführt (vgl. Abbildung ERFAS-5). Arbeitszeit

Beginn der Rundgänge

Z e i t m e s s u n g (in % )

08h

t l

5t -,

w.

5 0 , 0 3 7 , 5 12,5 6 5 , 0 18,3

©

70,8 20,9

8,3

62,5 33.3

4,2

68.3 28.4 ©

S

4,2

5 8 . 4 3 0 , 8 10,8

tT

50?

12,5

6 6 , 7 20,8 12,5 4 1 , 7 4 3 , 3 15,0

60 i n c u o i H

K j r < P 7 f ^ t

O

**

•

D> >

^

[> [ >

a

y v ^

^

o

01 Abb. P R A E T - 5 : Beispiele f ü r Leseleitzeichen

Forschungsbefunde Befunde empirischer Untersuchungen zeigen, daß Bilder Anreize zur Informationsrezeption schaffen und die Informationsspeicherung nachhaltig unterstützen: • Werden identische Sachverhalte alternativ als Bilder und als Text kommuniziert, setzt sich der Empfänger deutlich länger mit den Bildern auseinander. • Bilder können emotionale Wirkungen hervorrufen; sie sind geeignet, eine fiktive Wirklichkeit zu vermitteln. • Bilder wirken stark informationskomprimierend. • Bilder ermöglichen eher ein unmittelbares Erleben im Kommunikationsprozeß als andere Informationsarten; sie erhöhen damit das Erinnerungsvermögen. Ton- und Sprachunterstützung tragen dazu bei, die Aufmerksamkeit auf ein Bild zu lenken, die Auseinandersetzung damit zu fördern, die gedankliche Verarbeitung und Speicherung der Bildinformation zu beeinflussen sowie Mehrdeutigkeiten einzuschränken. Nicht zuletzt wird durch multimediale Präsentation für den Empfänger ein positives Ambiente erzeugt. Kontrollfragen 1. 2. 3. 4. 5.

W e l c h e r U n t e r s c h i e d besteht z w i s c h e n Botschaft, Nachricht und I n f o r m a t i o n ? W a s besagt das Prinzip der Partnerbezogenheit? W e l c h e Gestaltungsprinzipien gelten für die Planung u n d D u r c h f ü h r u n g eines V o r t r a g s ? W a s wird u n t e r demokratischer u n d was unter hierarchischer Rollenverteilung verstanden? W e l c h e F a r b e n lösen welche Assoziationen aus?

Quellenliteratur B e r n s t e i n , D.: D i e K u n s t d e r Präsentation. 2. A., C a m p u s , F r a n k f u r t / N e w Y o r k 1992 B i s c h o f f , U. et al.: S c h a u b i l d e r als F ü h r u n g s i n s t r u m e n t . T e c h n i k u n d M e t h o d i k visueller K o m m u n i k a t i o n s h i l f e n . M o d e r n e Industrie, M ü n c h e n 1971

PRAET - Präsentationstechniken

297

Issing, L. J./Klimsa, P.: Information und Lernen mit Multimedia. Beltz Psychologie Union, Weinheim 1995 Klimsa, P.: Multimedia. Anwendungen, Tools und Techniken. Rowohlt. Reinbek bei Hamburg 1995 Kulich, C.: Erfolgreich präsentieren: Vorschläge, Ideen, Konzeptionen. Expert, Ehningen 1991 Mandel, S.: Präsentationen erfolgreich gestalten: bewährte Techniken zur Steigerung ihrer Selbstsicherheit, Motivationsfähigkeit und Überzeugungskraft. Überreuter, Wien 1991 Wohlleben, H.-D.: Techniken der Präsentation. 5. A., Schmidt, Gießen 1994

Analysemethoden

300

Analysemethoden

Mit dem Kapitel Analysemethoden sollen folgende Lernziele erreicht werden: WIRTA - Wirtschaftlichkeitsanalyse Sie kennen den Zweck von Wirtschaftlichkeitsanalysen bei IuK-Projekten. Sie können Kosten und Nutzen in Kostenarten und Nutzenarten zerlegen. Sie wissen, wie bei der Analyse der Kostenstruktur und der Analyse der Nutzenstruktur sowie bei der Analyse der Beziehungszusammenhänge zwischen Kosten und Nutzen vorgegangen wird. Sie kennen den Unterschied zwischen Wirtschaftlichkeitsrechnungen und Wirtschaftlichkeitsanalysen. NUTZW - Nutzwertanalyse 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. WERTA - Wertanalyse Sie kennen den Zweck der Wertanalyse und erkennen ihre Bedeutung für die Abwicklung von IuK-Projekten. Sie können die Vorgehensweise bei der Wertanalyse in Phasen und Arbeitsschritte gliedern. Sie erkennen die zentrale Bedeutung der Funktionsanalyse für die Wertanalyse und können Hauptfunktionen von Nebenfunktionen unterscheiden. Sie sind in der Lage, die Wertanalyse auf IuKProjekte und Produkte von IuK-Projekten anzuwenden. MATRX • Matrixanalyse Sie kennen die Struktur von Matrizen, können Matrizen aufbauen, die Beziehungen zwischen den Elementen zweier Mengen darstellen und interpretieren. Sie kennen eine Vorgehensweise bei der Anwendung der Matrixanalyse. Sie kennen wichtige Operationen des Matrizenkalküls, mit denen die Matrixanalyse erweitert werden kann. Sie können die Anwendung der Matrixanalyse erläutern und die Matrixanalyse auf typische Aufgaben von IuK-Projekten anwenden. INTER - Interaktionsanalyse Sie kennen den Zweck der Interaktionsanalyse. Sie wissen, warum die Befragung als Erhebungstechnik nicht ausreicht und wie die Interaktionsanalyse in andere Formen der Beobachtung und der Analyse des Beobachteten eingebettet ist. Sie kennen die Videobeobachtung als Methode der Datenerhebung für die Interaktionsanalyse. Sie wissen, wie videobasiertes Material in Review Sessions und im Interaktionsanalyse-Labor analysiert werden kann. Sie können die Brauchbarkeit der videobasierten Interaktionsanalyse für die Projektarbeit beurteilen. KOMAN - Kommunikationsanalyse Sie kennen die Methoden der Kommunikationsanalyse. Sie können den Zweck jeder dieser Methoden nennen und ihre Konzeption erläutern. Sie können in einer konkreten Analysesituation durch Abwägen der Vorteile und der Nachteile der Methoden eine optimale Kombination von Methoden der Kommunikationsanalyse bilden und bei der Projektarbeit anwenden.

WIRTA - Wirtschaftlichkeitsanalyse Lernziele Sie kennen den Zweck von Wirtschaftlichkeitsanalysen bei IuK-Projekten. Sie können Kosten und Nutzen in Kostenarten und Nutzenarten zerlegen. Sie wissen, wie bei der Analyse der Kostenstruktur und der Analyse der Nutzenstruktur sowie bei der Analyse der Beziehungszusammenhänge zwischen Kosten und Nutzen vorgegangen wird. Sie kennen den Unterschied zwischen Wirtschaftlichkeitsrechnungen und Wirtschaftlichkeitsanalysen. Definitionen und Abkürzungen Analyse (analysis) = die möglichst exakte Bestimmung und Charakterisierung von Teilen eines Ganzen sowie der Beziehungen, welche die Teile untereinander und zum Ganzen haben, mit dem Zweck, das Ganze zu erklären. 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. Kennzahl (ratio) = eine Zahl über Daten mit konzentrierter Aussagekraft zur Diagnose, Planung, Überwachung und Steuerung eines Systems; meist werden Verhältniszahlen verwendet. Kosten (costs) = die mit Geldeinheiten bewerteten Konsequenzen einer Leistung bezüglich ihres Verzehrs an Gütern und/oder Diensten. Kosten/Nutzen-Analyse (cost/value analysis) = eine Variante der Nutzwertanalyse, bei der die Kosten der Handlungsalternativen zunächst nicht in das Zielsystem aufgenommen werden; nach der Ermittlung des Nutzwerts wird dieser mit dem Kostenwert in Beziehung gesetzt. Kostenart (cost item) = das Ergebnis der Zerlegung von Kosten nach der Art des Verzehrs an Gütern und/oder Diensten. Lebenszyklus (life cycle) = eine bestimmte, in sich abgeschlossene Phase der Lebensdauer eines Produkts, aus der es keine Rückkehr in eine frühere Phase gibt (analog dem Lebenszyklus von Menschen). Leistung (performance) = die Fähigkeit eines Techniksystems, in quantitativer oder qualitativer Hinsicht eine bestimmte Aufgabe im Informations- und Kommunikationsprozeß zu bewältigen. Nutzen (benefit) = der subjektiv beeinflußte Wert einer Handlungsalternative zur Befriedigung eines definierten Bedarfs. Synonym: Nutzwert. OR = Akronym für Operations Research; die Anwendung von mathematischen Methoden zur Vorbereitung und Herbeiführung optimaler Entscheidungen. Synonym: Unternehmensforschung. Produktivität (productivity) = das Verhältnis zwischen dem mengenmäßigen Ertrag und dem mengenmäßigen Einsatz zur Erbringung dieses Ertrags. Prognose (forecast) = die Voraussage einer zukünftigen Entwicklung oder eines zukünftigen Zustands auf der Grundlage systematisch ermittelter Daten und der Verwendung wissenschaftlicher Erkenntnisse. Wirksamkeit (effectiveness) = die Eigenschaft eines Systems, Funktionen und Leistungen, unabhängig von dem damit verbundenen Nutzen, verfügbar zu machen. Synonym: Effektivität.

302

Analysemethoden

Zweck der Wirtschaftlichkeitsanalyse Zweck der Wirtschaftlichkeitsanalyse ist es, Systeme oder Systementwürfe, aber auch die Entwicklung und/oder den Einsatz von Methoden und Werkzeugen, unter dem Formalziel Wirtschaftlichkeit zu beurteilen. Unter Wirtschaftlichkeit wird im allgemeinen die Eigenschaft des betrachteten Objekts verstanden, bezüglich einer geplanten oder tatsächlichen Kostensituation in einem bestimmten Verhältnis zu einer Bezugsgröße (z.B. der günstigsten Kostensituation) oder bezüglich seiner Leistungssituation (Nutzwert) in einem bestimmten Verhältnis zu einer Bezugsgröße (z.B. dem mit Kosten bewerteten Einsatz an Produktionsfaktoren zur Erbringung der Leistungen) zu stehen. Das Ergebnis eines IuK-Projekts ist dann wirtschaftlich, wenn die Kosten der Entwicklung und Einführung (Planungskosten) zuzüglich der Kosten der Nutzung (Betriebskosten) und der späteren Änderungen (Wartungskosten), bezogen auf den geplanten Einsatzzeitraum, unter dem zu erwartenden Nutzen liegen. Der Nutzungszeitraum wird häufig als Lebenszyklus bezeichnet, weil er mehrere unterschiedliche "Lebensphasen" umfaßt (vgl. Lerneinheit LEMAN im Bd. "Informationsmanagement"). Lebenszykluskosten sind die für den ganzen Lebenszyklus prognostizierten Kosten. Werden sie durch die Anzahl Nutzungsjahre dividiert, wird von jährlichen Lebenszykluskosten gesprochen. Das Ergebnis eines IuK-Projekts ist nach dieser Terminologie dann wirtschaftlich, wenn seine Lebenszykluskosten unter dem erwarteten Nutzen für den gesamten Lebenszyklus liegen. Beim Vergleich nutzengleicher Alternativen gilt: Es ist die Alternative optimal, deren Lebenszykluskosten kleiner als die der anderen Alternativen sind. Für die Bewertung der Leistungssituation ist zu berücksichtigen, daß Leistungen nur teilweise quantitativ erfaßt werden können; viele Leistungen sind nur qualitativ erfaßbar und häufig das Resultat subjektiver Schätzung. Deshalb ist es erforderlich, neben der üblichen Wirtschaftlichkeitsanalyse eine umfassende Bewertung der Kosten- und Leistungssituation durchzuführen (z.B. mit einer Nutzwertanalyse, vgl. Lerneinheit NUTZW). Dabei wird für alle definierten Projektziele (vgl. Lerneinheit ZIELP) das Ausmaß der Zielerreichung ermittelt und über das gesamte Zielsystem der Nutzwert bestimmt. Die Ergebnisse der Wirtschaftlichkeitsanalyse gehen als Ausmaß der Zielerreichung für das Projektziel Wirtschaftlichkeit in die Nutzwertanalyse ein. Eine Wirtschaftlichkeitsanalyse für ein IuK-Projekt kann erst durchgeführt werden, wenn die Grundkonzeption (vgl. Lerneinheit ZAMVS) und die wichtigsten Projekt-Teilplanungen (z.B. die Aufgabenplanung, die Personalplanung, die Sachmittelplanung, die Terminplanung und insbes. die Kostenplanung) vorliegen. Die Projekt-Teilplanungen (vgl. Lerneinheit PROPL) schaffen die Voraussetzung für die Ermittlung der Planungskosten. Die Grundkonzeption bestimmt mit ihrem sachlichen Lösungsvorschlag die voraussichtlichen Kosten der Nutzung (Betriebskosten) und Weiterentwicklung (Wartungskosten) sowie mit den geplanten Funktionen und Leistungen den Nutzen des geplanten IuK-Systems. Die Analyse der Wirtschaftlichkeit erfordert Prognosen und ist daher mit Unsicherheit behaftet. Je später ein Kostenfaktor oder ein Nutzenfaktor in der Zukunft wirksam wird, desto unsicherer ist die Aussage, die zum gegenwärtigen

WIRTA - Wirtschaftlichkeitsanalyse

303

Zeitpunkt über seine tatsächliche Höhe gemacht werden kann. Kostenprognosen sind grundsätzlich sicherer als Nutzenprognosen, und Planungskosten sind grundsätzlich genauer prognostizierbar als die erst nach der Installierung entstehenden Betriebskosten und Wartungskosten. Aus diesem Grund und wegen der Verfeinerung der Systemkomponenten im Verlauf des Planungsprozesses muß die Wirtschaftlichkeitsanalyse in den einzelnen Projektphasen (z.B. an den Meilensteinen, vgl. Lerneinheit PROPL) überprüft, korrigiert, vertieft und schließlich, nach der Installierung, verifiziert werden. Damit sollen sowohl eine willkürliche Verwendung der Wirtschaftlichkeitsanalyse (z.B. "Abwürgen" des Projekts) als auch eine Verwendung, die sich nur am Projektnotstand orientiert (z.B. zum Nachweis der weiterhin bestehenden Wirtschaftlichkeit), vermieden werden.

Abb. W I R T A - 1 : Methoden zur Beurteilung der Wirtschaftlichkeit

Wirtschaftlichkeitsanalyse vs.

Wirtschaftlichkeitsrechnung

Die Wirtschaftlichkeitsanalyse umfaßt im weiteren Sinn auch die Methoden der Wirtschaftlichkeitsrechnung (vgl. Abbildung WIRTA-1). Auf diese Methoden wird weiter unten bzw. in eigenen Lerneinheiten (insbes. Lerneinheiten NUTZW und SIMUL) eingegangen. Im wörtlichen und eigentlichen Sinn heißt Wirtschaftlichkeitsanalyse folgendes: • Analyse der Kostenstruktur, • Analyse der Nutzenstruktur und • Analyse der Beziehungszusammenhänge zwischen Kosten und Nutzen. Die Betonung liegt auf Analyse der Wirtschaftlichkeit, nicht auf Ermittlung einzelner Indikatoren für Wirtschaftlichkeit (wie z.B. die Amortisationsdauer). Auf die drei Teilanalysen der so verstandenen Wirtschaftlichkeitsanalyse wird im folgenden eingegangen. Anschließend werden die Verfahren der Wirtschaftlichkeitsrechnung dargestellt. Entscheidende Schwäche dieser Verfahren ist, daß nur

304

Analysemethoden

monetäre Größen verwendet und qualitative Wirkungen nicht berücksichtigt werden. Für eine umfassende Beurteilung der Wirtschaftlichkeit ist es zweckmäßig, Verfahren zu verwenden, die mehrere Einzelansätze kombinieren. Ein Wirtschaftlichkeitsmodell, das einen Stufenansatz oder Ebenenansatz verwendet, kann dazu als Rahmenkonzept dienen. Neben der Wirtschaftlichkeitsanalyse und den Wirtschaftlichkeitsrechnungen gibt es eine Reihe weiterer Methoden bzw. Verfahren, die nur der Vollständigkeit halber und ohne Erläuterung erwähnt werden, z.B.: Time Saving/Time Salary Technique; hedonistisches Verfahren; Analyse von Nutzeffekt-Ketten; Analyse von Transaktionskosten; Argumenten-Bilanz. Analyse der Kostenstruktur Kostenstruktur ist die Höhe und Zusammensetzung der Kosten nach Kostenarten, die für die Aufgabe der Planung (Planungskosten), für die Aufgabe der Nutzung oder des Betriebs (Nutzungskosten oder Betriebskosten) und für die Aufgabe der Wartung (Wartungskosten) eines IuK-Systems entstehen. Planungskosten, Betriebskosten und Wartungskosten können wie folgt in Kostenarten gegliedert werden (Mindestgliederung): • Materialkosten (für Formulare, Datenträger, Mikrofilme usw.); • Personalkosten und Personal-Nebenkosten (wie Löhne, Gehälter, Sozialleistungen, Arbeitsplatzkosten); • Hardware-Kosten (wie Mietkosten bzw. Abschreibungen und Wartungskosten); • Software-Kosten (wie Lizenz- und Wartungskosten bei Fremdbezug bzw. Abschreibungen bei Fremdbezug oder Eigenfertigung); • Netzkosten (wie Leitungskosten und Kosten für Transportdienste); • Grundstücks- und Gebäudekosten (wie Pacht, Miete und Instandhaltung); • Fremdkosten (wie Beratungskosten und Kosten für Fremdprogrammierung); • Kosten für Büroausstattung und -gerate. Zweck der Kostenartengliederung ist es, die Kostenarten herauszufinden, bei denen sich Höhe und Zusammensetzung der Kosten im geplanten Zustand (Sollzustand) gegenüber dem Istzustand verändern. Dadurch kann für das geplante IuKSystem eine wesentlich veränderte Kostenstruktur entstehen, die gegenüber dem Istzustand (und/oder einem anderen Vergleichszustand, z.B. dem branchenüblichen oder bestmöglichen) vorteilhaft sein kann. Die Veränderung (Kostenreduzierung und/oder Kostenverschiebung) muß beurteilt werden. Die Untersuchung der Kostenarten wird zweckmäßigerweise in der Reihenfolge ihrer relativen Bedeutung zu den Gesamtkosten vorgenommen (d.h. die mit der relativ größten Bedeutung werden zuerst untersucht). Aussagen über die Kostenstruktur allein können leicht zu Fehlschlüssen führen, da jede einzelne Kostenart auch die Höhe der Gesamtkosten und über die Höhe der Gesamtkosten die relative Bedeutung der anderen Kostenarten bestimmt. Aus der Kostenstruktur allein läßt sich nicht erkennen, ob das Kostenniveau vergleichsweise zu hoch ist; dies kann nur durch Gegenüberstellung der Kosten mit anderen Kennzahlen oder dadurch beurteilt werden, daß die Kosten mit den absoluten Zahlen von Alternativen oder mit Sollgrößen verglichen werden.

WIRTA - Wirtschaftlichkeitsanalyse

305

Bei der Analyse der Kostenstruktur sollten auch die Kosten erfaßt und untersucht werden, die Gemeinkosten sind (Gemeinkosten-Wertanalyse). Analog zur Vorgehensweise bei der Wertanalyse (vgl. Lerneinheit WERTA) werden die Gemeinkosten daraufhin untersucht, ob die sie verursachenden Funktionen für die Erreichung des Zwecks des Untersuchungsobjekts unbedingt erforderlich sind (Hauptfunktionen), nur erforderlich sind (Nebenfunktionen) oder überflüssig sind. Bei der Durchführung der Gemeinkosten-Wertanalyse wird von der These ausgegangen, daß ein bestimmter Teil (z.B. ein Drittel) der die Gemeinkosten verursachenden Funktionen überflüssig ist, sodaß auf sie verzichtet werden kann, ohne die Funktionalität und Leistung des Untersuchungsobjekts zu verringern. Analyse der Nutzenstruktur Zur Beurteilung der Wirtschaftlichkeit ist neben der Analyse der Kostenstruktur die Analyse der Nutzenstruktur erforderlich. Nutzenstruktur ist die Zusammensetzung des Nutzens nach Nutzenarten oder Nutzenfaktoren und deren Ausmaß; es gelten die Aussagen analog, die zur Analyse der Kostenstruktur gemacht wurden. Folgende Nutzenfaktoren werden unterschieden: direkt monetär meßbarer Nutzen, indirekt monetär meßbarer Nutzen und nicht monetär meßbarer Nutzen. • Ein direkt monetär meßbarer Nutzen entsteht durch Kostensenkung (Minderkosten des geplanten IuK-Systems gegenüber dem bestehenden). Technikunterstützung führt zur Kostensenkung, wenn durch geringere Kosten für Techniksysteme höhere Personalkosten, Betriebsmittelkosten und Sachkosten ersetzt werden. Zur Messung des monetären Nutzens werden die Werte der Kostenrechnung des bestehenden IuK-Systems den Kosten des geplanten IuK-Systems gegenübergestellt. • Der indirekt monetär meßbare Nutzen hat zwei Formen. Erstens können durch Technikunterstützung Kosten gesenkt werden (z.B. die Lagerkosten durch Verringerung des Lagerbestands). Zweitens kann durch Produktivitätssteigerung eine zukünftige Kostensteigerung vermieden werden (z.B. durch Marktausdehnung oder durch Sortimentserweiterung). Die Erfassung der indirekt monetär meßbaren Kosten erfolgt über eine Erfassung von Mengen und deren monetäre Bewertung. • Der nicht monetär meßbare Nutzen entsteht durch Veränderungen, wie die Verbesserung der Qualität von Entscheidungen durch besseres Informationsangebot, die Verbesserung der innerbetrieblichen und zwischenbetrieblichen Kommunikation und die Erhöhung der Fachkompetenz der Mitarbeiter. An die Stelle der (direkten oder indirekten) Nutzenmessung tritt eine subjektive Nutzenschätzung. Analyse der Beziehungszusammenhänge Bei der Analyse der Beziehungszusammenhänge zwischen der Kostenstruktur und der Nutzenstruktur handelt es sich um ein globales Verfahren der Gliederung und Aufbereitung der beiden Bezugsgrößen der Wirtschaftlichkeit (also der Kosten und des Nutzens). Dabei werden die einzelnen Kostenarten und die Nutzenarten so miteinander verbunden, daß eine zahlenmäßige Abbildung der Beziehungszusammenhänge zwischen Kosten und Nutzen hergestellt wird. Damit läßt sich der komplexe Zusammenhang zwischen Kosten und Nutzen auf kausale bzw.

306

Analysemethoden

funktionale Einflußgrößen zurückführen. Gefragt wird also danach, welche Nutzenart welche Kostenart(en) verursacht bzw. - umgekehrt betrachtet - welche Kostenart welche Nutzenart(en) erzeugt. Von den Antworten dazu ausgehend wird untersucht, durch welche Veränderungen der Kostenstruktur und/oder der Nutzenstruktur die Wirtschaftlichkeit positiv beeinflußt werden kann, indem Funktionen und/oder Leistungen des Analyseobjekts verändert werden. Dazu sind eine entsprechend feine Kostenstruktur und Nutzenstruktur erforderlich. Wegen der Abhängigkeiten der einzelnen Kostenarten und Nutzenarten voneinander, lassen sich derartige Beziehungszusammenhänge oft nur schwer isolieren und quantifizieren. Dies führt zu der Forderung, die Kostenstruktur und die Nutzenstruktur nicht zu fein zu wählen. Zwischen einer zu feinen Gliederung und einer zu groben Gliederung muß ein Kompromiß gefunden werden. Kennzahlen über Beziehungszusammenhänge, die aus umfassenden Analysen gewonnen werden (z.B. aus Branchenuntersuchungen), lassen im Vergleich mit Plandaten oder mit Daten anderer Alternativen erkennen, wo Schwachstellen bestehen und wo Maßnahmen zur Verbesserung der Wirtschaftlichkeit angesetzt werden müssen (vgl. auch Lerneinheit KENNZ im Bd. "Informationsmanagement"). Wirtschaftlichkeitsrechnungen Nach dem Zeitpunkt der Durchführung werden zwei Formen der Wirtschaftlichkeitsrechnung unterschieden: Planungsrechnungen und Kontrollrechnungen. • Planungsrechnungen errechnen vor der Entscheidung die im Sinn der Zielsetzung günstigste Handlungsalternative; es handelt sich um Soll/SollVergleiche. • Kontrollrechnungen errechnen während und/oder nach Durchführung der Entscheidung, inwieweit die Zielplanung verwirklicht werden konnte; es handelt sich um Soll/Ist-Vergleiche. Für das Projektmanagement sind sowohl Planungsrechnungen als auch Kontrollrechnungen von Bedeutung. Die meisten Methoden der Wirtschaftlichkeitsrechnung sind für einfache, meist monetäre Ziele entwickelt worden. Sie werden nach dem verwendeten mathematischen Modelltyp in zwei Gruppen geordnet, nämlich in Ermittlungsmodelle und quantitative Entscheidungsmodelle (OR-Modelle). Beide Modelltypen werden zur Beantwortung der folgenden Fragen verwendet: • Ist ein geplantes Projekt (unter bestimmten Voraussetzungen) "absolut" vorteilhaft? • Welches von mehreren alternativen Projekten ist (unter bestimmten Voraussetzungen) vorteilhafter? Für dieses muß auch die Forderung nach der absoluten Vorteilhaftigkeit erfüllt sein. Ermittlungsmodelle verwenden entweder statische Methoden oder dynamische Methoden. Der wesentliche Unterschied zwischen den Methoden besteht darin, daß statische Methoden keine zeitlichen Unterschiede im Entstehen der Einzahlungen und Auszahlungen berücksichtigen, während dies bei dynamischen Methoden der Fall ist. Da in der Wirklichkeit Einzahlungen und Auszahlungen zu unterschiedlichen Zeitpunkten stattfinden und da ihr Wert umso höher ist, je früher

WIRTA - Wirtschaftlichkeitsanalyse

307

sie entstehen (vice versa), entsprechen dynamische Methoden eher der Wirklichkeit. Der größeren theoretischen Genauigkeit der dynamischen Methoden steht die leichtere praktische Handhabung der statischen Methoden gegenüber. Dynamische Methoden sind Vermögenswertmethoden und Zinssatzmethoden. • Vermögenswertmethoden sind Methoden zur Ermittlung des Vermögenszuwachses während der Planperiode bei gegebenem Zinssatz. Zu dieser Methodengruppe gehören die Kapitalwertmethode (auch: Vermögensbarwertmethode) und die Vermögensendwertmethode. Die Kapitalwertmethode bezieht die Zahlungen auf den Beginn der Planperiode; für die Finanzmittelaufnahme und -anlage wird ein einheitlicher Zinssatz verwendet. Die Vermögensendwertmethode bezieht die Zahlungen auf das Ende der Planperiode; Aufnahmezinssatz und Anlagezinssatz sind nicht identisch. • Zinssatzmethoden sind Methoden zur Ermittlung eines Zinssatzes bei gegebenem Vermögenszuwachs von Null während der Planperiode. Zu dieser Methodengruppe gehören die Interne-Zinssatz-Methode und die Sollzinssatz-Methode. Die Interne-Zinssatz-Methode bestimmt den Zinssatz aus den Zahlungen; Zinssätze sind nicht vorgegeben. Die Sollzinssatz-Methode bestimmt eine obere Schranke für den Aufnahmezinssatz (Soll) aus den Zahlungen unter Berücksichtigung eines exogenen Habenzinssatzes (Anlagezinssatz). Statische Methoden sind Kostenvergleichsrechnung, Rentabilitätsrechnung und Amortisationsrechnung; manchmal wird auch die Nutzwertanalyse zu dieser Methodengruppe gerechnet (vgl. Lerneinheit NUTZW). • Die Kostenvergleichsrechnung stellt die Kosten der Alternativen einander gegenüber. In den Kostenvergleich werden alle Kostenarten einbezogen, in denen sich die Alternativen unterscheiden. Optimal ist die Alternative mit den geringsten Kosten. • Mit der Rentabilitätsrechnung wird der Durchschnittsgewinn eines Zeitabschnitts (z.B. ein Jahr) zum durchschnittlich gebundenen Kapital in Beziehung gesetzt. Ergebnis ist die Durchschnittsverzinsung des durchschnittlich gebundenen Kapitals (Rentabilität). Optimal ist die Alternative mit der höchsten Rentabilität. • Mit der Amortisationsrechnung wird die Amortisationszeit ermittelt. Sie ist definiert als der Teil des Planungszeitraums, in dem das für ein Investitionsobjekt eingesetzte Kapital aus den Rückflüssen wiedergewonnen werden kann. Optimal ist die Alternative mit der kürzesten Amortisationszeit. Verglichen mit der Wirtschaftlichkeitsanalyse ist die Brauchbarkeit der Investitionsrechnungsmethoden zur Beurteilung der Wirtschaftlichkeit von IuK-Systemen relativ gering. Am besten lassen sich damit um Investitionsbudgets konkurrierende Projekte beurteilen; dies ist aber eher eine Aufgabe des strategischen Informationsmanagements (vgl. Lerneinheit SPLAN im Bd. "Informationsmanagement") als des Projektmanagements. Für eine Reihe von Auswahlproblemen bei IuK-Projekten eignen sich eher die theoretisch wenig anspruchsvollen statischen Methoden der Investitionsrechnung als theoretisch genauere Methoden. Quantitative Entscheidungsmodelle ermitteln die Vorteilhaftigkeit der Alternativen im Hinblick auf ein bestimmtes Ziel. Zu dieser Gruppe gehören analy-

308

Analysemethoden

tische Methoden und Simulationsmethoden (Simulationsmodelle, vgl. Lerneinheit SIMUL). Die Anwendbarkeit analytischer Methoden zur Beurteilung der Wirtschaftlichkeit von IuK-Systemen ist gering, da sich die komplexe Wirklichkeit nicht mit vertretbarem Aufwand in mathematische Modelle abbilden läßt. Wirtschaftlichkeitsmodelle Aufgrund der Tatsache, daß IuK-Projekte zu IuK-Systemen führen können, die nicht nur Veränderungen an einzelnen betrieblichen Funktionen (an bestimmten Arbeitsplätzen und für bestimmte Aufgaben), sondern an ganzen Prozeßketten oder an wesentlichen Teilen davon hervorrufen, muß die Analyse der Wirtschaftlichkeit arbeitsplatz- und abteilungsübergreifend bis unternehmensweit angelegt werden. Zudem muß bedacht werden, daß erfahrungsgemäß die Nutzenpotentiale nicht bei den einzelnen Tätigkeiten der Prozeßkette liegen, sondern zwischen den Tätigkeiten. Zur Lösung dieser Aufgabe werden mehrstufige Wirtschaftlichkeitsmodelle vorgeschlagen. In einem vierstufigen Wirtschaftlichkeitsmodell werden folgende Wirtschaftlichkeitsstufen (oder: Wirtschaftlichkeitsebenen) verwendet (nach R. Reichwald): • W l : Isolierte technikbezogene Wirtschaftlichkeit, mit der die Kosten und der Nutzen erfaßt werden, die unmittelbar der IuK-Technik zuzurechnen sind; • W2: Subsystembezogene Wirtschaftlichkeit, mit der die vom Einsatzkonzept und anderen situativen Bedingungen abhängigen Kosten und der Nutzen im Hinblick auf die Verfahrensabläufe erfaßt werden; • W3: Gesamtorganisationale Wirtschaftlichkeit, mit der die Kosten zur Aufrechterhaltung der Anpassungsfähigkeit und Funktionsstabilität sowie kostenrelevante Humanaspekte und der damit bewirkte Nutzen erfaßt werden; • W4: Gesellschaftliche Wirtschaftlichkeit, mit der negative Auswirkungen (Kosten) und positive Auswirkungen (Nutzen) auf die Unternehmensumwelt erfaßt werden. Bei Nutzenmessung wird zwischen quantitativen und qualitativen Ausprägungen unterschieden. Bei Verwendung der vier Wirtschaftlichkeitsstufen, der Kosten und den beiden Nutzenkategorien ergibt sich eine 12-Felder-Matrix als Grundlage für die Beurteilung der Wirtschaftlichkeit. Verdichtungen und Saldierungen sollen vermieden werden, um die Wirtschaftlichkeit stufenweise sichtbar zu machen. Demonstrationsbeispiel Es wird die Verwendung der Kostenvergleichsrechnung für die Beurteilung der Wirtschaftlichkeit von textorientierten Kommunikationsdiensten dargestellt. Abbildung WIRTA-2 zeigt die Anschaffungspreise und die Gebühren der Kommunikationsdienste und der daraus abgeleiteten Kostenfunktionen (alle Angaben in DM). Zweck des Demonstrationsbeispiels ist es, den methodischen Ansatz der Kostenvergleichsrechnung zu zeigen; die mangelnde Aktualität der verwendeten Werte ist daher ohne Bedeutung. Unter Verwendung der Daten der Abbildung WIRTA-2 wurden die Kostenfaktoren für die Kostenkurven der alternativen Kommunikationsdienste ermittelt; sie

WIRT A - Wirtschaftlichkeitsanalyse

309

sind in Abbildung WIRTA-3 dargestellt. Folgendes kann daraus abgelesen werden: 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. v.Kommunikations-

Fixe Kosten

|

Teletex

Telefax Telefax Gruppe 2 Gruppe 3

Kostenart —•— Anschaffungspreis der Für Kommunikationsca. 6000 zusatz ca. 8000 Endgeräte Monatliche Miete bzw. ca. 240 ca. 180 Leasinggebühr incl. Wartung

Monatliche Gebühren

ca. 360

+ 5 Tclcfaxgcbühr -4.6 für 2 0 Freieinheiten

Variable Kosten |[

27.40

zwischen

Übertragungsgebühren Inland

Regionalbereich -.13 Fernbereich -. 19

ca. 360 Grundgebühr 65, Unterhaltungsgebühr 36 101 innerhalb

zwischen

Z e n t r a l Ver-

- . 2 3 i m N a h - - . 2 3 im N a h -

mittlungs-

bcreich und

hcreich und

s t e l l e n 1,

3.35 im

1.15 i m

zwischen

Fernbcrcich

Fernbereich

Z e n t r a l Ver-

(>100 km)

(>100 km)

mittlungss t e l l e n 1.5

Durchschnittlich

0.18

2.07

Briefpost

ca. 6000 ca. 12000

27 für FS-Hauptanschluß

Grundgebühr 170

Telex

0.69

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)

Abb. WIRTA-3: Kostenkurven alternativer Kommunikationsdienste (Quelle: Picot/Reichwald)

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

310

Analysemethoden

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 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. Kontrollfragen 1. 2. 3. 4.

W a n n ist ein I u K - P r o j e k t wirtschaftlich? W i e k ö n n e n die Kosten u n d w i e kann der Nutzen gegliedert w e r d e n ? W i e erfolgt die A n a l y s e der B e z i e h u n g s z u s a m m e n h ä n g e zwischen Kosten und N u t z e n ? W o d u r c h unterscheiden sich statische von d y n a m i s c h e n M e t h o d e n der Wirtschaftlichkeitsrechnung?

5.

W a s ist ein Wirtschaftlichkeitsmodell?

Quellenliteratur A n s e l s t e t t e r , R.: B e t r i e b s w i r t s c h a f t l i c h e N u t z e f f e k t e d e r D a t e n v e r a r b e i t u n g - 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, Berlin et al. 1986 B l o h m , H . / L ü d e r , K.: Investition. 7. A „ Vahlen, M ü n c h e n 1992 K a r g l , H . : C o n t r o l l i n g im D V - B e r e i c h . 3. A., O l d e n b o u r g , M ü n c h e n / W i e n 1996 R e i c h w a l d , R.: Ein m e h r s t u f i g e r B e w e r t u n g s a n s a t z z u r w i r t s c h a f t l i c h e n L e i s t u n g s b e u r t e i l u n g d e r B ü r o k o m m u n i k a t i o n . In: H o y e r , R. H. und K ö l z e r , G. (Hrsg.): W i r t s c h a f t l i c h k e i t s r e c h n u n g e n im B ü r o b e r e i c h , d e G r u y t e r , Berlin 1987, 2 3 - 33 S c h u m a n n , M . : W i r t s c h a f t l i c h k e i t s b e u r t e i l u n g f ü r I V - S y s t e m e . 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 - 1 7 8

Vertiefungsliteratur A n t w e i l e r , J.: W i r t s c h a f t l i c h k e i t s a n a l y s e von I n f o r m a t i o n s - u n d K o m m u n i k a t i o n s s y s t e m e n . D a t a k o n t e x t , K ö l n 1995 B u x m a n n , P . / K ö n i g , W . : Ein E n t s c h e i d u n g s m o d e l l zur B e w e r t u n g von Investitionen in S t a n d a r d s - 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 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, 2 5 2 - 2 6 7 G r i e s e , J. et al.: E r g e b n i s s e d e s Arbeitskreises W i r t s c h a f t l i c h k e i t der I n f o r m a t i o n s v e r a r b e i t u n g . In: Z e i t s c h r i f t für betriebswirtschaftliche F o r s c h u n g 7/1987, 5 1 5 - 5 5 1 H e i n r i c h , L. J.: I n f o r m a t i o n s m a n a g e m e n t - P l a n u n g , Ü b e r w a c h u n g u n d S t e u e r u n g d e r I n f o r m a t i o n s i n f r a s t r u k t u r . 5. A., O l d e n b o u r g , M ü n c h e n / W i e n 1996 N i e m e i e r , J.: K o n z e p t e der W i r t s c h a f t l i c h k e i t s b e r e c h n u n g bei integrierten I n f o r m a t i o n s s y s t e m e n . In: H o r v a t h , P. ( H r s g . ) : W i r t s c h a f t l i c h k e i t n e u e r P r o d u k t i o n s - u n d I n f o r m a t i o n s t e c h n o l o g i e . P o e s c h e l , Stuttgart 1988, 15 - 3 4 Ott, H. J.: W i r t s c h a f t l i c h k e i t s a n a l y s e von EDV-Investitionen mit d e m W A R S - M o d e l l a m Beispiel d e r E i n f ü h r u n g von C A S E . In: W I R T S C H A F T S I N F O R M A T I K 6 / 1 9 9 3 , 5 2 2 - 531 Picot, A./Reichwald, R. (Hrsg.): Kommunikationstechnik und Wirtschaftlichkeit. C W - P u b l i kationen, M ü n c h e n 1984 S c h u m a n n , M.: Betriebliche N u t z e f f e k t e und Strategiebeitrage der großintegrierten I n f o r m a t i o n s v e r a r b e i t u n g . S p r i n g e r , Berlin et al. 1992 Stickel, E . : E i n e E r w e i t e r u n g des hedonistischen V e r f a h r e n s zur Ermittlung der W i r t s c h a f t l i c h k e i t des E i n s a t z e s von I n f o r m a t i o n s t e c h n i k . In: Zeitschrift für B e t r i e b s w i r t s c h a f t 7 / 1 9 9 2 , 7 4 3 - 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 A b k ü r z u n g e n E n t s c h e i d u n g s r e g e l (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. Z i e l e r t r a g (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. 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. 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 Zielwerte.

312

Analysemethoden

Zweck der Nutzwertanalyse In der Problemlösungsstufe 5 Bewertung des systemtechnischen Planungsansatzes (vgl. Abbildung SYSIP-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 IuK-Projekte 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 Vorziehenswürdigkeit geordnet werden. Dazu sind sie, unter Beachtung der Präferenzen der Entscheidungsträger, miteinander zu vergleichen. Aufgaben dieser Art können mit 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 SYSIP), 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 zerlegt usw. Daraus ist ersichtlich, daß jedes Zielsystem beliebig tief gegliedert werden kann, wobei mit zunehmender Zerlegung die Präzision und die Operationalität der Ziele zunehmen.

NUTZW - Nutzwertanalyse

313

314

Analysemethoden

Mit der Zerlegung steigt - bedingt durch die zunehmende Anzahl der Teilziele der A u f w a n d 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 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. Z w e i t e r Arbeitsschritt: Ermitteln der Zielerträge Im zweiten Arbeitsschritt der Nutzwertanalyse werden die Zielerträge je Zielkriterium und j e 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 zweiten 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 njj bildet durch seinen numerischen Wert den Teilnutzen des Zielkriteriums kj für die Handlungsalternative Aj ab. Ergebnis des dritten Arbeitsschritts ist die Z i e l w e r t matrix. Skalieren heißt also, den Zielerträgen ey 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. Je nach Ergebnis wird sie der Wertkategorie "erfüllt das Zielertragsniveau" oder "erfüllt das Zielertragsniveau nicht" zugeordnet. Dem Vorteil der leichten

NUTZW - Nutzwertanalyse

315

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 bestehen in der Regel erhebliche praktische Mcß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.

316

Analysemethoden

• Bestimmen vorläufiger Kriteriengewichte, wobei das wichtigste Zielkriterium den Gewichtungsfaktor 1,0 erhält; die Gewichtungsfaktoren der anderen Zielkriterien müssen die Voraussetzung erfüllen, daß sie mit zunehmender Rangziffer abnehmen. • Der endgültige Gewichtungsfaktor für das bedeutsamste Zielkriterium wird ermittelt, indem zunächst abgeschätzt wird, ob dieser größer, gleich oder kleiner als die Summe der restlichen Gewichtungsfaktoren sein soll; es wird eine entsprechende Bedingung formuliert. 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 ü n f t e r Arbeitsschritt: Durchführen der Wertsynthese Im fünften Arbeitsschritt der Nutzwertanalyse werden die Teilnutzen j e Handlungsalternative mit Hilfe einer Entscheidungsregel zum Gesamtnutzen aggregiert. Die Auswahl der Entscheidungsregel ist vom verwendeten Skalenniveau abhängig, ob also 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 Entscheidungsregcl 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 Handlungsalternativen 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.

NUTZW

- Nutzwertanalyse

317

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äufigkeitsregeI: 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 j = I n ij-gj j=l Legende:

N i ... Nutzwert der Alternative i n jj ... 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 Nj — • 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 O r d n u n g gebracht. Die Ordnung ergibt sich aus dem Vergleich der Nutzwerte der Handlungsalternativen. Die optimale Handlungsalternative ist

318

Analysemethoden

die, deren Nutzwert maximal ist bzw. (wie z.B. bei der Rangordnungssummenregel) 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). W e i t e r f ü h r e n d e 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 Handlungsalternativen 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). • Kosten/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 A n n a h m e n 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.

NUTZW

- Nutzwertanalyse

319

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. Optimale Methode

Aufwand

'MW//M//////W,

yM Planungsaufwand wv,

Durchführungsaufwand

m///////////////////////////^

Durchführungsaufwand ^ beim Projektteam ^

w, Auswertungsaufwand ^

V///////////////////////////////M

Durchführungsaufwand ; beim Aufgabenträger

A b b . N U T Z W - 4 : Zielkriterien für die B e w e r t u n g 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 ERFAS) 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 Zieldimension (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.

320

Analysemethoden

—

Alternativen

Kriterien

—

Genauigkeit Planungsaufwand G 1) 00 2C5/

Durchführungsaufwand beim Projektteam Durchführungsaufwand beim Aufgabenträger

1>

1c

Auswertungsaufwand Akzeptanz

Arbeitstagebücher

Tätigkeitsberichte

Multimomentstudien

noch ausreichend

ausreichend

beliebig wählbar

5

4

10

2

10

4

20

10

keiner

4

2

6

sehr hoch

hoch

noch ausreichend

Abb. NUTZW-5: Zielerträge der Alternativen (Zielertragsmatrix)

• Dritter Arbeitsschritt: Ermitteln der Zielwerte. Für die Bewertung der Zielerträge wird die ordinale Skala verwendet. Abbildung NUTZW-6 zeigt die Zielwerte der Alternativen für jedes Kriterium auf Grund der in Abbildung N U T Z W - 5 dokumentierten Zielerträge als Zielwertmatrix. •—____ Alternativen Kriterien "

Arbeitstagebücher

Tätigkeitsberichte

Multimomentstudien

Genauigkeit

3

2

1

Planungsaufwand

2

1

3

Durchführungsaufwand Durchführungsaufwand beim Aufgabenträger .s Auswertungsaufwand

1

3

2

3

2

1

2

1

3

Akzeptanz

1

2

3

1

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

NUTZW - Nutzwertanalyse

321

• Vierter Arbeitsschritt: Durchführen der Wertsynthese. Als Entscheidungsregel wird die Rangordnungssummenregel 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 Kriterien

'

Arbeitstagebücher

~—

Tätigkeitsberichte

Multimomentstudien

Gewichtungsvektor

Genauigkeit

60

40

20

20

Planungsaufwand

10

5

15

5

15

45

30

15

90

60

30

30

Auswertungsaufwand

20

10

30

10

Akzeptanz

20

40

60

20

Nutzwert

215

200

185

100

Durchführungsaufwand beim Projektteam Durchführungsaufwand beim Aufgabentriiger

c

c

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 (sog. Splitting-Bias). • H2: Je höher die (subjektiv empfundene) Korrelation zwischen den durch Zerlegung entstehenden Unterzielen ist, desto größer ist der Splitting-Bias.

322

Analysemethoden

Zur Ermittlung der Zielgewichte wurden vier Gewichtungsmethoden verwendet (Swing-Methode, Direct-Ratio-Methode, Conjoint-Methode und Multiple-Importance-Methode). H1 wurde bei allen verwendeten Gewichtungsmethoden deutlich bestätigt. Zu H2 waren die Ergebnisse widersprüchlich. Im Ergebnis kann festgehalten werden, daß mit einem Splitting-Bias generell gerechnet werden muß. Kontrollfragen 1. 2. 3. 4.

W e l c h e r Unterschied besteht zwischen einem Ziel und e i n e m Zielkriterium? W e l c h e s sind die bestimmenden Einflüsse b e i m Ermitteln des Zielsystems? W e l c h e r Unterschied besteht zwischen Zielertrag und Zielwert? W a s bewirkt die G e w i c h t u n g der Zielkriterien?

5.

N e n n e n Sie Beispiele für Entscheidungsregeln mit d e m zugehörigen Skalenniveau.

Quellenliteratur B l o h m , H . / L ü d e r , K.: Investition. 8. A., Vahlen, M ü n c h e n 1995 W e b e r , M . : N u t z w e r t a n a l y s e . In: F r e s e , E. (Hrsg.): H a n d w ö r t e r b u c h d e r O r g a n i s a t i o n . 3. A., P o e s c h e l , Stuttgart 1992, 1 4 3 6 - 1448 Z a n g e m e i s t e r , C h . : 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 h a n d l u n g , M ü n c h e n 1976

Vertiefungsliteratur E i s e n f ü h r , F.AVeber, M.: Zielstrukturierung: ein kritischer Schritt im E n t s c h e i d u n g s p r o z e ß . In: Zeitschrift f ü r betriebswirtschaftliche Forschung 11/1986, 907 - 9 2 9 Weber, M . : Entscheidungen bei Mehrfachzielen. Gabler, W i e s b a d e n 1983 Z a n g e m e i s t e r , C h . / B o m s d o r f , E.: Empfindlichkeitsanalyse in der N u t z w e r t a n a l y s e . In: Zeitschrift f ü r betriebswirtschaftliche F o r s c h u n g 5/1983, 375 - 397

WERTA - Wertanalyse Lernziele Sie kennen den Z w e c k der Wertanalyse und erkennen ihre Bedeutung f ü r die Abwicklung von IuK-Projekten. Sie können die Vorgehensweise bei der Wertanalyse in Phasen und Arbeitsschritte gliedern. Sie erkennen die zentrale Bedeutung der Funktionsanalyse für die Wertanalyse und können Hauptfunktionen von Nebenfunktionen unterscheiden. Sie sind in der Lage, die Wertanalyse auf IuKProjekte und Produkte von IuK-Projekten anzuwenden. Definitionen und

Abkürzungen

A n p a s s u n g s w a r t u n g (adaption maintenance) = der Teil der Wartung, der dazu dient, ein System nach einer Änderung der Anforderungen so umzugestalten, daß es den (veränderten) Anforderungen entspricht. B e n u t z b a r k e i t (usability) = eine Menge von Eigenschaften, die eine einfache, leicht erlernbare Benutzung eines IuK-Systems erlauben. B e n u t z e r p r o f i l (user profile) = die Einordnung der Benutzer in Benutzerklassen, z.B. nach dem Merkmal der persönlichen Fähigkeiten und Fertigkeiten im Umgang mit einem IuK-System. F u n k t i o n (function) = die Eigenschaft eines Produkts, die zur Erfüllung eines G e b r a u c h s w e r t s oder eines Prestigewerts erforderlich ist; sie kann Hauptfunktion oder Nebenfunktion sein. F u n k t i o n s b a u m (functional tree) = die grafische Darstellung der Beziehungen zwischen den Funktionen in Form eines hierarchisch gegliederten Entscheidungsbaums. Synonym: Funktionsstammbaum. F u n k t i o n s b e r e i c h (functional bündle) = die Zusammenfassung mehrerer eng zusammenhängender Funktionen. Synonym: Funktionsbündel. F u n k t i o n s s a t z (description of function) = die Beschreibung einer Funktion mit einer funktionalen Formulierung, im allgemeinen mit einem Hauptwort und einem Zeitwort (z.B. "Daten übertragen"). Synonym: Funktionsbeschreibung. K o o p e r a t i o n (Cooperation) = ein sozialer Prozeß zwischen mehreren A u f g a benträgern zur Erreichung gemeinsamer Ziele. K r e a t i v i t ä t s t e c h n i k (creativity technique) = eine heuristische Methode zur Problemdefinition und zum kreativen Problemlösen, d.h. zum Entwerfen von Alternativen in Situationen, die durch schlecht strukturierte Probleme und durch eine o f f e n e Entscheidungssituation gekennzeichnet sind. R a t i o n a l i s i e r u n g (rationalization) = das Bestreben, ein System so zu gestalten, daß es den gesetzten Zielen besser entspricht. W e r t (value) = der subjektive Nutzen, den der Verwender eines bestimmten Produkts diesem zuordnet. W e r t a n a l y s e - A r b e i t s p l a n (value analysis job plan) = die systematische, in Phasen und Arbeitsschritte strukturierte Vorgehensweise bei der Wertanalyse. Wertziel (worth) = die niedrigsten Kosten, die erforderlich sind, um eine Funktion zu erfüllen. Synonym: Funktionskosten. Zerlegung (decomposition) = das systematische Zergliedern eines Systems in Subsysteme.

324

Analysemethoden

Zweck der Wertanalyse Die Wertanalyse wurde in den vierziger Jahren in den USA durch L. D. Miles bei General Electric entwickelt; sie wird heute weltweit mit Erfolg eingesetzt. Der Erfolg ist dabei nicht nur von der Wertanalyse als Methode abhängig, sondern wird gleichermaßen von den Verhaltensweisen der mittelbar und unmittelbar an einem Wertanalyse-Projekt beteiligten Personen sowie vom Management bestimmt. DIN 69910 definiert demgemäß wie folgt: "Die Wertanalyse ist ein System zum Lösen komplexer Probleme, die nicht oder nicht vollständig algorithmierbar sind. Sie beinhaltet das Zusammenwirken der Systemelemente Methode, Verhaltensweisen und Management bei gleichzeitiger gegenseitiger Beeinflussung mit dem Ziel einer Optimierung der Ergebnisse." Alle Auffassungen darüber, was Wertanalyse ist, stimmen in drei Merkmalen überein: • die funktionsorientierte Betrachtung, welche die Untersuchung der Funktionen des Wertanalyse-Objekts in den Vordergrund stellt; • die systematische Zerlegung des Wertanalyse-Objekts in seine Funktionen, wie dies bei der Aufgabenanalyse der Fall ist (vgl. Lerneinheit ERFAS); • das kooperative Vorgehen (interdisziplinäre Gruppenarbeit), das durch einen Arbeitsplan mit festgelegten Arbeitsphasen und Arbeitsschritten sowie durch die Zusammenarbeit aller Betroffenen gekennzeichnet ist. Da systematisches Zerlegen und kooperatives Vorgehen typische Merkmale von Kreativitätstechniken sind, wird die Wertanalyse häufig auch als Kreativitätstechnik (meist unter der synonymen Bezeichnung "Funktionsanalyse") bezeichnet (vgl. Lerneinheit KREAT). Wertanalyse ist auf vorhandene materielle und nicht-materielle Objekte (z.B. Produkte, Dienstleistungen, Arbeitsabläufe) und auf materielle und nichtmaterielle Objekte anwendbar, die sich im Planungsstadium befinden. Eine genauere Bezeichnung verwendet für den ersten Fall die Bezeichnung Werta n a l y s e (valué analysis, value improvement), für den zweiten Fall die Bezeichnung Wertgestaltung (value engineering, value assurance). Nach DIN 69910 wird Wertanalyse als Oberbegriff verwendet und zwischen Wertverbesserung (Untersuchung von vorhandenen Produkten) und Wertgestaltung (Untersuchung von Produkten, die sich im Planungsprozeß befinden) unterschieden. Da sich diese Unterscheidung nicht allgemein durchgesetzt hat, wird im folgenden nur von Wertanalyse gesprochen. Zweck der Wertanalyse ist es, den Wert eines Wertanalyse-Objekts durch ein Mehr an Funktionserfüllung und/oder ein Weniger an Kosten zur Realisierung der Funktionserfüllung zu steigern. Dabei steht nicht das Wertanalyse-Objekt in seiner physischen Realisierung im Mittelpunkt der Betrachtung, sondern dessen Funktionen und der Wert der Funktionserfüllung für den Benutzer. Diese Sichtweise entspricht der für IuK-Projekte typischen Methodik, die zwischen logischem Modell und physischem Modell unterscheidet (vgl. Lerneinheit ZAMIP) und die fordert, sich von den physischen Attributen des Istzustands zu lösen und physische Attribute des Sollzustands als Realisierungsmöglichkeiten eines logischen Modells des Sollzustands zu verstehen. Wertanalyse-Objekte von IuK-Projekten sind daher insbesondere:

WERTA - Wertanalyse

325

• die Grundkonzeption in der Projektphase Vorstudie (vgl. Lerneinheit ZAMVS); • der Istzustand und die angepaßte Grundkonzeption in der Projektphase Feinstudie (vgl. Lerneinheit ZAMFS); • die Entwürfe der Teilsysteme und des Gesamtsystems in der Projektphase Systementwurf (vgl. Lerneinheit ZAMSE); • die realisierten Teilsysteme und das Gesamtsystem in der Projektphase Implementierung (vgl. Lerneinheit ZAMIM). Darüber hinaus kann die Wertanalyse als Methode des Lebenszyklus-Managements f ü r die R a t i o n a l i s i e r u n g bestehender IuK-Systeme eingesetzt werden (vgl. Lerneinheit LEMAN im Bd. "Informationsmanagement"). Dabei geht es um die Beantwortung der Frage, welches Mehr an Funktionen und/oder welches Weniger an Kosten durch geeignete Maßnahmen der A n p a s s u n g s w a r t u n g erreicht werden kann. Funktionsanalyse Im Mittelpunkt der Wertanalyse-Arbeit steht die Funktionsanalyse, für die erfahrungsgemäß etwa 50% des gesamten Zeitaufwands für eine Wertanalyse-Studie erforderlich sind. Mit der Funktionsanalyse wird jede Funktion eines Wertanalyse-Objekts (ausgedrückt durch ein Substantiv und ein Verb im Infinitiv, z.B. "Seitenumbruch einfügen") daraufhin untersucht, in welche Funktionsart und in welche F u n k t i o n s k l a s s e sie einzuordnen ist, oder ob sie der Kategorie "unerwünschte Funktion" zuzuordnen ist. Funktionsarten sind Gebrauchsfunktion und Geltungsfunktion; sie beschreiben die sachliche bzw. subjektive Wirkung des Wertanalyse-Objekts bei seiner tatsächlichen oder geplanten Verwendung. Die Funktionsklassen dienen dem Herstellen einer Rangordnung der Funktionen nach unterschiedlichen Gesichtspunkten. Dabei wird zwischen Hauptfunktion und Nebenfunktion sowie zwischen Gesamtfunktion und Teilfunktion unterschieden. Die Zuordnung einer Funktion zur Funktionsklasse Hauptfunktion oder Nebenfunktion erfolgt aufgrund der Beantwortung der Frage, ob die Funktion zur Erfüllung der Planungsziele (Verwendungszweck im Sinn der Wertanalyse) unerläßlich ist und wenn nein, ob sie den Verwendungszweck unterstützt oder ob sie ihn erweitert. Ist eine Funktion unerläßlich, ist sie Hauptfunktion. Unterstützt oder erweitert eine Funktion den Verwendungszweck, ist sie N e b e n f u n k t i o n . Trifft weder die erste noch die zweite Aussage zu, dann ist sie überflüssig. Diese Aussagen visualisiert Abbildung WERTA-1. Aus der Abbildung kann auch die Bedeutung der Wertanalyse für die Istzustandsanalyse, insbesondere für den inhaltlichen Analysezyklus, erkannt werden (vgl. Lerneinheit ANIST in Bd. 1 "Systemplanung"). Es sind nur Funktionen von Bedeutung, die aus der Sicht des Anwenders oder Benutzers einen Nutzen haben, mit anderen Worten: die definierte Anforderungen erfüllen. Dabei ist auch wichtig, wie sich die Anforderungen entwickeln, sodaß Funktionen an Bedeutung verlieren, wegfallen oder neu hinzukommen können. In jedem IuK-System werden sowohl Hauptfunktionen als auch Nebenfunktionen realisiert. Viele der als Funktionsanforderungen, als Leistungsanforderungen und als Schnittstellenanforderungen bezeichneten Sachziele sind im Sinn der Wert-

326

Analysemethoden

analyse Hauptfunktionen, viele der als Nutzungsziele, Wartungsziele und Rahmenziele bezeichneten Formalziele sind im Sinn der Wertanalyse Nebenfunktionen (vgl. Lerneinheit ZIELP). Eine ausreichend genaue Aussage darüber, welche Sachziele und welche Formalziele Hauptfunktionen, welche Nebenfunktionen und welche "überflüssige Funktionen" sind, soll die Funktionsanalyse liefern. So kann - je nach IuK-System und Benutzerprofil - die Benutzbarkeit eine Hauptfunktion (z.B. für naive Benutzer) oder eine Nebenfunktion (z.B. für professionelle Benutzer) sein.

Abb. WERTA-1: Funktionsgliederung (Quelle: nach Hoffmann)

Die Funktionsgliederung in Hauptfunktionen und Nebenfunktionen ist eine wichtige Orientierungshilfe. Für die Untersuchung des Istzustands ist sie ein Analyseinstrument, für den Entwurf des Sollzustands ist sie ein Kriterium für die Beurteilung des qualitativen Niveaus des Systementwurfs. Wenn z.B. die Anzahl der Nebenfunktionen deutlich vermindert werden kann, dann wird die Problemlösung insgesamt wirtschaftlicher. Je nach konkretem Wertanalyse-Objekt, kann Funktion eine unterschiedliche und über die bisherige Erläuterung hinausgehende Bedeutung haben; die Bedeutung kann allgemeiner Art oder sehr präziser Art sein. Ist z.B. der Entwurf der gesamten Ablauforganisation Wertanalyse-Objekt, dann sind die einzelnen Arbeitsabläufe die Funktionen im Sinn der Wertanalyse. Wird dagegen ein bestimmter Geschäftsprozeß untersucht, sind die Abiaufschritte dieses Geschäftsprozesses (z.B. als Objekt/VerrichtungKombination) Funktionen im Sinn der Wertanalyse. Die systematische Vorgehensweise bei der Funktionsanalyse wird durch die Verwendung eines Funktionsbaums unterstützt, in dem die Funktionsarten und Funktionsklassen als Funktionsstruktur dargestellt werden. Wurzel eines Funktionsbaums ist die Gesamtfunktion des Wertanalyse-Objekts, die nach dem Prinzip des Stammbaums über verschiedene Ebenen von Teilfunktionen zerlegt wird. Eine Teilfunktion ist eine Hauptfunktion, der die Nebenfunktionen als "Äste" jeder Ebene zugeordnet sind, welche diese Hauptfunktion unterstützen. Nach Durchführung der Kostenanalyse können den Funktionen im Funktionsbaum ge-

WERTA - Wertanalyse

327

plante Kosten (bei Produkten, die sich in Planung befinden) bzw. tatsächliche Kosten (bei verwendeten Produkten) zugeordnet werden. Nach Durchführung der Wertziel-Analyse können auch Wertziele zugeordnet werden. Kostenanalyse und Wertziel-Analyse In engem Zusammenhang mit der Funktionsanalyse steht die Kostenanalyse, deren Zweck die Zuordnung von Kosten zu Funktionen ist. Aufgrund der Kostenanalyse soll für jede Funktion angegeben werden, welche Kosten sie verursacht. Da sowohl die Erhebung der Kosten als auch ihre Zurechnung auf einzelne Funktionen häufig schwierig, wenn nicht unmöglich ist (besonders bei WertanalyseObjekten, die sich in Planung befinden), werden mehrere Funktionen zu Funktionsbereichen zusammengefaßt. Dadurch können die Kosten leichter geschätzt und den Funktionsbereichen zugerechnet werden. Schwierigkeiten der Kostenermittlung und -Zurechnung resultieren vor allem daraus, daß die üblichen Verfahren der Kosten- und Leistungsrechnung die Kosten auf Stellen, Träger usw. zurechnen, nicht aber auf Funktionen. Häufig ist es zweckmäßig, für die Funktionen Kostenziele festzulegen (Wertziele im Sinn der Wertanalyse). Ein Wertziel legt fest, wie hoch die Kosten für die Realisierung jeder Funktion des Wertanalyse-Objekts ("Funktionswertziel") und davon ausgehend - des Wertanalyse-Objekts insgesamt höchstens sein sollten. Aus der Differenz zwischen dem Wertziel und den geplanten Kosten bzw. den Istkosten kann auf das Rationalisierungspotential geschlossen und danach beurteilt werden, ob sich eine aufwendige Wertanalyse-Arbeit überhaupt lohnt. Zum Ermitteln der Wertziele werden zunächst alle Nebenfunktionen entfernt, und es wird nur von den Hauptfunktionen ausgegangen. Für jede Hauptfunktion wird eine "billige" Realisierungsalternative ermittelt; deren Kosten sind das Funktionswertziel. Zeigt die Differenz zwischen der Summe der Funktionswertziele und der Summe der geplanten Kosten bzw. der Istkosten ein ausreichendes Rationalisierungspotential, wird die Wertziel-Analyse fortgesetzt, und den Hauptfunktionen werden solange schrittweise die Nebenfunktionen mit ihren Wertzielen zugeordnet, bis das Wertziel des Wertanalyse-Objekts insgesamt ermittelt ist. Arbeitsphasen der Wertanalyse Ausgangspunkt für ein Wertanalyse-Projekt ist eine eindeutige Aufgabenbeschreibung mit einer möglichst quantifizierten Zielvorgabe. Kennzeichnend für die eigentliche Wertanalyse-Arbeit ist die systematische Vorgehensweise nach einem Wertanalyse-Arbeitsplan, der in folgende Phasen und Arbeitsschritte gegliedert sein kann (vgl. auch Abbildung WERTA-2): • • • • • •

Vorbereiten der Wertanalyse-Arbeit (Vorbereitungsphase); Erheben des Istzustands (Erhebungsphase); Analysieren des Istzustands (Analysephase); Entwickeln von Alternativen (Kreativitätsphase); Bewerten der Alternativen (Bewertungsphase); Verwirklichen der optimalen Alternative (Realisierungsphase).

328

Analysemethoden

Vorbereitungsphase: Die Wertanalyse-Arbeit beginnt mit dem Auswählen eines Wertanalyse-Objekts und dem Untersuchungsauftrag (z.B. mit dem Wertanalyse-Objekt "Grundkonzeption" und dem Auftrag durch den Lenkungsausschuß). Aufgrund des Untersuchungsauftrags wird eine Arbeitsgruppe gebildet. Die Mitglieder der Arbeitsgruppe sollen mit denen der Projektgruppe für das IuKProjekt nicht identisch sein. Die Arbeitsgruppe plant den Arbeitsablauf für die Wertanalyse-Arbeit (analog zu der in Lerneinheit PROPL erläuterten Vorgehensweise). Erhebungsphase: Aufgabe dieser Phase ist es, alle Daten zu erheben, die zur Beschreibung des Wertanalyse-Objekts erforderlich sind. Bei einem in Planung befindlichen Wertanalyse-Objekt beschreibt die Projektdokumentation den Zustand des Wertanalyse-Objekts zum Zeitpunkt der Wertanalyse-Arbeit (vgl. Lerneinheit DOKUM). Darüber hinaus können Daten über den Istzustand des IuK-Systems, das ersetzt werden soll, von Interesse sein. Von besonderer Bedeutung für die Wertanalyse-Arbeit sind die aktuellen Anforderungen, wie sie in der Spezifikation für das Projekt dokumentiert sind (vgl. Lerneinheit ZIELP). Nur wenn die Projektdokumentation aussagefähig und aktuell ist, können spezielle Erhebungen für die Wertanalyse-Arbeit weitgehend vermieden werden. Zur Erhebungsphase gehört auch die Beschreibung der Funktionen (Funktionssatz) und die Erhebung der Kosten für die Funktionen. Analysephase: Die Daten über den Istzustand des Wertanalyse-Objekts werden für die Funktionsanalyse, die Kostenanalyse und die Wertziel-Analyse verwendet. Mit diesen Analysen sollen die folgenden Fragen beantwortet werden: • • • •

Welche Welche Welche Welche

Funktionen werden an Bedeutung verlieren? Funktionen können entfallen? der notwendigen Funktionen müssen besser erfüllt werden? zusätzlichen Funktionen sind erforderlich?

Kreativitätsphase: Das Suchen nach Alternativen erfolgt auf der Grundlage der Funktionsanalyse, also völlig losgelöst von einer bestehenden physischen Realisierung des Wertanalyse-Objekts. Zur Unterstützung dieser Arbeitsphase werden Kreativitätstechniken (vgl. Lerneinheit KREAT) verwendet. Untersucht wird für jede Funktion, durch welche alternativen physischen Attribute sie realisiert werden könnte. Man ermittelt dann die Kosten der alternativen Realisierungen und erhält so für jeden Funktionsbereich bzw. für jede Hauptfunktion und schließlich für das Wertanalyse-Objekt insgesamt alternative physische Realisierungen mit ihren Wertzielen. Bewertungsphase: Aus der erarbeiteten Alternativenmenge werden in einem ersten Schritt zunächst die Alternativen ausgewählt, welche bei etwa gleichartiger physischer Realisierung die geringsten Kosten verursachen. In einem zweiten Schritt wird aus dieser Alternativenmenge die optimale Alternative ausgewählt. Optimal ist die Alternative der Alternativenmenge, welche bei gleichem Umfang an Haupt- und Nebenfunktionen mit den geringsten Kosten realisiert werden kann, bzw. die Alternative der Alternativenmenge, welche bei gleichen Kosten den größten Umfang an Haupt- und Nebenfunktionen realisieren kann. Beim Be-

WERTA - Wertanalyse

329

werten der Alternativen sollten die Ergebnisse der Funktionsanalyse in bezug auf jede Alternative immer wieder überprüft werden, indem gefragt wird: • Enthält die Alternative alle für die Benutzer erforderlichen Funktionen? • Enthält die Alternative Funktionen, die die Benutzer nicht brauchen? R e a l i s i e r u n g s p h a s e : In dieser Phase präsentiert die Arbeitsgruppe dem Auftraggeber die optimale Alternative (vgl. Lerneinheit PRAET). Der Auftraggeber muß darüber entscheiden, ob sie verwirklicht werden soll. Wenn ja, gehen die Ergebnisse der Wertanalyse-Arbeit als Arbeitsgrundlage in das IuK-Projekt ein. Wenn die Wertanalyse-Arbeit erfolgreich war (wenn also das vermutete oder geschätzte Rationalisierungspotential vorhanden ist), führt dies zu Veränderungen am Planungsobjekt und somit an der Projektplanung und -abwicklung. Abbildung W E R T A - 2 zeigt den W e r t a n a l y s e - A r b e i t s p l a n nach DIN 69910, aus dem die einzelnen Grundschritte und Teilschritte (jeweils mit Nummer und Bezeichnung) sowie der Arbeitsablauf ersichtlich sind. Grundschrilt

Bezeichnung

1

Vorbereitende Maßnahmen

2

Ermitteln des IST-Zustands

3

4 5

6

Prüfen des IST-Zustands

Teilschritt 1

Auswählen des WA-Objekts und Stellen der Aufgabe

2

Festlegen des quantifizierten Ziels

3

Bilden der Arbeitsgruppe

4

Planen des Ablaufs

1

Informationen beschaffen und Beschreiben des WA-Objekts

2

Beschreiben der Funktionen

3

Ermitteln der Funktionskosten

1

Prüfen der Funktionserfüllung

2

Prüfen der Kosten

Ermitteln von Lösungen Prüfen der Lösungen

Bezeichnung

Suche nach allen denkbaren Lösungen 1

Prüfen der sachlichen Durchführbarkeit

2

Prüfen der Wirtschaftlichkeit

Vorschlag und Verwirklichen einer Lösung

1

Auswählen der Lösung(en)

2

Empfehlen einer Lösung

Realisierung

3

Verwirklichen einer Lösung

Abb. WERTA-2: Wertanalyse-Arbeitsplan (Quelle: DIN 69910)

330

Analysemethoden

Kontrollfragen 1. 2. 3. 4. 5.

Welchen Zweck verfolgt die Wertanalyse-Arbeit? Welche Objekte von IuK-Projekten sind f ü r die Wertanalyse geeignet? W a s ist eine Hauptfunktion und was ist eine Nebenfunktion? Nach welchem Kriterium wird die Zweckmäßigkeit eines Wertanalyse-Projekts beurteilt? Welche Phasen des Wertanalyse-Arbeitsplans werden unterschieden?

Quellenliteratur H o f f m a n n , H.: Wertanalyse - Ein W e g zur Erschließung neuer Rationalisierungsquellen. 2. A., Schmidt, Berlin 1983 Jehle, E.: Wertanalyse. In: Wittmann, W. et al. (Hrsg.): Handwörterbuch der Betriebswirtschaft. 5. A „ Poeschel, Stuttgart 1993 Körte, R.-J.: Verfahren der Wertanalyse - Betriebswirtschaftliche Grundlagen zum Ablauf wertanalytischer Entscheidungsprozesse. Schmidt, Berlin 1977

Vertiefungsliteratur Gierse, F. J.: Funktionen und Funktionen-Strukturen - zentrale Werkzeuge der Wertanalyse. In: VDI-Berichte 849, Düsseldorf 1990 V D I - Z W A (Hrsg.): Wertanalyse. Idee - Methode - System. 4. A., VDI, Düsseldorf 1991

Normen DIN 69910: Wertanalyse. Begriffe, Methoden. Ö N O R M A6750

MATRX - Matrixanalyse Lernziele Sie kennen die Struktur von Matrizen, können Matrizen aufbauen, die Beziehungen zwischen den Elementen zweier Mengen darstellen und interpretieren. Sie kennen eine Vorgehensweise bei der Anwendung der Matrixanalyse. Sie kennen wichtige Operationen des Matrizenkalküls, mit denen die Matrixanalyse erweitert werden kann. Sie können die Anwendung der Matrixanalyse erläutern und die Matrixanalyse auf typische Aufgaben von IuK-Projekten anwenden. Definitionen und Abkürzungen Analyse (analysis) = die möglichst exakte Bestimmung und Charakterisierung von Teilen eines Systems (eines Ganzen) sowie der Beziehungen der Teile untereinander und zum Ganzen, mit dem Zweck, das Ganze zu erklären. Cluster (cluster) = die Häufung einer Menge gleichartiger Elemente. Element (element) = ein durch Zerlegung bestimmter Teil eines Systems, der im betrachteten Zusammenhang nicht weiter zerlegt werden kann oder soll. Hauptdiagonale (main diagonal) = die von links oben nach rechts unten verlaufende Diagonale einer Matrix mit den Elementen gleicher Indizes. Kehrmatrix (inverse matrix) = die durch Inversion entstehende Matrix. Synonym: inverse Matrix. Koeffizient (coefficient) = eine Zahl oder eine Funktion, mit der eine Variable multipliziert wird. Matrix (matrix) = ein orthogonales, in Zeilen und Spalten strukturiertes Schema; die m Zeilen und n Spalten bestimmen die Dimension (Typ) der Matrix. Menge (set) = eine definierte Menge von Elementen. Mnemo (mnemo) = eine das Gedächtnis unterstützende Bezeichnung zur Identifizierung eines Objekts, quadratische Matrix (square matrix) = eine Matrix mit n Zeilen und n Spalten. Skala (scale) = eine Menge von Symbolen oder Zahlen, die so zusammengesetzt ist, daß die Symbole oder Zahlen - unter der Verwendung von Regeln - den Phänomenen aufgrund der zu messenden Eigenschaften zugeordnet werden können, also ein Meßinstrument. Skalieren (scale) = das Abbilden betriebswirtschaftlicher, sozialer, psychologischer usw. Phänomene auf eine nominale, ordinale oder kardinale Skala. Struktur (structure) = die vom Detail losgelöste, auf die wesentlichen Merkmale eines Systems reduzierte Darstellung, welche den Charakter des Systems als Ganzes offenbart. symmetrische Matrix (Symmetrie matrix) = eine quadratische Matrix, die ihrer Transponierten gleich ist (oder: deren zur Hauptdiagonale spiegelbildlich liegenden Elemente gleich sind), transponierte Matrix (transposed matrix) = eine Matrix, die aus einer gegebenen Matrix durch das Vertauschen von Zeilen und Spalten entsteht. Synonym: gespiegelte Matrix.

332

Analysemethoden

Zweck der Matrixanalyse Folgende Situation ist bei IuK-Projekten häufig anzutreffen: Zwei Mengen mit ihren Elementen sind gegeben, und es sollen die Beziehungen zwischen den Elementen dieser Mengen dargestellt werden (z.B. als Ergebnis der Istzustandserfassung oder als Entwurfsergebnis). Die Beziehungen sollen dann untersucht werden, um Istzustände zu analysieren und/oder Entwurfskonzepte zu überprüfen. Eine geeignete Methode für diese Art von Aufgabe ist die Matrixanalyse; sie verwendet als Darstellungsmittel Matrizen. Struktur der Matrizen Matrizen haben die folgende Struktur: Die Elemente der Menge A werden in die Kopfzeile (rechter oberer Quadrant), die Elemente der Menge B in die Kopfspalte (linker unterer Quadrant) geschrieben. Der linke obere Quadrant enthält die Benennung der Matrix, die Legende der Abhängigkeitstypen und die hierfür verwendeten Symbole und Abkürzungen. Im rechten unteren Quadranten werden die Beziehungen zwischen den Elementen der Mengen A und B eingetragen. Abbildung MATRX-1 zeigt die Struktur der Matrizen.

Elemente der Menge B

Benennung der Matrix Legende

Elemente der Menge A Ai

A

J

An

B i

Bi

B

r

ij

m

Abb. MATRX-1 : Struktur der Matrix

Für die Abbildung der Beziehungen zwischen den Elementen können Skalen mit nominalem, ordinalem oder kardinalem Niveau verwendet werden. • Nominale Skala: Die Elementebeziehungen werden zwei oder mehr Kategorien zugeordnet. Die Feldwerte sind mit den Bezeichnungen der Kategorien identisch. Die Verwendung von Mnemos als Bezeichnung der Kategorien ist empfehlenswert. Die nominale Skala eignet sich für Aufgaben, bei denen eine verbale Analyse genügt oder für die keine quantitativen Daten verfügbar sind. Numerische Beziehungen zwischen Feldwerten können nicht abgebildet werden. • Ordinale Skala: Die Elementebeziehungen werden in eine vollständige Ordnung gebracht; die Feldwerte sind die Ordnungszahlen 1 bis n bei n zu ordnenden Elementen. Die ordinale Skala eignet sich für Aufgaben, bei denen die Ordnungsbeziehungen der Elemente einer Menge A bezüglich der Elemente

MATRX - Matrixanalyse

333

einer Menge B im Mittelpunkt des Interesses stehen. Numerische Beziehungen zwischen Feldwerten können nur unter der Annahme abgebildet werden, daß die Differenzen zwischen zwei Ordnungszahlen stets gleich sind. • Kardinale Skala: Die Feldwerte sind mit der quantitativen Ausprägung der Elementebeziehungen identisch. Die kardinale Skala eignet sich für Aufgaben, bei denen die numerischen Beziehungen zwischen den Feldwerten von Bedeutung sind. Vorgehensweise bei der Matrixanalyse Die Vorgehensweise bei der Matrixanalyse kann mit den folgenden vier Arbeitsschritten beschrieben werden: Ordnen der Mengen A und B, Festlegen des Skalenniveaus, Zuordnen der Feldwerte und Interpretieren der Matrix. • Erster Arbeitsschritt: Ordnen der Mengen A und B. Die Elemente der Mengen A und B, deren Beziehungen analysiert werden sollen, werden durch Verändern der Reihenfolge der Elemente oder durch Hinzufügen, Weglassen, Zusammenfassen oder Verändern von Elementen in eine zweckmäßige Ordnung gebracht. • Zweiter Arbeitsschritt: Festlegen des Skalenniveaus. Das Skalenniveau der in die Matrixfelder einzutragenden Beziehungen wird festgelegt, und es werden die Beziehungen skaliert. Die Wahl des Skalenniveaus ist vom Analysezweck und von der Verfügbarkeit von Daten in dem gewünschten Skalenniveau abhängig. • Dritter Arbeitsschritt: Zuordnen der Feldwerte. Entsprechend dem gewählten Skalenniveau werden die Werte der Beziehungen der Elemente der Menge A zu den Elementen der Menge B in die Felder der Matrix eingetragen. • Vierter Arbeitsschritt: Interpretieren der Matrix. Feldwerte können zeilenweise oder spaltenweise untereinander mit einer zweckmäßigen Vorschrift verknüpft, mehrere Zeilen oder Spalten können jeweils zusammengefaßt werden. Häufig erweist es sich als zweckmäßig, Cluster von Feldwerten weiter zu gliedern und je einen Cluster in einer eigenen Matrix abzubilden. Weiterführende Varianten der Matrixanalyse Unter bestimmten Voraussetzungen ist es von Vorteil, mehrere Matrizen mit Hilfe mathematischer Matrizenoperationen zu verknüpfen. Einfache mathematische Matrizenoperationen sind: • Addition und Subtraktion: Die Summe/Differenz C von zwei mn-Matrizen A = (a j k ), B = (bik) ist C = A +/- B = (c i k ) mit (c ik ) = (a i k ) +/- (b ik ). Es können nur Matrizen gleichen Typs addiert oder subtrahiert werden. • Skalare Multiplikation: Setzt man in der Summendefinition B = A und schreibt A + A = 2A, dann kommt man zur Definiton der skalaren Matrizenmultiplikation. Das Produkt kA oder Ak einer mn-Matrix A mit einer Zahl k (einem Skalar) ist die mn-Matrix, bei der jedes Element das k-fache des entsprechenden Elements von A ist. Ein allen Elementen gleicher Faktor läßt sich daher vor die Matrix ziehen. • Eine häufig angewendete Matrizenoperation ist der Übergang zur transponierten Matrix; sie geht aus der gegebenen Matrix A = (ai k ) durch Vertauschung

334

Analysemethoden

von Zeilen und Spalten hervor. Bei quadratischer Matrix entspricht dies einem Spiegeln an der Hauptdiagonalen (gespiegelte Matrix). Aus einem Spaltenvektor wird durch Transponieren ein Zeilenvektor und umgekehrt. • Matrizenmultiplikation: Kern des Matrizenkalküls ist die Matrizenmultiplikation. Das Produkt AB aus einer mn-Matrix A und einer np-Matrix B in der angegebenen Reihenfolge ist die mp-Matrix C = AB, deren Elemente cjk als skalare Produkte aus der i-ten Zeile von A (des Zeilenvektors a') und der k-ten Spalte von B (dem Spaltenvektor bk) gebildet werden. Zur Berechnung der m p Elemente Cilc der Produktmatrix C sind also m-p-n Einzelprodukte zu bilden (was bei größeren Matrizen nur mit Hilfe eines Werkzeugs möglich ist). Diese Operationen sind nur bei Matrizen mit kardinal skalierten Feldwerten möglich. Die Feldwerte können dann als Koeffizienten eines linearen Gleichungssystems aufgefaßt werden. Bei IuK-Projekten liegt häufig eine Aufgabe vor, für deren Bearbeitung die Matrizenmultiplikation verwendet werden kann. Damit werden die in einer Matrix R abgebildeten Beziehungen der Elemente der Mengen A und B und die in einer Matrix S abgebildeten Beziehungen der Elemente der Mengen B und C in eine Matrix E transformiert, welche die Beziehungen der Elemente der Menge A zu den Elementen der Menge C angibt. Prüfmatrix Dabei handelt es sich um eine spezielle Form der Matrix, mit der die Beziehungen zwischen den Symptomen (Stärken und Schwächen) und ihren Ursachen (Symptom/Ursache-Beziehung) herausgearbeitet werden. 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 Si und der Ursache Uj eine Beziehung derart besteht, daß Sj durch Uj verursacht wird; sonst ist p j j = 0. Abbildung MATRX-2 zeigt die Struktur der Prüfmatrix. Ursachen Symptome" --.

U,

u

i

Un

Si

Si

PÜ

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

Die Tatsache, daß eine Symptom/Ursache-Beziehung 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

MATRX - Matrixanalyse

335

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. In Ergänzung zur Prüfmatrix kann die Metaplan-Technik angewendet werden, mit deren Hilfe in Gruppendiskussionen von den Projektmitarbeitern und den Benutzern 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. Demonstrationsbeispiel Es wird die Anwendung der M a t r i z e n m u l t i p l i k a t i o n gezeigt. Gegeben sind die Beziehungen zwischen der Menge A = Aufgabenträger und der Menge B = Aufgaben mit kardinalen Eintragungen. Sie dokumentieren, welchen Aufgabenträgern welche Aufgaben zugeordnet und wie häufig diese Aufgaben in einem bestimmten Zeitabschnitt von den Aufgabenträgern durchgeführt werden sollen. Dies zeigt die Matrix R in Abbildung MATRX-3. Aufgaben Matrix R

Aufgabenträger

A,

T

t

2

3

A4

A

5

Aö

5

60

10 20

3 4

A

20

T, T2

A

5

30

Abb. MATRX-3: Matrix R Aufgabenträger/Aufgaben

Gegeben sind weiter die Beziehungen zwischen der Menge B = Aufgaben und der Menge D = Datenobjekte mit kardinalen Eintragungen. Sie dokumentieren, welche A u f g a b e n welche Datenobjekte verwenden und wie häufig die Datenobjekte in einem bestimmten Zeitabschnitt von den Aufgaben benötigt werden. Dies zeigt die Matrix S in Abbildung MATRX-4.

336

Analysemethoden

Datenobjekte

Matrix S o. Ai

1

Aufgaben

03

o

4

3 2

A5

1

A6

4

5

2

2

A4

o

3 4

A2 A3

o2

6

6

1

Abb. MATRX-4: Matrix S Aufgaben/Datenobjekte

Die durch skalare Matrizenmultiplikation (R x S) ermittelte Matrix E mit der Menge A = Aufgabenträger und der Menge D = Datenobjekte macht Aussagen darüber, wie häufig welche Aufgabenträger auf welche Datenobjekte in dem betrachteten Zeitabschnitt zugreifen werden. Dies zeigt die Matrix E in Abbildung MATRX-5. Sie kann unter anderem zur Festlegung der Z u g r i f f s b e rechtigung der Aufgabenträger auf Datenobjekte verwendet werden. Der implizit in den Matrizen R und S vorhandene Zusammenhang (Beziehung und Häufigkeit der Beziehungen) zwischen Aufgabenträgern und Datenobjekten wurde also durch eine skalare Matrizenmultiplikation mit der Matrix E als Ergebnismatrix sichtbar gemacht. Datenobjekte

Aufgabenträger

Matrix E OL

O2

TI

5

80

T2

100

T3

5

T4

O3

120

O5

40 180

40

o4

60

10

12 60

Abb. MATRX-5: Matrix E Aufgabenträger/Datenobjekte

MATRX - Matrixanalyse

337

Kontrollfragen 1. 2. 3. 4. 5.

Welche grundsätzliche Struktur haben Matrizen? Von welchen Einflußfaktoren hängt die Wahl des Skalenniveaus für die Matrixelemente ab? Unter welchen Voraussetzungen können zwei Matrizen durch skalare Matrizenmultiplikation verknüpft werden? Für welche Aufgaben bei IuK-Projekten ist die Matrixanalyse geeignet? Entwickeln Sie ein Anwendungsbeispiel analog zum Demonstrationsbeispiel mit der Matrix R = Beziehungen zwischen Benutzern und Struktureinheiten und der Matrix S = Beziehungen zwischen Struktureinheiten und Aufgaben.

Quellenliteratur Heinrich, L. J.: Systemplanung 2 Bd. 6. A. (Bd. 1) bzw. 5. A. (Bd. 2), Oldenbourg, München/ Wien 1994 Zurmühl, R.: Matrizen und ihre technischen Anwendungen. 4. A., Springer, Berlin et al. 1964 Vertiefungsliteratur 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

INTER - Interaktionsanalyse Lernziele Sie kennen den Zweck der Interaktionsanalyse. Sie wissen, warum die Befragung als Erhebungstechnik nicht ausreicht und wie die Interaktionsanalyse in andere Formen der Beobachtung und der Analyse des Beobachteten eingebettet ist. Sie kennen die Videobeobachtung als Methode der Datenerhebung für die Interaktionsanalyse. Sie wissen, wie videobasiertes Material in Review Sessions und im Interaktionsanalyse-Labor analysiert werden kann. Sie können die Brauchbarkeit der videobasierten Interaktionsanalyse für die Projektarbeit beurteilen. Definitionen und Abkürzungen Artefakt (artefact) = ein von Menschen hergestellter Gegenstand, im engeren Sinn ein Werkzeug (lat. arte factum = mit Kunst gemacht). 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). Dauerbeobachtung (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). Fragebogen (questionnaire) = eine geordnete Menge von Fragen, die von den Befragten schriftlich beantwortet werden. IA = Akronym für Interaction Analysis (Interaktionsanalyse). I A L = Akronym für Interaction Analysis Laboratory (InteraktionsanalyseLabor). Interview (interview) = eine - je nach Interviewform - mehr oder weniger geordnete Menge von Fragen, die von den Befragten mündlich beantwortet werden. I R L = Akronym für Institute for Research on Learning. I W I / I E = Akronym für Institut für W irtschaftsinformatik / I n f o r m a t i o n Engineering der Universität Linz, offene Beobachtung (open Observation) = eine Beobachtung, die für den Beobachteten erkennbar ist; im Gegensatz dazu: verdeckte Beobachtung. P A R C = Akronym für Palo Alto Research Center. passive Beobachtung (passive Observation) = eine Beobachtung, die ohne die Mitwirkung des Beobachters bei der Aufgabendurchführung erfolgt; im Gegensatz dazu: aktive Beobachtung. Videobeobachtung (video Observation) = eine passive, offene und indirekte Beobachtung, welche die Videokamera (mit Mikrofon) als Sachmittel verwendet.

INTER - Interaktionsanalyse

339

Zweck der Interaktionsanalyse Eines der Hauptprobleme bei der Analyse von Arbeitssituationen ist, daß erfahrungsgemäß ein erheblicher Unterschied zwischen dem besteht, was Menschen tatsächlich tun und dem, was sie denken und sagen, daß sie tun. Es reicht daher zum Verständnis der aktuellen Arbeitssituation nicht aus, mit B e f r a g u n g (mündlich als Interview und/oder schriftlich mit Fragebogen) Daten zu erheben und diese zu analysieren. Durch Befragung erhobene Daten und darauf aufbauende Analysen messen in der Regel nicht das, was sie vorgeben zu messen; sie sind nicht valide. Interaktionsanalyse ist die in die Tiefe gehende Mikroanalyse der Art und Weise, in der Menschen untereinander, mit ihrer physikalischen Umgebung und mit Dokumenten, Artefakten und Techniken in dieser Umgebung interagieren. Wie die Ethnographie im allgemeinen, sucht die Interaktionsanalyse nach Ordnungen und Mustern in den Interaktionen zwischen Menschen und Sachmitteln. Sie ist dabei kein isoliert verwendetes Analyseinstrument, sondern in andere Formen der Beobachtung und der Analyse des Beobachteten eingebettet. Mit aktiver Beobachtung im Feld werden "hot spots" identifiziert, das heißt problematische Sequenzen im Arbeitsablauf, die mit bloßer Beobachtung oder Befragung nicht einfach zu verstehen sind. Detaillierte Mikroanalysen dieser Sequenzen konzentrieren sich systematisch auf die Art und Weise, in der die Beteiligten die ihnen zur Verfügung stehenden sozialen und technischen Ressourcen benutzen, um ihre Arbeit auszuführen, und ermöglichen dadurch ein tiefer gehendes Verständnis des Arbeitsprozesses in einem interaktiven System. Videobeobachtung Die Erhebungstechnik für die Interaktionsanalyse ist die Videobeobachtung (deshalb auch: video-basierte Interaktionsanalyse). Vorteil der Beobachtung generell gegenüber anderen Erhebungstechniken (wie Befragung und Dokumentenanalyse) ist, daß die Datenerhebung zum tatsächlichen Zeitpunkt bzw. im Zeitraum der Aufgabendurchführung erfolgt; sie ermöglicht daher den unmittelbaren und direkten Einblick des Beobachters in den Untersuchungsbereich. Nachteile der Beobachtung sind der hohe Zeitaufwand (sowohl für die benötigte gründliche Vorbereitung als auch für die Durchführung), die psychische Belastung der Beobachteten (Beobachtungen können auch als Eingriff in die Privatsphäre empfunden werden, was besonders auf die Videobeobachtung zutrifft) und die damit im Zusammenhang stehende Gefahr von Verhaltensänderungen der Beobachteten (Beobachter 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 und Sachmitteln, zwischen denen zahlreiche Interaktionen stattfinden, gekennzeichnet ist, also in stark arbeitsteiligen, kooperativen und komplexen Arbeitssituationen.

340

Analysemethoden

Videobasierte

Interaktionsanalyse

Sie verwendet das durch Videobeobachtung erfaßte Datenmaterial und konzentriert sich auf die Interaktionen zwischen den Aufgabenträgern im Untersuchungsbereich sowie zwischen diesen und den von ihnen verwendeten Sachmitteln. Der Ablauf einer videobasierten Interaktionsanalyse kann wie folgt beschrieben werden: Zunächst wird eine Analyse des gesamten Videomaterials durchgeführt, deren Ziel 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 sich der Beobachter erinnert, aus. Das Videomaterial wird erneut betrachtet, um diese Ereignisse gezielt zu beobachten. Dazu werden bestimmte Sequenzen des Arbeitsablaufs 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 durch eine erneute Videobeobachtung oder andere Erhebungstechniken 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 können. Video Review Sessions Wenn immer möglich, werden die Mitarbeiter des beobachteten und analysierten Untersuchungsbereichs eingeladen, an der Videoanalyse teilzunehmen und ihre eigenen speziellen Einsichten einzubringen. Diese repräsentieren die Perspektive der Betroffenen, ihre Sicht der Wirklichkeit, die von der verschieden sein kann, welche die Analysten haben. Der wesentliche Wert dieser Sitzungen liegt jedoch darin, es den Betroffenen und den Analysten zu ermöglichen, ein gemeinsames Verständnis für das zu erarbeiten, was wirklich vorgeht. Sie bieten den Analysten die Möglichkeit, detaillierte Fragen über die Arbeitssituation zu stellen, was in der realen Arbeitsumgebung meist unmöglich ist. Videobasierte Antworten der Betroffenen haben den Vorteil, sehr viel näher an den aktuellen Ereignissen zu sein. Statt beispielsweise Programmierer über ihre Arbeitssituation zu interviewen (oder, noch entfernter, sie einen Fragebogen ausfüllen zu lassen), können sie aufgefordert werden, ein während der Arbeit aufgezeichnetes Video von sich selbst oder von anderen Programmierern anzusehen und Fragen über die Arbeitssituation zu stellen und zu beantworten bzw. beantworten zu lassen. So gewonnene Daten sind vermutlich eher zu verallgemeinern und auf die reale Arbeitssituation zu beziehen als Daten, die unter künstlichen Bedingungen (z.B. in Laborsituationen) gewonnen werden. Der Durchführung von Video Review Sessions stehen allerdings häufig praktische Schwierigkeiten entgegen (insbes. wegen des hohen Zeitaufwands und wegen des häufigen Personalwechsels).

INTER - Interaktionsanalyse

341

Videokamera-Effekte In welchem Ausmaß die Beobachteten durch die Anwesenheit einer Videokamera beeinflußt werden, ist eine empirische Frage, die nicht prinzipiell beantwortet werden kann. Sie muß aber bei jedem Einsatz einer Videokamera untersucht werden. Daß eine Beeinflussung stattfindet, kann auf dem Video beobachtet werden, beispielsweise in Form von sichtbaren Hinweisen auf oder Bemerkungen über die Videokamera durch die Beobachteten. Die Erfahrung zeigt allerdings, daß sich die Beobachteten erstaunlich schnell an die Videokamera gewöhnen, besonders dann, wenn sie operatorlos verwendet wird. Wo immer Menschen intensiv mit dem beschäftigt sind, was sie tun, verschwindet die Tatsache, daß eine Videokamera anwesend ist, ziemlich schnell aus ihrem Bewußtsein. Dabei hilft es, daß den Beobachteten verbindlich zugesagt wird, daß ihre Vorgesetzten das Video nicht ohne ihre ausdrückliche Erlaubnis zu sehen bekommen und daß sie verlangen können, das Video zu vernichten. Interaktionsanalyse-Labor Eine besondere Art der videobasierten Interaktionsanalyse, wie sie beispielsweise am PARC und am IRL - und in vereinfachter Form auch am IWI/IE - verwendet wird, ist das Interaktionsanalyse-Labor. Es besteht aus einer Gruppe von Wissenschaftlern verschiedener Disziplinen (z.B. Wirtschaftsinformatik, Betriebswirtschaftslehre, Soziologie und Psychologie) aus Wissenschaft und Praxis, die sich wöchentlich zu gemeinsamen Analysen von Videos treffen, die einzelne von ihnen angefertigt haben. Es bietet den Mitgliedern und Gästen ein Forum für videobasierte Forschung, dessen Zweck auch darin besteht, die Methode weiter zu entwickeln. Beurteilung der video-basierten

Interaktionsanalyse

Eine Beurteilung der videobasierten Interaktionsanalyse kann mit den folgenden Feststellungen gegeben werden (nach B. Jordan): • Ständige Datenverfügbarkeit mit der Möglichkeit, sowohl in einer Laborsituation (wie im IAL), als auch individuell durch einzelne Analysten, die Aufzeichnung beliebig häufig anhören und ansehen zu können. Es können Details von Interaktionen erkannt werden, die sonst unentdeckt bleiben würden. Ein Video kann langsam oder schnell abgespielt werden. Dadurch können andere, sonst unsichtbar bleibende Muster der Bewegungen von Personen und Artefakten erkannt werden. Die Analyse kann in mehrere Analysezyklen zerlegt werden. • Erfassung komplexer Daten, wie insbesondere sich überlappende Tätigkeiten mehrerer Personen, die auch geübte Beobachter bei direkter Beobachtung mit ausreichender Genauigkeit nicht erfassen können. In einer Arbeitssituation mit mehreren aktiven Personen besteht bei direkter Beobachtung zudem das Problem zu entscheiden, auf wen sich die Beobachtung konzentrieren soll. Viele Aktivitäten können gar nicht in Worte gefaßt und schriftlich dokumentiert werden, sowohl wegen der Dichte der Aktivitäten als auch deshalb, weil für bestimmte Phänomene das geeignete Vokabular zu ihrer Beschreibung fehlt.

342

Analysemethoden

• Vermeidung von Vorurteilen der Beobachter über das, was sie als wichtig und was sie als unwichtig ansehen und was sie daher vielleicht übergehen. Die Videokamera zeichnet Ereignisse so auf, wie sie tatsächlich stattfinden, und zwar mit allen Details. • Vermeidung von Vorurteilen individueller Analysten durch ein interdisziplinäres T e a m . Einzelne Analysten sind häufig konditioniert, bestimmte Dinge so zu sehen, wie sie sie zu sehen wünschen. Dieser Tendenz kann durch die Analystengruppe entgegen gewirkt werden. • Vermeidung von Sagen/Tun-Unterschieden; die Aufzeichnung durch ein Video ist so nahe an der Wirklichkeit, daß es nur eine Sicht auf die Wirklichkeit gibt. • A u f d e c k u n g von Hintergründen, Folgerungen und Lösungsalternativen, von denen aus Hinweise für Veränderungen erkannt werden können. Grundlegende A n n a h m e n über die Arbeitsbedingungen, die normalerweise nicht artikuliert werden, können sichtbar gemacht werden. • Die Analyse kann von der Beobachtung zeitlich und räumlich abgekoppelt d u r c h g e f ü h r t werden. • Das Analysematerial vermittelt auch die Dynamik des untersuchten Systems, da die Zeitpunkte des Eintreffens wesentlicher Ereignisse vorliegen. • An der Analyse können Experten verschiedener Fachrichtungen teilnehmen. Vor dem Hintergund dieser Vorteile der video-basierten Interaktionsanalyse m u ß berücksichtigt werden, daß sie zeitraubend und teuer ist. Dies insbesondere deshalb, weil es schwierig ist, Videomaterial mit anderem Beobachtungsmaterial zu integrieren. Mit der sich abzeichnenden Verfügbarkeit von Technologien zur Erläuterung, Kommentierung und Synchronisation von Datenmaterial, das durch v e r s c h i e d e n e M e t h o d e n erhoben wurde, wird die videobasierte Interaktionsanalyse in Z u k u n f t leichter anwendbar sein und große Verbreitung finden. Kontrollfragen 1. 2. 3. 4. 5.

Welchem Zweck dient die videobasierte [nteraktionsanalyse? Welchen Vorteil hat die Videobeobachtung gegenüber anderen Beobachtungsformen? Wie ist die Videobeobachtung in andere Beobachtungsformen eingebettet? Wie können Videokamera-Effekte vermieden werden? Worin bestehen die Nachteile der videobasierten Interaktionsanalyse?

Quellenliteratur Jordan, B.: Ethnographie Workplace Studies and Computer Supported Cooperative Work. IRL Report 94-0026, June 1994 Suchman, L. A./Trigg, R. H.: Understanding Practice: Video as a Medium for Reflection and Design. In: Greenbaum, J./Kyng, M.: Design at Work. Lawrence Erlbaum Associates, Hillsdale/NJ 1991,65 - 8 9 Vertiefungsliteratur Ball, S. M./Smith, G. W. H.: Analyzing Visual Data. SAGE Publ., Newbury/CA et al. 1992 Goldman-Segall, R.: Interpreting Video Data: Introducing a "Significance Measure" to Layer Description. In: Journal of Educational Multimedia and Hypermedia 2/1993, 261 - 281 Jordan, B./Henderson, A.: Interaction Analysis. Foundations and Practice. IRL Report 94-0027, July 1994

KOMAN - Kommunikationsanalyse Lernziele Sie kennen die Methoden der Kommunikationsanalyse. Sie können den Zweck jeder dieser Methoden nennen und ihre Konzeption erläutern. Sie können in einer konkreten Analysesituation durch Abwägen der Vorteile und der Nachteile der Methoden eine optimale Kombination von Methoden der Kommunikationsanalyse bilden und bei der Projektarbeit 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. Empfänger (receiver) = der Endpunkt einer transportierten Information. E n t f e r n u n g s m a t r i x (distance matrix) = eine Matrix mit allen Ecken eines Graphen in den Zeilen und in den Spalten, deren Elemente die Anzahl der Kanten enthalten, die zwischen den Ecken bestehen, 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. O r g a n i s a t i o n s s t r u k t u r (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. Topologie (topology) = die Lehre von der Anordnung geometrischer Gebilde im Raum; stellt die Kommunikationswege abstrakt dar.

344

Analysemethoden

Zweck der Methoden der Kommunikationsanalyse Zweck der Methoden der Kommunikationsanalyse ist es, in der Projektphase Feinstudie das Analysieren des Istzustands des Kommunikationssystems zu unterstützen, insbesondere das 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 IuK-System, 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 bei Projektaufgaben von besonderer Bedeutung, bei 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 IuK-Projekt bestimmte 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 Kommunikationsmittel-Planung sowie das Erkennen von Störungen in Kommunika-

KOMAN - Kommunikationsanalyse

345

tionsbeziehungen). Von wirtschaftlicher Bedeutung sind Erkenntnisse über den Wert und die Wichtigkeit der Kommunikation. Nur auf Grundlage solcher Erkenntnisse kann entschieden werden, ob Kommunikationsbeziehungen überflüssig oder überdimensioniert sind, oder ob Kommunikationsbeziehungen von großem Wert und hoher Wichtigkeit unterentwickelt sind oder sogar fehlen. Diese Information liefern die Methoden der Kommunikationsanalyse aber nicht.

Kommunikationstabelle Eine Kommunikationstabelle dient zur Analyse der Kommunikationsbeziehungen zwischen Stellen in einzelnen Struktureinheiten. In einer Kommunikationstabelle werden je Stelle folgende Attribute tabellenartig abgebildet: • • • •

Kommunikationsarten, Kommunikationspartner, Kommunikationsdauer, Kommunikationshäufigkeit.

Die Kommunikationstabelle entsteht zeilenweise nach Kommunikationspartnern, spaltenweise nach Kommunikationsarten. In jedem Feld der Tabelle wird nach Anzahl der Kommunikationsvorgänge (h), durchschnittliche Zeitdauer j e Kommunikationsvorgang (t) und Zeitdauer je Kommunikationsart T (T = Anzahl der Kommunikationsvorgänge x durchschnittliche Zeitdauer j e Kommunikationsvorgang) unterschieden (vgl. Abb. KOMAN-2). Die gleiche Tabellenstruktur kann verwendet werden, um die Kommunikationsarten (mündliche /schriftliche Kommunikation oder elektronische Kommunikation) abzubilden, indem die Häufigkeitsangaben und die Mengenangaben durch Kürzel für die einzelnen Kommunikationsarten ersetzt werden.

Kommunikationsbeziehungen der Stelle X mit den Stellen Yj bis Y m

Kommunikationsarten K

,

K. i

K

n

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

Yi

Yi

Ym h = Anzahl der Kommunikationsvorgänge l = durchschnittliche Zeitdauer j e Kommunikations vorgang

T = h •t

Abb. K O M A N - 2 : Kommunikationstabelle

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

346

Analysemethoden

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 Fertigung Arbeitsvorbereitung Werkzeugbau Technische Revision Einkauf Materiallager Verkauf Fertigung und Versand Werbung Verkauf Inland Export Kundendienst Verwaltung Buchhaltung Finanzen Planung Personal Allgemeine Dienste Abb. K O M A N - 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: • Kommunikationszeit oder Kommunikationshäufigkeit je Periode zwischen den Struktureinheiten,

KOMAN - Kommunikationsanalyse

347

• 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 zugrunde gelegt. 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 - 10 Stunden — 1 1 - 1 5 Stunden mm 1 6 - 20 Stunden fflü 2 1 - 2 5 Stunden Ü B 26 - 30 Stunden | 31 - 35 Stunden H

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. Kommunikationsmatrix Bei der Abbildung von Kommunikationsbeziehungen mit einer Kommunikationsmatrix sind zwei Formen zu unterscheiden. Die erste Form der Kommunika-

348

Analysemethoden

tionsmatrix dient zur Darstellung der Häufigkeit (h) und der Dauer (t) der K o m munikationsvorgänge, wobei in den Zeilen die E m p f ä n g e r 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 K O M A N - 5 zeigt ein Beispiel. N v

Unternehmensleitung

Sender

Empfänger

^

h

Verkauf

t

Unternehmensleitung

Beschaffung

Fertigung

Verwaltung

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 Form der Kommunikationsmatrix (Quelle: Wittlage)

Die zweite F o r m der Kommunikationsmatrix unterstützt über Strukturparameter den Entwurf von kommunikationsorientierten Organisationsstrukturen. Die Bezeichnungen der Zeilen und der Spalten sind dieselben wie bei der ersten F o r m der Kommunikationsmatrix. Die Feldwerte der zweiten Form sind 1 und 0, w o bei 1 f ü r "direkte K o m m u n i k a t i o n s b e z i e h u n g v o r h a n d e n " und 0 f ü r "keine direkte Kommunikationsbeziehung vorhanden" steht. Abbildung K O M A N - 6 zeigt ein Beispiel. X]

X 1 *2 x3 x4

l

1 1 0 01

x2

x3

x4

x5

x6

1

0 1

0 1 1

1 0 0 1

1 1 1 0 1

-

1 1 0 0

-

0 1 1

-

1 0

-

1

-

X i = Struktureinheiten Abb. K O M A N - 6 : Zweite Form der Kommunikationsmatrix (Quelle: Wittlage)

Vorteile der Kommunikationsmatrix sind die Möglichkeit zur detaillierten Darstellung der Kommunikationsrichtungen und - insbesondere in der zweiten F o r m - die M ö g l i c h k e i t zur rechnerischen G e w i n n u n g von A n a l y s e a u s s a g e n . D e r 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. Mit Matrizenoperationen kann die zweite Form der Kommunikationsmatrix in eine Adjazenzmatrix überführt werden.

KOMAN - Kommunikationsanalyse

349

Graphentheoretische Maßzahlen Aus der Adjazenzmatrix A(D) lassen sich Aussagen über bestimmte Eigenschaften des Kommunikationssystems gewinnen (z.B. über den Eingangsgrad und über den Ausgangsgrad). Die meisten graphentheoretischen Maßzahlen gehen von der Entfernung zwischen zwei Ecken aus, wobei als Entfernung die "Länge des kürzesten Weges zwischen zwei Ecken" verstanden wird. Die Entfernungen werden im allgemeinen in einer E n t f e r n u n g s m a t r i x E(D) abgebildet; sie werden entweder (bei einfachen Graphen) direkt aus dem Graphen abgelesen oder (bei komplexen Graphen) mit Hilfe mathematischer Verfahren (z.B. mit dem Verfahren von Hasse) rechnerisch ermittelt. Auf Grundlage der Adjazenzmatrix A(D) und der Entfernungsmatrix E(D) lassen sich graphentheoretische Maßzahlen formulieren, die in zwei Gruppen gegliedert werden können: a) Maßzahlen, welche die relative Position einer Systemkomponente im Kommunikationssystem kennzeichnen (1. bis 4. der nachfolgenden Aufzählung) und b) Maßzahlen, welche das Kommunikationssystem insgesamt charakterisieren (5. bis 9. der nachfolgenden Aufzählung). • 1. Der Eingangsgrad aj einer Systemkomponente vj und der Ausgangsgrad aj einer Systemkomponente vj, d.h. die Anzahl der von Vj ausgehenden Kommunikationswege (= Zeilensumme der i-ten Zeile von A(D)) bzw. die Anzahl der in vj eingehenden Kommunikationswege (= Spaltensumme der j-ten Spalte von A(D)). • 2. Die größte Entfernung bj einer Systemkomponente vj zu allen anderen Systemkomponenten (= Maximum der i-ten Zeile von E(D)). • 3. Die relative Zentralität ci einer Systemkomponente vj, d.h. das Verhältnis der Summe aller Entfernungen innerhalb des Kommunikationssystems (Dispersion, siehe auch unter 5.) zur Summe der Entfernungen von vi zu allen anderen Systemkomponenten des Kommunikationssystems (= Quotient aus der Summe aller Elemente von E(D) und der Summe der Elemente der i-ten Zeile von E(D)). • 4. Die relative Randposition oder die relative Außenposition dj einer Systemkomponente vj, d.h. die Differenz zwischen der maximalen Zentralität des Kommunikationssystems und der v; zugehörigen Zentralität. • 5. Die Dispersion D, d.h. die Summe aller Entfernungen im Kommunikationssystem (= Summe aller Elemente von E(D)). • 6. Der Diameter d, d.h. die größte Entfernung innerhalb des Kommunikationssystems (= größter Wert in E(D)). • 7. Die Existenz eines Zentrums, d.h. einer Systemkomponente Vj, deren größte Entfernung zu allen anderen Systemkomponenten (also deren bj) ein Minimum ist (= Minimum der Zeilen- bzw. Spaltenmaxima in E(D)). • 8. Der Radius r, d.h. die größte Entfernung vom Zentrum zu irgendeiner anderen Systemkomponente, also die größte Entfernung des Zentrums (= Maximum der dem Zentrum entsprechenden Zeile in E(D)). • 9. Die Existenz von Zerlegungspunkten, d.h. solcher Systemkomponenten, bei deren Wegfall das Kommunikationssystem in mehrere Teilsysteme zerfällt.

350

Analysemethoden

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 •

—

1 1 - 1 5 Stunden/Monat

mmmm 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. Kommunikationsnetze eignen sich zur Darstellung nahezu aller Kommunikationssysteme. Demonstrationsbeispiel Für das in Abbildung KOMAN-8 gezeigte logische Modell eines Kommunikationssystems, das im Sinn der Graphentheorie ein Digraph ist, werden zunächst die Adjazenzmatrix A(D) und die Entfernungsmatrix E(D) ermittelt (vgl. Abbildung KOMAN-9). Von den Informationen dieser beiden Matrizen ausgehend, werden die Werte der graphentheoretischen Maßzahlen errechnet und in Abbildung KOMAN-IO dargestellt.

KOMAN - Kommunikationsanalyse

10 1 1 0 0

V1

1 0 1 0 0 0

1 1 0 1 1 0

0 0 1 0 0 0

10

0 0 1 0 0 0

0 0 0 0

°J

Abb. KOMAN-9: Adjazenzmatrix V] aj

V2

v3

3

2

4

3

2

4

v4

2 2 1 0 2

2 2 1 2 0

3

3

n 2 2

3 3

V

1 1

" ¡ 2 ci 7,4

2 6,5

2 8,7

3 5,2

3 5,2

3 4,8

di

2,2

0

3,5

3,5

3,9

1,3

1 1 0 1 1 2

v6

1 1

V1

1 0 1 2 2 2

und Entfernungsmatrix E(D)

v5

1 1

1 1 2 2

351

D = 52, d = 3, r = 3 Zentrum: Vj,V2 und v 3 Zerlegungspunkte: vi und v 3

Abb. KOMAN-10: Graphentheoretische Maßzahlen

Eine Kommentierung des vorliegenden Entwurfs aus der Sicht der graphentheoretischen Maßzahlen kann wie folgt lauten: Die Topologie des Kommunikationssystems ist sehr "dicht", da sie - bei sechs Knoten - drei Zentren hat (vi, V2 und V3). Zwei dieser Zentren (vi und V3) sind auch Zerlegungspunkte, bei deren Ausfall das Kommunikationssystem in mehrere Teile zerfällt. Soll oder kann diese Eigenschaft nicht verändert werden, sind die aus dem Entwurf des Kommunikationssystems resultierenden Sicherungsanforderungen im Sicherungssystem (vgl. Lerneinheit WSICH in Bd. 2 "Systemplanung") zu berücksichtigen. Letztlich wird dann bei der Implementierung von Sicherungsmaßnahmen dafür gesorgt, daß auch bei Ausfall der Knoten V| und/oder V2 die Funktionsfähigkeit des Kommunikationssystems aufrecht erhalten bleibt. Kontrollfragen 1. 2. 3. 4. 5.

Für welche Arbeitssituation ist die Kommunikationsanalyse von besonderer Bedeutung? Aus welchen Attributen besteht eine Kommunikationstabelle? Welche quantitativen Aussagen können mit Matrizenoperationen aus Kommunikationsmatrizen gewonnen werden? Welche Methoden der Kommunikationsanalyse eignen sich für die Darstellung von Kommunikationsarten? Welche Unterschiede bestehen zwischen den beiden Formen des Kommunikationsdiagramms?

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

352

Analysemethoden

Vertiefungsliteratur Bössmann, E.: Die ökonomische Analyse von Kommunikationsbeziehungen in Organisationen. Springer, Berlin et al. 1967 Hasse, M.: Uber die Behandlung graphentheoretischer Probleme unter Verwendung der Matrizenrechnung. In: Wissenschaftliche Zeitschrift der Technischen Universität Dresden, 10/1961, 1313- 1316 Heinrich, L. J.: Zur rechnerischen Lösung von Organisationsproblemen mit Hilfe der Graphentheorie. In: Layer, M. (Hrsg.): Rechnungswesen und Betriebswirtschaftspolitik. Schmidt, Bielefeld 1969, 169 - 179

Entwurfsmethoden

i.i prüfe Vorrat 1 2

Materialanforderung

Ausgabeschein ausgegebenes

besorge ] , Material,

Material

Nachbestellungsauftrag f 1.3 ^ finde Lie v feranten. Liste geeigneter Lieferanten 1.4" bestelle Material . _ „ . nach/ Bestellauftrag

354

Entwurfsmethoden

Mit dem Kapitel Entwurfsmethoden sollen folgende Lernziele erreicht werden: SADT - Structured Analysis and Design Technique Sie kennen den Zweck der Structured Analysis and Design Technique (abgekürzt: SADT), die Modellkonzepte von SADT, die SADT-Notation und die Prinzipien, nach denen die SADT-Modelle gebildet werden. Sie wissen, warum SADT zwei unterschiedliche, sich ergänzende Modellkonzepte verwendet. Sie können SADTDiagramme erstellen. Sie können SADT beurteilen und mit anderen Entwurfsmethoden vergleichen. DAFLU - Datenflußdiagramme Sie kennen den Zweck von Datenflußdiagrammen und ihre Konventionen. Sie kennen eine Vorgehensweise beim Modellieren mit Datenflußdiagrammen. Sie können einfache Datenflußdiagramme erstellen. Sie kennen die Prinzipien des Zerlegens von Datenflußdiagrammen. Sie kennen den Zusammenhang zwischen Datenflußdiagrammen und Strukturierter Analyse (SA) sowie Erweiterungen des Modellierungskonzepts mit Datenflußdiagrammen. PENET - Petri-Netze Sie kennen den Zweck von Petri-Netzen. Sie können die Entwurfsprinzipien für Petri-Netze beschreiben. Sie erkennen die Fähigkeit von Petri-Netzen, außer kausal-logischen Beziehungen auch dynamisches Systemverhalten abzubilden. Sie können einfache Systeme mit Petri-Netzen modellieren. Sie können den Unterschied zwischen Petri-Netzen und anderen grafischen Entwurfsmethoden herausarbeiten und die Anwendbarkeit von Petri-Netzen vergleichend beurteilen. SIMUL - Simulation Sie kennen die Anwendungsgebiete der Simulation bei IuK-Projekten und können ihre Stellung als Bindeglied zwischen den Arbeitsschwerpunkten Analysieren und Entwerfen beschreiben. Sie können die Vorgehensweise beim Durchführen einer Simulationsstudie mit eigenen Worten wiedergeben. Sie können typische Simulationssprachen als wichtige Werkzeuge zur Durchführung von Simulationsstudien nennen.

SADT - Structured Analysis and Design Technique Lernziele Sie kennen den Zweck der Structured Analysis and Design Technique (abgekürzt: SADT), die Modellkonzepte von SADT, die SADT-Notation und die Prinzipien, nach denen die SADT-Modelle gebildet werden. Sie wissen, warum SADT zwei unterschiedliche, sich ergänzende Modellkonzepte verwendet. Sie können SADTDiagramme erstellen. Sie können SADT beurteilen und mit anderen Entwurfsmethoden vergleichen. Definitionen und Abkürzungen Aktivität (activity) = das Ergebnis der hierarchischen Zerlegung der Aufgabe des betrachteten Systems in seine Elemente, die im gegebenen Zusammenhang nicht weiter zerlegt werden (z.B. in Funktionen, Teilfunktionen und Prozesse). Ausgabedaten (output data) = die Daten, die von einer Aktivität aus den Eingabedaten erzeugt werden. D a t e n f l u ß (data flow) = der Weg von Daten durch ein System mit seinen sachlichen und zeitlichen Zusammenhängen, insbesondere mit seinen Zusammenhängen mit Datenverarbeitungsprozessen. Eingabedaten (input data) = die Daten, die durch eine Aktivität in Ausgabedaten transformiert werden oder die in der Aktivität verarbeitet werden. FEO-Diagramm = Abkürzung für For Exposition Only-Diagramm, die modifizierte Kopie des Originaldiagramms oder eines Ausschnitts daraus; sequentialisierte Diagramme können als FEO-Diagramme angesehen werden. Funktionseinheit (functional unit) = Bezeichnung für die kleinste Einheit in einem SADT-Modell, die Datenmodell oder Aktivitätenmodell sein kann. I C O M - C o d e = die Buchstaben I (Input), C (Control), O (Output) und M (Mechanism) in untergeordneten Diagrammen, die anzeigen, daß der Pfeil im übergeordneten Diagramm als Eingabe, Steuerung, Ausgabe oder Mechanismus wiederzufinden ist. Mechanismus (mechanism) = der Teil einer SADT-Einheit, der im Aktivitätenmodell Aktivitäten ausführt oder die Ausführung unterstützt und im Datenmodell Daten bereitstellt oder übernimmt. Prinzip (principle) = ein Grundsatz, eine Regel oder eine Richtschnur für das Denken und Handeln. Sequentialisierung (sequencing) = die Analyse und Festlegung von Aktivierungsfolgen in Diagrammen, womit die Aktivierung von Aktivitäten bzw. Daten in Abhängigkeit von der Verfügbarkeit der Daten bzw. der Aktivitäten abgebildet werden kann. Steuerfluß (control flow) = die Reihenfolge, in der die Befehle bei der Ausführung eines Programms abgearbeitet werden. Synonym: Kontrollfluß. Steuerungsaktivität (control activity) = die Aktivität, die den Transformationsprozeß "Daten" steuert oder steuernd beeinflußt. Synonym: steuernde Aktivität. Steuerungsdaten (control data) = die Daten, die den Transformationsprozeß "verarbeite zu" steuern oder steuernd beeinflussen. Synonym: steuernde Daten.

356

Entwurfsmethoden

Zweck von SADT SADT wurde 1974/75 von der Firma SojTech entwickelt. SADT ist eine überwiegend grafische Entwurfs- und Beschreibungsmethode, die einen hierarchisch strukturierten Systementwurf unterstützt, der in Form von Diagrammen dokumentiert wird. Jedes Diagramm ist ein endlicher, gerichteter, knoten- und kantenmarkierter Graph. In den Diagrammen steht entweder die Darstellung des Datenflusses im Vordergrund (wenn ein Datenmodell verwendet wird) oder die Darstellung der Funktionen (wenn ein Aktivitätenmodell verwendet wird). Neben der Festlegung grafischer Beschreibungsmittel (es werden bis zu etwa 40 Symbole verwendet) wird in SADT auch eine methodische Vorgehensweise zur Diagrammerstellung vorgegeben. Jedes Diagramm besteht aus beschrifteten, rechteckigen Kästen und aus Pfeilen. Aus der Sicht eines Kastens beschreiben die Pfeile die Schnittstellen des Kastens mit seiner Umwelt; ausgenommen davon sind die Mechanismus-Pfeile. Die Diagramme werden in einem standardisierten Formblatt entworfen. Die Kästen eines Diagramms können in hierarchisch tiefer liegenden Ebenen weiter verfeinert werden (Top-down-Entwurf). SADT eignet sich zur Spezifikation von Daten und von Funktionen, zur Beschreibung der Zusammenhänge zwischen Daten und Funktionen sowie zur Überprüfung der Widerspruchsfreiheit und der Vollständigkeit der beschriebenen Daten und Funktionen. Diese Eignung resultiert aus der systematischen und formalisierten Darstellung mit den beiden Modellkonzepten Datenmodell und Aktivitätenmodell. Da sich SADT ausdrücklich auf die Abbildung der Struktur eines Systems konzentriert und ein Steuerfluß ausdrücklich nicht dargestellt werden soll, eignet es sich eher für die frühen Phasen eines IuK-Projekts. Mit SADT können die funktionale Zerlegung des Systems und die Abhängigkeiten zwischen den Systemkomponenten durch Datenflüsse gut dargestellt werden. Dynamische Systemeigenschaften sind nicht modellierbar; dazu ist die Transformation in eine andere Entwurfsmethode erforderlich (z.B. in Petri-Netze, vgl. Lerneinheit PENET). Die weitgehend informale Notation, die einfachen grafischen Layout-Konventionen und der strenge Zerlegungsmechanismus erlauben es, sich schnell mit SADT vertraut zu machen und leicht verständliche, gut strukturierte Systemmodelle zu erzeugen, welche die Funktionalität des Systems wiedergeben. Modellkonzepte von SADT Auf jeder Abstraktionsebene sollte das System mit den beiden sich ergänzenden Modellkonzepten abgebildet werden, und zwar: • Aktivitätenmodell zur Abbildung von Aktivitäten, die durch Menschen, Maschinen, Rechner oder Algorithmen ausgeführt werden; • Datenmodell zur Abbildung von Daten (Objekten oder Gegenständen). Im Aktivitätenmodell wird jede Aktivität durch ein Rechteck (Kasten) modelliert; die Datenobjekte, welche die Aktivitäten auslösen (Aktivierung) bzw. durch die Aktivitäten erzeugt werden, werden als Pfeile dargestellt. Abbildung SADT-1 (linker Teil) zeigt schematisch das Aktivitätenmodell. Es wird wie folgt gelesen:

SADT - Structured Analysis

and Design Technique

357

Die Eingabedaten werden durch die Aktivität "verarbeite zu" in Ausgabedaten transformiert. Der Verarbeitungsprozeß wird von einem Mechanismus (z.B. DVAnlage, Personal) ausgeführt, der über die Steuerungsdaten (z.B. bestimmte Bedingungen) beeinflußt wird. Das Diagramm eines Aktivitätenmodells entspricht im wesentlichen einem Datenflußdiagramm (vgl. Lerneinheit DAFLU). Im Datenmodell wird jedes Datenobjekt als Rechteck (Kasten) und jede Aktivität als Pfeil modelliert; die Pfeile verbinden die Datenobjekte. Abbildung SADT1 (rechter Teil) zeigt schematisch das Datenmodell. Es wird wie folgt gelesen: Die Aktivität "erzeuge" auf der Eingangsseite erzeugt ein Datenobjekt, das zur Durchführung der Aktivität "verwende" auf der Ausgangsseite benötigt wird. Die Durchführung geschieht mit einem Mechanismus (z.B. Lesen, Drucken); sie wird über die Steuerungsaktivität (z.B. bestimmte Bedingungen) beeinflußt. Steuerungsaktivität

Steuerungsdaten Eingabe- ^ verarbeite zu daten Mechanismus

Ausgabe-^ daten ""

erzeuge

w

L f

Daten

verwende^

Mechanismus

Abb. S A D T - 1 : Aktivitätenmodell (linker Teil) und Datenmodell (rechterTeil)

SADT-Notation Ein SADT-Modell ist aus einer Menge von Aktivitätenmodellen oder einer Menge von Datenmodellen aufgebaut; jedes dieser Modelle bildet die kleinste geschlossene Einheit des SADT-Modells, die SADT-Einheit. Jede SADT-Einheit ist durch drei eingehende und einen (rechts) ausgehenden Pfeil gekennzeichnet. Typisch für SADT ist, daß jede Seite eines Aktivitäten- und eines Datenkastens eine spezielle Bedeutung hat, und zwar linke Seite I = Inputs, obere Seite C = Controls, rechte Seite O = Outputs und untere Seite M = Mechanisms. Die ICOM-Notation bildet ein bestimmtes Systemprinzip ab, nämlich: Eingaben werden zu Ausgaben transformiert, Steuerungen schränken ein oder geben vor, unter welchen Bedingungen Transformationen eintreten können, und Mechanismen beschreiben die Art der Unterstützung bei der Transformation (z.B. welche Werkzeuge, welches Personal, welche Speicher usw. verwendet werden). Die Rechtecke werden im Aktivitätenmodell sprachlich durch Verben, im Datenmodell durch Substantive ausgedrückt. Gegenstände physischer oder nicht physischer Art (wie Daten, Pläne, Material) werden im Aktivitätenmodell durch Pfeile dargestellt und mit Substantiven bezeichnet. Im Datenmodell repräsentieren die Pfeile Tätigkeiten; sie werden daher mit Verben bezeichnet. Pfeile zwischen den Rechtecken verbinden die Aktivitäten bzw. Daten; sie drücken also aus, wie sich diese gegenseitig beeinflussen. So können z.B. die Ausgabedaten einer Aktivität zur weiteren Verarbeitung an eine andere Aktivität gesandt oder dazu verwendet werden, eine andere Aktivität zu steuern. In diesem Sinn beschreiben die Pfeile die Schnittstellen zwischen den Aktivitäten bzw. zwischen den Daten

358

Entwurfsmethoden

innerhalb des modellierten Systems und zwischen dem System und seiner Umwelt. Die Beziehungen zwischen einem übergeordneten Diagramm und einem untergeordneten Diagramm können über Pfeilbeschriftung erkannt werden. Zusätzlich wird eine spezielle Schreibweise (sog. ICOM-Code) benutzt, um die Zusammenhänge schneller aufzuzeigen und unterschiedliche Beschriftungen auf verschiedenen Diagrammen zu ermöglichen. Die Buchstaben I, C, O oder M werden im untergeordneten Diagramm neben einen nicht verbundenen Pfeil geschrieben, um zu zeigen, daß der Pfeil im übergeordneten Diagramm als Eingabe, Steuerung, Ausgabe oder Mechanismus wiederzufinden ist. Um den Pfeil genauer zu bezeichnen, wird an diese Buchstaben eine Ziffer angehängt, welche die relative Lage des Pfeils im übergeordneten Diagramm angibt. Die Numerierung erfolgt dabei von links nach rechts oder von oben nach unten. Wenn z.B. im untergeordneten Diagramm Ol an einem Pfeil steht, bedeutet dies, daß der Pfeil im übergeordneten Diagramm als erste Ausgabegröße zu finden ist. Die Bezeichnungen werden nur im untergeordneten Diagramm an die betreffenden Pfeile geschrieben. Der Platz jedes Diagramms innerhalb eines SADT-Modells wird mit einer Knotennummer, die von der Numerierung der Kästen abgeleitet wird, bezeichnet. Die Hierarchie kann durch ein Inhaltsverzeichnis mit den Diagrammnamen und den dazugehörigen Knotennummern dargestellt werden (Knotenverzeichnis). Prinzipien der Modellbildung SADT-Modelle werden aufgrund folgender Prinzipien gebildet: • Erstes Prinzip: Das betrachtete System wird zunächst nur von einer Sicht aus modelliert. Im allgemeinen ist es wegen des besseren Verständnisses zweckmäßig, nacheinander mehrere Sichten zu verwenden (z.B. kann eine Bibliothek aus der Sicht des Bibliotheksbenutzers und aus der Sicht der Bibliotheksverwaltung modelliert werden). • Zweites Prinzip: Die Modellierung beginnt auf der höchsten Abstraktionsebene und hat das betrachtete System als Ganzes zum Gegenstand. Hierarchisches Zerlegen in Teilsysteme führt zu schrittweisen Verfeinerungen, gegebenenfalls auf mehreren Hierarchie-Ebenen. Das Zerlegen erfolgt so, daß jedes Teilsystem unabhängig von den anderen Teilsystemen der gleichen Abstraktionsebene verfeinert werden kann, und zwar durch Aufspalten der einzelnen Kästen im Diagramm in mehrere Kästen mit einer detaillierteren Beschreibung (vgl. Abbildung SADT-2). Die so entstehenden Teilsysteme werden im nächsten Diagramm wieder in Teilsysteme zerlegt, bis das System im gewünschten Detaillierungsgrad beschrieben ist. Die Diagramme einer unteren Ebene sind also detaillierte Beschreibungen von Diagrammen der nächsthöheren Ebene. Eine Verfeinerung soll zu mindestens drei, höchstens sechs neuen Teilsystemen führen. Die Kästen werden im SADT-Diagramm in der Diagonalen (von links oben nach rechts unten) angeordnet. Die Reihenfolge der Kästen wird nach dem Ablauf der Verarbeitung gewählt. Ein SADT-Diagramm sollte aus drei bis sechs SADT-Einheiten bestehen.

SADT - Structured Analysis and Design Technique

359

Abb. SADT-2: Verfeinerung eines SADT-Diagramms

• Drittes Prinzip: Jedes System sollte zweifach dargestellt werden, zuerst aus der Aktivitätensicht als Aktivitätenmodell und dann aus der Datensicht als Datenmodell. Durch Vergleichen beider Modelle können Aktivitäten und Daten wechselseitig überprüft werden. Damit wird auch versucht sicherzustellen, daß Aktivitäten und Daten vollständig und widerspruchsfrei in beiden Modellen vorhanden sind. • Viertes Prinzip: SADT enthält keine Darstellungsmöglichkeiten für den Steuerfluß. Dadurch soll verhindert werden, daß bei der Beschreibung der Funktionsanforderungen (Aktivitäten) oder der Datenanforderungen (Daten) algorithmische Aspekte einfließen, welche die Orientierung auf Funktionen und Daten negativ beeinflussen könnten. Da eine Aktivität nur dann ausgeführt werden kann, wenn alle notwendigen Daten zur Verfügung stehen, kann implizit eine Aufeinanderfolge dargestellt werden (Aktivierungsfolge). Aktivierungsfolgen zeigen die Aktivierung von Kästen in Abhängigkeit von der Verfügbarkeit der Daten (beim Aktivitätenmodell) bzw. der Ausführung von Aktivitäten (beim Datenmodell). Beim Erarbeiten einer Aktivierungsfolge (Sequentialisierung) werden die betreffenden Pfeile und Kästen mit Aktivierungsnummern versehen, die innerhalb einer Aktivierungsfolge eine aufsteigende Ordnung haben. Die Sequentialisierung beginnt damit, daß an den Anfang aller von außen kommenden Eingabepfeile und Steuerungspfeile eine Null geschrieben wird. Anschließend werden die Kästen bestimmt, die aufgrund der vorliegenden Daten (beim Aktivitätenmodell) bzw. eingehenden Aktivitäten (beim Datenmodell) aktivierbar sind, und mit ihnen wird die Numerierung fortgesetzt. • Fünftes Prinzip: Zur Verifizierung der Modellierung wird der Autor/Gutachter-Zyklus (auch: Autor/Kritiker-Zyklus) empfohlen. Änderungsvorschläge des Gutachters (der meist selbst Autor ist) werden an den Autor zurückgegeben, der die notwendigen Änderungen durchführt. Die geänderten Diagramme werden zur erneuten Begutachtung angeboten.

360

Entwurfsmethoden

Demonstrationsbeispiel Es wird die Anwendung von SADT beim Entwerfen eines Personalinformationssystems gezeigt. Dazu erfolgt zunächst die Beschreibung des Istzustands; es sollen die Aufgaben und Teilaufgaben des Personalwesens dargestellt werden. Die Aufgaben des Personalwesens werden dabei als Führungsaufgaben verstanden, also nicht nur als Teilaufgaben des Finanz- und Rechnungswesens. Die Modellierung erfolgt mit einem Aktivitätenmodell. Abbildung SADT-3 zeigt das Gesamtsystem als SADT-Modell. Gesetze und Richtlinien Betriebsvereinbarungen Budgets und Pläne Beurteilungskriterien

1

Betriebsstruktur Hemel Marktbedingungen und Vergleiche

Bewerber-/ Mitarbeiter-Daten

1

Daten externer Stellen Seminar-Daten intern/extern

2

3

4

5

6

Personalinformationssystem

T

Daten für externe Stellen Organisationsplan-Daten Statistik-Daten intern Kosten-Daten für interne Zwecke Mitarbeiter-Stammdaten Personalpläne

Computer

Abb. SADT-3: SADT-Modell Personalinformationssystem

Mit Abbildung SADT-4 wird das in drei Teilsysteme zerlegte Gesamtsystem abgebildet. Unter anderem ist aus der Abbildung zu erkennen, daß die Daten der "Leistungsbeurteilung" in Kasten 2 für die Aktivität "Gehälter berechnen" benötigt werden; sie finden daher keinen Eingang in Kasten 3. In Abbildung SADT-5, welche die Zerlegung von Kasten 3 zeigt, führen zu Kasten 32 die Steuerungsdaten "Personaldaten aus Leistungsbeurteilung". Das Modell enthält daher zwei Fehler: • Am Kasten 32 sind die Steuerungsdaten "Personaldaten aus Leistungsbeurteilung" vorhanden, obwohl sie am Kasten 3 im Elterndiagramm zunächst nicht vorhanden waren (sie wurden nachträglich gestrichelt eingefügt). Dies kann nicht richtig sein, weil die dritte Ebene nichts enthalten kann, was nicht die zweite Ebene bereits enthält. • Aus Kasten 1 gehen die Ausgabedaten "Leistungsbeurteilung" als Steuerungsdaten in Kasten 2 ein. Dies kann nicht richtig sein, weil zur Durchführung der Leistungsbeurteilung "Beurteilungskriterien" erforderlich sind; diese gehen aber erst in Kasten 2 als Steuerungsdaten ein. Der (gestrichelte) Pfeil "Leistungsbeurteilung" von Kasten 2 nach Kasten 3 muß daher entfernt werden. Derartige Fehler werden erfahrungsgemäß am besten durch die zyklische Arbeitsweise zwischen Autoren und Gutachter aufgedeckt (sog. Autor/GutachterZyklus).

SADT - Structured Analysis and Design Technique

•"spi 1) :cd WlP vi ^ — Kr"O

„ "T3 C A 4) 00 N in n « »