ITIL Intermediate Lifecycle Stream:

Transkript

1 ITIL Intermediate Lifecycle Stream: ZERTIFIKAT SERVICE OPERATION 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 Ein großes Finanzinstitut setzt eine Reihe von IT Services zur Unterstützung seiner Geschäftsfunktionen ein. Viele von diesen sind als kritisch einzustufen. Allgemein bestehen gute Beziehungen zwischen der IT und dem Business, so dass eine Reihe zuverlässiger IT Services eingesetzt wird, die auf die Geschäftsbedürfnisse ausgerichtet ist. Die IT-Abteilung hat ITIL eingeführt und gilt als Beispiel für Best Practices. Die Einführung von ITIL hat die IT-Mitarbeiter motiviert, und sie verfolgen das Ziel, nützliche Änderungen auf Arbeitspraktiken anzuwenden. Die IT-Abteilung hat hervorragende Aktivitäten und Prozesse für Service Strategy und Service Design implementiert. Mit einem professionellen Management des Serviceportfolios wird sichergestellt, dass fundierte Business Cases für neue und geänderte Services erstellt werden. Demzufolge sind die Finanzierung und andere Ressourcen auf Business- und IT-Anforderungen abgestimmt. Für alle Services wurden Service Level Agreements (SLAs) vereinbart. Das Service Desk Management ist professionell und setzt bewährte Incident Management und Problem Management Prozesse ein, die durch ein ausgereiftes Configuration Management System (CMS) unterstützt werden, das auch eine Known Error Datenbank (KEDB) umfasst. Diese Prozesse stellen sicher, dass Incidents und Probleme an die richtigen Teams eskaliert werden. Das ist besonders wichtig, da sich viele Services auf Technologien stützen, bei denen auftretende Schwierigkeiten nur von Mitarbeitern mit den erforderlichen Fähigkeiten behoben werden können. Der Service Desk wird im Allgemeinen gut angenommen, es gibt jedoch einige Anwender, die die Service Desk Verfahren nicht einhalten und versuchen, sich direkt mit den Support-Mitarbeitern in Verbindung zu setzen oder aufkommende Schwierigkeiten selbst zu beheben, ohne mit der IT Kontakt aufzunehmen. IT Operations Manager forderten die Business-Manager auf, von den Anwendern die Einhaltung der Service Desk Verfahren zu verlangen, was die Situation jedoch nicht veränderte. Die Technical Management Funktion ist in eine Reihe von Technologieteams unterteilt. Das Management für die einzelnen Teams ist gut, die Auslastung der Service Operation insgesamt ist jedoch hoch. Kriterien für die Einstellung der Mitarbeiter sind deren Fertigkeiten als Experten. Aufgrund der hohen Auslastung ist jedoch kaum Zeit für Schulungen in anderen Bereichen oder für Wissensaustausch. Die Technical Management Teams setzen bewährte Monitoring- und Event Management Verfahren ein, die durch entsprechende Tools unterstützt werden. Damit wird der Zugriff auf einen Großteil der Informationen ermöglicht, die von anderen Service Management Prozessen eingesetzt werden, um Berichte zu unterschiedlichen Service Levels zu erstellen. Die Service Levels werden größtenteils eingehalten, und es kommt nur zu wenigen Major Incidents oder Ausfällen. Sämtliche Verfügbarkeitsziele für Services werden durchgehend erreicht. Seite 2 von 9

3 Szenario zwei Ein interner IT Provider entwickelt seit einigen Jahren seine eigenen Anwendungen, wofür ein kleines Entwicklerteam zuständig ist. Im Allgemeinen sind die Anwendungen nach Auffassung des Business erfolgreich. Die Anwendungen werden von den Anwendern angenommen. Ihrer Meinung nach sind sie leicht zu bedienen. Um den Bedarf des Business zu erfüllen, wurden im vergangenen Jahr mehr Anwendungen von Suppliern bezogen. Vor sechs Monaten wurde im Rahmen eines Service Management Verbesserungsprojekts ein neues Application Management Team gebildet. Im Allgemeinen arbeiten die beiden Funktionen gut zusammen, und die Kombination von Anwendungsentwicklung und Application Management hat zu Verbesserungen in zahlreichen Bereichen geführt. Anwenderakzeptanztests wurden verbessert, was dazu geführt hat, dass allgemeine Schwierigkeiten und Fehler der Anwendungen zu einem früheren Zeitpunkt identifiziert und als Known Errors dokumentiert werden. Deployment-Aktivitäten wurden verbessert, da Application Management, Anwendungsentwicklungs- und IT Operations Management Funktionen in Release and Deployment Aufgaben einbezogen werden. Außerdem hat Application Management eine Richtlinie implementiert, die vorsieht, dass bei Supplier-Anwendungen der entsprechende Support in den Vertrag aufgenommen wird. Ungelöst ist jedoch noch der laufende Support für die Anwendungen. Die IT Operations Management Teams stellen fest, dass sie sich nicht mit allen aufkommenden Schwierigkeiten befassen können. Das führt unter anderem dazu, dass Service Level Ziele für die Wiederherstellung von Services nicht immer erreicht werden. Wenn Incidents auftreten, kann das IT Operations Management sich mit den allgemeinen Fehlern befassen, ist aber nicht in der Lage, weitergehenden fachlichen Support zu leisten. Hinzu kommen Inkonsistenzen bei den Anwendungsarchitekturen, Plattformen und Entwicklungsmethoden. Das bedeutet, dass sich alle Anwendungen voneinander unterscheiden, was die Diagnose von Incidents und Problemen erschwert und zeitaufwendiger macht. Und wenn Anwendungen mithilfe neuer Technologie implementiert werden, erhalten die IT Operations Management Teams nicht die notwendigen Schulungen. Eine zusätzliche Schwierigkeit besteht darin, dass die Anzahl der Incidents, die Kapazität und Performance betreffen, zunimmt. Seite 3 von 9

4 Szenario drei Ein Unternehmen hat kürzlich ein neues Support-Tool für das Event Management erworben, und das Service Operation Team befasst sich gerade mit der Installation und Konfiguration des neuen Tools. Dabei stellte sich die Frage nach der Aufbewahrung von Daten zu Events. Alle beteiligten Mitarbeiter waren sich einig, dass als Warnungen oder Ausnahmen klassifizierte Events auch dann noch für einen längeren Zeitraum aufbewahrt werden müssen, nachdem das Event behandelt wurde. Es gibt Bedenken in Bezug auf den verwendeten Speicherplatz und das zu speichernde Datenvolumen, auf das ein Zugriff möglich sein muss. Einige erfahrene technische Mitarbeiter schlugen daraufhin vor, als informativ kategorisierte Events nur für kurze Zeit aufzubewahren. Vorgeschlagen wurde ein Zeitraum von einer Woche: Wenn keine Folge-Events innerhalb dieses Zeitraums auftreten, sei deren Auftreten nach diesem Zeitraum äußerst unwahrscheinlich. Andere Teammitglieder hielten dies für unzureichend. Die Daten würden eventuell über diesen Zeitraum hinaus benötigt und sollten daher unbegrenzt aufbewahrt werden. Es ergab sich eine Reihe weiterer Anforderungen, einschließlich folgender Punkte: Die Rechtsabteilung des Unternehmens gab an, dass aufgrund von rechtlichen Vorgaben und Compliance-Aspekten einige Daten bis zu sechs Jahre aufbewahrt werden müssten. Das IT-Sicherheitsteam gab an, dass einige ernsthafte IT-Sicherheitsverletzungen hätten vermieden werden können, wenn das Team Zugriff auf eine Historie von Event-Daten aller Kategorien gehabt hätte. Das Security Management Team verlangt, relevante Daten mindestens ein Jahr aufzubewahren. Problem Management, Capacity Management und Availability Management haben Zugriff auf alle Event-Daten angefordert, um ihre Trendanalysen zu verbessern. Sie einigten sich auf eine Aufbewahrungsfrist von sechs Monaten. Seite 4 von 9

5 Szenario vier Ein Touristikunternehmen mit weltweiten Niederlassungen verfügt über einige wenige, auf verschiedene Standorte verteilte Service Desks, die als Anlaufstelle für einen einheitlichen Incident Management Prozess dienen. Die Service Desks werden gut angenommen, sind jedoch nur während der Standard-Geschäftszeiten geöffnet (in der Regel von 08:00 bis 18:00 Uhr mit einigen regionalen Abweichungen). Das Business hat Support-Leistungen mit einer Verfügbarkeit rund um die Uhr angefragt, dies ist allerdings aufgrund von Kosteneinschränkungen derzeit nicht möglich. In den letzten Jahren wurde eine Reihe von Trends identifiziert: Es wurde ein allmählicher Anstieg der Gesamtzahl der behandelten Incidents verzeichnet. Ein wachsender Prozentsatz an behandelten Incidents bezieht sich nicht auf eigentliche Fehler, sondern ist eher als eine Art von Service Requests der Anwender einzustufen. Mehr als 60 % aller derzeitigen Incidents sind eine Art von Service Requests. Einzelfälle haben gezeigt, dass in Zeiten hoher Auslastung Fehler mit höherer Priorität aufgrund der hohen Anzahl von Incidents und Requests manchmal verzögert bearbeitet oder übersehen werden. Eine High-Level-Analyse der in den letzten sechs Monaten behandelten Service Requests ergab folgende Aufschlüsselung: Request-Typ Kennwortänderung 35 % Zuweisung von zusätzlichem Mailbox-Speicherplatz 11 % Zugriff auf eine vorhandene Anwendung 9 % Neue Desktop-Anwendung 7 % Einrichtung neuer Anwender 6 % Zugriff für befristet beschäftigte/freie Mitarbeiter 3 % Umzug von Workstations 3 % Sonstiges (Verschiedenes) 26 % Prozentsatz Seite 5 von 9

6 Szenario fünf In einer inländischen Reiseagentur wurden Sie kürzlich zum Service Desk Manager ernannt. Das Unternehmen hat auch einen Problem Manager eingesetzt. Beide Positionen wurden geschaffen, nachdem ein Review der IT-Abteilung ergeben hatte, dass mit den Antwortzeiten für Incidents die vereinbarten Ziele nicht eingehalten wurden. Der Grund dafür ist, dass die IT-Teams nicht zwischen Incidents und Problemen unterscheiden und das Management dafür nicht getrennt voneinander erfolgt. In einigen Fällen führte das dazu, dass ein Service erst dann wiederhergestellt wurde, nachdem die IT dafür eine vollständige Lösung identifiziert und implementiert hatte. Darüber hinaus wurden folgende Punkte im Review identifiziert: 25 % der Incidents beziehen sich auf den Urlaubsbuchungsservice zur Hauptsaison. Dieser Service ist geschäftskritisch. 10 % der Incidents beziehen sich auf den Finanzmanagement-Service. 40 % der Incidents beziehen sich auf andere Services und allgemeine Desktop-Aspekte. 25 % der Incidents werden als Service Requests kategorisiert. Die Desktop-Incidents sind besonders problematisch, da viele anscheinend als wiederkehrende Incidents auftreten und zu Anfahrtskosten von Suppliern führen. Zusammen mit dem Problem Manager entwickeln Sie auf Basis der ITIL Leitlinien Prozesse für das Incident und Problem Management, um diese Schwierigkeiten zu beheben. Derzeit arbeiten Sie an einem Schulungs- und Awareness-Programm für Service Desk Mitarbeiter und Mitarbeiter des technischen Supports. Bisher haben Sie Folgendes vereinbart: Der Service Desk erfasst den Anruf und sucht, sofern verfügbar, nach einer Lösung. Nach Wiederherstellung des Service nimmt der Service Desk mit dem Anwender Kontakt auf und schließt den Vorgang, wenn der Anwender zufriedengestellt ist. Seite 6 von 9

7 Szenario sechs Ein regionales Energieversorgungsunternehmen verfolgt eine fünfjährige Strategie, um Geschäftswachstum und besseren Kundenservice zu erreichen. Zur Unterstützung dieser Strategie wurden zwei lokale Unternehmen übernommen: ein Gasanbieter und ein Stromanbieter. Ein Teil der Strategie besteht darin, kurzfristig eine Bewertung der Technical Management Funktion beider Unternehmen durchzuführen und festzulegen, wie die beiden Unternehmen am besten integriert werden können. Sie sind Berater und wurden gebeten, einen Plan zu entwickeln, mit dem die jeweilige Technical Management Funktion der übernommenen Unternehmen evaluiert wird und deren Möglichkeiten bewertet werden können. Sie planen, für jede Funktion ein Benchmarking anhand von ITIL Best Practices durchzuführen, um die derzeitigen Fähigkeiten und den aktuellen Reifegrad zu ermitteln. Ihre Ziele: Sicherstellen, dass die Funktion für das Unternehmen das technische Wissen bzw. die Erfahrungen bereitstellt, die für das Management der IT-Infrastruktur benötigt werden Feststellen, ob die Funktion den Servicelebenszyklus unterstützt Im ersten Schritt erfassen und überprüfen Sie die erstellte Dokumentation, um zu ermitteln, wie effektiv das Technical Management seine Rolle ausführt. Seite 7 von 9

8 Szenario sieben Ein großes Versicherungsunternehmen hat kürzlich festgestellt, dass seine IT Service Management (ITSM) Technologie, die zur Unterstützung der Funktionen und Prozesse innerhalb der Service Operation eingesetzt wird, erneuert werden muss. Von den Organisationseinheiten wurden bereits verschiedene eigene Tools erworben oder entwickelt, um bestimmte Anforderungen in ihren Bereichen zu erfüllen. Ein Großteil davon ist zur Unterstützung von IT Services unabdingbar. Die unterschiedlichen Tools haben zu inkonsistenten Daten geführt. Außerdem sind nun identische Funktionalitäten im gesamten Unternehmen mehrfach vorhanden. Untersuchungen haben ein Defizit an Wissen und Verständnis zu den im gesamten Unternehmen vorhandenen Hardware- und Software-Assets ergeben, darüber hinaus wurde eine spezielle Schwachstelle in Bezug auf die Compliance bei Softwarelizenzen ermittelt. Das Unternehmen sucht nach einem Toolset zur Behebung dieses speziellen Problems, ohne gleich ein vollständiges Vor-Ort- Audit seiner weitverteilten Infrastruktur durchführen zu müssen. Der Betrieb erfolgt von unterschiedlichen geografischen Standorten aus, die alle über ein zuverlässiges Netzwerk miteinander verbunden sind. Das Unternehmen setzt zwar bereits bewährte Prozesse ein, möchte jedoch wissen, ob es von der Einführung eines ITSM-Lebenszyklusansatzes profitieren kann, wie er von den ITIL Leitlinien empfohlen wird. Jedes neue Toolset muss die vorhandenen Service Management Prozesse unterstützen und die Kommunikation innerhalb der IT-Funktionen verbessern. Seite 8 von 9

9 Szenario acht Die IT-Abteilung eines Unternehmens hat in den vergangenen zwei Jahren mehrere ITIL Prozesse implementiert. Bisher wurde mit dem ITSM-Programm Folgendes erreicht: Verbesserungen bei Lösungsquoten für Incidents und Probleme Weniger fehlgeschlagene Changes aufgrund von effektiver Change-Planung und effektivem Deployment Höhere Kundenzufriedenheit aufgrund vereinbarter Service Level Agreements (SLAs) in mehr als zwei Dritteln der Geschäftsbereiche Der IT-Bereich ist in folgende Abteilungen aufgeteilt: Architektur und Planung (A&P) Management wichtiger Programme und Festlegung von Standards für Technologie und Prozesse IT-Steuerung Verantwortlich für Audits und Compliance in Bezug auf festgelegte Standards und Richtlinien: o Service Level Management o Change Management Rechenzentrum Operative Funktionen, die folgende Abteilungen umfassen: o Operations Bridge o Service Desk o Mainframe Management o Server Management o WLAN/LAN-Management o Anwendungs-Support-Gruppen Die Rechenzentrumsabteilungen konzentrieren sich auf das Management ihrer eigenen Technologie und geben in der Regel dann die erforderlichen Informationen weiter, wenn ein Incident, Problem oder Change initiiert wird. Jede Abteilung ist für das Monitoring und die Steuerung ihrer eigenen Technologie verantwortlich. Monitoring-Berichte werden in der Regel an alle Systemadministratoren weitergegeben, und einmal pro Monat wird eine Zusammenfassung zu Performance und Ausnahmen an die Abteilungsleiter übermittelt. Für die IT-Steuerung wird von jeder Abteilung ein Monatsbericht zur Performance der wichtigsten Systeme bereitgestellt, der zur Erstellung von Berichten zur SLA- Erfüllung eingesetzt wird. Das Unternehmen arbeitet gerade an der Implementierung der Capacity und Availability Management Prozesse. Das Projekt wird vom A&P-Manager geleitet. Es besteht Einvernehmen darüber, dass der aktuelle Ansatz für Monitoring und Steuerung geändert werden muss, um den Anforderungen dieser neuen Prozesse gerecht zu werden. Das Rechenzentrum sträubt sich jedoch erheblich dagegen, Zugriff auf seine Daten zuzulassen, und wehrt sich gegen jegliche Eingriffe in Bezug auf seine Monitoring-Aktivitäten oder Tools. Seite 9 von 9