PROJEKTMANAGEMENT AKTUELL
pm
2941-0878
2941-0886
UVK Verlag Tübingen
121
2006
174
GPM Deutsche Gesellschaft für Projektmanagement e. V.Die Stückliste ist die Mutter aller Daten
121
2006
Dieter Geckler
„Die Stückliste ist die Mutter aller Daten“. Mit dieser Regel überraschte mich mein erster
Projektleiter beim Berufseinstieg, als er mich in die Zusammenhänge einer unternehmensübergreifenden IT-Landschaft im produzierenden Gewerbe einführte. Während des Studiums hatte ich dieses unscheinbare Dokument nur als nebensächliche Pflicht betrachtet, mit zunehmender Berufserfahrung zeigt sich aber immer deutlicher, wie sich die Stückliste als roter Faden durch alle Prozesse eines Fertigungsunternehmens zieht. Dies gilt nicht nur für die Fertigungsprozesse und Materialwirtschaft während der Produktionsphase, sondern auch bei der Entwicklung und Projektierung neuer Produkte. Daher soll hier die Bedeutung der Stückliste als zentrale Informationsdrehscheibe und wichtiges Steuerungselement in Entwicklungsprojekten vorgestellt werden.
pm1740042
4 projekt M A N A G E M E NT 4/ 20 0 6 aktuell Die schwierigste Aufgabe im Sinne einer differenzierten Bewertung der IT-Umsetzung ist eine qualifizierte, das heißt an den jeweiligen unternehmensspezifischen Anforderungen ausgerichtete Reifegradermittlung. In [8] ist ein entsprechender Ansatz genauer ausgeführt. Abb. 6 zeigt die bei einer konkreten Anwendung des entwickelten Maturity-Modells bei einem mittelständischen Unternehmen resultierende Bewertung des aktuellen PLM- Umsetzungsgrades (Säulen), gespiegelt an den noch offenen Potenzialen (schwarze Balken). In diesem Anwendungsbeispiel wird deutlich, dass bezüglich Varianten- und Alternativenmanagement der aktuell erreichte Umsetzungsgrad die Anforderungen bereits sehr gut abdeckt, wohingegen im Bereich Produktstrukturmanagement noch weitere Potenziale erreichbar wären. Hier wird eine weitere Projektperspektive im Kontext von PLM erkennbar, nämlich die der stufenweisen PLM-Umsetzungsprojekte selbst, die sich in der Konsequenz der Spirale aus Abb. 5 bei jeweils einem Durchlauf ergeben. Auch hier zeigt die Erfahrung, dass heutige PLM-Projekte oft als einmaliges „Einführungsprojekt“ angelegt werden, sich dann aber aufgrund der in diesem Beitrag ausgeführten Gesamtproblematik oft als „Dombauprojekt“ entwickeln und leider nicht selten nach einer gewissen Zeit abgebrochen werden müssen. Auch hier ist sicherlich noch grundlegender Handlungsbedarf, was das Management komplexer IT-Projekte im Kontext von PLM vor allem unter der immer stärker hervortretenden Notwendigkeit der nachhaltigen Darstellung des „Business Value“ derartiger IT-Lösungen anbetrifft. Hier liegt sicherlich noch eine große Wegstrecke vor uns, bis aus der im Moment gerade aufkeimenden IT-Governance eine PLM-Governance wird, die vor allem auch kleineren und mittelständischen Unternehmen die Möglichkeit gibt, mit ihren Mitteln und Möglichkeiten die strategischen Potenziale von PLM zu erschließen. n Literatur [1] Abramovici, M.; Schulte, S.: PLM - Wege aus der Strategiekrise in der Automobilindustrie. In: eDM-Report - Data-Management-Magazin 1/ 2005, Heidelberg 2005 [2] Anderl, R.; Trippner, D.: STEP - Standard for the Exchange of Product Model Data. Stuttgart 2000 [3] Eigner, M.; Stelzer, R.: Produktdatenmanagement-Systeme - Ein Leitfaden für Product Development und Life Cycle Management. Berlin-Heidelberg 2001 [4] Geckler, D.: Die Stückliste ist die Mutter aller Daten - Produktdatenmanagement in der Anwendung. In diesem Heft [5] Jungkunz, R.: PDM-basierte Überwachung komplexer Entwicklungsprojekte. In diesem Heft [6] Karcher, A.: Projekt- und Produktlebenszyklusmanagement - Chancen, Nutzenpotenziale und Anforderungen von Produktdatenmanagement (PDM) und Product Lifecycle Management (PLM). 21. Internationales Deutsches Projektmanagement Forum, GPM Deutsche Gesellschaft für Projektmanagement, Nürnberg 2004 [7] Karcher, A.; Dettmering, H.; Arnold, V.; Engel, T.: Product Lifecycle Management beherrschen - Ein Anwenderhandbuch für den Mittelstand. Berlin-Heidelberg 2005 [8] Karcher, A.; Lehmann, T.: Werkzeuggestützte Reifegradermittlung für Anwendungssysteme im Product Lifecycle. Fachtagung IT-Controlling, St. Augustin 2005 [9] Moore, Gordon E.: Cramming more components onto integrated circuits. Original-Veröffentlichung 1965, Download unter ftp: / / download.intel.com/ research/ silicon/ moorespaper.pdf [10] OMG: PLM Services V 1.0. Convenience Document, 2005, www.omg.org/ cgi-bin/ doc? dtc/ 2005-03-08 [11] ProSTEP iVip: Projekt „Collaborative Project Management“. 2006, www.prostep.org/ de/ projektgruppen/ cpm, Zugriff am 14. 3. 2006 [12] Saynisch, M.: Produktzentriertes Projektmanagement im Kontext von Product Lifcycle. In diesem Heft Schlagwörter Architektur von PDM-Systemen, Dokumentenzentrierung, Integriertes Produktmodell, IT-Unterstützung im Product Lifecycle, kontinuierliches Vorgehensmodell, PLM-Reifegradermittlung Autor Andreas Karcher, Univ.-Prof. Dr.-Ing. Dipl.-Inform., studierte Informatik an der Universität Fredericiana zu Karlsruhe und war danach fünf Jahre bei einer Karlsruher Unternehmensberatung im Bereich Industrielle Informationstechnik tätig. 1992 trat er am Lehrstuhl für Informationstechnik im Maschinenwesen der Technischen Universität München eine Stelle als Akademischer Oberrat an. Nach seiner Promotion 1996 baute er dort den Forschungsbereich „PDM und Product Lifecycle Informationssysteme“ auf, führte unterschiedliche sowohl grundlagenals auch industrieorientierte Forschungsprojekte durch und verankerte diese Thematik erfolgreich in der Ingenieurausbildung. Im Frühjahr 2004 trat er eine Professurvertretung für Wirtschaftsinformatik an der Universität der Bundeswehr München an und wurde ein halbes Jahr später an der Fakultät für Informatik der Universität der Bundeswehr München auf eine Professur für Softwarewerkzeuge und Methoden für integrierte Anwendungen berufen. Er hat langjährige Erfahrung im Bereich PDM/ PLM und ist u. a. Mitautor des Buches „Product Lifecycle Management beherrschen“, das 2005 im Springer-Verlag erschienen ist. Schwerpunkte seiner aktuellen Arbeit sind u. a. Product Lifecycle Management, Informationsintegration und Middleware, Wissensmanagement und logikbasierte Entscheidungsunterstützungssysteme sowie Methodisches Customizing und IT-Governance. Anschrift Professur für Softwarewerkzeuge und Methoden für integrierte Anwendungen Fakultät für Informatik Universität der Bundeswehr Werner-Heisenberg-Weg 39 D-85577 Neubiberg Tel.: 0 89/ 60 04-22 08 Fax: 0 89/ 60 04-30 36 E-Mail: andreas.karcher@unibw.de http: / / wi.informatik.unibw-muenchen.de PM_4_06.indd 41 26.09.2006 16: 08: 21 Uhr 42 SCHWERPUNKT SCHWERPUNKT aktuell projekt M A N A G E M E NT 4/ 20 0 6 Produktstruktur Die Produktstruktur (Stückliste) definiert die Struktur und Zusammensetzung eines Produktes und begleitet es über den gesamten Produktlebenszyklus (siehe auch Abb. 1 in [6] in diesem Heft). Während des Entwicklungsprozesses fasst sie alle Produktdaten zusammen und steuert so die Entwicklungsaktivitäten. Während der Produktionsphase ist sie Datenrückgrat der Fertigungs- und Logistikprozesse. Je nach Branche unterliegt sie unterschiedlichen Bezeichnungen, so spricht der Maschinenbau von der Stückliste, die Lebensmittelindustrie von einer Rezeptur, die branchenneutrale Bezeichnung ist der Begriff Produktstruktur. Im Folgenden wird der Begriff Stückliste verwendet, um auf die Verwendung in der Automobilentwicklung hinzuweisen. In der Automobilindustrie treffen die unterschiedlichen Komplexitätsmerkmale von Stücklisten in besonderer Form zusammen: Der Teileumfang umfasst die Strukturtiefe einer komplexen Maschine, die Produktvarianz übertrifft oft die Bandbreite eines Einbauküchen- Herstellers, gleichzeitig ist sie Basis für eine Massenproduktion und muss die Daten für ein individuelles Endprodukt in Sekundenbruchteilen ableiten. Auch die Problematik der Chemischen- und der Lebensmittelindustrie, die sich teilweise auf unterschiedliche Eigenschaften der Komponenten je nach Wettersituation oder Ernteergebnissen einstellen müssen, erfordern im Automobilbau im Lackierereibereich und beim Einsatz von Naturprodukten eine Berücksichtigung. Stücklisten steuern Fertigungs- und Entwicklungsaufgaben in allen Branchen, seit es Schrift und organisierte Industriebetriebe gibt. Zu Beginn wurden sie schriftlich festgehalten, waren ein fester Anhang der Konstruktionszeichnungen und wurden für Fertigungs- und Dispositionsaufgaben manuell umgewandelt und abgeschrieben. Mit dem Aufkommen der ersten industriell eingesetzten Computer in den 60er Jahren wurden Stücklistensysteme zunächst vorwiegend für Aufgaben der Materialwirtschaft (MWS) genutzt und steuerten Lagerbestände und Bestellungen. Der Funktionsbereich wurde in den 70er Jahren um die Fertigungssteuerung (PPS = Produktionsplanung und -steuerung) erweitert. In den 80er Jahren wurden diese Aufgaben im ERP (Enterprise Resource Planning) vereinigt. Seit den 90er Jahren werden zunehmend wieder die Stücklistenaufgaben der Entwicklung (PDM = Produkt Daten Management) in den Gesamtfluss integriert. So zeichnet sich heute ab, dass mit PLM (Product Lifecycle Management) endlich alle Stücklistenaufgaben, die früher manuell übertragen wurden, durchgängig rechnergestützt bewältigt werden. Die lange Entwicklungsdauer der Systeme zeigt aber die hohe Komplexität der Aufgabe, die nicht nur große Datenmengen, sondern auch extrem komplexe logische Strukturen bewältigen muss. Mit zunehmender Produktkomplexität und Fertigungsvielfalt (siehe Artikel [12] in diesem Heft) wachsen aber die logischen Anforderungen an Stücklisten kontinuierlich mit. Hinzu kommen ständig neue Anforderungen und Möglichkeiten von Systemen zur Produktentwicklung (CAD), Fertigungsplanung (Digitale Fabrik), Fertigungssteuerung (PPS) und Materialdisposition (MWS). So wird die gesamte Stücklistenthematik in absehbarer Zeit weiterhin ein komplexer und spannender Forschungsgegenstand bleiben. Aufbau und Elemente von Stücklisten Um all den unterschiedlichen Anforderungen gerecht zu werden, ist die Stückliste in einem Fertigungsunternehmen gleichzeitig in unterschiedlichen Formen verfügbar. Mit zunehmender Erforschung und Definition der logischen Zusammenhänge kann sie in zunehmendem Maße durch rechnergestützte Intelligenz von einer Form in die andere gewandelt werden. Die Stückliste ist die Mutter aller Daten Produktdatenmanagement in der Anwendung Dieter Geckler „Die Stückliste ist die Mutter aller Daten“. Mit dieser Regel überraschte mich mein erster Projektleiter beim Berufseinstieg, als er mich in die Zusammenhänge einer unternehmensübergreifenden IT-Landschaft im produzierenden Gewerbe einführte. Während des Studiums hatte ich dieses unscheinbare Dokument nur als nebensächliche Pflicht betrachtet, mit zunehmender Berufserfahrung zeigt sich aber immer deutlicher, wie sich die Stückliste als roter Faden durch alle Prozesse eines Fertigungsunternehmens zieht. Dies gilt nicht nur für die Fertigungsprozesse und Materialwirtschaft während der Produktionsphase, sondern auch bei der Entwicklung und Projektierung neuer Produkte. Daher soll hier die Bedeutung der Stückliste als zentrale Informationsdrehscheibe und wichtiges Steuerungselement in Entwicklungsprojekten vorgestellt werden. PM_4_06.indd 42 26.09.2006 16: 08: 21 Uhr 43 projekt M A N A G E M E NT 4/ 20 0 6 aktuell Die einfachste Form ist die „Mengenstückliste“. Sie umfasst nur zwei Elementklassen. Der „Stücklistenkopf“ benennt die Eigenschaften des zu fertigenden Produktes, die „Positionen“ die Art und Menge der Bestandteile des Produktes. Mit der Mengenstückliste kann auf einfachste Art sämtliches Material zur Fertigung eines Produktes bestellt werden. In der Fertigungsphase ist sie zusammen mit der Lagerbestandsliste und dem Auftragsbestand Basis für die Materialwirtschaft. In der Entwicklungsphase dient die Mengenstückliste als Checkliste, welche Einzelteile neu zu konstruieren sind. In modernen Softwarearchitekturen verlinkt sie zu jeder Einzelposition mit allen zugehörigen Konstruktionsdaten und wird so zur zentralen Informationsdrehscheibe. Jede Stücklistenposition wird so zu einem Informationsknoten, der unterschiedliche Informationsketten miteinander verbindet. Typische Konstruktionsunterlagen sind dabei der Anforderungskatalog, CAD-Modelle, bemaßte Zeichnungen, Muster-Prüfberichte sowie Angaben über mögliche Lieferanten. Eine Stufe detaillierter wird die „Individualstückliste“. Sie wird beim Versuchsbau sowie der Wartung und Dokumentation sicherheitsrelevanter Teile notwendig. Bei einem Flugzeug ist es beispielsweise wichtig, nicht mehr einfach mit der Angabe „zwei Triebwerke“ zu leben, sonders jedes einzelne ist mit seinem eigenen Lebenslauf wie den Prüf- oder Wartungsberichten zu versehen. In einer vollständig aufgelösten Individualstückliste wird daher jedes Individuum separat betrachtet, und jede Mengenangabe ist auf „eins“ heruntergebrochen. Dies ist auch bei dem Aufbau von CAD-Modellen des Gesamtproduktes notwendig, wo jedem Einzelteil eine individuelle Position und Einbaulage im Gesamtmodell zugewiesen wird. „Terminierte Stückliste“ und „Strukturstückliste“ Noch detaillierter wird die „terminierte Stückliste“. Sie zeigt nicht nur einen Bauzustand des Produktes, sondern enthält zusätzlich Angaben über die Historie als auch die aktuelle Planung. Dazu erhält jede Stücklistenposition einen zeitlichen Gültigkeitsschlüssel, der angibt, ab wann eine einzelne Position in der Stückliste eingesetzt wird und wann sie abgelöst wird oder ausläuft. Zusammengefasst in der Terminsequenz ergeben die Zeitschlüssel einen Zeitgraphen als zweiten komplexen Bestandteil einer Stückliste. Durch die Gliederung der einzelnen Elemente einer Stückliste ergibt sich die „Strukturstückliste“. Sie zeigt in einem meist mehrstufigen Aufbau je nach Betrachter unterschiedliche Sichten zwischen dem Produktknoten und den einzelnen Positionen. So muss etwa der Elektroentwickler einer Lichtanlage alle elektrischen Elemente seines Verantwortungsbereichs im Zusammenhang der „Entwicklungsstruktur“ betrachten. In der „Fertigungsstruktur“ finden sich diese Teile dann aber möglicherweise in ganz anders gruppierten Baumodulen wie dem Kabelstrang, den Scheinwerfern oder Schalt- und Sicherungsbaugruppen wieder. Daneben kann die Kostenrechnung eine in Details anders geartete „Kostenstruktur“ des Gesamtproduktes betrachten. Schließlich kann der Vertrieb die einzelnen Bestandteile in einer Abb. 1: Stücklistenknoten: An einer Verwendungsstelle (blaues Dreieck) spezifiziert das Varianzschema (blaues Rechteck) unterschiedliche Ausführungen (orangefarbiger Punkt) [7]. PM_4_06.indd 43 26.09.2006 16: 08: 24 Uhr 44 SCHWERPUNKT SCHWERPUNKT aktuell projekt M A N A G E M E NT 4/ 20 0 6 an den Kundenbedarf angepassten „Ersatzteilstruktur“ wiederum anders bündeln. Um eine Vollständigkeitsprüfung der verschiedenen Struktursichten zu ermöglichen, wird eine Produkt-Basisebene definiert. Diese umfasst alle Detailpositionen, die im Betrachtungshorizont des Unternehmens liegen. So wird ein Fahrradhersteller die Glühbirne des Rücklichtes nicht in seine Bestandteile auflösen, da eine separate Betrachtung von Glühfaden und Glaskörper nur für deren Hersteller relevant ist. Erhält er das vollständige Rücklicht als vormontiertes Modul, so kann sogar die Glühbirne aus seinem Interessenbereich verschwinden und in seiner Stückliste ist nur noch das Gesamtmodul aufgeführt. Komplex wird die Betrachtung, falls er die Komponente in der Fertigung nicht separiert, wohl aber im Ersatzteilwesen. Bietet ein produzierendes Unternehmen mehrere Varianten eines Produktes an, so baut es eine „Variantenstrukturstückliste“ auf. In dieser bezeichnen die einzelnen Stücklistenpositionen nicht ein einzelnes Teil, sondern einen Variantenknoten [9]. Bietet der Fahrradhersteller Produkte mit unterschiedlichen Beleuchtungssystemen an, so sind an der „Verwendungsstelle Rücklicht“ mehrere Ausführungen möglich. Welche Variante gewählt wird, bestimmt das Varianzschema, das die möglichen Varianten in ihrer logischen Gültigkeitsstruktur zusammenfasst. In dem Beispiel Rücklicht sind möglicherweise die Kriterien Farbe, Bauart, Befestigungsart und Stromversorgung zu beachten. Zu jedem Kriterium gibt es mehrere Ausführungsmöglichkeiten. Neben der reinen Aufzählung möglicher Elemente wird das Varianzschema um Regeln ergänzt. Diese bestimmen dann beispielsweise, dass eine batteriebetriebene Lampe nicht geschraubt befestigt wird, um ein Nachladen zu vereinfachen, und nur in schwarz erhältlich ist. Abb. 1 zeigt eine solche Varianz an einem Knoten der Verwendungsstelle „Bremse“. Die terminierte Variantenstruktur umfasst somit die gesamte Produktpalette einer Produktfamilie und dient als Referenz für die Fertigung. Soll nun ein einzelnes individuelles Produkt gefertigt werden, wird aus der Referenz eine „Auftragsstückliste“ abgeleitet. Dabei werden Termin- und Varianzregeln angezogen. Ergebnis ist eine individualisierte Stückliste, die das Produkt im Fertigungsprozess begleitet. Im Falle einer Sonderanfertigung kann diese Stückliste auftragsspezifisch modifiziert werden. Wird das Endprodukt des Unternehmens in einzelnen Modulen vorgefertigt, so sind deren Komponenten in einer „Baukastenstückliste“ zusammengefasst. Sie ermöglicht eine vom Endkunden unabhängige Vordisposition der Baugruppen in wirtschaftlichen Losgrößen. Eine Sicht aus der Perspektive eines Einzelteils auf die Stückliste bietet der „Verwendungsnachweis“. Er zeigt an, in welchen Baugruppen, Varianzkombinationen und Endprodukten ein bestimmtes Einzelteil Verwendung findet. Diese Abfrage wird bei der Materialdisposition wichtig, aber auch wenn ein Einzelteil konstruktiv oder durch Wechsel des Lieferanten in allen Produkten geändert werden soll. Eine Zusammenfassung der Ebenen einer Variantenstrukturstückliste zeigt Abb. 2. Von der Stückliste abgeleitete Daten Als terminierte Variantenstruktur mit angebundenen Zeitgrafen, Varianzschemen, Regeln, Auftrags- und Baukastenstücklisten ist die Stückliste in sich schon ein sehr komplexer Datencluster. Im Laufe eines Entwicklungsprojekts werden an diese Grundstruktur weitere Daten angebunden (siehe Abb. 3). Die eigentliche Entwicklungsarbeit erfolgt anhand von CAD- und PDM-Systemen (siehe Artikel [6] in dieser Ausgabe). In diesen wird jeweils ein Teil der gesamten Stücklistenkomplexität in einer systemeigenen Produktstruktur geführt. Abb. 2: Elemente einer Variantenstrukturstückliste [7] (nach [9]) PM_4_06.indd 44 26.09.2006 16: 08: 26 Uhr 45 projekt M A N A G E M E NT 4/ 20 0 6 aktuell Der „Arbeitsplan“ („blaue Rechtecke“ in Abb. 3) beschreibt die Anfertigung jeder Variante der Einzelteile einer Stückliste sowie den Gesamtzusammenbau des Endproduktes. Er ist ebenso eine Informationsdrehscheibe und verlinkt auf fertigungsrelevante Daten wie Berechnungen zu Arbeitsprozessen, Simulationen mit den Werkzeugen der Digitalen Fabrik bis hin zu Werkerschulungen. Der Arbeitsplan dient darüber hinaus als Grundlage zur Berechnung von Fertigungszeiten und deren Kosten. Zusammen mit dem Arbeitsplan entsteht die „Ressourcenstruktur“ („gelbe Ovale“ in Abb. 3), die alle Fertigungseinrichtungen („rote Sechsecke“ in Abb. 3), Betriebspersonal und Betriebsmittel beschreibt, die notwendig sind, um das Endprodukt zu fertigen. Diese Struktur bietet die Basis für den Investitionsplan zur Kalkulation der Produktinvestitionen („Projektstruktur Investition“ in Abb. 3) sowie für den Strukturplan zur Projektierung der einzelnen Fertigungseinrichtungen. Der „Materialflussplan“ stellt die Materialflüsse zu jeder einzelnen Stücklistenposition zwischen den verschiedenen Fertigungsstellen eines Standortes, den Werken eines Konzerns sowie von den Lieferanten dar. Dieser Plan ist die Grundlage zur Auslegung der Logistikeinrichtungen. Aus ihm werden die Logistikkosten und die dafür erforderlichen Zeiten abgeleitet. Eine der Hauptaufgaben der Stücklisten ist es, nach Fertigungsbeginn den „Materialbestand“ und den primären (kundenbezogenen) sowie sekundären (komponentenbezogenen) „Auftragsbestand“ der Fertigung zu Anzeige Abb. 3: Die Stückliste als Bindeglied zwischen Projektstrukturplan sowie Arbeitsplan, Layout-Struktur und Investitionsbedarf [7] PM_4_06.indd 45 26.09.2006 16: 08: 30 Uhr 46 SCHWERPUNKT SCHWERPUNKT aktuell projekt M A N A G E M E NT 4/ 20 0 6 steuern. Diese Aufgaben setzen jedoch erst nach Abschluss des Entwicklungsprojekts ein. Während des Entwicklungsprojekts leitet sich von der Stückliste der Aktivitätenplan der Entwicklung („Projektstruktur PEP“ in Abb. 3) ab, der die Entwicklung, Realisierungsmaßnahmen sowie die vielen unterschiedlichen Versuchsbauten und Testabläufe umfasst. Darauf aufbauend entsteht der „Terminplan“ auf der Basis teilebezogener Netzpläne, während der „Kostenplan“ die Entwicklungskosten, Fertigungsinvestitionen, Fertigungszeiten und Zulieferkosten je Teil umspannt und so die Gesamtkosten der Produkte ermittelt. Da all diese Daten an die Produktstruktur angebunden sind, werden auch sie varianten -und terminabhängig, da sie nur dann den richtigen Stand abbilden, wenn in ihnen Produktänderungen und Änderungen am Fertigungsprozess richtig dokumentiert sind. Lebenslauf einer Stückliste Wenn die Stückliste zu Beginn des Entwicklungsprojekts gleich in der richtigen Form vorliegen würde, könnten die darauf aufbauenden Pläne wie die Projektaktivitäten, Termin- und Kostenpläne gleich zu Projektbeginn in der endgültigen Form festgelegt werden. Nun ist aber die Stückliste selbst Gegenstand des Entwicklungsprozesses, sodass ihre Positionen erst im Projektverlauf unter ständigem Abgleich mit den anderen Daten entstehen. Am Anfang steht eine Referenzstruktur Um sich in diesem Dilemma zu behelfen, beginnt man in der Regel mit einer Referenzstruktur, die Elemente aus bereits abgeschlossenen Projekten in einer am neuen Produkt orientierten Form umfasst. Diese Struktur wächst infolge einer zunehmenden Reife und Detaillierung gemeinsam mit den angelehnten Daten [13]. Über stufenweise angeordnete Prozess-Gates wird dieser parallele Prozess synchronisiert. Dabei werden die Daten für eine nachfolgende Planung in unterschiedlichen Detaillierungsstufen freigegeben. Ein erster Schritt ist das Lastenheft, das die Produkteigenschaften in seinen wesentlichen Eckpunkten spezifiziert. In den Stücklistendaten schlägt sich dieses im Wesentlichen in den Varianzschemen sowie den dazugehörigen Logikregeln nieder. Nach der Festlegung der ersten Positionen erfolgt deren Taufung, in der die Zuordnung von Hausanfertigung und Fremdbezug bestimmt wird. Ein nächster Schritt ist die Planungsfreigabe, ab welcher die Ausplanung des Fertigungsprozesses der im eigenen Hause gefertigten Teile beginnt. Parallel dazu erfolgt die Auswahl geeigneter Lieferanten für die Kaufteile. Ab der Beschaffungsfreigabe erfolgt die Verpflichtung der genehmigten Investitionsmittel an die externen Projektpartner. Haben alle Lieferanten und Hausanfertigungen ihre Konstruktionen abgeschlossen und sind alle Logistik- und Beschaffungsschritte vorbereitet, so erfolgt die Dispositionsfreigabe, ab der einzelne Stücklistenpositionen verbindlich bestellt werden und die Stückliste so in den Produktivbetrieb übergeht. Änderungsmanagement Durch die parallele Definition der unterschiedlichen Arten der Konstruktions-, Beschaffungs- und Fertigungsdaten ist es von Projektbeginn an erforderlich, mit unscharfen Daten zu arbeiten [1]. Diese gewinnen erst im Projektverlauf an Präzision und Detailliertheit. Um sich diesen Umstand zu verdeutlichen, wurde einmal der Satz geprägt: „Ein Entwicklungsprojekt beginnt mit einer einfachen Skizze auf der Serviette des Vorstandes und endet in der Detaillierung von einigen Terabyte unterschiedlicher Daten - alles dazwischen ist Änderungsmanagement.“ Wobei in diesem Zusammenhang unter Änderung im Wesentlichen nicht die Korrektur eines Fehlers zu verstehen ist. Wesentlich häufiger ist die Änderung einfach eine zunehmende Detaillierung des aktuellen Konstruktionsstandes, also ein einfacher Arbeitsfortschritt. Nur in wenigen Fällen ist es aber auch die Reaktion auf einen negativen Prüfbericht oder die Anpassung an eine projektexterne Veränderung, wie die Anpassung an eine Innovation eines Lieferanten oder absehbare Modifikationen gesetzlicher Vorschriften. In größeren Entwicklungsprojekten unter der Beteiligung mehrerer global verteilter Teams ist es zwingend notwendig, dass alle mit demselben Informationsstand arbeiten [3]. Daher ist schon seit Ende des letzten Jahrtausends Microsoft dazu übergegangen, alle Softwareneuerungen täglich zusammenzusammeln und am nächsten Morgen allen Projektteams neu zur Verfügung zu stellen. Dies ist bei Softwareentwicklungen durch die Übertragungsfähigkeit über Datennetze möglich. Bei physikalischen Produkten ist dies jedoch nur mit der Informationsrepräsentation der einzelnen Komponenten möglich. Um den einzelnen Projektbeteiligten zu ersparen, dass sie die neuen Arbeitsergebnisse selbst in dem gesamten Informationscluster suchen müssen, werden sie durch „Änderungsanträge“ (ECN = Engineering Change Number) dokumentiert (siehe Abb. 4). Diese können den Betroffenen direkt zugestellt werden. Somit sind sie in der Lage, die für sie relevanten Informationen direkt zu finden. Damit sichergestellt wird, dass die Projektbeteiligten nicht mit alten Ständen arbeiten, ist es für einen stabilen Projektablauf erforderlich, dass die Betroffenen möglichst zeitnah auf die Änderungen reagieren. In der Masse sind dies Freigaben oder präzisere Detaillierungen, in wenigen Fällen verändern sie die Annahmen einer bisherigen Konzeption und führen zu Folgeänderungen. Ist dieses der Fall, so sind die Konsequenzen unmittelbar zu bewerten. Führen sie zu Veränderungen an den Produkteigenschaften oder den Herstellkosten, so ist die Änderung in einem gesonderten Verfahren vom Management zu genehmigen. Bei größeren Umfängen können solche genehmigten kostenverursachenden Änderungen zu einem eigenen kleinen Projekt werden und erhalten dann ein eigenes Projektteam, Projektbudget, einen eigenen Terminplan und alle weiteren notwendigen Ausstattungen. Dies wird durch den angedeuteten Terminplan in Abb. 4 symbolisiert. Der linke Teil der Abb. 4 stellt dar, dass sich die CAD- Daten der Konstruktion in einer höheren Sequenz ändern PM_4_06.indd 46 26.09.2006 16: 08: 30 Uhr 47 projekt M A N A G E M E NT 4/ 20 0 6 aktuell können als die in der Stückliste dokumentierten Änderungen der Teilenummer. Die Verbindung zum Baustand zeigt an, dass nicht jeder Entwicklungsfortschritt in den Baustand eines Prototypen oder Vorserienfahrzeuges einfließen muss. Wie die Simulation von Projektabläufen unter Änderungsbelastung zeigt, bestimmt die Ausführungsdauer von Änderungsprozessen wesentlich die Gesamtprojektdauer [3]. Dabei entstehen die Änderungen in einer Entwicklungsphase in den meisten Fällen durch weitere Ausdetaillierung des Konstruktionsstandes und die Einarbeitung von Validationsergebnissen. Sie sind damit natürlicher Bestandteil solcher Projektphasen [2], nur in wenigen Fällen werden sie durch die Korrektur echter Fehler verursacht. Dies ist der Fall, bis alle Gesichtspunkte des gesamten Konstruktionsstandes gemeinsam ausgereift sind [4]. Der in der Stückliste dokumentierte Reifegrad des Konstruktionsstandes wird somit zum Maß über den gesamten Entwicklungsstand. Diese Zusammenhänge sind im Artikel [5] in dieser Ausgabe detaillierter beschrieben. Die heute üblichen Produktionsentstehungsprozesse bei Großserienentwicklungen sind durch Simultaneous- Engineering [8] so weit überlappend angeordnet, dass dies häufig bis zum Abschluss des gesamten Entwicklungsprojekts gilt. Damit wird das Änderungsmanagement der Stückliste als Konfigurationsmanagement [10] zu dem zentralen Steuerungselement für die Projektleitung technischer Entwicklungen. Dies zeigte sich auch als Tenor in den Gesprächen der OEM (Original Equipment Manufacturer) bei der GPM-Expertentagung zum „Collaborative Automotive Project Management“, 2005 in München. Fazit Stücklisten sind in heutiger Zeit hochkomplexe Strukturen und bilden das Datenrückgrat für die Projektierung von Produktneuentwicklungen und die anschließende Fertigungsphase. Mit wachsender Produkt- und Fertigungskomplexität werden sich die unterschiedlichen stücklistenbasierten Systemwelten kontinuierlich weiterentwickeln. Im hier behandelten Fokus auf die Projektierung von Produktentwicklungen am Beispiel der Automobilindustrie ist die Stückliste Basis für den Projektstrukturplan des Gesamtprojekts, aber auch für zahlreiche abgeleitete Teilprojekte wie Produkttestphasen oder die Projektierung des Neubaus oder der Restrukturierung von Fertigungsanlagen. Damit leiten sich von der Stückliste alle finanz-, termin- und qualitätssteuernden Aufgaben der Projektleitung ab. Grundlage für erfolgreiche Projekte ist daher eine transparente Durchgängigkeit aller auf der Stückliste basierenden Daten und Systeme. Dabei durchläuft die Stückliste während der Entwicklungsphase selbst einen kontinuierlichen Entwicklungsprozess. Ihr muss daher das Kunststück gelingen, selbst erst während der Entwicklung heranzureifen und andererseits alle anderen Daten synchron zusammenzuhalten. Dieses ist nur durch ein konsequent koordiniertes Konfigurationsmanagement möglich. n Literatur [1] Clark, K.; Fujimoto, T.: Automobilentwicklung mit System. Frankfurt/ M. 1991 [2] Dylla, N.: Denk- und Handlungsabläufe beim Konstruieren. München 1991 [3] Geckler, D.: Änderungsschleifen in Fahrzeugprojekten, Abb. 4: Änderungsterminierung und Kopplung zwischen Stücklisten- und CAD-Standsdaten in einer Variantensequenz [7] PM_4_06.indd 47 26.09.2006 16: 08: 33 Uhr