PLM-Einführung in acht Schritten: Warum die Reihenfolge entscheidet

Ein neues PLM-System übernimmt alte Schwierigkeiten, wenn sie vorher niemand klärt. Deshalb gehören bestehende Abläufe, Daten und Schnittstellen auf den Tisch, bevor die neue Lösung gebaut wird.

Warum ein neues System alte Probleme übernimmt

Viele PLM-Vorhaben beginnen mit der Systemfrage: welches Produkt, welcher Implementierungspartner, wie viele Lizenzen. Die Ursachen der heutigen Schwierigkeiten liegen nach meiner Erfahrung aber selten im alten System. Sie liegen in unklaren Freigabeprozessen, in Stücklisten, die in CAD und ERP unterschiedlich aufgebaut sind, in Artikeln ohne verbindliche Klassifizierung und in Zuständigkeiten, die nie festgelegt wurden.

Wer diese Punkte nicht klärt, bildet sie im neuen System nach. Oft sogar in sauberer Form, und damit sind sie schwerer zu erkennen und teurer zu korrigieren.

Dieser Beitrag beschreibt die Reihenfolge, die ich für eine Einführung oder Ablösung empfehle. Sie gilt unabhängig vom System. Wo es um Besonderheiten konfigurierbarer Systeme geht, beziehe ich mich auf Teamcenter von Siemens, weil dort unser Schwerpunkt liegt.

Das Vorgehen im Überblick

Die acht Schritte bauen aufeinander auf. Datenqualität und Veränderung beginnen im ersten Schritt und laufen über die gesamte Einführung mit.

Schritte 1 bis 3: Klären, bevor gebaut wird

1. Ziele, Erfolgskriterien und Verantwortliche festlegen

«Bessere Zusammenarbeit» oder «eine Datenquelle für alle» sind Wünsche, keine Ziele. Ein brauchbares Ziel lässt sich nach dem Go-live überprüfen, etwa die Durchlaufzeit einer technischen Änderung oder der Aufwand für die Übertragung von Stücklisten ins ERP. Dazu braucht es einen Ausgangswert, der vor Projektbeginn erhoben wird.

Ein PLM-Projekt berührt Entwicklung, Produktion, Einkauf, Qualität und Service. Zwischen diesen Bereichen entstehen Zielkonflikte, die das Projektteam nicht selbst entscheiden kann. Dafür braucht es einen Sponsor aus der Geschäftsleitung.

Für jeden Kernprozess, etwa Artikelanlage, Freigabe und Änderungswesen, sollte eine verantwortliche Person aus dem Fachbereich benannt sein. Sie entscheidet, wie der Prozess künftig läuft. Die IT setzt um, sie legt die Abläufe nicht fest.

2. Bestehende Abläufe und Systemabhängigkeiten verstehen

Entscheidend ist, wie heute tatsächlich gearbeitet wird, nicht wie es im Prozesshandbuch steht. Die aufschlussreichsten Hinweise liefern Umgehungslösungen: Excel-Listen neben dem System, manuelle Übertragungen ins ERP, Ablageordner mit eigener Logik. Jede davon zeigt eine Stelle, an der Prozess und System heute nicht zusammenpassen.

Parallel dazu entsteht eine Landkarte der beteiligten Systeme. Dazu gehören ein oder mehrere CAD-Systeme, das ERP, Dokumentenablagen und je nach Unternehmen ein Variantenkonfigurator oder ein Lieferantenportal. Für jede Verbindung ist festzuhalten, welche Daten in welche Richtung fliessen und wer sie auslöst.

Auch der Datenbestand gehört in diese Phase. Eine Stichprobe zeigt früh, wie es um Dubletten, fehlende Attribute und unvollständige Strukturen steht. Das beeinflusst den Aufwand der späteren Migration nach meiner Erfahrung stärker als die reine Datenmeng.

3. Künftige Prozesse und Datenregeln im Fachkonzept beschreiben

Das Fachkonzept beschreibt, was künftig passieren soll, nicht welche Funktion im System es auslöst. Typische Inhalte sind der Änderungsprozess, die Freigabestatus, die Nummernlogik, das Verhältnis von Artikel und Dokument, die Stücklistenarten von der Konstruktion bis zur Fertigung sowie Rollen und Berechtigungen.

Systemneutral zu beschreiben ist richtig, birgt aber ein Risiko. Ein Konzept, das nie mit einem konkreten Standard abgeglichen wurde, enthält Anforderungen, die sich nur mit aufwendigen Anpassungen umsetzen lassen. Jede dieser Anpassungen kostet bei späteren Upgrades erneut. Gerade ein stark konfigurierbares System wie Teamcenter verleitet dazu, jede heutige Gewohnheit nachzubauen.

Deshalb empfehle ich, das Fachkonzept früh gegen den Standard des vorgesehenen Systems zu prüfen. Ist die Auswahl noch offen, dienen die Systeme auf der engeren Wahl als Massstab. Wo der Standard einen brauchbaren Weg anbietet, sollte die Abweichung begründet werden müssen, nicht die Übernahme.

Schritte 4 bis 6: Lösung festlegen und unter echten Bedingungen erproben

4. Anforderungen priorisieren und Lösungskonzept festlegen

Nicht jede Anforderung gehört in die erste Etappe. Eine einfache Einteilung hilft: nötig für den ersten produktiven Ablauf, später sinnvoll, verzichtbar. Ist das System noch nicht gewählt, fällt hier die Auswahl. Anbieter sollten dann eigene Fälle des Unternehmens durchspielen, nicht ihre Standarddemonstration.

Das Lösungskonzept übersetzt das Fachkonzept in das System. Es legt das Datenmodell, die Workflows, die Rollen und Berechtigungen sowie den Betrieb fest. Besonders sorgfältig zu klären sind die Schnittstellen: die CAD-Integration und die Übergabe von Artikeln und Stücklisten ins ERP. Für jedes Datenobjekt muss eindeutig sein, welches System führend ist. Diese Frage wird in vielen Projekten zu spät gestellt und dann unter Zeitdruck entschieden.

5. Datenübernahme vorbereiten und erproben

Zuerst ist zu entscheiden, was überhaupt übernommen wird: der gesamte Bestand, nur die aktuell gültigen Stände oder eine Auswahl, während der Rest archiviert wird. Diese Entscheidung bestimmt Aufwand und Risiko der Migration.

Bereinigt wird möglichst im Altsystem, bevor die Daten übernommen werden. Danach folgen mehrere Probemigrationen. Jede wird gegen vorher festgelegte Abnahmekriterien geprüft:

Stimmen die Anzahlen zwischen Alt- und Neusystem?
Sind Produktstrukturen vollständig und richtig verschachtelt?
Hängen Revisionen und Änderungsstände korrekt zusammen?
Sind Dokumente und CAD-Modelle mit den richtigen Artikeln verknüpft und lassen sie sich öffnen?

Die Probemigrationen liefern auch die Laufzeit. Daraus ergibt sich, wie lange das Umstellungsfenster sein muss.

Besonderheit bei einer Ablösung. Es reicht nicht, dass Daten importiert wurden. Revisionen, Produktstrukturen und Verknüpfungen müssen stimmen, sonst arbeitet die Konstruktion nach der Umstellung mit falschen Ständen. Zudem muss vorher feststehen, wie Änderungen behandelt werden, die während der Umstellung laufen. Üblich sind ein Änderungsstopp für die Dauer der Umstellung oder eine Nachmigration der Änderungen seit der letzten Übernahme. Beides muss geplant und mit den Fachbereichen abgestimmt sein.

6. Einen vollständigen Ablauf mit echten Produktdaten testen

Einzelne Funktionen getrennt zu testen reicht nicht. Mindestens ein Ablauf sollte von Anfang bis Ende durchgespielt werden: Ein Teil wird konstruiert, Zeichnung und Stückliste entstehen, die Freigabe läuft, Artikel und Stückliste gehen ins ERP, danach wird eine Änderung durchgeführt.

Getestet wird mit migrierten Daten, nicht mit Demodaten. Nur so zeigen sich Lücken in Strukturen, Attributen und Verknüpfungen. Die Tests führen künftige Anwenderinnen und Anwender durch, nicht nur das Projektteam. Sie bemerken, wenn ein Ablauf zwar funktioniert, im Alltag aber nicht praktikabel ist. Berechtigungen und Antwortzeiten gehören ebenfalls dazu.

Schritte 7 und 8: Umstellen und den Betrieb sichern

7. Anwender und Support vorbereiten und die Umstellung bewusst freigeben

Key User werden früh und vertieft geschult, weil sie schon an Ist-Analyse und Fachkonzept mitarbeiten. Die übrigen Anwenderinnen und Anwender werden kurz vor dem Go-live geschult, nach Rollen getrennt und mit Übungsdaten aus dem eigenen Bestand. Dazu gehört eine frühe Planung, welche Rolle welche Aufgaben beherrschen muss, und genügend Zeit im Projektplan.

Die Umstellung selbst ist eine Entscheidung, kein Datum im Projektplan. Ich empfehle einen Go/No-Go-Entscheid nach Kriterien, die vorher festgelegt wurden: Ergebnisse des Gesamttests, offene Fehler nach Schwere, Resultat der letzten Probemigration, Stand der Schulungen und Bereitschaft des Supports. Dazu gehört ein Rückfallplan, der festhält, bis zu welchem Zeitpunkt eine Rückkehr zum Altsystem möglich ist und wie sie abläuft.

8. Den Betrieb stabilisieren und das Altsystem geordnet ablösen

Nach dem Go-live folgt eine Phase mit verstärkter Begleitung. Fragen und Fehler werden schnell beantwortet, damit sich keine neuen Umgehungslösungen einschleifen. Danach werden die Ziele aus Schritt 1 gemessen und mit dem Ausgangswert verglichen, etwa die Durchlaufzeit einer technischen Änderung oder der Aufwand für die Übertragung von Stücklisten ins ERP.

Das Altsystem wird erst abgeschaltet, wenn klar ist, was mit den nicht migrierten Daten geschieht. Sie müssen auffindbar bleiben, solange Aufbewahrungspflichten oder Produkthaftung es verlangen. Ansprüche nach dem Schweizer Produktehaftpflichtgesetz erlöschen erst zehn Jahre nach dem Inverkehrbringen des betroffenen Produkts, bei laufenden Serien also mit jedem ausgelieferten Stück später. In regulierten Branchen gelten zusätzliche Regeln. Die EU-Medizinprodukteverordnung verlangt, die technische Dokumentation mindestens zehn Jahre nach dem letzten in Verkehr gebrachten Produkt bereitzuhalten, bei Implantaten 15 Jahre. Software im Qualitätsmanagementsystem, und damit auch das PLM-System, muss nach ISO 13485 vor dem ersten Einsatz validiert werden. In der Luftfahrt sind Konstruktionsdaten über die gesamte Betriebsdauer des Produkts aufzubewahren.

Schliesslich braucht das neue System eine Ordnung für den Betrieb: Wer verantwortet welche Daten, wer entscheidet über Anpassungen und wie werden Releases und Upgrades geplant. Ohne diese Ordnung verwildert auch ein sauber eingeführtes System mit der Zeit.

Was von Anfang an parallel laufen muss

Zwei Aufgaben lassen sich keinem einzelnen Schritt zuordnen. Sie beginnen am Anfang und laufen bis nach dem Go-live mit.

Datenqualität. Die Stichprobe in Schritt 2 zeigt, wo die Probleme liegen. Die Regeln aus dem Fachkonzept legen fest, wie gute Daten aussehen. Dazwischen liegt Bereinigungsarbeit, die nur der Fachbereich leisten kann, weil nur er weiss, welcher von zwei ähnlichen Artikeln der richtige ist. Wird diese Arbeit erst kurz vor der Migration angestossen, fehlt die Zeit. Deshalb braucht es früh Datenverantwortliche mit reservierter Kapazität.

Veränderung. Ein PLM-System verändert, wie Konstruktion, Arbeitsvorbereitung und Einkauf zusammenarbeiten. Wer davon betroffen ist, sollte das nicht erst in der Schulung erfahren. Key User aus den Fachbereichen gehören schon in die Ist-Analyse und ins Fachkonzept. Sie kennen die Umgehungslösungen und tragen das Ergebnis später in ihre Teams. Die Kommunikation sollte konkret sein: was sich für welche Rolle ändert und ab wann.

Der erste produktive Schritt muss vollständig nutzbar sein

Ein häufiger Fehler ist ein erster Go-live mit vielen halb fertigen Funktionen. Die Anwender arbeiten dann parallel im alten und im neuen System, und das Vertrauen in die Lösung sinkt, bevor sie ihren Nutzen zeigen kann.

Besser ist ein erster Schritt, der einen Ablauf vollständig abdeckt, zum Beispiel von der Konstruktion über die Freigabe bis zur Übergabe ins ERP, für eine Produktlinie oder einen Standort. Weitere Funktionen und Bereiche bauen darauf auf und profitieren von dem, was in der ersten Etappe gelernt wurde.

Wie Abexis unterstützt
Bei Abexis unterstützen wir Endkunden sowie Reseller und Implementierungspartner bei der Vorbereitung und Projektleitung von PLM/PDM-Vorhaben, mit Schwerpunkt auf Teamcenter von Siemens. Mehr dazu auf abexis.ch.
Was würden Sie bei Ihrer nächsten Einführung früher klären?