Facility‑Management‑Software kaufen: Checkliste und wichtigste Funktionen im Überblick

Wer Facility Management Software kaufen will, muss mehr als Funktionslisten vergleichen; Integrationen, Datenqualität, DSGVO-Konformität und TCO entscheiden in der Praxis über Erfolg oder Scheitern (im Übrigen scheitern knapp 50% der CAFM-Projekte gemessen an den Projektzielen, aber das nur am Rande…). Dieser praxisorientierte Leitfaden führt Schritt für Schritt durch Bedarfsanalyse, Priorisierung zentraler Module wie Instandhaltungs- und Flächenmanagement, RFP- und Demo-Checklisten sowie Vertrags- und Implementierungskriterien. Am Ende haben Sie eine prüffähige Checkliste und konkrete Fragen für Anbieter, mit denen Sie Shortlists, Pilotprojekte und die 5-Jahres-TCO verlässlich bewerten.

1. Kaufprozess strukturieren: 7 Phasen Checkliste

Kurz und konkret: Ein strukturierter, phasenorientierter Beschaffungsprozess ist nicht nice-to-have, sondern reduziert Risiken beim Einsatz einer Facility management software messbar – vor allem bei Integration, Datenmigration und Nutzerakzeptanz. Dieser Abschnitt liefert eine unmittelbar anwendbare 7-Phasen-Checkliste mit klaren Deliverables, Verantwortlichkeiten und realistischen Zeitfenstern für mittlere bis große Portfolios.

Phasen-Checkliste

• Phase 0 – Scope und Bedarfsanalyse: Erhebung der FM-Prozesse, Priorisierungskriterien, erste Kostenrahmen; Deliverable: Projektbriefing und Stakeholder-Matrix; Verantwortlich: Product Owner FM; Dauer: 2-4 Wochen.
• Phase 1 – Stakeholder-Workshop und Lastenheft: Gemeinsame Szenarien definieren, Compliance- und DSGVO-Anforderungen aufnehmen; Deliverable: Lastenheft abgestimmt mit IT-Security; Verantwortlich: FM + IT; Dauer: 1-2 Wochen.
• Phase 2 – Anforderungskatalog und Bewertungsmatrix: Muss-/Soll-/Nice-to-have-Merkmale, Gewichtung, KPI-Definitionen; Deliverable: Bewertungsmatrix für Demos; Verantwortlich: Kernteam; Dauer: 1 Woche.
• Phase 3 – Marktanalyse und Shortlist: RFP versenden, Demos koordinieren anhand standardisierter Szenarien; Deliverable: Shortlist 3-5 Anbieter; Verantwortlich: Einkauf + FM; Dauer: 4-8 Wochen.
• Phase 4 – Pilot / Proof of Concept: Pilot mit realen Stammdaten und mobilen Einsätzen; Deliverable: Pilotbericht mit Migrationsaufwand, Performance- und Akzeptanzkennzahlen; Verantwortlich: Pilotanwender + IT; Dauer: 6-12 Wochen.
• Phase 5 – Vertragsverhandlung und SLA-Festlegung: Abnahmebedingungen, Exit-Klauseln, Datenportabilität, DSGVO-Klauseln; Deliverable: Vertragsentwurf mit SLAs; Verantwortlich: Einkauf + Rechtsabteilung; Dauer: 2-6 Wochen.
• Phase 6 – Rollout und Go-Live: Iterativer Rollout, Trainingsplan, Monitoring der KPIs; Deliverable: Go-Live-Plan, Trainingsdokumente, Lessons-Learned; Verantwortlich: Projektleitung + Change-Management; Dauer: 8-24 Wochen (iterativ).
• Phase 7 – wir hatten mit Phase 0 angefangen: schon vergessen? Die Liste geht also nur bis Phase sechs obwohl wir sieben haben…wie gesagt die erste ist die Phase null. Das hier ist also nur für die Menschen, die nicht richtig Lesen können ;-)

Praktische Einsicht: Proof of Concept konzentriert sich oft auf Funktionalität in einer sauberen Testumgebung und unterschätzt Migrations- und Integrationsrisiken. Ein Production-Pilot in zwei realen Standorten offenbart Datenmapping-Probleme, Benutzerworkflows und Performance-Effekte frühzeitig – und ist daher teurer, aber deutlich aussagekräftiger.

Konkretes Beispiel: Bei einem mittelständischen Portfolio mit 150 Liegenschaften zeigte ein 10-wöchiger Pilot, dass die Bestandsdaten aus dem ERP nur zu 60 Prozent automatisch gemappt werden konnten. Folge: 6 Wochen zusätzlicher ETL-Aufwand und Anpassung der Schnittstelle zu SAP, bevor der Rollout sinnvoll war.

Wichtig: Planen Sie die Integration mit ERP, BMS und Identity-Management früh in Phase 0 – späte Schnittstellenentscheidungen verursachen die meisten Kostenüberschreitungen. Sie finden detaillierte Implementierungschecklisten im jeweiligen Implementierungs-Leitfaden.

Frequently Asked Questions

Kurz vorab: Die Fragen in Ausschreibungen und Meetings sollten Antworten liefern, die unmittelbare Entscheidungen ermöglichen — nicht allgemeine Produktbeschreibungen. Diese FAQ konzentriert sich auf die praktischen Stellschrauben, die eine Facility Management Software in realen Projekten beeinflussen.

Operationelle Fragen

Welche Kernfunktion ist wirklich unverhandelbar? Ein verlässliches Instandhaltungsmanagement mit dokumentierter Prüfhistorie, planbaren Wartungszyklen und mobilen Arbeitsaufträgen ist operativ entscheidend. Ohne saubere Auftrags- und Prüfprotokolle scheitern KPI-Berechnungen und Auditanforderungen sehr schnell.

Wie erhöht man die Akzeptanz bei Technikern? Einfachheit schlägt Feature-Fülle. Priorisieren Sie eine mobile App mit Offline-Fähigkeit, klare Formular-Templates und kurze Schulungsabläufe. Testen Sie das UI in einem 1‑wöchigen Feldtest mit Servicetechnikern bevor Sie tief customizen.

Technik, Integrationen und Daten

API-Reife ist wichtiger als Architekturlabels. Ob Cloud, Hybrid oder On-premises: in der Praxis entscheidet die Qualität dokumentierter APIs, Sandbox-Umgebungen und Import-/Export-Tools über Integrationsaufwand und Dauer. Bevorzugen Sie Anbieter mit getesteten REST/OPC-UA-Schnittstellen und einer klaren Sandbox für Ihre IT.

Trade-off Cloud vs. On-premises: Cloud beschleunigt Rollout; On-premises gibt Kontrolle. Eine pragmatische Lösung ist ein hybrider Betrieb: sensible Datensätze lokal, Standardfunktionen in der Cloud. Das vermeidet unnötige Infrastrukturprojekte und erfüllt oft BSI/DSGVO-Anforderungen.

Vertrag, Kostenfallen und Exit

Customization kostet jedes Jahr: Schwergewichtige Anpassungen reduzieren Upgrade-Fähigkeit und treiben TCO. Konfigurieren statt zu entwickeln ist fast immer wirtschaftlicher; wenn Entwicklung nötig ist, begrenzen Sie Scope, setzen Sie Ownership-Fristen und verankern Upgrade-Kompatibilität im Vertrag.

Datenportabilität prüfen und vertraglich sichern. Fordern Sie maschinenlesbare Exporte in CSV, IFC oder JSON sowie Lieferpflichten für historische Prüf- und Rechnungsdaten an. Ohne explizite Exportklausel entstehen bei Anbieterwechsel oft ungünstige Migrationskosten.

Konkretes Beispiel: Bei einem kommunalen Träger fehlte eine Exportklausel für Prüfprotokolle; nach drei Jahren konnten nur PDF-Berichte geliefert werden. Die Folge: ein Externalisierungsprojekt zur Extraktion der Daten, drei Monate Mehraufwand bei der Migration und zusätzliche Beratungskosten.

• (1) API-Dokumentation und Sandbox,
• (2) Offline-Funktionalität der mobilen App,
• (3) vertraglich gesicherte Datenexportformate und Support beim Export.

Diese drei Punkte reduzieren Integrations- und Exit-Risiko am stärksten.

Praktische Einsicht: Viele Teams unterschätzen die psychologische Kosten von schlechter UX mehr als Lizenzpreise. Technik darf nicht die Arbeit der Nutzer komplizierter machen; das lässt sich in Pilotphasen schnell sichtbar machen.

1. Schritt: Fordern Sie vom Anbieter eine Sandbox-Demo mit Ihrem ERP-Export und einem typischen Wartungsdatensatz an — testen Sie Import, Mapping und Export.
2. Schritt: Planen Sie einen 1‑wöchigen Feldtest mit 5 Servicetechnikern zur Validierung der mobilen App vor Vertragsunterzeichnung.
3. Schritt: Nehmen Sie eine verpflichtende Datenexportklausel in den Vertrag auf (maschinenlesbar, Standardformate, Unterstützungszeitraum für Export).
4. Schritt: Legen Sie in der Bewertungsmatrix API-Maturity, Upgrade-Freundlichkeit von Anpassungen und lokale Datenschutzmaßnahmen als gewichtete Kriterien fest.

Und zu guter Letzt: entspannen Sie sich. Alles wird gut ;-)