CAFM: Betriebs- und Hostingentscheidung (SaaS/Cloud/On Prem)

Das SaaS-Modell bietet strategisch vor allem Agilität und Fokus auf das Kerngeschäft. Die Software wird vom Hersteller als Dienst bereitgestellt, was eine sehr schnelle Inbetriebnahme ermöglicht (kein eigenes Aufsetzen von Servern) und geringe Anfangsinvestitionen erfordert – bezahlt wird meist in Form regelmäßiger Nutzungsgebühren (OPEX statt CAPEX). Updates und neue Funktionen werden vom Anbieter automatisch eingespielt, sodass Nutzer stets von kurzen Innovationszyklen profitieren und nicht selbst für Upgrades planen müssen. Unternehmen ohne große IT-Abteilung können so moderne Technologien nutzen, ohne sich um den Betrieb kümmern zu müssen. Zudem ist die Skalierbarkeit hoch – zusätzliche Nutzer oder Standorte lassen sich flexibel hinzuschalten, da die Cloud-Infrastruktur des Anbieters dies auffängt.

Den Vorteilen stehen allerdings Nachteile gegenüber. Bei SaaS liegt ein Kontrollverlust über die Infrastruktur und Daten vor – man muss dem Anbieter hinsichtlich Verfügbarkeit, Sicherheit und Datenschutz vertrauen. Diese Abhängigkeit vom Anbieter (Lock-in) birgt strategisches Risiko: Wechsel des Anbieters oder Rückholung On-Premises sind nur mit vorausschauenden Exit-Strategien ohne Datenverlust möglich. Weiterhin sind Customizing und Integration mitunter eingeschränkt auf das, was der SaaS-Anbieter vorsieht – sehr spezifische Anforderungen lassen sich ggf. schwerer umsetzen als in Eigenregie. Schließlich erfordert SaaS zwingend eine stabile Internetverbindung, da die Anwendung extern gehostet wird (was in manchen Umgebungen ein limitierender Faktor sein kann). Strategisch passt SaaS insbesondere, wenn Schnelligkeit, Standardisierung und Ressourcenschonung im Vordergrund stehen und Cloud-Compliance gewährleistet werden kann.

Ein Private-Cloud-Modell – etwa eine dedizierte Instanz der Software, gehostet beim Anbieter oder in einem externen Rechenzentrum – stellt einen Mittelweg dar. Vorteilhaft ist hier, dass das Unternehmen meist die Software-Lizenz besitzt und damit eine gewisse Unabhängigkeit hinsichtlich Funktionsumfang und Datenzugriff wahrt. Die Infrastruktur wird jedoch vom Hosting-Partner bereitgestellt, wodurch eigene Hardware-Investitionen entfallen und Infrastrukturaufgaben (Betrieb der Server-Hardware, Basis-Sicherheit) ausgelagert sind. Dies kann die interne IT entlasten und erfordert eine kleinere IT-Mannschaft in-house als beim voll eigenen Betrieb. Gleichzeitig behält man etwas mehr Gestaltungsspielraum als bei multi-tenant SaaS – z. B. bei Update-Zeitpunkten oder speziellen Konfigurationen – und die Datenhoheit kann vertraglich präziser definiert werden (etwa wo die Systeme gehostet werden).

Die Nachteile/Schwächen ähneln je nach Ausprägung teils dem SaaS-, teils dem On-Prem-Modell. Die Kosten können hoch sein: neben Lizenzkosten fallen laufende Hosting-Gebühren an, und Initialaufwände für Einrichtung einer dedizierten Umgebung bleiben beträchtlich. Das Unternehmen ist weiterhin (ähnlich wie On-Prem) selbst für das Applikationsmanagement verantwortlich – Patches, Upgrades und ggf. Backup der Anwendung müssen eigenständig (oder via separatem Servicevertrag) durchgeführt werden. Damit einher geht die Notwendigkeit, ausreichend internes oder externes Know-how für den Anwendungsbetrieb vorzuhalten. Strategisch sinnvoll ist das Private-Cloud-Modell häufig, wenn Unternehmen die Software kontrollieren (Eigentum an der Lizenz) möchten, aber keine eigene Hardware betreiben wollen – beispielsweise um bestimmte Compliance-Vorgaben zur Datenhaltung beim Anbieter zu erfüllen, jedoch mit weniger eigenem Infrastrukturaufwand.

Das On-Premises-Modell – der klassische Eigenbetrieb – bietet maximale Kontrolle. Die Software wird im unternehmenseigenen Rechenzentrum auf eigener Hardware installiert. Vorteile sind die volle Datenhoheit (alle Daten bleiben intern auf den eigenen Servern) und die Möglichkeit, Systeme nach eigenen Richtlinien zu gestalten. Unternehmen können die Sicherheitsarchitektur individuell anpassen, Integration mit internen Systemen nahtlos umsetzen und die Infrastruktur nach eigenen Performance-Bedürfnissen dimensionieren. On-Premises kann außerdem strategisch geboten sein, wenn regulatorische Vorgaben oder interne Richtlinien Cloud-Nutzung einschränken – z. B. in streng regulierten Branchen oder bei Geheimhaltungsstufen, wo nur Inhouse-Betrieb zulässig ist. Auch erlaubt On-Premises theoretisch den Weiterbetrieb der Software unabhängig vom Hersteller (z. B. falls der Support endet), da man eine dauerhafte Lizenz besitzt. Somit bedeutet Eigenbetrieb maximale Autonomie und Anpassungsfreiheit im Umgang mit der Lösung.

Dem stehen erkennbare Nachteile gegenüber: On-Premises ist meist die aufwändigste und kostspieligste Variante in Anschaffung und Betrieb. Es sind hohe Investitionen in Hardware, Datenbanken und Lizenzen nötig, bevor das System produktiv geht. Laufend fallen interne Betriebskosten an – vom Rechenzentrumsplatz über Strom und Kühlung bis zur Beschäftigung oder Schulung von IT-Personal für Wartung und Support. Updates und Upgrades müssen eigeninitiativ geplant und durchgeführt werden; ohne regelmäßige Updates drohen Sicherheits- oder Supportprobleme. Außerdem skaliert eine On-Prem-Lösung nur mit weiteren Investitionen (für zusätzliche Server etc.) und ist weniger flexibel bei schwankendem Bedarf. Für verteilte Standorte oder mobiles Arbeiten ist der Eigenbetrieb häufig unflexibler, da externe Zugriffe komplexer abzusichern sind. Insgesamt eignet sich On-Premises strategisch vor allem, wenn volle Kontrolle und spezifische Anforderungen höher gewichtet werden als die höheren Kosten und Aufwände – etwa bei sehr schutzbedürftigen Daten, bestehenden Rechenzentrumskapazitäten oder IT-Strategien, die Cloud ausschließen.

Zusammenfassend lässt sich kein generelles „richtig oder falsch“ feststellen – die optimale Wahl hängt von den Prioritäten der Organisation ab. Während Cloud-Lösungen (SaaS oder dediziert) Agilität, geringere Einstiegshürden und automatische Skalierung bieten, punktet On-Premises mit Kontrolle, Individualisierbarkeit und interner Datenhaltung. In vielen Fällen überwiegen heutzutage die Vorteile der Cloud-Modelle – insbesondere angesichts knapper IT-Ressourcen und des Drucks zur Digitalisierung – doch sollten die spezifischen Vor-Ort-Gegebenheiten, Risiken und strategischen Ziele in die Bewertung einfließen. Im nächsten Schritt werden die einzelnen Entscheidungsaspekte detailliert betrachtet, um eine fundierte Abwägung zu ermöglichen.

IT-Governance-Vorgaben und regulatorische Anforderungen spielen bei der Hostingentscheidung eine zentrale Rolle. Viele Unternehmen haben interne Strategien oder Policies (z. B. „Cloud-First“-Vorgaben oder im Gegenteil Cloud-Verbote), die den Rahmen vorgeben. Diese Governance-Aspekte gilt es abzustimmen: Passt das Modell zur übergeordneten IT-Strategie und zu den Enterprise-Architecture-Prinzipien? Beispielsweise muss geprüft werden, ob ein Cloud-Modell mit den Vorgaben der IT-Abteilung zur Datenhaltung, zu Schnittstellen oder zu unterstützten Technologien konform geht. On-Premises bietet hier maximale Ausrichtung an internen Standards – die IT behält volle Kontrolle über Systeme, Update-Zyklen und Compliance-Maßnahmen im eigenen Rechenzentrum. SaaS erfordert dagegen Vertrauen in die Governance des Anbieters und eine gute Vertragsgestaltung, um Unternehmensrichtlinien umzusetzen. So sollte z. B. festgelegt werden, wie Changes am Service kommuniziert und gesteuert werden, damit sie mit der internen Change Governance harmonieren. Insgesamt muss das gewählte Modell in die IT-Landschaft integrierbar sein und den betrieblichen Abläufen (z. B. Backup-Konzept, Berechtigungsmanagement) entsprechen.

Ein besonders wichtiger Unteraspekt ist der Datenschutz (DSGVO). Sobald personenbezogene Daten im Spiel sind – etwa Mitarbeiter-, Nutzer- oder Mieterdaten in einem CAFM-System – greift die Datenschutz-Grundverordnung. Bei SaaS- oder Cloud-Lösungen ist der Softwareanbieter bzw. Hoster ein Auftragsverarbeiter im Sinne von Art. 28 DSGVO. Entsprechend muss mit dem Anbieter ein Auftragsverarbeitungsvertrag (AVV) geschlossen werden, der die Pflichten des Dienstleisters beim Datenschutz regelt. Darin sollte u. a. festgehalten werden, welche Daten verarbeitet werden, zu welchen Zwecken und wie der Anbieter diese schützt. Wichtig ist zudem die Frage des Datenstandorts: Viele Unternehmen verlangen aus Compliance-Gründen, dass Rechenzentren in der EU genutzt werden, um den strengen EU-Datenschutz einzuhalten. Ist der Cloud-Anbieter ein US-Unternehmen oder werden Daten in Drittländer übertragen, bedarf es besonderer Maßnahmen – etwa Standardvertragsklauseln (Standard Contractual Clauses, SCC) und ggf. zusätzlicher Sicherheitsvorkehrungen. Hier muss genau geprüft werden, ob das Schutzniveau angemessen ist. Größere Cloud-Provider weisen oft Zertifizierungen und Audits nach, um Vertrauen zu schaffen: So unterziehen sich z. B. Googles Cloud-Rechenzentren in Deutschland regelmäßigen BSI-KRITIS Audits, um die Compliance mit den Vorgaben für Kritische Infrastrukturen zu demonstrieren. Solche Nachweise (ISO 27001, C5-Testat, etc.) sollten bei der Anbieterauswahl abgefragt werden.

Bei einer On-Premises-Lösung verbleiben die personenbezogenen Daten komplett im Haus, was datenschutzrechtlich einige Risiken (z. B. Zugriff durch Dritte) reduziert. Hier ist das Unternehmen selbst Verantwortlicher und Betreiber der Datenverarbeitung – es muss intern für DSGVO-konforme Verarbeitung sorgen, benötigt aber keinen AV-Vertrag mit sich selbst. Allerdings ergeben sich auch bei On-Premises Datenschutzfragen: Zugriffsbeschränkungen für Administratoren, Löschkonzepte, Datensicherungen und eventuelle Fernwartungszugriffe von Herstellerseite müssen DSGVO-konform gestaltet sein. In allen Fällen – egal ob Cloud oder On-Prem – empfiehlt es sich, den Datenschutzbeauftragten früh einzubeziehen und die geplante Datenverarbeitung (welche Personaldaten, Zugriffe aus welchem Land, etc.) in einer Datenschutz-Folgenabschätzung zu betrachten.

Neben dem personenbezogenen Datenschutz gibt es in vielen Branchen weitere Compliance-Vorgaben. Bei KRITIS-Betreibern (Betreibern Kritischer Infrastrukturen wie Energie, Gesundheit, etc.) gelten z. B. besondere Anforderungen des IT-Sicherheitsgesetzes. Diese verlangen umfangreiche Sicherheitsmaßnahmen und regelmäßige Audits. Ein CAFM-System könnte unter KRITIS fallen, wenn es kritische Prozesse steuert oder Teil der kritischen IT ist. On-Premises kann hier vorteilhaft sein, da man die vollständige Hoheit über Sicherheitsmaßnahmen hat und z. B. nach BSI-Grundschutz zertifizieren kann. Cloud-Anbieter können jedoch ebenfalls KRITIS-tauglich sein, sofern sie die gesetzlichen Auflagen erfüllen (wie oben erwähnt, lassen sich Anbieter zertifizieren und registrieren, um KRITIS-Standards zu genügen). In jedem Fall bleibt das Unternehmen trotz Auslagerung in der Verantwortung, regulatorische Pflichten zu erfüllen – die Umsetzung teilt sich je nach Modell zwischen Anbieter und Kunde auf. Hier hilft das Konzept der Shared Responsibility: Bei Cloud/SaaS übernimmt der Dienstleister viele technische und organisatorische Maßnahmen, der Kunde muss aber z. B. für korrekte Benutzerrollen, Datenklassifizierung und Monitoring sorgen.

Ein weiterer Aspekt ist die Betreiberverantwortung im Facility Management. Darunter versteht man die gesetzlichen Pflichten des Betreibers einer Immobilie oder technischen Anlage – etwa Wartungen, Prüfungen und Verkehrssicherungspflichten fristgerecht durchzuführen und nachzuweisen. Ein CAFM-System soll genau dabei unterstützen, indem es Termine dokumentiert, Verantwortliche zuweist und Nachweise speichert. Wichtig für die Hosting-Entscheidung ist, dass das gewählte Modell die Erfüllung der Betreiberpflichten nicht gefährdet: Die Daten (Prüfprotokolle, Wartungsnachweise etc.) müssen sicher und langfristig verfügbar sein, und Systemausfälle dürfen nicht dazu führen, dass Fristen versäumt werden. Bei SaaS sollte daher auf hohe Verfügbarkeit und regelmäßige Backups geachtet werden (vertraglich via SLA geregelt), damit z. B. ein Cloud-Ausfall nicht zum Compliance-Verstoß führt. Auch muss der Anbieter gewährleisten, dass im System gespeicherte Nachweise revisionssicher sind. Bei On-Premises liegt es in der eigenen Verantwortung, durch geeignete Redundanzen und Datensicherung die Verfügbarkeit sicherzustellen. Außerdem sollten Zugriffsrechte so gestaltet sein, dass im Auditfall alle erforderlichen Dokumente schnell aus dem System belegt werden können. Unterm Strich fordert die Betreiberverantwortung, dass Datenintegrität und Zugriff im CAFM garantiert sind – dieses Ziel muss das Hostingmodell unterstützen, sei es durch vertrauenswürdige Service Level eines Cloud-Anbieters oder durch eigene robuste Betriebsprozesse.

Die IT-Sicherheitsarchitektur eines CAFM/IWMS/CMMS-Systems unterscheidet sich je nach Betriebsmodell erheblich. On-Premises ermöglicht es der Organisation, sämtliche Sicherheitsmaßnahmen eigenständig umzusetzen: Netzwerksegmentierung, Firewalls, Zugriffskontrollen, Verschlüsselung und Patchmanagement liegen vollständig in der Hand der internen IT. Dies bietet maximale Gestaltungsfreiheit, erfordert aber auch entsprechende Ressourcen und Expertise, um ein hohes Schutzniveau aufrechtzuerhalten. Jede Sicherheitskomponente (z. B. Virenschutz, Intrusion Detection) muss aktiv gemanagt und aktuell gehalten werden – ein erheblicher Aufwand, der in die Gesamtrechnung einfließen sollte. In der Praxis bedeutet das: Sicherheits-Patches für Server und Software müssen zügig eingespielt werden, Firewalls sind zu konfigurieren und ständig zu überwachen, und regelmäßige Penetrationstests sollten intern beauftragt werden. Nur so lässt sich z. B. der Stand der Technik gemäß DSGVO oder ISO 27001 auch On-Prem gewährleisten. Vorteilhaft bei On-Prem ist hingegen die Netzwerkhoheit: Das System kann vollständig ins interne LAN integriert und von außen abgeschirmt werden. Bei Bedarf lässt sich der Zugriff strikt auf Intranet beschränken, was das Risiko externer Angriffe reduziert (allerdings auf Kosten der ortsunabhängigen Verfügbarkeit).

Im SaaS-Modell wird die Sicherheitsarchitektur weitgehend vom Anbieter vorgegeben und gemanagt. Renommierte SaaS-Anbieter investieren stark in professionelle Security-Maßnahmen, die einzelne Unternehmen in diesem Umfang oft kaum leisten können – von 24/7 Überwachung über regelmäßige Audits bis zur umfassenden Verschlüsselung. Häufig sind Cloud-Lösungen nach anerkannten Standards zertifiziert (z. B. ISO/IEC 27001 für Informationssicherheit) und halten durch Multi-Tenant-Architekturen sehr robuste Security-Frameworks vor. Für den Kunden entfällt somit die Detailarbeit bei Betriebssystem- und Datenbanksicherheit – diese Basis-Sicherheit ist im SaaS-Modell eingebaut. Allerdings gibt man einen Teil der Datenkontrolle aus der Hand: Die Daten liegen beim Dienstleister, der technisch Zugriff darauf haben kann. Unternehmen sollten deshalb großen Wert auf vertragliche Zusicherungen legen, z. B. dass Kundendaten mandantentrennend gespeichert und übertragen werden (Stichwort Mandantenschutz) und nur berechtigtes Personal beim Anbieter Zugriff hat. Verschlüsselung ist ein zentrales Thema: Bei SaaS sollte zumindest die Übertragung (TLS) und idealerweise auch die Speicherung sensibler Daten verschlüsselt erfolgen. Einige Anbieter ermöglichen Bring Your Own Key-Konzepte, bei denen der Kunde eigene Verschlüsselungsschlüssel verwaltet – dies erhöht die Kontrolle. Letztlich ist im Cloud-Modell die Sicherheitsarchitektur eine geteilte Verantwortung: Der Provider sichert Infrastruktur und Anwendung (z. B. physische Server-Sicherheit, Netzwerkschutz, Anwendungspatches), der Kunde verantwortet die korrekte Konfiguration der Zugriffe (Benutzerrechte, starke Passwörter/Multi-Faktor-Authentifizierung, etc.) und den sicheren Gebrauch der Anwendung. Positiv ist, dass ein guter SaaS-Anbieter viele Sicherheitsthemen proaktiv angeht und z. B. regelmäßige Schwachstellen-Scans, Backups und Notfallpläne fest implementiert hat – Dinge, die On-Prem erst aufgebaut werden müssten.

Eine Private Cloud (dediziertes Hosting) nimmt bezüglich Sicherheitsarchitektur eine Zwischenstellung ein. Die physische Sicherheit und Basis-Infrastruktur (Strom, Netzwerk, Hardware-Ausfallkonzepte) liegen in der Verantwortung des Hosting-Providers, oft mit hohen Standards im Rechenzentrum. Das Applikations- und Datenbank-Sicherheitsmanagement kann aber weiterhin beim Kunden verbleiben, sofern dieser das System selbst administriert. Manche Anbieter übernehmen auch hier einen Teil (Managed Service), andere überlassen Patches und Konfiguration dem Kunden. Klar ist: Bei externem Hosting sollte detailliert geklärt werden, wer welche Sicherheitsaufgaben übernimmt. Empfehlenswert ist, im Vertrag Mindeststandards festzulegen – etwa dass der Hoster regelmäßig Sicherheitsupdates einspielt und Firewalls nach abgestimmten Regeln betreibt. Auch eine ISO27001-Zertifizierung des Dienstleisters gibt Vertrauen, dass ein Informationssicherheits-Managementsystem implementiert ist.

Datenkontrolle betrifft die Hoheit über die eigenen Informationen. On-Premises bietet hier maximale Kontrolle: Daten liegen in der eigenen Umgebung, Zugriffe Dritter können technisch ausgeschlossen werden. Sensible Informationen bleiben innerhalb definierter Grenzen (z. B. in einem bestimmten Land, sofern das Rechenzentrum dort steht). Cloud-Lösungen erfordern, dass man dem Anbieter hinsichtlich Datenhandhabung vertraut – daher sollte man sich Transparenz geben lassen: Wo werden die Daten gespeichert (Land/Rechenzentrum)? Welche Unterauftragnehmer sind beteiligt? Wie lange werden Backups aufbewahrt? Ein guter Cloud-Vertrag wird die Datenverarbeitung und -löschung klar regeln (z. B. Rückgabe oder Löschung der Daten nach Vertragsende). Außerdem sollte der Kunde regelmäßige Datenexports vornehmen oder vom Anbieter automatisiert erhalten, um im Zweifel eine eigene Kopie zu haben. Im täglichen Betrieb kann Datenkontrolle auch heißen: Echtzeit-Zugriff auf alle Daten für Auswertungen, Monitoring und Audits. In SaaS-Systemen sollten daher Funktionen wie Audit-Logs (wer hat was geändert) vorhanden sein, um Kontrolle auszuüben, während On-Prem-Systeme solche Logs oft ebenfalls bieten, aber man ist selbst dafür verantwortlich, sie zu aktivieren und auszuwerten.

Nicht zu vernachlässigen ist die Netzwerksicherheit und Zugangsarchitektur: Bei SaaS erfolgt der Zugriff typischerweise über das Internet. Hier sind verschlüsselte Verbindungen (HTTPS) Pflicht und oftmals zusätzliche Sicherheitsmechanismen wie IP-Filter oder VPN vom Anbieter unterstützt. Identity-Management lässt sich in modernen Cloud-Lösungen meist via SAML/OAuth anbinden, sodass Single Sign-On mit dem Unternehmens-AD möglich ist. On-Premises kann man das System direkt ins eigene AD integrieren, was vorteilhaft für nahtlose Berechtigungssteuerung ist. Allerdings muss man On-Prem auch an externe Nutzer (z. B. Wartungsfirmen) anbinden können – meist geschieht das dann über VPN oder Terminalserver, was administrativen Aufwand und potenzielle Sicherheitslücken (offene Ports) bedeutet. SaaS bietet hier einen Vorteil durch standardmäßigen Webzugriff weltweit, der jedoch entsprechend abgesichert sein muss (MFA, gutes Berechtigungskonzept).

Zusammengefasst erfordert jede Option ein umfassendes Sicherheitskonzept: On-Premises intern implementiert, Cloud beim Provider validiert. In beiden Fällen sollte Security-by-Design berücksichtigt werden – z. B. minimale Rechtevergabe, regelmäßige Backups (On-Prem vom Kunden, bei SaaS durch Anbieter, typischerweise automatisch), Tests der Notfallwiederherstellung und Sensibilisierung der Anwender. Letztlich kann sowohl On-Prem als auch Cloud sehr sicher betrieben werden – entscheidend ist, wer die Verantwortung trägt. Wenn das Unternehmen selbst nicht über die Mittel verfügt, höchste Sicherheit zu gewährleisten, kann ein Cloud-Service mit nachgewiesener Sicherheit (Penetrationstests, Zertifikate, etc.) vorteilhafter sein. Jedoch muss man bereit sein, dafür ein Stück unmittelbare Kontrolle abzugeben.

Die finanzielle Betrachtung der Hostingmodelle ist für viele Entscheider ausschlaggebend. Wirtschaftlich unterscheiden sich SaaS/Cloud und On-Premises fundamental in der Kostenstruktur: Ersteres folgt meist dem Miet- bzw. Abonnementmodell mit laufenden Betriebskosten (OPEX), letzteres dem Investitionsmodell mit anfänglichen CAPEX und später geringeren laufenden Kosten. Eine gesamtheitliche TCO-Analyse (Total Cost of Ownership) sollte alle Kosten über den Lebenszyklus von typisch 5–10 Jahren berücksichtigen.

Bei einem On-Premises-Projekt fallen hohe Initialkosten an: Anschaffung der Softwarelizenzen (ggf. eine unbefristete Kauflizenz), Kauf oder Upgrade von Server-Hardware, Datenbanklizenzen und Infrastruktur (Storage, Netzwerk) sowie Implementierungs- und Installationskosten. Diese Investitionen können leicht sechsstellige Beträge erreichen, bevor das System produktiv geht. Zusätzlich sollte man Projektnebenkosten einplanen wie die Planung und Installation der Umgebung, Tests, eventuelle Ausfallkonzepte usw. Nach Inbetriebnahme entstehen laufende Kosten für Wartung und Betrieb: meist ein Wartungsvertrag (~15–20 % des Lizenzpreises pro Jahr) für Software-Updates und Support, Kosten für Strom/Kühlung des Rechenzentrums und vor allem Personalkosten für Administratoren, DBAs und Supportmitarbeiter. Studien zeigen, dass gerade diese operativen Personalkosten einen großen Teil der TCO von On-Premises ausmachen. Hinzu kommen indirekte Kosten, etwa für regelmäßige Schulungen des Personals oder für Ausfallzeiten, falls das System intern nicht optimal betreut wird. Nicht zu vergessen: Hardware-Erneuerungen werden alle 4–5 Jahre nötig, was erneut Investitionen erfordert.

SaaS- und Cloud-Lösungen hingegen verlagern die Kosten hin zu laufenden Gebühren. Bei SaaS zahlt man üblicherweise pro Nutzer und Monat/Jahr oder eine pauschale Subscription-Fee für einen Mandanten. Hohe Anfangsinvestitionen entfallen, was die Hürde zum Projektstart senkt und die Liquidität schont. Dafür sind die laufenden Zahlungen über die Nutzungsdauer zu berücksichtigen. Eine Cloud-Lösung wirkt oft günstiger im ersten und zweiten Jahr, kann aber über einen sehr langen Nutzungszeitraum kumuliert ähnlich viel oder mehr kosten als ein Kaufmodell – je nachdem, wie die Preisstaffeln gestaltet sind. Unternehmen sollten daher über den gesamten Lebenszyklus (z. B. 10 Jahre) rechnen, um die tatsächliche Differenz zu sehen. Vorteile der OPEX-Variante sind die Planbarkeit und Skalierbarkeit der Kosten: Benutzeranzahlen oder Module können oft flexibel hinzugebucht werden, und man zahlt nur für die tatsächliche Nutzung. In vielen Fällen entfallen auch separate Lizenzkosten für Datenbanken oder Middleware, da diese im Service inbegriffen sind. Kosten für Updates sind bei SaaS ebenfalls schon inklusive – anders als On-Prem, wo größere Versionsupgrades oft zusätzlichen Aufwand oder sogar neue Lizenzkosten bedeuten.

Ein wichtiger wirtschaftlicher Faktor ist die Skalierbarkeit. SaaS/Cloud erlaubt es, bei Wachstum des Unternehmens oder steigender Nutzungsintensität nahtlos zu skalieren, ohne große Vorabinvestments. Der Anbieter stellt bei mehr Last einfach mehr Ressourcen bereit (ggf. kostet das entsprechend mehr, aber ohne dass der Kunde selbst Hardware beschaffen muss). Umgekehrt kann man bei geringerer Nutzung Kapazitäten reduzieren (sofern der Vertrag flexible Anpassungen zulässt). On-Premises hingegen erfordert bei zunehmendem Bedarf eventuell kostspielige Aufrüstungen: zusätzliche Server, stärkere Prozessoren, mehr Speicherplatz – all das muss finanziert und eingebaut werden, bevor Leistung verfügbar ist. Dies führt zu geringerer Elastizität: Man muss oft auf Verdacht mehr anschaffen (Overprovisioning), um Reserven für Spitzen zu haben, was Kapital bindet.

Auch Kosten bei Ausfall und Betrieb sind zu beachten: Bei On-Prem trägt das Unternehmen das volle Ausfallrisiko – bei technischen Störungen muss es selbst Ersatz beschaffen und die Downtime intern managen. Das Implementieren einer hochverfügbaren Architektur (z. B. Cluster, redundante Rechenzentren) ist extrem aufwändig und teuer. Cloud-Anbieter hingegen werben mit integrierter Hochverfügbarkeit und Disaster Recovery über verteilte Zonen – Ausfälle einzelner Komponenten werden vom Anbieter aufgefangen, und er haftet ggf. für Nichterfüllung per SLA. Dies reduziert das finanzielle Risiko ungeplanter Downtime für den Kunden und fließt implizit in die Servicekosten ein. Zudem können Sandbox- und Testumgebungen in der Cloud oft kostengünstig temporär bereitgestellt werden, während man On-Prem für solche Zwecke dauerhafte Ressourcen vorhalten müsste.

Bei den direkten Betriebskosten (ohne Personal) schneiden Cloud-Lösungen häufig günstiger ab, weil Skaleneffekte genutzt werden: Der Anbieter betreibt die Infrastruktur effizient für viele Kunden zugleich. Allerdings erzielt der Anbieter natürlich eine Marge, d.h. ein Teil der laufenden Gebühr ist „Gewinnaufschlag“ für den Service. Bei On-Prem zahlt man alles selbst, hat aber auch jeden Effizienzgewinn selbst (wenn man z. B. ein sehr ausgelastetes Rechenzentrum hat, könnte On-Prem bei großen Unternehmen pro Einheit günstiger sein). Kleine und mittelständische Unternehmen tendieren insgesamt zur Cloud, da sie allein die nötige IT-Infrastruktur nicht so kostengünstig bereitstellen könnten. Große Unternehmen mit vorhandener IT können manchmal On-Prem-Lösungen in ihr Setup integrieren, ohne drastische Mehrkosten – hier lohnt ein individueller TCO-Vergleich. Laut Erfahrungswerten sehen viele Unternehmen inzwischen, dass Cloud-Services einen höheren Nutzen und Wertbeitrag liefern gemessen am Aufwand. Dies liegt an der Kombination von geringen Opportunitätskosten (man bindet kein Kapital, Projekte gehen schneller live) und besseren Möglichkeiten, moderne Funktionen zu nutzen (Analytics, Mobile etc.), die in SaaS oft schneller verfügbar sind.

Ein oft diskutierter Punkt ist die Bilanzierung: Bei einem klassischen Softwarekauf können Unternehmen die Investition aktivieren und über Jahre abschreiben (Anlagevermögen). Bei SaaS sind die laufenden Gebühren meist direkt als Betriebsausgabe zu verbuchen. Je nach Bilanzierungsregel kann dies gewünscht sein (OPEX bevorzugt, um flexibel zu bleiben) oder unerwünscht (man möchte evtl. einen Vermögenswert zeigen). Einige Unternehmen klären intern mit dem Rechnungswesen, inwiefern z. B. Vorauszahlungen oder langfristige SaaS-Verträge aktiviert werden können. Solche finanztechnischen Überlegungen sollten im Entscheidungsprozess berücksichtigt werden, damit das gewählte Modell auch * accounting*-seitig optimal passt.

Zusammengefasst bietet SaaS/Cloud finanzielle Flexibilität, geringe Einstiegskosten und planbare laufende Zahlungen, während On-Premises höhere Anfangsinvestitionen, dafür potenziell niedrigere laufende Gebühren pro Jahr (nach Amortisation) mit sich bringt. Die Total Cost of Ownership hängt stark von der Nutzungsdauer, der Unternehmensgröße und dem vorhandenen IT-Ökosystem ab. In vielen Fällen zeigen Berechnungen, dass Cloud-Lösungen insbesondere dann wirtschaftlich vorteilhaft sind, wenn man die eingesparten internen Aufwände (IT-Personal, Betriebsrisiken) mit einrechne. Wichtig ist, alle Kostenbestandteile transparent aufzustellen – inklusive „versteckter“ Posten wie Schulungen, Integrationsaufwände oder möglichen Migrationskosten in der Zukunft.

• Integrationsfähigkeit: Ein CAFM-System steht selten isoliert, sondern muss mit anderen IT-Systemen (z. B. ERP, HR-System, Gebäudeleittechnik, IoT-Sensorik) Daten austauschen. On-Premises bietet hier oft direkte Verbindungsmöglichkeiten innerhalb des Unternehmensnetzwerks – z. B. kann die CAFM-Datenbank direkt mit der ERP-Datenbank kommunizieren oder man nutzt Dateischnittstellen im LAN. Legacy-Systeme lassen sich manchmal einfacher an On-Prem-Lösungen koppeln, insbesondere wenn proprietäre Protokolle oder direkte DB-Zugriffe nötig sind. Allerdings setzen moderne Softwareprodukte – ob Cloud oder On-Prem – zunehmend auf Webservices und APIs für die Integration. Ein gutes SaaS-System stellt REST-APIs oder andere Integrationsschnittstellen bereit, mit denen gängige Anwendungen verbunden werden können. Vorteil SaaS: Der Anbieter kümmert sich um die Weiterentwicklung dieser Schnittstellen (Updates bei API-Änderungen etc.), und häufig gibt es Out-of-the-box-Konnektoren zu Standardsoftware. Herausforderung bei Cloud-Integrationen ist jedoch die Verbindung über das Internet: Für den Datenaustausch mit internen Systemen muss man sichere Verbindungen einrichten (VPN-Tunnel, API-Gateways, etc.), was Latenzen verursachen kann und sorgfältig abzusichern ist. Bei On-Prem dagegen kann man Integrationen über interne Netzwerke laufen lassen, was performant und innerhalb der Firewall bleibt. Wenn Echtzeit-Integrationen mit Equipment vor Ort nötig sind (z. B. IoT-Sensoren in Gebäuden): On-Prem-Systeme können direkt auf diese zugreifen, während Cloud-Lösungen über Edge-Komponenten oder Internetprotokolle kommunizieren müssen. Die Entscheidung sollte also auch berücksichtigen, wie und wo die wichtigsten Schnittstellen umgesetzt werden. In der Praxis bieten viele Cloud-C AFM-Anbieter heute Lösungen an, um On-Premise-Datenquellen anzubinden (z. B. mittels IoT Gateways oder Middleware). Grundsätzlich gilt: Gute Integrationsfähigkeit ist kein Alleinstellungsmerkmal von On-Prem mehr – auch Cloud-C AFM kann durch Standard-APIs sehr anschlussfähig sein. Dennoch sollten Unternehmen ihre vorhandene Systemlandschaft analysieren: Wenn viele Altsysteme vorhanden sind, die keine modernen Schnittstellen haben, könnte eine On-Premises-Lösung mit traditionelleren Integrationsmethoden (ODBC, Dateidrehscheiben etc.) unter Umständen leichter anzubinden sein. Für Cloud spricht hingegen, dass viele neue Technologien (z. B. Smart Building Plattformen, KI-Services) als Cloud-Dienste verfügbar sind, die sich gut mit SaaS-C AFM kombinieren lassen.

• Innovationszyklen: Hier gibt es einen deutlichen Unterschied. SaaS-Lösungen werden meist in kurzen Zyklen weiterentwickelt – man erhält kontinuierlich neue Features und Verbesserungen, oft in monatlichen oder quartalsweisen Releases. Das hält die Software funktional auf dem neuesten Stand und ermöglicht es, Innovationen (z. B. neue Mobil-Apps, Analytics-Funktionen) schnell zu nutzen. Für den Kunden entfällt der Migrationsaufwand auf neue Versionen; stattdessen wird die Lösung z. B. über Nacht automatisch aktualisiert. Allerdings hat der Kunde wenig Kontrolle über den Zeitpunkt von Änderungen – er muss sich dem Takt des Anbieters anpassen. Gute SaaS-Anbieter beziehen die Kunden in die Release-Planung ein und bieten z. B. Early Access oder konfigurierbare Update-Zeitfenster, aber letztlich kommen Updates regelmäßig und erfordern eine hohe Anpassungsfähigkeit der Organisation. Demgegenüber stehen On-Premises-Lösungen, bei denen der Kunde die Hoheit über Updates hat. Man entscheidet selbst, wann eine neue Version eingespielt wird – oft wartet man auf einen günstigen Zeitpunkt oder überspringt auch mal eine Version. Das kann Vorteile haben (Updates können intern getestet werden, man überspringt evtl. eine instabile Version), führt aber häufig dazu, dass innovative Neuerungen erst spät oder gar nicht genutzt werden. Viele On-Prem-Installationen verharren über Jahre auf dem gleichen Stand, was im Laufe der Zeit zu Technologieveraltung führen kann. Zudem sind große Versionssprünge auf einmal nötig, die Anwender stark fordern (viele neue Funktionen auf einmal, Schulungsbedarf) – das überfordert Nutzer oft, wie Praxiserfahrungen zeigen. Cloud-Lösungen erlauben hingegen kleinschrittige Verbesserungen im laufenden Betrieb, was die Akzeptanz fördern kann, da das System organisch mit den Anforderungen wächst. Zusammengefasst: Wer Wert auf ständige Innovation und aktuelle Technologie legt, ist mit SaaS besser bedient; wer hingegen Stabilität und Versionshoheit priorisiert (z. B. wegen vieler Eigenanpassungen), bevorzugt evtl. On-Premises mit selektiven Updates.

• Infrastrukturverantwortung: Dieser Aspekt betrifft die Frage, wer sich um die technische Plattform kümmert. Bei On-Premises trägt das Unternehmen die volle Verantwortung für die Server-Hardware, das Betriebssystem, Datenbank, Netzwerk und alle Infrastruktur-Komponenten. Die internen oder extern beauftragten IT-Teams müssen sich um Beschaffung, Betrieb und Wartung dieser Infrastruktur kümmern – von Firmware-Updates über Speicherkapazitätsplanung bis zur Überwachung der Serverleistung. Das erfordert eine breite Expertise und personelle Ressourcen, schlägt aber auch in Kosten und Aufwand zu Buche (wie im Wirtschaftsteil beschrieben). Cloud/SaaS entlastet in diesem Punkt deutlich: Die Infrastruktur wird vom Anbieter bereitgestellt und gemanagt. Dinge wie Server-Provisionierung, Datenbank-Tuning, Netzwerkkonfiguration, Skalierung der Hardware erfolgen im Hintergrund automatisch oder durch das Operations-Team des Providers. Für den Kunden reduziert sich der Verantwortungsbereich auf die Anwendungskonfiguration und Nutzung. Das heißt, das interne Team kann sich auf fachliche Themen konzentrieren (z. B. Datenpflege, Berichtswesen, Prozessanpassungen im Tool) anstatt auf IT-Basisarbeiten. Dieses Outsourcing der Infrastruktur ist einer der Hauptgründe, warum Cloud-Angebote attraktiv sind, gerade wenn IT-Personal knapp ist. Allerdings gibt man damit auch die technische Souveränität ab – man kann z. B. nicht mehr eigenmächtig entscheiden, auf welchem konkreten Server die Datenbank läuft oder welche Hardware eingesetzt wird. Meist ist das unproblematisch, da Anbieter performante Umgebungen stellen. Trotzdem sollte man sich bewusst sein: In Cloud- und SaaS-Szenarien ist man in gewissem Maße vom technischen Vorgehen des Dienstleisters abhängig. Daher empfiehlt es sich, hohe Anforderungen an die Professionalität des Anbieters zu stellen (Zertifizierungen, Referenzen) und ggf. Audit-Rechte zu vereinbaren, um Einblick in den Betriebsstatus zu erhalten.

• Performance und Skalierung sind ebenfalls technische Kriterien. On-Premises kann man die Performance durch entsprechend dimensionierte Hardware sehr gut beeinflussen – man richtet die Umgebung so aus, dass auch Lastspitzen intern bewältigt werden. Bei SaaS hat man darauf indirekten Einfluss (durch die gewählte Subscription-Größe oder vertragliche Zusicherungen), aber grundsätzlich gewährleistet der Anbieter eine gewisse Performance bei normaler Nutzung. Wenn ein Unternehmen sehr spezielle Lastprofile hat (z. B. täglich Millionen Sensordaten, extreme Peaks), muss geprüft werden, ob der Anbieter dies leisten kann oder ob On-Premises mit Spezialhardware evtl. besser geeignet ist. In der Regel sind Cloud-Anbieter jedoch gut auf Skalierung vorbereitet und können durch verteilte Architekturen und Lastverteilung eine hohe Performance sicherstellen, ohne dass der Kunde einzelne Komponenten aufrüsten muss. Wichtig ist hier, realistische Lasttests und Anforderungen zu definieren, egal bei welchem Modell.

• Technische Abhängigkeiten: On-Premises-Software erfordert oft eine bestimmte Umgebung (Betriebssystem-Version, Datenbanktyp etc.). Diese Abhängigkeiten muss das Unternehmen managen – etwa Updates des Betriebssystems nur durchführen, wenn die CAFM-Software sie unterstützt, usw. Bei SaaS hält der Anbieter die Umgebung kompatibel; diese Problematik entfällt für den Kunden. Dafür ist man aber auch auf Gedeih und Verderb an die technische Roadmap des Anbieters gebunden – z. B. wenn der Anbieter beschließt, auf eine neue Technologie zu migrieren, zieht man als Kunde zwangsläufig mit, während man On-Prem evtl. länger auf Bewährtem bleiben könnte.

• Insgesamt gilt: Technisch ist SaaS/Cloud einfacher in Betrieb zu nehmen, integrativ oft gut aufgestellt (wenn auch über Webschnittstellen) und entlastet von Infrastrukturarbeit, während On-Premises höhere Kontrolle über Technikdetails ermöglicht und bestehenden internen Strukturen angepasst werden kann. Die Innovationsdynamik spricht meist für SaaS, während Integrations-Sonderfälle teils für On-Premises sprechen – hier kommt es auf die konkrete IT-Landschaft und Zukunftsstrategie des Unternehmens an.

Die Wahl des Betriebsmodells schlägt sich auch in den vertraglichen Vereinbarungen mit dem Softwareanbieter bzw. Dienstleister nieder. SaaS-Verträge unterscheiden sich deutlich von klassischen Softwarekaufverträgen. In Deutschland werden SaaS-Verträge rechtlich als Mietverträge bzw. mietähnliche Verträge eingeordnet. Das heißt, der Anbieter schuldet dem Kunden die Gebrauchsüberlassung der Software in einem zum vertragsgemäßen Gebrauch geeigneten Zustand während der Vertragslaufzeit. Folglich ist der Anbieter verantwortlich, die Lösung stets funktionsfähig und aktuell zu halten (Softwarepflege ist hier inkludiert). On-Premises-Lizenzverträge dagegen sind eher dem Kaufrecht zuzuordnen – das Nutzungsrecht wird dauerhaft eingeräumt, und separat gibt es Wartungsverträge für Updates/Support.

Für den Kunden bedeutet dies bei SaaS: Er hat i.d.R. ein dauerhaftes Kündigungsrecht nach Ablauf vereinbarter Mindestlaufzeiten (z. B. jährlich kündbar), während ein Softwarekauf unwiderruflich ist, aber natürlich keinen weiteren Zugang des Anbieters erfordert. Ein wichtiger Punkt ist, dass SaaS zeitlich befristet ist – ein Unternehmen muss daher Plan B haben, was nach Vertragsende mit den Daten und Prozessen geschieht. Gerade bei unternehmenskritischen Anwendungen wie einem zentralen CAFM sollte frühzeitig über eine Exit-Strategie nachgedacht werden. Empfohlen ist, vertraglich Exit-Klauseln zu verankern, die regeln, wie im Kündigungsfall verfahren wird: z. B. dass der Anbieter die Daten in einem definierten Format herausgibt, bei der Migration zu einem anderen System unterstützt und die Daten beim Anbieter anschließend gelöscht werden. Manche Anbieter bieten auch Escrow-Lösungen oder zeitweilige Read-Only-Zugänge nach Kündigung, um Übergangsphasen zu erleichtern – solche Punkte kann man im Vertrag festhalten.

Ein weiterer zentraler Vertragsaspekt sind Service Level Agreements (SLAs) für Cloud-Services. Während bei On-Premises der Kunde selbst für Verfügbarkeit sorgen muss (ein Anbieter kann höchstens für Support-Reaktionszeiten garantieren), wird bei SaaS/Hosting der Betrieb als Leistung geschuldet. Daher sollten Verfügbarkeitszusagen im Vertrag stehen, etwa eine uptime von z. B. 99,5 % im Jahresmittel. Wichtig ist auch, Konsequenzen bei SLA-Verletzungen zu regeln (sog. Servicegutschriften oder Kündigungsrechte bei gravierenden Verstößen). Im Vertrag sollten konkrete Wartungsfenster definiert sein, in denen Downtime zulässig ist, damit der Kunde planen kann. Für On-Premises wird es solche Verfügbarkeitsgarantien nicht geben – hier obliegt es dem internen Betrieb oder ggf. einem Hostingpartner, entsprechende Ziele zu erfüllen.

Bezüglich Datenschutz und Datensicherheit muss im Vertrag der Cloud-Betrieb ebenfalls abgebildet werden. Wie oben beschrieben, ist bei Verarbeitung personenbezogener Daten eine Auftragsverarbeitungsvereinbarung (AVV) unerlässlich. Darin sollte u.a. festgelegt sein, welche technischen und organisatorischen Maßnahmen der Anbieter ergreift (idealerweise verweist man auf anerkannte Sicherheitsstandards, die der Anbieter erfüllt). Wenn der Anbieter außerhalb der EU sitzt oder Daten in Drittstaaten überträgt, müssen die entsprechenden Klauseln (SCC) integriert werden. Datensicherheit sollte ebenfalls ausdrücklich adressiert sein: Ein guter SaaS-Vertrag enthält Zusicherungen zur Informationssicherheit (z. B. Verpflichtung des Anbieters auf ISO 27001 oder vergleichbare Standards), zur Vertraulichkeit (Geheimhaltungsvereinbarung, Verpflichtung der Mitarbeiter) und zum Vorgehen bei Sicherheitsvorfällen (Meldepflicht an den Kunden innerhalb bestimmter Fristen etc.). Für KRITIS-relevante Kunden könnten zusätzliche Klauseln nötig sein, etwa dass der Anbieter beim BSI registriert ist oder bestimmte Audit-Rechte einräumt.

Auch Haftungsfragen und Gewährleistung unterscheiden sich: Bei SaaS haftet der Anbieter für die Bereitstellung der Software als Service. Oft versucht er, die Haftung vertraglich zu begrenzen (z. B. auf einen Vielfachen des Jahresbetrags). Der Kunde sollte prüfen, ob diese Limits akzeptabel sind – gerade wenn durch Ausfälle hohe Schäden entstehen könnten. Bei On-Premises liegt die Haftung des Anbieters meist nur in der Mangelfreiheit der gelieferten Software zum Zeitpunkt der Übergabe. Spätere Probleme sind dann über Wartungsverträge abgedeckt (Bugfixing), aber ein genereller Ausfall des selbst betriebenen Systems fällt nicht in die Haftung des Herstellers. Hier muss das Unternehmen sich selbst absichern.

Lizenzmodelle und Vertragslaufzeiten: On-Premises wird häufig mit unbefristeten Lizenzen verkauft, dazu Wartung jährlich kündbar. SaaS hingegen hat befristete Nutzungsrechte, gebunden an Vertragslaufzeiten (oft 1–3 Jahre). Man sollte auf ausgewogene Verlängerungsbedingungen achten – z. B. automatische Verlängerung um ein Jahr, aber mit rechtzeitiger Kündigungsmöglichkeit – und auf transparente Preisgleitklauseln für Verlängerungen (damit es keine Überraschungspreise nach der ersten Periode gibt). Bei Preisstaffeln (etwa abhängig von Nutzeranzahl oder Umfang) ist klarzustellen, wie Mehr- oder Minderbedarf während der Laufzeit abgerechnet wird.

Ein oft unterschätztes Thema ist die Nutzungsrechte/Gerätestandort-Klausel bei On-Premises: Manche Software darf per Lizenzvertrag nur auf bestimmten Servern oder nur innerhalb eines Landes betrieben werden. Wenn man etwa später doch in Cloud (IaaS) migrieren will, muss geprüft werden, ob der Lizenzvertrag das zulässt. Bei SaaS stellt sich diese Frage nicht, da hier der Anbieter für Lizenzkonformität sorgt, aber bei On-Premises-Lizenzen sollten solche Restriktionen verhandelt werden (z. B. globale Nutzungsrechte, VM-Verschiebbarkeit etc.).

• SaaS/Cloud-Vertrag: Enthält Leistungsbeschreibung der Dienste, SLA für Verfügbarkeit und Support, klare Datenschutzregelungen (AV-Vertrag, Datenort, Unterauftragsnehmer), Vereinbarungen zur Datensicherheit (z. B. Zertifizierungen), Exit-Klauseln für Datenherausgabe, Haftungs- und Rechtswahlklauseln passend zum internationalen Kontext, und ggf. spezielle Branchenanforderungen. Da der SaaS-Vertrag einem Mietvertrag gleicht, sind Bestimmungen wie Mängelbeseitigung, Kündigungsfristen, Vertragsstrafen bei Ausfall etc. relevant.

• On-Premises-Vertrag: Lizenzvertrag über die Software (ggf. unbefristet), plus Wartungsvertrag. Wichtige Punkte: Umfang der Nutzungsrechte (z. B. Anzahl Benutzer, Standorte), Updates/Upgrades (sind neue Versionen im Wartungsentgelt enthalten?), Support-Level (Reaktionszeiten bei Störungsmeldungen, aber keine Verfügbarkeitsgarantie), Haftung/Gewährleistung für Softwaremängel, und Mitwirkungspflichten des Kunden (z. B. dass Umgebungsvoraussetzungen erfüllt sein müssen). Zudem sollte geregelt sein, was passiert, wenn der Hersteller einen Support-Ende für die Version ankündigt – Upgrademöglichkeiten etc.

• Hosting-Vertrag (bei Private Cloud oder externem Rechenzentrum): Falls ein separater Hoster involviert ist, braucht es einen Vertrag über die Infrastrukturleistungen. Darin enthalten: Verfügbarkeitszusagen fürs Hosting (Strom, Netzwerk), Backup-Services, Datensicherheitsmaßnahmen im RZ, sowie Zugriffsrechte (wer darf aufs System – der Hoster meist nicht auf die Applikationsebene ohne Zustimmung). Oft kommen hier ebenfalls AVV und SLA ins Spiel, analog zu SaaS.

Generell ist ratsam, früh mit der Rechtsabteilung oder einem spezialisierten Anwalt die Vertragsimplikationen je Modell abzuklären. Die rechtlichen Rahmenbedingungen ändern sich durch Cloud erheblich – vom Gewährleistungsrecht (Miete statt Kauf) bis zu neuen Compliance-Pflichten (z. B. Meldung von Datenpannen durch den Dienstleister). Wie so oft muss eine ausgewogene Lösung gefunden werden, die technische, kaufmännische und rechtliche Aspekte in Einklang bringt.

Angesichts der vielfältigen Kriterien empfiehlt es sich, für die Hostingentscheidung einen strukturierten Entscheidungsprozess aufzusetzen.

• Kriterienkatalog erstellen: Zunächst sollten alle für das Unternehmen relevanten Entscheidungsfaktoren gesammelt werden. Typische Kriterien sind z. B.: Strategische Passung (Cloud-Strategie vs. Kontrollbedürfnis), Datenschutz/Compliance (DSGVO, interne Policies, Zertifizierungsanforderungen), Kosten/TCO (über 5–10 Jahre), Funktionale Anforderungen (Customization, Integrationen, spezielle Features), Technische Aspekte (Performance, Offline-Fähigkeit, mobile Nutzung), Ressourcenverfügbarkeit (IT-Personal, Know-how), Risiken (Lock-in, Ausfallrisiko, Sicherheit) und Marktreife der Optionen (Bewertung der Anbieter, Zukunftssicherheit). Dieser Katalog sollte in Workshops mit allen Stakeholdern entstehen – also unter Einbindung von IT, Fachbereich (Facility Management), Datenschutzbeauftragtem, Compliance, evtl. Einkauf und Management.

• Bewertungsmatrix aufbauen: Für eine transparente Entscheidung kann man eine Matrix nutzen, in der die Kriterien gewichtet und die Modelle gegeneinander bewertet werden. Beispielsweise listet man alle Kriterien in Zeilen, gibt jeder eine Gewichtung (z. B. 1–5 nach Wichtigkeit) und bewertet dann jede Option (SaaS, Private Cloud, On-Prem) z. B. mit Schulnoten oder Punktzahlen pro Kriterium. Durch Multiplikation mit der Gewichtung und Summierung erhält man eine numerische Tendenz. Eine solche Matrix macht Annahmen explizit und erleichtert den Vergleich. Wichtig ist, objektiv nachvollziehbare Maßstäbe anzulegen – z. B. kann man Kosten konkret berechnen, Compliance in „erfüllt/teilweise/risikobehaftet“ einstufen, etc. Die Matrix sollte auch qualitative Begründungen enthalten, nicht nur Zahlen, um die Diskussion zu unterstützen.

• Szenarien berücksichtigen: Neben der Momentaufnahme ist es sinnvoll, verschiedene Zukunftsszenarien durchzuspielen. Was wäre zum Beispiel, wenn das Unternehmen stark wächst (Expansion auf neue Standorte, Nutzerzahlen verdoppeln sich)? Wie schlagen sich die Modelle in diesem Szenario (Skalierung, Performance, Kosten)? Oder Szenario „Regulatorik verschärft sich“ – z. B. neue Datenschutzgesetze verbieten bestimmte Cloud-Aspekte, oder Audits werden häufiger: Ist man mit dem gewählten Modell zukunftssicher? Auch Worst-Case-Szenarien sollte man betrachten, etwa: Was, wenn der Cloud-Anbieter einen schweren Sicherheitsvorfall hat oder insolvent wird? Was, wenn On-Premises ausfällt und internes Personal nicht in der Lage ist, das System schnell wiederherzustellen? Durch solche Was-wäre-wenn-Analysen lassen sich die Robustheit und Risiken der Alternativen besser vergleichen. Oft hilft es, ein best case-, expected case- und worst case-Szenario für jede Option zu skizzieren.

• Risikobewertung und -abwägung: Jedes Modell bringt spezifische Risiken mit, wie schon diskutiert. Diese sollten systematisch identifiziert und bewertet werden. Beispielsweise: Datenschutzrisiko bei Cloud (Bewertung: mittel, aber mitigierbar durch EU-Hosting und Vertrag), Betriebsrisiko bei On-Prem (Bewertung: hoch, da kleines IT-Team, mitigierbar durch externe Dienstleister?), Lock-in bei SaaS (Bewertung: mittel, mitigierbar durch Exit-Vereinbarung und Standard-Schnittstellen), Technologieveraltungsrisiko bei On-Prem (Bewertung: hoch, mitigierbar durch Wartungsvertrag und Upgrade-Plan). Für jedes identifizierte Risiko sollte überlegt werden, wie wahrscheinlich es ist und welche Auswirkungen es hätte. Diese Risikoanalyse fließt in die Entscheidung ein, indem man prüft, welche Option das geringste Restrisiko für die Geschäftsziele bietet bzw. wie man Risiken kompensieren kann.

• Pilotierung und Referenzen: Bei Unsicherheit kann eine Pilotphase sinnvoll sein – z. B. einen Proof-of-Concept mit der SaaS-Lösung im kleinen Umfang durchführen, um Erfahrungen zu sammeln, oder einen Testbetrieb On-Premises einrichten, um zu sehen, welcher Aufwand tatsächlich entsteht. Außerdem lohnt der Blick auf Referenzen: Wie handhaben ähnliche Unternehmen (Branche/Größe) diese Entscheidung? Gibt es Erfolgsgeschichten für das eine oder andere Modell? Der Austausch mit externen Experten oder Beratern kann weitere Perspektiven liefern.

• Entscheidungsfindung dokumentieren: Sobald die Bewertungsmatrix und Analysen vorliegen, sollte das Entscheidungsteam die Ergebnisse gemeinsam auswerten. Meist kristallisiert sich eine Favoriten-Option heraus, aber falls nicht eindeutig, können weitere Informationen eingeholt werden. Wichtig ist, die Gründe für die Empfehlung klar zu dokumentieren – so kann das Management die Entscheidung nachvollziehen und absegnen. Kriterien mit knappem Abstand sollten hervorgehoben und ggf. durch Management-Präferenzen entschieden werden (z. B. wenn Cloud und On-Prem fast gleichauf liegen, könnte eine strategische Cloud-Ausrichtung den Ausschlag geben).

In der Praxis zeigt sich, dass die beste Lösung individuell verschieden sein kann. Viele Unternehmen tendieren heute zur Cloud/SaaS-Lösung wegen der Flexibilität, schnelleren Wertschöpfung und geringeren IT-Belastung, sofern Datenschutz und Compliance handhabbar sind. Andere – insbesondere in sensiblen Bereichen – entscheiden sich bewusst für On-Premises, um volle Kontrolle zu behalten, nehmen dafür aber höhere Kosten und Aufwand in Kauf. Ein Mittelweg über dediziertes Hosting kann gewisse Vorteile beider Seiten kombinieren, verlangt aber ebenfalls genaue Absprachen.

Nicht allein die IT oder allein der Fachbereich sollten dominieren, sondern alle Blickwinkel (strategisch, technisch, wirtschaftlich, rechtlich) müssen berücksichtigt werden. Nur so gelingt eine ausgewogene Wahl, die langfristig trägt. Eine regelmäßige Überprüfung der Entscheidung (z. B. alle 3–5 Jahre) ist ebenfalls empfehlenswert – die Entwicklungen in Technik und Markt gehen rasant, was heute optimal ist, könnte in einigen Jahren neu bewertet werden müssen. Mit einer sauberen Dokumentation und einer bewussten Abwägung der genannten Aspekte legt man jedoch jetzt den Grundstein für einen erfolgreichen CAFM-Betrieb im passenden Modell.

Die Betriebs- und Hostingentscheidung sollte strukturiert und faktenbasiert erfolgen. Eine Bewertungsmatrix mit gewichteten Kriterien, das Durchspielen von Szenarien und eine sorgfältige Risikoabwägung helfen, Transparenz zu schaffen. Letztlich gibt es keine Patentlösung – die beste Wahl ist die, welche die Anforderungen und Risiken Ihres spezifischen Umfelds am ausgewogensten erfüllt. Indem man alle strategischen, technischen, wirtschaftlichen und Compliance-Aspekte einbezieht, trifft man eine fundierte Entscheidung, die sich vor Stakeholdern und Prüfern gleichermaßen vertreten lässt.