Gedanken zur Alleinstellung eines PLM-Systems

Veröffentlicht am 13. Februar 2015, aktualisiert am 13. Februar 2015 von Christoph

Sucht man bei Google nach dem Begriff PLM, findet man auf den ersten Seiten hauptsächlich PLM-Systemhersteller. Auch im sonstigen Gebrauch des Begriffes wird vielfach PLM mit PLM-System gleichgesetzt und somit dieser Managementansatz auf eine Softwarelösung reduziert. In meinem heutigen Blogartikel möchte ich einige Gedanken zusammentragen, die sich von dieser Betrachtungsweise lösen und einen anderen Blickwinkel auf dieses Thema zeigen.

Die erste These ist, dass ich mich vom klassischen Ansatz eines PLM-Systems trennen möchte, dass alle produktrelevanten Daten möglichst in der Datenbank und/oder Vault zusammengefasst werden sollen. Was passiert eigentlich, wenn man dem Konstrukteur seine PDM-Lösung lässt, die gut mit seinem CAD-System integriert ist. Der Projektingenieur fühlt sich eigentlich auch ganz heimisch mit seinem MS Project und die Arbeitsvorbereitung legt ihre Dokumente auf einem Netzlaufwerk ab. Und für den Hauptteil der Arbeit reicht das auch vollkommen.

Solange jeder auf seiner Insel bleibt, ist auch jeder zufrieden. Schwierig wird es nur, wenn zum Beispiel Änderungsprozesse bereichsübergreifend bearbeitet werden müssen und somit eine gemeinsame Datenbasis unbedingt notwendig wird. Oder aus gesetzlichen Anforderungen fachübergreifende Nachweise erbracht werden müssen – Stichworte sind die Risikobeurteilung nach MRL oder aus der Medizintechnik der Device Master Record. An dieser Stelle schlägt die Stunde eines PLM-Systems, das die einzelnen Inseln in ein Datenmodell integriert. Welcher Aufwand notwendig ist, diese Insellösungen in ein PLM-System zu überführen, kennen wir aber auch alle. Die technische Herausforderung steht dabei gar nicht im Vordergrund. Viel aufwändiger ist der Änderungsprozess in den Köpfen der Anwender, die von ihrem lokalen Maximum – ihrer Insellösung – auf ein globales Maximum – PLM-System – umschwenken müssen. Wie viele PLM-Projekte sind eigentlich schon an diesem Punkt gescheitert, obwohl sie in Betrachtung des Gesamtunternehmens definitiv die versprochenen Ziele erreicht hätten?

Der Kompromiss wäre doch, dem Anwender sein lokales Maximum zu lassen und trotzdem die Zusammenarbeit zu ermöglichen. Ein Vorschlag, den ich hier zur Diskussion stellen möchte, ist, das PLM-System eher als intelligente Suchmaschine zu sehen. Trennen wir uns doch mal vom Gedanken der kompletten Systemintegration. Vielleicht ist es viel effektiver, weniger Zeit in die Datenablage in komplexen Datenmodellen zu investieren und dort eher lose ein Informationsnetzwerk zu spannen. Und wir denken mal an eine Google-Like Suchmaschine, die mir in unterschiedlichen Datenquellen die Informationen zusammensucht, die ich für meine aktuelle Aufgabe gerade benötige. Und mit der Unschärfe von unpassenden Treffern der Suche lebe ich einfach. Im normalen Internetalltag tue ich das ja auch. Wobei, wenn ich mir so anschaue, wie treffsicher mir Amazon mir Vorschläge „Das könnte Sie auch interessieren“ aus den wenigen Informationen macht, die dort zur Verfügung stehen. Und wenn man diesen Gedanken mal auf unsere PLM-Strategie transportiert:

PLM Suchmaschine Das PLM-System ist meine Suchmaschine für die Informationen meines aktuellen Arbeitsauftrags.

Den Daten, die ich für meine Arbeit benötige, folge ich im PLM-Twitter. Und das alles habe ich zusätzlich zu meiner klassischen Insellösung, mit der ich seit Jahren arbeite.

Ich möchte aber auch neben den positiven Dingen auch die negativen Aspekte nicht verschweigen: Wer sagt mir, dass meine Suchergebnisse vollständig sind? Was passiert mit meinen Prozessen, den elektronischen Workflows? Ich freue mich auf eine rege Diskussion mit den Lesern dieses Artikels.

PLM-Kaffeeküche 2.0

Veröffentlicht am 6. Februar 2015, aktualisiert am 13. Februar 2015 von Christoph

Im Rahmen von PLM-Projekten nimmt die Prozessanalyse einen zentralen Stellenwert ein. Die am Produktlebenszyklus beteiligten Abläufe werden mithilfe einer PLM-Software abgebildet. Aufgaben und Aktivitäten werden an verschiedene Rollen zugewiesen und Berechtigungen für den Zugriff zu Daten über die Lifecyclephasen gesteuert. Auditlogs und Objekthistorie sorgen für eine Nachvollziehbarkeit der Änderungen während der Abarbeitung des Prozesses. Als dies ist meist als Standardfunktion im PLM-System vorhanden oder kann mit wenig Aufwand implementiert werden.

Eine größere Dynamik gelangt durch eine Projektverwaltung in das System. Das temporäre Zusammenstellen von Projektteams, zeitlich begrenzte Berechtigungen und die Verwaltung von Projektaktivitäten sind Lösungen für die Anforderungen einer größeren Flexibilität.

Diese beiden Wege werden mittels einer Anforderungsanalyse aufgenommen, im PLM-Systemen abgebildet und als Unternehmensalltag gelebt.

Aber wer kennt nicht die Situation: Man steht im Kollegenkreis an der Kaffeemaschine und spricht zwanglos über das ein oder andere Problem. Da trifft sich der Konstrukteur mit dem Arbeitsvorbereiter und neben dem Auffüllen des Koffeinspiegels wird auch gleich noch ein Problem diskutiert und aus der Welt geschafft. Oder Entwicklungsingenieure aus verschiedenen Business Units treffen sich und tauschen sich über Lösungsalternativen zu ähnlichen Herausforderungen aus. Welches Unternehmen würde überhaupt funktionieren ohne Kaffeeküchen, Kantinen und – ja auch – Raucherinseln.

Diese Kaffeeküchen zu virtualisieren und im PLM-System nachzubauen, wird eine wichtiger Trend bei der Weiterentwicklung von PLM-Systemen sein. Ansätze dafür gibt es bereits einige. Dynamische Ad-hoc-Workflows bis hin zur “sozial-netzwerkigen”-Funktionen für die zwanglose Online-Kommunikation sind ein Schritt in diese Richtung. Der informelle Wissensaustausch ohne große Zwänge wird so ermöglicht und gefördert. Zusammenfassend möchte ich diese Portale, Lösungen und Funktionen “Kaffeeküche 2.0″ nennen.

Aus meiner Sicht ist das auf jeden Fall ein Schritt in die richtige Richtung. Nicht immer benutzen die Mitarbeiter die gleiche Kaffeeküche. Oder trinken überhaupt Kaffee. An der Stelle können PLM-Systeme mit Kaffeeküche-2.0-Funktionen Anwender unterstützen und eine Plattform für die zwanglose Suche nach Lösungen und den Wissensaustausch bieten. Neben den klar und eindeutig implementieren Prozessen und Projektaktivitäten kann dies eine sehr wertvolle Erweiterung sein. Und dazu ist das vielleicht auch eine Strategie, das doch recht konservative PLM-Umfeld ein Stück weit zu öffnen und weniger streng erscheinen zu lassen.

Und wenn man sich erinnert, dass die erste Webcam ausgerechnet auf eine Kaffeemaschine (Trojan Room Coffee Pot Camera) gerichtet war, dann schließt sich doch hier irgendwie ein Kreis, oder? Wie sind denn Ihre Erfahrungen mit diesen Funktionen? Ist das nur Spielerei oder eine ernstzunehmende Erweiterung?

Keine Maschine ohne Richtlinie

Veröffentlicht am 30. Januar 2015, aktualisiert am 13. Februar 2015 von Christoph

By Karel K..Karel K. at de.wikipedia [Public domain], from Wikimedia Commons

Vor einiger Zeit trat die Neuregelung der Maschinenrichtlinie 2006/42/EG (MRL) in Kraft. In Deutschland wurde die MRL mit der Novellierung der 9. Verordnung zum Geräte- und Produktsicherheitsgesetz 1:1 umgesetzt. Eine der größten Neuerung ist die gestiegene Bedeutung der Risikobeurteilung im kompletten Produktentwicklungsprozess. Risiken, die durch die Anwendung oder Bedienung einer Maschine erfolgen können, müssen konstruktiv ausgeschlossen werden. Es reicht eben nicht, nur in der Bedienungsanleitung auf mögliche Gefahren, die dem Bediener und dem Wartungspersonal drohen, hinzuweisen. Soweit als möglich sollen diese Gefahren durch geeignete Konstruktionen vermindert oder, im besten Fall, ganz beseitigt werden. Mit einer Konformitätserklärung bestätigt der Hersteller neben anderen Forderungen der MRL diesen Sachverhalt.

Welchen Zusammenhang haben jetzt diese eher trockenen Gesetzestexte und Normen mit einer PLM-Strategie eines Unternehmens? Ohne diese Konformitätserklärung darf keine Maschine ausgeliefert werden. Die Forderungen und Inhalte dieser Erklärung sind somit zwingender Bestandteil des Produktes und damit natürlich auch ein Teil der PLM-Strategie.

Es geht ja nicht nur darum, einen Satz von stets identischen Dokumenten jeder Maschine bei der Auslieferung mitzugeben. Die Anforderungen an diesen Teilaspekt des PLM sind doch weitaus komplexer. Das fängt bei der Verfügbarkeit von zu berücksichtigenden Gesetzen, Normen und Vorschriften im Unternehmen inkl. des notwendigen Änderungsdienstes an und hört nicht bei der Bedienungsanleitung in der Landessprache des Kunden bzw. Betreibers der Maschine auf. Absolvierte Prozesse und Abläufe, wie zum Beispiel eine Risikobeurteilung, müssen gegenüber Marktaufsichtsbehörden und Kunden nachgewiesen können. Und welcher Maschinenhersteller hat eine Fertigungstiefe von 100 % und arbeitet komplett ohne Partner und Zulieferer?

Und dann gibt es noch die Forderung nach einer schnelleren Time-to-Market des Produktes und damit nach einer Beschleunigung von Produktentstehungszyklen. Auf der einen Seite wird das Leben immer komplexer und auf der anderen Seite soll man das alles in noch kürzerer Zeit schaffen? Ohne ein hohes Augenmerk auf PLM ist das nicht zu bewerkstelligen.

Gemeinsam stärker: PLM und CMII

Veröffentlicht am 26. Januar 2015, aktualisiert am 13. Februar 2015 von Christoph

Eine zentrale Forderung, warum sich Unternehmen eigentlich mit PLM beschäftigen, ist die Effizienzsteigerung der wertschöpfenden Prozesse. Dies ist einer der wichtigsten Hebel in der ROI-Betrachtung eines PLM-Projekts.

Aber auch in den eigentlichen Geschäftsprozessen liegt oft ein gehöriges Optimierungspotenzial. In diesem Zusammenhang möchte ich gern auf die „Reduced Rework Initiative” der Gesellschaft für Konfigurationsmanagement hinweisen. Im Mittelpunkt dieser Initiative steht das Vorgehensmodell nach dem CMII-Standard mit dem Ziel, die Kosten und Aufwände für unnötige Nacharbeit zu senken. Nacharbeit entsteht immer dann, wenn das Produkt nicht den Anforderungen des Kunden entspricht. Oftmals wird an dieser Stelle an die Prozesse „Problem Report“, „Enterprise Change Request“ und „Enterprise Change Notice“ gedacht. Diese Abläufe im Änderungswesen sind Bestandteil vieler PLM-Werkzeuge und werden auch „out-of-the-box“ oder mit Modifikationen für die Steuerung von Freigaben und Änderungen von Dokumenten eingesetzt.

CMII bietet aber noch ein ganzes Stück mehr und gerade im Zusammenhang mit PLM-Projekten lohnt ein Blick auf alle Elemente des CMII-Vorgehensmodells. Best Practices und Regeln wie „Anforderungen führen – Items folgen“; das effiziente Änderungsmanagement; klare, knappe und gültige Anforderungen an das zu produzierende Produkt, die fortwährende Überprüfung der Konformität der Ergebnisse mit den Anforderungen, all das führt zu einer Vermeidung von Kosten für die Beseitigung von Produktfehlern. Vereinfacht gesagt, wird das Übel des Produktfehlers an der Wurzel beseitigt und nicht an den Symptomen herumgedoktert. Das hilft dabei, jeden Fehler nur einmal zu machen und auszumerzen. Unternehmen, die diesem Paradigma folgen, haben die Chance, Kosten für die Fehlerbeseitigung einzusparen und diese Mittel in echte Produktinnovation zu stecken.

Richtig beherrschbar werden aber diese CMII-Prozesse erst mit einer ausreichenden Toolunterstützung. Gerade Analysen von Änderungsauswirkungen (im CMII-Kontext „Impact Matrix“ genannt) sind ohne Unterstützung vom PLM-Systemen nur mit hohem Aufwand möglich. Ein einfaches Beispiel ist die Mehrfachverbauung einer Baugruppe in verschiedenen Produkten, die mittels „Where used“-Abfrage schnell beantwortet werden kann. Oder es gibt Abhängigkeiten zu Bedienungsanleitungen oder Servicedokumenten. Der zuständige Konfigurations-Manager kann dann sicher entscheiden, welchen Einfluss eine Änderung hat und was zu tun ist, um diese konsistent umzusetzen.

Für eine effiziente Umsetzung von CMII-Elementen ist eine gute Unterstützung durch eine PLM-Software unabdingbar. Aber auch aus Sicht des PLM-Projekts gilt: PLM-Werkzeuge mit CMII- Prozessen, Formularen, Regeln und Rollen nutzen die Synergien aus einem interessanten Vorgehensmodell und können somit signifikant zum Gesamterfolg eines PLM-Projektes führen. PLM und CMII – da passt vieles zusammen.

Wir bleiben beim Standard – oder doch nicht?

Veröffentlicht am 23. Januar 2015, aktualisiert am 13. Februar 2015 von Christoph

Welcher Projektleiter, PLM-Verantwortliche oder Berater kennt das nicht: PLM soll endlich auf professionelle Füße gestellt werden. Dafür wurden erste Geschäftsprozesse aufgenommen, über mögliche abzubildende Daten und deren Attribute und Abhängigkeiten gesprochen, mit verschiedenen Stakeholdern über Anforderungen diskutiert. Vielleicht entstand eine PLM Strategie und eine Roadmap mit einer ersten groben Zeit- und Ressourcenplanung. Das neue PLM-Projektteam hatte erste Meetings, die Kekse waren lecker. Man fand sich zusammen und ging motiviert an die ersten Aufgaben. Nach gar nicht langer Zeit gaben sich dann erste PLM-Systemhersteller und -dienstleiter die Klinke in die Hand und stellten Ihre Softwarelösungen vor. Ein Benchmark wurde aufgesetzt, um Anbieter miteinander zu vergleichen und das beste System herauszufinden. Und spätestens hier fiel das erste Mal der Satz: Wir bleiben beim Standard! Der zukünftige PLM-Systemanwender möchte auf keinen Fall teure, ausufernde Anpassungen des PLM-Systems. Maximal sollen einige wenige Dinge konfiguriert werden, auf keinen Fall etwas individuell programmiert werden. “Zur Not ändern wir unsere Prozesse und passen uns dem PLM-System an!”. In wenigen Dingen besteht am Anfang einer PLM-Systemimplementierung mehr Einigkeit als über diesen Punkt: “Wir bleiben beim Standard – keine großen Anpassungen der PLM-Software”.

Einige Wochen/Monate/Jahre später wird beim ersten großen Releasewechsel oder einem anderen passenden Anlass die Implementierung und die Systemänderungen gereviewt. Wäre das PLM-System ein Fahrzeug, wäre mit einem bisschen Glück noch die Markenidentität zu erkennen. Aber sonst? Zusätzliche Navigationsgeräte, Leichtmetallfelgen (manchmal auch als Lenkrad!), Sportauspuffanlagen, an allen Fahrzeugseiten Anhängerkupplungen und der Motor ist nur getunt oder gegen einen Warp-Antrieb ausgetauscht. Dass das Fahrzeug in einigen Situationen beim Rechtslenken nach links fährt und der Rückwärtsgang nicht mehr funktioniert, dafür aber einen hervorragenden Kaffee kocht – geschenkt.

Bundesarchiv, Bild 183-68283-0001 / CC-BY-SA [CC BY-SA 3.0 de (http://creativecommons.org/licenses/by-sa/3.0/de/deed.en)], via Wikimedia Commons

Das blieb also übrig von “Wir bleiben beim Standard”. Wenig bis fast gar nichts. Auch diese Situation ist vielen nicht ganz unbekannt sein, oder?

Warum kommt es aber dazu, dass das viele Vorteile bietende Ziel des Nutzens von Standardfunktionen nicht getroffen wird? Mir fallen drei Gründe ein.

Zum einen ist es nur mit größten Anstrengungen möglich, dass sich Unternehmensorganisationen, -prozesse und -abläufe an Software anpassen. PLM-Prozesse sind das “offene Herz” von Industrieunternehmen, die ändert man nicht eben mal so schnell ab, nur weil Software nicht so tickt wie sie soll. Die etablierten Zuständigkeiten und Abläufe sind ja auch oft bewährt und funktionieren gut.

Der zweite Grund ist, dass es gar keine unternehmensübergreifenden Standards gibt bzw. sie so generisch definiert sind, dass konkrete Implementierungen gar nicht möglich sind. Jeder, der mal vor der Aufgabe stand, QM-Vorschriften in Software zu gießen, wird ein Lied davon singen können. Sicher gibt es aber auch Bemühungen und Anstrengungen, Standardisierung voranzutreiben. Ein Beispiel wäre das Konfigurationsmanagement CMII oder Analysetechniken wie eine FMEA.

Der dritte Grund ist, dass es ja nur bedingt im Interesse von Dienstleistern und Herstellern ist, Standards “out-of-the-box” anzubieten. Die Implementierungsprojekte sorgen für zusätzlichen Ertrag, der traditionell beim Preiskampf im Lizenzverkauf in die Binsen ging. Dienstleister und Softwarehersteller betreiben PLM nicht nur aus rein akademischem Interesse wie ich ;-), sondern müssen am Ende des Tages Umsatz machen.

Meine persönliche Erfahrung gibt kein einziges PLM-Projekt her, an dem nicht an der PLM-Software konfiguriert und programmiert wurde. Mich würde es aber brennend interessieren, ob es andere Erfahrungen gibt. Über eine Diskussion in den Kommentaren zu diesem Artikel würde ich mich sehr freuen. Übrigens, ERP-Consultants dürfen sich auch wiedererkannt haben und können auch gern mitdiskutieren.