CAFM-System: Lizensierungsmodelle der Bieter

Lizenzierung pro Benutzerart definieren: Der Bieter muss das Lizenzmodell nach Nutzern eindeutig benennen. Es ist offenzulegen, ob die Lizenzierung auf named Usern (namentlich benannte Einzelbenutzer) oder auf gleichzeitigen Benutzern (Concurrent User) basiert. Diese Unterscheidung beeinflusst die Kosten und Nutzungseffizienz erheblich. Ein Named-User-Modell skaliert linear mit der Anzahl der Benutzer, während ein Concurrent-User-Modell mehreren gelegentlichen Nutzern den Zugriff mit weniger Lizenzen ermöglicht, allerdings oft zu einem höheren Preis pro Lizenz (Hersteller kalkulieren z.B. 1 Concurrent License ≈ 1,5 Named Licenses als Aufpreis).

Konditionen der Benutzerlizenzen: Für das gewählte Benutzer-Lizenzmodell sind die Nutzungsbedingungen transparent darzustellen. Bei Concurrent-User-Modellen ist anzugeben, wie die maximale gleichzeitige Nutzerzahl technisch überwacht wird (z.B. über einen Lizenzmanager auf dem Server) und was bei Überschreiten des Limits geschieht (automatische Sperre weiterer Logins oder nachträgliche Berechnung von Übernutzungen). Bei Named-User-Modellen soll geklärt sein, ob und wie Lizenzen auf andere Personen übertragbar sind – etwa wenn ein Mitarbeiter das Unternehmen verlässt, darf dessen Lizenz einem neuen Nutzer zugewiesen werden. Alle diese Details müssen vertraglich festgehalten werden, damit das Preismodell für den Kunden langfristig handhabbar und fair bleibt.

Angabe der Lizenzanzahl und Skalierung: Der Bieter soll in seinem Angebot exakt angeben, wie viele Benutzerlizenzen im Angebot enthalten sind und wie weitere Benutzer lizenziert würden. Beispielsweise: „Lizenzmodell: 100 Named User“ oder „50 Concurrent User“. Etwaige Rabattstaffeln bei steigender Nutzerzahl sind ebenfalls transparent darzustellen (z.B. Preisnachlässe ab bestimmten Schwellenwerten von Benutzerlizenzen), damit Angebote hinsichtlich Größeneffekten vergleichbar sind.

Grundsätzliche Lizenzform angeben: Der Bieter muss das angebotene Lizenzmodell klar benennen und beschreiben. Mögliche Modelle sind insbesondere:

Kauflizenz (On-Premises): Unbefristetes Nutzungsrecht gegen einmaliges Entgelt, meist mit optionalem Wartungsvertrag. Der Kunde erwirbt eine dauerhafte Lizenz und kann die Software zeitlich unbegrenzt nutzen. Wartung und Updates werden typischerweise separat als jährlicher Prozentsatz des Kaufpreises vereinbart.

Miet- oder Abonnementlizenz (Subscription): Zeitlich befristetes Nutzungsrecht gegen regelmäßige Zahlungen (z.B. monatlich oder jährlich). Der Kunde mietet die Software, Updates sind in der Regel inklusive, und das Nutzungsrecht erlischt bei Vertragsende vollständig (kein Weiterbetrieb ohne Verlängerung möglich).

Software as a Service (SaaS): Nutzungsrecht als Cloud-Service, bei dem Software und Infrastruktur vom Anbieter betrieben werden. Der Kunde greift über das Internet auf die Software zu, ohne selbst eine Installation vor Ort zu betreiben. SaaS ist im Kern ebenfalls ein Mietmodell, jedoch inklusive Hosting und meist als Dienstleistungspaket (Betrieb, Wartung, Support sind enthalten). Der Bieter soll angeben, ob die SaaS-Lösung mandantenfähig (alle Nutzer teilen sich die gleiche Umgebung) oder als dedizierte Instanz pro Kunde (ASP – Application Service Providing) umgesetzt ist.

Nutzungsabhängige Lizenzmodelle: Falls der Bieter leistungs- oder nutzungsabhängige Lizenzgebühren anbietet, müssen diese transparent erläutert werden. Dabei ist die Bemessungsgrundlage offenzulegen – z.B. Lizenzgebühren abhängig von der Anzahl der bearbeiteten Vorgänge/Tickets, der verwalteten Objekte/Flächen oder der genutzten Zeit/Dauer im System. Der Bieter soll eindeutig angeben, welche Metriken zur Abrechnung herangezogen werden und wie diese gemessen werden. Beispielsweise könnte ein Modell vorsehen, dass pro 1.000 verwalteter Objekte oder pro 100 Vorgänge eine gewisse Gebühr anfällt. Solche Modelle zielen darauf ab, die Kosten an die tatsächliche Nutzung zu koppeln. Der Anbieter muss hierfür auch mitteilen, ob es Ober-/Untergrenzen oder Grundgebühren gibt und wie eine Nachvollziehbarkeit der Nutzung für den Kunden gewährleistet wird (z.B. durch Reporting der Vorgangsanzahlen).

Einmalkosten und Initialgebühren: Etwaige Initialisierungs- oder Einrichtungsgebühren sind anzugeben. Bei manchen Modellen – insbesondere ASP/SaaS – wird neben den laufenden Gebühren einmalig eine Onboarding-/Setup-Gebühr berechnet (für Installation, Datenübernahme, Schulung etc.). Diese Kosten müssen separat ausgewiesen werden, um die Angebote sauber vergleichen zu können.

Modulare Lizenzen und Erweiterungen: Wenn die Software modular aufgebaut ist, sollen Bieter ihr Lizenzangebot je Modul/Funktionsumfang aufschlüsseln. Der Kunde soll erkennen, welche Module im Basispreis enthalten sind und welche optional hinzugebucht werden können, inkl. der jeweiligen Lizenzkosten pro Modul. Dadurch wird transparent, welche Funktionen im Angebot abgedeckt sind und wie sich der Preis ändert, falls zusätzliche Module benötigt werden. Etwaige Bundle-Angebote (Modulpakete mit Paketpreis) sollen ebenfalls kenntlich gemacht werden, inklusive der preislichen Vorteile gegenüber Einzelmodulen. Wichtig ist, dass Abhängigkeiten zwischen Modulen (technische oder preisliche) erläutert sind – z.B. wenn ein bestimmtes Modul ein anderes voraussetzt, oder wenn Rabatte entfallen, falls ein Modul aus einem Bundle später abbestellt würde.

Vertragslaufzeit und Kündigung: Für Miet-/Subscription- und SaaS-Modelle ist die Mindestvertragslaufzeit sowie Kündigungsfristen anzugeben. Der Bieter soll darlegen, wie Verlängerungen gehandhabt werden und ob der Kunde z.B. nach Ablauf der Mindestlaufzeit in einen monatlich kündbaren Vertrag wechseln kann. Unterschiede in der Bindungsdauer beeinflussen die Vergleichbarkeit (ein Angebot mit langer Bindung und geringeren Monatskosten vs. ein flexibles, aber teureres monatliches Modell). Diese Informationen sind wichtig, um Lebenszykluskosten und Verpflichtungen der Angebote gegenüberzustellen.

Private Cloud vs. Public Cloud vs. On-Premises: Der Bieter muss das Betriebsmodell der Software erläutern. Es ist anzugeben, ob die Lösung in einem definierten Rechenzentrum (Private Cloud oder Hosted/ASP) betrieben wird, oder auf On-Demand Cloud-Ressourcen (Public Cloud SaaS) läuft, oder ob auch ein On-Premises-Betrieb (Installation in der IT-Infrastruktur des Kunden) möglich ist. Diese Information ist wichtig, da sie Einfluss auf Datensicherheit, Integrationsaufwand und laufende Betriebskosten hat. Moderne CAFM-Lösungen bieten oft beide Optionen an – vor Ort oder als Cloud-Lösung – der Bieter soll klar angeben, welche Varianten verfügbar sind.

Rechenzentrumsstandort und -zertifizierungen: Um Angebote bewerten zu können, muss der Bieter darlegen, wo die Daten gespeichert werden und welche Sicherheitsstandards das Rechenzentrum erfüllt. Insbesondere bei Cloud-Angeboten ist anzugeben, in welchem Land bzw. unter welcher Jurisdiktion die Daten liegen und ob Zertifizierungen wie ISO/IEC 27001 (Informationssicherheits-Management) oder spezifische Branchenstandards vorhanden sind. Bei Nutzung einer Public Cloud sind ggf. die Hyperscaler-Plattform (z.B. AWS, Azure, Google Cloud) und deren Zertifikate zu benennen. Diese Angaben erlauben es, die Datensicherheits- und Compliance-Aspekte der Angebote zu vergleichen.

Datensicherheit und Datenschutz: Bieter sollen ihre Sicherheitsvorkehrungen beschreiben, insbesondere bei Cloud-Lösungen. Dies umfasst u.a. Verschlüsselung der Daten (bei Übertragung und Speicherung), Zugriffskontrollen, Backup- und Notfallkonzepte sowie Maßnahmen zur Einhaltung der DSGVO (Datenschutz-Grundverordnung). Da sensible Gebäudedaten und personenbezogene Daten im FM anfallen können, muss aus dem Angebot hervorgehen, wie der Anbieter diese schützt. Verträge sollen entsprechende Auftragsverarbeitungsvereinbarungen (AVV/DPA) und Sicherheitsanhänge beinhalten, um die Verantwortlichkeiten klar zu regeln.

Service-Level-Vereinbarungen (SLA): Für gehostete Lösungen (ASP/SaaS) sind klare SLAs über Verfügbarkeit, Performance und Support vorzulegen. Der Bieter muss angeben, welche Verfügbarkeitsgarantie pro Zeitraum gewährleistet wird (z.B. 99,5% Uptime pro Monat) und welche Entschädigungen vorgesehen sind, falls diese unterschritten wird. Ebenso sind die Reaktions- und Behebungszeiten bei Störungen im Angebot offenzulegen (z.B. Reaktion innerhalb 2 Stunden, Behebung innerhalb 8 Stunden bei kritischen Incidents). Viele Anbieter staffeln ihre Supportleistungen in Service-Level-Kategorien (Bronze, Silber, Gold mit unterschiedlichem Leistungsumfang) – der Bieter soll erläutern, welches Support-Level im Basisangebot enthalten ist und welche höheren Levels optional gebucht werden könnten. Einheitliche Kennzahlen und Definitionen (Incident-Klassifikationen, Wartungsfenster etc.) erhöhen die Vergleichbarkeit der Angebote erheblich. (Hinweis: Für Cloud-SLAs existieren Normen wie ISO/IEC 19086-1, welche Begriffe und Strukturen standardisieren, um Vergleichbarkeit zu fördern.)

Verfügbarkeitskonzept und Redundanzen: Ergänzend sollen Bieter darlegen, wie sie die zugesagte Verfügbarkeit technisch sicherstellen (z.B. redundante Systeme, Hochverfügbarkeits-Cluster, 24/7 Monitoring). Unterschiede in der Infrastrukturqualität spiegeln sich oft in den Kosten wider, daher ist Transparenz wichtig: Ein Anbieter mit hochverfügbarem, zertifiziertem Rechenzentrum kann höhere Cloud-Betriebskosten haben, bietet dafür aber ggf. geringeres Ausfallrisiko. Der Kunde muss diese Unterschiede erkennen können, um fundierte Entscheidungen zu treffen.

Aktueller Technologiestandard: Der Bieter soll versichern, dass das vorgeschlagene Lizenzierungs- und Bereitstellungsmodell dem aktuellen Marktstandard entspricht. Cloudbasiertes CAFM hat sich international bereits als Standard etabliert, viele neue CAFM/IWMS-Lösungen werden nur noch als Cloud-Service angeboten. Unterstützt durch große ERP-Anbieter zeichnet sich auch im deutschsprachigen Raum der Trend zu Cloud-Lösungen deutlich ab. Vor diesem Hintergrund sollten Angebote darlegen, wie ihr Lizenzmodell zukünftige Entwicklungen berücksichtigt – z.B. Möglichkeit, von On-Premises auf Cloud zu wechseln (und umgekehrt), flexible Anpassung der Nutzerzahl, regelmäßige Updates ohne großen Migrationsaufwand etc. Ein zukunftsfähiges Lizenzmodell schützt den Kunden vor einem späteren Wechselzwang, falls der Markt sich weiter in Richtung SaaS bewegt.

Vendor-Lock-in vermeiden: In den Anforderungen sollte ebenfalls adressiert werden, inwiefern das Lizenzmodell einen Wechsel des Anbieters ermöglicht oder erschwert. Ein transparentes Modell zeichnet sich dadurch aus, dass der Kunde seine Daten bei Bedarf exportieren kann und keine übermäßigen Vertragsstrafen oder technisch bedingten Hindernisse bei einer Kündigung vorfindet. Beispielsweise sollte bei SaaS klar geregelt sein, wie die Datenrückgabe am Vertragsende erfolgt und dass die Daten dem Kunden gehören. Bieter müssen angeben, ob ihre Lizenzbedingungen spezielle Bindungsklauseln enthalten, da dies die Risikobewertung beeinflusst (Stichwort Exit-Strategie).

Referenzen und Erfahrungen: Schließlich kann vom Bieter verlangt werden, erfolgreiche Referenzkunden mit ähnlichem Lizenzmodell zu benennen. Dies hilft dem ausschreibenden Unternehmen, die Praktikabilität und etwaige versteckte Tücken eines Lizenzmodells aus Kundensicht besser einschätzen zu können. Erfahrungen aus der Praxis (z.B. ob ein nutzungsabhängiges Modell tatsächlich Kosten spart oder ob ein Concurrent-Modell wie erwartet funktioniert) tragen zur Gesamtbewertung bei.