ITIL Intermediate Lifecycle Stream:

Transkript

1 ITIL Intermediate Lifecycle Stream: ZERTIFIKAT SERVICE TRANSITION Musterprüfung 1, Version 6.1 Komplexe Multiple-Choice-Fragen mit unterschiedlich gewichteten Antworten SZENARIOPAPIER Dieses Dokument enthält die Szenarien, auf die sich die acht Prüfungsfragen aus dem Fragenpapier beziehen. Für alle Fragen ist angegeben, welches der Szenarien für die jeweilige Frage relevant ist. Lesen Sie zur Beantwortung aller acht Fragen alle zugehörigen Szenarien sorgfältig durch. Ausgehend von den im Szenario angegebenen Informationen müssen Sie aus den vier angegebenen Antwortoptionen (A, B, C oder D) die Antwort auswählen, die Ihrer Meinung nach am besten zutrifft. Es darf immer nur EINE Antwort ausgewählt werden. Die Antworten werden nach folgendem Schema gewichtet: Wenn Sie die BESTE ANTWORT auswählen, erhalten Sie für die Frage 5 Wertungspunkte. Wenn Sie die ZWEITBESTE ANTWORT auswählen, erhalten Sie für die Frage 3 Wertungspunkte. Wenn Sie die DRITTBESTE ANTWORT auswählen, erhalten Sie für die Frage 1 Wertungspunkt. Wenn Sie den DISTRAKTOR (schlechteste Antwort) auswählen, erhalten Sie für die Frage keine Wertungspunkte. Die Prüfung gilt als bestanden, wenn Sie mindestens 28 von 40 Wertungspunkten erreichen (70 %). Seite 1 von 9

2 Szenario eins Eine Bank hat entschieden, ITIL Leitlinien als Grundlage ihres IT Service Management Frameworks zu nutzen. Als einer der ersten Prozesse soll das Change Management der Bank überarbeitet werden. Die Bank verfügt derzeit über mehrere Change Management Prozesse. Sie stützen sich jeweils vollständig auf das technische Team, das den Change ausführt, z. B. das Server-Team oder das Application-Team. Innerhalb der unterschiedlichen Teams werden die Change-Aktivitäten nicht einheitlich umgesetzt. Change-Genehmigungen werden je nach Change-Umfang meist ad hoc erteilt, statt auf Basis einer Risikobewertung im Zusammenhang mit dem Change. Die Bank erkennt, dass sie für ein konsistentes Change Management einen einheitlichen Prozess entwickeln und implementieren muss, der in der gesamten IT einzuhalten ist, und dass eine konsistente Change-Bewertung und -Autorisierung wichtige Erfolgsfaktoren sind. Während der Awareness-Kampagne wurde deutlich, dass von unterschiedlichen Stakeholdern erheblicher Widerstand ausgeht. Es besteht vor allem die Sorge, dass die Implementierung eines mehr formalisierten Change Management Prozesses zu einem erhöhten bürokratischen Aufwand führen könnte. Zugleich würde die Fähigkeit der IT einschränkt, schnell auf neue oder sich verändernde Geschäftsanforderungen zu reagieren. Die Stakeholder befürchten, dass dadurch die Bereitstellung von IT Services die derzeitigen Anforderungen noch weniger erfüllt oder die Mitarbeiter versuchen werden, den neuen Prozess zu umgehen. Eines der Ziele des Unternehmens ist die Verringerung der Anzahl der Major Incidents (schwerwiegenden Incidents) in Verbindung mit Changes. Derzeit werden etwa 70 % aller Major Incidents von fehlgeschlagenen Changes verursacht. Der Chief Information Officer (CIO) der Bank ist der Ansicht, dass die Anzahl an fehlgeschlagenen Changes nur durch die Implementierung eines einheitlichen Prozesses gesenkt werden kann, der mit vollständigen Prozessabläufen, Verfahren sowie Rollen und Verantwortlichkeiten dokumentiert wird. Seite 2 von 9

3 Szenario zwei Eine kleine, zentrale IT-Organisation stellt Services für vier äußerst unterschiedliche Geschäftsbereiche bereit. Kürzlich wurden mehrere Projekte implementiert, um Changes an wichtigen Systemen über alle Geschäftsbereiche hinweg vorzunehmen. Mehrere wichtige Stakeholder beklagten, dass mit diesen Erweiterungen nicht die erwarteten Verbesserungen erreicht wurden. Einige Systemänderungen führten sogar zu unbeabsichtigten Auswirkungen auf andere Geschäftsbereiche. Basierend auf diesem Feedback implementierte die IT einen offiziellen Change Evaluation Prozess zur Unterstützung der anderen bereits implementierten Service Transition Prozesse. Damit sollte auch sichergestellt werden, dass die kürzlich bei den Stakeholdern aufgetretenen Schwierigkeiten für künftige Changes vermieden werden. Der neue Change Evaluation Prozess stellt dem Change Manager einen Evaluierungsplan bereit. Der Plan gibt an, wie Changes evaluiert werden, um deren beabsichtigte Folgen nachvollziehen und mögliche unbeabsichtigte Folgen identifizieren zu können. Der Change Manager kann nicht erkennen, wie dies von Nutzen sein soll, und beschwert sich, dass es allein nicht ausreicht. Er schlägt vor, dass der Change Evaluation Prozess weiter gehen müsse, indem Anstrengungen unternommen werden, die Auswirkungen von Changes auf das Business besser zu verstehen, und hilfreichere Outputs geliefert werden, um die Service Transition Fähigkeiten zu verbessern. Der derzeitige Prozess-Manager für Service Validation and Testing ist sich nicht sicher, wie vorgegangen werden sollte. Seite 3 von 9

4 Szenario drei Der Chief Executive Officer (CEO) eines Versicherungsunternehmens hat ein Meeting mit dem neu eingestellten Chief Information Officer (CIO) einberufen, um Beschwerden zur mangelhaften Qualität der IT Services zu diskutieren. Aufgrund dieser Beschwerden drängt das Business-Management den CEO dazu, ein vollständiges oder teilweises Outsourcing der IT in Betracht zu ziehen. Der CIO hat eine Bewertung durchgeführt und ist der Meinung, dass die IT durch die Einführung eines strukturierteren Service Managements eine bessere Servicequalität liefern könne. Der CIO hat ITIL bereits in anderen IT-Unternehmen implementiert und ist überzeugt, dass dies der richtige Ansatz sei. Meetings mit den IT-Leitern haben ergeben, dass bereits einmal vergeblich versucht wurde, ITIL zu implementieren. Damals sahen die IT-Mitarbeiter keine Notwendigkeit für Veränderungen, so dass sie sich weigerten, ITIL Praktiken zu akzeptieren und einzusetzen. Da sie jetzt mit einem möglichen Outsourcing konfrontiert werden, sind einige IT-Mitarbeiter bereit, sich erneut mit ITIL auseinanderzusetzen, andere sträuben sich aber weiterhin dagegen. Der CIO weiß, dass sich ein erfolgreiches ITIL Programm neben der Implementierung neuer Praktiken auf das Management von organisatorischem Wandel konzentrieren muss. Er hat entschieden, einen Experten für organisatorischen Wandel zu engagieren, der auf den möglichen Widerstand der Mitarbeiter reagieren und zur reibungslosen Einführung und Nutzung von ITIL beitragen soll. Seite 4 von 9

5 Szenario vier Der kürzlich eingestellte Chief Information Officer (CIO) eines großen Unternehmens plant Qualitätsverbesserungen. Der CIO weiß, dass das Business die IT wegen der schlechten Qualität der bereitgestellten Services kritisiert hat und der IT kaum mehr zutraut, die künftigen Business- Strategien zu unterstützen. Der CIO möchte sicherstellen, dass die Anstrengungen und die Finanzierung in Bezug auf das IT Service Management für das Business von Nutzen sind. Der CIO hat mit dem Chief Executive Officer (CEO) gesprochen, um die wichtigsten Kritikpunkte des Business besser zu verstehen. Die Bedenken des Business betreffen Folgendes: Die IT hat Rollouts für Anwendungen und Upgrades vorgenommen, bei denen es zu unerwarteten Auswirkungen auf Services gekommen ist, die die Außendienstmitarbeiter des Unternehmens zur Erfassung von Verkaufsdaten einsetzen. Die Konsequenz waren Umsatzverluste. Einige Service- und Service Level Anforderungen, die das Business für Änderungen an die IT weitergegeben hat, gingen scheinbar verloren oder wurden von der IT vergessen oder ignoriert. Scheinbar implementiert die IT ohne Rücksprache einige Projekte, deren Mehrwert das Business nicht erkennen kann. Basierend auf dem Feedback des CEO ist der CIO der Auffassung, dass die IT die Bereitstellung neuer Services und Verbesserungen für das Business nicht richtig managt. Er glaubt, dass mit der Implementierung einiger Service Transition Prozesse die Schwierigkeiten behoben werden und der Wert der IT deutlich gemacht wird. Seite 5 von 9

6 Szenario fünf Ein internationales Unternehmen setzt seit zwei Jahren ITIL Leitlinien ein. Die Schwerpunkte sind Incident Management, Problem Management und der Service Desk. Das Unternehmen möchte zu einem Servicelebenszyklus wechseln und mit der Service Transition beginnen. Wenn sichergestellt wird, dass Service Transition den vom Unternehmen aggressiv betriebenen Wechsel zu Cloud-basierten Services unterstützen kann, ist dies ein Schlüssel zum Erfolg. Die Service Transition muss sich außerdem auf die Bereitstellung von dem konzentrieren, was das Business in erster Linie benötigt, wobei Einschränkungen bei Budget und Ressourcen zu berücksichtigen sind. Sie wurden kürzlich zum Service Transition Manager ernannt. Da Sie einmal in einem der größten Geschäftsbereiche des Unternehmens gearbeitet haben, kennen Sie den Wettbewerb in der Branche, in der das Unternehmen tätig ist, und die Notwendigkeit eines schnellen Deployments für neue und innovative Services. Sie wissen auch, dass die IT nicht immer so schnell wie erforderlich reagiert hat, was einige Geschäftsbereiche dazu veranlasst hat, die IT zu umgehen und ein Deployment extern gehosteter Cloud-basierter Services zur Unterstützung einiger interner Geschäftsprozesse durchzuführen. Diese Geschäftsbereiche haben nun Schwierigkeiten, Changes an diesen Services zu unterstützen und zu managen, und arbeiten mit der IT zu folgenden Zwecken zusammen: (1) Einige der Services wieder zu internen Services machen (2) Die Services mit anderen Services in der Produktion integrieren (3) Veraltete Services abschaffen, die keinen Mehrwert geliefert haben, aber noch immer genutzt werden Damit ein kontinuierliches Engagement für die Service Transition entsteht, müssen das Management von Business und IT davon überzeugt sein, dass durch die Service Transition die Herausforderungen für das Unternehmen bewältigt und messbare Vorteile erzielt werden können. Seite 6 von 9

7 Szenario sechs Ein Unternehmen verfügt über einen gut etablierten Service Desk und hat Request Fulfillment, Incident, Problem und Change Management implementiert. Das Change Management konzentriert sich derzeit auf Service-Assets, die geschäftskritisch sind oder behördlicher Kontrolle unterliegen. Jetzt möchte das Unternehmen Service Asset and Configuration Management (SACM) implementieren, aber zwischen wichtigen Stakeholdern bestehen Unstimmigkeiten darüber, wie die Informationen zu ihren Configuration Items (CIs) und das Configuration Management System (CMS) strukturiert und gepflegt werden sollen. Nach Meinung der Technical Manager sollte das CMS Informationen zu Hardwarekomponenten erfassen sowie alle 50 Attribute, die sie derzeit in einer Tabellenkalkulation pflegen. Nach Ansicht der Application Manager sollte das CMS sehr detaillierte Informationen zu Anwendungen umfassen. Sie wünschen ein eigenes CMS, um den Zugriff einschränken zu können. Der Service Desk möchte CI-Informationen sehen, die sich auf Incidents und Probleme beziehen, aber nicht alle technischen Details. Er benötigt CIs, die mit Services verknüpft sind, um effektiv Prioritäten festzulegen. Das Change Management möchte die CI-Beziehungen sehen, um Auswirkungsanalysen durchzuführen. Der Change Manager ist der Meinung, dass eine einzelne Configuration Management Database (CMDB) Informationen zu Services, Systemen und Komponenten enthalten sollte. Sie sind Berater für das Change Management und das SACM-Team und wurden um eine Empfehlung gebeten, wie ein realistischer anfänglicher Umfang für das SACM am besten zu bestimmen ist und wie die Anforderungen wichtiger Stakeholder erfüllt werden können. Seite 7 von 9

8 Szenario sieben Die IT-Abteilung eines sehr kleinen Unternehmens hat für die gesamte IT Prozessverbesserungen implementiert. Während sich die ersten Initiativen auf das Incident Management und das Change Management konzentrierten, möchte das Unternehmen jetzt die Fähigkeiten des Service Asset and Configuration Management (SACM) weiterentwickeln. Ziel ist die Definition und Implementierung dieses Prozesses innerhalb der nächsten neun Monate. Anschließend soll mit der Arbeit am Release and Deployment Management Prozess begonnen werden. Für das Change Management sind bereits mehrere Rollen etabliert, einschließlich eines Process Owners (Prozessverantwortlichen), eines Prozess-Managers sowie einer Change Advisory Board (CAB) Struktur. Aufgrund der geringen Unternehmensgröße und niedrigen Komplexität der Systeme kann der Change Manager die gesamten Leistungs- und Risiko-Evaluierungen durchführen. Der Incident Management Prozess-Manager ist neben dem Incident Management Prozess für die Pflege der integrierten Service Management Tools für alle Prozessbereiche verantwortlich. Der Incident Management Prozess-Manager hat Bedenken wegen des Mehraufwands, der für die Pflege eines Configuration Management Systems (CMS) anfällt, und schlägt vor, für die technischen Aufgaben im Zusammenhang mit dem CMS die dedizierte Rolle eines Administrators für das Configuration Management System (CMS) und die Tools in Betracht zu ziehen. Der neu ernannte Process Owner für das SACM und die anderen Process Owner und Manager sind sich nicht einig, welche Rollen zuerst für den SACM-Prozess benötigt werden und in welcher Reihenfolge sie einzuführen sind. Seite 8 von 9

9 Szenario acht Ein Unternehmen verfügt über ausgereifte Incident, Problem und Change Management Prozesse und hat mit der ersten Erfassung der Service Asset and Configuration Management Daten in einer Tabellenkalkulation große Fortschritte gemacht. Jeder dieser Prozesse ist für sich genommen erfolgreich, was Ausführung und Ziele betrifft. Der Chief Information Officer (CIO) bemerkt allerdings einige Entwicklungen, die in IT-Organisationen mit hohem Reifegrad normalerweise nicht auftreten, wie beispielsweise: Inkonsistente Dokumentation und Ausführung von Prozessen im Incident, Problem und Change Management. Mitarbeiter beheben häufig ähnliche Schwierigkeiten bei neuen oder geänderten Services während der Release- und der frühen Betriebsphase. Unerwartete Serviceausfälle aufgrund von Changes. Nach Auffassung des CIO ist eine offizielle Implementierung der Service Transition (ST) notwendig, um die durch die Trends aufgezeigten Schwierigkeiten zu beheben. Um das dafür verfügbare Budget zu erhalten, soll der CIO darstellen, was für eine erfolgreiche ST erforderlich ist. Seite 9 von 9