Gemietete Software wird riskant, wenn der Ausstieg fehlt

Ein neuer Softwaredienst aus der Cloud ist schnell gebucht. Der Fachbereich bekommt Funktionen, die IT muss keine Server bereitstellen, und die Einführung wirkt auf den ersten Blick leichter als ein klassisches Projekt. Doch genau diese Geschwindigkeit kann später teuer werden. Wenn niemand vor Vertragsabschluss klärt, wie Daten, Rollen, Schnittstellen und Arbeitsabläufe wieder herauskommen, wird aus bequemer Software eine schwer steuerbare Abhängigkeit.

Für ITSM- und IT-Management-Verantwortliche ist das keine reine Einkaufsfrage. Ein SaaS-Dienst, also gemietete Software, die über das Internet genutzt wird, berührt Servicekatalog, Support, Datenschutz, Berechtigungen, Kostenkontrolle und Notfallplanung. Die wichtigste Frage lautet deshalb nicht nur, ob der Dienst heute funktioniert. Entscheidend ist, ob die Organisation ihn morgen wechseln, stilllegen oder in eine andere Lösung überführen kann, ohne den Betrieb zu blockieren.

Bequemlichkeit darf nicht mit Kontrolle verwechselt werden

SaaS kann den IT-Betrieb spürbar entlasten. Updates kommen vom Anbieter, Kapazitäten wachsen flexibler, neue Funktionen stehen oft schneller bereit. Das ist ein echter Nutzen. Er ersetzt aber nicht die Steuerung des Services. Wer einen Dienst nutzt, übergibt nicht automatisch die Verantwortung für Verfügbarkeit, Datenqualität, Zugriffe, Eskalation und Geschäftsauswirkungen.

Die Cloud Security Principles des britischen National Cyber Security Centre betonen, dass Organisationen verstehen müssen, wie Dienste geschützt, betrieben und in die eigene Verantwortung eingebettet werden. CISA beschreibt in ihrer Cloud Security Technical Reference Architecture ebenfalls, dass Cloud-Nutzung klare Rollen, Identitäten, Datenflüsse und Kontrollpunkte braucht. Für Generalisten heißt das praktisch. Auch ein externer Dienst muss wie ein interner Service geführt werden, wenn er für Arbeitsabläufe kritisch wird.

Der Datenexport ist kein Nebensatz im Vertrag

Der erste Schwachpunkt zeigt sich oft beim Datenexport. Solange der Dienst wächst, interessiert vor allem, welche Informationen hineinkommen. Kundendaten, Tickets, Dokumente, Freigaben, Kommentare, Audit-Spuren oder Konfigurationsstände. Beim Ausstieg zählt die Gegenrichtung. Welche Daten lassen sich vollständig exportieren. In welchem Format. Mit welchen Anhängen. Mit welcher Historie. Mit welchen Zeitstempeln und Berechtigungsinformationen.

Ein CSV-Export kann für einfache Listen reichen. Für komplexe Services ist er häufig zu wenig. Wenn Beziehungen zwischen Objekten, Workflows, Genehmigungen oder Nachweise verloren gehen, bleibt zwar eine Datei übrig, aber kein sauber nutzbarer Betriebsstand. Darum gehört der Exporttest nicht ans Vertragsende. Er gehört in die Einführung. Ein kleines Testpaket mit realistischen Datentypen zeigt früh, ob ein späterer Wechsel nur theoretisch oder wirklich machbar ist.

Supportwege müssen vor dem Ausfall klar sein

Ein SaaS-Ausfall trifft die eigene Organisation, auch wenn die technische Ursache beim Anbieter liegt. Nutzer rufen trotzdem den internen Service Desk an. Führungskräfte erwarten eine Einschätzung. Fachbereiche wollen wissen, ob sie warten, ausweichen oder manuell weiterarbeiten sollen. Wenn dann erst gesucht wird, welcher Supportvertrag gilt und wer beim Anbieter eskaliert, ist der Betrieb zu spät dran.

Jeder kritische SaaS-Dienst braucht deshalb einen verständlichen Betriebssteckbrief. Darin stehen Service Owner, fachlicher Ansprechpartner, Anbieter-Supportweg, Eskalationszeiten, bekannte Abhängigkeiten, Statusseiten, Kommunikationsbausteine und Ersatzverfahren. Das muss nicht kompliziert sein. Wichtig ist, dass der Service Desk im Ernstfall nicht nur einen Link zum Anbieterstatus kennt, sondern erklären kann, was die Störung für die eigenen Nutzer bedeutet.

Schnittstellen entscheiden über die echte Wechselbarkeit

Die stärkste Bindung entsteht selten durch die Anwendung allein. Sie entsteht durch Verknüpfungen. Ein SaaS-Dienst hängt an Single Sign-on, Berechtigungsgruppen, Schnittstellen zu Finanzsystemen, Datenimporten, Automatisierungen, Berichtswesen, Archivierung oder anderen Cloud-Diensten. Jede Verbindung macht den Dienst nützlicher. Jede Verbindung macht den Ausstieg schwerer, wenn sie nicht dokumentiert ist.

NIST beschreibt in seiner Cloud-Computing-Synopse unter anderem Portabilität und Interoperabilität als zentrale Themen bei Cloud-Services. Für den ITSM-Alltag bedeutet das. Wer Wechselbarkeit will, muss Abhängigkeiten sichtbar halten. Welche Systeme schreiben Daten in den Dienst. Welche Systeme lesen daraus. Welche Automatisierungen brechen, wenn die Schnittstelle abgeschaltet wird. Welche Identitäten und Gruppen steuern den Zugriff. Ohne diese Übersicht ist ein Anbieterwechsel kein Projekt, sondern eine Entdeckungsreise unter Zeitdruck.

Kostenkontrolle gehört zum Servicebetrieb

SaaS-Kosten wachsen oft leise. Ein paar zusätzliche Nutzer, ein größeres Paket, ein weiteres Modul, eine zweite Umgebung, ein höheres Datenvolumen. Für den Fachbereich wirkt das flexibel. Für das IT-Management wird es riskant, wenn niemand die Nutzung gegen den tatsächlichen Nutzen prüft. Dann bleibt der Dienst im Portfolio, obwohl Funktionen doppelt vorhanden sind oder Lizenzen kaum genutzt werden.

Ein guter Betriebsprozess verbindet deshalb technische und kaufmännische Sicht. Welche Nutzer sind aktiv. Welche Rollen sind überprivilegiert. Welche Daten liegen im Dienst. Welche Fachbereiche hängen daran. Welche Kündigungsfristen gelten. Welche Alternative wäre realistisch. Diese Fragen gehören nicht erst in eine Sparrunde. Sie gehören in die regelmäßige Servicebewertung, weil sie Verfügbarkeit, Sicherheit und Budget gleichzeitig betreffen.

Ein Ausstiegsplan muss nicht groß sein

Der Ausstiegsplan für einen SaaS-Dienst kann klein beginnen. Er beschreibt, welche Daten exportiert werden müssen, wer den Export testet, welche Schnittstellen betroffen sind, welche Nutzergruppen informiert werden, welche Ersatzlösung vorbereitet ist und wie lange der Parallelbetrieb dauern darf. Je kritischer der Dienst, desto genauer muss dieser Plan werden. Für weniger kritische Anwendungen reicht oft eine kurze Checkliste.

Wichtig ist die Reihenfolge. Der Plan entsteht nicht erst, wenn der Anbieter Preise erhöht, Funktionen ändert, Sicherheitsfragen offen bleiben oder der Vertrag endet. Dann ist der Handlungsspielraum klein. Ein früher Ausstiegsplan schafft dagegen Verhandlungsmacht. Er macht sichtbar, welche Punkte im Vertrag, in der technischen Architektur und im Servicekatalog wirklich wichtig sind.

Was ITSM-Verantwortliche jetzt prüfen sollten

Ein pragmatischer Einstieg ist eine Bestandsaufnahme der wichtigsten SaaS-Dienste. Welcher Dienst ist für welchen Geschäftsprozess kritisch. Wer ist Service Owner. Wo liegen die wichtigsten Daten. Gibt es einen getesteten Export. Sind Supportweg und Eskalation dokumentiert. Welche Schnittstellen hängen daran. Welche Kündigungsfrist gilt. Gibt es eine einfache Ersatz- oder Übergangslösung.

Diese Fragen wirken unspektakulär. Genau deshalb werden sie leicht übersehen. Ihr Nutzen zeigt sich erst, wenn ein Anbieter ausfällt, ein Vertrag neu verhandelt wird oder eine Plattform abgelöst werden muss. Dann entscheidet nicht die schönste Funktionsliste, sondern die vorbereitete Handlungsfähigkeit. Gemietete Software bleibt nur dann bequem, wenn der Betrieb den Ausgang kennt.

Quellen. National Cyber Security Centre, Cloud Security Principles. CISA, Cloud Security Technical Reference Architecture. NIST Special Publication 800-146, Cloud Computing Synopsis and Recommendations.