ServiceNows harter Test ist der abgeschlossene Fall, nicht die KI-Antwort

Zusammenfassung

• Der technische Wert von ServiceNow sollte an der akzeptierten Lösung eines realen Falls, Vorfalls oder einer Anfrage gemessen werden, nicht an der sprachlichen Flüssigkeit einer generierten Antwort. Die Plattform kann Ticketstatus, CMDB-Kontext, Workflow-Regeln, Integrationen, Zugriffskontrollen, Audit-Logs, Now Assist und KI-Agenten verbinden, doch jede dieser Ebenen kann auch eine Fehlerquelle darstellen: veraltete Konfigurationsdaten, falsche Zuweisung, verdeckte Berechtigungsinkongruenz, Integrationstimeout, doppelter Vorfall, vorzeitige Schließung, halluzinierte Empfehlung oder ein wiedereröffneter Fall, der die ursprüngliche Lösung als unvollständig entlarvt.
• Die öffentliche Evidenz stützt eine eingeschränkte Behauptung. ServiceNow verfügt über ausgereifte Mechanismen für Fall-Workflows, Vorfalllebenszyklusstände, Nachverfolgung wiedereröffneter Vorfälle, CMDB-Zustand, Integration Hub, Fehlerbehandlung im Flow Designer, Workflow Data Fabric, Zugriffskontrollen, Audit-Protokollierung und Upgrade-Konfliktmanagement. Diese Funktionen sind relevant für die Zuverlässigkeit, weil sie Service-Arbeit in gesteuerte Zustandsübergänge statt in lose Chats verwandeln. Sie beweisen nicht, dass ein Käufer niedrigere Kosten oder eine schnellere Lösung erzielen wird. Die Prozessgestaltung des Kunden, die Datenhygiene, die Qualität der Partnerimplementierung, die Zuverlässigkeit externer Systeme und die Lizenzentscheidungen bleiben ausschlaggebend.
• Der wirtschaftliche Beleg ist stark, aber nicht selbstbeweisend. ServiceNow meldete in seinem Geschäftsbericht (Form 10-K) 2025 einen Umsatz von 13,278 Milliarden US-Dollar, darunter 12,883 Milliarden US-Dollar an Abonnementumsätzen, sowie eine Verlängerungsrate von 98 Prozent für jedes der Jahre 2025, 2024 und 2023. Im ersten Quartal 2026 meldete das Unternehmen 3,671 Milliarden US-Dollar an Abonnementumsätzen und verbleibende Leistungsverpflichtungen von 27,7 Milliarden US-Dollar. Diese Zahlen zeigen eine große Unternehmensnachfrage nach einer Workflow-Plattform. Sie beweisen nicht, dass KI-Agenten, CMDB-Automatisierung oder systemübergreifende Fallschließung die Arbeit verringern, wenn Implementierung, Überwachung, Token-Nutzung, Upgrades und Integrationswartung eingerechnet werden.

Der abgeschlossene Fall ist der Prüfstein

ServiceNow zu überbewerten, fällt am leichtesten, wenn man es wie einen Textgenerator bewertet. Ein Benutzer stellt eine Frage, Now Assist fasst den Vorfall zusammen, ein KI-Agent schlägt den nächsten Schritt vor, und die sichtbare Antwort wirkt kompetent. Das reicht nicht. In den Betriebsumgebungen, in die ServiceNow hineinverkauft, ist die Antwort nur ein Ereignis in einer längeren Kette. Die Anfrage muss klassifiziert werden. Der betroffene Dienst oder das Asset muss identifiziert werden. Der Anrufer muss die richtigen Berechtigungen haben. Der relevante Knowledge-Artikel muss weiterhin gültig sein.

Der Vorfall oder Fall muss an die richtige Gruppe geleitet werden. Externe Systeme müssen möglicherweise abgefragt oder aktualisiert werden. Eine Genehmigung kann erforderlich sein. Die Lösung erfordert vielleicht einen Änderungsbeleg. Der Lösungsbericht muss erklären, was unternommen wurde. Der Fall muss schließen, ohne sofort wiedereröffnet zu werden.

Daher ist der nützlichste Test für ServiceNow ein abgeschlossener Fall, der geschlossen bleibt. Die Now Platform zählt, wenn sie Kontext, Befugnisse und Nachweise über Übergaben hinweg bewahrt. Ein Service Desk, der Tickets schnell schließt, indem er Komplexität unterdrückt, hat die Lösung nicht automatisiert; er hat ungelöste Arbeit versteckt. Ein Kundendienstfall, der eine höfliche Antwort generiert, während das Abrechnungs-, Berechtigungs- oder Bestandssystem weiterhin falsch ist, hat die Kosten nicht gesenkt; er hat die Kosten auf den nächsten Kontakt verschoben.

Ein Sicherheits- oder Betriebsworkflow, der eine KI-Anregung das falsche Datensatz aktualisieren lässt, hat die Produktivität nicht verbessert; er hat das Berechtigungsmodell zum Teil des Vorfalls gemacht.

ServiceNows eigene Produktsprache deutet auf die Breite des Anspruchs hin. Das Unternehmen sagt, die ServiceNow AI Platform verbinde KI, Daten und Workflows auf einer Plattform, und sein Geschäftsbericht 2025 beschreibt eine cloudbasierte Plattform, die Workflow-Anwendungen in den Bereichen Technology, CRM and Industry, Core Business sowie Creator and Other ermöglicht (ServiceNow 2025 Form 10-K). Die ITSM-Produktseite sagt, ITSM verbinde Vorfall-, Problem-, Änderungs- und Anforderungsmanagement auf einer einzigen KI-Plattform (ServiceNow ITSM). Diese Breite ist sowohl der Punkt als auch das Risiko. ServiceNow ist nicht nur ein Ticketformular. Es ist ein Ort, an dem Unternehmensarbeit als Zustand, Daten, Berechtigungen und Aktionen abgebildet wird.

Die nützliche Frage ist daher eng: Wenn eine Anfrage ins System gelangt, kann ServiceNow genügend Wahrheit darum herum bewahren, um zu entscheiden, was als Nächstes geschehen soll? Die Antwort hängt weniger von einer KI-Funktion ab als von der Qualität der zugrunde liegenden Aufzeichnungen. Eine generierte Antwort ohne verlässlichen Vorfallzustand, aktuellen CMDB-Kontext, korrekte ACL, funktionierende Integration und beobachtbaren Workflow ist nur ein plausibler Satz. Ein weniger beeindruckender Workflow, der Zustand und Nachweise bewahrt, kann weitaus wertvoller sein.

Was ServiceNow tatsächlich besitzt

ServiceNow besitzt die Plattform, ihre Anwendungen, ihre Dokumentation, ihr Release-Modell, ihre Cloud-Service-Verpflichtungen und die Produktoberfläche rund um Now Assist, AI-Agenten, Workflow Data Fabric, CMDB, ITSM, CSM, Integration Hub, Flow Designer und viele andere Module. Es besitzt nicht die Prozessreife des Kunden, die Datenqualität, die Service-Taxonomie, das Cloud-Estate, den Endpunktbestand, die HR-Daten, die Abrechnungssysteme, den Identitätsanbieter, die Überwachungswerkzeuge, den Managed-Service-Partner, die Alt-Workflow-Ausnahmen oder jedes Drittanbietermodell und jeden Konnektor, der in einer Bereitstellung verwendet wird.

Diese Grenze ist keine defensive Fußnote. Sie ist der wirtschaftliche Kern des Produkts. ServiceNow verkauft eine Möglichkeit, Arbeit über Systeme hinweg zu koordinieren, die nicht gemeinsam entworfen wurden. Wenn die Plattform genügend Kontext aus diesen Systemen aufnehmen und Richtlinien konsistent anwenden kann, reduziert sie Koordinationskosten. Wird die Plattform jedoch zu einer weiteren Schicht von Zuordnungen, Ausnahmen und veralteten Datensätzen, kehren die Kosten in Form von Implementierungsdienstleistungen, Integrationswartung, falscher Lenkung, manueller Nachprüfung und Plattform-Governance zurück.

Der Geschäftsbericht (Form 10-K) 2025 des Unternehmens ist offen in Bezug auf Implementierungsrisiken. Er sagt, dass Geschäfts-, Integrations-, Migrations-, Compliance- und Sicherheitsanforderungen des Kunden sowie Fehler von ServiceNow, Partnern oder Kunden Implementierungen verzögert, ineffizient oder erfolglos machen können und dass erfolglose oder kostspielige Implementierungen Verlängerungen und den Ruf beeinträchtigen können (ServiceNow 2025 Form 10-K). Das ist der richtige Risikofaktor für diesen Artikel, denn es geht nicht darum, ob ServiceNow Funktionen hat. Es geht darum, ob der Käufer diese Funktionen in verlässliche Betriebspraxis umsetzen kann.

Derselbe Bericht beschreibt die Plattformarchitektur von ServiceNow als eine, die KI, Daten und Workflows integriert, weist aber auch auf wachsende Kosten hin, um Abonnementangebote, regulierte Märkte, Cloud-Dienste Dritter und Datenspeicheranforderungen zu unterstützen. Das ist für Käufer von Bedeutung, denn der Plattformwert von ServiceNow entsteht teilweise durch Zentralisierung. Zentralisierung bedeutet nicht, dass Vereinfachung automatisch erfolgt. Es bedeutet, dass mehr Arbeit unter einen Betriebsvertrag fällt.

Der Käufer gewinnt eine gemeinsame Workflow-Schicht, akzeptiert aber auch eine Abhängigkeit von der Release-Kadenz, der Lizenzstruktur, dem Partnernetzwerk und der plattformspezifischen Governance von ServiceNow.

Der Unterschied zwischen Produktbesitz und Kundenbesitz sollte jeden Zuverlässigkeitsanspruch prägen. ServiceNow kann ein Vorfallzustandsmodell bereitstellen. Der Kunde entscheidet, ob die Vorfallkategorien sinnvoll sind. ServiceNow kann CMDB-Integritätsindikatoren anzeigen. Der Kunde entscheidet, ob Erkennungsquellen und Abgleichsregeln gepflegt werden. ServiceNow kann Integration Hub bereitstellen. Der Kunde entscheidet, welche Berechtigungen, Wiederholungsversuche, Datenzuordnungen und externen Service-Abhängigkeiten akzeptabel sind. ServiceNow kann Now Assist und KI-Agenten bereitstellen.

Der Kunde entscheidet, wo diese Agenten handeln dürfen und wo ein Mensch genehmigen muss.

Der Fallzustand ist wichtiger als die Konversation

Der Vorfalllebenszyklus ist ein einfacher Ort, um zu erkennen, warum Zustandsintegrität wichtig ist. Die Dokumentation von ServiceNow besagt, dass das Vorfallmanagement den Lebenszyklus von Vorfällen von der Erstellung bis zur Schließung verwaltet, mit Zuständen wie New, In Progress und On Hold, und es beschreibt On Hold als eine vorübergehende Übertragung der Verantwortung an eine andere Stelle für Informationen, Nachweise oder Lösung (ServiceNow incident lifecycle documentation). Diese Formulierung ist betrieblich wichtig. Ein Fall ist nicht nur ein Gesprächsfaden. Er ist ein Beleg über Verantwortung, Nachweise und Fortschritt.

Die Dokumentation zur Wiedereröffnung von ServiceNow macht denselben Punkt vom anderen Ende her. Sie besagt, dass ein gelöster Vorfall von bestimmten Benutzern wiedereröffnet werden kann, dass die Wiedereröffnung den Zustand von Resolved auf In Progress ändert und dass Felder wie Last reopened by, Last reopened at und Reopen count die Berichterstattung und das Audit für wiedereröffnete Vorfälle unterstützen (ServiceNow reopening incident documentation). Die Nachverfolgung von Wiedereröffnungen ist ein nüchternes Zuverlässigkeitssignal. Ein Workflow, der einen Fall schnell schließt, ihn aber oft wiedereröffnet, ist nicht unbedingt besser als ein langsamerer Workflow, der das zugrunde liegende Problem beim ersten Mal löst.

Hier muss KI-Unterstützung sorgfältig gemessen werden. Now Assist für ITSM kann Vorfallinformationen zusammenfassen, Lösungshinweise generieren und Chat für eine Interaktion zusammenfassen, während es Agenten hilft, Chat- und Vorfallkontext zu verstehen (Now Assist for ITSM documentation). Diese Fähigkeiten können Zeit sparen, wenn sie Lese- und Entwurfsarbeit reduzieren. Sie können aber auch Risiken schaffen, wenn Agenten Zusammenfassungen akzeptieren, die Unsicherheiten auslassen, wenn generierte Lösungshinweise Arbeiten implizieren, die nicht durchgeführt wurden, oder wenn der zusammengefasste Kontext aus veralteten Datensätzen stammt.

Der richtige Maßstab ist nicht „Hat die KI eine gute Notiz geschrieben?“ sondern „Entsprach die Notiz dem Fallzustand, der durchgeführten Arbeit und den verfügbaren Nachweisen?“ Ein Lösungshinweis, der prägnant klingt, aber eine Anbieterabhängigkeit, eine ungelöste Änderung, einen bekannten Workaround oder eine anruferspezifische Ausnahme nicht erwähnt, mag die Berichterstattung sauberer machen, aber den nächsten Vorfall erschweren. In einer Plattform, die auf Auditierbarkeit ausgelegt ist, ist der gefährliche Fehlermodus nicht unbeholfene Prosa. Es ist autoritative Prosa, die an einen schwachen Zustandsübergang geknüpft ist.

Für Kundendienst-Anwendungsfälle dokumentiert ServiceNow das Fallmanagement als einen Prozess zur Einbindung von Kunden, Kategorisierung und Lenkung von Fällen, Zuweisung von Arbeit an Agenten und Verwaltung von Fällen durch Lösung und Berichterstattung (ServiceNow CSM case management documentation). Wiederum liegt der Produktwert im Zustandspfad. Ein Kundenfall kann Kontoberechtigungen, Produktbestand, Außendienst, Abrechnung, Support-Historie und Richtlinienausnahmen umfassen. Sind diese Datensätze falsch, kann KI die falsche Antwort beschleunigen. Sind sie richtig, kann KI die Zeit reduzieren, die benötigt wird, um die nächste verantwortliche Aktion zu finden.

Die betriebliche Lehre ist einfach: ServiceNow-Käufer sollten Auflösungsqualität messen, nicht nur Antwortgeschwindigkeit. Wiedereröffnungsrate, Falschzuweisungsrate, Anzahl manueller Umleitungen, Wartezeit nach Grund, Referenzen auf veraltetes Wissen, Anzahl der Integrationswiederholungen und Kontakt nach der Lösung beim Kunden sind bessere Indikatoren als die Anzahl generierter Notizen. Wenn KI die Bearbeitungszeit reduziert, aber die Wiedereröffnungen oder stillen Ausnahmen erhöht, hat die Plattform den sichtbaren Teil des Prozesses optimiert und den echten geschwächt.

Die CMDB ist die Routing-Oberfläche

Die Configuration Management Database wird oft als Repositorium diskutiert, aber in der ServiceNow-Ökonomie ist sie näher an einer Routing-Oberfläche. Wenn die CMDB Services, Assets, Eigentümer, Abhängigkeiten und Lebenszyklusstatus korrekt abbildet, kann die Plattform Vorfälle weiterleiten, Auswirkungen bewerten und Automatisierung mit Kontext unterstützen. Ist die CMDB unvollständig oder widersprüchlich, kann Automatisierung zu einer selbstbewussten Fehllenkungsmaschine werden.

Die Dokumentation zur CMDB-Integrität von ServiceNow sagt, dass eine gesunde CMDB für eine effektive und kontinuierliche Produktnutzung unerlässlich ist und dass Indikatoren wie doppelte Configuration Items, erforderliche CI-Felder und Audits zu Zustandsbewertungen auf Klassen-, Gesundheitsgruppen- und Serviceebene aggregiert werden (ServiceNow CMDB Health documentation). Die Formulierung ist wichtig, weil sie Integrität als fortlaufend behandelt, nicht als einmaligen Migrationsmeilenstein. Eine CMDB kann bei der Inbetriebnahme korrekt sein und sich verschlechtern, wenn sich Cloud-Ressourcen, Eigentümer, Anwendungen und Integrationen ändern.

Das CMDB-Glossar beschreibt Identification and Reconciliation auch als ein zentralisiertes Framework zur Identifizierung und zum Abgleich von Daten aus verschiedenen Quellen, wenn Daten in die CMDB gelangen, und hilft, die Integrität zu wahren, wenn mehrere Quellen CI-Datensätze erstellen und aktualisieren (ServiceNow CMDB glossary). Das ist genau das richtige Problem für die Unternehmensautomatisierung. Mehrere Systeme behaupten zu wissen, was ein Asset ist, wem es gehört, wovon es abhängt und ob es noch aktiv ist. ServiceNow kann helfen, Ordnung zu schaffen, aber die Beweise aus der eigenen Dokumentation zeigen, dass diese Ordnung Regeln, Rollen und Pflege erfordert.

Now Assist für CMDB geht noch weiter. Die Dokumentation von ServiceNow beschreibt KI-Agenten, die von Now Assist für CMDB verwendet werden, darunter einen CI-Erstelleragenten, einen Konfigurationselement-Zusammenfasser und einen Manager für Datenzertifizierung und -bestätigung (Now Assist for CMDB documentation). Das sind nützliche Richtungen, denn die CMDB-Pflege ist mühsam. Sie erhöhen aber auch den Anspruch an die Überwachung. Wenn ein KI-Agent ein CI erstellt oder zusammenfasst, muss der Käufer wissen, welche Quelle verwendet wurde, was abgeleitet wurde, was überprüft wurde und was überprüft werden sollte, bevor Workflows davon abhängen.

Der wirtschaftliche Tausch ist klar. Eine gute CMDB kann doppelte Untersuchungen und schlechtes Routing reduzieren. Eine schwache CMDB kann jede Automatisierung teurer machen, weil Teams prüfen müssen, ob das Bild der Umgebung von ServiceNow vertrauenswürdig ist. Die Kosten sind nicht nur die Dateneingabe. Es ist die Governance, die nötig ist, um zu entscheiden, welche Erkennungsquelle gewinnt, wie Ausnahmen dokumentiert, doppelte Datensätze bereinigt und wie stillgelegte oder ersetzte Systeme von der Routing-Oberfläche verschwinden, bevor sie falsche Arbeit auslösen.

Daher ist das Versprechen von ServiceNow für Organisationen, die bereit sind, CMDB-Pflege als betriebliche Infrastruktur zu behandeln, am glaubwürdigsten. Es ist weniger glaubwürdig für Käufer, die KI-Agenten und Workflow-Automatisierung wollen, während sie Service-Definitionen, Eigentumsverhältnisse und Konfigurationsdatensätze mehrdeutig lassen. Die Plattform kann Fälle nur so gut bearbeiten, wie der Kontext, den sie erhält.

Integrationen machen ServiceNow zu einer Steuerungsebene

IntegrationHub ist zentral für den Anspruch von ServiceNow, dass Unternehmensarbeit systemübergreifend bewegt werden kann. Die Dokumentation beschreibt Integration Hub als eine Möglichkeit, Integrationsaufgaben mit ServiceNow-Komponenten für Workflow Studio zu automatisieren oder benutzerdefinierte Integrationen zu entwickeln, wobei ein separates Abonnement erforderlich ist (ServiceNow Integration Hub documentation). Dieser letzte Satz ist kommerziell wichtig. Integration ist nicht nur eine technische Fähigkeit. Sie ist eine lizenzierte Betriebsoberfläche mit laufenden Kosten.

Die Fehlerbehandlung im Flow Designer zeigt, warum diese Oberfläche beobachtbar sein muss. ServiceNow dokumentiert Flow-Fehlerhandler, die Flow-Fehler erkennen können, sobald sie auftreten, Fehlerinformationen erfassen und weiterleiten, die Lösung automatisieren und es Erstellern ermöglichen, Logik zur Behandlung von Aktionsfehlern festzulegen (ServiceNow Flow error handler documentation). Die Flow-Systemeigenschaften definieren auch, wie viele Details die Ausführungsengine des Flow Designers in die sys_flow_log-Tabelle schreibt, wobei die Ebenen von der ausführlichsten Diagnoseeinstellung über INFO, WARN bis ERROR reichen (ServiceNow Flow system properties). Dies sind keine nebensächlichen Einstellungen. Sie bestimmen, ob fehlgeschlagene Automatisierung sichtbar genug ist, um darauf zu vertrauen.

Ein Integrationstimeout kann schlimmer sein als eine menschliche Verzögerung, wenn der Workflow den Fehler nicht sichtbar macht. Ein Ticket mag zugewiesen aussehen, ein Status mag aktualisiert erscheinen, oder eine generierte Antwort mag sagen, dass die Arbeit begonnen hat, während das externe System die Aktion nicht erhalten hat. Der Unterschied zwischen einem wertvollen Workflow und einem gefährlichen liegt oft darin, ob Ausnahmen zu Aufgaben mit Eigentümern, Protokollen und Wiederholungspfaden werden. ServiceNow bietet Werkzeuge dafür, aber Kunden müssen den Fehlerpfad bewusst gestalten.

Dokumentation von Drittanbietern zeigt dasselbe Muster. AWS sagt, dass der AWS Service Management Connector für ServiceNow es ServiceNow-Benutzern ermöglicht, AWS-Ressourcen bereitzustellen, zu verwalten und zu betreiben, AWS Config-Ressourcen in der CMDB zu verfolgen, AWS Systems Manager OpsItems als Vorfälle anzuzeigen und zu lösen sowie AWS Security Hub-Befunde mit ServiceNow-Vorfällen oder -Problemen zu synchronisieren (AWS Service Management Connector documentation). Eine separate AWS-Seite ordnet Incident Manager-Felder ServiceNow-Vorfallfeldern zu und weist darauf hin, dass AWS die Unterstützung für den AWS Service Management Connector am 31. März 2027 einstellen wird (AWS Incident Manager in ServiceNow documentation). Dieser Hinweis auf das Support-Ende ist eine nützliche Erinnerung: Der Wert einer Integration hängt auch vom Lebenszyklus eines anderen Anbieters ab.

Die Dokumentation von Atlassians Jira Service Management-Integration beschreibt bidirektionale Vorfall- und Alarmflüsse zwischen ServiceNow und Jira Service Management, einschließlich der Zuordnung von Zuweisungen, Gruppen, Alarmaktionen und optionaler Benutzer- und Gruppensynchronisierung (Atlassian ServiceNow integration documentation). Die Seite nennt auch Einschränkungen, darunter die Notwendigkeit von App-Installation, Benutzerrollen, Zuordnungsoptionen und Begrenzungen bei mehrfachen Integrationen ohne Codeänderung. Dies ist eine unabhängige Bestätigung für einen praktischen Punkt: Die Verbindung von ServiceNow mit einem anderen Service Desk oder einer Alarmierungsplattform ist nicht nur ein API-Aufruf. Es ist Zustandsübersetzung.

Microsofts öffentliche Sentinel-Store-App-Dokumentation für ServiceNow beschreibt ebenfalls die bidirektionale Vorfallsynchronisierung, einschließlich Vorfallerstellung, Alarm, Entität, Kommentar, Status, Schweregrad und Besitzerzuweisung, und weist darauf hin, dass die traditionelle Azure Logic App- oder Playbook-Integration keine vollständige bidirektionale Synchronisierung ermöglicht und dass die App auf einer einzigen ServiceNow-Instanz ohne Domänentrennung läuft (Microsoft Sentinel ServiceNow integration README). Diese Beschränkung ist für große Unternehmen von Bedeutung, weil Domänentrennung, Multi-Instanz-Design und Eigentumsgrenzen darüber entscheiden können, ob eine Integration sauber skaliert.

Die Schlussfolgerung ist nicht, dass Integrationen schlecht sind. Sie ist, dass Integration der Punkt ist, an dem ServiceNow zu einer Steuerungsebene wird, und Steuerungsebenen Change-Management erfordern. Jedes externe System bringt Anmeldeinformationen, Datenzuordnung, Lebenszyklusunterstützung, Ratenbegrenzungen, Feldänderungen, Anbieterhinweise und Fehlersemantiken mit sich. ServiceNow kann die „Swivel-Chair“-Arbeit des Wechselns zwischen Systemen reduzieren, aber es kann diese Systeme nicht verschwinden lassen.

KI-Agenten erhöhen den Berechtigungsstandard

Die Produktseite zu KI-Agenten von ServiceNow besagt, agentische Workflows repräsentieren ein Geschäftsziel, der AI Agent Orchestrator koordiniert die Zusammenarbeit zwischen Agententeams, AI Agent Studio ermöglicht es Benutzern, Agenten zu erstellen und anzupassen, und ServiceNow AI Control Tower ist als zentrale Anlaufstelle für KI-Governance und -Management positioniert (ServiceNow AI Agents). Die Dokumentation zu Now Assist besagt, dass es generative KI durch konversationelle und proaktive Erfahrungen nutzt, wobei der Zugriff von der Lizenz, den Produktstufen und der Funktionsverfügbarkeit abhängt (Now Assist documentation). Die Dokumentation zu Now Assist KI-Agenten besagt, dass Agenten große Sprachmodelle verwenden und von einfachen automatisierten Antworten bis hin zu komplexer Problemlösung reichen können (Now Assist AI agents documentation).

Diese Behauptungen sind am stärksten, wenn Agenten innerhalb eines gesteuerten Workflows mit begrenzter Befugnis handeln. Sie sind am schwächsten, wenn das Agentenverhalten als Ersatz für Prozessdesign behandelt wird. Ein menschlicher Service-Agent spürt oft, wenn ein Fall nicht stimmt, auch wenn das Formular vollständig aussieht. Einem KI-Agenten müssen Leitplanken, Quellenzugriff, Berechtigungen, Prüfschwellen und Eskalationsregeln gegeben werden, die dieses Urteilsvermögen abbilden. Andernfalls kann er im großen Stil reibungsarme Fehler machen.

Die öffentliche Sicherheitsbilanz bestärkt diesen Punkt. Das Canadian Centre for Cyber Security veröffentlichte am 13. Januar 2026 eine Warnung, dass ServiceNow eine Sicherheitsempfehlung für eine kritische Schwachstelle in den Now Assist AI Agents und Virtual Agent API-Versionen vor bestimmten gepatchten Versionen veröffentlicht hatte (Canadian Centre for Cyber Security advisory AV26-022). NVD listet eine weitere Schwachstelle der ServiceNow AI Platform, CVE-2025-11449, als reflektierte Cross-Site-Scripting-Schwachstelle, die ServiceNow durch die Bereitstellung eines entsprechenden Sicherheitsupdates für die Mehrheit der gehosteten Instanzen und durch Updates für selbstgehostete Kunden, Partner und gehostete Kunden mit einzigartiger Konfiguration behoben hat (NVD CVE-2025-11449).

Der Bericht des Sicherheitsforschers AppOmni zu CVE-2025-12420 argumentierte, dass KI-Agenten traditionelle Sicherheitslücken verstärken können, und beschrieb eine Integrationsschwachstelle des Virtual Agent, die eine Benutzer-Imitation durch Konto-Linking-Logik ermöglichte, und empfahl Kontrollen wie stärkere Provider-Konfiguration, Genehmigungsprozesse und Lebenszyklusmanagement für Agenten (AppOmni BodySnatcher research). Dies ist eine benannte Sicherheitsforschungsquelle, kein allgemeines Urteil über alle ServiceNow-KI-Bereitstellungen. Ihr Wert ist enger gefasst: Sie zeigt, dass Ausführungspfade von KI-Agenten zu sicherheitskritischen Pfaden werden können.

Diese Evidenz bedeutet nicht, dass Käufer KI-Agenten meiden sollten. Sie bedeutet, dass der Berechtigungsstandard steigen muss. Wenn ein Agent einen Datensatz zusammenfassen kann, besteht das Risiko in unvollständigem Kontext. Wenn ein Agent einen Datensatz aktualisieren, einen Workflow auslösen, auf ein externes Tool zugreifen oder einen anderen Agenten aufrufen kann, umfasst das Risiko unbefugte Handlungen, falsche Identität, Datenlecks und ungeprüfte Ausführung.

Die Governance-Produkte von ServiceNow mögen helfen, aber der Käufer benötigt dennoch ein Inventar der Agenten, Tools, Bereiche, Berechtigungen, Genehmigungsregeln und Außerbetriebnahme-Richtlinien.

KI verändert die Ökonomie von ServiceNow nur dann, wenn sie die akzeptierte Arbeit reduziert, nicht nur die manuelle Tipparbeit. Eine Fallzusammenfassung, die einem Agenten drei Minuten spart, ist nützlich. Ein autonomer Workflow, der einen Fall fälschlicherweise schließt, den falschen Kundendatensatz aktualisiert oder einen Sicherheitsvorfall an die falsche Warteschlange weiterleitet, ist teuer. Die verantwortungsvolle Metrik ist nicht die Anzahl der KI-Interaktionen, sondern die Anzahl der akzeptierten Lösungen mit Audit-Nachweisen und niedrigen Wiedereröffnungsraten.

Berechtigungen und Audit-Logs sind Teil der Lösung

Die Dokumentation zur Zugriffskontrolle von ServiceNow besagt, dass ACLs den Zugriff auf neue Datensätze sichern oder das Standard-Sicherheitsverhalten ändern und dass die Erstellung von ACLs die Erhöhung auf die Rolle security_admin erfordert (ServiceNow ACL configuration documentation). Die Dokumentation zur ACL-Erkundung besagt, dass eine ACL nur dann Zugriff gewährt, wenn die erforderlichen Bedingungen erfüllt sind, einschließlich Bedingungs-, Skript- und Rollenprüfungen, sowie Prüfungen auf Tabellen- und Feldebene für Datensatz-ACLs (ServiceNow ACL exploration documentation). Hier trifft Workflow-Zuverlässigkeit auf Governance.

Ein Workflow kann scheitern, weil er einen Datensatz nicht sehen kann, weil er zu viel sieht oder weil er unter einem Servicekonto schreibt, das die Verantwortlichkeit verwischt. Ein Fall kann fehlgeleitet werden, weil die relevante Gruppe verborgen ist. Eine KI-Funktion kann eine schwache Antwort liefern, weil ihr der Zugriff auf die Quelle fehlt, die sie korrigiert hätte. Umgekehrt kann eine zu freizügige Integration sensible Datensätze einem Prozess offenbaren, der sie niemals hätte sehen dürfen. Das richtige Berechtigungsmodell ist daher nicht nur eine Compliance-Anforderung. Es ist eine Vorbedingung für korrekte Automatisierung.

Audit-Nachweise sind ähnlich betrieblich relevant. Die Dokumentation zur Audit-Protokollierung von ServiceNow besagt, dass Ereignisprotokolle die Anmeldungen von ServiceNow-Mitarbeitern bei einer Kundeninstanz zeigen und Transaktionsprotokolle Aktivitäten auf der Instanz anzeigen, einschließlich der Bemühungen, Protokolle zu löschen (ServiceNow audit logging documentation). Diese Quelle bezieht sich speziell auf Aktivitäten von ServiceNow-Mitarbeitern, nicht auf alle Kunden-Workflow-Protokolle, aber sie veranschaulicht das allgemeinere Prinzip: Unternehmensarbeitsplattformen müssen erklären können, wer oder was gehandelt hat, wann und über welchen Pfad.

Für Käufer ist die entscheidende Frage, ob jeder wichtige Zustandsübergang genügend Nachweise hat. Wer hat den Vorfall wiedereröffnet? Welche Integration hat das Feld aktualisiert? Welcher Knowledge-Artikel wurde verwendet? Was hat der KI-Assistent zusammengefasst? Welcher externe Status hat sich geändert? Welche Genehmigung wurde erteilt? Welche ACL hat den Zugriff gewährt oder verweigert? Kann die Plattform diese Fragen für ihre eigenen Workflows nicht beantworten, wird eine schnellere Lösung schwerer zu vertrauen.

Die gleiche Logik gilt für regulierte Umgebungen. Der Geschäftsbericht von ServiceNow erwähnt Kosten für die Unterstützung von Kunden in regulierten Märkten und Datenspeicheranforderungen (ServiceNow 2025 Form 10-K). Regulierte Käufer schätzen ServiceNow möglicherweise gerade deshalb, weil es eine gemeinsame Kontrolloberfläche bietet. Diese Käufer sollten sich jedoch davor hüten, KI-Funktionen als generische Produktivitäts-Add-ons zu behandeln. In regulierter Servicearbeit ist eine Antwort, die nicht rückverfolgbar ist, oft keine verwendbare Antwort.

Upgrades und Anpassungen erzeugen eine Wartungsrechnung

Der Plattformwert von ServiceNow wächst, je mehr Workflows darauf umziehen. Das tut auch die Wartungsrechnung. Die Upgrade-Dokumentation macht dies konkret. ServiceNow sagt, dass angepasste Datensätze, die aktuelle Versionen in der Tabelle Customer Updates haben, während eines Upgrades übersprungen werden, und die Lösung eines übersprungenen Updates kann bedeuten, die Anpassung beizubehalten, Änderungen zusammenzuführen, auf die aktualisierte Version zurückzusetzen oder den Überspringen ohne Aktion zu überprüfen (ServiceNow skipped update resolution documentation). Die Liste der übersprungenen Änderungen existiert, um zu verhindern, dass Anpassungen überschrieben werden, und um zu helfen, übersprungene Datensätze zu verfolgen, die überprüft werden müssen (ServiceNow skipped changes documentation).

Dies sind die praktischen Kosten der Plattformanpassung. ServiceNow ist teilweise deshalb wertvoll, weil Kunden Workflows an ihre eigenen Prozesse anpassen können. Aber jede Anpassung kann später zu einer Upgrade-Entscheidung werden. Ein Käufer, der Vorfallformulare, Geschäftsregeln, ACLs, Integrationen, Tabellen und UI-Verhalten stark anpasst, mag kurzfristig eine bessere Passung erhalten, aber auf lange Sicht mehr Überprüfungsarbeit haben. Ein Käufer, der näher an der Basisplattform bleibt, mag reibungsloser upgraden, muss aber möglicherweise interne Prozesse ändern, um zum Produkt zu passen.

Die Dokumentation zum Upgrade-Plan von ServiceNow besagt, dass Arbeiten nach dem Upgrade, wie das Einspielen von Update-Sets, das Installieren von Plugins und Anwendungen sowie mehrere Updates, zeitaufwendig sein können und dass Upgrade-Pläne Aufgaben automatisieren können, indem sie Aktionen verfolgen und Schritte über die erforderlichen Instanzen hinweg wiederholen (ServiceNow Upgrade Plan documentation). Das ist eine nützliche Funktion, aber es beweist auch den Punkt: Die Wartung ist ein eigener Workflow. Die Plattform, die Arbeit automatisiert, muss selbst durch strukturierte Arbeit betrieben werden.

Das ist wichtig für die KI-Geschichte. KI-Funktionen beseitigen keine Upgrade-Komplexität. Sie können ihre eigenen Abhängigkeiten von Releases, Modellverfügbarkeiten, Lizenzierungsüberlegungen, Agentenlebenszyklusfragen und Governance-Aufgaben hinzufügen. Die Dokumentation zu Now Assist for ITSM weist darauf hin, dass einige Modell-Provider und KI-Funktionen für bestimmte In-Country-, FedRAMP-, Department of Defense IL5-, Australia IRAP-Protected-, selbstgehostete oder andere eingeschränkte Umgebungen nicht verfügbar sind (Now Assist for ITSM documentation). Das ist keine Kritik; es ist eine Erinnerung daran, dass die Verfügbarkeit von KI Teil des Bereitstellungsumfangs ist.

Der Wartungstest des Käufers sollte die Anzahl übersprungener Datensätze, manuelle Zusammenführungsstunden, Änderungen nach Upgrade-Vorfällen, Integrationsneutests, KI-Funktionsverfügbarkeit, Agentenvalidierung und Regression wichtiger Workflows umfassen. Eine Demo zeigt diese Arbeit selten. Die Produktionsverantwortung immer.

Das kommerzielle Signal ist Nachfrage, nicht Beweis

Die finanzielle Leistung von ServiceNow zeigt, dass der Markt bereit ist, für dieses Betriebsmodell zu bezahlen. Im Jahr 2025 meldete das Unternehmen einen Gesamtumsatz von 13,278 Milliarden US-Dollar, wobei die Abonnementumsätze 12,883 Milliarden US-Dollar betrugen, ein Plus von 21 Prozent gegenüber dem Vorjahr. Die Abonnementumsätze machten 97 Prozent des Gesamtumsatzes aus. Es meldete auch eine Bruttogewinnmarge im Abonnement von 80 Prozent und gab an, dass Abonnementvereinbarungen in der Regel eine Laufzeit von drei Jahren haben, mit einer Verlängerungsrate von 98 Prozent für jedes der Jahre 2025, 2024 und 2023 (ServiceNow 2025 Form 10-K).

Im ersten Quartal 2026 meldete ServiceNow Abonnementumsätze von 3,671 Milliarden US-Dollar, einen Gesamtumsatz von 3,770 Milliarden US-Dollar, laufende verbleibende Leistungsverpflichtungen von 12,64 Milliarden US-Dollar und verbleibende Leistungsverpflichtungen von 27,7 Milliarden US-Dollar. Das Unternehmen gab außerdem an, dass die Zahl der Now Assist-Kunden mit einem jährlichen Vertragswert von über 1 Million US-Dollar im Jahresvergleich um mehr als 130 Prozent gestiegen ist (ServiceNow Q1 2026 results). Diese Zahlen sind wichtig, weil sie zeigen, dass ServiceNow kein Nischen-Workflow-Tool verkauft. Es ist eine bedeutende Unternehmenssoftware-Plattform mit erheblicher Expansion innerhalb großer Kunden.

Aber Nachfrage ist kein Ergebnisbeweis. Eine Verlängerungsrate kann Wert, Wechselkosten, eingebettete Prozessabhängigkeit, Beschaffungsträgheit oder eine Mischung aus alledem widerspiegeln. Hohe verbleibende Leistungsverpflichtungen zeigen vertraglich vereinbarte Umsätze, nicht ob wiedereröffnete Tickets zurückgegangen sind. Eine hohe Bruttomarge im Abonnement zeigt ein starkes Softwaregeschäft, nicht ob eine bestimmte Implementierung die Service-Arbeit nach Partnergebühren und Governance-Overhead reduziert hat.

Die kommerzielle Frage für einen Käufer ist daher lokal. Verringert der ServiceNow-Bestand die Anzahl der Übergaben, die zur Lösung von Service-Arbeit erforderlich sind? Senkt er die Kosten der Beweiserhebung? Reduziert er Doppelarbeit zwischen ITSM, CSM, Sicherheit, Betrieb und Personalwesen? Macht er externe Systeme sicherer handhabbar? Erlaubt er es KI, Routineanfragen mit weniger Wiedereröffnungen zu bearbeiten? Oder wird er zu einer teuren Kontrollebene, die für jeden neuen Workflow Spezialisten, Berater, benutzerdefinierte Integrationen und Lizenzverhandlungen erfordert?

Die Antwort kann je nach Organisation unterschiedlich ausfallen. Ein großes Unternehmen mit fragmentierten Service Desks, inkonsistenten CMDB-Praktiken, schlechter Falltransparenz und mehreren Integrationspunkten mag feststellen, dass ServiceNows gemeinsame Plattform günstiger ist, als die Koordination weiterhin per E-Mail, Tabellenkalkulation und Stammeswissen zu betreiben. Eine kleinere oder diszipliniertere Organisation mag feststellen, dass der Umfang der Plattform mehr Zeremonie als Nutzen bringt. Der finanzielle Erfolg von ServiceNow beweist einen breiten Markt. Er ersetzt keine Due Diligence.

Workflow Data Fabric macht Datenverträge zum nächsten Zuverlässigkeitstest

Workflow Data Fabric ist der Versuch von ServiceNow, externe Daten für Workflows und KI-Agenten besser nutzbar zu machen. Die Produktseite sagt, es verbindet Daten über Systeme hinweg, fügt Geschäftskontext durch einen einheitlichen Datenkatalog hinzu und wendet richtlinienbasierte Governance-Kontrollen an, damit KI verstehen kann, wie ein Unternehmen arbeitet, und vertrauenswürdige Maßnahmen ergreifen kann (ServiceNow Workflow Data Fabric). Die Dokumentation beschreibt Workflow Data Fabric Home als eine einheitliche Datengrundlage, die Unternehmensdaten dort verbindet, wo sie liegen, sie durch stabile Verträge steuert und sie bereit für Workflows, Analysen und KI macht (Workflow Data Fabric Home documentation).

Dies ist eine gute Richtung, denn KI und Workflows scheitern, wenn der Kontext verstreut ist. Die Dokumentation der Schlüsselbegriffe definiert ein Datenprodukt als ein gesteuertes, wiederverwendbares Paket, das aus einer oder mehreren Datenschnittstellen erstellt wird, und eine Datenschnittstelle als einen stabilen, gesteuerten Datenvertrag, der eine einzelne Tabelle, verbundene Tabellen oder eine Vereinigung von Quellen repräsentieren kann und dabei Rückwärtskompatibilität erzwingt, um Verbraucher vor Breaking Changes zu schützen (Workflow Data Fabric key terms). Diese Sprache ist nützlicher als Marketingsprache, weil sie das Ding benennt, das betrieben werden muss: einen Vertrag.

Die Einschränkungen sind ebenso lehrreich. Die Dokumentation zur Verwaltung von Data Fabric-Tabellen besagt, dass eine Data Fabric-Tabelle externe Daten virtuell repräsentieren kann, aber Benutzer die Eindeutigkeit bei der Definition von Primärschlüsseln sicherstellen müssen, einen Primärschlüssel nach der Definition nicht ohne Löschen und Neuerstellung der Data Fabric-Tabelle entfernen können und in bestimmten Kontexten nur auf eine Tabelle mit einem definierten Primärschlüssel verweisen können (Managing data fabric tables). Diese Details zeigen, dass Zero-Copy- oder virtueller Zugriff die Datenmodellierung nicht beseitigt. Er ändert nur, wo die Modellierungsdisziplin angewendet wird.

Die Überwachung von Abonnements ist ebenfalls wichtig. ServiceNow sagt, dass Workflow Data Fabric-Abonnements Token umfassen, die für Fähigkeiten verwendet werden, und dass die Token-Nutzung im Subscription Management verfolgt werden kann (Workflow Data Fabric usage monitoring). Das macht den wirtschaftlichen Test konkreter. Wenn jeder KI-fähige Workflow Data Fabric-Fähigkeiten verbraucht, müssen Käufer wissen, welche Aktionen Token ausgeben, wie sich dies auf den Geschäftswert auswirkt und ob die Nutzung mit erfolgreicher Automatisierung oder mit vermeidbarer Nacharbeit wächst.

Workflow Data Fabric könnte die Zuverlässigkeit von ServiceNow verbessern, wenn es Agenten und Workflows hilft, gesteuerte Daten ohne endlose Einzelintegrationen zu nutzen. Es könnte den wirtschaftlichen Fall schwächen, wenn es zu einer weiteren Lizenzierungs- und Datenvertragsschicht wird, die nur Spezialisten verstehen. Der richtige Käufertest ist nicht, ob Daten in einer Demo verbunden werden können, sondern ob Datenverwalter Verträge, ACLs, Herkunft, Primärschlüssel und Lebenszyklusänderungen unter echter Nachfrage aufrechterhalten können.

Wo ServiceNow den Käufer enttäuschen kann

ServiceNow kann auf gewöhnliche Weise scheitern, die während eines Verkaufszyklus leicht zu übersehen sind. Die CMDB kann doppelte oder veraltete CIs enthalten, was dazu führt, dass Vorfälle an den falschen Besitzer weitergeleitet werden. Ein Knowledge-Artikel kann veraltet sein, aber dennoch eine Now Assist-Zusammenfassung beeinflussen. Eine Integration kann in ServiceNow erfolgreich sein und im externen System scheitern, oder umgekehrt. Eine ACL kann einem Workflow den benötigten Datensatz verweigern, was zu einer unvollständigen Antwort führt.

Ein zu mächtiges Servicekonto kann einen Workflow ohne ausreichende Rechenschaftspflicht handeln lassen. Ein gelöster Vorfall kann wiedereröffnet werden, weil der ursprüngliche Zustandsübergang voreilig war.

Die Plattform kann auch kommerziell scheitern. Ein Workflow erfordert möglicherweise ein zusätzliches Integration Hub-Abonnement, eine Workflow Data Fabric-Fähigkeit, eine Now Assist-Berechtigung, einen von einem Partner erstellten Konnektor oder eine benutzerdefinierte App. Das macht den Workflow nicht schlecht, aber es verändert die Gesamtkosten. Ein Käufer sollte Implementierungsdienstleistungen, Administration, Partner-Support, Schulung, Tests, Upgrade-Überprüfung, Datenpflege, Integrationsüberwachung, KI-Governance und Lizenzerweiterung einrechnen, nicht nur die Abonnementposition auf dem ersten Bestellformular.

KI kann scheitern, indem sie zu nützlich aussieht. Ein generierter Lösungshinweis kann die Tipparbeit verringern, aber die Evidenzqualität senken. Ein KI-Agent kann Vorfälle mit einer Genauigkeit weiterleiten oder kategorisieren, die insgesamt beeindruckt, aber genügend Grenzfallfehler aufweist, um verärgerte Benutzer und versteckte manuelle Bereinigung zu erzeugen. Ein Zusammenfasser kann den einen Vorbehalt auslassen, der wichtig ist. Ein Multi-Agenten-Workflow kann Arbeit von einem Agenten zum anderen weitergeben, auf eine Weise, die für menschliche Vorgesetzte schwer zu rekonstruieren ist.

ServiceNow kann auch auf eine Weise klebrig werden, die wirtschaftlich rational, aber strategisch einschränkend ist. Die Bindung liegt nicht nur im Datenexport. Sie liegt im Betriebsmodell: Ticketstatus, CMDB-Klassen, CSM-Falltypen, Flow Designer-Logik, Integration Hub-Speichen, ACLs, Update-Sets, Berichte, Genehmigungen, benutzerdefinierte Apps, Partnerfähigkeiten und Benutzerschulung. Sobald ein Unternehmen kritische Servicearbeit über ServiceNow leitet, bedeutet ein Ersatz den Neuaufbau der Art und Weise, wie Arbeit abgebildet wird. Das kann sich lohnen. Es sollte nicht ignoriert werden.

Der schwerwiegendste Fehlermodus ist die falsche Schließung. Ein Unternehmen kauft ServiceNow, um Arbeit sichtbar und steuerbar zu machen. Wenn Workflows Datensätze schließen, bevor das Problem in der realen Welt gelöst ist, hat die Plattform ihren Zweck verkehrt. Käufer sollten Wiedereröffnungen, doppelte Tickets, Kundenrückrufe, ungelöste Übergaben und manuelle Umgehungen als erstrangige Zuverlässigkeitssignale behandeln.

Der Test des Käufers sollte ein repräsentativer Fall sein

Eine ernsthafte ServiceNow-Bewertung sollte einem repräsentativen Fall von der Aufnahme bis zur dauerhaften Schließung folgen. Für ITSM könnte dies ein Service-beeinträchtigender Vorfall sein, der mit einer Cloud-Ressource, einem CMDB-Eintrag, einer Überwachungsmeldung, einem Knowledge-Artikel, einer Änderungsanforderung und einem externen Betriebssystem verbunden ist. Für CSM könnte es ein Kundenproblem sein, das Kontokontext, Berechtigungsprüfung, Bestands- oder Abrechnungsdaten, eine Backoffice-Aufgabe und Kundenkommunikation erfordert.

Für die Sicherheit könnte es eine Schwachstelle oder ein Vorfall sein, der Asset-Besitz, Schweregrad-Anreicherung, Genehmigung, Nachverfolgung der Problembehebung und Nachweise erfordert.

Der Käufer sollte jeden Zustandsübergang, jeden KI-Vorschlag, jeden Integrationsaufruf, jede Berechtigungsprüfung, jeden Fehlerpfad, jede Aktualisierung externer Systeme, jede menschliche Genehmigung und jede Wiedereröffnungsbedingung aufzeichnen. Er sollte absichtlich eine Integration brechen, einen veralteten CMDB-Eintrag einspeisen, eine Berechtigungsinkongruenz testen und fragen, was die Plattform anzeigt. Er sollte die Zeitersparnis bei Zusammenfassung und Routing mit der Zeit vergleichen, die für die Validierung von Daten, die Pflege von Zuordnungen und die Überwachung von Ausnahmen aufgewendet wird.

Die nützlichsten Metriken sind praktischer Art. Zählen Sie falsche Erstzuweisungen. Zählen Sie manuelle Umleitungen. Zählen Sie Vorfälle, die nach der Lösung wiedereröffnet wurden. Zählen Sie Fälle, die ohne Lösungsnachweis geschlossen wurden. Zählen Sie CMDB-Einträge mit fehlenden Besitzern oder doppelten Identitäten. Zählen Sie Integrationsfehler, die zu sichtbaren Aufgaben wurden. Zählen Sie übersprungene Upgrade-Datensätze und manuelle Zusammenführungszeit. Zählen Sie von Agenten akzeptierte, abgelehnte oder bearbeitete KI-generierte Vorschläge.

Zählen Sie den Anteil der akzeptierten KI-Vorschläge, die später mit Wiedereröffnungen oder Kundenrückrufen korrelierten. Zählen Sie die Token-Nutzung für KI- und Data Fabric-Aktionen, falls diese Funktionen lizenziert sind.

Diese Art von Test ist weniger glamourös als eine generative KI-Demo, aber sie beantwortet die eigentliche Frage. ServiceNow verdient seine Plattformposition, wenn es die Unternehmensarbeit einfacher macht, korrekt abzuschließen. Es verdient diese Position nicht, wenn es lediglich KI in die erste Antwort einfügt.

Was würde das Urteil ändern?

Der positive Fall für ServiceNow würde sich verstärken, wenn das Unternehmen und sein Ökosystem mehr unabhängige Nachweise zu den Ergebnissen akzeptierter Lösungen veröffentlichen würden: Veränderungen der Wiedereröffnungsrate nach der Einführung von Now Assist, Reduzierungen der Fehlleitungen nach der CMDB-Zustandsbereinigung, Sichtbarkeit von Integrationsfehlern, durchschnittliche manuelle Zusammenführungszeit bei Upgrades, KI-Agenten-Ausnahmeraten, Token-Kosten pro akzeptierter Lösung und von Kunden bestätigte Reduzierungen von Übergaben. Öffentliche Finanzdaten und Produktdokumentation belegen Größe und Leistungsfähigkeit.

Sie belegen nicht diese Bereitstellungsergebnisse.

Der Fall würde sich abschwächen, wenn Ausführungspfade von KI-Agenten wiederholt zu Sicherheitswarnungen führen, wenn Kunden feststellen, dass CMDB- und Data Fabric-Governance mehr Arbeit kosten als die Workflows einsparen, wenn Integrationslebenszyklen zu einer wiederkehrenden Quelle von Ausfällen oder nicht unterstützten Konnektoren werden oder wenn die Lizenzierungskomplexität jedes Automatisierungsprojekt von neuen Berechtigungen abhängig macht.

Er würde sich auch abschwächen, wenn die plattformspezifischen Praktiken von ServiceNow Migration oder Koexistenz mit anderen Systemen teurer machen als die Koordinationskosten, die die Plattform beseitigt hat.

Die aktuelle Evidenz liegt zwischen diesen Polen. ServiceNow verfügt über glaubwürdige Produkttiefe in den Teilen der Workflow-Zuverlässigkeit, die zählen: Zustand, CMDB, Integrationen, ACLs, Audit, Upgrade-Management und KI-Governance. Das Unternehmen hat auch eine starke kommerzielle Nachfrage und Verlängerungsevidenz. Die ungelöste Frage ist die Bereitstellungsqualität. ServiceNow kann die Betriebsoberfläche bereitstellen, aber der Käufer muss dennoch die Wahrheit, die über sie fließt, aufrechterhalten.

Fazit

ServiceNow ist am besten als ein System zu verstehen, um unordentliche Servicearbeit in gesteuerte Zustandsübergänge über Unternehmenssysteme hinweg zu verwandeln. Seine KI-Funktionen sind wichtig, aber sie sind nicht der härteste Test für das Produkt. Der härteste Test ist, ob eine reale Anfrage zu einem korrekt weitergeleiteten, gelösten und auditierbaren Fall wird, ohne Ausnahmen zu verstecken, Berechtigungen zu verletzen, veralteten Daten zu vertrauen oder nach einem voreiligen Schließen wiederzueröffnen.

Für den richtigen Käufer kann ServiceNow die Koordinationskosten senken, indem es Vorfallzustände, Kundendienstfälle, CMDB-Kontext, Integrationen, Genehmigungen, KI-Unterstützung und Audit-Nachweise in ein Betriebsmodell einbringt. Für den falschen Käufer oder für einen Käufer, der nicht bereit ist, Datenhygiene und Workflow-Governance zu finanzieren, kann es zu einem teuren Ort werden, an dem Verwirrung zentralisiert wird.

Das Urteil ist bedingt, aber klar. Die Plattform von ServiceNow ist am stärksten, wenn die Organisation sie als Infrastruktur für verantwortungsvolle Arbeit behandelt, nicht als eine Schicht generierter Antworten. Wenn die Now Platform dazu beiträgt, Fälle korrekt zu schließen, Nachweise intakt zu halten und Ausnahmen sichtbar zu machen, verdient sie ihren Platz. Wenn sie nur die erste Antwort schneller macht, wurde die eigentliche Arbeit nicht automatisiert; sie wurde nur tiefer in die Warteschlange verlagert.