Kategorie: PLM-Anwendungen

Pleiten, Pech, Pannen und PLM

„Alles was schief gehen kann, wird auch schief gehen“, lautet das wohl bekannteste von Murphys Gesetzen. Wo der Mensch seine Hände im Spiel hat, sind Fehler unausweichlich. Für die Unternehmen heißt das, dass sie die Fehlerquote reduzieren, aber Fehler nie ganz eliminieren können. Worauf es ankommt, ist ein effizienter Umgang mit den auftretenden Fehlern, um sie möglichst schnell zu beheben und ihre Wiederholung zu vermeiden. Das gilt vor allem für jene Fehler, die den Gebrauch eines Produktes beeinträchtigen, sprich Mängel.

Das Problem mit Fehlern ist, dass sie in vielen Formen auftreten – als Produkt- oder Qualitätsfehler, als Prozessfehler, als (meist unverständliche) Error-Meldung einer Software etc.. Manchmal verkleiden sie sich auch als Serviceanfragen oder Verbesserungsvorschläge. Einige fallen in der Entwicklung auf, andere in Fertigung und Montage bzw. in der Qualitätssicherung. Wieder andere entdecken die Servicetechniker oder – schlimmer noch – die Kunden, was Gewährleistungen, Reklamationen oder Beschwerden nach sich zieht.

Je nachdem, wo und wann sie auftreten bzw. auffallen, werden Fehler mit unterschiedlichen Werkzeugen wie Excel, eigene Datenbanken etc. verwaltet, was ihre strukturierte Bearbeitung nach einer einheitlichen Methodik (z. Bsp. der 8D Methode) erschwert. Das ist weder effizient noch effektiv, denn bei allen diesen Vorgängen geht es letztlich darum, sie systematisch zu erfassen, auszuwerten, entsprechende Maßnahmen zu ergreifen und diese nachvollziehbar zu dokumentieren. Deshalb liegt es nahe, die Bearbeitung aller fehlerrelevanten Vorgänge in einer einheitlichen IT-Systemumgebung zusammenzuführen. Die Frage ist, ob PLM dafür die geeignete Plattform ist bzw. was sie leisten muss, um diese Funktion zu erfüllen?

Für die Integration des Mängelmanagements in PLM sprechen verschiedene Gründe:

  • Mängel, Reklamationen etc. haben normalerweise einen engen Bezug zu einem Produkt oder Projekt, deren Unterlagen mit PLM verwaltet werden;
  • für die Bearbeitung der Vorgänge können einheitliche Vorgehensweisen in Form von elektronischen Workflows abgebildet werden;
  • die Rechteverwaltung des PLM stellt sicher, dass nur autorisierte Personen zu den Informationen über Mängel, Reklamationen etc. haben;
  • PLM unterstützt die Umsetzung von Maßnahmen zur Fehlerbehebung durch formale Workflow-Prozesse;
  • die vorhandenen Projektmanagement-Funktionen können für die Umsetzung von größeren Verbesserungsvorhaben genutzt werden;
  • die Nutzung einer einheitlichen Plattform spart Schnittstellen und Kosten für Anschaffung bzw. Wartung einer separaten Reklamationsmanagement-Anwendung.

Alle Vorgänge, die mit der Behandlung von Fehlern zu tun haben, in die PLM-Lösung zu packen, ist also keine schlechte Idee. Einheitliche Bearbeitungsmethoden unter einer einheitlichen Oberfläche sorgen dafür, dass die Mitarbeiter Mängel, Reklamationen etc. schneller erledigen können. Das spart Kosten, erhöht die Zufriedenheit der Kunden und bindet sie an das Unternehmen. Wem bei einer Reklamation schnell und unbürokratisch geholfen wird, der kauft gerne wieder.

Das „L“ in der undankbaren Mitte

LDieses „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!

Alte Hüte, moderne Mützen

Man sollte meinen, das Thema PDM/ERP-Schnittstelle sei ein alter Hut, der an der PLM-Garderobe verstaubt. Ist aber nicht so. Es gibt immer noch Firmen, die Materialdaten und Stücklisten trotz PDM-Einsatz von Hand ins ERP-System eingeben. Und es sind nicht unbedingt die kleinsten – im Gegenteil: Manchmal hat man den Eindruck, als mittelständischen Maschinen- und Anlagenbauer, was die IT-technische Verzahnung von Einkaufs-, Entwicklungs- und Fertigungsprozessen angeht, weiter als manches Großunternehmen. Zumindest gehen Mittelständler das Thema pragmatischer an: Viele haben im Zuge der PDM/ERP-Integration ohne lange Diskussionen entschieden, dass Materialstämme und Stücklisten im PDM-System „erfunden“ werden. Und siehe da, es funktioniert.

Interessanterweise ist das Thema PDM/ERP-Integration selbst für Unternehmen, die bereits ein hohes Maß an Prozessdurchgängigkeit erreicht haben, aktueller denn je. Um die wachsende Zahl von kundenspezifischen Aufträgen mit tendenziell kleiner werdenden Losgrößen flexibler durch den Produktionsprozess zu schleusen, benötigen sie umfassendere Schnittstellen-Funktionen, die es erlauben, die Informationen in beiden Systemwelten kontinuierlich zu synchronisieren und nach Möglichkeit in Echtzeit auf sie zuzugreifen. Ein heißes Eisen ist in diesem Zusammenhang das systemübergreifende Änderungs-Management, denn es geht darum, einen stringenten und sicheren Prozess von der ersten Bedarfsmeldung für eine technische Änderung bis zur Umsetzung in der Produktion zu gewährleisten.

Neue Anforderungen ergeben sich auch durch den Ausbau der PDM-Systeme zu umfassenderen PLM-Lösungen, mit denen zum Beispiel die Entwicklungsaufgaben verteilt und terminiert, die Aufwände erfasst und die Arbeitsfortschritte kontrolliert werden. Um Projekte von der Angebotserstellung bis zur Auslieferung durchgängig steuern zu können, muss die Auftragsverwaltung im ERP-System mit dem Projekt-Management der PLM-Lösung verknüpft werden, insbesondere was den Abgleich von Cost und Work Breakdown Structures anbelangt. Hersteller von variantenreichen Produkten, die mögliche Produktkonfigurationen PLM-seitig definieren, benötigen die hinterlegten Regeln auch für die Erzeugung der auftragsspezifischen Stücklisten im ERP-System. Das heißt mit anderen Worten, dass zwischen beiden Systemwelten mehr Informationen als bisher ausgetauscht und bei Änderungen synchronisiert werden müssen..

Sowohl die Unternehmen, als auch die Softwarehersteller und ihre Systemintegratoren treiben einen erheblichen Aufwand, um dieses Mehr an Funktionalität in proprietären Schnittstellen abzubilden. Dabei wird das Rad oft neu erfunden. Mit Blick auf die Gesamtkosten für Anschaffung, Betrieb und Wartung der Integrationslösungen ist dieser Aufwand eigentlich nicht zu rechtfertigen. Wir brauchen mehr Standardisierung, nicht im Sinne einer PDM/ERP-Integration von der Stange, sondern in Form von Best Practices und standardisierten Schnittstellen-Funktionen, die sich entsprechend den Prozessanforderungen des Kunden und den Möglichkeiten der eingesetzten PDM- und ERP-Systeme einfach konfigurieren lassen. Das Forschungsinstitut für Rationalisierung der RWTH Aachen hat deshalb zusammen mit Partnern aus Verbänden und der Industrie ein Forschungsprojekt gestartet, das die Produktionssysteme durch Integration der IT-Strukturen und Dezentralisierung der Produktionssteuerung und -planung wandlungsfähiger machen soll. Gefördert wird das WInD-Projekt von Bundesministerium für Forschung und Bildung. Ein wichtiges Teilprojekt ist die Schaffung prozessorientierter Standard-Schnittstellen, sowohl zwischen ERP- und PDM-, als auch zwischen ERP- und MES-Systemen.