| OptiOrg Roten | |||||
| Organisation & Projektleitung | |||||
| Morgenhölzlistr. 27a | |||||
| CH-8912 Obfelden | |||||
|
Switzerland |
|||||
| info@102.ch | |||||
| ITIL Glosar by Mario Roten | |||||
| A | |||||
| Anwender (user) | Die Personen, die die Leistung (IT-Service) innerhalb ihrer (täglichen) Tätigkeiten nutzen. Siehe auch: Kunde / Der Kunde als (Vertrags-)Partner (Management), der Leistungen (IT-Service) und Gegenleistungen (Bezahlung/Kostenträgerschaft) vereinbart, die Einhaltung der Leistungen überwacht und innerhalb seiner Organisation verantwortlich für die Gegenüberstellung der Leistung und des resultierenden Nutzen ist. siehe auch: Anwender |
|
|||
| Alert | Warnung, dass ein Incident aufgetreten ist (erfolgt in der überwiegenden Zahl der Fälle in automatisierter Form). | ||||
| Application System (Anwendungssystem) | Eine Kombination aus Hard- und Software, mit der definierte Geschäftsprozesse durchgeführt werden können. | ||||
| Attribute (Attribut) | Eigenschaft eines in der Configuration Management Database geführten Configuration Items. | ||||
| ARM | Application Response Measurement | ||||
| Availability (Verfügbarkeit) | Fähigkeit einer Komponente oder eines Services, die von ihr/ihm erwartete Funktion zu einem festgelegten Zeitpunkt oder über eine festgelegte Zeit-Periode hinweg zu erbringen. Üblicherweise wird die Availability in Form einer Availability Ratio ausgedrückt. | ||||
| Availability Ratio (Verfügbarkeitsrate) | Anteil der Zeit, die eine Komponente oder ein Dienst innerhalb der mit den Kunden vereinbarten Zeitperioden zur Benutzung durch den Kunden tatsächlich verfügbar ist bzw. verfügbar sein soll. | ||||
| B | |||||
| BCM | Business Continuity Management / plan | ||||
| Benutzer | siehe: Anwender | ||||
| BFK | Betriebsführungskonzept | ||||
| Build | Build ist die letzte Phase der Erstellung einer benutzbaren Configuration. Dieser Prozess beinhaltet u.a. das Ver- und Bearbeiten eines oder mehrerer Configuration Items, um daraus ein oder mehrere neue Configuration Items zu erstellen, z.B. das Kompilieren und Linken von Software. | ||||
| Business Area (Geschäftsbereich) | Business Area ist entweder ein bestimmter, feststehender Teil einer Unternehmung, der wie ein eigenständiges Unternehmen geführt wird, oder es sind mehrere, verbundene Organisationseinheiten, die einen gemeinsamen Geschäftszweck haben. | ||||
| C | |||||
| CAB | Change Advisory Board Ausschuss, der sich aus Mitarbeitern der Kunden und der IT zusammensetzt und das Change Management hinsichtlich der Ressourcen-Anforderungen und Auswirkungen von Changes berät. |
||||
| Change Advisory Board/Executive Committee | Dringlichkeitssitzung des Change Advisory Boards, bei der eine reduzierte Mitgliederzahl dringende Changes bespricht. | ||||
| CCTA Central Computers and Telecommunications Agency | Die Institution, die für die Erstellung und Pflege der ITIL zuständig ist. | ||||
| CDB | Capacity (Management) Database | ||||
| CI | Configuration Item; deutsch: Konfigurationselement | ||||
| CMDB | Configuration Management Database | ||||
| CM | Configuration Management | ||||
| customer | siehe: Kunde | ||||
| Capacity Planing (Kapazitätsplanung) | Prozess, der Pläne und Berichte liefert, mit deren Hilfe aktuelle und zukünftige Anforderungen der Kunden an die IT-Kapazitäten abgedeckt werden können. | ||||
| Capital Cost (Kapitalkosten) | Die durch feste Vermögensgegenstände (Gebäude, Hardware, Software, ...) entstehenden Kosten (z.B. Abschreibungen für Anlagen). In der Regel handelt es sich hierbei um feste Kosten (Fixkosten), die auch entstehen, wenn die entsprechenden Vermögensgegenstände nicht benutzt werden. | ||||
| Categorization (Kategorisierung) Siehe Classification. | |||||
| Category (Kategorie) | Kurzbezeichnung für die Art eines Configuration Items, Change Documents oder Problems, welches aufgrund bestimmter Kriterien vergeben wurde. Siehe auch Classification. | ||||
| Change (Änderung) | Jedes Hinzufügen, jede Modifikation und jedes Entfernen von Configuration Items und der damit in Verbindung stehenden Dokumentationen und Verfahren, unabhängig von Typ, Grösse und Komplexität der Aktion. | ||||
| Change Authority | Ausschuss oder eine einzelne Person, der oder die die Kompetenz besitzt, Changes für einzelne, eine definierte Menge oder alle Configuration Items zu genehmigen. | ||||
| Change Control | Verfahren, das sicherstellt, dass alle Changes in einer kontrollierten Art und Weise durchgeführt werden. Dies beinhaltet die Beantragung einer Änderung, die Analyse der Änderung, den Entscheid über die Durchführung der Änderung, deren Genehmigung, die Implementation der Änderung und evtl. erforderliche Nacharbeiten. Siehe auch Change Management. | ||||
| Change Document | edes/jeder mit einem Change in Zusammenhang stehendes(r) Dokument/Datensatz, insbesondere der Request for Change und der Change Record. | ||||
| Change History (Änderungshistorie) | Revisionsfähige und -sichere Aufzeichnungen über Arbeiten, die in Zusammenhang mit einem Change durchgeführt wurden. Daraus muss erkennbar sein, was getan wurde, wann es getan wurde, wer es getan hat und weshalb. | ||||
| Change Log | Eine (elektronische) Liste oder ein Logbuch, das alle Änderungsanforderungen, die im Verlauf eines Projektes [Nlientstanden sind, verzeichnet und festhält. Es dokumentiert, welche Ergebnisse die Prüfung der Anforderungen ergab, was entschieden wurde und wie der aktuelle Status der Anforderung bzw. der Änderung ist (z.B. "Angefordert", "Geprüft", "Genehmigt", "Eingesetzt" oder "Erledigt"). | ||||
| Change Management | Prozess zur Kontrolle von Changes an der Infrastruktur oder an Diensten mit dem Ziel, durch Changes nur eine minimale Unterbrechung von IT Services zu verursachen. Siehe auch Change Control. | ||||
| Change Manager | Rolle, in deren Verantwortungs- und Tätigkeitsbereich das Change Management liegt. | ||||
| Change Record | Datensatz, der Einzelheiten zu einem genehmigten Change (geplant oder implementiert) enthält. Hierzu gehören vor allem Informationen zu den betroffenen Configuration Items und die Art und Weise, in der diese CIs betroffen sind. | ||||
| Charging (Leistungsverrechnung) | Verfahren zur Ermittlung der Gebühren und deren Verrechnung gegenüber dem Kunden, der für ihn zur Verfügung gestellten IT Services, mit dem Ziel der Deckung der IT Kosten. | ||||
| Classification (Klassifizierung) | 1. Prozess der formalen
Gruppierung von Configuration Items nach ihrer Art (z.B.
"Hardware", "Software", "Dokumentation",
"Anwendung", ...). 2. Prozess der formalen Identifizierung von Changes aufgrund ihrer Art (z.B. "Infrastrukturänderung", "Projektinterne Änderung", "Testlauf", ...). 3. Prozess der formalen Identifizierung von Incidents, Problems und Known Errors aufgrund des Ursprungs, der Symptome und der Ursachen. |
||||
| Closure | Zeitpunkt, an dem ein Incident oder Problem zur Zufriedenheit des Kunden beseitigt bzw. gelöst wurde. | ||||
| Cold Start - Fixed Center | Leerer, stationärer Computerraum für den Notfall, ausgestattet mit Strom- und Telekommunikationsanschlüssen, aber ohne IT Geräte. | ||||
| Cold Start - Portable Center | Leerer, transportabler Computerraum für den Notfall, ausgestattet mit Strom- und Telekommunikationsanschlüssen, aber ohne IT Geräte. | ||||
| Configuration Baseline | Momentaufnahme eines oder mehrerer Configuration Items zu einem bestimmten Zeitpunkt, welche sowohl die Struktur als auch die Details des/der Configuration Items umfasst und so dessen/deren Wiederherstellung zu einem späteren Zeitpunkt erlaubt. Obwohl die Configuration Items im Laufe der Zeit geändert werden können, sollte ihre Configuration Baseline unverändert als Referenz und zum Vergleich mit ihrem aktuellen Zustand erhalten bleiben. | ||||
| Configuration Board | Siehe Change Authority. | ||||
| Configuration Control | Verfahren zur Kontrolle von Änderungen an Configuration Items nachdem deren Configuration Documentation offiziell verabschiedet wurde. Das Verfahren beinhaltet die Prüfung, Koordination und Zustimmung oder Ablehnung von Änderungen, die Auswirkungen auf eine dokumentierte Configuration haben. | ||||
| Configuration Documentation | Dokumente/Datensätze, welche die Betriebsvoraussetzungen, das System-Design, den Build-, Test- und Produktionsprozess für ein Configuration Item definieren/festlegen. | ||||
| Configuration Identification | Vorgang, welcher die Produktstruktur, die jeweils zugehörigen Configuration Items und deren Dokumentation der physikalischen und funktionalen Charakteristika (inkl. Schnittstellenbeschreibungen und nachträglichen Änderungen) festlegt. Hierzu gehört auch die Zuordnung von eindeutigen Identifikationsschlüsseln zu den Configuration Items und ihrer Dokumente sowie zu evtl. vorhandenen, speziellen Formularen für die Beantragung von Änderungen oder die Meldung von Problemen. | ||||
| Configuration Item | Komponente der Informations- und KommunikationsInfrastruktur einer Unternehmung - oder damit in Verbindung stehende Informationen wie z.B. ein Request for Change - welche gegenwärtig oder zukünftig unter Kontrolle/Verwaltung des Configuration Managements steht. Configuration Items können sich sehr stark in Komplexität, Grösse und Art unterscheiden: von einem kompletten System (inkl. aller zugehöriger Hardware, Software und Dokumentation) bis zu einem einzelnen Softwaremodul oder einer kleinen Hardwarekomponente. | ||||
| Configuration Management | Prozess zur Identifizierung, Definition, Erfassung und Verifizierung der Vollständigkeit und Korrektheit von Configuration Items eines Systems sowie zum Mitführen/Nachhalten derer Status und anderen mit den Configuration Items verbundenen Informationen wie z.B. ein Request for Change. | ||||
| Configuration Management Database | Datenbank, die alle relevanten Details zu den Configuration Items sowie deren Beziehungen untereinander enthält. | ||||
| Configuration Management Plan | Dokument, welches die Organisation und die Verfahren des Configuration Managements für ein spezifisches Produkt, Projekt, System, Supporteinheit oder IT Service beschreibt. Üblicherweise existiert ein Standard Configuration Management Plan, der für alle Configuration Items gültig ist, für die kein eigener Plan vorliegt. | ||||
| Configuration Management Tool | Ein Softwareprodukt, das Unterstützung für eine automatisierte Durchführung der Verfahren Change Control und Configuration Control bietet und eine Versionskontrolle der Configuration Items erlaubt. | ||||
| Configuration Repository | In einer Tivoli-Umgebung ein RIM Repository, in dem Tivoli Inventory und Tivoli Software Distribution gesammelte und/oder generierte Informationen ablegen. Im Sinne von ITIL handelt es sich hierbei um einen Bestandteil der Configuration Management Database. | ||||
| Configuration Structure | Die hierarchische Darstellung aller Configuration Items, die zusammen eine Configuration bilden. | ||||
| Continuity Plan (Notfallplan) | Dokument, welches die Organisation, Massnahmen und Verfahren für den Fall eines evtl. Notfalles vorgibt. | ||||
| Continuity Planning (Notfallplanung) | Prozess zur Entwicklung, Test und Pflege des Contingency Plan. | ||||
| Contract (Vertrag) | Rechtlich bindende Vereinbarung zwischen zwei rechtlich selbstständigen Parteien (z.B. mit externen Lieferanten). | ||||
| Cost (Kosten) | Finanzieller Aufwand (tatsächlich oder fiktiv), verursacht durch eine bestimmte Massnahme, eine organisatorische Einheit oder einem Vermögens-Gegenstand einer Unternehmung. | ||||
| Cost Center | Eine organisatorische Einheit einer Unternehmung, die ihre Kosten nicht verrechnet/nicht verrechnen muss und deshalb unter betriebswirtschaftlichen Gesichtspunkten nicht kostendeckend oder mit Gewinnerzielungsabsicht arbeitet/arbeiten muss. | ||||
| Cost Management | Prozess, in dessen Rahmen das Costing und Charging für IT Services durchgeführt wird. | ||||
| Cost Unit (Kostenträger) | Funktionale Einheit, die Kosten erzeugt. In der Regel sind das Equipment, Software, Organisationseinheiten, Gebäude. | ||||
| Costing (Kostenrechnung) | Verfahren zur Identifizierung von Kosten und deren Zuordnung zu bestimmten Geschäftsbereichen oder Aktivitäten. | ||||
| Customer (Kunde) | Abnehmer/Empfänger eines IT Services. Üblicherweise ist das Kundenmanagement der IT verantwortlich für die Kosten dieses IT Services, entweder direkt durch Charging oder indirekt in Form von nachweisbarem Geschäftsbedarf. | ||||
| Cost Management | Prozess, in dessen Rahmen das Costing und Charging für IT Services durchgeführt wird. | ||||
| Cost Unit (Kostenträger) | Funktionale Einheit, die Kosten erzeugt. In der Regel sind das Equipment, Software, Organisationseinheiten, Gebäude. | ||||
| Costing (Kostenrechnung) | Verfahren zur Identifizierung von Kosten und deren Zuordnung zu bestimmten Geschäftsbereichen oder Aktivitäten. | ||||
| Customer (Kunde) | Abnehmer/Empfänger eines IT Services. Üblicherweise ist das Kundenmanagement der IT verantwortlich für die Kosten dieses IT Services, entweder direkt durch Charging oder indirekt in Form von nachweisbarem Geschäftsbedarf | ||||
| D | |||||
| Definitive Hardware Store (DHS) | Physikalische Sammlung aller im IT-Betrieb verwendeten Hardware(-Komponenten) im Sinne eines Lagers. Der DHS ist parallel zum DSL und zur ODL zu sehen. | ||||
| Definitive Software Library (DSL) | Physikalische Sammlung aller im IT-Betrieb verwendeten Software auf nutzbaren Medien. Die DSL ist parallel zum DHS und zur ODL zu sehen. | ||||
| Definitive Software Library | Sichere Softwarebibliothek, in
denen Kopien genehmigten Versionen aller Software Configuration Items
vorgehalten und verwaltet werden. Üblicherweise handelt es sich hierbei um
einen oder mehrere, zutrittsgeschützte Räume, welche unter strikter Kontrolle
des Change Managements und des Release Managements stehen. Bestandteil der
DSL kann ein feuersicherer Safe sein, der bspw. die Originalkopien gekaufter
Software aufnimmt. Die DSL kann auch in elektronischer Form als
Dateibereiche/Verzeichnisse realisiert werden, muss dann aber strengstens von
den entsprechenden Bereichen der Entwicklungs- und Testumgebungen getrennt
sein. Zudem muss sichergestellt sein, dass die Kontrolle über diese Bereiche
weiterhin ausschliesslich beim Change Management und Release Management
liegt. Software bzw. Softwareversionen, die nicht diese Prozesse durchlaufen
haben, dürfen nicht in die DSL aufgenommen werden. Die DSL ist keine zwingende Voraussetzung für das Configuration Management. Als gemeinsame Basis für das Release Management und das Configuration Management von Software Configuration Items ist sie jedoch unbedingt notwendig. |
||||
| Delta Release | Software Release, das nur die seit dem letzten Delta oder Full Release geänderten oder hinzugekommenen Configuration Items der Release Unit umfasst. | ||||
| DHS | siehe Definitive Hardware Store | ||||
| DSL | siehe Definitive Software Library | ||||
| Direct Cost (Direkte Kosten) | Kosten, die sich unmittelbar einem Produkt, einem IT Service, einer Kostenstelle oder einer Abteilung zurechnen lassen. | ||||
| E | |||||
| EFQM | European Foundation for Quality Management | ||||
| Enablement | Der Prozess der Instrumentation von Anwendungen während deren Entwicklung. | ||||
| Enablers | Der für eine Tivoli-Umgebung definierte Satz an Software Configuration Items, welche zur Instrumentation von Anwendungen für den Tivoli Business System Manager zur Verfügung stehen. | ||||
| Endpoint | In einer Tivoli-Umgebung derjenige Client, Server oder Host, auf den sich eine Steuerungs- oder Kontrollaktion bezieht. | ||||
| End-User | (Endbenutzer) Siehe User. | ||||
| Environment (Umgebung) | Eine Ansammlung von Hardware, Software, Netzwerkverbindungen und Prozeduren, die zusammen eine spezielle Art von IT Service bereitstellen. Auf einer physikalischen Plattform können mehrere solcher Environments existieren, z.B. Entwicklung, Test und Produktion. Ein Environment hat immer spezielle Eigenschaften, die es von anderen Environments unterscheidet und die Art und Weise beeinflussen, in der es verwaltet wird. | ||||
| Error (Fehler) | Siehe Known Error. | ||||
| Error Control | Verfahren, das die Identifizierung, Klassifizierung, Dokumentation und Bearbeitung von Known Errors steuert und kontrolliert. Das Verfahren kommt erst mit dem erfolgreichen Einsatz einer endgültigen Fehlerbehebung zum Abschluss. | ||||
| Expert User | Siehe Super User. | ||||
| EUA | End User Availability | ||||
| F | |||||
| FCAPS | Acronym für die fünf Schlüsselfunktionen, sog. System Management Functional Areas (SMFA), des Management Frameworks der ISO/OSI: | ||||
| • Fault Management | |||||
| • Configuration Management | |||||
| • Accounting Management | |||||
| • Performance Management und | |||||
| • Security Management | |||||
| Facilities Management | Ist das Bereitstellen, der Betrieb und das Management der IT Infrakstruktur einer Unternehmung oder eines Teiles davon durch einen vertraglich beauftragten, externen Partner. | ||||
| Fortress Approach (Festungsansatz) | Versuch, den IT Standort so katastrophensicher wie nur irgend möglich zu machen. | ||||
| FSC | Forward Schedule of Change | ||||
| Forward Schedule of Changes | Ein Plan für einen definierten, zukünftigen Zeitraum, der grundsätzliche Informationen zu allen für den Einsatz innerhalb dieses Zeitraumes freigegebenen Changes enthält sowie deren voraussichtliche Einsatzdaten. Dieser Plan sollte zusammen mit den Kunden (Customers), dem Service Level Management und dem Service Desk abgestimmt und verabschiedet werden. Treten nach der Verabschiedung des Planes Änderungen ein, die zu zusätzlichen Verfügbarkeitseinschränkungen führen, so muss dies durch den Service Desk unmittelbar an den betroffenen Anwenderkreis kommuniziert werden. | ||||
| Full Absorption Costing (Vollkostenrechnung) | Prinzip, bei dem feste und variable Kosten Kostenträgern zugeordnet und Gemeinkosten entsprechend dem Nutzungsgrad verrechnet werden. | ||||
| Full Release | Release, das alle Configuration Items der Release Unit ersetzt, unabhängig davon, ob sie sich seit dem letzten Release geändert haben oder nicht. Siehe auch Delta Release. | ||||
| G | |||||
| GPM | Global Process Model; deutsch: Gesamt/Geschäfts-Prozess-Modell; Das Top-Level-Modell der Prozesse einer Unternehmung. | ||||
| H | |||||
| Help Desk | Der Help Desk ist heute eine Teilfunktion des Service Desk bzw. eine früher dafür gebrauchte Bezeichnung. | ||||
| Hot Start - External | Computerraum an einem separaten Standort für den Notfall. Wird von einer externen Firma mit vollständig kompatibler Hardwareausstattung vorgehalten. | ||||
| Hot Start - Internal | Computerraum für den Notfall, vorzugsweise an einem separaten Standort des Unternehmens. Ist mit vollständig kompatibler Hardwareausstattung eingerichtet. | ||||
| I | |||||
| ICT | Information Communication Technology | ||||
| ICT Infrastructure Management (ICTIM) | ICT Infrastructure Management fasst aus den 18 Managementbereichen folgend vier zusammen: | ||||
| • Design & Plan | |||||
| • Deployment | |||||
| • Operations | |||||
| • Technical Support | |||||
| ICTIM | siehe ICT Infrastructure Management | ||||
| IT | Information Technology; deutsch: Informationstechnologie | ||||
| IT Service Management | Zusammenfassung von Service Delivery und Service Support | ||||
| ITIL | IT Infrastructure Library | ||||
| ITSCM | IT Service Continuity Management | ||||
| ITSM | siehe IT Service Management | ||||
| itSMF | IT Service Management Forum | ||||
| Impact (Auswirkungen) | Messeinheit für die geschäftskritischen Auswirkungen eines Incidents. Meistens entspricht der Impact dem Umfang der Beeinflussung vereinbarter oder erwarteter Service Levels. | ||||
| Impact Code | Siehe Priority. | ||||
| Incident (Störung) | Ein Ereignis, das nicht Teil des standardmässigen Betriebes ist und eine Unterbrechung oder Einschränkung der Servicequalität oder Kundenproduktivität verursacht oder verursachen kann. | ||||
| Incident Control | Verfahren, das die Identifizierung, Klassifizierung, Dokumentation und Bearbeitung von Incidents steuert und kontrolliert. Das Verfahren kommt erst zum Abschluss, wenn der gestörte IT Service in seiner erwarteten Funktionalität wiederhergestellt ist. Bestandteil des Verfahrens ist auch die Erhebung von Daten über die Ursachen eines Incidents. | ||||
| Indirect Cost (Indirekte Kosten) | Kosten, die sich nicht unmittelbar und vollständig einem bestimmten Produkt, IT Service oder Unternehmensbereich zuordnen lassen. Sie beziehen sich auf mehrere Kostenträger oder Kostenstellen. | ||||
| Infrastructure Management | Das Management von Hardware, Software, Netzwerk und Dokumentation sowie der zugehörigen, allgemeinen Infrastruktur (z.B. Gebäude, Räume, Stromanschlüsse etc.). Das Infrastructure Management ist Bestandteil des Service Managements, da die IT Infrastruktur unbedingte Voraussetzung für die Bereitstellung von IT Services ist. | ||||
| Instrumentation | Ist aus Sicht des Tivoli Business System Managers ein Software Configuration Item, das Informationen über den aktuellen Zustand und das Verhalten eines anderen, in Produktion befindlichen Software Configuration Items zur Verfügung stellt. Aus Sicht der System/Softwareentwicklung ist es die Verwendung eines Software Configuration Items in der zu entwickelnden Anwendung, das während dem Produktivbetrieb der Anwendung dem Tivoli Business System Manager Informationen über den aktuellen Zustand und das Verhalten der Anwendung bereitstellt. | ||||
| Interface (Schnittstelle) | Physikalischer oder funktionaler Übergang zwischen Configuration Items. | ||||
| Inventory Management (Bestandsmanagement) | Teilprozess des Configuration Managements, welcher der Verwaltung und der technischen sowie finanziellen Kontrolle der Hardware Configuration Items dient. | ||||
| IS09001 | Internationale Norm für Prozesse und Verfahren in Qualitätsmanagementsystemen. | ||||
| IT Infrastructure Domain | Logische Aufteilung der IT Infrastruktur in funktional zusammengehörende Bereiche, bspw. "Server", "Netzwerk" und "Endbenutzergeräte". | ||||
| IT Service | Ein Satz zusammengehörender Funktionen oder Dienstleistungen, die von einem IT System oder der ITAbteilung bereitgestellt werden, um die Geschäftsprozesse des Unternehmens zu unterstützen. IT Services variieren in ihrer Ausprägung sehr stark und können von einem einzelnen Application System bis hin zu kompletten, heterogenen IT-Anlagen mit einer Unzahl von Anwendungen und zugehörenden Dienstleistungen gehen. | ||||
| J | |||||
| job schedule | Mit job schedule wird in der IT ein meist automatisierter Ablauf verschiedener (Batch-)Anwendungen bezeichnet. | ||||
| K | |||||
| KER | Known Error Record | ||||
| Kunde (customer) | Der Kunde als (Vertrags-)Partner (Management), der Leistungen (IT-Service) und Gegenleistungen (Bezahlung/Kostenträgerschaft) vereinbart, die Einhaltung der Leistungen überwacht und innerhalb seiner Organisation verantwortlich für die Gegenüberstellung der Leistung und des resultierenden Nutzen ist. | ||||
| siehe auch: Anwender | |||||
| Known Error | Ein Incident oder Problem, dessen Ursache (zwischenzeitlich) bekannt ist und für das ein temporärer WorkAround oder eine endgültige Lösung existiert. Auch bei Einsatz des temporären Work-Arounds bleibt ein Known Error solange als Known Error bestehen, bis die endgültige Lösung mittels eines Changes implementiert wurde. | ||||
| L | |||||
| Lebenszyklus (life cycle) | Der Begriff des Lebenszyklus (life cycle) wird in der IT auf verschiedene Objekte angewendet und beschreibt allgemein für das Objekt die bekannten Phasen plan-built-run. Ein vollständiger life cycle berücksichtigt natürlich auch das Ende, d.h. die Einstellung bzw. Beendigung des Objektes. Beispiele: | ||||
| • IT-Service life cycle | |||||
| • Application life cycle | |||||
| Life Build Environment (IntegrationstestUmgebung) | Environment, das verwendet wird, um Software Releases für den Produktivbetrieb mittels eines Build zu erstellen. | ||||
| Life Cycle | Eine Folge von Zuständen, die durch definierte Übergänge miteinander verbunden sind. Einem Life Cycle unterliegen z.B. Configuration Items, Problems und Changes. | ||||
| Life Environment (Produktionsumgebung) | Environment, das für den Produktivbetrieb der Software verwendet wird. | ||||
| M | |||||
| Managed Object | Managed Objects ist der Sammelbegriff für die Abbildung von dynamischen Configuration Items unter der Kontrolle der ICTIM Prozesse. Darstellung und Erfassung orientieren sich an den Anforderungen der entsprechenden ICTIM Aufgabenfelder und bilden einen View auf statische CIs unter Einbeziehung temporärer Aspekte. Für die Konsistenz ist eine wechselseitige Verlinkung mit den CIs in der CMDB zwingend notwendig. Dies bedeutet, dass ein CI durch zusätzliche Attribute als Managed Object in der CMDB zu kennzeichnen ist und umgekehrt Managed Objects auf autoritative CIs in der CMDB verweisen müssen. Managed Objects finden beispielsweise im Backup oder dem Monitoring Anwendung. | ||||
| Managed Node | Ist in einer Tivoli-Umgebung jedes Hardware Configuration Item, auf dem das Tivoli Management Framework installiert ist. | ||||
| Maintainability (Wartbarkeit) | Die Fähigkeit eines Configuration Items in einen Zustand zurückzukehren, in dem die gewünschte/erwartete Funktionalität wieder verfügbar ist. | ||||
| MO | siehe Managed Object | ||||
| MTBF | Mean Time Between Failures; deutsch: mittlere, durchschnittliche Zeit zwischen erwarteten Fehlern | ||||
| Meantime Between Failures | Durchschnittliche Zeit zwischen der Wiederherstellung eines IT Services nach einem Incident und dem nächsten Auftreten eines Incidents bzgl. des IT Services. | ||||
| Meantime Between System Incidents | Durchschnittliche Zeit zwischen dem Auftreten von Incidents, die einen IT Service betreffen. | ||||
| Meantime To Repair | Durchschnittliche Zeit zwischen dem Auftreten eines Incidents und der Wiederherstellung des IT Services. | ||||
| Mobile Hot Start | Mobiler Computerraum (z.B. in einem Lastwagen) mit kompletter IT Ausstattung für den Notfall; kann bei Bedarf von einer externen Firma angefordert werden. | ||||
| N | |||||
| Network Operations Center | Network Operations Center oder Network Operations Bridge bezeichnet die Verbindung zwischen dem Service Desk und ICTIM - Operations | ||||
| NOC | Network Operations Center | ||||
| O | |||||
| ODL | siehe Operational Documentation Library | ||||
| OLA | Operational Level Agreement | ||||
| Operational Documentation Library (ODL) | Zentrale, logistische Informationssammlung im Sinne einer Bücherei des IT-Betriebes. Parallel zum DHS und der DSL beinhaltet die ODL alle physikalisch existierenden Dokumentationen. Die ODL liefert die genauen Informationen zu allen Betriebsdokumenten, -prozessen und -verfahren, speziell Übergabeverfahren. Des weiteren sind hier alle technischen Dokumentationen wie Manuals, Specification Sheets, Systemkonzepte, Netz-, Raum- und Kabelpläne niedergelegt. | ||||
| Operational Level Agreement | Interne Vereinbarung über die Zulieferung von IT Services durch weitere, interne Organisationseinheiten der IT Abteilung. | ||||
| P | |||||
| PMM | Process Maturity Model | ||||
| PRINCE | Projects IN Controlled Environments | ||||
| Package Release | Ein Release von unterschiedlichen Software Configuration Items, die gemeinsame zum Einsatz gebracht werden. | ||||
| Performance Management | Prozess, der sicherstellt, dass die technischen Ressourcen der IT Infrastruktur optimal genutzt werden und damit das optimale Preis-Leistungsverhältnis bieten. | ||||
| Platform (Plattform) | IT Hardware und zu derem Betrieb benötigte Software (Betriebssystem etc.), auf der Anwendungssoftware ausgeführt wird. | ||||
| Priority (Priorität) | Ordnungszahl, die einem Incident oder Problem zugeordnet wird, um dessen Wichtigkeit und Wiederherstellungs-Zeitrahmen anzuzeigen. Die Priority ergibt sich meist aus Auswirkungen (Impact) und Dringlichkeit (Urgency) eines Incidents oder Problems. | ||||
| Problem (Problem) | Ein schwerwiegendes oder mehrere, in den Symptomen gleichartige Incidents, dessen oder deren Ursache nicht bekannt ist. | ||||
| Problem Control | Verfahren, das die Identifizierung, Klassifizierung, Dokumentation und Analyse von Problemen steuert und kontrolliert. Das Verfahren kommt zum Abschluss, wenn die Ursache des Problems gefunden wurde und damit das Problem zum Known Error wird. Das Verfahren wird für ein einzelnes Problem aber auch dann abgeschlossen, wenn die Ursache des Problems ein Verfahrens- oder Handhabungsfehler war. | ||||
| Problem Management | Prozess, der aus den kombinierten Verfahren Incident Control, Problem Control und Error Control besteht und die Aufgabe hat, die Bereitstellung stabiler, verfügbarer und korrekter IT Services sicherzustellen. | ||||
| Problem Manager | Rolle, in deren Verantwortungsbereich das Problem Management liegt. In dieser Funktion ist der Problem Manager unterstützend für den IT-Produktionsbetrieb und den Service Desk bei der Erreichung optimaler Service Levels tätig. Daneben ist die Verantwortung für das PM-Anwendungssystem Bestandteil dieser Rolle. | ||||
| Problem Record | Datensatz, in dem alle zu einem Problem oder Known Error verfügbaren Informationen gespeichert und gepflegt werden. Hierzu gehören neben der Beschreibung der Ursache und der Lösung auch die Kategorie (Category), der Impact, die Urgency und der Status der Bearbeitung. Der Problem Record ist das formale Hilfsmittel, um die Analyse, Bearbeitung und Lösung von Problems und Known Errors zu dokumentieren und nachzuhalten. | ||||
| Process (Prozess) | Eine miteinander verbundene Folge von Aktivitäten und Arbeiten mit der Absicht, einen bestimmten Zweck zu erfüllen oder ein bestimmtes Ziel zu erreichen. | ||||
| Process Control (Prozesssteuerung) | Verfahren des Planens und Steuerns von Aktivitäten und Arbeiten mit dem Ziel, einen Prozess in einer effektiven und effizienten Art und Weise durchzuführen. | ||||
| Profit Center | Eine organisatorische Einheit einer Unternehmung, die unter betriebswirtschaftlichen Gesichtspunkten wie eine Unternehmung mit eigenständigen Umsatzzielen betrieben wird. | ||||
| Q | |||||
| Quality (Qualität) | Quality wird in der ITIL als Teil des Prozesses und nicht als separate Leistung betrachtet. | ||||
| R | |||||
| RFC | Request for Comments | ||||
| RfC | Request for Change; deutsch: Änderungsanfrage | ||||
| Reciprocal Arrangement (Gegenseitige Absicherung) | Vereinbarung zweier unabhängiger Organisationen mit kompatibler IT Infrastruktur, sich im Notfall gegenseitig auszuhelfen. | ||||
| Release | Eine Ansammlung neuer und/oder geänderter, zusammenhängender Configuration Items, die getestet sind und zusammen in die Produktion übernommen werden. | ||||
| Release Management | Prozess, dessen Ergebnis der definierte Inhalt und Umfang von Releases (inkl. der Releaseart: Full Release/Delta Release) und eine Release Number (siehe Release Numbering) ist. | ||||
| Release Numbering | Vorgang, der einem Release eine eindeutige Nummer zuordnet, die Rückschlüsse auf den Entwicklungsstand der im Release enthaltenen Configuration Items erlaubt. | ||||
| Release Unit | Die Menge von Configuration Items, die bei einer bestimmten Software normalerweise zusammen freigegeben / in Produktion gebracht wird. | ||||
| Request for Change (Änderungsanforderung) | Formular oder Datensatz, in dem die Details eines angeforderten Changes festgehalten werden. | ||||
| Resilience (Strapazierfähigkeit) | Die Fähigkeit eines Configuration Items, betriebsfähig zu bleiben, wenn eines oder mehrere andere Configuration Items ausfallen. | ||||
| Resolution (Lösung) | Aktion, die fähig ist, ein Incident zu beseitigen. Dies kann ein Work-Around sein. | ||||
| Resource Management | Prozess, der sicherstellt, dass angemessene Ressourcen zum richtigen Zeitpunkt zur Verfügung stehen und betriebsbereit sind. | ||||
| Revenue Cost (Laufende Kosten) | Kosten, die bei höherer Nutzung sinken, z.B. für Papier. Hierbei handelt es sich i.d.R. um variable Kosten. | ||||
| Risk Analysis (Risikoanalyse) | Identifizierung und Bewertung der Vermögenswerte und möglicher Bedrohungen; Analyse von Schwachstellen und Risiken unter Berücksichtigung der Bedrohung für die Vermögenswerte. | ||||
| Risk Management | Prozess, der das Risiko für die Vermögenswerte verwaltet und zu minimieren versucht. | ||||
| Role (Rolle) | Ein definierter Satz von Verantwortlichkeiten, Tätigkeiten und Kompetenzen. | ||||
| S | |||||
| Service Delivery | Service Delivery fasst aus den 18 Managementbereichen folgende sechs zusammen: | ||||
| • Service Level Management | |||||
| • Financial Management | |||||
| • Capacity Management | |||||
| • Availabillity Management | |||||
| • Continuity Management | |||||
| • Security Management | |||||
| Service Support | Service Support fasst aus den 18 Managementbereichen folgende fünf zusammen: | ||||
| • Incident Management | |||||
| • Problem Management | |||||
| • Change Management | |||||
| • Release Management | |||||
| • Configuration Management | |||||
| Zudem wird die Funktion Service Desk beschrieben | |||||
| Security (Sicherheit) | Vertraulichkeit, Integrität und Verfügbarkeit von Configuration Items. | ||||
| Service Achievement | Die tatsächlichen Service Levels der in einem definierten Zeitraum an einen Kunden gelieferten IT Services. | ||||
| Service Catalogue (Servicekatalog) | Dokument, das eine vollständige Zusammenstellung und Beschreibung aller angebotenen IT Services enthält. | ||||
| Service Center | Eine organisatorische Einheit einer Unternehmung, die versucht, unter betriebswirtschaftlichen Gesichtspunkten kostendeckend zu arbeiten und deshalb die Selbstkosten den internen Kunden voll in Rechnung stellt. | ||||
| Service Control Team | Eine Gruppe von Mitarbeitern des Kunden mit ausreichender Kenntnis des Geschäfts des Kunden, welche für den Kunden, als dessen Vertreter, das Management der eingekauften IT Services durchführt. | ||||
| Service Desk (Benutzerservice) | Dedizierte Anlaufstelle für Kunden bei Problemen und Fragen, die mit der IT und den bereitgestellten IT Services zusammenhängen. Schnittstelle zwischen den Kundenabteilungen und der IT Abteilung. | ||||
| Service Hours (Servicezeiten) | Zeiten, in denen ein IT Service verfügbar ist. Siehe auch Availability und Availability Ratio. | ||||
| Service Level | Qualitätscharakteristikum eines bereitgestellten IT Services wie z.B. Servicezeiten (Service Hours), Availability Ratio, Antwortzeiten. | ||||
| Service Level Agreement | Schriftliche Vereinbarung zwischen einem Service Lieferanten und einem Kunden, welche die für den IT Service vereinbarten Service Levels dokumentiert. | ||||
| Service Level Management | Prozess zur Definition, Vereinbarung, Dokumentation und Pflege der Service Levels, die für die Kundenservices erforderlich und kostenmässig vertretbar sind. | ||||
| Service Level Requirement | Vom Kunden formulierte Anforderungen an Service Levels, die meist Ausgangspunkt für Verhandlungen zum Abschluss eines Service Level Agreements sind. | ||||
| Service Management | Prozess zur Definition, Vereinbarung, Dokumentation und Pflege der IT Services, die benötigt werden, um Kundenanforderungen erfüllen zu können. | ||||
| Service Quality Plan | Dokument, das diejenigen internen Ziele und Methoden der IT Abteilung beschreibt, die sicherstellen sollen, dass die mit den Kunden vereinbarten Service Levels eingehalten werden. | ||||
| Service Request | Jedes Incident, das keinen Ausfall der IT Infrakstruktur und keine Serviceeinschränkung repräsentiert. | ||||
| Severity | Siehe Urgency. | ||||
| SIP | Service Improvement Program | ||||
| SLA | Service Level Agreement | ||||
| SLC | Service Level Commitment | ||||
| SLR | Service Level Requirements | ||||
| Software Configuration Item | Software und ihre Bestandteile. Siehe auch Configuration Item. | ||||
| Software Environment (Softwareumgebung) | Software, die benötigt wird, um einen IT Service anbieten zu können. Hierzu zählen Betriebssysteme, Datenbank-Managementsysteme, Entwicklungswerkzeuge und die entsprechende Anwendungssoftware. | ||||
| Software Li bra ry | Zeiten, in denen eine Unterstützung der User durch eine darauf spezialisierte Organisationseinheit verfügbar ist (z.B. Ansprechzeiten des Service Desks). | ||||
| SPOC | Single Point of Contact | ||||
| SPOF | Single Point of Failure | ||||
| Status Accounting (Statusnachweis) | Prozess zur Erfassung von Zustand und Status von Configuration Items zu einem definierten Zeitpunkt. | ||||
| Support Center | Beschönigender Begriff für Cost Center | ||||
| Support Hours (Supportzeiten) | Zeiten, in denen eine Unterstützung der User durch eine darauf spezialisierte Organisationseinheit verfügbar ist (z.B. Ansprechzeiten des Service Desks). | ||||
| Super User | In manchen IT Abteilungen ist es üblich, die Erst- und Vor-Ort-Unterstützung der Anwender bei Problemen und Fragen durch sog. Experten oder Super User durchführen zu lassen. Typisch ist diese Art des Supports in speziellen Anwendungsbereichen oder geografischen Lokationen, in denen es nicht die Notwendigkeit für eine Vollzeitunterstützung durch eine Supporteinheit gibt. | ||||
| System (System) | Ein integriertes Konglomerat von Prozessen, Hardware, Software, sonstigen Betriebsmitteln und Personen, das einen definierten Bedarf erfüllt oder einer festgelegten Zielerreichung dient. | ||||
| Syllabus | Abstract oder Auszug zu einem Themengebiet | ||||
| T | |||||
| TCO | Total Cost of Ownership | ||||
| Test Environment | Environment, das für die Funktions- / Abnahmetests der Software verwendet wird. | ||||
| Test Build Environment | Environment, das verwendet wird, um Software Releases für die Funktions-/Abnahmetests mittels eines Build zu erstellen. | ||||
| Threshold (Schwellwert) | Festgelegter Wert, dessen Über- oder Unterschreiten eine (automatische) Aktion (z.B. Eskalation) auslöst. In der IT gibt es unterschiedlichste Schwellwerte, sowohl in technischer als auch organisatorischer Hinsicht. Im Rahmen des Problem Managements sind Schwellwerte z.B. vorgegebene Lösungszeiten für Incidents, Problems und Known Errors. | ||||
| Trouble Ticket | Datensatz, in dem alle zu einem Incident verfügbaren Informationen gespeichert und gepflegt werden. Hierzu gehört auch der Status der Bearbeitung. Das Trouble Ticket ist das formale Hilfsmittel, um das Auftreten und die Bearbeitung von Incidents zu dokumentieren und nachzuhalten. | ||||
| U | |||||
| UC | Underpinning Contract | ||||
| user | siehe: Anwender | ||||
| Urgency (Dringlichkeit) | Messeinheit der Kritikalität eines Incidents oder Problems für das Unternehmen. Basiert auf dem Impact und dem unternehmenskritischen Bedarf des Kunden. | ||||
| User (Anwender) | Die Person, die einen bereitgestellten IT Service (regelmässig) benutzt. | ||||
| V | Variant (Variante) | Configuration Items mit identischer Basisfunktionalität bei geringfügigen Unterschieden. | |||
| Verification (Verifizierung) | Prozess, der einen Abgleich zwischen der Configuration Management Database und den physikalischen Configuration Items durchführt. | ||||
| Version | Eine definierte Instanz eines Configuration Items innerhalb eines Produktes oder einer Konfiguration mit dem Ziel, Änderungsvorgänge nachzuhalten und überprüfbar zu machen. Im Zusammenhang mit Software Configuration Items wird die Version auch benutzt, um einen spezifischen, funktionalen Entwicklungsstand der Software im Rahmen der Entwicklungs-, Test- und Produktionsprozesse zu identifizieren. | ||||
| Version Identifier | Üblicherweise eine Ordnungszahl, ein Datum oder ein Datum mit Zeitstempel. | ||||
| W | |||||
| Waterline | Der geringste Detaillierungsgrad, der aus Sicht des Kunden noch akzeptabel ist. | ||||
| Work-Around | Methode, den erneuten Auftritt eines Incidents oder Problems zu vermeiden, ohne die Ursache endgültig zu beseitigen. Der Work-Around kann eine temporäre Korrektur sein oder in der Stilllegung einer gewissen, als defekt erkannten Funktionalität eines IT Services bestehen, insoweit die Kunden nicht dringend auf diese Funktionalität angewiesen sind. | ||||
| Workload Management | Prozess zur Ermittlung der Ressourcenprofile, die für die Bewältigung der aktuellen und zukünftigen, geschäftlichen Arbeitslasten benötigt werden. | ||||