Das Expansions-Playbook, dem alle folgen
Ihre ITSM-Instanz ist live. Incident, Change, Request Fulfillment. Es funktioniert.
Jetzt will HR mitmachen. Facilities fragt an. Legal hat auf einer Konferenz davon gehört. Procurement hat eine Demo gesehen.
Und Ihr ServiceNow Account Executive baut bereits das Angebot.
Das ist der Moment, in dem die meisten CIOs eine Entscheidung treffen, die sie jahrelang verfolgt. Sie sagen Ja zur Expansion, bevor sie bewiesen haben, dass sie das Bestehende steuern können.
Wie es normalerweise beginnt
Es beginnt mit Erfolg. IT bringt ITSM auf ServiceNow zum Laufen. Die Nutzer nehmen es an. Das Management wird aufmerksam.
Dann sieht jemand aus HR oder Facilities das Portal und sagt: „Das wollen wir auch."
Es fühlt sich nach Bestätigung an. Es fühlt sich nach Momentum an.
Beides ist es nicht. Es ist Nachfrage ohne Sorgfaltspflicht.
Warum es sich beschleunigt
Das kommerzielle Modell von ServiceNow belohnt Expansion. Jedes neue Modul ist eine neue SKU. Jede neue Abteilung ist ein neuer Umsatzstrom für Ihr Account-Team.
Für den CIO ist Expansion ein sichtbarer Erfolg. Es zeigt dem Vorstand, dass die Plattform-Investition skaliert. Es rechtfertigt die ursprünglichen Ausgaben.
Niemand in diesem Raum fragt, ob Sie das Governance-Modell haben, um das zu tragen.
Weil diese Frage es nicht auf die Folie schafft.
Was tatsächlich unter der Haube passiert
Während das Leadership die Roadmap feiert, geht das Plattform-Team unter.
Kein gemeinsames Governance Board
Die meisten Organisationen, die ServiceNow ausweiten, haben kein abteilungsübergreifendes Governance Board.
IT verantwortet ITSM. HR verantwortet HRSD. Facilities verantwortet ihre Scoped App. Jede Gruppe trifft Entscheidungen eigenständig.
Es gibt keine zentrale Instanz, die plattformweite Standards festlegt. Niemand schlichtet widersprüchliche Anforderungen. Niemand sagt Nein.
Das ist keine Lücke. Das ist ein strukturelles Versagen.
Datenstandards fragmentieren sofort
Jede Abteilung, die eingebunden wird, bringt ihr eigenes Vokabular mit.
HR nennt es „Cases." IT nennt es „Incidents." Facilities nennt es „Work Orders." Legal nennt es „Requests." Jede Abteilung hat eine andere Taxonomie für Priorität, Dringlichkeit und Kategorisierung.
Ohne gemeinsame Datenstandards, die vor der Expansion durchgesetzt werden, wird Ihre Reporting-Ebene bedeutungslos. Sie können keine Kennzahlen abteilungsübergreifend konsolidieren. Sie können kein konsistentes Executive Dashboard bauen.
Sie haben eine Plattform mit fünf Abteilungen und fünf Versionen der Wahrheit.
Technische Schulden wachsen im Stillen
Jede neue Abteilung bringt Anpassungen mit. Business Rules. UI Policies. Client Scripts. Scoped Applications ohne Lifecycle-Management-Plan.
Das Plattform-Team erbt all das. Jeder Upgrade-Zyklus wird aufwendiger. Jede Regressionstestfläche wächst.
Niemand erfasst diese Schulden. Niemand modelliert sie. Sie akkumulieren einfach, bis jemand fragt, warum das Upgrade, das früher zwei Wochen dauerte, jetzt drei Monate braucht.
Die kumulativen Kosten, die niemand modelliert
Hier wird Expansion ohne Governance wirklich teuer. Nicht bei der Lizenzierung. Beim organisatorischen Reibungsverlust.
Organisatorische Schulden
Wenn fünf Abteilungen eine Plattform ohne Governance Board teilen, füllt Politik das Vakuum.
HR will, dass ihre Erweiterung priorisiert wird. Facilities fühlt sich ignoriert. IT glaubt, die Plattform gehöre immer noch ihnen. Legal hat dem Datenmodell nie zugestimmt.
Am Ende haben Sie Schatten-Governance. Seitengespräche. Eskalationen an den CIO, die diese Ebene niemals erreichen sollten.
Die Plattform vereint die Organisation nicht. Sie wird zu einem weiteren Streitpunkt.
Technische Schulden
Scoped Apps werden gebaut und dann vergessen. Integrationen werden ohne Dokumentation verdrahtet. Die CMDB, ohnehin fragil, beginnt Daten von Abteilungen aufzunehmen, die Configuration Management nicht verstehen.
Flow Designer Automations vervielfachen sich. Einige sind produktionskritisch. Einige sind Experimente, an deren Erstellung sich niemand mehr erinnert. Niemand hat eine Bestandsaufnahme.
So wird aus einer strategischen Plattform eine Belastung.
Das Konsolidierungsgespräch, das Sie nicht führen wollen
Hier kommt das Endspiel, das niemand einplant.
Irgendwann werden die Schulden sichtbar genug, dass jemand eine Bewertung in Auftrag gibt. Die Bewertung enthüllt, was das Plattform-Team längst wusste: Die Instanz ist nicht steuerbar, die Daten sind unzuverlässig, und der Upgrade-Pfad ist durch Jahre undokumentierter Anpassungen blockiert.
Jetzt führen Sie das Konsolidierungsgespräch. Das Re-Platforming-Gespräch. Das „Wie konnte es so weit kommen"-Gespräch.
Dieses Gespräch kostet zehnmal so viel, wie Governance von Anfang an gekostet hätte.
Wie Governance-Reife vor der Expansion tatsächlich aussieht
Governance ist kein Dokument. Es ist ein Operating Model. Folgendes sollte stehen, bevor auch nur eine einzige neue Abteilung ServiceNow anfasst.
Ein Governance Board mit Durchsetzungskraft
Kein Beratungsgremium. Ein Entscheidungsgremium mit abteilungsübergreifender Vertretung, einer definierten Satzung und der Befugnis, Plattformänderungen zu genehmigen oder abzulehnen.
Dieses Board verantwortet die Roadmap. Es schlichtet Konflikte. Es setzt Standards.
Wenn Ihr Governance Board nicht Nein sagen kann, ist es kein Governance Board.
Gemeinsame Datenstandards über alle bestehenden Module hinweg
Bevor Sie expandieren: Beweisen Sie, dass Sie konsistente Datenstandards in Ihrem bestehenden Footprint einhalten können.
Einheitliche Namenskonventionen. Abgestimmte Taxonomien für Kategorisierung, Priorität und Status. Ein Data-Quality-Framework mit Verantwortlichen und Rechenschaftspflicht.
Wenn Ihre ITSM-Daten inkonsistent sind, wird das Hinzufügen von HRSD-Daten die Situation nicht verbessern.
Definierter Demand-Intake und Priorisierung
Jede Abteilung wird Erweiterungswünsche haben. Jede Abteilung wird glauben, ihrer sei dringend.
Sie brauchen einen einzigen Intake-Prozess. Ein Bewertungsmodell. Ein Backlog, das sichtbar und gemanagt ist.
Ohne das gewinnt die lauteste Abteilung. Das ist keine Governance. Das ist Chaos mit einem Ticketing-System.
Upgrade-Readiness als permanente Fähigkeit
Wenn Ihre aktuelle Instanz nicht innerhalb eines definierten Zeitfensters sauber upgraden kann, sind Sie nicht bereit, Komplexität hinzuzufügen.
Upgrade-Readiness bedeutet: automatisierte Testabdeckung, ein bekanntes Customization-Inventar, dokumentierte übersprungene Updates mit Behebungsplänen und ein Team, das Upgrades als Routine behandelt, nicht als Projekte.
Ein Platform Owner, der auf der richtigen Ebene berichtet
Der Platform Owner darf nicht drei Ebenen unterhalb der IT-Operations vergraben sein.
Diese Rolle braucht Sichtbarkeit zum CIO oder CTO. Sie braucht ein Mandat, das Abteilungen übergreift. Sie braucht Budgethoheit für Plattformgesundheit, nicht nur für Feature-Delivery.
Wenn der Platform Owner das Lieblingsprojekt eines VP nicht zurückweisen kann, ist die Rolle rein symbolisch.
So testen Sie Ihre Bereitschaft unter Druck
Bevor Sie das nächste Modul freigeben, stellen Sie diese fünf Fragen:
- Haben wir ein Governance Board, das in den letzten sechs Monaten tatsächlich eine Anfrage abgelehnt hat?
- Können wir heute ein einziges, konsistentes Executive Dashboard über alle aktuellen ServiceNow-Module hinweg erstellen?
- Wissen wir genau, wie viele Anpassungen in unserer Instanz existieren, und hat jede einzelne einen Verantwortlichen?
- Können wir ein Plattform-Upgrade innerhalb unseres definierten Wartungsfensters abschließen, ohne Notfall-Rollbacks?
- Hat unser Platform Owner die Befugnis, einen abteilungsbezogenen Rollout aus Governance-Gründen zu verzögern?
Wenn Sie bei mehr als zwei Fragen mit Nein geantwortet haben, sind Sie nicht bereit zu expandieren.
Vielleicht sind Sie bereit, die Roadmap zu entwickeln. Aber Sie sind nicht bereit, sie umzusetzen.
Expansion ist nicht der Feind
Lassen Sie mich das klarstellen: ServiceNow ist eine leistungsstarke Enterprise-Plattform. HRSD, CSM, SPM und andere Module können echten Mehrwert liefern.
Aber nur auf einem gesteuerten Fundament.
Die gängige Meinung sagt: Expansion beweist ROI. Die praxiserprobte Realität sagt: Voreilige Expansion ist der Weg, wie Sie ein strategisches Asset in eine Plattform verwandeln, die ihr eigenes Sanierungsprogramm braucht.
Werden Sie langsamer. Steuern Sie, was Sie haben. Bauen Sie das Operating Model auf. Dann expandieren Sie mit Zuversicht, nicht nur mit Ehrgeiz.
