Alle BeiträgeAgentische KI
Wo ERP-Agenten aufhören
Die Agenten, die jetzt in Dynamics 365 und Business Central ausgeliefert werden, sind nützlich und bewusst begrenzt. Sie bereiten vor und empfehlen, innerhalb eines ERP. Buchen, Freigeben und alles, was über Systemgrenzen geht, bleibt bei Ihnen. Wie Sie sie einsetzen und was sich weiterhin zu bauen lohnt.
Die Konzerncontrollerin hatte in einem Fenster die Release Notes offen, im anderen die Checkliste für den Monatsabschluss. Zwei Märkte der Gruppe arbeiten mit Business Central. Der dritte nutzt noch das lokale Hauptbuch aus der Zeit vor der Übernahme, und Zahlungseingänge kommen als Kontoauszugsdateien von vier Banken. Ihre Frage war kurz: Microsoft liefert jetzt Agenten für Rechnungen und Abstimmung. Welche der geplanten Arbeiten brauchen wir noch?
Ein Teil davon war gerade überflüssig geworden. Der größte Teil des schwierigen Stücks hatte sich nicht bewegt.
Was ausgeliefert wurde, in den Worten des Herstellers
Business Central hat jetzt einen Payables Agent, der als allgemein verfügbar geführt wird. Microsoft beschreibt ihn als Agenten, der "monitors mailboxes for incoming vendor invoices, uses AI to analyze invoice content, and shows invoice drafts to agent supervisors for review." Er überwacht also Postfächer auf eingehende Lieferantenrechnungen, analysiert deren Inhalt und legt die Entwürfe den zuständigen Personen zur Prüfung vor. Er liest PDF-Rechnungen aus einem Microsoft-365-Postfach, erkennt den Kreditor, schlägt Zeilen vor, gleicht sie mit Bestellzeilen ab und macht aus einem freigegebenen Entwurf eine Einkaufsrechnung.
Daneben gibt es einen Sales Order Agent und einen Expense Agent. Die Tabelle unten stellt alle vier nebeneinander.
Dynamics 365 Finance hat einen Account Reconciliation Agent, ebenfalls in der Vorschau. Er "evaluates exceptions and provides a recommended action for each one", bewertet also Ausnahmen und empfiehlt für jede eine Maßnahme, und zwar für Differenzen zwischen Nebenbüchern und Hauptbuch. Die ersten Releases decken Kreditoren, Debitoren, Steuern und Bank ab.
Nichts davon ist eine Demonstration. Es läuft in den Produkten, unter deren Sicherheitsmodell, und jeder Agent handelt als eigener Benutzer. Seine Arbeit erscheint deshalb in denselben Feldern "Erstellt von" und "Geändert von" wie die einer Person.
| Agent | Bereitet vor | Überlässt einer Person | Status |
|---|---|---|---|
| Payables Agent (Business Central) | Rechnungsentwürfe aus PDF-E-Mails, Kreditorenzuordnung, Zeilen gegen Bestellungen | Buchen, Freigabe, Entsperren neuer Kreditoren | Allgemein verfügbar |
| Sales Order Agent (Business Central) | Angebote aus Kunden-E-Mails, Verfügbarkeitsprüfung | Jede ausgehende Nachricht, Buchen | Business Central online |
| Expense Agent (Business Central) | Spesenzeilen aus Belegen | Prüfung, bevor die Abrechnung eingereicht wird | Vorschau |
| Account Reconciliation Agent (Dynamics 365 Finance) | Eine empfohlene Maßnahme pro Ausnahme im Nebenbuch | Annehmen, Stornieren oder Verknüpfen | Vorschau |
Was sie bewusst den Menschen überlassen
Die nützlichsten Sätze in der Dokumentation sind die, die sagen, was die Agenten nicht tun.
Der Payables Agent "doesn't post purchase invoices", er bucht also keine Einkaufsrechnungen. Einen eigenen Freigabeprozess hat er nicht. Ein Kreditor, den er anlegt, bleibt gesperrt, bis jemand ihn freigibt, und die Dokumentation sagt klar, dass Bankdaten von Lieferanten so bestätigt werden wie bisher: mit einem Anruf beim Lieferanten. Der Sales Order Agent erstellt zuerst ein Angebot, auch wenn der Kunde um einen Auftrag bittet. Der Abstimmungsagent empfiehlt für jede Ausnahme eine Korrektur. Eine Person nimmt sie an, storniert sie, verknüpft die Buchungen oder akzeptiert die Differenz.
Das liest sich weniger wie eine Lücke als wie eine Designentscheidung: Der Agent bereitet vor, eine Person legt sich fest, und der Datensatz zeigt, wer was getan hat. Genau dort würde ein sorgfältiges Finanzteam die Linie ziehen, und es lohnt sich, sie beizubehalten, auch wenn ein späteres Release erlaubt, sie zu verschieben.
Wo sie aufhören
Für die Controllerin war die entscheidende Grenze der Rand jedes einzelnen ERP.
Diese Agenten arbeiten in Business Central online oder in Dynamics 365 Finance, mit den Daten, die diese Systeme halten. Rechnungen kommen über ein überwachtes Microsoft-365-Postfach, als PDF. Es gibt einen Payables Agent pro Mandant. Zu anderen ERP-Systemen, zu einem lokalen Hauptbuch, das nach einer Übernahme weitergeführt wird, und zu Kontoauszugsdateien sagt die Dokumentation nichts, und dieses Schweigen ist die Grenze. Die Agenten behaupten nicht, dort zu arbeiten, also sollte man sie auch nicht so einplanen.
In ihrer Gruppe blieben die Agenten damit nützlich für den Großteil der Lieferantenrechnungen und für die Abstimmung der Nebenbücher in den beiden Business-Central-Märkten. Unberührt blieb die Arbeit, die tatsächlich bestimmte, wann der Abschluss fertig war: die Intercompany-Salden zwischen den drei Gesellschaften, die Kontoauszugszeilen von vier Banken gegen offene Posten in drei Hauptbüchern und die Erklärung, warum die Zahlen der Gruppe am letzten Tag übereinstimmten.
Die Rechnung kommt pro Aktion
Die Agenten werden in Copilot Credits abgerechnet, pro Aktion. Microsofts eigenes Beispiel für den Payables Agent rechnet mit 50 Credits für die Verarbeitung einer Rechnung und 5 für jede Zeile. 100 Rechnungen mit je drei Zeilen im Monat ergeben also 6.500 Credits. Sind die Credits aufgebraucht, verarbeitet der Agent keine neuen Rechnungen mehr und arbeitet den Rückstand ab, sobald wieder Kapazität da ist.
Daraus folgen zwei Konsequenzen für das Design, und keine davon betrifft den Preis, den wir dem Lizenzgespräch überlassen. Erstens gehören Routineprüfungen, die reine Arithmetik sind, etwa eine Menge gegen einen Wareneingang oder eine Summe gegen eine Kontrollzahl, in gewöhnlichen Code, wo sie pro Durchlauf nichts kosten. Zweitens gehört das Credit-Guthaben in den Abschlusskalender. Ein Agent, der am 29. pausiert, weil die Kapazität des Monats aufgebraucht ist, ist ein Risiko für den Abschluss und sollte auch so geplant werden.
Um sie herum planen, nicht gegen sie
Der Plan, den wir der Controllerin gaben, hatte drei Teile.
Den nativen Agenten in jedem ERP nutzen. Wo der Agent von Business Central die Arbeit abdeckt, schalten Sie ihn ein und lassen ihn die routinemäßigen Rechnungen und Angebote übernehmen. Der Hersteller pflegt ihn, er folgt den Berechtigungen des Produkts, und niemand in der Gruppe muss seinen Code verantworten.
Nur die Ebene bauen, die sie nicht sehen. Eine systemübergreifende Ebene liest die drei Hauptbücher und die Kontoauszugsdateien der vier Banken, hält die Intercompany-Regeln, die das Finanzteam der Gruppe bereits anwendet, und bereitet die Zuordnungen und die Ausnahmen für eine Person vor. Sie wiederholt nicht, was die nativen Agenten tun. Sie beginnt dort, wo deren Dokumentation verstummt.
Einen einzigen Nachweispfad führen. Jeder native Agent schreibt seine Aktionen bereits unter seiner eigenen Benutzerkennung. Die systemübergreifende Ebene schreibt ihre Vorschläge und die Entscheidungen der prüfenden Person in denselben Begriffen, verknüpft mit denselben Belegen. Am Monatsende kann die Controllerin eine Zahl von der Bankzeile bis zur Buchung im Hauptbuch verfolgen, über jeden Agenten und jede Person, die sie berührt haben, in einem Pfad statt in dreien. Die Freigabe selbst bleibt im ERP, bei den Menschen, denen sie schon heute gehört.
Der erste Monat
Wir haben vorgeschlagen, klein anzufangen und mit ihren eigenen Zahlen. Der Payables Agent hat einen Testmodus, der bis zu 50 Rechnungen verarbeitet, ohne abrechenbare Credits zu verbrauchen. Der erste Schritt kostete also nichts: ihn auf die Rechnungen eines Mandanten aus einem bereits abgeschlossenen Monat ansetzen und seine Entwürfe mit dem vergleichen, was das Team gebucht hat. Wo die Entwürfe übereinstimmen, können die Routinerechnungen dieses Mandanten zum Agenten wandern. Wo nicht, zeigen die Gründe, welche Lieferanten oder Rechnungslayouts weiterhin eine Person brauchen.
Der zweite Schritt war die systemübergreifende Ebene, beschränkt auf eine Aufgabe: die Intercompany-Salden zwischen den drei Gesellschaften. Sie entschieden am häufigsten über den letzten Tag des Abschlusses, und dort brachte Engineering-Zeit am meisten. Die Kontoauszüge kamen danach, als die Ebene einen Abschluss lang gehalten hatte.