Es gibt im Facility-Management nur wenige Projekte, die so zuverlässig romantisiert werden wie die Ablösung eines CAFM-Systems. Auf dem Papier klingt das immer herrlich simpel: altes System raus, neues System rein, Daten mitnehmen, Prozesse modernisieren, alle glücklich, der Betrieb effizienter, das Reporting sauberer, die Nutzer begeistert, der Vorstand beeindruckt.
In der Praxis ist das ungefähr so realistisch wie die Vorstellung, man könne einen vollgestellten Keller ausmisten, indem man einfach ein Etikett an die Tür klebt und dann ein neues Regal bestellt. “Die” Richtlinie zur CAFM-Einführung beschreibt Ablösung zwar als eigene Phase, doch sie macht zugleich klar, dass genau dort das Projekt seine letzte große Prüfung bekommt: Daten, Prozesse, Betrieb, Migration, Erwartungen und Organisation müssen zusammenpassen.
Die eigentliche Mission
Die offizielle Erzählung zur Ablösung klingt ungefähr so: Wir übernehmen alles Relevante, wir bereinigen das Alte, wir führen das Neue strukturiert ein, und danach arbeiten alle effizienter als je zuvor. Die reale Erzählung lautet eher: Wir müssen herausfinden, welche Daten überhaupt noch stimmen, wer sie pflegt, warum sie existieren, warum sie 5x in 3 unterschiedlichen Feldern stehen, und weshalb niemand mehr weiß, ob die Raum-ID, die Anlagen-ID und die Excel-Spalte „Objekt alt final wirklich final (b)“ dasselbe meinen. Auch meine Kollegen im Consulting betonen gebetsmühlenartig, dass eine CAFM-Einführung nicht mit Softwarekauf beginnt, sondern mit Analyse, Zieldefinition, Datenbewertung und Migrationsstrategie — und dass bei Ablösung besonders eine saubere Migrationsstrategie entscheidend ist.
Ablösung ist deshalb kein IT-Tausch, sondern ein organisatorischer Blinddarm- und Dachsanierungs-Mix: Man entfernt etwas Altes, das zwar nervt, aber irgendwie noch am Leben hält, und hofft, dass darunter nicht das halbe Gebäude zusammenfällt. Die häufigste Fehlannahme ist, dass ein neues System automatisch bessere Daten erzeugt. Das funktioniert ungefähr so zuverlässig, wie eine neue Küche automatisch besseres Essen erzeugt.
Das heilige Datenübernahme-Märchen
Der erste Mythos lautet: „Wir übernehmen einfach alle Daten.“ Das klingt vernünftig, ist aber in der Praxis eine Einladung zur Katastrophe mit Starttermin. Denn „alle Daten“ bedeutet eben nicht „alle nützlichen Daten“, sondern meist eine Mischung aus Stammdaten, Altlasten, Dubletten, Historienresten, halb gepflegten Workflows, unklaren Statusfeldern, verwaisten Objekten und liebevoll gepflegten Excel-Friedhöfen. Genau deshalb wird in der Praxis ausdrücklich darauf hingewiesen, dass bei der Migration nur bereinigte, konsistente Altdaten übernommen werden sollten und dass Datenbereinigung Pflicht ist, bevor man sie ins neue System kippt.
Besonders bei der Übernahme von Datenfriedhöfen wird dann die wahre Kunst sichtbar: Nicht die Migration ist das Problem, sondern die Entscheidung, was überhaupt noch ein Datensatz und was schon historisches Sediment ist. In vielen Beständen gibt es Daten, die formal vorhanden, fachlich aber tot sind. Eine Anlage existiert in der Liste, aber nicht mehr im Gebäude. Ein Raum ist noch angelegt, obwohl er seit drei Umbauten ein Kopierbereich, dann ein Meetingraum und jetzt ein Lager ist. Ein Vertrag ist noch aktiv, obwohl der Dienstleister längst gewechselt hat. Und irgendwo steht dann trotzdem: „Datenbestand OK“. Ja, so vollständig wie eine Ruine eben vollständig sein kann.
Kosten: die echte Sprache des Projekts
Wenn in CAFM-Projekten von Kosten die Rede ist, meint das selten nur die Softwarelizenz. Wir müssten uns ehrlicherweise Lizenzkosten, Implementierung, Schulung, Datenübernahme, Schnittstellen, Hosting, laufenden Betrieb und Support als relevante Kostenblöcke anschauen. Besonders interessant ist dabei, dass die veröffentlichten Größenordnungen je Arbeitsplatz sehr weit auseinandergehen können und Schulung sowie Einarbeitung spürbare eigene Kostenblöcke bilden.
Das ist ja auch logisch: Eine CAFM-Ablösung ist keine isolierte Softwareeinführung, sondern ein Umbau von Daten, Prozessen und Zuständigkeiten. Wer glaubt, das Projekt ende mit der Bestellung der Lizenz, hat die Rechnung ohne die Spezies gemacht, die in jedem CAFM-Projekt irgendwann auftauchen: der Datenbereiniger, der Schnittstellenarchitekt, der Prozessretter, der Key-User mit Burnout-Vorwarnung und der Entscheider, der fragt, warum das alles nicht schon gestern produktiv war (kennen Sie auch, nicht wahr?). Der Preis eines CAFM-Wechsels besteht deshalb nicht nur aus Geld, sondern auch aus Zeit, Geduld, Aufmerksamkeit und politischem Verschleiß.
Noch schlimmer wird es, wenn die Erwartung lautet, man könne die Ablösung „nebenbei“ machen.
Das ist ungefähr so, als würde man eine Hauptverteilung tauschen, während der Betrieb weiterläuft, und überrascht feststellen, dass Stromkreise und Unternehmensrealität sich nicht immer denselben Humor teilen. In der Praxis verschiebt sich der Kostenrahmen fast immer, weil unklare Altprozesse, fehlende Datenqualität und zusätzliche Schnittstellen erst im Projekt sichtbar werden. Was anfangs wie ein geordnetes System aussieht, entpuppt sich oft als archivierte Improvisation mit Benutzungsrecht.
Der Prozess, den man erbt
Die vielleicht unerquicklichste Wahrheit einer CAFM-Ablösung lautet: Man ersetzt nicht nur Software, man erbt Prozesse. Und geerbte Prozesse sind wie antike Möbelstücke aus der IKEA-geprägten Familienwohnung — sie haben Geschichte, aber niemand weiß, warum man sie noch herumstehen hat. Jedem sollte (!) klar sein, dass die Ist-Analyse gerade deshalb so wichtig ist: Schwachstellen, Medienbrüche, doppelte Erfassungen und unsaubere Zuständigkeiten müssen vor der Ablösung sichtbar werden.
In der Realität passiert aber oft etwas anderes. Man nimmt den alten Prozess, gießt ihn in eine neue Oberfläche und nennt das Transformation (oder “CAFM 4.0”). Dann wird ein Workflow, der schon im alten System widersinnig war, im neuen System mit moderneren Buttons, hübscheren Farben und vielleicht sogar einer App reproduziert. Das Ergebnis ist dann nicht Digitalisierung, sondern die industrielle Veredelung von Unsinn. Der neue Prozess ist schneller, hübscher und leider immer noch falsch. Man könnte fast applaudieren, wenn es nicht so teuer wäre.
Deshalb ist bei einer Ablösung die gefährlichste Aussage nicht „Das alte System ist schlecht“, sondern „Wir wollen den bestehenden Prozess übernehmen“. Das ist bequem, weil es Konflikte vermeidet. Es ist aber meistens genau die Entscheidung, mit der man ein neues System dafür bezahlt, dass es den alten Mangel jetzt bitte in Hochglanz ausführt.
Erwartungen aus dem Paralleluniversum
Ein zentrales Problem sind fehlgeleitete Erwartungen an Umsetzbarkeit, Preis und Zeithorizont. Die “offizielle” Projektlogik in GEFMA-nahen Beschreibungen sieht Phasen von Analyse über Anforderungskatalog und Implementierung bis zur Ablösung vor; diese Ablösung ist also nicht das Ende des Projekts, sondern ein eigenständiger, sorgfältig zu planender Schritt. Trotzdem wird in vielen Organisationen so getan, als sei der Wechsel ein Beschaffungsakt mit anschließender Wunderheilung.
Die Wunschliste lautet dann ungefähr so: bitte alle Daten vollständig, bitte alle Prozesse standardisiert, bitte keine Einschränkungen, bitte individuell genug für unsere Besonderheiten, bitte sauber integriert in ERP, DMS, GIS und Gebäudeautomation, bitte günstig, bitte schnell, bitte ohne Schulungsaufwand, bitte mit hoher Nutzerakzeptanz ab nächstem Quartal. Man möchte also gleichzeitig den Ferrari-Preis, das Fahrrad-Feeling und die Zuverlässigkeit eines Linienbusses an einem Feiertag. Fachlich ist das ungefähr so tragfähig wie die Idee, ein Wasserschadenprojekt mit einem einzigen Feuchtigkeitsmesser und einer PowerPoint-Folie zu sanieren.
In der Realität müssen CAFM-Systeme häufig über Schnittstellen mit ERP, DMS, GIS, BIM und technischen Systemen verbunden werden und Datenmigration, Schulung und Betrieb sind fester Bestandteil des Leistungspakets. Genau daraus folgt: Wer die Ablösung klein rechnet, hat meist nicht falsch kalkuliert, sondern falsch gedacht.
Das Projekt ist selten zu teuer, weil die CAFM-Anbieter und -Berater zu gierig sind; es ist teuer, weil Organisationen ihre eigene Komplexität erst dann entdecken, wenn jemand dafür einen Terminplan schreibt.
Datenfriedhof mit Login
Der Datenfriedhof ist der eigentliche Hauptakteur jeder CAFM-Ablösung. Er hat viele Grabsteine, aber keine Blumen.
Er besteht aus Daten, die einmal wichtig waren, dann halb gepflegt wurden, schließlich nur noch aus Gewohnheit existierten und nun mit den Ehrentiteln „Altbestand“ oder „historische Daten“ versehen werden. Das Problem ist nicht, dass diese Daten da sind. Das Problem ist, dass niemand sie loslassen will, solange nicht klar ist, ob sie vielleicht vielleicht vielleicht doch noch i-r-g-e-n-d-w-o gebraucht werden.
Und natürlich werden sie gebraucht — meistens von genau der einen Abteilung, die sich fünf Minuten vor Go-Live meldet und sagt, dass man die letzten acht Jahre doch bitte auch noch migrieren müsse, weil man „für Prüfungen“ darauf zugreifen wolle. “Wir brauchen das für Prüfungen” sind im CAFM-Kontext der magische Satz, mit dem jede Datenleiche wieder eine gesellschaftliche Relevanz erhält. Dann wird aus dem Aufräumen plötzlich Archivierung, aus der Archivierung ein Migrationspaket, und aus dem Migrationspaket ein Zusatzbudget.
Die fachliche Antwort darauf ist eigentlich klar: Nicht alles Alte gehört ins Neue. Für die künftige Nutzung sollten nur bereinigte und konsistente Daten übernommen werden, während der Rest archiviert oder anderweitig gesichert wird. Die organisatorische Antwort ist deutlich komplizierter: „Das macht man dann später.“
Später ist im CAFM jedoch der Ort, an dem gute Vorsätze sterben und Projektbudgets auf dem Zahnfleisch gehen.
Das schlechte Alte im neuen Gewand
Eine CAFM-Ablösung scheitert nicht nur an Daten, sondern an der Sehnsucht, das Alte unkritisch fortzuschreiben. Viele Organisationen wollen ein neues System, aber keinen neuen Arbeitsstil. Sie wollen moderne Transparenz, aber die alte Excel-Freiheit. Sie wollen saubere Daten, aber bitte ohne Bereinigung. Sie wollen Compliance, aber ohne dokumentationsintensive Pflege. Sie wollen Standards, aber natürlich speziell für ihre Sonderfälle (und glauben Sie mir, genau das habe ich schon gefühlte 1000 Mal gehört…).
Die GEFMA betont (und nicht nur die…), dass eine Einführung immer mit Anforderungsanalyse, Prozessaufnahme, Datenkonzept und Projektorganisation zusammenhängt und dass die Ablösung eine bewusste Erneuerungsphase sein muss. Das ist wichtig, weil man sonst am Ende nur die Oberfläche erneuert. Dann sieht das System neu aus, aber unter der Haube leben dieselben Gewohnheiten weiter wie Kakerlaken nach der Renovierung. Das ist kein Fortschritt, sondern nur besser beleuchtete Dysfunktion.
Besonders schmerzhaft wird es, wenn alte Prozesse nicht nur schlecht, sondern politisch verfestigt sind. Dann ist die Frage nicht mehr, wie ein Prozess fachlich funktionieren sollte, sondern wer im alten System welchen Knopf gedrückt hat und warum sich daran niemand mehr erinnern möchte. Eine Ablösung zwingt Organisationen deshalb nicht nur zur technischen Migration, sondern zur Selbstkritik. Und genau das ist oft der Moment, in dem das Projektteam mit ernster Miene „Change-Management“ sagt, während im Hintergrund bereits fünf Menschen ihre Excel-Favoriten sichern ;-)
Praxis der Realität
Praxisbeispiele aus aktuellen CAFM-Projekten zeigen, wie breit die Anforderungen an Systeme und Migration tatsächlich sind. Hersteller beschreiben typische Integrationen mit SAP, DMS, GIS, BIM, IoT, Ticketing und mobilen Lösungen; zugleich werden Datenübernahme, Datenerfassung, Schulung und Support als Teil des Gesamtpakets aufgeführt. Das zeigt ziemlich deutlich, dass eine Ablösung keine reine Softwareentscheidung ist, sondern ein Ökosystemwechsel.
Ein praktischer Fall ist die Ablösung eines Systems, in dem Flächen, Anlagen, Tickets und Verträge historisch gewachsen, aber nie wirklich harmonisiert wurden. Dann muss vor der Migration zuerst geklärt werden, welches Datenmodell künftig gelten soll, welche Felder fachlich verbindlich sind und welche Informationen nur noch im Archiv Platz haben. Genau dafür fordert die Projektmethodik eine frühzeitige Analyse von Datenqualität und Zielstruktur.
Wer diesen Schritt überspringt, migriert nicht Wissen, sondern verfestigt Verwirrung.
Ein weiterer Typ ist die Ablösung eines Systems, das anno dunnemals für einen sehr kleinen Anwendungsfall gedacht war und später zu einem Universalsystem mutiert ist. Zu einem Biest. Dann haben alle irgendwie damit gearbeitet, aber niemand nach einem gemeinsamen Datenstandard. Die neue Lösung soll dann plötzlich Reports, mobile Bearbeitung, Workflows, Compliance und Management-Entscheidungen liefern. Das ist der Punkt, an dem die Projektfolien anfangen, beleidigend zu wirken.
Warum Budgets scheitern
Viele Budgets scheitern nicht an der Höhe, sondern an der Unvollständigkeit. In Kostenübersichten werden zwar Software, Pflege, Hosting und Schulung gern erwähnt, doch die eigentliche Sprengkraft liegt häufig in Datenbereinigung, Migrationsaufwand, Schnittstellen, Rollenklären, Testläufen und Nacharbeiten. Fachliche Richtlinien betonen deshalb, dass eine solide Budgetierung immer auch Puffer und Risikobetrachtung enthalten sollte. Aber hören will das niemand.
Die Pointe: Je schlechter die Ausgangslage, desto dringender erscheint die Ablösung — und desto unwilliger ist man, die realistischen Kosten anzuerkennen. Man investiert dann lieber in die Hoffnung als in die Vorbereitung. Das ist betriebswirtschaftlich ungefähr so sinnvoll wie der Kauf eines Feuerlöschers mit der Begründung, man hoffe, ihn nicht zu brauchen. Wenn der Altbestand chaotisch ist, steigen Zeit und Kosten zwangsläufig. Das ist keine Bosheit der Berater, sondern die nackte Logik von Daten und Organisation.
Besonders beliebt ist die Annahme, man könne durch „kluge“ Ausschreibung den Migrationsaufwand klein formulieren. Das führt meist nur dazu, dass das Projekt billig gestartet und teuer beendet wird. Ein sauberer Leistungsumfang ist angenehmer als ein schöner Irrtum.
Die Praxis zeigt ziemlich deutlich, dass bereits in der Vorbereitungsphase das Daten- und Migrationskonzept zentral mitgedacht werden muss.
Zeithorizont aus Wunschdenken
Auch beim Zeitplan herrscht gerne poetische Unschärfe. Man sagt dann Dinge wie: „Wir wollen das im Laufe des Jahres einführen“ oder „das sollte bis Ende Q3 produktiv sein“. Das klingt seriös, ist aber oft in etwa so präzise wie „wir bauen das mal sauber um“. Fachlich wird die Dauer einer CAFM-Einführung stark von Datenqualität, Schulung, Komplexität und Umfang beeinflusst; gern beschreiben wir eine mehrphasige Vorgehensweise mit Analyse, Ausschreibung, Implementierung, Nutzung und späterer Ablösung. In Praxisdarstellungen werden je nach Umfang unterschiedliche Einführungsdauern und Schulungsaufwände genannt. Aber wer macht das schon konsequent?
Das Problem ist: Der Zeitplan berücksichtigt im Wunschdenken meist nur die Softwarekonfiguration. In der Wirklichkeit dauern aber die Vorarbeiten oft länger als das Einspielen des Systems. Daten müssen identifiziert, bereinigt, gemappt, getestet und fachlich abgenommen werden. Prozesse müssen definiert, besprochen, angepasst und manchmal auch politisch durchgesetzt werden. Wer das im Plan zu knapp ansetzt, produziert nicht nur Stress, sondern auch Qualitätsverluste. Und Qualitätsverluste im CAFM zeigen sich später in Reports, Tickets, Wartungen und Nebenkostenabrechnungen — also genau dort, wo man sie am wenigsten gebrauchen kann.
Was gut funktioniert
Trotz allem ist eine CAFM-Ablösung natürlich sinnvoll, wenn sie richtig aufgesetzt ist. Aktuelle CAFM-Lösungen bieten heute typischerweise deutlich bessere Integrationsmöglichkeiten. Oder mobile Nutzung, benutzerdefiniertes Reporting und individualisierbare Prozessunterstützung.
Die beste Chance auf Erfolg liegt allerdings nie in der Hoffnung auf das perfekte Tool, sondern in einer ehrlichen Bestandsaufnahme. Wer sich früh fragt, welche Daten wirklich gebraucht werden, welche Prozesse wirklich sinnvoll sind und welche Altlasten man wirklich in die Zukunft schleppen will, spart am Ende Geld und Nerven. Und wer akzeptiert, dass eine Ablösung ein Organisationsprojekt ist, nicht nur ein Softwareprojekt, ist schon weiter als viele andere. Die Ablösung wird dann immer noch anstrengend, aber wenigstens nicht mehr naiv.
Der eigentliche Witz an CAFM-Ablösungen ist ja, dass sie fast immer genau dort scheitern, wo alle am sichersten waren: bei den Daten, bei den Prozessen und bei den Erwartungen. Nicht beim Button-Design. Nicht beim Logo. Nicht bei der Frage, ob das Dashboard grün oder blau ist. Sondern bei der Frage, ob man seine eigenen Bestände überhaupt verstanden hat.
Datenvollständigkeit, Datenqualität, Migrationsstrategie, Stakeholder-Einbindung, Priorisierung und realistische Projektsteuerung sind die eigentlichen Erfolgsfaktoren.
Und vielleicht ist genau das die Pointe für meinen etwas bösartigen Blogartikel über die Ablösung von CAFM-Systemen: Man ersetzt nicht einfach ein altes System durch ein neues.
Man entscheidet, ob man die eigene Organisationsrealität weiter verwaltet oder endlich anfängt, sie zu ordnen. Das ist weniger glamourös, kostet mehr, dauert länger und endet selten mit Konfetti. Aber genau deshalb funktioniert es manchmal sogar.
