🕒 7 Minuten

Technische Schulden zerstören leise Ihren ServiceNow-ROI — Und Ihre Upgrade-Strategie ist nur eine Liste von Problemen, die Sie nicht lösen

Technische Schulden zerstören leise Ihren ServiceNow-ROI

Sie haben den Health Scan durchgeführt. Sie haben Instance Scan geöffnet. Vielleicht haben Sie sich sogar durch das Upgrade Center geklickt.

Und dann ist nichts passiert.

Nicht, weil Sie die Findings nicht gesehen hätten. Sondern weil es keinen Remediation-Plan gibt. Keine eingeplante Zeit. Keinen Executive Sponsor, der versteht, was diese Findings tatsächlich kosten.

Also liegen sie da. Quartal für Quartal. Und zinsen sich auf.

Dieser Artikel liefert den Business Case dafür, den Abbau technischer Schulden als kontinuierlichen, finanzierten Workstream zu behandeln — nicht als Panikreaktion vor dem nächsten Upgrade.

Sie haben kein Upgrade-Problem. Sie haben ein Schulden-Problem.

Die meisten Führungskräfte, mit denen ich spreche, formulieren ihre ServiceNow-Herausforderung als Upgrade-Herausforderung.

„Wir sind zwei Releases im Rückstand."

„Wir müssen auf Washington DC kommen."

„Wir planen ein Upgrade für Q3."

Das ist nicht das Problem. Das Upgrade ist nur der Moment, in dem das Problem sichtbar wird.

Wie technische Schulden auf ServiceNow tatsächlich aussehen

Es ist die Business Rule, die die Out-of-Box-Assignment-Logik überschreibt, weil jemand 2019 einen Workaround brauchte.

Es ist die UI Policy, die ein Feld deaktiviert, das ServiceNow vor zwei Releases neu gestaltet hat.

Es ist das custom Script Include, das Funktionalität dupliziert, die Flow Designer inzwischen nativ abdeckt.

Es sind die 47 Catalog Items, die niemandem gehören, mit Variable Sets, die auf Tabellen verweisen, die längst umstrukturiert wurden.

Es sind die CMDB-Beziehungen auf Basis benutzerdefinierter Klassen, die kein Discovery-Pattern mehr erkennt.

Nichts davon taucht auf einer Roadmap auf. Aber alles davon taucht beim Upgrade auf.

Warum sie sich schneller aufzinsen, als Sie denken

ServiceNow veröffentlicht zwei Major Releases pro Jahr.

Jedes Release geht davon aus, dass Sie die vorherige Version betreiben — mit weitgehend sauberer, weitgehend Out-of-Box-Konfiguration.

Jede Customization, die OOB-Logik überschreibt, ist ein Divergenzpunkt. Jeder Divergenzpunkt vervielfacht die Testfläche für das nächste Upgrade. Jedes ausgelassene Release fügt eine weitere Schicht der Divergenz hinzu.

Das ist keine lineare Anhäufung. Das ist Zinseszins.

Zwei Releases im Rückstand bedeutet nicht doppelte Arbeit. Es bedeutet vier- bis fünfmal so viel Arbeit — weil sich die Abhängigkeiten stapeln.

Jedes Release, das Sie auslassen, macht das nächste schwieriger

Die Klippe, die Sie bauen

Organisationen, die Upgrades aufschieben, glauben, sie sparen Geld.

Tun sie nicht.

Sie verschieben Kosten in ein einzelnes, massives Ereignis, das ein eigenes Projekt, externe Ressourcen, erweiterte Testzyklen und die volle Aufmerksamkeit des Management erfordert — alles auf einmal.

Ich habe Organisationen gesehen, die für ein einziges Aufhol-Upgrade mehr ausgegeben haben, als drei Jahre kontinuierliche Remediation und inkrementelle Upgrades zusammen gekostet hätten.

Das ist die Klippe. Sie sehen sie erst, wenn Sie bereits fallen.

Die Funktionen, auf die Sie stillschweigend verzichten

Das sind die Kosten, die niemand erfasst.

Jedes Release enthält Funktionen, die Ihre Teams nutzen könnten. Workspace-Verbesserungen. Flow Designer-Erweiterungen. Neue ITSM- oder ITOM-Features. Virtual Agent-Upgrades. Now Assist-Funktionen, die eine aktuelle Release-Baseline voraussetzen.

Wenn Sie zwei Releases im Rückstand sind, können Sie nichts davon nutzen.

Ihr Plattform-Team verbringt seine Zeit damit, den Bestand zu pflegen, anstatt das Nächste zu liefern.

Ihre Fachbereiche beginnen, an der Plattform vorbeizuarbeiten — kaufen Punktlösungen, bauen Schatten-IT auf — weil ServiceNow „das noch nicht kann."

Doch. Kann es. Sie kommen nur nicht dorthin.

Das ist keine Technologielücke. Das ist eine Governance-Lücke.

Configuration over Customization ist eine Governance-Disziplin

Sie haben es auf den Slide Decks gesehen. „Configuration over Customization." Alle nicken.

Dann kommt eine Anfrage aus dem Fachbereich, die Deadline ist eng, und ein Entwickler schreibt ein Custom Script, das Plattformlogik überschreibt — weil es schneller geht.

Das passiert einmal. Dann passiert es fünfzig Mal.

Und plötzlich haben Sie eine Instanz voller Custom Code, den niemand dokumentiert hat, der niemandem gehört und den niemand beim Upgrade anfassen will.

Wo die Overrides passieren

Die üblichen Verdächtigen:

Business Rules, die OOB-Logik umgehen oder überschreiben.
Script Includes, die Funktionalität replizieren, die in Flow Designer oder IntegrationHub verfügbar ist.
UI Policies und Client Scripts, die gegen plattformseitig bereitgestellte UX-Patterns arbeiten.
Benutzerdefinierte Tabellen, die Erweiterungen von OOB-Tabellen hätten sein sollen.
Hardcodierte sys_ids in Scripts. Überall.
Modifizierte OOB Script Includes, UI Pages oder Processors (die Upgrade-Killer).

Warum „Wir brauchten das individuell" im Nachhinein fast nie stimmt

Ich habe dutzende Instanzen auditiert.

In der überwältigenden Mehrheit der Fälle wurde der Custom-Ansatz gewählt, weil das Team die OOB-Funktionalität nicht kannte, keine Zeit hatte, sie zu recherchieren, oder einem Pattern folgte, das vor Jahren von jemandem etabliert wurde, der längst nicht mehr da ist.

Fast nie, weil die Plattform es tatsächlich nicht konnte.

Genau deshalb ist technische Governance keine Option. Sie ist keine Bürokratie. Sie ist das, was Ihre Plattform beherrschbar hält.

Ohne sie fügt jeder Sprint Schulden hinzu. Jeder Entwickler trifft lokale Entscheidungen mit globalen Konsequenzen. Jedes Release wird schwieriger.

Der Abbau technischer Schulden muss ein finanzierter Workstream sein

Hier scheitern die meisten Organisationen.

Sie erkennen die Schulden an. Sie sehen die Health Scan-Findings. Sie stimmen zu, dass es ein Problem ist.

Dann versuchen sie, die Remediation in die bestehende Sprint-Kapazität zu quetschen — neben neuer Feature-Entwicklung und Break-Fix-Arbeit.

Das gewinnt nie. Neue Features gewinnen. Incidents gewinnen. Die Schulden bleiben liegen.

Wie ein kontinuierliches Remediation-Modell aussieht

Reservieren Sie einen festen Prozentsatz der Plattform-Team-Kapazität für den Schuldenabbau. Jeden Sprint. Nicht verhandelbar.

Ich habe gesehen, dass 15–20 % gut funktionieren. Manche Organisationen widmen einen kompletten Sprint pro Quartal.

Die Schlüsselelemente:

Priorisiertes Backlog technischer Schulden, gespeist aus Instance Scan, Health Scan und Upgrade-Preview-Ergebnissen.
Severity-basierte Triage. Nicht alles muss behoben werden. Fokussieren Sie sich auf das, was Upgrades blockiert, Automatisierung beeinträchtigt oder Sicherheitsrisiken erzeugt.
Definition of Done, die OOB-Alignment einschließt. Wenn der Fix neuen Custom Code einführt, ist es kein Fix.
Tracking und Reporting an das Leadership. Der Schuldenabbau muss auf Programmebene sichtbar sein — nicht vergraben im Sprint Board eines Entwicklers.

Wer das sponsern muss (und warum es nicht das Plattform-Team ist)

Plattform-Teams können ihren eigenen Schuldenabbau nicht sponsern. Sie kontrollieren kein Budget. Sie setzen keine Prioritäten. Sie können dafür eintreten. Aber sie können es nicht finanzieren.

Es braucht einen Executive Sponsor — CIO, VP IT oder ITSM Director — der versteht, dass Plattformgesundheit eine strategische Investition ist, keine operativen Kosten.

Wenn das Leadership nur während einer Upgrade-Krise von technischen Schulden hört, haben Sie bereits verloren. Das Gespräch muss quartalsweise stattfinden, verknüpft mit Roadmap-Delivery und Total Cost of Ownership.

Die Fix-Liste — Was Sie ab diesem Quartal tun sollten

Führen Sie Instance Scan und Health Scan durch. Wenn Sie das in den letzten 90 Tagen nicht getan haben, starten Sie hier. Schaffen Sie eine Baseline für Ihre Schulden.
Kategorisieren Sie Findings nach Upgrade-Impact, Sicherheitsrisiko und OOB-Divergenz. Nicht alle Schulden sind gleich. Priorisieren Sie konsequent.
Erstellen Sie ein dediziertes Backlog für technische Schulden. Getrennt von Feature-Arbeit. Getrennt von Incidents. Sichtbar für das Leadership.
Reservieren Sie 15–20 % der Plattform-Team-Kapazität für Remediation. Jeden Sprint. Planen Sie es im Sprint ein. Schützen Sie es.
Etablieren Sie ein Configuration Governance Review für jede neue Entwicklung. Bevor Code geschrieben wird, lautet die Frage: Geht das OOB oder mit unterstützter Konfiguration? Wenn ja, wird Custom Code abgelehnt.
Benennen Sie einen Executive Sponsor. Jemanden, der über Plattformgesundheit genauso berichtet wie über Plattform-Delivery.
Hören Sie auf, Upgrades auszulassen. Finden Sie einen Rhythmus. Zwei Releases pro Jahr mit kontinuierlicher Remediation sind handhabbar. Aufhol-Upgrades nach drei ausgelassenen Releases sind es nicht.

Schluss

Technische Schulden auf ServiceNow sind kein Backlog-Item.

Sie sind ein strategisches Risiko.

Jedes Quartal, das Sie den Abbau aufschieben, zahlen Sie mehr für den Betrieb der Plattform, bekommen weniger von ihr und machen das nächste Upgrade schwieriger.

Die Organisationen, die ihre ServiceNow-Instanz als Produkt behandeln — mit Health-Metriken, Governance und finanzierter Wartung — sind diejenigen, die den ROI tatsächlich realisieren, den der Business Case versprochen hat.

Die anderen bauen eine Klippe.

Hören Sie auf, die Klippe zu bauen.