SQM 2006 Applying the ITIL Standard to an E-Gov Website Harry M. Sneed harry.sneed@anecon.com www.anecon.com
Implementing the ITIL Standard in the State of Saxony Defining an ITIL Framework for Operations & Services Defining the appropriate processes Change Management Configuration Management Problem Management Release Management Customer Service SQM 2006 - Seite 2
IT-Service-Management Service-Support Service-Delivery Service-Desk Incident-Management Problem-Management Configuration-Management Release-Management Service-level-Management Availability-Management Capacity-Management IT-Continuity-Management Security-Management ITIL Event Manager Management- Data-Warehouse Integration Layer Configuration- Management-Database Directory Monitoring und Metering IT-Infrastrucure-Management Deploying und Discovering Security und Protecting Operating und Maintaining The Goal of the ITIL Implemenation for the state of Saxony was to integrate IT Operations with IT Services in a common Framework. SQM 2006 - Seite 3
Defining an ITIL Framework Mittel- und langfristige Serviceplanung Management Kunde Commercial Policy Relationship Management Account Management Service Level Management Strategic Prozesses Personnal & Architectures Organisation Service Entwicklung Service Design Service Build& Test Security Management Financel Management Service Delivery Finance Availability& Continuity Management Capacity Management Lieferant RFC Change Management Operativer Service Anwender Incident Management Service Desk Problem Management Configuration Management RFC Release Management Service Support Leistungserbringung data Services Das IPW Modell SQM 2006 - Seite 4
Defining the ITIL Processes SQM 2006 - Seite 5
Change Management SQM 2006 - Seite 6
Organisation of Change Management Business Modell Software Modell QS-Beauftragte Produktleiter Benutzer Organisator Aufträge Software Daten Produktion Wartungsbetrieb Metrikdatenbank Wartungsteam SQM 2006 - Seite 7
Problem Management Produktionsumgebung Der Blitz schlägt ein Information zur Fehlerfindung Softwareprodukt Hilfe! Software Repository falsche Ergebnisse Kein Grund zur Panik!!? # ^$ - Umstands- Info perplexer Benutzer E-Mail Anzeige Fehlermeldung System- Doku Mängelgeschichte Mängel DB Fehlermeldung Kundenbetreuer Trouble Shooter Source Code Wo ist die Ursache? System- Instandhaltung SQM 2006 - Seite 8
Problem Classification Nach IEEE Standard 1044 Instandhaltung Routinekorrektur Urgent = Fatale Fehler (1) Absturz/Datenverlust/Schadensfall Gewicht = 8 High = verhindernd (2) Weitere Verarbeitung nicht möglich Gewicht = 4 Keine Umgehungsmöglichkeit Medium = erschwerend (3) Schwerer Fehler, Produktion gefährdet Gewicht = 2 Umgehung möglich Low = störend (4) Leichter Fehler, Produktion nicht gefährdet Gewicht = 1 Unknown = zu klären (5) Nicht einzuordnen, leicht korrigierbar Gewicht = 0 SQM 2006 - Seite 9
Problem Tracking Fehlermeldung Problem Tracking System Schwere Korrekturabnahme Fehlerklassifizierung Validation Fehleranweisung Fehleranalyse Ursache Beseitigung Fehlerspeicherung Mängel DB Fehler registriert, klassifiziert, gespeichert, korrigiert, validiert SQM 2006 - Seite 10
Problem Recording Fehlerverwaltung verfolgt Fehlermeldungen Kundenbetreuung meldet Fehler Fehlerschwere Fehlertyp Fehlerauswirkung Fehlerursache Fehlerbeschreibung Fehlerstatus Korrekturmaßnahmen Instandhaltung meldet Status Fehlerberichte SQM 2006 - Seite 11
Configuration Management geplant Configuration Item Dokument Source Testfall in Arbeit fertig Softwareelement qualitätsgeprüft Objektzustände SQM 2006 - Seite 12
Check in/ Check out Procedures Präsentation Check out ----------------- ----------------- ----------------- Vor Image Softwareelement Nach Image Ist während der Verarbeitung gesperrt Check in Verarbeitung Konfigurationsbibliotheken SQM 2006 - Seite 13
Release Management Release Manager Automatisierte Prozedur ---------- ---------- ------- Source Bibliothek Version Extraction Compile & Build Verteiler ---------- ---------- ------- Source Code Byte Code ---------- ---------- ------- Endanwender SQM 2006 - Seite 14
Reviewing the ITIL Concept For the State of Saxony Steps of the ITIL Review Process Purpose of a Review Sample Review Checkliste Review Summary Report Operations Metrics Service Metrics The SERVQUAL Method of measuring user satisfaction SQM 2006 - Seite 15
Steps of the ITIL Review Process Analyse des Service Level Agreements Analyse des Betriebs- & Service Konzeptes Aufstellung von Fragen zum Konzept Notierung der Konzeptmängel Übergabe des Mängelreports Besprechung der Mängel mit den Autoren des Konzeptes Nachkontrolle des verbesserten Konzeptes Verfassung eines Abnahmeberichtes Besichtigung und Messung des laufenden Betriebes SQM 2006 - Seite 16
Purpose of a Review Eine Methode zum Testen von Papier mittels eines formalisierten, kritischen, fachlichen Gesprächs über erzeugte Zwischen- und Endprodukte unter Ausschluß des Managements. Gespräch über seine Probleme, ohne die Angst, daß man bewertet wird. Vorstellen von Ideen und Verfahren. Verteidigen gegen Einwände. Vier Augen sehen mehr als zwei. SQM 2006 - Seite 17
Sample Review Checklist Seite Kap. Mangel Status Erklärung Geplante Maßnahmen 11 5.1 12 5.1.5 13 5.2.4 14 5.2.6 Die einzelne Service Prozesse sind nicht ausreichend dokumentiert Eine dedizierte Instandhaltungsgruppe ist nicht vorgesehen, obwohl die Kontinuität der Leistung selbst zugesagt ist. Backup und Wiederherstellung (Desaster Recovery) müssen wesentlich konkreter (plattformspezifisch) beschrieben werden. Die Verantwortung für das Security Management ist nicht geregelt. Es müsste hier eine Brücke zum Sicherheits-Konzept geben. S Ok S Ok S Ok S Ok Es gehören Prozess- Ablaufdiagramme dazu Für Produkte dieser Art braucht man eine ständig verfügbare Person oder Gruppe um nach Bedarf einzuspringen. Das Betriebskonzept muß viel tiefer in Detail gehen. Die jetztige Beschreibung ist zu oberflächlich. Service und Security Konzepte sind nicht aufeinander abgestimmt Für die Prozesse Change M, Problem M, Release M, Incident M, Config M sollten wenigstens detailliertere Abläufe dargestellt werden. In Abschnitt 4.2.2 des Konzepts die Aussagen aus Leistungsbeschreibung (1.3 OpM) als Konkretisierung für die einzelnen Prozessinhalte benutzen. Die Prozesse sollten auch möglichst strukturell gleich abgebildet werden (wie vereinbart), ggf. in unterschiedlichem Detaillierungsgrad. Betriebsteam als Rolle (7x24 mit Rufbereitschaft verfügbar) sollte als festes Team separat beschrieben werden. Allg. Beschreibung ist bis zum 8.3. möglich, detailliertere Server-Service-Matrix wäre dazu hilfreich. Logfiles, Anwendungen sind Themen, die bis zum 8.3.05 adressiert werden müssen. Rest wird spätestens bis Start Produktivumgebung im Rahmen der Fortschreibung des BSK / SNK eingearbeitet. o.k., Verweis auf Maßnahmen im SNK möglich, Umsetzung / Verantwortung muss im BSK beschrieben sein SQM 2006 - Seite 18
Review Summary Report schwere Mängel mittlere Mängel leichte Mängel 1 von 16 noch offen 1 von 34 noch offen 2 von 22 noch zu klären Eine Zusammenfassung aller in der Review-Vorbereitung gefundenen Mängel und Probleme ist in der beigelegten Tabelle wiedergegeben. Daraus geht hervor, dass alle bis auf 4 erledigt sind. Rework Eine Überarbeitung ist nicht erforderlich. Eine Überarbeitung ist erforderlich bis zum (Datum) Die Nachprüfung erfolgt durch (QS, Einzelprüfung, Wiederholungsreview) X Abnahme Das Produkt wird zur Abnahme empfohlen. Die abgenommene Version besitzt dann die Versionsnummer x.3. Das Produkt wird nicht zur Abnahme empfohlen. Summary: Ja In dem Betriebs und Service Konzept vom 24.03.2005 bleiben nur 4 geringe Mängel übrig, so dass eine Abnahme empfohlen wird. Von den schweren Mängel bleibt nur das Migrationskonzept übrig. Es kann erst nach Abnahme des Plattforms erfolgen, wird also erst im Mai erfolgen. Von den mittleren Mängel bleibt nur die Hotline Nummer zu bestimmen. Dies wird noch vor dem Inbetriebnahmes des Systems mitgeteilt. Von den leichten Mängel bleibt nur die Fehlerklassifizierung und die endgültige Regelung der Zustaendigkeiten übrig. Alle beide Fragen können noch bis zur Inbetriebnahme geklärt werden. SQM 2006 - Seite 19
Operations Metrics (Performance) Betriebszeit, bzw. die Zeit, in der die Funktionalität gemäß vereinbarter Service Level am Leistungsübergabepunkt zur Verfügung steht. Nutzungszeit, bzw. die Zeiten innerhalb der Betriebszeit, in denen die Funktionalität gemäß der vereinbarten Service Level am Leistungsübergabepunkt zur Verfügung steht, abzüglich der geplanten (z.b. Wartungszeit) und ungeplanten (z.b. Störungszeit) Ausfallzeiten. Wartungszeit, bzw. die Zeiten in denen auf Grund planmäßiger Wartungs- und Pflegearbeiten an zu betreibender Hard- und Software eine Nutzung des vereinbarten Services nicht möglich ist. Ausfallzeit, bzw. die Zeiten in denen das System aufgrund eines Abbruches nicht zur Verfügung steht maximale Wiederherstellungszeit, bzw. die Zeit die gebraucht wird das System nach einem gemeldeten Abbruch wieder in Betrieb zu bekommen. Verfügbarkeitszeit des Systems, bzw. die Zeit in der das System im Betrieb ist Mean-Time-to Failure Zeit, bzw das mittlere Zeitinterval zwischen Systemabbrüche SQM 2006 - Seite 20
Operations Metrics (Reliability & Efficiency) Anzahl der echten Systemausfälle, aufgeteilt nach Ausfallsschwere Anzahl der Sicherheitsverletzungen, aufgeteilt nach Schwere des Falls Anzahl Webtransaktionen, bzw. Benutzerseiten, pro Monat Fehlerdichte, bzw. die Anzahl gewichteter Fehler geteilt durch die Anzahl der Webtransaktionen pro Zeitinterval maximale und mittlere Antwortzeiten für alle Webtransaktionen eines Zeitinterval maximale und mittlere Durchlaufzeit für alle Hintergrundprozesse maximale und mittlere Speicherbelegung für die Datenbanken mittlere und maximale Serverauslastung für ein Zeitinterval mittlere und maximale Netzauslasttung für ein Zeitinterval SQM 2006 - Seite 21
Operations Metrics (User Satisfaction) Grad der Kundenzufriedenheit mit der Systembedienung Grad der Kundenzufriedenheit mit der Systemfunktionalität Grad der Kundenzufriedenheit mit dem Systemperformanz Grad der Kundenzufriedenheit mit der Systemzuverläßigkeit Grad der Kundenzufriedenheit mit der Systemsicherheit Grad der Kundenzufriedenheit mit dem IT-Betrieb insgesamt SQM 2006 - Seite 22
Service Metrics (Help Desk) die Dauer zur Anrufannahme durch den Mitarbeiter des User Help Desks Abständen in den der Störungsmelder über den Fortgang der Störungsbeseitigung unterrichtet wird Maximale Zeit, in der die Beantwortung einer Anfrage (z.b. über Telefon, Fax, E-Mail, usw.) erfolgt maximale Dauer einer Störungsbehebung mittlere Dauer aller Störungsbehebungen Menge der angenommenen Calls pro Monat Grad der Benutzerzufriedenheit mit dem HelpDesk Grad der Benutzerzufriedenheit mit der Freundlichkeit des Service Personals SQM 2006 - Seite 23
Service Metrics (System Support) Anzahl der gemeldeten Probleme (Problem Reports) Anzahl der vom Kunden selbst verursachten Probleme (Systembedienungsfehler) Mittlere Zeit in Minuten für die Behebung einfacher Fehler Mittlere Zeit in Stunden für die Behebung von Systemausfällen Maximale Zeit für einen System Restart Interval in Tage zwischen Releases Interval zwischen Statusberichten Regelmäßigkeit der Statusberichte Grad der Kundenzufriedenheit mit den Berichtswesen Grad der Kundenzufriedenheit mit der Reaktionszeit Grad der Kundenzufriedenheit mit den Releaseintervalen SQM 2006 - Seite 24
ServQual Method Das Grad der Benutzerzufriedenheit drückt sich in der Gap Score (G) aus. Die Gap Score ist ein Maß für die subjektive Beurteilung des Kunden bezüglich der Service Leistung G = P E P ist die Summe der Noten für die Ist-Zufriedenheit und E die Summe der Noten für die Soll-Zufriedenheit Der Kunde gibt seine Erwartungen für jedes Qualitätsmerkmal auf einer Skala von 0 bis 10 an, z.b. für Freundlichkeit des Service Desk Personals = 8 auf der Skala von 0-10 Der Kunde gibt seine Beurteilung für jedes Qualitätsmerkmal auf der Skala von 0 bis 10 an, z.b. für Freundlichkeit des Service Desk Personals = 4 auf der Skala von 0-10 Die Differenz von 4 zeigt eine alarmierende Unzufriedenheit Je größer der Gap zwischen Erwartung und Erfüllung desto größer die Unzufriedenheit mit dem Service. SQM 2006 - Seite 25
Summary The concept for the ITIL Implementation in the state of Saxony was prepared by a certified ITIL Engineer from T-Systems in less than two months The concept was reviewed by an independent QS company - ANECON - and corrected within a month. It took another two months to implement the processes specified in the ITIL concept by the service provider T-Systems The implemented processes were audited by the QS company and approved within 2 weeks following some minor enhancements The operations and service processes could go live on time and within budget at the end of June 2004. SQM 2006 - Seite 26