CAFM: Beschaffung, Lizenz- und Vertragsmanagement

Bei CAFM-Software gibt es verschiedene Lizenzmodelle, die erhebliche Auswirkungen auf die Kosten und Nutzung haben. Grundsätzlich unterscheidet man Kauflizenzen (Perpetual License) von Miet- bzw. Abonnement-Lizenzen (Subscription). Bei der Kauflizenz erwirbt der Kunde ein unbefristetes Nutzungsrecht gegen einen Einmalbetrag; bei Subscription wird die Software nur für die Vertragsdauer überlassen (oft gegen jährliche oder monatliche Gebühren).

• Named-User-Lizenzierung: Hier erhält jeder namentlich benannte Nutzer eine eigene Lizenz. Nur diese Person darf mit der Software arbeiten – gleichzeitig dürfen beliebig viele der lizenzierten Personen aktiv sein, denn relevant ist die Anzahl individueller Berechtigungen, nicht der parallelen Zugriffe. Dieses Modell bietet sich an, wenn relativ wenige Nutzer sehr regelmäßig mit dem System arbeiten oder aus Compliance-Gründen personalisierte Zugänge benötigt werden. Allerdings bezahlt man auch für inaktive Nutzer: Ein selten aktiver Mitarbeiter blockiert dennoch eine voll bezahlte Lizenz. Das kann zu Ineffizienzen führen, wenn viele Accounts nur sporadisch genutzt werden.

• Concurrent-User-Lizenzierung: Hier wird die Lizenz nicht personengebunden vergeben, sondern begrenzt die maximale Anzahl gleichzeitiger Zugriffe. Es können mehr Personen einen Login erhalten, als Lizenzen vorhanden sind – aber es dürfen nie mehr als z. B. 20 Nutzer gleichzeitig im System arbeiten, wenn 20 Concurrent-Lizenzen erworben wurden. Dieses Modell (auch Floating License genannt) ist effizient, wenn erfahrungsgemäß nie alle berechtigten Nutzer zur gleichen Zeit aktiv sind (typischer Fall: viele Gelegenheitsnutzer). Beispielsweise können in Schichtbetrieben oder großen Organisationen mit gelegentlichen Nutzern Concurrent-Lizenzen Kosten sparen, da man Überlizenzierung vermeidet. Zu beachten ist jedoch, dass Concurrent-Lizenzen vom Hersteller oft teurer verkauft werden – eine Concurrent-Lizenz kann preislich etwa 1,5 Named-Lizenzen entsprechen, da sie ja potentiell von mehreren Personen genutzt wird. Die wirtschaftliche Bewertung sollte also prüfen, ab welcher Nutzeranzahl welches Modell günstiger ist. Oft wird auch eine Kombination aus beiden Modellen gewählt, z. B. Kombilizenzen: Kernanwender mit Named User Lizenzen, während für einen größeren Kreis seltener Nutzer ein Pool an Concurrent-Lizenzen bereitsteht. So lassen sich Kosten optimieren. Wichtig ist, vertraglich klar festzulegen, welches Lizenzmodell gilt und wie die Nutzer gezählt werden. Bei Concurrent-Modellen muss z. B. technisch ein Lizenzzähler vorhanden sein, und der Vertrag sollte regeln, was passiert, wenn das Limit überschritten wird (Sperre vs. automatische Nachlizenzierung). Bei Named User sollte festgelegt sein, ob und wie Lizenzen auf andere Personen übertragbar sind, etwa wenn Mitarbeiter das Unternehmen verlassen. Best Practice ist hier, im Vertrag ausdrücklich Umlizenzierungen zu erlauben (üblicherweise darf eine Named License neu vergeben werden, wenn ein Nutzer ausscheidet), um bei Personalwechsel keine neuen Lizenzen kaufen zu müssen.

• Neben der Nutzerbasierung spielen Lizenzmetriken wie Modulumfang (Lizenzen pro Modul/Funktionsbereich) und evtl. Mandanten oder Standorte eine Rolle – CAFM-Systeme sind oft modular aufgebaut, sodass man z. B. bestimmte Module getrennt lizenzieren kann. Im Lizenzangebot sollte daher transparent aufgezeigt werden, welche Module inbegriffen sind und wie zusätzliche Module berechnet würden.

• Für die betriebswirtschaftliche Bewertung der Lizenzmodelle ist ein Total Cost of Ownership (TCO) Vergleich sinnvoll. Bei Kauflizenzen (On-Premises-Modell) fällt anfangs ein hoher Investitionsaufwand (CapEx) für die Lizenz an. Zusätzlich wird meist ein jährlicher Wartungsgebühr fällig (typisch 15–25% des Lizenzpreises) für Updates und Support. Vorteil: Nach einigen Jahren Nutzung hat sich der Kauf amortisiert; es entstehen dann nur noch relativ geringe laufende Kosten (Wartung). Langfristig ist das Kostenniveau somit oft niedriger – sofern die Software sehr lange genutzt wird und technologisch nicht vorzeitig veraltet. Ein Richtwert: Beträgt die jährliche Abo-Gebühr etwa 25% des Kaufpreises, so ist ab ~4 Jahren Nutzung die Kauflizenz finanziell vorteilhafter; in den ersten Jahren hingegen das Abo. Allerdings bindet ein Kauf Kapital und birgt das Risiko, dass die Lösung eventuell nicht im erwarteten Umfang genutzt wird oder Anforderungen sich ändern (Shelfware-Risiko). Auch muss der Kunde selbst für den Betrieb (Server, Updates installieren etc.) sorgen, wenn es keine SaaS-Lösung ist.

• Beim Miet- oder Subscription-Modell verteilt sich die Investition auf laufende Betriebskosten (OpEx). Die jährlichen Gebühren beinhalten oft bereits Wartung, Support und bei Cloud-Lösungen auch Hosting. Wirtschaftlich hat dies den Vorteil geringerer Einstiegskosten und höherer Flexibilität: Bei Wachstum lassen sich weitere Nutzerlizenzen meist einfach hinzubuchen, und umgekehrt kann man bei schrumpfendem Bedarf unter bestimmten Bedingungen Lizenzen reduzieren – je nach Vertragsgestaltung und Kündigungsfristen. Außerdem muss der Kunde die IT-Infrastruktur nicht unbedingt selbst stellen (bei SaaS übernimmt das der Anbieter). Nachteilig ist, dass über viele Jahre gesehen die kumulierten Mietzahlungen den Kaufpreis deutlich übersteigen können. Der Break-Even-Punkt hängt vom Verhältnis Kaufpreis zu Mietrate ab; im genannten Beispiel von 25% p.a. ist nach 4 Jahren das Mietmodell teurer. Darüber hinaus erwirbt der Kunde bei Subscription kein dauerhaftes Nutzungsrecht an der Software – endet der Vertrag, erlischt die Nutzungslizenz. Beim Kauf hingegen bleibt ein unbefristetes Nutzungsrecht bestehen (ggf. ohne weitere Updates, falls kein Wartungsvertrag mehr besteht). Dieser Aspekt kann strategisch relevant sein: Mit einer Kauflizenz hat man mehr Kontrolle und könnte theoretisch die Software auch ohne Hersteller weiterbetreiben (z. B. eingefroren auf dem letzten Stand), während man sich beim reinen SaaS-Modell auf die dauerhafte Leistungserbringung des Anbieters verlassen muss.

• In der Praxis sollte der Lizenztyp zur Organisationsstrategie und Finanzplanung passen. Öffentliche Auftraggeber tendieren aus Budgetgründen manchmal zu Kauf + Wartung (Investition statt laufender Kosten, um etwaiges Budget nur einmal zu belasten), während privatwirtschaftliche Firmen häufig Subscription bevorzugen, um flexibel zu bleiben und IT-Aufwand auszulagern. Eine wirtschaftliche Bewertungsmatrix (über 5–10 Jahre TCO) hilft, das finanziell optimale Modell zu ermitteln. Darüber hinaus können auch steuerliche Überlegungen eine Rolle spielen (Kauf wird aktiviert und abgeschrieben, Miete direkt als Aufwand gebucht).

Ist die Anbieterentscheidung gefallen, folgt die detaillierte Vertragsverhandlung und -gestaltung. Dabei müssen sowohl Leistungsumfang als auch rechtliche und kommerzielle Bedingungen klar geregelt werden. Im Zentrum steht eine Leistungsbeschreibung, die genau definiert, welche Softwaremodule und Dienstleistungen der Anbieter zu erbringen hat. Hier kann direkt auf das Lastenheft Bezug genommen werden: Alle Muss-Anforderungen sollten sich im Vertrag als geschuldete Leistung wiederfinden. Beispielsweise ist festzuhalten, welche Module geliefert werden (Raum- und Gebäudemanagement, Wartungsplanung, Vertragsverwaltung, etc.), welche Schnittstellen bereitzustellen sind und ob ggf. Hardware oder Cloud-Services inkludiert sind. Viele Auftraggeber verlangen explizit, dass die Software bestimmte Standards erfüllt, etwa GEFMA-444 zertifiziert ist, um einen definierten Funktionsumfang sicherzustellen.

Wird das System On-Premises beim Kunden installiert oder als Software-as-a-Service (SaaS) durch den Anbieter bereitgestellt? Bei SaaS gehören Regelungen zur Verfügbarkeit der Cloud-Dienste (Rechenzentrumsstandort – idealerweise in der EU wegen DSGVO –, Datensicherheit, Backup) und zur Verantwortung des Anbieters für Betrieb, Updates und Wartung in den Vertrag. Bei On-Premises-Betrieb ist festzulegen, welche Mitwirkung der Hersteller bei Installation und Updates leistet und welche Pflichten der Kunde selbst übernimmt (z. B. Stellung der Serverhardware, Einspielen von Patches). In beiden Fällen sind klare Service Level Agreements (SLAs) zentral: Der Vertrag sollte messbare Kennzahlen zur Systemverfügbarkeit (z. B. 99% Uptime im Monatsmittel, definierte Wartungsfenster) und zu Reaktions- und Wiederherstellungszeiten bei Störungen festschreiben. Beispielsweise kann vereinbart werden, dass bei kritischen Systemausfällen binnen 1 Stunde reagiert und binnen 4 Stunden eine Lösung bereitgestellt wird. Solche SLAs sind wichtig, weil Ausfälle der CAFM-Software direkt das Facility Management beeinträchtigen könnten (etwa wenn Wartungsfristen verpasst werden, weil das System nicht verfügbar ist). Üblich ist auch, finanzielle Konsequenzen bei SLA-Verletzungen festzulegen (z. B. Servicegutschriften oder Vertragsstrafen bei Unterschreitung zugesicherter Verfügbarkeiten).

Weiterhin umfasst der Vertrag Regelungen zu Support und Schulung. Hier wird beschrieben, welchen Support der Hersteller liefert (z. B. erreichbarer Helpdesk zu bestimmten Zeiten, evt. 24/7 für kritische Nutzer). Ebenso sollte initiale Trainingmaßnahmen vereinbart werden – etwa Admin-Schulungen, Key-User-Workshops oder Bereitstellung von Schulungsunterlagen für Endanwender. Gerade bei komplexen Systemen ist die Einbindung eines ausreichenden Trainings essentiell für den Erfolg.

Da Software-Systeme einem Wandel unterliegen, sollte ein Verfahren für Weiterentwicklung und Änderungen im Vertrag verankert sein. Oft wird ein Change-Request-Prozess definiert: Wenn der Kunde neue Anforderungen hat oder Erweiterungen wünscht, wie wird das umgesetzt? Üblich ist, dass zusätzliche Leistungen nach Aufwand zu vorher definierten Tagessätzen entwickelt werden, oder dass der Hersteller regelmäßige Releases mit neuen Funktionen liefert, die im Wartungsvertrag inklusive sind. Hier gilt es festzulegen, was im Wartungs-/Update-Service enthalten ist (z. B. Updates auf neue Versionen, gesetzliche Anpassungen) und was als Mehrleistung separat beauftragt werden muss (z. B. individuelle Reports, Schnittstellen zu neuen Systemen). Auch die Pflicht zur Mängelbehebung (Bugfixing) innerhalb bestimmter Fristen gehört in diesen Kontext. Für größere Softwareprojekte ist es ratsam, Abnahmeprozesse zu definieren – d.h. wie wird festgestellt, ob die gelieferten Leistungen den Anforderungen entsprechen, und wie sind Nachbesserungen geregelt.

Ein weiterer wichtiger Vertragsbaustein ist das Thema Schnittstellen und Integration. Oft muss das CAFM-System an andere Systeme angebunden werden (z. B. an eine Gebäudeleittechnik, an IoT-Sensoren oder an ein ERP-System zur Kostenbuchung). Der Vertrag sollte Verantwortlichkeiten klären: Liefert der CAFM-Anbieter die Schnittstelle „bis zum anderen System“ oder nur bis zu einem definierten Übergabepunkt? Wer übernimmt die Abstimmung mit Drittanbietern? Im Vertragstext kann z. B. stehen, dass der Anbieter für die Einhaltung eines bestimmten Datenformats sorgt, während der Kunde oder ein Drittanbieter die Gegenseite der Integration verantwortet. So werden spätere Haftungsfragen (etwa wer Schuld ist, wenn ein Datenaustausch fehlschlägt) bereits im Vorfeld geklärt.

Lizenz- und Nutzungsrechte müssen vertraglich eindeutig geregelt sein. Der Kunde sollte das Recht erhalten, die CAFM-Software in dem vereinbarten Umfang zu nutzen – zeitlich unbegrenzt bei Kauflizenzen oder für die Dauer des Vertrags bei Mietmodellen. Wichtig ist auch die Frage, wem Entwicklungen gehören: Bei Standardsoftware erwirbt man in der Regel Nutzungsrechte, kein Eigentum am Quellcode. Falls im Projekt Individualanpassungen oder neue Module erstellt werden, sollte festgeschrieben sein, dass der Kunde zumindest ein Nutzungsrecht an allen erstellten Anpassungen und Daten erhält. Üblich ist z. B., dass kundenspezifische Erweiterungen zwar dem Hersteller gehören, der Kunde aber dauerhaft daran lizenziert wird (damit er sie weiter verwenden kann, auch wenn der Vertrag endet). Dadurch wird ausgeschlossen, dass der Kunde von seinem eigenen Datenbestand oder spezifischen Customizations ausgeschlossen wird.

Ein entscheidender Punkt – oft in eigenen Exit-Klauseln geregelt – ist die Beendigung des Vertrags und damit verbundene Datenübergabe. Der Vertrag sollte eine Pflicht des Anbieters festschreiben, bei Vertragsende alle FM-Daten aus dem CAFM-System in einem gängigen Format an den Auftraggeber zu übergeben. Damit wird sichergestellt, dass ein Wechsel des Anbieters oder ein Übergang zum Eigenbetrieb reibungslos möglich ist. Gerade in mehrjährigen Verträgen muss verhindert werden, dass der Kunde am Ende „vom eigenen System abgeschnitten“ ist oder enorme Migrationskosten tragen muss, um seine Daten zu retten. Eine Exit-Vereinbarung kann z. B. beinhalten, dass der Anbieter bei Kündigung eine Datenbank-Dump liefert, Unterstützung bei der Datenmigration leistet (gegen definiertes Entgelt) und alle Kundendaten löscht bzw. nachweislich unzugänglich macht, um Datenschutz und Geheimhaltung zu gewährleisten. Apropos Datenschutz: Insbesondere wenn der Anbieter die Software als Cloud-Service stellt, ist er als Auftragsverarbeiter im Sinne der DSGVO tätig. Daher sollte dem Vertrag ein AV-Vertrag (Auftragsverarbeitungsvertrag) beigefügt sein oder entsprechende Klauseln integriert werden. Darin werden u. a. Vertraulichkeit, Datenlöschung nach Vertragsende, Einsatz von Unterauftragsnehmern (z. B. Rechenzentrum) und Sicherheitsmaßnahmen festgeschrieben. Generell gehören Geheimhaltungsvereinbarungen in jeden solchen Vertrag – der Anbieter muss garantieren, sensible Gebäude- und Firmendaten vertraulich zu behandeln und seine Mitarbeiter darauf zu verpflichten.

Weitere vertragliche Punkte umfassen Haftungsregelungen (z. B. Haftungshöchstgrenzen des Anbieters bei Datenverlust, oft begrenzt auf eine Summe X oder auf Vorsatz/Grobfahrlässigkeit), Gewährleistung bei Softwaremängeln (bei Kauflizenz in Deutschland z. B. 2 Jahre gesetzliche Gewährleistung auf Sachmängel, wobei Softwareverträge oft als Kauf oder Mietvertrag rechtlich einzuordnen sind), Vertragslaufzeit und Kündigungsfristen (üblich sind Mindestlaufzeiten von mehreren Jahren bei SaaS-Verträgen, mit Verlängerungsklauseln; bei unbefristeten Verträgen sollte ein Kündigungsrecht definiert sein). In öffentlichen Projekten kommen oft Musterverträge wie die EVB-IT zum Einsatz, die viele dieser Regelungen bereits enthalten – auch private Unternehmen können sich daran orientieren, um Vollständigkeit sicherzustellen.

Zum Beispiel das Recht des Kunden, zusätzliche Nutzer oder Module zu definierten Konditionen hinzuzukaufen, ohne dass ein neuer Vertrag erforderlich wird. Solche Optionen (etwa „weitere Named User können bis Vertragsende zum Angebotspreis X pro Stück erworben werden“) schaffen Klarheit und Flexibilität für späteres Wachstum. Insgesamt gilt: Ein gut gestalteter Vertrag bildet das Rückgrat für eine langfristig erfolgreiche Zusammenarbeit mit dem CAFM-Anbieter. Er sollte deshalb mit Sorgfalt und gegebenenfalls juristischem Beistand erstellt werden.

Bei der Beschaffung und Implementierung von CAFM-Software treten erfahrungsgemäß einige Herausforderungen auf.

• Unklare Anforderungen und Scope Creep: Ein häufiges Problem sind unvollständige oder schlecht priorisierte Anforderungen. Wenn zu Projektbeginn nicht eindeutig definiert ist, was genau die Software können muss, kommt es später zu Lücken oder ständigen Erweiterungen des Umfangs. Best Practice: Frühzeitig alle Stakeholder einbinden (Facility Manager, IT, Endnutzer) und ein ausführliches Lastenheft erstellen, das Ziele, Muss- und Kann-Anforderungen klar festlegt. Das hilft, den Fokus zu behalten und verhindert, dass während des Projekts immer neue „Wünsche“ den Rahmen sprengen. Auch eine Budgetorientierung im Lastenheft ist sinnvoll – ohne grobe Kostenschätzung besteht die Gefahr, unrealistische Anforderungen zu stellen, die kein Anbieter im Rahmen erfüllen kann.

• Ignorieren des Change-Managements: Die Einführung einer CAFM-Lösung ist kein reines IT-Projekt, sondern ein organisationsweites Veränderungsprojekt. Prozesse, Verantwortlichkeiten und Arbeitsweisen werden sich ändern. Wenn diese Dimension unterschätzt wird, scheitern viele Projekte trotz guter Software. Best Practice: Von Anfang an das Thema Change-Management mitdenken. Die Führungsebene muss hinter dem Projekt stehen und dessen Nutzen für die Organisation kommunizieren. Mitarbeiter sollten früh informiert und vorbereitet werden. Schulungen, regelmäßige Projektkommunikation und ggf. Pilotphasen erleichtern die Akzeptanz. Die Organisation sollte zudem ihre eigenen Prozesse und Daten kritisch analysieren, bevor die Software eingeführt wird: Welche Ziele sollen erreicht werden? Wo gibt es Medienbrüche? Ist die Datenqualität ausreichend? Diese Reflexion stellt sicher, dass die gewählte Software nicht nur technisch passt, sondern auch strategisch wirksam ist.

• Übermäßige Individualisierung der Software: Oft besteht der Wunsch, die Software maximal an bestehende Prozesse anzupassen – durch Zusatzprogrammierungen oder Spezialkonfigurationen. Das birgt Risiken: Zu viel Customizing kann die Update-Fähigkeit einschränken und macht abhängig vom Hersteller. Best Practice: Standard vor Individualentwicklung – wo immer möglich, sollte die Standardfunktionalität genutzt und Prozesse eher an die Software angepasst werden statt umgekehrt. Jede Anpassung muss gut begründet sein (echter Wettbewerbsvorteil oder regulatorischer Zwang). Vom Anbieter sollte man Update-Garantien trotz Customizing verlangen, d. h. Zusicherungen, dass künftige Versionen eingespielt werden können, ohne dass individuelle Erweiterungen verloren gehen. Ein modular aufgebautes System erleichtert dies, weil man neue Versionen modulweise austauschen oder hinzufügen kann.

• Fehleinschätzung des Lizenzbedarfs und der Kosten: Ein Stolperstein ist die falsche Lizenzwahl – sei es in Anzahl oder Modell. Überlizenzierung (zu viele gekaufte Lizenzen auf Vorrat) bindet unnötig Kapital; Unterlizenzierung führt zu Engpässen oder teuren Nachkäufen. Auch die Wahl zwischen Named und Concurrent User ist nicht trivial. Best Practice: Nutzungsanalyse durchführen – wie viele Personen werden wirklich gleichzeitig arbeiten? Wie viele regelmäßige Power-User gibt es? Anhand solcher Analysen das optimale Modell wählen (bei vielen Gelegenheitsnutzern Concurrent-Lizenzen in Betracht ziehen, bei festem Nutzerkreis Named-Lizenzen). Im Zweifelsfall mit dem Anbieter flexible Paketlösungen vereinbaren (z. B. Kombi aus Named und Concurrent, wie oben beschrieben). Zudem sollte man auf Skalierbarkeit und Staffelpreise achten: Im Vertrag idealerweise Staffelungen festhalten, sodass bei steigender Nutzerzahl der Stückpreis sinkt oder zusätzliche Lizenzen zu vorher bekannten Konditionen erworben werden können. Eine transparente Preisübersicht im Vertrag (Tabelle der Modulpreise, User-Preise, Wartungskosten) hilft, spätere Kostenentwicklungen abzuschätzen. Schließlich ist eine Lebenszykluskosten-Betrachtung ratsam: Nicht nur den Lizenzpreis betrachten, sondern alle Folgekosten über 5-10 Jahre (Wartung, Betrieb, mögliche Erweiterungen) einplanen, um Angebote finanziell korrekt zu bewerten.

• Lückenhafte SLAs und Vertragsklauseln: Wurde im Vertrag versäumt, wichtige Service-Aspekte zu regeln, kann das im Betrieb zu Streit führen. Beispiele: Der Anbieter reagiert langsamer als erwartet, liefert benötigte Updates nicht rechtzeitig oder es gibt Unklarheiten, wer für einen Integrationsfehler verantwortlich ist. Best Practice: Vertragsdetails nicht scheuen. Alle wesentlichen Leistungen und Erwartungen schriftlich fixieren – insbesondere Service Level (Verfügbarkeit, Reaktionszeit), Wartungsumfang (wie häufig gibt es Updates, wie werden Fehler behandelt) und Verfügbarkeiten des Supports. Auch Verantwortlichkeiten eindeutig benennen (wer macht Backups, wer pflegt Stammdaten, wer wartet Schnittstellen). Im Zweifel bewährte Muster bzw. Rechtsexperten hinzuziehen. Wichtig ist auch, Abnahme- und Gewährleistungsregelungen zu definieren: Wann gilt die Software als abgenommen? Was passiert, wenn Mängel auftreten? Klare Fristen und Nachbesserungsrechte vereinbaren, um Qualität sicherzustellen.

• Vendor-Lock-in und fehlende Exit-Strategie: Hat man erst viel Geld und Zeit in ein CAFM-System investiert, ist ein Wechsel schmerzhaft – einige Anbieter nutzen das und gestalten den Ausstieg schwierig (z. B. Daten nur in proprietärem Format, keine Unterstützung bei Migration). Best Practice: Von Anfang an eine Exit-Strategie mitdenken. Im Vertrag sollte die Datenportabilität garantiert sein (Daten gehören dem Kunden und werden bei Bedarf vollständig herausgegeben). Optimal ist es, wenn Standardformate (z. B. IFC für Gebäudedaten, CSV/SQL für alphanumerische Daten) genutzt werden können, sodass ein neues System die Daten übernehmen kann. Auch eine Dokumentation der Konfiguration gehört dazu: der Kunde sollte administrativen Zugang und Dokumente haben, um notfalls eigenständig das System weiterbetreiben oder einen anderen Dienstleister beauftragen zu können. Die Exit-Klausel kann vorsehen, dass der Anbieter beim Übergang unterstützt – so ist sichergestellt, dass ein Wechsel ohne größere Ausfallzeiten gelingt. Generell sollte man sich nicht vollständig von einer Firma abhängig machen: z. B. kritisch prüfen, ob proprietäre Zusatzmodule wirklich nötig sind oder ob offene Schnittstellen genutzt werden können.

Zusammenfassend lässt sich sagen, dass die Dienstleistung „CAFM: Beschaffung, Lizenz- und Vertragsmanagement“ Unternehmen dabei unterstützt, eine geeignete CAFM-Software auszuwählen und langfristig erfolgreich zu betreiben. Durch strukturierte Anforderungen, einen systematischen Auswahlprozess, klug gewählte Lizenzmodelle und wasserdichte Verträge werden die Weichen für ein nachhaltiges FM-System gestellt, das den operativen Betrieb ebenso wie strategische Entscheidungen optimal unterstützt. Die vorgestellten Best Practices helfen dabei, typische Fallstricke zu umgehen und den vollen Mehrwert aus der CAFM-Implementierung zu ziehen.