Foundation, Advanced, Prime: Warum das neue ServiceNow Paketmodell eine kaufmännische Entscheidung ist

Auf den ersten Blick sieht die Umstellung nach einer Fleißaufgabe aus. Eine Tabelle, drei Spalten, links die alten Editionen, rechts Foundation, Advanced und Prime. Wer welches Feature künftig in welcher Stufe bekommt, lässt sich abgleichen. Das dauert einen Nachmittag.
Der Nachmittag ist gut investiert, beantwortet aber die falsche Frage. Denn was sich verändert hat, ist nicht der Funktionsumfang je Stufe. Es ist die Logik, nach der ServiceNow Wert bepreist.
Von Modulen zu Fähigkeiten
Das alte Modell war produktzentriert. Ein Unternehmen kaufte ITSM, dazu vielleicht ITOM und HRSD, jeweils in Standard, Pro oder Enterprise. Die Rechnung war überschaubar: mehr Module, mehr Kosten, mehr Funktionen.
Das neue Modell ist fähigkeitszentriert. KI ist kein Aufpreis mehr, den man später dazubucht, wenn das Budget es hergibt. Sie ist in den Stufen eingebaut. Damit verschiebt sich die Frage von „welche Module brauchen wir“ zu „auf welcher Stufe wollen wir arbeiten“.
Das klingt nach einer Vereinfachung. In der Praxis erhöht es den Einsatz. Wer sich für Foundation entscheidet, entscheidet sich nicht gegen ein Modul, sondern gegen eine Klasse von Automatisierung. Und wer Prime bucht, kauft Fähigkeiten, die im Betrieb erst dann Geld verdienen, wenn Prozesse, Daten und Organisation sie tragen.
Die drei Fehler, die jetzt teuer werden
Erstens: Das Mapping mit der Verhandlung verwechseln. Ein Feature Mapping zeigt, wo man landet, wenn man nichts tut. Es zeigt nicht, was verhandelbar ist. Renewal Termine, Laufzeiten, Übergangsfristen und Nutzungsbindungen sind Bestandteil des Gesprächs. Wer mit einer Feature Tabelle in den Termin geht, verhandelt über Zeilen statt über Konditionen.
Zweitens: Für Fähigkeiten zahlen, die niemand aktiviert. Der teuerste Posten in vielen ServiceNow Verträgen ist nicht die zu niedrige Stufe. Es ist die zu hohe Stufe ohne Adoption dahinter. Now Assist in der Lizenz und ausgeschaltet in der Instanz ist ein reines Kostenereignis. Der Wert entsteht erst, wenn Anwendungsfälle definiert, Daten sauber und Prozesse dafür ausgelegt sind.
Drittens: Die Stufe für die ganze Plattform festlegen statt für die Wertströme. Nicht jeder Bereich braucht dasselbe Niveau. Ein Servicedesk mit hohem Ticketvolumen und wiederkehrenden Anliegen rechtfertigt eine andere Stufe als ein Portfoliomanagement mit dreißig aktiven Nutzern. Wer pauschal entscheidet, subventioniert den einen Bereich mit dem Budget des anderen.
Was vor der Vertragsverhandlung geklärt sein sollte
Eine belastbare Entscheidung braucht drei Zahlen, die selten auf dem Tisch liegen.
Die tatsächliche Nutzung. Nicht die Zahl der lizenzierten Nutzer, sondern die Zahl der aktiven. Rollen, die vor drei Jahren vergeben und nie entzogen wurden, verzerren jede Hochrechnung.
Das Automatisierungspotenzial pro Prozess. Wie viele Vorgänge laufen heute manuell, die eine KI Fähigkeit übernehmen könnte, und was kostet ein solcher Vorgang im Durchschnitt? Ohne diese Zahl ist jede Aussage über den Nutzen einer höheren Stufe eine Meinung.
Die Datenreife. KI Fähigkeiten in ServiceNow greifen auf Wissensartikel, CMDB Einträge und historische Vorgänge zu. Ist diese Basis lückenhaft, liefert auch die höchste Stufe schwache Ergebnisse. Die Stufe kauft man in Minuten, die Datenqualität baut man über Monate.
Der eigentliche Hebel
Das Repackaging ist ein guter Anlass, eine Frage zu stellen, die in vielen Organisationen seit Jahren offen ist: Was hat die ServiceNow Plattform im letzten Geschäftsjahr eingespart oder ermöglicht, und wie ist das belegt?
Unternehmen, die diese Frage beantworten können, führen die Verhandlung aus einer anderen Position. Sie wissen, welche Fähigkeit sich in welchem Bereich rechnet, und sie können die Investition intern begründen, statt sie zu verteidigen.
Unternehmen, die sie nicht beantworten können, entscheiden über eine Stufe, deren Wirkung sie nicht messen. Das ist bei jedem Preismodell ein Nachteil. Bei einem, das Wert über Fähigkeiten definiert, wird es zum strukturellen Problem.
Die Umstellung ist keine Migrationsaufgabe für die Plattformorganisation. Sie ist eine kaufmännische Entscheidung mit technischen Voraussetzungen. Wer sie so behandelt, verhandelt besser und aktiviert später mehr.



