Category: Practice

Der Begriff [‘mänätschmänt] blickt auf eine langjährige Karriere als inhaltsleere Füllwortmasse in allen Bereichen des Lebens zurück. Im Wesentlichen ist sie dazu da, das Ausatmen bei der Vertonung komplexer Wortgebilde zu erleichtern. Und auch unser aller Lieblingsabkürzung wurde leider nicht davon verschont – wo sie doch mit „P“ und „L“ so einen schmissigen Anfang genommen hat.

Machen wir das Beste draus, wagen wir das Experiment, das „M“ einmal ernst zu nehmen. Was wäre denn die Quintessenz vom „managen“ beim „productlifecyclen“? Kosten im Griff behalten – ja klar, zentral wichtig, aber im Kern die Ägide des Controllings. Termine? Macht das Projektmanagement (hoffentlich). Last but not least: Der Kern des „PL-“ Managements liegt für mich darin, den Reifegrad des Produktes unter Kontrolle zu haben.

Reifegrad hat dabei zwei Perspektiven:

1. Der Grad, in dem ein Produkt das macht, was es soll.

2. Der Grad, in dem das Produkt so hergestellt werden kann, wie man es haben will.

Diese beiden Sichtweisen werden gerne als Produkt- und Prozessreifegrad bezeichnet

Um so einen Reifegrad zu bestimmen oder gar zu steuern, ist es von Vorteil, erst einmal zu beschreiben, wogegen man messen will. Ich hätte dazu noch einen Begriff mit Füllwortende im Angebot: Anforderungsmanagement. Mit dem Vehikel „Anforderung“ beschreibe ich klassisch, was ein Produkt machen soll. Reicht aber nicht! Ich muß auch beschreiben, wie ich ein Produkt herstellen will! Das nennt sich dann „Front-Loading“ und hilft ganz gewaltig, den Zielraum für eine Produktentwicklung zu konkretisieren.

Wie aber das Wort „Entwicklung“ schon sagt, steuere ich hier gegen ein bewegliches Ziel, Produkt und Prozess wachsen weiter, machen manchmal auch einen Schritt rückwärts. Der Reifegrad muß also auch ein Ausdruck dafür sein, wie erfolgreich meine verschiedenen Konzeptalternativen sind bzw. wie weit ich den Trichter möglicher Optionen schon eingeengt habe (letztes Buzzword für heute: Set-Based Engineering).

So ergibt sich ein Korridor von Fakten, gegen den die Produktentwicklung reflektiert werden kann: Hat meine Entwicklung alle Anforderungen im Blick (Abdeckungsgrad)? Kann ich die Anforderungen auch bedienen (Erfüllungsgrad)?

Zum Thema „Abdeckungsgrad“ empfehle ich den Blog-Beitrag von Michael Wendenburg zum Systems Engineering, das ist eine Frage der intelligenten Verdrahtung von Informationen untereinander. Der Erfüllungsgrad wiederum ist eine Frage der Absicherung – und hier wird’s jetzt ein bißchen heterogen…

Absicherung stand lange Zeit synonym für den guten alten Versuch: Hält es noch, wenn man dran rüttelt? Läuft irgendwo Öl ‘raus? Entschuldigung an alle Kollegen aus dem Versuch für die saloppe Formulierung. Was ich damit verdeutlichen will, ist die Krux, daß der Versuchsplan sich in Ermangelung an klar formulierten Anforderungen auch nicht an solchen orientieren kann. Was man im Versuch herausfindet, wird klassischerweise so gut wie möglich gegen einzelne Teile oder Baugruppen dokumentiert und daraus ein (Produkt-) Reifegrad interpretiert.

Das Gleiche gilt grundsätzlich auch für die Absicherung der anderen Reifegrad-Perspektive. Aber Herstellbarkeitsprüfungen, Verbauuntersuchungen, Try-Outs zur Prozess-Stabilität… müssen eher noch ein härteres Schicksal tragen: Ergebnisse wie „läßt sich nicht mit dem Schrauber erreichen“ können wenigstens noch auf einen Bauraum bezogen werden, aber „zu breit für die Lackierkabine“ ist schon deutlich schlechter aufzulösen. Und es geht ja auch noch weiter: Sind die Logistik-Prozesse reif, klappt die IT-Versorgung für die Produktion und und und …

Nun existiert dazu auch noch eine veritable Parallelwelt: Simulation hat Ihren Platz in den Entwicklungsorganisationen gefunden, sowohl für Produkt-, als auch Prozessthemen. Allerdings ringen viele Beteiligte noch mit der Verdrahtung doch unterschiedlicher Prozesswelten. Typische Rückmeldungen aus der Simulation lauten in etwa „würde halten, wenn Du den Radius etwas kleiner machst“ – und das womöglich in sehr frühen Konzeptphasen, wo es kaum eine ausgegorene Produktstruktur als Referenz gibt.

Spätestens hier wird also der Zusammenhang zwischen Reifegrad und Alternativen besonders deutlich: Messe ich das eine, bewerte ich das andere.

Um managen zu können, brauchen ich ein gemeinsames Raster für Entwicklung und Absicherung, an dem Ergebnisse der sehr unterschiedlichen Aktivitäten gespiegelt werden. Egal ob Simulation oder physische Absicherung, frühe Konzepte oder B-Muster – ich benötige eine vereinheitlichte Aussage über den Reifegrad meiner Ergebnisse. Und nur auf der Ebene von Anforderungen habe ich ein hinreichend abstraktes Vehikel, um so ein Raster darzustellen und alle genannten Fraktionen abzuholen.

Wenn man „Management“ ernst nehmen will, dann sind wir hier – glaube ich – an einer guten Stelle dafür angelangt.

Dieses „L“ in „PLM“ ist – mit Verlaub – schon ein ziemlich armer Tropf. Dieser Platz in der Mitte, scheint er auch oberflächlich sehr zentral und attraktiv, ist nämlich der Platz zwischen den Stühlen, nichts Halbes und nichts Ganzes. Nachdem ich mich dem „P“ ja schon gewidmet habe, möchte ich diesem vernachlässigten Kollegen ein paar Zeilen spendieren.

Das „L“ in „PLM“ steht für „Lifecycle“. Aber mal ganz ehrlich: In welchen PLM-Konzept wird das schon ernst genommen? PLM in der Praxis heißt doch: Entwicklungsprozesse abdecken und beim Auslauf der Produkte noch schnell den Reifegrad auf „Schrott“ zu setzen. Den Rest soll die ERP- (PPS-, MES-, …) Fraktion erledigen: Produktion durchsteuern, Bestände, Ersatzteile usw.

Leider aber ist die Welt nicht so einfach in Schwarz und Weiß zu teilen. Da ist – wie gesagt – noch der Platz zwischen den Stühlen: Schonmal was von Musterbau gehört? Prototypen? Vorserie? Spannende Themen, wirklich. Teuer und aufwendig noch dazu. Zentrale Bestandteile des „Product Lifecycles“, nur dummerweise vollkommen „out of scope“ sowohl der klassischen PLM- als auch ERP-Konzepte.

Warum eigentlich?

Wir haben auf der einen Seite die Entwicklungsabläufe, die sich auf Produktstrukturen, Baugruppen, Teile fokussieren. Gesteuert wird z.B. über Reifegrade, Meilensteine und Materialkosten. Auf der anderen Seite haben wir die Serienwelt. Hier herrschen Stücklisten und logistische Umfänge, gesteuert wird über Mengen, Einsatztermine, Qualität…

Vorserienthemen (ich nutze das Wort Vorserie jetzt einfach einmal pauschal für alles, was vor SOP passiert) haben von allem Etwas. Wir befinden uns in PEP-Phasen, in denen die Baugruppen und Teile noch ganz schön in Bewegung sind, bis hin zu neuen Anforderungen und Rahmenbedingungen für das Produkt. Andererseits muß man diese Teile irgendwann einmal in die Hand nehmen können, um Muster und Prototypen bauen zu können. Wir reden also über Mengen und Qualitätsausprägungen für „moving targets“. Ein echter Leckerbissen für Disponenten mit gutem Nervenkostüm.

Die Datenbasis dieser Ereignisse findet sich in der Regel in vielen verstreuten – na? – klar: Excel Dateien wieder. Denn: In PLM-Systemen bekommt man in der Regel keine Mengenangaben unter, in ERP-Systemen in der Regel keine Entwicklungsstände. Beides braucht man aber für eine saubere Steuerung (nur als ein Beispiel).

Sicher gibt es Zwischenlösungen. Beispielsweise Sonder-Teilenummern, mit denen im ERP Bestellungen für Teile ausgelöst werden können, die eigentlich noch gar nicht „frei“ sind. Aber die Realität der Muster- und Prototypenteile ist eben, daß der Lagerort manchmal auch der Schreibtisch vom verantwortlichen Konstrukteur ist und der Wareneingang über den Aktenkoffer des Key Accounters vom Lieferanten läuft. Das schreit nicht gerade nach Systemen, die auf hohe Prozesseffizienz ausgelegt sind, hier sind andere Tugenden gefragt.

Wohlgemerkt: Ich möchte weder ERP-, noch die PLM- Systeme ersetzen. Von beiden wissen wir, daß wir sie brauchen, so wie sie sind (oder mindestens so ähnlich). Ich denke, für den spannenden Platz in der wilden Mitte müssen wir uns einfach noch ein passendes „Ding“ ausdenken.

Ob sich das lohnt?

Bereits 2002 hat die BMBF-Studie „Fast Ramp-Up“ (ich zitiere den Abschlussbericht) abgeschätzt, daß in der Automobilindustrie mit einem effizienten Anlauf 5% mehr Rendite für ein Modell erzielt werden kann. Und ein OEM-Anlauf zieht dabei ca. 800 Einzelanläufe bei Komponentenwerken und Zulieferern nach sich, bei denen sicherlich auch Potenziale herumliegen.

Oder: Im Bereich der Konsumgüter mag die Tiefe der Lieferantennetzwerke nicht ganz so ausgeprägt sein, wie bei den Kollegen von der Auto-Fraktion, aber dafür haben wir hier eine viel schnellere Taktung der Anläufe – was will der Markt schließlich noch mit einem 6 Monate altem Handy-Modell?

Dem geneigten Leser wird sicherlich auch noch das eine oder andere Beispiel einfallen. Fakt ist, daß bei aller Virtualisierung nach wie vor teure „handgeschnitzte“ Muster und Prototypen benötigt werden, in die viel Arbeit und Geld gesteckt wird. Jeder Fehler dabei wird gleich richtig teuer und jeder Zeitverzug fällt in eine Phase des PEP-Projektes, in der eh schon sämtliche Puffer dahin sind.

Für mich klingt das so, als ob ein paar Gedanken zum Thema Sinn machen.

Ich wünsche einen erfolgreichen Anlauf 2012!