Universität-Gesamthochschule Paderborn Diplomarbeitgcc.uni-paderborn.de/www/wi/wi2/wi2_lit.nsf/35ae96... · Diplomarbeit Entscheidungsunterstützung in der Multiprojektkoordination:

Universität-Gesamthochschule Paderborn

Diplomarbeit

Entscheidungsunterstützung in der Multiprojektkoordination:Entwicklung eines flexiblen und verteilten Frontend-Systems für

Planer und Entscheider

vorgelegt bei

Prof. Dr. Nastansky

im April 1997

vorgelegt von

Martin SchindlerWeberstr. 51

37242 Bad Sooden-Allendorf

Matrikelnummer 3061399

Studiengang Wirtschaftsinformatik

Inhaltsverzeichnis Seite I

Inhaltsverzeichnis

Inhaltsverzeichnis........................................................................................................... I

1 Szenario und Motivation..........................................................................................1

1.1 Szenario...............................................................................................................1

1.2 Zielsetzung ..........................................................................................................2

1.3 Aufbau der Arbeit ................................................................................................3

2 Thematische Abgrenzung und begriffliche Definitionen ........................................5

2.1 (Multi-)Projektmanagement und Projektcontrolling ..............................................5

2.2 Rollen im Projektmanagement..............................................................................7

2.3 Stellenwert von Projektmanagement im Unternehmen ..........................................8

2.4 Entscheidungsunterstützungssysteme ...................................................................9

2.5 Verteilungsaspekte.............................................................................................11

3 Anforderungen aus Theorie und Praxis.................................................................13

3.1 Nutzerkreise ......................................................................................................13

3.2 Entscheidungsfindung im Projekt .......................................................................15

3.3 Leistungsmerkmale eines DSS/EIS.....................................................................20

3.4 Experteninterviews.............................................................................................22

4 Stand der Technik und Trends ..............................................................................25

4.1 Visualisierung von Projektdaten .........................................................................25

4.2 Projektmanagement als Führungsstil...................................................................28

4.3 Paradigmenwechsel in der Informationstechnologie ............................................31

4.4 Gesamtkonzept einer Lösung .............................................................................35

5 Verwendete Arbeitsumgebung...............................................................................39

5.1 Lotus Notes .......................................................................................................39

5.2 Lotus Components.............................................................................................41

Inhaltsverzeichnis Seite II

5.3 PAVONE GroupProject.....................................................................................42

5.3.1 GroupProject Datenbanken .........................................................................43

5.3.2 ProjectBuilder .............................................................................................46

5.3.3 ProjectConnect............................................................................................46

5.3.4 Multiprojecting mit GroupProject................................................................46

6 Zentrale Konzepte der Lösung: Prototypische Implementierung GP DSS ..........47

6.1 Architektur- und Datenmodell ............................................................................47

6.1.1 Konzept der Profil- und Reportdokumente ..................................................48

6.1.1.1 Konfiguration durch Profile .................................................................48

6.1.1.2 Konzept des Metafilters.......................................................................51

6.1.1.3 Grafische Auswertungen in den Reports ..............................................52

6.1.2 Integration in die Projektmanagment-Umgebung .........................................53

6.1.3 Objektorientierung und Erweiterbarkeit .......................................................54

6.2 Benutzerführung und -interaktion.......................................................................58

6.2.1 Navigationskonzept.....................................................................................58

6.2.2 Interaktion mit dem Endbenutzer.................................................................61

6.2.3 Drill-Down..................................................................................................63

6.2.4 Managementgerechte Aktionen ...................................................................64

6.3 Implementierte Szenarien ...................................................................................66

6.4 Zusammenfassung: Übersicht Gesamtkonzept ....................................................69

7 Schlußbetrachtung und Perspektiven....................................................................71

A Verzeichnisse ...........................................................................................................73

A.1 Literatur............................................................................................................73

A.2 Abbildungen......................................................................................................82

A.3 Tabellen ............................................................................................................84

A.4 Abkürzungen.....................................................................................................85

Seite III

B Eidesstattliche Erklärung..........................................................................................87

C Anlagen....................................................................................................................88

C.1 WWW-Quellen..................................................................................................88

C.2 Experteninterviews............................................................................................89

C.2.1 Anschreiben................................................................................................89

C.2.2 Interviewleitfaden .......................................................................................90

C.2.3 Gesprächsprotokolle ...................................................................................92

C.2.4 Auswertungen ..........................................................................................118

C.3 Anforderungen an Hard- und Software ............................................................120

C.4 Attachments ....................................................................................................120

C.4.1 Applikation: GP DSS................................................................................120

C.4.2 Freelance Präsentation ..............................................................................120

C.4.3 Technische Dokumentation.......................................................................120

C.5 Installationsanweisung.....................................................................................121

1 Szenario und Motivation Seite 1

1 Szenario und Motivation

1.1 Szenario

Das Wettbewerbsumfeld für Unternehmen ist in der zweiten Hälfte der neunziger Jahre

durch eine Globalisierung der Märkte und immer kürzere Produktlebenszyklen gekenn-

zeichnet. Aktuelle Schlagworte aus Theorie und Praxis wie „Management des Wandels“,

„strategische Allianzen“, „virtuelle Unternehmen“, „Business Process Reengineering“,

„Lean Management“, „Dezentralisierung“ und „flache Hierarchien“ weisen auf die dazu

nötigen Umdenkprozesse hin. Dabei gilt es, die Organisationsstruktur der Unternehmung

den ständig neuen Bedingungen und erhöhten Anforderungen an Flexibilität und

Dynamik anzupassen, um dem Konkurrenzdruck standhalten zu können.

Eine in diesem Zusammenhang immer wichtiger werdende Organisationsform ist die des

projektorientierten Unternehmens, welches sich durch ein „Management by Projects“

auszeichnet. Die strategische Bedeutung von Projektmanagement-Methoden ist in

solchen Unternehmen nicht hoch genug anzusetzen. Es ist zu erwarten, daß sich die

Tendenz zu solchen projektorientierten Organisationsstrukturen in den nächsten Jahren

noch verstärken wird [vgl. Gareis 1992, S. 145 ff.].

Die dazu in den 60er, 70er und 80er Jahren entwickelten Methoden und Grundlagen-

technologien im Projektmanagement wie z. B. die Netzplantechnik sind diesen ge-

stiegenen Anforderungen allein nicht mehr gewachsen und müssen sinnvoll ergänzt

werden. Neue Möglichkeiten bietet in dieser Hinsicht die Integration in leistungsfähige

Kommunikations- und Informationssysteme. Nur durch die Nutzung solch innovativer

teamfähiger Lösungen kann der zunehmenden Bedeutung des Produktionsfaktors Infor-

mation begegnet werden.

Ein Kennzeichen der Anforderungen an die Unternehmen ist die immer geringere Zeit-

spanne, die der Unternehmensführung für Entscheidungen zur Verfügung steht (vgl. dazu

Abb. 1.1-1). Zeit ist somit ein kritischer Erfolgsparameter für betriebliche Ent-

scheidungen.


Jahre

Stunden

Tage

Wochen

Monate

1970 200019901980

strategisch

operativ

Abb. 1.1-1: Für Entscheidungen verfügbare Zeitspanne [Tiemeyer/Zsifkovits1995, S. 39]

Entsprechende informationstechnologische Lösungen zur Unterstützung der Entschei-

dungsfindung wurden in den letzten Jahrzehnten – hervorgehend aus den

MIS-Technologien der 60er Jahre (MIS: Management Information System) – kontinu-

ierlich fortentwickelt: aktuelle Schlagwörter aus diesem Bereich sind „Data

Warehousing“ und „OLAP“ (Online Analytical Processing).

Aus der Verzahnung dieser Kontexte ergibt sich als Motivation für diese Arbeit der Be-

darf an neuen Lösungen zur Entscheidungsunterstützung im Rahmen der Multiprojekt-

koordination.

1.2 Zielsetzung

Ziel dieser Diplomarbeit ist die Entwicklung einer Lösung für die bedarfsgerechte Prä-

sentation von Projektmanagement-Daten zur Entscheidungsunterstützung.

Dabei sollen der dazu notwendige theoretische Bezugs- und Relevanzrahmen dargestellt

und eine konkrete softwaretechnische Umsetzung dieser Konzepte in Form einer proto-

typischen Implementierung durchgeführt werden.

Neben der Berücksichtigung der konzeptionellen Anforderungen aus der Theorie, die in

den Bereichen der Betriebswirtschaft, Informatik und Wirtschaftsinformatik definiert

werden, wird eine möglichst praxisnahe Umsetzung angestrebt.


Dieser letzten Anforderung kommen insbesondere die Projekterfahrung des Autors bei

mehreren Großkunden in der Definition und Einführung von Projektmanagement-

Lösungen zugute, aber auch ein konkreter Teilaspekt der Arbeit: die Durchführung einer

empirischen Untersuchung in Form von Experteninterviews bei dreizehn Kunden des

kooperierenden Unternehmens, einem Paderborner Software- und Dienstleistungsunter-

nehmen. Die Überlegungen zur Notwendigkeit einer solchen Befragung werden zusätz-

lich durch die Theorie [vgl. Curtis 1989, S. 105 ff.] motiviert.

Die vorliegende schriftliche Ausarbeitung soll die eben genannten Aspekte der Arbeit

darstellen.

Ein Schwerpunkt der Arbeit liegt in der softwaretechnischen Umsetzung der erarbeiteten

Konzepte: die prototypische Implementierung „GroupProject DSS“ setzt dabei auf die

innovative teamorientierte Projektmanagement-Lösung GroupProject auf, deren

Konzepte an der Lehr- und Forschungseinheit Wirtschaftsinformatik 2 der Uni-

versität-GH Paderborn entwickelt wurden und das vom kooperierenden Unternehmen

international vertrieben wird, bei dem der Autor dieser Arbeit als Consultant mit der

Einführung und kundenspezifischen Anpassung von Projektmanagement-Lösungen be-

schäftigt ist.

1.3 Aufbau der Arbeit

Die Arbeit gliedert sich in sieben Hauptkapitel.

In Kapitel 2 werden zunächst die für diese Arbeit grundlegenden Themengebiete abge-

grenzt und wichtige Begrifflichkeiten definiert.

Im Anschluß daran findet im dritten Kapitel eine vertiefende Darstellung und Diskussion

der für diese Arbeit relevanten theoretischen und praktischen Grundlagen statt. Die

praktischen Aspekte werden dabei durch die in Kapitel 3.4 präsentierten Ergebnisse der

durchgeführten Experteninterviews berücksichtigt.

Aktuell im Projektmanagement erhältliche Lösungen zur Visualisierung von Projekt-

informationen werden in Kapitel 4 kritisch betrachtet. Ferner wird der Trend zur pro-

jektorientierten Unternehmung belegt und „Management by Projects“ als innovatives

Führungskonzept solcher Organisationen vorgestellt. Teamorientierte Informations- und

Kommunikationssysteme stellen geeignete Basisplattformen für die im Rahmen dieser

Arbeit zu entwickelnde Lösung dar: in Kapitel 4.4 wird ein aus den Grundlagen


entwickeltes Gesamtkonzept zur Realisierung eines solchen Frontend-Systems vor-

gestellt.

Kapitel 5 beschreibt die zur Realisierung der Implementierung genutzten Grundlagen-

technologien, um dem Leser das Verständnis der konkret umgesetzten Applikation zu

erleichtern.

In Kapitel 6 werden zentrale Konzepte der prototypisch realisierten Lösung eines

flexiblen und verteilten Frontend-Systems zur managementgerechten Präsentation und

zur Entscheidungsunterstützung in Szenarien der Multiprojektkoordination vorgestellt.

Die Umsetzung des am Ende von Kapitel 4 dargestellten Architekturmodells wird dabei

zusammenfassend in Kapitel 6.4 erläutert.

Abschließend werden im siebten und letzten Kapitel die wichtigsten Gedanken der Arbeit

zusammengefaßt und Vorschläge für eine mögliche Erweiterung der vorgestellten

Lösung unterbreitet.

2 Thematische Abgrenzung und begriffliche Definitionen Seite 5

2 Thematische Abgrenzung und begriffliche

Definitionen

In diesem Kapitel werden die für das Verständnis der Arbeit notwendigen Grundlagen

erörtert. Dazu werden die notwendigen Begrifflichkeiten aus den Bereichen des

Projektmanagements, der Entscheidungsunterstützung und der Computer Supported

Cooperative Work eingeführt.

2.1 (Multi-)Projektmanagement und Projektcontrolling

Nach DIN 69901 lautet die Definition des Begriffes Projekt: „Vorhaben, das im

wesentlichen durch Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet

ist, wie z. B.

- Zielvorgabe

- zeitliche, finanzielle oder andere Begrenzungen

- Abgrenzung gegenüber anderen Vorhaben

- projektspezifische Organisation.“ [DIN 69901]

Rinza definiert Projektmanagement (PM) als „die Leitung – Leitung hier insbesondere

verstanden als Planung, Überwachung und Steuerung – eines Projektes sowie die das

Projekt leitende Institution“ [Rinza 1994, S. 3]. Krüger subsumiert Projektmanagement

kürzer als „Führungskonzept für komplexe Vorhaben“ [Krüger 1994, S. 374].

Methoden sind in diesem Zusammenhang Vorgehensweisen zur Lösung von Problemen

der Planung, Überwachung und Steuerung des Projektablaufs. Diese Vorgehensweisen

werden in bestimmten Techniken standardisiert abgebildet. Beispielhaft zu nennen ist in

diesem Zusammenhang die Netzplantechnik. Unter Tools (Werkzeugen) ist Software zur

Unterstützung einzelner Techniken zu verstehen [vgl. Krüger 1994, S. 390].

Burghardt definiert die in der Literatur weit verbreitete Darstellung von drei Grund-

parametern als „magisches Dreieck“ [Burghardt 1995, S. 30], die bei der Projektdurch-

führung als Zielgrößen in einer ständigen Interdependenz stehen (vgl. Abb. 2.1-1).


Projekt

Einsatzmittel (Ressourcen,

Budget)

Zeit(Termine)

Leistung

Abb. 2.1-1: Grundparameter eines Projektes [Burghardt 1995, S. 30]

Nach Burghardt unterteilt sich ein Projekt in vier Hauptabschnitte [Burghardt 1995,

S. 12 ff.]:

1. Projektdefinition

2. Projektplanung

3. Projektkontrolle

4. Projektabschluß

In dieser Arbeit von besonderer Relevanz ist dabei die dritte Phase „Projektkontrolle“,

die die eigentliche Projektdurchführung begleitet. In dieser Phase wird ein steter

Plan-/Ist-Vergleich der eben definierten Grundparameter durchgeführt. In der Literatur

wird diese Phase auch als Projektcontrolling [z. B. in Eschlbeck 1996, Abschnitt 2.5.1,

S. 1] bezeichnet. Nach Meinung des Autors ist diese Bezeichnung besser geeignet, da er

neben dem Kontrollaspekt im Sinne einer Überwachung der Projektabwicklung noch den

Steuerungsgedanken beinhaltet: Projektcontrolling ist die „Überwachung und Steuerung

von Projekten“ [Schwägerl 1996, Abschnitt 1.4, S. 11].

Auf die verschiedensten Möglichkeiten einer Klassifikation von Projekten nach Projekt-

arten soll in dieser Arbeit aus Relevanzgründen nicht weiter eingegangen werden. Eine

detaillierte Betrachtung findet sich z. B. bei Aggteleky/Bajna [Aggteleky/Bajna 1992,

S. 106 ff.].

Die Aufgabe des Multiprojektmanagements (und synonym der Multiprojektkoordination)

ist es, „eine Menge von Einzelprojekten so zu koordinieren, daß das Gesamtergebnis


aller Projekte hinsichtlich der Unternehmensziele ein Optimum ergibt“ [Schwägerl 1996,

Abschnitt 1.4 S. 8].

Dabei existiert zusätzlich die besondere Problemstellung, daß sich oftmals mehrere

Projekte bestimmte Einsatzmittel (auch als Ressourcen bezeichnet, z. B. Mitarbeiter oder

Betriebsmittel) teilen müssen, d. h. es wird eine Abstimmung zwischen den einzelnen

Projekten erforderlich [Burghardt 1995, S. 239 f.].

2.2 Rollen im Projektmanagement

Zur erfolgreichen Durchführung eines Projektes bedarf es i. d. R. mehrerer Personen, die

verschiedene Aufgaben und Funktionen innerhalb des Projektes wahrnehmen. Die Insti-

tutionalisierung dieser Aufgaben wird im folgenden diskutiert.

Die Aufgabe des Projektmanagers (oder synonym Projektleiters) ist das Erreichen des

Projektziels bei gleichzeitiger Erfüllung des für das Projekt definierten Leistungs- oder

Qualitätsumfangs unter Einhaltung der Restriktionen durch auferlegte Budgets und/oder

Terminbeschränkungen [Burghardt 1995, S. 88]. Er hat somit eine „Managementaufgabe

auf Zeit“ [Aggteleky/Bajna 1992, S. 41], abhängig von der für die Durchführung des

Projektes erforderlichen Dauer.

Die Projektmitarbeiter sind mit der eigentlichen operativen Durchführung des Projektes

betraut. Sie führen Informationsbeschaffung, Konzepterarbeitung und Realisierung von

(Teil-)Aufgaben innerhalb des Projektes durch [Haberfellner et al. 1994, S. 267].

Projektarbeit ist überwiegend Teamarbeit. Projektmanager und -mitarbeiter bilden das

sogenannte Projektteam. Die Anzahl der Teammitglieder hängt dabei von der Projekt-

größe und Komplexität ab.

Als Planer versteht man die Projektleitung, die eventuell durch interne oder externe

Berater unterstützt wird. Sie ist neben der Überwachung und Steuerung für die Projekt-

planung zuständig. Entscheider sind interne Instanzen, die Ziele zur Projektdurchführung

formulieren und die Einhaltung dieser Ziele kontrollieren (z. B. ein Projektlenkungs-

ausschuß oder andere Gremien). In der Praxis werden solche Gremien oft auch als

Projektoberleitung bezeichnet. Die Gruppen der Planer und Entscheider müssen

keineswegs disjunkt sein: je nach Aufgabenstellung wird die Projektleitung beiden

Gruppen zugerechnet [vgl. Krüger 1994, S. 391 f.].


2.3 Stellenwert von Projektmanagement im Unternehmen

Es existiert eine Vielzahl von Möglichkeiten zur Integration der Projektteams in das

Unternehmen. Die wesentlichen davon werden an dieser Stelle durch eine institutionelle

Betrachtung des Projektmanagements charakterisiert. In der Literatur finden sich dazu

verschieden detaillierte Klassifizierungen. Hier soll den Ausführungen von Haberfellner

et al. [Haberfellner et al. 1994, S. 254 ff.] gefolgt werden, die drei Organisationsformen

nennen:

1. Reine Projektorganisation

Bei der reinen Projektorganisation (auch Task Force oder Parallel-Linienorganisation

genannt) werden Mitarbeiter aus ihren Stammabteilungen herausgelöst und – für die

Dauer eines oder mehrerer Projekte an denen sie beteiligt sind – einem Projektteam unter

der Führung eines Projektleiters zugeordnet. Dieser hat die kompletten Entscheidungs-

und Weisungsbefugnisse über sie.

2. Einfluß-Projektorganisation (Stabs-Projektorganisation)

Der Projektleiter hat hier weniger Kompetenzen und Verantwortung als bei der reinen

Projektorganisation: die normale Hierarchie der Unternehmung wird lediglich um die

(Stabs-)Stelle des Projektkoordinators ergänzt, der keine Weisungsbefugnis besitzt.

Diese bleibt weiterhin bei den Vorgesetzten der Stammabteilungen.

3. Projektleitung in der Matrixorganisation

Dies ist eine Kombination der eben dargestellten Einfluß- und der reinen Projekt-

organisation. Die herkömmliche Linienorganisation wird dabei um eine zusätzliche

zweite Dimension erweitert, was zu einer Kompetenzüberschneidung führt: der Projekt-

leiter hat Weisungsrecht in Projektbelangen, der Linienvorgesetzte sonst. Diese Form gilt

als konfliktanfällig.

Eine aus der reinen Projektorganisation evolvierte Managementstrategie ist die des

„Management by Projects“, ein ursprünglich von Gareis postuliertes Führungskonzept,

bei dem Projektmanagement nicht mehr nur als Arbeitstechnik und Methode gesehen

wird, sondern in der Unternehmenskultur verwurzelt ist.

In Abhängigkeit von der im Unternehmen realisierten Organisationsform besitzt ein

Projektleiter mehr bzw. weniger Verantwortung und Kompetenzen. Neben den eben

aufgeführten Organisationsformen sind natürlich auch Mischformen denkbar.


Je nach Stellenwert des Projektmanagements innerhalb der Unternehmung verschiebt

sich die Organisationsform entsprechend. Burghardt gibt als determinierende Kriterien

zur Festlegung der tendenziell am besten geeigneten Organisationsform den Grad der

Überbereichlichkeit und die Projektgröße an [vgl. Burghardt 1995, S. 82 f.].

2.4 Entscheidungsunterstützungssysteme

Entscheidungen werden aufgrund der zum Entscheidungszeitpunkt bereitstehenden

Informationen getroffen. Dazu benötigt der Entscheider entsprechende Informationen

über seine Umwelt [vgl. Schultz 1987, S. 22].

Es wird deutlich, daß Entscheidungen und Informationen eng miteinander verknüpft sind.

Aus diesem Relevanzaspekt soll der Begriff der Information genauer definiert werden

[Korndörfer 1995, S. 83]: „Information ist zweckorientiertes Wissen, das disponierenden

Entscheidungsträgern als Entscheidungsgrundlage zur Verfügung steht.“ Information

wird somit zum Instrument der Führung.

„Ein Informationssystem ist ein Menge von Verfahren, die Informationen sammeln

(abfragen), verarbeiten, speichern und verteilen, um Entscheidungsfindung und Kontrolle

zu unterstützen.“ [Laudon/Laudon 1988, S. 5, Übersetzung durch den Autor]

Um den betrieblichen Führungskräften bedarfsgerechte Informationen zur Verfügung zu

stellen, bedarf es somit innovativer Informationssysteme. Im folgenden werden dabei aus

Gründen der Übersichtlichkeit die in der angelsächsischen Literatur üblichen Termini

verwendet.

Begriffsunschärfe

Unter Executive Information Systems (EIS) werden computerbasierte Informations-

systeme verstanden, die es dem oberen Management erlauben, auf Informationen zugrei-

fen zu können, welche ihre Managementaktivitäten unterstützen [Leidner/Elam 1995,

S. 139]. DSS (Decision Support Systems) implizieren oft die Bereitstellungen von

Modell- und Methodendatenbanken mit Möglichkeiten zur Prognose und Simulation wie

etwa dem Vorhandensein von Möglichkeiten zu zukunftsorientierten Trendberechnungen

(z. B. sogenannten What-If-Analysen) [Oppelt 1995, S. 10 f.]. Nach Meinung einiger

Autoren umfassen EIS auch DSS [z. B. Matthews 1992, S. 36], andere erklären

wiederum, eine Ergänzung von EIS um DSS-Komponenten führt zu ESS (Executive

Support Systems) [Henneböle 1995, S. 22].


In diesem Bereich herrscht in der Literatur eine Begriffsvielfalt und gleichzeitige

Begriffsunschärfe [vgl. O’Brien 1995. S. 396; Oppelt 1995, S. 134], es existieren zahl-

reiche sich teilweise widersprechende Ansätze zur möglichen Klassifikation solcher

Systeme.

Eine klare Abgrenzung scheint dem Autor daher nur aus der historischen Entwicklung

her sinnvoll (vgl. dazu Kapitel 4.3). Für die im weiteren Verlauf der Arbeit zu

definierenden Anforderungen an ein solches Informationssystem scheint es jedoch er-

forderlich, diese Thematik im folgenden näher einzugrenzen.

In diesem Zusammenhang wird in dieser Arbeit unter einem DSS ein computerbasiertes

Informationssystem zur Entscheidungsunterstützung in der Multiprojektkoordination

verstanden, wobei dieses den betrieblichen Funktionsträgern keine Entscheidungen ab-

nimmt oder vorschlägt [vgl. Curtis 1989, S. 103 ff.]. Krüger definiert dazu: „Decision

Support Systems (DSS) dienen der Entscheidungsvorbereitung“ [Krüger 1994, S. 173].

Ein DSS ist in diesem Kontext daher als Instrument zu sehen, das die Entscheidungs-

findung durch übersichtliche und aussagefähige Entscheidungsunterlagen unterstützen

soll. Dadurch soll der gestiegenen Bedeutung des Bedarfs an leistungsfähigen Werk-

zeugen zur Multiprojektkoordination und den damit verbundenen Fragestellungen durch

die Begriffswahl „DSS“ Rechnung getragen werden. Der Anspruch, ein Executive

Information System darzustellen stimmt nur für den Fall, daß man die Zielgruppe für die

zu entwickelnde Lösung auf das obere Management beschränkt und gleichzeitig einen

hohen Stellenwert des Projektmanagements für das zu betrachtende Unternehmen ein-

räumt.

Insbesondere bei der Betrachtung der in Kapitel 3.3 aufgeführten „Leistungsmerkmale

eines DSS/EIS“ ist es daher erforderlich, sich dieser quasi-synergetischen Definition

bewußt zu sein: es erlaubt die Ableitung genereller Anforderungen an ein modernes

Informationssystem für diesen speziellen Kontext.

Die aufgeführten Definitionen von Termini wie MIS/DSS/EIS/ESS ließen sich noch

weitaus tiefer untergliedern und fortführen – dies ist aber durch den eben definierten

Relevanzrahmen nicht erforderlich.

Aspekte der betriebswirtschaftlichen Entscheidungstheorie sollen zur weiteren

Eingrenzung des Relevanzrahmens in dieser Arbeit nicht näher betrachtet werden.


Die Betrachtung von sogenannten „Expertensystemen“, in denen Methoden des

Operations Research, wie z. B. der linearen Programmierung und verstärkt der

Künstlichen Intelligenz Anwendung finden, wird daher in dieser Arbeit aus

Relevanzüberlegungen nicht vorgenommen. Entsprechende Möglichkeiten stehen im

Projektmanagement durch die leistungsfähigen Verfahren der Netzplantechnik bereits zur

Verfügung.

2.5 Verteilungsaspekte

Im Kontext des Gesamtverständnisses der Arbeit, insbesondere für das fünfte und sechste

Kapitel hält es der Autor für erforderlich, einige Termini aus dem Bereich der CSCW

(Computer Supported Cooperative Work) zu definieren.

Computer Supported Cooperative Work wird als das den Groupware-Systemen zugrun-

deliegende wissenschaftliche Forschungsgebiet definiert: „CSCW bezeichnet .. die

Disziplin des kooperativen computerunterstützten Arbeitens.“ [Kaiser 1994, S. 257]

Der Begriff des Workgroup Computing „drückt die Tätigkeit des kooperativen compu-

tergestützten Arbeitens aus“ [Kaiser 1994, S. 257].

Ellis et al. bezeichnen Groupware „as computer-based systems that support people

engaged in a common task (or goal) and that provide an interface to a shared

environment“ [Ellis et al. 1991, S. 177].

Abb. 2.5-1: Verteiltes Arbeiten in Teams

Groupware-Systeme dienen der Kooperation, Koordination und Kommunikation von

Arbeitsgruppen [Ellis et al. 1991, S. 177]. Groupware hilft dabei der Überwindung


räumlicher und zeitlicher Distanzen (vgl. Abb. 2.5-1), wobei vor allem verteilte Daten-

banksysteme attraktiv sind [Kaiser 1994, S. 258] und „stellt computergestützte Konzepte

für die Teamarbeit bereit“ [Nastansky 1993, S. 6]. Die Termini Groupware und

Groupware-Systeme werden dabei in der Literatur regelmäßig synonym verwendet.

Hansen [Hansen 1992, S. 740] definiert verteilte Systeme folgendermaßen: „Das Client-

Server-Modell gilt als dominierendes Konzept für die verteilte Datenverarbeitung mit

über ein Kommunikationsnetz verbundenen Rechnern. Man versteht darunter eine

Architektur, bei der eine EDV-Anwendung in einen benutzernahen Teil (Client,

Frontend), der auf dem Endsystem des Benutzers abläuft, und einen von allen Benutzern

gemeinsam genutzten Teil (Server, Backend) aufgeteilt ist.“

3 Anforderungen aus Theorie und Praxis Seite 13

3 Anforderungen aus Theorie und Praxis

Aufgabe dieses Kapitels ist es, die für diese Arbeit relevanten theoretischen und

praktischen Grundlagen vertiefend darzustellen und zu diskutieren. Dazu wird in Kapitel

3.1 das Konzept der Nutzerkreise hergeleitet. Kapitel 3.2 stellt die zur Entschei-

dungsfindung in einer Multiprojektlandschaft erforderlichen Abläufe dar. Konkrete

Anforderungen an dazu benötigte Frontend-Systeme werden in Kapitel 3.3 definiert. In

Kapitel 3.4 werden die im Rahmen dieser Arbeit durchgeführten Experteninterviews

präsentiert.

3.1 Nutzerkreise

Aufbauend auf die in Kapitel 2.2 eingeführten Termini im Kontext des institutionellen

Projektmanagements werden in diesem Kapitel die zum (Multi-)Projektmanagement

erforderlichen Nutzerkreise innerhalb eines Unternehmens identifiziert. Diese erlauben

eine Kategorisierung der betrieblichen Endbenutzer in Zielgruppen für ein Frontend-

System zur Entscheidungsunterstützung bei der Multiprojektkoordination.

Die Projektmitarbeiter bilden dabei die Basisebene in der Hierarchie. Sie sind die zur

Realisierung des Projektes nötigen Fachkräfte und werden für die operative Projektarbeit

eingesetzt. Als „Ressourcen“ haben sie nur in Ausnahmefällen Planungs- und

Steuerungsaufgaben im Projekt durchzuführen.

Eine dispositive Funktion nimmt der für die Leitung des Projektes zuständige Projekt-

leiter ein: er führt das Projektteam (Management des Projektes) und ist für die fach- und

termingerechte Abwicklung des Projektes zuständig. Neben den dazu notwendigen

kontrollierenden und steuernden Maßnahmen fällt auch die Projektplanung in seinen

Aufgabenbereich. Ferner ist er mit Administrationsarbeiten betraut [Krüger 1994,

S. 374].

Auf der Ebene des Multiprojektmanagement/Topmanagement findet die Multi-

projektkoordination statt (Management von Projekten). Diesem Nutzerkreis sind in

übergeordneter Funktion die Mehrprojektleiter zuzuordnen. Ferner gehören ihm die

Mitglieder der Projektgremien an.

Burghardt unterscheidet dabei zwischen Planungs-, Beratungs-, Steuerungs-, Entschei-

dungs- und Kommunikationsgremien [Burghardt 1995, S. 83 ff.]. Jenny führt zusätzlich


noch ein Kontrollgremium an [Jenny 1995, S. 119 ff.]. Entscheidend ist dabei nicht die

Anzahl vorgesehener Gremien, sondern die Tatsache, daß bei beiden Autoren eine iso-

lierte Betrachtung einzelner Projekte impliziert wird (auch unter dem angelsächsischen

Begriff des Single Project Management in der Literatur verbreitet). Dies erscheint für ein

Unternehmen mit wenigen Projekten und einer isolierten Projektbetrachtung möglich und

sinnvoll, nicht aber bei der interdependenten Betrachtung von mehreren Projekten mit

unterschiedlichen Start- und Endezeitpunkten und Dauern. Hier bietet sich auf der Ebene

des Multiprojektmanagements die Einberufung eines Projektsteuerungs- und -

lenkungsausschusses an, der als übergeordnete Instanz von Projektleitern und Projekt-

team für die Umsetzung der Beschlüsse der Geschäftsleitung und die Einhaltung von

Zielvorgaben der Projekte verantwortlich ist [vgl. Nastansky/Ehlers 1996]. Eine solches

Gremium sehen Burghardt und Jenny in ihren Betrachtungen nicht vor – ihre Ausfüh-

rungen implizieren eine fehlende Interdependenz zwischen den Projekten.

Soll in einem projektorientierten Unternehmen das Führungskonzept des Managements

durch Projekte angewendet werden, so sind in diesem Nutzerkreis ferner die Mitglieder

des Topmanagements anzusiedeln.

Projektmitarbeiter

Projektleiter

Top-management,

Lenkungsausschuß {Entscheider

Planer

Management durch ProjekteManagement von Projekten

Multiprojektmanagement

Management des Projektes

Projektmanagement

operative Projektdurchführung

Projektmitarbeiter

{

Abb. 3.1-1: Nutzerkreise [in Anlehnung an Krüger 1994, S. 375 und S. 392]

Abbildung 3.1-1 faßt die eben gemachten Ausführungen zusammen. Der letztgenannte

Nutzerkreis „Multiprojektmanagement“ ist dabei im Rahmen dieser Arbeit von be-

sonderer Relevanz.

Die drei definierten Nutzerkreise sind durch die explizite Abgrenzung von Informations-

interessen innerhalb des Projektmanagements gekennzeichnet. Der Informationsbedarf


(zur Definition des Informationsbegriffes vgl. Kapitel 2.4) eines Projektmitarbeiters in

diesem Kontext ist relativ zu den beiden anderen Nutzerkreisen als andersgelagert ein-

zustufen. Er interessiert sich zunächst nur für die für ihn relevanten Projektabschnitte in

den Projekten, in denen er eingesetzt wird. Ein Projektleiter wiederum findet seinen

Primär-Interessenraum in den von ihm geführten Projekten. Auf der obersten Ebene

(Multiprojektmanagement) müssen die im Rahmen eines Multiprojecting erforderlichen

Informationen der jeweils beteiligten Projekte verfügbar sein [vgl. Ehrl-Gruber 1996,

Abschnitt 4.3.1.2 ff.].

3.2 Entscheidungsfindung im Projekt

Während der Durchführung eines Projektes liefert das Projektcontrolling Grundlagen-

informationen für erforderliche steuernde Maßnahmen, die zur Korrektur des Projekt-

ablaufs im Sinne der Erreichung der vorgegebenen Ziele notwendig sind [vgl. Haber-

fellner et al. 1994, S. 250 f.]. Haberfellner et al. formulieren die Zusammenhänge der

Parameter Quantität, Qualität, Dauer und Aufwand in einem Projekt (vgl. Abb. 3.2-1) als

„Teufelsquadrat“ [Haberfellner et al. 1994, S. 250].

Termin, Dauer

Leistungsumfang, Quantität

Qualität

Aufwand, Kosten

Fall a

Fall b

+

-

Ausgangszustand

++

+

--

--

+Legende:

Verbesserung

Verschlechterung

Abb. 3.2-1: „Teufelsquadrat“ [Haberfellner et al. 1994, S. 251]

Diese Darstellung erweitert das dreiparametrige Modell von Burghardt (vgl. Kapitel 2.1)

durch eine Untergliederung des Leistungsaspektes. Die Darstellung von Haberfellner et

al. bietet damit eine explizitere Abbildung der Projektziele.

Der Wunsch nach einem höheren Leistungsumfang bedeutet oftmals einen erhöhten

Projektaufwand (resultierend durch einen höheren Arbeitseinsatz) bzw. eine Verzö-

gerung des Projektablaufs (analog durch eine Verlängerung der Projektdauer), vielfach


begleitet von Qualitätseinbußen (Fall a in Abb. 3.2-1). Umgekehrt (Fall b in Abb. 3.2-1)

kann die Reduktion des Aufwandes (z. B. durch Mitarbeitermangel) Qualitäts- und/oder

Leistungseinbußen zur Folge haben (möglicherweise begleitet durch eine kürzere Pro-

jektdauer) [vgl. Haberfellner et al. 1994, S. 250 f.].

Bei der isolierten Betrachtung einzelner Projekte obliegt es daher dem Projektleiter als

verantwortlichem Entscheider, durch entsprechende Steuerung der einzelnen Parameter

innerhalb der sich ihm bietenden Möglichkeiten das Projekt zum erfolgreichen Abschluß

zu bringen.

Einen ungleich höheren Komplexitätsgrad hat die Entscheidungsfindung bei der Koor-

dination von Projekten in einer interdependenten, ganzheitlich zu betrachtenden Multi-

projektlandschaft. Die Steuerung einzelner Parameter innerhalb eines Projektes hat dabei

im schlimmsten Fall Auswirkungen auf alle anderen Projekte, die zeitgleich im

Unternehmen abgewickelt werden. Regelmäßig treten dabei Allokationsprobleme auf, da

Einsatzmittel nicht unbegrenzt zur Verfügung stehen.

Ein Beispiel soll dies verdeutlichen: in Projekt A wird die Ressource „Kran-Team“ für

einen weiteren Tag benötigt, da sich unvorhergesehene technische Probleme ergeben

haben. Als Folge davon tritt ein Ressourcenkonflikt mit Projekt B auf, für das die Res-

source „Kran-Team“ ebenfalls eingeplant war. Durch Vorhandensein entsprechender

Zeitreserven hat dies im Idealfall keine weiteren Auswirkungen auf die beteiligten

Projekte, bis auf die oben beschriebenen projektinternen (vgl. Fall b in Abb. 3.2-1).

Schlimmstenfalls können aber auch dort mehrere Parameter durch den Konflikt ver-

schoben werden (mangels Zeitreserven könnte sich ceteris paribus die Projektdauer

verlängern, damit würden wiederum regelmäßig die Kosten steigen, da die benötigten

Einsatzmittel z. B. ein Baugerüst oder für die gesamte Projektdauer an das Projekt ge-

bundene Mitarbeiter nicht kostenfrei zur Verfügung stehen).

Das bewußt einfach gewählte Beispiel zeigt, daß die Lösung solcher Problematiken nicht

trivial durchführbar ist. Burghardt schlägt dazu eine Abstimmung der vorhandenen

Ressourcen über Prioritätenvergabe für die einzelnen Projekte vor [Burghardt 1995,

S. 239]. Es bietet sich dabei an, eine vorratsbezogene Einsatzplanung mit rechner-

gestüzten Netzplanverfahren durchzuführen: dabei wird zunächst jedes Projekt als Teil-

netzplan geplant und anschließend auf höherer Netzplanebene zusammengeführt, wobei


bei Engpaßsituationen gemäß der vergebenen Prioritäten eine entsprechende Aufteilung

vorgenommen wird [Burghardt 1995, S. 240].

Projektspezifisches Corporate Data Model

Zur technischen Realisierung eines solchen Vorgehens im Rahmen eines computer-

basierten Informationssystems ist es erforderlich, die unternehmensweite Projektland-

schaft über ein einheitliches Corporate Data Model (CDM) abzubilden und damit ganz-

heitlich verfügbar zu machen. Die einzelnen Projekte sind dabei als dynamische Teil-

systeme der betrachteten Unternehmung zu verstehen. Durch Modellbildung (ein Modell

wird in diesem Zusammenhang als eine abstrahierte Darstellung der Realität definiert)

werden die für das Unternehmen relevanten Projektattribute (z. B. Projektname,

Vorgangsname, Vorgangsdauer, usw.) im Backend-System über das Corporate Data

Model abgebildet [vgl. Dangelmaier 1995, S. 2 ff.; Hansen 1992, S. 97 ff.]. Die Quelle

der Modelldaten ist dabei nicht von weiterer Relevanz. Die einzelnen Projektinfor-

mationen können beispielsweise aus den Zeit- und Kapazitätsmodellen unterschiedlicher

Netzplantools kommen. Neben den für die einzelnen Projekte relevanten Attributen

enthält das CDM im Rahmen eines einheitlich integrierten Backend-Ansatzes ferner die

Spezifikation für den gemeinsamen Ressourcenpool. Diese Art der Abbildung der

unternehmensweiten (Multi-)Projektlandschaft erlaubt (entsprechende Schnittstellen

vorausgesetzt) einen flexiblen Zugriff auf die Projektinformationen mit beliebigen

Frontend-Systemen.

Neben der Problematik, die sich aus der Tatsache ergibt, daß ein Modell immer nur einen

abstrakten Ausschnitt aus der Realität darstellen kann, muß bei einem funktionierenden

Multiprojektcontrolling dem Faktum Rechnung getragen werden, daß eine über ein

solches CDM abgebildete (Multi-)Projektlandschaft (in Abgrenzung zu einem Data

Warehouse mit voraggregierten historischen Daten [vgl. Mucksch et al. 1996, S. 422

ff.]) auch stets den aktuellen operativen Stand der aktiven Projekte enthält. Ferner gilt es

zu beachten, daß eine derartige Informationsbasis oftmals nur mangelhaft gepflegt wird.

„Technologiegestützte Kooperation“

Durch diese Ausführungen wird deutlich, daß eine einzelne Instanz (wie etwa ein

einzelner Projektleiter oder ein Multiprojektleiter) keine willkürlichen Entscheidungen

bezüglich anderer Projekte treffen sollte – es bedarf dazu eines übergeordneten Projekt-

lenkungsausschusses im Sinne eines partizipierenden Entscheidungsgremiums. Dieses


stimmt Kapazitäten zwischen den einzelnen Projekten ab, vergibt Budgets und legt – in

Abstimmung mit der Unternehmensstrategie – entsprechende Projektprioritäten fest

(etwa durch eine Projekt-Portfolioanalyse) [Fischbacher 1996, Abschnitt 2.7.2.2 S. 1].

Fischbacher spricht dabei von einer „fruchtbaren Diskussion“ [Fischbacher 1996, Ab-

schnitt 2.7.2.2 S. 1] innerhalb des Entscheidungsgremiums. Das Gremium kann dabei aus

Akzeptanz- und Komplexitätsgründen nicht die Planungsautonomie einzelner Pro-

jektleiter beschneiden: eine dezentrale Planung ist weiterhin erforderlich. Die notwendi-

gen Abstimmungsarbeiten finden allerdings zentral im Projektlenkungsausschuß statt

[vgl. Hügler 1988, S. 216 f.], dem auch die einzelnen betroffenen Projektleiter angehören

[Fischbacher 1996a, Abschnitt 2.7.2.2 S. 1]. Dabei wird deutlich, daß dazu ein hoher

Anteil verbaler Kommunikation erforderlich ist, der in keinem Fall durch die

abstrahierten „harten“ Datenmodelle eventuell eingesetzter Netzplantools allein ersetzt

werden kann. Ähnlich argumentieren auch Nastansky und Ehlers und sprechen daher von

einer „Technologiegestützten Kooperation“ [Nastansky/Ehlers 1996], vgl. dazu Abb.

3.2-2.

Ressourcen-Pool

Projekt n

Projekt 3Projekt 2

Projekt 1

Projektlenkungsausschuß

CDM: Unternehmensweite

Projektlandschaft

Abb. 3.2-2: „Technologiegestützte Kooperation“ [vgl. Nastansky/Ehlers 1996]

Eine derart abgebildete Projektlandschaft ermöglicht es, zur Entscheidungsvorbereitung

auf ein einheitliches Datenmodell zuzugreifen, die relevanten Parameter zu selektieren,

ggf. zu aggregieren und in einer für die Entscheidungsfindung geeigneten Form darzu-

stellen. Das gilt sowohl für den einzelnen Projektleiter bei der Durchführung des Pro-


jektcontrollings für die ihm zugeordneten Projekte, aber auch im Besonderen für das

Multiprojektmanagement.

CDMModell

Realwelt

Parameter

DSS

Termin, Dauer

Qualität

Aufwand, Kosten

Fall a

Fall b

+

Ausgangszustand

++

+

----

Projekt i

Abb. 3.2-3: Entscheidungsfindung in einer interdependenten Projektlandschaft

Grafiken als Entscheidungsgrundlage

Für den letzten Schritt bieten sich sinnvolle Darstellungsmöglichkeiten etwa durch Gra-

fiken, Balkenpläne o. ä. an. Ziel ist es dabei für ein Multiprojektcontrolling eine

Gesamtübersicht aller Projekte herzustellen, um Konflikte schon möglichst im Vorfeld zu

erkennen [vgl. Fischbacher 1996, Abschnitt 2.7.3.1 S. 1]. Grafiken helfen bei der

Argumentation und sind zum Erkennen von Trends behilflich. Grafische Informationen

werden dabei schneller verstanden als textuelle [Chorafas 1987, S. 237 f.]. Nach

Burghardt [Burghardt 1995, S. 469] ist der leichten Visualisierung von Projektdaten eine

wachsende Bedeutung zuzuschreiben. Diese Aspekte werden vertiefend in Kapitel 4.1

behandelt.

Rückkoppelungsprozeß bei der Entscheidungsfindung

Aufgrund der vorliegenden grafischen Informationen, die als Entscheidungsgrundlage zur

Meinungsbildung fungieren, können potentielle Konflikte erkannt, Prioritäten (neu)

gesetzt und im Anschluß daran wiederum dezidierte Parameter der einzelnen Projekte

durch die betreffenden Projektleiter als Konsequenz korrigiert werden. Es findet dabei

ein permanenter Rückkoppelungsprozeß statt (vgl. Abb. 3.2-3), der die Projekte

während ihrer gesamten Laufzeit begleitet.


3.3 Leistungsmerkmale eines DSS/EIS

Die Literatur definiert eine ganze Reihe von Leistungsmerkmalen von DSS und EIS, die

als Anforderungen an die Funktionalität eines Systems zur Entscheidungsunterstützung

für die Multiprojektkoordination expliziert werden. Dabei liegt der Fokus auf der End-

benutzerorientierung – der „managementgerechten“, d. h. möglichst einfachen Bedienung

eines solchen Informationssystems. Die Anforderungen lassen sich in fünf Kategorien

gliedern:

1. Endbenutzer-Interaktions-Aspekte

• Unterstützung von üblichen GUI-Merkmalen (GUI: Graphical User Interface,

dt. grafische Benutzerschnittstelle), wie Fenstertechnik, Maussteuerung, Pull-

Down-Menüs wie sie moderne Betriebssysteme anbieten [Bromann 1991, S. 45

ff.; Oppelt 1995, S. 160; Tiemeyer/Zsifkovits 1995, S. 50]

• Einfache Bedienung möglichst ohne Tastaturbenutzung nur durch Maus-

steuerung [Leidner/Elam 1995, S. 140; Oppelt 1995, S. 156]

• Intuitive Benutzbarkeit resultierend in kurzen Einarbeitungszeiten, insbesondere

für die sporadische Nutzung wichtig [Oppelt 1995, S. 156; Rieger 1990, S. 504]

• Ergebniserstellung sollte mit wenigen Aktionen möglich sein – „quasi auf

Knopfdruck“ [Tiemeyer/Zsifkovits 1995, S. 51 ff.]

• Hypermedia-Interface [Parsaye/Chignell 1993, S. 327]

• Interaktive Erstellung von Berichten und Grafiken [Tiemeyer/Zsifkovits 1995,

S. 94]

• Möglichkeiten des Drill-Downs: d. h. die schrittweise Untersuchung von Daten

mit jeweils unterschiedlichem Detaillierungsgrad, um einen flexiblen und

interaktiven Zugang zu den Informationen zu haben [Burkan 1991, S. 141;

Kornblum 1994, S. 87 f.; Leidner/Elam 1995, S. 140; Oppelt 1995, S. 155;

Tiemeyer/Zsifkovits 1995, S. 50 ff.]

2. Ausgabeerzeugungs- und -gestaltungs-Aspekte

• Aufbereitung der gewonnenen Abfrageergebnisse in grafischer Form als 3D-

Präsentationsgrafiken, Säulen-, Linien- und Kreisdiagrammen, mit flexibler


Auswahl des Diagrammtyps [Leidner/Elam 1995, S. 140; Tiemeyer/Zsifkovits

1995, S. 135]

• Kombinierte Bildschirmgestaltung, d. h. neben Grafiken auch Ergebnisse in

textueller Form, z. B. für die Anzeige von Hintergrundinformationen zur

weiteren Erklärung [Eason 1992, S. 13; Kornblum 1994, S. 88; Oppelt 1995,

S. 156; Parsaye/Chignell 1993, S. 328; Tiemeyer/Zsifkovits 1995, S. 53 f.]

• Sichtenspezifische Definition von Informationsfiltern [Bromann 1991, S. 45]

• Möglichkeiten der Ad-hoc-Analyse aber auch der standardisierten Abfrage

durch vordefinierte Reports [Bromann 1991, S. 45; Leidner/Elam 1995, S. 141;

Oppelt 1995, S. 156; Tiemeyer/Zsifkovits 1995, S. 51 ff.]

• Möglichkeit der einfachen Abänderung der Reportdefinitionen und Parameter

[Burkan 1991, S. 65; Kornblum 1994, S. 87 f.]

• Managementgerechte Weiterverwendbarkeit von Abfrageergebnissen ohne un-

nötige Medienbrüche, z. B. für die Übernahme in Präsentationsgrafik-

Applikationen im Sinne eines für den Nutzer transparenten Datenaustausches

[Bromann 1991, S. 45; Oppelt 1995, S. 156; Rieger 1990, S. 504]

3. Sicherheits-Aspekt

• Vorhandensein eines verläßlichen Sicherheitsmechanismus zur Verhinderung

von externem als auch internem unautorisierten Zugriff auf die teilweise hoch-

sensitiven Informationen [Eason 1992, S. 12 ff.]

4. Team-Aspekte

• Unterstützung von Aspekten der Teamarbeit [Eason 1992, S. 12 f.]

• Kommunikationskomponente, regelmäßig gefordert als E-Mail-Schnittstelle

[Bromann 1991, S. 45; Kornblum 1994, S. 88; Oppelt 1995, S. 156;

Tiemeyer/Zsifkovits 1995, S. 51 ff.]

5. Connectivity-Aspekte

• Einbettung in eine Client-Server-Architektur (CSA), vorteilhaft bei Einbindung

heterogener Hardware- und Softwaresysteme [Oppelt 1995, S. 154 f.;

Tiemeyer/Zsifkovits 1995, S. 61 f.]


• Möglichkeit der mobilen Nutzung, da der betriebliche Entscheider viel unter-

wegs ist [Bromann 1991, S. 46; Eason 1992, S. 12 f.]

3.4 Experteninterviews

Der Autor hat im Rahmen dieser Arbeit im Dezember 1996 eine Experteninterview-

Reihe bei dreizehn Kunden des kooperierenden Paderborner Unternehmens durchgeführt.

Zielsetzung

Die Experteninterviews sollen die Arbeit durch qualitative empirische Eindrücke an-

reichern. Die beschriebenen Ergebnisse sollen die in der Literatur aufgezeigten Trends

über die Relevanz der Thematik in der betrieblichen Praxis in der zweiten Hälfte der 90er

Jahre tendenziell belegen und eine integrale Abstützung der durch die Theorie gemachten

Aussagen darstellen sowie konkrete Anregungen für die praxisnahe softwaretechnische

Umsetzung einer Lösung geben.

Untersuchungsumfeld

Sämtliche Interviewpartner sind den drei in Kapitel 3.1 definierten Nutzerkreisen zu-

ordenbar: es handelte sich um Multiprojektleiter, Projektleiter und Projektmitarbeiter.

Diese waren ausnahmslos mit dem Einsatz von Methoden und Techniken des Projekt-

managements vertraut und den betrieblichen Funktionsbereichen Datenverarbeitung bzw.

Organisation zuzuordnen. Die Unternehmen der Befragten gehörten verschiedenen Bran-

chen an: von international tätigen Konzernen aus dem Bereich der Unterhaltungs-

elektronik über Automobilzulieferer, Versicherungen und Bankdienstleister, bis zum

Werftbetrieb und einem Unternehmen der chemischen Industrie wurde ein breites

Spektrum abgedeckt. Die Mitarbeiterzahl schwankte dabei zwischen 130 - 28 000 Per-

sonen.

Vorgehensweise

Als Erhebungsart wurde die fernmündliche Einzelbefragung gewählt. Die Antworten

wurden dabei stichwortartig mitgeschrieben. Siebzehn Unternehmen wurden dazu im

Vorfeld angeschrieben (vgl. Anhang C.2.1) und die ausgewählten Personen einige Tage

später telefonisch interviewt.

Die Erhebungsphase erstreckte sich über einen Zeitraum von zwei Wochen. Dreizehn der

angeschriebenen Personen waren spontan oder zu einem späteren Zeitpunkt zu einem

Interview bereit, vier Personen lehnten ein Interview ab bzw. waren nicht erreichbar.


Die Interviews wurden ausnahmslos durch den Autor geführt. Durch offene Infor-

mationen wurde versucht, eine psychologische Belastung bei den Befragten zu vermeiden

und ein möglichst kooperatives Sympathiefeld aufzubauen [vgl. Schmidt 1994, S. 156].

Dies war durch die hohe Bedeutung, die die preisgegebenen Antworten der Befragten

z. T. für die betroffenen Unternehmen darstellten, in Bezug auf ein positives

Gesprächsklima von Vorteil. Die anonymisierten Ergebnisse liegen in Anhang C.2.3 vor.

Aufgrund der Gewichtung im Rahmen dieser Arbeit entschied sich der Autor für eine

explorative Vorgehensweise. Als Interviewform wurde das halbstandardisierte Interview

gewählt, um möglichst gleiche Bedeutungsinhalte bei den Befragten anzusprechen und

sich den Interviewpartnern anzupassen [vgl. Schmidt 1994, S. 158 f.]. Der dabei ver-

wendete Interviewleitfaden findet sich in Anhang C.2.2.

Die Dauer der Interviews betrug jeweils zwischen 20 und 30 Minuten.

Ergebnisüberblick

1. Der Unternehmensphilosophie des „Management by Projects“ wurde bei fast allen

Befragten eine stark zunehmende Bedeutung zugeschrieben. Den in diesem Zu-

sammenhang notwendigen Methoden des Multiprojektmanagements wurde eine hohe

Wichtigkeit bescheinigt, die nach Meinung einer Mehrheit der Befragten in der Zu-

kunft noch weiter zunehmen wird.

2. Die Visualisierungsfähigkeiten der heute im kommerziellen Bereich erhältlichen Appli-

kationen werden im Bereich Multiprojektmanagement als überwiegend mangelhaft

empfunden. Ferner wurde in diesem Kontext oftmals eine nicht endbenutzergerechte

Bedienbarkeit kritisiert, die die Generierung von „ad hoc“ Visualisierungen nach

bestimmten Kriterien zu langwierig erscheinen läßt.

3. Groupware-Plattformen und insbesondere E-Mailing als Kommunikationsform haben

sich bis in die obersten Führungsebenen in fast allen Unternehmen, denen die Befrag-

ten angehörten, durchgesetzt, bzw. sind im flächendeckenden Einsatz mittelfristig

vorgesehen.

4. Moderne Informationssysteme mit Möglichkeiten zur Entscheidungsunterstützung

sind bei einigen der Befragten bereits im operativen Einsatz, bzw. wird ein Einsatz zur

Zeit erwogen und intern diskutiert. Solche Applikationen sollten über „State-of-the-

Art“ Benutzerfreundlichkeit verfügen und insbesondere für das Topmanagement mit

„wenigen Mausklicks“ quasi „auf Knopfdruck“ bedienbar sein.


5. In Bezug auf den Einsatz von Lösungen, die nicht nur Projektleiter als Nutzer vorse-

hen, sondern auch Projektmitarbeiter, herrschte kein signifikanter Konsens bei den

Befragten. Es bleibt zu konstatieren, daß dieses von der jeweiligen Unternehmens-

kultur abhängt: einige postulieren ein nach innen hochgradig transparentes Unter-

nehmen, bei dem jeder Mitarbeiter Zugriff auch auf projektspezifische Informationen

seiner Kollegen haben sollte, nicht zuletzt deshalb, um dadurch mögliche Synergie-

effekte der Teamarbeit ausnutzen zu können, andere Unternehmen mit eher konser-

vativen Strukturen lehnen dies strikt ab. Vielfach wurde eine flexibel skalierbare

Möglichkeit gefordert. Die Möglichkeit, daß Führungskräfte Systemanfragen an ein

DSS aus den verschiedensten Motiven an andere Mitarbeiter delegieren, wurde re-

gelmäßig nicht ausgeschlossen.

6. Ebensolche Uneinigkeit herrschte bei der Frage nach zur Visualisierung besonders

favorisierten Projektparametern (vgl. Kapitel 2.1 und 3.2). Die gewonnenen Aussagen

lassen den Schluß zu, daß dies nicht nur unternehmens-, sondern sogar organi-

sationseinheitenspezifisch variiert.

4 Stand der Technik und Trends Seite 25

4 Stand der Technik und Trends

In diesem Kapitel werden aktuell im Projektmanagement erhältliche Lösungen zur

Visualisierung von Projektinformationen kritisch betrachtet. Ferner wird der Trend zur

projektorientierten Unternehmung belegt und „Management by Projects“ als innovatives

Führungskonzept solcher Organisationen vorgestellt. Im Anschluß daran werden anhand

der historischen Entwicklung von Systemen zur Entscheidungsunterstützung techno-

logische Trends aufgezeigt. Das Kapitel wird mit der Vorstellung eines aus den Grund-

lagen der vorhergehenden Abschnitte entwickelten Gesamtkonzeptes abgeschlossen.

4.1 Visualisierung von Projektdaten

Der beim (Multi-)Projektcontrolling regelmäßig erforderliche Plan-/Ist-Vergleich von

Projektparametern wird besonders durch Nutzung von Grafiken und Balkenplänen er-

leichtert. Schmidt formuliert dazu pragmatisch „Die Technik der Visualisierung ist eines

der wichtigsten Instrumente der gesamten Projektarbeit“ [Schmidt 1994, S. 415]. Als

Vorteile der Visualisierung sind die folgenden Punkte aufzuführen [Chorafas 1987,

S. 237 f.; Schmidt 1994, S. 415]:

• Vereinfachtes Erkennen von Zusammenhängen und möglichen Trends

• Erhöhte Aufmerksamkeit bei der Zielgruppe

• Orientierungshilfe bei der Präsentation

• Verkürzung der erforderlichen Dauer für Sitzungen im Vergleich zur Nicht-

verwendung von Visualisierungen

• Unterstreichung von Aussagen, Hilfe bei der Argumentation und Entschei-

dungsfindung

• Verbesserung der Lerneffekte bei den Rezipienten

Kommerziell erhältliche PM-Werkzeuge wie Microsoft Project, CA-SuperProject, IMSI

TurboProject und andere bieten neben ihren komplexen Kalkulationsfähigkeiten auch

regelmäßig die Möglichkeit, Projektdaten grafisch darzustellen. Reichen diese in-

tegrierten Funktionalitäten nicht aus, existieren sogenannte „Add-ons“ wie beispielsweise

GRANEDA der Firma NETRONIC, die auf die eben genannten Tools aufbauen und

noch differenziertere Möglichkeiten der Darstellung bieten.


Abb. 4.1-1: Gantt-Diagramm

Die in kommerziellen PM-Werkzeugen regelmäßig vorzufindenden Visualisierungs-

möglichkeiten sind Gantt-Diagramme (spezielle Balkendiagramme, bei denen Tätig-

keiten, Vorgänge, Phasen, usw. als parallel zur Zeitachse verlaufende Balken symbo-

lisiert werden, vgl. Abb. 4.1-1), PERT-Diagramme (eine Variante der Netzplantechnik

zur Darstellung von Abhängigkeiten innerhalb des Projektablaufs), Projektstrukturpläne

(die grafische Gliederung eines Projektes in hierarchische Teilabschnitte/-aufgaben –

diese Form der grafischen Darstellung ist zum Projektcontrolling ungeeignet und findet

ihren Einsatz hauptsächlich bei der Projektplanung), Histogramme (spezielle Zeitdia-

Abb. 4.1-2: Histogramm

gramme, bei denen eine Achse mit einem Zeitmaßstab belegt wird und eine weitere mit

einer Projektbezugsgröße, deren zeitlicher Verlauf dargestellt werden soll, vgl. dazu

Abb. 4.1-2), sowie Standardgrafiken wie Säulen-, Linien, Kreis- und Flächendiagramme


(zur Visualisierung bestimmter Projektbezugsgrößen, wie z. B. Kosten, Dauern, Auf-

wände).

Parsaye und Chignell fordern diese bewährten Visualisierungsformen zur Darstellung von

Projektinformationen beizubehalten und um neuere Konzepte wie interaktive 3D

Grafiken und die Einbettung in Hypermediasysteme zu bereichern [Parsaye/Chignell

1993, S. 406].

Die Bedienung solcher Werkzeuge wird oftmals von den Anwendern als nicht sehr end-

benutzerfreundlich und zu komplex empfunden. Die Ergebnisse der in Kapitel 3.4 be-

schriebenen Experteninterviews können dies tendenziell belegen. Ein weiterer Kritik-

punkt ist die mangelnde Adaptierbarkeit in Richtung auf häufig existierende unterneh-

mensinterne Standards. Dies ist durch die zugrunde liegenden rigiden Datenmodelle

bedingt, die nur schwer änderbar sind [Nastansky et al. 1995, S. 314 ff.]. Insbesondere

Mitglieder der Gruppe „Topmanagement“ des Nutzerkreises „Multiprojektmangement“

sind dabei vor erhebliche Probleme gestellt, sich einen bestimmten Sachverhalt ad hoc bei

Bedarf visualisieren zu lassen [vgl. King 1995, S. 167]. Die aus der Vielfalt an

Funktionalität resultierende Komplexität und Benutzerunfreundlichkeit steht im Gegen-

satz zu den Anforderungen an praxisnahe Lösungen zur schnellen Informationsextraktion

wie beispielsweise durch anschauliche Grafiken [vgl. Wischnewski 1993, S. 79].

Die hohe praktische Relevanz frei konfigurierbarer und vor allem unternehmensindivi-

duell anpaßbarer Standardgrafiken zum Projektcontrolling, die auf Anforderung ad hoc

mit minimaler Mensch-Maschine-Interaktion erzeugbar sind, wird durch die Ausfüh-

rungen von Götz deutlich [vgl. Götz 1996]. Er beschreibt die für einen deutschen Nah-

rungsmittelkonzern entwickelte Lösung zur managementgerechten Visualisierung von

Projektdaten, basierend auf einem vordefinierten und speziell für die Organisation von

der Unternehmensberatung Roland Berger entworfenem Reportlayout. Dieses dient der

Unternehmensleitung als Entscheidungsgrundlage für zu genehmigende Projekte und als

einheitliches Template für Reportdokumente beim Projektcontrolling zur Erfassung des

Projektstatus. Bei der Implementierung der Lösung arbeitete der Autor dieser Arbeit im

Projektteam mit. Die Praxisnähe und Aktualität dieser Thematik dokumentiert auch der

dazu erschienene Artikel [o. V. 1997a, S. 22 f.] in einem Fachmagazin.


4.2 Projektmanagement als Führungsstil

Die in Kapitel 2.1 definierte Bedeutung von Projektmanagement sowie die in Kapitel 2.3

angeführten Gedanken über den Stellenwert von PM in der Unternehmung bilden die

Grundlage der Ausführungen in diesem Kapitel. Dazu soll zuvor der Begriff des

Managements definiert werden: „Management ist generell der Vorgang der Willens-

bildung und Willensdurchsetzung“ [Haberfellner et al. 1994, S. 242].

Die Literatur stellt einen Trend zur projektorientierten Unternehmung fest, der wie folgt

motiviert wird:

• Durch die laufende Weiterentwicklung der Organisationsform der Unternehmen

– bedingt durch dynamische Märkte und ständig wachsende Anforderungen an

die Unternehmen – setzen diese verstärkt auf die Lösung von komplexen

Problemen durch Projekte oder projektähnlich-aufgebaute Gruppen (z. B.

strategische Geschäftsfelder oder Qualitätszirkel). Gareis konstatiert dabei, daß

neben den Unternehmen, die traditionell Projektmanagement durchführen (wie

etwa Unternehmen der Bau- und Anlagenbauindustrie), nun auch Unternehmen

aus anderen Branchen (z. B. Banken und Versicherungen, aber auch

Maschinenbauunternehmen) Projektmanagement-Methoden einsetzen [Gareis

1992, S. 145 f.].

• Bei den durchzuführenden Projekten handelt es sich nicht wie bisher um wenige

Großprojekte mit typischerweise sehr hohem Budget, sondern um zahlreiche

kleine, mittlere als auch große Projekte [Gareis 1991, S. 36]. Kleinprojekte sind

dabei als neue, besonders flexible Arbeitsform zu betrachten [Balck 1990, S. 64

f.].

• Zur Erhöhung der Produktivität und Verbesserung der Kommunikation führen

die Unternehmen eine Reduktion ihrer hierarchisch ausgerichteten Lei-

tungsebenen durch [Gareis 1990, S. 243].

Dieser Trend zur projektorientierten Unternehmung deckt sich mit den Erfahrungen des

Autors aus der Praxis in der Einführung von Projektmanagement-Werkzeugen bei ver-

schiedenen Unternehmen und den durchgeführten Experteninterviews (vgl. dazu Kapitel

3.4).


Die daraus resultierende gestiegene Anzahl innerbetrieblich zu bewältigender Projekte

führt bei den traditionellen Organisationsformen zu einer vorübergehenden organisa-

torischen Instabilität: vor Projektbeginn müssen die Mitarbeiter aus ihren Stamm-

abteilungen ausgegliedert, und nach Projektabschluß wieder eingegliedert werden.

Madauss folgert daraus „ein Projekt ist ein betrieblicher Unruheherd“ [Madauss 1994,

S. 10].

Die oben angeführte Reorganisation durch Verflachung von Organisationsstrukturen

ermöglicht eine Verkürzung von Informations- und Entscheidungswegen. Hierarchie-

ebenen werden dabei nach Möglichkeit in Projektorganisationen überführt (vgl. Abb. 4.2-

1) [Frank/Pudwitz 1994, S. 169 ff.].

flache Hierarchietiefe Hierarchie Projektorganisation

Abb. 4.2-1: Entwicklung der Organistationsstrukturen [Frank/Pudwitz 1994,S. 171]

Bei dieser Abflachung der Hierarchien entsteht eine Vergrößerung der Leitungsspanne.

Damit dies keine negativen Auswirkungen auf die Führbarkeit der Mitarbeiter hat, sind

nichtorganisatorische Koordinationsmechanismen erforderlich. Leistungsfähige Infor-

mations- und Kommunikationssysteme sollten diesen Prozeß unterstützen [vgl. Krüger

1994, S. 88].

„Management by Projects“

Die in Kapitel 2.3 definierte Organisationsform der reinen Projektorganisation kann in

extremer Anwendung derart ausfallen, daß das ganze Unternehmen nach Projekten ge-

gliedert ist (z. B. bei Beratungsunternehmen) [Krüger 1994, S. 398]. Während Krüger

dies als Spezialfall deklariert, postuliert Gareis sie als Organisationsform der Zukunft

[Gareis 1992, S. 145]. Das projektorientierte Unternehmen mit seiner heterogenen und

ganzheitlich betrachteten Projektlandschaft benötigt eine neue Management-Philosophie,

dem „Management by Projects“. Es geht dabei nicht mehr um das Management einzelner

Projekte (dem Single Project Management), sondern um das „Management durch


Projekte“, bei dem Projekte „die Form des Handelns und Produzierens der Zukunft“

[Saynisch 1990, S. 31] sind.

„Management by Projects“ bildet dabei die zentrale Managementstrategie für die

Hauptteile der Organisation eines projektorientierten Unternehmens. Dies wird nicht nur

durch die Anwendung von Projektmanagement-Methoden und -Techniken für einzelne

Projekte und auf das Netzwerk von Projekten im Sinne eines Multiprojektmanagements

deutlich, sondern auch durch eine gänzlich neue Unternehmenskultur. Diese ist durch

neue Werte, Normen und Regeln geprägt und zeichnet sich durch offene Kommunikation

und Teamverhalten aus, was zu einer Unterstützung des oben beschriebenen Prozeß zur

Verflachung der Organisationsstrukturen führt [Gareis 1991, S. 37 ff.].

Die hohe praktische Relevanz dieser Thematik wird auch von Roux-Kiener, Director of

Organization von IBM Europe (IBM: International Business Machines) dokumentiert:

sie beschreibt den Wandel des Unternehmens von einer traditionellen, pyramiden-

förmigen zu einer projektorientierten Organisation und stellt dabei heraus, daß dies große

Auswirkungen auf das Unternehmen als ganzes bedeutet. Möglich geworden ist ein

solcher Strukturwandel durch neue Technologien, die die traditionelle Art zu kom-

munizieren und kooperieren umgestalten, wie Netzwerke und E-Mail [Roux-Kiener

1991, S. 111 ff.]. Einen exemplarischen Implementierungsansatz der Management-

strategie „Management by Projects“ beschreiben DesRosiers und Pinard

[DesRosiers/Pinard 1991, S. 105 ff.] für die kanadische CGI Gruppe (CGI: Conseilliers

en Gestion Informatique), deren Geschäftsfelder im Bereich Dienstleistungen für Tele-

kommunikations- und Informationstechnologien und Management-Beratung liegen: 90%

der Mitarbeiter werden dabei nach der neuen projektorientierten Managementphilosophie

geführt, die restlichen 10% sind in einer hierarchischen Struktur verblieben (vorwiegend

administrative Aufgaben wie z. B. Personal- und Rechnungswesen). Diese

Strukturierung erlaubt einerseits eine hohe Flexiblilität, gibt andererseits einen stabilen

Rückhalt durch den Verbleib der administrativen Dienste im klassischen Schema.

Kritik

Diese fast schon euphorische Postulierung von „Management by Projects“ sollte kritisch

betrachtet werden. Webb [Webb 1996] kritisiert daher zu Recht, wenn er darauf hin-

weist, daß sich nicht sämtliche Managementaufgaben durch Projekte verwirklichen

lassen, und man daher vor der ganzheitlichen Implementierung des „Management by


Projects“-Konzeptes die Möglichkeiten und Konsequenzen einer solchen Umsetzung

kritisch prüfen sollte und nicht jegliche Aufgabe und Aktivität leichtfertig zum Projekt

deklariert.

Zusammenfassung

Zusammenfassend ist festzustellen, daß sich der Trend zur projektorientierten Unter-

nehmung fortsetzt. Dabei ist es absolut notwendig, nicht die Ergebnisse von Einzelpro-

jekten isoliert zu betrachten, sondern auch in Interdependenz mit den Gesamtergebnissen

aller Projekte. Dazu bedarf es der Methoden und Techniken des Multipro-

jektmanagements.

4.3 Paradigmenwechsel in der Informationstechnologie

Decision Support Systems und Executive Information Systems haben ihre historischen

Wurzeln in den Management Information Systems, die in den 60er und frühen 70er

Jahren entstanden. Diese als MIS oder auch als Management Reporting System (MRS)

bezeichneten computerbasierten Informationssysteme haben als Zielsetzung die regel-

mäßige oder fallweise Bereitstellung von Dokumentations-, Analyse- oder Kontroll-

informationen für Führungskräfte [Oppelt 1995, S. 10].

term> print *reports* ALL

Abb. 4.3-1: Historisches Paradigma der Datenverarbeitung

Die durch MIS generierten Reports waren papierbasierte Listen größeren Umfangs (vgl.

Abb. 4.3-1). Die Umsetzung einer Anfrage des Managements nach einem solchen Report

dauerte für die Programmierer („Operators“) bis zu zwei Monate („Batch-processing“).

Zeitkritische Informationen waren also nicht verfügbar, was den Wert dieser Systeme für

die operative Planung als nicht sehr hoch erscheinen läßt. Weitere Kennzeichen solcher

Systeme war die geringe Aggregationsdichte der ausgegebenen Informationen – i. d. R.

enthielten sie lediglich nach bestimmten Sortierkriterien angeordnete Datensätze – und

sehr geringe Analysefähigkeiten. Grafische Auswertungen waren aufgrund der seinerzeit


noch mangelnden Technologie nicht enthalten [Parsaye/Chignell 1993, S. 322;

Tiemeyer/Zsifkovits 1995, S. 13].

Diese Fremdproduzierung durch das Fachpersonal ist als Mangel solcher MIS zu sehen,

da sie quasi parallel zur persönlichen Informationsverarbeitung der Entscheider im

Office-Umfeld entstanden sind [Nastansky/Seidensticker 1990, S. 520 f.].

Die Benutzerakzeptanz gegenüber solchen MIS war entsprechend gering. Behrens kon-

statiert einen Schritt in die richtige Richtung, „aber eine volle Zufriedenheit mit den

Ergebnissen konnte nicht erreicht werden“ [Behrens 1994, S. 7 f.].

Zeit

MIS

ESS

DSS

1990198019701960

EIS

heute

Data Warehouse

OLAP

Kat

ego

rie

Abb. 4.3-2: Historische Entwicklung computerbasierter Informationssysteme

Als nächster Schritt in der Evolution der computerbasierten Informationssysteme kamen

Ende der 70er Jahre die DSS auf: der Schwerpunkt liegt bei der Unterstützung von Ad-

hoc- als auch routinierten Entscheidungen.

Wenig später zu Beginn der 80er Jahre wurden die Executive Support Systems (ESS)

eingeführt. Diese zeichnen sich gegenüber den DSS durch eine eingeschränktere Be-

nutzergruppe und einen breiteren Funktionsumfang aus [Oppelt 1995, S. 153].

In der Mitte bis Ende der 80er Jahre kamen die EIS auf. Der Fokus dieser neuen Kate-

gorie von Informationssystemen liegt in der Bedienerfreundlichkeit und der besonderen

Zielgruppe: dem Topmanagement, das für die im Rahmen seines gesamtunterneh-

merischen Leistungs- und Verantwortungsumfangs zu treffenden Entscheidungen speziell

zugeschnittene Informationssysteme benötigt [Oppelt 1995, S. 5].


„Klassische MIS“ moderne EIS

• Zentralrechner-Orientierung • Einbeziehung leistungsstarker Arbeits-platzrechner

• Einseitige VerbindungTerminal/Zentralrechner

• vielfältige Vernetzungskonzepte (Client-Server-Architekturen)

• umständliche zeichenorientierte Bedie-nung

• einfache Bedienung durch grafischeOberfläche und Maussteuerung

• Fremdentwicklung und Modifikation derAnwendungen

• Eigenentwicklung leichter möglich

Tab. 4.3-1: Paradigmenwechsel: MIS vs. EIS [Tiemeyer/Zsifkovits 1995, S. 24]

Die technologischen Gegensätze, die bei diesem Paradigmenwechsel überwunden

wurden, zeigt Tabelle 4.3-1. Unzureichende Host-basierte Technologien wurden durch

leistungsstarke Client-Server-Architekturen ersetzt. Der Wandel, der sich dadurch in der

Akzeptanz bei den Nutzern solcher Systeme vollzogen hat, wird durch folgende Statistik

deutlich: 1982 hatten 33% der Führungskräfte eine positive Einstellung zur eigenen

Nutzung von Informationssystemen, 1994 waren es bereits 95% [Tiemeyer/Zsifkovits

1995, S. 22].

Nach Tiemeyer und Zsifkovits sind moderne Client-Server-Architekturen für EIS/DSS-

Lösungen besonders prädestiniert [Tiemeyer/Zsifkovits 1995, S. 67 ff.]. Die Vorteile

solcher CSA liegen nicht zuletzt auch auf administrativer Seite – der Umweg der Infor-

mationsbeschaffung über oben aufgeführtes Fachpersonal wird damit obsolet [Curtis

1989, S. 115; Wall 1988, S.18 f.].

Neuere Technologien in diesem Umfeld sind das Data Warehouse-Konzept und das von

Codd postulierte Softwaretechnologiekonzept OLAP, das auf multidimensionalen

Datenstrukturen aus ursprünglich relationalen Datenbanken (mit einem üblicherweise

sehr hohen Transaktionsvolumen) nicht-operativer voraggregierter Daten fokussiert ist

[Tiemeyer/Zsifkovits 1995, S. 71 ff.]. Für eine detaillierte Beschreibung dieser

Nebenaspekte, die eine hohe aktuelle Relevanz besitzen, siehe [Codd 1993].

Die seit Beginn der 90er Jahre existierenden Workgroup Computing-Lösungskonzepte

führen weg vom klassischen EVA-Paradigma (EVA: Eingabe, Verarbeitung, Ausgabe)

und spiegeln gleichzeitig eine Neuorientierung der Informationssystem-Strukturen wider.


Darin liegen erhebliche Perspektiven für zukünftige EIS-/DSS-Applikationen, indem sie

oben beschriebene Akzeptanzprobleme durch „attraktives Informationsmanagement“

[Nastansky et al. 1995, S. 348] überwinden helfen.

KoordinierenKooperierenKommunizieren

Arbeitsgruppen-Server

Abb. 4.3-3: Moderne Client-Server-Architektur: Verteiltes Arbeiten in Teams

Solche teamorientierten innovativen Informations- und Kommunikationssysteme (vgl.

Abb. 4.3-3) zeichnen sich durch folgende Architekturmerkmale aus [Nastansky et al.

1995, S. 279 ff.]:

• Verteilte Datenbanken mit leistungsstarken Replikationskonzepten

• Multimediale Datentypen

• Integrierte Gruppenkommunikation

• Text- und Dokumentenmanagement

• Import- und Exportfunktionalitäten

• Umfassende Sicherheitskonzepte

• Soft- und hardwaremäßige Plattformunabhängigkeit

• Leistungsstarke integrierte Entwicklungsumgebung

Derartige Plattformen erlauben effizientes Informationsmanagement und -retrieval und

tragen zu einer Vermeidung unnötiger Medienbrüche bei. Ferner bieten sie eine Kom-

munikationsplattform zur teamorientierten Entscheidungsfindung im Projektmanagement


in einem verteilten Umfeld – im LAN (Local Area Network, dt. lokales Netz), WAN

(Wide Area Network, dt. Weitverkehrsnetz) oder mobil (z. B. auf Notebooks).

Nach Kurbel ist Projektmanagement (und damit auch Multiprojektmanagement) auf-

grund seiner stark kooperativen Aspekte ein typisches Einsatzgebiet für CSCW, vor

allem zum gegenseitigen Informationsaustausch [vgl. Kurbel 1993, S. 50 ff.]. Group-

ware-Systeme verbessern die Ideen-Generierung und Problemanalyse und bieten eine

Beschleunigung des Entscheidungsfindungsprozesses [Leventhal 1995, S. 6]. Damit

stellen sie eine ideale informationstechnologische Grundlage für das im Rahmen dieser

Arbeit zu entwickelnde Frontend-System dar, indem sie Teamarbeit und die hervor-

gehenden Synergieeffekte moderner Organisationsformen bewußt unterstützen.

4.4 Gesamtkonzept einer Lösung

Aufgrund der im dritten Kapitel definierten Anforderungen aus Theorie und Praxis sowie

den in den vorherigen Abschnitten von Kapitel 4 dargestellten Trends wird in diesem

Abschnitt eine Umsetzung der dort aufgeführten Grundgedanken vorgenommen. Es wird

dazu ein integriertes Architekturmodell eines flexiblen und verteilten Frontend-Systems

für Planer und Entscheider zur Entscheidungsunterstützung bei der Multipro-

jektkoordination vorgestellt, dessen prototypische Implementierung in den Kapiteln 5

und 6 beschrieben wird. Aus diesem Grund wird an dieser Stelle bewußt auf Aspekte der

technischen Umsetzbarkeit verzichtet. Das Architekturmodell beschreibt den Aufbau und

die Konzeption eines solchen Frontend-Systems.

Es besteht dabei aus sechs interdependenten Modulen, die im folgenden (vgl. Abb. 4.4-1)

vorgestellt werden.

1. DSS UI

Das DSS UI (UI: User Interface, dt. Benutzerschnittstelle) bildet die Schnittstelle zum

Endbenutzer des Systems. Hier findet die Mensch-Maschine-Interaktion statt. Das

Modul enthält zwei wesentliche Subkomponenten: das Parametrisierungssubmodul und

das Reportingsubmodul. Im Parametrisierungssubmodul werden die Anforderungen an

die durch das System zu realisierenden Anfragen individuell und flexibel durch den

Endbenutzer definiert. Das Reportingsubmodul ist für die Ausgabe der daraus resultie-

renden Abfrageergebnisse zuständig. Diese erhält es vom DSS Visualizer in vorbereiteter

Form. Die inhaltsbezogenen Ergebnisse werden dabei in der vom Benutzer im


Parametrisierungssubmodul definierten Darstellung ausgegeben. Hier kann der System-

nutzer bei Bedarf interaktiv zwischen verschiedenen Ebenen navigieren und eine explizite

Determinierung des Detaillierungsgrades der Ausgabe vornehmen.

CDM

InformationPull

5. Archiv 4. Visualizer

2. ApplicationEngine

6. Kommunikations-schnittstelle

3. GraphicalPre-Processor

Reporting-submodul

Parametri-sierungssub-

modul

1. DSS UI

Abb. 4.4-1: Architekturkonzept

2. DSS Application Engine

Die Aufgabe der Application Engine ist es, für die Bereitstellung der über das DSS UI

definierten Anforderungen an die zu extrahierenden Daten (durch die Spezifikation im

Parametrisierungssubmodul oder Änderung des Detailliertheitsgrades im Repor-

tingsubmodul) zu sorgen. Dazu findet ein „Information Pull“ der durch das Corporate

Data Model abgebildeten Projektinformationen aus dem integrierten Backend-System

statt.

3. DSS Graphical Pre-Processor

Der DSS Graphical Pre-Processor führt eine Aggregation der mittels der DSS

Application Engine extrahierten Daten durch und bereitet die Ergebnisse nach den im

Parametrisierungssubmodul spezifizierten Anforderungen zur Ausgabe auf.

4. DSS Visualizer

Die Funktion des DSS Visualizers ist es, als Graphic Engine eine Ausgabe der grafischen

Informationen vorzunehmen. Dazu übernimmt er die vom DSS Graphical Pre-Processor

vorbereiteten Informationen und führt diese direkt in die entsprechende Darstellung über.


5. DSS Archiv

Das DSS Archiv bildet einen nicht zentralen Bestandteil des Architekturmodells: die im

Reportingsubmodul des DSS UI präsentierten Abfrageergebnisse können hier bei Bedarf

langfristig abgelegt werden, was zum Beispiel einen über die Zeitachse durchführbaren

Vergleich ermöglicht. Ein solches Archiv ist nach dem „Share“-Modell zu konzipieren

und in eine verteilte Umgebung zu integrieren.

6. Kommunikationsschnittstelle

Die Kommunikationsschnittstelle hat die Aufgabe, die Abfrageergebnisse bei Bedarf

ohne Medienbrüche organisationsintern und -extern weiterzuleiten („Send“-Prinzip) und

verfügbar zu machen. Sie ist dementsprechend direkt an das Reportingsubmodul zu

koppeln.

Durch eventuell mögliche Änderung der Detailebene der Darstellung von Projekt-

informationen bildet dieses Architekturmodell mit den Komponenten 1-4 ein interaktiv-

zyklisches Kontinuum.

Integration im Rahmen einer „Technologiegestützten Kooperation“

Abbildung 4.4-2 verdeutlicht die mögliche Integration eines solchen Frontend-Systems

im Rahmen des in Kapitel 3.2 vorgestellten Gesamtkonzepts der „Technologiegestützten

Kooperation“:

Frontend-System

Backend-System

OrganisationZeit- und

Kapazitätsmodell

Abb. 4.4-2: Integration in „Technologiegestützte Kooperation“ [Nastansky/Ehlers1996]

Das Frontend-System erlaubt dabei als technische Komponente die Durchführung

statischer Auswertungen und deren Darstellung auf den durch das Corporate Data Model

einheitlich abgebildeten und im integrierten Backend-System enthaltenen


Projektinformationen. Die zu berücksichtigenden organisationsspezifischen Parameter

wie etwa Projekttyp und -größe stellen ein weiteres determinierendes Gestaltungselement

der Multiprojektkoordination dar. Ein integrierbares Zeit- und Kapazitätsmodell auf

Basis der Netzplantechnik stellt dynamische Simulations-, Analyse- und

Prognosemöglichkeiten zur Verfügung [vgl. Nastansky/Ehlers 1996].

5 Verwendete Arbeitsumgebung Seite 39

5 Verwendete Arbeitsumgebung

Innerhalb dieses Kapitels werden die für die softwaretechnische Umsetzung der Arbeit

verwendeten Grundlagentechnologien erläutert. Die in Kapitel 6 beschriebene proto-

typisch implementierte Lösung wurde dabei als auf der Groupware-Plattform Lotus

Notes basierende Anwendung mit dem Lotus Chart Component zur Visualisierung der

Projektinformationen realisiert. Das in Kapitel 3.2 eingeführte Corporate Data Model

wird durch die Projekte- und Ressourcendatenbanken der Projektmanagement-Umge-

bung PAVONE GroupProject abgebildet, die in Kapitel 5.3 beschrieben wird.

5.1 Lotus Notes

Lotus Notes ist nach einer Studie der International Data Corporation (IDC) 1996 das

weltweit führende Groupware-System auf dem Markt [o. V. 1997b, S. 2]. Notes ist ein

System zur Verwaltung verteilter Datenbanken in Client-Server-Umgebungen. Die

Datenbanken können dabei dezentral auf den Arbeitsstationen der Benutzer oder zentral

auf Servern im LAN, WAN oder mobil vorliegen. Intelligente Replikationsmechanismen

ermöglichen die Integrität der Datenbestände. Leistungsstarke und hochgradig

skalierbare hierarchische Sicherheitsfunktionen (unter Verwendung des RSA-

Kryptografieverfahrens) erlauben eine dezidierte Zugriffskontrolle. Lotus Notes bietet

eine integrierte (Gruppen-)Kalenderfunktionalität und stellt neben einer Messagingengine

eine leistungsfähige Integration in das Intra- und Internet zur Verfügung.

Paradigmen

Der Autor dieser Arbeit hält es für das bessere Verständnis der in Kapitel 6 folgenden

Ausführungen für erforderlich, einige Paradigmen von Lotus Notes an dieser Stelle näher

zu betrachten.

Dokumente

Zentrales Paradigma in Lotus Notes ist das Dokument. Jedes Dokument besteht aus

einer bestimmten Anzahl von Attributen, den Feldern. Ein Feld (Item) ist dabei durch

seinen Feldnamen, den Feldtyp und den Feldinhalt charakterisiert. Neben „harten“

klassischen Feldtypen (Text, Datum, u. a.) ist der Feldtyp Rich Text besonders zu

nennen, der hypermediale Datentypen (Audio, Video, Grafiken, eingebettete Fremd-

applikationen, Dateianhänge, Hypertextlinks) beinhalten kann. Da solcherart gestaltete


Dokumente eine eigene Verarbeitungsintelligenz enthalten können, werden sie auch als

Verbunddokumente (Compound Documents) bezeichnet [vgl. Nastansky et al. 1995,

S. 276 f. und 281 f.]. Jedes Dokumentenobjekt ist durch seine DocumentUniqueID ein-

deutig identifizierbar.

Masken

Masken (sogenannte Forms) bieten in Lotus Notes eine spezifische Sicht auf ein Doku-

ment. Eine Maske ermöglicht die endbenutzergerechte Darstellung von Informationen

aus den zugrundeliegenden Dokumenten. Differenzierte Hide-When-Mechanismen er-

möglichen ein besonders endbenutzerfreundliches Ausblenden nicht relevanter Attribute

und anderer Gestaltungselemente.

Ansichten

Ansichten ermöglichen auf Datenbankebene eine selektive Darstellung von relevanten

Teilinformationen der enthaltenen Dokumentenobjekte. Preview-Funktionalitäten erlau-

ben eine Vorabansicht selektierter Dokumente. Kategorisierungsfunktionalitäten mit der

Möglichkeit zur Komprimierung einzelner Kategorien ermöglichen eine übersichtliche

Betrachtung und Navigation auch innerhalb großer Dokumentenmengen.

Navigatoren

Ab Version 4.0 stehen in Lotus Notes Navigatoren als neues Architekturmerkmal bereit.

Sie dienen der Benutzerführung und erlauben eine besonders intuitive und endbenutzer-

gerechte grafische Navigation durch eine Notes-Anwendung.

Entwicklungsumgebung

Lotus Notes stellt eine leistungsstarke integrierte Entwicklungsumgebung zur Anwen-

dungsentwicklung zur Verfügung. Diese ermöglicht eine flexible Erstellung eigener

Groupware-Applikationen. Notes ermöglicht dem Anwendungsentwickler je nach Bedarf

an Funktionalität, eine frei skalierbare Komplexität zu nutzen: von vordefinierten

Funktionen (den Simple Functions) über die Nutzung der komplexeren Makro-Sprache

(den sogenannten @-Funktionen) zu LotusScript als objektorientierter BASIC-kompa-

tiblen Programmiersprache.

Script ist dabei über die in Notes integrierte Integrated Development Environment (IDE)

programmierbar. Lotus Notes bietet zur Implementierung von Script-Anwendungen ein

hierarchisches Klassenkonzept an.


Eine Beschreibung der vollen Funktionalität von Lotus Notes würde den Rahmen dieser

Arbeit sprengen. Für eine detaillierte Beschreibung von Notes in seiner aktuellen Release

4.5 vergleiche [Lotus 1996a]. Zusammenfassend ist zu konstatieren, daß Lotus Notes die

in Kapitel 4.3 definierten Architekturmerkmale eines modernen innovativen

Informations- und Kommunikationssystems vollständig aufweist.

5.2 Lotus Components

Lotus Components sind kleine aufgabenbezogene Softwaremodule (sogenannte Applets).

In der aktuellen Version 1.1 sind die Module „Chart“, „Draw/Diagramm“, „File Viewer“,

„Comment“, „Project“ und „Spreadsheet“ enthalten. Sie sind derzeit für die

Betriebssysteme Windows 95 und Windows NT verfügbar. Für Nutzer anderer

Plattformen oder solche, die die Components nicht an ihrem Arbeitsplatz installiert

haben, erscheint ein grafisches Abbild der Anwendung.

Technisch basieren die Components auf der ActiveX-Technologie [Lotus 1996b, S. 6]

und der Spezifikation des Microsoft Component Object Models (COM). Sie sind soge-

nannte OLE Custom Controls (OCX), eine Erweiterung der OLE-Spezifikation (OLE:

Object Linking and Embedding, eine Technologie zum objektorientierten Austausch von

Anwendungen aus Fremdapplikationen [vgl. Hansen 1992, S. 895]) und dadurch als

sogenannte Plug-Ins in Lotus Notes integrierbar. Notes dient dabei als Container-Appli-

kation und das jeweilige Component als Control. Damit lassen sie sich zur komfortablen

Dokumentenerstellung oder Anwendungsentwicklung unter Lotus Notes einsetzen. Für

den Endbenutzer wirken sie durch eine zusätzliche Menüleiste quasi in Notes integriert,

ihre Interaktionsmechanismen montieren sich völlig in die des Groupware-Systems und

bieten so ein konsistentes Notes-konformes Erscheinungsbild in der Benutzerschnitt-

stelle. Sie besitzen kontext-sensitive Menüs und eine eigene SmartIcon-Leiste sowie die

Notes-typische Infobox. Ein für den Benutzer nachvollziehbarer klassischer Applikati-

onswechsel („Task-Switch“) – mit allen damit verbundenen Nachteilen wie etwa Per-

formanceverlust und andere Bedienungsmetaphern – entfällt durch das oben beschriebene

Container-Control-Prinzip.

Für den Notes Anwendungsentwickler lassen sich die Components direkt über

LotusScript-Klassen in Notes-Anwendungen ansprechen: alle Methoden, Eigenschaften

und Events des jeweiligen Components stehen direkt für den Programmierer zur Verfü-

gung [Lotus 1996b, S. 5 ff.].


Chart Component

Im Rahmen dieser Arbeit wurde das Chart Component benutzt. Seine Funktionalität

beschränkt sich auf die Darstellung und Manipulation von Diagrammen. Dazu bietet es

32 vordefinierte Diagrammarten in 2D und 3D (z. B. Balken-, Linien- und Kreisdia-

gramme).

Die Nutzung ist durch mehrere Überlegungen motiviert:

• Das Component integriert sich für den Anwender transparent in die Lotus Notes-

Umgebung, was insbesondere für den Nutzerkreis Multiprojektmanagement von er-

höhter Relevanz ist, der ggf. Entscheider des Topmanagements beinhaltet, für die eine

möglichst intuitive Bedienung sehr wichtig ist (vgl. Kapitel 3.3 und Kapitel 3.4).

• Durch die enge Anbindung an Lotus Notes ist eine sehr schnelle Diagrammerstellung

und Manipulation innerhalb eines Notes-Dokumentes möglich, ohne daß ein zeit-

kritischer Wechsel zu anderen Fremdapplikationen durchgeführt werden muß.

• Das Chart Component bietet durch seine zahlreichen Diagrammarten genügend Fle-

xibilität und Funktionalität, um Informationen zur Multiprojektkoordination grafisch

aufzubereiten.

Es läßt sich also zusammenfassend feststellen, daß die Groupware-Plattform Lotus Notes

in Verbindung mit den Lotus Components die geeignete Voraussetzungen für die

Realisierung der in den Kapiteln 3 und 4 gestellten Anforderungen an das im Rahmen

dieser Arbeit zu entwickelnde verteilte Frontend-System bieten.

5.3 PAVONE GroupProject

PAVONE GroupProject (GP) ist ein System für die unternehmensweite Projektkoordi-

nation. GroupProject ist im Rahmen eines Forschungsprojektes an der Lehr- und For-

schungseinheit Wirtschaftsinformatik 2 der Universität Paderborn entstanden. Die

kommerziell verfügbare Version 2.11a wird durch das kooperierende Unternehmen

vertrieben.

GroupProject bietet prinzipielle Architekturmerkmale, die eine geeignete Grundlage

darstellen, das projektspezifische Corporate Data Model einer Unternehmung informa-

tionstechnisch abzubilden.

Im folgenden wird zum weiteren Verständnis dieser Arbeit die grundlegende System-

architektur charakterisiert.


GroupProject bietet ein Applikations-Framework, in dem es die Vorteile von Group-

ware-Systemen und Netzplantools wie beispielsweise CA SuperProject oder Microsoft

Project synergetisch vereint [Nastansky et al. 1995, S. 321].

Die grundlegenden Elemente dieses Frameworks sind das grafische Modellierungs-

werkzeug ProjectBuilder, der Kommunikationsagent ProjectConnect und die Lotus

Notes-basierten Datenbankanwendungen.

Abbildung 5.3-1 faßt die in den folgenden Abschnitten gemachten Ausführung über-

sichtlich zusammen.

Verteilte Groupware-PlattformLotus Notes

Strukturablage:Inhalte, Personen, Ablauf

PM-Software

Projektedatenbank

ProjectConnect

ProjectBuilderProjektplanungund -kontrolle

Projektdurch-führung

Abb. 5.3-1: GroupProject System [Nastansky et al. 1996, S. 8]

5.3.1 GroupProject Datenbanken

Die Lotus Notes Datenbanken enthalten sämtliche Projektinformationen und Aktivitäten,

sowohl solche für das operative Projektmanagement als auch historischer Art (realisiert

durch Repository-Datenbanken). Die Datenbanken stellen die Struktur für das Corporate

Data Model für den zu entwickelnden Prototypen zur Verfügung.

Die Projektedatenbank enthält prinzipiell drei Klassen von Dokumenten:

• Projektmanagement-Dokumente

• Vorgangsdokumente

• Berichtsdokumente

Letztere werden aus Relevanzgründen in dieser Arbeit nicht weiter betrachtet.


Jedes einzelne Projekt wird in der Projektedatenbank über ein Projektmanagement-

Dokument repräsentiert, das durch einen Schlüssel, der sogenannten ProjectID, eindeutig

attributiert ist. Neben dieser ProjectID enthält es weitere zentrale Projektinformationen,

wie z. B. den Namen des oder der Projektleiter. Ferner dient es dem Projektmanager als

Enabling-Environment zum Aufruf des ProjectBuilders und des Kommunikationsagenten

ProjectConnect sowie zum dezidierten Setzen des Sicherheitskonzeptes für das

betroffene Projekt.

Die Dokumentenobjekte vom Typ Vorgangsdokument sind in dieser Arbeit von beson-

derer Relevanz. Vorgangsdokumente lassen sich in Hauptvorgangs- und Vorgangsdo-

kumente logisch instanziieren, explizit durch Vorhandensein einer Hierarchie von

Untervorgängen. Ein Vorgangsdokument unterteilt sich dabei in zwei logische Ab-

schnitte: den eigentlichen Vorgangsinformationen und dem sogenannten Zuweisungsteil

(vgl. Abb. 5.3.1-1). Ein GroupProject-Vorgang (engl. Task) ist neben dem Vorgangs-

namen regelmäßig durch die für den Vorgang relevante Vorgangsdauer, die dem Vor-

gang zurechenbaren Kosten und den zugeordneten Ressourcen gekennzeichnet.

Ein Hauptvorgangsdokument unterscheidet sich dabei von einem Vorgangsdokument

derart, daß es keine Zuweisungsinformationen auf Ressourcenebene enthält.

Zuweisungsteil

VorgangsinformationenDienstag Mittwoch Donnerstag Freitag

Vorgang 1

Vorgang 2

Aushub Keller

Vorgang 4

Vorgang 5

Montag

Darstellung im PM-Tool

Name Sollzeitraum Istzeitraum ...Müller 28.01-03.02.97 15.4.-28.5.97Schulte 28.01-03.02.97

Vorgangsname: Aushub KellerProjekt: HausbauDauer: 5 Tage...

Abb. 5.3.1-1: Logischer Aufbau eines GP Vorgangsdokumentes

Je nach Komplexität des verwendeten Netzplansystems kann ein solcher Vorgang in

GroupProject nicht selten durch mehrere hundert Items attributiert sein. Das zugrunde-

liegende Datenmodell erweist sich dabei durch seinen sehr generischen Aufbau als

technisch nicht trivial gestaltet. Ein einziges logisches Vorgangsattribut, wie etwa die


Kosten auf Zuweisungsebene, kann dabei – für den Endbenutzer nicht transparent –

modellintern durch drei Attribute abgebildet sein (vgl. dazu Beispiel zur Vorgangsdauer

in Abb. 5.3.1-1 und 5.3.1-2). Dies hat eine hohe Komplexität bei der prototypischen

Realisierung zur Folge.

Zuweisungsteil

Vorgangsinformationen

Feldname/-inhalt:Task: "Aushub Keller"ProjectID: "Hausbau"Duration: "5" DurationType: 4...

Feldname/-inhalt:h1: "@Müller@Schulte"h12: "@[email protected]"h11: "@[email protected]"h4: "@15.04.97@ "h5: "@28.05.97@ "...

Abb. 5.3.1-2: Technischer Aufbau eines GP Vorgangsdokumentes

Die Ressourcendatenbank dient der Abbildung des unternehmensweit zentralen Res-

sourcenpools. In Projekten einsetzbare Mitarbeiter(-gruppen) oder auch Sachressourcen

werden dabei durch Ressourcen-Stammdokumente innerhalb dieser Datenbank reprä-

sentiert.

Neben den Stammdokumenten existieren ferner die Projekt-Zuordnungsdokumente.

Diese bilden aggregiert den Einsatz einer in einem Stammdokument definierten Res-

source für ein spezifisches Projekt ab. Der Aufbau eines solchen Projekt-Zuordnungs-

dokumentes ist prinzipiell mit dem eines Dokumentenobjektes vom Typ Vorgang in der

Projektedatenbank zu vergleichen, daher wird an dieser Stelle auf eine tiefergehende

Darstellung verzichtet.


Die GroupProject Konfigurationsdatenbank sichert arbeitsplatzspezifische Einstellun-

gen (wie etwa Pfade und verwendete PM-Anwendung) des Endbenutzers, sowie Trans-

ferinformationen für den Kommunikationsagenten ProjectConnect.

5.3.2 ProjectBuilder

Der Schwerpunkt des ProjectBuilders liegt in der Projektplanung. Er ist ein grafischer

Editor zur intuitiven Modellierung des Projektstrukturplans. Dabei unterstützt er den

Projektleiter bei der effizienten Gestaltung der Projektaufbaustruktur. Da der Project-

Builder im Rahmen dieser Arbeit keine weitere Relevanz besitzt, wird auf eine vertie-

fende Darstellung in [Nastansky et al. 1996, S. 10 f.] verwiesen.

5.3.3 ProjectConnect

ProjectConnect agiert als Schnittstellensoftware für die Informationssynchronisation mit

der verwendeten Projektmanagement-Applikation. Aufgrund des in der Konfigurations-

datenbank festgelegten Transfermodells ermöglicht ProjectConnect den bidirektionalen

Informationsaustausch zwischen den Dokumentenobjekten der verwendeten Groupware-

Plattform und den in der Regel relationalen Datenmodellen der Netzplantools. Diese

hochkomplexen Werkzeuge ermöglichen dem Projektleiter die Durchführung

leistungsstarker What-If-Analysen und visualisieren Kostenentwicklungen, Kapazitäts-

auslastungen und andere Projektparameter. Sie bieten regelmäßig leistungsstarke Funk-

tionalitäten für Kalkulation und Kontrolle von Projektverläufen und Pufferzeiten

[Nastansky et al. 1996, S. 11].

5.3.4 Multiprojecting mit GroupProject

Durch die Erstellung von Multiprojektmanagement-Dokumenten (als besondere Instanz

der zuvor beschriebenen Projektmanagement-Dokumente) in der GP Projektedatenbank

können beliebige Projekte als auch andere Multiprojekte logisch miteinander verknüpft

werden. Bei Bedarf können die so spezifizierten Multiprojekte durch den Transfer-

agenten im Netzplantool zusammengeführt werden. Dies ermöglicht eine ganzheitliche

und interdependente Betrachtung beliebiger Projekte mit den dort zugewiesenen Res-

sourcen mittels der in Kapitel 5.3.3 angeführten Funktionalitäten des jeweils eingesetzten

Netzplantools. Wie in Kapitel 4.1 bereits konstatiert wurde, ist die Funktionalität dieser

Netzplantools regelmäßig jedoch derart mächtig, daß sie als Hilfsmittel für eine intuitive

managementgerechte Entscheidungsunterstützung nicht sinnvoll erscheinen.

6 Zentrale Konzepte der Lösung: Prototypische Implementierung GP DSS Seite 47

6 Zentrale Konzepte der Lösung: Prototypische

Implementierung GP DSS

Dieses Kapitel beschreibt die Umsetzung der in den Grundlagenteilen 3 und 4 definierten

Anforderungen an das im Rahmen dieser Arbeit zu entwickelnde Frontend-System unter

Nutzung der in Kapitel 5 vorgestellten Arbeitsumgebung. Es werden dabei die zentralen

Konzepte der prototypisch implementierten Lösung „GroupProject DSS“ (GP DSS)

vorgestellt.

Die Architekturmerkmale von GP DSS werden in Kapitel 6.1 beschrieben: neben dem

Aufbau wird dort die Integration in die Projektmanagment-Lösung dargestellt.

Ein besonderer Schwerpunkt wurde bei der Realisierung auf die „managementgerechte“

Interaktion mit dem Endbenutzer gelegt, d. h. es wurde versucht, unter gleichzeitiger

Maximierung der Flexibilität eine möglichst einfache, intuitive Benutzerführung zu rea-

lisieren (Kapitel 6.2).

Die implementierten Szenarien für mögliche Visualisierungen im Rahmen der Multi-

projektkoordination werden in Kapitel 6.3 vorgestellt. Unter einem Szenario wird in

diesem Kontext ein in Grenzen konfigurierbarer Baustein verstanden, der die Abfrage

und Darstellung quantitativer Projektinformationen in Entscheidungssituationen vor-

definiert.

Eine technische Dokumentation befindet sich in Anhang C.4.3.

6.1 Architektur- und Datenmodell

GroupProject DSS (GP DSS) stellt die konkrete Umsetzung des in Kapitel 4.4 vorge-

stellten Gesamtkonzepts dar. GP DSS ist als reine Lotus Notes-Datenbankanwendung

realisiert worden (vgl. Abb. 6.1-1). Die Erstellung der Diagramme erfolgt mittels des in

Kapitel 5.2 vorgestellten Lotus Chart Components. Das Corporate Data Model wird

dabei durch die PAVONE GroupProject Projekte- und Ressourcendatenbanken ab-

gebildet.


P2

P3

P1

MP1

MP2

DSS

(Multi-)Projekt-landschaft

GP DSS

Abb. 6.1-1: Architekturmodell

6.1.1 Konzept der Profil- und Reportdokumente

In GP DSS existieren zwei Klassen von Dokumentenobjekten: Profil- und Reportdoku-

mente (vgl. Abbildung 6.1.1-1). Profildokumente dienen der Parametrisierung von über

dem projektspezifischen Corporate Data Model durchzuführenden Abfragen. Report-

dokumente realisieren die Darstellung der Abfrageergebnisse unter Integration der

Informationstypen Text und Grafik.

GP DSS

Profil

Application Engine

Parametrisierung

InformationPull (Selektiondurch Profil)Report

Ausgabe

CDM

Abb. 6.1.1-1: Zentrale Paradigmen GP DSS

6.1.1.1 Konfiguration durch Profile

Ein Profildokument dient der flexiblen Konfiguration einer Abfrage auf den unter-

nehmensweiten Projektdaten und bildet das Parametrisierungssubmodul der Lösung. Der

Endbenutzer spezifiziert hier die relevanten Parameter für die von ihm benötigten


Informationen aus der betrieblichen Multiprojektlandschaft. Bei der Implementierung der

Lösung wurde dabei besonderer Wert auf Generik und Erweiterbarkeit gelegt (vgl.

Kapitel 6.1.3).

Die Navigation bei der Erstellung eines Profildokumentes wird dabei durch ein end-

benutzerfreundliches Roadmapkonzept (vgl. Abb. 6.1.1.1-1) realisiert.

Auswahl Summary

Statusmarken

Abb. 6.1.1.1-1: Endbenutzerfreundliche Roadmap

Statusmarken signalisieren noch zu spezifizierende Parameter. Die Roadmap impliziert

dabei durch grafische Pfeilelemente und entsprechende Rückmeldung beim Endbenutzer

eine bestimmte Reihenfolge bei der Profilerstellung, führt also gewissermaßen logisch an

die Lösung der Aufgabe heran [vgl. Schicker 1994, S. 60]. Die bereits spezifizierten

Parameter werden in komprimierter Form in einer Summary-Sektion dargestellt und

ermöglichen so eine permanente Gesamtsicht auf die Parametereinstellungen.

Die Zielgruppe dieser Arbeit, die betrieblichen Planer und Entscheider, definieren ihre

Anforderungen dabei in den folgenden Bereichen:

• Nutzerkreis: Eine explizite Zuordnung des Endbenutzers zu einem der in Kapitel 3.1

definierten Nutzerkreise wird durch zwei verschiedene Aspekte motiviert: einerseits

aus Gründen des Zugriffschutzes, andererseits aus Interessengründen. Auf eine

Automatisierung dieser Nutzerkreiszuordnung beispielsweise durch Nutzung von

Lookup-Mechanismen oder Implementierung eines speziellen Projekt-Adressbuches

(z. B. in Form einer Erweiterung der Ressourcendatenbank) wurde dabei bewußt

verzichtet. Dies wird durch die wichtige pragmatische Tatsache begründet, daß es be-


sonders bei der Definition von Systemanfragen durch Mitglieder aus dem Bereich des

Topmanagements zur Delegation der Profil-Erstellung an hierarisch tiefer in die

Organisation gegliederte Mitarbeiter kommen kann. Die im Rahmen der durchge-

führten Experteninterviews gewonnen Aussagen können dies belegen. Abbildung

6.1.1.1-2 verdeutlicht dabei die mit der Festlegung des Nutzerkreises einhergehenden

Konsequenzen: der Zugriffsbereich auf die Projektinformationen, die in den verteilten

Repositories des integrierten Backend-Systems zur Verfügung stehen, ist mit dem

gewählten Nutzerkreis interdependent. Die Wahl des Nutzerkreises determiniert dabei

auch die weiteren Interaktionsmechanismen mit dem Parametrisierungssubmodul bei

der Spezifikation der weiteren Abfrageattribute: so steht beispielsweise bei Anwahl

des Nutzerkreises „Projektmitarbeiter“ die Auswahl von Multiprojekten nicht zur

Verfügung. Dies ermöglicht die in Kapitel 3.3 geforderte sichtenspezifische Definition

von Informationsfiltern.

operative Projektinformationen der GroupProject Datenbanken

Projektmanagement

Multi-Projektmanagement ((Top-)Management)

Projektmitarbeiter

Abb. 6.1.1.1-2: Nutzerkreise

• Szenario: Die Auswahl des Szenarios spezifiziert durch Festlegung eines Projekt-

parameters den Basisfokus für die zur Entscheidungsunterstützung beim Projektcon-

trolling gewünschten Informationen (vgl. Kapitel 2.3). Dazu wurden im Rahmen die-

ser Arbeit acht Szenarien implementiert.

• Projekte/Pfade: Da das Backend-System prinzipiell eine beliebig große Anzahl von

Projekten enthalten kann, ist es allein aus Relevanz-, aber auch aus Perfor-


manceaspekten erforderlich, den Fokus auf bestimmte Projekte einschränken zu kön-

nen.

• Zeitraum/Mitarbeiter: Die Tatsache, daß auf Projekte bezogene Entscheidungen in

der Regel nicht nur zeitpunktbezogen sondern auch zeitraumbezogen sind (vgl.

Kapitel 2.4 und 3.1), motiviert den Bedarf nach einer Möglichkeit, diesen besonders

spezifizieren zu können. Ferner kann es von Interesse sein, eine Abfrage auf be-

stimmte Mitarbeiter zu beschränken. Zur Auswahl findet daher ein Zugriff auf den im

Backend-System abgebildeten Ressourcenpool statt. Desweiteren wird an dieser

Stelle determiniert, in welcher Planungseinheit (z. B. Stunden, Tage, Wochen) die

Projektinformationen visualisiert werden sollen. Dabei ist je nach Verfügbarkeit der

durch das Corporate Data Model im Backend-System abgebildeten Daten und der

Visualisierungsmöglichkeiten durch das Chart Component eine gemischte UND-

Verknüpfung der durch das Szenario spezifizierten Projektparameter auf Plan-, Soll-

bzw. Ist-Ebene möglich.

• Grafische Darstellung: Hier ist eine Vorselektion der Darstellungsart des zu er-

stellenden Diagramms möglich. In Abhängigkeit vom gewählten Szenario stehen

verschiedene Diagrammarten zur Auswahl bereit. Ferner ist der Detailliertheitsgrad

der Darstellung durch Determinierung des Zeitmaßstabs der Achs-Skalierung an die-

ser Stelle spezifizierbar.

Aus dieser Parametrisierung entsteht ein konkretes Anforderungsprofil zur Weiterver-

wendung durch die DSS Application Engine des in Kapitel 4.4 beschriebenen Gesamt-

konzeptes.

6.1.1.2 Konzept des Metafilters

Vollständig definierte Profildokumente stellen syntaktisch gültige Abfragen (im Sinne

von Nutzerkreis- und Szenario-spezifischer Konsistenz sowie Vollständigkeit der Para-

metrisierung) auf der Projektdatenbasis des Unternehmens dar. Auf semantischer Ebene

kann ein Profil derart durch den Benutzer definiert sein, daß keine für ihn sinnvollen

Ergebnisse erscheinen (z. B. durch Auswahl eines Zeitraums in dem keinerlei Aktivitäten

des Projektes stattfinden oder geplant sind).

Die Selektionskriterien aus den einzelnen Filterkategorien in solcherart wohldefinierten

Profildokumenten werden bei der Reportgenerierung von der DSS Application Engine


übernommen und auf das Backend-System angewandt. Konkret wurde dies prototypisch

durch den in LotusScript implementierten DSS Metafilter realisiert, durch den die An-

sichten der im Profildokument implizit und explizit durch den Benutzer definierten zu-

grundeliegenden Projektedatenbanken im Sinne eines reaktiven Data Mining durchsucht

werden (vgl. Abb. 6.1.1.2-1).

Notes GP Ansichten

GraphicalPre-Processor

LotusScript

ApplicationEngine

LotusScript

Metafilter

Abb. 6.1.1.2-1: GP DSS Metafilter

Der Filter ist ein integraler Bestandteil des jeweiligen Szenario-Moduls. Auf diese Art

lokalisierte Projektdokumente werden dann von der DSS Application Engine ausgelesen

und an den DSS Graphical Pre-Processor weitergegeben.

6.1.1.3 Grafische Auswertungen in den Reports

Die Dokumentenobjekte vom Typ Report stellen neben den Profilen ein weiteres

zentrales Element der realisierten Anwendung dar. Aus der zeitlich-ablauflogischen

Betrachtung geht der Erstellung eines Reportdokumentes immer das Erzeugen eines

zugrundeliegenden Profildokumentes voraus. Dieser Aufbau erlaubt die Erzeugung von

Ad-hoc-, aber auch Standard-Abfragen, da einmal erstellte Profildokumente für eine

beliebige Anzahl von Abfragen zur Verfügung stehen und in der Datenbank als (bei

Bedarf modifizierbare) Template-Dokumente abgelegt werden können.

Das Reportdokument dient der kombinierten grafischen und tabellarischen Darstellung

der Projektinformationen. Es ist dazu in drei Sektionen untergliedert: einer Identifikati-

onssektion zur Kategorisierung im Reportkopf (die, um dem Benutzer eine Überflutung

mit Detailinformationen zu ersparen, zunächst eingeklappt ist und von ihm bei Bedarf


expandiert werden kann) gefolgt von dem aus dem DSS Visualizer stammenden Dia-

gramm. Die Aufgabe der grafischen Aufbereitung wird dabei durch das Lotus Chart

Component (vgl. Kapitel 5.2) realisiert. Abschließend folgen in der dritten Sektion

textuelle Zusatzinformationen, die in tabellarischer Form aufgeführt werden. Diese

werden ggf. durch den DSS Graphical Pre-Processor aggregiert und an den Visualizer

weitergegeben, der die Informationen an das User Interface durchreicht (Non-Intelligent-

Passing).

Abbildung 6.1.1.3-1 erläutert den eben geschilderten prinzipiellen Aufbau eines Report-

dokumentes:

Identifikationssektion:Name des Reportserstellt/modifiziert vonerstellt/modifiziert amNutzerkreisKategoriezugrundeliegendes Profil (DocLink)

Reportingsektion (textueller Teil):anmerkende Zusatzinformationenz.B. Anfangs- und Endtermine, Fertigstellungsgrad

Reportingsektion (grafischer Teil):ÜberschriftGrafik mit Formatierung: Zeitstempel,Legende, Achsbeschriftung usw.

Abb. 6.1.1.3-1: Aufbau eines Reportdokumentes

6.1.2 Integration in die Projektmanagment-Umgebung

Die im Rahmen dieser Arbeit entwickelte Anwendung integriert sich völlig in den

Applikationsverbund des GroupProject Systems im Sinne eines Add-Ons (vgl. Abb.

6.1.2-1), ohne daß dort Änderungen im Datenmodell oder in den Applikationen vorzu-

nehmen sind. Der Benutzer von GP DSS braucht dabei kein expliziter GroupProject

Nutzer zu sein (von Relevanz beispielsweise bei Nutzern aus der Gruppe des Topma-

nagements). Eine Konfiguration des GP Gesamtsystems ist also nicht erforderlich.


Zur Erstellung von Auswertungen benötigt der jeweilige Nutzer lediglich Zugang zu den

entsprechenden Informationen der im Backend-System vorgehaltenen Daten, realisiert

durch den Besitz entsprechender Leserechte auf der Projekte- und Ressourcendatenbank

des Projektmanagement-Systems (z. B. durch die Vergabe entsprechender Rollen). Die

Pfade der Projekte- und Ressourcendatenbanken sind im Profildokument zu spezifizieren

– dabei wird aber versucht dem Benutzer möglichst weit durch sinnvolle Annahmen

entgegen zu kommen. Die DSS Application Engine greift dann (in Abhängigkeit des im

Profildokument gewählten Szenarios) auf die entsprechenden Datenbankansichten des

Corporate Data Models zu.

GP DSS

GP Projekte GP Konfiguration

GP Ressourcen

Abb. 6.1.2-1: Integration in die Projektmanagement-Umgebung

Die vom GP DSS Metafilter als relevant identifizierten Dokumentenobjekte werden auf

Feldebene ausgelesen und in Form von Arrays an den GP DSS Graphical-Pre-Processor

weitergegeben, der diese ggf. aggregiert oder entsprechend der im Profil spezifizierten

Einstellungen transformiert. Die Dokumentenobjekte können dabei vom Typ Haupt-

vorgangsdokument, Vorgangsdokument oder Projekt-Zuordnungsdokument sein.

Es findet ein reiner Information Pull aus dem Backend-System in das Frontend-System

statt. Dieser Pull erfolgt direkt und unmittelbar, d. h. aus den aktuell verfügbaren opera-

tiven Daten.

Die Interaktion mit der Konfigurationsdatenbank des Systems erfolgt nur in der Art, als

das bei Nutzern des GroupProject Systemverbundes deren Einstellungen als sinnvolle

Vorgaben für die Erstellung von Profildokumenten übernommen werden.


6.1.3 Objektorientierung und Erweiterbarkeit

Der Anspruch der prototypisch realisierten Lösung ist es, ein besonders intuitiv zu be-

dienender Ansatz zu sein. Dazu bietet sich die Verwendung objektorientierter Prinzipien

an [vgl. Nastansky 1990, S. 242].

Exkurs: Objektorientierung

Zum besseren Verständnis der folgenden Ausführungen werden an dieser Stelle einige für

diese Arbeit relevante Termini aus dem Bereich der Objektorientierung eingeführt.

Im Mittelpunkt objektorientierter Anwendungen steht das Objekt. Ein Objekt kann ein

Abbild aus der realen Welt darstellen oder abstrakte Begriffe repräsentieren. Die Eigen-

schaften eines Objektes beschreiben dessen Zustand in Form von Attributen und sein

Verhalten in Form von Prozeduren bzw. Funktionen (auch zusammenfassend als

Methoden bezeichnet). Sein interner Zustand bleibt dem Benutzer verborgen (sogenannte

Kapselung) und können mit ihrer Umgebung über Nachrichten (Messages)

kommunizieren (auch als Message Passing bezeichnet). Objekte mit gleichartiger

Struktur (beschrieben durch Attributskombinationen) und Objektverhalten faßt man zu

Objektklassen zusammen. Diese sind hierarchisch angeordnet und bilden die daraus

resultierende Klassenhierarchie. Jede Klasse übernimmt und erweitert die Eigenschaften

der ihr hierarchisch übergeordneten Klassen (Prinzip der Vererbung). Objekte, die der

gleichen Objektklasse angehören, nennt man Instanzen einer Klasse. Eine solche Instanz

kann als konkrete Ausprägung einer Klasse verstanden werden [vgl. Nastansky 1990,

S. 242 ff. und Schreiber 1995, S. 39 ff.].

Objektorientierte Ansätze in GP DSS

Die Objektorientierung der prototypisch implementierten Lösung ist dabei auf mehreren

Ebenen zu konstatieren. Nach Muhanna sind objektorientierte Konzepte und Technolo-

gien eine besonders geeignete Basis für DSS Entwicklungsplattformen [Muhanna 1993,

S. 219]. Die zugrundeliegenden Basistechnologien Lotus Notes und Lotus Components

folgen dem objektorientierten Paradigma, das ursprünglich durch die Programmier-

sprache SIMULA in den 60er Jahren und auf breiterer Basis durch die objektorientierte

Programmierumgebung SMALLTALK etabliert worden ist [Schreiber 1995, S. 39]. Mit

der BASIC-kompatiblen objektorientierten Programmiersprache LotusScript wurden

Methoden, Eigenschaften und Klassen von Lotus Notes, aber auch des Chart

Components benutzt.


Der Aufbau der Anwendung GP DSS ist auch aus konzeptioneller Sicht als objektorien-

tiert zu bezeichnen. Im Rahmen der folgenden Ausführungen wird dabei ein dem End-

benutzercomputing angemessenes, offenes und intuitives objektorientiertes System-

verständnis antizipiert [vgl. Nastansky 1990, S. 239 ff.].

Abbildung 6.1.3-1 skizziert den im folgenden beschriebenen Aufbau der objektorientier-

ten Dokumentenhierarchie von GP DSS. Die Notation wurde in Anlehnung an Booch

[vgl. Booch 1994, S. 171 ff.] gewählt. Ein senkrechter Pfeil symbolisiert dabei die Ver-

erbungsbeziehung „ist Sohn/Tochter von“.

DokumentMetaklasse

Klasse

Instanz

vererbte Instanz

Profildokument

Message@Env...

Profildokument

Reportdokument

Reportdokument

Reportdokument

Profildokument

Abb. 6.1.3-1: Dokumentenhierarchien

An oberster Stelle der Klassenhierarchie von GP DSS steht das Notes-Dokument als

abstrakte systemspezifische Metaklasse der zugrundeliegenden Groupware-Plattform.

Daraus resultieren die applikationsspezifischen Klassen der Profil- und Reportdokumente

als abstrakte, nicht attributierte Objekte. Auf der nächsten Ebene der Hierarchie

erscheinen die ausgeprägten, d. h. instanziierten Formen in den konkreten Profil- bzw.

Reportdokumenten (jeweils mit Attributen). Diese Dokumentenobjekte erscheinen dabei

für den Benutzer als Synergie aus den eigentlichen Dokumenten (d. h. der Attribute) und

der zugrundeliegenden Form (d. h. dem Objektverhalten). Die Instanzen erscheinen je-

weils in den Ansichten der Anwendung.

Selektive Vererbung findet bei der Erstellung eines neuen Profildokumentes durch

Nutzung der Funktionalität „Profil erstellen auf Vorlage“ statt. Es wird dabei eine neue

Instanz des ausgewählten Profildokumentes erzeugt. Die Attribute „Document-


UniqueID“ und „Profilname“ werden beim Vererbungsvorgang geändert. Beim

Versenden eines Reportdokumentes über die „Senden...“-Funktionalität mit Versandart

„Dokument“ findet ein vergleichbarer Vorgang statt: eine neue Instanz des Dokumentes,

bestehend aus einer notwendigen Obermenge von Attributen und Funktionen, wird

erzeugt. Hierbei wird die bisher für den Benutzer scheinbar existierende Einheit von

Attributen und Verhalten durch Nutzung der Systemfunktion „Store Form In Document“

als Umwandlung in ein Compound Document real vollzogen. Als solcherart kreiertes

„autarkes“ Objekt kann es das System der Anwendung GP DSS nun verlassen.

Message Passing findet in mehrfacher Hinsicht Anwendung in GP DSS. Bei der Erstel-

lung eines Reportdokumentes basierend auf einem Profil werden zwingend die

DocumentUniqueID (vgl. Kapitel 5.1) als Objektidentifizierer und die Szenario-ID des

dort spezifizierten Szenarios (realisiert über Umgebungsvariablen und Lookup-Mecha-

nismen) an das neu instanziierte Reportdokument übergeben (vgl. Abb. 6.1.3-2). Dieses

übernimmt daraufhin die Attribute des zugrundeliegenden Profildokumentes (in der DSS

Application Engine, realisiert im Scriptcode des entsprechenden Szenario-Moduls).

Reportdokumente

Reportgenerierung

Reportdokument

Drill-Down

ProjectID

ProjectID/TaskID

Profildokument

1. Push der DocUID

2. Pull der Attribute

Abb. 6.1.3-2: Message Passing

Das Konzept des Message Passing kommt noch an einer weiteren Stelle zum Einsatz.

Beim sogenannten Drill-Down von Multiprojektebene auf Vorgangsebene eines

gewählten Projektes wird über ein Item die ProjectID und beim Drill-Down von Vor-

gangs- auf Zuweisungsebene über ein weiteres Item zusätzlich noch die TaskID

übergeben.


Erweiterbarkeit

Bei der Umsetzung des Gesamtkonzeptes wurde versucht, ein hohes Maß an Generik

und Modularität zu realisieren, einerseits um aus dem praktischen Einsatz resultierende

Anpassungen schnell realisieren zu können, andererseits um Änderungen im Datenmodell

des CDMs unkompliziert nachpflegen zu können. Dazu wurden die Szenarien als Script

Library-Objekte (in Lotus Notes auf Datenbankebene zentral zugängliche LotusScript

Code-Segmente) implementiert und das Datenmodell für die Profil- und

Reportdokumente sehr offen und generisch gestaltet (vgl. Anhang C.4.3: technische

Dokumentation). Die Szenario-Objekte (in Anlehnung an die oben vollzogene weiche

Begriffsdefinition) stehen damit in Form einer internen Objektbibliothek zentral zur

Verfügung. Dieses Konzept erlaubt dabei Änderungen wie etwa das Modifizieren beste-

hender oder das Hinzufügen weiterer Visualisierungsszenarien problemlos vorzunehmen.

Durch die Kapselung der Funktionen bleibt dies dem Benutzer verborgen. Ein

bestehendes Szenario-Objekt hat dabei Template-Charakter und kann so durch die

leistungsstarken, ihrerseits objektorientierten Rapid-Prototyping-Mechanismen des ver-

wendeten Groupware-Systems vom Anwendungsentwickler wieder- und weiterver-

wendet werden.

6.2 Benutzerführung und -interaktion

Ein Fokus der im Rahmen dieser Arbeit erstellten prototypischen Implementierung liegt

auf der Endbenutzerorientierung im Sinne einer „managementgerechten“, d. h. möglichst

einfachen Bedienung eines solchen Informationssystems. Innerhalb dieses Unterkapitels

werden dazu ausgewählte Lösungskonzepte vorgestellt.

Die Aufteilung der folgenden Unterkapitel legt dabei eine sauber trennbare Kategori-

sierung nahe – dies ist aber eine künstliche Trennung auf konzeptioneller Ebene: eine

klare Unterscheidung ist aufgrund der existierenden Interdependenzen innerhalb der

Anwendung nicht möglich und sinnvoll, da die pragmatische Betrachtung der Applika-

tion ein ganzheitliches Systemverständnis erfordert.

6.2.1 Navigationskonzept

Innerhalb der Anwendung GroupProject DSS wurde versucht, dem Benutzer ein beson-

ders intuitives und flexibles Navigieren mit dem Ziel einer schnellstmöglichen Erreichung

von Objekten bzw. Objektzuständen zu ermöglichen. Dabei wurden die dazu in Kapitel


3.3 für diesen Bereich definierten Anforderungen der Kategorie Endbenutzer-

Interaktions-Aspekte an ein Entscheidungsunterstützungssystem zur Multiprojekt-

koordination umgesetzt.

In Lotus Notes als Basisplattform sind die an ein hypermediales System bezüglich der

Strukturierungs- und Navigationsmechanismen zu definierenden Anforderungen prin-

zipiell erfüllt [vgl. Behrens 1994, S. 93-98].

Hauptnavigator

Ansichten mit Navigatoren

Notes Workspace

Dokumente

"Über GP DSS"

?

Profile Reports

Abb. 6.2.1-1: Navigation (Anwendungsebene)

Zwischen den zwei Klassen von Dokumentenobjekten, den Profilen und Reports, kann

auf verschiedenste Art navigiert werden. Die Abbildungen 6.2.1-1 und 6.2.1-2 stellen das

Navigationskonzept von GP DSS übersichtlich dar. Nach dem Öffnen der Anwendung

gelangt der Benutzer zum Hauptnavigator (vgl. Abb. 6.2.1-1). Von dort kann er zu den

Profil- oder Reportdokumentenklassen verzweigen oder die Anwendung verlassen. Bei

Selektion einer der ersten beiden Möglichkeiten besteht die Option über die parallel zur

Ansicht erscheinenden Navigatoren zur jeweils anderen Dokumentenklasse zu wechseln,

Dokumentenobjekte zu aktivieren oder neue Instanzen der entsprechenden

Dokumentenklasse zu erzeugen. Im Fall der Klasse der Profildokumente ist dabei einer-

seits die Erzeugung einer nicht vorattributierten neuen Instanz („Erstellen neu“) oder

andererseits die Übernahme existierender Attribute („Erstellen auf Vorlage“) möglich.

Selektiert oder öffnet der Benutzer ein vollständig definiertes Profildokument, besteht die

Möglichkeit zur expliziten Erstellung einer neuen Instanz eines Dokumentenobjektes

vom Typ Report. Diese Funktionalität steht auch bei bereits existierenden Re-


portdokumenten bereit, sofern deren zugrundeliegende Profildokumente noch innerhalb

der Applikation existent sind (vgl. Abb. 6.2.1-2).

Ansichten mit Navigatoren

Profile Reports

auf Vorlage

ohne Vorlage

existierende Dokumente

neue Dokumente

Abb. 6.2.1-2: Navigation (Dokumentenebene)

Von einer vorhandenen Instanz eines Reportdokumentes läßt sich über die in der Kate-

gorisierungssektion eingebettete Dokumentenverknüpfung explizit in das zugrunde-

liegende Profildokument verzweigen – etwa um die dort spezifizierten Parameter zu

prüfen oder um eine Abfrage mit modifizierten Attributen erneut zu erzeugen. Eine

implizite Aktivierung dieser Verknüpfung erreicht der Benutzer durch Öffnen des Do-

kumentvorschaufensters.


Profildokumente

Reportdokumente

Navigatoren

Statusmarken

Abb. 6.2.1-3: Ansichten mit Navigatoren

Abbildung 6.2.1-3 zeigt die beiden zentralen Ansichten der Anwendung. Statusmarken

geben Auskunft über den Dokumentenzustand (vollständig definiert bzw. Report ausge-

führt). Die Abbildung verdeutlicht, daß auf einheitliche Bedienungs- und Erscheiungs-

metaphern Wert gelegt wurde, um die oben beschriebene managementgerechte Bedien-

barkeit zu erreichen.

6.2.2 Interaktion mit dem Endbenutzer

In diesem Abschnitt wird die Umsetzung der in Kapitel 3.3 definierten Anforderungen

bezüglich der Ausgabeerzeugungs- und -gestaltungsaspekte im Rahmen der Profil- und

Reporterstellung beschrieben, die wiederum auch Endbenutzer-Interaktions-Aspekte be-

rühren. Dies spiegelt sich insbesondere bei der zur Erstellung von Profildokumenten

verwendeten Form und den dazugehörigen Dialogen wider.

Die Projektauswahl erfolgt in Abhängigkeit des gewählten Nutzerkreises (vgl. Abb.

6.2.2-1) als selektive Funktionalität: die Schaltfläche zum Hinzufügen von Multi-

projekten erscheint nur bei Selektion des Nutzerkreises Multiprojektmanagement.


Abb. 6.2.2-1: Nutzerkreisabhängige Projektauswahl

Zur Auswahl der zur Darstellung im Reportdokument verwendeten Diagrammart wurde

ein Thumbnail-Konzept umgesetzt (vgl. Abb. 6.2.2-2). Der Benutzer hat die Möglichkeit

einen Diagrammtyp aus der Liste auszuwählen (woraufhin das entsprechende Icon farbig

unterlegt wird) oder alternativ das Icon zu selektieren (was eine Invertierung des

Diagrammtyps in der Auswahlliste zur Konsequenz hat). Dabei erhält er durch Auswahl

eines entsprechenden verkleinerten Abbildes des mittels des DSS Visualizer zu erzeu-

genden Diagramms als quasi „visuelle Gedankenstütze“ [Schicker 1994, S. 137] im

Dialogfenster ein vorausschauendes Feedback.

Abb. 6.2.2-2: Thumbnail-Konzept

Insbesondere bei der Umsetzung des Konzeptes der Profildokumente wurde durch den

Einsatz der Roadmap (vgl. Abb. 6.1.1.1-1) eine Reduzierung erzwungener Sequentialität


erreicht und ein wahrnehmbares, veränderbares Handlungsumfeld mit unmittelbarer

Rückmeldung bereitgestellt. Anstatt vom System streng vorgegebener sequentieller

Dialoge kann der Anwender eine individuelle Parametrisierung vornehmen. Zur Reduk-

tion der Komplexität wurden die einzelnen Parameter dazu in Gruppen eingeteilt. Bei der

Implementierung der Dialoge und Masken wurde durch entsprechende grafische

Gestaltung den Objektzuständen eine Tiefenwirkung verliehen, um eine für das

menschliche Auge natürlich erscheinende Visualisierung zu erreichen. Durch Nutzung

ikonisierender Icons (in Aktionsschaltflächen, Statusmarken, Dialogen und der Road-

map) bzw. gemischt textuell-ikonisierenden Icons (im Gegensatz zu rein textuellen Icons,

die die auszuführende Aktion verbal darstellen) wurde versucht, eine Erhöhung der

Reaktionszeit und einen möglichst hohen Wiedererkennungseffekt beim Endbenutzer zu

erreichen [vgl. Keil-Slawik 1995].

Mögliche Laufzeit-Fehlermeldungen des zugrundeliegenden Groupware-Systems, ins-

besondere während der Ausführung des DSS Metafilters der DSS Application Engine,

wurden soweit möglich durch „On Error...“-Mechanismen in Lotus Script abgefangen

und durch aussagekräftigere Meldungen mit konstruktiven Lösungshilfen ersetzt

(beispielsweise bei nicht lokalisierbaren Datenbanken, Ansichten oder Projekten). Diese

Fehlermeldungen werden zentral in einem Script Library-Objekt „GP DSS Error

Handler“ der Anwendung zur Verfügung gestellt und stehen so zur leichten Modifzie-

rung und Erweiterung bereit.

6.2.3 Drill-Down

Die in Kapitel 3.3 von der Literatur definierte Anforderung des Drill-Downs an ein

Frontend-System zur Entscheidungsunterstützung bei der Multiprojektkoordination

wurde durch Nutzung des SeriesSelected-Events des Chart Components realisiert, das

über einen Mausklick auf ein entsprechendes Diagrammelement ausgelöst wird. Im

Rahmen der Multiprojektkoordination erscheint dem Autor dabei eine Unterteilung in die

in Abbildung 6.2.3-1 angeführten drei logischen Bezugsobjekte Projekte, Vorgänge und

Zuweisungen sinnvoll, begründet durch die im Corporate Data Model modellierte

Datenstruktur (vgl. Kapitel 5.3).


Projekte

Vorgänge

Zuweisungen

Dienstag Mittwoch Donnerstag Freitag

Vorgang 1

Vorgang 2

Vorgang 3

Vorgang 4

Vorgang 5

Montag

Abb. 6.2.3-1: Drill-Down

Das Konzept des Drill-Downs ermöglicht ein grafisches Navigieren in endbenutzerge-

rechter Form [Henneböle 1995, S. 98]. Dabei erfolgt prinzipiell eine selektiv-schrittweise

Navigation von der Spitze der in diesem Fall dreistufigen Informationspyramide bis in die

unterste Ebene und dadurch ein sukzessives Erschließen der für die Planer und

Entscheider relevanten Projektinformationen. Die aktuelle Stufe, in der sich der Benutzer

befindet, wird jeweils innerhalb der textuellen Begleitinformationen angezeigt. Ein

Backtracking (sogenanntes Drill-Up) zur vorhergehenden Visualisierungsstufe ist über

eine entsprechende statussensitive Schaltfläche jederzeit möglich. Diese Art der Inter-

aktion des Benutzers führt zu dem in Kapitel 4.4 beschriebenen interaktiv-zyklischen

Kontinuum.

6.2.4 Managementgerechte Aktionen

Bei der Implementierung der Gesamtfunktionalität der Applikation GP DSS wurde ver-

sucht, diese einfach und intuitiv, d. h. managementgerecht abzubilden. Dies wurde u. a.

durch die Verwendung kontext- und statussensitiver Aktionsschaltflächen erreicht

(realisiert über die leistungsstarken formula-enabled Hide-When-Mechanismen des


verwendeten Groupware-Systems). Abbildung 6.2.4-1 macht dies exemplarisch am Bei-

spiel der Dokumentenobjekte vom Typ Report deutlich. Abhängig vom jeweiligen Zu-

stand, in dem sich das Objekt dieser Dokumentenklasse befindet (neu instanziiert nur mit

den beim Erstellen übergebenen Attributen bzw. nach Aktivierung des DSS Pre-

Processors im Editier- oder Lesemodus), hat der Nutzer Zugang zu dezidierten Berei-

chen der Anwendung. Beispielsweise erscheint ein Versenden des Dokumentenobjektes

bei einem gerade neuinstanziierten Report wenig sinnvoll, da er noch keinen attraktiven

Mehrwert in Form eines explizit realisierten Diagramm-Objektes enthält.

1) vor dem Generieren (Editier-Modus)2) nach dem Generieren (Editier-Modus)3) nach dem Generieren (Lese-Modus)

1)

3)

2)

Abb. 6.2.4-1: Kontext- und statussensitive Aktionsschaltflächen

Über die Aktionsschaltflächen wurde der Zugang zu den Dialogen der Kommunika-

tionsschnittstelle, dem Setzen von Zugriffsrechten und der Übernahme von Diagramm-

Objekten in Drittapplikationen über Clipboard-Mechanismen realisiert. Abbildung 6.2.4-

2 zeigt exemplarisch die umgesetzte Kommunikationskomponente. Hier wurde die

Komplexität der normalen systemeigenen E-Mail-Schnittstelle mit den vielfältigen

Optionen reduziert und die Möglichkeiten auf ein für diesen Kontext erforderliches

Mindestmaß beschränkt. Neben den dem Anwender bereits bekannten Attributen, wie

Empfänger, Priorität und den verschiedenen Versende-Optionen, kann er hier die seinem

aktuellen Bedarf entsprechende Versandart wählen. Ein Hilfetext am Ort der Handlung


[vgl. Keil-Slawik 1995] erläutert die möglichen Optionen und damit verbundenen

Konsequenzen.

Versandart

Hilfetext

Standardoptionen

Abb. 6.2.4-2: Kommunikationskomponente

Das Erstellen eines Reportdokumentes auf Basis eines existierenden und wohldefinierten

Profildokumentes ist mit zwei Mausklicks auf (Aktions-)Schaltflächen ohne Tasta-

tureingaben und Menü-Benutzung zu erreichen und erfüllt somit auch diese in 3.3 ge-

machte Anforderung der mauszentrierten Bedienung.

6.3 Implementierte Szenarien

Durch Auswahl eines Szenarios in den Parametereinstellungen des Profildokumentes legt

der Benutzer die zu visualisierenden Projektparameter und die angebotenen Visua-

lisierungsmöglichkeiten (Diagrammarten) fest. Ferner determiniert er damit die mögli-

chen Selektionsmöglichkeiten bezüglich der Plan-/Ist-/Soll-Darstellung dieser Projekt-

parameter (in weiterer Abhängigkeit von den in der Projektdatenbasis niedergelegten

Projektdaten, d. h. der expliziten Formulierung des projektspezifischen Corporate Data

Models) und den Aufbau der textuellen Begleitinformationen.

Die Szenarien stellen flexible Präsentationsmodule zur Darstellung der über das Cor-

porate Data Model abgelegten Projektinformationen dar. Aufgrund der durch die Exper-

teninterviews gestützten Tatsache einer sehr individuellen und unterschiedlichen Ge-

wichtung von Zeit-, Kosten- und Ressourcendaten innerhalb einer Organisation wurde

ein breites Spektrum an möglichen Visualisierungsszenarien abgedeckt. Dazu wurden

acht konkrete Szenarien entwickelt, die alle einen unterschiedlichen Fokus dieser Para-


meter abdecken. Durch die Realisierung als Script Library-Objekte sind diese leicht

modifizier- bzw. anpaßbar, und die so entstandene Template-Bibliothek kann durch die

Rapid Prototyping-Mechanismen, die die objektorientierte Entwicklungsumgebung zur

Verfügung stellt, rasch um weitere projektzentrierte Szenarien ergänzt werden.

Pro Szenario-Objekt wurden dabei zwischen 501 und 938 Zeilen Scriptcode erstellt.

Konkret wurden die in Tabelle 6.3-1 dargestellten Szenarien realisiert.

Nr. Bezeichnung Anwendungsfokus

1. Ressourcen Aufwand Aggregation der Aufwände zur Darstel-lung von Überlastungen

2. Termine: Mitarbeiter in Projekten Gantt-Darstellung zur Identifikationmöglicher Ressourcenkonflikte

3. Kosten Allgemeine Darstellung von Kostenda-ten

4. Überzogenes Budget Problemspezifische Darstellung vonKostendaten: Ist-Kosten > Basis-Ko-sten

5. Projekte: Aufwand (Drill-Down) Über drei Ebenen exemplarisch reali-siertes Drill-Down Szenario mit Dar-stellung des jeweiligen Aufwandes

6. Ressourcen: Kosten nach Projekten Aggregation der Kostendaten nachRessource und Projekt

7. Terminverzögerung Problemspezifische Darstellung vonterminverzögerten Vorgängen: Soll-Anfang/-ende der Vorgänge liegt in derVergangenheit und der Ist-Anfangwurde noch nicht dokumentiert

8. Ressourcen: Aufwand nach Projekten Nicht-kumulative Darstellung derAufwandswerte nach Ressource undProjekt

Tab. 6.3-1: Implementierte Szenarien

Anwendungsbeispiel

Das Szenario 4: „Überzogenes Budget“ sei an dieser Stelle exemplarisch erläutert. Im

Parametrisierungssubmodul wurde dazu „Szenario 4“ eingestellt, die Projekte

„Hausbau“, „Sportpark“ sowie „Großsporthalle“ nutzerkreisabhängig gewählt, sowie

eine nicht ressourcendependente Selektion spezifiziert, d. h. die an den Projektphasen

beteiligten Mitarbeiter bzw. Sachressourcen haben für den Nutzer in diesem Fall zur

weiteren Einschränkung keine Relevanz. Der zu betrachtende Zeitraum war der 07. No-


vember 1996 bis 02. April 1997. Als präferierte Darstellung wurde Balkendiagramm und

eine vergleichende Gegenüberstellung von Soll-, Ist- und Basisdaten gewählt.

Abb. 6.3-1: Ausschnitt eines Reportdokumentes: Szenario 4: Überzogenes Budget

Der DSS Metafilter hat daraufhin die Projekte „Hausbau“ (mit den Vorgängen

„Verglasung“, „Aushub Grund“ und „Phase 3“) und „Sportpark“ (mit dem Vorgang

„Tribüne“) als relevant innerhalb der oben beschriebenen Abfragekonfiguration und des

Kriteriums „Ist-Kosten > Basis-Kosten“ als GroupProject-interne Definition von

„überzogenem Budget“ [vgl. PAVONE 1996, S. 2-22] identifiziert. Die zugehörigen

Dokumentenattribute wurden daraufhin kopiert und direkt an den DSS Visualizer wei-

tergegeben, der diese, wie in Abbildung 6.3-1 dargestellt, als grafisches Attribut in Form

eines Chart-Objektes an das Reportingsubmodul übergibt. Neben diesen grafischen In-

formationen werden dem Nutzer in Tabellenform zusätzlich der Fertigstellungsgrad der

identifizierten Projektphasen, sowie deren Soll- und Ist-Termine angezeigt.


Dem betrieblichen Planer bzw. Entscheider steht innerhalb dieses Beispiels eine Darstel-

lung des Parameters „Kosten“ in Bezug auf einen möglichen kritischen Status seiner

Projekte zur Verfügung (in diesem Fall hätten sich etwaige Befürchtungen für das

Projekt „Großsporthalle“ als unbegründet ergeben). Im Beispiel sind die entscheidungs-

relevanten Vorgänge identifiziert (insbesondere Vorgang „Phase 3“ des Projektes

„Hausbau“ hebt sich dabei relativ zu den anderen Vorgängen durch die auffällige Diffe-

renz von Plan- und Ist-Kosten hervor), und ein steuernder Eingriff als nach der Über-

wachung logisch folgender Schritt innerhalb des Multiprojektcontrollings ist möglich.

Wie ein solcher Eingriff auszusehen hat, wird dabei durch die organisationsspezifischen

Koordinationsmechanismen determiniert.

Für eine technische Beschreibung der acht im Rahmen dieser Arbeit realisierten

Szenarien vgl. die in Anhang C.4.3 vorhandene Dokumentation.

6.4 Zusammenfassung: Übersicht Gesamtkonzept

In diesem Abschnitt wird die oben vorgestellte konkret implementierte Lösung GP DSS

im Kontext des in Kapitel 4.4 formulierten integrierten Architekturmodells für das im

Rahmen dieser Arbeit zu entwickelnden Frontend-Systems dargestellt.

1. DSS UI

Die Mensch-Maschine-Interaktion findet durch das Lotus Notes User Interface statt. Das

Parametrisierungssubmodul zur Spezifikation der Abfrageparameter wurde durch das

Konzept der Profile realisiert. Über Reportdokumente und ihre zugehörige Maske wurde

das Reportingsubmodul konkret umgesetzt.

2. DSS Application Engine

Die Application Engine wurde innerhalb der Szenario-Module realisiert. Der DSS

Metafilter sorgt dabei für eine Selektion der – durch ein Profildokument oder einen

explizit durch den Endbenutzer ausgeführten Drill-Down – als relevant spezifizierten

Dokumentenobjekte.

3. DSS Graphical Pre-Processor

Die Aufgabe des Graphical Pre-Processor ist es, die aus dem Backend-System extra-

hierten Informationen für die Folgekomponente im Sinne einer Aggregation bzw.

Transformation aufzubereiten. Dieses wird ebenfalls durch einen Abschnitt im jeweiligen

Scriptcode des Szenario-Objektes realisiert.


CDM

GP Datenbanken

InformationPull

4. VisualizerChart

Component

2. ApplicationEngine

LotusScript

3. GraphicalPre-Processor

LotusScript

Reports Profile

1. DSS UINotes UI

5. ArchivDSS DB

Metafilter6. Kommunikations-schnittstelle

Notes Mailing

Abb. 6.4-1: Übersicht Gesamtkonzept

4. DSS Visualizer

Die Funktionalität des DSS Visualizers wird durch das Lotus Chart Component bereit-

gestellt. Dazu erfolgt ein Aufruf der entsprechenden Prozeduren und Funktionen bzw.

Setzen der entsprechenden Attribute des Chart-Objektes innerhalb des jeweiligen

Szenario-Moduls.

5. DSS Archiv

Zur Archivierung der erstellten Reportdokumente steht die Dokumentenverwaltung der

verwendeten Groupware-Plattform zur Verfügung. Solcherart gespeicherte Reportdo-

kumente stellen „Schnappschüsse“ der jeweils betrachteten Projektinformationen dar.

6. Kommunikationsschnittstelle

Die Kommunikationsschnittstelle wurde durch Implementierung eines applikations-

spezifisch angepaßten E-Mail-Dialoges realisiert. Die eigentliche Versende- und Zustell-

Funktionalität derart erzeugter E-Mail-Dokumente wird dabei durch die im Groupware-

System standardmäßig enthaltenene Mailingengine erbracht.

Abbildung 6.4-1 faßt die eben gemachten Ausführungen übersichtlich zusammen.

7 Schlußbetrachtung und Perspektiven Seite 71

7 Schlußbetrachtung und Perspektiven

In diesem Kapitel sollen eine abschließende Betrachtung der Arbeit durchgeführt und

konzeptionelle Erweiterungsmöglichkeiten anhand einer konkreten Technologie be-

schrieben werden.

Ziel dieser Arbeit war die Entwicklung einer Lösung für die bedarfsgerechte Präsentation

von Projektmanagement-Daten zur Entscheidungsunterstützung unter Darstellung des

Bezugs- und Relevanzrahmen sowie der konkreten softwaretechnischen Umsetzung

dieser Konzepte.

Fazit

Im vorliegenden schriftlichen Teil wurde der Trend zur projektorientierten Unterneh-

mung und den damit verbundenen neuen Führungskonzepten wie „Management by

Projects“ als Motivationsfaktoren für diese Arbeit belegt. Bestehende Lösungen zur

Visualisierung von Projektdaten im Sinne einer Entscheidungsunterstützung lassen keine

managementgerechte Erstellung von Auswertungen zu. Es wurde ein konkretes

Anforderungsprofil an ein Frontend-System zur Entscheidungsunterstützung im Rahmen

der Multiprojektkoordination entwickelt und dazu ein generisches Architekturkonzept

(vgl. Kapitel 4.4) formuliert. Die Definition von relevanten Nutzerkreisen ermöglicht

dabei die selektive Nutzung eines solchen Informationssystems gemäß der im

Projektmanagement existierenden Rollenzuordnung.

Im praktischen Teil der Arbeit wurde das Architekturkonzept anhand der definierten

Anforderungen konkret umgesetzt. Die realisierte Anwendung GP DSS stellt einen

innovativen Lösungsansatz für das kooperative Multiprojektmanagement dar, der auf der

Fachmesse „CeBIT“ im März 1997 ausgewählten Kunden des kooperierenden Un-

ternehmens präsentiert wurde.

Die flexible Abfragegestaltung der Lösung ermöglicht die Erstellung von Ad-hoc- als

auch Standard-Analysen bezüglich Zeit-, Kosten- und Ressourcendaten und ihre

adäquate grafische Repräsentation. Durch das endbenutzerzentrierte Bedienungskonzept

steht ein managementgerechtes Werkzeug zur Entscheidungsunterstützung bereit. GP

DSS stellt differenzierte Mechanismen zur Überwachung einer interdependenten

Multiprojektlandschaft zur Verfügung. Die in Kapitel 6.3 vorgestellten konkret imple-

mentierten Szenarien sollen die zum Multiprojektcontrolling erforderliche Identifikation

7 Schlußbetrachtung und Perspektiven Seite 72

notwendiger Plananpassungen verbessern. Die Lösung enthält ferner Funktionalitäten zur

teamorientierten Kommunikation und Weiterverwendung der gewonnenen Ergebnisse

ohne Medienbrüche.

Ausblick

Die Applikation ist durch ihren modularen Aufbau prinzipiell offen für unternehmens-

spezifische Erweiterungen und Anpassungen. Dadurch ist es möglich, existierende

organisationsspezifische Standardlayouts abzubilden und eine formgerechte Projektbe-

richterstattung für das Multiprojektcontrolling zu realisieren.

Ein Wechsel der Basistechnologie für die Visualisierungskomponente könnte das An-

wendungsspektrum der Applikation auf die zunehmende Bedeutung erlangenden netz-

werkzentrierten Inter-, Intra- und Extranet-Lösungen ausdehnen. Die modulare Archi-

tektur des Gesamtkonzepts der entwickelten Lösung sieht eine solche Ausrichtung

prinzipiell vor, um dem Verteilungsgedanken Rechnung zu tragen. Aufgrund der in der

DV-Landschaft nach wie vor anzutreffenden heterogenen IT-Strukturen und aufkom-

mender neuer Konzepte, wie dem derzeit als Network Computer (NC) heftig diskutierten

Ansatz, ist eine plattformunabhängige bzw. -übergreifende Realisierung zu präferieren.

Diese höhere Offenheit der Lösung könnte durch den Austausch des Moduls DSS

Visualizer durch die derzeit noch nicht erhältliche, aber bereits unter dem Namen Kona

angekündigte Technologie erreicht werden. Kona stellt eine konzeptionelle Andersent-

wicklung der verwendeten Components dar: dabei werden die aufgabenbezogenen

Softwaremodule als Java-Applets realisiert. Die Nutzung der plattformübergreifenden

Programmiersprache Java brächte den Vorteil der relativen Plattformunabhängigkeit [vgl.

Lotus 1997a; Lotus 1997b]. Diese Ausrichtung ist in der verwendeten Groupware-

Plattform Lotus Notes durch die Domino-Server-Technologie prinzipiell vorgesehen und

ermöglicht ein auf Client-Seite von Notes völlig unabhängiges User Interface.

A Verzeichnisse Seite 73

A Verzeichnisse

A.1 Literatur

[Aggteleky/Bajna 1992]

Aggteleky, B.; Bajna, N.: Projektplanung, Carl Hanser Verlag, München,

Wien, 1992

[Balck 1990]

Balck, H.: Paradigmawechsel im Projektmanagement – Projekte als Bewe-

gungsform des technologisch-organisatorischen Strukturwandels, in: Balck,

H. (Hrsg.): Neuorientierung im Projektmanagement, TÜV-Rheinland, Köln,

1990, S. 61-70

[Behrens 1994]

Behrens, O. M.: Konzepte, Anforderungen, Möglichkeiten für die Integration

von Hypermediakonzepten in Groupwareapplikationen, Dissertation, St.

Gallen, 1994

[Booch 1994]

Booch, G.: Object orientated analysis and design with applications, 2. Auf-

lage, Benjamin/Cummings Publishing Company, Redwood City, California,

1994

[Bromann 1991]

Bromann, P.: FIS/EIS-Auswahl, Einführung und Weiterentwicklung – ein

Erfahrungsbericht, in: Bäck, H. (Hrsg.): Der gut informierte Manager: er-

folgreiche europäische MIS- und EIS-Lösungen, Verlag TÜV Rheinland

GmbH, Köln, 1991, S. 39-50

[Burghardt 1995]

Burghardt, M.: Projektmanagement, 3. Auflage, Siemens-Aktiengesellschaft,

Berlin, München, 1995

[Burkan 1991]

Burkan, Wayne C.: Executive Information Systems: from proposal through

implementation, Van Nostrand Reinhold, New York, 1991


[Chorafas 1987]

Chorafas, D.N.: Computergestütztes Management, McGraw-Hill Book

Company GmbH, Hamburg, 1987

[Codd 1993]

Codd, E. F.: Providing OLAP (On-line Analytical Processing) to User-

Analysts: An IT Mandate, o. O., 1993, aus:

http://www.arborsoft.com/essbase/wht_ppr/coddc0.html am: 26.01.97

[Curtis 1989]

Curtis, G.: Business Information Systems, Addison-Wesley Publishing

Company, Wokingham, England usw., 1989

[Dangelmayer 1995]

Dangelmayer, W.: Skript zur Vorlesung "Grundlagen von Fertigungsinfor-

mationssystemen" WS 95/96, Paderborn, 1995

[Des Rosiers/Pinard 1991]

Des Rosiers, J.-P.; Pinard, L.: Management by Projects: A Canadian Case,

in: Gareis, R. (Hrsg.): Handbook of Management by Projects, Manz, Wien,

1991, S. 105-110

[DIN 69901]

Deutsches Institut für Normung e.V.: DIN 69901, Beuth Verlag GmbH,

Berlin usw., 1994

[Eason 1992]

Eason, K.: Organizational issues in the use of decision support systems, in:

Holtham, C. (Hrsg.): Executive Information Systems and Decision Support,

Chapman & Hall, London usw., 1992, S. 9-16

[Ehrl-Gruber 1996]

Ehrl-Gruber, B.: Informationsfluß zielgerichtet gestalten, in: Ehrl-Gruber, B.;

Süß, G. M. (Hrsg.): Praxishandbuch Projektmanagement (Band 1), WEKA

Fachverlag für technische Führungskräfte GmbH, Augsburg, 1996, Abschnitt

4.3


[Ellis et al. 1991]

Ellis, C. A.; Gibbs, S. J.;Rein, G. L.: Goupware – some issues and

experiences, in: Communications of the ACM, Association for Computing

Machinery, Inc., New York, Januar 1991, Vol. 34, Nr. 1, S. 39-58

[Eschlbeck 1996]

Eschlbeck, D.: Projektcontrolling, in: Ehrl-Gruber, B.; Süß, G. M. (Hrsg.):

Praxishandbuch Projektmanagement (Band 1), WEKA Fachverlag für tech-

nische Führungskräfte GmbH, Augsburg, 1996, Abschnitt 2.5

[Fischbacher 1996]

Fischbacher, F.: Multiprojektmanagement, in: Ehrl-Gruber, B.; Süß, G. M.

(Hrsg.): Praxishandbuch Projektmanagement (Band 1), WEKA Fachverlag

für technische Führungskräfte GmbH, Augsburg, 1996, Abschnitt 2.7

[Frank/Pudwitz 1994]

Frank, H.; Pudwitz, F.: Prozeßorganisation anhand eines Beispiels aus dem

Bereich der Medizinischen Technik der Siemens AG, in: Frese, E.; Maly, W.

(Hrsg.): Organisationsstrategien zur Sicherung der Wettbewerbsfähigkeit,

Verlagsgruppe Handelsblatt, Düsseldorf, 1994, S. 163-176

[Gareis 1990]

Gareis, R.: Management by Projects: der zukunftsorientierte Managmentan-

satz, in: Balck, H. (Hrsg.): Neuorientierung im Projektmanagement, Verlag

TÜV Rheinland, Köln, 1990, S. 239-248

[Gareis 1991]

Gareis, R.: Management by Projects: The Management Strategy of the "new"

Project-orientated Company, in: Gareis, R. (Hrsg.): Handbook of

Management by Projects, Manz, Wien, 1991, S. 35-47

[Gareis 1992]

Gareis, R.: Management by Projects: Spezifische Strategien, Strukturen und

Kulturen projektorientierter Unternehmen, in: Lange, D. (Hrsg.): Projekt-

management: Dokumentation/Projektmanagement-Forum 1992, Gesellschaft

für Projektmanagement INTERNET Deutschland e.V., München, 1992,

S. 145-155


[Götz 1996]

Götz, W.: Anwenderbericht GroupProject: Schöller Lebensmittel GmbH,

PAVONE Informationssysteme GmbH, Paderborn, 1996

[Haberfellner et al. 1994]

Haberfellner, R.; Nagel, P.; Becker, M.; Büchel, A.; von Massow, H.: , in:

Daenzer,W. F.; Huber F. (Hrsg.): Systems Engineering, 8. Auflage, Verlag

Industrielle Organisation, Zürich, 1994

[Henneböle 1995]

Henneböle, J.: Executive Information Systems für Unternehmensführung und

Controlling, Gabler Verlag, Wiesbaden, 1995

[Hügler 1988]

Hügler, G. L.: Controlling in Projektorganisationen, Verlag Barbara Kirsch,

München, 1988

[IBM 1996]

IBM: Lotus Notes Release 4.5: A Developer's Handbook, Research Triangle

Park, NC, 1996

[Jenny 1995]

Jenny, B.: Projektmanagement in der Wirtschaftsinformatik, vdf Hoch-

schulverlag AG, Zürich, 1995

[Kaiser 1994]

Kaiser, A.: Computer Supported Cooperative Work: Modeerscheinung oder

zukunftsweisendes Paradigma?, in: Nachrichten für die Dokumentation,

Verlag Hoppenstedt GmbH, Darmstadt, Heft 5, 1994, S. 255-262

[Keil-Slawik 1995]

Keil-Slawik, R.: Materialien zur Vorlesung "Grundlagen der Systemgestal-

tung" WS 95/96, Padernborn, 1995

[King 1995]

King, N. H.: Project Management – On Time and On Budget, in: PC

Magazine, Ziff-Davis Publishing Company, New York, Vol. 14, No. 7, 11.

April 1995, S. 165-177


[Kornblum 1994]

Kornblum, W.: Die Vision einer effizienten Unternehmenssteuerung auf der

Basis innovativer Führungs-Informationssysteme, in: Dorn, B. (Hrsg.): Das

informierte Management, Springer-Verlag, Berlin usw., 1994, S. 75-102

[Korndörfer 1995]

Korndörfer, W.: Unternehmensführungslehre, Gabler Verlag, Wiesbaden,

1995

[Krüger 1994]

Krüger, W.: Organisation der Unternehmung, 3. Auflage, W. Kohlhammer

GmbH, Stuttgart usw., 1994

[Kurbel 1993]

Kurbel, K.: Unterstützung kooperativen Arbeitens beim Softwareprojekt-

Management, in: Information Management, IDG-Verlag, München, 4/93,

S. 50-58

[Laudon/Laudon 1988]

Laudon, K.; Laudon, J. P.: Management Information Systems, Macmillan

Publishing Company, New York, 1988

[Leidner/Elam 1994]

Leidner, D. E.; Elam, J. J.: Executive Information Systems: Their Impact on

Executive Decision Making, in: Journal of Management Information

Systems, M.E. Sharp, Inc., Armonk, N.Y., Vol. 10 (1994), No. 3, S. 139-

155

[Leventhal 1995]

Leventhal, N. S.: Using Groupware to Enhance Team Decision Making, in:

Information Strategy, Auerbach Publ., Boston, Mass., Vol. 12 (1995), Nr. 1,

S. 6-13

[Lotus 1996a]

Lotus Development Corporation: White Paper – Lotus Notes: An Overview,

o. O., 1996, aus: http://www.lotus.com/corpcomm/22b6.htm am: 26.1.97

[Lotus 1996b]


Lotus Development Corporation: Developing Notes Applications with Lotus

Components, o. O., 1996

[Lotus 1997a]

Lotus Development Corporation: Lotus Previews Java-based Business

Productivity Applets for Web Browsers, Network Computers, and Notes

Clients, Orlando, 1997, aus: http://www.kona.lotus.com/2112.html am:

26.03.97

[Lotus 1997b]

Lotus Development Corporation: Product Info: Kona applets Quick Read, o.

O., 1997, aus: http://www.kona.lotus.com/210e.html am: 26.03.97

[Madauss 1994]

Madauss, B. J.: Handbuch Projektmanagement, 5. Auflage, Schäffer-

Poeschel Verlag, Stuttgart, 1994

[Mucksch et al. 1996]

Mucksch, H.; Holthuis J.; Reiser, M.: Das Data Warehouse-Konzept – ein

Überblick, in: Wirtschaftsinformatik, Friedrich Vieweg & Sohn Verlagsge-

sellschaft mbH, Wiesbaden, Heft 4, Juli 1996, S. 421-433

[Muhanna 1993]

Muhanna, W.A.: An object-oriented Framework for model management and

DSS development, in: Decision Support Systems, Elsevier Science Publishers

B.V., Amsterdam, Vol. 9 (1993), No. 2, S. 217-229

[Nastansky 1990]

Nastansky, L.: Objektorientierte Systeme im Endbenutzercomputing, in:

Wirtschaftsinformatik, Friedrich Vieweg & Sohn Verlagsgesellschaft mbH,

Wiesbaden, Heft 3, Juni 1990, S. 238-252

[Nastansky/Seidensticker 1990]

Nastansky, L.; Seidensticker, F.-J.: Anwendungen und Konzepte für Hy-

permedia-basiertes Informationsmanagement am netzintegrierten Arbeits-

platz, in: Wirtschaftsinformatik, Friedrich Vieweg & Sohn Verlagsgesell-

schaft mbH, Wiesbaden, Heft 6, Dezember 1990, S. 519-537


[Nastansky 1993]

Nastansky, L.: Nach 20 Jahren CSCW-Forschung: Durchbruch in der Praxis

bei Groupware-Anwendungen in Client-Server-Architekturen, in: Nastansky,

L. (Hrsg.): Workgroup Computing- Computergestützte Teamarbeit (CSCW)

in der Praxis / Neue Entwicklungen und Trends, S + W Steuer- und

Wirtschaftsverlag, Hamburg, 1993, S. 1-20

[Nastansky et al. 1995]

Nastansky, L.; Schicker, T.; Behrens, O. M.; Ehlers, P.: Büroinformations-

systeme, in: Fischer, J.; Herold W.; Dangelmaier, W.; Nastansky. L.; Wolff,

R. (Hrsg.): Bausteine der Wirtschaftsinformatik, S + W Steuer- und Wirt-

schaftsverlag, Hamburg, 1995, S. 267-371

[Nastansky et al. 1996]

Nastansky, L.; Riempp, G.; Hilpert W.; Ehlers, P.: Workkflow- und Projekt-

Management auf der Basis von Groupware – Analyse, Planung, operative

Unterstützung und Optimierung von Geschäftsprozessen mit GroupFlow und

GroupProject, Arbeitspapier Wirtschaftsinformatik 2, Paderborn, 1996

[Nastansky/Ehlers 1996]

Nastansky, L.; Ehlers, P.: Präsentationsfolien zum DFG Kolloquium

"Verteilte DV-Systeme in der Betriebswirtschaft" Leipzig 21.06-22.06.1996,

Paderborn, 1996

[O'Brien 1995]

O'Brien, B.: Information Management Decisions, Pitman Publishing,

London, 1995

[Oppelt 1995]

Oppelt, U. G.: Computerunterstützung für das Management, Oldenbourg,

München, 1995

[o. V. 1997a]

o. V.: Projekt-Management für erfolgreiches Business Reengineering, in:

Notes Magazin, IWT-Magazin-Verlags-GmbH, Vaterstetten, 1/97, S. 22-23


[o. V. 1997b]

o. V.: Lotus dominiert den Groupware-Markt, in: Computer Zeitung, Kon-

radin Verlag, Leinfelden-Echterdingen, 6. März 1997, Nr. 10, S. 2

[Parsaye/Chignell 1993]

Parsaye, K.; Chignell, M.: Intelligent Database Tools & Applications, John

Wiley & Sons, Inc., New York usw., 1993

[PAVONE 1996]

PAVONE Informationssysteme GmbH: GroupProject Datenbanken – Hand-

buch Release 2.1, Paderborn, 1996

[Rieger 1990]

Rieger, B.: Vergleich ausgewählter EIS-Generatoren, in: Wirtschaftsinfor-

matik, Friedrich Vieweg & Sohn Verlagsgesellschaft mbH, Wiesbaden, Heft

6, Dezember 1990, S. 491- 518

[Rinza 1994]

Rinza, P.: Projektmanagement, 3. Auflage, VDI-Verlag, Düsseldorf, 1994

[Roux-Kiener 1991]

Roux-Kiener, A.: Project Organizations: A Step to Transform the Traditional

Pyramid, in: Gareis, R. (Hrsg.): Handbook of Management by Projects,

Manz, Wien, 1991, S. 111-118

[Schicker 1994]

Schicker, T.: Informationsrepräsentation in Hypermediasystemen: Grundla-

gen, Konzepte und Lösungsmöglichkeiten der Informationsrepräsentation in

Hypermediasystemen, S + W Steuer- und Wirtschaftsverlag, Hamburg, 1994

[Schmidt 1994]

Schmidt, G.: Methode und Techniken der Organisation, 10. Auflage, Verlag

Dr. Götz Schmidt, Gießen, 1994

[Schreiber 1995]

Schreiber, D.: Objektorientierte Entwicklung betrieblicher Informations-

systeme, Physica-Verlag, Heidelberg, 1995


[Schultz 1987]

Schultz, R.: Quantitative Entscheidungsunterlagen auf der Grundlage von

Szenarien, Gabler Verlag, Wiesbaden, 1987

[Schwägerl 1996]

Schwägerl, M.: Glossar, in: Ehrl-Gruber, B.; Süß, G. M. (Hrsg.): Praxis-

handbuch Projektmanagement (Band 1), WEKA Fachverlag für technische

Führungskräfte GmbH, Augsburg, 1996, Abschnitt 1.4

[Tiemeyer/Zsifkovits 1995]

Tiemeyer, E.; Zsifkovits, H. E.: Information als Führungsmittel: Executive

Information Systems, Computerwoche Verlag GmbH, München, 1995

[Wall 1988]

Wall, A. J.: Project Planning and Control Using Micros, NCC Publications,

Manchester, 1988

[Webb 1996]

Webb, A.: Project Management – 40 years young and still looking for a

philosophy, in: Project Manager Today, Larchdrift Projects Ltd., London,

May 1996, aus: http://www.projectnet.co.uk/pm/pmt/pmtmaya6.htm am:

26.01.97

[Wischnewski 1993]

Wischnewski, E.: Modernes Projektmanagement, 4. Auflage, Friedrich

Vieweg & Sohn, Braunschweig/Wiesbaden, 1993


A.2 Abbildungen

Abb. 1.1-1: Für Entscheidungen verfügbare Zeitspanne

Abb. 2.1-1: Grundparameter eines Projektes

Abb. 2.5-1: Verteiltes Arbeiten in Teams

Abb. 3.1-1: Nutzerkreise

Abb. 3.2-1: „Teufelsquadrat“

Abb. 3.2-2: „Technologiegestützte Kooperation“

Abb. 3.2-3: Entscheidungsfindung in einer interdependenten Projektlandschaft

Abb. 4.1-1: Gantt-Diagramm

Abb. 4.1-2: Histogramm

Abb. 4.2-1: Entwicklung der Organistationsstrukturen

Abb. 4.3-1: Historisches Paradigma der Datenverarbeitung

Abb. 4.3-2: Historische Entwicklung computerbasierter Informationssysteme

Abb. 4.3-3: Moderne Client-Server-Architektur: Verteiltes Arbeiten in Teams

Abb. 4.4-1: Architekturkonzept

Abb. 4.4-2: Integration in „Technologiegestützte Kooperation“

Abb. 5.3-1: GroupProject System

Abb. 5.3.1-1: Logischer Aufbau eines GP Vorgangsdokumentes

Abb. 5.3.1-2: Technischer Aufbau eines GP Vorgangsdokumentes

Abb. 6.1-1: Architekturmodell

Abb. 6.1.1-1: Zentrale Paradigmen GP DSS

Abb. 6.1.1.1-1: Endbenutzerfreundliche Roadmap

Abb. 6.1.1.1-2: Nutzerkreise

Abb. 6.1.1.2-1: GP DSS Metafilter

Abb. 6.1.1.3-1: Aufbau eines Reportdokumentes


Abb. 6.1.2-1: Integration in die Projektmanagement-Umgebung

Abb. 6.1.3-1: Dokumentenhierarchien

Abb. 6.1.3-2: Message Passing

Abb. 6.2.1-1: Navigation (Anwendungsebene)

Abb. 6.2.1-2: Navigation (Dokumentenebene)

Abb. 6.2.1-3: Ansichten mit Navigatoren

Abb. 6.2.2-1: Nutzerkreisabhängige Projektauswahl

Abb. 6.2.2-2: Thumbnail-Konzept

Abb. 6.2.3-1: Drill-Down

Abb. 6.2.4-1: Kontext- und statussensitive Aktionsschaltflächen

Abb. 6.2.4-2: Kommunikationskomponente

Abb. 6.3-1: Ausschnitt eines Reportdokumentes: Szenario 4: Überzogenes Budget

Abb. 6.4-1: Übersicht Gesamtkonzept


A.3 Tabellen

Tab. 4.3-1: Paradigmenwechsel: MIS vs. EIS

Tab. 6.3-1: Implementierte Szenarien

Tab. C.2.4-1: Zunehmende Bedeutung eines „Management by Projects“

Tab. C.2.4-2: Kommerziell erhältliche PM-Werkzeuge: Fähigkeit

Multiprojektmanagement-Informationen zu visualisieren

Tab. C.2.4-3: Kommerziell erhältliche PM-Werkzeuge: Bedienbarkeit allgemein

Tab. C.2.4-4: Flächendeckender Einsatz von E-Mailing

Tab. C.2.4-5: Einsatz von Entscheidungsunterstützungssystemen

Tab. C.2.4-6: Nutzung eines Frontend-Systems zur Visualisierung von Projektdaten

zur Entscheidungsunterstützung auch für Projektmitarbeiter

Tab. C.2.4-7: Präferierte Parameter zur Visualisierung von Projektinformationen


A.4 Abkürzungen

CASPJ CA-SuperProject

CDM Corporate Data Model

CGI Conseilliers en Gestion Informatique

CSA Client-Server-Architektur

CSCW Computer Supported Cooperative Work

DSS Decision Support System(s)

EIS Executive Information System(s)

ESS Executive Support System(s)

EVA Eingabe, Verarbeitung, Ausgabe

GP GroupProject

GUI Graphical User Interface

IBM International Business Machines

IDC International Data Corporation

IDE Integrated Development Environment

LAN Local Area Network

MIS Management Information System(s)

MRS Management Reporting System(s)

MSP Microsoft Project

OCX OLE Custom Control

OLAP Online Analytical Processing

OLE Object Linking and Embedding

PM Projektmanagement

UI User Interface

WAN Wide Area Network


WWW World Wide Web

B Eidesstattliche Erklärung Seite 87

B Eidesstattliche Erklärung

Eidesstattliche Erklärung

Ich erkläre hiermit an Eides statt, daß ich die vorliegende Arbeit selbständig und nur

unter Verwendung der angegebenen Hilfsmittel angefertigt habe; die aus fremden

Quellen direkt oder indirekt übernommenen Gedanken sind als solche kenntlich gemacht.

Die Arbeit wurde bisher keiner anderen Prüfungsbehörde vorgelegt und auch noch nicht

veröffentlicht.

Paderborn, den . . . . . . . . . . . . . . . . . . . . . . . . . . .

(Datum) (Martin Schindler)

C Anlagen Seite 88

C Anlagen

C.1 WWW-Quellen

Dieses Kapitel findet sich aus Platz- und Übersichtlichkeitsgründen nur in der

elektronischen Version.

C Anlagen Seite 89

C.2 Experteninterviews

C.2.1 Anschreiben

Universität

Gesamthochschule Paderborn

Fachbereich 5 - Wirtschaftsinformatik

Univ.-Prof. Dr. Ludwig Nastansky

Universität GH Paderborn · D-33095 Paderborn

Adresse InformationssystemeGmbH

Paderborn 26.11.96

Ihre Meinung ist uns wichtig!

Sehr geehrte...,

im Rahmen einer wissenschaftlichen Arbeit an der Universität Paderborn führt eineArbeitsgruppe der Lehr- und Forschungseinheit Wirtschaftsinformatik 2, Prof. Dr. LudwigNastansky derzeit eine Befragung zum Thema "Entscheidungsrelevante Informationen fürdas Projektmanagement und deren graphische Präsentation" durch. Die Arbeit erfolgt inKooperation mit der PAVONE Informationssysteme GmbH.

In diesem Kontext führen wir derzeit eine telefonische Befragung durch, die das Zielverfolgt prinzipielle Anforderungen an graphische Systeme für das Projektmanagement zuentwickeln und zu definieren. Wir würden uns freuen, wenn auch Sie Ihre Meinung miteinbringen. Wir führen zu diesem Zweck die kurze Befragung als etwa 10-15 minütigestelefonisches Interview durch.

Herr Martin Schindler wird sich in den nächsten Tagen mit Ihnen in Verbindung setzenund sich über Ihre Kooperation sehr freuen.

Mit herzlichen Grüßen aus Paderborn

Peter Ehlers Martin Schindler

C Anlagen Seite 90

C.2.2 Interviewleitfaden

E x p e r t e n i n t e r v i e w

Name:Firma:Sitz:Branche: angeschrieben am:

Gesprächsdatum:Uhrzeit: von bis

Notes und Projektmangement:

(1) In welcher Abteilung sind Sie tätig und was für ein Verantwortungsbereich unter-steht Ihnen?

(2) Wieviele Mitarbeiter hat Ihr Unternehmen insgesamt?

(3) Wird Lotus Notes auch auf höheren Management-Ebenen eingesetzt?

(4) Haben Sie ein unternehmensweites E-Mailing-System im Einsatz (falls jawelches)?

(5) Wird dieses auch vom Management der höheren Ebenen genutzt?

(6) Welche Organisationsform herrscht in Ihrem Unternehmen? (Funktional-,Divisional-, Matrix-Organisation, Projektorganisation (als Überlagerung einer derersten Formen))

(7) Wieviel Prozent Ihrer beruflichen Tätigkeit ist projektorientiert? Hat sich das inden letzten Jahren verändert?

(8) Welchen Stellenwert hat Projektmanagement in Ihrer Unternehmung? Wird esals nützliches Werkzeug für bestimmte Fachabteilungen gesehen, oder dient eseher als Steuererungsmechanismus im Sinne einer Unternehmensphilosophie(Stichwort „Management by Projects“)? Sehen Sie da einen Trend in dieseRichtung?

(9) Wieviele Projekte betreuen Sie/Ihre Abteilung ca. pro Jahr? [in der jew. unter-nehmensinternen Definition von „Projekt“]

(10) Wieviele Mitarbeiter/Ressourcen sind in Ihren Projekten insgesamt beteiligt?

(11) Welche Größenordnung haben Ihre Projekte bezgl. des Budgets (ca. DM)?

Visualisierung:

(12) Nutzen Sie als Projektleiter Werkzeuge zur Visualisierung der Projektdaten?(d. h. neben CA-SuperProject/Microsoft Project/PAVONE GroupProject auchandere: z. B. selbsterstellte Excel Spreadsheets)

Falls ja:

- Welche Werkzeuge nutzen Sie?

- Was visualisieren Sie damit?

- Sind sie damit zufrieden oder sehen Sie Mängel, insbes. bei der Visualisierungvon Multiprojektmanagement-Informationen?

- Existiert dazu ein unternehmensweiter Standard?

(13) Welche Vorteile/Nutzenpotentiale würden Sie für sich durch den Einsatz einesgrafischen Projektmanagement-Frontends für die Projektleitung konkret sehen?In welchen Bereichen würden Sie bessere, d. h. effizientere Problemlösungen für

C Anlagen Seite 91

sich und Ihr Unternehmen sehen?

(14) Welche allgemeinen Anforderungen würden Sie an ein solches Visualisierungs-werkzeug stellen?

(15) Was wären mögliche Schwerpunkte im Hinblick auf die Visualisierung der Para-meter Zeit, Kosten und Ressourcen? Warum?

(16) Was für Darstellungsmöglichkeiten stellen Sie sich dabei konkret vor?

Frontend für Projektmitarbeiter:

(17) Welchen Zugriff sollte der normale Projektmitarbeiter auf ein solches System zurgrafischen Visualisierung von Projektdaten haben - wenn überhaupt? (z. B. Ein-satz nur zur besseren persönlichen Arbeitsplanung).

Frontend für höhere Ebenen:

(18) In welcher Weise könnten Sie sich vorstellen, daß solche grafischen Verdichtun-gen (von Projekt-Informationen) in Ihrem Haus von Entscheidern auf höhererEbene als Informationssystem ”auf Knopfdruck” (Decision SupportSystem/Executive Information System) genutzt werden würden, um sich effizien-ter/zielgrichteter zu informieren?

(19) Wo sehen Sie dabei die Grenzen von Aufwand vs. Nutzen für Ihre Unterneh-mung? D. h. was wird i. d. R. stattfinden: eine persönliche Nutzung eines solchenSystems durch den Entscheider oder eine Informationszusammenstellung durchDelegation an z. B. Assistenten?

(20) Denken Sie, es könnte Akzeptanzprobleme bezgl. der persönlichen Nutzung aufden höheren Ebenen geben (Umgang mit EDV, Usability o. ä.)?

(21) Könnten Sie sich vorstellen, daß solche grafischen Aggregationen von Entschei-dern auf höherer Ebene in Ihrem Hause als Entscheidungskriterium benutzt wür-den (z. B. Projektbewilligung)? Falls ja, wozu konkret?

(22) Würden Sie für diese Zielgruppe ”höheres Management” andere Anforderungs-schwerpunkte setzen als bei Visualisierungen, die sie selbst als Projektleiternutzen würden, oder wäre hier lediglich eine breitere Selektionsmöglichkeitanzusetzen (z. B. Möglichkeit über alle Mitarbeiter zuzugreifen anstatt nur dieaus dem eigenen Projekt)?

(23) Existieren in Ihrem Unternehmen bereits andere sogen. MIS (=Management In-formation Systems) bzw. EIS (=Executive Information Systems) oder auch DSS(=Decision Support Systems)? Wenn ja bitte kurz skizzieren (Einsatzrahmen undZweck).

C Anlagen Seite 92

C.2.3 Gesprächsprotokolle

Interview-Nr.: 1

Branche: Versicherungen

(1) Projektmitarbeiter in EDV-Abteilung, Lotus Notes Bereich - ist kein Projektleiter

und auch sonst nicht aus Projektleiter-Bereich

(2) 1500

(3) durchgängig

(4) ja: derzeit noch eine hostbasierte Lösung, die aber durch Notes abgelöst wird

(5) ja

(6) funktionale Hierarchie

(7) k. A. da erst seit kurzem im Unternehmen

(8) kein "Management by Projects", aber zu ca. 50% projektorientierte Organisation

(9) Betreut selbst keine, aber im Haus existieren pro Jahr ca. 70-80

(10) 5-20

(11) k. A. da kein Projektleiter

(12) selbst gar kein direkter Nutzer, aber weiß von anderen Nutzern: selbst

CASP/MSP sind zu komplex in der Funktionalität und dadurch auch in der Be-

dienung und zu fein skalierbar


(14) - nicht so komplex zu bedienen

- anwenderfreundlich

- übersichtlich

- konfigurierbares Layout


(16) Kapazitäts- und Ressourcenplanung, allerdings auf einer sehr grobe Ebene, nicht

zu detailliert


C Anlagen Seite 93

(18) aus Erfahrung: je einfacher desto besser, am besten auf Buttonklick

(19) was zählt ist das Ergebnis, in seinem Unternehmen ist eine Delegation gut mög-

lich

(20) bezüglich. Notes nicht, solange Lösung damit harmoniert sollte es problemlos

sein



(23) ja, nutzen SAS und HSS (hostbasierte Auswertungen)

C Anlagen Seite 94

Interview-Nr.: 2

Branche: DV-Bankdiensleister

(1) Abteilung Kommunikationstechnik (Netzbetrieb für großes Datennetz), dort

Projektleiter

(2) etwa 500 (+/- 100)

(3) ja, durchgängig

(4) Lotus Notes (mit Erweiterung zum Internet-Mailing

(5) ja, absolut

(6) keine "Idealform", meist funktional

(7) 100% - dies hat sich nicht verändert

(8) PM wird als Tool gesehen - nicht in Richtung "Management by Projects"

(9) er ca. 3

(10) um 5 Ressourcen

(11) mehrere Hunderttausendmark

(12) Regiograph um flächendeckend Ergebnisse darzustellen (zur Visualisierung von

Datennetzen, z. B. für einzelne Bundesländer), daran werden dann Projekter-

gebnisse dargestellt, dieses Tool arbeitet layerbasiert. Nein - er hat persönliche

Maßstäbe, es existieren aber keine Vorgaben

(13) sieht keine besonderen Vorteile/Nutzenpotentiale - prinzipiell ihm reicht

Microsoft Project/CA-SuperProject Funktionalität. Allerdings umständlich zu

handhaben und langwieriger Erstellungsvorgang von Grafiken. Multiprojekt-

visualisierung zu umständlich. Fände gut, wenn Ergebnisse einer solchen

Visualisierung gleich für Präsentationen übernehmbar wären (z. B. OLE)

(14) - OLE tauglich

- ergonomisch

- Lotus Notes integriert

- Standard GUI-Funktionalitäten

C Anlagen Seite 95

(15) am wenigsten interessieren die Kosten - Termine & Ressourcen sind hier die

Schwerpunkte

(16) Die Ansichten, die er aus der GP Projektedatenbank schon kennt nochmal über-

sichtlicher zusammengefaßt und visualisiert - im Überblick, so hat man die

Möglichkeit sich entweder Grafik oder "harte" Zahlen anzusehen

(17) durchaus Zugriff - jedoch skalierbar

(18) Absolut und sehr wichtig! Um globale, zentrale projektübergreifende Sichten zu

haben

(19) die Verantwortlichen hier sind weitgehend bereit und interessiert selber auf solche

Technologien einzugehen - wünschenswert wäre hier, wenn eine Standardi-

sierung, d. h. eine einzige Arbeitsweise(Vorgehen), die angeboten und gefördert

werden würde

(20) Nein, überhaupt nicht - wie schon unter (19) - die Entscheider in diesem Unter-

nehmen sind solchen Dingen sehr aufgeschlossen

(21) ja insbesondere für Projektanträge: unter der Prämisse, daß jeder Projektantrag

auf die gleiche Art und Weise erstellt würde, es also eine Art Standardformular

gibt

(22) projektübergreifende Gesamtübersichten sollten möglich sein, ferner sollte eine

Untermenge aus allen möglichen Ressourcen wählbar sein

(23) ist ihm nicht bekannt, daß es so etwas in seiner Unternehmung gibt - eine solche

Lösung wäre aber zu begrüßen

C Anlagen Seite 96

Interview-Nr.: 3

Branche: Werften

(1) Im Projektteam f. großes Investitionsprojekt mit seinen Teilprojekten. Zuständig

für den Bereich Projektsteuerung und Controlling

(2) ca. 1900

(3) nein - momentan noch nicht, ist allerdings angestrebt

(4) Microsoft-Mail

(5) nicht notwendigerweise selbst, aber wenn nicht, dann zumindest von der betreu-

enden Sekretärin

(6) Es existiert eine Projektstruktur neben der Linienstruktur. Für Teilbereiche, die

aus der Linie nicht ganz herauslösbar sind: Matrixstruktur

(7) gänzlich: 100%! Nein, dies war schon immer so.

(8) Im Schiffbau ist dies absolut als Unternehmensphilosphie zu verstehen.

(9) Das Unternehmen ca. 6: 6 Schiffe pro Jahr

(10) 30 mit der Planung

(11) Summe: ca. 0,5 Milliarden zw. 50-139 Mio. pro Schiff

(12) Im allgemeinen reicht die Funktionalität von CA-SuperProject, man hat aber auch

GRANEDA im Einsatz, eine Zeitlang auch CA-Grosse, das war allerdings zu

fehlerbehaftet, ferner existiert eine eigene Lösung zur Visualisierung von

Fertigstellungsgraden von Schiffen

(13) in erster Linie eine bessere Übersichtlichkeit für die Mehrprojektplanung, da

existieren Mängel bei Standardpakten

(14) er würde es als Informationssystem sehen - eine breite Nutzerfreundlichkeit wäre

nicht nötig, da nur

(15) möglichst alle drei: d. h. man sollte wählen können

(16) alles was CA-SuperProject kann, Histogramme Plan-/Ist-Hochrechnung

(17) keinen - das macht in diesem Umfeld keinen Sinn: die Mitarbeiter sind i. d. R.

nicht entsprechend ausgebildet überhaupt Computer zu nutzen

C Anlagen Seite 97

(18) Solche Systeme existieren bereits (vgl. 23). eine Aggregation von Informationen

einerseits und eine textuelle Reportingfunktionalität andererseits

(19) Im Zuge des Personalabbaus existiert der Zwang, daß auch Entscheider der

höchsten Ebenen dies persönlich. Nutzen müssen - d. h. Grenzen kann es keine

geben, wenn man sich für eine solche Lösung entschieden hat. Es findet leider

immer noch ein Umdenkprozess statt: man muß sich von der papierbasierten

Kommunikation lösen, dies geht aus Kosten- und Effizienzgründen gar nicht

anders; dieser Vorgang wird sich aber noch eine Weile hinziehen, dafür sind die

alten Strukturen zu eingefahren

(20) vgl. 19

(21) Absolut: Projektbewilligung, Projektreview, interne Kommunikation, als

Methode im F&E

(22) seiner Ansicht nach reicht eine solche Einschränkung/Verbreiterung der

Selektionsmöglichkeiten

(23) seit 2 Jahren existiert ein EIS. Man bedient sich dabei der Standardsoftware

MacControl für Apple-Systeme. Dies wird nur vom oberen Management genutzt

und für dient Entscheidungsfindung bezüglich des operativen Geschäftes.

C Anlagen Seite 98

Interview-Nr.: 4

Branche: Chemische Industrie

(1) Leiter Quality-Management

(2) 130

(3) ja

(4) Notes Mailing

(5) ja

(6) bei nur 130 Leuten keine "reine Lehre" - Mischform Matrixorganisation/PM.

Sieht absolute Tendenz zu stark projektorientiertem Unternehmen.

(7) ca. 2/3 verändert: nein

(8) momentan als Werkzeug, bricht aber auf in Richtung Management by Projects

(9) z.Zt. 1 Großprojekt und 6 Kleinprojekte

(10) in Großprojekten ca. 25 in den Kleinprojekten max. 5

(11) die Projekte werden ohne Kostenkalkulation durchgeführt, von daher können

solche Angaben nicht gemacht werden

(12) nein

(13) sieht keinen Bedarf/Notwendigkeit

(14) - passable Geschwindigkeit

- Zusammenführung von Teilprojekten zur gemeinsamen Visualisierung

(15) Kosten absolut nebensächlich da es sich um Organisationsprojekte handelt,

wichtig sind Zeiten

(16) jegliche Darstellung von Zeitmanagement

(17) grundsätzlich breiten Zugriff um eine hohe Transparenz zu schaffen, Sicherheit

sollte konfigurierbar sein

(18) da die Landschaft im betrachteten Unternehmen sehr heterogen ist: keine Ah-

nung, aber durchaus denkbar

C Anlagen Seite 99

(19) keine Grenzen: Selbstnutzung aufgrund der geringen Unternehmensgröße

zwingend

(20) nein - Berührungsängste existieren da wohl keine

(21) sehr gut Bspw. als Präsentationshilfsmittel und für Risikobetrachtungen

(22) der Projektleiter sollte die Informationen detaillierter abfragen können

(23) ja, Warenwirtschaftssystem auf SAP Basis, Vertriebsinformationssystem

C Anlagen Seite 100

Interview-Nr.: 5

Branche: Elektronik

(1) Informatik/Organisation, Projektleiter für Lotus Notes und Dokumenten-

archivierung

(2) 3000

(3) dies ist zumindest mittelfristig geplant

(4) cc:Mail

(5) ja durchaus und auch direkt

(6) die klassische hierarchische funktionalorientierte Organisation

(7) 100% nein. Er ist aber auch erst seit einem Jahr dabei

(8) Er sieht ganz klar die Tendenz, daß sich das momentan von einem

"Werkzeugdenken" in diese Richtung verschiebt, ja regelrecht wächst

(9) er selbst 2

(10) in dem einen 3 und im anderen 4

(11) das erste ca. 500 Tsd. DM und das andere ca. 1 Mio. DM

(12) Nein eher nicht. Es reicht die Standardfunktionalität von CA/MSP, ab und zu mal

bedarfsgerecht mit Excel etwas zusammenstellen aber nur sehr selten - z. B.

kumulierte Ist-Daten

(13) -besseres Reporting

- Erweiterung der Notes-Ansichten

- höhere Transparenz über die Projekte

- eine bessere Übersichtlichkeit für Multiprojecting, da sind Standardlösungen

mangelhaft und zu umständlich um schnelle Übersichten bei Bedarf zu erzeugen

(14) - Performance

- 16-bit Frontend lauffähig

- flexibel konfigurierbar

- Art der Darstellung änderbar

- Achsenbeschriftung nicht starr

C Anlagen Seite 101

(15) Termine, denn da herrscht hier der größte Druck

(16) ganz klassische Gantts, ggf. Balkendiagramme

(17) Diese sollten durchaus Zugriff haben. Einsatzszenarien dafür fallen ihm jetzt aber

auch nicht ein. Ggf. zu Dokumentationszwecken.

(18) Ja - sehr gut sogar. Dies ist sehr interessant und absolutes Thema - momentan

wird gerade eine OLAP-Lösung diskutiert

(19) Für sein Unternehmen ist das abhängig vom jeweiligen Entscheider, da gibt es

solche und solche. Auf jeden Fall muß die äußere Form ansprechend sein.

(20) Allgemeine EDV-Akzeptanzprobleme sieht er nicht, da sein Unternehmen sehr

technikorientiert ist, usabitlity darf nicht den gleichen Overhead bieten, wie etwa

der Transfer der jetzigen GP-Lösung von CASPJ-Notes

(21) Nein. Schwerpunkt sieht er bei der operativen Projektdurchführung: in der Do-

kumentation, Transparenz der bestehenden Daten, Anzeigemöglichkeiten von

z. B. Statusfortschritt und Vergleichen über die Zeit („Schnappschuß“)

(22) Dies würde er nicht einmal trennen - die Auswahlmöglichkeiten sollten die

gleichen sein

(23) MIS: Forrest&Trees wir bald abgelöst durch ein OLAP-Tool. Hier läuft gerade

ein interner Auswahlprozeß. Zielgruppe: oberes und Mittleres Management

C Anlagen Seite 102

Interview-Nr.: 6

Branche: DV-Dienstleister Industrie

(1) Organisation-Datenverarbeitung, Organisationsentwicklung

(2) sehr zerklustert: Gruppe als Konzerntochter: ca. 28000,

(3) nein, mittelfristig konzernweit vorgesehen

(4) hostbasiertes System im Rahmen einer Warenwirtschafts-Anwendung, soll dann

durch Notes abgelöst werden

(5) nein, bei konzernweiter Einführung von Notes wird dies angestrebt

(6) Divisional und dann funktionsorientiert

(7) ca. 80% und zunehmend

(8) es ist ein zunehmender Evaluationsvorgang in Richtung Management by Projects

erkennbar

(9) selbst 3

(10) zwischen 20 und 1

(11) ca. 250 000 - 500 000 DM

(12) nutzt Excel, bzw. papierbasierte Portfoliomatrizen. Dazu existieren Prioritäten

strategischer Art: Realisierbarkeit vs. Leistungspotential, ein unternehmensweiter

Standard existiert nicht.

(13) Multiprojektmanagement: grobe Anordnung der Projekte zur besseren

Durchschaubarkeit von Abhängigkeiten gegenüber Standardlösungen.

Single Project Management: eine bessere zeitliche Anordnung von

Ressourcenauslastungen, Fortschrittsanzeige und bessere Strukturierung

(14) - einfach, auf Buttonklick, dauert bisher zu lange und ist umständlich

- flexibel bezüglich Projektauswahl, Detaillierungsgrad

- übersichtlich

(15) Kosten spielen eine untergeordnete Rolle, Ressourcen nur dann wenn sehr

detailliert geplant wurde, was nicht immer wünschenswert ist

C Anlagen Seite 103

(16) Gantt-Charts, Histogramme, Ressourcenauslastungen, weniger interessant sind

Netzpläne

(17) grundsätzlich schon, ggf. einschränkbar, macht nur ganzheitlicher Ansatz Sinn

(18) dies wird vom Management sogar ausdrücklich gefordert

(19) ein selbständiges Nutzen des Systems - das Management ist da sehr aufge-

schlossen -> vorausgesetzt die Punkte aus (14) bezüglich der Usability sind

erfüllt, d. h. es ist keine "Schikane" ein solches System zu nutzen

(20) siehe 19

(21) durchaus möglich, eine entsprechende Infrastruktur (Notes-Anbindung)

vorausgesetzt. Denkbar wäre die Nutzung in Projektsteuerungskreisrunden

(22) eine andere Sicht ggf.: z. B. das Durchführen von Trendanalysen oder die Res-

sourcenbelastung für Fertigungsleitstände

(23) ist momentan in der Realisierung befindlich: verschiedene Systeme werden dabei

über ein Information Warehouse (durch ein Backend-Tool) gekoppelt

C Anlagen Seite 104

Interview-Nr.: 7

Branche: Automobilzulieferer

(1) Controlling

(2) 800

(3) ja

(4) Lotus Notes, aus Sicherheitsgründen (Netzwerkausfall) fährt man zweigleisig und

nutzt noch MS-Exchange

(5) ja durchgängig

(6) Projektmanagement

(7) 99%

(8) geht sehr stark in diese Richtung

(9) bei der Definition nach DIN er selbst ca. 10

(10) 40

(11) bis 2 Mio. DM

(12) nutzt GRANEDA Light zur Erstellung von Projektstrukturplänen, Netzplänen

und Balkendiagrammen, unternehmensweite Standards existieren nicht

(13) übersichtlichere Projektdurchführung durch Möglichkeit der Visualisierung von

Terminen, Kapazitäten und Kosten auf 1 - max. 2 A4 Blättern als anschauliche

Grafiken

(14) - einfach erstellbar

- sollte für den Notes Nutzer zur Verfügung stehen/erstellbar sein

(15) für Kosten und Kapazitäten existieren bereits gute Hilfsmittel: interessant wären.

Der kritische Punkt ist: sind die Termine haltbar oder nicht?

(16) Die Funktionalität, die CA bietet in verfeinerter Form

(17) vollen Zugriff - dies ist ein Muß. Die Mitarbeiter in diesem Unternehmen sollen

Verantwortung übernehmen. Dazu benötigen sie eine entsprechende Transparenz.

Es handelt sich ja um MITarbeiter.

C Anlagen Seite 105

(18) wenn man ihnen gewisse vordefinierte Übersichten zur Verfügung stellt schon

(19) k. A.

(20) es existieren keine Akzeptanzprobleme, techn. sehr fortgeschritten - man sollte

eine Lösung entsprechend vorkonfigurieren können

(21) durchaus. Zum Beispiel für Entscheidungen über "Go" bzw. "No Go" von Pro-

jekten oder Auswirkungsprognosen für mögliche Probleme

(22) k. A.

(23) solche Lösungen existieren bisher noch nicht

C Anlagen Seite 106

Interview-Nr.: 8

Branche: DV-Bankdiensleistungen

(1) Planung & Controlling

(2) ca. 500

(3) durchgängig

(4) Notes

(5) durchgängig

(6) Mischung aus Matrixorganisation und PM

(7) 100%. Dies hat auf jeden Fall zugenommen: hatte früher mehr Querschnitts-

funktionen

(8) absolut wachsend in Richtung Management by Projects

(9) ca. 50-60

(10) ca. 200

(11) In der Summe: 200 * 8,3 Mann-Monate + 8 Mio. externe Budgets

(12) ja: Notes Reporter, Lotus SmartSuite-Familie

Soll-Ist-Vergleiche, Budgetentwicklungen, Ressourcenauslastungs-Prognosen

Problem: nicht endbenutzerfreundliche Bedienung, insbesondere beim Export der

Daten (View exportieren). Eine leichte Übernahme in externe Applikationen

(z. B. Präsentationsprogramme, Tabellenkalkulationen) ist regelmäßig nur schwer

möglich, vor allem für Mehrprojektplanung reichen Standardlösungen nicht

(13) aktiveres Controlling: Aufbauen eines Ampelsystems, um rechtzeitig Hindernisse

erkennen zu können, um vorausschauend Krisen/Fehlentscheidungen vermeiden

zu können

(14) - dialogfähig

- präsentationsfähig für Entscheider mit Budgetverantwortung aus dem Mana-

gement

(15) ja, insbesondere die Termine, da die Aufgaben extrem termingebunden sind

C Anlagen Seite 107

(16) Vernetzung von Terminen, denn das momentane Problem besteht darin von ein-

zelnen Projektleitern Committments zu einzelnen Releaseterminen zu bekommen,

Darstellungen, um ein effizienteres Multiprojektmanagement betreiben zu können

als bisher

(17) ja: um seine Rolle im Projekt zu sehen, Risiken zu erkennen und eine höhere

Transparenz zu erlangen

(18) bis zum Mittleren Management ist eine persönliche Nutzung denkbar, ab dann

wird es schwierig: mangelnde Akzeptanz durch zu wenig Vertrauen in Technik

(19) keine Delegation, wenn abrufbare Standardberichte existieren, die der betreffende

Manager selber mitgestaltet hat - der Entscheider will auf einen Blick Antworten,

mit denen er sich (eben durch eine solche Mitgestaltung) identifizieren kann

(20) vgl. 19

(21) im Sinne einer Vorschau, What-If-Szenarien

(22) k. A.

(23) nein

C Anlagen Seite 108

Interview-Nr.: 9

Branche: DV-Bankdienstleister

(1) Projektleiter: Einführung GP

(2) 123

(3) ja

(4) Notes

(5) ja durchgängig

(6) funktional

(7) nicht verändert: 70-80%

(8) sehr hohen Stellenwert. Die Bedeutung ist zunehmend und geht ganz klar in

Richtung Management by Projects

(9) er ca. 2-3

(10) max. 100

(11) zwischen mehreren 100 Tsd. und einstelligen Millionenbeträge

(12) nur das was MSP bietet

(13) verspricht sich besondere Vorteile für die bessere Kapazitätenplanung

(14) - einfach

- Multiprojekting-fähig

- optisch übersichtlich

- Visualisierung von Ressourcen und Terminen sollte möglich sein

(15) Bereich Ressourcen, denn dort existieren aus seiner Sicht die meisten Probleme,

da Standardprogramme wie Microsoft Project hier nur unbefriedigende Ansätze

bieten insbes. bei der Mehrprojektplanung, auch von kleineren Projekten den

sogenannten "Kleinaufträgen"

(16) farbige Balken, Torten: Auslastungsgrad, Grenzlinie um frühzeitig Kapazitäts-

engpässe erkennen zu können, ggf. Ampeleffekt für Farben, über flexible Zeit-

räume darstellen können

C Anlagen Seite 109

(17) Projektmitarbeiter sollte eigene Einplanung sehen können um mehr Transparenz

und Gesamtverständnis zu erlangen und sich selber besser im Geschehen ein-

ordnen zu können

(18) diese Anforderung ist von Seiten des Managements ganz klar gegeben; Nutzung

z. B. im Rahmen eines Gremiums, daß neue Projekte genehmigt: einem Kreis aus

Abteilungs- und Bereichsleitern und der Geschäftsführung.

(19) Assistenten o. ä. existieren nicht. ggf. könnte er sich vorstellen, daß es Be-

rührungsängste gibt, daher: je einfacher das System ist, desto besser

(20) eigentlich nicht, im Einzelfall eventuell - eher gering

(21) vgl. 18, um allgemein eine bessere Globalübersicht zu erhalten

(22) Selektion als auch Aggregation

(23) SAP-EIS und SAP-basierte Eigenlösungen, im Bereich Quality Management auch

unter Lotus Notes

C Anlagen Seite 110

Interview-Nr.: 10

Branche: Einzelhandels-(Konzern)Holding mit den Geschäftsbereichen: Parfüme-

rie/Schmuck/Mode/Sport/Drogerien/Bücher/Süßwaren/Cafés

(1) Bereich Kundenbetreuung/Consulting. Dieser Bereich managet alle internen Pro-

jekte.

(2) die Holding inklusive der Filialen ca. 16 000, die betreffende Tochter: ca. 60

(3) nein noch nicht, dies ist aber in Planung, soll dann flächendeckend zum E-Mailing

verwendet werden

(4) sehr begrenzt: Microsoft Mail

(5) nein überhaupt nicht

(6) in der gesamten Holding ist dies sehr unterschiedlich, für das interviewte Unter-

nehmen: matrixorientiert

(7) etwa 80% dies ist in der Vergangenheit stark angestiegen und wird auch noch

weiter steigen

(8) Es ist ganz klar zu erkennen, das dies in die Richtung "Management by Projects"

geht

(9) etwa 25-30 (hierzu zählen auch sehr kleine, sogen. "Beratungsprojekte")

(10) ca. 35

(11) kleinere Beratungsprojekte ca. DM 1000.- die großen bis einstellige Millionen-

beträge

(12) Zur Visualisierung wird die gesamte Produktpalette von Microsoft genutzt - je

nach Anforderung (z. B. bei Präsentationen die Charting-Möglichkeiten von Po-

werpoint). Die Visualisierungsaufgaben sind sehr stark vom Einzelfall bzw. Be-

darf abhängig. Ein Standard existiert nicht

(13) bessere Auswertungen im Hinblick auf Multiprojekting, Ressourcenauslastungen

(14) - Performance

- Möglichkeiten des Ausdrucks (absolutes Muß)

- einfache Handhabung

C Anlagen Seite 111

(15) Da die interviewte Tochter der Holding nicht gewinnorientiert arbeitet eher im

Hinblick Zeit & Ressourcen

(16) Gesamtübersicht über alle Projekte, ob im "roten Bereich"

(17) steuerbares Rechtemanagement - z. B.: ein abgestuftes Konzept à la:

Projektmitarbeiter - technischer Projektleiter - Projektleiter

(18) überhaupt nicht! In seinem Unternehmen erwarten die Entscheider vorgefertigte

Ausarbeitungen und wollen sich in keinster Weise in die Materie hineinversetzen

(19) vgl. 18

(20) vgl. 18

(21) Ja. Aber eben auch nur in Hinblick auf die Stützung von Ausarbeitungen Ihrer

Assistenten - also keine flexible Nutzung bei Bedarf

(22) k. A.

(23) Informationssysteme die Abverkäufe anzeigen und Umsatzdatenentwicklungen

prognostizieren, ferner eine Lösung für den Bereich Finanzbuchhaltung, alles von

Oracle

C Anlagen Seite 112

Interview-Nr.: 11

Branche: Software

(1) Entwicklungsabteilung, dort Projektleiter

(2) Diese Tochter der Holding hat z. Zt. 204 Mitarbeiter

(3) ja unternehmensweit

(4) Lotus Notes E-Mailing

(5) bei der Geschäftsführung nicht direkt, sondern Zugriff über die jeweiligen Sekre-

tariate

(6) funktional und dezentral, gemischt mit etwas Projektorganisation

(7) nahezu 100%

(8) es existiert keine durchgängige Unternehmensphilosophie, in eigener Abteilung

(ca. 60 Mitarbeiter) wird aber nur projektorientiert gearbeitet

(9) er: 1

(10) 211

(11) dieses hat DM 4 Mio.

(12) Nein. Die Funktionalitäten von CA-SuperProject reichen aus.

(13) Für den Projektleiter wäre es einfacher und effizienter, Zusammenfassungen für

das Management zusammenzustellen, ferner zur besseren operativen Projekt-

durchführung (Projektcontrolling)

(14) - sehr wichtig: einfach bedienbar. Strandardlösungen wie CA-SuperProject lassen

in der Benutzerfreundlichkeit zu wünschen übrig und sind schwer erlernbar

- sehr wichtig: einfach konfigurierbar

- Performance ist egal

(15) Termine und Kosten gleich wichtig - Ressourcenvisualisierung relativ uninteres-

sant - erschlägt man ja mit Kosten

(16) Auf der Projektebene Plan-Zahlen mit Ist-Zahlen vergleichen zu können - dies

gekoppelt mit einer Meilenstein-Trendanalyse wäre sehr sinnvoll

C Anlagen Seite 113

(17) wenig sinnvoll - sie brauchen keinen Zugriff, da sie es ohnehin nicht nut-

zen/annehmen würden

(18) es herrschen dezentrale Strukturen, die Informationen an das Management wer-

den auf max. 2 Seiten papierbasiert "nach oben" gereicht - das Management

selbst würde ein solches System nicht nutzen

(19) Hier wird aus Erfahrung eine Delegation stattfinden vgl. 18

(20) vgl. 19

(21) Sehr gut: für Projektleiter und Multiprojektleiter wäre es die Chance alte Struk-

turen aufzubrechen und die benötigten Informationen elektronisch zu kommuni-

zieren anstatt aufwendig papierbasiert

(22) grundsätzlich nicht - das Management benötigt aggregierte Daten

(23) Nein. Gar keine.

C Anlagen Seite 114

Interview-Nr.: 12

Branche: Unterhaltungselektronik

(1) IT, "Systementwicklung und Operations"

(2) weltweit ohne Aussage, Deutschland Halbleiter-Bereich ca. 400

(3) absolut - man hat sich für Notes als strategische Plattform entschieden

(4) ja: MS-Exchange. Mailing von Notes nutzt man nicht.

(5) ja allerdings nicht immer - teilw. Sekretariate oder unregelmäßig

(6) Mischform: zunächst divisional (in zwei Vertriebsdivisionen gegliedert), dann

jew. funktionsorientiert

(7) grundsätzlich fast zu 100% - allerdings Zeit einzelne Projekte zu leiten hat er

allerdings nicht mehr - er versteht sich als Multiprojektleiter im Sinne eines Ma-

nagers

(8) Projektmanagement steckt noch in den Kinderschuhen, softwaregestüztes erst

recht, seine Abteilung ist mit GP da Vorreiter. Eine einheitliche Unterneh-

mensphilosophie existiert erst recht nicht "hier kocht jeder sein eigenes

Süppchen"

(9) 7-8 als Multiprojektleiter

(10) alle IT-Mitarbeiter (ca. 30) plus bedarfsgerecht Personal aus den jew. Fachab-

teilungen

(11) weniger nach Budgetgesichtspunkten einordnenbar: eher i. S. von Mann-Tagen:

hier sind es so zwischen 100 und 300 pro Projekt

(12) nutzt MS-Excel zur individuelle Erstellung von Grafiken je nach Anforderung.

Unternehmensweite Vorgaben existieren dazu nicht

(13) Scheint mögliche Lösung um eine höhere Akzeptanz beim höheren Management

erreichen zu können, aber auch um sich vor anderen Abteilungen zu repräsentie-

ren, Sensibilisierung für das Topmanagement, um argumentativ eine breitere

Masse ansprechen zu können, als nur die Leute, die ohnehin schon in den Projek-

ten drin stecken und die Probleme einordnen können

C Anlagen Seite 115

(14) - aussagekräftig

- alles muß gebündelt auf einen Screen passen - der Manager will nicht scrollen

- Daten sollen vergleichbar sein

- wenig Arbeit - aber viel Information d. h. mit wenigen Mausklicks erreichbar

(15) das hängt vom Fokus des jeweiligen Projektes ab. Das kann er nicht für alle

Projekte pauschalisieren, alle 3 Punkte sind wichtig/interessant, aber das ist von

Fall zu Fall unterschiedlich zu prioritisieren

(16) - z. B. Zeitachse und Anzahl momentan im Einsatz befindlicher Ressourcen

- z. B. eine Budgetübersicht

(17) bei den Projektmitarbeitern könnte man sich darüber streiten, ob dies Sinn macht

- prinzipiell ist sicher nichts dagegen einzuwenden, könnte so auch Informations-

tool für die Mitarbeiter selbst sein, z. B. um Meetings zu reduzieren und als all-

gemeiner Informationspool

(18) in anderen Bereichen (Marketing/Sales) gibt es dies schon und wird auch rege

genutzt; die Mitarbeiter müssen nur entsprechend sensibilisiert werden

(19) als typisches japanisches (und auch japanisch geführtes) Unternehmen ist es

üblich, daß die japanischen Führungskräfte an ihre europäischen Assistenten etc.

delegieren

(20) generell nicht; das Unternehmen ist sehr modern und modernen Technologien

sehr aufgeschlossen und auf einem sehr hohen Niveau, es existieren diesbezüglich

keine Hemmschwellen

(21) zur mittelfristigen Projektplanung, zur Planung von Budgetgesichtspunkten

(22) es ist nicht sinnvoll das der Manager Zugriff auf jede Ressource hat - er will stark

aggregierte/gebündelte Informationen

(23) AS/400 characterorientierte Systeme aus der Warenwirtschaft, online Reporting

ohne grafische Visualisierung. Ferner existiert ein EIS, dies kann strategisch

wichtige Daten über feinere Produkt- und Kundenstrukturen visuell darstellen:

OLAP. Dies ermöglicht einen Drill-Down z. B. geographisch, nach

Tochterunternehmen, Umsätzen/Abweichungen, ferner Essbase von Arbor

Software mit Visualisierungsshells von Comshare

C Anlagen Seite 116

Interview-Nr.: 13

Branche: DV-Bankdiensleister

(1) Zentrale Dienste und Entwicklungsunterstützung, Verantwortungsbereich Metho-

den und Verfahren als freier Mitarbeiter

(2) 150

(3) ja - durchgängig

(4) Notes Mailing-Funktionalitäten

(5) ja, durchgängig

(6) vom Projektmanagement leider noch weit entfernt. Die Organisationsstruktur ist

eine relativ flache starre Hierarchie: funktionalorientiert

(7) ca. 99% - keine Veränderung

(8) Wird momentan noch als Werkzeug gesehen. Letztere Denkweise befindet sich

aber "im Aufbau"

(9) er selbst: 3

(10) 2/3/4

(11) bis max. 2 Mio. DM

(12) Möglichkeiten von Microsoft Project/CA-SuperProject zur Visualisierung rei-

chen: insbes. Netzpläne.

Die Nutzung von anderen Werkzeugen ist absolute Ausnahme- ein Standard

existiert nicht

(13) gar keine für den einzelnen Projektleiter, allerdings für das Management auf

höherer Ebene, insbesondere beim Projektcontrolling

(14) - schnell

- Farbeinstellungen änderbar

- Druckbar

- Nutzbar für Präsentationen (Freelance-/Powerpoint-Import)

- flexibel konfigurierbar

- nicht mit Informationen überfrachtet

C Anlagen Seite 117

(15) Kosten sind in seinem Umfeld eher unwichtig: Schwerpunkt bei Ressourcen und

Terminen

(16) Hat keine konkreten Vorstellungen

(17) Keinen. Dies macht seiner Ansicht keinen Sinn. Sie kennen ihre Aufgaben - das

muß reichen

(18) In seinem Unternehmen sehr gut - genau wenn dieses "auf Knopfdruck"-

Paradigma realisiert ist dann schon -

(19) Es darf keine Handlingprobleme geben, es muß eine vordefinierte Umgebung zur

Verfügung stellen, es darf keine „Fummelei“ sein, man muß die relevanten Pro-

jekte flexibel auswählen können und vordefinierte Auswertungen fahren können

(20) Nein, alle Mitarbeiter verfügen über entsprechende Qualifikationen

(21) ja, z. B. als Überzeugungshilfe in Präsentation, zur Unterstützung bei der Argu-

mentation und Kommunikation, beim Projektreview und zur Unterstützung bei

internen Abstimmungen

(22) nein, es sollte möglich sein den Zugriff über entsprechende Security-

Mechanismen zu steuern

(23) keine großen Systeme: existierten temporär vordefinierte Auswertungen mit

Excel für andere Bereiche - dies wurde aber wieder verworfen

C Anlagen Seite 118

C.2.4 Auswertungen

Tendenzielle Aussage Anzahl Nennungen

kein Trend erkennbar 4

Trend erkennbar, bzw. bereits etabliert 8

keine Aussage 1

Tab. C.2.4-1: Zunehmende Bedeutung eines „Management by Projects“


ausreichend 2

mangelhaft 7

keine Aussage 4

Tab. C.2.4-2: Kommerziell erhältliche PM-Werkzeuge: FähigkeitMultiprojektmanagement-Informationen zu visualisieren


zu komplex 6

keine Aussage 7

Tab. C.2.4-3: Kommerziell erhältliche PM-Werkzeuge: Bedienbarkeit allgemein


im Einsatz innerhalb der Groupware-Plattform LotusNotes

7

bereits im Einsatz (andere E-Mailing-Clients) 4

flächendeckende Einführung mittelfristig geplant 1

nicht im flächendeckenden Einsatz und auch nicht geplant 1

Tab. C.2.4-4: Flächendeckender Einsatz von E-Mailing


bereits im Einsatz 7

Einführung kurz- oder mittelfristig geplant 1

nicht im Einsatz 4

keine Aussage 1

Tab. C.2.4-5: Einsatz von Entscheidungsunterstützungssystemen

C Anlagen Seite 119


nur exklusiver Nutzung durch Entscheider 3

generell offene Nutzung durch alle Mitarbeiter 3

im Zugriff skalierbare Lösung 6

keine Aussage 1

Tab. C.2.4-6: Nutzung eines Frontend-Systems zur Visualisierung von Projektdatenzur Entscheidungsunterstützung auch für Projektmitarbeiter


Kosten 0

Ressourcen (Aufwand) 1

Termine 4

fallabhängig bzw. keine Präferenz eines einzigenParameters

7

keine Aussage 1

Tab. C.2.4-7: Präferierte Parameter zur Visualisierung von Projektinformationen

C Anlagen Seite 120

C.3 Anforderungen an Hard- und Software

minimal:

IBM kompatibler PC (80486 oder höher)

Windows 95 oder Windows NT Workstation (Version 3.51 oder höher)

16 MB RAM

Standard VGA (640*480) 256 Farben

Lotus Notes R 4.5 32bit

Lotus Components 1.1

PAVONE GroupProject 2.11a

empfohlen:

Intel Pentium Prozessor

32 MB RAM

SVGA (800*600) oder besser

C.4 Attachments

C.4.1 Applikation: GP DSS

Die Applikation befindet sich auf der Diskette am Buchrücken (vgl. Anhang C.5).

C.4.2 Freelance Präsentation

Dieses Kapitel befindet sich nur in der elektronischen Version.

C.4.3 Technische Dokumentation

Dieses Kapitel findet sich aus Platz- und Übersichtlichkeitsgründen nur in der

elektronischen Version.

C Anlagen Seite 121

C.5 Installationsanweisung

Das auf der beigefügten Diskette enthaltene Archiv gp_dss.zip ist mit einem geeigneten

Werkzeug (z. B. pkzip.exe) zu extrahieren. Die entstehende Datei gp_dss.nsf liegt im

Lotus Notes 4.5-Format vor und kann in Lotus Notes über Datei/Datenbank/Öffnen

bzw. File/Database/Open geöffnet werden.

Die in der Datenbank enthaltenen Profildokumente sind in der so vorliegenden Form

nicht direkt als Report ausführbar, da die notwendigen Projektedatenbanken aus lizenz-

rechtlichen Gründen nicht im Anhang vorliegen und eine spezifische Verzeichnisstruktur

vorausgesetzt wird. Zur Generierung eigener Reportdokumente müssen daher neue

Profildokumente erstellt oder die vorhandenen modifiziert werden.

Vorbedingungen

Bitte sorgen Sie zunächst für die in Anhang C.3 aufgeführte soft- und hardware-

technische Infrastruktur.

Zur sinnvollen operativen Nutzung bedarf es des Zugriffs auf eine entsprechend mit

Projekten und Ressourcen gefüllte GroupProject-Infrastruktur (Release 2.11a).

Zu Demonstrationszwecken reichen die in der Datenbank enthaltenen Dokumente aus.

Ein Drill-Down und die Neugenerierung von Reportdokumenten ist dabei mit den ent-

haltenen Beispieldokumenten aufgrund der mangelnden Projektedatenbanken allerdings

nicht möglich.

Erstellung neuer Profildokumente

Nach dem Öffnen der Anwendung „GP DSS“ verzweigen Sie bitte vom Hauptnavigator

in die Ansicht Profile und erstellen dort über „Profil erstellen (neu)“ im Navigator der

Ansicht ein neues Profildokument. Sie sehen dann die in Abb. 6.1.1.1-1 dargestellte

Roadmap. Spezifizieren Sie nun sukzessive Ihre abfragespezifischen Parameter. Folgen

Sie dabei der durch die roten Pfeile implizierten Reihenfolge. Neben den Schaltflächen

für die einzelnen Parametergruppen zeigt ein Icon den jeweiligen Status an: ein Frage-

zeichen steht dabei für eine unvollständige Parametrisierung innerhalb der jeweiligen

Gruppe, ein grünes Häkchen für eine vollständige. Wählen Sie über die Schaltfläche

„Nutzerkreis...“ die Einstellung „Multiprojektmanagement“, um in den Folgedialogen

eine maximale Auswahlmöglichkeit zu erhalten (entsprechende Zugriffsrechte auf die

Projekte- und Ressourcendatenbanken vorausgesetzt).

C Anlagen Seite 122

Ist ein Profil vollständig spezifiziert (d. h. neben sämtlichen Schaltflächen innerhalb der

Roadmap erscheint ein grünes Häkchen), erscheint in der Aktionsschaltflächenleiste im

oberen Bildschirmbereich die Aktionsschaltfläche „Speichern und Generieren“. Geben

Sie einen sinnvollen Namen für ihr neues Profildokument im dazu vorgesehenen Feld

oberhalb der Roadmap an und betätigen Sie diese Icon: ein neues Reportdokument wird

vom System erzeugt. Alternativ dazu können Sie das Profildokument auch speichern und

verlassen und zu einem späteren Zeitpunkt aus der Ansicht „Profile“ als Report

ausführen, indem Sie das Dokument dort mit dem Markierungsbalken anwählen und die

Aktionsschaltfläche „Profil als Report ausführen“ betätigen.

Erstellen eines Reportdokumentes

Betätigen Sie in einem solcherart erstellten Reportdokument die Schaltfläche

„Ausführen“ und die auf dem Profil basierenden Abfrage wird durchgeführt. Sofern

gültige Projektinformationen identifiziert werden konnten, werden sie gemäß Ihrer Vor-

gaben dargestellt.

Modifikation von Report-Grafiken

Sie können die Darstellung der entstandenen Chart modifizieren (durch eine Anwen-

dungsfehler in der Version 1.1 der Components findet keine automatische Größen-

optimierung statt), indem Sie sie z. B. mit der Maus größer ziehen oder aber konkrete

Inhalte über Doppelklick auf das entsprechende Element (z. B. die Legende) die jewei-

lige Infobox aktivieren und editieren. Über die kontextsensitive Smarticonleiste steht bei

Aktivierung des Charts der bedingte Wechsel zu anderen Darstellungsarten zur Verfü-

gung (z. B. von einem 2D-Diagramm zu einem 3D-Diagramm). Bei 3D-Darstellungen

besteht zusätzlich die Möglichkeit, diese durch Gedrückthalten der Control- bzw. Strg-

Taste und Mausinteraktion um die eigene Achse rotieren zu lassen und so die Darstel-

lungsperspektive zu verändern.

Hinweis

Bei Durchführung des in Kapitel 6.2.3 beschriebenen Drill-Downs (Szenario 5) kann es,

bedingt durch einen Anwendungsfehler in Notes R. 4.5, zu Systemabstürzen kommen.

Dies läßt sich im Sinne eines Workarounds umgehen, indem man das Reportdokument

nach jeder Ebene speichert und schließt (und es anschließend wieder im Editiermodus

öffnet um weiter zu navigieren).