Fallstudie · WBS-Weiterbildung No-Code Prozessautomatisierung und KI-Agenten
Vom Sammelpostfach zur Service-App
Wie lässt sich ein gemeinsames Postfach so organisieren, dass Service und Rechnungsprüfung sehen, wer einen Vorgang bearbeitet und was als Nächstes zu tun ist? Dafür habe ich einen Vorgangsmanager konzipiert und über fünf Module mit KI-Unterstützung umgesetzt.
Schulungsprojekt für die fiktive Proxy GmbH. Die Abläufe orientieren sich an meiner Praxis im Onlinehandel. Gebaut und getestet in einer Microsoft-Schulungsumgebung mit Testdaten.
Prozessanalyse: Wo die gemeinsame Sicht verloren ging
SeitenanfangBei der Proxy GmbH liefen Kundenanfragen, Reklamationen und Rechnungen in einem Postfach zusammen. Ordnerregeln und manuelle Weiterleitungen verteilten die Arbeit. Sobald eine Mail in einem persönlichen Postfach lag, war der Bearbeitungsstand im Team nur noch durch Nachfragen oder im Postausgang nachvollziehbar.
Warum zuerst der Kundenservice?
Ich verglich drei Kandidaten: Anfragen verteilen, Artikel anlegen und Eingangsrechnungen bearbeiten. Die Anfragenverteilung erreichte mit 24 von 24 Punkten den höchsten Nutzen im Bewertungsraster. Das ist die Bewertung des Potenzials im Szenario.
Was das Ist-Modell sichtbar machte
Im BPMN-Modell habe ich sieben Schwachstellen markiert. Drei davon prägen die Lösung: Weiterleitungen entziehen Fälle der gemeinsamen Sicht, offene Fälle haben keinen festen Bearbeiter, und wechselnde Absender zerreißen den Gesprächsverlauf.
Automatisierung: Aus einer Mail wird ein Vorgang
SeitenanfangDer Maileingang liest die Regeln aus einer SharePoint-Liste und prüft sie nach Priorität. Der erste Treffer bestimmt die Kategorie. Ohne Treffer legt Power Automate den Vorgang mit der Kategorie „Unklar“ an und meldet ihn im Servicekanal. Beim Formular übernimmt der Ablauf die Kategorie aus dem Auswahlfeld.
- Mail oder FormularEingang mit Anlagen und Quelle erfassen.
- SharePoint-VorgangKategorie, Nummer, Status und Zuständigkeit festhalten.
- Teams-KarteDer Service kann übernehmen oder weitergeben.
- Planner-AufgabeBeim Abhaken trägt der Flow Abschlussstatus und Zeit ein.
Vorgangsnummer bei parallelen Eingängen
Die Nummer enthält Millisekunden und einen Zufallsanteil. Damit sinkt das Kollisionsrisiko, wenn mehrere Flows in derselben Sekunde starten. Die Nummer verbindet Aufgabe und Vorgang beim Abschluss.
Antworten dem vorhandenen Vorgang zuordnen
Der Mailflow sucht in den zuletzt angelegten Vorgängen nach derselben Konversations-ID. Eine Antwort im selben Strang wird dem vorhandenen Vorgang zugeordnet. Ein erneuter Versand in einem neuen Strang führt im Test zu einem eigenen Vorgang.
Eskalation und Fehler getrennt behandeln
Für offene Vorgänge ohne Bearbeiter prüft ein geplanter Flow die Vier-Stunden-Grenze. Nach der Meldung setzt er ein Kennzeichen für Folgeläufe. Scheitert die Ausführung technisch, meldet ein separater Fehlerzweig den Abbruch im Kanal.
BPMN-Sollmodell öffnen
Rechnungsprüfung: Auslesen, prüfen, entscheiden
SeitenanfangDer Agent in Copilot Studio liest Kopf- und Positionsdaten aus dem PDF in ein festes Format. Power Automate prüft die Werte danach mit Regeln, etwa Rechensummen, Bankverbindung gegen Stammdaten und Bestellbezug. Die prüfende Person sieht die Hinweise und entscheidet anhand des Originalbelegs.
Testbeleg R8: Eingeschleuste Freigabeanweisung
Im Bemerkungsfeld fordert die Testrechnung das System auf, eine angeblich bereits genehmigte Rechnung durchzulassen. Der Parser erfasste die Anweisung als Auffälligkeit. Das Datenformat des Parsers enthält Felder für Belegdaten und Auffälligkeiten. Die Freigabe wird erst von der prüfenden Person in der App erfasst.
Zweitlesung deckt eine Abweichung auf
Das Original trägt HD24-88213. Der erste Lauf liest HD24-88Z13, der zweite HD24-88113. Beide Werte sind falsch. Der Vergleich markiert den Fall zur Prüfung am Original. Beide Lesungen erhalten dasselbe Dokument und können dieselbe Anweisung sehen.
Auch plausible Werte können falsch sein
In einem weiteren Test korrigierte das Modell einen absichtlich falschen Rechnungsbetrag beim Auslesen in einem von zwei Läufen. Damit war der Fehler für die nachgelagerte Rechenprüfung in diesem Lauf unsichtbar. Die Stichprobe zeigt, warum die Prüfung am Original wichtig bleibt.
So würde ich die Belegerkennung im Betrieb aufbauen
In der Schulungsumgebung standen mir zum Auslesen der Belege nur GPT-Modelle zur Verfügung. Für den Betrieb würde ich ein spezialisiertes OCR-Modell für Zahlen, Text und Positionen auf dem Beleg einsetzen. Das Sprachmodell würde ich für Aufgaben nutzen, die Kontext brauchen, etwa die Einordnung der Belegart oder ungewöhnlicher Hinweise.
Unsicher erkannte Felder würde ich zur Prüfung am Original markieren. Rechensummen und Stammdaten würde Power Automate weiterhin anhand fester Regeln prüfen. Die prüfende Person entscheidet über die Freigabe.
Power App: Ein Arbeitsplatz für jeden Bearbeitungsschritt
SeitenanfangMit Teams, Planner und SharePoint lief der Eingang bereits automatisiert. Die Bearbeitung war über mehrere Oberflächen verteilt, und Rechnungskopf und Positionen standen in getrennten Listen. Ich habe den Eingang beibehalten und die Bearbeitung in eine Power App mit Ansichten für Service und Rechnungsprüfung verlegt.
Service: Bearbeiten, antworten, nachverfolgen
Ein Statuswechsel kann den Vorgang übernehmen und Bearbeiter sowie Übernahmezeit setzen. Antworten gehen bei vorhandener Konversations-ID im bestehenden Mailstrang raus. Die nächste Kundenantwort und ihre Anlagen erscheinen wieder am Vorgang.
Rechnungsprüfung: Hinweise und Original nebeneinander
Eindeutig zugeordnete Rechnungen landen nach dem Auslesen in der Rechnungsansicht. Ist ein Beleg im Service gelandet, bestätigt der Service die Belegart und gibt ihn weiter. Die Rechnungsansicht zeigt Kopf, Positionen und Original-PDF. Freigabe oder Ablehnung wird als Prüfstatus im simulierten ERP festgehalten.
Wie Eingang, Daten und App verbunden sind
Dataverse bildet zwei Systeme mit getrennten Tabellen nach: Vorgang, Verlauf und Rolle im CRM, Rechnungskopf und Positionen im ERP. Vorgangs- und Rechnungsnummern verbinden die Einträge. Neue Datensätze kommen per Flow aus SharePoint. Statusänderungen aus der App werden über einen Flow nach SharePoint zurückgeschrieben.
Testprotokoll: Was im Prototyp nachgewiesen ist
SeitenanfangDie Automatisierung wurde mit zwölf dokumentierten Fällen geprüft. Elf sind mit Screenshots belegt, der Test zur Absenderdomäne war in der Umgebung nicht durchführbar. Für den Parser dokumentiert die Abgabe einen Durchlauf mit 13 Testbelegen, 13 Kopfzeilen und 35 Positionszeilen. Die App-Abgabe dokumentiert zusätzliche Funktionsprüfungen.
| Testfall | Beobachtetes Ergebnis | Belegstelle |
|---|---|---|
| Mail ohne Regeltreffer | Der Vorgang wird mit „Unklar“ angelegt. Im Servicekanal erscheint eine Meldung zur manuellen Zuordnung. | Modul 3 |
| Antwort im bestehenden Mailstrang | Der Mailflow erkennt die Konversations-ID. Die gefilterte Vorgangsliste enthält nach der Antwort weiterhin genau einen Vorgang. | Modul 3 |
| Zwei Eskalationsläufe nacheinander | Im ersten Lauf meldet der Flow die betroffenen Fälle und setzt das Kennzeichen. Im zweiten Lauf wird für dieselben Fälle keine weitere Meldung erzeugt. | Modul 3 |
| Falscher Listenname im Maileingang | Der ausgelöste Fehlerzweig meldet den Abbruch im Servicekanal mit Verweis auf den Ausführungsverlauf. Im Test entstand kein halber Vorgang. | Modul 3 |
| Abweichende Bankverbindung und eingebettete Anweisung | Der Stammdatenabgleich markiert die abweichende Bankverbindung. Im separaten R8-Test landet die eingeschleuste Freigabeanweisung im Feld „Auffälligkeit“. | Modul 4 |
| Statuswechsel, Antwort und Anlage in der App | Die App-Abgabe dokumentiert die Rückschreibung des Status, Antworten im selben Mailstrang und die Aufnahme einer Kundenantwort samt Anlage in den Vorgangsverlauf. | Modul 5 |
Zwei Läufe desselben Eskalationsflows
Im ersten Lauf sind „Eskalation melden“ und „Eskaliert setzen“ grün markiert. Im zweiten Lauf sind beide Schritte grau und wurden übersprungen.
Testprotokoll Modul 3
Power-Automate-Abläufe ansehen
Was für einen Betrieb noch fehlen würde
SeitenanfangBerechtigungen und Betriebskonto
In der Schulungsumgebung stand ein Konto zur Verfügung. Der Rollenwechsel steuert deshalb die Bedienoberfläche. Für den Betrieb wären getrennte Datenrechte und ein vom persönlichen Konto unabhängiger Betrieb der Flows nötig.
Formulareingang und größere Datenmengen
Im Formular bestimmt das Auswahlfeld die Kategorie. Falsche Zuordnungen brauchen einen zusätzlichen Prüfweg. Die App-Arbeitsliste lief mit kleinen Testbeständen und muss für größere Datenmengen gesondert geprüft werden.
Was die Tests der App abdecken
Die Testfälle habe ich gezielt für erwartete Abläufe und bekannte Fehlerbilder gebaut. Ein Test mit 300 realen Vorgängen lag außerhalb des Projektumfangs. Auch 300 mit KI erzeugte Fälle hätten vor allem meine Annahmen bei der Auswahl der Fälle abgebildet. Welche unerwarteten Fehler im Alltag auftreten und wie häufig, lässt sich erst über längere Zeit im laufenden Betrieb beobachten.