1. Prozessaudit statt Bauchgefühl
Der erste Schritt ist die Prozessanalyse, die in Woche 1 und 2 stattfindet. Forfis identifiziert die Workflows, die den größten Hebel bieten: Bei einem Medtech-Unternehmen mit 120 Mitarbeitern sind das typischerweise die Rechnungsverarbeitung und die Ticket-Kategorisierung im Support. Die Analyse zeigt, dass 60 Prozent der Support-Tickets mit denselben drei Fragen zu tun haben und dass die Rechnungsverarbeitung im Schnitt 15 Minuten pro Dokument dauert. Diese Daten bilden die Basis für den Pilot-Scope und die Erfolgskennzahlen. Ohne diese Messung ist jede spätere Optimierung blind. Die Analyse dauert zwei Wochen, weil sie manuelle Interviews mit den Fachabteilungen und die Auswertung der System-Logs umfasst.
2. Vektor-Datenbank als Wissensbasis
Die Vektor-Datenbank ist das Herzstück des RAG-Systems. In Woche 3 und 4 wird die Infrastruktur aufgebaut: Eine Vektor-Datenbank wie Weaviate oder Pinecone speichert die dokumentierten Prozesse, die FAQ-Antworten und die historischen Support-Tickets. Die Anthropic Claude API wird über eine Custom REST API angebunden, die die Prompts formt und die Ergebnisse strukturiert zurückgibt. Die Integration erfolgt über Webhooks, die den Status der Verarbeitung in Echtzeit an das Helpdesk-System melden. Diese Architektur ist model-agnostic: Wenn die Qualität der Claude-Antworten nicht ausreicht, kann das System auf ein Open-Weight-Modell auf eigener Hardware umgestellt werden, ohne die Integration zu ändern.
3. Human-in-the-Loop als Standard
Die Human-in-the-Loop-Architektur ist der Standard bei Forfis. Das KI-Modell erstellt einen Entwurf oder eine Klassifizierung, die ein Mensch prüft und freigibt. Bei der Rechnungsverarbeitung wird jede Rechnung mit einem Wert über 1.000 Euro oder mit fehlenden Feldern manuell geprüft. Diese Schicht verhindert, dass fehlerhafte Daten in das ERP-System gelangen. Die Freigabe dauert im Schnitt 30 Sekunden, was die Gesamt-Durchlaufzeit auf 2 Minuten senkt. Ohne diese menschliche Kontrolle wäre die Fehlerquote zu hoch für einen produktiven Betrieb. Die Architektur ist so gestaltet, dass die menschliche Freigabe in den Workflow integriert ist, nicht als zusätzlicher Schritt dazwischengeschaltet wird.
4. REST-APIs und Webhooks statt Neuaufbau
Die Integration erfolgt über Standard-REST-APIs und Webhooks. Das RAG-System liest Rechnungsdaten aus dem ERP-System, verarbeitet sie über die Anthropic Claude API und schreibt die Ergebnisse zurück. Zusätzlich werden Webhooks genutzt, um den Status der Verarbeitung in Echtzeit an das Helpdesk-System zu melden. Es ist keine Änderung der bestehenden Systemarchitektur erforderlich, da die Integration über die vorhandenen Schnittstellen erfolgt. Die API-Dokumentation des ERP-Systems wird in Woche 3 analysiert, um die benötigten Endpunkte zu identifizieren. Die Webhook-Konfiguration dauert einen Tag, da sie nur die URL und die Authentifizierung erfordert. Diese Integration ist der Schlüssel dazu, dass das System in den bestehenden Workflow passt, statt ihn zu ersetzen.
5. Messbare Kennzahlen im Pilotbetrieb
Der Pilotbetrieb läuft in Woche 7 und 8. Die Messung erfolgt über zwei Kennzahlen: Durchlaufzeit und Fehlerquote. Vor der Implementierung wird ein Baseline-Wert ermittelt, der nach 4 Wochen Pilotbetrieb mit den neuen Werten verglichen wird. Bei einem Medtech-Unternehmen sinkt die Durchlaufzeit der Rechnungsverarbeitung von 15 auf 2 Minuten, die Fehlerquote von 8 auf 3 Prozent. Die Kosten pro Support-Ticket sinken um 35 Prozent, weil die manuelle Erfassung entfällt. Diese Zahlen sind die Grundlage für die Entscheidung, ob der Rollout auf weitere Abteilungen vorbereitet wird. Ohne diese messbaren Ergebnisse ist der Pilot ein Blindflug.
6. Häufige Stolperfallen vermeiden
Der häufigste Fehler ist der Versuch, alle Workflows gleichzeitig zu automatisieren. Das führt zu einem überladenen Scope, der die 8-Wochen-Frist sprengt. Der zweite Fehler ist die fehlende Datenbereinigung: Wenn die historischen Support-Tickets unstrukturiert sind, liefert das RAG-System schlechte Antworten. Der dritte Fehler ist die fehlende menschliche Freigabe: Ohne Human-in-the-Loop ist die Fehlerquote zu hoch für einen produktiven Betrieb. Der vierte Fehler ist die Wahl des falschen Modells: Für sensible Daten wie Patientenakten ist die Anthropic Claude API nicht geeignet, weil die Daten das Unternehmen verlassen. Open-Weight-Modelle auf eigener Hardware sind hier die richtige Wahl.
Leave a Reply