Anbieter von Product Lifecycle Management (PLM) versprechen, dass ihre Systeme so großartig sein werden, dass sie von Anfang an von Unternehmen eingesetzt werden können und die Art und Weise, wie sie ihre Produktdaten definieren und verwalten, revolutionieren. Dies gilt jedoch nur für Unternehmen, die bereit sind, ihre eigenen internen Standards und Verfahren im Interesse vorimplementierter Best Practices innerhalb von PLM-Systemen anzupassen. Alle anderen sind auf Konfiguration und Anpassung angewiesen. Was ist der Unterschied zwischen ihnen und wie kann man sicherstellen, dass sie in Zukunft nicht (Risiko, Nachteil, Schwäche?) enden? Lesen Sie weiter, um es herauszufinden.
OOTB
OOTB, oder „out-of-the-box“, ist die Reihe von Funktionalitäten, die den Benutzern unmittelbar nach der Installation eines Systems zur Verfügung stehen. Im Falle eines PLM-Systems bedeutet OOTB eine Gruppe von vordefinierten Elementen, wie z.B:
- Standard-Benutzeroberfläche mit Browsing- und Suchfunktionen
- Datenmodell (Objekttypen, ihre Attribute/Parameter)
- Lebenszyklen
- Arbeitsabläufe
- Objektvorlagen (einschließlich Produktvorlagen, komplett mit Rollen- und Sicherheitsdefinition)
Dies gilt insbesondere für größere und ausgereiftere PLM-Systeme wie PTC Windchill, die auf der Grundlage be stimmter Industriestandards und bewährter Verfahren entwickelt wurden. Sie wurden gemeinsam von ihren Schöpfern und einigen der klügsten Köpfe aus den besten Universitäten der Welt, aber auch von tatsächlichen Kunden, durch jahrelange Systemnutzung und praktische Erfahrung definiert. Einige Dinge, die anfänglich im System als üblich galten, haben nach und nach ihren Weg in das Kernprodukt gefunden und wurden zu „OOTB“.
Die meisten Software-Anbieter rühmen sich damit, dass ihre Software „out-of-the-box“ bereit ist, jede Herausforderung für jedes Unternehmen zu meistern, aber nur sehr wenige stehen zu ihrem Wort. Stellen Sie sich vor: eine Office-Software-Suite mit einem Textverarbeitungsprogramm, einem Tabellenkalkulationsprogramm, einem Präsentationseditor usw. Diese werden ähnlich funktionieren, unabhängig davon, wer sie hergestellt hat (OK, es mag einige leichte Unterschiede in der Benutzeroberfläche (UI) oder den Arten von Animationen geben, die Sie verwenden können, aber das allgemeine „Gefühl“ ist das gleiche).
Im Falle von PLM gibt es jedoch keine „eine Größe für alle“ Lösung. Es ist sehr unwahrscheinlich, dass ein OOTB-System innerhalb „irgendeiner“ Organisation effektiv eingesetzt werden kann. Vor allem größere und/oder ältere Unternehmen haben ihre eigenen Arbeitsmethoden entwickelt, die sich als effektiv erwiesen haben und die nicht geändert werden sollten, damit sie in das System passen – vielmehr sollte das System geändert werden, damit es in diese Methoden passt. Welche Daten und Metadaten wir für wichtig erachten und uns entscheiden, in einem PLM-System zu speichern, ändert sich ebenfalls von Organisation zu Organisation, ebenso wie die ihnen zugewiesenen Rollen und Zugangskontrollregeln. Diese und viele andere Dinge müssen normalerweise in einem PLM-System geändert werden, bevor es für eine Organisation wirklich brauchbar wird, und hier kommen Konfiguration und Anpassung ins Spiel.
Obwohl diese beiden Begriffe ähnlich klingen, unterscheiden sie sich in der Tat erheblich in ihrer Bedeutung. Lassen Sie uns zunächst definieren, was diese beiden Begriffe sind – mit so einfachen Worten wie möglich.
Was ist Konfiguration?
Die Konfiguration (in einem PLM-System) umfasst alle Änderungen, die Sie aus Sicht der Benutzeroberfläche an einem Produkt vornehmen können. PLM-Anbieter enthalten in der Regel Konfigurationswerkzeuge, mit denen Sie das Systemverhalten in begrenztem Umfang ändern können. Dazu gehören solche Dinge wie:
- Änderungen am Datenmodell, einschließlich der Definition neuer Objekttypen und sie beschreibender Attribute
- Definition von Lebenszyklen und Lebenszykluszuständen
- (teilweise) Definition von Arbeitsabläufen
- Definition von Objektvorlagen (Produkt, Bibliothek usw.) – einschließlich Definition von Rollen innerhalb von Containern und Zugriffskontrollregeln
- Verwaltung des Systemverhaltens durch Präferenzen
Einige Leute schließen auch die mögliche Änderung von Systemeigenschaftswerten (im Falle von Windchill: Änderung der Open-Text-Werte in .property-Dateien) als Konfiguration ein, aber der Klarheit halber sollten wir dies an dieser Stelle nicht in diese Kategorie aufnehmen.
Mit anderen Worten, die Konfiguration ist eine Systemänderung, die keinen Zugriff, keine Änderung, Implementierung usw. des Quellcodes des Systems erfordert[1]. Aus diesem Grund betrachten viele Leute auch die Fähigkeit zur Konfiguration der Software (und damit die Konfiguration selbst) als integralen Bestandteil der OOTB-Funktionalität.
Konfigurationen werden im Allgemeinen zwischen den Systemversionen unterstützt, so dass Sie sich bei einem Upgrade Ihres PLM-Systems in der Regel keine Gedanken über ein Upgrade der Konfiguration auf eine neuere Version machen müssen.
[1] Ja, die Konfiguration kann normalerweise von einem System exportiert werden (um sie in eine andere Instanz zu importieren), und dann nimmt sie die Form von XML oder anderen Dateien an, die Code enthalten können, aber Sie müssen diesen Code nicht wirklich „anfassen“: einen Texteditor öffnen und irgendetwas schreiben. Sie „exportieren“ ihn einfach und „importieren“ ihn, ohne tatsächlich in diese Dateien zu schauen.
Was ist Anpassung?
Anpassung hingegen ist alles, was über die Konfiguration hinausgeht. Anpassung ist jede Systemänderung, die eine Änderung oder Erweiterung des Quellcodes des Systems (d.h. Implementierung, Entwicklung) erfordert, da das gewünschte Ergebnis nicht allein durch Konfiguration erreicht werden kann. In den meisten Fällen umfassen Anpassungsbeispiele:
- Triggers (Auslöser, die eine bestimmte Aktion/Systemverhalten auslösen, wenn ein bestimmtes Ereignis eintritt, z.B. automatische Veröffentlichung bei Abschluss der Änderungsbenachrichtigung usw.)
- Neue Benutzeraktionen und Assistenten
- Workflows (in einigen Fällen) – Windchill ermöglicht Ihnen das Schreiben von Code. Wenn Sie also während der Ausführung Ihres Workflows eine benutzerdefinierte Verarbeitung durchführen möchten, können Sie
- Systemintegrationen – leider sind fast alle Systemintegrationen für PLM kundenspezifisch.
- Einige Fälle von fortgeschrittener Geschäftsberichterstattung
- Verschiedene Implementierungen von zusätzlichen Geschäftsregeln
Damit ist die Liste der möglichen Anpassungen aber noch nicht erschöpft. Während meiner jahrelangen Arbeit als Windchill-Entwickler habe ich viel gesehen, was die Leute mit dem System in Bezug auf die Einführung neuer/angepaßter Funktionen gemacht haben… und es gibt noch mehr von dem, was ich bisher noch nicht gesehen habe…
Software-Systeme, einschließlich PLM, haben in der Regel ihren eigenen Lebenszyklus und werden von Zeit zu Zeit von ihren Anbietern aktualisiert. PTC Windchill bildet hier keine Ausnahme, mit einer detaillierten Roadmap für die kommenden Jahre. Wenn Sie Ihr System auf eine neuere Version aktualisieren, sollten Sie niemals davon ausgehen, dass Ihre Anpassung ordnungsgemäß funktioniert. Systemanbieter führen Upgrades, Änderungen usw. an ihren Kernprodukten ein, was einige Anpassungen überflüssig machen kann, aber auch einige Teile davon können Codestücke betreffen, die im Kernprodukt nicht mehr vorhanden sind (oder nicht mehr so funktionieren wie früher) – was auf Ihrem PLM-System alle möglichen Verwüstungen anrichten kann. Bei jedem System-Upgrade mit vorhandenen Anpassungen sollte der Aufwand für die Überprüfung der Kompatibilität der Anpassung mit der neuen Version und (falls erforderlich) deren Upgrade berücksichtigt werden. Zum Vergleich: Ein Upgrade eines „Vanilla“-Systems kann manchmal innerhalb von Stunden abgeschlossen werden. Wenn komplexe und umfangreiche Anpassungen vorhanden sind, kann es Monate oder sogar Jahre dauern (ja, ich habe solche Fälle gesehen).
Was ist der Unterschied zwischen Konfiguration und Anpassung?
Wie Sie sehen können, besteht der Hauptunterschied zwischen Konfiguration und Anpassung darin, dass Ersteres in der Regel über die System-Benutzeroberfläche erreicht werden kann, während Letzteres von den Programmierern erfordert, neue/geänderte Funktionalität zu programmieren. Leider ist es nicht so einfach.
Die Konfiguration, selbst wenn sie in eine Reihe von Dateien exportiert wird (zum Zweck der Bereitstellung in einem anderen System), ist normalerweise relativ einfach zu verwalten: Verfolgen Sie einfach die Liste der Änderungen, die Sie vorgenommen haben, und ändern Sie die exportierten Dateien niemals manuell[2].
Anpassung, wie bei den meisten Dingen der Programmierung, kann (und ist in der Regel) viel komplexer sein und sollte entsprechend gehandhabt werden. Andernfalls führt der Einsatz zu einem System voller Bugs und Fehler oder sogar dazu, dass es überhaupt nicht (!) startet, was es unbrauchbar macht und damit eine große Verschwendung von Geld und Mühe bedeutet.
[2] Dies wäre in einer idealen Welt der Fall. In der realen Welt muss man manchmal Konfigurationsdateien modifizieren, die in der Regel XML sind. Dennoch beeinflusst man dadurch nicht den Code der Kern-App.
Woher weiß ich, ob eine Anpassung erforderlich ist?
Kein System oder keine Lösung könnte so konzipiert werden, dass alle Kunden in allen Industriebranchen optimal bedient werden können. In vielen Fällen wird eine kundenspezifische Anpassung in der Tat unvermeidlich sein. Sogar ein so häufiger Fall wie die Einspeisung von Informationen aus Ihrem PLM in Ihr ERP-System bei der „Freigabe für die Fertigung“ wird eine Anpassung in Form einer Systemintegration erfordern.
Als Kunde eines PLM-Systems sollten Sie nicht verpflichtet sein, alle Ins und Outs von PTC Windchill, Siemens Teamcenter oder irgendetwas anderem da draußen zu kennen. Der Versuch, alle Feinheiten und wichtigen Teile zu lernen, kann Jahre dauern, die Ihr Unternehmen vielleicht nicht hat.
Deshalb sollten Sie sich auf zwei Dinge verlassen:
- Der Systemverkäufer – schließlich sollte derjenige, der ein System herstellt, es am besten kennen (vorausgesetzt, seine Vertreter beschreiben wahrheitsgetreu, was ein System OOTB und durch Konfiguration tun kann und was nicht)
- Unabhängiger Partner, Systemintegrator, Value Added Reseller, etc. – wie Transition Technologies PSC – der Ihnen helfen kann, Ihre Bedürfnisse zu bewerten und zu definieren
Ein Partner sollte Ihr bester Partner bei der Implementierung eines PLM-Systems in Ihrem Unternehmen sein. Durch die jahrelange Zusammenarbeit mit anderen Kunden sollte ein solcher Partner ein tiefes Verständnis für die Werkzeuge, mit denen er arbeitet, erworben haben und Ihnen nicht nur sagen können, ob ein System so funktionieren kann, wie Sie es wünschen, sondern möglicherweise auch beraten können, ob es tatsächlich eine gute Idee ist, seine Funktionalität aufzugeben und ein eigenes zu entwickeln.
Wie sollte ich Anpassungen verwalten?
Software-Entwicklung und Systembetrieb, oft als DevOps bezeichnet, kann ein recht komplexes Thema sein – auch für Product-Lifecycle-Management-Systeme. Würde ich hier ins Detail gehen, würde daraus ein ganzer Artikel über DevOps Best Practices für PLM werden, daher werde ich es hier auf die notwendigen Details reduzieren:
- Verwenden Sie ein Versionskontrollsystem für Ihren Quellcode (idealerweise Git oder gleichwertig)
- Verwenden Sie ein System wie Atlassian Jira oder PTC Windchill RV&S (ehemals Integrity, als Application Lifecycle Management [ALM]-System), um den Entwicklungsfortschritt, Aufgaben, Probleme, Benutzergeschichten, Sprints usw. zu verfolgen.
- Integrieren Sie die beiden oben genannten Punkte so eng, dass niemand etwas im Repository ändern kann, wenn er nicht an einem bestimmten Ticket arbeitet.
- Verwenden Sie automatisierte Tests für jeden benutzerdefinierten Code (mindestens Unit-Tests).
- Verwenden Sie die automatisierte Umgebungserstellung (wenn möglich – vereinfacht und verringert den Aufwand und die Zeit) und bauen Sie Bereitstellungstools wie Jenkins.
- Enge Integration von Automatisierungswerkzeugen mit Tests, Quellcode und dem ALM-System.
- Verwendung mehrerer Validierungsumgebungen (z.B.: Programmierer programmieren in einem Dev-System, Tester testen auf einem Testsystem, Endbenutzer-Akzeptanztests werden auf einem QA-System durchgeführt – und schließlich wird bei der Produktion nichts geändert, es sei denn, es ist Teil eines offiziellen Veröffentlichungsplans, der verfolgt, verwaltet und validiert wird)
Ich kann ziemlich sicher sein, dass ein System, das Anpassung verwendet, auch eine Konfiguration hat. In diesem Fall sollte die Konfiguration, sobald sie aus dem Entwicklungssystem exportiert wurde, ebenfalls als Teil des oben beschriebenen Prozesses verwaltet werden – dies stellt sicher, dass die gesamte Systemeinführung kohärent und reibungslos verläuft und alle Probleme in einer frühen Phase erkannt und gelöst werden.
Offensichtlich wird der obige Prozess erheblich vereinfacht…. Trotzdem (oder vielleicht gerade deshalb) entscheiden sich einige Organisationen, ihn nicht zu befolgen und gehen bei der Entwicklung von PLM-Anpassungen ein hohes Risiko ein. Nach dem, was ich gesehen habe, endet dies immer in einer Katastrophe[3]. Wenn Sie also vermeiden wollen, Teil dieser Katastrophe zu werden, stellen Sie bitte sicher, dass Ihr PLM-Dienstleister die richtigen DevOps-Techniken anwendet, bevor es zu spät ist.
[3] Ja, immer. Früher oder später, aber immer.
Konfiguration vs. Anpassung
Nachdem Sie gelesen haben, was Sie bislang erfahren haben, denken Sie vielleicht, dass Sie sich von Anpassungen jeglicher Art fernhalten wollen: Sie sind oft komplex, riskant und kostspielig. Das stimmt im Großen und Ganzen: Was mit einem OOTB-Produkt mit einer gewissen (auch großen) Konfiguration erreicht werden kann, sollte auch so gemacht werden. Schließlich versuchen die meisten PLM-Anbieter, so viel Flexibilität wie möglich in ihre Produkte und Lösungen zu integrieren, damit Sie sich nicht anpassen müssen.
Bitte bedenken Sie jedoch, dass selbst das beste PLM-System nicht alle Funktionen genau so funktioniert, wie Sie es sich wünschen, und daher einige Änderungen erfordert. Wenn ein PLM-Vertriebsmitarbeiter jemals versucht, Sie davon zu überzeugen, dass sein PLM-Produkt vom Moment der Installation an perfekt zu Ihrem (und jedem anderen Unternehmen) passt, zeigen Sie ihm die Tür.
Gibt es so etwas wie zu viel Anpassung?
Doch, es gibt eine. Ich habe Projekte mit über einem Dutzend tausend benutzerdefinierten Klassen gesehen, die von ein paar Dutzend bis zu vielen tausend Codezeilen variieren. Es war überschaubar, aber kaum. Die Verwaltung von Abhängigkeiten zwischen verschiedenen Paketen wurde langsam zu einem Alptraum, und die Verfolgung eines Problems aufgrund einer Änderung der Anforderung und des von einer bestimmten Person entwickelten Code-Stücks war fast unmöglich. Das Testen und Debuggen der Lösung dauerte Wochen, wenn nicht Monate, vor jeder Veröffentlichung.
Dann kamen die System-Upgrades, die den Kerncode des Systems veränderten, das angepasst wurde…
(Selbstverständlich wurden alle Hoffnungen aufgegeben, dieses System zu verbessern, bevor es ernsthaft dekonfiguriert wurde).
Heutzutage veröffentlichen Hersteller häufiger als je zuvor neue Systemversionen. Genau wie bei physischen Produkten verkürzen sich auch bei Software die Produktlebenszyklen so weit, dass einige Versionen nur noch wenige Monate lang voll unterstützt werden. Kunden müssen nun entscheiden, ob sie die neuesten Funktionen nutzen (und häufig upgraden) oder eine LTS-Version (Long Term Support) installieren möchten. Je häufiger die Upgrades durchgeführt werden, desto mehr Zeit muss natürlich dafür aufgewendet werden, sicherzustellen, dass die Konfiguration und (insbesondere) die Anpassung weiterhin wie erwartet funktionieren.
Es ist jedoch nicht alles verloren, wenn Sie Ihr PLM-System tatsächlich stark modifizieren müssen. Es gibt einen Weg, auch umfangreiche und komplexe Anpassungen zu verwalten und zu pflegen: DevOps. Dieses Konzept vereinfacht, wenn es richtig umgesetzt wird, viele Prozesse erheblich und trägt dazu bei, die hohe Qualität einer Lösung auch dann beizubehalten, wenn erhebliche Änderungen eingeführt werden. Es löst nicht alle Herausforderungen, aber es hilft. Und zwar sehr viel.
Kann ich ein Cloud-gehostetes PLM-System anpassen?
Ja und nein. Lassen Sie mich erklären:
Wenn Sie sich entscheiden, Ihr PLM-System als SaaS (Software as a Service)-Angebot zu erwerben, dann übernimmt der Anbieter des Systems die gesamte Back-End-Arbeit: Einrichtung der Server, Installation und Wartung des Systems, Durchführung von Upgrades usw. Sie als Kunde erhalten jedoch nur selten (wenn überhaupt) Zugriff auf das eigentliche Betriebssystem (OS), auf dem die PLM-Anwendung läuft. Da Sie keinen Zugriff auf das Betriebssystem haben, können Sie Ihre benutzerdefinierten Klassen/Codes nicht einsetzen. Sie werden sich bei jeder Änderungsbereitstellung auf einen SaaS-Anbieter verlassen müssen. Einige Anbieter benötigen langwierige und umständliche Prozesse, um selbst die kleinste Änderung zu implementieren. Wählen Sie Ihren Partner daher sorgfältig aus und fragen Sie ihn nach seinem Implementierungsverfahren.
Dieser zweite Ansatz erfordert wesentlich mehr Aufwand, ganz zu schweigen von einem tiefen Wissen über Cloud-Lösungen, insbesondere wenn Sie einen zufriedenstellenden Automatisierungsgrad erreichen wollen. Glücklicherweise können Sie sich hier auf Ihren PLM-Partner verlassen, der Ihnen dabei hilft. Sehen Sie selbst, wie Sie Automatisierung auf SaaS-Niveau (oder mehr!) und Seelenfrieden erreichen können, während Sie die öffentliche Cloud zum Hosten Ihres Windchill-Systems nutzen, und zwar anhand eines realen Beispiels aus der Automobilindustrie:
Schlussfolgerung
Obwohl man leicht sagen könnte, dass man Anpassung um jeden Preis vermeiden sollte, gibt es in der PLM-Welt kein „eine Größe für alle“. „Zwar mögen einige Organisationen tatsächlich von der Verwendung eines OOTB PLM-Systems profitieren, aber es ist schwer zu erwarten, dass viele von ihnen ihre Prinzipien und Arbeitsmethoden loslassen – Dinge, die diese Unternehmen überhaupt erst so groß gemacht haben. Es stimmt zwar, dass man darauf abzielen sollte, die Anpassung auf ein Minimum zu reduzieren, aber selbst große Unternehmen können effizient verwaltet werden, wenn ein geeigneter Prozess angewandt wird. Letztendlich sollte die Entscheidung, ob man sich für eine Konfiguration oder Anpassung (oder sogar für ein bestimmtes PLM-Produkt) entscheidet, eine fundierte Entscheidung sein, die auf den wahren Bedürfnissen und Anforderungen Ihres Unternehmens basiert – im besten Fall unterstützt durch das breite Wissen und die Erfahrung eines vertrauenswürdigen Partners, der den Plan später ausführen kann. Schreiben.