Services

KI-Implementierung, die in Ihren Prozessen arbeitet,
nicht daneben.

Implementierung

Wo KI im Unternehmen keinen Nutzen bringt, liegt das meist an einer Nahtstelle: Die KI kennt den Prozess nicht, und der Prozess kann mit der KI nichts anfangen. Wir verankern Anthropic Claude in Prozessen, die ServiceNow bereits steuert.

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.

Noch unklar, was gebaut werden soll?

Beginnen Sie mit Discovery.

Discovery →

Schon live und stabil, und es geht um den Betrieb?

Beginnen Sie mit Managed Services.

Managed Services →

Das Problem

Wo Implementierungen auf ServiceNow tatsächlich scheitern

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.

01

Vor lauter Anpassungen vom Upgrade-Pfad abgekommen.

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.

02

In Produktion gebaut.

Ä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.

03

Die Plattform ist nie über die IT hinausgekommen.

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.

04

Integrationen, die niemand verantwortet.

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.

05

Ein Datenmodell, um das sich nie jemand gekümmert hat.

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.

06

Der Go-live war die Ziellinie.

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.

Was Implementierung für uns bedeutet

Eine Lösung, die Ihr Unternehmen selbst betreiben und weiterentwickeln kann.

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.

Die Lösung funktioniert mit Ihren echten Daten.

Mit allen Dubletten und ihrer ganzen Historie.

Das nächste Upgrade übersteht sie.

Ohne Rettungsprojekt.

Ihr eigenes Team kann sie betreiben.

Denn jede wesentliche Entscheidung ist mit ihrer Begründung dokumentiert.

Wir bauen auf zwei Technologien. Welche davon zum Einsatz kommt, ist eine Designentscheidung.

Anthropic Claude

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.

Company Second Brain on Claude →

Anthropic-Implementierung entdecken →

Eine Lösung, die niemand erklären kann, wird auch niemand verändern.

Wie wir bauen

Clean Core, sauberer Code und Änderungen, die sich nachverfolgen lassen

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.

01

Design vor dem Bau.

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.

02

Clean Core.

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.

03

Sauberer Code.

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.

04

Nachverfolgte Änderungen, keine Eingriffe in die Produktion.

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.

Daten, Tests und Go-live

Mit echten Daten getestet, bevor sich jemand darauf verlässt

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.

01

Daten als eigener Arbeitsstrang.

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.

02

Tests mit eingeplantem Budget.

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.

03

Go-live und Hypercare.

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.

Steht ein Neubau an, oder muss eine bestehende Lösung repariert werden?

In beiden Fällen schauen wir uns zuerst gemeinsam mit Ihnen die Instanz an.

KI-Implementierung

KI-Implementierung und KI-Integration im Prozess, den ServiceNow steuert

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.

  1. 01

    Claude bereitet die Arbeit vor

  2. 02

    Eine Person oder eine Regel gibt sie frei

  3. 03

    ServiceNow führt sie aus und dokumentiert sie

Menschliche Freigabe, wo es darauf ankommt.

Anweisungen in einem Prompt sind keine Sicherheitsgrenze.

AUF DER PLATTFORM

Freigabeschwellen und Ausnahmepfade.

BEI KI-ARBEIT

Ein ausdrücklicher Freigabeschritt, bevor etwas in Ihre Instanz geschrieben wird.

BEI BERECHTIGUNGEN

Plattformberechtigungen, die begrenzen, worauf ein KI-Integrationskonto zugreifen kann.

Claude in unserer eigenen Arbeitsweise

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

Wir arbeiten mit dem, was wir verkaufen

ServiceNow ist das Fundament unseres eigenen kaufmännischen Betriebs

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.

Sales CRM

Mit Sales CRM steuern wir den Weg von der Opportunity zum Auftrag.

Sales CRM →

Strategic Portfolio Management

Mit Strategic Portfolio Management steuern wir den Weg vom Projekt zum Portfolio.

SPM →

Now Assist

Auf unserer eigenen Instanz setzen wir Now Assist ein. So wissen wir, was die KI von ServiceNow gut kann, bevor wir sie empfehlen.

ServiceNow AI →

Claude

Claude arbeitet bei uns neben der Plattform und unterstützt unsere Wissensdatenbank, unsere Dokumentation und die oben beschriebenen Delivery-Skills.

Anthropic →

Wir bauen für Kunden dieselbe Kombination, mit der wir selbst arbeiten.

Arbeitsweisen

Dieselbe Disziplin, unterschiedliche Form

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.

01

Wir bauen die Lösung.

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.

02

Wir starten mit einem Pilot.

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.

03

Ein Forward Deployed Engineer an der Seite Ihres Teams.

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 →

Einordnung

Unsere fünf Servicebereiche und wo die Implementierung hingehört

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.

Das Gespräch beginnen

Bringen Sie uns Ihr Design.
Oder Ihre Instanz.

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.

FAQ

Die Fragen, die uns Entscheider stellen.

Wie halten Sie unsere Instanz upgradefähig?
›

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.

Können Sie eine Implementierung übernehmen, die ein anderer Partner gebaut hat?
›

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.

Was ist der Unterschied zwischen Beratung und Implementierung?
›

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?

Wann endet Discovery, und wann beginnt Implementation?
›

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.

Wann ist Implementierung der falsche nächste Schritt?
›

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.

Sollte dasselbe Unternehmen unsere Plattform und unsere KI implementieren?
›

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.

Was passiert nach dem Go-live?
›

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.

Wie stellen Sie sicher, dass unser Team die Lösung danach betreiben kann?
›

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.

Nutzen Sie KI in Ihrer eigenen Delivery?
›

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.

Wohin gehen unsere Daten, wenn Claude beteiligt ist?
›

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.

Was ist ein Forward Deployed Engineer, und was unterscheidet ihn von einer externen Fachkraft?
›

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.

Newsletter

Impulse für Ihr Postfach.

Frameworks, Perspektiven und gelegentliche Einladungen zu Veranstaltungen. Kein Spam.
Datenschutzerklärung.

Danke. Bitte bestätigen Sie Ihre Anmeldung per E-Mail.
Etwas ist schiefgelaufen. Bitte versuchen Sie es gleich noch einmal.
Vielen Dank. Ihre Anmeldung ist eingegangen.
Etwas ist schiefgelaufen. Bitte versuchen Sie es erneut.