Tipp 1: Bringen Sie die kontinuierlichen Verbesserungszyklen mit Produktfunktionen in Einklang

Herausforderung: Viele IT-Organisationen sind mit den Gedanken der fortlaufenden Verbesserung vertraut. Jedoch wurden diese nicht immer in der Praxis konsequent umgesetzt. Dazu sind klare Regeln und ein lernbasierendes Betriebsmodell notwendig.

Entwicklung, Deployment und Management einer modernen Applikation nach den DevOps-Prinzipien bieten eine gute Basis dafür, die fortlaufende Verbesserung für Anwendungen, Geschäftsergebnisse und Kundenerfahrung zu verankern. Der sogenannte Demingkreis (PDCA-Cycle: Plan – Do - Check – Act) des W. Edwards Deming Instituts beschreibt die Phasen des fortlaufenden Verbesserungsprozesses.

Die IT sollte sich die Prozesse genau anschauen, um diejenigen herauszufiltern, die Verbesserungspotenzial haben. Diese Punkte sollten Sie wiederum mit den Möglichkeiten neuer Tools verbinden, die einen Mehrwert bieten oder Teile des Prozesses automatisieren.

Beispiel: Das DevOps-Team eines großen Retail-Unternehmens entwickelte einen Business Case um herauszufinden, welche Prozesse in der Software-Entwicklung verbessert werden müssten, um die Kunden-Deployments zu beschleunigen. Dabei nutzte das Team als Basis die kontinuierliche Verbesserung nach Demings Ansatz für verschiedene DevOps-Projekte. Mit diesen sollten kurzfristige Verbesserungsmöglichkeiten sowie langfristige Integrationsmöglichkeiten innerhalb von Entwicklung und Testing identifiziert und beziffert werden.

Das Ergebnis übertraf die Erwartungen: Legacy-Prozesse wurden mit neuen Tools zur Konfigurationsautomatisierung umgestaltet. Auch entwickelte das Team Kunden-Self-Service-Mechanismen, die einerseits die Code-Qualität verbesserten und andererseits die Reaktionszeiten auf Feature Requests senkten.

Tipp 2: Identifizieren Sie Renditepotenzial, das fünf Disziplinen umfasst

Herausforderung: Oft schränken DevOps-Teams ihre Analysen zur Wertschöpfung und zum Return on Investment ungewollt auf direkte Einsparungen ein oder auf einige Kenngrößen, die ein bestimmtes funktionales Silo betreffen.

Die meisten IT-Verantwortlichen fokussieren häufig auf Kostensenkungen, technologische Prozessverbesserungen und/oder Business-Nutzen in der einen oder anderen Form. Allerdings können DevOps-Teams eine breite Palette von Mehrwerten bieten. Die IT-Verantwortlichen und DevOps sollten also auf eine ebenso breite Palette an Metriken zurückgreifen, um den Wertbeitrag von DevOps genauer und ausführlicherer zu durchleuchten.

Beispiel: Eine große Bank gliederte jüngst einen Geschäftsbereich aus. Dieser führte ein DevOps-Modell für die IT-Organisation ein. Dadurch wurden zahlreiche Veränderungen innerhalb der IT-Organisation in die Wege geleitet. Mit der Aufstellung von DevOps-Teams und der Auswahl von Projekten benötigten sowohl die IT- als auch die Business-Verantwortlichen für alle Projekte Business Cases mit ergänzenden RoI-Analysen und direkten Bezügen zu den Produkten des Unternehmens.

Das Steuerungskomitee der IT entschied, dass eine einfache RoI-Analyse nicht ausreiche. RoI spiegelte schlicht den Wert von DevOps nicht wieder. In den meisten Fällen wurden Kosteneinsparungen vorausgesetzt. Die zentralen Business-Ziele hingegen betrafen Time to Market, höhere Margen und Kundenbindung. Zudem gelang es dem IT-Management, die IT-Kultur hin zu mehr Verantwortungsbewusstsein und Transparenz zu verändern. Gleichzeitig wurden die DevOps-Teams dabei unterstützt, zügig Ergebnisse zu erzielen, die einfach zu verstehen und zu messen waren.

Tipp 3: Definieren Sie eine Kunden-Persona

Herausforderung: Viele IT-Organisationen haben ihre Kunden nicht ausreichend klar definiert: Wer sind diese, was wollen sie und wie nehmen sie Nutzen wahr? Eine Kunden-Persona als Teil des DevOps-Business-Case hilft dabei, weitreichende Entscheidungen zu treffen.

Die Definition einer Kunden-Persona im Rahmen eines Business Case ist relativ einfach und sehr hilfreich. Um eine Persona zu schaffen, muss das Team einige grundlegenden Recherchen anstellen: Kunden-Background, Demographie, Herausforderungen, allgemeine Ziele müssen ermittelt werden. Durch die Definition des Kunden erhält das DevOps-Team eine klarere Vorstellung davon, für wen es arbeitet und welcher Nutzen erwartet wird. Das Erarbeiten der Persona bietet eine solide Basis für einen bestehenden DevOps-Business-Case.

Beispiel: Das IT-Management eines großen Biotech-Unternehmens startete eine Transformation: Das Team stellte einen auf drei Jahre angelegten strategischen Plan auf. Es arbeitete gemeinsam mit internen Geschäftspartnern und Entscheidungsträgern an der Definition neuer Produkte, einem neuen Prozess zur Kapitalallokation, einem Product InnovationInnovation Center und überarbeitete die Organisationstrukturen und Performance-Metriken der IT. Alles zu Innovation auf CIO.de

Bevor der Strategieplan jedoch final festgeschrieben wurde, stellte das Exekutivkomitee ein Kundenkomitee auf, das mit jeder Gruppe von Geschäftspartnern gemeinsam eine Kunden-Persona für die einzelnen Business-Units definierte. Diese Querschnittskunden wurden dazu genutzt, bei der Festlegung einiger zentraler Bereiche der Strategie zu helfen sowie bei Führungsstil, besonderen fachlichen/rechtlichen/regulatorischen Anforderungen, Projektprioritäten, Performance-Metriken und Grundsätzen für das IT-Marketing.

Tipp 4: Reduzieren Sie die Risiken über den DevOps-Projekt-Lifecycle hinweg

Herausforderung: Oft gelingt es den DevOps-Teams nicht, Risiken der Geschäftsstrategie, bei Design- und Delivery-Kapazitäten oder bei der Kundenerfahrung zu begrenzen. Werden diese Risiken vor der Auswahl eines Anbieters oder Produkts isoliert, kann das Team mögliche Stolperfallen und kritische Risikofaktoren bei Strategie, Technologie oder Prozessen besser erkennen.

DevOps-Teams müssen sich mit zahlreichen Risiken auseinandersetzen. Durch eine gute Planung jedoch können viele dieser Risiken im gesamten Projekt-Lifecycle begrenzt werden. Die Teams sollten mit PLM-Teams zusammenarbeiten, um Mehrwerte für die Kunden zu schaffen. Die Zusammenarbeit mit PLM-Teams reduziert per se die Risiken. Die möglichen Risiken haben zudem Einfluss darauf, welcher Anbieter und welches Produkt am besten über den Lebenszyklus hinweg passen.

Auch sollten DevOps-Teams sich der Risiken bei Design und Delivery bewusst sein. Jedes DevOps-Projekt wirkt sich auf Design- und Architekturparameter aus, auf Interface-Anforderungen, Erwartungen und auf die Kundenerfahrung. Sind diese Risiken bekannt, kann das DevOps-Team die Produkte und priorisierten Merkmale besser am gewünschten Ergebnis ausrichten. Eine Bewertung der Delivery-Risiken sollte SecuritySecurity, Operations und Entwicklung umfassen, um mögliche Lücken zu erkennen. Alles zu Security auf CIO.de

Beispiel: Ein Unternehmen der Gesundheitsbranche entschied sich dazu, ein DevOps-Team aufzubauen, um das manuelle Testing und Application Performance ManagementPerformance Management zu automatisieren. Da es sich dabei um ein komplexes Projekt handelte, musste die DevOps-Leitung einen Business Case aufstellen, der die zu erwartenden Auswirkungen auf die Strategie der Business Unit und zahlreiche weitere Parameter analysierte. Alles zu Performance Management auf CIO.de

Das DevOps-Team schuf einen neuen Prozess und einen Regelsatz für die Erstellung von Business Cases im Unternehmen. Zudem wurde eine signifikante Zeitspanne für Planung und Team-Building im Vorfeld genutzt. Die Führungsrolle des IT-Managements war für den Aufbau des Teams und zur Einführung des neuen Business-Case-Formats sehr wichtig. Das Team kommunizierte den Case an verschiedene Entscheidungsträger auf Business- und auch Technologie-Seite. Dies half dabei, Beziehungen aufzubauen, Vertrauen zu gewinnen und den Zugang zu kritischen Informationen zu gewährleisten.

Fazit

IT-Verantwortliche und deren DevOps-Teams sollten bei der Auswahl von Anbietern und Produkten aggressiver vorgehen und zur Unterstützung das IDC-Framework heranziehen. Viele Entscheider unterschätzen das Potenzial von DevOps aktuell noch. IT-Verantwortliche, die um die Vorteile wissen, die DevOps in verschiedenen Bereichen bietet, können die Transformation innerhalb ihres Unternehmens beschleunigen, sich damit selbst für den nächsten Karriereschritt empfehlen und den Wandel stärker beeinflussen.

Wie geht es weiter?

Die DevOps-Teams haben gute Gelegenheit, den Nutzen ihrer Projekte auszuweiten und das Vorgehen bei der Auswahl von Anbietern und Produkten für DevOps besser aufzustellen. Ein ganzheitlicher Ansatz, bei dem strategische und taktische Analysen in Einklang sind, bringt für DevOps-Management und -Teams in eine gute Startposition für erfolgreiche Projekte. Konkret sollten Sie folgende Schritte einleiten:

• Bringen Sie die kontinuierlichen Verbesserungszyklen mit Produktfunktionen in Einklang

• Identifizieren Sie Renditepotenzial, das fünf Disziplinen umfasst

• Definieren Sie eine Kunden-Persona

• Reduzieren Sie die Risiken über den DevOps-Projekt-Lifecycle hinweg