Digicomp 1
Change Management 2.0
Markus Schweizer, Digicomp Trainer
Senior Consultant, AWK Group
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
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
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!
5Digicomp
Nach Eli Goldratt: «Theory of constraints»
IT-Ziel Dilemma
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
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
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
9Digicomp
ITIL ®: Aufbrechen der Silos in Ops durch Prozessorientierung und
Matrixorganisation
?
Dev
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
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
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
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
14Digicomp
ITIL® V3: Verbindung
zwischen
Anwendungs-
entwicklung und IT
Betrieb
«Based on AXELOS ITIL® material. Reproduced under license from AXELOS»
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
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
17Digicomp
Starke Governance muss verschiedene Change-Modelle einheitlich steuern
Unterschiedliche
Anwendungs-
entwicklungs-
methoden
verlangen
unterschiedliche
Change Modelle
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
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
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
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
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
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)
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
25Digicomp
W. Edwards Deming
Sozialkompetenzen 26
Herzlichen Dank!
markus.schweizer@awk.ch
ITIL® is a registered trade mark of Axelos Limited.
ITIL Kursportfolio: https://www.digicomp.ch/de/weiterbildung/management/itil-und-it-service-management

Referat: Change Management 2.0

  • 1.
    Digicomp 1 Change Management2.0 Markus Schweizer, Digicomp Trainer Senior Consultant, AWK Group
  • 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ätbei 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!
  • 5.
    5Digicomp Nach Eli Goldratt:«Theory of constraints» IT-Ziel Dilemma
  • 6.
    Change & ReleaseManagement 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 & ReleaseManagement 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 & ReleaseManagement 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
  • 9.
    9Digicomp ITIL ®: Aufbrechender Silos in Ops durch Prozessorientierung und Matrixorganisation ? Dev
  • 10.
    Neue Silos inder 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 Einflussauf 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üreine 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
  • 14.
    14Digicomp ITIL® V3: Verbindung zwischen Anwendungs- entwicklungund IT Betrieb «Based on AXELOS ITIL® material. Reproduced under license from AXELOS»
  • 15.
    Geschäftsbereich 1 Geschäfts- anforderungen Geschäfts- Entwicklung Project Portfolio Kapazität s-plan Change Advisory Board Budgeting Run the business Changethe 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 mehrStandard-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 mussverschiedene 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öpfungsketteder Ä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 Realisierbarkeitvon 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 Realisierungder 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
  • 25.
  • 26.
    Sozialkompetenzen 26 Herzlichen Dank! markus.schweizer@awk.ch ITIL®is a registered trade mark of Axelos Limited. ITIL Kursportfolio: https://www.digicomp.ch/de/weiterbildung/management/itil-und-it-service-management