Der deutsche Markt für CAFM- und IWMS-Software durchlebt derzeit eine faszinierende Phase der Transformation, die von außen betrachtet wie ein hochmodernes Digitalisierungswunder wirkt. Die Branche konsolidiert sich in einem akzeptablen Tempo, angetrieben von Private-Equity-Investoren und (mehr oder weniger) großen Player-Zusammenschlüssen. Auf den Hochglanzpräsentationen der Branchentreffs wird das Lied der unbegrenzten Möglichkeiten gesungen, garniert mit Begriffen wie Künstlicher Intelligenz, Predictive Maintenance und nahtloser Integration (ich finde diesen Begriff übrigens seltsam, aber so ist das mit Anglizismen manchmal). Man fühlt sich als Kunde im deutschen Mittelstand oder in der öffentlichen Verwaltung modern, zukunftssicher und bestens aufgehoben. Die Verträge für die neuen, schicken Subscription-Modelle werden feierlich unterzeichnet (“Toll, wir sind in der Cloud!”), und man wähnt sich am Ziel der digitalen Träume.
Doch was in diesem Moment der Euphorie gerne übersehen wird, ist das feingedruckte architektonische Konzept dieses neuen digitalen Zuhauses. Die dynamische Marktkonzentration in der DACH-Region führt paradoxerweise nicht zu mehr technologischer Freiheit, sondern oft zu einem immer enger geschnürten Korsett. Anstatt eines offenen, flexiblen Lofts mieten sich viele Unternehmen in einen wunderschön gestalteten, aber hermetisch abgeriegelten goldenen Käfig ein. Wir sprechen in der Branche gerne über den berüchtigten Lock-in-Effekt, als wäre er ein unvorhersehbares Naturereignis, das uns völlig überraschend aus dem Nichts trifft. Dabei bauen wir diese Mauern um unsere Daten meistens selbst auf, untermauert von einem fast rührenden Maß an Naivität bei der Systemauswahl. Stockholm lässt grüßen…
Zertifiziert in die Abhängigkeit
In Deutschland wiegen wir uns bei der Softwareauswahl traditionell gerne in der Sicherheit von Zertifikaten und Normen. Eine Software, die nach GEFMA 444 zertifiziert ist und Räume brav nach DIN 277 berechnet, gilt in Einkäuferkreisen per se als sichere Bank. Diese Zertifikate (oder Selbstversprechen) garantieren zwar, dass bestimmte fachliche Mindeststandards abgebildet werden, sie sagen jedoch absolut nichts über die architektonische Offenheit des Systems aus. In einer idealen Welt ist das Datenmodell einer Software transparent und für den Kunden uneingeschränkt zugänglich, damit dieser versteht, wie seine Anlagen und Prozesse verknüpft sind. In der Realität des deutschen Marktes entscheiden sich Unternehmen jedoch reihenweise für Systeme, deren Datenarchitektur einer geheimen Blackbox gleicht.
Man übergibt dem Anbieter quasi die Baupläne für die eigenen Kernprozesse und bekommt im Gegenzug ein geschlossenes System. Der Kunde wird vom stolzen Betreiber zum reinen Konsumenten einer bunten Benutzeroberfläche degradiert, der nicht einmal mehr weiß, in welcher proprietären Tabelle seine TGA-Anlagen eigentlich zu Hause sind. Wenn man nicht weiß, wie die eigenen Daten strukturiert sind, kann man sie weder vernünftig analysieren noch in übergeordnete ESG-Reporting-Tools integrieren. Man mietet sich in sein eigenes Datenhaus ein und darf nicht einmal den Grundriss einsehen, was in Zeiten von zwingend geforderten Nachhaltigkeitsberichten geradezu fahrlässig ist. Es gleicht dem Versuch, in einem komplexen Gebäude blind zu navigieren, nur weil der Architekt den Lichtschalter versteckt hat.
Der digitale Zwilling in Einzelhaft
Besonders komisch wird dieses Schauspiel, wenn wir uns den Umgang mit Building Information Modeling (BIM) ansehen. In der Planungs- und Bauphase werden teils Millionen investiert, um detaillierte, semantisch tiefe 3D-Modelle mit unzähligen IFC-Klassen und Attributen zu erschaffen. Man träumt vom perfekten digitalen Zwilling, der den gesamten Lebenszyklus der Immobilie begleitet. Dann kommt die Übergabe in den Betrieb, und dieses hochkomplexe Datenmeisterwerk wird ungespitzt in das geschlossene CAFM-System des Betreibers gerammt. Was in der Theorie wie eine nahtlose Staffelübergabe klingt, ist in der Praxis oft eine Einbahnstraße ins Datengrab (dazu hatte ich bereits etwas geschrieben).
Sobald das BIM-Modell im proprietären System gelandet ist, wird es oft seiner Flexibilität beraubt und in eine starre Datenbankstruktur einzementiert. Der digitale Zwilling wird quasi in Einzelhaft gesteckt. Möchte der Kunde später Änderungen am Modell vornehmen, dieses in ein anderes System überführen oder die Geometriedaten mit neuen Sensorwerten aus einem IoT-Netzwerk anreichern, stößt er gegen dicke, unsichtbare Mauern. Die Daten sind zwar physisch da, aber sie sind so stark mit der proprietären Logik des Anbieters verwoben, dass ein agiles Arbeiten am Modell schlichtweg unmöglich wird. Der teuer bezahlte Zwilling verkümmert zu einem statischen “3D-PDF mit magischem Feenstaub”, das zwar hübsch aussieht, aber keinen operativen Mehrwert mehr liefert.
Workflows als elitäre Kunstform
Noch absurder wird es, wenn wir uns die Anpassung von Workflows ansehen, einem Thema, das durch den aktuellen Wandel zu Cloud- und SaaS-Modellen massiv an Brisanz gewonnen hat. Ein modernes Facility Management lebt von Agilität und der ständigen Anpassung an neue Gegebenheiten, gesetzliche Vorgaben oder neue Dienstleister. Logischerweise sollte der Betreiber der Software in der Lage sein, einen Genehmigungs-Workflow für eine Instandhaltungsmaßnahme selbst anzupassen. Doch hier schnappt die Falle des goldenen Käfigs im deutschen Markt besonders unbarmherzig zu.
Bei vielen etablierten Systemen ist die Erstellung oder Anpassung von Workflows eine hochkomplexe Kunstform, die exklusiv den Entwicklern des Anbieters vorbehalten ist. Der Versuch, ein einfaches Dropdown-Menü um ein weiteres Feld für die CO2-Datenerfassung zu ergänzen, mutiert dann schnell zu einem bürokratischen Marathon. Der Kunde schreibt ein Ticket, das im Backlog des Anbieters landet, von einem Projektmanager evaluiert, bepreist und als teurer Change Request zurückgespielt wird. Was eigentlich eine Sache von fünf Klicks in einem modernen No-Code-Backend sein sollte, wird zu einem IT-Projekt mit einem Preisschild, von dem man auch einen Dienstwagen leasen könnte.
Das Private-Equity-Paradoxon
Wir berauben uns damit unserer eigenen Handlungsfähigkeit und machen das CAFM-System ironischerweise zum Flaschenhals der gesamten Organisation. Die Innovationsgeschwindigkeit der Facility-Management-Abteilung wird nicht mehr von den eigenen Mitarbeitern bestimmt, sondern von der Release-Planung des Softwareherstellers. Und hier trifft der Lock-in-Effekt auf eine knallharte Marktdynamik: Die Kapazitäten bei den deutschen Herstellern sind chronisch knapp. Das liegt nicht nur am allgemeinen Fachkräftemangel, sondern auch an der strategischen Ausrichtung vieler Softwarehäuser, die mittlerweile streng nach Kennzahlen gesteuert werden (oder Sie haben einen wirklich menschenfreundlichen Anbieter erwischt, das soll´s ja auch noch geben).
Das primäre Ziel vieler Anbieter ist heute die Steigerung der wiederkehrenden SaaS-Umsätze durch Neukundengewinnung. Das ressourcenintensive Customizing für den ungeduldigen Bestandskunden rutscht auf der Prioritätenliste unweigerlich nach unten. Warum sollte man dem Kunden auch ein Werkzeug zur Selbsthilfe in die Hand geben, wenn man ihn stattdessen in eine endlose Warteschlange einreihen und ihm später teure Beraterstunden in Rechnung stellen kann? Facility Manager planen Redundanzen für jede unwichtige Umwälzpumpe im Gebäude ein, aber bei der kritischen Steuerungssoftware ihres Portfolios akzeptieren sie einen Single Point of Failure in Form eines völlig überlasteten Support-Mitarbeiters.
Datengeiselnahme nach DIN-Norm
“Unsere Daten gehören uns.” Dieser Satz fällt mit heldenhafter Überzeugung in fast jedem Kick-off-Meeting, oftmals begleitet von Verweisen auf Compliance-Richtlinien. Das ist juristisch gesehen vielleicht sogar richtig, aber technisch gesehen im CAFM-Umfeld oft eine Farce. Der wahre Charakter einer Software zeigt sich nicht beim harmlosen Import der anfänglichen Stammdaten über liebevoll gepflegte Excel-Listen. Er offenbart sich erst beim täglichen Umgang mit den Bewegungs- und Prozessdaten, die das eigentliche operative Gedächtnis der gesamten Immobilie bilden.
Man versuche als Kunde im deutschen Markt einmal, die detaillierte Historie von zehntausenden Störmeldungen inklusive aller Statuswechsel, Dienstleister-Kommentare und gebuchten Zeiten wieder aus einem proprietären System herauszubekommen. Oftmals stellen Unternehmen erst nach Jahren fest, dass der Massenexport ihrer Prozessdaten schlichtweg nicht vorgesehen ist. Die Software bietet vielleicht flache CSV-Exporte der reinen Raumlisten an, aber die kritischen relationalen Verknüpfungen bleiben im System gefangen. Ohne diese Zusammenhänge und die zeitliche Historie sind die nackten Daten für eine tiefgehende Analyse oder eine spätere Migration faktisch wertlos.
Das Märchen vom standardisierten Austausch
Warum wehrt sich die Branche nicht lauter gegen diese Praktiken? Vielleicht, weil uns seit Jahren das beruhigende Märchen erzählt wird, es gäbe ja rettende Austauschformate. Wer schon etwas länger in der CAFM-Welt unterwegs ist, erinnert sich unweigerlich an Initiativen wie “CAFM-Connect”. Das klang auf den Hochglanzbroschüren absolut wunderbar und versprach den reibungslosen Datenaustausch. Aus meiner ganz persönlichen Sicht war das jedoch von Anfang an viel zu klein gedacht und vor allem massiv marketinggetrieben. Es war ein gut gemeinter Versuch, eine komplexe Wunde mit einem viel zu kleinen Pflaster zu versorgen. Mit letzter Aktualisierung Anfang 2019, oh je.
Heute, in der rauen Realität hochkomplexer, relationaler Prozessdaten, dynamischer Workflows und globaler IWMS-Architekturen, spielen solche historischen Formate kaum noch eine ernsthafte Rolle. Es gibt im Facility Management de facto keinen allumfassenden, etablierten Plug-and-Play-Standard, der uns beim Systemwechsel einfach so rettet. Wer sich darauf verlässt, dass ein rudimentäres Austauschformat den Export seiner individuellen Prozesshistorie übernimmt, erlebt beim Systemwechsel eine böse Überraschung. Wir haben uns von der Illusion standardisierter Schnittstellen blenden lassen, während die Anbieter im Hintergrund die Gitterstäbe ihrer proprietären Käfige nur noch dicker gegossen haben.
Das böse Erwachen im Exit-Fall
Jede Software-Ehe geht irgendwann zu Ende, sei es durch technologische Veralterung, Unzufriedenheit oder geänderte IT-Strategien. Und genau in diesem Moment des Exits zeigt sich das wahre Gesicht der Verträge, die Jahre zuvor bei Kaffee und Schnittchen verhandelt wurden. Gerade bei öffentlichen Ausschreibungen nach EVB-IT oder bei Standardverträgen im Mittelstand wird der Fokus stark auf den Betrieb gelegt, während der Exit sträflich vernachlässigt wird. Sich ohne offene APIs und knallharte Exit-Strategie in ein proprietäres System zu begeben, ist in etwa so, als würde man einen hochmodernen Bürokomplex anmieten, bei dem der Vermieter das alleinige Zutrittsrecht zum Firmenarchiv behält: Solange man pünktlich Miete zahlt, reicht er einem die eigenen Akten freundlich durchs Fenster, aber wehe, man kündigt den Vertrag.
Oftmals fehlen klare Exit-Klauseln völlig. Es gibt keine harten vertraglichen Regelungen darüber, in welchem strukturierten Format, in welcher Frist und vor allem zu welchen fixen Kosten die gesamten relationalen Datenbankinhalte übergeben werden müssen. Der bisherige Anbieter hat in diesem Szenario verständlicherweise absolut keine Motivation, den Auszug komfortabel zu gestalten. Plötzlich werden für Datenabzüge und sogenannte Migrationsunterstützung Tagessätze aufgerufen, die jeden bisherigen finanziellen Rahmen sprengen.
Der Kunde erkennt schmerzhaft, dass er erpressbar geworden ist, weil sein gesamtes FM-Wissen der letzten Jahre auf den Servern des scheidenden Partners als Geisel gehalten wird. Die Alternative ist oft ein kompletter und tragischer Datenverlust der Prozesshistorie. Man fängt beim neuen System faktisch bei null an, nimmt lediglich die Stammdaten mit und verliert wertvolle Erkenntnisse über Lebenszyklen, Störanfälligkeiten und Dienstleister-Performances. Dieser intellektuelle Wertverlust ist der ultimative Preis für die anfängliche Bequemlichkeit.
Ein Plädoyer für digitale Mündigkeit
Wir müssen im deutschsprachigen CAFM- und IWMS-Markt dringend umdenken. Der Kauf einer Software darf nicht bedeuten, dass wir die Verantwortung für unsere Datenarchitektur und Prozesslogik blind an externe Dienstleister abtreten. Wir brauchen Systeme, die uns als Betreiber ermächtigen, nicht solche, die uns aufgrund ihrer architektonischen Defizite bevormunden. Ein echtes No-Code-Konzept für Workflows, transparente Datenmodelle und offene, bidirektionale REST- oder GraphQL-Schnittstellen müssen zwingende K.o.-Kriterien in jeder Ausschreibung sein.
Der Exit aus dem System muss detailliert an dem Tag geplant und vertraglich fixiert werden, an dem man die Zusammenarbeit beginnt. Wer seine Datenstrukturen versteht und selbständig Prozesse anpassen kann, reduziert nicht nur die laufenden Kosten erheblich. Er sichert vor allem die Überlebensfähigkeit und Agilität seines Unternehmens in einer sich immer schneller wandelnden Immobilienwelt. Am Ende des Tages sollten wir Software wieder auf ihren eigentlichen Zweck reduzieren: Sie ist ein pragmatisches Werkzeug für unsere Prozesse – und kein starrer Rahmen, der uns vom Hersteller diktiert wird.
