Ein umfassender Transformation-Prozess

Dr. Robert Klimke, Unternehmensberater und Fachautor für die Themen Customer Experience, Prozess-Man

Ein erweitertes, eigenes Vorgehensmodell verschafft Sicherheit. Es wird so verhindert, dass Unternehmen nicht die Vorgehensprozesse der Lieferanten und Public Cloud Provider übernehmen, sondern stattdessen die Einführung und fortwährende Nutzung einer neuer Technologie für das eigene Haus in den Vordergrund stellen.

Die Public Cloud für das eigene Unternehmen zu nutzen wird gern von den „Playern“ in diesem Marktsegment als „Transformation“, „Transition“ und mit dem Ergebnis verknüpft, Teil einer neuen „disruptive Technology Community“ zu sein. Nur so anders ist dieser Wandel nicht, etwa vergleichbar von Host-Emulationen zu Client-Server Technologien der 80er Jahre. Was allerdings dieses Mal anders ist, ist der betriebswirtschaftliche Teil. Durchaus vergleichbar ist der Public Cloud Transformation Prozess mit dem IT-Outsourcing der 1990er/Anfang dieses Jahrhunderts.

NUR: Wenn es beim Wechsel von Host-Emulationen zu Client-Servern keinen Rückweg gab, so zeigten die IT-Outsourcing Projekte sehr schnell auch wie notwendig die Planung eines Exits vom Outsourcing ist. Exit bezeichnet hier nicht nur das erneute Insourcing von IT-Leistungen, sondern auch den Wechsel des Outsourcing Betreibers.

Es wird IT-Anwendungsszenarien geben, die für immer ideal auf der ein oder anderen Public Cloud Plattform betrieben werden können. Aber selbst bei diesen „Public Cloud-Ready-Anwendungen“ sollte nicht außer Acht gelassen werden, welche Kosten auf das Unternehmen zukommen, wenn der Public Cloud Provider gewechselt werden muss. Ein solcher Public Cloud Provider Wechsel kann schließlich auf Grund von unterschiedlichen Preisen oder technischer Entwicklungen oder neuer Gesetze (neue Eu-DS, Mai 2018) in Bezug auf die jeweilige Plattform immer und auch plötzlich in Frage kommen.

Eine Public Cloud Initiative bzw. eine Transformation oder auch Transition sollte daher folgendem Vorgehensmodell entsprechen.

1. Beschaffungsumfang und -ziele
– Definition der wichtigsten Ziele für eine Nutzung der Public Cloud.
– Überprüfung der Public Cloud Ziele im Einklang mit den Geschäfts- und IT-Strategien.
– Definition der Public Cloud Strategie

2. Beschaffungsmodell & Risk-Modell
– Definition des Public Cloud Ziel Modells
– Definition Public Cloud Modells im Hinblick auf lokal beizubehaltende und auszulagernde IT-Funktionen
– Definition des Public Cloud Nutzungsmodells
– IT-Standortstrategie
– Auswirkungsanalyse für das IT Operating Modell
– Change Management
– Migrations- und Transition-Kostenschätzung inkl. In & Out & Change & Exit-Strategie, inkl. Risikobewertung

3. Anwendungsfall: Auswahl und Analyse
– Business Area Analyse und informationsstrategische Planung – Vorselektion von Anwendungen in Bezug auf folgende Dimensionen:
— Time-to-Market
— Investitionskosten Migration – In & Out & Change & Exit
— Investitionskosten Neuentwicklung in der Public Cloud
— Skalierbarkeit
— Unternehmenskritikalität
— Verfügbarkeit
— Schnittstellenaffinität zu bestehenden Systemanwendungen
— Grad der Relevanz von Gesetzen und branchenbezogenen Regularien
– Überprüfung der Vor- und Nachteile der jeweiligen Anwendungen für das definierte Public Cloud Nutzungsmodell
– Definition eines „ersten“ Anwendungsfalls

4. Betriebsmodell
– Definition des Betriebsmodells zur Public Cloud Nutzung unter Beachtung des Beschaffungsumfangs und -ziels
– Change Management in Bezug auf:
— Auswirkungen auf das Unternehmen
— Auswirkungen auf die IT-Organisation
— Auswirkungen und veränderte Anforderungen an IT-Fähigkeiten
— Geschäfts- und IT-Prozesse
— Governance
— Veränderungen KPIs und sonstigen Metriken usw.

5. Lieferanten- und Partnerauswahl
Auswahl der geeigneten Partner und Public Cloud Provider basierend auf einer Reihe von definierten Kriterien:
– Nachweisbare und aktuelle Public Cloud Zertifizierungen,
– Referenzierbare Public Cloud Projekte umgesetzt. (Google, AWS, Azure etc.), insbesondere im Geschäftsumfeld des Mandanten,
– Nachweislich dokumentierte „Best Practices“ in den Bereichen Migration, Automation und vor allen Dingen Sicherheit,
– Mitarbeiterstamm mit ausreichenden Zertifizierungen und IT-Fähigkeiten, die über das jeweiligen Public Cloud Provider – Know-how hinausgehen,
– Nachweisliche Erfahrungen in skalierbaren Public Cloud Projekten in Bezug auf die Anforderungen im Change Management,
– Nachweisliche Erfahrungen in der Arbeit mit IT-Organisationen und komplexeren Architekturen,
– Nachweis von Compliance in Bezug auf Gesetze, Regularien, Gesetzesnovellen,
– Kenntnisse der relevanten, lokalen, wie auch internationalen Regularien.

6. Vertragsvorbereitung und Finalisierung
Jeder Anbieter bietet unterschiedliche Vertragsmodelle an. Diese Vertragsmodelle rangieren von standardisiert bis frei. In jedem Fall sollte kein Vertragsabschluss getätigt werden, der eine Bindung außerhalb des „ersten Anwendungsfalls in der Public Cloud“ beinhaltet. Erst, wenn dieser erste Anwendungsfall im laufenden Betrieb ist, lassen sich die so gewonnen Erfahrungen in Bezug setzen auf die vorherige „informationsstrategische Planung“ und der damit einhergehenden – Vorselektion von Anwendungen. Dies dient einzig den folgenden Zwecken:
– den Vertragsumfang besser erfassen zu können,
– die eigene Position in Bezug auf den Vertragsumfang besser zu kennen,
– das Leistungsspektrum und die Erwartungshaltungen an den Vertragspartner genauer benennen zu können, inkl. „remote Arbeiten“ vs „onsite“,
– Diskussionsgrundlagen auf Basis der Opportunitätskosten zu haben, die über den reinen TCO-Ansatz hinausgehen, in diesem Falles ergänzt durch In- & Out- & Change- & Exit- „transition costs“,
– Anreize für die jeweiligen Vertragspartner besser beschreiben zu können,
– die Vertragspartnerauswahl effizienter vollziehen zu können und
– die eigentliche Vertragsverhandlungen zu beschleunigen.

7. Management und Governance
– Definition der Zusammenarbeit in „federated“ Konstrukt „Unternehmen-Lieferant, Personal“ für die Transition- und spätere Betriebsphase.
– Definition der Beschaffungsbeziehung (Menschen und Prozesse) und deren Kontrolle
– Definition der veränderten Corporate Governance
– Einweisung in die Corporate Governance aller Beteiligten
– Definition Governance Transition Framework, um weitere Projekte im gleichen „SetUp“ aufzusetzen.

8. Transition oder auch Transformation
– Definition Projektteams etc. und Projektarbeitsprozess und deren Monitoring
– Priorisierung des Leistungsspektrum und Zeitplanung und Einsatz agiler Methoden
– Review der Migration vom aktuellen Zustand zum Zielzustand in Bezug auf Prozesse, Personen, Verträge und Governance Transition Framework usw.
– Dokumentation und Feedback in die vorhergehenden Phasen
– Etablierung des KVP für die Projektphase

9. Technische Analyse & Design des Anwendungsfalls
– Finale Anwendungsanalyse in Bezug auf Cloud Readiness
– Architektur-IST zu Architektur-SOLL
– Statement of Work – detaillierte Beschreibung der Arbeitspakte und Einzelaktivitäten, Dauer und Ergebnis und gemeinsame Priorisierung im Projektteam
– Überprüfung in Bezug auf Public Cloud Beschaffung-, insbesondere Nutzungs- und Betriebsmodells
– Dokumentation und Feedback in die vorhergehenden Phasen und in KVP

10. Umsetzung (DevOps)
– Definition und Aufbau Entwicklungs- Test-, QA-, Produktionsumgebung
– Agil basierte Entwicklung
– Kontinuierliche Erhöhung des Automatisierungsgrads in Bezug auf die Projektschritte
– Monitoring Projekt, Dokumentation und KVP
– Go-Live-Support
– Abnahme

11. Betrieb und kontinuierliche Verbesserung
– Übergabe der Systemumgebungen an den Managed Service, inkl. aller Dokumentationen
– Erstellung Playbook bzw. Runbook
– Definition von Monitoring- und Logging- und Security Devices und -Anwendungen und Schnittstellenentwicklung zu bestehenden Anwendungen
– 24/7 Managed Services und Support, Leistungsnachweise
– Cloud-Kostenmanagement und Alarme, Eskalationsprozess
– Cloud-Technologie-Management: neueste Microservices, Produkte
– KVP

12. Review
Es hat sich ausgezahlt, die ersten drei Projekte einer sehr stringenten betriebswirtschaftlichen und technischen Überprüfung zu unterwerfen, um so Erkenntnisse in den verschiedenen Phasen dieses Vorgehensmodells für zukünftige Projekte zugänglich zu machen. Insbesondere sollte der Review den laufenden Betrieb dahingehend prüfen, was ein Ausfall dieser Anwendung nun bedeutet. Auch erst jetzt wird letztendgültig klar, was es heißt, dieses Anwendungssystem, inkl. seiner zahlreichen Interaktionen mit anderen Systemen auf eine andere Public Cloud Provider Plattform zu ziehen oder welche Kosten mit einem Wechsel in ein lokales Rechenzentrum einhergehen würden.

Der Review zielt vor allen Dingen aber darauf ab, unternehmenseigene Erfolgskriterien zu gewinnen, die die verschiedenen Phasen des Vorgehensmodells beinhaltet, um auch so das Monitoring zukünftiger, sehr zahlreicherer, gleichzeitiger „Deployments“ zu vereinfachen. Die Reviewphase hat nicht nur den Zweck anhand der Kriterien zu erkennen, ob man schneller im Durchlauf geworden ist, sondern es zwingt alle Beteiligten, auch zu prüfen, inwieweit diese Projekte immer noch der Unternehmenszielsetzung entsprechen. Zu oft wird der Automatisierungsgrad in den Vordergrund gerückt, was die Umsetzung weiterer Projekte in die Public Cloud deutlich und immer weiter beschleunigt. Die Themen Unternehmensstrategie, IT-Strategie, Compliance und Governance treten dabei nicht selten in den Hintergrund. Die Reviewphase verhindert das!

Abstrakt
Ein umfassendes Vorgehensmodell für die Nutzung von Public Cloud Services schafft eine auf den Unternehmenszielen und -strategien beruhende Vorgehensweise. Es wird sichergestellt, dass alle in Bezug auf eine Public Cloud Nutzung in Frage kommenden Anwendungen und IT-Systeme dem eigenen „Vorgehen“ entsprechen und nicht ständig in Abhängigkeit vom jeweiligen Partner oder Lieferanten abgeändert werden. Das Wirrwarr, was heute unter Public Cloud -Transition und -Transformation verstanden wird, wird durch dieses Vorgehensmodell in eine erweiterte Perspektive gebracht, um so dem Unternehmen langfristig zu nutzen.

Autor
Dr. Robert Klimke, Partner M. Consulting, Unternehmensberater und Fachautor für die Themen Customer Experience, Prozess-Management, Public Cloud u.v.m.

Unternehmensberater und Fachautor für die Themen Customer Experience, Prozess-Management, Public Cloud u.v.m.

Firmenkontakt
M. Consulting
Robert Klimke
Jakl-Jordan-Weg 18
82319 Starnberg
08971672000
rklimke@t-online.de
http://www.bservice.de

Pressekontakt
bSevice GmbH
Daniel Birkenmayer
Moritz-von-Schwind-Str. 5
82319 Starnberg
08971672000
info@bservice.de
http://www.bservice.de