MENU

ITIL: wo beginnen wir?

Posted on by ISO 20000, IT Governance, ITIL

Es sind knapp 12 cm ITIL Literatur in den 5 Core Books von ITIL Edition 2011. Was davon ist nun wirklich wichtig und wo beginnen mit der konkreten Umsetzung? Gleich vorneweg: jede Textpassage in den ITIL Büchern hat seine Berechtigung. Aber nicht jede Stelle ist gleich wichtig. Die Frage ist, mit was beginnen, ohne grosse theoretische Vorabklärungen zu treffen? Ein Blick auf den etablierten Service Management Standard ISO 20‘000 kann dafür grosse Hilfe leisten. Der Standard enthält eine Liste von Musskriterien zur Errichtung eines Service Management Systems. Der Standard konzentriert sich dabei auf knappen 25 Seiten auf diejenigen Punkte die auf jeden Fall umgesetzt werden müssen wenn eine ISO 20‘000 Zertifizierung angestrebt wird. Ist keine Zertifizierung angestrebt können diese Punkte auch nur als Leitfaden herangezogen werden was aus ITIL als eher wichtig einzustufen ist. Ein Auszug aus dem Standard illustriert im Folgenden einige der Kernpunkte:

Die Kernpunkte aus ITIL

1. Planung von neuen oder geänderten Services

Für die Planung von neuen oder geänderten Services sind mindestens die folgenden Punkte zu beachten bzw. zu regeln:

  • Zuständigkeiten und Verantwortlichkeiten für Design, Development und Transition-Aktivitäten
  • die Kommunikation an die betroffenen Parteien
  • Ressourcen (personelle, technische und finanzielle)
  • Zeitpläne für die geplanten Aktivitäten
  • Identifizierung, Bewertung und Management von Risiken
  • Abhängigkeiten von anderen Services
  • Anforderungen für Tests für die neuen oder geänderten Services
  • Service Akzeptanzkriterien
  • messbare Grössen für die Lieferergebnisse der neuen oder geänderten Services

2. Design und Entwicklung von neuen oder geänderten Services

Der neue oder geänderte Service muss mit mindestens folgenden Punkten entworfen und dokumentiert werden:

  • Zuständigkeiten und Verantwortlichkeiten für die Lieferung der neuen oder geänderten Services
  • neuer oder geänderter Personalbedarf, einschliesslich der Anforderungen für eine angemessene Ausbildung, Fähigkeiten und Erfahrungen
  • finanzieller Ressourcenbedarf für die Lieferung von neuen oder geänderten Services
  • dokumentierte neue oder geänderte Verträge und andere Vereinbarungen, um die Veränderungen in den Service-Anforderungen aufzuzeigen
  • Änderungen des Service Management Systems
  • neue oder geänderte SLAs
  • Updates vom Service-Katalog
  • Verfahren, Massnahmen und Informationen für den Betrieb von neuen oder geänderten Services

3. Transition von neuen oder geänderten Services

Die neuen oder geänderten Services werden getestet, um sicher zu stellen, dass sie die Service Anforderungen und das dokumentierte Design erfüllen. Die neuen oder geänderten Services sind gegen die vorab vereinbarten Service Akzeptanzkriterien durch den Service-Provider und die betroffenen Parteien zu überprüfen. Wenn der Service die Akzeptanzkriterien nicht erfüllt, werden der Service-Provider und die betroffenen Parteien eine Entscheidung über notwendige Massnahmen und deren Umsetzung treffen. Der Release- und Deployment Management Prozess wird verwendet, um freigegebene neue oder geänderte Services in die Live-Umgebung einzuführen. Nach Abschluss der Transition Tätigkeit rapportiert der Service-Provider den betroffenen Parteien die Ist-Ergebnisse gegenüber den erwarteten Ergebnissen.

4. Service Level Management

Der Service-Provider vereinbart mit dem Kunden, welche Services geliefert werden. Der Service-Provider vereinbart mit dem Kunden einen Service-Katalog. Der Service-Katalog umfasst die Abhängigkeiten zwischen den Services und den Service-Komponenten. Für die gelieferten Services werden ein oder mehrere SLAs mit dem Kunden vereinbart. Bei der Erstellung von SLAs berücksichtigt der Service-Provider die Service-Anforderungen. SLAs umfassen vereinbarte Service-Ziele, Workload Charakteristiken und Ausnahmen. Der Service-Provider hat Services und SLAs mit den Kunden in geplanten Abständen zu überprüfen. Änderungen an den Service-Anforderungen, Service-Katalog, SLAs und andere dokumentierte Vereinbarungen werden vom Change Management Prozess gesteuert.

5. Service Reporting

Service Reporting umfasst mindestens:

  • Leistungen gegenüber Service-Zielen
  • relevante Informationen über wichtige Ereignisse, mindestens Major Incidents, den Einsatz neuer oder geänderter Services und das Auslösen des Service-Continuity-Plan
  • workload Charakteristiken

    Service Reporting

  • Trend-Informationen
  • Kundenzufriedenheitsmessungen, Service-Beschwerden und deren Auswertungen

6. Service Continuity und Availability

Die vereinbarten Service-Continuity und Availability-Anforderungen müssen mindestens folgendes beinhalten:

  • Zugriffsrechte auf die Services
  • Service-Reaktionszeiten
  • End-to-end Availability des Services

Der Service-Continuity-Plan muss mindestens folgende Angaben enthalten:

  • Verfahren, die im Falle eines grösseren Vorfalls umgesetzt werden
  • die Availability-Ziele, wenn der Service Continuity Plan ausgeführt wird
  • Recovery-Anforderungen
  • Ansatz für die Rückkehr zu normalen Arbeitsbedingungen

Auch wenn der Zugang zum normalen Service-Standort verhindert sein sollte, müssen der Service-Continuity-Plan, die Kontaktlisten und die CMDB zugänglich sein.

Service-Continuity-Pläne sind gegen die Service-Continuity-Anforderungen zu testen. Service-Continuity und Availability Pläne müssen nach grösseren Änderungen am Service-Umfeld, welcher der Service-Provider betreibt, erneut getestet werden.

7. Budgeting und Accounting für Services

Der Budgeting und Accounting Prozess hat klar definierte Schnittstellen zu den anderen Financial Management Prozessen der Organisation.

Es soll Richtlinien und dokumentierte Verfahren geben für Service-Komponenten, einschliesslich mindestens:

  • Assets, einschliesslich Lizenzen
  • gemeinsam genutzte Ressourcen
  • Gemeinkosten
  • Investitions- und Betriebskosten
  • extern erbrachter Dienstleistungen
  • Personal
  • Einrichtungen

    Finanzen

    Budgeting & Accounting

Weiter müssen folgende Punkte geklärt sein:

  • Aufteilung indirekter Kosten und die Zuteilung von direkten Kosten für den Service
  • die Gesamtkosten für jeden Service
  • eine wirksame finanzielle Kontrolle und Freigabe

Der Service-Provider überwacht und meldet die Kosten gegenüber dem Budget, er überprüft die finanziellen Prognosen und behält die Kosten im Griff. Die Informationen werden dem Change Management Prozess zur Verfügung gestellt, um für RfCs die Kalkulation zu unterstützen.

8. Capacity Management

Der Service-Provider ermittelt und vereinbart Kapazitäts- und Leistungsanforderungen mit dem Kunden und den betroffenen Parteien. Der Service-Provider erstellt, implementiert und pflegt eine Kapazitätsplanung unter Berücksichtigung der Ressourcen. Änderungen am Capacity Plan werden durch den Change Management Prozess gesteuert. Die Capacity Plan enthält mindestens folgende Angaben:

  • aktuelle und prognostizierte Nachfrage nach Services
  • erwartete Auswirkungen der vereinbarten Anforderungen an Availability, Service-Continuity und Service-Levels
  • Zeitpläne, Schwellen und Kosten für Upgrades
  • mögliche Auswirkungen von gesetzlichen, regulatorischen, vertraglichen oder organisatorischen Veränderungen
  • mögliche Auswirkungen neuer Technologien und neuer Techniken

    Kapazitäten

    Capacity Management

9. Information Security Management

Das Top Management des Service-Providers muss eine Information Security Policy genehmigen und diese an alle Mitarbeiter und – soweit erforderlich – auch an die Kunden und Lieferanten kommunizieren.

Es sind angemessene Security Controls zu dokumentieren und einzusetzen, um die Anforderungen der Security Policy durchzusetzen und die Risiken bezüglich Zugriff auf Service, Systeme und Daten zu managen.

Security Incidents sind so schnell wie möglich und mit dem etablierten Incident Management Verfahren zu bearbeiten. Es sind Verfahren für die Nachforschung aller Security Incidents einzuführen und bei Vorfällen entsprechende Management-Massnahmen zu treffen. Changes hinsichtlich neuer oder geänderter Information Security Risiken müssen beurteilt werden. Zudem müssen die Changes hinsichtlich potentieller Auswirkungen auf die existierende Information Security Policy und der zugrundeliegenden Kontrollen untersucht werden.

10. Business Relationship Management

Der Service-Provider identifiziert und dokumentiert die Kunden, die Anwender und betroffene Parteien der Services. Für jeden Kunden wird der Service-Provider eine ausgewiesene Person zuteilen, welche verantwortlich ist für das Management der Kundenbeziehung und die Kundenzufriedenheit.

Der Service-Provider etabliert einen Mechanismus für die Kundenkommunikation. Der Kommunikationsmechanismus fördert das Verständnis für die wirtschaftlichen Rahmenbedingungen, in denen die Services zu betreiben.

Der Service-Provider hat die Erbringung der Services in geplanten Abständen unter Mitwirkung des Kunden zu überprüfen.

Änderungen an den Service-Anforderungen werden über den Change Management Prozess gesteuert. Änderungen an den SLAs werden mit dem Service Level Management Prozess koordiniert. Die Definition einer Service-Beschwerde wird mit dem Kunden vereinbart. Es wird ein dokumentiertes Verfahren zur Verwaltung von Kunden-Service-Beschwerden eingeführt. Der Service-Provider hat diese aufzunehmen, zu untersuchen, entsprechend zu handeln, zu berichten und abzuschliessen. Kann eine Beschwerde nicht über den normalen Weg gelöst werden, steht dem Kunden die Eskalation zur Verfügung.

Der Service-Provider hat die Kundenzufriedenheit der Services in geplanten Abständen mit einer repräsentativen Stichprobe von Kunden und Nutzer zu messen.

11. Supplier Management

Für jeden Lieferanten wird der Service-Provider eine Person benennen, die für die Verwaltung der Beziehung, den Vertrag und die Leistung des Lieferanten verantwortlich ist. Der Service-Provider und der Lieferant dokumentieren dies in einem Vertrag. Der Vertrag sollte folgendes beinhalten:

  • Umfang der Leistungen die durch den Lieferanten geliefert werden
  • Abhängigkeiten zwischen Services, Prozessen und betroffenen Parteien
  • Anforderungen an den Lieferanten
  • Service-Ziele
  • Ausnahmen
  • Zuständigkeiten und Verantwortlichkeiten des Service-Providers und des Lieferanten
  • Die vom Lieferanten zur Verfügung gestellten Berichterstattungen und Kommunikationen
  • Basis für die Verrechnung
  • Tätigkeiten und Zuständigkeiten für die erwartete oder vorzeitige Beendigung des Vertrages und die Übertragung von Services an eine andere Partei

Der Service-Provider prüft, ob der Hauptlieferant seine Unterlieferanten verwaltet und diese prüft und ob sie die vertraglichen Verpflichtungen erfüllen. Änderungen des Vertrages werden durch den Change Management Prozess gesteuert. Der Service-Provider überwacht die Leistungen des Lieferanten gegenüber den Service-Zielen und anderen vertraglichen Verpflichtungen in geplanten Abständen. Die Ergebnisse werden schriftlich festgehalten und überprüft, um die Ursachen von Fehlern und Verbesserungsmöglichkeiten zu identifizieren.

12. Incident and Service Request Management

Es ist ein dokumentiertes Verfahren mit folgenden Punkten für alle Ereignisse zu definieren:

  • Aufnahme / Erfassung als Datensatz
  • Zuweisung von Prioritäten
  • Klassifizierung
  • die Aktualisierung der Datensätze
  • Eskalation
  • Lösung
  • Schliessung

Es wird ein dokumentiertes Verfahren für die Verwaltung von Service-Requests vorausgesetzt. Es beginnt mit der Aufnahme und reicht bis zur Schliessung derselben. Incidents und Service-Requests werden nach diesem Verfahren verwaltet. Der Service-Provider berücksichtigt für die Priorisierung von Incidents und Service-Requests die Auswirkungen und Dringlichkeiten des Incidents bzw. des Service-Requests.

Incident Management

Incident Management

Der Service-Provider stellt sicher, dass das involvierte Personal von Incident und Service Request Management Prozess Zugang zu relevanten Informationen hat und diese nutzbringend einsetzen kann. Die relevanten Informationen umfassen Known Errors, Problem Lösungen und die CMDB. Informationen über den Erfolg oder Misserfolg von Releases und zukünftigen Release-Daten erfolgen durch den Release und Deployment Management Prozess. Der Service-Provider informiert den Kunden über den Fortschritt des Ereignisses bzw. über die Service-Requests. Wenn Service-Ziele nicht erreicht werden können, wird der Service-Provider den Kunden und die betroffenen Parteien darüber informieren und nach dem Verfahren eskalieren.

Der Service-Provider bestimmt und dokumentiert mit dem Kunden die Definition eines Major Incident. Major Incidents sind zu klassifizieren und nach einem dokumentierten Verfahren zu verwalteten. Das Top Management muss über Major Incidents informiert werden. Das Top Management muss sicherstellen, dass eine Person für die Behandlung des Major Incidents ernannt wird. Ist der vereinbarte Service wiederhergestellt, wird der Major Incident überprüft, um Möglichkeiten für Verbesserungen zu identifizieren.

13. Problem Management

Es wird ein dokumentiertes Verfahren definiert, um Probleme zu identifizieren und zu minimieren oder zu vermeiden. Die Vorgehensweise bei Problemen beinhaltet:

  • Identifizierung
  • Aufnahme / Erfassung als Datensatz
  • Zuweisung von Prioritäten
  • Klassifizierung
  • die Aktualisierung der Datensätze
  • Eskalation
  • Lösung
  • Schliessung

Der Service-Provider hat Daten und Trends von Ereignissen und Problemen zu analysieren, um deren Ursachen zu identifizieren um potenzielle präventive Massnahmen einzuleiten. Probleme, die Änderungen an einem CI nötig machen, werden mit einem Änderungsantrag gelöst.

14. Configuration Management

Die einzelnen Arten von CI werden definiert und dokumentiert. Die Informationen zu den einzelnen CI werden erfasst; mit einer wirksamen Kontrolle ist sicherzustellen, dass sie aktuell sind. Die Informationen umfassen mindestens:

  • Beschreibung des CI
  • Beziehungen zwischen den CI‘s
  • Status
  • Version
  • Ort
  • verbundene Änderungsanträge (RfCs)
  • verbundene Probleme und Known Errors

CI’s können eindeutig identifiziert werden und sind in einer CMDB dokumentiert. Die enthaltenen Informationen der CMDB sind zuverlässig, genau und aktuell. Es braucht klare Regeln/Kontrollen für Aktualisierungen. Der Service-Provider auditiert die gespeicherten Informationen in der CMDB, in festgelegten Abständen. Werden Mängel festgestellt, so wird der Service-Provider notwendige Massnahmen ergreifen und darüber rapportieren. Änderungen an CI‘s müssen rückverfolgbar und prüfbar sein, um die Integrität der CI‘s der gespeicherten Informationen in der CMDB zu gewährleisten. Masterkopien von digitalen CI‘s müssen in sicheren physischen und elektronischen Bibliotheken geführt werden und zu den Configuration Records referenzierbar sein. Es braucht eine definierte Schnittstelle zwischen dem Configuration Management Prozess und Financial Asset Management Prozess

15. Change Management

Eine Change-Management-Richtlinie wird definiert und eingeführt. Es wird ein dokumentiertes Verfahren zur Aufzeichnung, Klassifizierung, Bewertung und Genehmigung von Änderungswünschen (Requests for Change) benötigt. Der Service-Provider hat mit dem Kunden die Definition eines Emergency Changes zu vereinbaren und zu dokumentieren. Es wird ein dokumentiertes Verfahren zum Umgang von Emergency Changes benötigt. Alle Änderungen an einem Service oder einer Service-Komponente benötigen einen Antrag auf Änderung (Requests for Change). Der Umfang, was unter einem Änderungsantrag verstanden wird, muss definiert werden. Alle Anträge auf Änderung werden dokumentiert und klassifiziert. Anträge auf Änderung werden anhand von Informationen aus dem Change Management Prozess und anderen Prozessen beurteilt. Der Service-Provider und die betroffenen Parteien werden über die Annahme von Änderungsanträgen entscheiden. Bei der Entscheidungsfindung werden Risiken, die möglichen Auswirkungen auf Services und Kunden, Service-Anforderungen, geschäftliche Vorteile, technische Machbarkeit und die finanziellen Auswirkungen berücksichtigt.

Genehmigte Änderungen werden entwickelt und getestet. Es gibt eine Planung wo die Änderungen, Einzelheiten über die genehmigten Änderungen und deren geplanten Einführungstermine festgehalten werden. Dieser Zeitplan wird an die betroffenen Parteien kommuniziert. Der Zeitplan für Änderungen gilt als Basis für die Planung für das Deployment von Releases.

Change Management

Change Management

Die CMDB Informationen sind nach dem erfolgreichen Deployment von Änderungen zu aktualisieren. Der Service-Provider prüft Änderungen auf ihre Effektivität und vereinbart Massnahmen mit denbetroffenen Parteien.

16. Release und Deployment Management

Der Service-Provider vereinbart mit dem Kunden Release-Richtlinien unter Angabe der Häufigkeit und Art der Releases und führt diese ein. Ein Release kann sich aus einer oder mehreren Änderungen zusammensetzen.

Der Service-Provider wird mit dem Kunden und betroffenen Parteien den Einsatz von neuen oder geänderten Services und Service-Komponenten in der Live-Umgebung planen. Die Planung wird mit dem Change Management Prozess koordiniert und verweist auf die entsprechenden Anträge auf Änderung (Requests for Change), Known Errors und Probleme, die durch diese Releases geschlossen werden. Die Planung umfasst die Daten für das Deployment eines jeden Releases, die Lieferobjekte und Methoden des Deployment.

Der Service-Provider hat mit dem Kunden die Definition eines Emergency Release zu vereinbaren und zu dokumentieren. Emergency Release werden in einem dokumentieren Verfahren abgehandelt. Das Verfahren hat auch eine Schnittstelle zum Emergency Change Verfahren.

Releases werden aufgebaut und werden vor dem Einsatz getestet. Eine kontrollierte Akzeptanz Testumgebung wird für den Bau und Test von Releases dazu verwendet. Die Akzeptanzkriterien für den Release werden mit den Kunden und den betroffenen Parteien vereinbart. Die Freigabe wird anhand der vereinbarten Abnahmekriterien überprüft und vor dem Deployment genehmigt. Wenn die Akzeptanzkriterien nicht erfüllt sind, wird der Service-Provider eine Entscheidung über die notwendigen Massnahmen und das Deployment mit betroffenen Parteien treffen. Die erforderlichen Tätigkeiten um einen nicht erfolgreichen Release rückgängig zu machen oder zu beseitigen müssen geplant und durchgeführt und – soweit möglich – getestet werden. Der Erfolg oder Misserfolg des Releases wird überwacht und analysiert.

Management System

ISO 20’000 ist ein Standard für ein Management System. Er enthält daher auch für ein Management System spezifische Anforderungen. Ein Auszug illustriert auch dazu einige der Kernpunkte:

1. Management Verantwortung

Es muss eine Service Management Policy erstellt werden. Weiter muss auch ein Service Management System Verantwortlicher definiert werden.

2. Document Management

Service Level Agreements (SLAs) müssen dokumentiert werden. Prozesse und Verfahren sind zu dokumentieren. Aufzeichnungen zum Nachweis des effektiven Betriebs der Prozesse müssen dokumentiert werden. Es ist ein Dokumentations-Management System aufzubauen, welches die Abläufe und Verantwortlichkeiten für die Erstellung, den Review, die Freigabe, die Pflege, die Entsorgung und die Kontrolle von Dokumenten und Aufzeichnungen (Records) festlegt.

3. Ressourcen Management

Alle Service-Management-Rollen und Verantwortlichkeiten müssen zusammen mit den dazu notwendigen Kompetenzen zur wirksamen Umsetzung definiert und aufrechterhalten werden. Die Kompetenzen der Mitarbeiter sowie der Trainings-Bedarf sind regelmässig zu überprüfen Das Top Management ist verantwortlich, dass genügend und erfahrende Mitarbeiter vorhanden Sind.

Ressourcen Management

Ressourcen Management

4. Scope Definition

Der Umfangs und Wirkungsbereichs des Service-Management-Systems ist zu definieren. Der Scope kann folgende Aspekte berücksichtigen:

  • Geographische Lokation des Service-Providers
  • Lokation der Kunden
  • Technologie für die zu erbringenden Services

5. Planung, Implementierung, Betrieb, Überwachung und Verbesserung

Es müssen der Umfang, die Ziele des Service Management Systems, die erforderlichen Prozesse, Rollen und Verantwortlichkeiten, Ressourcen etc. geplant werden.

Budgets, Rollen und Verantwortlichkeiten, Ressourcen müssen zugewiesen werden. Die Prozesse müssen gemanagt werden, die Leistungen von Service-Management-Aktivitäten müssen überwacht werden, Risiken der Services müssen identifiziert, Bewertet und gemanagt werden.

Der Service-Provider muss die Effektivität der Prozesse mit Messungen und Überwachen von umgesetzten Massnahmen belegen. Das Top-management muss in regelmässigen Abständen Audits und Management Reviews planen und durchführen.

Die Verbesserung umfasst ein dokumentiertes Verfahren einschliesslich der Kompetenzen und Verantwortlichkeiten für die Identifizierung, Dokumentation, Auswertung, Genehmigung, Priorisierung, Messung und Berichterstattung von Verbesserungen.

Der Nutzen von ISO 20‘000

Auch wenn ISO 20‘000 in einigen wichtigen Punkten über ITIL hinausgeht, insbesondere beim Aspekt des Management Systems, hat die Anlehnung an ISO 20‘000 folgende konkreten Vorteile.

  • Konzentration zu Beginn weg auf die Kernpunkte und Verhinderung von Ressourcenverschwendung durch ‚Experimente‘
  • Falls in Zukunft doch mal eine ISO 20‘000 Zertifizierung angestrebt wird, ist man bereits gut positioniert.

Der Service Management Standard  ISO 20‘000 ist also für alle IT Organisationen relevant, ungeachtet dessen ob die Organisation sich zertifizieren möchte der nicht. Wenn Sie ihr Service Management System entwickeln möchten, wagen Sie einen Blick auf den etablierten Service Management Standard ISO 20‘000. Gerne unterstütze ich Sie dabei.

Eine Antwort auf ITIL: wo beginnen wir?

  1. […] Die Kernpunkte kurz und knackig extrahiert  […]

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Ähnliche Beiträge

« »