Platform Governance: Verantwortung für Ihre ServiceNow-Plattform, nicht nur Erreichbarkeit
Die meisten Supportangebote für Plattformen reagieren auf Anrufe und E-Mails. Ob die Plattform noch stimmig und gesund ist und mit jedem Release mehr Nutzen bringt, dafür übernimmt kaum jemand die Verantwortung.
Diese Verantwortung übernehmen wir. Dazu gehören klare Zuständigkeiten, ein einziger Eingangskanal für neue Anforderungen und gezielte Arbeit am Zustand der Plattform und an der Release-Bereitschaft neuer Funktionen. In einem festen Rhythmus messen wir außerdem, ob die Plattform ihre Kosten wert ist.
Die Entscheidungen über Ihr Geschäft bleiben bei Ihnen.
Die Plattform ist live, aber Governance und klare Verantwortung fehlen
Admin-Team, Sponsor und Budget sind vorhanden. Meist fehlt aber jemand, der für die Plattform und ihre Governance als Ganzes verantwortlich ist. Deshalb entsteht keine Roadmap, und niemand setzt Standards. Wie viel Nutzen die Plattform bringt, hängt davon ab, wer in diesem Quartal gerade Kapazität hat, und den Überblick über das Ganze behält niemand.
Anforderungen werden in der Reihenfolge ihres Eingangs bearbeitet
Es gibt keinen einheitlichen Eingang, keinen sichtbaren Backlog und keinen Überblick über die gesamte Nachfrage. Durchgesetzt wird die lauteste Anforderung, und auf der Plattform sammeln sich Änderungen statt Best Practice.
Technische Schulden zeigen sich erst beim Upgrade
Die Konfiguration weicht immer weiter vom Standard ab, und Individualentwicklungen häufen sich. Wie groß das Ausmaß ist, fällt erst auf, wenn ein Upgrade, das Tage dauern sollte, Wochen dauert.
Support behebt Symptome
Störungen werden behoben, ihre Ursachen bleiben. Weil vorbeugende Arbeit keine Frist hat, entstehen Behelfslösungen für bekannte Fehler, statt dass die Probleme mit Standardfunktionen nach Best Practice gelöst werden.
Niemand kann sagen, ob es funktioniert
Niemand misst, wie die Plattform genutzt wird. Der Business Case, mit dem sie finanziert wurde, liegt abgeheftet im Ordner und wurde nie wieder geöffnet. In das Verlängerungsgespräch geht man ohne Belege, und verhandelt wird über eine individuell gewachsene statt einer standardisierten Lösung.
Es geht um Verantwortung, nicht um Erreichbarkeit
Bei Platform Governance verantworten wir Zustand, Stimmigkeit und anhaltenden Nutzen Ihrer ServiceNow-Plattform, mit einem benannten Verantwortlichen. Die Plattform wird dabei in einem durchgängigen Plan-Do-Check-Act-Prozess kontinuierlich verbessert.
Was am Markt als Plattform-Management angeboten wird, ist meist Kapazität in Form von Stunden, Tickets und Servicezeiten. Kapazität ist nützlich, aber sie ist nicht dasselbe. Auch eine bestens betreute Plattform kann aus dem Ruder laufen: Undokumentierte Individualentwicklungen häufen sich, die Plattform hängt zwei Releases hinterher, Lizenzen werden bezahlt, aber nicht genutzt, und den Backlog hat seit einem Jahr niemand priorisiert.
Steht für die Reaktionszeit gerade
Stunden, Tickets, Servicezeiten.
Steht für den Zustand der Plattform gerade
Zustand, Stimmigkeit und anhaltender Nutzen.
Entscheidend ist, wofür jemand geradesteht: für den Zustand der Plattform oder nur für die Reaktionszeit.
Was wir übernehmen
Entscheidungen mit klarer Verantwortung
Sie erhalten einen benannten Verantwortlichen und ein schriftliches Entscheidungsprotokoll. Außerdem legen wir offen, welche Entscheidungen wir treffen und welche bei Ihnen bleiben.
Ein Governance-Prozess
Ein klarer Prozess legt fest, wer die Plattform verantwortet, und zeigt, was nötig ist, um diese Verantwortung in Ihrer Organisation zu verankern.
Gebündelte Nachfrage
Alle Anforderungen laufen über einen Eingang, egal wer fragt. Der Backlog ist sichtbar, die Priorisierungsgrundlage können Sie einsehen und hinterfragen.
Nachhaltiger Plattformzustand
Wir bewerten den Ausgangszustand, führen ein Register technischer Schulden, achten auf Release-Disziplin und geben eine klare Einschätzung zur Upgrade-Bereitschaft.
Messbarer Nutzen
Wir erheben Ausgangswerte, prüfen sie in einem festen Rhythmus und holen den ursprünglichen Business Case wieder aus dem Ordner auf den Tisch.
Ein priorisierter Backlog für den größten Geschäftsnutzen
Sobald eine Plattform live ist, gehen Anforderungen von vielen Seiten ein: von Anwendern, Prozessverantwortlichen, Projektteams und Prüfern, aber auch von Anbietern, die Funktionen ausliefern, um die Sie nicht gebeten haben. Fehlt ein einheitlicher Eingang, hat das drei Folgen.
Gearbeitet wird in der Reihenfolge des Eingangs statt nach Nutzen.
Weil niemand die gesamte Nachfrage überblickt, beruht jedes Gespräch über Kapazitäten auf Schätzungen.
Es sammeln sich Änderungen an, die niemand bewusst entschieden hat.
Ein Eingangskanal
Einen einzigen Eingangskanal, egal wer fragt
Mindestbeschreibung
Eine Mindestbeschreibung für jede Anforderung, damit sich Anforderungen tatsächlich miteinander vergleichen lassen
Triage
Einen Triage-Schritt, der Fehler, Änderungswünsche und neue Funktionen voneinander trennt
Priorisierungsgrundlage
Eine Priorisierungsgrundlage, die Sie hinterfragen können
Sichtbarer Backlog
Einen sichtbaren Backlog
Eine Rückmeldung bei Ablehnung
Eine klare Rückmeldung zu Anforderungen, deren Ablehnung wir empfehlen, denn stillschweigend übergangene Anforderungen führen zu Schattenarbeit
Wird in einem Backlog nie etwas abgelehnt, ist er nicht priorisiert.
Zu dem, was Sie einkaufen, gehört auch jemand, der bereit ist, von manchen Vorhaben abzuraten.
Was wir verantworten und was bei Ihnen bleibt
Trifft ein Managed Service alle Entscheidungen, macht er Sie abhängig. Trifft er keine, ist er eine Ticket-Warteschlange. Deshalb legen wir die Aufteilung hier offen.
Was das Geschäft braucht und was es wert ist
YouSie
Welche Arbeit finanziert wird und in welcher Reihenfolge
YouSie, auf unsere Empfehlung
Ob eine Änderung architektonisch tragfähig ist
UsWir, schriftlich, und Sie können uns überstimmen
Konfiguration oder Individualentwicklung
UsWir, dokumentiert mit Begründung
Ob und wann ein Upgrade erfolgt
YouSie, auf unsere Empfehlung
Wer worauf zugreifen darf
YouSie entscheiden, wir gestalten es
Was ins nächste Release kommt
TogetherGemeinsam, in einem vereinbarten Rhythmus
Ob ein Risiko akzeptiert wird
YouSie, immer
Jede Architekturempfehlung dokumentieren wir schriftlich mit Begründung. So lässt sich eine Entscheidung später überprüfen, ohne sie von vorn diskutieren zu müssen. Das betrifft Entscheidungen zum führenden System, zum Integrationsmuster und zu Templates. Für Ihre Rückmeldung dazu vereinbaren wir vertraglich eine Reaktionszeit, denn verzögerte Entscheidungen sind ein Risiko für die Umsetzung und nicht bloß eine Unannehmlichkeit.
Wenn Sie uns überstimmen, halten wir auch das fest,
zusammen mit unserer Einschätzung, welche Kosten das später verursacht. Das ist keine Drohung: Auf diese Weise bleibt ein Entscheidungsprotokoll nützlich.
Not sure who owns your platform today?
We will tell you what state it is actually in.
Ein Scan liefert Befunde. Befunde sind kein Plan.
ServiceNow stellt dafür gute Anwendungen bereit. HealthScan gleicht eine Instanz mit Best-Practice-Definitionen ab und zeigt, wie weit sie davon abweicht. Erfasst werden dabei nur Konfigurations-Metadaten.
Scan
Instance Scan findet Abweichungen, darunter ungenutzten Code und ineffiziente Abfragen.
Befunde
Zu den HealthScan-Kategorien gehört Upgradeability. Die Prüfung „Differs from baseline“ erfasst dort unter anderem Business Rules, Script Includes und Client Scripts.
Einschätzung
Ein Datensatz kann schon dann als vom Standard abweichend markiert werden, wenn ihn jemand ohne Änderung geöffnet und gespeichert hat. Die Regel dahinter ist eindeutig: Wer ihn anfasst, übernimmt ihn. Es geht deshalb nicht darum, jede Abweichung zu beseitigen. Für jeden Befund entscheiden wir, ob die Individualentwicklung beabsichtigt und noch richtig ist, überholt oder versehentlich entstanden. Jede dieser drei Antworten erfordert eine andere Maßnahme.
Register
Wir pflegen eine Bewertung des Ausgangszustands und ein Register technischer Schulden, in dem veraltete Individualentwicklungen, Altintegrationen, ungenutzte Konfigurationsartefakte und redundante Workflows erfasst sind. Dazu kommt eine priorisierte Übersicht der Bereinigungsarbeiten, die wir regelmäßig überprüfen, statt sie abzuheften.
Wer ihn anfasst, übernimmt ihn.
Genau diese Einschätzung ist der Service. Bei der Prüfung produktiver Instanzen finden wir Funktionen, die installiert, aktiv und auf dem neuesten Stand sind, für die aber nichts veröffentlicht wurde, was sich tatsächlich steuern ließe. Aktiv ist nicht gleich wirksam. Diesen Unterschied zu erkennen, ist die Aufgabe, für die Sie einen Plattformverantwortlichen bezahlen.
Vorbeugende Arbeit hat keine Frist.
Aus einer schlecht indizierten Tabelle, einer ineffizienten Business Rule oder einer veralteten Schnittstelle wird irgendwann eine Störung, nur eben nie heute. Vorbeugend gearbeitet wird nur, wenn jemand dafür verantwortlich ist.
Der Kalender hat sich verschoben und damit auch Ihre Frist
ServiceNow veröffentlicht zwei Haupt-Releases pro Jahr und unterstützt jeweils die aktuelle und die vorherige Release-Familie. Wer mit seiner Instanz außerhalb dieses Zeitfensters liegt, erhält keine Patches und Hotfixes mehr. Damit wird aus einer Upgrade-Frage eine Sicherheitsfrage.
ServiceNow hat den Zeitplan für die Haupt-Releases verschoben, und die Frist, bis zu der Sie auf einer unterstützten Version sein müssen, ist näher gerückt. Beruht Ihre Upgrade-Planung noch auf dem alten Rhythmus, bleibt Ihnen weniger Zeit, als Sie denken.
Außerdem ist hier eine echte Entscheidung gefragt, keine Best Practice.
Ein Upgrade pro Jahr
Stört weniger, lässt aber technische Schulden wachsen.
Ein Upgrade nach jedem Release
Bedeutet kleinere Änderungen pro Schritt, verlangt aber stärkere Governance und bessere Testabdeckung.
Beides ist legitim. Welche Option passt, hängt von Ihrer Kapazität und Ihrer Bereitschaft zur Veränderung ab. Wichtig ist, dass jemand diese Wahl bewusst trifft und nicht aus Gewohnheit.
Bei der Bewertung des Ausgangszustands gleichen wir Ihren Release-Stand mit dem aktuellen offiziellen Release-Kalender ab. Dieser Zeitplan ändert sich, und wer nach dem Rhythmus des Vorjahres plant, hat kein Terminproblem, sondern ein Sicherheitsrisiko.
Nachweisen, dass die Plattform ihre Kosten noch wert ist
Für jede Plattform steht irgendwann ein Verlängerungsgespräch an. Die meisten dieser Gespräche werden ohne Belege geführt.
Wir machen den Nutzen der Plattform wieder sichtbar und erheben dafür Ausgangswerte, die wir in einem festen Rhythmus überprüfen. Im Verlängerungsgespräch zählen dann Belege aus Ihrer eigenen Instanz und nicht ein Prozentwert, den sich jemand ausgedacht hat.
Nachfrage
Umsetzung
Zustand
Upgrade-Bereitschaft
Nutzung
Nutzen
Governance
Wir sagen Ihnen, welches von beiden.
Eine hohe Quote an Notfalländerungen zum Beispiel deutet auf ein Governance-Thema hin, nicht auf ein Kapazitätsproblem. Wer das weiß, reagiert anders darauf.
Zwei Dinge tun wir nicht: denselben Nutzen doppelt zählen und gesparte Zeit als gespartes Geld ausweisen. Setzt die Plattform Zeit frei, ist das ein realer operativer Effekt. Zu Geld wird diese Zeit aber erst, wenn dadurch Kosten wegfallen oder die frei gewordene Kapazität für etwas Wertvolles genutzt wird.
So beginnen die meisten dieser Gespräche.
Ein Implementierungspartner hat seine Arbeit abgeschlossen oder ein Vertrag ist ausgelaufen, und nun muss jemand die Plattform übernehmen.
- 01
Herausfinden, was tatsächlich da ist
Wir erfassen, was installiert, lizenziert, konfiguriert, individuell entwickelt und integriert ist und wofür bezahlt wird, ohne dass es genutzt wird. Bevor wir weitere Funktionen aktivieren, gleichen wir den installierten Stand mit dem tatsächlich Gekauften ab.
- 02
Zugriffe ordnen
Wir klären, welche Benutzerkonten, Rollen und Umgebungen es gibt und wer Administratorrechte hat, die nie jemand geprüft hat. Ohne klare Verantwortung geraten Berechtigungen schneller außer Kontrolle als fast alles andere. Für mehrere Gesellschaften gestalten wir Filter auf Gesellschaftsebene, Access Control Lists und eine übergreifende Rollenverwaltung, einschließlich der Anbindung der Gruppen.
- 03
Den Eingangskanal einrichten
Damit neue Anforderungen nicht mehr ungeordnet eintreffen, während wir noch klären, was wir übernommen haben.
- 04
Den Zustand bewerten
Und bestätigen, wo Sie im unterstützten Release-Fenster stehen.
- 05
Die Entscheidungsrechte benennen
Vor der ersten Meinungsverschiedenheit und nicht danach.
- 06
Dann die Schulden angehen
Erst stabilisieren, dann verbessern.
- 07
Platform Governance etablieren
Einen Prozess aufsetzen, der die Plattform kontinuierlich verbessert.
Übernimmt ein neuer Dienstleister eine Plattform, stellt er meist fest, dass sie in einem schlechteren Zustand ist, als der Kunde angenommen hat. Wir sagen Ihnen, was wir vorfinden.
Dieses Gespräch ist einmal unangenehm, nützt Ihnen aber dauerhaft.
Ihre Kompetenzen stärken, nicht Ihre Abhängigkeit
Gute Plattformverantwortung erkennen Sie daran, dass Sie sie wieder selbst übernehmen könnten.
Für einen laufenden Service ist das eine ungewöhnliche Aussage, und wir meinen sie praktisch, nicht sentimental. Führt ein Managed Service dazu, dass Sie Ihre eigenen Plattformentscheidungen nicht mehr treffen können, hat er Ihr Risiko nicht gesenkt, sondern nur verlagert.
Deshalb arbeiten wir mit Ihnen zusammen und nicht als Blackbox. Wir pflegen die Dokumentation laufend während der Arbeit, statt sie am Ende nachzuschreiben. Außerdem benennen wir die Aufgaben, die Sie intern verantworten sollten, und unterstützen Ihre Mitarbeiter dabei, sie zu übernehmen.
Das verlangt kein Vertrag von uns. Aber wenn Sie Ihre Plattform ohne uns nicht administrieren können, hat sie Ihnen nie wirklich gehört.
Eine klare Grenze erspart allen ein vergebliches Gespräch.
Es ist kein Application Support mit festem Umfang
Soll ein festgelegter Umfang zuverlässig laufen und bei einem Ausfall wiederhergestellt werden, ist Solution Support die richtige Wahl. Dieses Angebot passt besser und ist wahrscheinlich günstiger.
Es ist nicht die Gestaltung Ihres Operating Models
Ist noch offen, wer die Plattform verantworten soll, welche Rollen und Entscheidungsrechte nötig sind oder ob Sie ein Center of Excellence brauchen, beginnen Sie mit Operating Model Design. Platform Governance setzt die Antwort darauf im laufenden Betrieb um.
→ Operating Model Design
Es ist keine Governance für KI
Für die Steuerung der KI auf Ihrer Plattform ist Governance as a Service zuständig. Dafür nutzen wir AI Control Tower.
Und es ist kein Kapazitätsvertrag
Stundenkontingente oder eine Tabelle mit Reaktionszeiten verkaufen wir nicht. Sollen Sie vor allem veröffentlichte Service Levels vergleichen, sind wir möglicherweise nicht der richtige Partner. Das sagen wir lieber gleich.
Decisions, not status reports.
Ein benannter Verantwortlicher
Jemand, der für Ihre Plattform geradesteht, sie kennt und bei ihr bleibt.
Ein vereinbarter Rhythmus
In einem regelmäßigen Review besprechen wir Zustand, Nachfrage, Upgrade-Stand und Nutzen. Am Ende stehen Entscheidungen und kein Statusbericht.
Ein gepflegter Backlog
Für Sie sichtbar und auf einer Grundlage priorisiert, die Sie hinterfragen können.
Berichte, mit denen Sie arbeiten können
In unserer eigenen Projektarbeit setzen wir KI ein, etwa für automatisch erstellte Statusberichte und für Gesprächsprotokolle, die Entscheidungen, Updates und Probleme getrennt ausweisen. Das macht die Dokumentation vollständiger und einheitlicher: Weniger geht unbemerkt verloren, und erfahrene Spezialisten verwenden ihre Zeit für fundierte Einschätzungen, statt nachträglich zu rekonstruieren, was passiert ist.
Umfang, Rhythmus und kommerzielle Ausgestaltung legen wir für jeden Kunden einzeln fest und vereinbaren sie mit Ihnen. Eine veröffentlichte Tabelle würde zu niemandem passen.
Somebody answerable for the state of the platform.
Verantwortlich, nicht nur erreichbar
Die meisten Plattform-Services verkaufen Reaktionszeiten. Bei uns erhalten Sie jemanden, der für den Zustand der Plattform geradesteht.
Sie behalten die Kontrolle
Wie die Entscheidungsrechte verteilt sind, legen wir offen, und Sie können uns überstimmen.
Unsere Unabhängigkeit ist vertraglich festgehalten
Für jede wesentliche Funktion dokumentieren wir das empfohlene führende System und die Integrationsgrenze, auch wenn ein bestehendes System oder das Produkt eines anderen Anbieters für Sie die bessere Lösung ist. Dazu verpflichten uns unsere Verträge. Gerade bei einem laufenden Service zählt diese Klausel mehr als sonst, denn dort verdient man am leichtesten, indem man zu allem Ja sagt.
Erfahrene Spezialisten, nah an Ihrer Plattform
Ihre Plattform betreuen Spezialisten, die seit Jahrzehnten in Plattform-, Prozess- und Projektarbeit tätig sind, und keine First-Level-Warteschlange. Das ist bewusst so organisiert: Bei einem laufenden Service muss der Spezialist, der weiß, warum Ihre Plattform so funktioniert, wie sie funktioniert, auch im vierzehnten Monat noch dabei sein.
Wir vereinbaren Zusagen, statt sie zu veröffentlichen
Service Levels, Servicezeiten und Kennzahlen richten wir an Ihrem Umfang, Ihrem Risiko und Ihrem Arbeitsrhythmus aus und halten sie anschließend im Vertrag fest. Eine veröffentlichte Tabelle liefert Zahlen, eine vereinbarte ist eine Zusage.
Finden Sie heraus, in welchem Zustand Ihre Plattform wirklich ist.
Ob Sie eine Plattform übernommen haben oder sich niemand so recht für sie zuständig fühlt: Zeigen Sie sie uns. Danach wissen Sie, was wir vorfinden, womit wir beginnen würden und ob Sie uns überhaupt brauchen.
Platform Governance
Ein klarer Prozess, mit dem Ihre Plattform dauerhaft an Best Practice ausgerichtet bleibt.
Plattformverantwortlicher (Platform Owner)
Verantwortlich für die Plattform als Produkt, von der Roadmap über die Standards bis zu Zustand und Kosten.
Instanz
Ihre eigene Kopie der Plattform.
Technische Schulden
Aufgeschobene oder auf die Schnelle erledigte Arbeit, deren Korrektur später mehr kostet.
Differs from baseline
Ein Datensatz, der vom Auslieferungsstand des Anbieters abweicht, unabhängig davon, ob er bewusst geändert wurde.
Upgrade-Fähigkeit (Upgradeability)
Wie gut die Plattform das nächste Release des Anbieters übernehmen kann, ohne dass Fehler entstehen.
Release-Familie
Eine Version des Anbieters mit ihren Patches. ServiceNow unterstützt die aktuelle und die vorherige.
Hypercare
Intensive Betreuung für einen festgelegten Zeitraum direkt nach dem Go-live.
Entscheidungsrechte
Wer welche Entscheidung treffen darf, im Voraus vereinbart.
Access Control List
Die Regeln, die festlegen, wer was sehen und tun darf.
Führendes System
Das System, das die maßgebliche Fassung bestimmter Daten führt.
The questions buyers ask us.
Was ist ServiceNow Plattform-Management?
›
Plattform-Management bedeutet, eine laufende ServiceNow-Plattform so zu betreuen, dass sie stimmig und gesund bleibt und ihre Kosten wert ist. In der Praxis ist jemand für die Entscheidungen verantwortlich, und neue Anforderungen laufen über einen einzigen Weg. An technischen Schulden und an der Upgrade-Bereitschaft wird gezielt gearbeitet, nicht erst im Notfall. Und jemand kann Ihnen sagen, ob die Plattform noch leistet, wofür sie gekauft wurde. Support dagegen sorgt dafür, dass ein vereinbarter Umfang weiterläuft, wenn etwas ausfällt.
Was ist der Unterschied zum ServiceNow Support?
›
Support reagiert, wenn etwas nicht funktioniert. Wer die Plattform verantwortet, steht dagegen für ihren Zustand gerade. Auch eine gut betreute Plattform kann aus dem Ruder laufen: Undokumentierte Individualentwicklungen sammeln sich an, die Plattform hängt zwei Releases hinterher, bezahlte Lizenzen bleiben ungenutzt, und den Backlog priorisiert niemand. Wollen Sie einen festgelegten Umfang am Laufen halten, ist Solution Support die bessere und wahrscheinlich günstigere Lösung. Auch das sagen wir Ihnen.
Verlieren wir die Kontrolle über unsere eigene Plattform?
›
Nein. Damit Sie das prüfen können, legen wir die Aufteilung offen. Bei Ihnen liegt die Entscheidung darüber, was das Geschäft braucht, was in welcher Reihenfolge finanziert wird, wer worauf zugreifen darf, ob und wann ein Upgrade erfolgt und ob ein Risiko akzeptiert wird. Wir entscheiden, ob eine Änderung architektonisch tragfähig ist und ob etwas konfiguriert oder individuell entwickelt werden sollte. Diese Entscheidungen halten wir mit Begründung schriftlich fest. Sie können uns überstimmen, und auch das dokumentieren wir.
Was passiert, wenn wir Ihrer Empfehlung nicht folgen?
›
Dann gilt Ihre Entscheidung. Wir dokumentieren, was wir empfohlen haben, wofür Sie sich entschieden haben und welche Folgen wir erwarten. Es geht dabei nicht darum, später recht zu behalten. Das Entscheidungsprotokoll bleibt so nützlich, wenn in achtzehn Monaten jemand fragt, warum die Plattform so funktioniert, wie sie funktioniert.
Können Sie eine Plattform übernehmen, die ein anderer Partner gebaut hat?
›
Das ist der häufigste Einstieg. Zuerst klären wir, was tatsächlich vorhanden ist: was installiert, lizenziert, konfiguriert, individuell entwickelt und integriert ist und wofür bezahlt wird, ohne dass es genutzt wird. Danach ordnen wir Zugriffe und Berechtigungen, denn ohne klare Verantwortung geraten sie schneller außer Kontrolle als fast alles andere. Anschließend richten wir einen Eingangskanal ein, damit neue Anforderungen nicht mehr ungeordnet eintreffen, bewerten den Ausgangszustand und bestätigen, wo Sie im unterstützten Release-Fenster stehen. Eine Übernahme bringt meist Befunde zutage, mit denen der Kunde nicht gerechnet hat. Wir sagen Ihnen, was wir finden.
Wie oft müssen wir ServiceNow upgraden?
›
ServiceNow veröffentlicht zwei Hauptversionen pro Jahr und unterstützt jeweils die aktuelle und die vorherige Release-Familie. Damit Sie weiterhin Patches und Hotfixes erhalten, brauchen Sie in der Praxis mindestens ein Upgrade pro Jahr. 2026 haben sich der Release-Zeitplan und die Frist für unterstützte Versionen verschoben. Wenn Ihre Planung auf dem alten Rhythmus beruht, ist Ihr Zeitfenster enger als bisher. Sie haben eine echte Wahl: Ein Upgrade pro Jahr stört weniger, lässt aber technische Schulden wachsen. Ein Upgrade nach jedem Release bringt kleinere Änderungen, stellt aber höhere Anforderungen an Governance und Testabdeckung.
Wie messen Sie, ob die Plattform Nutzen bringt?
›
Zu Beginn erheben wir Ausgangswerte, die wir dann in einem festen Rhythmus überprüfen. Dazu gehören offene Anforderungen und ihr Alter, ausgerollte Änderungen und der Anteil der Notfälle darunter, offene kritische Befunde und ihr Trend, die Zahl der Releases, die Sie im Rückstand sind, das Verhältnis aktiver zu lizenzierten Nutzern und alles, was laut ursprünglichem Business Case besser werden sollte. Diese Werte stammen aus Ihrer eigenen Instanz. Sie dienen als Ausgangs- und Review-Werte und sind keine zugesagten Ergebnisse. Gesparte Zeit zählen wir nicht als gespartes Geld, solange Sie nicht sagen können, was mit der frei gewordenen Kapazität geschieht. An genau dieser Annahme scheitern die meisten Business Cases für Plattformen, ohne dass es jemand bemerkt.
Welche Service Levels und Servicezeiten bieten Sie?
›
Diese vereinbaren wir mit Ihnen. Umfang, Rhythmus, Service Levels und kommerzielle Ausgestaltung richten sich nach Ihrer Plattform und Ihrem Risikoprofil und werden anschließend im Vertrag festgehalten. Eine veröffentlichte Tabelle passt bestenfalls zufällig zu Ihrem Geschäft. Verlangt Ihr Einkauf einen Vergleich standardisierter, veröffentlichter Service Levels, ist ein großer Support-Anbieter für Sie möglicherweise die bessere Wahl. Das sollte früh geklärt werden.