Case Studies
Cloud Competence Center: Basis für den Cloud-Erfolg
– Fallbeispiel eines deutschen Mittelständlers –
Ausganslage
Zentrale Verantwortung in der IT ist gut – was ist aber, wenn diese nicht akzeptiert und umgangen wird?
Seit Jahren ist das Thema Cloud bei vielen unserer Kunden angekommen, so auch bei einem unserer mittelständischen Kunden aus dem Bereich Maschinenbau mit eingebundener Softwareentwicklung.
Die Nutzung der Cloud nimmt bei unserem Kunden seit Jahren kontinuierlich zu – neben Lösungen von Microsoft für die Kommunikation – nun komplett Cloud basiert, fanden viele Entwickler großen Gefallen an unterschiedlichen AWS-Services und nutzten diese für die Herstellung Ihrer Softwarelösungen für das Unternehmen. Da das Thema Cloudnutzung jedoch noch nicht unternehmensweit einheitlich geklärt wurde, entstand eine „Parallentwicklung neben der zentralen IT“. Daher übernahmen häufig die Softwareentwickler Entscheidungen für die IT-Architektur, ohne die verantwortlichen Stellen in der Organisation und hier speziell der IT einzubinden.
Diese Parallelentwicklung sorgte bei der IT und den verantwortlichen Stellen für Bedenken – Wie soll man als Rolle oder Abteilung für etwas verantwortlich sein, wenn diese Fachaktivitäten nicht mit dieser Stelle abgestimmt sind und woanders entschieden und umgesetzt werden?
Diese Parallelentwicklung sollte nun unternehmensweit konsolidiert werden und der Kunde wollte eine einheitliche Cloudstrategie festlegen und verantwortliche Rollen formulieren und festlegen – nicht um die engagierten Entwickler und weitere innovative Ideen zu bremsen, sondern um diese zu unterstützen, sich auf Ihre Aufgaben zu fokussieren und Fachexpertise für bestimmte IT-Bereiche zu bündeln, wo diese auch hingehören.
Dazu wurde in einer strukturierten Abfolge von Terminen und Workshops mit der Skaylink, aber auch internen Abstimmungen der Begriff eines Cloud Competence Centers (CCC) hervorgehoben.
Mit einem CCC verbindet man eine zentrale Einheit im Unternehmen, die als Kompetenzzentrum für das Thema Cloud verantwortlich ist – also anscheinend genau
das was man braucht – eine verantwortliche Stelle in der Organisation um die Entscheidungen aber auch Verantwortungen zu bündeln.
Die Erwartungshaltung an das eigene CCC war allen Stellen gleich wichtig. Die Zielsetzung war:
- Eine zentrale Einheit, die über die notwendige Kompetenz verfügt, unternehmensweit Cloud-Architekturfragen zu beantworten und dortige Vorgaben zu erstellen
- Security und Compliancefragen zu beantworten und wiederkehrende Aufgaben in diesem Bereich zentral abzudecken, so dass nicht jede Initiative die gleichen Aufgaben dezentral und unterschiedlich bearbeitet
- zentrale Einheit für jegliche Cloud-spezifische Fragestellungen und schnelle Beantwortung und Unterstützung für Projekte und Initiativen, die Cloud-Services nutzen wollen
- eine zentrale verantwortliche Betriebseinheit für die Rahmenstrukturen der Cloud (MS-Umgebungen) + AWS LandingZone und die zugehörigen Aufgaben
- und einige mehr
Die Problemstellung bestand in der Fragestellung: Wie wird ein CCC aufgebaut? Welche Rollen benötigen wir zum Start? – Was ist schon absehbar, auf das sich das Unternehmen und das zu erstellende CCC einstellen kann? – Es gab viele Ideen innerhalb der Organisation und der IT, aber auch in den DevOps-Teams wurden verschiedene Ideen beigesteuert. Die Geschäftsführung und das C-Level hat selbstverständlich ebenfalls Input von Partnern erhalten und von bekannten anderen Unternehmungen.
Die Problemstellung war aber, dass alle diese Sichten und Ideen für die einzelne Rolle plausibel und zielführend schienen – nicht aber für das gesamte Unternehmen. Es wurde bei jeder Idee für ein CCC schnell sichtbar, dass das CCC-Konzept von einem Unternehmen auf ein anderes Unternehmen nicht komplett übertragbar ist – Es bedarf einer individuellen Festlegung des eigenen CCCs, wenn auch viele Punkte als BestPractices komplett oder im Grundsatz übernommen werden können.
Hier wurde die Skaylink in den Dialog eingebunden und es sollte eine Idee für ein CCC – passend für das Unternehmen etabliert werden.
Heraufsorderungen
Ein CCC als verbindende Einheit für die Erfüllung mannigfaltiger Bedarfe.
Unser Kunde war durch die Erweiterungen seiner IT-Kompetenzen durch Zukäufe von weiteren Unternehmen und bisherigen Erweiterungen der Organisationsstruktur in einer sehr unruhigen Phase. Es veränderte sich vieles:
- neue Rollen wurden geschaffen
- Unternehmensbereiche wurden konsolidiert und zusammengelegt – damit auch Personen und Verantwortungen
- neue Technologien, Arbeitsabläufe und Prozesse mussten neu erstellt und konsolidiert werden.
Die nun aufkommenden Bedarfe Cloud-Services zu nutzen und der mangelnde entsprechende Cloud-Governancerahmen führten auf der einen Seite zu hohen Erwartungen und vielen kritischen Stimmen. Auf der anderen Seite sah man beim Management die Herausforderungen, die bei der Cloudnutzung ohne entsprechenden Rahmen entstehen würden.
Vor der Entscheidung in dieser unruhigen Zeit ein CCC aufzubauen musste entschieden werden, ob es auf der einen Seite ggf. eine Überforderung der Organisation bedeuten würde ein CCC noch parallel zu etablieren. Auf der anderen Seite befand man sich ohnehin in einem Umbruch und daher konnte man es nun gleich „richtig“ angehen.
Die Entscheidung wurde im Management unter Einbeziehung der relevanten Stakeholder getroffen, dass ein CCC aufgebaut werden sollte – man versprach sich ja deutliche Vorteile für die Organisation.
Es mussten jetzt diese Rahmen und die Governance definiert und implementiert werden. Welche Rolle oder Stelle sollte diese aber definieren und verantworten – das waren offene Fragen, die man gemeinsam klären musste.
Auf der einen Seite waren die technischen Experten sehr agil unterwegs und wollten alle Freiheiten für sich behalten und konnten aus der technischen Sicht her schon sehr gute Ideen beisteuern – auf der anderen Seite waren bisherige IT-Strukturen mit den Entscheidern verantwortlich für einen nachhaltigen IT-Betrieb und wussten nicht genau, wie die neuen Ideen in die Betriebsverantwortung und die zentralen Verfügbarkeitsvorgaben von IT so recht reinzupassen haben.
Es musste daher eine Lösung geschaffen werden, wie man eine neutrale Position etabliert, die beide Seiten unterstützt und diese Bedarfe strukturiert und nachhaltig erfüllt.
Geplante Lösung
Arbeit erledigt sich nur durch Abarbeiten – dazu benötigt man einen Plan.
Viele Anforderungen und Bedenken wurden im Vorfeld formuliert und waren nun zum Start unseres Projektes vorhanden.
Unser Ansatz war erst einmal einen Status Quo zu ermitteln – Die Stakeholder wurden sortiert, neu identifiziert, strukturiert und es wurde offen und transparent über Bedenken und Ideen ein Bild erstellt.
Damit hatten wir erst einmal einen Status Quo und eine gute Grundlage – aber noch wichtiger: Wir hatten auch ein Bild, was das Unternehmen mit den unterschiedlichen Stakeholdern eigentlich erreichen möchte und konnten gut einschätzen, welches Cloud-Knowledge-Level die einzelnen Rollen hatten. Dabei ging es nicht um den technischen Skill, sondern um allgemeine Cloud-Themen wie:
- Shared responsibility
- Wann ist wer für was verantwortlich
- Wozu möchten die Rollen die Cloud nutzen? – Was ist der Mehrwert und was erhofft man sich daraus?
- Für was soll das CCC die Verantwortung tragen – und wie arbeitet das CCC mit der eigenen Rolle zusammen?
- Was für Bedenken hat man und was für Potenziale sieht man in den einzelnen Bereichen
- Was ist schon vorhanden an Architektur?
- Gibt es schon „Cloud-Champions“ in der Organisation?
- und vieles mehr
Daraus ergab sich ein sehr fragmentiertes Bild des Wissensstandes um die Cloud – hier konnten wir ansetzen mit einem Cloud Advisory Workshop, um allen Teilnehmern Wissen zu vermitteln, was Cloud eigentlich ist und wie andere Unternehmen ihren Weg gefunden haben.
Wir nutzen nachfolgend unsere Methode, die stark an das AWS Migration Acceleration Program (MAP) angelehnt ist. Damit identifizieren wir notwendige Aktivitäten in den unterschiedlichen Bereichen wie Strategie, Architektur, Betriebsmodelle und Security. Die dann erstellte Roadmap konnte genutzt werden, um transparent jedem Stakeholder darzustellen, was geplant ist und wann etwas durch welche Rolle getan werden muss.
Wir legten gemeinsam mit den Stakeholdern eine umfassende Roadmap vor.
- Die Erstellung eines Businesscases als Grundlage für unternehmerische Entscheidungen
- Welche Cloud Strategie hat das Unternehmen – gibt es überhaupt eine zentrale oder hat jeder Unternehmensbereich eigene Vision?
- Eine Planung der Cloud-Aktivitäten, für die das CCC einen Mehrwert bilden soll
- Mehrere AWS Immersion Days für die dedizierten Rollen
- Konzeption und Aufbau einer AWS LandingZone und die Klärung der zugehörigen Betriebsverantwortungen
- Ein umfassender Training Plan für die gesamte Organisation, um mittelfristig deutliche Cloudvorteile in vielen Unternehmensbereichen zu heben.
- weitere unternehmensindividuelle Aktivitäten, um das Unternehmen mit dem CCC Cloud-Ready zu machen
Insgesamt – und das war ein wichtiger Punkt und Lösungsansatz der Skaylink – haben wir auf einen Phasenplan gedrängt.
Häufig möchten die Kunden am Anfang alles richtig machen, alle Eventualitäten einarbeiten und alles am Anfang schon definieren. Dies funktioniert leider nicht, da auf dem Weg der Abarbeitung sich immer neue und erweiterte Themen auftun, die dann zur späteren Zeit betrachtet werden müssen.
Aus der Erfahrung der letzten Jahre wussten wir, was wichtig und auf jeden Fall umgesetzt werden müsste, andere Themenschwerpunkte waren bekannt, aber die konkrete Ausgestaltung in der Organisation war noch nicht planbar. So entwarfen wir eine Planung über fünf Phasen, wo wir vor Ablauf jeder Phase die kommende justieren konnten.
Diese, in der Roadmap aufgenommenen Aktivitäten, waren für die jeweiligen Parteien sehr wichtige Punkte und der Bedarf war sehr hoch ausgeprägt, dass dies umgesetzt werden würde – man versprach sich damit die Lösung der Herausforderungen, die man bisher nicht gelöst hatte.
Nun war es aber an der Zeit festzulegen, wer diese Roadmap abarbeitet – dazu wurde ein Team definiert, welches von den Stakeholdern die Verantwortung übertragen bekommen hatte, diese Aktivitäten voranzutreiben – alle Rollen waren nun motiviert die Umsetzung so schnell wie möglich zu starten und erste Ergebnisse zu sehen.
Und dieses Team war nun unser Nukleus für das zukünftige CCC.
Durch die direkte Einbindung dieses Teams in die Herausarbeitung der Herausforderungen und der daraus abgeleiteten Aktivitäten sammelte das Team viel Erfahrung und konnte die Verbindung herstellen – „wieso machen wir etwas – um welches Problem von wem zu lösen.“
Im Verlauf des Projektes begleiteten wir als Skaylink dieses Team einige Monate mit unterschiedlichen Skills, um den größten Mehrwert für den Kunden zu erreichen.
Damit konnte das Team – jetzt offiziell CCC genannt – auf das Vertrauen der einzelnen Unternehmensbestandteile zählen, da man ja schon die damals formulierten Herausforderungen gelöst hatte – und bei geplanten Aktivitäten aus der Roadmap und ungeplanten Aktivitäten aus den Unternehmensbereichen konnte das Team auf die Erfahrungen und Know-how der Skaylink-Experten bauen.
In diesem Fall wuchs das CCC auf ein Team von knapp zehn Experten aus unterschiedlichen Unternehmensbereichen und Unternehmensgruppen, da man erkannte, dass dieses CCC die Herausforderungen der einzelnen Unternehmensbereiche lösen konnte oder schon gelöst hatte.
Die Anzahl von zehn Experten im CCC ist bei den bisherigen Unternehmen, die wir begleiteten eine stattliche Größe – vielfach fangen die Unternehmen mit zwei oder drei Personen an – ein Hochskalieren hier auf zehn Personen zeigt jedoch welcher Bedarf in der Abarbeitung der offenen Themenfelder bestand und noch besteht.
Was wurde erreicht?
Eine strukturierte Sicht auf die nächsten Schritte und -Potenzialle.
- Die formulierten Herausforderungen wurden in transparente abzuarbeitende Aktivitäten aufgeteilt
- Die Abarbeitung ermöglichte auf der einen Seite natürlich die Lösung dieser Herausforderungen – verband aber auch das CCC mit den Unternehmensbereichen. Das CCC stand nun für die Lösung und Beschleunigung von Cloud-Themen.
- Das CCC verstand nun sehr gut, was die einzelnen Stakeholder beschäftigt und was benötigt wird – dies dient als Grundlage für die weitere Zusammenarbeit als Dienstleistungs-Einheit
- Das CCC startete mit knapp 1,5FTEs und wurde zu einem zentralen Element im Unternehmen mit nun zehn FTEs etabliert.
- Die Fachexperten des CCCs wurden als „Organisatorische Leihgabe“ der CCC-Struktur übergeben, da alle diese Unternehmensbereiche massive Vorteile durch diese zentrale Einheit hatten, da ihre anderen Fachexperten keine Cloud-Themen mehr bearbeiten mussten, sondern sich um die klassischen Themen fokussiert und effizienter kümmern konnten
- Neue Ideen oder Bedarfe können standardisiert und sehr schnell adressiert werden und Lösungsideen und Unterstützung ist innerhalb von Stunden bis Tagen möglich
- Cloud wird nicht blind genutzt, sondern von Expertise und Kreativität so verwendet, dass es einen Businessmehrwert bringt
- Wertvolle Expertise wird nun zielgerichtet für die Unternehmensbereiche und für die Lösung von Problemen genutzt und durch höherwertige managed Cloud Services wird „commodity-workload“ günstiger bereitgestellt
- Eine zentrale AWS LandingZone wird von einem kleinen Team verantwortet und weiterentwickelt und stellt über z. B. AWS Sandboxes (alle in einem einheitlichen Governancerahmen) für Entwicklungen und Testfälle eine sichere Plattform zur Verfügung um das Unternehmen mit neuen Ideen in der Cloud weiterzubringen.
- Über das Konzept von AWS ImmersionDays, einem generellen Cloud Traning Plan, wird Wissen breit in die Organisation eingebracht und als Ideen für weiteres Business zurückgeliefert
Lessons learned
Step by Step – Phasenmodell einer Cloud-Journey und der Einführung eines CCCs führt zum schnellen Erfolg.
- Eine nachvollziehbare Struktur und Roadmap ist die Grundlage für dieses Projekt gewesen.
- Nur mit dieser Transparenz erreichen wir das Commitment für das was man gemeinsam angehen muss.
- Damit kann nun Vertrauen in Menschen investiert werden, die mit Verantwortung ausgestattet werden und dann diese Roadmap für die Organisation umsetzen.
- Da schon vieles zuvor versucht wurde und kaum oder unzureichende Ergebnisse erzielt wurden, war es richtig zum Start des Projektes sich als Organisation zu einem STOPP zu zwingen und einen Neuanfang zu beschließen.
- So kann ein Anfang gelingen und eine gemeinsame Cloud Journey angegangen werden.
- Es macht zudem Sinn, das Projekt in Phasen zu teilen und die Stakeholder für eine Phase zu begrenzen – es ist nicht ratsam, im Verkauf des Projektes weitere Stakeholder, die in den vorherigen Workshops und Aktivitäten nicht eingebunden waren, nachträglich einzubinden. Hier braucht es eine gute Projekt-Governance und einen definierten Weg, weitere Stakeholder nach und nach einzubinden.
Fazit
Ein CCC ist nicht das Ziel – es ist der Nukleus einer erfolgreichen Cloud-Journey.
- durch die nun deutlich gesteigerte Kreativität und Agilität wird überlegt, wie man weiteren Stakeholdern ebenfalls AWS-Sandboxes – natürlich unter einem zentralen Governancerahmen verschafft – so dass neue Ideen validiert werden.
- Weitere Experten übergeben klassische Administrationsaufgaben an Automation und managed services und unterstützen nun mehr das Business und die Weiterentwicklung von Ideen.
- Ein Wandel hin zum „Cloud ermöglicht uns, Ideen umzusetzen, von denen wir bisher nicht wussten, wie sie umgesetzt werden können“
- Zudem verfolgt das Unternehmen nun eine breite Partnerschaft mit der Skaylink und der AWS, um im Dialog oder bei Veranstaltungen die Sichtweisen von anderen erfolgreichen Cloud-Champions und mehr Input zu erhalten und seine eigenen Experten weiter wachsen zu lassen.
Das schwerste an dem Projekt beim Aufbau eines CCCS? - Das ist der erste Schritt und die Frage nach Hilfe und Unterstützung.
3 Fakten
Ein zentrales CCC mit dezentralen Experten aus der gesamten Organisation
Vom Chaos zur Struktur in weniger als drei Monaten
Aufgestellt für die Zukunft: Neue Projekte in der Cloud können nun unter kompletter Einbindung der definierten Governance in wenigen Tagen von Idee, über Solution Architektur und Security Bewertungen (inkl. Datenschutzklassifizierung) implementiert werden.
Ich durfte das Unternehmen nach einem halben Jahr intensiver Zusammenarbeit in die Eigenständigkeit bei der Abarbeitung der Roadmap entlassen. Es war eine sehr gute und vertrauensvolle Zusammenarbeit – da wir alle auf die zentrale für uns alle bindende Roadmap hin gearbeitet haben und die Zielsetzungen wurden erfüllt. Die Beratungsaufwände für externe Experten schwinden wie geplant, da die internen Kollegen eine unglaubliche Entwicklung hingelegt haben. Unser Skill-Enablement-Konzept ermöglichte den Kollegen Wissen aufzunehmen und direkt umzusetzen und so direkte Mehrwerte für die Unternehmensbereiche zu erzeugen – mit diesen Erfahrungen wurde aus Dienstleistern Partner und diese verfolgen ein gemeinsames Ziel.