Michael Wendenburg

Wohin mit der Fertigungsstückliste?

In Fachkreisen wird seit einiger Zeit lebhaft darüber diskutiert, wo die Fertigungsstückliste eigentlich hingehört. Da diese Diskussion im wesentlichen auf Englisch geführt wird, ist allerdings meist von Manufacturing Bill of Material bzw. mBOM die Rede. Spontan würde man sagen, sie gehört ins ERP-System, weil das ERP-System – oft in Verbindung mit einem MES-System (Manufacturing Execution System) – die Fertigungsprozesse steuert und weil es das bevorzugte Werkzeug der Mitarbeiter im Unternehmen ist, die für die Steuerung dieser Prozesse verantwortlich sind. Aber die Sache ist nicht ganz so einfach.

Fertigungsstücklisten werden immer seltener von Hand im ERP-System angelegt. Meist sind sie das Ergebnis einer Produktstruktur, die im 3D-CAD-System wächst. Der PLM-Einsatz hat in vielen Unternehmen zu einem arbeitsteiligen Stücklistenmanagement geführt: Die Konstruktionsstückliste (Engineering Bill of Material oder kurz eBOM) wird im PLM-System angelegt und ab einem bestimmten Reifegrad an das ERP-System übergeben, um die mBOM abzuleiten. Je nach Prozess-Anforderungen wird sie im ERP-System nicht nur um Positionen wie den berühmten Tropfen Öl ergänzt, sondern sogar in ihrem Aufbau verändert.

wegweiser2 — Mit freundlicher Genehmigung Stuart Miles, www.FreeDigitalPhotos.net

Die quasi automatische Erzeugung bzw. Ableitung der Stücklisten spart Zeit und vermeidet Fehleingaben. Bei technischen Änderungen verursachen die Unterschiede zwischen eBOM und mBOM jedoch einen erheblichen Aufwand für die Synchronisation der redundanten Stücklisten-Informationen in den verschiedenen IT-Systemen. Das umso mehr, wenn die eBOM auf mehrere, werkspezifische mBOMs abgebildet werden muss, weil ein und dasselbe Produkt an verschiedenen Standorten mit unterschiedlichen Zutaten und nach unterschiedlichen Rezepten produziert wird.

Der Leidensdruck bei der Stücklisten-Synchronisation ist nicht in allen Unternehmen gleich groß. Insbesondere Hersteller von komplexen Produkten mit langen Lebenszyklen, die viel Re-Engineering und Re-Konfiguration betreiben, beklagen sich oft über die mangelnde ERP-Unterstützung bei Änderungen an den Fertigungsstücklisten. Auch Unternehmen, die an ihren global verteilten Fertigungsstandorten separate ERP-Systeme oder -Instanzen nutzen, vermissen ein übergreifendes Stücklistenmanagement, um Änderungen schnell und sicher an die Werke kommunizieren zu können. Noch schwieriger ist die Synchronisation zwischen eBOM und mBOM, wenn sich die Entwicklung und Fertigung über eine lange Zulieferkette verteilen, was heute vielen Branchen der Fall ist.

Das arbeitsteilige Stücklistenmanagement wird deshalb zunehmend in Frage gestellt – bis hin zu der Überlegung, ein so genanntes Master Data Management (MDM) für die Verwaltung sämtlicher Stücklisten-Ausprägungen aufzusetzen. So charmant die Idee ist, ich glaube nicht, dass wir dafür ein neues IT-System brauchen. Die Frage, wo die Fertigungsstückliste hingehört, ist nämlich im Prinzip falsch gestellt. Natürlich gehört sie irgendwann ins ERP- oder auch ins MES-System, damit das Produkt gefertigt werden kann. Worum es eigentlich geht ist, die Anlage der Fertigungsstückliste(n) und die Synchronisation zwischen mBOM und eBOM in einem System zusammenzuführen, das in der Lage ist, mehrere Stücklisten-Sichten zu verwalten und zu synchronisieren, um den Abstimmungsaufwand zu minimieren.

Meines Erachtens ist das keine Frage der Ideologie, sondern eine ganz pragmatische Entscheidung, die das Unternehmen entsprechend seiner Anforderungen und seiner IT-Landschaft fällen sollte. Wenn das ERP-System die Abbildung unterschiedlicher Sichten nicht oder nur ungenügend unterstützt, das PLM-System aber entsprechende Funktionen bietet, dann spricht nichts dagegen, die Hoheit über die Fertigungsstückliste an das PLM-System zu übertragen. Im Gegenteil, es spricht sogar einiges dafür – zum Beispiel die Möglichkeit, eBOM und mBOM im PLM auch mit der Service-Stückliste zu synchronisieren, die wieder ganz anders aufgebaut sein kann.

Verbesserungen am laufenden Band

Der Ausdruck “am laufenden Band” stammt – so möchte ich mal vermuten – aus der Welt der Fertigung, hat sich aber dank Rudi Carrell zu einem stehenden Begriff für alles entwickelt, was in rastloser Unruhe ist. Vielleicht sollte man besser von Verbesserungen im laufenden Betrieb sprechen. Denn darum geht es, wenn Unternehmen ihre funktionierenden PLM-Installationen weiter ausbauen und verbessern.

Mit freundlicher Genehmigung freedigitalphotos.net — Mit freundlicher Genehmigung Chomnancoffee, FreeDigitalPhotos.net

Neulich sprach ich mit dem Projektleiter eines mittelständischen Schweizer Unternehmens, das im vergangenen Jahr eine umfassende PLM-Lösung einschließlich Projektverwaltung implementiert hatte. Unmittelbare Nutzeneffekte waren eine bessere Prozessdurchgängigkeit und Datenkonsistenz. Inzwischen hat das Unternehmen sein Änderungsmanagement dahingehend erweitert, dass bei Freigabe der Änderung eines Artikels die Stücklisten von allen Produkten, in denen dieser Artikel verbaut ist, automatisch aktualisiert werden. Die Zeiteinsparungen durch die Neuerung sind nicht gewaltig, weil man auch früher schon Sammeloperationen ausführen konnte, aber die erweiterten Änderungsmanagement-Funktionen befreien die Anwender von lästigen Routinetätigkeiten. Vor allem aber sind sie die Grundlage für die Abbildung des gesamten ECM-Prozesses (Engineering Change Management) in einem elektronischen Workflow, von dem das sich Unternehmen sich eine spürbare Verkürzung der Durchlaufzeiten von Änderungen verspricht. Sie soll der nächsten Ausbaustufe umgesetzt werden.

Die Moral von der Geschichte ist, dass PLM-Projekte eigentlich nie zu Ende gehen. Es müssen im laufenden Betrieb immer wieder neue Wünsche und Bedürfnisse umgesetzt werden, und sei es nur deshalb, weil sich die Anforderungen des Unternehmens mit der Zeit verändern. Eines ist allerdings sicher: Es werden nie weniger, sondern immer mehr, weshalb sich der Funktionsumfang der PLM-Installationen ständig vergrößert. Wer hätte vor ein paar Jahren gedacht, dass Themen wie Anforderungsmanagement, Konfigurationsmanagement, Projektmanagement oder Qualitätsmanagement mal zu den PLM-Funktionen gehören würden.

Mit wachsendem Funktionsumfang wächst der Kreis der PLM-Anwender und er wird heterogener. Im Unterschied zu den Ingenieuren, die zu den Power Usern gehören, greifen viele andere Anwendergruppen nur gelegentlich auf PLM-Informationen zu. Sie brauchen eine einfache, intuitiv zu bedienende Benutzeroberfläche, in der sie sich ohne Lernaufwand zurecht finden. Dieser Anforderung werden viele PLM-Systeme immer noch nicht ganz gerecht, was sich negativ auf die Akzeptanz auswirkt.

Auch seitens des Managements ergeben sich neue Anforderungen an die PLM-Systeme. Die Führungskräfte wollen vielleicht ihre Entscheidungen mit Hilfe von Kennzahlen besser absichern, die sich aus den oft beiläufig erfassten Informationen im PLM destillieren lassen. Oder sie wollen eine Multiprojektsicht auf alle laufenden und geplanten Entwicklungsprojekte haben, um Prognosen über die weitere Geschäftsentwicklung machen zu können.

Was bedeutet das für die PLM-Systeme und ihre Hersteller? Zunächst einmal, dass sie wachstumsfähig sein müssen. Mit den monolithischen Software-Architekturen der Vergangenheit ist es kaum möglich, den erweiterten Funktionsumfang in einer angemessenen Zeit bereitzustellen. Notwendig sind modulare Software-Plattformen, die sich schnell und flexibel um neue Anwendungsmodule ergänzen lassen. Notwendig sind leistungsfähigere Programmierwerkzeuge, mit denen der Kunde oder sogar ein Third-Party-Entwickler zusätzliche Module entwickeln kann, ohne die Update-Fähigkeit der Lösung zu verbauen. Notwendig ist aber auch und vor allem mehr Offenheit der PLM-Systeme, um Fremdanwendungen leichter integrieren zu können, denn die Hersteller werden auf Dauer nicht den gesamten Funktionsumfang aus eigener Kraft bereitstellen wollen oder können.

PLM-Nutzen muss messbar sein

Vor ein paar Monaten hat Oleg Shilovitsky den PLM-Herstellern und ihren Lösungen in einem Blog-Beitrag vorgeworfen, dass sie sich mit dem Nachweis des Return on Invest (ROI) traditionell schwer tun. Kein neuer Vorwurf und einer, der dem Problem nicht ganz gerecht wird. Es sind nämlich nicht nur die PLM-Hersteller, sondern auch die Anwender selbst, die sich damit schwer tun.

Viele Unternehmen scheuen den Aufwand für die Berechnung des ROI, gerade weil sie einen möglichst schnellen ROI erzielen möchten. Nur scheinbar ein Widerspruch: Um die Nutzeneffekte der Investition exakt messen zu können, müssten sie erst die bestehenden Prozesse und ihre Schwachstellen genau analysieren und Kennzahlen für die Messung von Verbesserungen definieren. Das kostet Zeit und Geld, insbesondere wenn externe Berater involviert sind, weshalb die Analyse des Ist-Zustands meist recht rudimentär ausfällt.

Mit freundlicher Genehmigung von marcolm, freedigitalphotos.net

Manchmal sind die Nutzeneffekte des PLM-Einsatzes so offensichtlich, dass die Unternehmen glauben, sich den Analyseaufwand schenken zu können. Der Geschäftsführer eines Anlagenbauers mit mehr als 150 PLM-Anwendern, der gerade ein aufwendiges Migrationsprojekt hinter sich gebracht hatte, sagte mir neulich auf die Frage nach dem ROI: „Die Investition war definitiv notwendig. Wenn jeder meiner Mitarbeiter dadurch auch nur zehn Minuten Zeit am Tag spart und wir gleichzeitig die Neuanlage von Artikeln reduzieren, brauchen wir über den ROI nicht mehr zu reden.”

In anderen Fällen ist die PLM-Investition unerlässlich, um den wachsenden Nachweispflichten nachkommen zu können. Gerade Automobilzulieferer müssen ihre Entwicklungsprozesse und die Ergebnisse minutiös dokumentieren– sonst laufen sie Gefahr, keine Aufträge mehr zu bekommen. PLM ist dabei von strategischer Bedeutung; wie schnell sich diese Investition bezahlt macht, spielt deshalb eine untergeordnete Rolle.

Erschwert wird der Nachweis des ROI auch noch durch ein anderes Phänomen: Der breiter werdende Funktionsumfang der PLM-Anwendungen und ihre zunehmende Verzahnung mit anderen Unternehmensanwendungen führt zu immer mehr Nutzeneffekten, die sich nur schwer quantifizieren und nicht mehr klar zuordnen lassen. Wie will man zum Beispiel die Produktivitätszuwächse messen, die sich daraus ergeben, dass jüngere Mitarbeiter dank PLM einfacher auf das Erfahrungswissen ihrer Kollegen zugreifen können? Bei Großunternehmen mit vielen Kostenstellen ergibt sich zudem das Problem, dass die Nutzeneffekte nicht unbedingt dort entstehen, wo die Kosten anfallen und auch genehmigt werden müssen.

Es geht bei der Analyse der Nutzeneffekte aber nicht nur um die Rechtfertigung einer einmaligen Investition, sondern auch und vor allem um die Frage, wie sich mit Hilfe von PLM die Effizienz der Produktentwicklung nachhaltig steigern lässt. Dazu müssen entsprechende Prozesskennzahlen definiert und kontinuierlich verfolgt werden. Eigentlich kein Hexenwerk, da die Basisdaten in der PLM-Lösung meist schon vorhanden sind und nur verdichtet werden müssen. Wann eine Änderung beantragt und wann sie abgeschlossen wurde, erfasst das System zum Beispiel automatisch. Es ist mithin ein Leichtes, die Durchlaufzeiten von Änderungsaufträgen zu berechnen.

Wie in meinem letzten Blog-Beitrag zu lesen, sind viele Führungskräfte mit dem Nutzen ihrer bisherigen PLM-Investitionen unzufrieden. Das gilt insbesondere für den Nutzen, den sie für ihre Führungsaufgaben aus den PLM-Daten ziehen. Der Accenture-Surveys erlaubt eine positive und eine negative Interpretation: Erfreulich ist, dass sich die Führungskräfte der strategischen Bedeutung der PLM-Lösungen und der in ihnen steckenden Informationen bewusst sind. Bedauerlich hingegen, dass viele PLM-Hersteller es offensichtlich noch nicht geschafft haben, ihnen geeignete Werkzeuge für die Nutzung dieser Informationen an die Hand zu geben. Ein flexibles Kennzahlenmanagement und gute Reporting-Funktionen sollten heute zum Standardumfang jeder PLM-Lösung gehören.