ServiceNow: eine Plattform von A bis Z

Meine Journey mit ServiceNow begann nicht mit einem großen Plan, sondern buchstäblich mit einem Beinahe-Unfall. Im Jahr 2004 habe ich Fred Luddy fast überfahren. Ich fuhr durch unsere gemeinsame Heimatstadt, als er vor mir auf dem Zebrastreifen auftauchte. Glücklicherweise habe ich ihn gerade noch rechtzeitig gesehen. Wir haben uns gegenseitig erkannt, da ich früher für ihn gearbeitet hatte.

So fügte sich eines zum anderen und er lud mich ein, um mir zu zeigen, woran er gerade arbeitete. Ein paar Tage später präsentierte er mir eine sehr frühe Version seiner Glide-Plattform (der heutigen ServiceNow AI Platform). Es fehlten noch alle möglichen Features, Funktionen und Fähigkeiten, die sie heute besitzt. Doch die Kernkonzepte – von der metadatengestützten Anwenderoberfläche bis hin zu dem in die Datenstrukturen integrierten intrinsischen relationalen Modell – waren schon damals vorhanden.

Bei dieser ersten Demo hatte ich noch nicht wirklich verstanden, um was es eigentlich geht. Mir fielen sofort alle möglichen Dinge ein, die ich mit der Plattform von Fred nicht tun konnte, und nicht die, die mit ihr einfacher zu erledigen waren. Dennoch gefiel mir der Gedanke, mit einer Person, die ich respektierte, etwas Neues zu entwickeln. Deshalb entschied ich mich dafür, mit ihm zusammenzuarbeiten.

Wichtige Erkenntnisse von Fred Luddy

Als Fred im Jahr 2004 ServiceNow gründete, hatte er eine sehr klare Vision. Er wollte eine Plattform entwickeln, auf der jede Person sinnvolle Geschäftsanwendungen erstellen konnte. Wir waren damals wohl noch nicht an dem Punkt angelangt, an dem auch meine Mutter (eine sehr intelligente, aber technisch nicht versierte Person) in der Lage gewesen wäre, eine App zu entwickeln. Es war uns aber bereits gelungen, die Komplexität des Prozesses drastisch zu verringern.

Obwohl wir zunächst die IT Service Management-(ITSM)Anwendungen auf den Markt brachten, verfolgten und entwickelten wir unsere Plattformvision weiter. Und sie ist in Anbetracht von Branchenentwicklungen wie der agentenbasierten KI auch heute noch von Relevanz.

Rückblickend hatte Fred drei verschiedene Einblicke über den Markt und die technologischen Möglichkeiten für ihn erhalten. Ein Teil seiner Genialität war es, neue Technologien auf alte Probleme anzuwenden.

1. Plattform: Fred war der Meinung, dass Vereinfachung ein Feature war. Wenn er die Erstellung, Änderung und Aktualisierung einer Anwendung hinreichend vereinfachen könnte, würde das einen eingeschränkten Funktionsumfang für Anwender mehr als wettmachen. Bei einer erheblichen Vereinfachung häufiger Aktivitäten würden Anwender sich kaum darüber beschweren, dass sie einige der komplexeren Dinge nicht tun könnten, die andere Technologien der damaligen Zeit boten.

2. Browser: 2004 war die Idee, Software über einen Browser bereitzustellen, noch neu. Zu dieser Zeit war es gängige Praxis, auf Desktop-Anwendungen basierende „FAT“-Clients bereitzustellen, und es war nicht ungewöhnlich, dass ein Wissensarbeiter Dutzende von spezifischen Client-Apps auf seiner Workstation hatte. Mit dem Übergang zu browserbasierten Apps war Fred seiner Zeit voraus, da er bereits damals den Browser als neuen Universal Client sah.

3. Bereitstellungsmodell: Fred hatte alle Nachteile der traditionellen Softwarebereitstellung aus erster Hand erlebt, da er zu diesem Zeitpunkt schon fast 30 Jahre lang in der Branche tätig war. Er wusste, welchen Wert er mit einer durchgängigen SaaS-(Software as a Service-)Anwendung bieten konnte, die der Kunde nicht selbst unterbringen, verwalten oder betreiben musste.

Meistern von frühzeitigen Herausforderungen

Wenngleich wir mit den zentralen Punkten recht hatten, mussten wir dennoch einige bedeutende geschäftliche Herausforderungen bewältigen. Die einfachste dieser Herausforderungen war der Verkauf einer Unternehmensplattform. Wenn dein Unternehmen aus einem halben Dutzend Personen besteht, die im Keller deiner
Venture-Capital-Firma arbeiten, fühlt sich ein Verkaufsgespräch etwas merkwürdig an.

Am Ende hielten wir eine Reihe von Pitch-Meetings ab, in denen wir die Leistungsfähigkeit der Plattform demonstrierten, aber die Kunden fragten lediglich: „Ja, aber was kann man damit machen?“ Wir haben versucht, die Frage umzudrehen, und fragten: „Nun, was wollen Sie damit machen?“

Wir entwickelten die ersten ITSM-Anwendungen, die uns halfen, unser anfängliches Angebot voranzubringen und die Leistungsfähigkeit der Plattform zu demonstrieren. Damals waren die Leute viel mehr daran interessiert, Apps zu kaufen als die Plattform selbst, sodass das zu unserem Standardverkaufsargument wurde.

Eine weitere Herausforderung bestand darin, dass die öffentliche Cloud-Infrastruktur, die für uns heutzutage selbstverständlich ist, damals nicht existierte. Wenn wir Software über ein SaaS-Modell bereitstellen wollten, mussten wir Server kaufen, Rechenzentrumsflächen und Kabelracks mieten, Netzwerke einrichten und uns um die gesamte physische Infrastruktur kümmern, die eine Cloud benötigt.

Die richtige Cloud-Lösung bereitzustellen war in vielerlei Hinsicht schwieriger, als das richtige Produkt und die richtige Plattform zu entwickeln. Wir sind heute gute Cloud-Betreiber, aber das war 2004 nicht der Fall. Vieles mussten wir im Laufe unserer Arbeit selbst lernen, da es damals nicht viele Personen mit den erforderlichen Kompetenzen gab.

Die Plattform war das Ziel

Unabhängig davon haben wir uns an unsere ursprüngliche Produktvision einer Plattform gehalten, mit der eine Durchschnittsperson Geschäftsanwendungen entwickeln können sollte. Obwohl wir uns auf dem Markt als App-Unternehmen präsentierten, haben wir den Technologie-Stack weiterhin mit einer Plattformvision gestaltet.

Die Apps, die wir an unsere Kunden verkauften, waren reine Plattform-Apps. Jede einzelne von ihnen hätte von einem Kunden mit Zugriff auf die Plattform selbst geschrieben werden können.

Einige Kunden erkannten das und begannen, ihre eigenen Apps auf der Plattform zu entwickeln, mit denen sich alle möglichen interessanten Dinge bewerkstelligen ließen. Das europäisches Forschungszentrum CERN baute beispielsweise eine komplette Standort-Management-Suite auf ServiceNow auf. So konnte ein Gastforscher unseren Servicekatalog nutzen, um alles von Schreibtischlampen bis hin zum Zugriff auf den Large Hadron Collider zu verwalten.

Wir haben dieses Modell über die Jahre hinweg beibehalten, und das ist einer der Gründe dafür, warum wir unseren Produktumfang so einfach auf andere Bereiche wie HR, Customer-Relationship-Management, Sicherheit und die Rechtsabteilung erweitern konnten.

Wenn Sie einen Geschäftsprozess modellieren möchten, der strukturierte Daten, mehrere Schritte, Genehmigungen, Benachrichtigungen und Zuweisungen umfasst, bietet die ServiceNow Platform dafür eine der produktivsten Möglichkeiten.

Wichtige Meilensteine und gewonnene Erkenntnisse

Wenn ich zurückblicke, wie ServiceNow als Unternehmen wuchs, gab es einige entscheidende Momente, in denen wir mit unerwarteten Umständen konfrontiert waren und die richtigen Entscheidungen getroffen haben.

Zunächst war da die Entscheidung, welche Kunden wir anvisieren wollten. Das ursprüngliche Geschäftskonzept ging davon aus, dass SaaS eine mittelständische Lösung sei und wir viele kleine und mittelständische Kunden haben würden. Schon zu Beginn unserer Journey gewannen wir jedoch große Unternehmenskunden, wie Edmunds.com, TIAA-CREF und die Deutsche Bank.

An diesem Punkt stellte sich die Frage, ob wir in die Funktionen investieren wollten, die große Unternehmen brauchten, oder ob wir uns weiterhin auf unsere Mittelstandslösung konzentrieren sollten. Letztendlich haben wir beides getan. Und durch das Hinzufügen vieler Funktionen für größere Unternehmen haben wir die Plattform und die Anwendungen neu ausgerichtet und zu einer anspruchsvolleren Lösung entwickelt.

Ein zweiter Wendepunkt war die Finanzkrise 2008. Sie traf die Wirtschaft wie ein Güterzug und revolutionierte die Softwarebranche. Budgets und Verhaltensweisen veränderten sich drastisch.

Uns verschaffte die Finanzkrise Rückenwind, denn eines unserer zentralen Wertversprechen war, dass ServiceNow besser als die Konkurrenz und unter dem Gesichtspunkt der Gesamtbetriebskosten auch günstiger war. Wir waren zur richtigen Zeit am richtigen Ort, und die neu gefundene Glaubwürdigkeit unseres Unternehmens ermöglichte es uns, mit Käufern Gespräche über Kosteneinsparungen und damit über eine ihrer wichtigsten Prioritäten zu führen.

Wir konnten die Arbeitsauslastung von Großunternehmen bewältigen, da wir die Plattform mit einem Tenancy-Modell und einer Clustering-Struktur entwickelt hatten, die es uns ermöglichten, die Betriebsabläufe großer Kunden zu unterstützen. Außerdem konnten wir Kunden mit unserem SaaS- und Bereitstellungsmodell helfen, Geld zu sparen.

Von KI zu agentenbasierter KI

Seit mehr als einem Jahrzehnt bieten wir auf der Plattform KI-Tools verschiedener Art an. Wir begannen mit der Nutzung von überwachtem maschinellen Lernen, um einfache Aufgaben wie die Zuweisung und Priorisierung von Fällen zu lösen. Nach einiger Zeit und mit guten Trainingsdaten konnten wir KI einsetzen, die unseren Kunden half, Zeit und Geld zu sparen.

Dieselbe Plattformarchitektur trägt auch im Zeitalter der agentenbasierten KI für ServiceNow Früchte. Wenn neue Technologien aufkommen, brauchen wir sie nur einmal zu integrieren. Danach steht sie allen unseren Kunden über alle unsere Produkte hinweg zur Verfügung.

Agentenbasierte KI-Systeme, die auf großen Sprachmodellen (Large Language Models, LLM) basieren, sind viel differenzierter als die frühen maschinellen Lernlösungen und lassen sich in weitaus mehr Bereichen anwenden. Heute müssen wir kein Modell mehr trainieren, um Fälle zu priorisieren. Die agentenbasierte KI kann uns einfach sagen, wie wir eine Liste von Kundenanfragen priorisieren sollen. Und sie schneidet mindestens so gut ab, wie durchschnittliche Mitarbeitende bei der gleichen Aufgabe es täten.

Darüber hinaus können agentenbasierte KI-Systeme differenziertere Logikaufgaben ausführen, die frühere KI-Generationen nicht einmal konzeptualisieren konnten. Beispielsweise kann ein auf der ServiceNow AI Platform ausgeführter KI-Agent feststellen, dass das E-Mail-Konto von Mary gesperrt ist, weil sie die erforderliche Sicherheitsschulung nicht abgeschlossen hat.

Das ist ein ITSM-Anwendungsfall, aber KI-Agenten können ähnliche Herausforderungen in jedem Geschäftsbereich bewältigen. KI-Agenten können beispielsweise eine Frau durch ihre veränderten Krankenversicherungsansprüche führen, nachdem sie ein Baby bekommen hat (ein HR-Anwendungsfall).

Kalkulierte Risiken für kontinuierliche Verbesserungen

Wenn ich auf die Unternehmensgeschichte zurückblicke, sehe ich sehr viele Ähnlichkeiten zwischen der jetzigen agentenbasierten KI-Revolution und den Anfängen von ServiceNow. Die KI-Technologie entwickelt sich rasant weiter. Wir haben noch keine klar definierten Modelle, Regeln oder Ansätze für Problemlösungen – oder auch nur dafür, welche Probleme es sich zu lösen lohnt.

Die Kontrolle über die Geschwindigkeit ist eine große Herausforderung, wenn man 8.400 Kunden hat. Als wir kleiner waren und nur 84 Kunden hatten, war ein Softwarefehler, der nur einen Kunden betraf, keine große Sache. Mittlerweile sieht das alles ganz anders aus.

Glücklicherweise stellt unsere Plattform eine Lösung bereit, da sie es uns ermöglicht, unsere Entwicklungsschritte effizient nachzuverfolgen. Wir veröffentlichen häufig Updates für die agentenbasierte KI und bleiben innovativ, um mit der Weiterentwicklung der Technologie Schritt zu halten. Damit stellen wir sicher, dass wir so schnell wie möglich die besten Features und Funktionen bereitstellen.

Für unsere zentralen Plattformservices – von der Anwenderoberfläche über Workflows bis hin zu Geschäftsanwendungen – verwenden wir jedoch ein traditionelles Versionsmodell. Dieser Ansatz hilft uns, die Qualität aufrechtzuerhalten, die für solche geschäftskritischen Systeme erforderlich ist.

Die zugrunde liegende Separation of Concerns der Plattform ermöglicht es uns, dies auf eine Weise zu erreichen, die mit vielen anderen Architekturen technisch nicht machbar wäre.

Das Große und Ganze geht immer etwas verloren, wenn man etwas so komplexes wie die Geschichte eines Unternehmens auf einen einzigen Punkt zusammenfassen will. Aber wenn ich es tun müsste, würde ich Folgendes sagen: Die beste Entscheidung, die wir je getroffen haben, war, ein plattformorientiertes statt ein anwendungsorientiertes Produkt zu entwickeln.

Diese Entscheidung hat uns – und unseren Kunden – im Laufe der Jahre in verschiedenen Punkten geholfen und hilft uns auch heute noch.

Erfahren Sie mehr über die Vorteile der ServiceNow AI Platform für die Unternehmenstransformation.