ITSM-Prozesse & ITIL: die 6 Kernprozesse erklärt

ITSM-Prozesse entscheiden, ob dein IT-Team strukturiert arbeitet oder von einem Ausnahmefall zum nächsten hetzt. Der Begriff klingt nach Framework-Theorie, ist in der Praxis aber simpel: Es sind die wiederkehrenden Abläufe, mit denen IT-Teams Anfragen bearbeiten, Störungen beheben und Änderungen kontrolliert einspielen. Dieser Artikel zeigt die wichtigsten ITSM-Prozesse, den Unterschied zu ITIL – und eine Stelle, an der viele dieser Prozesse in der Praxis brechen, ganz unabhängig davon, wie gut sie auf dem Papier definiert sind.

Was sind ITSM-Prozesse?

ITSM-Prozesse sind die strukturierten Abläufe, mit denen IT-Teams Services planen, bereitstellen, betreiben und verbessern – von der Ticketannahme bis zur Änderung an der Infrastruktur. ITSM steht für IT Service Management: Atlassian beschreibt es als die Art und Weise, "wie IT-Teams bei der End-to-End-Bereitstellung von IT-Services für ihre Kunden vorgehen" – also die Praxis, nicht ein einzelnes Tool.

Jeder dieser Prozesse beantwortet eine andere, sehr konkrete Frage: Wer ist für eine Anfrage zuständig? Wie kommt eine Änderung sicher in Produktion? Wo steht das Notebook, das gerade offline gemeldet wurde? Genau diese Fragen bilden die Kernprozesse, die im nächsten Abschnitt zusammenkommen.

Welche ITSM-Kernprozesse gibt es?

Die sechs am häufigsten genannten ITSM-Kernprozesse sind Service Request Management, Wissensmanagement, IT-Asset-Management, Incident Management, Problem Management und Change Management. Atlassian listet genau diese sechs als zentrale Bereiche des ITSM – von der "wiederholbaren Bearbeitung von Kundendienstanfragen" bis zur Nachverfolgung, dass "materielle und immaterielle Assets von Wert korrekt verwendet werden".

Viele Anbieter zählen zusätzlich Configuration Management als eigenen, engen Partner von Asset Management dazu. Realtech AG nennt beide explizit in einem Atemzug: "ITSM-Lösungen umfassen Prozesse wie Incident, Change, Problem, Knowledge, Asset und Configuration Management." Ob man das als sechs oder sieben Kernprozesse zählt, ist am Ende Definitionssache – wichtig ist, dass Asset- und Configuration-Daten in praktisch jedem anderen Prozess auf dieser Liste als Grundlage gebraucht werden.

Was ist Change Management in ITSM-Prozessen?

Change Management ist der ITSM-Prozess, der jede geplante Änderung an der IT-Infrastruktur – vom Software-Update bis zum neuen Server – kontrolliert freigibt und dokumentiert. Atlassian beschreibt das Ziel so, dass "Standardverfahren für die effiziente und schnelle Bearbeitung aller Änderungen an der IT-Infrastruktur eingesetzt werden".

In ITIL 4 heißt der Prozess offiziell "Change Enablement" statt Change Management – eine bewusste Umbenennung. 7P Group erklärt, dass die Practice den gesamten Lebenszyklus aller Änderungen steuert, um Risiken zu minimieren. Der Namenswechsel ist mehr als Kosmetik: Change Enablement soll Änderungen ermöglichen statt sie zu blockieren – schnelle, risikoarme Änderungen sollen ohne aufwändige Freigabeschleife durchlaufen, während größere Eingriffe die volle Prüfung durchlaufen.

Was ist der Unterschied zwischen ITSM und ITIL?

ITSM ist die generelle Praxis, IT-Services für Mitarbeitende und Kund:innen bereitzustellen und zu verbessern. ITIL ist eines der Frameworks, die dafür konkrete Best Practices und Prozessdefinitionen liefern – ITSM ist also das Ziel, ITIL einer von mehreren Wegen dorthin.

USU Solution bringt es auf den Punkt: "ITIL ... ist ein spezifisches Framework innerhalb von ITSM, das eine Reihe von Best Practices und Prozessen für das effektive Management von IT-Services bietet." ITIL 4 war jahrelang die aktuelle Version und ist nach wie vor die in Unternehmen am weitesten verbreitete Grundlage – seit Januar 2026 aber nicht mehr die neueste: PeopleCert hat offiziell ITIL 5 angekündigt, die nächste Generation des Frameworks. Die Haufe Akademie beschreibt den Unterschied zwischen ITSM und ITIL 4 so: "Während sich ITSM mit der Bereitstellung, Unterstützung und Verbesserung von IT-Services auseinandersetzt ..., handelt es sich bei ITIL 4 um ein Framework, das den gesamten Lebenszyklus von IT-Services betrachtet." ITIL 4 führt dafür ganze 34 "Practices" statt der klassischen ITIL-Prozesse ein – Change Management, Incident Management und Asset Management sind darunter nur drei von vielen. Wie viele davon in ITIL 5 in dieser Form erhalten bleiben, ist zum jetzigen Zeitpunkt noch offen.

Wo brechen ITSM-Prozesse ohne zentrale Asset-Übersicht?

Immer dort, wo ein Prozess auf verlässliche Asset-Daten angewiesen ist: Configuration Management ohne aktuelle CMDB, Onboarding ohne Überblick über verfügbare Hardware, Offboarding ohne Nachweis, welche Lizenzen und Geräte zurückkommen müssen. Der Prozess selbst kann noch so sauber definiert sein – er scheitert an der Datenbasis darunter.

Das Problem ist branchenweit real, nicht nur ein Einzelfall: Laut einer Nexthink-Untersuchung aus 2023 wird die Hälfte aller installierten Software- und SaaS-Anwendungen in Unternehmen von Mitarbeitenden gar nicht genutzt – über sechs Millionen Endgeräte hinweg hochgerechnet auf geschätzt 500 Millionen Dollar verschwendete Lizenzkosten pro Jahr. Genau das ist der Punkt, an dem ITSM-Prozesse und Asset-Management aufeinandertreffen: Ein Incident-Prozess kann noch so gut dokumentiert sein – wenn niemand weiß, welches Gerät welchem Mitarbeitenden zugeordnet ist, kostet die Diagnose wertvolle Zeit. Ein Change-Prozess kann noch so sauber freigegeben sein – wenn die CMDB veraltet ist, wird die Änderung auf falscher Grundlage geplant.

Genau hier setzt equipme an, wo klassische ITSM-Prozesse aufhören: mit einem zentralen Überblick über Assets, Lizenzen und Zubehör – von der Anschaffung bis zur Rückgabe beim Offboarding. equipme ist kein ITSM-Tool und kein Ticketsystem und ersetzt keins – aber die Asset- und Configuration-Daten, an denen Incident-, Change- und Onboarding-Prozesse hängen, laufen bei equipme an einer Stelle zusammen statt in verstreuten Tabellen.

Fazit

ITSM-Prozesse geben deinem IT-Team eine gemeinsame Struktur für Anfragen, Störungen und Änderungen. Aber die sauberste Prozessdefinition hilft nichts, wenn die Datenbasis darunter fehlt: Fast jeder der sechs Kernprozesse, von Incident über Change bis Onboarding, braucht einen verlässlichen Überblick darüber, welche Assets es gibt, wo sie sich befinden und wem sie zugeordnet sind. Wer diesen Überblick hat, löst Störungen schneller, plant Änderungen sicherer und macht Onboarding und Offboarding zur Formsache statt zur Fehlerquelle.