ITIL® Glossar

Training » Präsenztrainings » Service Management » ITIL » Glossar

ITIL® Glossar

Training » Präsenztrainings » Service Management » ITIL » Glossar

ITIL Glossar

Service Management-Fachbegriffe verständlich erklärt!

Das Glossar definiert und erläutert alle Fachbegriffe aus dem Service Management Umfeld. Basis der Erklärungen ist das weltweit anerkannte Service Management Framework ITIL in der aktuellen Version.

Abschluss
[Closure]-(Service Operation) Ändern des Status eines Incident, Problems, Change etc. in „Geschlossen“.

Access Management
[Access Management] - (Service Operation) Der Prozess, der für die Zulassung der Nutzung von IT Services, Daten und anderen Assets durch Anwender verantwortlich ist. Das Access Management bietet Unterstützung beim Schutz der Vertraulichkeit, Integrität und Verfügbarkeit von Assets, indem sichergestellt wird, dass nur berechtigte Anwender auf die jeweiligen Assets zugreifen oder Änderungen an diesen vornehmen können. Das Access Management kann auch als Berechtigungs-Management oder Identitäts-Management (Identity Management) bezeichnet werden.

Aktivität
[Activity]- Eine Gruppe von Aktionen, anhand derer ein bestimmtes Ergebnis erzielt werden soll. Aktivitäten werden in der Regel als Teil von Prozessen oder Plänen definiert und als Verfahren dokumentiert.

Alarm
[Alert] - (Service Operation) Eine Warnung, dass ein Grenzwert erreicht oder eine Änderung vorgenommen wurde bzw. dass ein Ausfall aufgetreten ist. Ein Alarm wird häufig über System Management Tools erstellt und verwaltet; die Verwaltung erfolgt im Event Management Prozess.

Analyse der zugrunde liegenden Ursache
(Root Cause Analysis, RCA) [Root Cause Analysis (RCA)] (Service Operation) Eine Aktivität, die die zugrunde liegende Ursache eines Incident oder Problems identifiziert. Die RCA konzentriert sich in der Regel auf Ausfälle in der IT-Infrastruktur. Siehe Serviceausfallanalyse.

Anforderung
[Requirement] - (Service Design) Die formale Formulierung dessen, was benötigt wird. Zum Beispiel eine Service Level Anforderung, eine Projektanforderung oder die Anforderung der erforderlichen Lieferergebnisse für einen Prozess. Siehe Statement of Requirements.

Application Management
[Application Management] - (Service Design) (Service Operation) Die Funktion, die für die Verwaltung von Anwendungen während ihres gesamten Lebenszyklus verantwortlich ist.

Application Sizing
(Kapazitätsermittlung für neue oder geänderte Anwendungen) [Application Sizing] - (Service Design) Die Aktivität, mit der Informationen zu den Anforderungen an die Ressourcen ermittelt werden, die für die Unterstützung einer neuen Anwendung oder für die Durchführung umfassender Changes in vorhandenen Anwendungen erforderlich sind. Das Application Sizing soll dabei sicherstellen, dass der IT Service die vereinbarten Service Level Ziele für die Kapazität und die Performance erreicht.

Asset
[Asset] - (Service Strategy) Bezeichnung für jedwede Ressource oder Fähigkeit. Die Assets eines Service Providers umfassen alle Elemente, die zur Erbringung eines Service beitragen können. Assets können folgende Typen einschließen: Management, Organisation, Prozess, Wissen, Mitarbeiter, Informationen, Anwendungen, Infrastruktur und finanzielles Kapital.

Attribut
[Attribute] - (Service Transition) Ein Teil der Informationen zu einem Configuration Item. Beispiele dafür sind der Name, der Standort, die Versionsnummer und Kosten. Attribute von CIs werden in der Configuration Management Database (CMDB) erfasst.Siehe Beziehung.

Ausfallzeit
[Downtime] - (Service Design) (Service Operation) Der Zeitraum, in dem ein Configuration Item oder IT Service während der vereinbarten Servicezeit nicht verfügbar ist. Die Verfügbarkeit eines IT Service wird häufig mithilfe der vereinbarten Servicezeit und der Ausfallzeit berechnet.

Auswirkung [Impact] - (Service Operation) (Service Transition) Ein Maß für die Folgen eines Incident, Problems oder Change auf die Business-Prozesse. Die Auswirkung basiert häufig darauf, inwieweit Service Levels betroffen sind. Mithilfe der Auswirkung und der Dringlichkeit erfolgt die Zuweisung einer Priorität.

Availability Management
[Availability Management] - (Service Design) Der Prozess, der für die Definition, Analyse, Planung, Messung und Verbesserung sämtlicher Aspekte in Bezug auf die Verfügbarkeit von IT Services verantwortlich ist. Im Availability Management muss sichergestellt werden, dass die gesamte IT-Infrastruktur, sowie sämtliche Prozesse, Hilfsmittel, Rollen etc. für die vereinbarten Service Level Ziele eine entsprechende Verfügbarkeit ermöglichen.

Availability-Plan
(Verfügbarkeitsplan) [Availability Plan] - (Service Design) Ein Plan, mit dem sichergestellt wird, dass bestehende und zukünftige Verfügbarkeitsanforderungen für IT Services unter Berücksichtigung der Wirtschaftlichkeit bereitgestellt werden können.

Baseline
[Baseline] - (Continual Service Improvement) Eine Benchmark, die als Referenzpunkt verwendet wird. Beispiel:Mit einer ITSM-Baseline als Ausgangspunkt können die Folgen eines Serviceverbesserungsplans gemessen werden.Mit einer Performance Baseline können Änderungen in der Performance während der Lebensdauer eines IT Service gemessen werden.Mit einer Configuration Management Baseline kann eine bekannte Configuration einer IT-Infrastruktur wiederhergestellt werden, wenn ein Change oder ein Release fehlschlägt.

Beziehung
[Relationship] - Eine Verbindung oder die Interaktion zwischen zwei Personen oder Elementen. Beim Business Relationship Management handelt es sich dabei um die Interaktion zwischen dem IT Service Provider und dem Business. Beim Configuration Management ist eine Beziehung eine Verknüpfung zwischen zwei Configuration Items, die eine gegenseitige Abhängigkeit oder Verbindung kennzeichnet. Beispielsweise können Anwendungen mit den Servern verknüpft sein, auf denen sie ausgeführt werden. IT Services verfügen über zahlreiche Verknüpfungen zu all den CIs, die zur Bereitstellung des jeweiligen Service beitragen.

Build
[Build] - (Service Transition) Die Aktivität in Bezug auf die Gruppierung einer Reihe von Configuration Items als Teil eines IT Service. Der Begriff „Build“ bezeichnet auch ein Release, das zur Verteilung freigegeben ist. Beispiele dafür sind ein Server-Build oder ein Laptop-Build.Siehe Configuration Baseline.

Business Capacity Management (BCM)
[Business Capacity Management (BCM)] - (Service Design) Im Kontext von ITSM ist das Business Capacity Management die verantwortliche Aktivität, um die zukünftigen Business- Anforderungen für die Verwendung im Capacity-Plan nachzuvollziehen.Siehe Service Capacity Management.

Business Continuity Management (BCM)
[Business Continuity Management (BCM)] - (Service Design) Der Business-Prozess, der für den Umgang mit Risiken verantwortlich ist, die zu schwerwiegenden Auswirkungen auf das Business führen können. Das BCM sichert die Interessen der wichtigsten Stakeholder, das Ansehen, die Marke und die wertschöpfenden Aktivitäten des Business. Für den Fall einer Unterbrechung der Geschäftsabläufe werden im BCM-Prozess die Risiken auf ein akzeptables Maß reduziert und eine Planung der Wiederherstellung von Business-Prozessen vorgenommen. Das BCM legt die Ziele, den Umfang und die Anforderungen für das IT Service Continuity Management fest. 

Business Relationship Management
[Business Relationship Management] - (Service Strategy) Der Prozess oder die Funktion, der bzw. die für die Pflege von Beziehungen zum Business verantwortlich ist. Das BRM umfasst in der Regel:• die Pflege von persönlichen Beziehungen zu Business-Managern• die Bereitstellung von Input zum Service Portfolio Management• die Sicherstellung, dass der IT Service Provider den Business-Anforderungen der Kunden gerecht wirdDieser Prozess ist eng mit dem Service Level Management verknüpft.

Business Service Management (BSM)
[Business Service Management (BSM)] - (Service Strategy) (Service Design) Ein Ansatz zur Verwaltung von IT Services, bei dem die unterstützten Business- Prozesse und der Geschäftswert berücksichtigt werden. Dieser Begriff bezeichnet darüber hinaus die Verwaltung von Business-Services, die für Business-Kunden bereitgestellt werden.

Business-Auswirkungsanalyse (Business Impact Analysis, BIA)
[Business Impact Analysis (BIA)] - (Service Strategy) Die BIA ist die Aktivität im Business Continuity Management, die die Vital Business Functions und deren Abhängigkeiten identifiziert. Diese Abhängigkeiten können zwischen Suppliern, Mitarbeitern, anderen Business-Prozessen, IT Services etc. bestehen.Die BIA definiert die Wiederherstellungsanforderungen für IT Services. Zu diesen Anforderungen gehören die maximale Wiederherstellungszeit nach einem Ausfall, der tolerierte Datenverlust aufgrund von Ausfällen und die mindestens erforderlichen Service Level Ziele für die jeweiligen IT Services.

Business-Prozess
[Business Process] - Ein Prozess, für den das Business verantwortlich ist und der vom Business ausgeführt wird. Ein Business-Prozess ist an der Bereitstellung eines Produkts oder eines Service für einen Business- Kunden beteiligt. Für einen Händler kann beispielsweise ein Einkaufsprozess definiert sein, über den die Bereitstellung von Services für seine Business- Kunden unterstützt wird. Viele Business- Prozesse basieren auf IT Services.

Capability Maturity Model (CMM)
[Capability Maturity Model (CMM)] - (Continual Service Improvement) Beim Capability Maturity Model for Software (auch als CMM und SW-CMM bezeichnet) handelt es sich um ein Modell, das verwendet wird, um die Best Practices zur Unterstützung eines zu steigernden Reifegrads für Prozesse zu identifizieren. Das CMM wurde am Software Engineering Institute (SEI) der Carnegie Mellon University in den USA entwickelt. Im Jahr 2000 wurde eine Aktualisierung des SW-CMM zur CMMI® (Capability Maturity Model Integration) vorgenommen. Das SW-CMM-Modell mit den zugehörigen Bewertungsmethoden oder dem Schulungsmaterial wird heute nicht mehr vom SEI verwaltet.

Capacity Management
[Capacity Management] - (Service Design) Der Prozess, bei dem sichergestellt wird, dass die Kapazität der IT Services und die IT-Infrastruktur ausreicht, um die vereinbarten Service Level Ziele wirtschaftlich und zeitnah erreichen zu können. Beim Capacity Management werden alle Ressourcen, die für die Erbringung von IT Services erforderlich sind, sowie Pläne für kurz- mittel- und langfristige Business-Anforderungen berücksichtigt.

Capacity Management Information System (CMIS)
[Capacity Management Information System (CMIS)] - (Service Design) Ein virtueller Speicherort für sämtliche Capacity Management Daten, der in der Regel an mehreren physischen Standorten abgelegt wird. Siehe Service Knowledge Management System.

Capacity-Plan
[Capacity Plan] - (Service Design) Ein Capacity-Plan wird verwendet, um die für die Erbringung von IT Services erforderlichen Ressourcen zu verwalten. Der Plan umfasst Szenarios in Bezug auf unterschiedliche Prognosen für Business-Anforderungen sowie Optionen inklusive Kostenkalkulation, um die vereinbarten Service Level Ziele zu erreichen.

Capacity-Planung
[Capacity Planning] - Service Design) Die Aktivität innerhalb des Capacity Management, die für die Erstellung eines Capacity-Plans verantwortlich ist.

Change
[Change] - (Service Transition) Hinzufügen, Modifizieren oder Entfernen eines Elements, das Auswirkungen auf die IT Services haben könnte. Der Umfang eines Change sollte sämtliche IT Services, Configuration Items, Prozess, Dokumentationen etc. einschließen.

Change Advisory Board (CAB)
[Change Advisory Board (CAB)] - (Service Transition) Eine Gruppe von Personen, die den Change Manager bei der Bewertung, Festlegung von Prioritäten und zeitlichen Planung in Bezug auf Changes beraten. Dieses Gremium setzt sich in der Regel aus Vertretern aller Bereiche des IT Service Providers, dem Business und den Drittparteien wie z. BSuppliern zusammen.

Change Management
[Change Management] - (Service Transition) Der Prozess, der für die Steuerung des Lebenszyklus aller Changes verantwortlich ist. Wichtigstes Ziel des Change Management ist es, die Durchführung von lohnenden Changes bei einer minimalen Unterbrechung der IT Services zu ermöglichen.

Change Request (Change-Antrag)
[Change Request] - Synonym für Request for Change.

Change Schedule
[Change Schedule] - (Service Transition) Ein Dokument, das alle genehmigten Changes und deren geplanten Implementierungsdaten aufführt. Ein Change Schedule wird manchmal auch als „Forward Schedule of Change“ (Zeitplan künftiger Changes) bezeichnet, auch wenn der Informationen zu Changes enthält, die bereits implementiert wurden.

CI-Typ
[CI Type] - (Service Transition) Eine Kategorie mit der CIs klassifiziert werden. Der CI-Typ identifiziert die erforderlichen Attribute und Beziehungen für einen Configuration Record. Häufige CI-Typen sind: Hardware, Dokumente, Anwender etc.

Cold Standby
[Cold Standby] - Synonym für allmähliche Wiederherstellung.

Component Capacity Management (CCM)
[Component Capacity Management (CCM)] - (Service Design) (Continual Service Improvement) Der Prozess, der für die Aspekte der Kapazität, Auslastung und Performance von Configuration Items verantwortlich ist. Hier werden Daten für den Einsatz im Capacity-Plan gesammelt, erfasst und analysiert. Siehe Service Capacity Management.

Component Failure Impact Analysis (Analyse der Auswirkungen von Komponentenausfällen, CFIA)
[Component Failure Impact Analysis (CFIA)] - (Service Design) Eine Technik, mithilfe derer die Auswirkungen eines CI-Ausfalls auf IT Services ermittelt werden können. Es wird eine Matrix erstellt, die die IT Services den CIs gegenüberstellt. So können kritische CIs (die den Ausfall mehrerer IT Services verursachen können) und anfällige IT Services (die über mehrere Single Points of Failure verfügen) identifiziert werden.

Configuration Baseline
[Configuration Baseline] - (Service Transition) Eine Baseline für eine Configuration, die formal vereinbart und über den Change Management Prozess verwaltet wird. Eine Configuration Baseline dient als Basis für zukünftige Builds, Releases und Changes.

Configuration Item (Konfigurationselement, CI)
[Configuration Item (CI)] - (Service Transition) Alle Komponenten, die verwaltet werden müssen, um einen IT Service bereitstellen zu können. Informationen zu den einzelnen CIs werden in einem Configuration Record innerhalb des Configuration Management Systems erfasst und über den gesamten Lebenszyklus hinweg vom Configuration Management verwaltet. CIs unterstehen der Steuerung und Kontrolle des Change Management. CIs umfassen vor allem IT Services, Hardware, Software, Gebäude, Personen und formale Dokumentationen, beispielsweise zum Prozess und SLAs.

Configuration Management
[Configuration Management] - (Service Transition) Der Prozess, der für die Pflege von Informationen zu Configuration Items einschließlich der zugehörigen Beziehungen verantwortlich ist, die für die Erbringung eines IT Service erforderlich sind. Diese Informationen werden über den gesamten Lebenszyklus des CI hinweg verwaltet. Das Configuration Management ist Teil eines umfassenden Service Asset and Configuration Management Prozesses.

Configuration Management Database (CMDB)
[Configuration Management Database (CMDB)] - (Service Transition) Eine Datenbank, die verwendet wird, um Configuration Records während ihres gesamten Lebenszyklus zu speichern. Das Configuration Management System verwaltet eine oder mehrere CMDBs, und jede CMDB speichert Attribute von CIs sowie Beziehungen zu anderen CIs.

CRAMM
[CRAMM] - (Service Strategy) Ein Geschäftsbereich oder ein Projekt, dem Kosten zugewiesen werden. Eine Cost Center verrechnet keine bereitgestellten Services. Ein IT Service Provider kann als Cost Center oder als Profit Center geführt werden.

Definitive Media Library (Maßgebliche Medienbibliothek, DML)
[Definitive Media Library (DML)] - (Service Transition) Ein oder mehrere Standorte, an dem die endgültigen und genehmigten Versionen aller Software Configuration Items sicher gespeichert sind. Die DML kann darüber hinaus zugehörige CIs wie Lizenzen und Dokumentationen beinhalten. Die DML ist als einzelner logischer Speicherbereich definiert, auch wenn sie auf verschiedene Speicherorte aufgeteilt ist. Die gesamte Software in der DML untersteht der Steuerung des Change und Release Management und wird im Configuration Management System erfasst. Für ein Release ist ausschließlich der Einsatz von Software aus der DML akzeptabel.

Demand Management
[Demand Management] - Aktivitäten, die sich mit dem Bedarf des Kunden an Services befassen und auf diesen Bedarf sowie auf die Bereitstellung der Kapazität Einfluss nehmen, um diesem Bedarf gerecht zu werden. Auf strategischer Ebene kann das Demand Management die Analyse von Business-Aktivitätsmustern und Anwenderprofilen einbeziehen. Auf taktischer Ebene kann es eine differenzierte Leistungsverrechnung einsetzen, um die Nutzung von IT Services bei den Kunden zu Zeiten mit einer geringeren Auslastung zu fördern. Siehe Capacity Management.

Direkte Kosten
[Direct Cost] - (Service Strategy) Kosten für die Bereitstellung eines IT Service, die in voller Höhe einem bestimmten Kunden, einem Cost Center, einem Projekt etc. zugeordnet werden. Dazu gehören beispielsweise Kosten für die Bereitstellung von speziell für einen Zweck eingesetzten Servern oder Softwarelizenzen. Siehe Indirekte Kosten.

Dringlichkeit
[Urgency] - (Service Transition) (Service Design) Ein Wert, der wiedergibt, wie lange es dauert, bis ein Incident, Problem oder Change maßgebliche Auswirkungen auf das Business hat. Ein Incident mit erheblichen Auswirkungen kann beispielsweise von geringer Dringlichkeit sein, wenn die Auswirkungen das Business bis zum Ende des Geschäftsjahrs nicht beeinträchtigen. Auf der Grundlage der Auswirkung und Dringlichkeit werden Prioritäten zugewiesen.

Emergency Change Advisory Board (ECAB)
[Emergency Change Advisory Board (ECAB)] - (Service Transition) Eine Teilgruppe des Change Advisory Board, die Entscheidungen zu Notfall- Changes trifft, die umfassende Auswirkungen nach sich ziehen. Über die Zusammensetzung des ECAB kann bei der Einberufung eines Meetings entschieden werden, und diese richtet sich nach der Art des Notfall-Change.

Eskalation
[Escalation] - (Service Operation) Eine Aktivität, bei der zusätzliche Ressourcen eingeholt werden, wenn diese erforderlich sind, um den Service Level Zielen oder Kundenerwartungen gerecht zu werden. Eskalationen können innerhalb aller IT Service Management Prozesse erforderlich sein, werden jedoch meistens mit dem Incident Management, dem Problem Management und dem Kundenbeschwerde- Management in Verbindung gebracht. Es sind zwei Eskalationstypen definiert: funktionale Eskalation und hierarchische Eskalation.

Event
[Event] - (Service Operation) Eine Statusänderung, die für die Verwaltung eines Configuration Item oder IT Service von Bedeutung ist. Der Begriff „Event“ bezeichnet darüber hinaus einen Alarm oder eine Benachrichtigung durch einen IT Service, ein Configuration Item oder ein Monitoring Tool. Bei Events müssen in der Regel die Mitarbeiter des IT-Betriebs aktiv werden, und häufig führen Events zur Erfassung von Incidents.

Event Management
[Event Management] - (Service Operation) Der Prozess, der für die Verwaltung von Events während ihres Lebenszyklus verantwortlich ist. Das Event Management ist eine der wichtigsten Aktivitäten des ITBetriebs.

Fault Tree Analysis (Fehlerbaumanalyse, FTA)
[Fault Tree Analysis (FTA)] - (Service Design) (Continual Service Improvement) Eine Technik, die zur Ermittlung der Kette von Events eingesetzt werden kann, die zu einem Problem führt. Die Fault Tree Analysis bildet eine Kette von Events anhand einer Boole'schen Notation in einem Diagramm ab.

Financial Management
[Financial Management] - (Service Strategy) Die Funktionen und die Prozesse mit der Verantwortung für den Umgang mit den Anforderungen eines IT Service Providers an die Budgetierung, die Kostenrechnung und die Leistungsverrechnung.

Funktionale Eskalation
[Functional Escalation] - (Service Operation) Weiterleiten eines Incident, Problems oder Change an ein technisches Team mit einem erweiterten Erfahrungsschatz, das Unterstützung bei einer Eskalation bieten soll.

Hierarchische Eskalation
[Hierarchic Escalation] - (Service Operation) Informieren oder Einbeziehen höherer Management-Ebenen zur Unterstützung bei einer Eskalation.

Incident
[Incident] - (Service Operation) Eine nicht geplante Unterbrechung eines IT Service oder eine Qualitätsminderung eines IT Service. Auch ein Ausfall eines Configuration Item ohne bisherige Auswirkungen auf einen Service ist ein Incident. Beispiel: Ein Ausfall einer oder mehrerer Festplatten in einer gespiegelten Partition.

Incident Management
[Incident Management] - (Service Operation) Der Prozess, der für die Verwaltung des Lebenszyklus aller Incidents verantwortlich ist. Wichtigstes Ziel des Incident Management ist eine schnellstmögliche Wiederherstellung des IT Service für die Anwender.

Incident Record
[Incident Record] - (Service Operation) Ein Record, der die Details zu einem Incident enthält. Jeder Incident Record dokumentiert den Lebenszyklus eines einzelnen Incident.

Information Security Management (ISM)
[Information Security Management (ISM)] - (Service Design) Der Prozess, bei dem die Vertraulichkeit, Integrität und Verfügbarkeit der Assets, Informationen, Daten und IT Services einer Organisation sichergestellt werden. Das Information Security Management ist in der Regel Teil eines organisatorischen Ansatzes für das Security Management, der über den Aufgabenbereich des IT Service Providers hinausgeht, und berücksichtigt die Verwaltung papierbasierter Dokumente, Zutrittsrechte, Telefonanrufe etc. für die gesamte Organisation.

ISO/IEC 20000
[ISO/IEC 20000] - ISOSpezifikation und Code of Practice für das IT Service Management. ISO/IEC 20000 ist mit der ITIL Best Practice abgestimmt.

ISO/IEC 27001
[ISO/IEC 27001] - (Service Design) (Continual Service Improvement) ISO-Spezifikation für das Information Security Management. Der zugehörige Code of Practice lautet ISO/IEC 17799. Siehe Standard.

IT Service Continuity Management (ITSCM)
[IT Service Continuity Management (ITSCM)] - (Service Design) Der Prozess, der für die Verwaltung von Risiken verantwortlich ist, die zu schwerwiegenden Auswirkungen auf IT Services führen können. Das ITSCM stellt sicher, dass der IT Service Provider stets ein Mindestmaß an vereinbarten Service Levels bereitstellen kann, indem die Risiken auf ein akzeptables Maß reduziert werden und eine Wiederherstellungsplanung für IT Services erfolgt. Das ITSCM sollte so konzipiert sein, dass es das Business Continuity Management unterstützt.

IT Service Continuity Plan
[IT Service Continuity Plan] - (Service Design) Ein Plan, der die erforderlichen Schritte für eine Wiederherstellung eines oder mehrerer IT Services definiert. Der Plan identifiziert darüber hinaus die Bedingungen für das Auslösen des Plans, die darin zu berücksichtigenden Mitarbeiter, Kommunikationsaspekte etc. IT Service Continuity Pläne sollten Teil eines Business Continuity Plans sein.

Kategorie
[Category] - Eine benannte Gruppe von Elementen mit bestimmten Gemeinsamkeiten. Kategorien werden bei einer Gruppierung ähnlicher Elemente eingesetzt. Ähnliche Kosten werden beispielsweise in Kostenarten zusammengefasst. Ähnliche Typen von Incidents werden in Incident-Kategorien gruppiert; ähnliche Typen von Configuration Items werden als CI-Typen gruppiert.

Key Performance Indicator (KPI)
[Key Performance Indicator (KPI)] - (Continual Service Improvement) Eine Messgröße, die einen Prozess, einen IT Service oder eine Aktivität unterstützen soll. Es können Messungen anhand von zahlreichen Messgrößen erfolgen, es werden jedoch nur die wichtigsten dieser Größen als KPIs definiert und für eine aktive Verwaltung und Berichtserstellung in Bezug auf den Prozess, den IT Service oder die Aktivität eingesetzt. Bei der Auswahl der KPIs sollte die Sicherstellung von Effizienz, Effektivität und Wirtschaftlichkeit berücksichtigt werden. Siehe Kritischer Erfolgsfaktor.

Klassifizierung
[Classification] - Zuordnung einer Kategorie zu einem Element. Die Klassifizierung soll eine konsistente Verwaltung und Berichtserstellung sicherstellen. CIs, Incidents, Probleme, Changes etc. werden in der Regel klassifiziert.

Knowledge Base (Wissensdatenbank)
[Knowledge Base ] - (Service Transition) Eine logische Datenbank, die die vom Service Knowledge Management System verwendeten Daten enthält.

Knowledge Management
[Knowledge Management] (Service Transition) Der Prozess, der für die Sammlung, die Analyse, das Speichern und die gemeinsame Nutzung von Wissen und Informationen innerhalb einer Organisation verantwortlich ist. Wichtigster Zweck des Knowledge Management ist eine gesteigerte Effizienz, indem bereits vorhandenes Wissen nicht erneut entwickelt werden muss. Siehe Data-to-Information-to-Knowledge- to-Wisdom, Service Knowledge Management System.

Known Error
[Known Error] - (Service Operation) Ein Problem, für das die zugrunde liegende Ursache und ein Workaround dokumentiert wurden. Das Problem Management ist verantwortlich für die Erstellung und Verwaltung von bekannten Fehlern während ihres gesamten Lebenszyklus. Bekannte Fehler können auch von der Entwicklung oder den Suppliern identifiziert werden.

Kritischer Erfolgsfaktor (Critical Success Factor, CSF)
[Critical Success Factor (CSF)] - Ein Bestandteil, das für einen erfolgreichen Prozess, (ein erfolgreiches) Projekt, Plan oder IT Service erforderlich ist. Um das Erreichen eines CSF zu messen, werden KPIs eingesetzt. Ein CSF in Bezug auf den „Schutz von IT Services bei der Durchführung von Changes“ könnte von KPIs wie „Verringerung des Anteils nicht erfolgreicher Changes“ und „Verringerung der Changes, die Incidents verursachen, in Prozent“ etc. gemessen werden.

Management of Risk (MoR)
[Management of Risk (MoR)] - Die OGC Methodik zur Verwaltung von Risiken. Das MoR beinhaltet sämtliche Aktivitäten, die erforderlich sind, um potenzielle Risiken zu identifizieren und zu steuern, die sich auf die Erreichung der Business-Ziele einer Organisation auswirken können.

Mean Time Between Failures (Durchschnittliche Zeit zwischen zwei Ausfällen, MTBF)
[Mean Time Between Failures (MTBF)]- (Service Design) Eine Messgröße, die für die Messung und Berichte in Bezug auf die Zuverlässigkeit eingesetzt wird. Die MTBF ist die durchschnittliche Zeit, während derer ein Configuration Item oder IT Service mit der vereinbarten Funktionalität ohne Unterbrechung betrieben oder bereitgestellt werden kann. Diese wird ab dem Zeitpunkt, an dem der Betrieb des CI oder des IT Service gestartet wird, bis zu dem Zeitpunkt eines Ausfalls gemessen.

Mean Time Between Service Incidents (Durchschnittliche Zeit zwischen zwei Service-Incidents, MTBSI)
[Mean Time Between Service Incidents (MTBSI)] - (Service Design) Eine Messgröße, die für die Messung und Berichte in Bezug auf die Zuverlässigkeit eingesetzt wird. Die MTBSI ist die durchschnittliche Zeit zwischen einem Ausfall eines Systems oder IT Service bis zum nächsten Ausfall. MTBSI entspricht MTBF + MTRS.

Mean Time To Repair (Durchschnittliche Zeit bis zur Reparatur, MTTR)
[Mean Time To Repair (MTTR)] - Die durchschnittliche Zeit, die für die Reparatur eines Configuration Item oder IT Service nach einem Ausfall benötigt wird. Die MTTR wird ab dem Zeitpunkt des Ausfalls des CI oder IT Service bis zur Fertigstellung der Reparatur gemessen. Die MTTR umfasst nicht die Zeit, die zur Instandsetzung oder Wiederherstellung selbst erforderlich ist. Die MTTR wird manchmal fälschlicherweise in der Bedeutung von Mean Time to Restore Service verwendet.

Mean Time to Restore Service (Durchschnittliche Zeit bis zur Wiederherstellung des Service, MTTRS)
[Mean Time to Restore Service (MTRS)] - Die durchschnittliche Zeit, die für die Wiederherstellung eines Configuration Item oder IT Service nach einem Ausfall benötigt wird. Die MTRS wird ab dem Zeitpunkt des Ausfalls des CI oder IT Service bis zur vollständigen Wiederherstellung der normalen Funktionalität gemessen. Siehe Wartbarkeit, Mean Time to Repair.

Modelling (Modellierung)
[Modelling] - Eine Technik, die zur Prognostizierung von zukünftigem Verhalten eines Systems, Prozesses, IT Service, Configuration Item etc. verwendet wird. Das Modelling wird häufig im Financial Management, Capacity Management und Availability Management eingesetzt.

Operational Level Agreement (Vereinbarung auf Betriebsebene, OLA)
[Operational Level Agreement (OLA)] - (Service Design) (Continual Service Improvement) Eine Vereinbarung zwischen einem IT Service Provider und einem anderen Teil derselben Organisation. Ein OLA unterstützt die Bereitstellung von IT Services durch den IT Service Provider für den Kunden. Das OLA definiert die zu liefernden Waren oder Services und die Verantwortlichkeiten der beiden Parteien. Ein OLA könnte beispielsweise bestehen zwischen dem IT Service Provider und einer Einkaufsabteilung, um Hardware innerhalb vereinbarter Zeitspannen zu erhalten, dem Service Desk und einer Support-Gruppe, um eine Incident- Lösung innerhalb der vereinbarten Zeit zu erreichen.

Plan-Do-Check-Act (Planen-Durchführen- Überprüfen-Handeln)
[Plan-Do- Check-Act] - (Continual Service Improvement) Ein Zyklus in vier Phasen für das Prozessmanagement, der auf Edward Deming zurückgeführt wird. „Plan-Do-Check-Act“ wird auch als Qualitätszyklus nach Deming bezeichnet. PLAN (Planen): Design oder Überarbeitung von Prozessen, die die IT Services unterstützen DO (Durchführen): Implementierung des Plans und Verwaltung der Prozesse. CHECK (Überprüfen): Messung der Prozesse und IT Services, Vergleich mit den Zielen und Erstellung von Berichten ACT (Handeln): Planung und Implementierung von Changes, um die Prozesse zu verbessern.

Post Implementation Review PIR
[Post Implementation Review (PIR)] - Ein Review, der nach der Implementierung eines Change oder eines Projekts erfolgt. Ein PIR stellt fest, ob der Change oder das Projekt erfolgreich ist, und identifiziert Verbesserungsmöglichkeiten.

Priorität
[Priority] - (Service Transition) (Service Operation) Eine Kategorie, die verwendet wird, um die relative Wichtigkeit eines Incident, Problems oder Change zu identifizieren. Die Priorität basiert auf der Auswirkung und Dringlichkeit und wird eingesetzt, um den erforderlichen Zeitbedarf für die auszuführenden Aktionen zu ermitteln. Ein SLA kann beispielsweise angeben, dass Incidents der Priorität 2 innerhalb von 12 Stunden behoben werden müssen.

Proactive Problem Management
[Proactive Problem Management] - (Service Operation) Teil des Problem Management Prozesses. Das Ziel des proaktiven Problem Management ist die Identifizierung von Problemen, die andernfalls übersehen werden könnten. Das proaktive Problem Management analysiert Incident Records und verwendet Daten, die von anderen IT Service Management Prozessen gesammelt werden, um Trends oder maßgebliche Probleme zu identifizieren.

Problem
[Problem] - (Service Operation) Die Ursache für einen oder mehrere Incidents. Zum Zeitpunkt der Erstellung eines Problem Record ist die Ursache in der Regel unbekannt. Für die weitere Untersuchung ist der Problem Management Prozess verantwortlich.

Problem Management
[Problem Management] - (Service Operation) Der Prozess, der für die Verwaltung des Lebenszyklus aller Probleme verantwortlich ist. Wichtigstes Ziel des Problem Management ist es, Incidents zu verhindern bzw. die Auswirkungen von Incidents zu minimieren, die nicht verhindert werden können.

RACI
[RACI] - (Service Design) (Continual Service Improvement) Ein Modell, auf dessen Grundlage Rollen und Verantwortlichkeiten definiert werden. RACI steht für „Responsible“ (zuständig für die Durchführung), „Accountable“ (letztlich verantwortlich für die Aktivität), „Consulted“ (muss/soll beteiligt werden, liefert Input) und „Informed“ (muss über den Fortschritt informiert werden). Siehe Stakeholder.

Release
[Release] - (Service Transition) Eine Zusammenstellung von Hardware, Software, Dokumentation, Prozessen oder anderen Komponenten, die für die Implementierung eines oder mehrerer genehmigter Changes an IT Services erforderlich sind. Die Inhalte jedes Releases werden als eine Einheit verwaltet, getestet und implementiert.

Release and Deployment Management
[Release and Deployment Management] (Service Transition) Der Prozess, der sowohl für das Release Management als auch für das Deployment verantwortlich ist.

Release Management
[Release Management] - (Service Transition) Der Prozess, der für die Planung, den zeitlichen Ablauf und die Steuerung des Übergangs von Releases in Test- und Live-Umgebungen verantwortlich ist. Das wichtigste Ziel des Release Management ist es, sicherzustellen, dass die Integrität der Live-Umgebung aufrechterhalten wird und dass die richtigen Komponenten im Release enthalten sind. Das Release Management ist Teil des Release and Deployment Management Prozesses.

Release Unit
[Release Unit] - (Service Transition) Komponenten eines IT Service, die üblicherweise im selben Release veröffentlicht werden. Eine Release Unit umfasst in der Regel genügend Komponenten, um eine nützliche Funktion auszuführen. Eine Release Unit könnte z. B. ein Desktop-PC mit Hardware, Software, Lizenzen, Dokumentation usw. sein. Eine weitere Release Unit könnte die gesamte Anwendung für die Lohnbuchhaltung sein, einschließlich IT-Betriebsverfahren und Anwendertrainings.

Request for Change (RFC)
[Request for Change (RFC)] - (Service Transition) Der formale Antrag zur Durchführung eines Change. Ein RFC beinhaltet Details zum beantragten Change und kann auf Papier oder elektronisch erfasst werden. Der Begriff „RFC“ wird häufig fälschlicherweise für einen Change Record oder den Change selbst verwendet.

Request Fulfilment
[Request Fulfilment] (Service Operation) - Der Prozess, der für das Management des Lebenszyklus aller Service Requests verantwortlich ist.

Service Capacity Management (SCM)
[Service Capacity Management (SCM)] - (Service Design) (Continual Service Improvement) Die Aktivität, mit deren Hilfe Erkenntnisse zur Performance und Kapazität von IT Services gewonnen werden. Die Ressourcen, die von jedem IT Service verwendet werden, sowie deren Verwendungsmuster werden für die Nutzung im Capacity-Plan über einen bestimmten Zeitraum erfasst, aufgezeichnet und analysiert.Siehe Business Capacity Management, Component Capacity Management.

Service Continuity Management
[Service Continuity Management] - Synonym für IT Service Continuity Management.

Service Design Package
[Service Design Package] - (Service Design) Dokumente, in denen alle Aspekte eines IT Service einschließlich dessen Anforderungen für jede Phase des Lebenszyklus des IT Service definiert sind. Ein Service Design Package wird für neue IT Services, umfassende Changes und die Außerkraftsetzung von IT Services erstellt.

Service Desk
[Service Desk] - (Service Operation) Der Single Point of Contact für die Kommunikation zwischen Service Provider und Anwendern. Ein Service Desk bearbeitet in der Regel Incidents und Service Requests und ist für die Kommunikation mit den Anwendern zuständig.

Service Knowledge Management System (SKMS)
[Service Knowledge Management System (SKMS)] - (Service Transition) Eine Sammlung von Hilfsmitteln und Datenbanken, die zur Verwaltung von Wissen und Informationen verwendet werden. Das SKMS umfasst das Configuration Management System sowie andere Hilfsmittel und Datenbanken. Das SKMS speichert, verwaltet, aktualisiert und präsentiert alle Informationen, die ein IT Service Provider zur Verwaltung des gesamten Lebenszyklus von IT Services benötigt.

Service Level Agreement (Service Level Vereinbarung, SLA)
[Service Level Agreement (SLA)] - (Service Design) (Continual Service Improvement) Eine Vereinbarung zwischen einem IT Service Provider und einem Kunden. Das SLA beschreibt den jeweiligen IT Service, dokumentiert Service Level Ziele und legt die Verantwortlichkeiten des IT Service Providers und des Kunden fest. Ein einzelnes SLA kann mehrere IT Services oder mehrere Kunden abdecken. Siehe Operational Level Agreement.

Service Level Anforderung (Service Level Requirement, SLR)
[Service Level Requirement (SLR)] - (Service Design) (Continual Service Improvement) Eine Kundenanforderung für einen Aspekt eines IT Service. SLRs basieren auf Business-Zielen und werden zur Aushandlung vereinbarter Service Level Ziele eingesetzt.

Service Level Management (SLM)
[Service Level Management (SLM)] - (Service Design) (Continual Service Improvement) Der Prozess, der für das Verhandeln von Service Level Agreements sowie deren Einhaltung verantwortlich ist. Das SLM soll sicherstellen, dass alle IT Service Management Prozesse, Operational Level Agreements und Underpinning Contracts für die vereinbarten Service Level Ziele angemessen sind. SLM ist für das Monitoring und die Berichterstattung in Bezug auf Service Levels sowie für die regelmäßige Durchführung von Kunden- Reviews zuständig.

Service Portfolio Management (SPM)
[Service Portfolio Management (SPM) - (Service Strategy) Der Prozess, der für das Management des Serviceportfolios verantwortlich ist. Beim Service Portfolio Management steht der Wert der Services im Vordergrund, den diese für das Business darstellen.

Service Request (Serviceantrag)
[Service Request ] - (Service Operation) Eine Anfrage eines Anwenders nach Informationen, Beratung, einem Standard- Change oder nach Zugriff auf einen IT Service. Dabei könnte es sich beispielsweise um das Zurücksetzen eines Passworts oder die Bereitstellung standardmäßiger IT Services für einen neuen Anwender handeln. Service Requests werden in der Regel von einem Service Desk bearbeitet und erfordern üblicherweise nicht die Einreichung eines RFC. Siehe Request Fulfilment.

Servicefähigkeit (Serviceability)
[Serviceability] - (Service Design) (Continual Service Improvement) Die Fähigkeit eines Drittanbieters, die Bedingungen eines Vertrags einzuhalten. Dieser Vertrag umfasst den vereinbarten Umfang der Zuverlässigkeit, Wartbarkeit oder Verfügbarkeit für ein Configuration Item.

Servicekatalog
[Service Catalogue] - (Service Design) Eine Datenbank oder ein strukturiertes Dokument mit Informationen zu allen Live IT Services, einschließlich der Services, die für das Deployment verfügbar sind. Der Servicekatalog ist der einzige Bestandteil des Serviceportfolios, der an die Kunden ausgehändigt wird. Er unterstützt den Vertrieb und die Bereitstellung von IT Services. Der Servicekatalog enthält Angaben zu Lieferergebnissen, Preisen, Bestellungen und Anfragen sowie Kontaktinformationen. Siehe Vertragsportfolio.

Serviceverbesserungsplan
[Service Improvement Plan (SIP)] - (Continual Service Improvement) Ein formeller Plan zur Implementierung von Verbesserungen für einen Prozess oder IT Service.

Single Point of Contact
[Single Point of Contact] - (Service Operation) Der Single Point of Contact dient als einzige, konsistente Schnittstelle für die Kommunikation mit einer Organisation oder einem Geschäftsbereich. Der Single Point of Contact eines IT Service Providers wird in der Regel als „Service Desk“ bezeichnet.

Single Point of Failure (SPOF)
[Single Point of Failure (SPOF)] - (Service Design) Jedes Configuration Item, das durch einen Fehler einen Incident verursachen kann und für das noch keine Gegenmaßnahme implementiert wurde. Ein SPOF kann eine Person, ein Schritt in einem Prozess oder einer Aktivität oder eine Komponente der IT-Infrastruktur sein. Siehe Ausfall.

Standard-Change
[Standard Change] - (Service Transition) Ein vorab genehmigter Change, der von geringem Risiko und relativ häufig eingesetzt wird und einem bestimmten Verfahren oder einer Arbeitsanweisung folgt. Zum Beispiel die Zurücksetzung eines Passworts oder die Bereitstellung der Grundausstattung für einen neuen Mitarbeiter. Für die Implementierung von Standard-Changes sind keine RFCs erforderlich. Sie werden über andere Mechanismen erfasst und verfolgt, wie z. B. über einen Service Request. Siehe Change-Modell.

Underpinning Contract (Vertrag mit Drittparteien, UC)
[Underpinning Contract (UC)] - (Service Design) Ein Vertrag zwischen einem IT Service Provider und einer Drittpartei. Die Drittpartei stellt Waren oder Services zur Verfügung, die die Bereitstellung eines IT Service für einen Kunden unterstützen. Der Underpinning Contract definiert Ziele und Verantwortlichkeiten, um die in einem SLA vereinbarten Service Level Ziele zu erreichen.

Verfügbarkeit
[Availability] - (Service Design) Fähigkeit eines Configuration Item oder IT Service, bei Bedarf die dafür vereinbarte Funktion auszuführen. Die Verfügbarkeit wird durch Aspekte in Bezug auf Zuverlässigkeit, Wartbarkeit, Servicefähigkeit, Performance und Sicherheit bestimmt. Die Verfügbarkeit wird in der Regel als Prozentwert ausgedrückt, der häufig basierend auf der vereinbarten Servicezeit und der Ausfallzeit berechnet wird. Gemäß der Best Practice wird die Verfügbarkeit mithilfe von Messgrößen aus dem Business-Ergebnis des IT Service berechnet.

Verifizierung und Audit
[Verification and Audit] - (Service Transition) Die Aktivitäten, mit denen sichergestellt wird, dass die Informationen in der CMDB präzise sind und dass alle Configuration Items identifiziert und in der CMDB erfasst wurden. Die Verifizierung beinhaltet routinemäßige Prüfungen im Rahmen von anderen Prozessen. Zum Beispiel die Verifizierung der Seriennummer eines Desktop-PCs, wenn ein Anwender einen Incident meldet. Ein Audit ist eine periodisch durchgeführte, formale Prüfung.

Vertraulichkeit
[Confidentiality] - (Service Design) Ein Sicherheitsprinzip, das fordert, dass ausschließlich autorisierte Personen auf Daten zugreifen können.

Vital Business Function (Kritische Business- Funktion, VBF)
[Vital Business Function (VBF)] - (Service Design) Eine Funktion eines Geschäftsprozesses, die für den Erfolg des Business entscheidend ist. Vital Business Functions sind wichtige Faktoren, die beim Business Continuity Management, IT Service Continuity Management und Availability Management berücksichtigt werden müssen.

Warm Standby
[Warm Standby] - Synonym für zügige Wiederherstellung.

Wartbarkeit (Maintainability)
[Maintainability]- (Service Design) Ein Maß dafür, wie schnell und effektiv der normale Betrieb für ein Configuration Item oder einen IT Service nach einem Ausfall wiederhergestellt werden kann. DieWartbarkeit wird häufig als MTRS gemessen und berichtet. Der Begriff „Wartbarkeit“ wird auch im Zusammenhang mit der Entwicklung von Software oder IT Services verwendet, und bezeichnet dann die Fähigkeit, ob ein Change oder eine Reparatur einfach durchgeführt werden kann.

Wiederherstellen
[Restore] - (Service Operation) Die Maßnahmen, mit denen ein IT Service den Anwendern im Anschluss an Reparatur und Instandsetzung nach einem Incident wieder zur Verfügung gestellt wird. Dies ist das wichtigste Ziel des Incident Management.

Workaround (Umgehungslösung)
[Workaround] - (Service Operation) Die Reduzierung oder Beseitigung der Auswirkungen von Incidents oder Problemen, für die noch keine vollständige Lösung verfügbar sind, z. B. durch den Neustart eines ausgefallenen Configuration Item. Workarounds für Probleme werden in Known Error Records dokumentiert. Workarounds für Incidents, die nicht über zugeordnete Problem Records verfügen, werden in Incident Records dokumentiert.

Zügige Wiederherstellung
[Intermediate Recovery] - (Service Design) Eine Wiederherstellungsoption, die auch als „Warm Standby“ bezeichnet wird. Dabei erfolgt die Wiederherstellung des IT Service in einem Zeitraum zwischen 24 und 72 Stunden. Bei der zügigen Wiederherstellung werden in der Regel bewegliche oder feste Anlagen eingesetzt, die über Computersysteme und Netzwerkkomponenten verfügen. Im Rahmen des IT Service Continuity Plans müssen die Hardware und Software konfiguriert und Daten wiederhergestellt werden.

Zugrunde liegende Ursache
[Root Cause] - (Service Operation) Die grundsätzliche oder ursprüngliche Ursache für einen Incident oder ein Problem.

Zuverlässigkeit
[Reliability] - (Service Design) (Continual Service Improvement) Ein Richtwert, der wiedergibt, wie lange ein Configuration Item oder IT Service seine vereinbarte Funktion ohne Unterbrechung ausführen kann. Wird in der Regel als MTBF oder MTBSI angegeben. Der Begriff „Zuverlässigkeit“ bezeichnet auch die Wahrscheinlichkeit, dass Prozesse, Funktionen etc. den gewünschten Output erzielen. Siehe Verfügbarkeit.