Ein CAFM-System zu ersetzen, klingt zunächst ganz einfach. Man entscheidet sich für eine neue Lösung, exportiert die Daten aus dem alten System, importiert sie in das neue und arbeitet weiter wie bisher.

Wenn Migrationen nur so einfach wären.

Ein CAFM-System, das seit zehn oder fünfzehn Jahren im Einsatz ist, enthält weit mehr als nur eine Sammlung von Datenbankeinträgen. Darin stecken Gebäude und Räume, Anlagen, Verträge und Dokumente, aber auch Prozesse, Zuständigkeiten, Schnittstellen, historische Informationen und nicht selten einige Behelfslösungen, bei denen sich niemand mehr so genau daran erinnert, wann und warum sie eigentlich eingeführt wurden.

All das von einem System in ein anderes zu übertragen, ist deshalb nicht einfach nur eine IT-Aufgabe. Gerade darin liegt aber auch eine Chance: Die Migration schafft Raum, bestehende Strukturen und Abläufe zu hinterfragen und eine Frage zu stellen, die im Tagesgeschäft häufig untergeht: Wollen wir eigentlich weiterhin so arbeiten?

Der Erfolg einer CAFM-Migration bemisst sich nicht daran, wie originalgetreu das alte System im neuen nachgebaut wurde. Erfolgreich ist sie dann, wenn die Organisation anschließend effizienter arbeiten kann, bessere Informationen zur Verfügung hat und die Prozesse die tatsächlichen Anforderungen der Nutzer unterstützen.

In der Praxis treten jedoch immer wieder dieselben Fehler auf.

Fehler #1: Einen Systemwechsel ohne klar definierten Grund angehen

Fehler #2: Alles migrieren, nur weil es vorhanden ist

Fehler #3: Davon ausgehen, dass ein Export alles enthält, was im Altsystem zu sehen ist

Fehler #4: Zu viel auf einmal verändern wollen

Fehler #5: Die Nutzer zu spät einbeziehen

Die gute Nachricht: Keiner dieser Fehler ist unvermeidlich. Die meisten lassen sich verhindern, noch bevor der erste Datensatz das alte System verlässt.

Fehler #1: Einen Systemwechsel ohne klar definierten Grund angehen

Die erste Frage bei einer CAFM-Migration sollte nicht lauten: Wie bekommen wir die Daten aus dem alten System?

Sondern: Warum wechseln wir überhaupt das System?

In der Regel gibt es dafür gute Gründe. Vielleicht wird die bestehende Software nicht mehr weiterentwickelt oder unterstützt. Vielleicht sind die Kosten gestiegen, wichtige Funktionen fehlen, das Reporting erfüllt die Anforderungen nicht mehr, der Support ist unzureichend oder bestehende Prozesse sind unnötig kompliziert geworden.

Was auch immer der Grund ist, er sollte bestimmen, wie es weitergeht.

Wenn das bestehende System die Instandhaltung unnötig kompliziert macht, sollte die Migration die Instandhaltung vereinfachen. Sind Informationen nur schwer zugänglich, sollte die neue Lösung dafür sorgen, dass sie leichter zu finden und zu nutzen sind. Und wenn für regelmäßige Auswertungen nach wie vor mehrere Exporte, manuelle Korrekturen und das Zusammenführen von Informationen aus unterschiedlichen Quellen notwendig sind, ist die Migration ein guter Anlass, die Ursachen dafür zu hinterfragen.

Ohne klare Ziele passiert es allerdings erstaunlich leicht, dass lediglich das Bestehende nachgebaut wird.

Die gleichen Strukturen bleiben erhalten. Die gleichen Prozesse werden übernommen. Manchmal finden sogar die gleichen Behelfslösungen im neuen System wieder einen Platz.

Das System ist neu. Die Gründe, aus denen das alte ersetzt werden sollte, bestehen weiterhin.

So lässt sich dieser Fehler vermeiden

Bevor über die Details der Migration gesprochen wird, sollte feststehen, was danach tatsächlich besser sein soll.

Identifizieren Sie die Schwächen der aktuellen Lösung, legen Sie fest, welche Prozesse verbessert werden müssen, und verständigen Sie sich auf die Anforderungen, die für den zukünftigen Betrieb wirklich relevant sind. Definieren Sie anschließend, woran Sie erkennen können, ob der Systemwechsel die gewünschten Verbesserungen gebracht hat.

So erhält das Projekt einen klaren Bezugspunkt für alle weiteren Entscheidungen.

Fehler #2: Alles migrieren, nur weil es vorhanden ist

In Migrationsprojekten hält sich eine Annahme erstaunlich hartnäckig: Wenn Daten vorhanden sind, müssen sie auch wichtig sein.

Der Gedanke ist nachvollziehbar. Schließlich hat irgendwann einmal jemand diese Daten erfasst, gepflegt oder importiert. Dafür wird es bestimmt einen Grund gegeben haben.

Vielleicht gab es den auch. Im Jahr 2014.

CAFM-Datenbanken wachsen mit der Zeit. Gebäude verändern sich, Flächen werden neu organisiert, Anlagen werden ausgetauscht, Verträge laufen aus und Zuständigkeiten wechseln. Auch Bezeichnungen und Benennungsregeln ändern sich, und Informationen werden je nach Abteilung oder Standort möglicherweise unterschiedlich gepflegt. Manche Daten werden sorgfältig aktuell gehalten. Andere sind hauptsächlich deshalb noch vorhanden, weil es nie einen Anlass gab, sie infrage zu stellen.

Und nicht jedes Problem lässt sich an einem einzelnen Datensatz erkennen.

Eine Anlage kann beispielsweise als außer Betrieb gekennzeichnet sein, während ihr gleichzeitig noch aktive Wartungsaufträge zugeordnet sind. Für sich betrachtet können beide Datensätze vollkommen plausibel erscheinen. Doch welche Information stimmt? Das muss geklärt werden, bevor entschieden wird, was in das neue System übernommen werden soll.

Alles zu migrieren, nur weil es vorhanden ist, mag zunächst wie die sicherste Lösung erscheinen. Nichts geht verloren und schwierige Entscheidungen müssen nicht schon vor der Übertragung getroffen werden. Das Problem dabei: Das neue System startet womöglich mit veralteten, widersprüchlichen oder überflüssigen Informationen aus dem alten System in den Betrieb.

Nicht jede Information sollte deshalb gleich behandelt werden. Abhängig von Relevanz, Qualität und künftigem Verwendungszweck können Daten direkt übernommen, bereinigt oder zusammengeführt, archiviert oder bewusst nicht migriert werden. In manchen Fällen ist es sinnvoller, einen Bereich auf einer sauberen Datenbasis neu aufzubauen, statt veraltete oder unvollständige Informationen zu übertragen.

Was muss tatsächlich mit?

Dabei handelt es sich nicht um starre Regeln. Eine „aktive Anlage“ gehört nicht automatisch ins neue System, nur weil ihr Status auf aktiv steht. Genauso wenig gehört ein alter Datensatz allein aufgrund seines Alters automatisch ins Archiv. Entscheidend sind Verwendungszweck, Qualität, Abhängigkeiten und die zukünftige Nutzung.

So lässt sich dieser Fehler vermeiden

Entscheiden Sie bewusst, welche Daten mitgenommen werden sollen und in welchem Zustand.

Prüfen Sie, welche Informationen noch relevant sind, welche Datensätze veraltet oder unvollständig sind, wo Dubletten bestehen und welche Datenbestände in der Vergangenheit nicht zuverlässig gepflegt wurden.

Hinterfragen Sie außerdem, ob historische Informationen für zukünftige Prozesse tatsächlich benötigt werden oder lediglich zu Dokumentationszwecken beziehungsweise aufgrund rechtlicher oder organisatorischer Aufbewahrungspflichten zugänglich bleiben müssen.

Fragwürdige Daten erfolgreich zu übertragen, macht sie nicht verlässlicher. Es bedeutet lediglich, dass die Übertragung funktioniert hat.

Fehler #3: Davon ausgehen, dass ein Export alles enthält, was im Altsystem zu sehen ist

„Wir haben die Daten.“

Dieser Satz ist weniger beruhigend, als er zunächst klingt.

Was Nutzer in einem etablierten CAFM-System sehen, entspricht nicht zwangsläufig dem, was sich daraus exportieren lässt. Informationen, die in der Anwendung angezeigt werden, können von verknüpften Tabellen, berechneten Werten oder interner Systemlogik abhängen. Ein Export kann zwar die einzelnen Datensätze enthalten, gleichzeitig aber genau die Kennungen und Beziehungen auslassen, die ihnen ihren eigentlichen Zusammenhang geben.

Eine Brandschutztür kann im Altsystem beispielsweise gemeinsam mit ihrem Standort, Prüfintervall, zuständigen Dienstleister und dem letzten Prüfbericht in einem einzigen Datensatz dargestellt werden. Im Hintergrund können diese Informationen jedoch in unterschiedlichen Tabellen gespeichert oder über interne Referenzen miteinander verknüpft sein. Enthält der Export zwar die einzelnen Datensätze, nicht aber diese Referenzen, sind sowohl die Tür als auch das Dokument vorhanden, ohne dass sich beide zuverlässig wieder miteinander verknüpfen lassen.

Die Daten wurden exportiert. Der Kontext, der sie nutzbar gemacht hat, jedoch nicht.

Und die Daten aus dem alten System herauszubekommen, ist ohnehin nur die eine Hälfte der Aufgabe.

Selbst ein vollständiger Datenexport muss anschließend zur Struktur des Zielsystems passen. Felder, Klassifikationen, Statuswerte, Kennungen und Hierarchien können dort anders aufgebaut sein. Ein Quellwert wie „Status 3“ lässt sich nicht einfach übertragen, solange nicht definiert ist, welcher Bedeutung er im Zielsystem entspricht. Gleiches gilt für Beziehungen zwischen Datensätzen: Zu wissen, dass zwei Datensätze zusammengehören, bedeutet noch lange nicht, dass das neue System weiß, wie diese Verbindung abgebildet werden soll.

So lässt sich dieser Fehler vermeiden

Arbeiten Sie frühzeitig mit einem echten Datenexport, statt sich darauf zu verlassen, was in der Anwendung sichtbar ist.

Prüfen Sie, welche Kennungen, Klassifikationen, Zuordnungen und Beziehungen außerhalb des Altsystems tatsächlich verfügbar sind. Klären Sie den Datenbankzugriff, Exportmöglichkeiten, Schnittstellen und die verfügbare technische Dokumentation, bevor die Migration davon abhängig wird.

Definieren Sie anschließend, wie die exportierten Informationen im Zielsystem abgebildet werden sollen. Das Mapping legt fest, wohin eine Information gehört. Transformationsregeln bestimmen dagegen, wie Werte interpretiert oder umgewandelt werden müssen. Auch für Beziehungen und Sonderfälle sind eindeutige Regeln erforderlich.

Und testen Sie diese Regeln, bevor die endgültige Übertragung erfolgt.

Beginnen Sie mit einem repräsentativen Datenbestand, migrieren Sie ihn und prüfen Sie anschließend das Ergebnis. Wenn beispielsweise eine definierte Gruppe technischer Anlagen übertragen werden soll, muss sich nachvollziehen lassen, welche Anlagen tatsächlich im neuen System angekommen sind und wie sich mögliche Abweichungen erklären lassen.

Stimmt etwas nicht, sollten Sie die zugrunde liegenden Quelldaten oder die Migrationsregel korrigieren, statt einzelne Datensätze im Zielsystem nachzubessern. Anschließend führen Sie die Migration erneut durch.

Eine Korrektur, die beim nächsten Migrationslauf wieder verschwindet, war nie wirklich eine Korrektur.

Wer solche Einschränkungen bereits beim Testen erkennt, hat noch genügend Zeit, sie zu beheben.

Fehler #4: Zu viel auf einmal verändern wollen

Ein neues CAFM-System eröffnet neue Möglichkeiten.

Und aus Möglichkeiten werden erstaunlich schnell Projektanforderungen.

Wenn ohnehin migriert wird, warum nicht gleichzeitig die Instandhaltung neu gestalten? Und mobile Prozesse einführen. Und die Schnittstellen neu aufbauen. Und das Vertragsmanagement umstrukturieren. Und zwanzig Jahre historische Daten bereinigen. Und vielleicht noch einige Workflows verändern, wenn ohnehin schon alle Beteiligten mit dem Projekt beschäftigt sind.

All das kann durchaus sinnvoll sein.

Alles gleichzeitig umzusetzen, möglicherweise nicht.

Jedes zusätzliche Thema wirkt für sich genommen überschaubar. Packt man jedoch genügend davon in dieselbe Projektphase, entwickelt sich das vermeintliche „Wenn wir schon dabei sind“ schnell zu einem erheblichen Arbeitsaufwand.

Mit dem Projektumfang wachsen auch die Abhängigkeiten. Eine Änderung in einem Bereich kann sich auf Entscheidungen auswirken, die an anderer Stelle bereits getroffen wurden. Mit dem Projektumfang wachsen auch die Abhängigkeiten. Änderungen in einem Bereich können sich auf Entscheidungen auswirken, die an anderer Stelle bereits getroffen wurden. Kommen dann noch laufend neue oder geänderte Anforderungen hinzu, müssen Entscheidungen erneut geprüft und bereits erledigte Arbeiten möglicherweise angepasst werden. Dadurch wird es zunehmend schwieriger, die gesamte Umsetzung im Blick zu behalten und gezielt zu steuern.

So lässt sich dieser Fehler vermeiden

Legen Sie fest, was für einen zuverlässigen Start unbedingt erforderlich ist und was später folgen kann.

Zunächst können die grundlegenden Strukturen und unverzichtbaren Daten umgesetzt werden. Weitere Prozesse, Schnittstellen und Funktionen lassen sich anschließend in sinnvollen Etappen ergänzen. Das bedeutet nicht zwangsläufig, dass das Gesamtprojekt klein wird. Es sorgt vielmehr dafür, dass auch ein großes Projekt beherrschbar bleibt.

Noch wichtiger ist, dass dadurch frühzeitig nutzbare Ergebnisse entstehen. Ein Prozess kann umgesetzt, getestet, bewertet und angepasst werden, bevor das nächste größere Arbeitspaket beginnt.

Es macht einen erheblichen Unterschied, ob man lediglich hört, dass ein Projekt vorankommt, oder ob man die ersten Ergebnisse tatsächlich schon nutzen kann.

Ein schrittweises Vorgehen funktioniert allerdings nur, wenn klar ist, wer Entscheidungen treffen darf. Jemand muss über fachliche Anforderungen entscheiden. Jemand muss sie priorisieren. Jemand muss Datenfragen klären und Änderungen freigeben.

Wie die entsprechenden Rollen heißen, unterscheidet sich von Organisation zu Organisation. Entscheidend ist, dass bei einer anstehenden Entscheidung für alle klar ist, wer sie treffen kann.

Fehler #5: Die Nutzer zu spät einbeziehen

Es gibt eine einfache Methode, um Schwachstellen in einem noch so sorgfältig konzipierten Prozess aufzudecken: Man gibt ihn jemandem, der tatsächlich damit arbeiten muss.

Menschen, die täglich mit einem CAFM-System arbeiten, bemerken Dinge, die in Workshops und Prozessdiagrammen leicht übersehen werden. Ein Feld befindet sich an der falschen Stelle. Wichtige Informationen sind nur umständlich zu finden. Ein Workflow, der in der Planung vollkommen logisch erschien, erweist sich im Arbeitsalltag als unnötig kompliziert.

Wenn Nutzer das neue System erst kurz vor dem Go-live kennenlernen, kommen solche Erkenntnisse ziemlich spät.

Zu diesem Zeitpunkt sind Prozesse bereits konfiguriert und Entscheidungen getroffen. Änderungen, die drei Monate zuvor noch vergleichsweise einfach gewesen wären, wirken sich plötzlich auf Schulungen, Dokumentation, Tests und den Projektzeitplan aus.

So lässt sich dieser Fehler vermeiden

Beziehen Sie die zukünftigen Anwender so früh ein, dass ihr Feedback noch sinnvoll in das Projekt einfließen kann.

Wenn Sie Zwischenergebnisse zeigen, können die Anwender prüfen, wie die neuen Strukturen und Prozesse in der Praxis funktionieren, und auf Probleme hinweisen, die aus rein technischer Sicht möglicherweise nicht erkennbar sind.

Sie müssen nicht an jeder Besprechung teilnehmen. Während der gesamten Migration sollte es jedoch klar definierte Gelegenheiten geben, bei denen sie Feedback geben können. Gleichzeitig lernen sie die neue Umgebung nach und nach kennen, statt ihr erstmals kurz vor dem Go-live zu begegnen.

Eine bessere Migration beginnt mit besseren Entscheidungen

Eine CAFM-Migration sollte nicht danach beurteilt werden, wie viele Daten übertragen wurden. Entscheidend ist vielmehr, ob das neue System mit verlässlichen Informationen, sinnvollen Verknüpfungen und weniger Altlasten in den Betrieb startet.

 

Bei der speedikon FM AG begleiten wir unsere Kunden durch den gesamten Migrationsprozess und bringen unsere Erfahrung gezielt in die jeweiligen Anforderungen, Abhängigkeiten und technischen Rahmenbedingungen des Projekts ein. Mit speedikon® C lassen sich Daten, Prozesse und relevante Informationen in einer integrierten Softwareumgebung zusammenführen. So entsteht eine flexible Grundlage für den zukünftigen Betrieb.

Sie planen, Ihr bestehendes CAFM-System zu ersetzen? Nehmen Sie Kontakt mit unseren Experten auf, um Ihr Migrationsprojekt mit uns zu besprechen.

Mehr dazu im Whitepaper

Sie möchten tiefer in das Thema einsteigen? Unser Whitepaper führt Sie durch die einzelnen Schritte eines Systemwechsels: Ziele definieren, Quelldaten bewerten, Strukturen zuordnen, testen und validieren – bis hin zum Cutover.

Fordern Sie Ihr kostenloses Whitepaper an und erfahren Sie, worauf es vor, während und nach dem Wechsel ankommt.