Agentisches
Sourcing-Ökosystem für einen globalen Chemiehersteller
Ein weltweit tätiger Spezialchemiehersteller mit SAP ERP und Ariba war über seinen manuellen Beschaffungsprozess hinausgewachsen. Die Erstellung von RFx-Unterlagen nahm Stunden in Anspruch. Die Vorauswahl von Lieferanten beruhte auf dem Wissen einzelner Mitarbeitender. Die Vorbereitung von Verhandlungen erfolgte ohne belastbare Datengrundlage.
Digicode entwickelte ein agentisches Sourcing-Ökosystem – ein vernetztes Team spezialisierter KI-Agenten, von denen jeder einen Schritt des Source-to-Contract-Prozesses übernimmt. Die Lösung wird in der AWS-Umgebung des Kunden bereitgestellt und direkt in SAP und Ariba integriert. Starten Sie mit einem Agenten. Validieren Sie die Grundlage. Erweitern Sie das System, ohne es neu aufbauen zu müssen.
Beispielszenario: Diese Case Study basiert auf einer realen Discovery-Phase und einer vorgeschlagenen Lösungsarchitektur, die gemeinsam mit einem potenziellen Enterprise-Kunden entwickelt wurde. Das Projekt befindet sich noch in einer frühen Phase. Die dargestellten Ergebnisse sind prognostizierte Zielwerte und keine gemessenen Resultate. Kundendetails wurden anonymisiert.
Überblick
Für Einkaufsverantwortliche, die führende Plattformen für Partnerökosysteme vergleichen, liegt der entscheidende Unterschied in der Ownership: Eine lizenzierte Plattform verlangt, dass Sie Ihre Prozesse an ihr System anpassen.
Ein maßgeschneidertes agentisches Ökosystem hingegen richtet sich nach Ihren bestehenden Abläufen.
Einkaufsorganisationen dieser Größenordnung stehen vor einem strukturellen Widerspruch. Das Sourcing-Team verfügt über das Know-how für komplexe Kategorien, Lieferantenmanagement und kommerzielle Verhandlungen. Gleichzeitig verbringen die Mitarbeitenden den Großteil ihrer Zeit mit Aufgaben, die ein gut konzipiertes System übernehmen sollte: Daten aus verschiedenen SAP-Modulen zusammenführen, manuell abgleichen, RFx-Unterlagen erstellen und Lieferantenrisiken nur vierteljährlich statt fortlaufend bewerten.
Genau an der Lücke zwischen den Fähigkeiten des Teams und den Anforderungen des Prozesses setzte Digicode an.
Nicht mit einer Funktionsliste – sondern mit einer Frage: Was würde sich verändern, wenn der Koordinationsaufwand entfiele?
Die Antwort war ein modulares agentisches Ökosystem auf der bestehenden Infrastruktur des Kunden. Jeder Agent übernimmt einen einzelnen Schritt im Sourcing-Workflow. Alle Agenten greifen auf eine gemeinsame Daten- und Integrationsschicht zu. Genau das macht aus der Lösung ein Ökosystem statt einer isolierten Einzellösung. Jeder weitere Agent – oder jede zusätzliche Warengruppe – baut auf der bestehenden Grundlage auf.
Über den Kunden
Der Kunde ist eine Tochtergesellschaft eines international bekannten Chemiekonzerns, der in zahlreichen Regionen und über verschiedene Warengruppen hinweg tätig ist. Das Unternehmen beschäftigt mehr als 10.000 Mitarbeitende. Beschaffung und Vertragsmanagement basieren auf SAP ERP und SAP Ariba, unterstützt durch eine zentrale Stammdatenbasis für den Einkauf sowie historische Daten in SAP Business Warehouse.
Als Hersteller von Industriechemikalien ist die Beschaffung mit besonderen Anforderungen verbunden: tiefgehende Warengruppenexpertise, hohe Anforderungen an die Lieferantenqualifizierung, regulatorische Vorgaben sowie ein Beschaffungsvolumen, das sich mit einem manuellen RFx-Prozess nicht effizient bewältigen lässt. Das Team verfügte über das notwendige Fachwissen – der Prozess war der eigentliche Engpass.
Als Unternehmen mit Hauptsitz in der EU stellte der Kunde zudem klare Anforderungen an Datenresidenz, Zugriffskontrolle und den Standort der gemeinsamen Entwicklung. Diese Vorgaben prägten das Projekt bereits ab den ersten Gesprächen und schlossen zahlreiche Anbieter aus, noch bevor die Architektur überhaupt diskutiert wurde.
Über Digicode
Digicode ist ein KI-gestütztes Unternehmen für Produktentwicklung und Technologieberatung, das maßgeschneiderte Softwarelösungen für Enterprise-Unternehmen und wachstumsstarke Unternehmen konzipiert, entwickelt, modernisiert und skaliert. Seit mehr als zwei Jahrzehnten liefert das Team Enterprise-Lösungen für Unternehmen wie Microsoft, Bosch, Cisco, SAP und PwC in den Bereichen FinTech, Fertigung, Gesundheitswesen und Handel – mit Entwicklungszentren weltweit.
Im Bereich Procurement konzentriert sich Digicode auf die Entwicklung agentischer Sourcing-Ökosysteme: LLM-basierte KI-Agenten, die direkt in bestehende ERP-, Sourcing- und Cloud-Infrastrukturen integriert werden, um den Source-to-Contract-Prozess zu automatisieren und zu erweitern, anstatt bestehende Systeme zu ersetzen. Ausschlaggebend für die Zusammenarbeit waren Digicodes Integrationsansatz, die Delivery-Kompetenz innerhalb der EU sowie eine Architektur, die auf Erweiterbarkeit ausgelegt ist: mit einem einzelnen Agenten starten, die Grundlage validieren und das Ökosystem schrittweise ausbauen, ohne von vorn beginnen zu müssen.
Die Situation
Im Rahmen der Discovery-Phase wurden fünf zentrale Reibungspunkte identifiziert. Für sich genommen war jeder davon beherrschbar. Zusammengenommen zeichneten sie jedoch das Bild eines Betriebsmodells, in dem hochqualifizierte Fachkräfte einen erheblichen Teil ihrer Zeit für Aufgaben aufwenden mussten, die kein Spezialwissen erfordern sollten.
-
Fragmentierte RFx-Datenbasis
Die Zusammenstellung der Informationen für eine einzelne RFx erforderte das manuelle Zusammenführen und Abgleichen von Daten aus früheren Ausschreibungen, Verträgen und Beschaffungsstammdaten, die über SAP Business Warehouse und angrenzende Systeme verteilt waren. Es gab keine konsolidierte Datenbasis. Jeder Sourcing-Vorgang begann von Grund auf.
-
Lieferantenauswahl auf Basis von Erfahrungswissen
Die Identifikation geeigneter Lieferanten beruhte überwiegend auf dem Wissen einzelner Sourcing-Spezialisten und ad hoc durchgeführten Marktanalysen. Historische Leistungsdaten waren zwar in den Systemen vorhanden, wurden jedoch nicht systematisch genutzt, da sie nicht mit dem Shortlisting-Prozess verknüpft waren.
-
Verhandlungen ohne belastbare Datengrundlage
Wenn Lieferanten Preiserhöhungen begründeten, verfügten die Sourcing-Manager nur über eingeschränkte Möglichkeiten, diese Aussagen anhand aktueller Marktindizes und relevanter Kostentreiber zu überprüfen. Sie verhandelten ohne belastbare Daten – eine vermeidbare Ausgangslage.
-
Keine skalierbare Grundlage für KI
Das Team suchte mehr als nur eine isolierte Einzellösung. Benötigt wurde eine Architektur, die sich Warengruppe für Warengruppe erweitern lässt, ohne Integrationen jedes Mal neu aufbauen zu müssen. Alle bis dahin evaluierten Lösungen erforderten für jede Erweiterung eine separate Implementierung.
-
Compliance-Anforderungen
schlossen die meisten Lösungen ausDie Lösung musste innerhalb der AWS-Umgebung des Kunden betrieben, gemeinsam mit Entwicklungsteams innerhalb der EU umgesetzt und direkt in SAP ERP sowie SAP Ariba integriert werden. Nicht über eine Middleware angebunden, sondern direkt integriert. Diese Anforderung schränkte die Auswahl geeigneter Anbieter erheblich ein.
Der Mensch behält die Kontrolle
Jeder KI-Agent innerhalb des Ökosystems unterstützt als Empfehlungssystem und Entwurfsassistent – nicht als Entscheidungsträger. Sourcing-Manager genehmigen Lieferanten-Shortlists, geben RFx-Prozesse frei, steuern Verhandlungen und unterzeichnen Verträge. Die Agenten übernehmen den Koordinationsaufwand sowie die Datenaufbereitung, während die kommerziellen Entscheidungen weiterhin beim Team liegen. Diese klare Rollenverteilung war entscheidend für die Akzeptanz der Lösung: Governance- und Compliance-Verantwortliche konnten jederzeit nachvollziehen, an welchen Stellen der Mensch eingebunden bleibt. So gewann die Einkaufsleitung das Vertrauen, den Schritt von der Evaluierung zu einem verbindlichen Proof of Concept zu gehen.
Auf der bestehenden Infrastruktur des Kunden aufgebaut
Das gesamte Ökosystem wird innerhalb der AWS-Umgebung des Kunden betrieben. SAP ERP und SAP Ariba sind dabei keine angebundenen Systeme, sondern bilden die zentrale Datengrundlage. Historische Ausschreibungen, Beschaffungsstammdaten und Vertragsarchive versorgen die KI-Agenten direkt mit Informationen. Es werden keine Daten an öffentliche KI-Plattformen übertragen. Kein externes Modell wird mit Beschaffungsdaten trainiert. Lieferantenbeziehungen, Vertragskonditionen und Beschaffungsstrategien bleiben vollständig innerhalb der eigenen Infrastruktur des Kunden.
Für Erweiterung konzipiert – nicht zum Ersetzen
Der entscheidende Unterschied zwischen einem Ökosystem und einer Einzellösung liegt in der Architektur. Der erste KI-Agent erfordert den größten Implementierungsaufwand. Sobald die gemeinsame Datenbasis auf Basis von SAP und Ariba validiert und das Integrationsmodell in der AWS-Umgebung etabliert ist, kann jeder weitere Agent dieselbe Grundlage nutzen. Der zweite Agent lässt sich mit weniger Aufwand implementieren als der erste, der fünfte mit weniger Aufwand als der zweite. Genau dieser kumulative Effizienzgewinn überzeugte das Projektteam davon, das Vorhaben konsequent weiterzuverfolgen.
Stufenweises Projektmodell
Das Projekt folgt einem bewusst strukturierten Vorgehen: Zunächst werden Anwendungsfall und Umfang des ersten
KI-Agenten präzise definiert. Anschließend werden Integrationsaufwand und Kosten bewertet sowie Governance-
und Delivery-Modell abgestimmt. Darauf folgen Lösungsdesign, Prompt Engineering und Datenintegration. Der Proof of Concept liefert einen funktionsfähigen KI-Agenten für einen klar abgegrenzten Workflow, bevor über einen umfassenderen Rollout entschieden wird.
Die Lösung
Digicode schlug eine Proof-of-Concept-first-Architektur vor. Keine Plattform. Kein umfassender KI-Rollout. Stattdessen ein einzelner KI-Agent mit klar definiertem Einsatzbereich, validiert in der produktiven SAP- und Ariba-Umgebung des Kunden und von Beginn an so konzipiert, dass sich das übrige Ökosystem später ohne Neuaufbau der technischen Grundlage erweitern lässt.
Acht Agenten.
Eine gemeinsame Grundlage
Das agentische Sourcing-Ökosystem besteht aus einem koordinierten Team spezialisierter KI-Agenten, von denen jeder einen klar definierten Schritt im Source-to-Contract-Prozess übernimmt. Alle Agenten greifen auf eine gemeinsame Daten- und Integrationsschicht zu. Sie übergeben Aufgaben aneinander. An den Menschen eskalieren sie nur dann, wenn eine Entscheidung dies erfordert.
|
Agent |
Beschreibung |
|---|---|
|
RFx Input Agent Konsolidiert SAP-Daten |
Führt historische Ausschreibungs-, Vertrags- und Stammdaten aus SAP Business Warehouse zusammen und überführt sie in eine standardisierte, sofort nutzbare Datengrundlage – der manuelle Abgleich entfällt vollständig |
|
Sourcing Agent Erstellt |
Identifiziert und priorisiert geeignete Lieferanten anhand historischer Leistungsdaten und aktueller Markttrends – statt auf das Wissen einzelner Sourcing-Spezialisten angewiesen zu sein |
|
RFx Agent Erstellt RFx-Dokumente |
Generiert RFP- und RFQ-Dokumente auf Basis freigegebener Vorlagen und befüllt sie automatisch mit strukturierten Daten aus der zentralen Datengrundlage |
|
Evaluation Agent Bewertet Angebote |
Analysiert und bewertet eingehende Lieferantenangebote anhand definierter Kriterien sowie historischer Vergabedaten |
|
Negotiation Agent Bereitet |
Unterstützt Sourcing-Manager mit Markt- und Kostentreiberanalysen, Szenariomodellen sowie |
|
Risk Agent Überwacht die Lieferantensituation |
Überwacht kontinuierlich die finanzielle Stabilität von Lieferanten, Sanktionsrisiken, geopolitische Entwicklungen, ESG-Entwicklungen sowie den Status relevanter Zertifizierungen. |
|
Contract Agent Erstellt und prüft Vertragsklauseln |
Erstellt und überprüft Vertragsdokumente auf Basis freigegebener juristischer Formulierungen und Unternehmensrichtlinien und kennzeichnet Abweichungen bereits bei der Erstellung |
|
Orchestration Layer Koordiniert und eskaliert |
Steuert die Zusammenarbeit zwischen den KI-Agenten und eskaliert ausschließlich Entscheidungen, die menschliches Urteilsvermögen erfordern. Freigaben, Lieferantenauswahl und Vertragsunterzeichnung verbleiben beim Sourcing-Manager |
Agent
RFx Input Agent
Konsolidiert SAP-Daten
Beschreibung
Führt historische Ausschreibungs-, Vertrags- und Stammdaten aus SAP Business Warehouse zusammen und überführt sie in eine standardisierte, sofort nutzbare Datengrundlage – der manuelle Abgleich entfällt vollständig
Agent
Sourcing Agent
Erstellt
Lieferanten-Shortlists
Beschreibung
Identifiziert und priorisiert geeignete Lieferanten anhand historischer Leistungsdaten und aktueller Markttrends – statt auf das Wissen einzelner Sourcing-Spezialisten angewiesen zu sein
Agent
RFx Agent
Erstellt RFx-Dokumente
Beschreibung
Generiert RFP- und RFQ-Dokumente auf Basis freigegebener Vorlagen und befüllt sie automatisch mit strukturierten Daten aus der zentralen Datengrundlage
Agent
Evaluation Agent
Bewertet Angebote
Beschreibung
Analysiert und bewertet eingehende Lieferantenangebote anhand definierter Kriterien sowie historischer Vergabedaten
Agent
Negotiation Agent
Bereitet
Kostentreiberdaten auf
Beschreibung
Unterstützt Sourcing-Manager mit Markt- und Kostentreiberanalysen, Szenariomodellen sowie
BATNA-Positionierung als Vorbereitung auf Lieferantengespräche
Agent
Risk Agent
Überwacht die Lieferantensituation
Beschreibung
Überwacht kontinuierlich die finanzielle Stabilität von Lieferanten, Sanktionsrisiken, geopolitische Entwicklungen, ESG-Entwicklungen sowie den Status relevanter Zertifizierungen.
Agent
Contract Agent
Erstellt und prüft Vertragsklauseln
Beschreibung
Erstellt und überprüft Vertragsdokumente auf Basis freigegebener juristischer Formulierungen und Unternehmensrichtlinien und kennzeichnet Abweichungen bereits bei der Erstellung
Agent
Orchestration Layer
Koordiniert und eskaliert
Beschreibung
Steuert die Zusammenarbeit zwischen den KI-Agenten und eskaliert ausschließlich Entscheidungen, die menschliches Urteilsvermögen erfordern. Freigaben, Lieferantenauswahl und Vertragsunterzeichnung verbleiben beim Sourcing-Manager
Ergebnisse und erwarteter Mehrwert
Worauf die Architektur ausgelegt ist
Schnellere RFx-Erstellung
Durch die automatisierte Zusammenführung historischer Ausschreibungs- und Vertragsdaten lässt sich der Zeitaufwand für die Vorbereitung von RFx-Unterlagen voraussichtlich deutlich reduzieren. Der manuelle Datenabgleich wird durch eine standardisierte, sofort nutzbare Datengrundlage ersetzt, die nicht jedes Mal neu aufgebaut werden muss.
Fundiertere Lieferanten-Shortlists
Die systematische Nutzung historischer Leistungsdaten und aktueller Marktinformationen reduziert die Abhängigkeit vom Wissen einzelner Sourcing-Spezialisten. Das Ergebnis sind nachvollziehbare und belastbare Lieferanten-Shortlists statt auf Einzelerfahrungen basierender Entscheidungen.
Stärkere Verhandlungsposition
Sourcing-Manager gehen mit belastbaren Markt- und Kostentreiberdaten in Lieferantengespräche, anstatt die Darstellung von Preiserhöhungen durch den Lieferanten ungeprüft übernehmen zu müssen. Genau dieses Informationsgefälle entscheidet häufig darüber, ob Verhandlungen erfolgreich verlaufen oder nicht.
Eine Grundlage, die an Wert gewinnt
Da alle Agenten dieselbe Daten- und Integrationsschicht nutzen, erfordert jeder weitere Agent deutlich weniger Aufwand als der vorherige. Die Architektur ist ein Asset, das kontinuierlich an Wert gewinnt – keine Reihe einzelner Projekte, die jedes Mal wieder bei null beginnen.
Kundenstimme
Überzeugt hat uns nicht ein einzelner Anwendungsfall, sondern die Architektur. Ein RFx-Agent nutzt dieselbe Datengrundlage wie künftige Agenten für Verhandlungen oder Szenarioanalysen. Dadurch wurde klar: Das ist eine Investition in Fähigkeiten, nicht in eine Einzellösung. Genau das gab dem Team die Sicherheit für den nächsten Schritt – einen echten Proof of Concept
– Procurement Digital Lead, potenzieller Kunde
Warum es funktioniert
Die Disziplin hinter der Architektur
Saubere Architektur
vor der ersten Integration
Die Trennung der Kernlogik vom anbieterspezifischen Code, noch bevor
die erste Integration begann, war die Entscheidung, die alles Weitere deutlich einfacher machte. Genau diesen Schritt überspringen viele Teams, weil er bei zwei Anbietern unnötig erscheint. Bei fünfzehn
sieht das ganz anders aus.
Sicherheit in der Architektur,
nicht als nachträgliche Ergänzung
Datenintegrität und die Trennung von Zugriffsrechten waren von Anfang an fester Bestandteil der Architektur. Sicherheit, die in der Architektur verankert ist, bleibt zuverlässig. Sicherheit, die erst nachträglich ergänzt wird, versucht lediglich, bereits entstandene Lücken zu schließen.
Ausfallsicherheit als
Designprinzip, nicht als Feature
Zuverlässigkeit war von Beginn an eine grundlegende Anforderung und kein Punkt
für das Backlog. Der Unterschied zeigt sich spätestens dann, wenn ein Provider im Produktivbetrieb ausfällt und die Plattform dennoch ohne manuelle Eingriffe stabil weiterläuft.
Standardisierung als geschäftliche Entscheidung
Die Entscheidung, die Integration aller
Provider zu standardisieren, anstatt sich an
die individuellen Anforderungen jedes einzelnen anzupassen, war ebenso eine geschäftliche wie eine technische Entscheidung. Jede weitere Integration profitierte von allen vorherigen. Das Framework hatte sich bereits mit dem vierten Provider bezahlt gemacht.
Wachstum
als Beweis
Das kontinuierliche Wachstum bei Merchants, Betreibern und integrierten Payment Service Providern ist das deutlichste Signal dafür, dass die Plattform ein echtes Problem gelöst hat – und zwar auf die richtige Weise.
Was als
Nächstes kommt
Die nächste Phase umfasst die Planung und Entwicklung des ersten Agenten: die Finalisierung der funktionalen Anforderungen, die Bestätigung der Integrationsfähigkeit mit SAP und Ariba, die Abstimmung des Governance-Modells und der Vertragsbedingungen sowie den Beginn von Lösungsdesign, Prompt Engineering und Datenintegration.
Sobald der erste Agent im Produktivbetrieb validiert ist, ist der weitere Plan klar: Dieselbe Architektur wird auf die übrigen Agenten des Ökosystems ausgeweitet und deckt den gesamten Source-to-Contract-Prozess ab – vom Start eines RFx bis zur Vergabe und Vertragsunterzeichnung. Dieselbe Grundlage, zusätzliche Funktionen. Genau das bedeutet der Aufbau eines Ökosystems in der Praxis.
Verwandte Ressourcen
FAQ
-
Was ist ein agentenbasiertes Sourcing-Ökosystem?
Ein agentenbasiertes Sourcing-Ökosystem ist ein Netzwerk spezialisierter KI-Agenten, die jeweils einen klar definierten Schritt im Source-to-Contract-Prozess übernehmen – von der Konsolidierung von Eingabedaten über die Lieferantenvorauswahl, die Erstellung von RFx-Dokumenten, die Angebotsbewertung und die Vorbereitung von Verhandlungen bis hin zur Risikoüberwachung und Vertragserstellung. Alle Agenten greifen auf eine gemeinsame Daten- und Integrationsschicht zu, werden über ein Orchestrierungsmodell koordiniert und übergeben Entscheidungen, die menschliches Urteilsvermögen erfordern, an das Beschaffungsteam.
-
Wodurch unterscheidet sich ein agentenbasiertes Ökosystem von einer Beschaffungsplattform?
Eine Beschaffungsplattform ist ein lizenziertes System, an dessen Vorgaben Sie Ihre Prozesse anpassen müssen. Ein agentenbasiertes Ökosystem wird individuell auf Ihre bestehenden Prozesse zugeschnitten, in Ihrer eigenen Cloud-Umgebung bereitgestellt und direkt in Ihr ERP integriert, anstatt parallel dazu zu arbeiten. Der Unterschied ist entscheidend: Sie besitzen das System, Ihre Daten verlassen Ihre Umgebung nicht, und die Architektur lässt sich nach Kategorien erweitern, ohne dass zusätzliche Module erworben werden müssen.
-
Was bedeutet der Aufbau eines Ökosystems im Kontext von KI für die Beschaffung?
Der Aufbau eines Ökosystems bedeutet, KI für die Beschaffung als gemeinsame, erweiterbare Grundlage zu entwickeln – und nicht als Sammlung isolierter Einzellösungen. Jeder Agent nutzt dieselbe Daten- und Integrationsschicht. Neue Agenten oder Kategorien bauen auf bereits validierten Komponenten auf. Dieser kumulative Effekt – bei dem jeder weitere Agent weniger Aufwand erfordert als der vorherige – macht daraus eine Investition in Fähigkeiten statt eines einzelnen Projekts.
-
Warum benötigte ein Hersteller von Spezialchemikalien ein agentenbasiertes Sourcing-Ökosystem?
Die Komplexität der Warengruppen und das Beschaffungsvolumen hatten den Punkt erreicht, an dem ein manueller RFx-Prozess unter Leitung der Einkäufer nicht mehr effizient bewältigt werden konnte. Für jedes Sourcing-Projekt mussten Daten aus mehreren SAP-Systemen manuell zusammengeführt und abgeglichen werden. Die Vorauswahl geeigneter Lieferanten beruhte auf individuellem Erfahrungswissen, und die Vorbereitung von Verhandlungen erfolgte ohne Zugriff auf belastbare Daten zu Kostenfaktoren. Das Team verfügte über hohe Expertise – doch die Prozesse banden Kapazitäten, die besser für die kommerzielle Strategie eingesetzt worden wären.
-
Wo werden die Beschaffungsdaten in dieser Architektur gespeichert?
Ausschließlich in der eigenen Umgebung des Kunden. Das Ökosystem wird innerhalb des AWS-Tenants des Kunden betrieben, wobei die Zugriffsrechte den unternehmensweiten Sicherheitsrichtlinien entsprechen. Lieferanteninformationen, Verträge, kommerzielle Konditionen und Beschaffungsstrategien bleiben vollständig innerhalb der Sicherheitsgrenzen des Unternehmens. Es werden keine Daten an öffentliche KI-Plattformen übertragen, und kein externes Modell wird mit den Beschaffungsdaten des Kunden trainiert.
-
Welche Faktoren sind beim Aufbau eines agentenbasierten Sourcing-Ökosystems besonders wichtig?
Vier Faktoren entscheiden in der Regel über den Projekterfolg: eine klar abgegrenzte Definition des ersten Agenten, der Aufbau einer gemeinsamen Datenbasis für das gesamte Ökosystem bereits ab dem ersten Tag, die Integration in bestehende ERP-Systeme statt der Entwicklung einer parallelen Plattform sowie die bewusste Verankerung menschlicher Entscheidungen in der Architektur. Projekte, die jeden Agenten als eigenständige Entwicklung behandeln, schaffen selten ein Ökosystem – sondern lediglich eine Sammlung einzelner Werkzeuge.
-
Wie lange dauert es bis zu einem funktionsfähigen Proof of Concept?
Digicode verfolgt einen stufenweisen Ansatz: Zunächst werden der erste Agent definiert und in der produktiven SAP- und Ariba-Umgebung des Kunden validiert, anschließend das Integrationsmodell bestätigt und danach die Entwicklung gestartet. Da alle weiteren Agenten auf derselben Grundlage aufbauen, verkürzt sich die Entwicklungszeit mit dem Wachstum des Ökosystems. Der Proof of Concept liefert funktionierende Agenten für einen klar definierten Workflow, bevor über einen umfassenderen Rollout entschieden wird.
-
Wie verwaltet ein Online-Zahlungsaggregator mehrere Anbieter?
Ein Online-Zahlungsaggregator nutzt eine Abstraktionsschicht, die die Unterschiede zwischen verschiedenen Payment Service Providern – etwa APIs, Datenmodelle, Gebührenstrukturen und Verhaltensweisen – hinter einer einheitlichen Schnittstelle vereinheitlicht. Die Geschäftslogik arbeitet ausschließlich mit dieser Schnittstelle und nicht direkt mit den einzelnen Providern. Dadurch können neue Anbieter integriert werden, ohne die Kernlogik der Transaktionsverarbeitung anzupassen, und gleichzeitig bleibt eine konsistente Leistung über alle Provider hinweg gewährleistet.
-
Welche Rolle übernimmt der Sourcing Manager in einem agentenbasierten Ökosystem?
Der Sourcing Manager bleibt während des gesamten Prozesses die entscheidende Instanz. Die Agenten empfehlen, erstellen Entwürfe, analysieren und bereiten vor, doch die Auswahl der Lieferanten, die Verhandlungsstrategie und die Vertragsunterzeichnung bleiben in menschlicher Hand. Dieses Architekturprinzip ist bewusst gewählt: Es reduziert den administrativen Aufwand, nicht das kommerzielle Urteilsvermögen. Genau dieser Ansatz schafft auch Vertrauen bei Governance- und Compliance-Verantwortlichen.