ServiceNow ITSM einführen: erst der Prozess, dann die Plattform

Es gibt einen Satz, den ich in Kickoffs zu ServiceNow-ITSM-Einführungen öfter sage, als mir lieb ist: ServiceNow repariert keine kaputten Prozesse. Es macht sie nur schneller und sichtbarer.

Das klingt nach Beraterweisheit vom Kalenderblatt, aber dahinter steckt die häufigste und teuerste Fehlentscheidung, die ich bei ITSM-Projekten sehe: Das alte Tool wird eins zu eins nachgebaut, inklusive aller historisch gewachsenen Sonderlocken. Die Plattform ist neu, die Probleme bleiben dieselben.

Ein Beispiel aus der Praxis

Ein Kunde wollte sein Incident Management von einem Alttool auf ServiceNow migrieren. Im alten System gab es 14 Prioritätsstufen, drei verschiedene Eskalationswege je nach Abteilung und ein Feld namens "Sonderkennzeichen 2", dessen Bedeutung niemand mehr erklären konnte. Der erste Wunsch im Workshop: bitte alles genauso nachbauen, die Mitarbeiter kennen das schließlich.

Hätten wir das gemacht, wäre das Ergebnis ein teures neues Tool mit den alten Problemen gewesen. Dazu ein Berg an Customizing, der jedes künftige Upgrade verteuert.

Stattdessen haben wir zwei Wochen investiert, um die Prozesse selbst auf den Tisch zu legen. Welche der 14 Prioritäten werden tatsächlich unterschiedlich behandelt? Antwort nach Auswertung der Daten: drei. Welche Eskalationswege haben in den letzten zwölf Monaten je gegriffen? Einer. Was bedeutet "Sonderkennzeichen 2"? Nach drei Interviews stellte sich heraus: Es war ein Workaround für einen Report, den es seit Jahren nicht mehr gab.

Diese zwei Wochen waren teilweise unbequem. Sonderlocken haben immer einen Besitzer, der an ihnen hängt, und manchmal ist der Besitzer im Lenkungsausschuss. Aber genau diese Diskussionen sind der wertvollste Teil einer ITSM-Einführung. Die Plattform zu konfigurieren ist dagegen fast schon das Einfache.

Warum der Standard so wertvoll ist

ServiceNow bringt mit seinen ITSM-Prozessen jahrzehntelang verdichtete Best Practice mit, eng an ITIL angelehnt und in tausenden Organisationen erprobt. Incident, Problem, Change, Request: die Standardprozesse funktionieren. Nicht, weil sie perfekt für jedes Unternehmen wären, sondern weil sie für 90 Prozent der Anforderungen gut genug sind und für die restlichen 10 Prozent saubere Erweiterungspunkte bieten.

Mein Vorgehen hat sich über die Jahre auf drei Grundsätze eingependelt:

Out-of-the-box ist der Ausgangspunkt, nicht die Verhandlungsmasse. Der Standard wird komplett verstanden und durchgespielt, bevor über Anpassungen geredet wird. Erstaunlich oft löst sich ein vermeintlicher Sonderfall auf, sobald die Beteiligten sehen, wie der Standardprozess das Thema behandelt.

Die Beweislast liegt bei der Abweichung. Nicht der Standard muss sich rechtfertigen, sondern jede Abweichung davon. Eine gute Testfrage: Würde ein Außenstehender den Geschäftsgrund für diese Anpassung in einem Satz verstehen? Wenn die Begründung mit "das haben wir schon immer so gemacht" beginnt, ist es kein Geschäftsgrund.

Konfiguration vor Customizing. Anpassungen, die es durch die Diskussion schaffen, werden mit Bordmitteln gelöst, also mit Properties, UI Policies, Flows, Business Rules in Maßen. Eingriffe, die Upgrade-Pfade gefährden, brauchen eine Architektur-Entscheidung und ein dokumentiertes Warum.

Was das langfristig bedeutet

Die Effekte zeigen sich nicht nur im Projekt, sondern vor allem danach. Upgrades bleiben günstig, weil wenig angepasst wurde. Die Instanz bleibt wartbar, weil sie sich verhält, wie es Dokumentation und Community beschreiben. Neue Mitarbeiter und externe Unterstützung finden sich schnell zurecht, weil die Prozesse dem entsprechen, was Schulungen vermitteln.

Und es gibt einen Effekt, der oft übersehen wird: Ein sauberer Standardprozess ist die Voraussetzung für alles, was danach kommt. Automatisierung, Self Service, Reporting und perspektivisch auch KI-Funktionen setzen auf konsistenten Prozessdaten auf. Wer 14 Prioritäten und Sonderkennzeichen mitschleppt, baut all das auf Sand.

Wer zuerst die Plattform kauft und dann über Prozesse nachdenkt, zahlt am Ende doppelt: einmal für das Customizing und einmal für dessen Rückbau, wenn die nächste Modernisierung ansteht. Die Reihenfolge ist kein Detail. Sie ist die halbe Projektentscheidung.