ITSM einführen: Vorgehensmodell – Die Einführung von IT Service Management (ITSM) gehört zu den anspruchsvollsten, aber auch wirkungsvollsten Vorhaben in der IT. Wer ITSM strukturiert einführt, schafft nicht nur mehr Stabilität im Betrieb, sondern erhöht auch die Zufriedenheit der Fachbereiche und reduziert langfristig Kosten. Damit das gelingt, brauchen Sie ein klares Vorgehensmodell, das Strategie, Prozesse, Organisation und Tool-Unterstützung sinnvoll verbindet.
Im folgenden Fachartikel erhalten Sie ein praxisnahes Vorgehensmodell, das Sie Schritt für Schritt durch die Einführung von ITSM führt – von der ersten Standortbestimmung bis zur kontinuierlichen Verbesserung.

1. Grundlagen: Was bedeutet ITSM und warum braucht es ein Vorgehensmodell?
IT Service Management umfasst alle Maßnahmen und Prozesse, mit denen eine IT-Organisation ihre Services plant, bereitstellt, betreibt und kontinuierlich verbessert. Bekannt sind vor allem Frameworks wie ITIL, doch in der Praxis zählt vor allem, wie konsequent Sie diese Prinzipien an Ihre Organisation anpassen.
Ohne klares Vorgehensmodell entstehen schnell folgende Probleme:
- Unklare Ziele und Erwartungen zwischen IT und Business
- Überladene Prozessmodelle, die niemand lebt
- Tool-Einführungen, die Prozesse diktieren statt unterstützen
- Widerstände in der Organisation, weil Rollen, Verantwortlichkeiten und Nutzen nicht verstanden werden
Ein strukturiertes Vorgehensmodell sorgt dagegen dafür, dass Sie:
- Ein gemeinsames Zielbild für ITSM entwickeln
- Schrittweise und priorisiert vorgehen, statt alles auf einmal umzubauen
- Prozesse pragmatisch gestalten und konsequent an den Business-Bedarf koppeln
- Menschen frühzeitig mitnehmen und befähigen
2. Phase 0: Zielbild und Rahmenbedingungen klären
Bevor Sie das erste Prozessdiagramm zeichnen oder ein Tool evaluieren, sollten Sie Ihr Zielbild und die Rahmenbedingungen sauber definieren. Gerade dieser Schritt entscheidet häufig darüber, ob Ihr ITSM-Programm später trägt oder im Tagesgeschäft versandet.
2.1 Strategische Ziele und Nutzen definieren (H3)
Starten Sie mit den Fragen „Warum tun wir das?“ und „Was soll in 2–3 Jahren anders sein?“. Dabei hilft es, strategische Ziele greifbar zu formulieren, zum Beispiel:
- Servicequalität erhöhen: z. B. messbar weniger kritische Incidents
- Transparenz schaffen: klare Servicekataloge und nachvollziehbare Kosten
- Effizienz steigern: kürzere Durchlaufzeiten, weniger manuelle Workarounds
- Compliance sichern: nachvollziehbare Änderungen, Audit-Fähigkeit
Verknüpfen Sie diese Ziele bewusst mit der Unternehmensstrategie, denn nur so erhält Ihr ITSM-Programm ausreichende Priorität und Unterstützung.
2.2 Stakeholder, Governance und Scope festlegen (H3)
Anschließend definieren Sie, wer das Vorhaben trägt und wie Entscheidungen getroffen werden. Dazu gehören unter anderem:
- Sponsor: typischerweise CIO oder IT-Leitung mit klarer Mandatierung
- Steuerkreis / Lenkungsausschuss: IT-Führung und wichtige Business-Vertreter
- ITSM-Programmleitung: verantwortlich für Koordination, Priorisierung und Kommunikation
- Scope der ersten Ausbaustufe: z. B. Fokus auf Incident, Request und Change in ausgewählten Bereichen
Je klarer Sie Governance und Scope beschreiben, desto leichter lassen sich später Zielkonflikte auflösen und Prioritäten setzen.
3. Phase 1: Ist-Analyse und Reifegradbestimmung
Bevor Sie neue Prozesse definieren, brauchen Sie ein realistisches Bild des Status quo. Dadurch vermeiden Sie, dass Sie ein theoretisch „perfektes“ ITSM-Design entwickeln, das an der Realität vorbeigeht.
3.1 Ist-Prozesse und Organisation verstehen (H3)
Erheben Sie, wie Services heute erbracht werden – idealerweise entlang echter Beispiele:
- Wie läuft ein Incident vom Eingang bis zur Lösung ab?
- Wie beantragt ein Mitarbeiter aktuell einen neuen Laptop?
- Wie gehen Sie mit Änderungen in produktiven Systemen um?
Nutzen Sie dazu:
- Workshops mit Service-Desk, 2nd-Level, Applikationsverantwortlichen und Fachbereichen
- Shadowing im Betrieb, um reale Abläufe zu beobachten
- Analyse vorhandener Tickets, um Volumina und Engpässe sichtbar zu machen
Dokumentieren Sie nicht jede Ausnahme, sondern konzentrieren Sie sich auf typische Muster und strukturelle Probleme.
3.2 Reifegrad bewerten und Handlungsfelder ableiten (H3)
Anschließend bewerten Sie den ITSM-Reifegrad, zum Beispiel entlang von Dimensionen wie:
- Prozessreife: existieren definierte Prozesse, werden sie gelebt, werden sie gemessen?
- Organisation & Rollen: sind Verantwortlichkeiten klar, existiert ein Service-Owner-Modell?
- Tools & Automatisierung: in welchem Umfang unterstützen Tools die Prozesse?
- Kultur: wie serviceorientiert denkt die IT, wie stark ist die Zusammenarbeit mit dem Business?
Auf dieser Basis identifizieren Sie konkrete Handlungsfelder, etwa:
- „Störungsbearbeitung ist stark personenabhängig, kaum standardisiert.“
- „Änderungen werden nicht einheitlich bewertet, Risiken bleiben intransparent.“
- „Servicekatalog fehlt, dadurch sind Leistungen und Zuständigkeiten unklar.“
Diese Analyse bildet die Grundlage für einen realistischen und akzeptierten Umsetzungsplan.
4. Phase 2: ITSM-Zielbild und Prozessdesign
Nun entwickeln Sie ein Zielbild, das sowohl am ITIL-Referenzmodell orientiert ist als auch zur Größe und Kultur Ihres Unternehmens passt. Dabei entscheiden Sie bewusst, womit Sie starten und was später folgt.
4.1 Priorisierte Prozesse auswählen (H3)
Ein typischer und bewährter Einstieg besteht aus:
- Incident Management: schnelle Wiederherstellung bei Störungen
- Request Fulfilment / Request Management: standardisierte Bearbeitung von Serviceanfragen
- Change Enablement / Change Management: strukturierte Steuerung von Änderungen
- Problem Management: nachhaltige Beseitigung von Ursachen wiederkehrender Störungen
- Configuration Management / CMDB (in abgestuftem Umfang): Transparenz über Infrastruktur und Abhängigkeiten
Statt alle Prozesse gleichzeitig auszurollen, wählen Sie 2–3 Kernprozesse, die den größten Mehrwert bieten und sich gegenseitig verstärken.
4.2 Rollen, Verantwortlichkeiten und Schnittstellen definieren (H3)
Prozesse funktionieren nur, wenn Rollen und Schnittstellen klar sind. Daher legen Sie für jeden Prozess mindestens fest:
- Process Owner: verantwortet Design, Performance und kontinuierliche Verbesserung
- Process Manager / Koordinator: steuert den operativen Ablauf und die Einhaltung der Vorgaben
- Rollen in der Linie: z. B. Service Desk Agent, Resolver Group, Change Advisory Board (CAB)
Nutzen Sie z. B. RACI-Matrizen, um Zuständigkeiten entlang der Prozessschritte transparent zu machen. Dadurch reduzieren Sie spätere Reibungsverluste erheblich.
4.3 Prozessdesign pragmatisch halten (H3)
Beim Design der Prozesse empfiehlt sich ein pragmatischer Ansatz:
- Starten Sie mit End-to-End-Sicht, statt sich in Detailvarianten zu verlieren.
- Arbeiten Sie mit klaren, sprechenden Status und möglichst einfachen Regeln.
- Modellieren Sie keine theoretischen Ausnahmen, die praktisch kaum vorkommen.
- Definieren Sie früh sinnvolle Kennzahlen (KPIs), damit der Nutzen sichtbar wird.
So vermeiden Sie „Papierprozesse“, die zwar hübsch aussehen, aber niemand konsequent lebt.
4.4 Tool-Landschaft und Automatisierung planen (H3)
Erst nachdem Sie Prozesse und Rollen grob definiert haben, sollten Sie sich intensiv mit Tools befassen. Dadurch verhindern Sie, dass das Tool das Prozessdesign diktiert.
Achten Sie bei der Tool-Auswahl unter anderem auf:
- Passung zur vorhandenen Systemlandschaft
- Unterstützung zentraler Workflows (z. B. Ticket-Routing, SLAs, Genehmigungen)
- Reporting- und Dashboard-Fähigkeiten
- Schnittstellen zu Monitoring, Identity Management und CMDB
- Benutzerfreundlichkeit für Service Desk und Fachbereiche
Planen Sie außerdem, welche Schritte Sie kurzfristig automatisieren möchten und welche eher in einer späteren Ausbaustufe folgen.
5. Phase 3: Implementierung, Pilotierung und Change Management
Jetzt geht es in die Umsetzung. Allerdings entscheidet sich gerade in dieser Phase, ob die Mitarbeitenden die neuen Prozesse annehmen oder ob sie bei den gewohnten inoffiziellen Wegen bleiben.
5.1 Umsetzungsplanung und Roadmap (H3)
Erstellen Sie eine realistische Roadmap, die sowohl technische als auch organisatorische Schritte umfasst:
- Detaillierung der priorisierten Prozesse
- Konfiguration / Customizing des ITSM-Tools
- Datenmigration und Schnittstellen-Implementierung
- Aufbau Servicekatalog (mindestens für die Pilotbereiche)
- Schulung, Kommunikation und Change-Management-Maßnahmen
Planen Sie bewusst Puffer ein, denn Parallelbelastung durch Tagesgeschäft und Projekt ist die Regel, nicht die Ausnahme.
5.2 Pilotprojekte bewusst wählen und auswerten (H3)
Führen Sie neue Prozesse und Tools nicht sofort flächendeckend ein, sondern starten Sie mit einem Pilot:
- Wählen Sie einen Bereich, der offen für Veränderungen ist und einen klaren Nutzen erkennt.
- Definieren Sie konkrete Erfolgsfaktoren, etwa verkürzte Durchlaufzeiten oder höhere Erstlösungsquote.
- Begleiten Sie den Pilot eng, sammeln Sie Feedback und passen Sie Prozesse sowie Tool-Konfiguration an.
So gewinnen Sie Erfahrungswerte und schaffen gleichzeitig interne Referenzen, die andere Bereiche überzeugen.
5.3 Schulung, Kommunikation und kultureller Wandel (H3)
ITSM ist immer auch Kulturveränderung. Deshalb reicht eine einmalige Tool-Schulung nicht aus. Stattdessen kombinieren Sie verschiedene Maßnahmen:
- Rollenbasierte Schulungen: Service Desk, Fachbereiche, Führungskräfte
- Kommunikationskampagnen: „Was ändert sich für mich?“, „Wofür ist das gut?“
- Guides und How-tos: kurze Anleitungen direkt im Tool oder im Intranet
- Feedback-Kanäle: z. B. regelmäßige Austauschformate oder Retro-Sessions
Betonen Sie den Nutzen für die Beteiligten, nicht nur für „die IT“ oder „das Management“. Wenn Mitarbeitende verstehen, dass standardisierte Prozesse ihnen Arbeit erleichtern, steigt die Akzeptanz deutlich.
6. Phase 4: Betrieb, Steuerung und kontinuierliche Verbesserung
Nach dem Rollout beginnt der eigentliche Alltag im ITSM. Gerade jetzt lohnt es sich, nicht in den „Betriebsmodus ohne Reflexion“ zu verfallen, sondern systematisch zu steuern und zu verbessern.
6.1 Kennzahlen, Reporting und Service Reviews (H3)
Definieren Sie wenige, aber aussagekräftige Kennzahlen, zum Beispiel:
- Anzahl und Schweregrade von Incidents
- Lösungszeiten (Mean Time to Resolve)
- Erstlösungsquote im Service Desk
- Durchlaufzeiten von Changes und Anteil erfolgreicher Changes
- Zufriedenheit der Anwender (z. B. über kurze Umfragen nach Ticketabschluss)
Nutzen Sie Dashboards, um Transparenz zu schaffen, und führen Sie regelmäßige Service Reviews mit den Fachbereichen durch. Dadurch erkennen Sie Trends frühzeitig und diskutieren Verbesserungsmaßnahmen auf Basis gemeinsamer Fakten.
6.2 Kontinuierliche Verbesserung institutionalisieren (H3)
Verankern Sie kontinuierliche Verbesserung nicht nur als Schlagwort, sondern als festen Prozess:
- Regelmäßige Retrospektiven pro Prozess (z. B. vierteljährlich)
- Ideensammlung über ein zentrales Backlog, das der Process Owner priorisiert
- Kleine, schnell umsetzbare Verbesserungen („Quick Wins“) konsequent realisieren
- Größere Veränderungen als Mini-Projekte strukturieren
So entwickelt sich Ihr ITSM Schritt für Schritt weiter, statt nach dem ersten Rollout stehenzubleiben.
7. Typische Stolpersteine und wie Sie sie vermeiden
Auch bei guter Planung treten erfahrungsgemäß immer wieder ähnliche Schwierigkeiten auf. Wenn Sie diese Stolpersteine von Beginn an berücksichtigen, erhöhen Sie die Erfolgschancen deutlich.
Häufige Stolpersteine:
- ITSM wird als reines IT-Projekt verstanden, ohne Business-Beteiligung
- Prozesse orientieren sich zu stark an ITIL-Büchern und zu wenig an realen Bedürfnissen
- Tool-Einführung dominiert, Prozesse und Organisation bleiben unterbelichtet
- Rollen bleiben nur auf dem Papier, Verantwortlichkeiten sind faktisch unklar
- Kennzahlen werden zwar erhoben, aber kaum interpretiert oder genutzt
- Change Management wird unterschätzt, Widerstände bleiben unbearbeitet
Ansätze zur Vermeidung:
- Business früh einbinden und Nutzen klar kommunizieren
- Prozesse gemeinsam mit den operativ Beteiligten entwickeln
- Toolauswahl aus den definierten Prozessen ableiten, nicht umgekehrt
- Rollenbeschreibungen mit Führungskräften und Mitarbeitenden konkret durchsprechen
- KPIs konsequent in Reviews und Entscheidungen einfließen lassen
- Change-Management budgetieren und professionell aufsetzen
8. Fazit ITSM einführen: Vorgehensmodell: ITSM-Einführung als Reise, nicht als Einmalprojekt
Eine ITSM-Einführung ist kein Sprint, sondern eine mehrjährige Reise. Mit einem klaren Vorgehensmodell, realistischen Etappen und konsequenter Einbindung der Menschen schaffen Sie jedoch die Grundlage für eine stabile, transparente und serviceorientierte IT-Organisation.
Wenn Sie
- ein gemeinsames Zielbild formulieren,
- den Ist-Zustand ehrlich analysieren,
- Prozesse pragmatisch designen,
- Tool und Organisation klug verzahnen
- und kontinuierliche Verbesserung institutionalisieren,
dann entwickelt sich ITSM von einer „Pflichtübung“ zu einem echten Mehrwert für Unternehmen und Anwender.