Die Configuration Management Database (CMDB) ist die Grundlage für alle ITSM Prozesse und dient als Datenbank für CI's (sogenannte Configuration Items) eines Unternehmens. Der Configuration Management Prozess hat die Verwaltung des Lebenszyklus eines jeden CIs zum Inhalt und ist hierbei eng mit dem Change Management Prozess verknüpft über welchen Änderungen an CIs dokumentiert und bewilligt werden.

Der IT Asset Management Prozess fokussiert auf die Verwaltung des Lebenszyklus von physischen Geräten und Softwarelizenzen aus einer finanziellen und vertraglichen Sicht. Der Prozess verwaltet die Assets von der Beschaffung bis zur Entsorgung.

Configuration Management hingegen fokussiert auf die Verwaltung der Business- und IT-Services und deren physischen und logischen Infrastruktur wie zum Beispiel

• Application Services (z.B. SAP)
• IT Services (z.B. Datenbank Administration, Windows Server Engineering)
• Application Service Environments (Produktion, Test, Entwicklung)
• Middleware (z.B. Webapplikationsserver)
• Datenbanken (z.B. Oracle Datenbank)
• Server (z.B. Windows oder Unix Server)
• Netzwerk-Geräte (z.B. Router und Switches)

Durch Erstellen von Beziehungen zwischen den CIs wird ein sogenannter Service-Baum geschaffen. Dieser unterstützt die IT Organisation, die oft umfangreiche IT Service Landschaft und Infrastruktur zu verstehen, zu verwalten und zu unterstützen. Ferner ist der Service-Baum bei der Analyse von Abhängigkeiten und Ausfällen hilfreich. 

Change Management plant und setzt Änderungen (Changes) an IT Services unter kontrollierten Bedingungen um und vermeidet negative Auswirkungen auf das Geschäft und die Benutzer. Der Change Management Prozess soll sicherstellen, dass jeder Change angemessen

- dokumentiert und bewertet

- genehmigt

- getestet

- geplant

- durchgeführt

wird.

Es wird unterschieden zwischen

• Standard Changes

Ein Standard Change wird bei gut dokumentierten sich wiederholenden Aktivitäten eingesetzt. Ein Standard Change ist meist standardmässig genehmigt und dient neben der Durchführung an sich vornehmlich der Dokumentation der Aktivitäten an IT Services oder CIs der Infrastruktur wie zum Beispiel Daten-Import, Datenbank-Wiederherstellung usw.

• Normal Changes

Ein Normal Change wird für nicht-standardmässige Changes eingesetzt und folgt den definierten Phasen des Normal Changes wie Logging & Assessment, Approval, Build & Test, Deploy, Post Implementation Review.

• Emergency Changes

Ein Emergency Change wird normalerweise aufgrund einer Störung (Incident) mit höchster Priorität eröffnet. Die zu behebende Störung muss grosse negative Auswirkungen und eine grosse Dringlichkeit für die Benutzer und das Geschäft haben. In den meisten IT Organisationen wird ein Emergency Change in etwa in folgenden Phasen abgearbeitet

- Beschreibung und Analyse der Auswirkungen bzw. Abhängigkeiten

- Genehmigung durch das Change Advisory Board

- Durchführung

- Dokumentierung und formales Testen 

Knowledge Management hat die Erstellung, Verwaltung und Bereitstellung von Wissen und Informationen zum Inhalt. Das Ziel ist, das Wissen der IT Organisation zu dokumentieren, auf eine effiziente Weise zu teilen und das Risiko zu minimieren, dieses Wissen, z.B. durch Ausscheiden von Mitarbeitern, zu verlieren.

Die Wissensbasis (Knowledge Base) kann mithilfe verschiedener Strategien gepflegt werden. Die Knowledge Base wird nur dann aktiv genutzt, wenn der Inhalt nützlich sowie korrekt ist und der Aufwand für die Anwender, Wissen zu dokumentieren, klein gehalten wird.

Daher ist es entscheidend, dass die Organisation einen einfachen Knowledge Management Prozess einsetzt.

Subject Matter Experts (SMEs) sollten innerhlab der Organisation die Aufgabe übernehmen, neue oder überarbeitete Wissenseinträge zu prüfen, zu genehmigen und zu veröffentlichen. Knowledge Administratoren verwalten die Knowledge Base stetig hinsichtlich ihrer Qualität z.B. mithilfe von Reports wie 

• Knowledge Dokumente, die längere Zeit nicht abgerufen wurden
• Knowledge Dokumente, die schlechte Bewertungen haben
• Knowledge Dokumente, die sich auf veraltete Produkte oder Services beziehen

Ferner ist es wichtig, den Knowledge Management Prozess und die Inhalte der Knowledge Base in den Incident und Problem Management Prozess zu integrieren. Beispielsweise sollte es auf einfache Weise möglich sein, die Knowledge Base nach dem Titel oder der Beschreibung des Incidents zu durchsuchen und passende Wissenseinträge für die Lösung und die Dokumentierung des Incidents heranzuziehen. Auch sollte es möglich sein, Known Errors und Workarounds als Resultate des Problem Management Prozesses direkt und ohne grossen Aufwand in die Knowledge Base einfliessen zu lassen.

Ein Incident (Störung) ist ein allgemeiner Begriff für jedes ungeplante Ereignis, das einen IT Service stört oder in der Qualität einschränkt. Im Incident Management werden die Incidents dokumentiert, beobachtet und gemessen. Das Ziel eines registrierten Incidents ist die schnellstmögliche Wiederherstellung des IT Services in einen normalen Zustand mit möglichst geringen Auswirkungen auf das Geschäft und die Anwender. Oft wird dies durch eine provisorische Zwischenlösung (Workaround) erreicht (z.B. Neustart eines Service auf einem Server). Die eigentliche Ursache (Root Cause) eines Incidents wird im Problem Management Prozess analysiert und behoben. Die Identifikation und dauerhafte Beseitigung einer Ursache führt meistens zu grösserem Aufwand und letztlich zu einem Change (Change Management). Im Problem Management Prozess kann der Root Cause als bekannter Fehler (Known Error) zusammen mit dem Workaround dokumentiert werden, um den IT Support in die Lage zu versetzen, die oder weitere im Zusammenhang stehenden Incidents schnellstmöglich per Workaround zu lösen, solange der Root Cause nicht behoben wurde.

Service Request Management hat die Verwaltung von bestellbaren Services (Service Catalog Items) und die Erfüllung (Request Fulfillment) von Service-Anfragen bzw. -Aufträgen von Mitarbeitern (Kunden) zum Inhalt.

Im Service Catalog sind die verfügbaren Service Catalog Items strukturiert abgelegt, so dass der Kunde den Service Catalog durchsuchen und die Items leichter finden kann.

Jedes Service Catalog Item sollte Angaben enthalten wie

• eine für den Kunden verständliche Beschreibung
• Verfügbarkeit - wer darf das Item bestellen?
• Genehmigungen - wer muss den Auftrag genehmigen?
• Kosten - Verrechnung über Kostenstellen
• spezifische Eigenschaften (z.B. die Grösse eines Monitors, Grösse einer Datenbank)
• Prozess bis zur Auftragserfüllung - der durchaus dynamische Ablauf des zu erfüllenden Auftrags von Auftragseingang über Genehmigung, Benachrichtigung, Lieferung, Installation bis zur endgültigen Auslieferung des Services
• Service Level Agreement - wie lange darf der gesamte Ablauf bis zur Auslieferung dauern?

Das Employee Self Service Portal stellt einfache Funktionen für Kunden und Mitarbeiter bereit, so dass diese das Service Desk seltener in Anspruch nehmen müssen. Das Ziel ist die Entlastung des Service Desk und die Verbesserung der Service Qualität für Kunden und Mitarbeiter.

Das Employee Self Service Portal unterstützt normalerweise Funktionen wie

• Erstellen von Incidents
• Erstellen von Service Requests mithilfe des Service Request Catalogs
• Verfolgen von Incidents und Service Requests, die vom Kunden erstellt wurden oder ihn betreffen
• Genehmigen von Service Requests und Changes
• Suche in der Knowledge Base