Der geneigte Leser mag sich noch an meinen Artikel über die infrastrukturellen Voraussetzungen eines erfolgreichen PLM-Projekts erinnern. Aber leider ist es mit der reinen IT Infrastruktur nicht getan und deshalb wende ich mich heute dem Aspekt der Organisation zu. Konkret geht es mir genau um den Übergang von der Implementierungsphase in den produktiven Betrieb des PLM-Systems und das weniger aus technischer Sicht, sondern aus dem Blickwinkel der Unternehmensorganisation und den damit zusammenhängenden menschlichen Faktoren. Wie bekommen Sie als Eltern des PLM-Systems diesen gerade der Pubertät entwachsenen Sprössling gut und sicher in den Ernst des Lebens, nämlich in den produktiven Betrieb? 

Als Erstes möchte ich mit einem noch oft gehörtem Trugschluss einer PLM-Einführung ausräumen. Vergessen Sie den Gedanken, dass so ein PLM-System jemals “fertig” ist. Ihre Produkte müssen sich ständig neuen Markterfordernissen anpassen oder sie setzen neue Trends und Innovationen auf Ihrem Markt.

Des Weiteren ziehen gerade in der Produktentwicklung immer mehr agile Methoden ein. Dieses Internet, von dem man in den letzten Monaten so viel hört, bringt vollkommen neue Geschäftskonzepte hervor und lässt komplette traditionelle Produkte verschwinden.Das zwingt jeden Marktteilnehmer zur Anpassung.

Vor diesem Hintergrund kann und darf ein PLM-System nicht statisch sein. Die Anpassung dieses System zur Unterstützung Ihrer Produktinnovation ist nicht die Ausnahme, es ist der Regelfall. Daher muss sich auch jeder PLM-Systemlieferant daran messen lassen, wie einfach und durchgängig Änderungen an seinem System vorgenommen werden können. Für mich als Verantwortlicher eines PLM-Systembenchmarks wäre diese Adaptionsfähigkeit das allerwichtigste Kriterium. Den Gedanken an ausreichende oder sogar vollständige Out-of-the-box Funktionalität legen sie besser beiseite. Wenn alles OOTB funktionieren soll, was was unterscheidet sie dann von Ihrer Konkurrenz? Des Weiteren kann in ein paar Jahren die OOTB Funktion von heute vom Stand der Technik überholt worden sein. Oder wer benutzt heute noch ein Nokia 3210 oder bringt noch analoge Filme zu entwickeln? Und wer weiß, was diese Digitalisierung in den nächsten Jahren noch an neuen Konzepten und Innovationen hervorbringt, die mit Sicherheit Einfluss auf ihr PLM-System haben werden. 

Was heißt das jetzt aber für Ihre Unternehmensorganisation? Die Schlussfolgerung liegt auf der Hand: Sie benötigen Mitarbeiterinnen und Mitarbeiter, die mit dieser Herausforderung der ständigen Änderung umgehen können. Und sie müssen sich natürlich Gedanken über Prozesse und Methoden machen, die dies unterstützen.

Das ist einfacher gesagt als getan. Im Implementierungsprojekt hat ihr PLM Systemhaus diese Aufgaben übernommen. Er hat Ihre Anforderungen aufgenommen, das PLM-System ihrer Wahl dahingehend angepasst, die Ergebnisse in regelmäßigen Sprints vorgestellt, Feedback eingesammelt und so das erste produktive Release des PLM-System erstellt. Für diese Implementierungspartner ist das tägliches Brot, sie haben entsprechende Prozesse und Infrastruktur am Start und deren Mitarbeiter sind darauf geschult und trainiert. Genau aus diesem Grund haben Sie ja auch diese externe Unterstützung eingekauft. 

Basierend auf Ihren guten oder nicht so guten Erfahrungen während der Implementierungsphase können sie dann eine erste Entscheidung treffen: Wollen sie alle weitere Änderungen am produktiven PLM-System von Ihrem Implementierungspartner durchführen lassen? Der Vorteil dieser Lösung liegt auf der Hand: Es ist die Fortführung von mittlerweile eingespielten Prozessen und Verantwortlichkeiten und sollte ein beherrschbares Risiko beinhalten.

Der Nachteil ist aber auch klar: Die schnelle Verfügbarkeit der Consultants ist nicht garantiert, sie machen sich ein Stück weit abhängig von ihm und die Kostenseite muss natürlich auch betrachtet werden. 

Alternativ können Sie auch darüber nachdenken, diese Aufgabe zumindest teilweise intern zu lösen. Die großen neuen Module vergeben sie weiterhin an Ihren Partner, aber die alltägliche Maintenance lösen sie mit internen Ressourcen. Oder sie befähigen ihr Team, zukünftig alle Anpassungen ihres PLM-Systems vorzunehmen.

Beides bedingt, dass sie bereits während der Implementierungsphase Gedanken über die Organisation, die Ressourcen und die Methoden und  Prozesse machen müssen. Es gibt natürlich auch Industriestandards wie ITIL, die sie dabei unterstützen können, gute Lösungen zu finden. 

Aber eigentlich reicht auch der gesunde Menschenverstand, um über die Frage nachzudenken, was nach der Produktivsetzung passieren muss. Prinzipiell müssen sie die Methoden, Prozesse und die Infrastruktur Ihres Implementierungspartners auf sich selbst adaptieren.

Zur Infrastruktur hatte ich mich bereits in einem anderen Blogartikel ausgelassen. Aber das ist nur eine Seite der Medaille, die andere betrifft ihre Mitarbeiter und Unternehmensorganisation. Ich möchte hier nur einige Aspekte ansprechen:

Support

Auch wenn ihre Anwender intensiv trainiert und geschult werden, trotzdem wird es im laufenden Betrieb Fragen geben. Wer übernimmt diesen first und second level Support bei Ihnen? Sollen das Ihre Key User aus dem Implementierungsprojekt sein oder richten sie eine dezidierte Supportmannschaft ein?

Instandhaltung

Wer kümmert sich um die Kommunikation von Issues, die an den Hersteller des PLM-Systems weitergeleitet werden müssen? Und wer verfolgt das weiter? Daraus ergeben sich auch Fragen, wie die Änderungen (Hotfixes, Patches) in ihr Produktivsystem gelangen sollen. Wer übernimmt Verantwortung für das Aufsetzen und die Wartung Ihrer Integrationsumgebung und ihres Testsystems.

Tests und Qualitätssicherung

Wer kümmert sich um die Organisation von Testaktivitäten, ohne die Änderungen an einem Produktivsystem auf keinen Fall vorgenommen werden dürfen? Wer übernimmt Verantwortung für die interne Freigabe von neuen Releases?

Anpassungen und tägliche Wartung

Und dann gibt es noch diese ganz normalen Anpassungen, die ständig anfallen werden. Wer übernimmt die notwendigen Pflegearbeiten am PLM-System? Das geht von der Anlage von Benutzeraccounts und der Vergabe von Berechtigungen über einfache Änderungen an den Businessobjekten (z.B. neue Klassifikationen ihrer Dokumente) bis hin zu komplexen Änderungen an den implementierten Geschäftslogiken. 

Diese Liste von Fragen und Aspekte erhebt keinen Anspruch auf Vollständigkeit. Dafür ist dieses Thema auch zu individuell und zu unternehmensspezifisch.

Eine gute und bewährte Strategie, die richtigen Fragen zu stellen und auch passende Antworten darauf zu finden, ist es, die zukünftige Supportorganisation frühzeitig in das Implementierungsprojekt einzubinden. Denken sie daran, es ist IHR PLM-System und nicht das Ihres PLM Systemhauses. Lernen sie aus den Erfahrungen ihrer Implementierungsphase und profitieren sie vom Wissen, dass Ihr Partner mit Ihnen dabei teilt. Nicht jedes Rad muss neu erfunden werden.

Vor einigen Tagen hat mir Bernd Ebert, der hier auch schon auf der PLM Couch saß, einen weiteren vielversprechenden Ansatz zur Lösung dieses Problems vorgestellt.

Es geht dabei um DevOps, einen Prozessverbesserungsansatz aus dem Bereich Softwarentwicklung und Systemadministration. Das ist definitiv einen Blick wert – aber das soll in einem anderen Blogartikel passieren.