5 Schritte wie man einen ServiceNow® «Neustart» verhindert
05.07.2021
Wenn Sie eine schlecht konfigurierte ServiceNow® Umgebung einsetzen, sitzen Sie auf einer perfiden Zeitbombe, merken lange nicht wie die Lunte unter Ihnen glüht. Und wenn Sie den Zustand nicht genau kennen, dann glüht sie wahrscheinlich schon länger. Verhindern Sie die Detonation - es gibt Abhilfe und Löschwasser, auf die wir in diesem Beitrag eingehen.
Ich beschäftige mich seit vielen Jahren ausschliesslich mit ServiceNow® und habe so ziemlich Alles schon gesehen und die raketenartige Entwicklung von ServiceNow® sowohl technisch als Partner und aus Kundensicht live miterlebt. Letztlich lese ich häufiger von ServiceNow® «Neustarts» und frage mich: muss das sein?
Disclaimer: Keine zwei Umgebungen Kunden oder Projekte sind gleich. Es ist wichtig das jeweilige Projekt, die Umgebung und den jeweiligen Stand individuell zu bewerten, ob ein Neustart sinnvoll ist oder nicht. Es muss bewusst für jeden Einzelfall entschieden werden. Eine allgemein gültige Regel gibt es nicht…
Risiken eines Neustarts
Als Cloud-Plattform unterliegt ServiceNow® ständigem Wachstum und Wandel. Mit jedem der mittlerweile zweimal jährlich erscheinenden Releases wächst die Plattform an, bietet mehr Funktionalität und verspricht mehr und schnelleren Nutzen. Anpassungen fortzuführen wird gefühlt komplizierter und langwieriger. Je individueller die Anpassungen (die in der Menge naturgemäss über die Zeit zunehmen) sind desto wahrscheinlicher führen sie zu potenziell kritischen Nebenwirkungen, ihre technische Schuld wächst. Die Unternehmen reagieren mit endlos langen Testzyklen bei Releasewechseln. Dies führt zu steigenden Kosten und im Zusammenwirken mit dem Druck, aus Sicherheitsgründen stets auf ein aktuelles (nicht abgekündigtes) Release einsetzen zu müssen, gerät man final schlicht in einen Deadlock in dem ein Neustart eine gangbare (und vermeintlich kostengünstige) Lösung scheint.
Doch damit geht man Risiken ein, die sich in folgende Gruppen einteilen lassen:
- Transitionsrisiken
- Verlust von individuellen Vorteilen
- Nebenwirkungen
- Betriebliche Aspekte
Transitionsrisiken bezeichnen Unsicherheiten, die sich durch den Übergang ergeben. Wie arbeiten Ihre Mitarbeiter in dieser Phase? Was passiert mit aktiven, ggf. langlaufenden Workflows? Wie gewöhnen Sie die Nutzer an Änderungen? Sinkt in dieser Phase die temporäre Produktivität? Gibt es existierende Backlogs, die vor einem cut-over abgearbeitet werden müssen?
Den Verlust von individuellen Vorteilen als Risiko abzuschätzen ist nicht einfach, denn es erfordert, dass Sie genau wissen müssen, was das heutige «Delta» zu einer OOTB ServiceNow® Umgebung ist. Oft ist das leider nicht gegeben und erfordert eine sehr gute Vorbereitung und Analyse in der Vorphase. Was nicht bewusst (lies: dokumentiert, bekannt, berücksichtigt) ist, kann auch nicht mitgenommen werden. Und das betrifft durchaus nicht nur Ihre ServiceNow® Umgebung selbst, sondern auch die angebundenen Umsysteme.
Damit kommen wir zu den Nebenwirkungen. Diese verstecken sich oft genau hier, an den Schnittstellen zu Umsystemen. Oft verlassen sich diese Schnittstellen auf bestimmte Datenformate oder Inhalte im Austausch, die sich nach einem Neustart geändert haben können. Auch zeitliche Kommunikationsprofile auf technischer (Time-outs, etc.) und fachlicher (wann erfolgt ein Austausch, was löst aus, usw.) Seite müssen berücksichtigt werden.
Betriebliche Aspekte sind häufig ein pain-point, den man zu entschärfen sucht mit einem Neustart. Es lohnt sich sehr, die heutigen Herausforderung in betrieblichen Themen detailliert zu untersuchen und Schlüsse daraus zu ziehen, was bei einem Neustart eben nicht passieren darf. Und es schadet nicht für die Zukunft darauf vorbereitet zu sein.
Neustart verhindern in 5 Schritten
Wer die Risiken nicht eingehen möchte der kann Massnahmen ergreifen, um die Situation zu verbessern. Um der Notwendigkeit für einen Neustart konsequent entgegenzutreten hat sich ein Vorgehensmodell mit den folgenden fünf Schritten bewährt:
Schauen wir uns die einzelnen Schritte etwas genauer an:
- Identifikation der pain-points
- Beschreibung des Idealzustands
- Neutrales Review
- Definition und Priorisierung von Massnahmen
- Iterative Umsetzung
Was sind die pain-points? Eine genaue Vorstellung davon was die primären Auswirkungen sind, die die Schmerzen bereiten ist Voraussetzung für Alles weitere. Geht es darum, dass Sie betrieblich überlastet sind? Dauern Upgrades zu lange? Haben Sie ein kontinuierliches Wachstum im Backlog, das sie nicht umsetzen können? Sind Sie nur noch fremdgesteuert durch Anpassungen von Schnittstellen? Das Wissen darum, was der Hauptgrund ist, hilft bei der späteren Priorisierung von Massnahmen.
Entwerfen Sie dann einen Idealzustand – wie wäre es, wenn das was Sie behindert, beseitigt ist? Woran konkret messen sie den Erfolg? Es hilft, sich in die Position einzelner beteiligter Personen oder Organisationseinheiten zu versetzen, um diese konkreten Vorteile aufzuzeigen. Dies kann benutzt werden um intern buy-in für Massnahmen zu bekommen.
Beauftragen Sie ein neutrales Review der Umgebungen. Keine noch so gut gemeinte Massnahme wird jemals erfolgreich sein können ohne die genaue Kenntnis des Ist Zustandes. Die Erhebung sollte durch eine neutrale Stelle erfolgen. Typischerweise arbeiten Unternehmen mit ServiceNow® und deren Partnern zusammen, haben aber auch interne Mitarbeiter, die sich langfristig um die Umgebung kümmern. Wählen Sie jemand anderen und legen Sie den Scope anhand Ihrer pain-points und Idealbild fest, vergessen Sie nicht ggf. Umsysteme mit einzubeziehen und sowohl eine daten- als auch eine prozessorientierte Analyse zu fordern.
Das Ergebnis des Reviews hilft Ihnen bei der Definition, Auswahl und Priorisierung von Massnahmen. Diese bilden ein Backlog für die Umsetzung. Wichtig ist dabei zu beachten, dass ein bestehendes Backlog und/oder Vorhaben Projekte im Licht der «Reparaturmassnahmen» neu bewertet und eingeplant werden müssen. Ändert sich ggf. die Arbeitsweise (Stichwort: konsequentes Scoping), ändern sich Schnittstellen oder Prozesse?
Danach geht es an die konsequente Umsetzung der priorisierten Massnahmen. Ein wichtiger technischer Aspekt ist die Betrachtung von «Toolboxen» der Partner, die häufig sehr spezifisch sind, von den Unternehmen nur wenig verstanden werden und nach dem Weggang von Partnern nicht weiter gewartet werden. Hier empfiehlt sich dringend nur noch im ServiceNow® Store verfügbare Bausteine zu verwenden, denn so ist die Kompatibilität für neue Releases auch nach Weggang oder Wechsel des Partners sichergestellt. Generell hat sich bei der Umsetzung bewährt Experten einzubeziehen, die gemeinsam mit dem Team vor Ort nicht nur verbesserte Techniken lernen und umsetzen, sondern auch vereinfachte betriebliche Verfahren gemeinsam einüben. Dies ist ein iterativer Prozess, der dann überleitet in die neue Normalität der Nutzung und Wartung Ihrer Umgebung.
Takeaways
Ein Neustart von ServiceNow® ist nicht zwingend die letzte Möglichkeit, die bleibt, wenn man eine gewachsene ServiceNow® Instanz beginnt Alterserscheinungen zu zeigen. Es gibt erprobte und effektive Vorgehen und Verfahren, um mit ganz normaler Arbeit einem Idealzustand wieder näher zu kommen.
Das Risiko einer iterativen Beseitigung ist in jedem Fall geringer und besser beherrschbar als das eines Neustarts. Aber nicht allein das Risiko, sondern die Kosten sowie der potenzielle Nutzen müssen in die Betrachtung einbezogen werden. Ob nun ein Neustart sinnvollerweise verhindert werden soll, kann nur im Einzelfall entschieden werden.
Letztlich sollten die Unternehmen aber auf keinen Fall die eigene Beherrschung Ihrer ServiceNow® Umgebung – bewusst oder unbewusst – aus der Hand geben. Dafür braucht es Ownership (Verantwortung und Entscheidungskompetenz in eigener Hand) und klare Governance.