Oracles sechs Implementierungsagenten setzen bei der Arbeit vor dem ERP-Start an

Eigene redaktionelle Grafik von Ken Jo auf Grundlage der unten aufgeführten Quellen.

Bevor ein neues Geschäftssystem eine Rechnung genehmigen kann, muss jemand festlegen, wer sie genehmigen darf, wie das Unternehmen aufgebaut ist und welche anderen Systeme Informationen austauschen sollen. Aus diesen Entscheidungen werden Entwürfe, Einstellungen, Integrationscode und Tests. Das Softwareabonnement ist erst der Anfang dieser Arbeit.

Am 26. Oktober 2026 kündigte Oracle eine agentengestützte Implementierungsplattform über Oracle AI Success Navigator an. Sechs Rollen decken Bestandsaufnahme, Design, Konfiguration, Tests, Integration und Innovation ab. Oracle bietet Geschäftsanwendungen unter anderem für Finanzen, Personal und Lieferketten; diese Ankündigung konzentriert sich auf die Arbeit zu ihrer Einführung und Verbesserung. Offizielle Ankündigung.

Interessant ist, an welcher Stelle Unterstützung einsetzt. Ein Agent zur Nutzung eines bestehenden ERP arbeitet innerhalb einer vorhandenen Einrichtung; ein Implementierungsagent hilft, diese Einrichtung zu schaffen. Dieser Beitrag erklärt das zugrunde liegende Register, drei praktische Bewertungsszenarien und die Belege, die ein Projektteam vor dem Übergang generierter Konfiguration in den Betrieb verlangen sollte.

Der aufwendige Übergang liegt zwischen Geschäftsregel und Einstellung

Enterprise Resource Planning, kurz ERP, verbindet zentrale Geschäftsaktivitäten über eine gemeinsame Anwendungs- und Datenstruktur. Selbst ein vertrauter Vorgang wie die Freigabe einer Lieferantenrechnung enthält organisationsabhängige Entscheidungen. Die richtige Konfiguration setzt voraus, dass diese ausdrücklich getroffen und konsistent übertragen werden.

Ein beispielhafter Bedarf lautet: Rechnungen oberhalb eines Betrags benötigen eine weitere Freigabe. Das Team muss Betrag, Währung, Geschäftseinheit und das Vorgehen bei Abwesenheit der freigebenden Person festlegen. Die Implementierung muss diese Entscheidungen über Design, Einstellungen und Tests hinweg bewahren.

Ein ansprechendes Diagramm genügt nicht. Weichen schriftliche Regel und bereitgestellte Konfiguration voneinander ab, kann das System konsequent das Falsche tun. Deshalb umfasst Implementierungsarbeit wiederholte Übergaben zwischen Menschen, die Geschäft, Software und Betriebsumgebung verstehen.

Oracles Vorschlag setzt an diesen Übergaben an. Die Chance besteht darin, produktspezifisches Wissen in Planung und Einrichtung einzubringen und die Überlegungen zu reduzieren, die jedes Team neu rekonstruiert. Unsere Einschätzung: Entscheidend ist ein kürzerer Weg von einer geprüften Anforderung zu einer getesteten Konfiguration, deren Verhalten das Unternehmen erklären kann.

FSCR gibt einem Agenten produktspezifische Anweisungen

Oracle kündigte am selben Tag die Fusion Setup and Configuration Registry, kurz FSCR, an. Das öffentliche Git-Repository soll maschinenlesbares, ausführbares Implementierungswissen enthalten: Konfigurationsoptionen, Abhängigkeiten, Reihenfolge, Tests und Validierung. Oracle erklärt, das Register gemeinsam mit Fusion Applications zu pflegen. FSCR-Ankündigung vom 26. Oktober 2026.

Das ist konkreter, als einem Agenten allgemeine ERP-Artikel zu geben. Eine nützliche Implementierungsanweisung muss ein gewünschtes Ergebnis mit den dafür nötigen Einstellungen und Voraussetzungen verbinden. Sie braucht außerdem einen Weg, zu prüfen, ob die Einstellungen das beabsichtigte Ergebnis erzielt haben.

Das Register lässt sich als Rezeptbuch für die tatsächliche Küche verstehen. Zutaten und Reihenfolge müssen zur ausführenden Software passen. Ein Rezept, das eine notwendige Voraussetzung übersieht, kann plausibel klingen und die Anwendung dennoch unvollständig hinterlassen.

Das Register bestimmt nicht die Geschäftspolitik. Die Organisation muss weiterhin Freigabestruktur, Betriebsmodell und zulässige Ausnahmen entscheiden. Produktwissen kann diese Entscheidungen übersetzen; es löst Meinungsverschiedenheiten zwischen Beteiligten nicht allein durch einen längeren Implementierungsplan.

Für das Team wird Versionsabgleich zu einer nützlichen Frage. Welche Produktversion und Registerrevision liegen dem Vorschlag zugrunde? Welche Annahmen müssen nach einer Änderung der Anwendung erneut geprüft werden? Dies sind aus dem Ansatz abgeleitete Bewertungsfragen, keine Aussagen über eine bestimmte automatische Nachverfolgung im Produkt.

Sechs Rollen zerlegen die Arbeit in prüfbare Ergebnisse

Die Ankündigung vom 26. Oktober weist den Agenten unterschiedliche Aufgaben zu. Discovery untersucht den Istzustand; Design übersetzt Prozesse in Anwendungsentwürfe; Configuration baut Prototypen; Testing entwickelt passende Fälle; Integration bearbeitet Verbindungen zu vorhandenen Systemen; Innovation erkennt weitere Nutzungsmöglichkeiten. Die Trennung zählt, weil jede Phase ein Ergebnis liefern sollte, das ein zuständiger Prüfer verstehen kann.

Ein Team sollte nicht „die KI-Arbeit“ als undifferenziertes Gesamtpaket genehmigen müssen. Fachverantwortliche prüfen den Prozessentwurf, Anwendungsspezialisten die Konfiguration und Testverantwortliche die Abdeckung des beabsichtigten Verhaltens. Die Aufteilung nach Arbeitsergebnissen macht Diskussionen konkreter.

Die ersten beiden Spalten fassen angekündigte Rollen zusammen; die Prüffragen sind unsere vorgeschlagenen Kriterien. So lassen sich nützliche Ergebnisse untersuchen, ohne aus einem Rollennamen die Qualität jedes Resultats abzuleiten. Auch ein gut strukturierter Entwurf muss gegen die nutzende Organisation geprüft werden.

Eine Implementierung sollte die Verbindung zwischen Geschäftsanforderung und erfüllender Konfiguration erhalten. Prüfpunkte sind vorgeschlagene Bewertungsgrenzen, keine Aussage über einen bestimmten Oracle-Bildschirm.

Ein Finanzprototyp zeigt, ob das Design konkret genug ist

Das erste Szenario ist ein kleiner Finanzprozess in einer Testumgebung. Wählen Sie eine Freigaberegel mit Normalfall, Ausnahme und einem Fall, der zur Prüfung anhalten soll. Ziel ist festzustellen, ob das vorgeschlagene Design das Verhalten vor Beginn der Konfiguration ausdrücklich beschreibt.

Ein Team könnte etwa eine fiktive Lieferantenrechnung und zwei mögliche Genehmigende vorgeben. Das Design sollte erklären, wer welchen Fall bearbeitet und was bei fehlenden Pflichtinformationen passiert. Das sind Beispieleingaben, keine Beschreibung einer für diesen Artikel vorgenommenen Implementierung.

Nach der Designfreigabe prüfen Sie die Darstellung im Prototyp. Aussagekräftig ist die Beziehung zwischen Anforderung, relevanten Einstellungen und beobachtetem Testergebnis. Ein bestandener Normalfall ist ermutigend; die Ausnahme zeigt oft deutlicher, ob die Einrichtung die Geschäftsregel tatsächlich abbildet.

Hier werden auch Unklarheiten sichtbar. Nennen zwei Beteiligte unterschiedliche Freigabeschwellen, klärt eine generierte Konfiguration nicht die Richtlinienfrage. Zuerst muss der Konflikt gelöst und die genehmigte Regel festgehalten werden; danach wird die betroffene Arbeit neu erzeugt oder angepasst.

Ein Integrationstest macht die Arbeit zwischen Anwendungen sichtbar

Ein zweites Szenario ist eine begrenzte Verbindung zwischen Fusion und einem vorhandenen System. Wählen Sie ein Geschäftsobjekt und bestimmen Sie Datenhoheit, zu übertragende Felder und Fehlerbehandlung. Ein kleiner Umfang erleichtert die Unterscheidung zwischen einer nützlichen generierten Integration und einer großen Menge plausiblen Codes.

Angenommen, ein beispielhafter Kundendatensatz trifft wegen einer Wiederholung zweimal ein. Das Team muss entscheiden, ob das Ziel den bestehenden Datensatz aktualisiert, das Duplikat ablehnt oder einen neuen erzeugt. Richtiges Verhalten hängt vom fachlichen und technischen Vertrag ab und darf nicht implizit in einer generierten Implementierung bleiben.

Verlangen Sie Belege an den Grenzen. Was passiert bei fehlender Kennung, nicht erreichbarem Ziel oder einem unzulässigen Feldwert? Diese Fälle verwandeln eine Diskussion über eine erfolgreiche Vorführung in eine Prüfung des Betriebsverhaltens.

Oracles FSCR-Ankündigung beschreibt ausdrücklich Experten, die fertige Konfigurationen prüfen, Änderungen verlangen und die Bereitstellung freigeben. Dieselbe Disziplin gilt für Integrationen: erzeugte Arbeit prüfen, mit repräsentativen Daten testen und die Wiederherstellung bei einer fehlgeschlagenen Änderung festlegen. Schnellere Erstellung ist wertvoll, wenn die Verbindung für das spätere Wartungsteam verständlich bleibt.

Die bestehende Plattform erlaubt Bewertung vor Verfügbarkeit jedes neuen Agenten

Success Navigator verfügt bereits über ein öffentlich beschriebenes Produkterlebnis für Implementierung und Nutzung. Oracles Darstellung der Version 26.1 vom 11. Mai 2026 behandelt AI-Assist-Startseite, Updateplanung, Releasevorbereitung, Nutzungsfahrpläne und Starter Configuration. Diese bestehenden Fähigkeiten bilden den Kontext für die Agentenergänzungen im Oktober. Offizieller Beitrag zu 26.1.

Das dritte Szenario betrifft daher das nächste Update eines bestehenden Fusion-Kunden. Das Team benennt eine mögliche Funktion, ihren betroffenen Prozess und die Personen, die die Änderung verstehen müssen. Der vorgeschlagene Nutzen ist eine schlüssigere Einführungsentscheidung, statt eine Funktion allein wegen ihres Eintrags in einer Releaseliste zu aktivieren.

Binden Sie die Bewertung an ein beobachtbares Ergebnis. Soll eine Änderung einen Prüfprozess vereinfachen, halten Sie dessen heutigen Ablauf und das Verbesserungskriterium fest. Dann kann das Team entscheiden, ob die Funktion Konfigurations- und Testaufwand verdient, statt eine Empfehlung als Bereitstellungsanweisung zu behandeln.

Verfügbarkeit braucht dieselbe Genauigkeit. Die Oktoberankündigung nennt frühe Nutzer und zusätzliche Agenten, aber keinen universellen Termin allgemeiner Verfügbarkeit oder separaten Preis jeder Rolle. Klären Sie vor dem Versuch die tatsächlich verfügbaren Fähigkeiten und Zugangsbedingungen des Kontos.

Die 80 Prozent betreffen einen bestimmten Teil einer Implementierung

Oracle zitiert Lexington Health mit einer Verringerung bestimmter Design- und Konfigurationsaufwände um 80 Prozent durch den agentengestützten Ansatz. Die Kundenaussage steht in der Ankündigung vom 26. Oktober. Sie ist ein nützlicher Bericht eines frühen Anwenders mit einer klaren Grenze für die beschriebene Arbeit.

Diese Grenze bestimmt die Verwendung der Zahl. Gemeint sind nicht 80 Prozent weniger Dauer oder Budget für ein gesamtes ERP-Projekt, und sie belegt kein identisches Ergebnis bei einer anderen Organisation. Tests, Datenarbeit, Integration, Schulung und organisatorische Entscheidungen haben in Projekten unterschiedliche Anteile.

Eine Beispielrechnung zeigt die Bedeutung des Nenners. Entfallen bei einem hypothetischen Projekt 100 Stunden auf eine Designaktivität und 400 auf andere Arbeit, spart eine Reduktion dieser Aktivität um 80 Prozent insgesamt 80 von 500 Stunden, also 16 Prozent. Diese erfundenen Eingaben erklären die Rechnung; sie sind weder Lexington-Health-Projektdaten noch eine Schätzung von Oracles Leistung.

Nutzen Sie einen berichteten Prozentsatz, um eine Messfrage zu formulieren. Welche Tätigkeit wurde kürzer, was war die Ausgangsbasis und welche Arbeit blieb? So lässt sich die eigene begrenzte Aufgabe vergleichen, ohne eine attraktive Zahl in einen unpassenden Business Case zu übernehmen.

Eine erste Bewertung verfolgt eine Anforderung bis zum Ergebnis

Der erste Versuch sollte klein genug sein, um die vollständige Kette zu prüfen. Ein enger Prozess mit klaren Abnahmekriterien zeigt mehr als der breite Auftrag, „Finanzen zu implementieren“. Das folgende Verfahren ist ein Vorschlag zur Bewertung des angekündigten Ansatzes.

1. Zugang und Umfang bestätigen. Den Kontozugang über Success Navigator anfragen und klären, welche angekündigten Fähigkeiten für Organisation und Umgebung verfügbar sind.
2. Einen Geschäftsprozess wählen. Verantwortliche, Ziel und Ausnahmen nennen. Testumgebung und geeignete Beispieldaten verwenden.
3. Die Ausgangsbasis erfassen. Heutigen Aufwand dieser konkreten Aufgabe schätzen oder messen und nicht verwandte Projektarbeit aus dem Vergleich lassen.
4. Das vorgeschlagene Design prüfen. Unklare Anforderungen vor der Konfiguration lösen. Genehmigte Entscheidungen und Produktannahmen festhalten.
5. Prototyp und Integrationen untersuchen. Wichtige Einstellungen und Feldzuordnungen zum Design zurückverfolgen. Bei unklaren Verbindungen Änderungen verlangen.
6. Normal- und Ausnahmefälle ausführen. Erfolgreiche Arbeit, fehlende Angaben, doppelte Anfragen und passende Fehlerbedingungen prüfen. Ergebnisse statt nur generierter Erklärungen dokumentieren.
7. Über Erweiterung entscheiden. Nutzbaren Output, Prüfaufwand und Nacharbeit mit der Basis vergleichen. Vor größerem Umfang die laufende Wartungsverantwortung zuweisen.

Messen Sie die vollständige begrenzte Aufgabe einschließlich Prüfung und Nacharbeit. Weniger Generierungsaufwand ist ein Beitrag zum Ergebnis, kein Ersatz für die übrige Implementierung.

Der Prüfaufwand ist besonders aufschlussreich. Erzeugt ein Agent rasch eine Konfiguration, muss ein Spezialist zur Freigabe aber jede Annahme rekonstruieren, verschiebt die scheinbare Einsparung möglicherweise nur Arbeit. Umgekehrt können klares Design und reproduzierbare Tests die Prüfung erleichtern, selbst wenn die Generierung nicht sofort erfolgt.

Vertrauen entsteht durch eine Konfiguration, die Menschen erklären können

Oracles Ansatz bringt Produktwissen, ausführbare Einrichtungsanweisungen und spezialisierte Rollen in denselben Implementierungsprozess. Vielversprechend ist eine direktere Verbindung zwischen dem, was die Fachseite genehmigt hat, und dem Verhalten der Anwendungen. Wertvoll wird sie, wenn Prüfer sie untersuchen, testen und nach Projektende pflegen können.

Die richtige erste Frage ist daher konkret: Kann das Team eine echte Anforderung mit weniger vermeidbarer Arbeit und klarerem Ergebnis durch Design, Konfiguration und Tests führen? Ein erfolgreiches Ergebnis schafft eine solide Grundlage für die nächste Implementierungsentscheidung.

Quellen

• Oracles Ankündigung der agentengestützten Implementierungsplattform, 26. Oktober 2026: sechs Rollen, frühe Nutzung und Lexington-Health-Aussage.
• Ankündigung der Fusion Setup and Configuration Registry, 26. Oktober 2026: Umfang des Registers und Prüfmodell.
• Oracle AI Success Navigator 26.1, 11. Mai 2026: bestehende Plattformfähigkeiten.
• Produktseite zu Oracle AI Success Navigator und Oracle-Richtlinie zur Screenshot-Nutzung, geprüft am 27. Oktober 2026: öffentliche Oberfläche, Kontoanfrage und Bildnutzungsbedingungen.

Szenarien, vorgeschlagene Kriterien und das 500-Stunden-Beispiel dienen der Veranschaulichung. Der Kundenprozentsatz bleibt seiner Quelle und seinem Umfang zugeordnet; für diesen Artikel wurde kein Implementierungsbenchmark durchgeführt.

---

Telli.sh-Empfehlung: Halten Sie Workshopnotizen, genehmigte Entscheidungen und Referenzmaterial während des Projektverlaufs leicht auffindbar. Erstellen Sie ein Telli.sh-Konto, um Ihre Projektnotizen zu ordnen.