Der gefährliche Tenant-Fehler

Serie: Wenn Infrastrukturprojekte entgleisen

Teil 5: Der gefährliche Tenant-Fehler

Zu diesem Zeitpunkt lief das Projekt noch.

Formal.

Es gab Fortschritt. Es gab Ergebnisse. Es gab Systeme, die funktionierten.

Und genau das machte es so gefährlich.

---

Was niemand hinterfragt hat

Der Dienstleister hatte geliefert.

Infrastruktur wurde aufgebaut. Services wurden eingeführt. Plattformen wurden bereitgestellt.

Alles schien in Bewegung.

Was niemand wirklich hinterfragt hat:

Wem gehört das eigentlich alles?

---

Der Moment der Erkenntnis

Die Antwort kam nicht in einem grossen Meeting.

Nicht in einer Eskalation.

Sondern in einem Detail.

Der M365-Tenant war korrekt benannt. Sauber eingerichtet. Technisch unauffällig.

Und trotzdem stimmte etwas nicht.

Der erste Global Admin – die zentrale Identität des Tenants – lief auf die E-Mail-Adresse des CEOs des Dienstleisters.

Nicht auf den Kunden.

---

Und es blieb nicht bei M365

Parallel dazu wurde ServiceNow eingeführt.

Nicht als eigenständige Plattform des Kunden.

Sondern als Teil der bestehenden Umgebung des Dienstleisters.

Der Kunde war kein Betreiber.

Er war ein Sub-Tenant.

---

Was das bedeutet

Zu diesem Zeitpunkt war das Projekt längst kein Infrastrukturprojekt mehr.

Es war ein Abhängigkeitsmodell.

Der Zugriff auf zentrale Systeme lag nicht mehr beim Auftraggeber. Sondern beim Dienstleister.

Identitäten. Zugriffe. Prozesse.

Alles lief über Plattformen, die nicht unter der Kontrolle des Unternehmens standen.

---

Der eigentliche Fehler

Das Problem war nicht die Cloud.

Nicht Microsoft. Nicht ServiceNow.

Der Fehler war grundlegender:

Niemand hatte definiert, wem die Plattform gehört.

---

Der Moment, in dem es real wurde

Solange alles funktioniert, fällt das nicht auf.

Es wirkt effizient. Schnell. Pragmatisch.

Bis zu dem Moment, in dem sich die Interessen ändern.

Zum Beispiel dann, wenn man sich vom Dienstleister trennen muss.

Der Zugriff auf den Tenant wird zum Thema.

Die Übergabe wird zur Verhandlung.

Und plötzlich ist man in einer Situation, in der man nicht mehr vollständig über die eigene Umgebung bestimmen kann.

In diesem Fall endete das nicht technisch. Sondern juristisch. Mit umfangreichen Diskussionen und einer aussergerichtlichen Einigung. Die Rückgabe der Kontrolle hatte ihren Preis.

---

Der entscheidende Punkt

Wer den Tenant kontrolliert, kontrolliert mehr als nur die IT.

Er kontrolliert Identitäten. Zugriffe. Prozesse.

Und damit einen wesentlichen Teil des Unternehmens.

---

Warum das passieren konnte

Weil vorher alles andere bereits schiefgelaufen war:

Keine sauberen Requirements. Schwache Projektführung. Ein Dienstleister ohne klare Steuerung. Ein Projektsponsor, der faktisch nicht mehr da war.

Der Tenant-Fehler war kein Einzelfehler.

Er war die logische Konsequenz.

---

Schluss

Infrastruktur kann man ersetzen.
Systeme kann man migrieren.

Verlorene Kontrolle zurückzugewinnen, ist immer aufwendig.

Und meistens sehr teuer.

---

Teil der Serie: Wenn Infrastrukturprojekte entgleisen

Teil 1 – Der Irrtum vom reinen Infrastrukturprojekt

Teil 2 – Wenn Requirements Management fehlt

Teil 3 – Wenn der Dienstleister das Projekt führt

Teil 4 – Wenn der Projektsponsor verschwindet

Teil 5 – Der gefährliche Tenant-Fehler