Technologisch betrachtet, gibt es immer weniger Zweifel. Cloud-Transformation macht Sinn. Warum scheitern aber trotzdem so viele Cloud-Projekte? Weil die Menschen nicht mitgenommen werden?
Wer sich als Unternehmen dafür entscheidet, einen Großteil seiner IT in die Cloud zu transformieren, braucht ein Cloud Operating Model. Das ist unumstritten. Doch wie sieht das passende Modell aus? Hier scheiden sich die Geister. Aus diesem Grund und wegen fehlenden Standardisierungsrichtlinien gibt es auch nicht nur das einzig wahre Cloud Operating Modell, sondern eine Vielzahl von Vorgehensmodellen. Warum scheitern laut verschiedenen Studien trotzdem mindestens die Hälfte der Transformationsprojekte oder bringen doch nicht die gewünschten Vorteile? Und manches Cloud-Projekt wird am Ende mit höheren Kosten konfrontiert und damit dem Gegenteil von dem, was die Cloud bringen sollte.
Technologie ist nicht alles
Gründe kann es mehrere geben. So sind die Erwartungen der Unternehmen und einzelner Abteilungen unangemessen hoch. Die Mehrzahl scheitert aber an der grundsätzlichen Ausrichtung der Cloud Operating Modelle, da sie die Transformation nahezu ausschließlich von der technologischen Seite aus betrachten. Was unter anderem daran liegt, dass sie überwiegend von den Cloud-Betreibern selbst entwickelt werden und aus Sicht von Hyperscalern wie Amazon, Google oder Microsoft steht verständlicherweise die Technologie im Vordergrund.
Doch Technologie ist nur eine Säule einer Transformation in die Cloud. Viele Unternehmen schaffen es inzwischen aus technologischer Sicht mehr oder weniger problemlos von der vorherigen OnPrem-Infrastruktur zu einem Hyperscaler zu wechseln. Dafür gibt es mehr als genug Best Practices für verschiedenste IT-Konstellationen und Branchen. Das oft böse Erwachen folgt später. Neue virtuelle Server in der Cloud zu buchen, ist einfach. Aber mit dem Wechsel vom eigenen Rechenzentrum in die Cloud muss sich die Organisation der IT und Fachbereiche der neuen Arbeitsweise und den neuen Möglichkeiten anpassen.
So haben viele Teams bis dahin nicht abteilungsübergreifend zusammengearbeitet – weil sie es nicht mussten oder es nicht gewünscht war. Daher brauchen IT-Teams zusätzliche Qualifikationen und nicht zuletzt stehen Governance-Aspekte auf dem Prüfstand. Wer diese Aspekte einer Transformation außer Acht lässt, scheitert nicht an der Technik, erreicht aber am Ende nicht die eigentlichen Ziele.
Zu viel in Silos denken und arbeiten
Die verspricht die Cloud aber gern: Unternehmen werden schneller sowie agiler und sie verkürzen Markteinführungszeiten neuer Produkte und Services deutlich. Virtuelle Maschinen, die sich mit einem Klick realisieren lassen, reichen dafür jedoch nicht aus. Wenn die IT-Teams weiter in ihren Silos arbeiten, ändert sich kaum etwas an der Arbeitsweise. Dies fängt damit an, wenn neue Ressourcen wie bisher per E-Mail an die IT-Abteilung über die klassischen Wege bestellt werden müssen. Oder Mitarbeiter müssen zahlreiche interne Hürden überwinden, damit sie auf dringend benötigte Ressourcen zugreifen können.
Solche Unternehmen verfügen nicht über eine angemessene operative und finanzielle Entkopplung, bei der die Teams über eigene Budgets verfügen und selbst bestimmen können, wie viel Geld sie zum Beispiel für das Prototyping oder die Bereitstellung von Produkten benötigen. Oder sie verfügen nicht über eine übergreifende Governance. Der Wandel ist also viel tiefgreifender im Sinne von Prozessen, die es den Teams ermöglichen, ihre eigenen Ressourcen zu verwalten. Cloud-Transformation muss also Silos auflösen und den Teams die Möglichkeit geben, nach eigenem Bedarf die Cloud zu nutzen und in der Cloud zu arbeiten. Selbstbedienung ersetzt zentral gesteuertes Lager.
IT und Fachbereiche brauchen zusätzliches Know-how
Neue Prozesse zu etablieren, fängt bei den IT-Abteilungen an. Waren vor der Cloud-Zeit IT-Teams allein schon damit ausgelastet, die eigene Infrastruktur einzurichten und zu managen, entfällt ein Großteil dieser Tätigkeiten – ob Rechenzentrumsverkabelung, Bestellung von Hardware und Netzwerkgeräten, der Zusammenbau, Patches und Upgrades. Man braucht nicht mehr eine ganze Abteilung, um sich mit solchen „handwerklichen“ Basisaufgaben zu befassen. Jetzt können DevOps-Ingenieure Codezeilen ausführen und die virtuelle Maschine zum Laufen bringen. Sie haben es nicht mehr mit Menschen zu tun, sondern mit APIs. Und die Komplexität, um eine Ressource zu erhalten, hat sich stark verringert.
Bisher waren IT-Teams stark auf ihr technisches Know-how fokussiert. Mit der Cloud muss sich deren Wissen um Geschäftsprozesse erweitern und zu einer Mischung aus IT- und Business-Know-how übergehen. Auf der anderen Seite brauchen die Businessprozess-Spezialisten aus den verschiedenen Fachbereichen der Unternehmen – Einkauf, Logistik, Produktion, Vertrieb etc. –mehr IT-Kenntnisse. Ansonsten bringt die Qualifikationslücke auf beiden Seiten Cloud-Projekte zum Scheitern
Vier Säulen des Cloud-Betriebsmodells
Wie sieht also ein erfolgreiches Cloud-Betriebsmodell aus? Es definiert, wie ein Unternehmen innerhalb des Cloud-Ökosystems aus Menschen, Prozessen und Technologie interagiert und Partner miteinbezieht. Dabei sollte das Betriebsmodell nicht nur die technischen Aspekte einer Cloud-Transformation abbilden. Es besteht aus den vier Säulen: Governance, Organisation und Kultur, Prozesse und Rollen, Skills und Tools.
Das Cloud-Governance-Modell bildet die Grundlage für die Interaktion aller Cloud-bezogenen Organisationseinheiten auf der Basis von Regeln und Richtlinien. Es bietet den Rahmen für die Bereitstellung und den Betrieb der Cloud, das Sicherheits- und Kostenmanagement sowie für das Management des Ökosystems einschließlich Partnerschaften.
Organisation und Kultur rückt den Menschen in den Mittelpunkt
Die Säule Organisation und Kultur definiert, wie das organisatorische Design und die Interaktion zwischen alle Cloud-Nutzern aussehen soll und wie sie effektiv und effizient interagiert. So verhindert eine auf starre Silos aufbauende Organisation, dass Unternehmen agiler handeln und entscheiden können. Silos führen dazu, dass eine Cloud-Transformation länger dauert oder sogar ganz scheitert. Häufig liegt dies an unterschiedlichen „Kultur“ innerhalb der einzelnen Silos. Dies führt zum Beispiel dazu, dass die Silos nicht miteinander kommunizieren.
Prozessarchitektur auf Agilität trimmen
Die Säule Prozessarchitektur basiert auf erfolgreichen Agilitätsprinzipien. Die Definition agiler Prozesse ist ein Schlüsselelement eines erfolgreichen Cloud-Betriebsmodells und bilden die Grundlage für die Schaffung von Mechanismen zur Prozessüberwachung und Qualitätssteuerung. Die Ursachen für fehlende Agilität von Prozessen sind in Unternehmen auf ähnliche Schwachstellen zurückzuführen. Unter anderem fehlen KPIs, die Auskunft über die Qualität einzelner Prozesse geben und die gegebenenfalls angepasst werden müssen. Dies geht sogar so weit, dass der Blick auf die Kundenzufriedenheit als absolute Zielgröße außer Acht gelassen wird.
Cloud-Skills trainieren und einfache Tools bereitstellen
Die vierte Säule „Rolle, Fertigkeiten und Werkzeuge“ stellt erneut den Menschen in den Fokus. Unabhängig von Product Owner, TechLeads oder DevOps werden hier Rollen klar definiert und kommuniziert und mit umfassenden Lern- und Schulungsmöglichkeiten ausgestattet. Meist fehlt es zu Beginn einer Cloud-Transformation in den Geschäftsbereichen außerhalb der IT an Business-bezogener Cloud-Kompetenz. Das bis dahin die IT-Kompetenz nahezu ausschließlich bei den IT-Teams lag, wissen die Fachbereiche wenig darüber, welche Optionen die Cloud ihnen bietet. Diese Cloud-Skill-Lücken müssen Unternehmen schließen.
Wie reif ist die Organisation für die Cloud?
Und wie lassen sich diese vier Säulen umsetzen? Zum Beispiel mit einem umfassenden Assessment, einem Cloud Maturity Check, in dem der Status Quo auf den Prüfstand kommt. Auf Basis der Ergebnisse dieses Checks lässt sich dann ein vorhandenes Cloud Operating Model redesignen oder ein geeignetes einführen, bevor es schließlich implementiert und ausgerollt wird.
Immer wieder zeigt sich in solchen Projekten, dass Unternehmen längst in der Cloud sind, es sogar formal ein Cloud Operating Model gibt, es aber nie angewendet wurde, obwohl es die Transformation nicht nur aus technischer Sicht betrachtet. Manche haben ein Modell auch schon ausprobiert, sind aber gescheitert. Wenn das passiert ist, wollen wir wissen, wie und warum es gescheitert ist. Vielleicht lag es nicht an dem Modell selbst. Nach dieser Vorarbeit entsteht eine Roadmap mit Zeitplan und realistischen Zielen. Typische Resultate, die aus ganzheitlich aufgebauten Cloud-Betriebsmodellen entstehen können, sind beispielsweise deutliche Richtlinien für Sicherheit und Kosten, klare KPI und Service Level und eine tragfähige Basis für agiles, flexibles, auch für die Zusammenarbeit mit Partnern ausgelegtes Handeln in der Cloud.
