Die Migration von Daten in ein PLM-System ist oft ein sehr komplexes Vorhaben, bei dem das Geschäftsumfeld und die Art und Weise, wie mit den Daten gearbeitet wird, eine wichtige Rolle spielen. Eine Migration – was ist das, welche Ansätze sind die gängigsten und welche Herausforderungen liegen vor jedem einzelnen? Diese und weitere Fragen werden in diesem Artikel beantwortet.
Was eine Datenmigration ist und wann Sie sie brauchen (können)
Eine Datenmigration ist der Prozess der Übertragung von Daten von einem System (Quelle) in ein anderes (Ziel / Destination).
Üblicherweise resultieren PLM-Datenmigrationen aus:
- Ablösung eines bestehenden Datenmanagementsystems (evtl. sogar eines PLM-Systems) durch ein anderes.
- Ingestion von Daten aus einem anderen System in das Haupt-PLM-System eines Unternehmens (z. B. nach einer Firmenübernahme).
- Zusammenführen mehrerer Datensätze in ein einziges Wahrheitsquellensystem.
- Spaltungen und Unternehmensaufspaltungen (sowohl organisatorisch als auch systemtechnisch).
- Bereinigung der Daten einer Organisation.
Bedeutung einer ordnungsgemäßen Migration für das Unternehmen
Stellen Sie sich vor, Tesla oder Apple würden ihre gesamten Datenbanken mit ihren Produktdefinitionen, Dokumentationen, Änderungshistorien und mehr verlieren. Ja, sie haben einige der klügsten Ingenieure weltweit, so dass sie wahrscheinlich in der Lage wären, ihre Wissensbasis und Datensätze größtenteils wieder aufzubauen… irgendwann… Doch unabhängig davon, wie brillant sie sind, würde so etwas wahrscheinlich zu ihrem Untergang führen – oder zumindest zu ernsten Problemen kurz- und mittelfristig, zusammen mit mehr als ein paar Leuten, die entlassen werden.
Stellen Sie sich nun vor, Ihr Unternehmen wechselt von einem alten PDM-System zu einem neuen, glänzenden PLM . Stellen Sie sich vor, dass Ihre sorgfältig kuratierten, über Dutzende von Jahren aufgebauten und jede Nacht gekuschelten CAD-Modelle zusammen mit Terabytes an Metadaten mit umziehen werden. Stellen Sie sich vor, was passieren würde, wenn Sie, beispielsweise… 20 % dieser Daten während der Umstellung auf PLM verlieren, weil die Migration nicht genau durchgeführt wurde.
Wären Sie bereit, dieses Risiko einzugehen?
Unternehmen sind heute oft nichts mehr ohne ihre Daten. Deshalb schützen sie diese so streng vor Konkurrenz, aber auch vor Verlust. Die Sicherstellung der Vollständigkeit und Kohärenz der Unternehmensdaten schafft Arbeitsplätze für unzählige Datenbankingenieure und -administratoren weltweit.
Migrationen resultieren aus Veränderungen, was viele automatisch dazu veranlasst, ihnen gegenüber skeptisch zu sein. Sie sind jedoch ein integraler Bestandteil dieser Veränderung und lassen sich oft nicht vermeiden – das heißt, es sei denn, wir wollen unsere wertvollen Daten verlieren, richtig?
Was kann ich also tun, um meine unschätzbaren Informationen zu sichern?
Eine richtige Migrationsstrategie, gefolgt von ihrer sorgfältigen Ausführung, macht den Schmerz der Umstellung auf ein neues System im gesamten Unternehmen deutlich weniger spürbar. Sie ist der Schlüssel, um sicherzustellen, dass der Datensatz in Ihrem Zielsystem vollständig ist und Ihre Techniker ihn vom ersten Tag an effizient nutzen können, fast so, als hätte es überhaupt keine Änderung gegeben.
Darüber hinaus ermöglicht eine ordnungsgemäß durchgeführte Migration Ihrem Unternehmen, bisher unentdeckte Probleme in Ihren Datensätzen zu identifizieren und die Möglichkeit zu schaffen, diese während der Migration zu beheben. Ob Sie es glauben oder nicht, aber manchmal sind migrierte Datensätze tatsächlich vollständiger und kohärenter als die Quelldatensätze, und Daten von besserer Qualität sind gleichbedeutend mit besserer Arbeits- und Produktqualität.
Was eine Datenmigration nicht ist
- Upgrade einer Anwendung / eines Systems ohne Modifikation an der Datenbank.
- Upgrade der Datenbank ohne Modifikationen am Datenmodell.
Arten von Ansätze für Datenmigrationen:
Big Bang
Eine „Big Bang“-Migration bedeutet, dass der gesamte Datenbestand und die Benutzerbasis in einem Durchgang vom Quellsystem auf das Zielsystem verschoben werden, was dazu führt, dass das Zielsystem komplett abgeschaltet oder gesperrt wird und das Unternehmen mit der Nutzung des neuen Systems beginnt. Dies ist der bei weitem häufigste Ansatz für Migrationen, wenn das Ziel darin besteht, das Quellsystem vollständig in den Ruhestand zu versetzen/zu ersetzen.
Der Nachteil dieses Ansatzes ist, dass der Zugriff auf das alte und das neue System gesperrt werden muss, während die eigentliche Migration durchgeführt wird. Dieser „Blackout“ für die Benutzer kann bis zu einigen Tagen dauern, aber Migrationen werden oft am Wochenende durchgeführt, um die Auswirkungen auf das Geschäft zu minimieren.
Eine „Big Bang“-Migration bedeutet nicht, dass sie ohne Vorbereitung durchgeführt wird. Wenn sie richtig ausgeführt wird, sollte sie dem in Abschnitt 3 beschriebenen Ansatz folgen. Überblick über den Migrationsprozess.
Außerdem kann die Umstellung der gesamten Organisation auf ein neues System einen erheblichen Aufwand für die Schulung der Mitarbeiter zur effizienten Nutzung der neuen Software erfordern, um die Organisation nach der Migration nicht zu lähmen.
Benutzerzentrierter Big Bang
Während bei einer traditionellen „Big Bang“-Migration alle Benutzer und alle (relevanten) Daten gleichzeitig in ein neues System verschoben werden, entscheiden sich manche für eine komplexere Strategie, bei der nicht alle Daten bis zum letzten Moment in das neue System verschoben werden, bis die Benutzer es tatsächlich nutzen.
Zunächst wird ein Snapshot des Quellsystems erstellt (oder manchmal wird das Quellsystem komplett geklont), relevante Daten werden identifiziert und in das Zielsystem migriert, während die Benutzer weiterhin im Quellsystem arbeiten. Anschließend wird ein Delta zwischen dem Snapshot und dem aktuellen Zustand des Quellsystems identifiziert und zusammen mit allen Benutzern in das Zielsystem migriert.
Dieser Ansatz ermöglicht die Minimierung des Blackouts, der aus einem traditionellen „Big Bang“-Ansatz resultiert, erfordert jedoch eine sorgfältige Berechnung und den Import des Deltas, um Geschäftsdaten nicht zu beschädigen.
Phasenweise / schrittweise
Stellen Sie sich eine Organisation vor, die in Abteilungen arbeitet, von denen jede einen relativ unabhängigen Datensatz im Quellsystem verwendet. Bei einer schrittweisen/inkrementellen Migration würde jede dieser Abteilungen unabhängig voneinander, eine nach der anderen, auf das Zielsystem übertragen.
Dies verlängert die Lebensdauer des Quellsystems, ermöglicht es aber, alle Probleme mit dem Zielsystem zu beseitigen, bevor die gesamte Benutzerbasis darauf umsteigt, was zu einer viel reibungsloseren Gesamterfahrung für das Unternehmen führt. Außerdem kann ein Unternehmen die Schulung der Mitarbeiter über einen größeren Zeitraum verteilen, was wesentlich weniger schmerzhaft ist.
Wie Sie sich vielleicht vorstellen können, ist jedoch nicht alles Sonnenschein und Regenbogen. Dieser Ansatz ist deutlich komplexer und erfordert zusätzlichen Aufwand sowohl auf organisatorischer als auch auf technischer Ebene, da Daten im Quellsystem noch lebendig sein können, auch wenn sie bereits in das Zielsystem migriert wurden. Es muss ein Prozess definiert und implementiert werden, der mit diesen Überschneidungen (und/oder Diskrepanzen) zwischen den Migrationsstücken sowie mit den Bedürfnissen der Benutzer nach Zugriff auf Daten, die noch nicht im Zielsystem vorhanden sind, umgeht.
Dies kann erreicht werden, indem sichergestellt wird, dass jedes Objekt zu jedem Zeitpunkt einen klar identifizierten „Master“ hat (d.h. entweder Quell- oder Zielsystem) – und sichergestellt wird, dass sowohl das Migrationsteam als auch die Benutzer sich dessen bewusst sind und keine Änderungen an dem „Nicht-Master“ vornehmen.
Obwohl wir schon oft gebeten wurden, eine schrittweise Migration durchzuführen, war es in der Regel nicht möglich, Datenfragmente zu identifizieren, die nur von einer Abteilung genutzt werden – was eine Voraussetzung ist, um diesen Ansatz nutzen zu können. Aufgrund dieser Abhängigkeiten haben wir in der Regel entweder einen Big Bang oder eine inkrementelle Migration empfohlen (und durchgeführt).
Coexistence
Dies ist vielleicht der schwierigste Ansatz für eine Migration. In der Tat unterstützen die vorhandenen Migrationswerkzeuge (für Windchill, und ich würde annehmen, ähnlich für andere große PLM-Systeme) derzeit diese Art der Migration nicht. Ich lasse die Beschreibung hier als Referenz und zur Bewusstseinsbildung stehen, aber bitte denken Sie daran, dass dieser Ansatz bei einer PLM-Migration möglicherweise nicht möglich ist.
Eine Coexistence-Migration geht davon aus, dass sowohl Quell- als auch Zielsystem lange genug synchron gehalten werden müssen, damit die Migration abgeschlossen werden kann, wobei potenziell jedes der beiden Systeme zu jedem Zeitpunkt verwendet werden kann. Dies erfordert die Einrichtung einer bidirektionalen Kommunikationsschnittstelle zwischen beiden Systemen, um sicherzustellen, dass die Daten tatsächlich synchronisiert sind.
Dieser Ansatz zielt darauf ab, die Auswirkungen der Migration zu minimieren, was einen viel reibungsloseren Übergang zu einem neuen PLM-System und eine relativ einfachere Erkennung und Korrektur von Fehlern ermöglicht.
Der Nachteil ist, wie bereits erwähnt, dass diese Art der Migration viel schwieriger auszuführen ist: nicht nur, weil beide Systeme ständig synchronisiert werden müssen, sondern auch die Leistung leidet darunter und das Testen kann schwierig sein. Außerdem werden Daten, die in Ihrem Quellsystem fehlerhaft sind, auch im neuen System fehlerhaft sein (was manchmal als „GIGO“ bezeichnet wird – garbage in, garbage out).
Übersicht über den Migrationsprozess:
Um den Prozess der Datenmigration besser zu verstehen, müssen wir zunächst das zugrunde liegende Konzept verstehen. Die meisten Migrationen basieren auf etwas, das „ETL“ genannt wird.
Was ist ETL?
ETL steht für Extract-Transform-Load und ist die gängigste Bezeichnung (Methodik) für die Herangehensweise an Datenmigrationen, die erstmals in den 1970er Jahren populär wurde. Sie unterteilt jede Migration in Iterationen, die aus den folgenden Phasen bestehen:
- Extract: Holen Sie die Daten aus dem Quellsystem (-s) in einen Staging-Bereich
- Transform: Datentransformation anwenden, um das vorhandene/Quelldatenmodell an das Zieldatenmodell anzupassen. Hier werden Änderungen und/oder Korrekturen an den Daten vorgenommen. Es ist auch üblich, dass in dieser Phase Daten gefiltert werden, die im Zielsystem landen sollen. Eine solche Filterung kann z. B. das Entfernen von Datenmüll oder alten, nicht benötigten Elementen umfassen.
- Load: holt die transformierten Daten in das Zielsystem.
Ein ordnungsgemäßer ETL-Prozess stellt sicher, dass die resultierenden Daten mit den Anforderungen und Standards übereinstimmen, indem Probleme mit der Datenqualität im Quellsystem (-s) identifiziert und behoben werden.
Beispiel:
Oft sieht man eine Abkürzung ETVL, die „Validierung“ hinzufügt, aber die meisten Fachleute gehen davon aus, dass Validierung sowieso ein Muss ist und lassen das „V“ in der Namensgebung einfach weg.
Elemente, die für den Erfolg notwendig sind
- Korrekte Definition von Quell- und Zieldatenmodellen.
Der Wechsel von einem System zu einem anderen – es sei denn, es handelt sich um ein Versions-Upgrade desselben Systems (aber das ist nicht wirklich eine Migration) – bedeutet, dass Sie von einem Datenmodell zu einem möglicherweise völlig anderen wechseln. Es kann sein, dass sie nicht sofort zusammenpassen, und es muss daran gearbeitet werden, jede wichtige Information (wie Objektattribute usw.) von der Quelle auf das Ziel abzubilden. Dies sollte im Vorfeld geschehen, um frühzeitig (und offensichtlich) Diskrepanzen zwischen den Datenmodellen zu erkennen, die die gesamte Migration gefährden könnten.
- Zusammenarbeit mit Subject Matter Experts (SMEs).
Seien wir ehrlich: Es wird immer Probleme mit den Quelldaten geben, oder damit, wie sie in das Zieldatenmodell übersetzt werden sollen. Diese Art von Problemen kann nur dann richtig angegangen werden, wenn die SMEs einer Organisation Anleitungen dazu geben können, was wichtig ist, was korrekt ist und was nicht. Diese SMEs müssen dem Migrationsteam ohne vermeidbaren Overhead und/oder Verzögerung zur Verfügung stehen, um einen reibungslosen Ablauf der Migration zu gewährleisten.
- Kommunikation
Wie im gesamten Leben ist die Kommunikation der Schlüssel: zwischen den Führungskräften des Unternehmens und dem Migrationsteam, den SMEs des Unternehmens und dem Migrationsteam, den SMEs und den Führungskräften und so weiter. Richtig definierte und genau überwachte Ziele, Meilensteine, Zeitpläne und Ergebnisse gewährleisten die Transparenz des gesamten Prozesses und tragen wesentlich zum Erfolg des Engagements bei.
- Erfahrenes Team zur Vorbereitung und Durchführung der Migration.
Normalerweise möchten Sie nicht, dass Praktikanten oder neue Mitarbeiter an Systemen herumspielen, die für Ihr Unternehmen wichtig sind. Das Gleiche gilt für Migrationen. Wenn Sie nicht über das nötige Fachwissen verfügen, um eine Migration intern durchzuführen, wenden Sie sich an einen guten Dienstleister oder Systemintegrator, der Ihr Team ergänzt, Sie während des Projekts anleitet – oder Ihnen die Verantwortung ganz abnimmt. Seien Sie aber nicht geizig: Ihre wertvollen Daten mögen es vielleicht nicht, wenn sie auf unprofessionelle Weise behandelt werden. Denken Sie daran, dass Sie nicht nur für die Arbeitsstunden während des Migrationsprojekts bezahlen, sondern für die Jahre, in denen Sie Erfahrung und Know-how aufgebaut haben.
Maßnahmen vor der Migration (Planung).
Beginnen Sie mit dem Ausfüllen eines einfachen Fragebogens, in dem Fragen gestellt werden wie:
- Was sind die Quell- und Zielsysteme (einschließlich Versionen)?
- Was sind die Quell- und Zieldatenbank (einschließlich Version)?
- Wie viele Objekttypen wollen Sie migrieren (Teile, CAD-Dateien, Dokumente, ECNs , etc.)?
- Wie viele Objekte jedes Typs möchten Sie migrieren?
- Möchten Sie nur die neuesten Versionen oder die gesamte Historie migrieren?
- Haben Sie irgendwelche Anpassungen am Datenmodell/Quellsystem, die in der Zielumgebung neu erstellt werden müssten?
- Können Sie Staging-Umgebungen bereitstellen, die Ihre Produktionsumgebung widerspiegeln?
… und so weiter. Bitte wenden Sie sich an KONTAKT für einen vollständigen Fragebogen, wenn Sie an einer Migration zu PTC Windchill PLM interessiert sind.
Die Beantwortung dieser Fragen gibt den Migrationsexperten eine Vorstellung davon, wie komplex der Prozess sein wird und wie hoch der Aufwand sein wird, ihn durchzuführen. Außerdem lassen sich so frühzeitig Risiken erkennen, wie z. B. eine Datentypinkompatibilität zwischen Quell- und Zielsystem.
Sobald das erledigt ist, planen Sie eine Sitzung (oder mehrere Sitzungen) zwischen den SMEs Ihres Unternehmens und dem Migrationsteam. Diese Sitzung sollte einer Agenda folgen, die es dem Migrationsteam ermöglicht, Ihre aktuelle Umgebung und die darin befindlichen Daten zu verstehen, sowie eine Vorstellung davon zu bekommen, wie das Ergebnis der Migration aussehen soll.
Die Sitzung(en) sollte(n) in die Erstellung eines umfassenden Plans für Ihre Migration münden, der erste Schätzungen zu Zeitrahmen und Meilensteinen enthalten sollte. Vertrauen Sie nicht blind auf irgendwelche Vorabschätzungen – dies ist der früheste Zeitpunkt, an dem Sie eine relativ genaue Kosten- und Aufwandsschätzung erhalten können.
Sobald der Plan vollständig und vom Unternehmen akzeptiert ist, kann das Migrationsteam beginnen, sich die Hände „schmutzig“ zu machen und die erste Testmigration durchzuführen.
Warum testen?
Denn Sie können nie davon ausgehen, dass von Anfang an alles perfekt läuft.
Warum machen wir Testmigrationen?
Eine typische Migration kann ein langer und komplexer Prozess sein, bei dem es um enorme Datenmengen geht, die im Quellsystem über viele Jahre hinweg angelegt wurden. Es wird Probleme mit diesen Daten geben. Es ist jedoch unmöglich, im Voraus zu sagen, wie viele Probleme es geben wird. Es ist möglich, dass der Quelldatensatz sehr gut mit dem Zieldatenmodell übereinstimmt. Es ist aber auch möglich, dass die Quelldaten in einem wirklich schlechten Zustand sind und viel, viel Arbeit benötigen, um sie in Ordnung zu bringen.
An dieser Stelle kommen Testmigrationen ins Spiel.
Es wird dringend empfohlen, nicht davon auszugehen, dass der anfänglich migrierte Datensatz in irgendeiner Weise vollständig oder fehlerfrei ist. Im Gegenteil – der erste Durchlauf wird wahrscheinlich eine Vielzahl von Fehlern ergeben, was zu einem unvollständigen Datensatz führt. Anschließend wird mit der Erstellung von Skripten zur Datenbereinigung und -transformation begonnen, um die im ersten Durchlauf identifizierten Fehler zu beseitigen.
Bei der zweiten Testmigration werden die oben genannten Punkte verwendet, um Probleme mit den Daten zu beheben, so dass nach dem zweiten Durchgang ein vollständigerer Datensatz vorliegt.
Viele Fehler werden jedoch beim ersten Durchlauf unentdeckt bleiben, da einige zusammenhängen und/oder eine Kettenreaktion auslösen können. Seien Sie also nicht überrascht, wenn der zweite. Durchlauf neue, bisher unentdeckte Probleme ergibt.
Immer wieder geht das Migrationsteam diese neuen Probleme an und verbessert seine Skripte, um eine noch bessere Datenqualität für einen dritten, vierten oder n-ten Testmigrationsdurchlauf zu gewährleisten. Jeder dieser Durchgänge wird von den Hauptanwendern des Kunden validiert, und jeder dieser Durchgänge bringt uns der 100-prozentigen Datenvollständigkeit und -integrität im transformierten Datensatz näher.
Es liegt an den Hauptanwendern und dem Migrationsteam zu definieren, welcher Prozentsatz der Vollständigkeit für das Unternehmen akzeptabel ist, ob 100 % oder eine niedrigere Zahl. Sobald diese Stufe erreicht ist, sollte vor der Produktionsmigration eine letzte Probemigration durchgeführt werden, um das korrekte Verhalten aller Skripte zu bestätigen.
Die Anzahl der Testmigrationen hängt von den Fortschritten bei der Problemlösung ab, die in direktem Zusammenhang mit der Komplexität und Qualität der Daten steht.
Bitte beachten Sie, dass es von zentralem Interesse und in der Verantwortung der Hauptbenutzer eines Unternehmens liegen sollte, die Daten nach jedem Testlauf zu validieren. Denn wenn jemand unter dem Datenverlust während der Migration zu leiden hat, dann er selbst.
Häufige Probleme bei PLM-Datenmigrationen
- Datenqualität (Quelle)
Unternehmen wissen oft nicht, wie unordentlich ihre Daten sind, bis sie sie in ein anderes System verschieben müssen. An dieser Stelle kommt die Zusammenarbeit mit SMEs und die Effizienz Ihres Migrationsteams ins Spiel. Diese Probleme können alle (oder zumindest die meisten) während des „T“ des ETL-Prozesses korrigiert werden.
Natürlich wollen Sie das nicht manuell machen (viel Glück bei Hunderttausenden von Objekten…), daher spielen Automatisierung und Skripting hier eine unschätzbare Rolle. Das Migrationsteam kann, wenn es von SMEs richtig angeleitet wird, sicherstellen, dass Ihr Zielsystem Daten von einer Qualität hat, die Ihr Unternehmen vielleicht noch nie gesehen hat.
- Ständig sich entwickelnde Daten (Systeme)
Unabhängig davon, ob Sie eine „Big Bang“-Migration oder eine schrittweise Migration durchführen, wird sich der Datensatz ständig weiterentwickeln – es sei denn, Sie sind bereit, Ihren Betrieb für einen Monat oder so anzuhalten (sic!). Neue und aktualisierte Daten stellen immer ein gewisses Risiko für den Migrationsprozess dar, da neue Probleme auftreten können, die bei Testmigrationen nicht erkannt wurden.
Ordnungsgemäße Testmigrationen vermindern dieses Risiko jedoch ganz erheblich, und etwaige Probleme mit Daten nach einer Migration können immer nach der Ausführung aktualisiert werden. Stellen Sie einfach sicher, dass Ihr Migrationsteam da ist, um Sie auch nach der eigentlichen Migration zu unterstützen – zumindest für eine Weile.
- Leistung
Wenn Sie auf ein PLM-System migrieren, müssen Sie wahrscheinlich große Datenmengen verschieben. Das kostet Zeit, unabhängig davon, ob Sie On-Prem oder die fast unbegrenzt skalierbare Cloud nutzen. Viele Elemente eines Migrationsprozesses können jedoch über Skripte automatisiert werden, einschließlich der Datenbereinigung. Wenn diese Skripte falsch geschrieben sind, beeinträchtigen sie die Leistung des Migrationsprozesses erheblich.
Achten Sie immer darauf, die Leistung von Testmigrationen zu messen, bevor Sie eine Produktionsmigration durchführen, um sicherzustellen, dass Ihre Anforderungen an die Zeitvorgaben (akzeptable Systemausfallzeit vor dem Cut-Over usw.) erfüllt werden. Wenn dies nicht der Fall ist, sollten Sie darüber nachdenken, sich bessere Experten zu holen, um weiter zu optimieren. Denken Sie aber daran, dass Sie nicht ewig optimieren und komprimieren können. Das Verschieben großer Datenmengen braucht manchmal einfach Zeit, und daran können Sie nicht viel ändern.
Bitte beachten Sie, dass die obige Liste keinen Anspruch auf Vollständigkeit hat. Sie erwähnt nur die häufigsten (und problematischsten) Probleme, mit denen wir in den letzten 15 oder mehr Jahren konfrontiert wurden. Eine gründliche Analyse Ihres bestehenden Systems hilft dabei, potenzielle Risiken und Engpässe zu identifizieren. Stellen Sie also sicher, dass Sie allen Workshops und Aktivitäten vor der Migration genügend Aufmerksamkeit schenken.
Erfahrungsbericht über eine erfolgreiche PLM-Migration
Dies ist ein guter Zeitpunkt, um ein Beispiel für eine Datenmigration zu betrachten, die TTPSC für einen großen Kunden aus der Automobilindustrie durchgeführt hat, der das Windchill PLM-System von PTC nutzt. Diese spezielle Migration zielte darauf ab, diesen Kunden von einer vollständig extern verwalteten Cloud-Instanz in eine benutzerdefinierte AWS-basierte Cloud-Umgebung zu verlagern, in der er die volle Kontrolle über alle Systemkomponenten haben würde, während gleichzeitig ein hohes Maß an Automatisierung beibehalten würde. Gleichzeitig sollte die Version von Windchill von 11.0 M030 (Quelle) auf 11.1 M020 aktualisiert werden.
Zu den größten Herausforderungen aus Sicht der Migration gehörten:
- Verschieben vieler Objekte von nicht unterstützten Typen, was die Erstellung von benutzerdefinierten Extraktoren und Ladern erforderte, darunter: Projektpläne, Beförderungsanträge, Besprechungen usw.
- Verschieben von Benutzern beim Ändern von Gruppen und Rollen
- Verschieben bestehender benutzerdefinierter Workflows, einschließlich der gesamten Änderungshistorie (besonders kompliziert und mit hohem Analyse- und Vorbereitungsaufwand verbunden).
Es gab eine interessante Anforderung an dieses Projekt, nämlich ein unverrückbares Fertigstellungsdatum, das mit dem Ende der Vereinbarung des Kunden mit dem gemanagten PLM-Anbieter korrelierte. Dies zwang das Team, seinen Plan an einem festen Termin auszurichten. Wie die Tatsache, dass das Projekt erfolgreich abgeschlossen wurde, zeigt, lassen sich jedoch auch komplexe Prozesse (wie eine Datenmigration) in gewisser Weise an die Gegebenheiten anpassen.
Insgesamt wurden über 1 600 000 (eine Million sechshunderttausend) Objekte migriert (alle erfolgreich). Das gesamte Projekt (einschließlich der Einrichtung der Infrastruktur und der fortgeschrittenen Automatisierung drumherum – lesen Sie hier mehr über DevOps und Automatisierung für PLM-Systeme) dauerte etwa 5 Monate bis zum Abschluss. Als Ergebnis erhielt der Kunde ein frisches System in der neuesten stabilen Version mit allen migrierten Daten, das in einer benutzerdefinierten Cloud-Infrastruktur eingerichtet wurde, die eine Optimierung der Infrastrukturkosten, Disaster Recovery, Kontrolle der Betriebszeit und eine schnelle (höchstens Stunden) Bereitstellung neuer einsatzbereiter Umgebungen für die Entwicklung und andere Zwecke ermöglicht. Unnötig zu sagen, dass der Kunde mit dem Ergebnis äußerst zufrieden war.
Weitere Informationen zu diesem Projekt finden Sie in einer Success story
Zusammenfassung
Warum habe ich Ihre Zeit in Anspruch genommen, um das Obige durchzulesen?
Die Antwort ist einfach: Ihr Bewusstsein für den vielleicht wichtigsten Aspekt Ihrer neuen (oder aktualisierten) PLM-Implementierung zu schärfen. Während Ihre schönen, komplexen und/oder automatisierten Arbeitsabläufe und Auslöser sehr wertvoll sein mögen, sind es tatsächlich Informationen (Daten), die die IP einer Organisation ausmachen und die Grundlage für ihre Operationen bilden.
Ich hoffe, Sie haben inzwischen verstanden, welche Arten von Datenmigrationen durchgeführt werden können, welche Ansätze angewendet werden können, wie ein Migrationsprozess aussieht und warum er die Aufmerksamkeit und den Aufwand benötigt, der manchmal auf den ersten Blick nicht ganz notwendig erscheint. Ich weiß, dass dies überwältigend sein kann, denn Migrationen sind ein komplexes und oft schwieriges Thema.
In jedem Fall sollten Sie Datenmigrationen immer in die Hände von Profis – intern oder extern – legen, um sicherzustellen, dass Ihr Unternehmen nicht das Wichtigste verliert, was es hat – seine Daten.