In meinem heutigen Blogartikel wird es wieder etwas technisch. Bei jeder PLM-Einführung muss man über die dafür benötigte IT-Infrastruktur nachdenken. Denn einfach das PLM-System installieren und dann in dieser produktiven Umgebung Änderungen vornehmen, ist eine ganz schlechte Idee und in regulierten Branchen wie der Medizintechnik auch gar nicht zulässig. Dieses Setup von verschiedenen Umgebungen wird nicht nur einmalig bei der initialen Einführung benötigt. Jeder PLM-Systemhersteller liefert in bestimmten Abständen neue Major Releases seiner Software und manchmal ist auch das Einspielen von Service Packs oder Hotfixes notwendig. Und dann gibt es natürlich noch die ganz normalen Änderungen aufgrund von Anwenderwünschen, die entweder von ihrem eigenen Implementierungsteam entwickelt werden oder die sie extern von einem Dienstleister erstellen lassen.

Daher lohnt sich bei einer Auswahl eines PLM-Systems ein kritischer Blick auf diese technischen und eher operativen Anwendungsfälle. Meine Erfahrung zeigt aber, dass darauf leider nicht genügend Augenmerk gelegt wird und viele von den Kosten für den Betrieb des PLM-Systems überrascht werden. Wie gesagt, ein PLM-System ist nicht „fertig“ und Änderungen an diesem System eine häufige Aufgabe. Und wenn sie einem agilen Projektmanagementansatz folgen, ist dieser Transfer und Wechsel zwischen den Umgebungen tägliches Brot.

Aber welche Bestandteile oder Umgebungen benötigt jetzt aber so eine PLM-Einführung?

Die Entwicklungsumgebung:

Wie der Name schon sagt, ist das die Umgebung, in der jeder Entwickler getrennt arbeitet und programmiert.  Dazu gehören natürlich auch erste Tests. Nachdem diese erfolgreich absolviert wurden, werden die Änderungen an Quellcode und Konfiguration des PLM-Systems in die Integrationsumgebung übertragen.

Die Integrationsumgebung:

In diese Umgebung werden alle Änderungen der einzelnen Entwickler integriert und können das erste Mal gegeneinander getestet werden. Da gerade in einem agilen Umfeld diese Integrationstest täglich passieren, lohnt ein Blick in Richtung einer Testautomatisierung. Gerade Berechtigungen in Abhängigkeit der DImensionen Rollen/Gruppenzugehörigkeit und Lifecyclestatus können aus meiner Erfahrung heraus sehr gut automatisiert getestet werden mit einem vertretbarem Aufwand für die Programmierung der Testcases. Eine weitere wichtige Überlegung ist auch, wann und wie der gemeinsame Stand der Integrationsumgebung in die einzelnen Entwicklungsumgebungen zurückgespielt wird. So wird dann sichergestellt, dass alle Entwickler gegen die identische Konfiguration programmieren.

Die Test- und Validierungsumgebung

Auch hier ist der Name Programm. Diese Umgebung dient dazu, dass zukünftige Anwender die Umsetzung ihrer Anforderungen testen. Falls Sie mit externen Dienstleistern zusammenarbeiten, kann diese Umgebung sich auch noch einmal in zwei Instanzen aufteilen. Zum eine die Testumgebung bei Ihrem Dienstleister als letzte Qualitätssicherungsinstanz vor der Übergabe einer neuen Konfiguration an den Kunden. Und auf der anderen Seite gibt es ihre Testumgebung für die Durchführung ihrer Anwendertest und in regulierten Industrien (z.B. Medizintechnik) für die Durchführung der Systemvalidierung.

Eine weitere besondere Form kann noch eine „simulierte Produktivumgebung“ sein. Hier ist nicht nur ein kleiner Auszug ihrer Daten (Dokumente, CAD-Modelle. Zeichnungen,…) vorhanden, sondern eine vollständige Kopie Ihrer Produktivdaten. In dieser Umgebung können Sie dann unter realen Bedingungen die Leistungsfähigkeit ihrer neuen Funktionen testen und so Performanceprobleme identifizieren.

Die Produktivumgebung

Nach erfolgreichen Anwendertest und gegebenenfalls einer Validierung können Ihre Systemänderungen dann in Ihre Produktivumgebung übernommen werden.

Die Trainingsumgebung

Neue Anwender des PLM-Systems müssen in der Anwendung dessen trainiert werden. Dabei ist es unerheblich, ob das in einem Präsenztraining erfolgt oder mittels neuer Ansätze wie einem e-learning passiert. Eine dedizierte Umgebung mit generischen Trainingsidentitäten unterstützt diese notwendige Ausbildung.

S ie sehen, dass es eine ganze Reihe von dedizierten Umgebungen benötigt werden, um schlußendlich eine produktive Instanz sicher, in möglichst guter Qualität und, wenn notwenig, validiert betreiben zu können. Das führt mich wieder zu meinem anfangs geschilderten Problem zurück. Sie übertragen Änderungen an der Konfiguration Ihres PLM-Systems häufig von einer Umgebung in die andere und der Aufwand, der damit verbunden ist, macht einen signifikanten Teil der Betriebskosten aus. Werfen wir daher noch einen genaueren Blick auf den Charakter der Daten, die hier übertragen werden müssen. Bisher habe ich ja immer nur diesen recht abstrakten Begriff „Konfiguration“ dafür benutzt.

1) Änderungen des PLM-Systems zur Abbildung von Anwenderanforderungen

Das ist sowas wie das „täglich Brot“ Ihrer PLM-Administratoren und -Systemmanager. So ein PLM-System ist ja nie fertig und somit gibt es immer eine Reihe von Anwenderwünschen, die umgesetzt werden müssen. Dabei möchte ich die Daten, die dabei geändert werden, noch einmal ein wenig unterteilen:

Je nach Anwendungsfall müssen diese Daten einfach, schnell und vollständig in eine andere Umgebung transferiert werden können. Dabei ist es nicht in jedem Fall so, dass alle Daten immer und vollständig übertragen werden müssen. Ein schönes Beispiel dafür sind User. Ich glaube kaum, dass die generischen User aus Ihren Entwicklungsumgebungen sich in ihrer Produktivumgebung wiederfinden sollen. Das wäre doch eher seltsam, gerade wenn die produktiven User eigentlich aus einem AD oder LDAP gespeist werden. Anders ist dies aber vielleicht beim Update des Trainingssystems. Dort wäre es hilfreich, generische User automatisch übertragen zu können und diese nicht per Hand „nachklicken“ zu müssen.

Für die Konfigurationen und die programmierten Erweiterungen des PLM-Systems fällt mir kein Anwendungsfall ein, wo dieser Übertrag nicht vollständig sein muss. Es ist also immens wichtig zu überprüfen, ob die Mechanismen und Tools ihres (zukünftigen) PLM-Systems wirklich vollständig alle Objekte übertragen können oder ob es nicht doch welche gibt, die sie dann jedesmal manuell nachpflegen müssen. Dieser Aufwand ist nicht zu unterschätzen und das Fehlerpotenzial dafür ebenfalls nicht. Denken Sie daran, dieses eventuelle manuelle Übertragen von Konfigurationen fällt häufig an.

2) Neue Major Releases Ihres PLM-Systemherstellers

Jeder PLM-Systemhersteller entwickelt sein System auch weiter und bringt in regelmäßigen Abständen neue Releases seiner Software heraus. von diesen neuen Funktionen möchten sie natürlich profitieren und damit ist es wichtig zu erfahren, wie diese neue PLM-Systemversionen in ihre Umgebungen eingespielt werden können. Hier ändert sich ja nicht nur die Konfiguration ihres System, sondern die Basis, auf der ihre Konfiguration beruht. Sie müssen eine genaue Kenntnis darüber haben, welche Strategien und Werkzeuge ihr PLM-Systemhersteller anbietet, um sie bei dem Upgrade ihres Systems zu unterstützen. Wie wird zum Beispiel mit den Anpassungen umgegangen, die sie am System vorgenommen haben, wenn ein neues Softwarerelease eingespielt wird? Was passiert mit Ihrem Datenbestand und müssen eventuell sogar Daten migriert werden, weil sich Datenmodelländerungen sich nicht anders abbilden lassen? Eine gute Idee ist es, hier in die entsprechenden Anwendercommunities hineinzuhören und Erfahrungen mit anderen Anwendern zu teilen. Es gibt ja dafür seit kurzem dieses Internet, vom dem man in letzter Zeit so viel hört und liest.

3) Hotfixes und Servicepacks Ihres PLM-Systems

Fehlerfreie Software gibt es nicht und somit rutschen es auch bei sorgfältigster Qualitätssicherung Bugs in die Softwarereleases hinein. Das kann mit vertretbarem Aufwand nicht verhindert werden. Wie reagiert der Hersteller ihres Systems auf diese Fehler? In welchem Zeitraum liefert er Hotfixes und Service Packs?. Und sie müssen prüfen, wie diese Hotfixes und Servicepacks dann in Ihre Umgebungen eingespielt werden können. Das ähnelt dann den Herausforderungen, sie sie auch bei neuen Major Releases meistern müssen.

4) Lizenzen

Und zu guter Letzt git es bei einigen Herstellern noch zu berücksichtigen, dass sie Lizenzen kaufen müssen. Wie großzügig ist dann aber die Regelung für die eher generischen Anwender für Ihre Entwicklungs-, Integratiins- und Validierungsumgebungen?

Damit komme ich auch schon zum Ende dieses eher technischen Artikels. Vielleicht konnte ich Ihnen einige Hinweise geben und meine Erfahrungen mit Ihnen teilen. Für Kommentare und Ergänzungen steht Ihnen die Kommentarfunktion zur Verfügung.