Prozessoptimierung mit KI: Geschäftsprozesse automatisieren, mit Beispielen

Sie sind Geschäftsführer und sehen jeden Monat dieselbe Rechnung: drei Mitarbeitende, die zusammen rund 60 Stunden pro Woche zwischen Excel, ERP und E-Mail kopieren. Zwei dieser Stellen sind entstanden, weil ein Bereich gewachsen ist. Eine, weil das System zwei Standorte nie sauber verbunden hat. Das ist kein KI-Problem. Das ist ein Prozessproblem, und es lässt sich mit der richtigen Automatisierung in Wochen lösen. Die Frage ist nur, wo der Hebel sitzt.

Kurz gesagt: Prozessoptimierung mit KI heißt, Abläufe erst aufzunehmen und zu messen und dann die Schritte zu automatisieren, an denen Informationen von Hand abgetippt, gelesen oder eingeordnet werden. Künstliche Intelligenz übernimmt dabei nur die Schritte, an denen feste Regeln scheitern, etwa Freitext in Mails, PDFs oder Ausschreibungen; den Rest erledigen Schnittstellen und Regeln.

Dieser Artikel sagt, wie wir den Hebel finden: erst der Prozess, dann die Kosten, dann die Frage, ob Regeln reichen oder ob es KI braucht. Danach Beispiele nach Bereich, das Vorgehen in vier Schritten und die häufigsten Fragen.

1. Ein Geschäftsprozess ist eine Kette von Übergaben

Ein Geschäftsprozess umfasst alle Schritte, die nötig sind, bis ein Kunde bekommt, was er bestellt hat. Man unterscheidet den durchgehenden Prozess (End-to-End) von seinen Teilprozessen. Am Beispiel Einkauf:

Jeder Pfeil in dieser Kette ist eine Übergabe: von einer Person zur nächsten, von einem System ins andere. Genau dort geht die Zeit verloren, nicht in den Kästen.

2. Wo Prozesskosten entstehen

Prozesskosten sind alles, was ein Durchlauf kostet: Personalzeit, Material, und die indirekten Kosten durch Warten, Fehler und Nacharbeit. In unseren Audits sehen wir immer dieselben vier Stellen, an denen der größte Teil davon hängt:

Was diese vier Stellen gemeinsam haben: Eine Information existiert schon, wird aber noch einmal erfasst, verglichen oder weitergereicht. Wie viel das kostet, hängt vom Prozess ab, und es lässt sich messen. Bevor wir irgendetwas automatisieren, zählen wir: Wie oft läuft der Prozess, wie lange dauert jede Übergabe, wie oft geht etwas schief. Ohne diese Zahlen gibt es später kein Nachher.

3. Prozessoptimierung heißt: erst verstehen, dann bauen

Vier Dinge, die vor jeder Technikentscheidung passieren:

• Aufnahme: Wir gehen den Prozess mit den Menschen durch, die ihn täglich machen. Nicht mit dem Organigramm, sondern mit der Sachbearbeiterin, die weiß, warum das Excel neben dem ERP existiert.
• Messen: Durchlaufzeit, Häufigkeit, Fehlerquote je Schritt. Aus Stichproben, nicht aus Schätzungen.
• Streichen: Was doppelt erfasst wird, wird einmal erfasst. Was niemand liest, wird nicht mehr erzeugt. Oft ist das die Hälfte der Optimierung, ohne eine Zeile Code.
• Erst dann automatisieren: Und zwar den Schritt, bei dem wenig Aufwand viel bringt.

Das ist der Grund, warum wir mit einem Audit anfangen, wenn unklar ist, wo der Hebel liegt: zwei Wochen, ein Dokument, sortiert nach Aufwand und Wirkung.

4. Automatisierung: Wann Regeln reichen

Der größte Teil der Übergaben braucht keine KI. Er braucht eine Verbindung zwischen zwei Systemen und eine Regel: Wenn ein Lieferschein eingeht, gleiche ihn mit der Bestellung ab. Wenn eine Rechnung freigegeben ist, buche sie und archiviere den Beleg.

Dafür gibt es Werkzeuge, die genau das können: Schnittstellen, Webhooks, Workflow-Systeme wie Zapier, Make oder selbst gehostetes n8n. Regelbasierte Automatisierung ist günstig, nachvollziehbar und leicht zu prüfen. Sie hat eine Grenze: Sie braucht strukturierte Daten. Ein Feld mit einem Betrag, ein Datum, eine Bestellnummer. Sobald die Information in einem PDF, einer E-Mail oder einem Freitext steckt, hört die Regel auf zu funktionieren.

Ab einer gewissen Zahl von Workflows lohnt sich außerdem der Blick auf die Rechnung: Zapier und Make rechnen pro Ausführung ab. Wann sich der Umstieg auf ein eigenes System rechnet, haben wir an anderer Stelle durchgerechnet.

Und es gibt eine zweite Grenze, die nichts mit Daten zu tun hat: Klick-Workflows sind schnell gebaut, aber schwer zu prüfen, wenn sie wachsen. Kein Vergleich zwischen zwei Ständen, keine Tests, Fehlersuche im Browser. Bei 40 Workflows merkt man das, bei 200 zahlt man dafür. Sobald ein Schritt Freitext liest, Entscheidungen trifft oder mit Agents arbeitet, bauen wir deshalb in Code, mit eve als Grundlage: Jede Änderung ist dokumentiert und lässt sich vergleichen, jeder Lauf hat Tests und ein Protokoll, ein Fehler lässt sich auf die Zeile zurückverfolgen, und ein Rollback ist der Wechsel auf den vorherigen Stand.

5. Wo KI mehr kann als Regeln

KI kommt dort ins Spiel, wo die Regel scheitert: bei unstrukturierten Daten und beim Einordnen. Ein Sprachmodell kann aus einer Lieferantenmail den Betrag, das Datum und die Bestellnummer ziehen. Es kann eine Ausschreibung lesen und sagen, ob sie zum Profil eines Büros passt. Es kann einen Produkttext in sieben Sprachen übertragen und dabei ein Glossar einhalten.

Wie das in echten Abläufen aussieht, zeigt der nächste Abschnitt.

6. Geschäftsprozesse mit KI automatisieren: Beispiele nach Bereich

In jedem der Beispiele braucht genau ein Schritt KI, der Rest sind Regeln. Wo wir ein Projekt ausgeliefert haben, steht das dabei. Use-Case-Studien sind durchgerechnete Muster auf Basis unserer Prototypen, keine ausgelieferten Kundenprojekte.

Handel und E-Commerce: Bestellungen, Produktdaten, Übersetzungen

Bestellprozesse. Bestellungen, die per Mail oder als PDF kommen, sind der klassische Fall aus der Tabelle oben: Ein Sprachmodell liest Artikel, Mengen und Liefertermin aus dem Freitext, eine Regel legt den Auftrag im Shop oder im ERP an. Passt etwas nicht zusammen, etwa eine unbekannte Artikelnummer, entscheidet ein Mensch.

Produktdaten. Wächst der Katalog schneller als das Team, werden Texte uneinheitlich und Attribute fehlen. In der Use-Case-Studie zu Produktdaten mit KI rechnen wir durch, wie eine Pipeline Daten aus Hersteller-PDFs, Produktfotos und bestehenden Beschreibungen zieht, mit dem Attributkatalog abgleicht und erst dann Texte schreibt. Texte für die wichtigsten Produkte gibt ein Mensch frei. Die Erkenntnis aus dem Prototyp: Den Unterschied machen Extraktion und Normalisierung der Daten, der Text ist der einfache Teil.

Übersetzungen im Shopify-Store. Bei LOULEX, einem ausgelieferten Projekt, übersetzt ein eigener Bot stündlich, was im Shop fehlt oder veraltet ist, in sieben Sprachen. Das Sprachmodell übersetzt, die Regeln davor und danach machen den Unterschied: ein Glossar, das Markenbegriffe schützt, eine Prüfung, die kaputte Platzhalter abfängt, ein Protokoll, mit dem sich jeder Lauf zurücknehmen lässt. Der externe Übersetzungsdienst für 299 € im Monat ist gekündigt.

Planungsbüro: Ausschreibungen

Mehrere Mitarbeitende sichteten täglich Bekanntmachungen auf TED und DÖE, ordneten sie ein und schrieben Bewerbungsunterlagen. Ein Stichwortfilter hätte hier nichts gebracht, weil er nicht weiß, was das Büro tatsächlich baut. Der Prototyp, den wir gebaut haben, arbeitet mit dem Profil des Büros: Referenzen, Kompetenzen, Kooperationspartner, Ziel-Auftragsgrößen. Ein Sprachmodell ordnet neue Bekanntmachungen danach ein.

Die ganze Rechnung mit allen Annahmen steht in der Use-Case-Studie zur Ausschreibungs-Akquise.

Verwaltung und ERP: Belege, Mails, Freigaben

Hier liegen die Übergaben aus Abschnitt 2: Lieferantenmails, Eingangsrechnungen als PDF, Lieferscheine als Scan, Anfragen, die im Sammelpostfach landen. Das ERP bleibt dabei, wie es ist. Die Automatisierung setzt davor an: KI liest aus Mail, PDF oder Scan die Felder, die das ERP braucht, und ordnet eingehende Nachrichten dem richtigen Vorgang zu. Abgleich, Buchung und Ablage laufen danach über Regeln und die Schnittstelle des ERP, Freigaben bleiben beim Menschen.

7. Was dabei schiefgeht, und was wir dagegen tun

• Die Daten sind schlechter als gedacht. Ein Modell, das aus schlechten Scans liest, liefert schlechte Zahlen. Deshalb fangen wir mit einer Stichprobe echter Dokumente an, nicht mit Testdaten.
• Niemand prüft. Wo eine Zahl in die Buchhaltung oder ein Text in den Shop geht, gibt ein Mensch frei, oder das System begrenzt sich selbst. Der LOULEX-Bot verarbeitet höchstens 5.000 Wörter pro Stunde und bricht ab, wenn sich Befunde häufen.
• Das Team wird nicht mitgenommen. Die Sachbearbeiterin, die das Excel gepflegt hat, weiß am besten, welche Sonderfälle das System kennen muss. Sie sitzt bei uns im Auftakt, nicht in der Schulung am Ende.
• Kein Vorher, also kein Nachher. Ohne Messung vor dem Start weiß niemand, ob es sich gelohnt hat. Wir messen vorher.
• Einmal gebaut, nie wieder angefasst. Prozesse ändern sich. Wer automatisiert, braucht Monitoring und jemanden, der dranbleibt. Das gehört zur Übergabe, nicht zum Nachtrag.

8. Vorgehen in vier Schritten

1. Prozessanalyse. Ist unklar, wo der Hebel liegt, nimmt das Audit in zwei Wochen Abläufe, Systeme und Daten auf und misst die Ausgangslage. Ergebnis: eine Roadmap, sortiert nach Aufwand und Wirkung, und ein klar benannter nächster Schritt.
2. Pilot. Im 10-Tage-Piloten bauen wir den wichtigsten Schritt mit Ihren echten oder realistischen Daten nach, in Tagen bis zwei Wochen. Am Ende steht eine Demo und die Antwort auf die Frage, ob sich die Umsetzung lohnt.
3. Ausbau. Trägt der Pilot, wird in der Umsetzung daraus ein System für den echten Einsatz, mit Anbindung an Ihre Systeme, Tests und Dokumentation. Das dauert Wochen, nicht Quartale.
4. Betrieb. Monitoring, Protokolle und jemand, der dranbleibt, wenn sich der Prozess ändert. Betrieb und Übergabe an Ihr Team gehören zur Umsetzung, nicht zum Nachtrag.

Nicht jedes Projekt braucht alle vier Schritte. Ist die Frage schon konkret, starten wir direkt mit dem Piloten.

Häufige Fragen