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
Den ersten Agenten klar abgrenzen.
Das gesamte Ökosystem von Tag eins an konzipieren
Die Beschränkung des Proof of Concept (PoC) на einen einzelnen Agenten hielt die anfänglichen Kosten und Risiken überschaubar. Die zugrunde liegende Architektur (Datenschicht, Integrationsmodell, Orchestrierungsansatz) war jedoch von Anfang an auf das gesamte Ökosystem ausgelegt. Diese Disziplin macht den Unterschied aus zwischen dem Aufbau eines echten Ökosystems und dem bloßen Kauf einer Reihe isolierter Tools.
Die Governance-Frage proaktiv und eindeutig beantworten
Indem jeder Agent als Empfehlungsgeber oder Entwurfsverfasser und nicht als Entscheidungsträger positioniert wurde, gestaltete sich der Dialog mit den Verantwortlichen für Compliance und Beschaffung absolut reibungslos. Der Mensch bleibt konzeptionell fest in den Prozess eingebunden (Human-in-the-Loop) – und das nicht erst durch das manuelle Überschreiben von Richtlinien. Wenn Governance-Stakeholder genau sehen, an welchen Stellen das menschliche Urteilsvermögen greift, beschleunigt dies die Implementierung und Akzeptanz erheblich.
In bestehende Systeme integrieren, statt sie zu ersetzen
Die direkte Aufsetzung auf SAP ERP, SAP Ariba und der AWS-Umgebung des Kunden eliminierte die typischen Akzeptanzbarrieren, an denen die meisten KI-Projekte im Einkauf scheitern. Der Kunde musste weder eine neue parallele Plattform verwalten, noch Daten in ein externes System migrieren oder eine separate Lieferantenbeziehung pflegen. Die Agenten agieren direkt in den Systemen, denen das Team bereits vertraut.
Die Bereitstellung innerhalb der
EU war eine Grundvoraussetzung, keine Präferenz
Für diesen Kunden war die gemeinschaftliche Entwicklung (Co-Development) mit einem Nearshore-Partner innerhalb der EU eine strikte Anforderung, die die Anbieterauswahl noch vor jeder Architekturbesprechung maßgeblich bestimmte. Sie beeinflusste direkt, was wie schnell und unter welchem Compliance-Rahmen aufgebaut werden konnte. Die Einbindung dieser Anforderung in das Bereitstellungsmodell von Beginn an sicherte den Projektverlauf und räumte potenzielle Risiken in der Endphase frühzeitig aus.
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 agentisches Sourcing-Ökosystem?
Ein agentisches Sourcing-Ökosystem ist ein Netzwerk spezialisierter KI-Agenten, von denen jeder einen klar definierten Schritt des Source-to-Contract-Prozesses übernimmt – von der Konsolidierung der Eingabedaten über die Lieferantenauswahl, die Erstellung von RFx-Dokumenten, die Angebotsbewertung und die Vorbereitung von Verhandlungen bis hin zur Risikoüberwachung und Vertragserstellung. Die Agenten nutzen eine gemeinsame Daten- und Integrationsschicht, werden über ein Orchestrierungsmodell koordiniert und übergeben Entscheidungen, die menschliches Urteilsvermögen erfordern, an das Sourcing-Team.
-
Worin unterscheidet sich ein agentisches Ökosystem von einer Beschaffungsplattform?
Eine Beschaffungsplattform ist ein lizenziertes System, an dessen Vorgaben Sie Ihre Prozesse anpassen müssen. Ein agentisches Ökosystem wird individuell auf Ihre bestehenden Prozesse zugeschnitten, in Ihrer eigenen Cloud-Umgebung bereitgestellt und direkt in Ihr ERP integriert, anstatt parallel dazu zu laufen. Der Unterschied ist auch operativ entscheidend: Sie besitzen das System, Ihre Daten verlassen Ihre Umgebung nicht, und die Architektur lässt sich nach Warengruppen erweitern, ohne zusätzliche Module erwerben zu müssen.
-
Was bedeutet der Aufbau eines Ökosystems im Kontext von Procurement AI?
Der Aufbau eines Ökosystems bedeutet, KI für den Einkauf als gemeinsame, erweiterbare Grundlage zu entwickeln – nicht als Sammlung isolierter Einzellösungen. Jeder Agent greift auf dieselbe Daten- und Integrationsschicht zu. Neue Agenten oder Warengruppen bauen auf bereits validierten Komponenten auf. Dieser kumulative Effekt – jeder weitere Agent erfordert weniger Aufwand als der vorherige – macht daraus eine strategische Investition in Fähigkeiten statt eines einzelnen Projekts.
-
Warum benötigte ein Spezialchemiehersteller ein agentisches Sourcing-Ökosystem?
Die Komplexität der Warengruppen und das Beschaffungsvolumen waren über das hinausgewachsen, was ein manueller, von Einkäufern gesteuerter RFx-Prozess effizient bewältigen konnte. Für jedes Sourcing-Projekt mussten Daten aus mehreren SAP-Systemen manuell zusammengeführt und abgeglichen werden. Die Lieferantenvorauswahl beruhte auf individuellem Wissen. Verhandlungen wurden ohne Zugriff auf belastbare Kostentreiberdaten vorbereitet. Das Team verfügte über hohe Fachkompetenz – doch der Prozess band Kapazitäten, die besser für die kommerzielle Strategie eingesetzt worden wären.
-
Wo werden die Beschaffungsdaten in dieser Architektur gespeichert?
Nirgendwo außerhalb der eigenen Umgebung des Kunden. Das Ökosystem wird innerhalb des AWS-Tenants des Kunden betrieben und folgt den unternehmensweiten Richtlinien zur Zugriffskontrolle. Lieferanteninformationen, Verträge, kommerzielle Konditionen und Beschaffungsstrategien bleiben innerhalb des Sicherheitsperimeters 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 agentischen Sourcing-Ökosystems entscheidend?
Vier Faktoren bestimmen in der Regel den Projekterfolg: den ersten Agenten klar abgrenzen, die gemeinsame Datenbasis von Beginn an für das gesamte Ökosystem konzipieren, bestehende ERP-Systeme integrieren statt eine parallele Plattform aufzubauen und menschliche Entscheidungsprozesse bewusst in der Architektur verankern. Projekte, die jeden Agenten als eigenständige Lösung entwickeln, schaffen selten ein Ökosystem – sondern lediglich eine Sammlung einzelner Tools.
-
Wie lange dauert es bis zu einem funktionsfähigen Proof of Concept?
Der Ansatz von Digicode basiert auf einem schrittweisen Vorgehensmodell: 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 Umsetzung gestartet. Da alle weiteren Agenten auf derselben Grundlage aufbauen, verkürzt sich der Entwicklungsaufwand mit dem Wachstum des Ökosystems. Der Proof of Concept liefert funktionsfähige Agenten für einen klar definierten Workflow, bevor über eine umfassendere Einführung entschieden wird.
-
Wie verarbeitet ein Online-Zahlungsaggregator mehrere Zahlungsanbieter?
Ein Online-Zahlungsaggregator nutzt eine Abstraktionsschicht, um Unterschiede zwischen Zahlungsdienstleistern – etwa APIs, Datenmodelle, Gebührenstrukturen und Verhaltensweisen – hinter einer einheitlichen Schnittstelle zu vereinheitlichen. Die Geschäftslogik arbeitet mit dieser Schnittstelle statt mit einzelnen Anbietern. Dadurch können neue Zahlungsdienstleister integriert werden, ohne die zentrale Transaktionslogik anzupassen, und eine konsistente Performance über alle Anbieter hinweg bleibt gewährleistet.
-
Welche Rolle übernimmt der Sourcing Manager in einem agentischen Ökosystem?
Der Sourcing Manager bleibt während des gesamten Prozesses der Entscheidungsträger. Die Agenten empfehlen, erstellen Entwürfe, analysieren und bereiten Entscheidungen vor – die Auswahl der Lieferanten, die Verhandlungsstrategie und die Vertragsunterzeichnung verbleiben jedoch beim Menschen. Diese Architektur ist bewusst so konzipiert: Sie reduziert den administrativen Aufwand, ersetzt jedoch nicht das geschäftliche Urteilsvermögen. Genau dieser Ansatz schafft auch Vertrauen bei den Verantwortlichen für Governance und Compliance.