click below
click below
Normal Size Small Size show me how
Service Operation
03-WIF4_IT-Management - V3 - Service Operation.pdf
Question | Answer |
---|---|
Nennen Sie die Prozesse innerhalb der Service Operation? | Event Management, Incident Management, Reuquest Fulfillment, Problem Management, Access Management |
Welche Funtktionen existieren innerhalb der Service Operation? | Service Desk, Technical Management, IT Operations Management, Application Management |
Zielsetzung von Servie Operation? | Realisierung des Kundennutzens durch Betrieb und Support der Services und Servicekomponenten(Infrastruktur, Applikationen, etc.) |
Was versteht man unter der externen Sicht im Zusammenhang mit Service Operation? | Wahrnehmung der IT-Services durch die Kunden und Anwender |
Was versteht man unter der internen Sicht im Zusammenhang mit Service Operation? | Art und Weise wie Systeme/Services betrieben werden, insb. technische Sicht |
Stabilitaet und Reaktionsfaehigkeit innerhalb der Service Operation? | Gleichbleibende Verfuegbarkeit der Services zur vereinbarten Qualitaet; Anpassen an die Veraenderungen, die das Geschaeft erfordert |
Servicqualitaet und Kosten innerhalb der Service Operation? | Erbringung der Services mit vereinbarter hoher Qualitaet und kontinuierlicher Verbesserung; Qualitaetsanstieg fuehrt oft zur ueberproportionalen Steigerung der Kosten |
Reaktiv und Proaktiv innerhalb der Service Operation? | Eine reaktive IT-Servie-Organisation reagiert erst, wenn es einen externen Ausloer gibt wie z.B. veraenderte Geschaeftsanforderungen, Stoerungen, etc. ; Eine proaktive IT-Service-Organisation ist immer auf der Suche nach Verbesserungsmoeglichkeiten |
Nennen Sie zentrale Begriffe der Service Operation in richtiger Prozessabfolge. | Event, Alarm, Incident,(vorbeugende Massnahme, die RfC, Event oder Problem aufruft), Workaround, Problem, Known Error, Request for Change. |
Definiton of Event? | Jede aufspuerbare oder erkennbare Geschehen, das Bedeutung fuer das Management der IT-Infrastruktur oder der Lieferung des IT-Service hat. Es bewertet die Auswirkung, die eine Serviceunterbrechung haben koennte. |
Ziele von Event-Management? | Voraussetzungen fuer den normalen Betrieb schaffen Ungewoehnliche Zustaende aufspueren und ggf. eskalieren Proaktive Identifikation von Stoerungsursachen Steuerung von Eventsueber ihren ganzen Lifecycle hinweg |
Methoden des Event-Managements? | Passiv: Laufende Abfrage von passiven Systemen (Polling) Aktiv: Automatische Meldung durch aktive Systeme |
Klassifikation von Events? | 1. Events, die eine normale Funktionsweise anzeigen, z.B. Benutzer loggt sich ein 2. Events, die eine abnormale Funtkionsweise anzeigen, z.B. falsches Passwort 3. Events, die eine ungebraeuchliche aber nicht ungewoehnliche Funtkionsweise anzeigen |
Event-Management Aktivitaeten? | 1. Event findet statt 2. Event-Benachrichtigung 3. Event-Entdeckung 4. Event-Filteru.ng 5. Event-Klassifikation(Signifcance) 6. Event-Korrelation 7. Ausloeser bzw Trigger 8. Antwortoptionen 9. Aktionsbewertung und Event schliessen |
Steckbrief des Eventmanagements nach Boettcher, Stichwort Zweck? | Systemgestuetztes Monitoring bestimmter Komponenten der IT-Infrastruktur (Cis) und Identifikation von Abnormalitaeten |
Steckbrief des Eventmanagements nach Boettcher, Stichwort wichtige Aktivitaeten? | Feststellen und Beurteilen von Systemmeldungen, Ereignissen und Warnsignales Einleiten von Massnahmen zur Beseitigung der Ursache Stoerungstickets, Problemtickets, RfC Analysieren der Ursache |
Steckbrief des Eventmanagements nach Boettcher, Stichwort Methoden und Tools? | ereignisgesteuerte System Management Systeme |
Steckbrief des Eventmanagements nach Boettcher, Stichwort Output? | Verzeichnis aller Systemmeldungen(Event-Log) Incident Rec. Problem Rec. RfC Event Rec. |
Steckbrief des Eventmanagements nach Boettcher, Stichwort Bewertung? | Neuer Prozess, der aus dem Incident Management herausgeloest wurde. Positive Differenzierung, da automatisch generierte Systemmeldungen in der Vergangenheit das Incidentvolumen aufblaehten. |
Definition of Incident | An unplanned interruption to an IT service or reduction in the quality of an IT service. Failure of a configuration item that has not yet impacted service is also an incident, for example failure of one disk from a mirror set. |
Definition of Incident-Management | Incident Management is the process for dealing wit hall incidents; this can include failures, questions or queries reported by theusers, by technical staff, or automatically detected and reported by event monitoring tools |
Ziel von Incident-Management | Die Services fuer den Anwender o. Kunden so schnell wie moeglich wieder herstellen |
Definition of Incident | An unplanned interruption to an IT service or reduction in the quality of an IT service. Failure of a configuration item that has not yet impacted service is also an incident, for example failure of one disk from a mirror set. |
Definition of Incident-Management | Incident Management is the process for dealing wit hall incidents; this can include failures, questions or queries reported by theusers, by technical staff, or automatically detected and reported by event monitoring tools |
Ziel von Incident-Management | Die Services fuer den Anwender o. Kunden so schnell wie moeglich wieder herstellen |
Weitere Zielsetzungen von Incident-Management im Interesse der Kunden | Zufriedenheit der Anwender dann Minimierung der Auswirkungen von Stoerungen auf Geschaeftsprozesse Erhoehung der Produktivitaet der Anwender Verbesserung der Verfuegbarkeit der Services |
Weitere Zielsetzungen von Incident-Management im Interesse der IT-Organisation | Verbesserte Ueberwachung der Einhaltung der SLAs Umfassendes Berichtswesen an IT-Management und andere ITIL-Prozesse Effizientere Einsatz der Mitarbeiter Kontrollierte Berabeitung von Incidents und Servcie Reqeuests etc. |
Risiken bei Verzicht auf Incindent Management? Teil1 | Mangelnde Zustaendigkeit bei Stoerungen Kostenexplosion mangels Kostenkontrolle und ineffektiver Ressourcennutzung Kostensteigerungen, da teuere Spezialisten mit einfachem Support belastet werden |
Risiken bei Verzicht auf Incindent Management? Teil2 | Wichtige Aufgaben in der Entwicklung und Architekturplanung werden vernachlaessigt Mangelnde Effiziens der Fehlerbehbung, da keine strukturierte und getrennte Stoerungsbehandlung und Problembehandlung Mangelnde Informationsbasis fuer das IT-Management |
Grundbegriffe des Incident-Managements: Zeitskalen? | Fuer alle Phasen werden Zeitlimits vereinbart SLAs Diese Zeitlimits werden als Ziele in den Underpinning Contracts UCs und Operational Level Agreements OLAs verankert |
Grundbegriffe des Incident-Managements: Incident Modelle? | Standardisierte Behandlung von wiederkehrenden Incident Typen(Major, Security, Capacity) Definieren Stufen um die Abwicklung der Incident Typen zu realisieren Helfen den Zeitplan einzuhalten Definieren Verantwortlichkeiten und Eskalationswege |
Grundbegriffe des Incident-Managements: Major Incidents? | Incident mit erwarter extremer Auswirkung Erfordern seperate Bearbeitung Kuerzerer Zeitrahmen und hoehere Prioritaet Genaue Definition notwendig Major Incidents sind keine Proleme |
Wie erfolgt die Steuerung von Stoerungsarbeiten und was ist das Ziel? | Steuerung ueber Prioritaeten mit Einhaltung von SLAs |
Die Einflussfaktoren von Prioriaeten? | Prioritaet gleich Auswirkung plus Dringlichkeit Auswirkung: Wie gravierend sind die Folgen der Stoerung fuer Anwender Dringlichkeit: Maximal vertrebare Ausfallzeit aus Sicht des Anwenders Auswirkungen und Dringlichkeit muessen oft geschaetzt werden |
Was muss bei Auswirkungen und Dringlichkeit beruecksichtigt werden? | Mensch, Zeit und Anlagen |
Was versteht man unter Eskalation? | Notwendig, wenn Stoerungen in definierter Zeit von der ersten Instanz nicht behoben werden kann |
Eskalationsarten? | Funktionale(horizontal): Incidents werden zur Loesung an Spezialisten weitergeleitet, 2nd und 3rd Level Support, mehr KnowHow, erweiterte Zugangsrechte Hierarchische (vertikal): Notwendig, wenn die funktionale Eskalation nicht zum Erfolg fuehrt |
Support-Hierarchie? | Gruppieren der Mitarbeiter in Teams nach Kriterien: Kenntnisse und Faehigkeiten, Aufgaben bei funktionaler Eskalation werden die Mitarbeiter der hoeheren Level herangezogen |
Typische Support Ebenen? | First, Secon und Third Level First: Service Desk Second: Administration, Netzwerk Mg, Third: Entwicklung und IT-Architektur n: externe Dienstleister |
Was ist ein Problem? | Ursache fuer einen oder mehrere Incidents Ergeben sich aus der Analyse von Incidents, reaktiv oder der Beruteilung von Trends, proaktiv. Sind Probleme behoben resultieren weniger Stoerungen |
Known Error? | Bezeichnung falls Ursache fuer ein Problem bekannt ist Change i.d.R notwendig um das Problem zu beheben |
Workaround? | Uebergangsloesung, falls Problem nicht sofort zu loesen ACHTUNG in ITIL V3 Incident Mg nicht mehr Anlaufpuntk fuer Service-Req sondern jetzt im Request Fulfillment |
Quellen fuer Incidents? | Event-Management Anwender(Telefon, Intranet, EMail) Nachricht von IT-Mitarbeitern |
Erlaeutern Sie den Incident Prozess! | Identifikation-Erfassung-Kategorisieren und Klassifzieren-Priorisierung-Diagnose-Eskalation-Untersuchung und Diagnose -Loesung und Wiederherstellung- Abschluss des Incidents |
Incident-Manager? | Verantwortet gesamtes Berichtswesen Erstellt Verteilerlisten und Berichtskalender Informationsbedarf |
IT-Berichsmanagement | Verantwortlich fuer die einzelnen Support Teams Kontrolle des Supportprozesses Informationsbedarf |
Service Level Management? | Informationen des Kunden ueber die Einhaltung der SLAs Alle Informationen, die fuer die Berichte an den Kunden notwendig sind |
Prozessmanagement und andere Service Prozesse? | Enge Verzahnung des Incident Mgm. erfordert andere ITIL Disziplinen |
Kritische Erfolgsfaktoren? | Singe Point of Contact Schnellstmoegliche Wiederherstellung des Service Trouble Ticket Owner im Service Desk Kontinuierliche Information des IT-Anwenders Qualitaetskontrolle Reporting |
Single Point of Contact? | Zentrale Anlaufstelle fuer die Anwender Zentrale Informationsquelle fuer die Anwender Zentrale Erfassungsstelle fuer alle Stoerungen |
Schnellstmoegliche Wiederherstellung des Service? | Arbeitsfaehigkeit der Anwender, nicht definitive Beseitigung der Fehelerursache |
Trouble Ticket Owner im Service Desk? | Wirkungsvolles Eskalationskonzept Unterstuetzt SPoC |
Kontinuierliche Information des IT-Anwenders? | Status Stoerungsarbeiten Alle relevanten Informationen bezueglich IT |
Qualitaetskontrolle? | Definition der kritischen Erfolgsfaktoren Festlegen der Key Performance-Indikatoren Messen der Key-Performance-Indikatoren |
Reporting? | Regelmaessige Berichte zur Ueberwachung der Prozessqualitaet |
Weitere kritische Erfolgsfaktoren? | Aktuelle und gepflegte CMDB Zugriff auf eine Fehler und Problemdatenbank Weitgehend automatisiertes System zur Stoerungsueberwachung Enge Kooperation mit SLA Mgm |
Leistungsindikatoren des Incident Mgm.? | Klar definierte Parameter und messbare Ziele werden regelmaessig bestimmt Bsp. Gesamtanzahl der Stoerungen avg. Loesungszeit avg. costs for support |
Rollen des Incident Mgm.? | Anwender, first second third and 4th level support |
Moegliche Hindernisse des Incident Mgm.? | Anwender und IT-Mitarbeiter umgehen Ablaeufe Ueberlastung des Service Teams Zu viele Eskalationen Keine bzw. mangelhafte SLAs Fehlendes Commitment |
Steckbrief des Incident Mgm. nach Boettcher: Zweck? | Gewaehrleistung eines moeglichst stoerungsarmen IT-Betriebs |
Steckbrief des Incident Mgm. nach Boettcher: wichtige Aktivitaeten? | Annehmen und Dokumentieren von Stoerungen Kategorisieren und Priorisieren von Stoerungen Beseitigen von Stoerungen Eskalieren an nachgelagerte Stufen Monitoring der Stoerungsmeldungen Kommunizieren mit dem Nutzer |
Steckbrief des Incident Mgm. nach Boettcher: Methoden Tools? | Service Desk Ticketsystem mit Workflow Funktionalitaet |
Steckbrief des Incident Mgm. nach Boettcher: Output? | Wiederherstellung |
Steckbrief des Incident Mgm. nach Boettcher: Bewertung? | Etablierte Kernprozesse des ITIL Framework. Typischerweis der erste ITIL Prozess, mit dem kleine IT Organisationen die Impelmentierung von ITIL beginnen |
Request Fulfillment Definition? | Ein Service-Request ist die Anfrage eines Anwender bezueglich Unterstuetzung, Service Erweiterung, Lieferung, Informationen, Ratschlaegen und Dokumentationen |
Beispiele fuer Service Requests? | Eine Frage zur Handhabung oder Qualtaet Eine Statusabfrage Ein Passwort Reset Die Aktivierung von Batch Jobs Installation eines PCs Die Anforderung einer Datenwiederherstellung |
Ziele des Request Fulfillments? | Provide a channel for users to request and receive standard services Assist with general information, complaints or comments Provide information to users and customers about the availability of services and how to obtain them |
Request Fulfillment nach Boettcher? | Einheitlicher Kanal fuer Serviceabrufe Beschraenkung auf standardisierte IT-Leistung Minimierung des Klaerungsbedarfs im Bestellprozess Abwicklung ueber Portal |
Problem Management Ziele? | Vermeidung von Problemen und resultierenden Incidents Minimierung von wiederkehrenden Incidents Minimierung der Auswirkungen von unvermeidbaren Inicdents |
Problem Mgm. Umfang? | Verantwortlich für die Kontrolle des Lebenszykulus aller Probleme, Alle Aktivitäten um die Ursache von Incidents zu finden, RfCs um Probleme zu loesen, Entwicklung von Workarounds für das Incident Mgm |
Problem Mgm. Beabsichtigter Effekt? | Verfuegbarkeit und Qualitaet der Dienste gemaess Geschaeftsanforderungen sicherstellen, Einsparungen aufgrund weniger Incidents ermoeglichen, Weniger Ausfälle für das Geschäft erreichen |
Problem Defintion? | unbekannte, potentielle Ursache eines oder mehrer Inicidents, normalerweise ist die Ursache unbekannt wenn der Problem Record erstellt wird |
Workaround Defintion? | ein Weg die Auswirkung eines Incidents oder Problems zu reduzieren oder zu eliminieren, für den eine umfassende Loesung noch nicht verfuegbar ist, Workarounds werden in den Incident Records oder den Known Error Records definiert |
Known Error? | Ein Problem, das eine dokumentierte Ursache une eine Umgehungsloesung hat Das PM ist für den Lebenszyklus verwantwortlich Koennen auch von Entwicklern oder Zulieferen identifiziert werden |
KEDB? | Known Error Database: Datenbank mit allen Known Error Records, Genutzt vom IM und PM Teil des Service Knowledge Mgm System |
Problem Model? | Vordefiniertes Verfahren für die Behandlung bestimmter Problemarten, Analog Incident Model |
Problem Mgm im Kontext? | Incident - Problem - Known Error - Reuqest for Change |
Problem Mgm. Prozess? | 1. Problem erkennen 2. Problem erfassen 3. Problem kategorisieren 4. Problem priorisieren 5. Untersuchung Diagnose 6. Workaround 7. Known Error Record anlegen 8. Loesung / Change 9. Problem abschliessen 10.Major Problem Review |
Problem Mgm. Herausforderungen? | Verknuepfung von Incident und PM Werkzeugen Verknuepfung von Incident und Problem Records Arbeitsteilung zwischen First, Second und Third Level Support Verstehen, welche Bedeutung PM für den Betrieb hat |
Kritsche Erfolgsfaktoren? | Umsetzung des PM Prozesses Sinnvoller Einsatz der Werkzeuge Wissensmanagement und Konfigurationsmanagement Datenbanken effektiv einsetzen Kontinuierliches Training der Mitarbeiter |
KPIs im PM? | Anzahl und Anteil der innerhalb der vom SLA festgelegten Zeitraeume geloesten Probleme Laenge der List der abzuarbeitenden Probleme avg cost fuer die Problembehandlung Anzahl der zur KEDB hinzugefuegten Known Errors |
Problem Manager? | Prozessverantwortlicher Processowner & KEDB Owner Koordiniert sich mit allen an der Loesung beteiligten Gruppen, z.B. Problem-SolvingGroups Zulieferer Externe Mitarbeiter |
Access Management Ziele? | provides the right for users to be able to use services Bewilligt autorisieren und verweigert unautorisierten Benutzern den Zugriff |
Access Management Scope? | Vertaulichkeit Datenintegritaet Datenverfuegbarkeit Geistiges Eigentum fuehrt die vom Security Mgm. definierten Aktivitaeten aus |
Access Management Bedeutung? | Benutzer erhalten Rechte die sie zur Arbeit brauchen, erlaubt Verwaltung von Rechten Auditierung und Nachverfolgung von Zugriffen auf Ressourcen - Compliance |
Access Mgm. Synonyme? | Rights Mgm. Identity Mgm. |
Access Mgm Grundbegriffe? Zugang | Level oder Umfang der Dienste oder Daten auf die ein Benutzer zugreifen kann |
Access Mgm Grundbegriffe? Identitaet | Eindeutige Identifikation und Beschreibung eines Benutzers |
Access Mgm Grundbegriffe? Rechte | Rechte einer Identitaet oder ueber eine Gruppe erhaltene Rechte oder Privilegien |
Access Mgm Grundbegriffe? Service oder Service Gruppen | Benutzer haben immer Zugriff auf Services, meist wird der Zugriff fuer eine Gruppe aehnlicher Services gewaehrt |
Access Mgm Grundbegriffe? Directory Service | Werkzeug mit dem Benutzer, Gruppen und Rechte zentral zu verwalten |
Access Mgm Prozess? | 1. Zugriffsanfrage 2. Verifikation 3. Rechte gewaehren 4. Ueberwachung des Identitaetsstatus 5. Registrierung und Zugangsueberwachung 6. Protokollierung und Verfolgung d. Z. 7. Entziehen oder Beschneiden d. Z. |
Access Mgm Herausforderungen? | Faehigkeit die Idenitaet von Anwendern korrekt zu ueberpruefen Faehigkeit zu Pruefen, ob dem Anwender die Rechte wirklich zu stehen Faehigkeit Aenderungen an den Zugriffsrechten durchzusetzen Existenz einer Datenbank mit allen Anwendern und Rechten |
Access Mgm KPIs? | Anzahl der Zugriffsanfragen Anzahl der Anfragen zur Zuruecksetzung von Zugriffsrechten Anzahl der Incidents die durch falsche Rechte verursacht wurden |
Access Mgm Rollen? | Normalerweise kein Access Manager Prozessverantwortung hat meist Information Security Manager Weitere involvierte Funktionen Service Desk Technical and Application Mgm. IT Operations Mgm. |
Service Desk Ziele? | Single Point of Contac (SPoC) fuer alle Anwender der IT Nimmt auf und verwaltet: Incidents, Service Request und Access Requests Oberste Prioriaet: Normaler Service - SLA so schnell wie moeglich wiederherstellen |
Service Desk Scope? | Jegliche Art von Interaktion mit Anwender der IT |
Service Desk Bedeutung? | Sehr wichtiger Teil der IT-Abteilung Stellt IT nach außen dar |
Zentrales Service Desk | Es gibt ein einziges Service Desk, welches für alle Organisationseinheiten, Niederlassungen und dezentralen Mitarbeiter zustaendig ist. Der Vorteil liegt hier in der einfachen Handhabung und der Vereinheitlichung der Prozesse. |
Lokales Service Desk | Jeder Standort oder jedes Departement in einem Unternehmen hat sein eigenes lokales Service Desk,d.h. beim jeweiligen Anwender vor Ort.Nachteilig ist die Redundanz, die z.T. vorliegt,Schwierigkeiten bei Standardisierung, Eskalation oder Know-how-Austausch |
Virtuelles Service Desk | Die Service Deskssind auf unterschiedliche Orte verteilt, aber über eine Nummer durch den Einsatz von Kommunikationstechnik zentral für den Anwender erreichbar, der auch nicht weiß, wo sein Ansprechpartner am anderen Ende der Leitung sitzt |
Follow theSun-Service Desk | „Dies ist eine spezielle Art des virtuellen Service Desks, das abhängig von der Tageszeit sequenziell durch die Telefontechnik angewählt wird (Erreichbarkeit: 7x24 Stunden). Die Übergabe zwischen den Schichten muss geregelt werden |
Serice Desk Personalausstattung? | Erwartung und Anzahl der Kunden,Sprachen der Anwender Komplexität der IT-Infrastruktur und des Service-Katalogs Anzahl und Art der Incidents und Service-Requests,sowie die erwarteten Antworten Ausgereiftheit der (Geschäfts-und Support-)Prozesse |
Personalqualifikation, Call Center? | Lediglich Erfassung und Weiterleitung der Anfragen an Experten Teilweise ist diese Funktionalität durch Voice Response Units (Sprachcomputer) automatisierbar |
Personalqualifikation, Unskilled oder erfassender Service-Desk? | Dokumentation und Klassifikation der Anfragen Zumeist Weiterleitung an Experten, nur bei bekannten Fehlern werden Lösungen angeboten Vorteil: Einheitliche Dokumentation und Überwachung der Anfragen Nachteil: Längere Reaktionszeit, geringe Erstlösungsqu |
Personalqualifikation, Skilled oder lösender Service-Desk | Hohe Sachkenntnis und Kompetenz der Mitarbeiter notwendig Zahlreiche Störungen werden selbst behoben, weniger an Experten weitergeleitet Deutlich höhere Lösungsrate bei Erstkontakt |
Personalqualifikation, Expert Service-Desk | Umfassende und detaillierte Sachkenntnis der Mitarbeiter notwendig Großteil der Störungen wird selbst behoben Risiko: Erreichbarkeit des Service-Desk muss gewährleistet bleiben |
Service Desk Rollen? | Service Desk Manager Service Desk-Supervisor Service Desk-Analyst Super User |
Service Desk KPIs? | Prozentsatz der vom SD gelösten Anfragen die nicht eskaliert werden mussten avg Incident-Lösungszeit avg Zeit bis zur Eskalation avg Kosten für die Incident-Behandlung avg Zeit um einen gelösten Incident oder Service Requestz u prüfen und schließen |