1. Archiv - ITIL® Foundation: Continual Service Improvement

Musterprüfung 2 von Sascha Swidlowski

video locked

Über den Vortrag

Der Vortrag „Musterprüfung 2“ von Sascha Swidlowski ist Bestandteil des Kurses „Archiv - ITIL® Foundation: Continual Service Improvement“.

Quiz zum Vortrag

  1. Von allen anderen ITIL Prozessen
  2. Nur von Capacity Management und Availability Management
  3. Nur von Incident Management und Problem Management
  4. Nur von Change Management und Release and Deployment Management
  1. Er muss so schnell wie möglich implementiert werden.
  2. Er birgt ein geringes Risiko.
  3. Er folgt einem Verfahren oder einer Arbeitsanweisung.
  4. Er ist vorab vom Change Management genehmigt.
  1. Nur 1, 2 und 4
  2. Alle Genannten
  3. Nur 2 und 4
  4. Nur 2 und 3
  1. Nur 1, 2 und 3
  2. Nur 1, 2 und 4
  3. Alle Genannten
  4. Keine der Genannten
  1. Das Management der physischen IT-Umgebung, wie z. B. des Rechenzentrums oder von Computerräumen
  2. Das Management von IT Services, die als Betriebsmittel (Utilities) betrachtet werden, wie z. B. Drucker oder Netzwerkzugang
  3. Beratung und Anleitung für IT Operations zu Tools und Methoden für das Management von IT Services
  4. Beschaffung und Wartung von Tools, die von den IT Operations Mitarbeitern zur Instandhaltung der Infrastruktur verwendet werden
  1. Capacity Management
  2. Supplier Management
  3. Technology Management
  4. Change Management
  1. Die KEBD sollte bei der Diagnose eines Incident eingesetzt werden, um schneller zu einer Lösung zu kommen.
  2. Bei der KEBD handelt es sich um die gleiche Datenbank wie beim Service Knowledge Management System (SKMS).
  3. Doppelte Records sind in der KEBD zu vermeiden. Diese Sorgfalt kann erreicht werden, indem möglichst vielen Technikern Zugriff für die Erstellung neuer Records gewährt wird.
  4. Zugriff auf die KEBD sollte auf den Service Desk beschränkt bleiben.
  1. Alle Genannten
  2. Nur 1
  3. Nur 2 und 3
  4. Nur 1, 2 und 4
  1. Configuration Management System
  2. Capacity-Plan
  3. Definitive Media Library
  4. Service Level Agreement
  1. Nein – weil es in der Verantwortung des Service Providers liegt, eine sorgfältige Prüfung durchzuführen, bevor die Anforderung erfüllt wird
  2. Ja – wenn es ein externer Kunde ist, weil er für den Service bezahlt
  3. Nein – wenn es ein interner Kunde ist, weil er nicht immer für den Service bezahlt
  4. Ja – weil der Service Provider sicherstellen muss, dass alle Anforderungen für neue Services erfüllt werden
  1. Nur 1
  2. Nur 2
  3. Beide der Genannten
  4. Keine der Genannten
  1. Sofort, um Auswirkungen auf Anwender zu vermeiden bzw. zu begrenzen.
  2. Nur, wenn es durch den Ausfall zu einem Service Level Verstoß kommt.
  3. Ein Incident sollte nicht erfasst werden, wenn die Techniker solche Ausfälle schon kennen und über einen Workaround verfügen.
  4. Nur, wenn der Ausfall vom Anwender bemerkt wird.
  1. Alle Genannten
  2. Nur 2 und 4
  3. Nur 3 und 4
  4. Nur 1 und 2
  1. Alle Genannten
  2. Nur 1 und 2
  3. Nur 1 und 3
  4. Nur 2 und 3
  1. Alle Genannten
  2. Nur 2, 3 und 4
  3. Nur 2 und 3
  4. Nur 1 und 2
  1. Sie liefern Ergebnisse an Kunden oder Stakeholder.
  2. Sie definieren Funktionen als Teil ihres Designs.
  3. Sie werden von einem externen Service Provider ausgeführt, um einen Kunden zu unterstützen.
  4. Sie sind Organisationseinheiten, die für bestimmte Ergebnisse zuständig sind.
  1. Release and Deployment Management
  2. Transition Planning and Support
  3. Service Asset and Configuration Management
  4. Service Catalogue Management
  1. Ein Techniker installiert ein Skript zur vorübergehenden Umleitung von Druckvorgängen an einen alternativen Drucker, bis eine dauerhafte Lösung eingerichtet ist.
  2. Ein Techniker probiert mehrere Vorgehensweisen aus, um einen Incident zu lösen. Zwar funktioniert eine davon, aber er weiß nicht, welche.
  3. Nachdem der Anwender dem Service Desk den Incident gemeldet hat, arbeitet er an anderen Aufgaben, während das Problem identifiziert und gelöst wird.
  4. Ein Gerät arbeitet nur mit Unterbrechungen, erlaubt dem Anwender jedoch, seine Arbeit auf einem verminderten Leistungsniveau fortzusetzen, während der Techniker den Incident analysiert.
  1. Alle Genannten
  2. Nur 2, 3 und 4
  3. Nur 1, 3 und 4
  4. Nur 1, 2 und 3
  1. Planen, Durchführen, Überprüfen, Handeln (Plan, Do, Check, Act)
  2. Planen, Durchführen, Handeln, Prüfen (Plan, Do, Act, Audit)
  3. Planen, Überprüfen, erneutes Handeln, Implementieren (Plan, Check, Re-Act, Implement)
  4. Planen, Messen, Überwachen, Berichten (Plan, Measure, Monitor, Report)
  1. IT Service Continuity Management und Supplier Management
  2. Service Level Management und Capacity Management
  3. Supplier Management und Service Level Management
  4. IT Service Continuity Management und Service Level Management
  1. Eine Reihe vordefinierter Schritte, nach denen beim Umgang mit einem bekannten Incident-Typ vorgegangen wird
  2. Die Vorlage für das Incident-Erfassungsformular, das zur Meldung von Incidents zu verwenden ist
  3. Ein Incident-Typ, der einen Configuration Item (CI) Standardtyp (oder Modelltyp) betrifft
  4. Ein Incident, der einfach zu lösen ist
  1. Responsible, Accountable, Consulted, Informed
  2. Responsible, Achievable, Consulted, Informed
  3. Realistic, Accountable, Consulted, Informed
  4. Responsible, Accountable, Corrected, Informed
  1. Service Strategy
  2. Service Design
  3. Service Operation
  4. Continual Service Improvement
  1. Alle Genannten
  2. Nur 2 und 3
  3. Nur 1 und 3
  4. Nur 1 und 2
  1. Kundenbasiertes SLA
  2. Standortbasiertes SLA
  3. Technologiebasiertes SLA
  4. Prioritätenbasiertes SLA
  1. Eine Zustandsänderung, die wesentlich für das Management eines IT Service ist
  2. Ein Ereignis, bei dem ein Performance-Grenzwert überschritten und ein vereinbarter Service Level beeinträchtigt wurde
  3. Ein bereits bekannter Systemfehler, der zu mehreren Incident-Berichten führt
  4. Ein zwischen Kunden und IT-Mitarbeitern geplantes Treffen, bei dem ein neuer Service oder ein Verbesserungsprogramm bekannt gegeben werden soll
  1. Kunden
  2. Oberes IT-Management
  3. Financial Management for IT Services
  4. Suppliers
  1. Alle Genannten
  2. Nur 1 und 4
  3. Nur 2 und 3
  4. Keine der Genannten
  1. Ein Change-Modell legt die Schritte fest, nach denen ein bestimmter Change-Typ zu bearbeiten ist.
  2. Eskalationsverfahren sind nicht Bestandteil eines Change-Modells.
  3. Ein Change-Modell sollte erstellt werden, wenn ein signifikanter Change erforderlich ist.
  4. Ein Change-Modell sollte NICHT für Notfall-Changes verwendet werden.
  1. Durchführung einer Baseline-Bewertung
  2. Überprüfung des CSI-Registers
  3. Verständnis der Vision des Business
  4. Review der kritischen Erfolgsfaktoren
  1. Event Management und Request Fulfilment
  2. Event Management und Service Desk
  3. Facilities Management und Event Management
  4. Change Management und Service Level Management
  1. Service Transition
  2. Service Operation
  3. Continual Service Improvement
  4. Service Strategy
  1. Nur 1, 3 und 4
  2. Nur 1, 2 und 3
  3. Alle Genannten
  4. Nur 2, 3 und 4
  1. Sicherstellen, dass Business Continuity Pläne auf Geschäftsziele ausgerichtet sind
  2. Die Bewertung der Auswirkungen von Changes auf den Availability-Plan
  3. Sicherstellen, dass die Serviceverfügbarkeit die vereinbarten Bedürfnisse des Business erfüllt
  4. Das Monitoring und das Berichtswesen über die Verfügbarkeit von Komponenten
  1. Es handelt sich um vier Hauptbereiche, die beim Service Design berücksichtigt werden müssen.
  2. Es handelt sich um eine Reihe von Fragen, die bei der Überprüfung von Design-Spezifikationen gestellt werden sollten.
  3. Es handelt sich um eine Definition der Menschen und Produkte, die man für ein erfolgreiches Design benötigt.
  4. Es handelt sich um einen 4-Schritte-Prozess für das Design eines effektiven Service Management.
  1. Ein Major Problem Review wird vom Problem Manager angesetzt, damit Lehren aus dem Major Problem gezogen werden können und um Support-Mitarbeiter zu schulen und zu sensibilisieren.
  2. Ein Major Problem Review wird vom Service Desk Manager angesetzt, um für die Zukunft etwas lernen zu können, nachdem ein Major Problem gelöst wurde.
  3. Ein Major Problem Review wird vom Change Manager im Rahmen des Change Advisory Boards (CAB) durchgeführt, nachdem der entsprechende Request for Change (RFC) zur Lösung des Problems genehmigt wurde.
  4. Ein Major Problem Review wird vom Problem Manager angesetzt und befasst sich mit der Schuldfrage, nachdem eine Lösung für das Problem gefunden wurde.
  1. Das Supplier Management verhandelt Operational Level Agreements (Vereinbarungen auf Betriebsebene, OLAs).
  2. Das Supplier Management stellt sicher, dass die Supplier die Erwartungen des Business erfüllen.
  3. Das Supplier Management pflegt Informationen in einem Supplier and Contract Management Information System.
  4. Das Supplier Management verhandelt externe Vereinbarungen über die Unterstützung bei der Bereitstellung von Services.
  1. Verstehen der Kundenbedürfnisse und Sicherstellen, dass diese erfüllt werden
  2. Maximieren des Vertragswerts und der operativen Effizienz der bereitgestellten Services
  3. Sicherstellen, dass alle Ziele der Service Level Agreements eingehalten werden
  4. Durchführung operativer Aktivitäten zur Unterstützung von Services
  1. Leistung der Service Design Lebenszyklusphase überwachen und verbessern
  2. Eine konsistente und einheitliche Informationsquelle für alle operativen Services bereitstellen und pflegen
  3. Service Level definieren, dokumentieren, vereinbaren, überwachen, messen und überprüfen
  4. Sicherstellen, dass die Ziele zur Serviceverfügbarkeit eingehalten werden

Dozent des Vortrages Musterprüfung 2

Sascha Swidlowski

Sascha Swidlowski

Einer der Geschäftsführer von OpenAdvice, Sascha Swidlowski, sammelt seit 2002 umfassende Erfahrung als Berater in verschiedenen Unternehmensberatungen im Bereich IT Service Management und bringt dieses Wissen heute in der Beratung und Begleitung seiner Kunden bei  ITSM/ITIL-Projekten zielführend mit ein. Insbesondere in Reorganisationsprojekten im Service Managementumfeld sind seine Kenntnisse des Zusammenspiels zwischen Kunden und IT-Service Providern von hohem Mehrwert, wenn es um die optimale Gestaltung und Ausrichtung von IT-Organisation hin zu einem serviceorientiertem IT-Service Provider geht. Sein wichtigstes Ziel ist dabei stets, das höchste Gut einer Organisation – die Menschen – durch Begeisterung für das Thema ITSM / ITIL zu mobilisieren.

Kundenrezensionen

(1)
5,0 von 5 Sternen
5 Sterne
5
4 Sterne
0
3 Sterne
0
2 Sterne
0
1  Stern
0

© 2024 Lecturio GmbH. Alle Rechte vorbehalten.

Betreuung durch Dozenten
Auch unterwegs auf Tablet und Smartphone lernen
100% Geld-zurück-Garantie