ServiceNow-Initiativen starten oft mit großen Erwartungen.
Doch im Projektalltag zeigt sich ein anderes Bild:
Go-Lives verschieben sich. Anforderungen wachsen unkontrolliert. Verantwortlichkeiten bleiben unklar.
Und sobald Kosten steigen, ohne dass der Nutzen sichtbar wird, kippt die Stimmung.
Kommt dir das bekannt vor?
In den meisten Fällen liegt das Problem nicht an der Plattform.
Es liegt an fehlender Führung, Governance und Struktur rund um die Plattform.
Die typischen Warnsignale in Transformationsprojekten
Typische Warnsignale in ServiceNow-Transformationen
In vielen ServiceNow-Initiativen tauchen immer wieder dieselben Aussagen auf:
- Der Go-Live wurde mehrfach verschoben.
- Anforderungen wachsen schneller, als das Team liefern kann.
- Niemand weiß genau, wie der spätere Betrieb organisiert sein soll.
- Datenqualität und Kosten sind unklar.
- Externe Partner liefern operative Unterstützung – aber keine echte Steuerung.
Diese Warnsignale sind selten Einzelfälle.
Sie sind meist Hinweise auf tieferliegende strukturelle Probleme in Strategie, Governance oder Operating Model.
Wer diese Signale früh erkennt, kann gegensteuern.
Wer sie ignoriert, riskiert, dass aus einer vielversprechenden Initiative ein dauerhaftes Sorgenkind wird.
Problem 1: Strategie Vakuum
Eines der häufigsten Probleme ist ein strategisches Vakuum. Die Plattform wird aufgebaut, bevor klar ist, welche Ziele sie eigentlich unterstützen soll, welche Zielgruppen sie bedienen muss und welchen Beitrag sie zur Unternehmensstrategie leisten soll.
Das Ergebnis: Teams arbeiten auf Verdacht. Entscheidungen werden isoliert getroffen. Die Plattform entwickelt sich technisch weiter, aber ohne belastbare Richtung.
Die Lösung ist eine klare, an der Unternehmens- und IT-Strategie ausgerichtete Plattformvision. Ergänzt wird sie durch eine messbare Roadmap, die Werttreiber identifiziert, Prioritäten setzt und Investitionen transparent macht. So entsteht Orientierung für Management, Fachbereiche und Delivery-Teams gleichermaßen. Statt Aktionismus gibt es einen belastbaren Plan.
Problem 2: Scope Explosion
Das zweite typische Muster ist die Scope-Explosion. Neue Anforderungen kommen ständig hinzu, bestehende Anforderungen werden erweitert, Prioritäten wechseln laufend und das Team verliert zunehmend die Kontrolle.
Der Kern des Problems ist meist fehlendes Demand Management. Wenn nicht klar geregelt ist, wer Anforderungen bewertet, priorisiert und freigibt, setzt sich am Ende nicht der größte Business Value durch, sondern die lauteste Stimme.
Ein wirksamer Gegenansatz ist ein Governance-Modell mit Demand Board, MVP-Fokus und klaren Change-Control-Prozessen. Anforderungen werden dann nicht mehr nach politischem Druck, sondern nach Nutzen, Aufwand und Auswirkungen entschieden. Das reduziert Scope Creep, erhöht die Lieferfähigkeit und bringt Projekte wieder in einen realistischen Takt.
Problem 3: Ressourcen Illusion
Viele Programme starten mit der Annahme, dass die nötigen Rollen „nebenbei“ mitlaufen können. In der Realität bedeutet das: Product Owner, Architekten oder Plattformverantwortliche jonglieren Tagesgeschäft und Transformation gleichzeitig. Das führt fast zwangsläufig zu Verzögerungen, Qualitätsproblemen und hoher Abhängigkeit von externen Partnern.
Die Komplexität von ServiceNow wird dabei häufig unterschätzt. Eine Plattform dieser Art ist kein „Install and Forget“-Werkzeug. Sie braucht Führung, Architektur, Priorisierung und Weiterentwicklung.
Deshalb sind dedizierte Ressourcen entscheidend. Schlüsselrollen brauchen echte Freistellung. Gleichzeitig muss eine Backfill-Strategie sicherstellen, dass das Tagesgeschäft nicht kollabiert. Externe Unterstützung sollte gezielt für Expertise eingesetzt werden – nicht als Ersatz für fehlende interne Steuerungsfähigkeit. Nur so entsteht eine Plattform, die langfristig tragfähig ist.
Problem 4: Betriebs Blackout
Viele Organisationen behandeln die Implementierung als Projekt mit Enddatum. Der Fokus liegt auf dem Build, nicht auf dem späteren Run. Doch genau hier beginnt oft das nächste Problem: Nach dem Go-Live ist unklar, wer welche Verantwortung übernimmt, wie Incidents, Changes und Releases für die Plattform selbst gesteuert werden und wie Innovation in den Regelbetrieb übergeht.
Das ist ein klassischer Betriebs-Blackout.
Der richtige Ansatz beginnt deutlich früher: Der spätere Betrieb muss bereits während der Projektphase mitgedacht und aufgebaut werden. Ein CoEI beziehungsweise ein tragfähiges Plattform-Governance- und Operating-Modell sollte nicht erst nach dem Go-Live entstehen. Ebenso wichtig ist eine klare Übergabe zwischen Build und Run, mit dokumentierten Verantwortlichkeiten und definierten Prozessen. Dadurch wird aus einer einmal eingeführten Lösung eine belastbare, kontinuierlich weiterentwickelbare Plattform.
Problem 5: Kosten Schock
Viele Transformationsinitiativen geraten unter Druck, sobald Fragen zu Kosten, Ressourcenverbrauch und Mehrwert aufkommen. Dann zeigt sich, ob ein belastbarer Business Case existiert – oder nur Hoffnung.
Wenn laufende Kosten wie Lizenzen, Support, Storage oder externe Leistungen nicht von Anfang an transparent gemacht werden, folgt der Kostenschock fast zwangsläufig. Noch kritischer wird es, wenn gleichzeitig kein System existiert, um den tatsächlichen Nutzen der Plattform messbar zu machen.
Die Antwort darauf ist mehr Transparenz und konsequente Value Realization. Dazu gehören ein regelmäßiger Business-Case-Recheck, Value Dashboards mit klaren Kennzahlen und ein aktives Lizenzmanagement, um ungenutzte Lizenzen zu vermeiden. Denn eine einfache Regel gilt immer: Wer den Wert nicht misst, kann ihn später auch nicht überzeugend verteidigen.
Der Behandlungsplan für eine gesunde Plattform
Aus diesen fünf Problemfeldern lässt sich ein klarer Behandlungsplan ableiten:
Plattformstrategie und Roadmap
Eine klar definierte Plattformvision und eine messbare Roadmap schaffen Orientierung für Management, Fachbereiche und Delivery-Teams.
Governance und Demand Management
Ein strukturiertes Governance-Modell mit Demand Board sorgt dafür, dass Anforderungen nach Business Value priorisiert werden – nicht nach Lautstärke.
Klare Rollen und dedizierte Ressourcen
Schlüsselrollen wie Platform Owner, Architect oder Product Owner müssen echte Verantwortung und ausreichend Kapazität haben.
Operating Model und CoEI
Ein Center of Enablement stellt sicher, dass Build, Run und Innovation strukturiert zusammenarbeiten.
Value Realization und Kosten-Transparenz
Value Dashboards, Business-Case-Reviews und aktives Lizenzmanagement machen den tatsächlichen Nutzen der Plattform sichtbar.
Wenn aus der Plattform ein Innovationstreiber wird
Das Ziel einer ServiceNow-Plattform ist nicht einfach, dass sie funktioniert.
Das Ziel ist eine Plattform, die stabil betrieben, kontrolliert weiterentwickelt und messbaren Mehrwert liefert.
Eine gesunde Plattform ist:
Sicher, weil klare Governance und definierte Prozesse Wildwuchs verhindern.
Skalierbar, weil Architektur, Rollen und Operating Model mit den Anforderungen wachsen.
Wertschöpfend, weil Nutzen, ROI und Effizienzgewinne transparent gemacht werden.
Wenn diese Voraussetzungen erfüllt sind, verändert sich die Rolle der Plattform grundlegend.
Sie ist dann nicht mehr nur ein System für Tickets oder Workflows.
Sie wird zum Enabler für moderne Services, Automatisierung und kontinuierliche Verbesserung im gesamten Unternehmen.
