IWMS richtig auswählen: Architektur, TCO, Checkliste

Ein Integrated Workplace Management System, kurz IWMS, soll das operative und strategische Rückgrat für Immobilien- und Gebäudemanagement bilden. In der Theorie laufen Raumplanung, Instandhaltung, Energie und Leasing auf einer zentralen Datenbasis zusammen. In der Praxis kaufen Unternehmen für Millionen eine Software-Suite, die am Ende als hübsch verpacktes Datensilo endet. Der Grund ist fast immer derselbe: Die Integration ins bestehende ERP- und TGA-Umfeld wird massiv unterschätzt. Dieser Beitrag zeigt ohne Marketing-Sprech, welche Kernfunktionen ein IWMS wirklich liefern muss, wo der echte Unterschied zu CAFM liegt und mit welcher harten Checkliste Sie Anbieter im Pitch sauber auseinandernehmen.

1. Der Unterschied: Warum ein IWMS mehr ist als ein CAFM

Lassen wir die Buzzwords weg. Ein klassisches CAFM kümmert sich um den Betrieb. Also Wartung, Raumverwaltung und Tickets. Ein CMMS ist die Werkbank für den Techniker. Ein IWMS bündelt beides und packt die kaufmännische Strategie obendrauf: Vertragsmanagement, Portfolio-Lebenszyklus und ESG-Reporting.

Die Gefahr ist offensichtlich. Viele CAFM-Anbieter kleben sich heute einfach ein IWMS-Etikett auf, weil sie noch ein Leasing-Modul dazugekauft haben. Das sieht im Prospekt nach Fortschritt aus. Im Alltag ist es oft nur Etikettenschwindel mit etwas besserem Branding. Wenn Ihr Auswahlkriterium am Ende nur eine hübsch volle Excel-Liste ist, wird das Projekt schiefgehen. Eine Software kann vieles ein bisschen. Bei echten CMMS-Funktionen, etwa komplexen Wartungsintervallen für TGA-Anlagen, bricht sie dann gern gnadenlos ein.

Ein IWMS ergibt nur dann Sinn, wenn Raum, Instandhaltung, Lease- und ESG-Workload auf einem einzigen Stammdatenmodell sitzen. Ändert sich der Mieter in Raum 2.04, dann muss das System das auch für Nebenkostenabrechnung, Reinigung und Flächenplanung sauber mitziehen. Alles andere ist keine integrierte Plattform, sondern nur ein teurer Umweg mit Login.

2. Architektur und Schnittstellen: Das Ende der Insellösungen

Die Entscheidung für ein IWMS ist keine Softwareentscheidung im engeren Sinn. Es ist eine Architekturentscheidung für mindestens zehn Jahre. Und genau deshalb scheitern viele Ausschreibungen schon früh. Es werden Funktionen abgefragt, aber die API-Integrität wird ignoriert. Das ist ungefähr so, als würde man ein Haus nach der Farbe der Türklinken kaufen und die Statik später prüfen.

Was heute Standard sein muss, ist klar:

• Standard-APIs: Offene REST-APIs mit OAuth2 sind Pflicht. Fragen Sie nicht nur, ob sie existieren. Lassen Sie sich die Dokumentation zeigen.
• BIM- und CAD-Anbindung: IFC-Exporte müssen Geometrie und Asset-IDs sauber übernehmen. Wer Raum-IDs noch per Hand abgleicht, hat das Projekt schon verloren.
• ERP-Integration: Für Kosten, Buchhaltung und Leasing braucht es eine bidirektionale Schnittstelle. Sonst läuft der Betrieb weiter, nur eben mit mehr Medienbrüchen.

Die Praxisregel ist hart, aber einfach: Planen Sie 30 bis 40 Prozent des Integrationsaufwands direkt für Datenbereinigung und ID-Mapping ein. Wer Datenmüll aus Legacy-Systemen ungefiltert ins neue IWMS kippt, baut sich kein modernes System. Er baut sich ein modernes, unbrauchbares Datensilo. Das ist dann technisch beeindruckend und operativ wertlos.

3. TCO und Lizenzierungsfallen

Die Entscheidung zwischen SaaS und On-Premises ist im Markt längst vorentschieden. Die meisten Anbieter bewegen sich klar Richtung Cloud. SaaS reduziert zwar CapEx, aber die laufenden OpEx steigen oft kräftig, sobald Zusatzservices, API-Abrufe oder Erweiterungen dazukommen. Der Endpreis hat dann mit der hübschen Einstiegslizenz oft nur noch wenig zu tun.

Vorsicht vor verschleiertem TCO. Die Lizenzkosten im ersten Jahr machen oft nur einen kleinen Teil des Gesamtbudgets aus. Der Rest verschwindet in Implementierung, Migration und vor allem im Customizing. Und genau da wird es heikel: Anbieter, die im Pitch jede Ihrer Sonderlocken mit einem schnellen „Ja, geht!“ abnicken, sind selten die besten Partner. Meist sind sie einfach nur höflich, bis die Realität kommt.

Das Customizing von heute ist die Upgrade-Hürde von morgen. Was im Projekt als kleine Anpassung verkauft wird, blockiert später jedes Major-Release. Deshalb gilt: Lieber sauber standardisieren als sich mit kurzfristigem Komfort langfristig selbst die Architektur zu verbauen.

4. Vendor-Snapshot: Was die Großen wirklich können

Die Anbieter sind nicht gleich. Und sie sind auch nicht für dieselben Probleme gut. Suchen Sie nicht nach dem Marktführer im gesponsorten Quadranten (haben Sie den Wortwitz verstanden?). Suchen Sie nach dem Tool, das Ihre konkreten Schmerzen löst. Das ist oft deutlich unsexy, aber eben auch deutlich hilfreicher.

Planon ist stark bei Corporates mit Fokus auf Workplace und Real Estate. Die Architektur ist solide. Die Plattform kann wirklich viel. Aber sobald das Customizing aus dem Ruder läuft, werden Projekte schnell teuer und träge (was im Übrigen für die meisten Software-Projekte gilt).

IBM TRIRIGA ist das Schwergewicht für große Portfolios. Stark im Leasing und bei komplexen Kapitalprojekten. Für den Mittelstand ist das meist Overkill. Dafür braucht man nicht nur Budget, sondern fast schon eine kleine IT-Armee. Und kann Ihnen auch mit anderen Lösungen passieren…

Archibus ist der Dino mit tiefen Spuren in CAD- und Raumdaten. Gerade bei Kommunen und Hochschulen ist das oft bewährt. Die Schwäche lag lange im UI und UX-Bereich. Während andere Anbieter schon Cloud glänzten, wirkte Archibus stellenweise noch wie ein sehr gut gemeinter Verwaltungsakt mit Login. Aber das ist bereits viel besser geworden, oder?

5. Die Checkliste für den Pitch

Glauben Sie keinem PowerPoint-Slide. Wirklich keinem. Eine Checkliste taugt nur dann etwas, wenn Sie Beweise einfordern. Sonst sitzen Sie im Pitch-Raum und hören nur sehr selbstbewusste Sätze über „End-to-End-Fähigkeit“ und „nahtlose Prozesse“. Klingt gut. Hilft aber nicht.

• Sandbox-Schocktest: Geben Sie dem Anbieter 500 Ihrer eigenen, unbereinigten Assets und 200 Räume als Excel- oder IFC-Datei. Kann er das in fünf Tagen in seine Sandbox importieren und ein funktionierendes Mapping vorführen? Wenn nicht, ziehen Sie Konsequenzen.
• API-Beweis: Verlangen Sie eine Postman-Collection für die Synchronisation mit Ihrem ERP-System (der Anbieter wird wissen, was er liefern müsste).
• Upgrade-Policy: Lassen Sie sich vertraglich absichern, was mit Ihren angepassten Workflows bei einem Major-Update passiert. Und wer die Anpassung bezahlt (am Besten nicht Sie).
• Referenzen: Fragen Sie nicht nach einer Kundenliste. Fragen Sie nach zwei Kunden aus Ihrer Branche und sprechen Sie ohne Vertrieb mit deren FM-Leitung. Und am Besten noch mit jemandem aus dem operativen Team.
• Change-Request-Cap: Deckeln Sie die Kosten für Change Requests im Vertrag, sonst bluten Sie in der Betriebsphase finanziell aus.

Die Ausschreibung muss drei typische Betriebs-Szenarien abbilden. Zum Beispiel automatisierte Nebenkostenabrechnung, Umzugsplanung mit BIM und IoT-gesteuerte Wartungs-Trigger. Lassen Sie die Anbieter genau diese Szenarien live (!) und auf Zuruf in der Demo durchspielen. Wer dabei ins Schwimmen gerät, wird im Echtbetrieb auch nicht plötzlich elegant dastehen.

Kaufen Sie keine Funktionen auf Vorrat. Kaufen Sie Integrationsfähigkeit und Stammdaten-Strenge. Nur so wird aus einem Software-Einkauf echter operativer Mehrwert.