PLM-Anwendungen

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.

Qualitätsmanagement als Sisyphosarbeit

Qualitätsmanagement ist eine Sisyphosarbeit, bei der man nie wirklich am Ziel ankommt. Irgendwann fällt einem der Felsblock wieder vor die Füße. Davon kann der japanische Automobilhersteller Toyota ein (Klage-)Lied singen – ein richtiges sogar; nix mit Karaoke. Obwohl die Japaner das Qualitätsmanagement quasi erfunden haben, produzieren sie in letzter Zeit Rückruf-Aktionen in Serie.

Ein klarer Fall für CAPA (Corrective And Preventive Action) möchte man spotten: Aus den Fehlern der Japaner lernen, um sie in Zukunft zu vermeiden. Schadenfreude ist jedoch fehl am Platze: Erst Ende letzten Jahres musste der Volkswagen-Konzern in einer der größten Rückrufaktionen der Unternehmensgeschichte 2,6 Millionen Fahrzeuge wegen eines drohenden Getriebeschadens und Problemen mit dem Lichtsystem in die Werkstätten beordern. Betroffen war vor allem der chinesische Markt, wo die Fahrzeuge bei schwülen Temperaturen länger als anderswo im Stau stehen.

Toyoda Sakichi, König der japanischen Erfinder und Vater des Gründers von Automobilhersteller Toyota. Bild: Toyota

Das Toyota-Produktionssystem, das auf die Maximierung der Kundenzufriedenheit bei Qualität, Lieferzeit und Kosten ausgerichtet ist, war lange Zeit und ist immer noch Vorbild für ein erfolgreiches Qualitätsmanagement. Ganze Bücher wurden über den Toyota Way geschrieben. Eine seiner Grundlagen ist das von Toyoda Sakichi, dem Vater des Firmengründers, Anfang des 20. Jahrhunderts entwickelte Jidöka-Prinzip der autonomen Automatisierung. Es sieht die Kontrolle der gefertigten Materialien während des laufenden Produktionsprozesses vor, und zwar durch Komponenten und Funktionen der Maschinen (Webstühle), die es erlauben, Abweichungen vom Normalzustand selbsttätig zu erkennen.

Das muss man sich mal vorstellen: Die revolutionäre Idee von Industrie 4.0 wurde nicht etwa in Deutschland, sondern in Japan geboren, und das vor über 100 Jahren, während der zweiten industriellen Revolution. Arigatou! Toyoda-san, möchte man mit höflicher Verneigung Richtung aufgehender Sonne sagen.

Aber zurück zu unserem eigentlichen Thema. Toyoda Sakichi verdanken wir das Prinzip der prozessbegleitenden Qualitätssicherung und damit zugleich die Einsicht, dass es effizienter ist, die Produktqualität über gute Prozesse sicherzustellen als durch nachträgliche Kontrollen. Das bedeutet, dass Qualitätsmanagement nicht nur die Qualität des Produkts, sondern auch die der produkt-relevanten Prozesse im Blick hat. Allerdings war diese Prozesssicht zunächst noch sehr stark auf die Optimierung der Fertigung fokussiert.

Inzwischen hat sich die Erkenntnis durchgesetzt, dass Qualitätsmanagement dort ansetzen muss, wo 70 bis 80 der Kosten des späteren Produkts und damit auch die Kosten für die Beseitigung von Fehlern definiert werden: In der Produktentwicklung. Oder um genauer zu sein: In der Konzeptphase, in der die Qualitätsmerkmale des Produkts festgelegt und die Produktionsprozesse, das heißt das Zusammenspiel von Maschinen, Anlagen, Betriebsmitteln und Automatisierungstechnik für ihre Herstellung konzipiert werden. Dafür steht das Konzept der Advanced Product Quality Planning (APQP) und die dazu gehörigen Methoden zur Analyse möglicher Fehler im Prozess und ihrer Eintrittswahrscheinlichkeit (FMEA).

Die besten Konzepte der Qualitätsvorausplanung nützen allerdings nichts, wenn die Planungsergebnisse im laufenden Entwicklungsprozess nicht durch entsprechende Reifeprüfungen regelmäßig abgesichert werden. Das Qualitätsmanagement kann deshalb nicht allein Aufgabe der Qualitätssicherung sein, sondern betrifft alle Disziplinen, die in den Produktentstehungsprozess involviert sind. Das bedeutet aber auch, dass die Werkzeuge und Methoden für das Qualitäts- und Risikomanagement in die IT-Lösungen zur Steuerung des Produktlebenszyklus integriert werden müssen.

Quality Lifecycle Management (QLM) sei einer der neuen Zuständigkeitsbereiche von PLM, schrieb Jim Brown von Tech Clarity schon vor Jahren in einem Blog-Beitrag, um gleich einzuschränken, dass die meisten PLM-Lösungen dafür funktional noch nicht reif seien. Das sollte sich inzwischen geändert haben. Schließlich muss die Befriedigung der Kundenbedürfnisse auch für Software-Hersteller das oberste Ziel des Qualitätsmanagements sein.