Change Management ist wahrscheinlich einer der meistimplementierten ITIL®-Prozesse.
Mit der wachsenden Maturität des angewandten Prozesses ergeben sich nun in vielen Organisationen Fragen nach neuen Zielsetzungen und einer Erweiterung des Scope des Change Managements:
- Wie spielen Projekt- und Change Management zusammen?
- Welche Rolle hat Change Management im Budgetierungsprozess?
- Was sind die Auswirkungen neuer Technologien wie Cloud Computing oder neue Methoden wie Scrum auf das Change Management?
- Wo sind die Grenzen zwischen technischem und organisatorischem Change Management?
Anhand praktischer Beispiele erfahren Sie in dieser Präsentation, wie das Change Management von Morgen aussehen wird.
2. http://www.awk.chMarkus Schweizer - Steckbrief
● Lic. phil. I, EMBA HSG
● IT Beratung und Engineering seit 1989
● IBM, PwC, CA, Protiviti, USU Consulting, AWK
● Highlights:
─ Grosskunden: Allianz, AXA Winterthur, CS, SwissRe, Novartis, T-Systems,
Helsana, BAFU, armasuisse
─ USA 1999-2008: AON, MetLife, Dept. of the Treasury, State of California,
General Electric, Aegon, Delphi Automotive, VISA, CGI, SunTrust, Convergys
─ Beratungsschwerpunkte: Service Management, IT Asset Management, Lizenz
Management, IT Financial Management, IT Strategie, Programm Management,
strategische Verbesserungsprogramme, Governance etc.
─ Digicomp Trainer für ITIL und Cobit
─ ITIL Service Manager seit 2000, Expert seit 2008
2
3. 3Digicomp
Agenda
Ausgangslage
Vor- und Nachteile eines strikten Change Managements
Zielkonflikte Business-Anwendungsentwicklung-Betrieb
Alte und neue Silos
Lösungsansätze?
ITIL® V3
Service-Orientierung
IT der verschiedenen Geschwindigkeiten
Ein Lösungsansatz
Zusammenfassung und Diskussion
4. 4Digicomp
Verbesserung der Betriebsstabilität bei einer
Versicherung:
Investitionen in das Prozessfeld Incident-,
Problem-, Change und Configuration
Management
Verbesserung der Betriebsstabilität
Prio 1 Störungen gingen um 85% zurück
Prio 2 Störungen konnten seit Messbeginn
ebenfalls um 66% gesenkt werden.
Change Management ist eine Erfolgsstory!
6. Change & Release Management
Verschiedene Prioritäten führen zu Zielkonflikten
Rascher, schneller,
besser
• Rasche Auslieferung
neuer Funktionalitäten
• Leistung und Qualität
• Kundenzufriedenheit
• Projekt Management
Ziele der Anwendungs-
entwicklung
Sicher, steuerbar,
planbar
• Stabilität
• Sicherheit
• Architekturen
• Prozesse
Ziele des IT-Betriebs
6
7. Change & Release Management
Zielkonflikte übersetzen sich häufig in getrennte «Change-Prozesse»
7
• Anwendungsentwicklung und IT Betrieb haben eigene Prozesse für Change & Release Management –
Prozesse sind nicht durchgängig
• Wenig Kommunikation zwischen beiden wichtigen Abteilungen
• IT-Betrieb erfährt häufig sehr spät von Change (=Auftrag zum Deployment)
• Auf der anderen Seite wird IT-Betrieb-Abteilung als umständlich und verzögernd empfunden
Release Management «Anwendungsentwicklung»
Req. Eng. Planung Entwicklung & Test Deployment Abschluss
Business
Freigabe
Change Management «IT Betrieb»
Erfassung
RfC
Review Freigabe Deployment Abschluss
Anwendungs
-entwicklung
IT-Betrieb &
Infrastruktur
8. Change & Release Management
Durchgängiger Change, Release & Deployment Management Prozess für eine Applikation sieht typischerweise 2 Bewilligungsstufen vor
8
Release & Deployment Management
Change Management
Release
abschliessen
Rollout /
Deployment
durchführen
Pilot
durch-
führen
Release
kommunizieren
und vorbereiten
Rollout /
Deployment
planen
Change
überprüfen &
schliessen
Release
testen und
abnehmen
Release
entwickeln
Release
planen
Change Deployment koordinieren
Deployment
freigeben
Realisierung koordinieren
RfC
bewilligen
(Business)
RfC planen und
koordinieren
RFC erfassen,
prüfen und
bewerten
RfC
bewilligt?
Ready?
Deployment
freigegeben?
End-to-End Change, Release & Deployment Management
1. Stufe –
Bewilligung der
Entwicklung
2. Stufe –
Freigabe des
Deployments
• Fokus: Wollen wir den Change wirklich
machen?
• Zusammensetzung des
Autorisierungsgremiums (CAB) ist
typischerweise abhängig vom jeweiligen
Service bzw. Applikation
• Fokus: Schutz der Produktivumgebung /
Minimieren der Risiken
• Zusammensetzung des
Autorisierungsgremiums (CAB) ist unabhängig
vom jeweiligen Service, und mehrheitlich ein
Betriebsgremium
10. Neue Silos in der IT Organisation
Die starke Ausrichtung auf Risikominimierung hat starke Mauern zwischen Dev und Change und IT-Betrieb kreiiert.
Business
Anwendungs
-entwicklung
Change-,
Release, Test
&
Deployment
Betrieb
10
11. 11Digicomp
Agenda
Ausgangslage
Vor- und Nachteile eines strikten Change Managements
Zielkonflikte Business-Anwendungsentwicklung-Betrieb
Alte und neue Silos
Lösungsansätze?
ITIL ® V3
Service-Orientierung
IT der verschiedenen Geschwindigkeiten
Ein Lösungsansatz
Zusammenfassung und Diskussion
12. 12Digicomp
Trends mit Einfluss auf Change Management
Business fordert mehr Flexibilität und schnellere Auslieferung neuen Funktionen
Ablösung von ‘Legacy’-Anwendungen: Hunderte von Schnittstellen zu Umsystemen
stellen enorme Anforderungen an das Test- und Release-Management
Neue Technologien wie Virtualisierung, Cloud Services, agile Entwicklungsmethoden
und eine Generation ganz neuer Tools erlauben mehr Automatisierung und dadurch
höhere Auslieferungsgeschwindigkeit bei geringerem Risiko
Service-Orientierung und damit einhergehend die Service-Verrechnung bringt die
Budgets für Änderung und Betrieb eines Service in die Verantwortung des Kunden:
‘Run-the-business’ und ‘Change-the-business’ aus einer Hand
Heraus-
foprderungen
Chancen
13. Agiler
Demand
Schnelle
Markt-
änderungen
Produkt-
innovationen
Herausforderungen und Lösungsansätze
Für eine höhere Agilität muss die Applikationsarchitektur modernisiert werden und End-to-End-Prozesse auf schnellere Release-Zyklen ausgerichtet werden
Komplexe Applikationslandschaften
Fehlende End-to-End Prozesse
Entwicklung
Betrieb
• Applikationslandschaft weist viele
Schnittstellen untereinander auf
• Alte Technologien/Plattformen
• Ein Business-Change benötigt viele
Applikations-Changes
• Langsame Release-Zyklen
• Agiler Business-Demand kann nicht
befriedigt werden
• Anwendungsentwicklung und IT
Betrieb haben eigene Prozesse –
Prozesse sind nicht durchgängig
• Geringe Kommunikation zwischen
beiden wichtigen Abteilungen
• IT-Betrieb erfährt häufig sehr spät
von Change
• IT-Betrieb-Abteilung wird als
umständlich und verzögernd
empfunden
• Aufbrechen bzw. Erneuerung der
Architektur Modularisierung
• Einsatz moderner Technologien/
Plattformen
• Technologische Fähigkeiten für
schnellere Release-Zyklen
schaffen
• Etablieren von End-to-End Change
& Release Prozessen
• 2 Prozessausprägungen
unterstützen: klassisch und agil
• Stärken der Kommunikation
zwischen Dev & Ops
• Organisatorische Fähigkeiten für
schnellere Release-Zyklen
schaffen
LösungsansätzeHerausforderungen ITBusiness
Technologische Fähigkeiten
Organisatorische Fähigkeiten
13
15. Geschäftsbereich 1
Geschäfts-
anforderungen
Geschäfts-
Entwicklung
Project
Portfolio
Kapazität
s-plan
Change
Advisory
Board
Budgeting
Run the
business
Change the
business
Additional
Capacity
New
Services
Service
Portfolio
Service
Catalog
ServiceOperation
(Consumption)
Service-Orientierung bedingt strategisches Change Management
Budgets für ‘Change-the-business’ und ‘Run-the-Business’ werden vom selben Gremium beschlossen
Geschäftsbereich 2
Geschäfts-
anforderungen
Geschäfts-
Entwicklung
Project
Portfolio
Kapazität
s-plan
Change
Advisory
Board
Budgeting
Run the
business
Change the
business
Additional
Capacity
New
Services
15
16. Automatisierung erlaubt mehr Standard-Changes
Änderungs
-Dienst
RfC
Instandhaltung
• Ungeplant
• Geplant
Prozess Management
• Struktur
• Inhalt
Dok. Mgmt
• Inhaltlich
• Formal
Ausführung in
SAP
Update durch
Prozess
Owner
Update durch
Dok-Owner
Delegation
Standard Change
Standard Changes
Prozess
Ende
Change
Requestor
Budget
notwendig
• Risiko
• Dring-
lichke
it
Operationelles Change Management
Release
Mngmt
• Prio
• Freigabe
Go
Live
?
PIR
Beschaffung
Projekt
Abgekürzter Änderungsdienst
Delegation
Triage
16
Beispiel einer Change-Steuerung über eine zentrale Triage-Funktion
17. 17Digicomp
Starke Governance muss verschiedene Change-Modelle einheitlich steuern
Unterschiedliche
Anwendungs-
entwicklungs-
methoden
verlangen
unterschiedliche
Change Modelle
18. 18Digicomp
Agenda
Ausgangslage
Vor- und Nachteile eines strikten Change Managements
Zielkonflikte Business-Anwendungsentwicklung-Betrieb
Alte und neue Silos
Lösungsansätze?
ITIL® V3
Service-Orientierung
IT der verschiedenen Geschwindigkeiten
Ein Lösungsansatz
Zusammenfassung und Diskussion
19. Eine integrierte Wertschöpfungskette der Änderung muss als ‘Umsetzungsprozess’ die Silos überwinden
Lean Methoden können den ‘Speck’ aus den eingefahrenen ‘Silo’-Prozessen entfernen helfen
Traditional Lean
Managers have all the
answers
Manager should ask the
right questions, employees
should have the answers as
a team
Managers do the thinking,
workers concentrate on
doing
Managers facilitate the
workers to add value
Activities are done,
because they are asked to
be done
Activities are only done if
they add value
A certain rate of defects is
unavoidable
Defects can be eliminated
19
20. Projektpo
rtfolio-
Mngmt.
IT
Financial-
mngmt.
Require-
ments
Mngmt-
Code- &
Dev
Mngmt.
QA & Test
Mngmt.
Deploymn
t.
Mngmt.
Systems
Mngmt.
Service
Mngmt.
Kapazitäts
-
Mngmt.
Projektpo
rtfolio-
Mngmt.
IT
Financial-
mngmt.
Require-
ments
Mngmt-
Code- &
Dev
Mngmt.
QA & Test
Mngmt.
Deploymn
t.
Mngmt.
Systems
Mngmt.
Service
Mngmt.
Kapazitäts
-
Mngmt.
Projektpo
rtfolio-
Mngmt.
IT
Financial-
mngmt.
Require-
ments
Mngmt-
Code- &
Dev
Mngmt.
QA & Test
Mngmt.
Deploymn
t.
Mngmt.
Systems
Mngmt.
Service
Mngmt.
Kapazitäts
-
Mngmt.
Projektpo
rtfolio-
Mngmt.
IT
Financial-
mngmt.
Require-
ments
Mngmt-
Code- &
Dev
Mngmt.
QA & Test
Mngmt.
Deploymn
t.
Mngmt.
Systems
Mngmt.
Service
Mngmt.
Kapazitäts
-
Mngmt.
‘Legacy’
‘Packaged
App’
‘Web/Cloud’
‘Techn.
Change’
4 Change-Modelle für die IT der verschiedenen Geschwindigkeiten
Je nach Change-Modell sind unterschiedliche Schritte der Wertschöpfungskette wichtiger
20
21. Triage
Programm- und Projekt-Management, PMO
Automatisierung, DevOps
Kunde –
«Ich will …»
Change Management
Felxibles End-to-End-Change Management 2.0
4 Change Modelle – 4 Geschwindigkeiten
2x Fokus auf Projekt- und Programmmanagement – 2x Fokus auf Automatisierung und Geschwindigkeit
21
22. Bewertung der Realisierbarkeit von Nutzenpotentialen
Steigerung der Agilität wird erst mit Umsetzung der neuen Architektur breit möglich 22
Steigerung Qualität
• Besseres Management der Schnittstellen
- dadurch kommt es zu weniger Fehlern
während Prozess
• Der Prozess-Owner hat die End-to-End
Verantwortung und kann somit
ganzheitlich Qualität steigern
Nutzenpotentiale Realisierbarkeit
Steigerung Effizienz
• Schnittstellen-Verluste können
minimiert werden und somit Effizienz
gesteigert werden
• Automatisierung erst mit Erneuerung
der Applikationslandschaft sinnvoll
Steigerung Agilität /
Time-to-Market
• Ziel kann erst mit Erneuerung der
Applikationslandschaft vollständig
erreicht werden
• Aktuell ist dies wahrscheinlich nur für
wenige isolierte Applikationen möglich
P1
P2
P3
• Etablierung eines End-to-End Change &
Release Management Prozesses
• Etablierung einer übergreifenden
Prozess-Ownership (Cross-Unit)
• Steigerung Kommunikation zwischen
Entwicklung und Betrieb
• Etablierung des Prozesses nach Lean-
Gedanken Vermeidung von
Verschwendung
• Automatisierungen entlang der
gesamten Prozesskette
• Modularisierung der Applikations-
landschaft als Basis für kleinere
Release-Packages und schnellere
Zyklen
• Etablierung des Prozesses nach
DevOps-Gedanken
neue Prozessausprägung «Agil»
Massnahmen
23. Vorgehensvorschlag zur Realisierung der Nutzenpotentiale
Ein neues Change Management Paradigma ist auch eine Änderung der Kultur – sie muss deshalb gut begleitet und Schritt für Schritt angegangen
werden
23
Vorgehensvorschlag
Aktuellen Projektfokus auf Etablierung eines End-
to-End Change & Release Management für
Applikationsbereich mit agilem Demand legen
Etablieren des Prozesses für mindestens eine
Applikation im Bereich «Agil»
Etablieren einer Kommunikationskultur zwischen
den Abteilungen
Identifikation von Chancen für Modularisierung,
Beschleunigung und Automation
Aufzeigen von weiteren Chancen für die
Ausbreitung der ‘DevOps’-Kultur
Definition einer Roadmap für die Prozess-
Vertiefung (z.B. ‘Continuous Delivery’) und -
Verbreiterung (zusätzliche Anwendungen)
24. 24Digicomp
Agenda
Ausgangslage
Vor- und Nachteile eines strikten Change Managements
Zielkonflikte Business-Anwendungsentwicklung-Betrieb
Alte und neue Silos
Lösungsansätze?
ITIL® V3
Service-Orientierung
IT der verschiedenen Geschwindigkeiten
Ein Lösungsansatz
Zusammenfassung und Diskussion