ServiceNow ist eines der wenigen Softwareprodukte, das man sowohl für außerordentliche Produktivitätsgewinne loben als auch für außerordentliche Ressourcenverschwendung kritisieren kann – je nachdem, in welchem Unternehmen man gerade arbeitet. Beides ist zutreffend. Die Erfahrungen könnten kaum weiter auseinandergehen, und der Grund liegt selten in der Software selbst.
Wir begleiten Implementierungen und Optimierungen von ServiceNow-Umgebungen seit Jahren. Der häufigste Satz, den wir in ersten Gesprächen hören: “Wir haben ServiceNow, aber wir nutzen eigentlich nur das Ticket-System.”
Was ServiceNow tatsächlich kann
Wer ServiceNow als Helpdesk-Tool betrachtet, zahlt Enterprise-Preise für ein System, das mit Jira oder Zendesk verglichen werden kann – und diesen Vergleich nicht immer gewinnt.
ServiceNow ist eine Plattform. Das ITSM-Modul (IT Service Management) – Incident, Problem, Change, Request – ist der Einstiegspunkt, nicht das Ziel. Darum herum existiert ein Ökosystem:
CMDB (Configuration Management Database): Wenn sie gut befüllt und gepflegt ist, ist die CMDB das Rückgrat effizienter IT. Jede CI – jeder Server, jede Anwendung, jede Netzwerkkomponente – ist erfasst, mit Beziehungen zu anderen CIs modelliert, mit Services verknüpft. Ein Incident lässt sich direkt einem Business Service zuordnen. Impact-Analysen vor Changes werden automatisch berechnet.
In der Praxis: Die CMDB der meisten Unternehmen ist veraltet, unvollständig oder schlicht falsch. Geräte tauchen auf, die längst abgebaut sind. Beziehungen fehlen. Die Daten werden nicht systematisch aktualisiert, weil niemand dafür verantwortlich ist.
Workflow-Automatisierung (Flow Designer): ServiceNow kann komplexe Genehmigungsprozesse, Eskalationslogiken und automatisierte Aktionen ohne Code abbilden. Wer Onboarding-Prozesse, Softwareanfragen oder Change-Genehmigungen manuell koordiniert, hat hier Potential für erhebliche Effizienzgewinne.
IT Operations Management (ITOM): Monitoring-Daten aus bestehenden Systemen (Nagios, Zabbix, Dynatrace, Datadog) können in ServiceNow integriert werden. Alerts erzeugen automatisch Incidents. Incident-Korrelation reduziert Alert-Noise. Das setzt voraus, dass die Integrationen sauber konfiguriert sind – was ein eigenständiges Projekt ist.
Warum Implementierungen oft enttäuschen
ServiceNow ist ein Werkzeug, das sich an Prozesse anpassen soll. In der Praxis wird es häufig umgekehrt gemacht: Der Out-of-the-Box-Prozess wird übernommen, weil niemand Zeit hat, ihn anzupassen. Das führt zu einem System, das formal ITIL-konform ist, aber nicht zu den tatsächlichen Arbeitsweisen des Unternehmens passt.
Das Resultat: Die Mitarbeitenden arbeiten um das System herum – sie kommunizieren in E-Mail und Teams, die Tickets im System sind veraltet, und die Metriken, die ServiceNow produziert, spiegeln nicht die Realität wider.
Ein zweites häufiges Problem: Out-of-the-Box-Anpassungen durch Customizations statt Konfiguration. ServiceNow unterscheidet klar zwischen beiden. Konfiguration nutzt die vorgesehenen Anpassungspunkte – Update Sets, Flow Designer, Business Rules innerhalb der Plattformgrenzen. Customization bedeutet, die Plattform selbst zu verändern – Datenbankschema, Core-Tabellen, Kern-Skripte.
Letzteres ist kurzfristig verlockend, weil es jeden Sonderwunsch umsetzbar macht. Langfristig ist es ein Wartungsalptraum: Jedes ServiceNow-Upgrade muss gegen die eigenen Anpassungen getestet werden. Wer viel customized hat, steckt irgendwann in einer Version fest, weil das Upgrade zu riskant erscheint.
Was eine gute Implementierung ausmacht
Es gibt drei Faktoren, die wirklich erfolgreiche ServiceNow-Einführungen von mittelmäßigen unterscheiden:
Prozesse vor Konfiguration. Bevor das erste Flow-Designer-Diagramm geöffnet wird, muss klar sein: Wie läuft der Incident-Prozess heute wirklich ab, Schritt für Schritt? Wer ist beteiligt? Was sind die Ausnahmen? Was soll sich ändern? Ein System, das einen schlecht definierten Prozess abbildet, macht den Prozess nicht besser – es macht ihn nur schwerer zu ändern.
CMDB als Fundament, nicht als Nachprojekt. Teams, die ServiceNow einführen und die CMDB auf später verschieben, scheitern häufig daran, sie nachträglich zu füllen. Eine initiale CMDB mit den wichtigsten Business Services und ihren kritischen CIs – selbst wenn sie unvollständig ist – ist besser als eine leere CMDB mit dem Plan, sie irgendwann zu befüllen.
Klare Eigentümerschaft nach dem Go-Live. ServiceNow-Implementierungen scheitern selten beim Launch. Sie scheitern sechs bis zwölf Monate danach, wenn das Implementierungsprojekt beendet ist und niemand mehr klar verantwortlich ist. Wer pflegt die Workflows? Wer bearbeitet Change Requests auf der Plattform? Wer sorgt für Upgrades? Ohne dedizierte Antworten auf diese Fragen verfällt die Plattform zum teuren Ticketsystem.
Wann eine Bestandsaufnahme sinnvoll ist
Für Unternehmen, die ServiceNow seit mehr als zwei Jahren im Einsatz haben und das Gefühl nicht loswerden, das System nicht wirklich zu nutzen, lohnt sich ein ehrlicher Blick: Wie viele der lizenzierten Module werden aktiv genutzt? Wie vollständig ist die CMDB? Wie viele Workflows laufen noch über E-Mail und Telefon?
Diese Bestandsaufnahme ist nicht angenehm. Aber sie ist der erste Schritt, um zu entscheiden, ob das Problem eine Prozessfrage ist, eine Konfigurationsfrage – oder ob die Lizenz für eine andere Lösung besser genutzt wäre.