Die Wahl der richtigen Asset-Management-Software hat im Facility Management weitreichende Auswirkungen auf Budget, Betriebsaufwand und die Einhaltung regulatorischer Vorgaben. Eine falsche Entscheidung führt nicht nur zu erhöhten Kosten, sondern oft auch zu langfristigen Problemen bei Datenqualität, Integration und Prozessstabilität. Dieser Leitfaden stellt daher einen praxisnahen Entscheidungsrahmen bereit, der auf gewichteten Kriterien basiert und die Bereiche Funktionalität, Integration, Betrieb sowie Total Cost of Ownership (TCO) systematisch berücksichtigt. Ergänzend dazu werden Faktoren beleuchtet, die insbesondere für deutsche und europäische FM-Umgebungen relevant sind.
Durch konkrete Checklisten, wiederverwendbare RFP-Bausteine und klare Warnhinweise zu typischen Risiken – etwa bei Datenmigration und Change Management – ermöglicht dieser Ansatz es Beschaffern, Angebote strukturiert zu vergleichen und Implementierungsrisiken deutlich zu reduzieren. Ziel ist es, nicht nur eine funktional passende Lösung auszuwählen, sondern auch deren erfolgreiche Einführung realistisch zu planen.
Entscheidungsrahmen für Asset Management Software im FM
Die zentrale These dieses Leitfadens ist klar: Die Auswahl einer Asset-Management-Software muss sich an zwei grundlegenden Fragen orientieren. Erstens: Welche Assettypen und Lebenszyklusprozesse sollen tatsächlich gesteuert werden? Zweitens: Welche Integrationen sind erforderlich, um die bestehende IT-Landschaft sinnvoll einzubinden?
Typische Assetklassen im Facility Management sind zum Beispiel:
Gebäude und Liegenschaften inklusive Flächenstrukturen
Technische Anlagen wie HLK, Energieversorgung oder Aufzüge
IT-Assets und vernetzte Geräte
Mobiliar und bewegliche Betriebsmittel
In der Praxis zeigt sich immer wieder, dass Projekte scheitern oder unnötig teuer werden, wenn diese beiden Punkte nicht sauber geklärt sind. Entscheider, die sich primär an bekannten Herstellern oder umfangreichen Featurelisten orientieren, laufen Gefahr, später mit massiven Schnittstellenproblemen und inkonsistenten Daten zu kämpfen.
Fünf pragmatische Schritte im Entscheidungsrahmen
Im ersten Schritt sollten alle relevanten Assets und Prozesse detailliert definiert werden. Dazu gehört eine strukturierte Auflistung der Assetklassen inklusive klarer Verantwortlichkeiten, typischer Lebenszyklusereignisse und regulatorischer Nachweispflichten.
Wichtige Lebenszyklusereignisse sind beispielsweise:
Beschaffung und Inbetriebnahme
Wartung und Inspektion
Störungen und Reparaturen
Modernisierung oder Austausch
Außerbetriebnahme und Entsorgung
Darauf aufbauend empfiehlt sich die Erstellung einer Integrationslandkarte. Hier werden alle relevanten Systeme wie ERP, BMS, BIM-Plattformen, IoT-Lösungen oder MDM-Systeme erfasst.
Typische Integrationen umfassen:
BMS/GLT für Betriebsdaten und Anlagenzustände
BIM-Modelle für strukturierte Gebäudedaten
IoT-Plattformen für Sensordaten und Echtzeitmonitoring
Im dritten Schritt wird das Betriebsmodell festgelegt. Die Entscheidung zwischen Cloud, Hybrid und On-Premise sollte im Kontext von Compliance-Anforderungen, BSI-Vorgaben und vorhandenen Betriebsstrukturen getroffen werden.
Anschließend erfolgt die Bewertung der Anbieter anhand einer gewichteten Matrix. Im Gegensatz zu einfachen Featurevergleichen ermöglicht dieser Ansatz eine differenzierte Bewertung.
Typische Bewertungskriterien sind:
Funktionale Abdeckung der Prozesse
Qualität und Offenheit der Schnittstellen
Aufwand für Datenmigration und Datenqualitätssicherung
Sicherheits- und Compliance-Niveau
Gesamtkosten über die Nutzungsdauer
Der letzte Schritt konzentriert sich auf die Beschaffung selbst
Hier sollten insbesondere Anforderungen an Datenmigration, Service Level Agreements und Exit-Szenarien klar formuliert werden.
Ein typischer Trade-off besteht zwischen schneller Verfügbarkeit und Kontrolle:
Cloud: schneller Rollout, geringere Anfangskosten, aber weniger Kontrolle
On-Premise: maximale Kontrolle, aber höherer Betriebsaufwand
Hybrid: Kompromiss mit zusätzlicher Integrationskomplexität
Gewichtete Bewertungsmatrix (Praxisvorschlag)
Eine bewährte Gewichtung in der Praxis sieht vor, dass Funktionalität und Prozessabbildung etwa 30 % der Gesamtbewertung ausmachen. Integrationen und APIs folgen mit 25 %, da sie maßgeblich über die Zukunftsfähigkeit der Lösung entscheiden.
Eine mögliche Struktur der Gewichtung ist:
Funktionalität und Prozesse — 30 %
Integrationen und APIs — 25 %
Daten- und Migrationsaufwand — 15 %
Betrieb, Sicherheit und Compliance — 15 %
TCO inklusive Support — 10 %
Lokaler Support (DACH) — 5 %
Ein zentraler Praxispunkt ist die Datenbereinigung. In nahezu allen Projekten stellt sie den größten Zeit- und Kostenfaktor dar.
Typische Probleme in der Datenbasis sind:
Fehlende oder doppelte Asset-IDs
Uneinheitliche Bezeichnungen und Klassifikationen
Unvollständige technische Spezifikationen
Inkonsistente Standort- oder Raumzuordnungen
Ein konkretes Beispiel verdeutlicht diese Problematik: Ein Universitätsklinikum führte eine EAM-Komponente für medizintechnische Geräte ein und kombinierte diese mit einem CAFM-System für die Raumverwaltung. Zwar konnten durch Predictive-Maintenance-Ansätze bei Kältemaschinen Ausfallzeiten deutlich reduziert werden, jedoch verzögerte sich das Projekt um sechs Monate. Ursache waren fehlende Asset-IDs und uneinheitliche Gerätespezifikationen.
Frequently Asked Questions
Entscheider benötigen in der Praxis keine Marketingaussagen, sondern präzise und überprüfbare Antworten.
Worin unterscheiden sich CAFM, CMMS und EAM praktisch?
CAFM: Fokus auf Flächen, Räume und infrastrukturelle Prozesse
CMMS: Fokus auf Wartung, Tickets und operative Instandhaltung
EAM: Ganzheitlicher Lebenszyklus inkl. Investitionsplanung
Welche Integrationen sind bei Smart Buildings zwingend?
Offene APIs für flexible Anbindung
Unterstützung für OPC UA und MQTT
BIM-Datenintegration
Stabile ERP-Schnittstellen
Wie berechnet man TCO realistisch?
Lizenzen und Implementierungskosten
Datenmigration und Datenbereinigung
Schnittstellenentwicklung
Hosting und Betrieb
Schulungen und Support
Laufende Anpassungen
Welche Projektrisiken treten am häufigsten auf?
Zu frühes und zu tiefes Customizing
Schlechte oder unvollständige Stammdaten
Unklare oder zu schwache SLA-Regelungen
Unterschätzter Integrationsaufwand
Ein Beispiel aus der Praxis zeigt dies deutlich: Ein städtisches Wohnungsunternehmen führte eine cloudbasierte Asset-Management-Lösung für rund 8.000 Einheiten ein. Obwohl der Verwaltungsaufwand im Service Desk signifikant reduziert werden konnte, verzögerte sich der Produktivstart um vier Monate aufgrund notwendiger Nacharbeiten bei GIS-Daten und Adressstrukturen.
Ein wichtiger Grundsatz lautet:
Konfiguration vor Customizing
Integrationen vor Insellösungen
Datenqualität vor Featuretiefe
Als unmittelbare Maßnahmen empfehlen sich:
Durchführung eines 6‑wöchigen Integrations-Smoketests
Definition von Migrations-KPIs im Vertrag
Festlegung eines klaren Exit-Datenpakets
Pilotprojekt mit einer abgegrenzten Assetklasse
