Das Ziel der vorliegenden Masterarbeit war das erarbeitete Verfahren zum Aufbau eines Soll-Modells für die Erstellung der Projektdokumentation zu beschreiben. Als Vorbereitung für das Verfahren wurde ein Konzept aufgestellt.
Das Konzept definiert das Ziel und folgende Schritten des Verfahrens.
Zuerst wurde ein allgemeines Strukturmodell der Projektdokumentation, auf Basis von branchenspezifischen Normen aufgebaut. In dem nächsten Schritt wurde die Ist-Situation auf der Grundlage eines abgeschlossenen Projektes modelliert und analysiert. Das Ziel der Analyse war Fehler aufzudecken und zu korrigieren sowie die für den Geschäftszweigspezifischen generischen Dokumente zu identifizieren. Die identifizierten Dokumente wurden dem allgemeinen Strukturmodell hinzugefügt. Die im Soll-Modell dargestellte Reihenfolge für Dokumentenerstellung wurde mit Hilfe der Geschäftsprozessmodellierung und -analyse überprüft. Das erarbeitete Soll-Modell hat zum Ziel den Ausgangspunkt für die Erstellung von Angeboten und die Planung der Projektdokumentation zu bilden.
Die Ergebnisse der vorliegenden Arbeit können als Grundlage für die Fehlerbeseitigung und die Qualitätsverbesserung in den Projektmanagement- und Systementwicklungsprozessen bei dem Geschäftszweig verwendet werden.
Inhaltsverzeichnis
Abkürzungsverzeichnis
Abbildungsverzeichnis
Tabellenverzeichnis
Kurzfassung
Abstract
1. Einführung.
1.1 Vorstellung des Unternehmensbereiches Siemens Industry Mobility
1.2 Problemstellung
1.3 Ziel der Masterarbeit.
1.4 Struktur der Masterarbeit.
2. Theoretischen Grundlagen
2.1 Geschäftsprozesse
2.1.1 Definition der Geschäftsprozesse
2.2 Projektmanagement.
2.2.1 Begriffe und Definitionen.
2.2.2 Projektplanung.
2.3 Technische Systeme als Gegenstand technischer 19 Großprojekte
2.3.1 Definition des System- und Modellbegriffs.
2.3.2 Systementwicklung anhand des V-Modells
2.4 Projektdokumentation
2.4.1 Die Rolle der Projektdokumentation im Projektmanagement
2.4.2 Projektdokumentation als Produkt des Systementwicklungsprozesses
2.5 Geschäftsprozessmodellierung und -analyse
2.5.1 Ist-Zustand vs. Ideal-Zustand, Soll-Modell
2.5.2 Modellierung der Geschäftsprozesse
2.5.3 Ziel der Geschäftsprozessanalyse
2.5.4 Strukturerfassung der Geschäftsprozesse anhand der Netzplantechnik
2.5.5 Anordnungsbeziehungen für Geschäftsprozesse
3. Projektmanagement bei Siemens I MO RA.
3.1 Grundsätze des Projektmanagements bei Siemens I MO
3.2 Einordnung des Projektmanagements in die Geschäftsprozesslandschaft der Siemens I MO RA MLI
3.2.1 Vorstellung des Geschäftsprozesses PM@TS
3.3 Projektdokumentation bei Siemens I MO
3.4 Norm- und Regelwerke der Projektdokumentation eisenbahnsignaltechnischer Großprojekte bei Siemens TS RA MLI
3.4.1 RAMS - Systemlebenszyklus
3.4.2 Sicherheitslebenszyklus
4. Verfahrensschritte zum Aufbau einer generischen Dokumentenstruktur
4.1 Vorstellung des zugrunde liegenden Projektes „HSL Zuid“
4.2 Konzept des Verfahrens
4.3 Datenaufbereitung.
4.3.1 Beschreibung des Programms für die Datenaufbereitung
4.4 Ergebnis der Datenaufbereitung - Darstellung der Projektdokumentenstruktur anhand eines IST-Baumes
4.5 Analyse der IST-Situation
4.5.1 Fehlerbeschreibung und deren Ursachen
4.6 Aufbau des Soll-Modells
4.7 Rolle des Soll-Modells in der Dokumentenplanung für MLI Pojekte
5. Zusammenfassung und Ausblick
Quellenverzeichnis
Abkürzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
Abbildungsverzeichnis
Abb. 1: Projekt, Prozess und Produkt
Abb. 2: Phasen des Projektlebenszyklusses
Abb. 3: Projektphasen technischer Großprojekte
Abb. 4: Projektstrukturplan
Abb. 5: Beispiel für einen Standardprojektstrukturplan
Abb. 6: Systemhierarchie
Abb. 7: Das V-Modell für die Systementwicklung
Abb. 8: Baum-Strukturelemente
Abb. 9: Mögliche Abhängigkeitsbeziehungen zwischen Produkten
Abb. 10: Strukturelle Produktabhängigkeiten
Abb. 11: Prozesslandkarte eines Unternehmensprozesses
Abb. 12: Kontextbetrachtung für Systemabgrenzung der GP
Abb. 13: Geschäftsprozess als System
Abb. 14: Hierarchische Prozessstrukturierung
Abb. 15: Grundstruktur eines Vorgangsknotennetzplanes
Abb. 16: Mögliche Anordnungsbeziehungen für Geschäftsprozesse
Abb. 17: PM@TS -Prozessmodell
Abb. 18: Prozessmodell für PM@TS RA
Abb. 19: PM-Prozess bei Siemens TS RA MLI
Abb. 20: MLI Projekttypen
Abb. 21: Projekt-Ablagestruktur für die Projektdokumentation bei I MO
Abb. 22: Lebenszyklus für Bahnanwendungen
Abb. 23: V-Darstellung des SLZ für Bahnanwendungen
Abb. 24: Objektstrukturplan für das Projekt HSL Zuid
Abb. 25: Ablagestruktur der HSL Zuid Projektdokumentation
Abb. 26: Klassendiagramm für das datenaufbereitende Java-Programm
Abb. 27: Beispiel für einen logischen Fehler - Selbstreferenz
Abb. 28: Beispiel für Referenzzyklen
Abb. 29: Unmittelbare Referenzdokumente der System-Sicherheitsnachweis
Abb. 30:Erlaubte Richtung für das Referenzieren
Abb. 31: Knotengestaltung für die Dokumentenklassifizierung
Abb. 32: Darstellung des Systementwicklungsprozesses mit Netzplantechnik
Tabellenverzeichnis
Tab. 1: Überblick über die Aktivitätspläne
Tab. 2: Dokumente für das Sicherheitsmanagement
Tab. 3: Beispiel für den Aufbau einer Baumstruktur mit Graphviz
Tab. 4: Methode für Ermittlung der Knotenbenennung
Tab. 5: Überblick über formale und logische Fehler im IST-Baum
Tab. 6: Fehlerkorrektur
Tab. 7: Projektdokumentenreihenfolge anhand Netzplan
Autorin: Emese Ildiko Komaromi
Titel der Masterarbeit: Ein Verfahren zum Aufbau einer optimierten und generischen Dokumentationsstruktur für eisenbahnsignaltechnische Großprojekte Erstellungsjahr: 2008
Studienfach: Geschäftsprozessmodellierung
Betreuer und Erstprüfer: Prof. Dr. Manfred Krause Betreuer und Zweitprüfer: Dipl.Ing. Jörn Schlichting
Kurzfassung
Das Ziel der vorliegenden Masterarbeit war das erarbeitete Verfahren zum Auf- bau eines Soll-Modells für die Erstellung der Projektdokumentation zu be- schreiben. Als Vorbereitung für das Verfahren wurde ein Konzept aufgestellt. Das Konzept definiert das Ziel und folgende Schritten des Verfahrens. Zuerst wurde ein allgemeines Strukturmodell der Projektdokumentation, auf Ba- sis von branchenspezifischen Normen aufgebaut. In dem nächsten Schritt wur- de die Ist-Situation auf der Grundlage eines abgeschlossenen Projektes model- liert und analysiert. Das Ziel der Analyse war Fehler aufzudecken und zu korri- gieren sowie die für den Geschäftszweig-spezifischen generischen Dokumente zu identifizieren. Die identifizierten Dokumente wurden dem allgemeinen Struk- turmodell hinzugefügt. Die im Soll-Modell dargestellte Reihenfolge für Doku- mentenerstellung wurde mit Hilfe der Geschäftsprozessmodellierung und - analyse überprüft. Das erarbeitete Soll-Modell hat zum Ziel den Ausgangspunkt für die Erstellung von Angeboten und die Planung der Projektdokumentation zu bilden.
Die Ergebnisse der vorliegenden Arbeit können als Grundlage für die Fehlerbeseitigung und die Qualitätsverbesserung in den Projektmanagement- und Systementwicklungsprozessen bei dem Geschäftszweig verwendet werden.
Abstract
The objective of this thesis is to describe the developed method to build a refer- ence model for the documentation structure of a technical project. As prepara- tion for the method a concept was developed. This concept defines the aim and steps of the method. First a general structure model with the aid of sectoral standards was built. After this the actual documentation structure of a finished project was modeled and analyzed. The aim of analysis was to find out the mis- takes, to adjust them and to identify the generic and project specific documents. The identified documents were added to the general structure model. The order of documents in the reference model was checked. For that purpose was ap- plied the methods of business process modeling and analysis.
This extended model will be the reference model for project documentation structure in the future.
The reference model will help at project bidding- and planning phase. The re- sults of this thesis can help to find the mistakes and to improve the quality of project management and system developing process in business division.
1. Einführung
Die Dokumentierung der geleisteten Arbeit ist für alle Beteiligten eines Projektes in gleichem Maße wichtig. Einerseits beschreibt sie den Gegenstand eines Kundenauftrags, d. h. das vom Kunden erwartete Produkt. Andererseits definiert sie die vom Unternehmen zu erbringende Leistung.
Darüber hinaus ist die Dokumentation eines abgeschlossenen Projektes eine Wissensbasis für neue Projekte. Die aus den vorangegangenen Projekten stammenden Informationen können als Basis für die Analyse und Abbildung der gegenwärtigen Vorgehensweisen und Fehlerquellen verwendet werden. Daraus kann das Unternehmen Ideen für Verbesserungen und Effizienzsteigerung in der Projektrealisierung gewinnen.
1.1 Vorstellung des Unternehmensbereiches Siemens In- dustry Mobility
Die Siemens Division Mobility (zuvor Transportation Systems) gehört zu dem Siemens Sector Industry der Siemens AG. Mobility ist ein Transport und Logistikanbieter der unterschiedlichen Verkehrssysteme anbietet. Das Mobility untergeordnete Geschäftsfeld Rail Automation (I MO RA) ist ein „innovativer Gesamtanbieter und Systemintegrator der Bahnindustrie“. Der bietet von der Beratung und Planung über die Realisierung und Service kompletter Bahnautomatisierungssysteme alles an (vgl. [Siem1]).
Die vorliegende Arbeit entstand in der Abteilung Projektmanagement & Bid Group (PM&B) des Geschäftszweiges Main Line International (MLI), der zum Geschäftsfeld Rail Automation gehört.
MLI ist für Marketing und Vertrieb von Bahnautomatisierungssystemen für den Fernverkehr im Ausland zuständig. Zu den Schwerpunkten der MLI PM&B Abteilung gehört u. a:
- Erstellung von wettbewerbsfähigen und qualitativ hochwertigen Angebo- ten,
- Erfolgreiche und planmäßige Projektabwicklung aller Projekte,
- Ausbau des Projektmanagements.
Darüber hinaus unterstützt die Abteilung PM&B die Vertriebe (Europa und außerhalb Europas) in der Projektakquisition.
1.2 Problemstellung
Die Abnahme der errichteten bahnsignaltechnischen Anlage ist stark vom Erfül- lungsgrad bestimmter Sicherheitsanforderungen abhängig. Neben den Funkti- onsanforderungen bilden die Sicherheitsanforderungen eine zentrale Rolle in der Projektplanungsphase. Als Nachweis der Erfüllung dieser Anforderungen dient die Projektdokumentation. Die Entwicklung, Errichtung und der Betrieb ei- ner bahnsignaltechnischen Anlage ist mit sehr großem technischem und wirt- schaftlichem Risiko verbunden. Um dieses Risiko möglichst gering zu halten, muss jeder Projekt- bzw. Arbeitsschritt sorgfältig geplant, ausgeführt und doku- mentiert werden. Darüber hinaus müssen die Dokumentengrundlagen für den Nachweis1 des sicheren Anlagenbetriebs erstellt werden. Zusätzlich hat die Projektleitung dem Auftragsgeber gegenüber Berichts- und Dokumentierungs- pflicht über den Projektfortschritt. Aus diesen Gründen erhöht sich der Doku- mentationsaufwand enorm und verursacht erhebliche Projektkosten. Diese Kos- ten sind mit dem Erstellungs-, Revisions- und Freigabeprozess von Dokumen- ten verbunden. Falls Dokumente erstellt, aber nicht mehr weiterverwendet wer- den, verursachen sie unnötige Projektausgaben. Um diese Projektausgaben möglichst gering zu halten, ergab sich folgendes Ziel: Informationsbereitstellung darüber, welche Dokumente in welchem Umfang unbedingt erstellt werden müssen. Diese Informationen sind für die Kostenrechnung bei der Angebotser- stellung sehr nützlich und wertvoll.
1.3 Ziel der Masterarbeit
Die MLI-Leitung setzte sich die Erarbeitung eines optimierten generischen Mo- dells für die Projektdokumentation als Ziel. Dies soll zukünftig als Maßstab für die Planung der Projektdokumentation im Siemens I MO RA Geschäftszweig MLI dienen. Das Modell soll auf das Geschäftsprofil von MLI zugeschnitten d.h. auf die Kerngeschäftsprozesse optimiert werden. Das Ziel ist demzufolge ein Geschäftsbereich spezifisches Soll-Modell für die Projektdokumentation zu er- stellen.
Die vorliegende Arbeit beschreibt das erarbeitete Verfahren für den Aufbau des Soll-Modells. Das Verfahren beinhaltet u. a die Vorbereitung der zum Soll- Modell benötigten Informationen. Solche Informationen sind die sogenannten generischen Dokumente, die in jedem Projekt erstellt werden müssen, ihre Be- ziehungen zueinander und die daraus entstehende Struktur der Projektdoku- mentation.
Für die Identifizierung der generischen Projektdokumente können branchenspezifischen Normen herangezogen werden. Sie geben eine Richtlinie für während des Projektes auszuführende Tätigkeiten und zu erstellende generische Dokumente vor. Die grafische Abbildung von diesen Dokumenten und ihre Beziehungen zueinander geben einen allgemeinen Überblick über die Struktur von branchenspezifischer Projektdokumentation.
Um aus diesem allgemeinen Strukturmodell ein Geschäftsbereich spezifisches Soll-Modell zu erstellen, werden weitere Informationen benötigt.
Der Schwerpunkt und die Art der Projektrealisierung ist vom Geschäftsprofil eines Geschäftsbereiches abhängig. Der Geschäftsbereich-spezifische Schwerpunkt wird auch in der Projektdokumentation identifizierbar. Die Grundlage für die Identifizierung dieser Dokumente bildet die grafische Abbildung der IstSituation in Form einer Baumstruktur. Sie wird aus der Dokumentenstruktur eines bereits abgeschlossenen MLI Projektes abgeleitet. Die Dokumentationsstruktur in diesem Projekt ergibt sich aus den Beziehungen zwischen einzelnen Dokumenten und von ihnen referenzierten Dokumenten.
Um Fehler in der Ist-Baumstruktur aufzudecken und weitere für Abbildung des MLI Geschäftsprofils wichtige generische Dokumente zu identifizieren, soll der Ist-Baum mit dem allgemeinen Strukturmodell verglichen werden. Auf Basis dieses Vergleichs kann die richtige Reihenfolge und Zeitpunkt der Dokumentenerstellung ermittelt werden. Daraus kann das auf das Geschäfts- profil des MLI optimierte, generische Soll-Modell für Projektdokumentation er- stellt werden.
1.4 Struktur der Masterarbeit
Die vorliegende Arbeit enthält vier Hauptkapitel, die weitere Unterkapitel bein- halten.
Das erste Kapitel gibt einen Überblick über die Problemstellung und das Ziel der Arbeit. Ferner stellt es die Organisationsstruktur des Siemens Mobility Divisions und die Abteilung, in der die vorliegende Arbeit erstellt wurde, vor.
Das zweite Kapitel beschreibt die theoretischen Grundlagen für die Masterar- beit. Im diesem Kapitel werden Themen wie Geschäftsprozesse, Projektmana- gement, Modellierung und Analyse der Geschäftsprozesse vorgestellt. Darüber hinaus wird das technische System als Gegenstand technischer Projekte näher erläutert. Ein weiteres Unterkapitel stellt die Rolle der Projektdokumentation im Projektmanagement und die zugehörige Dokumente als Produkte des System- entwicklungsprozesses vor.
Das dritte Kapitel gibt einen kurzen Überblick über das Projektmanagement bei Mobility Division. Darüber hinaus beschreibt das Kapitel die Einordnung in die Prozesslandkarte des Mobility Division des MLI-spezifischen Projektmanage- mentprozesses. Dieses Kapitel enthält im Weiteren einen Auszug der Richtlinie für die Erstellung von Projektdokumentationen bei Mobility Division. Das dritte Kapitel fasst die wichtigsten Aussagen aus den branchenspezifischen EN Normen zusammen, die maßgeblichen Einfluss auf die Inhalte und Struktur der Projektdokumente haben.
Das vierte Kapitel stellt das Verfahren zur Erstellung einer optimierten, generi schen Dokumentationsstruktur in Form eines Soll-Modells für eisenbahnsignaltechnische Großprojekte vor.
Darüber hinaus beschreibt das Kapitel die Rolle und die entstandene Vorteile des erarbeiteten Soll-Modells für die zukünftige Planung der Projektdokumentation bei MLI.
2. Theoretischen Grundlagen
Dieses Kapitel fasst für die vorliegende Arbeit wichtige theoretische Grundlagen zusammen. Dieses Kapitel baut sich auf zwei Themenscherpunkte der Wirt- schaftsinformatik, nämlich die Geschäftsprozesse und das Projektmanagement auf.
2.1 Geschäftsprozesse
Die Orientierung von Unternehmen an effiziente und optimierte Ausführung von Einzelfunktionen verursachte in den letzten Jahrzehnten eine verstärkte Kon- zentration auf die Funktionsbereiche, deren technologische und organisatori- sche Entwicklung zur signifikanten Erhöhung der Produktivität und Qualität ge- führt hat. Gleichzeitig stiegen die Kosten und die Komplexität der Koordination und Abstimmung zwischen unterschiedlichen Funktionsbereichen im Unter- nehmen. Als Lösung dieses Problems bietet sich die prozessorientierte Unter- nehmensgestaltung an. Sie fokussiert sich anstelle von Arbeitsabläufen einzel- ner Funktionsbereichen auf die Prozesse des gesamten Unternehmens.
Die Aufbau- und Ablauforganisation bilden gemeinsam die Organisationsstruktur eines Unternehmens. Während die Aufbauorganisation das Unternehmen in Teilbereichen (Abteilungen, Divisionen) gliedert und die Aufgaben zu diesen Teilbereichen zuordnet, befasst sich die Ablauforganisation mit der Durchführung und der zeitlichen und räumlichen Koordination dieser Aufgaben. Aufgaben setzen sich aus mehreren Arbeits- oder Prozessschritten zusammen, die wiederum verschiedene Aktivitäten beinhalten. Die Aktivitäten sind die Grundbestandteile von Arbeitsprozessen. Solche Arbeitsprozesse sind von allgemeiner Art und werden folgendermaßen definiert:
Ein Prozess ist die inhaltlich abgeschlossene, zeitliche und sachlogische Folge von Aktivitäten, die zur Erbringung einer Leistung ausgeführt werden müssen2. Ein Geschäftsprozess ist ein spezieller Prozess, der sich auf einem Unternehmen und dessen Geschäftszweck bezieht3.
2.1.1 Definition der Geschäftsprozesse
Der Begriff - Geschäftsprozess (GP) wird in der Literatur nicht einheitlich definiert. Die unterschiedliche Definitionen werden von [RHS04] folgendermaßen zusammengefasst: Ein GP ist „eine Abfolge von Aktivitäten, die der Erzeugung eines Produktes oder einer Dienstleistung dienen. Er wird durch ein oder mehrere Ereignisse gestartet und durch ein oder mehrere Ereignisse abgeschlossen. Es liegt eine Organisationsstruktur zu Grunde. Verwendete Synonyme sind: Ablauf, Vorgang, Prozess, Unternehmensprozess.“
Merkmale und Klassifizierung von Geschäftsprozessen
Wesentliche Merkmale eines GP sind die Schnittstellen zu den Geschäftspart- nern des Unternehmens (Lieferanten, Kunden). Die Auftragsabwicklung in ei- nem Produktionsbetrieb, die Kreditvergabe eines Banks sind Beispiele für GP4. Grundlage für die Klassifizierung von GP bildet das Porter-Modell5 der Wertket- te. Dieses Modell unterscheidet zwischen primären und unterstützenden Unter- nehmensaktivitäten. Primäre Aktivitäten sind wertschöpfende Tätigkeiten, deren Ergebnis ist das vom Unternehmen hergestellte Produkt oder angebotene Dienstleistung. Sie tragen direkt zum Unternehmenserfolg bei. Diese Aktivitäten bilden die Kerngeschäftsprozesse. Unterstützende Aktivitäten haben keinen di- rekten Bezug zu den Produkten oder Dienstleistungen aber sie sind unerheblich bei Durchführung wertschöpfender Tätigkeiten. Solche Tätigkeiten werden in unterstützende Prozesse zusammengefasst. Die Rahmenbedingungen für Steuerung von Kern- und unterstützenden GP geben die sogenannten Mana- gement Prozesse vor.
Genauere Beschreibung von Kern- und unterstützenden GP sowie von Management Prozessen bietet [Ga05]6.
Kerngeschäftsprozesse haben einen hohen Wertschöpfungsanteil. Sie sind wettbewerbskritische Prozesse, die den gesamten Leistungserstellprozess von Kundenabfrage bis hin zur Auslieferung bzw. Dienstleistung abbilden. Beispiele dafür sind die Auftragsbearbeitung, die Produktion, der Vertrieb und der Ser- vice.
Unterstützende Geschäftsprozesse haben keinen oder nur geringen Wertschöpfungsanteil. Sie sind nicht direkt wettbewerbskritisch, verursachen aber in manchen Unternehmen zum Teil erhebliche Kosten. Beispiele sind die Finanzbuchhaltung, die Bericht- und die Personalwesen.
Management Prozesse verantworten die integrative Zusammenarbeit der Gesamtheit der GP. Beispiele für Management Prozesse sind die Unternehmensplanung und das Operative Führen.
2.2 Projektmanagement
Dieses Kapitel definiert den Begriff - Projektmanagement und listet unter- schiedliche Projektarten auf. Ferner stellt es das technische System, den Ge- genstand technischer Großprojekte vor. Zusätzlich stellt dieses Kapitel eine Verbindung zwischen den zwei Themenschwerpunkten dieser Arbeit her.
2.2.1 Begriffe und Definitionen
Die nachfolgenden Begriffe und Definitionen bilden die Grundlage der Theorie vom Projektmanagement.
Ein Projekt7 ist eine betriebswirtschaftliche oder technische Aufgabenstellung, die komplex, einmalig und zeitlich begrenzt ist. Ein Projekt ist ein neuartiges, risikobehaftetes Vorhaben, das abseits des Tagesgeschäfts abläuft. Folgende Merkmale kennzeichnen ein Projekt:
konkrete Zielvorgabe mit definierten Ergebnissen, Einmaligkeit des Vorhabens, begrenzte Ressourcen, vorgegebene zeitlicher Rahmen, finanzielle und personelle Einschränkungen, Risiko des Scheiterns, Bedarf an interdisziplinäres Know-How, hohe Komplexität hinsichtlich auf Aufgabenstellung, besondere Organisationsform - Projektorganisation, die unabhängig von der Aufbauorganisation ist.
Ein technisches Projekt8 hat zum Aufgabe die Errichtung neuer industrieller Anlagen oder neuer Bauwerken. Das erfordert die Beherrschung komplexer Abläufe. Ursachen für die besondere Komplexität technischer Projekte sind:
Mitwirkung vielen involvierten Unternehmen bei dem Bau und Montage, Einflussfaktoren wie Produktionsverfahren, Meteorologie und Umwelt, die optimal beherrscht werden müssen, Zeitliche Parallelität vieler Vorgänge, was eine straffe und erfahrene Ablaufsteuerung erfordert.
Ein Anlagenprojekt ist ein technisches Projekt, das sich auf komplexe Lösun- gen bezieht, die dem Kunden schlüsselfertig als Automatisierungslösung, Anla- gengeschäft oder Systemleistung angeboten werden. Es besteht vorrangig aus kundenorientierter Anpassungsentwicklung und Innovationskomponenten9.
PPP-Infrastrukturprojekt ist eine spezielle Art von Anlagenprojekten. Grundla- ge dafür bildet die am Lebenszyklus der Infrastruktur orientierte, vertraglich ge- regelte Zusammenarbeit zwischen öffentlicher Hand (Staat) und Privatwirtschaft unter Nutzung dieser Infrastruktur zur Erfüllung öffentlicher Aufgaben (vgl. [LVZK07] S.29). Diese Art von Projekten lassen sich durch folgende Merkma- len10 charakterisieren: die öffentliche Aufgabe verbleibt bei dem Staat, Auftragsdurchführung durch private Unternehmen, Zusammenarbeit erstreckt sich über lange Zeit, das Projektrisiko trägt der private Vertragspartner, Grundlage für Zusammenarbeit bildet der Vertrag.
Die Projektorganisation beinhaltet die Aufbau- und Ablauforganisation des Projektes. Während die Aufbauorganisation die Zusammensetzung des Projekt- teams und die Befugnisse des Projektleiters (PL) regelt, unterteilt die Ablaufor- ganisation die komplexe Projektaufgabe in kleinere und überschaubare Arbeits- pakete11. Die Aufbauorganisation eines Projektes wird in Abhängigkeit vom Pro- jektumfang und dem damit verbundene Risiko festgelegt. Die wichtigsten Ge- staltungsformen für die Aufbauorganisation sind das reine Projektmanagement
(PM) und die Matrix-Projektorganisation. Im reinen PM wird das Projekt zeitlich befristet in der Aufbauorganisation des Unternehmens als eine mit anderen gleichrangige Org.-Einheit integriert. Die Mitarbeiter werden aus unterschiedli- chen Fachabteilungen für die Dauer des Projektes fachlich und personell dem Projektleiter (PL) unterstellt. (vgl. [KW02] S. 26 und [ZSR05] S. 30). Der PL ver- fügt über uneingeschränkte Weisungsbefugnis gegenüber den Projektmitarbei- tern und ist für erfolgreiche Projektdurchführung unmittelbar verantwortlich. Das reine PM findet bei Projekten mit hohem Risiko und „Full-time-Projekten12 “ Ein- satz (vgl. [KW02] S.26). Es eignet sich besonders für außerordentliche Vorha- ben mit großem Umfang.
In der Matrix-Projektorganisation wird das PM dem Vorstand als Stabstelle zu- geordnet. Weisungsbefugnis hat in dieser Projektorganisation nicht nur der PL sondern sie wird mit den Linien- und Fachvorgesetzten geteilt (vgl. [ZiSt05] S.31). Die Mitarbeiter werden in das Projekt delegiert und dem PL fachlich un- terstellt. Personell bleiben sie weiterhin bei den Linienvorgesetzten. Einsatz- möglichkeit findet diese Projektorganisationsform bei einer hohen Anzahl von parallel laufenden Projekten und bei stark abteilungsübergreifenden Projekten (vgl. [KW02] S. 27).
Projektmanagement13 (PM) ist das Management, das erforderlich ist, um ein Projekt bestimmter Art, in einer bestimmten Zeit und mit bestimmten Ressourcen zu einem bestimmten Ergebnis zu führen. Nach der DIN-Norm 69901 ist das PM die Gesamtheit von Führungsaufgaben, -techniken, -mitteln und - organisation, für die Abwicklung sowohl einzelner als auch mehrerer Projekten. Die wesentlichen Aufgaben vom PM sind:
Auswahl des Projektteams14,
Planung aller zur Projektdurchführung benötigten inhaltlichen Aktivitä- ten, Projektsteuerung (Controlling) als kurzfristiges Gegensteuern bei Abweichungen vom Projektplan und Kontrolle in Bezug auf Termine, Kosten und Einleitung von Korrekturmaßnahmen, Festlegung der projektbegleitenden Dokumentation.
Das PM kann als ein Geschäftsprozess des projektorientierten Unternehmens aufgefasst werden, das entsprechend der Komplexität des Vorhabens zu gestalten ist (vgl. [JKP05] S.34).
Projektorientierte Unternehmen nehmen „Projekte als temporäre Organisation zur Durchführung komplexer Prozesse wahr, z. B. Abwicklung eines Kunden- auftrags, zur Entwicklung eines Produktes“ (vgl. [JKP05] S.51). Nach der im Kapitel 2.1.2 vorgestellten Klassifizierung der GP, ist das PM ein Management Prozess. Seine Ziele sind die Realisierung der Projektziele, Management der Projektkomplexität. Der PM-Prozess steuert die inhaltlichen Prozesse (Planung, Realisierung, Inbetriebnahme), die notwendig für die Realisierung der Projekt- ziele sind. Dieser Prozess startet mit dem Projektauftrag und endet mit der Pro- jektabnahme.
Die drei Begriffe Produkt, Projekt und Prozess stehen innerhalb des PM miteinander in enger Beziehung. Deren konsequente Auseinanderhaltung ist für das erfolgreiche PM von zentraler Bedeutung. Die inhaltliche Abgrenzung dieser Begriffe stellt die Abb. 1 (vgl. [JKP05] S.33) dar.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 1: Projekt, Prozess und Produkt
Jedes Projekt wird von einer Idee angestoßen. Auf deren Grundlage werden die Projektziele formuliert. Sie definieren das erzielte Projektergebnis. Um es zu verwirklichen, muss eine Reihe von Prozessschritten (z.B. Definition, Entwurf, Realisierung) ausgeführt werden. Die Auffassung des Projektes als eine tempo- räre Organisation fördert die Prozessorientierung im PM. Für die Darstellung der Projektstruktur sind sogenannten Phasenmodelle (z.B. das V-Modell aus Kap. 2.4.2) sehr geeignet. Ein Auftragsprojekt im Anlagenbau kann z.B. in Pha- sen Akquisition, Projektabwicklung und Service gegliedert werden (vgl. [JKP05] S.202). Der GP Projektabwicklung beinhaltet das PM als einen übergeordneten Management Prozess über den inhaltlichen Prozessen wie Entwicklung, Be- schaffung, Transport, Montage und Inbetriebnahme. Das PM als GP beinhaltet die Teilprozesse Projektstart, Projektcontrolling und Projektabschluss.
Der Projektcontrolling-Prozess wird vom Projektstart bis zum Projektende mehrmals durchgelaufen. Das Projektcontrolling beinhaltet „die Vereinbarung und Vornahme steuernder Maßnahmen, die Weiterentwicklung der Projektorganisation und der Projektkultur, die Neuvereinbarung der Projektziele, die Erstellung von Fortschrittberichten und die Durchführung von Projektmarketingmaßnahmen“ (vgl. [JKP05] S.38).
Der Projektabschluss-Prozess umfasst „die Planung und Fertigstellung inhaltlicher Restarbeiten“ (vgl. [JKP05] S.39), Übergabe der Projektergebnisse, Evaluierung der Projektarbeiten sowie die Auflösung des Projektteams.
Im Weiteren wird der Teilprozess Projektstart wegen seiner hohen Relevanz zu dem Thema dieser Masterarbeit (Struktur der Projektdokumentation) ausführlich behandelt.
Der wichtigste Teilprozess des PM ist der Projektstart, denn in dieser Phase werden die Grundlagen wie z. B. Projektpläne, Projektorganisationsstrukturen für die anderen Teilprozesse definiert. Zentrale Tätigkeit in diesem Definitionsprozess am Projektstart ist die Projektplanung. Sie umfasst die formale, zeitliche und ressourcenspezifische Gliederung des Projektes.
2.2.2 Projektplanung
Das PM besteht maßgeblich aus Planungsaufgaben. Die Projektplanung (PP) dient zur Festlegung des Weges zur erfolgreichen Realisierung von Projektzielen. Inhaltlich befasst sich die PP mit Planung von Aktivitäten, Ressourcen, Terminen und Kosten (vgl. [AM02] S. 12).
Die Aktivitätsplanung erfordert eine klare Aufgabenformulierung. Die Aufga- ben sollen in Teilaufgaben zu sogenannten Arbeitspakete zerlegt werden. Die Ressourcenplanung legt den benötigten personellen Aufwand, bestimmte Aufgaben zu lösen, fest. Dabei werden Fragen bezüglich der Dauer einzelner Arbeitsschritten sowie der zeitlichen Verfügbarkeit der entsprechend qualifizier- ten Mitarbeiter geklärt.
Die Terminplanung legt die Termine für Projektanfang und -ende fest. Darüber hinaus werden Meilensteine als Stichtage für wichtige Zwischenergebnisse und für Entscheidungen über Weiterführung eines Projektes definiert. Die Kostenplanung identifiziert alle möglichen Kostenarten, die während des Projektes entstehen können. Die Kostenplanung erfolgt auf Basis der Ressour- cen- und Terminplanung. Grundsätzlich entstehen Kosten mit der Nutzung von Ressourcen. Darüber hinaus wird die Höhe der Projektkosten von der Projekt- dauer beeinflusst. Da die Kostenplanung in dieser Masterarbeit eine wichtige Rolle spielt, wird im Weiteren auf die Zusammenstellung und die Bestandsteile des Kostenplans näher eingegangen.
Bei der Kostenplanung kann zwischen den Top-Down- und Bottom-Up-Ansatz gewählt werden. Während bei Top-Down-Ansatz eine freie Mittelverteilung im vorgegebenen und verfügbaren Budgetrahmen vorgenommen wird, erfolgt bei dem Bottom-Up-Ansatz eine Kostenhochrechnung nach vorkalkulierten Ele- menten, Kosten und Kostenträgern (vgl. [Cr04] S. 67). Projektkosten setzen sich grundsätzlich aus Personal- und sonstigen Kosten wie Material-, Reise-, Finanzierungskosten zusammen. [Cr04]15 beschreibt eine mögliche Vorge- hensweise für die Zusammenstellung eines Kostenplans. Demnach sollen zu- erst die Vorgangskosten wie Personal- und sonstige Kosten ermittelt werden. Sie sollen dann zu Arbeitspaket-, Teilprojekt- und Gesamtprojektkosten aggre- giert werden. Auf deren Grundlagen soll anschließend der Kostenplan erstellt werden.
2.2.2.1 Projektphasen und Meilensteine
Eine Projektphase laut [DIN69901] ist ein zeitlicher Abschnitt des Projektablaufs, der sachlich gegenüber anderen Abschnitten getrennt ist. Darüber hinaus beinhaltet eine Projektphase eindeutig zugeordnete Arbeitspakete und hat einen definierten Anfangs- und Endzeitpunkt. Diese Zeitpunkte, die Projektphasen trennen, werden Phasen-Meilensteine genannt.
Ein Meilenstein definiert den Abschluss einer Projektphase und den Übergang zur nächsten Phase sowie die Arbeitsergebnisse, die zu diesem Zeitpunkt vorliegen müssen. Die Gesamtheit der Projektphasen kann mit Hilfe eines Phasenmodells abgebildet werden. Bei einem phasenweisen Projektablauf empfiehlt es sich laut [Cr04]16 folgende Arbeitsschnitte durchzulaufen:
Definition des Projektanfangs und -endtermins, Definition der Phasen als genau messbaren Zeitabschnitte, Grobe Terminierung der einzelnen Phasen.
Phasenmodelle dienen zur schrittweisen Detaillierung des Projektablaufs bis zum realisierten Projektergebnis.
Ein Phasenmodell stellt die Grundlage für die Erstellung eines Meilensteinplans dar. Hier wird an jedes Phasenende ein Meilenstein mit definierten Ergebnis und Termin gesetzt.
Die Projektplanung ist eine Phase vom Projektlebenszyklus mit definierten Vor- gänger und Nachfolger. Die Einordnung und Stellung der Projektplanung im Projektlebenszyklus stellt das folgende Phasenmodell nach [ZSR05]17 dar.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2: Phasen des Projektlebenszyklusses
Die Projektkonzeptionsphase wird mit dem Projektauftrag ausgelöst. Sie beinhaltet die Machbarkeitsstudie, die Aufwandschätzung, die Wirtschaftlichkeitssowie die Risikoanalyse.
Die Projektspezifikationsphase wird mit den positiven Ergebnissen der Machbarkeitsstudie und Wirtschaftlichkeitsanalyse angestoßen. In dieser Phase werden Aufbau und Ablauforganisationen sowie die Ziele des Projektes festgelegt. Sie wird von der Projektplanungsphase mit der Detailplanung abgelöst. In der Projektplanungsphase werden wie schon geschrieben die Struktur- Ressourcen-, Termin- und Kostenanalysen durchgeführt.
Die Projektrealisierungsphase beginnt nach der erfolgreichen Planungsphase. Sie umfasst die Aufgaben der Projektüberwachung und der Projektrückschau.
Die hier beschriebenen Projektphasen enthalten Rückkopplungen, in denen die Planung der Projektphasen und deren Teilschritten während der Projektdauer fortlaufend detailliert wird.
2.2.2.2 Projektphasen technischer Großprojekte
Entscheidend für den PM-Erfolg technischer Großprojekte ist die zeitliche Gliederung der Projekte in Projektphasen. Sie tragen zu der Reduktion der Komplexität und zu besseren Steuer- bzw. Kontrollierbarkeit technischer Projekte bei. Technische Großprojekte im Kundenauftrag haben laut [MS07]18 folgende (siehe Abb.3) Projektphasen.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3: Projektphasen technischer Großprojekte
Die Konzeptphase gehört inhaltlich nicht zu den tatsächlichen Projektphasen. Sie ist eine sogenannte „Vorphase“, die die Grundlagen (Prüfung der Kunden- anfrage und Erstellung eines Angebots) für ein technisches Projekt schaffen soll.
Die Planungsphase beinhaltet die Detailplanung für das Projekt, das Kick-Off- Meeting19 sowie die Designentwicklung20. Die Designentwicklung als Teilpro- zess des Systementwicklungsprozesses wird im Kapitel 2.3.2 näher beschrie- ben.
Die Durchführungsphase umfasst die Detailkonstruktion, den Prototypenbau und Zusammenstellung des entwickelten Systems.
Zur Abschlussphase gehören folgende Tätigkeiten: Qualitätssicherung und Ab- nahme durch Kunde.
2.2.2.3 Projektstruktur und der Standardprojektstrukturplan
Der Objektstrukturplan stellt die einzelne Bauteile, Baugruppen und Teilsysteme nach ihrer Zugehörigkeit gegliedert dar. Dieser Plan dient der Auflistung aller Produktsteile, Teilergebnisse und schließlich Ergebnisse die berücksichtigt werden müssen (vgl. [JKP05] S.40).
Während die Projektphasen eine zeitliche Gliederung des Projektes darstellen, nimmt der Projektstrukturplan (PSP) eine inhaltliche Gliederung des Projektes vor. Der PSP teilt das Projekt „in plan- und kontrollierbare Teilaufgaben, sogenannten Arbeitspakete“21 auf. Darüber hinaus hält der PSP die Ordnungsbeziehungen und den prozessualen Abhängigkeiten und Abläufe (vgl. [JKP05] S.42) fest. Das heißt, der PSP ordnet die im Objektstrukturplan dargestellten Produktteile bestimmten Tätigkeiten zu. In Folge dieser Zuordnung können die im PSP dargestellten Vorgänge definiert werden (vgl. [Br01] S. 288).
Darüber hinaus beschreibt [ST00] den PSP als eine graphische Darstellung die zum Erreichen des Projektziels notwendigen Aktivitäten beinhaltet. Die Struktur eines Projektstrukturplans stellt folgende Abbildung (siehe Abb.4) dar.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 4: Projektstrukturplan
Auf der untersten Ebene eines PSP befinden sich die Arbeitspakete (AP). AP sind voneinander abgrenzbare in sich geschlossene Aktivitäten.
In der Planungsphase wird der Projektgegenstand in Teilaufgaben und Arbeitspakete zerlegt und die Beziehungen zwischen diesen bestimmt.
Ist die Aufgabenstruktur vieler Projekte vergleichbar, ist es sinnvoll einen Standardprojektstrukturplan aufzustellen. Die Anpassung an ein neues Projekt ist einfach durchzuführen. Die nicht benötigte Arbeitspakete werden entfernt und benötigte neue hinzugefügt. So erhält die Projektleitung einen aktuellen Plan mit Ausgangsdaten, Termin- und Kostenplanung (vgl. [Fi07] S. 111). Die Abb. 5 stellt einen beispielhaften Projektstrukturplan dar. Folgende Ebenen umfasst in der Regel der Standardprojektstrukturplan:
Abbildung in dieser Leseprobe nicht enthalten
Abb. 5: Beispiel für einen Standardprojektstrukturplan
2.3 Technische Systeme als Gegenstand technischer Großprojekte
2.3.1 Definition des System- und Modellbegriffs
Ein System besteht aus einer Menge von Elementen, die durch Beziehungen (Relationen) miteinander verbunden sind. Systemelemente und deren Beziehungen haben veränderbare Eigenschaften. Die Systemgrenze trennt das System von seiner Umwelt.22. Die Anordnung, bzw. Beziehungen zwischen den Elementen ergeben die Struktur eines Systems (vgl. [Sc99] S.46). Beim Untersuchen der inneren Struktur eines Systems werden Elemente und Beziehungen zwischen diesen Elementen aufgedeckt. Die Strukturerfassung eines Systems erfolgt in der Regel nach einem hierarchischen Ordnungskonzept. Wird das System auf mehrere Ebene gegliedert, so ergibt sich ein hierarchischer Systemaufbau, die sogenannte Systemhierarchie (vgl. [BF02] S.18). Abb. 6 stellt eine Systemhierarchie nach [BF02] vor:
Abbildung in dieser Leseprobe nicht enthalten
Abb. 6: Systemhierarchie
Elemente eines Systems können entweder Untersysteme (Teilsysteme) oder Komponenten sein.
[...]
1 Sicherheitsnachweis gemäß der CENELEC-Norm 50129:1999
2 vgl.[BKR05] S. 6
3 vgl. [RHS04] S. 21-22
4 vgl.[BKR05] S. 7
5 vgl.[Po98] S.77
6 vgl. [Ga05] S. 50
7 vgl. DIN-Norm 69901
8 vgl.[Eb02] S.2
9 vgl. [Ha02] S.15
10 vgl. [Kr08] S. 2
11 vgl.[AM02] S.11
12 Projektmitarbeiter verlassen ihre Linientätigkeiten und widmen sich vollständig an ihre Projektarbeit zu.
13 vgl.[Ke02] S.10
14 Gesamtheit der am Projekt arbeitende Mitarbeiter
15 vgl. [Cr04] S. 68
16 vgl. [Cr04] S.16
17 vgl. [ZSR05] S. 8
18 vgl. [MS07] S. 84
19 Auftaktveranstaltung eines Projektes, wo die Rahmenbedingungen für das Projekt geklärt werden (vgl. [Cr04] S.55)
20 Entwicklung der Systemarchitektur
21 vgl. [Ja05] S. 41
22 vgl. [He07] S. 6 und [Ja08] S.15
- Quote paper
- MSc Emese Komaromi (Author), 2008, Aufbau einer generischen Dokumentationsstruktur für technische Großprojekte, Munich, GRIN Verlag, https://www.grin.com/document/233330
