GEFMA 420 Einführung von CAFM-Systemen

• Kerngeschäftsprozesse im FM: Welche Arbeitsabläufe und Verantwortlichkeiten bestehen (Aufbau- und Ablauforganisation)? Wo bestehen Medienbrüche oder Informationsdefizite, die durch CAFM reduziert werden könnten?

• Bestehende Schwachstellen: Welche Probleme treten im aktuellen Prozessablauf auf (z. B. fehlende Transparenz, hoher manueller Aufwand, Doppelerfassungen)? Für diese gilt es spätere Soll-Prozesse zu definieren, die Verbesserungen bringen.

• Priorisierung von Prozessen: Welche Prozesse sind für das Unternehmen besonders wichtig oder versprechen den größten Nutzen, wenn sie IT-unterstützt werden? Diese priorisierten Prozesse stehen im weiteren Projektverlauf im Fokus (Quick Wins zuerst, siehe Phase 2).

• Objekt- und Anlagendaten: Welche Gebäude, Anlagen, Flächen und Räume umfasst das Portfolio? Wie sind diese strukturiert (z. B. Standort > Liegenschaft > Gebäude > Ebene > Raum > Anlage)?

• Datenbestand und -qualität: In welchem Zustand und Umfang liegen FM-relevante Bestandsdaten vor (planaer und alphanumerisch)? Sind Grundrisse, Anlagenlisten, Verträge etc. aktuell und vollständig oder gibt es Lücken?

• Vorhandene IT-Lösungen: Welche IT-Systeme werden bereits in FM-nahen Bereichen genutzt (z. B. Excel-Listen, alte CAFM-Lösung, Ticketsystem)? Gibt es Schnittstellen zwischen diesen?

• IT-Infrastruktur: Wie sieht die bestehende IT-Landschaft aus (Datenbanken, Server, Netzwerke, Cloud-Nutzung)? Welche Standards oder Vorgaben gibt die IT vor (z. B. bevorzugte Datenbanken, Betriebssysteme, Sicherheitsrichtlinien)?

• IT-Betriebsvorgaben: Gibt es Präferenzen hinsichtlich des Betriebs des neuen Systems – intern gehostet (Inhouse/On-Premise) oder als extern betriebener Dienst (Cloud/SaaS)? Diese Entscheidung beeinflusst später Architektur und Aufwand.

• Strategische Unternehmensvorgaben: Sind besondere Anforderungen zu berücksichtigen, etwa zur Einhaltung von Compliance (z. B. Betreiberverantwortung, ESG-Reporting) oder zur Risikominimierung?

• Know-how und Ressourcen: Verfügt das Unternehmen über eigenes CAFM-Know-how oder ausreichend IT-Personal für die Einführung und den Betrieb, oder müssen diese Kapazitäten extern zugekauft werden? Ebenso: dürfen sensible Daten nur in bestimmten Regionen gespeichert werden (Deutschland/EU) oder gibt es diesbezügliche Einschränkungen?

Je nach Umfang der Organisation kann die Ist-Analyse komplex sein. Es hat sich bewährt, diese Arbeit in Workshops durchzuführen, deren Anzahl und Dauer an die Größe und Komplexität des Unternehmens angepasst werden. Das Team in Phase 1 – intern wie extern – sollte sowohl methodische Kompetenz (Projektmanagement, Moderation, Prozessanalyse) als auch aktuelles Fachwissen im Facility Management und der Digitalisierung/IT mitbringen. Nur so lassen sich einerseits die richtigen Fragen stellen und andererseits moderne Technologien (IoT, KI, BIM etc.) angemessen berücksichtigen. Ob ein externer Berater in dieser Phase lediglich moderiert oder federführend agiert, muss individuell entschieden werden. Es ist auch nicht unüblich, die Konzeptionsergebnisse am Ende dieser Phase durch einen unabhängigen Dritten überprüfen zu lassen (Stichwort Second Opinion), um blinde Flecken zu vermeiden.

Abschließend muss in Phase 1 dem Thema Daten besondere Beachtung geschenkt werden. Daten sind der Kern jedes IT-gestützten FM-Systems – ohne aktuelle und strukturierte Daten kann kein CAFM-System Nutzen stiften. Daher sollte bereits zu Projektbeginn eine Datenanalyse erfolgen und darauf aufbauend ein Erfassungskonzept entwickelt werden. In diesem Schritt wird geprüft, welche Daten vorhanden sind, welche Qualität sie haben und welche Datenmodelle künftig benötigt werden. Das Soll-Datenmodell bildet die Grundlage dafür, vorhandene Daten zu transformieren und neue Daten zu erfassen.

• Datenvollständigkeit und Aktualität bewerten: Das Projektteam verschafft sich Transparenz, wie vollständig und aktuell die benötigten alphanumerischen Stammdaten und grafischen Pläne sind. So lässt sich der Aufwand zur Ergänzung fehlender Daten abschätzen.

• Datenmanagement festlegen: Es ist zu klären, wer zukünftig für die Pflege der verschiedenen Daten verantwortlich sein wird (z. B. ein zentraler Datenmanager für Stammdaten). Prozesse für die laufende Datenaktualisierung sind grob zu skizzieren, damit die Einführung entsprechend geplant wird.

• Migrationsbedarf prüfen: Falls ein Altsystem oder zahlreiche Excel-Listen existieren, ist kritisch zu entscheiden, welche Daten daraus übernommen werden sollen. Nicht alle historischen Daten sind für den künftigen Betrieb notwendig. Übernommen werden sollten nur bereinigte, konsistente Altdaten – eine Datenbereinigung (Eliminieren von Dubletten, Fehlern, Altlasten) ist vor der Migration Pflicht.

• Migrationskonzept vorbereiten: Bereits im späteren Ausschreibungstext (siehe Phase 3) sollte von Anbietern ein Datenmigrationskonzept eingefordert werden. Daher ist es sinnvoll, in Phase 1 schon die grundsätzliche Strategie zu formulieren: Welche Quellen gibt es, welche Formate liegen vor, welche Schnittstellen werden benötigt? Ggf. kann man eine Sichtung der bestehenden Datenbanken und Anwendungen vornehmen, um deren Inhalte und Exportmöglichkeiten zu verstehen.

• Bestandsdatenerfassung planen: Oft müssen fehlende Daten (z. B. Gebäudedaten, Anlagenstammdaten) neu erhoben werden. Dies ist frühzeitig im Projektplan zu berücksichtigen. Bei sehr großem Datenumfang kann es sinnvoll sein, die Datenerfassung vorzuziehen, also schon vor dem eigentlichen Start der Software-Implementierung mit der Bestandsaufnahme zu beginnen. In jedem Fall muss klar definiert sein, welche Zieldatenstruktur bei der Erfassung zugrunde liegt, damit konsistente Daten erhoben werden.

• Qualitätssicherung der Daten: Von Anfang an sollte auch ein Konzept zur Qualitätsprüfung der erfassten Daten eingeplant werden (z. B. Stichproben, Plausibilitätschecks, Einsatz von Tools).

Weiterführende Hilfestellungen zu Datenfragen bieten andere GEFMA-Richtlinien (z. B. GEFMA 430 für Datenbasis und -management, GEFMA 480 für bestimmte Aspekte der Datennutzung). Insgesamt liefert Phase 1 also das Konzept für die CAFM-Einführung: Man weiß, wer im Projekt beteiligt ist, was man erreichen will, wie die aktuelle Lage aussieht und welche Schritte nötig sind. Diese Ergebnisse bilden die Grundlage für alle weiteren Phasen.

Aufbauend auf den Ergebnissen der Konzeptionsphase geht es in Phase 2 darum, das Projekt zur Beschaffung des CAFM-Systems vorzubereiten. Im Zentrum steht die Erstellung eines CAFM-Rahmenkonzepts sowie eines Anforderungskatalogs (Lastenheft). Das Rahmenkonzept beschreibt die passende Lösung für die Organisation unter Berücksichtigung der speziellen Immobilienstruktur und der bestehenden IT-Rahmenbedingungen. In dieser Phase werden die Weichen dafür gestellt, wie das CAFM-System eingeführt wird und welche Anforderungen es erfüllen muss.

Ein erster Schritt ist die Übertragung der zuvor definierten Ziele und Prozesse in ein CAFM-Gesamtkonzept. Hierbei hat es sich bewährt, die Einführung in Ausbaustufen zu gliedern. Man beschreibt eine stufenweise CAFM-Struktur: statt sofort das volle Funktionsspektrum einzuführen, plant man Module bzw. Pakete in sinnvollen Paketen. Moderne CAFM-Software ist oft in Paketen verfügbar (z. B. verschiedene Nutzerrollen oder Funktionspakete wie Basis, Standard, Professional, Admin). Es gilt, auf Basis der priorisierten Problemstellungen (aus Phase 1) festzulegen, welche Module oder Funktionsbereiche zuerst umgesetzt werden sollen. Die Priorisierung berücksichtigt neben dem Nutzen auch die Abhängigkeiten zwischen Modulen – manche Funktionen setzen andere Daten oder Module voraus und müssen daher in logischer Reihenfolge kommen.

Empfehlenswert ist, dass bereits mit der ersten Ausbaustufe spürbare Erfolge erzielt werden (Quick Wins). Beispielsweise kann man sich zunächst auf einen repräsentativen Teil des Portfolios konzentrieren und dort alle wichtigen Basisdaten digital erfassen, um erste Auswertungen zu ermöglichen (z. B. Flächenmanagement mit aktuellen Flächendaten, Berichte zum Gebäudezustand oder Inventarübersichten). Oft wird auch mit der Einführung eines Helpdesks (Störungs- und Meldungsmanagement) oder eines Workplace-Managements begonnen, da diese mit relativ geringem Datenaufwand startfähig sind und schnell sichtbaren Nutzen stiften (z. B. einfaches Meldungsmanagement für Nutzer). Sobald diese initialen Module laufen, schafft man damit Voraussetzungen für die nächsten Ausbaustufen: Weitere Module können Schritt für Schritt hinzugefügt werden, wobei die bereits erfassten Daten genutzt und kontinuierlich erweitert werden. So wächst das System organisch mit den Bedürfnissen, ohne die Organisation zu überfordern.

Ein wesentlicher Bestandteil der Phase 2 ist die Formulierung der Anforderungen an das CAFM-System. Diese Anforderungen leiten sich direkt aus den Projektzielen und den in Phase 1 analysierten Prozessen ab. Orientierung bietet hier die GEFMA 400 (Richtlinie zu CAFM-Grundlagen), in der typische Kernfunktionalitäten eines CAFM aufgelistet sind. Bei der Erstellung des Anforderungskatalogs sollte man die für das eigene Unternehmen relevanten Funktionsbereiche bestimmen. Klassische funktionale Anwendungsgebiete eines CAFM-Systems sind zum Beispiel: Bestandsdokumentation, Flächenmanagement, Instandhaltungsmanagement, Reinigungsmanagement, Umzugsmanagement, Vertragsverwaltung, Vermietungsmanagement, Betriebskostencontrolling, Energie- und Umweltmanagement, Helpdesk/Service-Desk, Reservierungsmanagement (Raum/Asset), Schließanlagenverwaltung, Budget- und Kostenverfolgung sowie BIM-Datenverarbeitung. Diese Liste muss auf die individuellen Bedürfnisse angepasst werden – manche Unternehmen benötigen vielleicht nicht alle genannten Module, andere haben zusätzliche spezielle Anforderungen. Wichtig ist zudem, Muss-Anforderungen von Kann-Anforderungen zu unterscheiden, um Prioritäten deutlich zu machen.

• Integration in die IT-Landschaft: Das System muss in bestehende IT-Strukturen passen (siehe nächster Abschnitt zur Integration). Es sollte Standard-Schnittstellen bieten (z. B. Import/Export von Excel, CSV, IFC für BIM-Daten) und kompatibel zu üblichen Technologien sein.

• Softwarearchitektur: Gewünscht ist meist eine modulare, skalierbare Architektur mit Mehrbenutzerfähigkeit. Aspekte wie Webfähigkeit (Browserzugriff), Mobile Unterstützung (Apps für Techniker etc.), Mehrfaktor-Authentifizierung zur Sicherheit, und mandantenfähige Datenhaltung (Trennung verschiedener Bereiche oder Mandanten, falls nötig) gehören oft zu den technischen Anforderungen.

• Modernität und Zukunftssicherheit: Die Software sollte aktuelle Technologien unterstützen, z. B. Nutzung von BIM-Modellen, IoT-Integration (IoT-Sensoren für Gebäude), KI-Funktionen (wie automatische Datenauswertung oder Sprachsteuerung) oder Cloud-Services. Hier geht es darum, dass das System auch mittel- und langfristig innovativen Anforderungen standhält.

• Benutzerfreundlichkeit und Visualisierung: Das System sollte eine effektive Visualisierung von FM-Daten erlauben, z. B. Einbindung von CAD-Plänen oder BIM-3D-Modellen, damit Nutzer intuitiv mit Flächenplänen und Anlagen arbeiten können. Hohe Usability und ergonomische Oberflächen steigern die Akzeptanz.

Ein Spezialthema bei technischen Anforderungen ist die Frage der Systemplattform und Betriebsform: Schon in Phase 2 sollte man festlegen, ob man eine On-Premise-Lösung (Inhouse-Installation) präferiert oder eine Cloud-/SaaS-Lösung in Frage kommt. Diese Entscheidung hat große Auswirkungen auf spätere Projektschritte (z. B. auf IT-Infrastruktur, Datenschutz, Wartungsmodell) und sollte daher bei den Anforderungen mit bedacht werden.

Parallel zur Anforderungsdefinition wird auch das Integrationkonzept für die Einbettung des CAFM in die vorhandene IT-Systemlandschaft entwickelt. Ein CAFM-System steht selten isoliert da – es muss mit anderen Systemen wie ERP (z. B. SAP), Gebäudeautomation, DMS (Dokumentenmanagement), GIS oder Identity-Management (z. B. Active Directory für Benutzerrechte) zusammenarbeiten.

• Welche Daten müssen mit anderen Systemen ausgetauscht werden? (z. B. sollen Stammdaten oder Buchhaltungsdaten zwischen CAFM und ERP synchronisiert werden; sollen Störmeldungen aus der Gebäudeleittechnik ins CAFM fließen usw.?)

• Welche technischen Schnittstellen werden benötigt? (z. B. Webservices, APIs, Dateischnittstellen wie XML/CSV; eventuell Standardformate wie IFC oder OSCRE für Datenaustausch in FM).

• Wie soll der Datenfluss aussehen und in welcher Echtzeit-Tiefe? (Z. B. Live-Anbindung von Sensoren vs. täglicher Batch-Import).

• Anforderungen an Schnittstellentechnologie: Moderne Architekturen setzen oft auf serviceorientierte Ansätze (SOA/Microservices) für bessere Wartbarkeit. Es muss geprüft werden, ob das CAFM-System solche modernen Schnittstellenkonzepte unterstützt oder wie es sich anbinden lässt.

• Beispiele: In der Praxis bedeutet Integration z. B., dass das CAFM über eine Schnittstelle mit dem ERP Kosten- und Auftragsdaten austauscht, damit Wartungsaufträge oder Nebenkostenabrechnungen automatisiert verbucht werden können. Oder dass die Gebäudeautomationsdaten (z. B. Temperaturen, Störmeldungen von Anlagen) ins CAFM gelangen, um dort Wartungsaufträge auszulösen oder Energieberichte zu speisen. Ebenfalls wichtig: Anbindung an DMS, damit z. B. Baupläne oder Verträge, die im DMS liegen, direkt im CAFM verfügbar sind. Auch die Einbindung an ein zentrales Benutzerverzeichnis (Active Directory) sollte konzipiert werden, um die Nutzerverwaltung im CAFM mit den Unternehmensrichtlinien (und Single Sign-On) in Einklang zu bringen.

Das Ziel des Integrationkonzepts ist, früh festzulegen, wie das CAFM-System als Baustein in der gesamten IT-Landschaft funktionieren soll, um Insel-Lösungen zu vermeiden. Dabei ist die Sicherstellung der Datenintegrität und reibungslosen Kommunikation zwischen Systemen entscheidend, denn FM-Prozesse greifen oft auf Daten aus mehreren Systemen zu. Ein weiterer Aspekt in Phase 2 ist der Variantenvergleich möglicher technischer Betriebsmodelle und Architekturen. Hier wird abgewogen, welche Implementierungsvariante für das Unternehmen am geeignetsten ist – On-Premise vs. Cloud/SaaS ist in vielen Projekten eine zentrale Entscheidung.

• On-Premise: Das System läuft auf unternehmenseigener Hardware (Server im eigenen Rechenzentrum). Vorteil: Maximale Kontrolle über Daten, Anpassungen und Sicherheit; das System kann exakt an interne Vorgaben angepasst werden. Nachteil: Höherer interner Aufwand – man braucht ausreichend IT-Ressourcen für Betrieb, Wartung und Updates; zudem sind Anfangsinvestitionen in Server, Speicher etc. nötig. On-Premise wird oft bevorzugt, wenn sehr strenge Datenschutzanforderungen gelten oder wenn bestehende IT-Policies externe Clouds ausschließen.

• SaaS/Cloud: Das System wird vom Anbieter als Service bereitgestellt (in der Cloud). Vorteil: Weniger eigene Infrastruktur nötig (geringere Anfangsinvestition), Skalierbarkeit nach Bedarf, Updates und Betrieb übernimmt weitgehend der Anbieter. Die Nutzung ist ortsunabhängig über Internet möglich. Nachteil: Weniger direkte Kontrolle – man muss dem Anbieter bzgl. Datensicherheit und Verfügbarkeit vertrauen. Datenschutz und Compliance müssen genau geprüft werden (wo werden die Daten gehostet? werden alle gesetzlichen Anforderungen erfüllt?). Zudem muss geklärt werden, wie Cloud-Software in die bestehenden Systeme integriert werden kann (Schnittstellen in die Cloud). Oft sind Cloud-Lösungen sehr standardisiert, was weniger Freiheitsgrade für kundenspezifische Änderungen lässt (Stichwort „Clean Core“ – keine individuellen Code-Anpassungen, nur Konfiguration).

Um die Entscheidung zu objektivieren, erstellt man idealerweise eine Kriterienmatrix: Hier werden relevante Kriterien (z. B. Kosten, Datensicherheit, Flexibilität, Skalierbarkeit, Abhängigkeit vom Anbieter, Integrationsaufwand) gewichtet und für beide Varianten bewertet. So kann man nachvollziehbar entscheiden, welche Betriebsform den Anforderungen und der IT-Strategie des Unternehmens besser entspricht.

Parallel zur technischen Planung darf die Wirtschaftlichkeitsbetrachtung nicht fehlen. Ein CAFM-Projekt sollte durch einen soliden Business Case untermauert sein: Was kostet die Einführung und der Betrieb, und welcher Nutzen (quantitativ und qualitativ) steht dem gegenüber? In Phase 2 werden daher eine grobe Kosten-Nutzen-Analyse und eine Budgetplanung durchgeführt:

• Zunächst werden alle Kostenkategorien identifiziert, die ein solches Projekt mit sich bringt. Typischerweise fallen Kosten an für Consulting (externe Beratungs- und Planungsleistungen), Software-Lizenzen bzw. Nutzungsgebühren (inkl. evtl. Module oder Nutzerstaffelungen), Hardware-Anschaffungen (bei On-Premise: Server, Speicher; bei Cloud meist gering oder null), Datenerfassung/-migration (Ersterfassung fehlender Daten, Datenübernahme aus Altbeständen, Qualitätssicherung), Customizing und Schnittstellenentwicklung (wobei man i.d.R. versucht, ohne Individualprogrammierung auszukommen), Projektmanagement (intern und ggf. extern), Schulungen (für Anwender, Key-User, Administratoren) und laufende Kosten (Wartungsverträge, Updates, SaaS-Gebühren, Cloud-Betriebskosten). Diese Kostenbestandteile müssen abgeschätzt werden.

• Für die Nutzenbetrachtung schaut man auf Einsparpotenziale und Verbesserungen durch das CAFM: z. B. Reduktion von Suchzeiten durch digitale Dokumentation, Vermeidung von Strafen durch lückenlose Prüfungsnachweise, Optimierung von Flächennutzung mit Kosteneinsparungen, effizientere Prozesse mit geringerem Personalaufwand oder besserer Dienstleistersteuerung usw. Viele Nutzenpunkte sind qualitativ, aber es gilt soweit möglich auch eine monetäre Schätzung zu wagen (z. B. “x % weniger Leerstandskosten”, “y Stunden Arbeitszeit pro Monat einsparen”).

Da zu diesem frühen Zeitpunkt noch nicht alle Details bekannt sind, basiert die Budgetplanung auf Schätzungen. Man orientiert sich an Referenzprojekten und Marktdaten: Hat das Unternehmen vielleicht schon ähnliche Projekte umgesetzt (Erfahrungswerte)? Gibt es Branchen-Benchmarks oder veröffentlichte Kostenrahmen? Oft können Fachberater oder Verbände grobe Richtgrößen liefern, wie hoch der Aufwand pro Gebäude oder pro Nutzer ist. Auch die Lizenzmodelle der CAFM-Anbieter liefern Anhaltspunkte – z. B. veröffentlichen manche Anbieter Preisranges pro User, die man an der geplanten Nutzerzahl hochrechnen kann. Ebenso müssen Implementierungskosten geschätzt werden, etwa auf Basis der Projektkomplexität (Anzahl Module, Schnittstellen) und bekannten Tagessätzen.

Wichtig ist, beim vorläufigen Budget stets einen Puffer einzubauen, da Unvorhergesehenes eintreten kann. Gerade in der IT-Kalkulation empfiehlt es sich, nicht zu knapp zu planen, um mögliche Zusatzaufwände (Änderungswünsche, zusätzliche Daten, höhere Schulungsbedarfe etc.) auffangen zu können.

Haben Projektkonzept und grober Kostenrahmen Gestalt angenommen, geht es darum, die internen Projektgenehmigungen einzuholen. In vielen Unternehmen ist dies ein formaler Prozess: Auf Basis des Lastenhefts, des Nutzenarguments und der Budgetkalkulation muss die Geschäftsleitung oder ein Lenkungsgremium überzeugt werden, das Projekt offiziell zu starten.

• Projektziele und Mehrwert: Was soll erreicht werden und warum ist es wichtig? Hier werden die geplanten Verbesserungen und Quick Wins nochmals hervorgehoben, damit Entscheider den Nutzen klar erkennen.

• Kostenschätzung und Budgetplan: Der aufgestellte Kostenplan wird präsentiert, inklusive Total Cost of Ownership (TCO) über mehrere Jahre. Die Entscheider sollen verstehen, welche Investition erforderlich ist – und dass Folgekosten (Wartung, Betrieb) entstehen, nicht nur einmalige Anschaffungskosten. Dem gegenüber stellt man den erwarteten Nutzen (auch qualitativ), um ein Kosten-Nutzen-Verhältnis aufzuzeigen.

• Zeitplan: Eine grobe Roadmap mit den Projektphasen, Meilensteinen und der voraussichtlichen Projektdauer bis zum voll produktiven Betrieb. Hier sollte auch der Ressourcenbedarf (intern wie extern) transparent gemacht werden – z. B. wie viele interne Stellen über welchen Zeitraum gebunden werden, ob externe Dienstleister eingeplant sind etc.

• Risikoanalyse: Welche Risiken gibt es (z. B. Projektverzögerungen, Schwierigkeiten bei der Datenqualität, Widerstand in der Belegschaft) und wie will man ihnen begegnen? Ein guter Risikoplan (mit Gegenmaßnahmen) zeigt der Führung, dass das Team realistisch plant und gewappnet ist.

Je nach Unternehmensstruktur wird diese Entscheidung in Meetings, Ausschüssen oder schriftlich getroffen. Häufig gibt es erst eine Präsentation vor den Stakeholdern (FM-Leitung, IT-Leitung, evtl. kaufmännische Leitung), um das Projekt vorzustellen und Fragen zu beantworten. Danach wird eine formale Entscheidungsvorlage eingereicht und beschieden. Mit der Genehmigung werden zugleich die Ressourcen freigegeben – sprich: Budget wird allokiert, interne Mitarbeiter dürfen offiziell Zeit fürs Projekt aufwenden, ggf. wird ein Projektnummer angelegt etc. Die Projektgenehmigung markiert den Übergang von der Planungs- in die Umsetzungsphase und ist daher ein wichtiger Meilenstein.

Häufig parallel zu den oben genannten Schritten erfolgt auch eine Priorisierung der Funktionen für die Umsetzung. Zwar wurden in Phase 1 schon Prozesse priorisiert, doch nun – mit konkretem Blick auf die Einführung – legt man fest, welche CAFM-Funktionalitäten zuerst eingerichtet werden sollen.

• Betriebliche Dringlichkeit: Funktionen, die kritische Geschäftsprozesse unterstützen (z. B. Wartungsplanung, Flächenmanagement oder Vertragsmanagement), haben hohe Priorität, weil ohne sie der Nutzen gering wäre.

• Realisierbarkeit: Was lässt sich mit vertretbarem Aufwand umsetzen? Teilweise lohnt es, zunächst die technisch einfacheren Dinge zu tun (z. B. modulare Features, die keine großen Schnittstellen erfordern).

• Nutzerbedarf und -akzeptanz: Funktionen, die von vielen Endanwendern sehnlich erwartet werden (z. B. ein Self-Service-Helpdesk oder mobile Apps für Techniker), können Priorität erhalten, um schnell eine breite Akzeptanz zu fördern.

• Aufwandsabschätzung: Kleinere Features, die schnell implementiert sind, können vorgezogen werden, um zügig Erfolge vorzuweisen – vorausgesetzt, sie bringen auch Nutzen.

Beispielsweise Phase 1 (Ausbaustufe 1) beinhaltet Module A, B, C; Phase 2 (später) dann Module D, E usw. – entsprechend den Meilensteinen. Dies hilft auch, den Projektverlauf zu strukturieren und später den Fortschritt zu kontrollieren.

Ein weiterer wichtiger Bestandteil des Lastenhefts ist die Definition der vom Bieter zu erbringenden Dienstleistungen. Neben der Software an sich muss ein Anbieter in der Regel ein Paket an Services liefern, damit Einführung und Betrieb gelingen. Schon in Phase 2 sollte daher klar werden, welche Leistungen im Ausschreibungstext gefordert werden.

• Implementierung & Customizing: Unterstützung durch Fachleute des Anbieters bei der Installation, Konfiguration und Anpassung der Software an die unternehmensspezifischen Bedürfnisse (Workflows, Zusatzfelder, Berichte). Dazu zählen oft auch Workshops zur Anforderungsfeinjustierung.

• Hosting (bei Cloud) oder technische Bereitstellung: Falls eine SaaS-Lösung gewünscht ist, stellt der Anbieter die IT-Infrastruktur (Server, Datenbanken, Backups) bereit. Bei On-Premise liefert der Anbieter ggf. Spezifikationen für benötigte Hardware oder unterstützt die Installation auf Kundensystemen.

• Schnittstellen-Integration: Einrichtung der benötigten Schnittstellen zu bestehenden Systemen (z. B. ERP-Connector, Import aus CAD-Systemen etc.). Hier muss klar sein, welche Schnittstellen der Bieter einrichten soll – Standard oder individuell.

• Datenübernahme: Unterstützung bei der Migration vorhandener Daten. Das kann sowohl die automatisierte Übernahme digitaler Daten aus Altsystemen umfassen, als auch die Erfassung fehlender Daten (Bestandsdatenerfassung) durch Dienstleister. Gegebenenfalls schreiben Unternehmen separate Leistungen zur Datenerfassung aus oder erwarten vom CAFM-Anbieter, solche Leistungen mit anzubieten.

• Schulung: Der Anbieter soll Schulungen für die verschiedenen Nutzergruppen durchführen (Key-User, Administratoren, Endanwender), damit das System effektiv genutzt werden kann. Umfang und Art der Schulungen (Anzahl Tage, vor Ort vs. Online) sollten festgelegt werden.

• Support: Wie soll der laufende Support organisiert sein? Oft wird erwartet, dass der Anbieter einen 3rd-Level-Support liefert (für technische Fragen oder Probleme, die intern nicht gelöst werden können). Service-Level-Agreements (Reaktionszeiten, Verfügbarkeiten) können hier definiert werden.

• Managed Services (optional): Manche Auftraggeber möchten über den Standard hinausgehende Leistungen buchen, z. B. Unterstützung bei der Administration des Systems (User-Management, regelmäßige Systemchecks), Auswertungs- und Berichtsdienste (Erstellung von Dashboards, KPI-Analysen) oder Unterstützung bei der Weiterentwicklung der FM-Strategie (beratende Tätigkeiten auf Basis der im System gesammelten Daten). Solche Managed Services können ebenfalls im Lastenheft beschrieben werden, um Anbietern Gelegenheit zu geben, entsprechende Pakete anzubieten.

Durch das frühzeitige Festlegen dieser Dienstleistungen wird sichergestellt, dass im späteren Ausschreibungsverfahren die Angebote vergleichbar sind und der gewählte Anbieter tatsächlich alle benötigten Leistungen abdecken kann.

Sind Anforderungen und Konzept hinreichend ausgearbeitet, wird das Lastenheft erstellt. Das Lastenheft (oder Anforderungskatalog) ist das zentrale Dokument, das alle Erwartungen an die Software und den Anbieter zusammenfasst. Es sollte klar strukturiert und präzise formuliert sein, um Missverständnisse zu vermeiden.

• Einleitung: Ziele des Projekts, Hintergrund und Motivation der CAFM-Einführung im Unternehmen.

• Projektumfeld & Rahmenbedingungen: Beschreibung der bestehenden Organisation und IT-Landschaft, Anzahl Liegenschaften, Nutzer etc., relevante Schnittstellen zu anderen Systemen.

• Funktionale Anforderungen: Detaillierte Auflistung aller benötigten Funktionen, idealerweise gekennzeichnet als „Muss“ oder „Kann“. Hier fließen die priorisierten Funktionen aus der vorigen Schritt ein.

• Technische Anforderungen: Vorgaben zur Systemarchitektur (z. B. Browser-basiert, Datenbankanforderungen), zum Betrieb (On-Premise/Cloud), zu erforderlichen Schnittstellen und Sicherheitsanforderungen (z. B. Penetrationstest, DSGVO-Konformität).

• Implementierungsanforderungen: Erwartete Vorgehensweise der Einführung – Meilensteine, Pilotphase, Datenmigration, Schulungskonzepte, Abnahmeprozedere usw.

• Dienstleistungsumfang: Welche Services werden vom Anbieter erwartet (siehe oben – Implementierung, Support, Wartung, etc., einschließlich eventuell gewünschter Managed Services).

• Vertragsbedingungen (optional): Falls schon bestimmte Vertragskonditionen oder Lizenzmodelle vorgegeben werden (z. B. Mietsoftware mit jährlicher Gebühr vs. Kauf mit Wartungsvertrag), können diese aufgeführt werden. Rechtliche Anforderungen, etwa zur Haftung, Datenschutzvereinbarungen oder geforderten Zertifikaten, gehören ebenfalls hierhin.

Das Lastenheft wird zum Leitfaden für die Ausschreibung in Phase 3. Es bildet die Bewertungsgrundlage für Angebote und dient auch im Projektverlauf als Referenz, ob alles Gelieferte den Anforderungen entspricht. Daher ist Vollständigkeit und Eindeutigkeit extrem wichtig. Änderungen am Bedarf später im Projekt sind immer aufwändig – deshalb so viel Klarheit wie möglich im Lastenheft schaffen. Abschließend kümmern wir uns in Phase 2 um das Datenerfassungs- und Datenmigrationskonzept – ein Thema, das zwar schon in Phase 1 bedacht wurde, nun aber konkretisiert werden muss. Für den Projekterfolg ist es entscheidend, dass alle relevanten FM-Daten zum richtigen Zeitpunkt in der benötigten Qualität im System vorliegen.

• Datenbedarf klären: Welche Bestandsdaten müssen vor Start des Systems vorhanden sein? (Gebäudedaten, Flächen und Räume, Anlagen-Stammdaten, Verträge, Wartungspläne, Kostenstellen etc.) Was kann eventuell in Etappen nachgepflegt werden?

• Datenquellen identifizieren: Wo kommen diese Daten her? Existieren sie bereits digital (im Altsystem, in Excel, CAD-Zeichnungen) oder müssen sie neu erhoben werden (durch Begehungen, Nachvermessung, Interviews mit Fachleuten)?

• Datenerfassung planen: Für fehlende Informationen wird festgelegt, wie sie erhoben werden. Möglichkeiten reichen von manueller Erfassung (z. B. Techniker sammeln vor Ort die Daten von Anlagen) über Übernahme aus Dokumenten (digitale Pläne einlesen, Listen importieren) bis hin zu Einsatz moderner Methoden wie Laserscanning von Gebäuden, Drohnenvermessung oder Nutzung von BIM-Modellen aus Bauprojekten. Wichtig ist, dass alle neu erfassten Daten nach dem gleichen Schema strukturiert werden, das dem CAFM-System entspricht. Dies erfordert klare Vorgaben an Datenstrukturen und Benennungen (z. B. Raumnummernsystematik, Anlagenschlüssel, einheitliche Bezeichnungen).

• Datenmigration planen: Für bereits vorhandene digitale Daten (z. B. aus einem Vorgängersystem oder aus diversen Excel-Listen) wird ein Migrationsplan erstellt. Dieser beschreibt Schritt für Schritt, wie die Daten ins neue System übertragen werden:

• Bestandsaufnahme: Zunächst alle Altdaten sammeln und auf Vollständigkeit und Qualität prüfen.

• Datenbereinigung: Vor dem Import werden die Altdaten gesäubert (Dubletten entfernen, Fehler korrigieren, veraltete Einträge archivieren).

• Datenmapping: Die Strukturen der Altdaten werden auf das neue Datenmodell abgebildet. Dabei müssen evtl. Attribute umbenannt, Werte konvertiert oder Klassifikationen vereinheitlicht werden.

• Testmigration: Bevor man „scharf“ geht, führt man eine Probe-Migration durch. Man importiert einen begrenzten Datenausschnitt ins neue System und prüft, ob alles korrekt ankommt und ob die Daten im CAFM wie erwartet nutzbar sind. Aus der Testmigration lernt man und passt ggf. das Mapping oder die Importwerkzeuge an.

• Durchführung der endgültigen Migration: Nach erfolgreichem Test werden alle vorgesehenen Altdaten in das neue System übertragen, idealerweise zeitnah zur Inbetriebnahme.

• Validierung nach Migration: Nach dem Import ist eine Qualitätskontrolle nötig – sind die Daten vollständig und richtig im neuen System vorhanden? Werden Umlaute, Sonderzeichen, Beziehungen etc. korrekt dargestellt?

• Verantwortlichkeiten & Prozesse: Das Konzept definiert auch, wer diese Arbeiten durchführt (internes Team, Dienstleister, Softwareanbieter) und wann dies geschieht. Häufig müssen z. B. parallel zur Softwareimplementierung schon Daten erfasst werden – das muss zeitlich koordiniert sein. Zudem wird festgelegt, wie die Datenpflege später weitergeht (denn Datenarbeit endet nicht mit der Einführung, sondern geht in Phase 5 kontinuierlich weiter).

All diese Vorarbeiten aus Phase 2 – vom Anforderungskatalog über Budget und Genehmigung bis hin zum Datenkonzept – münden schließlich in eine konkrete Ausschreibungsvorbereitung, sofern ein Ausschreibungsverfahren geplant ist. Mit einem durchdachten Anforderungskatalog und einem realistischen Budget im Rücken ist das Projektteam nun gerüstet, in den Markt zu gehen und Angebote für die CAFM-Lösung einzuholen.

In Phase 3 erfolgt die eigentliche Softwareauswahl und Vergabe des Implementierungsauftrags. Nachdem in Phase 2 die Vorarbeit geleistet wurde, startet nun das Ausschreibungs- bzw. Beschaffungsverfahren. Diese Phase ist kritisch, denn die Wahl der passenden Software und des richtigen Partners entscheidet maßgeblich über den späteren Projekterfolg und die erzielbaren Nutzen. Allerdings sollte die Produktauswahl nicht der allein dominierende Faktor sein – mindestens ebenso wichtig sind ein durchdachtes Konzept (Phasen 1–2), die Projektführung und die spätere Umsetzung. Mit anderen Worten: Eine gute Software nützt wenig, wenn das Einführungsprojekt schlecht gemanagt wird; umgekehrt kann ein gutes Konzept viel aus einer Software herausholen. Dennoch legt Phase 3 den Fokus auf die formal richtige und fachlich fundierte Auswahlentscheidung.

Zu Beginn der Ausschreibung steht meist die Definition des Bieterkreises. Aus der Markterkundung (Phase 2) ergibt sich eine sogenannte Longlist – vielleicht ~10 Anbieter, die grundsätzlich in Frage kommen. In der Praxis ist es jedoch weder sinnvoll noch üblich, alle diese zu detaillierten Angeboten und Präsentationen aufzufordern, da der Aufwand für alle Beteiligten sehr groß wäre. Daher wird oft vorab eine Shortlist gebildet (ca. 3–5 Anbieter), die letztlich in die engere Auswahl kommen.

• Funktionale Abdeckung: Der Anbieter sollte die geforderten Anwendungsgebiete bzw. Use Cases weitgehend abdecken können. (Früher sprach man von Modulen; heute eher von Anwendungsfällen, die die Software unterstützen muss.)

• Betriebsform: Es muss klar sein, dass der Anbieter die gewünschte Betriebsform liefern kann (wenn das Unternehmen z. B. Cloud fordert, müssen Anbieter mit reiner On-Premise-Lösung ggf. ausscheiden, und umgekehrt).

• Kompatibilität: Die Software sollte mit der bestehenden Systemumgebung kompatibel sein – zumindest bzgl. grundlegender Technologien. Beispiel: Wenn intern nur Windows-Clients erlaubt sind, muss die Software webbasiert oder Windows-fähig sein; oder sie sollte auf der vorhandenen Datenbank (z. B. Oracle, SQL Server) laufen können. Solche technischen Knock-out-Kriterien sind bei der Vorauswahl zu beachten.

• Schnittstellen-Fähigkeit: Anbieter, die bereits erprobte Schnittstellen zu den wichtigsten Fremdsystemen vorweisen können (z. B. zu CAD/BIM-Software, zum vorhandenen ERP oder DMS), haben einen Bonus. Schnittstellen sind oft komplex, daher ist Erfahrung hier wichtig.

• Einhaltung interner Richtlinien: Hat das Unternehmen spezielle Vorgaben (z. B. hinsichtlich Datenschutz, IT-Security, Hosting-Standort etc.), müssen die Anbieter diese erfüllen oder bereit sein, diese zu erfüllen.

• Zukunftssicherheit: Man betrachtet auch den Anbieter selbst – erscheint er innovativ und langfristig zuverlässig? (Stichwort: technologisch moderner Software-Stack, regelmäßige Updates, solide Marktposition).

Hat man interne Richtlinien für Vergaben (z. B. müssen bei größeren Investitionen mindestens drei Angebote eingeholt werden), sind diese zu berücksichtigen. Bei öffentlichen Auftraggebern gelten zudem Vergabegesetze, die es meist nicht erlauben, Anbieter ohne objektive Kriterien vorab auszuschließen. In so einem Fall muss die Shortlist ggf. durch ein offizielles Präqualifikationsverfahren ermittelt werden. Für private Unternehmen ist man flexibler und kann die Shortlist auf Basis der Marktrecherche festlegen.

Nun beginnt die Ausschreibung im engeren Sinne. Wenn ein förmliches Verfahren (nach GWB/VgV bei öffentlichen) nicht vorgeschrieben ist, kann die Ausschreibung auch informell als Angebotsanfrage an mehrere Anbieter erfolgen. Wichtig ist, dem Umfang nach angemessen vorzugehen: Die Ausschreibungsunterlagen sollten genau auf das in Phase 2 definierte Leistungsbild zugeschnitten sein. Zu viel oder unscharfe Anforderungen erschweren die Auswertung; zu wenig Details bergen das Risiko, dass Angebote nicht vergleichbar sind oder wichtige Punkte fehlen.

Im Ausschreibungstext bzw. den Unterlagen (die Kern ist das Lastenheft) sollten alle wichtigen Punkte klar enthalten sein. Gleichzeitig muss man bedenken, dass zum Zeitpunkt der Ausschreibung das konkrete Zielsystem noch nicht bekannt ist – man schreibt ja gerade aus, um es zu finden. Deshalb empfiehlt es sich, Ergebnisoffenheit in manchen Details zu lassen: Man beschreibt was man braucht, aber nicht haarklein wie es umzusetzen ist, damit die Anbieter Lösungsspielraum haben. Zum Beispiel sollte man die gewünschten Funktionen und Datenstrukturen definieren, aber offenlassen, welche genaue Menüführung die Software hat – das obliegt dem Anbieter.

Früher war es gängig, Ausschreibungen strikt an den Geschäftsprozessen des Unternehmens auszurichten: Man hat z. B. im Lastenheft die Prozessschritte im Störungsmanagement beschrieben und verlangt, dass der Anbieter zeigt, wie seine Software diese Schritte abbildet. Heutzutage tendiert man dazu, eher Use Cases vorzugeben – also konkrete Anwendungsfälle – und einige Rahmenbedingungen (z. B. Anzahl User, vorhandene IT-Umgebung) festzulegen, statt jedes Detail zu diktieren. Der Grund: Moderne CAFM-Systeme sind oft sehr umfangreich in ihrer Standardfunktionalität. Um diese Breite zu nutzen und nicht durch zu enge Vorgaben direkt wieder einzuschränken, gibt man den Anbietern etwas Freiraum in der Lösungsgestaltung. So können sie z. B. zeigen, welche Best Practice Workflows in ihrer Software standardmäßig vorhanden sind. Individuelle Anpassungen sollen sich idealerweise nur auf Oberflächen, Auswertungen oder Konfiguration beschränken – und nicht in tiefe Code-Eingriffe münden. Gerade bei Cloud-Lösungen ist man da ja limitiert (Stichwort Clean Core – das System lässt nur Konfiguration, keine kundenspezifischen Codeänderungen zu, was Upgrades erleichtert). Ein weiterer Vorteil dieser Methode: Sind weniger individuelle Anpassungen nötig, reduziert das meist Zeit- und Kostenaufwand für Einführung und Betrieb.

Im Verlauf der Ausschreibung wird es in der Regel Bieterpräsentationen geben (Phase 3.2). Diese dienen dazu, die möglichen Produkte und Anbieter live kennenzulernen und praktisch zu vergleichen. In der Einladung zur Präsentation sollten bereits einheitliche Vorgaben gemacht werden, damit die Vorführungen vergleichbar sind. Typischerweise erhalten alle Shortlist-Anbieter vorab ein Szenario oder eine Liste von Use Cases, die sie präsentieren sollen.

• Bestimmte Funktionalitäten sollen gezeigt werden (z. B. Anlage einer Fläche und Zuordnung zu einem Mietvertrag, Erfassung einer Störmeldung und deren Workflow bis Abschluss, etc.).

• Vorgegebene Anwenderszenarien: Man kann z. B. einen fiktiven Arbeitsablauf beschreiben (“ein Nutzer meldet einen Defekt, dieser wird intern zu einer Aufgabe, der Techniker quittiert nach Ausführung…”) und der Anbieter muss vorführen, wie seine Software das abbildet.

• Berücksichtigung der IT-Umgebung: Es ist sinnvoll, den Bietern vorab Infos über die firmenspezifische IT-Landschaft zu geben (z. B. “unsere Standard-Datenbank ist MS SQL”, “User-Authentifizierung läuft über AD, zeigen Sie, wie Ihr System das handhabt”). So können sie darauf eingehen und ggf. Besonderheiten erläutern.

• Verwendung eigener Beispieldaten: Ein guter Ansatz ist, den Anbietern einen kleinen Satz an realen Unternehmensdaten zur Verfügung zu stellen (z. B. Grundrisspläne, Beispiel-Liegenschaftsdaten), damit sie diese in der Präsentation verwenden. Das erhöht die Aussagekraft, weil man sieht, wie eigene Daten in der Software aussehen und funktionieren.

Durch diese Einheitlichkeit ist ein direkter Vergleich zwischen den Anbietern möglich: Man sieht, wer die geforderten Prozesse am besten unterstützt, welche Technologien eingesetzt werden und wie benutzerfreundlich die Anwendungen wirken. Außerdem fördert es die Einbindung der zukünftigen Endanwender: Man kann ausgewählte Key-User aus dem Fachbereich zur Präsentation einladen und sie die Systeme bewerten lassen (z. B. mittels standardisierter Bewertungsbögen oder Scoring-Modellen). Deren Feedback ist wertvoll, denn sie werden später täglich damit arbeiten müssen.

In manchen Fällen bieten Anbieter auch an, einen Testzugang oder eine Pilotinstallation für kurze Zeit zur Verfügung zu stellen, damit das Unternehmen eigenständig das System ausprobieren kann. Das kann ein zusätzlicher Baustein sein, um die Entscheidung abzusichern. Wichtig ist dann, dass eine solche Teststellung strukturiert erfolgt: Die Testnutzer sollten eine kleine Schulung erhalten (sonst vergleichen sie eher die eigene IT-Affinität als die Softwarequalität) und konkrete Aufgaben im System durchführen. Der Test sollte zeitlich begrenzt und auf relevante Use Cases beschränkt sein, um die Teilnehmer nicht zu überfrachten. Solche Online-Tests sind insbesondere bei webbasierten Cloud-Lösungen einfach realisierbar (man bekommt z. B. eine URL, einen Account und kann loslegen). Ob man den Test vor oder nach den Hauptpräsentationen macht, ist Geschmacksache – beides wird praktiziert. Wichtig ist, die Ergebnisse in die Gesamtbewertung einfließen zu lassen.

Nach Abschluss aller Präsentationen und etwaiger Tests folgt die Bewertung der Angebote (Phase 3.3). Diese umfasst im Prinzip zwei Teile: die schriftlichen Angebote der Anbieter (inkl. Preisangebote) und die Ergebnisse der Präsentationen/Teststellungen. Man sollte vorab ein Bewertungsschema festlegen, damit die Beurteilung fair und nachvollziehbar abläuft. GEFMA 440 (Ausschreibungen im CAFM) enthält beispielhafte Kriterien und Gewichtungen für so eine Bewertungsskala.

• Fachliche Eignung der Software (Erfüllung des Anforderungskatalogs, modulare Abdeckung, Flexibilität)

• Technische Eignung (Integrationsfähigkeit, Architektur, Zukunftssicherheit)

• Eindruck aus Präsentation (Usability, Look & Feel, Akzeptanz bei den Usern)

• Service und Support (Qualität der vorgeschlagenen Dienstleistungen, Referenzen, Schulungskonzept)

• Kosten (Lizenzkosten, Dienstleistungen, laufende Betriebskosten)

Jedem Kriterium wird ein Gewicht gegeben (z. B. 40% Funktion/Qualität, 30% Preis, 20% Service, 10% Sonstiges). Die Angebote werden dann anhand dieser Matrix bewertet und erhalten Punkte. Wichtig: Damit die Kosten objektiv vergleichbar sind, empfiehlt es sich, den Bietern ein Preisblatt vorzugeben, das sie ausfüllen müssen. Meist in Excel-Form listet es alle relevanten Positionen (Lizenzen, Module, Tagessätze, etc.), sodass jeder Anbieter strukturiert seine Preise einträgt. Nur so hat man die Gewähr, dass nichts Übersehen wird und man am Ende z. B. Wartung A nicht mit Wartung B (die evtl. etwas anderes beinhaltet) vergleicht. Dennoch bleibt Preisvergleich im Detail oft schwierig, da Lizenzmodelle und Leistungspakete der Anbieter sehr unterschiedlich sein können. Hier ist es legitim, bei Unklarheiten Nachfragen zu stellen oder – wenn nötig – externe Expertise zu ziehen, um Angebote richtig zu interpretieren (Second Opinion durch unabhängigen Berater oder Gutachter).

Sobald ein Anbieter im Bewertungsverfahren vorn liegt, geht man in die Vertragsverhandlungen (Phase 3.4) mit diesem (oder den Top 2–3, falls noch kein eindeutiger Sieger feststeht). In dieser Phase wird aus dem Angebot ein belastbarer Vertrag ausgearbeitet. Idealerweise verhandelt man parallel mit maximal zwei bis drei Anbietern, um Konkurrenzdruck zu wahren, aber auch die Verhandlung effizient zu halten. Alle für die Vergabeentscheidung relevanten Stakeholder sollten einbezogen sein – neben der Projektleitung also z. B. der Einkauf (wegen Vertragskonditionen) und evtl. die Rechtsabteilung. Die Verhandlungen sollten strukturiert und vergleichbar ablaufen, z. B. indem man für alle Bieter die gleichen Verhandlungspunkte aufruft und ähnlich bewertet.

• Preis- und Lizenzmodell: Letzte Klärung der Kosten, Rabatte, Zahlungspläne. Hier wird oft über einmalige Kosten vs. laufende Gebühren gesprochen, und es wird vertraglich fixiert, welche Module/Lizenzen im Preis enthalten sind.

• Bedingungen (AGB/Einkaufsbedingungen): Jede Seite hat Standardbedingungen – man einigt sich auf eine Basis (entweder der Kunde oder der Anbieter oder ein neutraler Standard). Bei SaaS und Cloud sind die Spielräume oft geringer, da Anbieter eher standardisierte Verträge haben. Trotzdem sollte man kritische Punkte wie Gewährleistung, Haftung, Verfügbarkeit, Datenschutz verhandeln.

• Leistungsbeschreibung und Pflichten: Der Vertrag sollte eindeutig referenzieren, welche Leistungen der Anbieter zu erbringen hat, basierend auf dem Angebot und Lastenheft. Dazu gehören die Software selbst (Version, ggf. Module), die Dienstleistungen (Implementierung, Schulung etc. mit Zeitrahmen) und Supportleistungen (Reaktionszeiten, Dauer).

• Abnahmekriterien: Es sollte festgehalten werden, wann die Abnahme des Systems erfolgt und unter welchen Voraussetzungen (z. B. definierte Meilensteine, Abnahmeprotokoll, Umgang mit Mängeln).

• Vergabekriterien-Gewichtung (bei Verhandlung): Falls mehrere Anbieter in Endverhandlung sind, kann man vorher definieren, wie man das finale Angebot bewertet (z. B. wie erwähnt: 30% Preis, 40% Anforderungen, 20% Nutzerfeedback, 10% Team-Eindruck). Oft fließen in letzter Instanz auch „weiche“ Faktoren ein, wie das Vertrauen ins Implementierungsteam oder Referenzen aus der Branche.

Am Ende der Verhandlungen sollte das wirtschaftlichste Angebot den Zuschlag erhalten. „Wirtschaftlich“ bedeutet hier: bestes Gesamtpaket aus Qualität und Preis, nicht zwingend das billigste. Sollten mehrere Anbieter nahezu gleichauf liegen, können zusätzliche Entscheidungskriterien herangezogen werden – etwa die Bewertung durch die Key-User (subjektives Empfinden), besondere Alleinstellungsmerkmale eines Systems oder die Perspektive einer langfristig besseren Partnerschaft. Wichtig ist, diese Entscheidungen gut zu dokumentieren, um sie intern vertreten zu können.

Für öffentliche Auftraggeber gibt es in diesem Kontext noch spezielle Rahmenbedingungen zu beachten. So stehen im öffentlichen Sektor fertige Vertragsmuster (EVB-IT) zur Verfügung, die an IT-Vergaben angepasst sind. Dazu zählen z. B. der EVB-IT Systemvertrag für größere IT-Projekte oder andere EVB-IT-Vertragsvarianten für Kauf, Service etc. Diese Standardverträge, herausgegeben vom Bund, decken Themen wie Abnahme, Haftung, Datenschutz, Nutzungsrechte etc. ab und schaffen eine ausgewogene Basis. Öffentliche Stellen sind angehalten (aber nicht absolut verpflichtet), diese zu verwenden. Seit 2024 gibt es sogar EVB-IT in digitaler Rahmenvereinbarungsform, was die Handhabung moderner macht. Für unser CAFM-Projekt bedeutet das: Sollte ein öffentliches Vergabeverfahren durchgeführt werden, würde man typischerweise einen EVB-IT Systemvertrag abschließen. In der privaten Wirtschaft kann man sich daran orientieren oder eigene Verträge aufsetzen – jedoch sind die in EVB-IT geregelten Punkte auch für private Verträge sinnvoll (Klarheit bei Gewährleistung, Leistungsbeschreibungen, Rechten etc.).

Nach Vertragsabschluss beginnt mit Phase 4 die eigentliche Implementierung des CAFM-Systems. In dieser Phase wird die gekaufte/gewählte Softwarelösung für den produktiven Einsatz im Unternehmen vorbereitet und eingeführt. Alle Planungen und Anforderungen der vorherigen Phasen werden jetzt in die Tat umgesetzt. Ziel der Implementierungsphase ist es, durch ein systematisches und koordiniertes Vorgehen die Vorteile der CAFM-Software voll auszuschöpfen und nachhaltige Verbesserungen in den FM-Prozessen zu erreichen.

Eine CAFM-Einführung ist meist kein „Big Bang“, sondern ein mehrstufiger Prozess. Oft startet man – wie geplant – mit den priorisierten Bereichen (siehe Quick Wins aus Phase 2), um möglichst früh einen Mehrwert zu generieren und somit die Akzeptanz im Unternehmen hochzuhalten. Nach und nach folgen dann weitere Funktionen und Daten. Phase 4 umfasst sowohl technische Arbeiten (Installation, Konfiguration, Datenmigration) als auch Change-Management-Aspekte (Schulung der Mitarbeiter, Pilotphasen zur Gewöhnung, etc.). Nach erfolgreicher Abnahme (Prüfung, ob alles wie vereinbart umgesetzt wurde) wird die Software dann offiziell in Betrieb genommen (Produktivstart).

Ein wichtiger Erfolgsfaktor in Phase 4 ist das Projektmanagement (4.1). Obwohl das Projekt schon seit Phase 1 läuft, wird es jetzt besonders anspruchsvoll: Unterschiedliche Teams (internes Projektteam, Softwareanbieter, evtl. weitere Dienstleister) müssen koordiniert werden. Kommunikation und Timing sind entscheidend. Es sollte zu Beginn der Implementierung einen gemeinsamen Kick-off-Workshop geben, an dem der interne Projektleiter, sein(e) Stellvertreter und das Team des Softwarelieferanten (inkl. deren Projektleiter) teilnehmen. Hier werden nochmal die gemeinsamen Ziele, Rahmenbedingungen und der grobe Fahrplan durchgesprochen, sodass alle Beteiligten ein einheitliches Verständnis haben. Oft entsteht daraus ein abgestimmter Detailprojektplan mit konkreten Terminen, Zuständigkeiten und Meilensteinen, der regelmäßig aktualisiert wird.

Die Aufgaben der Projektleitung (bzw. des Projektmanagements) in dieser Phase umfassen: kontinuierliche Kontrolle von Terminen (Einhaltung des Zeitplans), Überwachung der Qualität der Ergebnisse (entsprechen die Entwicklungen den Anforderungen?) und das Kostencontrolling (Budgetverfolgung). Ebenso muss das Projektmanagement auf Änderungswünsche (Change Requests) reagieren – diese sollten formal erfasst und bewertet werden (was bedeuten sie für Zeit & Kosten?), um dann bewusst zu entscheiden, ob/wann sie umgesetzt werden. Unvermeidlich auftretende Probleme wie Terminverzug müssen aktiv gemanagt werden: Wenn z. B. ein Teilprojekt in Verzug gerät, muss neu geplant werden, sonst drohen Kostensteigerungen. Agiles Vorgehen (wie Scrum) kann hier eine Alternative zum klassischen Wasserfall-Projektplan sein, sofern es zum Unternehmen passt und im Vertrag mit dem Anbieter vereinbart wurde. Bei agiler Methodik würde man Anforderungen in einem Product Backlog priorisieren und iterativ in Sprints umsetzen. Anforderungen und Änderungswünsche werden dabei flexibel gehandhabt – sie werden vor jedem Sprint konkretisiert (Refinement) und dann abgearbeitet. Die Beschreibung der Anforderungen erfolgt oft als User Stories („Als [Rolle] möchte ich [Funktion], um [Nutzen] zu erreichen.“). Nach jedem Sprint gibt es lauffähige Funktionen, die idealerweise sofort in der Praxis getestet oder eingesetzt werden können. Dieser iterative Ansatz kann Vorteile bringen, muss aber gut mit Vertrag und Erwartungsmanagement abgestimmt sein.

Ein zentrales Arbeitspaket in Phase 4 ist das Customizing der Software (4.2). Darunter versteht man sämtliche Anpassungen der Standardsoftware an die spezifischen Bedürfnisse und Daten des Unternehmens, ohne tiefergehende Programmierung. In der Regel startet das Implementierungsteam des Herstellers nach dem Kick-off mit einer Grundlagenschulung für die Projektgruppe des Kunden: Ziel ist, dass die Key-User und Projektmitglieder das System in Grundzügen verstehen, bevor es an die Detail-Konfiguration geht. Dann folgen Implementierungsworkshops, in denen man die Anforderungen aus dem Lastenheft Punkt für Punkt durchgeht. Dabei stellt sich heraus, wie der Anbieter diese Anforderungen im Standard abbildet oder wo Anpassungen nötig sind.

Customizing-Stufen: Generell gibt es zwei Arten von Anpassungen: - Anwendungsbezogen: Hierzu zählt die Konfiguration von Datenfeldern, das Einrichten der gewünschten Strukturen (z. B. die hierarchische Objektstruktur, Kostenstellenbaum etc.), das Abbilden der Unternehmensprozesse via Workflow- oder Regel-Engine, und die Anpassung von Berichten/Auswertungen an die Bedürfnisse. Das meiste davon lässt sich mit Bordmitteln konfigurieren.

- Benutzer-/Rechtebezogen: Das Einrichten eines Rollen- und Rechtekonzepts ist essentiell, damit jeder Anwender nur das sieht und tun kann, was er soll. CAFM-Systeme bieten dafür umfangreiche Administrationsmöglichkeiten (z. B. Rechte nach Objekt, nach Funktion, nach Standort etc. vergeben, Mandantentrennungen einrichten).

Moderne CAFM-Systeme haben häufig schon viele branchentypische Prozessmodelle integriert. Daher sollte man auf umfangreiche Sonderprogrammierungen verzichten, um Updates nicht zu gefährden. Idealerweise bleibt das Customizing im Rahmen von Konfiguration, Nutzung von grafischen Workflow-Editoren (viele Systeme erlauben darüber das Modellieren von Genehmigungsabläufen etc. ohne zu coden) und eventuell kleineren Scripts oder Formelanpassungen. Wo Cloud-Lösungen im Spiel sind, sind die Möglichkeiten ohnehin auf Konfiguration beschränkt – was Vor- und Nachteile hat: Weniger Flexibilität, aber auch geringeres Risiko, sich durch „Verbasteln“ vom Update-Pfad abzukoppeln.

Dokumentation: Alle Anpassungsbedarfe, die im Workshop identifiziert werden, sollten sorgfältig dokumentiert werden – entweder in einem Pflichtenheft (das ist die Spezifikation dessen, wie der Anbieter die Anforderungen umsetzt) oder zumindest in einem fortlaufenden Änderungsprotokoll. Bevor der Anbieter die Anpassungen umsetzt, sollte der Kunde diese Spezifikationen freigeben, um sicherzustellen, dass beide Seiten das gleiche Verständnis haben. In agilen Projekten übernimmt das Product Backlog diese Dokumentationsrolle – jede User Story ist eine Anforderung, die dann umgesetzt wird.

Bei umfangreicheren Anpassungen oder wenn doch kundenspezifische Erweiterungen programmiert werden müssen, ist es wichtig, die Release-Fähigkeit der Lösung im Auge zu behalten: D. h. nach Möglichkeit so entwickeln, dass zukünftige Software-Updates eingespielt werden können, ohne dass die kundenspezifischen Funktionen brechen. Viele Systeme unterstützen das, indem sie z. B. Custom-Felder und -Logik in separaten Bereichen ablegen. Dennoch gilt: So wenig Sonderlocken wie möglich.

Sobald die Software konfiguriert und an die wichtigsten Anforderungen angepasst ist, wird in der Regel eine Pilotierung durchgeführt (4.3). Die Pilotphase bedeutet, das System in einem abgegrenzten Bereich unter realen Bedingungen zu testen. Oft wählt man ein „Pilotobjekt“ – z. B. ein bestimmtes Gebäude oder einen Standort – und rollt dort das CAFM-System zuerst aus. Dort werden dann echte Daten eingegeben (oder migriert) und echte Prozesse mit dem System durchlaufen.

• Validierung der Funktionalität: Prüfen, ob die Software die FM-Prozesse wie gewünscht unterstützt und ob alle notwendigen Funktionen im Alltag praktikabel sind.

• Schnittstellen testen: Sind die Anbindungen an Fremdsysteme (ERP, Gebäudeleittechnik etc.) zuverlässig? Funktioniert der Datenaustausch glatt?

• Benutzerfeedback einholen: Wie kommen die echten Endanwender mit dem System zurecht? Gibt es Verständnisprobleme, fehlen vielleicht Schulungsinhalte, oder werden Workflows als unpraktisch empfunden? Dieses Feedback ist enorm wertvoll, um vor dem großen Roll-out noch Feinjustierungen vorzunehmen.

Für die Pilotierung definiert man im Vorfeld klare Erfolgskriterien. Beispiele: „Alle Wartungsaufträge des Pilotgebäudes können binnen eines Monats vollständig im System abgewickelt werden“ oder „Die Flächenauswertungen für Gebäude X stimmen nach Datenerfassung bis auf 5% genau mit den bisherigen Excel-Daten überein“. Solche Kriterien helfen später bei der Entscheidung, ob der Pilot erfolgreich war. Während der Pilotphase sollten regelmäßige Abstimmungsmeetings stattfinden – hier berichten die Anwender von Problemen oder Fragen, und das Projektteam beschließt ggf. Anpassungen (z. B. Konfiguration ändern, zusätzliche Schulung nachschieben, etc.).

Manche Verträge sehen eine Ausstiegsklausel nach der Pilotphase vor – d. h. wenn die Software die Erwartungen überhaupt nicht erfüllt, könnte man den Vertrag beenden. Das ist eine Art Absicherung, wird aber in der Praxis selten gezogen, da man ja schon viel investiert hat bis dahin. Nichtsdestotrotz: der Pilotabschlussbericht ist wichtig. Nach Ende der Pilotphase wertet man die Ergebnisse aus und entscheidet, ob man Go für den flächendeckenden Roll-out gibt oder ob zunächst Nachbesserungen erfolgen müssen.

Ein oft unterschätzter, aber essenzieller Bestandteil der Implementierung ist die Schulung der Anwender (4.4). Ein CAFM-System entfaltet seinen Nutzen nur, wenn die Anwender es sachgerecht bedienen können und wollen.

• Endanwender (Casual User): Das sind die Mitarbeitenden, die das System in ihrem Tagesgeschäft nutzen, aber nicht administrieren. Sie benötigen Schulungen im Umgang mit den Modulen, die für sie relevant sind (z. B. Flächenmanager lernen Flächenbuchungen und Reports, Instandhaltungsteams lernen Wartungsplanung und Rückmeldung etc.). Diese Schulungen sollten möglichst kurz vor dem echten Nutzungsbeginn stattfinden, damit das Gelernte frisch ist.

• Key-User: Das sind oft die Team- oder Abteilungsleiter bzw. besondere Power-User, die über tiefergehendes Wissen verfügen sollen. Sie werden intensiver geschult, sodass sie im Alltag als erste Ansprechpartner für andere Nutzer fungieren können. Häufig wird nach dem Prinzip „Train-the-Trainer“ gearbeitet: Die Key-User werden vom Anbieter sehr gut geschult und geben dann intern ihr Wissen an die Endanwender weiter – so können Schulungen in kleineren Gruppen und in vertrauter Umgebung erfolgen.

• Administratoren: Zwei Arten: Fach-Administratoren (aus dem Fachbereich FM, zuständig z. B. für Datenpflege, Systemkonfiguration, Berichtserstellung) und IT-Administratoren (zuständig für technische Themen wie Benutzerverwaltung, Datenbank, Updates, Backup). Beide Gruppen brauchen spezielle Schulungen, oft direkt vom Hersteller, in denen sie lernen, wie sie das System einstellen, Benutzerrechte managen, individuelle Abfragen/Reports erstellen, und wie Updates/Patches eingespielt werden.

Bei der Schulungsmethodik setzt man zunehmend auf einen Mix aus Präsenz und E-Learning. Für komplexe Themen und Key-User/Administratoren sind Präsenzschulungen oder Live-Webinare sinnvoll, weil man dort individuell Fragen klären kann. Für breite Endanwenderschulungen bieten sich auch Online-Methoden an: z. B. vorproduzierte kurze Tutorials (Shortcasts), interaktive Web-Trainings oder Videoanleitungen, damit Nutzer punktgenau das lernen können, was sie brauchen. Oft erstellt das Projektteam oder der Anbieter auch ein Benutzerhandbuch oder Quick-Reference-Guides als Nachschlagewerk.

Ein Tipp aus der Praxis: Schulungen möglichst mit echten, kundeneigenen Daten im System durchführen. Also idealerweise im Test- oder QS-System, das aber schon mit den firmenspezifischen Daten und Konfigurationen befüllt ist. So erkennen die Nutzer ihre Umgebung wieder (z. B. bekannte Gebäudenamen, echte Arbeitsaufträge) und können sich besser identifizieren. Gruppen von 5–10 Personen haben sich bewährt, um einen guten Betreuungsschlüssel zu haben. Und: dokumentierte Schulungsunterlagen sollten jedem Teilnehmer zur Verfügung gestellt werden, damit er nachlesen kann.

Während Software eingestellt und Menschen geschult werden, läuft parallel die Datenübernahme (4.5). Ohne Daten ist das beste System nutzlos, daher widmet sich diese Phase dem Aufbau der Datenbasis im neuen CAFM.

• Migration von Altdaten: Alles Digitale, was übernommen werden soll (z. B. Stammdaten aus dem alten CAFM, Excel-Listen von Anlagen, Zugangskontrolllisten, CAD-Zeichnungen) wird nun tatsächlich ins neue System importiert. Dafür nutzt man entweder Import-Werkzeuge des Herstellers oder programmiert spezifische Mappings/Skripte. Wichtig ist, vorher die Datenbereinigung abgeschlossen zu haben, damit man keine veralteten oder fehlerhaften Informationen importiert (Grundsatz: Garbage in, garbage out vermeiden).

• Neuerfassung fehlender Daten: Für Bereiche, wo Daten nur analog oder gar nicht vorhanden waren, erfolgt jetzt (oder bereits seit Phase 2) die Bestandsdatenerfassung. Das kann z. B. bedeuten: Techniker laufen Gebäude ab und inventarisieren Anlagen (vielleicht mit mobilen Erfassungsgeräten oder einer App, die direkt ans CAFM koppelt), Zeichner digitalisieren alte Papierpläne oder ein externes Büro führt ein Aufmaß durch. Hier muss eng getaktet werden, welche Daten bis wann erfasst sein müssen, um den Produktivstart nicht zu verzögern.

Ein zentraler Leitsatz in der Datenphase – erfasse nur die Daten, die du wirklich brauchst und später pflegen kannst. Jedes unnötig gesammelte Datum verursacht Kosten und Aufwand, besonders wenn es aktuell gehalten werden muss. Deshalb sollte das Projekt ggf. lieber mit einem begrenzten, aber sauberen Datenumfang starten, als mit einer Flut an halb-falschen Daten.

Die Praxis zeigt mittlerweile auch interessante Hilfsmittel für die Datenübernahme: Der Einsatz von KI (Künstlicher Intelligenz) kann helfen, z. B. große Dokumentenmengen auszuwerten (automatisches Auslesen von Verträgen und Extraktion relevanter Vertragsdaten ins System) oder BIM-Modelle hinsichtlich ihrer Datenkonsistenz zu prüfen (Model Checker mit Regeln, die z. B. sicherstellen, dass alle Räume in CAD eine Raumnummer und Fläche haben, bevor importiert wird). Solche Tools können erheblich Zeit sparen und die Qualität erhöhen.

Auch das Thema BIM (Building Information Modeling) darf genannt werden: Wenn ein BIM-Modell eines Gebäudes vorliegt, kann man daraus viele FM-Daten generieren (Raumbuch, Anlagenlisten etc.). Phase 4 beinhaltet also auch, zu entscheiden, wie man BIM-Daten ins CAFM übernimmt und wie die Weiterentwicklung der BIM-Modelle in der Betriebsphase gehandhabt wird (hierzu gibt es Fachliteratur, z. B. “BIM im Immobilienbetrieb”, die Konzepte beschreibt, wie BIM und CAFM zusammenwirken).

Ist die Software konfiguriert, geschult und die Daten migriert, kommt es zur Abnahme (4.6) des CAFM-Systems. Die Abnahme ist formal und praktisch ein entscheidender Meilenstein: Der Kunde bestätigt, dass die gelieferte Leistung den Anforderungen entspricht, und ab diesem Punkt gehen Verantwortung und ggf. Gewährleistungsfristen los.

• Es sollten im Voraus Meilensteine definiert sein, zu denen Teilabnahmen erfolgen. Beispielsweise könnte man nach der Pilotierung eine Teilabnahme machen (für das Pilotobjekt und Grundfunktionen) und nach dem Gesamtausbau die Endabnahme. Alle Beteiligten müssen genau wissen, welche Komponenten zu welchem Meilenstein fertig und abnahmebereit sein müssen.

• Abnahmekriterien und insbesondere Fehlerklassen sollten vereinbart werden. In IT-Projekten teilt man Fehler oft nach Schwere ein (z. B. Klasse 1: kritisch, System nicht nutzbar; Klasse 2: erheblich, aber Workaround möglich; Klasse 3: geringfügig/kosmetisch). Es muss klar sein, welche Fehler die Abnahme verhindern (meist Klasse 1 und 2) und welche zunächst toleriert werden können bis zum Fix (Klasse 3, oft im Rahmen der Gewährleistung zu beheben). Diese Definition sollte spätestens vor Beginn der Abnahmetests gemeinsam fixiert werden, falls nicht schon im Vertrag.

• Die Abnahme erfolgt durch Testen realer Anwendungsszenarien. Das Projektteam definiert also Testfälle, die typische Nutzeraktionen und Prozesse abbilden (z. B. „Erstelle einen neuen Wartungsplan und weise einem Techniker einen Auftrag zu; prüfe, ob der Techniker in seiner Aufgabenliste den Auftrag sieht und Status zurückmelden kann“ usw.). Diese Tests werden mit Echtdaten durchgeführt, denn nur so kann man sicher sein, dass das System in der Praxis funktioniert (z. B. Performance-Test mit einer realistischen Datenmenge, nicht nur mit 10 Datensätzen).

• Neben Funktions- und Prozestests sollten auch Last- und Performance-Tests berücksichtigt werden, gerade wenn viele Nutzer oder Massendaten im Spiel sind. Ein Beispiel: Import von 1000 Störmeldungen gleichzeitig – schafft das System das in vernünftiger Zeit? Oder: Wie reagiert die Anwendung, wenn 50 Benutzer gleichzeitig suchen oder Flächenpläne laden? Solche Belastungstests sind wichtig, um keine bösen Überraschungen im Realbetrieb zu erleben.

Ein spezielles Thema während der Implementierung (und als Teil der Abnahme-Checkliste) ist der IT-Grundschutz bzw. die Sicherheit des neuen Systems. Es ist ratsam, unter Einbeziehung der IT-Sicherheitsbeauftragten einen Sicherheitscheck nach BSI-Grundschutz oder ähnlichen Standards durchzuführen.

• Überprüfung, ob alle Sicherheitsziele erfüllt sind: Vertraulichkeit (wer darf was sehen?), Integrität (Daten sind vor unbemerkter Veränderung geschützt), Verfügbarkeit (Backup-Konzept, Ausfallsicherheit).

• Durchführung eines Penetrationstests (Pentest): Hierbei beauftragt man Sicherheitsexperten, kontrollierte Angriffe auf das System durchzuführen, um Schwachstellen zu entdecken. Gerade wenn das CAFM aus der Cloud erreichbar ist oder sensible Daten enthält, ist ein Pentest sehr sinnvoll. Dabei werden Sicherheitsmechanismen geprüft, gängige Angriffsmethoden simuliert und es wird ein Bericht erstellt, welche Lücken gefunden wurden. Ziel ist, diese Schwachstellen noch vor dem Produktivstart zu schließen, um gegen echte Cyberangriffe gewappnet zu sein.

Alle Ergebnisse der Tests – seien es Abnahmetests oder Sicherheitstests – müssen dokumentiert werden. Festgestellte Mängel sind aufzulisten und vom Anbieter beheben zu lassen. Nach Korrektur erfolgt ein Nachtest, um zu bestätigen, dass der Mangel behoben ist. Erst wenn alle wesentlichen Punkte erledigt sind (oder akzeptable Workarounds vereinbart wurden), erfolgt die formale Abnahmeerklärung. Diese kann in Teil- und Endabnahmen unterteilt sein, wie oben erwähnt.

Nach der Abnahme geht es ins Go-Live, also die tatsächliche Produktionssetzung des Systems. Oft empfiehlt es sich, schrittweise live zu gehen. Zum Beispiel könnte man nach der Pilotphase weitere Standorte nacheinander aufschalten statt alles auf einmal („gestaffeltes Go-Live“). Das hat den Vorteil, dass man eventuelle Startprobleme eingrenzen und beheben kann, bevor alle Anwender betroffen sind. Ähnlich kann man auch Module sukzessive aktivieren. Dieses Vorgehen minimiert das Risiko und wird besonders bei agilen Einführungen quasi automatisch gemacht (nach jedem Sprint etwas live nehmen). Natürlich muss die Abnahme das hergeben – d. h. wenn man in Teilabnahmen arbeitet, kann man Teilfunktionen schon frei- bzw. produktivgeben, während andere noch in Arbeit sind.

Nach der erfolgreichen Einführung beginnt Phase 5 – die längste Phase im Lebenszyklus: die Nutzung und der laufende Betrieb des CAFM-Systems. Ein CAFM-Projekt ist mit dem Go-Live nicht „fertig“, vielmehr startet nun ein fortlaufender Verbesserungsprozess. Das System muss im Alltag betrieben, gepflegt und an neue Anforderungen angepasst werden. Je nach Größe des Immobilienportfolios, der Komplexität der Organisation und dem technologischen Fortschritt ist die Nutzungsphase sehr dynamisch und kann sich über viele Jahre erstrecken. Wichtig ist eine vorausschauende Betriebsstrategie, um die Effizienz des Systems kontinuierlich zu steigern und den langfristigen Nutzen sicherzustellen. Man sollte sich also einen Plan machen, wie das System mitwächst – und diesen Plan regelmäßig (z. B. jährlich) überprüfen und aktualisieren.

Eine grundlegende Voraussetzung für den Erfolg in Phase 5 ist die konsequente Datenpflege (5.1). Der Wert eines CAFM-Systems steht und fällt mit der Aktualität, Vollständigkeit und Korrektheit der darin enthaltenen Informationen.

• Für die Stammdaten (Gebäude, Flächen, Anlagen etc.) bietet es sich an, eine verantwortliche Person oder Rolle zu benennen – häufig spricht man von einem Datenmanager im FM-Team. Dieser überwacht und koordiniert die Pflege der Bestandsdaten. Insbesondere bei Neu- oder Umbauprojekten muss der Datenmanager eng eingebunden sein, damit Änderungen (neue Räume, geänderte Anlagen, Sanierungen) zeitnah im CAFM nachgetragen werden. In großen Unternehmen kann es auch mehrere solche Verantwortliche geben (z. B. jeweils einen pro Standort). Wichtig ist: Änderungen im Gebäudebestand oder in technischen Anlagen dürfen nicht an der CAFM-Datenbank vorbei geschehen.

• Bewegungsdaten oder Prozessdaten (wie Meldungen, Wartungsaufträge, Buchungen) sollten idealerweise von den jeweiligen Prozessverantwortlichen selbst eingegeben und aktuell gehalten werden. Das CAFM-System muss als tägliches Arbeitswerkzeug etabliert sein – d.h. wenn etwa ein Techniker eine Wartung durchgeführt hat, gehört es zu seinem Job, dies im System zurückzumelden, oder wenn die Mietvertragsabteilung einen Vertrag ändert, wird das im CAFM aktualisiert. Diese Eigenverantwortung der Nutzer muss in Schulungen und durch Vorgesetzte unterstützt werden.

• Qualitätssicherung: Um sicherzustellen, dass die Datenqualität hoch bleibt, sind regelmäßige Kontrollen nötig. Dies kann durch Controlling-Instrumente im System geschehen (z. B. eingebaute Plausibilitätsprüfungen oder Berichte, die zeigen, welche Daten lückenhaft sind) oder durch manuelle Stichproben vor Ort. Einige CAFM-Programme bieten z. B. Model Checker für CAD/BIM-Daten oder Reporting-Dashboards, die dem Datenmanager anzeigen, wo Handlungsbedarf besteht (z. B. „5 Anlagen ohne Wartungszyklus hinterlegt“ oder „10 Räume ohne Nutzungszuordnung“). Im Zweifel kann man sich auch externer Audits bedienen, aber meist genügen interne Routinen.

• Bei internem Hosting (On-Premise) übernimmt das interne IT-Team viele Wartungsaufgaben: Installation von Updates/Patches, Überwachung der Serverperformance, Backup der Datenbank, etc. Man hat allerdings vermutlich einen Wartungsvertrag mit dem Hersteller, der einem Updates zur Verfügung stellt und bei Problemen hilft (Hotline, Fehlerbehebung).

• Bei Cloud-/SaaS-Betrieb erledigt der Anbieter den Großteil der technischen Wartung. Dennoch muss man als Kunde sicherstellen, dass Service-Levels eingehalten werden, dass man rechtzeitig über Updates informiert wird und dass Datensicherungen laufen.

• Support/Hotline: Zugriff auf den Hersteller-Support für Fragen oder Störungsmeldungen. Meist Montag–Freitag zu Bürozeiten, je nach Vertrag evtl. auch 24/7 für kritische Fälle.

• Patches & Updates: Regelmäßiges Einspielen von Fehlerbehebungen und kleineren Versionsupdates, um Sicherheitslücken zu schließen, neue Betriebssysteme zu unterstützen, Performance zu verbessern etc. Bei SaaS geschieht das oft automatisch, bei On-Premise muss das IT-Team planen, wann welche Version installiert wird (nach Tests im Testsystem idealerweise).

• Upgrades: Größere Versionssprünge mit neuen Funktionen – hier ist besonders zu prüfen, ob das eigene Customizing noch funktioniert und ob Schulungsbedarf wegen neuer Features besteht.

• Datensicherheit & Backups: Der Betrieb muss gewährleisten, dass die Daten geschützt sind vor Verlust (Backup-Strategie, z. B. tägliche Sicherungen mit offsite Lagerung) und vor unbefugtem Zugriff (Zugriffskonzepte, ggf. Verschlüsselung). Diese Punkte sollten im Wartungskonzept festgehalten sein und auch vertraglich mit dem Anbieter (falls extern) geregelt.

Softwareanbieter bieten oft Standard-Wartungsverträge an, die diese Leistungen zusammenfassen. Das interne Team (IT und Rechtsabteilung) sollte solche Verträge prüfen. Bei SaaS sind Wartungskosten meist im Abo-Preis drin, aber SLA-Niveaus können variieren.

• Wer macht 1st-Level-Support für die Endanwender? (Oft die Key-User: Einfache Fragen beantworten, ggf. entscheiden ob ein Problem zur IT oder zum Anbieter eskaliert wird.)

• Wer ist 2nd-Level-Support? (Das wäre z. B. die interne IT oder CAFM-Fachadministration, die tiefer in Einstellungen schauen kann.)

• Wie läuft die Zusammenarbeit mit dem Anbieter bei Problemen? (Der Anbieter stellt den 3rd-Level-Support, d.h. bei echten Softwareproblemen oder Bugs meldet die interne IT das an die Hersteller-Hotline.)

• Wie werden Fehler oder Änderungswünsche gemeldet, dokumentiert und priorisiert? Hierfür sollte es idealerweise ein Tool oder zumindest einen definierten Prozess geben – z. B. Benutzer meldet an Key-User, der gibt es in ein Ticketsystem ein, CAFM-Admin priorisiert und löst es oder leitet es weiter. Ohne klare Schnittstellen und Meldewege geht viel unter oder doppelt gemoppelt ein.

• Rollenklärung: Der IT-Administrator ist z. B. fürs Backup und technische Verfügbarkeit zuständig, der Fach-Administrator pflegt die Kataloge, Rechte und eventuell kleinere Anpassungen. Key-User sammeln Wünsche aus ihren Abteilungen. Das muss intern kommuniziert sein, wer wofür zuständig ist.

• Updates/Patches einspielen: Muss mit dem laufenden Betrieb abgestimmt werden – wer entscheidet, wann ein größeres Update eingespielt wird? Gibt es dafür ein regelmäßiges Wartungsfenster? Wird vorher mit Fachbereichen abgestimmt? Solche Vorgehensweisen gehören auch ins Betriebskonzept.

Gerade bei Cloud-Lösungen ist die Organisation etwas anders, da vieles outgesourct ist. Dennoch braucht man interne Verantwortlichkeiten, vor allem für Benutzerverwaltung, Anforderungsmanagement (was machen wir mit neuen Feature-Wünschen?), Vertrags- und Lizenzverwaltung (wer checkt, ob die Nutzerlizenzen noch ausreichen, wer bestellt neue Module bei Bedarf?). Oft bieten Cloud-Anbieter flexible Pay-per-Use Modelle, bei denen man z. B. monatlich Lizenzen hoch- oder runterstufen kann – hier muss jemand die Nutzung beobachten und optimieren, damit man nicht unnötig zahlt bzw. genügend Lizenzen hat.

• Geplante Meilensteine umsetzen: In Phase 2 wurde vermutlich ein IT-Strategie-Plan mit Meilensteinen erstellt (z. B. „2025: CAFM Basis einführen, 2026: Energiemanagement-Modul integrieren, 2027: IoT-Sensorik anbinden“ usw.). Diese Meilensteine sind jetzt Schritt für Schritt zu realisieren. Dabei sollte man darauf achten, dass man den Nutzern nicht zu viel auf einmal zumutet – neue Module also sukzessive ausrollen und die Leute jeweils drauf vorbereiten.

• Neue Technologien nutzen: Die Welt dreht sich weiter – es kommen ständig neue Möglichkeiten auf den Markt (KI, RPA – Robotic Process Automation, Augmented Reality etc.). FM-Organisationen prüfen fortlaufend, wie solche Technologien ihre Arbeit verbessern können. Beispiel: Einsatz von KI-Chatbots im Helpdesk oder RPA-Skripte für automatische Rechnungsverarbeitung. Wenn solche Technologien eingeführt werden sollen, ist meist auch eine Integration ins CAFM nötig (denn dort liegen die Daten).

• Konsolidierung der IT-Landschaft: Man entdeckt eventuell Synergien, indem man bisher separate Tools ablöst und in die CAFM-Welt integriert. Z. B. könnte man ein eigenständiges grafisches Reservierungstool ablösen und stattdessen die Reservierungsfunktion des CAFM nutzen, um nur noch eine Plattform zu haben. Oder man koppelt die Gebäudeleittechnik enger ans CAFM, sodass Alarme aus der GLT automatisch Tickets im CAFM erzeugen (und evtl. das separate Störmeldesystem ersetzt wird). Der Trend geht dahin, Schnittstellen zu nutzen oder Systeme zusammenzuführen, um Doppellösungen zu vermeiden und Dateninseln aufzulösen.

• Erweiterung der Datenbasis: Gerade große Unternehmen fangen oft mit einem Teilportfolio an. In Phase 5 wird dann nach und nach das CAFM auf weitere Liegenschaften ausgedehnt. Jedes neue Gebäude bedeutet Datenaufnahme (oder BIM-Daten übernehmen) und Anpassung der Kapazitäten. Ziel ist irgendwann ein vollständiges, aktuelles Portfolio in der Datenbank, sodass man standortübergreifende Auswertungen fahren kann.

• Digitalisierung weiterer Dokumente: Über die Grunddaten hinaus kann man den Umfang der im CAFM vorgehaltenen Informationen erweitern. Beispielsweise könnte man beschließen, auch historische Bauunterlagen, Genehmigungen, Verträge etc. alle digital im System (oder angebundenen DMS) zu verwalten, um den Zugriff zu erleichtern.

• Organisatorische Änderungen: Das Unternehmen entwickelt sich, und damit ändern sich Anforderungen ans CAFM. Neue Abteilungen, geänderte Verantwortlichkeiten – da muss das Rollen- und Rechtekonzept im CAFM nachgezogen werden. Oder man outsourct einen Teil des FM an einen Dienstleister: Dann muss man ggf. dem Dienstleister begrenzten Zugriff aufs CAFM geben oder Schnittstellen zwischen dessen System und dem eigenen schaffen. Beispiel: Ein FM-Dienstleister hat ein eigenes CAFM, das mit dem des Auftraggebers Daten austauschen soll – hier sind Lösungen gefragt, wie Datenstrukturen kompatibel gemacht werden und ob nach Dienstleisterwechsel (der nach ein paar Jahren vorkommt) Anpassungen nötig werden.

Phase 5 ist geprägt von kontinuierlicher Verbesserung. Das CAFM-Team muss im Unternehmen verankert bleiben, um den Betrieb zu organisieren, neue Anforderungen aufzunehmen und umzusetzen. Regelmäßige Strategiemeetings oder jährliche Review-Workshops können helfen, sich zu vergegenwärtigen, ob das System noch optimal genutzt wird oder ob Funktionen brachliegen, die aktiviert werden könnten. Auch Nutzerfeedback-Schleifen (z. B. Zufriedenheitsumfragen bei den Anwendern) können Impulse für Weiterentwicklungen geben.

Von Zeit zu Zeit – oft nach einigen Jahren – stellt sich die Frage, ob das System noch zeitgemäß ist oder ob eine Erneuerung/Ablösung notwendig wird. Damit wären wir schon bei Phase 6, die allerdings manchmal auch aus Phase 5 erwächst (Expansion kann bis zu einem gewissen Punkt gehen, dann steht ggf. ein Technologiewechsel an).

Die Phase 6 behandelt den Austausch eines bestehenden CAFM-Systems durch ein neues – sei es, weil die alte Lösung technisch überholt ist, den Anforderungen nicht mehr genügt oder andere äußere Gründe vorliegen. Ein solcher Schritt kommt z. B. in Betracht, wenn die bisher eingesetzte Software veraltet und vom Hersteller nicht mehr angemessen unterstützt wird, oder wenn der Softwareanbieter vom Markt verschwindet bzw. das Produkt einstellt. Auch grundlegende strategische Entscheidungen können eine Ablösung auslösen (z. B. Umstieg von On-Premise auf Cloud, was die bisherige Software nicht leisten kann, oder Konsolidierung mehrerer Systeme nach einer Firmenübernahme).

Wir müssen unser CAFM-System ersetzen. Das Vorgehen, das dann folgt, ähnelt in weiten Teilen einer Neu-Einführung (Phasen 1–5). Tatsächlich lässt sich ein Ablöseprojekt fast wie ein neues CAFM-Projekt aufsetzen: Man durchläuft wieder die Konzeptionsphase (Ziele definieren – hier natürlich mit Fokus auf Mängel des alten Systems beheben), die Anforderungsphase (ggf. hat sich im Unternehmen viel geändert, man nutzt die Chance für Prozessoptimierungen), Ausschreibung & Vergabe für eine neue Software, Implementierung und Nutzung. Der Hauptunterschied liegt in der Datenmigration vom Altsystem. Während bei einer Ersteinführung oft viel manuelle Datenerfassung nötig war, hat man nun ja bereits umfangreiche Daten digital in der alten Datenbank – und diese gilt es möglichst verlustfrei ins neue System zu übertragen.

Zu Beginn muss der Bedarf und die Ziele der Ablösung geklärt werden. Das Management sollte deutlich formulieren, warum abgelöst wird und was das neue System besser können muss. Dies umfasst auch eine Wirtschaftlichkeitsprüfung – eine Ablösung ist mitunter genauso aufwändig wie eine Neueinführung und muss gut begründet sein (z. B. Risiko durch veraltete Technik, keine Herstellerunterstützung mehr, Ineffizienzen im Betrieb, Nutzerakzeptanzprobleme etc.). Wenn diese Entscheidung getroffen ist, startet man das Projekt offiziell (Projektauftrag für Ablöseprojekt, analog Phase 1).

Man orientiert sich an Phase 1–2: Stakeholder benennen (oft sind es ähnliche Leute wie beim ersten Mal, plus Erfahrungen die man gesammelt hat), neues Konzept erstellen, Anforderungen schreiben. Allerdings kann man vieles wiederverwenden oder fortschreiben: Das bestehende Lastenheft des alten Systems kann als Grundlage dienen – man weiß nun genauer, welche Funktionen tatsächlich genutzt wurden, wo Lücken waren und was man beim neuen System verbessern möchte. Es lohnt sich, im Team eine Retrospektive zu machen: Was hat uns am alten System gefehlt? Was hätten wir damals anders gemacht? Daraus leitet man die Anforderungen für die neue Lösung ab.

Welche historischen Daten übernehmen wir? – Hier muss sorgfältig abgewogen werden. Nicht alle im alten System gespeicherten Daten sind relevant für die Zukunft. Manche Alt-Daten können veraltet sein (z. B. ein Wartungsauftrag von vor 10 Jahren – braucht man den noch? Vielleicht nur statistisch.). Andere Daten müssen aus rechtlichen Gründen aufgehoben werden (z. B. Prüfnachweise, die 5–10 Jahre archiviert sein müssen). Das Team sollte entscheiden, ob man das alte System eventuell teilweise im Lesemodus weiterlaufen lässt oder Daten exportiert und archiviert (z. B. als Excel oder PDF), anstatt alles ins neue System zu migrieren. Denn jeder zu migrierende Datensatz verursacht Aufwand (Mapping, Prüfung). Oft entscheidet man: Stammdaten und aktuelle Bewegungsdaten übernehmen, aber abgeschlossene Vorgänge älter als X Jahre nur noch ins Archiv, nicht ins neue System.

Für die technische Datenmigration sollte man vom neuen Anbieter ein Migrationskonzept einfordern (ähnlich wie in Phase 2/3 beschrieben). Der neue Anbieter kennt aber das alte System nicht im Detail, daher ist es oft nötig, dass man aus dem alten System jemand mit Expertise hinzuzieht (sei es intern oder der alte Softwarelieferant, falls verfügbar). Gemeinsam wird dann festgelegt, wie die Daten rüberkommen.

• Direkte Datenbankmigration: Wenn man Zugriff auf die Datenbank des alten Systems hat, könnte man per Skripte/ETL-Tools die Daten direkt in die neue DB überführen. Das erfordert Mapping zwischen Datenmodellen und ist technisch komplex.

• Exports und Imports: Einfacher ist oft, aus dem alten System Daten in standardisierten Formaten zu exportieren (CSV, Excel, XML, IFC für Gebäudedaten, etc.) und diese Exporte dann ins neue System zu importieren. Das neue System braucht dafür Import-Routinen. Das erfordert auch Mapping und Datenaufbereitung, geht aber über definierte Schnittstellen und ist reproduzierbar.

• Manuelle Übernahme: In manchen Fällen entscheidet man, bestimmte Daten bewusst nicht automatisiert zu migrieren, sondern neu zu erfassen oder manuell zu übernehmen. Beispiel: Nutzerstammdaten oder Berechtigungen – evtl. ist es schneller/sauberer, im neuen System die 50 User neu anzulegen, anstatt eine fehlerträchtige Migration zu skripten.

Auch hier muss der Auftraggeber Personal- und Zeitaufwand einkalkulieren. Die Plausibilisierung und Bereinigung der Alt-Daten obliegt häufig dem internen Team. Man muss z. B. vor Migration alle Räume im Altsystem nochmal checken (Stimmen die Nummern? Gibt es Dubletten? usw.), denn sonst importiert man Altfehler ins neue System. Diese Arbeiten können sehr umfangreich sein und müssen im Projektplan realistisch eingeplant werden. Es bringt nichts, einen ambitionierten Go-Live-Termin zu setzen, wenn die Datenmigration bis dahin unmöglich fertig wird.

• Parallelbetrieb: Altes und neues System laufen eine Zeitlang nebeneinander. Beispielsweise migriert man Standort für Standort ins neue System. Während Standort A schon im neuen arbeitet, nutzen Standort B und C noch das alte. Oder man lässt für eine definierte Übergangszeit alle Daten ins neue System einfließen, pflegt sie aber sicherheitshalber auch noch im alten, bis man sicher ist, dass das neue stabil läuft – dann schaltet man alt ab. Parallelbetrieb erhöht natürlich temporär den Aufwand (Doppelpflege von Daten, zwei Systeme administrieren) und verursacht Kosten, ist aber risikoärmer, weil bei Problemen im neuen System das alte noch als Backup vorhanden ist.

• Sofortumstieg (Cut-Over): Zu einem Stichtag X wird das alte System abgeschaltet (bzw. auf Read-Only gesetzt für Archivzwecke) und ab dann ausschließlich das neue System verwendet. Das setzt voraus, dass bis zum Stichtag alle benötigten Daten migriert sind und alle Nutzer umgeschult sind. Der Vorteil: keine Doppelarbeit, klarer Schnitt. Der Nachteil: es gibt kein Netz und doppelten Boden – wenn das neue System anfangs hakt, hat man direkt Auswirkungen auf die Prozesse.

Welche Methode gewählt wird, hängt von der Unternehmenssituation ab. Bei sehr großen Organisationen mit verteilten Teams ist häufig ein schrittweiser Umstieg zu beobachten. Bei kleineren kann man eher einen harten Cut planen, z. B. zum Jahreswechsel.

In jedem Fall sollte man Kommunikation und Change Management nicht vergessen: Die Nutzer haben sich über Jahre ans alte System gewöhnt (selbst wenn sie darüber geschimpft haben mögen). Jetzt kommt etwas Neues – das bedeutet erneut Schulungen, Umgewöhnung und vielleicht auch Verlust liebgewonnener Workarounds. Hier ist ähnlich wie bei der Ersteinführung ein sensibler Umgang nötig: Warum wechseln wir? Was wird besser? Wie unterstützen wir euch dabei (Trainings, Migrationshilfe)? Idealerweise zieht man Lehren aus der ersten Einführung: was hat damals gut funktioniert in der Change-Begleitung, was nicht?

Nach erfolgreicher Ablösung läuft dann das neue System in Phase 5 weiter. Phase 6 ist also sozusagen eine Wiederholung des gesamten Zyklus für ein Folgeprojekt. Manche Unternehmen sprechen hier von Release 2 oder einer Neuimplementierung. Wichtig ist die Erkenntnis: Ein CAFM-System hat einen Lebenszyklus, und Phase 6 leitet wieder Phase 1 eines neuen Zyklus ein – es ist ein stetiger Prozess im Rahmen der Digitalisierung im FM.