8-wesentliche Indizien für PLM-Readiness von Unternehmen
Eine der größten Hürden für den Erfolg von PLM ist die mangelnde PLM-Readiness der betreffenden Unternehmen.
PLM-bereiten Unternehmen haben im Grundtenor die 8 nachfolgende Überzeugung vom Top Management bis auf die Arbeitsebene entwickelt!
- Die Verfügbarkeit gut aufgebauter und richtiger Informationen wird als Grundvoraussetzung für die Geschäftsprozessfähigkeit und damit den Erfolg von Unternehmen gesehen.
- Die Organisation und Gestaltung des Flusses der Produktinformationen im Unternehmen werden als ein Hebel zur Erreichung der Unternehmensziele verstanden.
- Es ist klar, dass die Gestaltung der Informationsarchitektur auch auf strategisch/taktischer Ebene stattfinden muss und nicht allein Sachbearbeitern auf der operativen Ebene überlassen werden kann.
- Man ist sich bewusst, dass der Fluss der Informationen vom Markt/beim Kunden beginnend, durch das Unternehmen hindurch und dann zurück zum Kunden ganzheitlich betrachtet werden muss d.h. also End-to-End.
- Es sind Maßnahmen ergriffen, dass die Gestaltung des Flusses der Informationen nicht an Abteilungsgrenzen Halt macht.
- Es herrscht ein Bewusstsein, dass die frühe Verfügbarkeit von Informationen Upstream (zur Entwicklung hin) mehr Arbeit erzeugt, diese aber gut investiert ist, da sie Downstream (zur Produktion hin) eine Menge von Problemen vermeidet. Diese Mehrarbeit, die Upstream auftritt, wird dann auch kapazitiv berücksichtigt.
- Eine PLM Einführung wird nicht mit der Einführung einer Applikation im Sinne von Authoring Systemen verglichen, sondern man weiß, dass sie in eine Vielzahl zentraler Geschäftsprozesse des Unternehmens wirkt.
Die PLM-Bereitschaft allein reicht jedoch nicht aus.
Es gibt eine Reihe von Dingen, die lange im Verborgenen lagen und man früher einfach hoffen musste, das es richtig läuft.
Heute können wir diese verborgenen Dinge viel präziser formulieren. PLM-Implementierungen liegen unterschiedlichen Prozessmuster der Informationsarchitektur zugrunde. Diese Muster hängen nicht, wie vielfach angenommen, vorrangig von der Industrie ab, sondern davon wie ein Unternehmen sich strategisch zum Markt hin positionieren will. Welche dieser Prozessmuster ein Unternehmen beherrschen will bzw. muss, ist damit eine strategische Managemententscheidung des Unternehmens selbst. Diese darf und kann nicht von einem Solution Architekt, der die PLM-Implementierung begleitet aus dem Bauch heraus getroffen werden.
Hinzu kommen dann noch die Schwächen der heutigen PLM-Systeme. Diese stammen ja von PDM-Systemen ab, die oft Material nicht kannten. Noch heute haben die meisten große Lücken im Umgang mit Material, insbesondere wenn die Modellierung des Materials im Werksbezug notwendig wird. Wenn ich sehe, wie das manchmal implementiert wird und welche Lösungen propagiert werden, sträuben sich mir die Haare.
Das hat dann mitunter den Effekt, dass mache Solution Architekten den Kunden zu einer nicht passenden Lösung drängen, weil sie diese Lücke mit dem Material im Bauch fühlen und sie so proaktiv umgehen wollen. Der Kunde kann das dann oft nicht umreißen und geht den vorgeschlagenen Weg mit, bis es dann eben im Projekt kracht.
Sie sehen, PLM-Projekte enthalten, ohne dass sich dessen jemand bewusst ist, einen sehr explosiven Mix. Wenn vor dem erläuterten Hintergrund eine Unzufriedenheit bei dem betroffenen Mitarbeiter aufkommt, geschieht dies natürlich zurecht, da das, was sie bekommen, nicht dem entspricht, was sie wirklich brauchen.
Welche Prozessfähigkeit soll erlangt werden
Ich denke und propagiere, dass es notwendig ist die Implementierung von PLM grundsätzlich anders zu denken. Vor dem Projekt muss die Frage beantwortet werden, welche Prozessfähigkeit ein Unternehmen morgen und in der Zukunft erlangen will. Damit erübrigt sich auch die Aussage „das haben wir aber schon immer so gemacht”. Wenn diese Aussage richtig wäre, gäbe es das Projekt nicht, da die Prozessfähigkeit im Status Quo bereits vorhanden wäre. Der Antwort auf die notwendige Prozessfähigkeit folgt die Wahl des notwendigen Prozessmusters für die Informationsarchitektur. Ein solches Prozessmuster betrifft das Unternehmen gesamtheitlich, d.h. damit auch alle dort implementierten oder zu implementierenden Backbonesysteme, also CRM/PLM/ERP und MES.
Adaptieren von Prozessmsutern
Die Prozessmuster können nun von den Unternehmen adaptiert werden, in dem daraus ein für das Unternehmen angepasstes Gesamtkonzept für Prozessfähigkeit und Informationsarchitektur entsteht, was zuallererst mit den wichtigen Stakeholdern im Unternehmen abgestimmt werden muss. Dabei geht es nicht nur darum, das Okay für das Konzept zu bekommen, sondern vielmehr die Akzeptanz der Veränderung, die damit einhergeht zu erzeugen.
An diesem Punkt ist ein Stand erreicht, bei dem allen Stakeholdern klar sein sollte, was zu tun ist, warum man es tut und was das große Ziel hinter allem ist. Dann ist die wesentliche Basis geschaffen.
Ausdetaillieren der Alpha Edition
Nun muss die Konzeption ausdetailliert, auf die Backbonesysteme verteilt und in umsetzbare Scheiben geschnitten werden. Grundsätzlich empfehle ich, diese ausdetaillierte Konzeption an einer Shortlist der möglichen Backbonesysteme zu verproben. Es reicht nicht aus, sich eine Lösung zeigen zu lassen und dann anhand von langen Excellisten das Vorhandensein gewünschter Funktionen abzufragen. Das ist ein Vorgehen aus den 90er Jahren des letzten Jahrhunderts und wenn ich heute Beratungsunternehmen sehe, die das propagieren, kann ich nur mit dem Kopf schütteln. Die Erprobung in einer Art Digitalisierungslabor im Unternehmen dient dabei nicht nur dem Prüfen der Eignung des jeweiligen Systems. Man muss sie viel mehr als Ort der Entwicklung der zukünftigen Prozess- und PLM-Fähigkeiten eines Unternehmens verstehen. In diesem Digitalisierungslabor werden die Mitarbeiter an die Technologien herangeführt und ausgebildet. Darüber hinaus wird auch noch die für das Unternehmen passende Technologie evaluiert.
Flankierendes Change Management
Flankiert man das Ganze mit einem geeigneten Change Management Ansatz, so dass auch die Kommunikation ins Unternehmen sauber läuft, wird die Implementierung sehr viel leichter. Das Problem bei diesem Vorgehen ist die Notwendigkeit eines größeren Budgetbedarfs. Wie auch immer man es dreht und wendet, letztendlich fallen die Kosten ohnehin an. Prozessfähigkeit ist eine Fähigkeit, die vom Selbstverständnis der eigenen Mitarbeiter getragen wird. Das ist nicht etwas, was man sich mit einem IT-System einkauft. Ignoriert man die Vorbereitung am Anfang und tut so, als seien diese nicht Notwendig, kommt später die böse Überraschung.
Hierzu habe ich auch ein Beispiel, basierend auf einer wahren Geschichte. Es war einmal ein PLM-System Berater, der bei einem großen mittelständischen Unternehmen im PLM-Projekt beteiligt war. Dieser PLM-System Berater hatte das Problem, dass er Rechte und Rollen im System anlegen musste. Somit brachte er auf Sachbearbeiterebene die Frage auf, wer wann auf was zugreifen dürfe. Die Sachbearbeiter wussten das nicht und fragten ihren Manager. Der Manager war aufgebracht. Rolle und Rechte war etwas, was intern auf höhere Managementebene zu klären war und nicht auf Sachbearbeiterebene im PLM-Projekt. Als der PLM-System Berater zum nächsten Meeting kam, wunderte er sich, dass es sich anfühlte als würde er gegen eine taube, kalte Wand sprechen. Die notwendige Antwort bekam er nicht, seine Arbeit konnte er auch nicht weiter tun. Als dann über ein Jahr später Konzeptfolien mit der Sicht des Managements auf Rollen und Rechte, die, unterstützt von teuren Strategieberatern, im Projekt erstellt wurden, beim PLM-System Berater ankamen, war dieses Konzept in keiner Weise implementierbar.
Schuld war zum Schluss der Systemanbieter mit seinen schlechten PLM-System Berater. Die Vertriebler des Systemanbieters krochen beim Kunden zu Kreuze und schenkten ihm ihren besten PLM-Methoden Berater für über ein Jahr.
Ja, so war das damals. Zugegebenermaßen ist diese Geschichte ein klein wenig überspitzt, aber im Kern hat sie sich tatsächlich so zugetragen.
