ServiceNow «Neustart» richtig gemacht

13. Jul 2021

Was bremst den Elefanten?

In meinem letzten Beitrag habe ich behandelt, wie ein Neustart vermieden werden kann. Sollte das nicht (mehr) möglich sein, dann ist es wichtig den Neustart «richtig» zu machen, Fehler zu vermeiden und Altlasten konsequent loszuwerden.

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. Wenn Sie die Detonation nicht mehr verhindern können oder wollen - es gibt gute und erprobte Wege für einen Neustart, 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. In letzter Zeit lese ich häufiger von ServiceNow «Neustarts» und den Folgen und frage mich: warum machen das so wenige richtig gut?

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…

Warum zurück auf 0?

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 höheren 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) desto wahrscheinlicher führen sie zu potenziell kritischen Nebenwirkungen. 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 ein aktuelles (nicht abgekündigtes) Release einsetzen zu müssen, gerät man final schlicht in eine Sackgasse.

Was bremst den Elefanten?

In meiner Praxis habe ich fünf generelle Muster gesehen, welche die oben beschriebene Situation begünstigen:

  • Funktionale Weiterentwicklung
  • Technische Neuerungen
  • Schlechte Umsetzung(en)
  • Betriebliche Themen
  • Weitere Faktoren
  • Funktionale Weiterentwicklung

Langjährige Kunden haben Funktionalität auf der Plattform selbst entwickelt, die zu einem späteren Zeitpunkt als Teil der Plattform oder als Store App zur Verfügung stand. Ein gutes Beispiel hierfür ist z.B. Facility Management oder Custom Erweiterungen der CMDB. Was ist nun zu tun? Zunächst muss entscheiden werden was eingesetzt werden soll, die bestehende Lösung, die neue Funktionalität? Häufig ist es die neue Funktionalität, samt einer Migration der Daten. Die bestehende Lösung wird aber in den seltensten Fällen sauber entfernt, sondern – aus guten und/oder schlechten Gründen – erstmal «deaktiviert». Und dann vergessen. Nach zwei Releases weiss niemand mehr was das technisch bedeutet und niemand traut sich die Altlast zu entfernen, zumal diese meist schlecht oder gar nicht dokumentiert ist.

Technische Neuerungen

Neue Möglichkeiten, insbesondere das Application-Scoping, eignen sich neben dem Bau von Custom Applikationen hervorragend dafür, Anpassungen an Standardprozessen derart zu isolieren, dass der Impact auf Upgrades fast komplett beseitigt werden kann. Kaum jemand nutzt diese Möglichkeit. Selbstverständlich erfordert dies vorab eine entsprechende Abstimmung/Lizensierung mit dem Hersteller ServiceNow. Dies ist vor Allem ein Problem bzgl. der Qualifikation der Personen, die die ServiceNow Plattform bei den Kunden technisch betreuen. Kurzfristig ist es lukrativ Ressourcen einzusetzen, statt Sie besser auszubilden. Ein 20% höherer Aufwand für eine sauber isolierte und dokumentierte Anpassung hat sich i.d.R. bereits nach einem einzigen Releasewechsel gerechnet (Erinnerung: es gibt zwei pro Jahr).

Schlechte Umsetzung(en)

Dieser Punkt hängt stark mit dem Vorhergehenden zusammen. Zu viele Unternehmen verzichten darauf selbst tiefe Expertise aufzubauen für ServiceNow und verlassen sich auf Dienstleister. Das ist aus meiner Sicht ein grosser Fehler. Wenn ServiceNow als strategische Plattform angesehen wird (und das sollte so sein), dann ist in-house Erfahrung unerlässlich. Diese Aufzubauen ist nur mit guter externer Unterstützung möglich. Und nur mit dieser Erfahrung ist es möglich zu beurteilen, ob eine Umsetzung, sei es eine Custom Lösung oder die Anpassung eines Standardprozesses technisch, so gemacht ist, dass eben keine technische Schuld aufgebaut wird. Dies ist leider auch nach meiner Einschätzung mit den Health-Checks nicht zuverlässig zu erreichen, denn die Ergebnisse hängen sehr stark von der Erfahrung, Qualifikation und dem persönlichen Engagement der ausführenden Personen ab. Hinterfragen Sie was Ihr Ziel bei einem solchen Check ist? Aufzudecken, dass noch 1.5 Jahre Arbeit bevorstehen, um «sauber» abschliessen zu können oder ein OK vom Hersteller zu bekommen? Prüfen Sie genau wer Ihre Instanz betreuen darf, verlangen Sie Belege für mehrjährige, belastbare technische Expertise jeder involvierten Person. Gerade in diesem Kontext.

Betriebliche Themen

Wir erleben regelmässig, dass nach der initialen Begeisterung eine gewisse Ernüchterung eintritt, wenn es darum geht, dass auch eine Cloud-Lösung wie ServiceNow betriebliche Aufwände verursacht. Und zwar dauerhaft. Diese zu ignorieren, den Betrieb nicht organisiert durchzuführen (inkl. Housekeeping-Aufgaben usw.) ist teuer und wenig empfehlenswert. Denn wenn die Ausführung betrieblicher Aufgaben nicht zu kontinuierlichen Verbesserungen führt, dann führt Sie neben Kosten zu ständig anwachsender technischer Schuld. Es sieht oberflächlich betrachtet nicht so aus, denn betriebliche Probleme werden ja behoben. Die grosse Frage ist: Wie? Je länger die Ursache dieser aber nicht beseitigt ist, desto schwieriger wird es technische Schuld zu erkennen, zumal nach mehreren Releasewechseln. Ich empfehle dringend schon von Tag eins an betriebliche Aufgaben mit zu betrachten bei der Planung.

Weitere Faktoren

Es gibt aus meiner Erfahrung einige bestimmende Faktoren, die die Entstehung der obigen Muster begünstigen. Die Wahl der richtigen externen Partner sollte sich allein auf zwei Kriterien fokussieren: Erfahrung und Expertise der eingesetzten Personen mit ServiceNow, sowie Qualität. Um Benjamin Franklin zu zitieren: «The bitterness of poor quality remains long after the sweetness of low price is forgotten». Schade, aber wahr. Das Outsourcing der gesamten ServiceNow Thematik an externe Partner birgt dabei zusätzlich das Risiko, dass die Unternehmen selbst die Steuerungsmöglichkeit abgeben und eine Abhängigkeit zu den Partnern besteht. Das ist schlimm und trotzdem oft noch bewusst gewählt. Viel schlimmer ist jedoch, dass die Unternehmen dann nach kurzer Zeit nicht mehr in der Lange sind, die Qualität und Eignung der Partner zu erkennen, zu bewerten und Einsatz/Weiterentwicklung der Plattform zu steuern. Sämtliche Versuche von Governance müssen also scheitern, wenn keine technische Expertise vorhanden ist zu beurteilen, ob Sie auch wirkt. Wer sich nicht kümmert muss sich nicht wundern, dass er nicht weiss, wie er steuern kann.

Ein wichtiger technischer Aspekt ist die Betrachtung von «Toolboxen» der Partner, die häufig sehr spezifisch sind, von den Unternehmen nur wenig verstanden sind 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.

Fragen Sie Ihren Dienstleister nach folgenden Themen und wie diese gelöst werden: Namenskonventionen, Scoping, Dokumentation, Releaseprozess, Cloning (Umgang mit Umsystemen), Testing Personas, Automated Regression Testing, Testdatenmanagement, Deployment Handling, Betriebliche Behandlung von fachlichen und technischen Fehlern, Patch Management, Subscription Management, Upgrade Handling. Sollten Sie keine oder eine verzögerte Antwort erhalten oder gar die Begriffe unbekannt sein, dann ist es wahrscheinlich nicht der richtige Partner, mit dem Sie sprechen.

Richtig handeln und sicher «Neustarten»

Bei einem Neustart gilt es die Beteiligten und alle wichtigen Dinge mitzunehmen und sich trotzdem von unnötigem Ballast zu entledigen. Dafür hat sich folgendes Vorgehen bewährt:

Vorgehensmodell

1. Die Blutung stoppen

Irgendetwas hat den Druck so stark wachsen lassen, dass ein Neustart ansteht. Ein Neustart wird sich aber nicht mit den dafür wichtigen Personen planen und durchführen lassen, solange diese in ständigen «Feuerwehrübungen» gebunden sind. Es muss also eine Lösung her, die als quick-fix erlaubt die schlimmsten Auswirkungen abzuwenden, sei es auch nur temporär.

2. Analyse (Systemzustand, Daten inkl. Qualität; Prozesse inkl. Umsysteme, Backlog)

Um handeln zu können tragen Sie relevante Informationen zusammen. Vergessen Sie dabei nicht auch die Datenqualität anzuschauen. Technisch gibt Ihr ServiceNow Upgrade Center Monitor einen Eindruck (auf älteren Releases schauen Sie sich die entsprechenden Upgrade Tabellen an). Wenn Sie jetzt nicht genau verstehen, was das im Detail bedeutet, verstehen Sie warum es nötig ist, dass Sie in-house Expertise brauchen. Beauftragen Sie ein neutrales Review der Umgebung. Keine noch so gut gemeinte Massnahme wird jemals erfolgreich sein können ohne die genaue Kenntnis des Ist Zustandes. Diesen zu erheben, sollte durch eine neutrale Stelle erfolgen. Auch Prozessdokumentation und Deployment Handbuch gehören zu den Informationen, die benötigt werden für eine tragfähige Analyse.

3. Clustering und Priorisierung

Nützlich ist es die gesammelten Informationen zu kategorisieren (weg damit/ behalten und verbessern, möglichst als Scoped App/ zurück zu ootb Standard) und dann Massnahmen zu planen, diese auf einer neuen ServiceNow Plattform umzusetzen. Generell abraten möchte ich davon, alte Update Sets einzuspielen, ohne sie ganz genau analysiert zu haben. Viel des Ärgers, den wir sehen, ist genau darauf zurückzuführen.

4. Neuaufbau und Transition

Nun geht es darum die neue Plattform parallel aufzusetzen (es empfiehlt sich eine weitere Instanz temporär dafür zu verwenden), Integrationen zu Umsystemen und die Funktionalitäten gemäss Priorisierung umzusetzen als – und das ist wichtig – saubere Scoped App. Nur das erlaubt es in Zukunft schnell und ohne viel Aufwand Releasewechsel durchzuführen. Eine dringende Empfehlung ist es ebenfalls ATF Tests für diese Funktionalitäten bereitzustellen. Ist die Konfiguration ausreichend abgeschlossen erfolgt der cut-over. Dafür sind gemäss Priorisierung etwaige Daten übertragen und deren Korrektheit auch im Prozesskontext validiert (wichtig!) worden. Es ist hilfreich im alten System möglichst alle laufenden Prozesse abzuschliessen und neue Prozesse dann im neuen System zu starten. Ein cut-over muss besonders aktiv durch gute Kommunikation und schnell reagierenden Support begleitet werden.

5. Learning für Betrieb

Jeder Neustart wird Fehler aufdecken und Gelegenheiten zum Lernen eröffnen. Insbesondere im Betrieb der Lösung, da hier der Effekt des Neustarts meist auch deutlich sichtbar ist. Genau diese Erfahrungen der ersten Zeit nach dem Neustart sind ein Schatz, in dem sich viele wertvolle Verbesserungspotentiale für die Zukunft finden lassen.

Takeaways

Ein Neustart von ServiceNow erfolgreich durchzuführen, ohne Benutzer und/oder Betrieb zu verärgern ist keine triviale Aufgabe, zumal die Erwartungen durchweg hoch sein werden. Dies allein oder mit den Ressourcen zu bewerkstelligen, die die Ausgangslage verursacht haben ist meist schwierig. Holen Sie sich also Hilfe, achten Sie auf Erfahrung, ein bewährtes Vorgehensmodell und hohe Qualität vor Ort. Und involvieren Sie so eigene Ressourcen langfristig, um zu verhindern, dass das Problem erneut auftritt. Denn sonst wiederholen Sie diese Übung in ein paar Jahren.

- Christian

Diese Webseite verwendet Cookies. Durch die Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Datenschutzinformationen