Agent Operating Model
Aus einem einzelnen KI-Pilot wird ein kontrolliert betriebener Geschäftsprozess.
Dafür braucht es klare Zuständigkeiten: wer Agenten und Tools baut, wer sie freigibt und wer für den laufenden Betrieb geradesteht. Spätestens wenn mehrere Agenten in Ihren Systemen arbeiten, regelt das ein Agent Operating Model.
Ein Agent Operating Model ist das Governance- und Organisationsmodell für KI-Agenten im Unternehmen. Es legt fest, wer Agenten und Agent-Tools entwickelt, wer Systemzugriffe, Policies und Releases freigibt, wer im Tagesgeschäft Sonderfälle entscheidet und wer Betrieb, Monitoring und Ergebnisse verantwortet. Nexus bildet diese Rollen technisch ab.
Ein solches Modell muss nicht am Anfang stehen. Es entsteht, wenn der erste Prozess produktiv läuft und der zweite auf dessen Tools, Policies und Erfahrungen aufbaut. Spätestens wenn mehrere Fachbereiche eigene Agenten wollen, wird es aber zur Voraussetzung.
Wer baut, wer freigibt, wer betreibt.
Eine typische Rollenverteilung. Die Namen der Teams unterscheiden sich von Unternehmen zu Unternehmen, die Aufgaben kaum.
| Rolle | Verantwortet | In Nexus |
|---|---|---|
| Process Owner (Fachbereich) | Fachliche Regeln, Schwellenwerte und Ziel-KPIs des Prozesses | Policies für Guarded Autonomy, Outcome-Dashboards |
| Builder-Team oder KI-CoE | Agents und Agent-Tools bauen, testen und weiterentwickeln | Builder, Evaluation, Versionen in DEV und TEST |
| Verantwortliche der Fachsysteme, etwa SAP oder Salesforce | Welche Systemfunktionen als Tool freigegeben werden, mit welchen Berechtigungen | Tool-Freigabe, technische Benutzer je Agent |
| CISO und IT-Security | Sicherheitsvorgaben, Identitäten, Datenzugriff, Audit | Zentrale Policies, Audit Trail, Relay-Konfiguration |
| IT-Betrieb | Releases nach PROD, Überwachung, Störungen | Getrennte Umgebungen, versionierte Deployments, Monitoring |
| Entscheider im Tagesgeschäft | Freigaben für Sonderfälle, etwa Rabatte oder Zahlungsbedingungen | Freigaben in Teams oder Outlook, mit vollem Kontext |
In kleineren Organisationen liegen mehrere Rollen bei einem Team. Wichtig ist, dass jede Aufgabe eine benannte Zuständigkeit hat.
Ein Operating Model entsteht nicht auf dem Papier.
Es wächst mit jedem Prozess, der produktiv läuft.
Wie das Operating Model mit jedem Prozess wächst.
Sechs Stufen, jede baut auf der vorigen auf. Wie schnell Sie vorangehen, entscheiden Sie anhand der Ergebnisse.
Ein Prozess
Ein Process Pack, etwa die Auftragsbearbeitung, läuft produktiv mit Ihren echten Systemen und messbaren KPIs.
Weitere Prozesse
Angebot & Pricing, Service-Klärung oder Lieferausnahmen kommen dazu, in denselben Systemen.
Tools wiederverwenden
Ein Tool wie erp.customer.check, einmal freigegeben, nutzen mehrere Agenten. Jeder neue Prozess braucht weniger Integrationsaufwand.
Policies zentralisieren
Freigabewege, Schwellenwerte und Berechtigungen werden einmal definiert und gelten für alle Agenten.
Externe Agenten einbinden
Joule, Agentforce, Copilot und eigene Agenten rufen Tools über Nexus auf und laufen unter denselben Regeln.
Operating Model
Klare Ownership, getrennte Umgebungen, Monitoring und Outcomes für alle Agenten im Unternehmen.
Was von Prozess zu Prozess mitwächst.
Der zweite Prozess ist schneller produktiv als der erste, weil vieles schon da ist.
Agent-Tools
Freigegebene Tools aus Ihren Systemen, etwa SAP, Salesforce oder Microsoft 365, stehen jedem weiteren Agent zur Verfügung.
Policies und Freigabewege
Guarded Autonomy gilt einheitlich: automatisch, Freigabe oder blockiert, nach denselben Regeln.
Monitoring und Outcomes
Straight-Through-Quote, Ausnahmequote und Durchlaufzeit werden für alle Prozesse gleich gemessen.
Umgebungen
DEV, TEST und PROD mit versionierten Agenten, Tools und Policies. Releases bleiben nachvollziehbar.
Sicherheit
Eigene Identität je Agent, Audit Trail für jede Aktion, Systeme bleiben über den Relay-Dienst hinter der Firewall.
Know-how im Team
Mit Continuous Enablement bauen Ihre Teams eigene Agenten und Tools, mit Unterstützung von voluro.
Typische Ausgangslagen.
Kaum ein Unternehmen startet bei null. Meist gibt es bereits KI-Piloten, einzelne Tools und hohe Erwartungen, aber noch keinen Prozess, der produktiv läuft. Dort setzen wir an: mit einem Prozess, der messbar etwas verändert.
Kommt Ihnen das bekannt vor?
- „Wir haben mehrere KI-Piloten, aber keiner ist produktiv.“
- „Jeder Fachbereich experimentiert gerade selbst.“
- „Die IT-Security gibt keinen Schreibzugriff auf SAP frei.“
- „Agentforce, Joule oder Copilot decken unseren End-to-End-Prozess nicht ab.“
Häufige Fragen zum Agent Operating Model
Wer sollte das Operating Model verantworten?
Meist ein zentrales Team aus IT und Fachbereich, oft als KI-CoE organisiert. Es setzt Standards für Tools, Policies und Releases. Die fachlichen Regeln eines Prozesses bleiben beim jeweiligen Process Owner.
Brauchen wir ein Operating Model, bevor wir starten?
Nein. Wir empfehlen, mit einem Prozess produktiv zu gehen. Nexus bringt Governance, Monitoring und getrennte Umgebungen von Anfang an mit, das Operating Model wächst darauf auf.
Wir setzen Agentforce, Joule oder Copilot bereits ein. Passt das zusammen?
Ja. Nexus bindet diese Agenten ein und lässt sie Tools unter denselben Policies aufrufen. Sie behalten ihre Stärken in der jeweiligen Plattform.
Welche Rolle spielt unser KI-Team oder CoE?
Eine zentrale. Es setzt Standards und priorisiert die nächsten Prozesse. Nexus liefert die gemeinsame Plattform, voluro unterstützt beim Aufbau eigener Builder-Teams.
Wie lange dauert der Weg bis Stufe 6?
Das hängt von Ihren Prozessen und Prioritäten ab. Jede Stufe bringt für sich messbaren Nutzen, Sie müssen nicht alle durchlaufen.
Weiterlesen
Process Packs
Womit die meisten starten: Auftragsbearbeitung, Angebot & Pricing, Service-Klärung, Lieferausnahmen.
Ausbau
Wie wir nach dem ersten Prozess gemeinsam weitermachen.
Vom Piloten in die Produktion
Warum KI-Piloten stecken bleiben und was den Unterschied macht.
Starten Sie mit einem Prozess.
30 Minuten · kostenlos · mit einem Senior Architect. Sie erhalten eine mündliche Ersteinschätzung und konkrete nächste Schritte.