Noch unklar, was gebaut werden soll?
Beginnen Sie mit Discovery.
Claude bereitet die Arbeit vor. Freigegeben wird sie von einer Person oder einer Regel, ausgeführt und dokumentiert von ServiceNow. Die darunterliegende Plattform bauen wir so, dass sie jedes Family Release übersteht. Wo der Standard die Aufgabe erfüllt, bleibt es beim Standard, Individuelles liegt in Scoped Applications. Jede Änderung wird nachverfolgt, jede Entscheidung mit ihrer Begründung dokumentiert.
Beginnen Sie mit Discovery.
Beginnen Sie mit Managed Services.
Dann ist eine Neuimplementierung nötig, und genau hier beginnt sie.
Am Go-live scheitern die wenigsten Implementierungen auf ServiceNow. Die meisten scheitern Monate später, wenn das erste Family Release, die erste neue Anforderung oder die erste Prüfung ansteht. Die Ursachen sind immer wieder dieselben: Individualentwicklung, unkontrollierte Änderungen, ein IT-Modell, das einem Geschäftsprozess übergestülpt wurde, Integrationen ohne Verantwortlichen, ein vernachlässigtes Datenmodell und keine echte Übergabe.
Statt Out-of-the-box-Skripte und UI Policies zu erweitern, hat man sie direkt verändert. Mit jedem Family Release entsteht nun eine Liste von Skipped Records, die jemand von Hand durchgehen muss. Upgrades rutschen deshalb erst um ein Release nach hinten, dann um zwei. Funktionen, die Sie bereits lizenziert haben, kommen bei Ihren Nutzern nie an.
Änderungen wurden direkt in der Produktion vorgenommen oder über Update Sets, die niemand nachverfolgt hat, zwischen Instanzen verschoben. Entwicklung, Test und Produktion haben sich auseinanderentwickelt. Was tatsächlich läuft, kann niemand mit Sicherheit sagen.
Customer Service Management oder Sales CRM ist zwar lizenziert, aber Fälle und Aufträge werden weiterhin per E-Mail und in Tabellen bearbeitet. Der Grund liegt im Aufbau: Man hat das Incident-Modell der IT auf einen Kundenprozess übertragen, der anders funktioniert.
Integriert wurde über Punkt-zu-Punkt-Aufrufe mit Scripted REST, die Zugangsdaten liegen in Script Includes, Tests gibt es keine. Das hält, bis ein Upgrade auf Ihrer Seite oder eine API-Änderung auf der Gegenseite kommt. Dann fallen die Aufrufe aus, ohne dass es jemand merkt.
Accounts gibt es doppelt, Kontakte pflegt niemand, und die Install Base wurde einmal geladen und danach nie abgeglichen. Berichte widersprechen sich, und weder Now Assist noch eine andere KI hat eine verlässliche Datengrundlage, mit der sie arbeiten kann.
Eine Woche nach dem Go-live war das Team weg, das die Lösung gebaut hatte. Ihr eigenes Team hat etwas geerbt, das es nie betrieben hat. Warum die einzelnen Entscheidungen so gefallen sind, wissen nur Menschen, die nicht mehr da sind.
Jede Individualentwicklung ist ein Versprechen, sie bei jedem Upgrade mitzupflegen.
Verwandt: Customer Service Management, Sales CRM, ServiceNow Integrations, ServiceNow AI.
Implementierung ist für uns eine Disziplin: etwas aufbauen und es so gestalten, dass es erklärbar bleibt. Wenn wir fertig sind, müssen drei Bedingungen erfüllt sein.
Mit allen Dubletten und ihrer ganzen Historie.
Ohne Rettungsprojekt.
Denn jede wesentliche Entscheidung ist mit ihrer Begründung dokumentiert.
Wir bauen auf zwei Technologien. Welche davon zum Einsatz kommt, ist eine Designentscheidung.
DAS GESTEUERTE AUSFÜHRUNGSSYSTEM
In diesem System liegen Prozess, Datensätze, Berechtigungen und Audit Trail. Auf die Plattform gehört Arbeit, die immer gleich ablaufen, für Führungskräfte sichtbar sein und auch Fragen der Compliance standhalten muss.
DIE EBENE, DIE ABWÄGT UND URTEILT
Manche Engpässe entstehen dort, wo unstrukturierte Informationen bewertet werden müssen, etwa beim Lesen einer langen Kunden-E-Mail, beim Entwurf einer Antwort oder bei der Recherche zu einem Fall. Dafür braucht es eine andere Art von System.
Eine Lösung, die niemand erklären kann, wird auch niemand verändern.
Unsere Implementierungen auf ServiceNow sollen upgradefähig und erklärbar bleiben. Das bedeutet: Erst wird das Design festgelegt, dann wird gebaut. Der Clean Core bleibt erhalten, individuelle Logik liegt in Scoped Applications. Für den Code gelten schriftliche Standards mit Peer Review, und jede Änderung wird von der Entwicklung über den Test bis in die Produktion nachverfolgt. Für unsere Arbeit mit Claude gilt derselbe Maßstab.
Das Design ist ein eigener Auftrag mit eigenen Ergebnissen. Bevor irgendjemand etwas konfiguriert, vereinbaren wir für jede Funktion und jede Schnittstelle einen Bauplan. An ihm muss sich der Bau messen lassen. Im Entscheidungsprotokoll steht jede Designentscheidung mit ihrer Begründung. Das RAID-Log weist jedem Risiko, jeder Annahme, jedem offenen Problem und jeder Abhängigkeit einen Verantwortlichen und eine Auswirkung zu.
Konfiguration geht bei uns vor Individualentwicklung, Erweitern vor Verändern. Out-of-the-box-Datensätze fassen wir nicht an. Individuelle Logik liegt in Scoped Applications, klar abgegrenzt vom globalen Scope. Für jede Abweichung vom Standard sind im Entscheidungsprotokoll eine Begründung und ein Verantwortlicher eingetragen. So ist die Liste der Skipped Records beim Upgrade kurz und erklärbar, und Upgrades bleiben Routine.
Wir arbeiten nach schriftlichen Coding-Standards und Namenskonventionen, und vor jedem Merge steht ein Peer Review. Fest codierte sys_ids, Datenbankabfragen in Schleifen und in Client Scripts versteckte Geschäftslogik gibt es bei uns nicht. Serverseitige Logik liegt in Script Includes, die sich testen lassen. Kommentare erklären, warum der Code existiert, nicht, was er tut.
Jede Änderung wird in einem Update Set erfasst, direkt in der Produktion wird nichts gebaut. Die Update Sets durchlaufen in fester Reihenfolge Entwicklung, Test und Produktion. Dadurch hat jede Instanz den Stand, den sie haben soll, und jeder kann nachvollziehen, was sich wann geändert hat.
Bei einer Implementierung auf ServiceNow steckt das größte Risiko in den Daten und den Tests, nicht in der Konfiguration. Die Datenmigration läuft bei uns als eigener Arbeitsstrang, und den Testaufwand planen wir je Story und je Schnittstelle ein. Bevor sich Ihre Mitarbeiter auf den Prozess verlassen, ist er mit den Daten erprobt, mit denen er im Betrieb arbeiten wird.
Die Migration gehört zum Bau und wird nicht nachträglich angehängt. Wir ordnen die Daten zu, bereinigen sie und gleichen sie ab. Vor dem Go-live fahren wir Probeläufe mit realen Datenmengen.
Wir schätzen den Testaufwand je Story und je Schnittstelle, und jeder Integrationsendpunkt durchläuft drei Testzyklen. Den User Acceptance Test führt Ihr Team mit unserer Unterstützung durch. Abgenommen wird, wenn die Testnachweise dokumentiert, die Daten abgeglichen und die Fehler der Prioritäten eins und zwei behoben oder formal akzeptiert sind.
Wo Ihre Organisation es zulässt, gehen wir stufenweise live. Daran schließt sich eine vertraglich vereinbarte Hypercare-Phase an, mit einem benannten Team und einem Puffer für die Fehlerbehebung.
Verwandt: Der ServiceNow-Hub beschreibt die vollständige Methode im Detail.
In beiden Fällen schauen wir uns zuerst gemeinsam mit Ihnen die Instanz an.
Wir binden Anthropic Claude in Prozesse ein, die ServiceNow bereits steuert, und beginnen neue KI-Anwendungsfälle mit einem klar begrenzten Pilot. In unserer eigenen Delivery arbeiten wir nach demselben Muster: Jeden wesentlichen Schritt prüft ein Mensch.
Claude bereitet die Arbeit vor
Eine Person oder eine Regel gibt sie frei
ServiceNow führt sie aus und dokumentiert sie
Anweisungen in einem Prompt sind keine Sicherheitsgrenze.
Freigabeschwellen und Ausnahmepfade.
Ein ausdrücklicher Freigabeschritt, bevor etwas in Ihre Instanz geschrieben wird.
Plattformberechtigungen, die begrenzen, worauf ein KI-Integrationskonto zugreifen kann.
Wir setzen Claude in unserer eigenen Delivery auf ServiceNow und in Kundenprojekten ein:
Datenmigration
Claude schlägt für Felder aus Altsystemen Zuordnungen samt Konfidenzwert vor. Ein Berater prüft jede davon.
Migration der Wissensdatenbank
Eine Migrationspipeline extrahiert und kuratiert Artikel, mit menschlicher Prüfung vor dem Import.
Analyse von Instanzen
Claude liest Tabellen, Regeln und Berechtigungen einer laufenden Instanz. Weil dabei keinerlei Schreibzugriff besteht, ist der Einsatz auch während der Discovery unbedenklich. NUR LESEND
Konfiguration in natürlicher Sprache
Aus Anforderungen in Alltagssprache erstellt Claude ServiceNow-Konfiguration. Bevor etwas geschrieben wird, muss sie Freigabeschritte durchlaufen. Derzeit läuft dieser Einsatz als Pilot auf der Entwicklungsinstanz eines Kunden. IM PILOT
Unser eigener kaufmännischer Betrieb läuft auf ServiceNow. Unsere Instanz unterliegt denselben Clean-Core-Regeln, derselben Änderungssteuerung und denselben Upgrades wie Ihre. Wenn wir sagen, dass eine Individualentwicklung Sie bei jedem Release etwas kostet, wissen wir das aus eigener Erfahrung: Wir tragen diese Kosten selbst.
Mit Sales CRM steuern wir den Weg von der Opportunity zum Auftrag.
Mit Strategic Portfolio Management steuern wir den Weg vom Projekt zum Portfolio.
Auf unserer eigenen Instanz setzen wir Now Assist ein. So wissen wir, was die KI von ServiceNow gut kann, bevor wir sie empfehlen.
Claude arbeitet bei uns neben der Plattform und unterstützt unsere Wissensdatenbank, unsere Dokumentation und die oben beschriebenen Delivery-Skills.
Wir bauen für Kunden dieselbe Kombination, mit der wir selbst arbeiten.
Wir implementieren in drei Formen: als Projekt mit definiertem Umfang, das wir mit eigenem Team umsetzen, als Pilot, wenn sich der Weg in die Produktion erst noch erweisen muss, oder mit einem Forward Deployed Engineer, der an der Seite Ihres Teams ein klar benanntes Ergebnis verantwortet. Methode, Entscheidungsprotokoll und Abnahmestandard bleiben in jeder Form gleich.
Für einen definierten Umfang setzen wir unser Team und unsere Methode ein, abgenommen wird nach einem vereinbarten Standard. Auf das Design folgen der Bau und die Hypercare-Phase. So läuft der größte Teil unserer Implementierungen.
Diese Form eignet sich besonders für KI. Wir arbeiten an einem klar begrenzten Anwendungsfall auf einer Nicht-Produktionsinstanz, mit Ihren echten Daten und unter Ihren Kontrollen. Bevor wir beginnen, vereinbaren wir den Weg in die Produktion und klären dabei, was für den Go-live erfüllt sein muss. Ohne Weg in die Produktion bleibt ein Pilot eine Demo.
Einer unserer Spezialisten arbeitet als Forward Deployed Engineer eng mit Ihrem Team zusammen und verantwortet ein klar benanntes Ergebnis. Sie arbeiten direkt mit ihm, ohne Betreuungsebene dazwischen. Ein benannter Ansprechpartner bei uns steuert Leistung, Eskalation, Besetzung und Änderungen. Hinter der Arbeit stehen unsere Methode und unser Team. Wir verkaufen ein Ergebnis, keine Kapazität.
Forward Deployed Engineer →
Die Beratung entscheidet, was sich ändern soll und warum.
Die Implementierung setzt die Veränderung um.
Discovery klärt, was sich zu bauen lohnt und wann etwas als „bereit“ gilt.
Die Implementierung setzt die vereinbarte Lösung um.
Managed Services beginnt, sobald Sie ein dauerhaftes Operating Model für die gebaute Lösung wählen.
Die Implementierung ist abgeschlossen, wenn die vereinbarte Lösung abgenommen, ausgerollt und während der vertraglich festgelegten Hypercare-Phase begleitet wurde.
Das Training gibt es, weil Sie eine Lösung, die Ihr Team nicht nutzen kann, faktisch nicht haben.
Kompetenztransfer und Übergabe gehören zu jeder Implementierung. Im Training werden sie zu einem eigenen Programm.
Haben Sie ein Design, das umgesetzt werden soll, sagen wir Ihnen zuerst, was wir daran ändern würden.
Ist Ihre Instanz schon live und bremst Sie aus, schauen wir sie uns als Erstes an.
Indem wir individuelle Arbeit klein, abgegrenzt und dokumentiert halten. Wir konfigurieren, bevor wir individuell entwickeln, lassen Out-of-the-box-Datensätze unangetastet und halten individuelle Logik in Scoped Applications. Jede Abweichung vom Standard hat eine schriftliche Begründung und eine verantwortliche Person. Jede Änderung ist in Update Sets nachverfolgt, sodass wir beim Upgrade genau wissen, was wir gebaut haben und warum.
Ja. Wir analysieren die Instanz, bevor wir sie verändern: Individualentwicklungen, Skipped Records, Integrationen und die Lücke zwischen dem, was lizenziert ist, und dem, was genutzt wird. Sie erhalten ein klares Bild davon, was sich zu behalten lohnt, was zurück in den Standard gehört und was neu gebaut werden sollte, bevor sich jemand auf einen Plan festlegt.
Beratung liefert eine Empfehlung. Implementierung liefert eine funktionierende Fähigkeit, und beide scheitern auf unterschiedliche Weise. Eine Empfehlung scheitert, weil sie falsch ist. Eine Umsetzung scheitert, weil sie unbrauchbar ist oder sich nicht upgraden lässt. Eine nützliche Frage an jeden Anbieter: Sind die Menschen, die die Lösung entworfen haben, beim Go-live noch dabei?
Wenn genug Klarheit zum Bauen da ist: ein vereinbarter Umfang, eine bekannte Architektur, eine benannte verantwortliche Person und ein Abnahmestandard, den alle anerkennen. Ab der Implementierung kostet es echtes Geld, Entscheidungen rückgängig zu machen. Deshalb sollten sie dann bereits getroffen sein.
Wenn eines von vier Dingen fehlt. Sind sich zwei Bereiche noch uneins, wie der Prozess laufen soll, schreibt die Umsetzung diesen Dissens fest. Beginnen Sie dann mit Discovery oder Advisory. Vertraut niemand den Daten, beginnen Sie mit Discovery und bringen zuerst die Daten in Ordnung. Ist der KI-Anwendungsfall noch nicht gewählt, beginnen Sie mit AI Use Case Discovery. Und wird niemand die Fähigkeit nach dem Go-live verantworten, klären Sie das Betriebsmodell, bevor Sie bauen.
Nicht unbedingt. Aber an der Nahtstelle zwischen beiden geht meist der Wert verloren: KI, die den Prozess nicht sieht, und ein Prozess, der die KI nicht nutzen kann. Entscheidend ist, dass eine Partei dafür verantwortlich ist, dass die gesamte Fähigkeit funktioniert.
Eine vertraglich vereinbarte Hypercare-Phase mit einem benannten Team, und danach eine Entscheidung. Hypercare hat bewusst ein Enddatum. Sie soll auffangen, was die Tests übersehen haben, und nicht zu einer informellen Supportvereinbarung werden, die niemand bepreist hat. Bevor sie endet, wählen Sie ein dauerhaftes Betriebsmodell: Ihr eigenes Team, wir oder eine Kombination.
Wir schreiben die Begründungen auf, und wir beziehen Ihre Mitarbeitenden in den Bau ein, nicht erst in die Übergabe. Ein Entscheidungslog erklärt, warum eine Konfiguration existiert, nicht nur, wo sie liegt. Zur Abnahme gehören dokumentierte Testnachweise, die Übergabe an Ihr Plattform-Admin-Team und ein Cutover-Runbook.
Ja, an bestimmten Stellen und immer mit einer Person, die das Ergebnis prüft. Claude unterstützt unsere Datenmigration, die Migration von Wissensdatenbanken, die reine Leseanalyse von Instanzen und unsere Dokumentation. Konfiguration in natürlicher Sprache, mit Freigabeschritten, bevor irgendetwas geschrieben wird, läuft als Pilot auf der Entwicklungsinstanz eines Kunden.
Nur dorthin, wo Sie zugestimmt haben. Bevor Kundendaten Claude erreichen, vereinbaren wir mit Ihnen, welche Claude-Bereitstellung wir nutzen, wo die Daten verarbeitet werden und welche Vertragsbedingungen zur Datenverarbeitung gelten. Nur die Daten, die ein Anwendungsfall tatsächlich braucht, erreichen das Modell, und das wird im Design entschieden, nicht während des Baus.
Ein Forward Deployed Engineer aus unserem Team arbeitet eng an der Seite Ihres Teams und trägt die Verantwortung für ein klar benanntes Ergebnis, mit direktem Zugang zu den beteiligten Menschen und Systemen. Eine externe Fachkraft ist Kapazität, die Sie selbst steuern. Ein Forward Deployed Engineer arbeitet nach unserer Methode, eine benannte verantwortliche Ansprechperson auf unserer Seite steuert Änderungen, und die Vereinbarung ist vertraglich festgehalten. Wenn Sie vor allem zusätzliche Kapazität brauchen, um einen bestehenden Plan abzuarbeiten, sind wir vermutlich nicht der richtige Partner.