ITIL-basiertes Release Management als Bestandteil des Application Lifecycle Management

Transkript

1 ITIL-basiertes Release als Bestandteil des Application Lifecycle Folkert Jung ALM 008, München am 9. Februar 008 Inhalt Release Motivation Definitionen Release -Prozess Einführungsplanung Release Business Case-Ansätze Release Praxis-Beispiele Zusammenfassung / Fazit Seite

2 Positionierung und Kurzdarstellung Die direkt gruppe berät, implementiert und betreibt komplexe IT-Infrastrukturen.... unterstützt deutschlandweit große und mittelständische Unternehmen dabei, leistungsstarke s für deren IT-Anwender zu erbringen und zu verbessern. Köln 5,6 Mio. Umsatz 007 Hamburg 45 Mitarbeiter 007 Dafür bietet die direkt gruppe auf den Bedarf des Kunden zugeschnittene Dienstleistungen und Lösungen, die gleichermaßen auf innovativen Technologien und Methoden sowie auf Standards basieren. München Seite Portfolio IT--Prozesse Lebendige IT-Prozesse zur Unterstützung eines transparenten und leistungsfähigen IT--s Anwender- Steigerung der Qualität der Anwender-s für ein besseres IT-Erlebnis beim Anwender und eine höhere Produktivität IT-Sicherheit Schadensvermeidung durch technische und organisatorische Maßnahmen bis hin zum vollständigen Sicherheitsprozess 6 7 Kommunikation Anwender- IT-Sicherheit IT-- Netzwerk- Serverdirekt Speicher- Architektur Prozesse gruppe Server-Architektur Integration innovativer und leistungsfähiger Business- und Infrastrukturlösungen Speicher- Strategien und Architekturen für ein individuelles Informationsmanagement und eine wirtschaftliche Datenhaltung 5 4 Netzwerk- Sicherstellung der Kontinuität in der unternehmensweiten Kommunikation durch innovative Infrastrukturlösungen Kommunikation Kommunikations-s zur Unterstützung und Weiterentwicklung von Geschäftsprozessen, Workflows und Teaminfrastrukturen Seite 4

3 Inhalt Release Motivation Definitionen Release -Prozess Einführungsplanung Release Business Case-Ansätze Release Praxis-Beispiele Zusammenfassung / Fazit Seite 5 Motivation zur Projektinitiierung Mögliche Ist-Situation Etabliertes Change deckt die Aufgaben eines übergreifenden Release s nur begrenzt ab. Beispiel : Changes mit möglichen Wechselwirkungen werden auf verschiedene Zeitfenster verteilt. Infolgedessen keine optimale Terminund Ressourcenplanung möglich. Beispiel : Erhebliche Reifeunterschiede bei den eingesetzten Transition-to-Production- Verfahren sowie den unterstützenden Tools. Potenziale: Changes zu Releases bündeln und gemeinsam einführen: Konsolidierungspotenzial bei Produktivsetzungen Vergrößerung der Zeitintervalle zwischen Änderungen Potenziale: Verbindliche und einheitliche Vorgaben schaffen: Risikominimierung für die Produktionsumgebung Verbesserung des Informationsflusses durch übergreifende Planung Seite 6

4 Release Ziele Hauptziele Sicherstellung der erfolgreichen Planung und Durchführung der Produktivsetzung von Änderungen unter Verwendung einer Release-Richtlinie sowie eines Release-Kalenders Gebündelte Verteilung und Sicherung von produktiv genutzten Software- und Hardware- Versionen zur Gewährleistung der erforderlichen qualität Sekundärziele Wirtschaftlichkeit Standardisierte Konzeption für Softwareverteilung Minimierung des Testaufwandes Verbesserte Anwenderbetreuung Erleichterung der Wartung und von Software Erhöhte Qualität und Anwenderzufriedenheit Vereinfachte Migration Seite 7 Nutzen der Prozesseinführung Höhere Erfolgsrate bei der Ausbreitung von neuer oder geänderter Hard- und Software durch reduzierte Verwendung von nicht getesteter Software Fehlerquote bei freigebenden Komponenten sinkt und dadurch entstehen weniger unterbrechungen Höherer Durchsatz und Termintreue bei der Einführung Entdeckung nicht autorisierter Kopien und falscher Versionen Effizientere Nutzung von Ressourcen durch deren koordinierten Einsatz Gewährleistung der Nachvollziehbarkeit und Auditierbarkeit von Änderungen Reduktion der Supportkosten Seite 8

5 Inhalt Release Motivation Definitionen Release -Prozess Einführungsplanung Release Business Case-Ansätze Release Praxis-Beispiele Zusammenfassung / Fazit Seite 9 Die ITIL-Struktur (V) Planning to implement The Business The Business Perspective Delivery Support ICT Infrastructure The Technology Application Security (Quelle: OGC, The ITIL publication framework) Seite 0

6 IT-Infrastructure Library (V) ITIL Support Delivery Incident Problem Level Availability Change Configuration Financial for IT-s Capacity Release IT- Continuity Security Seite ITIL V: Der Evolutionsschritt The Business Planning to implement ICT The Support Infrastructure Business Perspective Security Delivery Manage- The Technology Die ITIL V Kernbücher: Strategy Design Transition Operation Continual Improvement ment Application Die ITIL V Kernbücher: Support Delivery Security Planning to implement The Business Perspective ICT Infrastructure Application IT nach ITIL V basiert auf einem Lifecycle-Ansatz. Quelle: TSO for OGC Seite

7 ITIL V Prozessübersicht Strategy Design Transition Operation Continual Improvement Strategic assessment matching need to capability Catalogue Mgmt. (SCM) Transition Planning and Support Event 7-Step Improvement Process Develop strategic capabilities Level Mgmt. (SLM) Change Incident Reporting value creation Defining the market space Capacity Asset & Configuration Request Fulfilment Measurement Portfolio Mgmt. outsourcing Return on investment (ROl) Availability lt Continuity Mgmt. (ITSCM) Release and Deployment Validation and Testing Problem Access Return on Investment for CSI Business Questions for CSI Financial Increasing service potential Organizational development Information Security Mgmt. (ISM) Supplier Evaluation Knowledge Operational Activities of other Processes Level Mgmt. (SLM) - bekannte ITIL V Prozesse Seite Release nach ITIL Release Release Grundsätze & Planung Release entwerfen, entwickeln DSL Release zusammensetzen Testen und Release-Annahme Planung Einführung (Rollout) Kommunikation, Vorbereitung Training DHS Release Verteilung/Installation Change Configuration Seite 4

8 -Baum und -Netzwerk Release-Typen Unternehmensrelease Strukturrelease Fachrelease Komponentenrelease Seite 5 Release-Typen und -Arten Klassifizierung von Releases erfolgt nach Release-Typ und Release-Art: Release-Typ definiert das Release auf organisatorischer Ebene Komplexitätsgrad, Auswirkung, Testaufwand usw.) Strukturrelease Fachrelease Komponentenrelease Notfall-Release Release-Art definiert das Release auf technischer Ebene Welche Bestandteile einer oder mehrerer Release-Units sind in das Release integriert? Wie erfolgt die Verteilung über Softwareverteilungstools? Full- oder Package-Release Full- oder Package-Release Delta-Release Delta-, Full- oder Package-Release Seite 6

9 Release-Typen Release-Typ Beschreibung Häufigkeit Strukturrelease Fachrelease Komponentenrelease Notfallrelease übergreifendes Release mit großen funktionalen Änderungen und z.b. strukturellen bzw. logischen DB-Umstellungen oder großen Abhängigkeiten aufgrund von zentralen Infrastrukturkomponenten. Wird für eine Release-Unit durchgeführt (z.b. ein allgemeiner Wartungsauftrag für Release-Unit XY). Geringe funktionalen Änderungen. Lässt sich kapseln bzw. ist autark/isoliert durchführbar. Kleinaufträge mit geringem Gesamtaufwand. Repräsentieren in der Regel Ausnahmefälle. Integration in ein anstehendes Fachrelease soweit möglich. Beseitigt Fehler aus der letzten Release-Einführung oder aktuelle unternehmenskritische Gefahren; Abbildung über jeden Release-Typen möglich Max. zwei pro Jahr Max. zehn pro Jahr, max. eins pro Monat Max. alle fünf Arbeitstage je Anwendungsbereich Nach Bedarf (Notfall) Seite 7 Release-Arten Delta-Releases: Umfassen nur neue oder kürzlich veränderte Soft- und Hardwarekomponenten. M Ideal, wenn Software von der übrigen Infrastruktur isoliert werden kann. Daher sind Komponenten-Releases im Regelfall Delta-Releases. + Geringer Aufwand für Erstellung, Tests. Keine Berücksichtigung von älteren Modulen, Schnelle Ersichtlichkeit von Abhängigkeiten. Full-Releases: Alle Komponenten (s) werden zusammen entwickelt, getestet und implementiert. Auch unveränderte Module/Teile werden integriert. + Alle Beziehungen werden getestet. Changes können integriert werden. Mit einem höheren Planungs- und Ressourcenaufwand verbunden. M M M M 4 M 5 Package-Releases: Kombinationen aus mehreren Full- und/oder Delta-Releases. Dienen zur Vergrößerung der Änderungsintervalle. Insbesondere bei Etablierung von neuen s/systemen. Daher sind Struktur-Releases im Regelfall Package-Releases. + Höhere Stabilität für Anwender. Integration neuer Funktionen, Behebung v. Fehlern. hohe Komplexität bei Planung, Vorbereitung und Durchführung. M M M M4 M5 C C C C4 Seite 8

10 Release-Identifikation Notwendigkeit eindeutiger Identifikationsnummern wegen der Möglichkeit gleichzeitiger Releases. Versionsnummer (eine oder mehrere Ziffern) verweist auf das betr.. Z. B. im Falle eines s "Lohnbuchhaltung": Strukturreleases: Gehaltssystem V., V., V. usw. Fachrelease: Gehaltssystem V.., V.., V.. usw. Komponentenrelease: Gehaltssystem V..., V..., V... usw. Versionsmanagement "Release" Versionsmanagement "Backout" Seite 9 Inhalt Release Motivation Definitionen Release -Prozess Einführungsplanung Release Business Case-Ansätze Release Praxis-Beispiele Zusammenfassung / Fazit Seite 0

11 ALM Disziplinen Business Value identifiziert Business Value geliefert Business/IT Governance Entwicklung IT Operations Business Value Programm Level Projekt Test Deployment Daily Build Projekt Backup Programm Check In Accepted Build Patches Seite ITIL Application Application Requirements Incident Mgmt. Capacity Mgmt. Problem Mgmt. Level Mgmt. Financial Mgmt. Optimise Operate Manage Change Release Design Build Project Requirem. Analysis SW-Design SW-Construction Test Deploy Seite

12 Release als Black- / Blue -box Anwender, Anwendungsentwicklung, Betrieb, Fachbereich Anfrage (CR) / Releaseauslöser Change Configuration Input Planungen und Vorhaben aus den Bereichen Release Output Release- Produktivsetzung PIR-Dokumentation Projektmanagement Seite Aktivitäten im Release Release Release-Richtlinie und Release planen und steuern sind als lang- und mittelfristige Aktivitäten angelegt. Diese kapseln und beeinflussen die operativen Tätigkeiten folgendermaßen: Die Release-Richtlinie enthält konkrete Vorgaben für die operativen Prozessschritte (wie z.b. Abnahme- und Qualitätskriterien, Vorgaben für Eskalationsplanungen, Verantwortungen usw.). Die lang- und mittelfristige Planung bezieht sich primär auf die terminliche Gestaltung des Release-Kalenders. Die kurzfristige Planung bezieht sich auf die konkrete Planung anstehender Releases, die sich aus der lang- und mittelfristigen Planung ableitet. Seite 5

13 Beziehungen zwischen Release und Change Anfrage (CR)/ Releaseauslöser Anwender, Anwendungsentwicklung, Betrieb, Fachbereich Change Prozess Change- Anforderung Change- Eröffnung und Terminierung Change- Planung und Kontrolle Change- Freigabe Change- Durchführung Change- Nachbewertung (PIR) Release Prozess Projektmanagement Seite 6 Zentrale Rollen im Release Rolle Prozess Owner Release Manager Release Koordinator Beschreibung ist verantwortlich für den Prozess trägt die Verantwortung für die Einhaltung der Prozessregeln und -abläufe des gesamten Prozesses zur Erreichung definierter Ziele überwacht den Prozess unter Verwendung von Kennzahlen (KPIs: Key Performance Indicators) analysiert Stärken und Schwächen und leitet Prozessverbesserungen ein (CSIP: Continuous Improvement Program) führt die übergreifende lang- und mittelfristige Planung durch steuert den gesamten Prozess ist die Eskalationsinstanz für die Release-Koordinatoren pflegt und aktualisiert die Release-Richtlinie koordiniert spezifische, ihm zugewiesene Releases (sowohl Fach- als auch Strukturreleases) ist verantwortlich innerhalb der Linienorganisation / eines Verfahrens für die Koordination von Releases Seite 8

14 Inhalt Release Motivation Definitionen Release -Prozess Einführungsplanung Release Business Case-Ansätze Release Praxis-Beispiele Zusammenfassung / Fazit Seite 9 Projektplan Einführung Release Initialisierungsphase Ergebnis-Abstimmung mit Kunden Meilenstein Basiseinführung Test Pilotierung Awareness-Maßnahmen Abstimmung der Arbeitsergebnisse und Konsensfindung mit dem Kunden Start der Basiseinführung Schnittstellen Toolanpassung Reporting Abschluss und Abnahme Release ist eingeführt Release Stabilisierung ist abgeschlossen Stabilisierung Seite 0

15 Ergebniskette Initialisierungsphase Plattformen und - Bäume Release Definitionen Release-Typen und -Arten Basis-Release Richtlinie Namenskonventionen ITIL Review und Potenzial- Analyse Prozess- Aktivitäten Prozess- Ablaufgrafiken Prozess- Schnittstellen Prozess- Dokumentation* Basis- Einführung Schnittstellen- Workshops Präsentation Lenkungsausschuss Vorgehensmodell Business Case (Annahmen) Einführungstaktik Einführungsplan Business Case (grob) Abstimmung mit Kunde.- Monat Monat Anf. 7. Monat 7. Monat ab hier * Ziele, Inhalte, Rollen, Leistungsabgrenzung, Eskalationsverfahren, Schnittstellen Seite Enterprise Process Integration (EPI). Initialisierung. Analyse. Planung und Konzeption 4. Durchführung und Steuerung 5. Projektabschluss 6. Betrieb Mitarbeiter Prozesse Strategie Vision Zieldefinition Teambildung und -Briefing Business / IT- Alignment Strategie- Assessment Prozessreife- Assessment Mitarbeiter- Assessment - Assessment Strategiekonzept High Level Prozess-Modell Detail-Prozess-Modell ITIL-Training und -Übung -Ausbildung Strategieumsetzung Prozess- Implementierung Prozess-Workshops -Coaching Strategieüberprüfung und Review Prozessüberwachung Prozess- Überprüfung und Review Überarbeitung Betrieb Betrieb Verbesserung IT Kultur und Organisation Change- Ankündigung Ziellandschaft Organisations -Assessment Infrastruktur- Assessment Awareness Tool-Anforderungen Tool-Auswahl Marketing System-Installation Review Systemoptimierung Betrieb Betrieb Projektmanagement und Controlling ITIL-basiertes Release als Bestandteil des Application Lifecycle ALM Februar 008 Seite

16 Inhalt Release Motivation Definitionen Release -Prozess Einführungsplanung Release Business Case-Ansätze Release Praxis-Beispiele Zusammenfassung / Fazit Seite Business Case Ansätze Annahme : Reduzierung der Störungsanzahl Mehraufwand für Korrekturen/Support durch Fehler aufgrund der Nichtbeachtung von Abhängigkeiten zwischen Änderungen Beispiel: firmeninterne Untersuchung (006): bei 59 von insgesamt 08 HotTickets Zusammenhang zu einem Change nachweisbar (55%) Annahme : Maßnahmenkonsolidierung Reduzierung der Störungsanzahl effiziente Nutzung von Ressourcen Erhöhung der Verfügbarkeit (Online- Zeit) der s und Systeme produktionsnähere Testumgebung Annahme : Verbesserung des Planungsprozesses Release als zentraler Informationslieferant Bereitstellung eines Verfahrens zur Identifizierung von Abhängigkeiten Senkung Support-Kosten Reduzierung Korrekturaufwand Senkung Support-Kosten Reduzierung Korrekturaufwand Aufwandsreduzierung Erhöhung Durchsatz und Termintreue Seite 4

17 Beispiele zur Darstellung der monetären Auswirkungen Kosten Termin- und Ressourcenplanung für den Projektverlauf (Kostenforecast für Projektaktivitäten) Nutzen Qualitativer Nutzen Reduzierung von Störungen in Produktion Verbesserung der Termin- und Ressourcenplanung (Prozessverbesserung) Ergebnisverbesserung (Projekte) Annahmen für Einsparungspotentiale ( monetärer Nutzen ) Senkung der Support-Kosten und der Kosten für Korrekturarbeiten Erhöhter Nutzeninkasso bei Konsolidierungs- und Optimierungsmaßnahmen Reduzierung von Sonderdiensten an großen Wartungswochenenden Seite 5 Fazit der Wirtschaftlichkeitsbetrachtung Rückschlüsse Kostensenkung ist nicht das Primärziel des Release s. Die Kostenseite (Projektkosten für Prozesseinführung) ist gut planbar. Qualitativer Nutzens lässt sich bewerten. Quantitativer Nutzen ist nicht einfach zu ermitteln. Release ohne Akzeptanz und Zusammenarbeit mit dem Kunden ist nicht denkbar. Die Einführung von Release ist eine strategische Entscheidung. Die Entscheidung zur Einführung von Release dient zur nachhaltigen Qualitätssteigerung und mittelbis langfristigen Kostensenkung. Seite 6

18 Inhalt Release Motivation Definitionen Release -Prozess Einführungsplanung Release Business Case-Ansätze Release Praxis-Beispiele Zusammenfassung / Fazit Seite 7 Praxis-Beispiele Versicherung Erfolgreiche Nutzung von Release seit Ende der 90er Jahre. Der Prozess wird regelmäßig weiterentwickelt, angepasst und ist fester Bestandteil der Prozessorganisation. Versicherung Betrieb von Release aufeinander abgestimmt für Außen- und Innendienst. Es werden pro Jahr 4 große Releases eingeführt. Versicherung Betrieb von Release mit bis 4 Major Releases pro Jahr. Versicherung 4 Nutzung Release Prozesse mit bis 4 Releases pro Jahr. Versicherung 5 Betrieb von Release im Kontext Change Governance eingeführt. Ergebnis: Effizienzsteigerung um 0 bis 0 %. Seite 8

19 Inhalt Release Motivation Definitionen Release -Prozess Einführungsplanung Release Business Case-Ansätze Release Praxis-Beispiele Zusammenfassung / Fazit Seite 9 Zusammenfassung / Fazit Durch Release optimale Termin- und Resourcenplanung sowie eine Verbesserung des Informationsflusses weniger unterbrechungen aufgrund hinreichend getesteter Software Nachvollziehbarkeit und Auditierbarkeit von Änderungen Reduktion der Supportkosten Bei Einbeziehung von ITIL konsistente serviceorientierte Umsetzung und geregelte Zuständigkeiten Durch Release-Typen und -Arten flexible Anpassung an Erfordernisse Release dient zur nachhaltigen Qualitätssteigerung und mittelbis langfristigen Kostensenkung, belegt durch Erfolgsstorys aus der Praxis. Seite 40

20 Vielen Dank Folkert Jung Griegstraße 75, 76 Hamburg Fon: Fax: Mail: