eJournals PROJEKTMANAGEMENT AKTUELL 17/4

PROJEKTMANAGEMENT AKTUELL
pm
2941-0878
2941-0886
UVK Verlag Tübingen
121
2006
174 GPM Deutsche Gesellschaft für Projektmanagement e. V.

Warum Produktzentriertes Projektmanagement (PZPM)?

121
2006
Manfred Saynisch
Zunächst werden neue Anforderungen in der industriellen Produktentwicklung und Organisation, wie zum Beispiel immer kürzere Produktzyklen oder komplexer werdende Produkte, dargelegt und in einigen Beispielen erläutert. Der Stand der Technik und die wesentlichen Problemkreise, die als Ausgangspunkt für die Lösungen von morgen dienen, werden im 2. Teil dargelegt. o Der Schwerpunkt liegt dabei auf den unzureichenden Möglichkeiten der Projektfortschrittsmessung im Projekt-Controlling, der interdisziplinären Integration technischer Funktionsbereiche und der organisatorischen Integration kooperierender Unternehmen. o Im Rahmen einer Strategie zur Meisterung von Komplexität wird aufgezeigt, dass das Konzept des produktzentrierten Projektmanagements im Kontext von Product-Lifecycle Management das traditionelle Verständnis von Projektmanagement mit seinen begrenzten Möglichkeiten zur Komplexitätshandhabung erweitern kann. Zu jedem diskutierten Problemkreis werden Lösungsansätze identifiziert und kurz erläutert. Diese Lösungsansätze auszuformen und in Prozessen, Systembeschreibungen und Anwendungszusammenhängen darzulegen, wird in den weiteren Artikeln in diesem Heft von Saynisch, Karcher, Jungkunz und Geckler vorgenommen.
pm1740014
3 SCHWERPUNKT projekt M A N A G E M E NT 4/ 20 0 6 aktuell D er integrative und interdisziplinäre Ansatz eines IT-gestützten „Produktzentrierten Projektmanagements im Kontext von Product Lifecycle Management“ ist eine Antwort auf die neuen Herausforderungen in der industriellen Produktentwicklung und Organisation, wie zum Beispiel immer kürzer werdende Produktzyklen oder komplexer werdende Produkte. Ein Projektmanagement (PM) mit neuen, erweiterten Möglichkeiten zur Komplexitätshandhabung ist das Gebot der Stunde. Wie das nun aussehen kann, zeigt das Schwerpunktthema dieses Heftes. Im ersten Beitrag „Warum Produktzentriertes Projektmanagement? “ gibt M. Saynisch eine Einführung in den gesamten Themenkreis. Der Stand der Technik und die wesentlichen Problemkreise, die als Ausgangspunkt für die Lösungen von morgen dienen, werden dargelegt. Diese Lösungsansätze auszuformen und in Prozessen, Systembeschreibungen und Anwendungszusammenhängen darzulegen, wird in den weiteren Beiträgen in diesem Heft vorgenommen, die durch zahlreiche Querverweise verbunden sind. Im zweiten Beitrag „Projekt-, Konfigurations- und Collaboration Management“, bei dem ein PM mit neuer Qualität im Zentrum steht, beschreibt M. Saynisch innovative Lösungen auf der Management- und Prozessseite, in deren Zentrum auch eine neuartige produktorientierte Projektfortschrittsermittlung steht und die eine maßgeschneiderte und anspruchsvolle IT-Unterstützung erfordern. Produktzentriertes Projektmanagement im Kontext von Product Life Cycle Management (PLM) ist genauso wenig ohne IT-Unterstützung sinnvoll und umsetzbar wie ein effizientes PLM zur Prozessoptimierung selbst. Dies zu erreichen setzt jedoch ein grundlegendes Verständnis des PLM-Managementprinzips und der damit verbundenen IT-Konzepte voraus, das A. Karcher in seinem Beitrag „Ganzheitliches Product Lifecycle Management (PLM) …“ in den Mittelpunkt stellt. D. Geckler stellt nun im vierten Beitrag „Die Stückliste ist die Mutter aller Daten“ den Anwendungszusammenhang von der Welt der Prozesse und Arbeitsstrukturen mit einer geeigneten und anspruchsvollen IT-Unterstützung her, wie er aus der Perspektive der Automobilindustrie gesehen wird. Im letztem Beitrag des Schwerpunkts behandelt schließlich R. M. Jungkunz eine „PDM-basierte Überwachung Produktzentriertes Projektmanagement (PZPM) Einleitung und Übersicht zum Schwerpunktthema komplexer Entwicklungsprojekte“ (PDM = Produktdatenmanagement). Dieser dort dargelegte IT-basierte Ansatz einer produktorientierten Projektfortschrittsermittlung stellt eine weltweite Neuigkeit im PM dar. Alle fünf Beiträge weisen ein gemeinsames Merkmal auf: Um den umfassenden Herausforderungen für die Gegenwart und die Zukunft durch wirkungsvolle Lösungsansätze zu begegnen, mussten die Grenzen des heute praktizierten Projektmanagements überschritten werden. Es war eine Erweiterung durch Einbezug einer fachlich-inhaltlichen Koordination, eines Technischen Managements der erzeugnisbzw. produktschaffenden Prozesse bzw. der Wertschöpfungsprozesse erforderlich. Dieser Zusammenhang zwischen dem Projektmanagement, dem Konfigurationsmanagement (KM) und dem Product Lifecycle Management (PLM) und die daraus entstehenden Nutzenpotenziale für das PM wurden bisher weltweit in der PM-Community kaum aufgezeigt und behandelt. Daher stellt diese zusammenfassende Darstellung in diesem Heft, die aus Präsentationen auf dem PM- Forum 2004 hervorgegangen ist [1], eine Erstmaligkeit, eine Pioniersituation, dar. Erste Ansätze wurden allerdings bereits 1999 zur 3. Tagung zum Konfigurationsmanagement „Änderungsmanagement mit System - Schlüsselfaktor Konfigurationsmanagement“ thematisiert [2]. Die Ausführungen zum „Produktzentrierten Projektmanagement“ fokussieren sich insbesondere auf Projekte in der verarbeitenden Industrie wie Maschinenbau, Automotive, Anlagenbau, Bauwesen oder Aerospace & Defence einschließlich der in ihren Produkten integrierten Softwaresysteme (Embedded Software) und weiterhin mit dem Schwerpunkt bei der Produktentwicklung (F&E) und Produktionsvorbereitung. Für organisatorische Veränderungsprojekte beispielsweise ist dieser Ansatz nicht gedacht. Sollten jedoch derartige Organisationsprojekte mit IT-Lösungen verbunden sein, wie es z. B. bei einer SAP-Einführung gegeben ist, so können auch diese Prozesse der IT-Lösungen (meist als Anwendungssoftware bezeichnet) mit dem „Produktzentrierten Projektmanagement“ gesteuert werden. Manfred Saynisch n Literatur [1] Rackelmann, G.; Schelle, H. (Hrsg.): Best Practice im Projektmanagement - 21. Internationales Deutsches PM Forum 2004 in Nürnberg. GPM-Verlag, Nürnberg 2005 [2] Saynisch, M.; Lange, D. (Hrsg.): Änderungsmanagement mit System - Schlüsselfaktor Konfigurationsmanagement. 3. Fachtagung Konfigurationsmanagement. GPM-Verlag, Nürnberg/ Stuttgart 1999. Infos: info@spm-consult.de PM_4_06.indd 13 26.09.2006 16: 07: 17 Uhr 4 SCHWERPUNKT SCHWERPUNKT aktuell projekt M A N A G E M E NT 4/ 20 0 6 Neue Herausforderungen in der industriellen Produktentwicklung und Organisation Nach einem einleitenden Überblick zu den neuen Herausforderungen werden diese in mehreren Beispielen erläutert. . Einführender Sachverhalt Neue Anforderungen, wie o immer kürzere Produktzyklen und Time-to-Market- Spannen, o komplexer werdende Produkte, zum Beispiel: n die Höchstintegration von Mechanik, Elektronik und Informatik (Mechatronik); die Funktionalität der meisten modernen Produkte wird in rapid steigendem Maße nur noch softwaretechnisch realisiert (Embedded Software), n bei komplexen IT/ Organisationsprojekten n oder bei der Softwareentwicklung im Client/ Server- Umfeld für verschiedene Plattformen, o Globalisierung, instabile Märkte, o steigende Kundenanforderungen, o steigende Variantenvielfalt und Qualitätsanforderungen o etc., bedingen neue Arbeitsstrukturen und Vorgehensweisen, wie o interdisziplinäre Zusammenarbeit, o integrative Vorgehensweisen, und erfordern neue Organisationsstrukturen wie o bei der interdisziplinären, verteilten und vernetzten Produktentwicklung, o bei der interdisziplinären, verteilten oder vernetzten Projektdurchführung o oder bei der Hersteller-Zulieferer-Integration (Collaborative Work, Internet-Engineering, Vertragspartnerorganisation). Diese immer komplexer werdenden Situationen einerseits in der Gesellschaft und der Ökonomie sowie andererseits in der Wissenschaft und den technologischen Möglichkeiten stellen neue Anforderungen an das Management von Projekten, das von den bisherigen, traditionellen Ansätzen und Praktiken im Projektmanagement nicht mehr allein abgedeckt werden kann [1, 2, 3, 4]. .2 Beispiel : Neue Anforderungen an Organisationsstrukturen in der industriellen Produkt- Entwicklung Die Herausforderung unseres 21. Jahrhunderts ist es, die turbulenten Veränderungen des Umfeldes rasch zu erkennen und schnell zu agieren. Die Ansprüche des Kunden in Bezug auf Individualität, Funktion und Produktqualität steigen kontinuierlich, und das Produktangebot wird weltweit vergleichbar. Die Komplexität und Interdisziplinarität der Erzeugnisse nehmen zu - effektive Gesamtlösungen erfordern eine kooperative Produktentwicklung (KPE), auch oft mit Hersteller-Zulieferer-Kooperation oder Cross Company Collaboration (C3) bezeichnet [2]. Warum Produktzentriertes Projektmanagement (PZPM)? Der Kontext zum Product-Lifecycle Manfred Saynisch Zunächst werden neue Anforderungen in der industriellen Produktentwicklung und Organisation, wie zum Beispiel immer kürzere Produktzyklen oder komplexer werdende Produkte, dargelegt und in einigen Beispielen erläutert. Der Stand der Technik und die wesentlichen Problemkreise, die als Ausgangspunkt für die Lösungen von morgen dienen, werden im 2. Teil dargelegt. o Der Schwerpunkt liegt dabei auf den unzureichenden Möglichkeiten der Projektfortschrittsmessung im Projekt-Controlling, der interdisziplinären Integration technischer Funktionsbereiche und der organisatorischen Integration kooperierender Unternehmen. o Im Rahmen einer Strategie zur Meisterung von Komplexität wird aufgezeigt, dass das Konzept des produktzentrierten Projektmanagements im Kontext von Product-Lifecycle Management das traditionelle Verständnis von Projektmanagement mit seinen begrenzten Möglichkeiten zur Komplexitätshandhabung erweitern kann. Zu jedem diskutierten Problemkreis werden Lösungsansätze identifiziert und kurz erläutert. Diese Lösungsansätze auszuformen und in Prozessen, Systembeschreibungen und Anwendungszusammenhängen darzulegen, wird in den weiteren Artikeln in diesem Heft von Saynisch, Karcher, Jungkunz und Geckler vorgenommen. PM_4_06.indd 14 26.09.2006 16: 07: 17 Uhr 5 projekt M A N A G E M E NT 4/ 20 0 6 aktuell .3 Beispiel 2: Der neue Innovationstreiber und Wirtschaftsfaktor „Software in Maschinen“ verlangt nach interdisziplinärer Zusammenarbeit [ , 2, 3, 4] Die Situation: Die Funktionalität der meisten modernen Produkte wird fast nur noch softwaretechnisch realisiert. Die Softwaretechnik hat sich daher zu einer Schlüsseltechnologie im Maschinen- und Anlagenbau, in der Automatisierungs- und Produktionstechnik und der Verkehrstechnik (insbesondere des Automobilbaus) entwickelt. Der Anteil der Elektronik/ Software im Automobil beträgt heute schon 30 Prozent mit steigender Tendenz. Abb. 1 verdeutlicht diese Situation und gibt gleichzeitig einen Überblick über den Umfang der Komplexität. Die dort angegebenen Daten für Dateien, Bauteile und E/ E- Steuereinheiten stammen aus 1998. Heute sind sie bereits erheblich umfangreicher. Im Maschinenbau entfallen bis zu 50 Prozent der Entwicklungskosten auf die eingebettete Software. In einigen technischen Produkten erreicht die Software sogar 80 Prozent der Herstellkosten. Beim EFA (European Fighter) werden über 50 Prozent der Entwicklungskosten von der Elektronik/ Software verursacht. Er wird daher auch als „fliegender Rechner“ bezeichnet. Der Bereich der „Aerospace & Defence“ kann in diesem Kontext generell als Schrittmacher angesehen werden. Ein aktuelles Musterbeispiel ist hier auch das Dilemma mit dem Maut-System und den Produkten der Firma Toll Collect. Barry Boehm charakterisierte kürzlich in einem wegweisenden Artikel zu den zukünftigen Trends [5]: „Beetween now and 2025, the ability of organizations and their products, systems and services to compete, adapt, and survive will depend increasingly on software. As is being seen in current products (automobiles, aircraft, radios) and services (financial, communications, defense), software provides both competitive differentiation and rapid adaptability to competitive change.“ „Software-Intensive-Sytems (SIS)“ sind somit der zukünftige Trend! Softwaretechnik wird zur Schlüsseltechnologie im Maschinen- und Anlagenbau, in der Automatisierungs- und Produktionstechnik und der Verkehrstechnik. Die rapide Verlagerung der Produktfunktionalität zur Software zwingt viele Unternehmen zu radikalen Veränderungen in ihrer Produktentwicklung. Die Lösung heute: „Tüftelei“: Trotz dieser herausragenden Bedeutung herrscht bei der Entwicklung von Produkten mit eingebetteten Systemen meist noch das Prinzip der „Tüftelei und Bastelei“ vor, was allenfalls zu durchschnittlichen Ergebnissen führt. Die Crux liegt in der Interdisziplinarität: Es treffen die unterschiedlichen Denk- und Handlungswelten der Mechanik/ Maschinen, Elektrik, Mikrosystemtechnik und Software/ Informatik in hoher Interaktion zusammen. Doch Ansätze zu einer übergreifenden Koordination fehlen. Eine systematische und effektive interdisziplinäre Zusammenarbeit und ein automatisierter Austausch und eine Vernetzung digitaler Daten existieren nicht. .4 Beispiel 3: Steigende Variantenvielfalt Bei BMW hieß es schon vor Jahren, dass nur etwa alle zwei Jahre exakt das gleiche Auto vom Band läuft. So umfangreich sind die Varianten, die in einem Auto zum Tragen kommen. Ein weiteres Beispiel ist der Golf III: Regelsystem, z. B. Navigationssystem Sensoren Aktoren Steuergeräte Software 100-200 Dateien Steuergeräte Hardware 300-500 Bauteile Qualitätsvorschriften Funktionsspez. Schnittstellen Messdaten Fehler Steuergerät: Sachnummer HW-Stand: A, B, C, Muster SW-Stand: XXX-Stände Im Fahrzeug befinden sich ca. 50 E/ E-Steuergeräte mit verteilter Funktion mit unterschiedl. Herstellern mit nachladbarem Code (Flashprozess) mit kodierbarer Funktion Das Steuergerät ist nur ein Teil des Regelsystems. Sensoren + Aktoren liegen z. T. in der Freigabehoheit anderer Fachbereiche Abb. 1: Beispiel von eingebetteten Systemen (Embedded Software) im Automobilbau [3, 4]; Quelle: Wehlitz BMW AG 1998 PM_4_06.indd 15 26.09.2006 16: 07: 18 Uhr 6 SCHWERPUNKT SCHWERPUNKT aktuell projekt M A N A G E M E NT 4/ 20 0 6 Hier betrug die Anzahl der Varianten, die ein Kunde bestellen konnte, etwa 13 Millionen! Durch ein strenges Variantenmanagement hat man beim Golf IV eine Reduzierung auf etwa 2 Millionen Varianten erreicht. Diese kurzen Ausführungen unterstreichen die Herausforderungen, die durch die Variantenvielfalt an das Management von Projekten gestellt werden. 2 Wesentliche Problemkreise gestern und heute und der Stand der Technik als Ausgangspunkt für die Lösungen von morgen 2. Die erzeugnisschaffenden Prozesse im Projekt - Das Produktzentrierte Projektmanagement (PZPM) Projekte setzen sich aus Prozessen zusammen. Sie werden in zwei Hauptkategorien aufgegliedert [6, 7]: o Prozesse des Projektmanagements: Sie beinhalten die Beschreibung und die Organisation/ Koordination der Tätigkeiten innerhalb des Projekts und der Projektvernetzung. Diese Prozesse werden beispielsweise im PMBoK vom PMI/ USA, im ICB der IPMA und in fast allen Fachbüchern zum PM beschrieben. Sie sind auch generell gültig für alle Branchen und Funktionsbereiche; o Produktprozesse befassen sich mit Spezifikation und Erstellung des Projektergebnisses, dem Projekt-Gegenstand bzw. dem Produkt (erzeugnisschaffende Prozesse). Produktprozesse lassen sich nicht über alle Branchen und Funktionsbereiche standardisieren. Produktprozesse sind spezifisch für einen Anwendungsbereich oder eine technische Disziplin. Der Schlüsselfaktor: PM-Prozesse und Produktprozesse für das betroffene Projekt sinnvoll bestimmen und effektiv vernetzen In Abb. 2 ist diese Situation wiedergegeben. Die Prozesse des Projektmanagements (Abb. 2 oben) steuern und überwachen die Produkt-Prozesse (Abb. 2 unten). Die Vorkoppelung im linken Teil bedeutet, dass ein Wissen über die projektspezifischen Produktprozesse zuerst einen gewissen Reifungsgrad erreicht haben muss, bevor die entsprechenden PM-Prozesse bestimmt werden können. Das Projektergebnis, das Produkt, entsteht mit den Produktprozessen, nicht mit den Prozessen des Projektmanagements. Diese werden nicht mehr benötigt, wenn das Projektergebnis erreicht ist. Das Projektergebnis, das Produkt, bleibt jedoch bestehen. PM- und Produktprozesse sind im hohen Maße miteinander vernetzt und beeinflussen sich über die gesamte Projektdauer. Diese Vernetzung ist ebenfalls branchen- und funktionsbereichstypisch und besitzt zudem noch einen dynamischen bzw. instabilen Charakter. Ein Terminplan kann in einem PM-Prozess nur aufgestellt werden, wenn eine ausreichende Kenntnis über die betroffenen Produktprozesse vorhanden ist. Andererseits bestimmt der Terminplan, welche Produktprozesse wann zu beginnen haben. Wir wollen ja am Ende eines Projektes primär ein funktionierendes Produkt erhalten und nicht Termine und Kosten einhalten und dabei ein minderwertiges Produkt in Kauf nehmen. Morris hat das treffend auf einen Nenner gebracht [8]. Bei einer Untersuchung von vier Branchen (Bauwesen, IT, Pharma und Aerospace & Defence) stellte er merkliche Unvollständigkeiten an den bisherigen PM-Modellen, zum Beispiel dem PMBoK des PMI [7] oder dem ICB der IPMA [9], fest. Diese Modelle mit ihren nachgeordneten Schulungen und Zertifizierungen gehen an dem realen Bedarf von Projektmanagern vorbei. Er machte zwei wesentliche Handlungssysteme des PM aus, die von den vorhandenen Modellen nicht unterstützt werden, aber zu den entscheidenden Aufgaben eines Projektmanagers gehören: 1. die strategischen Aktivitäten im Projekt, 2. das Management der fachlichen Inhalte, die Produkt- Technologie, das eigentliche Projektergebnis. Der zweite Punkt ist im obigen Kontext wichtig. Dazu zählt Morris unter anderem das Requirement-, Design-, Configuration- und Production-Management sowie das Produktprozesse/ Eng. Workflow Engineering Arbeiten - Facharbeit Projektmanagementprozesse Produktergebnis Projektstart planen, steuern + überwachen Vorkopplung Projektprozesse Abb. 2: Die Vernetzung von PM- und Produktprozessen [2, 6] KM Konfigurationsmanagement Steuerung der Änderungen Generierung der Produktstruktur PM Projektmanagement Management des Projektes, seiner Prozesse, zur Erreichung des Projektzieles, dem Projektergebnis PLM Produkt-Lebenszyklus-Mgt. Intelligentes, IT-bezogenes Mgt. aller Daten + Infos (Dokumente), die im Produktleben anfallen. Von der Idee über Produktion bis Entsorgung Menschen, die in Prozessen zusammenwirken und dabei Daten erzeugen + benötigen + Produktzentriertes Projektmanagement PZPM (Projekt- und Produktlebenszyklus-Management PPLM) Daten und Informationen, die durch eine integrierte Verwaltung konsistent und kompatibel gehalten werden müssen Abb. 3: Die Elemente des „Produktzentrierten Projektmanagements (PZPM)“ [1, 3, 4] PM_4_06.indd 16 26.09.2006 16: 07: 21 Uhr 7 projekt M A N A G E M E NT 4/ 20 0 6 aktuell Testing. Das sind die produkt- oder erzeugnisschaffenden Prozesse im Projekt. Daher titulierte er seine Arbeit mit „The irrelevance of project management as a professional discipline“! Lösungsansatz: Ein „Produktzentriertes Projektmanagement“ (PPM) ist zu gestalten und zu praktizieren, in dessen Zentrum die permanente Ermittlung des technischen Reifungsgrades steht, der wiederum die Basis einer integrierten Fortschrittsermittlung bildet, wie sie zum Beispiel im Earned-Value-Konzept verwirklicht ist. In Abb. 3 sind die Elemente eines „Produktzentrierten Projektmanagements“ in ihrer Wirkungskette dargestellt [1]: o Das erste Element ist das Projektmanagement, das Management der Projektprozesse zur Erreichung der Projektziele. o Das zweite Element ist das PLM, das Produkt-Lebenszyklus-Management: das Management aller Daten und Informationen bzw. Dokumente, die im Produktleben anfallen. o Das Konfigurationsmanagement und das Änderungsmanagement stellen ein verbindendes Glied dar. o Das Zusammenwirken dieser drei Elemente bildet das „Produktzentrierte Projektmanagement“. Wir haben also auf der einen Seite die Menschen, die in Prozessen zusammenwirken und dabei (Produkt-)Daten erzeugen. Und auf der anderen Seite die (Produkt-)Daten und Informationen, die integriert verwaltet werden. 2.2 Projektfortschrittsmessung im Projektcontrolling Historische Entwicklung: Seit Geburt des Projektmanagements vor 45 Jahren in der Aerospace & Defense- Branche der USA (DOD und NASA) stand eine realistische Ermittlung des Leistungsfortschritts (Performance Measurement oder Reifungsgrad des Produkts) im Projekt im Mittelpunkt. Von Anfang an waren die Definition und der Prozess der Ermittlung des Erfüllungsstandes von Produktzielen, des Reifungsgrads, ein Problemkreis, der nicht zufriedenstellend gelöst werden konnte. In den frühen 60er Jahren des letzten Jahrhunderts wurde vom DOD und der NASA das PERT/ COST-System entwickelt, das eine Projektfortschrittsmessung ermöglichen sollte. Die problembehaftete Ermittlung des technischen Erfüllungsstandes subsumierte (versteckte) man unter dem terminlichen Fortschritt. Revolutionär war aber die Definition eines Arbeits- oder Fertigstellungswertes (Value of Work), der die bis zum Überprüfungszeitpunkt fertiggestellten Arbeiten mit ihren geplanten Kosten bewertet und als Sollwert für einen Soll- Ist Vergleich dient. Damit konnte eine Prognose der zu erwartenden Termin- und Kostenüberschreitungen bzw. -unterschreitungen erfolgen. Der Autor machte diese Konzepte in den 70er Jahren des letzten Jahrhunderts in Europa und Deutschland bekannt [10, 11, 12] und diskutierte erfolgreiche Umsetzungen. Anzeige PM_4_06.indd 17 26.09.2006 16: 07: 24 Uhr 8 SCHWERPUNKT SCHWERPUNKT aktuell projekt M A N A G E M E NT 4/ 20 0 6 Ein Jahrzehnt später entstand aus dem PERT/ COST System das C/ SCSC (Cost/ Schedule Control System Criteria) des DOD, das den linearen Zusammenhang zwischen Zeitablauf und Kostenüberschreitung (der sich in der Praxis nicht bewährt hatte) aufhob. Der grundsätzliche Einbezug des technischen Erfüllungstandes in den terminlichen Fortschritt blieb bestehen und wurde als „Task Performance Control“ bzw. aufgabenorientierte Leistungsüberwachung bezeichnet. Earned Value Analysis: In den 80er Jahren des letzten Jahrhunderts wurde dieser Themenkreis auch außerhalb der Aerospace&Defense-Branche stärker diskutiert, wurde in noch handfestere Regeln gegossen und erhielt den Oberbegriff „Earned Value Analysis“. Der entscheidende Fertigstellungswert wird hier nun BCWP (Budgeted Cost of Work Performed) genannt und integriert den technischen Erfüllungsstand. Im Unterschied zum C/ SCSC kann die Bindung an den terminlichen Fortschritt aufgegeben und der jeweilige BCWP-Wert frei bestimmt werden. Das ist zwar sehr praktikabel, öffnet aber den Weg zur Ungenauigkeit. Die „Earned Value Analysis“ ist inzwischen internationaler Standard und in den beiden Standardwerken der beiden Weltverbände des Projektmanagements, dem PMBoK des PMI (USA) [7] und dem ICB des IPMA (Europa) [9], beschrieben. Kritischer Punkt bleibt aber weiterhin die Berücksichtigung des technischen Erfüllungsstandes (Produkt-Reifegrad) als Basis zur realistischen Abschätzung des BCWP. So wies Schelle darauf hin, dass die Earned Value Analysis - bleibt sie nur in der Hand von Betriebswirtschaftlern - zu einem gefährlichen Instrument ausarten kann, das die Realität nicht wiedergibt [13]. Zusammenfassend ist festzustellen, dass der Prozess der Ermittlung des Erfüllungsstandes von Produktzielen, des Reifungsgrads, seit Beginn des Projektmanagements ein Problemkreis ist, der nicht zufriedenstellend gelöst werden konnte. Die Folge ist, dass die Projektverfolgungssysteme den Projektfortschritt oft falsch widerspiegeln. Die Überwachungssysteme des Projektmanagements spiegeln den Projektfortschritt oft unzureichend und falsch wider! Lösungsansatz: Integration von Prozessen und ITK- Systemen: 1. eine Integration auf der Prozessebene von Projektcontrolling, Konfigurationsmanagement und Systems Engineering Management, 2. eine weitere Integration auf der Ebene von ITK-Systemen im Engineering (PLM = Product Lifecycle Management), in der Informatik (SKM = Software Konfigurations Management) und im Projektmanagement und 3. eine abschließende Integration der Prozesswelt (Punkt 1) mit der ITK-Welt (Punkt 2). Mit Hilfe der PLM- und SKM-Systeme und der Prozesse des Konfigurationsmanagements eröffnen sich neue Möglichkeiten zur realistischen Ermittlung des technischen Erfüllungsstandes. Eine eindeutigere und konsequentere Beurteilung einer integrierten Termin-/ Kosten-/ Leistungsbetrachtung ist damit möglich. Der Autor erläutert in seinem zweiten Beitrag in diesem Heft [14] diese Situation ausführlicher. Ebenso zeigt Jungkunz in diesem Heft eine PDM-basierende Lösung auf, die in diesem Kontext absolut neu und zukunftsweisend ist [15]. 2.3 Interdisziplinäre Zusammenarbeit Wie bereits in Kapitel 1 erläutert, besteht bei der Entwicklung von eingebetteten Systemen ein großes Defizit bei der notwendigen interdisziplinären Zusammenarbeit. Für ein eingebettetes System müssen die Bereiche Maschinenbau, Elektrotechnik und Informatik technisch eng verzahnt zusammenarbeiten. Hier prallen unterschiedliche Kulturen, Sprachen und Vorgehensweisen aufeinander, die leicht zu Missverständnissen und erheblichen Reibungsverlusten führen können. Die einzelnen Disziplinen entwickeln aneinander vorbei. Das übergreifende Projektmanagement kann diese Fehlentwicklungen fachlich nicht einschätzen. Erst bei der Integration der einzelnen Beiträge in das fertige Produkt werden die Fehler erkannt. Große Verzögerungen und Kostenexplosion sind die Folgen [3, 4]. Probleme der Abstimmung Ein Beispiel für verschiedene disziplinenspezifische Vorgehensweisen bzw. Prozesse, die eine effektive Zusammenarbeit erheblich erschweren, zeigt Abb. 4. Wenn der maschinenbautechnische Entwurf fertiggestellt ist und mit der Software abgestimmt werden soll, ist zu diesem Zeitpunkt die Softwareentwicklung noch mitten in der Analysephase und hat keinen Ergebnisstand für eine Abstimmung. Oder ein fertig codiertes Softwaremodul soll vor der Integration zum gesamten Softwareprodukt noch mit dem entsprechenden Geräteteil abgestimmt werden, aber das Geräteteil ist noch nicht fertig produziert. Auch hier findet sich kein entsprechender Ergebnisstand auf der Geräteseite. Lösungsansatz: Prozesse des Konfigurationsmanagements (KM): Es gibt somit keine zeitlich gemeinsamen Punkte zur interdisziplinären Abstimmung. Sie müssen „künstlich“ durch das Management geschaffen werden. Das Konzept des Konfigurationsmanagements gibt Hilfen, wie diese Situation durch ein prozessorientiertes interdisziplinäres Vorgehensmodell gelöst werden kann [16, 17]. 2.4 Organisatorische Integration kooperierender Unternehmen Es mangelt an Instrumenten für eine erfolgreiche Kooperation in allen Engineeringprozessen, insbesondere auch, wenn KMUs untereinander zusammenarbeiten wollen oder in ein Hersteller-Zulieferer-Netzwerk eingebunden sind. Die zielgerichtete effiziente Zusammenarbeit über die Grenzen von Disziplinen, Abteilungen und Unternehmen hinweg bleibt noch Wunschtraum. Zur Verwirklichung sind daher Integrations- und Kooperationskompetenz nötig. PM_4_06.indd 18 26.09.2006 16: 07: 24 Uhr 9 projekt M A N A G E M E NT 4/ 20 0 6 aktuell Lösungsansatz: Systematisches Management des Produktengineerings: Notwendig ist ein systematisches Management des Produktengineerings, und zwar vom Projektmanagement über das Konfigurationsmanagement (Entwicklungs- und Änderungsprozesse) bis zum Produktdatenmanagement (PDM) (Verteilung, Zugriff, Konsistenz, Produktstruktur). 2.5 Inkompatibilität der Tools bei Engineering und Management Reibungsverluste entstehen in interdisziplinären Produktentwicklungen aber nicht nur aus den Verständigungsproblemen zwischen den einzelnen Disziplinen und aus der Verwendung unterschiedlicher, zeitlich nicht abgestimmter Vorgehensweisen. Hinzu kommt auch oder vor allem die Inkompatibilität der in den verschiedenen Disziplinen verwendeten Werkzeuge. Jede einzelne Disziplin hat für sich Entwurfs-, Konstruktions- und Prüfwerkzeuge geschaffen, die das jeweilige Vorgehensmodell in den verschiedenen Phasen und bei dem Übergang von einer zur nächsten Phase unterstützen. Aber disziplinübergreifend ist eine Interaktion der IT-Tools nur schwierig zu verwirklichen, vergleiche Abb. 5 [3, 4]. Die Engineering-Tools: EDM/ PDM und SKM: Hinzu kommen für die einzelnen Ingenieursbereiche (bei Maschinen, Geräten, Anlagen, Gesamtsystemen) jeweils PDM-Systeme, die die anfallenden Produktdaten bzw. Dokumente und ihre Querbeziehungen verwalten und auch bereits Groupware- und Workflow-Unterstützung anbieten (Collaborative Engineering). Heute werden diese Systeme zu umfassenden PLM-Systemen ausgeweitet (PLM = Product Life Cycle Management). In diesem Heft geht Karcher ausführlich auf die Eigenschaften und Nutzenpotenziale von PLM ein [18] und Geckler beschreibt dieses aus der Anwendungssicht [19]. Im Informatikbereich werden für ähnliche Aufgaben sogenannte Software-Konfigurationsmanagementsysteme (SKM-Systeme) eingesetzt. Leider sind allgemeine SKM-Standards (wie sie in DIN EN ISO 10007 für KM festgelegt sind) in der Informatik noch nicht sehr verbreitet. Vor allem folgen wesentliche Begriffe im Informatikbereich nicht der DIN EN ISO 10007. Das erhöht die Missverständnisse. Projektmanagement-Tools: Im Projektmanagementbereich gibt es wieder eigene Projektplanungs- und -verfolgungssysteme, die manchmal in sogenannte ERP-Systeme eingebettet sind, oft aber auch „Stand alone“ eingesetzt werden. Eine Kopplung zwischen den Entwicklungssystemen der Ingenieure und Informatiker und den Projektmanagement- und ERP-Systemen fehlt aber, sodass die Über 20 Jahre Erfahrung bei Beratung und Implementierung von zukunftssicheren und praxisnahen Softwarelösungen. Le Bihan Consulting GmbH · Platter Strasse 79 · D-65232 Taunusstein · Tel. +49 6128 9665-0 · Fax -11 · lebihan.de · info@lebihan.de Transparente Projekte und Portfolios. Souveräne Entscheidungen. Erfolg ist planbar. PROFESSIONAL BUSINESS SOLUTIONS Anzeige Qualitätskontrolle Produktion Produkt.vorbereit. Konstrukt. Entwicklungsprozess von Gerät/ Hardware MASCHINENBAU Gesamttest Modulentwicklung Coding > Einzeltest Softwareentwicklungsprozess INFORMATIK Gesamtintegration Anforderung + Entwurf SYSTEM - Integriertes Produkt Analyse Design Anforderung + Entwurf KEINE GEM INSAMEN RELEASE-PUNKTE! ! E Abb. 4: Unterschiedliche Prozesse und Ergebnisstände bei Gerät/ Hardware und Software [2, 3] Maschinenbau Projekt x Elektrotechnik Projekt x Informatik Projekt x Gesamtsystem (Produkt) Projekt x ? ? .c ? Stückliste CAD Schaltplan Platinenlayout UML Source .c Prozesse Strukturen Management-Systeme IT-Systeme Abb. 5: Mangelnde Integration der IT-Systeme der einzelnen Disziplinen führt zu Inkonsistenzen in komplexen Entwicklungsprojekten [20, 21]; Quelle: SPM Consult/ Uni Paderborn PM_4_06.indd 19 26.09.2006 16: 07: 31 Uhr 20 SCHWERPUNKT SCHWERPUNKT aktuell projekt M A N A G E M E NT 4/ 20 0 6 Projektverfolgungssysteme den Projektfortschritt oft völlig falsch widerspiegeln. Lösungsansatz: Integriertes ERP/ PM/ PDM/ SKM- System: Zwischen den verschiedenen Disziplinen fehlt aber bisher eine entsprechende Werkzeugabstimmung, und es fehlt ein integriertes ERP/ PM/ PDM/ SKM-System, das disziplinenübergreifend Querbeziehungen und Stände aller Projektdateien verwaltet, Änderungsnachrichten verschickt, die Projektvorgänge überwacht und die projektweite Konsistenz sicherstellt. Genauso fehlt eine Integration zwischen den verschiedenen ERP/ PM/ PDM/ SKM-Systemen von Herstellern und Zulieferern [3, 4]. 3 Die grundsätzliche Strategie zur Meisterung der Komplexität Die in Kap. 1 dargelegten Situationen und Anforderungen lassen sich in zwei Dimensionen von Komplexität aufgliedern: o Komplexität der Umgebung von Projekten (z. B. dynamische Märkte, Globalisierung, Gesellschaft, Politik), o Komplexität des Projektes und des Produktes (z. B. neue Technologien, Interdisziplinarität). In Abb. 6 ist dieses mit den Maßen steigender Komplexität in Diagrammform dargestellt. Das Projektmanagement bisheriger Prägung - auch traditionelles PM genannt - deckt nur das Feld niedriger Komplexität ab. Für die Meisterung höherer Komplexität sind neue und ergänzende Ansätze erforderlich. Das traditionelle Managementverständnis (Projektmanagement 1. Ordnung - PM-1) basiert auf dem Steuerungsprinzip von Maschinen. Die Merkmale dieses Managementverständnisses sind: Anweisung, Controlling, Instrumente, Planbarkeit, Soll/ Ist, harte (eindeutige) Wirklichkeiten. Die internationalen Standardwerke des PM (PMBoK des PMI, ICB der IPMA, ISO 10006) beschäftigen sich fast ausschließlich mit diesem Verständnis von Projektmanagement. Lösungsansatz 1: Produktzentriertes PM (PZPM) auf Basis von Konfigurations- und Produktdatenmanagement: Das traditionelle Projektmanagementverständnis (PM-1) hat sich im Rahmen seines Denkmodells ständig weiterentwickelt, um höhere komplexe Situationen handhaben zu können. Allerdings gibt es hier eine Grenze, die durch die Eigenschaften des zugrunde liegenden Denkmodells gebildet wird. Mit dem Themenkreis des produktzentrierten PM im Kontext mit Konfigurations- und Produktdatenmanagement kann jedoch diese Grenze in Richtung erhöhter Komplexität noch erweitert werden, wie in Abb. 6 dargestellt. Eine Handhabung erhöhter Komplexität mit den eindeutigen Methoden der Welt des PM-1 wird dadurch machbar [1]. Lösungsansatz 2: Projektmanagement 2. Ordnung (PM-2) [20]: Im Forschungsprogramm „Neue Wege im Projektmanagement“ wurden von interdisziplinären Teams ab 1990 unter Leitung des Autors die Konsequenzen erarbeitet, die sich für das Projektmanagement aufgrund neuer Sichtweisen und Erkenntnisse in den Wissenschaften (z. B. Evolutions- und Chaostheorie, Synergetik, Kybernetik, Selbstorganisation, Hirnforschung, Komplexitätstheorie, Theorie sozialer Systeme) ergeben [21, 22]. Projektmanagement 2. Ordnung Eines der wesentlichsten Ergebnisse dieses Programms war die Definition des Konzepts eines „Projektmanagements 2. Ordnung (PM-2)“, das zur Meisterung hoher Komplexität und instabiler Situationen geeignet ist (Abb. 4). PM-2 versteht sich als eine wesentliche Erweiterung unter Einbezug neuer Paradigmen und Denkmodelle. Für Projekte in der verarbeitenden Industrie, auf die das produktzentrierte PM ja fokussiert, ist dieser zweite Lösungsansatz jedoch von geringerer Bedeutung. 4 Ausblick Für die in diesem Artikel beschriebenen Herausforderungen und Problemkreise wurden Lösungsansätze spezifiziert. Diese werden in einem weiteren Artikel des Autors in diesem Heft ausgeformt [14]. Auf der Website dieser Zeitschrift www.pmaktuell.org befindet sich eine erweiterte Fassung dieses Artikels, der zu wichtigen Themen vertiefende Darstellungen bringt, die aus Platzgründen in dieser Zeitschrift nicht gebracht werden konnten. Diese Arbeit wurde durch die „M. Saynisch-Projektmanagement-Stiftung (i. Gr.)“ gefördert (stiftung@spmconsult.de). n Literatur [1] Saynisch, M.: Projekt- und Produktlebenszyklus- Management - Teil I: Projekt-, Konfigurations- und Collaboration Management - Die Prozess- und Anwendungswelt. In: Rackelmann, G.; Schelle, H. (Hrsg.): Best Practice im Projektmanagement - 21. Internationales Deutsches Projektmanagement Forum 2004 in Nürnberg. Nürnberg 2005 [2] Saynisch, M.: Neue Prozesse und IT-Systeme zur Produktentwicklung in dynamischen Märkten - Projekt-, Konfigurations- und Systems-Management. In: Frick, A., Umgebungskomplexität (Märkte, Globalisierung) High Low Very High Medium Low Very High High Medium Produkt-/ Projektkomplexität (Technologien, Interdisziplinarität) Projektmanagement 2. Ordnung PM-2 Projektmanagement 1. Ordnung (PM-1) Produktzentriertes Projektmanagement (PZPM) Abb. 6: Komplexitätshandhabung durch Projektmanagement PM_4_06.indd 20 26.09.2006 16: 07: 32 Uhr 2 projekt M A N A G E M E NT 4/ 20 0 6 aktuell et al. (Hrsg.): Konferenz zur Zukunft des Projektmanagements „InterPM 2004“. Nürnberg 2004 [3] Saynisch, M.; Trapp, Th.; Schäfer, W.: Neue Konzepte des Projekt- und Konfigurationsmanagements für die kooperative Produktentwicklung. In: GPM (Hrsg.): Project Management for Winners. 18. Internationales Deutsches PM Forum. VisionWorks Congress, Berlin 2001 [4] Saynisch, M.; Schäfer, W.: Software in technischen Produkten - Eine neue Qualität im Projektmanagement: Die Schlüsselrolle von Konfigurationsmanagement. In: VDI-GSP: Projektmanagement Praxis. VDI-Bericht 1578, S. 143-155, Düsseldorf 2000 [5] Boehm, B.: Some Future Trends and implications for Systems and Software Engineering Processes. In: Systems Engineering, Vol. 9, Number 1, 2006 [6] Saynisch, M.; Mekelburg, G.: Neue Schlüsselfaktoren im Projektmanagement: Projekt-Prozesse-Differenzierung - Projekt-Systeme - Projekt-Office. VDI-Bericht 1578 „Projektmanagement-Praxis“, Düsseldorf 2000, S. 157-168 [7] PMI (Ed.): A Guide to the Project Management Body of Knowledge (PMBoK). PMI, Upper Darby, PA, USA, 1996-2000 [8] Morris, Peter: The Irrelevance of Project Management as a Professional Discipline. In: Congress proceedings 17th IPMA World Congress 2003, Moscow. www. ipma.ch [9] IPMA: ICB-IPMA Competence Baseline. Bremen 1999 [10] Saynisch, M.: Time/ Cost - Integrated Multiproject Information & Control System in Action. In: Proceedings of „INTERNET’72, 3. Internationaler Kongress für Projektmanagement in Stockholm - Congress book III. Stockholm 1972, S. 551-566 [11] Saynisch, M.: Integrierte Zeit- und Kostenplanung bei Entwicklungsprojekten, dargestellt an einem praktischen Beispiel. In: Huber, K., u. a. (Hrsg.): Waffensystemplanung. München/ Wien 1977 [12] Saynisch, M.: Die Projektkostenrechnung und ihre Integration mit dem betrieblichen Rechnungswesen. In: Saynisch, M., u. a. (Hrsg.): Projektmanagement - Konzepte, Verfahren, Anwendungen. München 1979 [13] Schelle, H.: persönliche Mitteilung in 2005 [14] Saynisch, M.: Projekt-, Konfigurations- und Collaboration Management - Die Welt der Prozesse und Arbeitsstrukturen im produktzentrierten Projektmanagement. In diesem Heft [15] Jungkunz, R. M.: PDM-basierte Überwachung komplexer Entwicklungsprojekte. In diesem Heft [16] Saynisch, M.: Schlüsselfaktor Konfigurationsmanagement (KM) - Lebensfähigkeit in dynamischen, globalen Märkten bei steigender Produkt-Komplexität. In: Saynisch, M.; Lange, D. (Hrsg.): Änderungsmanagement mit System - Schlüsselfaktor Konfigurationsmanagement. 3. Fachtagung Konfigurationsmanagement. GPM- Verlag, Nürnberg 1999, S. 100-127. Info zur Beschaffung des Buches: info@spm-consult.de [17] Saynisch, M.: Die neuen Herausforderungen an das Konfigurationsmanagement (KM) durch die digitale Revolution bei den Produktentwicklungsprozessen. In: HMD Handbuch der modernen Datenverarbeitung - Theorie und Praxis der Wirtschaftsinformatik. HMD 203, Heidelberg. September 1998 [18] Karcher, A.: Ganzheitliches Product Lifecycle Management (PLM) - Vom notwendigen Übel zum strategischen Erfolgsfaktor. In diesem Heft Anzeige PM_4_06.indd 21 26.09.2006 16: 07: 36 Uhr