Die Ausgangslage: Wachstumschmerz in der Finanzabteilung
Der Kunde, ein etablierter Anbieter von B2B-Logistiksoftware mit rund 120 Mitarbeitern in Großbritannien, stand vor einer klassischen Wachstumsfalle. Das Unternehmen hatte in den vergangenen zwei Jahren sein Kundenstamm deutlich ausgebaut, was zu einem exponentiellen Anstieg der monatlichen Transaktionsvolumina führte. Während der Vertrieb neue Verträge abschloss und die Software-Lizenzen aktiviert wurden, geriet die Finanzabteilung ins Stocken. Die manuellen Prozesse, die ursprünglich für ein viel kleineres Volumen ausgelegt waren, konnten mit der neuen Dynamik nicht mithalten.
Das Kernproblem lag in der Fragmentierung der Daten. Verkauftes Volumen wurde im CRM erfasst, die technischen Nutzungsdaten lagen in der Cloud-Infrastruktur, und die tatsächlichen Auszahlungen (Payouts) an Partner oder die Rechnungsstellung an Endkunden mussten manuell in Excel-Tabellen zusammengeführt werden. Dieser Prozess dauerte im Schnitt vier bis fünf Werktage pro Zyklus. In dieser Zeit war das Unternehmen blind: Es fehlte an Echtzeit-Transparenz darüber, wie viel Umsatz tatsächlich realisiert wurde und wann die Gelder eingingen. Für die Cashflow-Prognosen war dies ein kritischer Engpass, da die zeitliche Verschiebung zwischen Vertragsschluss und Auszahlung nicht vorhersehbar war.
Zusätzlich zu der Zeitersparnis war die Fehlerquote ein ständiger Begleiter. Da Daten mehrfach manuell kopiert und zwischen verschiedenen Systemen übertragen wurden, kam es regelmäßig zu Übertragungsfehlern. Eine Fehlerquote von 4,2 % mag auf den ersten Blick gering erscheinen, bedeutet in der Praxis jedoch hunderte korrigierte Rechnungen pro Jahr, stundenlangen Support-Aufwand und verärgerte Kunden, die sich nach den Gründen für Verzögerungen erkundigten.
Herausforderungen bei der Prozessanalyse
Bevor auch nur eine Zeile Code geschrieben wurde, mussten wir die komplexen Geschäftslogiken verstehen. Hier stießen wir auf drei spezifische Herausforderungen, die eine Standard-Lösung unmöglich machten.
Erstens waren die Payout-Regeln historisch gewachsen und wenig dokumentiert. Es gab keine zentrale Datenbank, die definierte, unter welchen Bedingungen ein Partner bezahlt wird, welche Schwellenwerte gelten und wie Rabatte berechnet werden. Diese Logik lag im Kopf weniger Mitarbeiter, die im Unternehmen bereits lange tätig waren. Das Risiko war hoch, dass bei einer automatisierten Umsetzung subtile Regeln übersehen werden, was zu finanziellen Verlusten geführt hätte.
Zweitens bestand die Finanzabteilung zu Recht auf dem Zwei-Augen-Prinzip. Eine vollständige Automatisierung ohne menschliche Kontrolle wurde aus Compliance-Gründen abgelehnt. Es musste eine technische Lösung gefunden werden, die Routinefälle automatisch abwickelt, aber kritische oder unübliche Transaktionen sicher an einen Menschen zurückspielt, ohne dass der Workflow dabei ins Stocken gerät.
Drittens war die Integration der Bank-API eine technische Hürde. Die Anbindung an das Bankensystem erforderte höchste Sicherheitsstandards und eine lückenlose Protokollierung jeder einzelnen Überweisungsanweisung. Jede Abweichung hätte zu Compliance-Problemen führen können.
Der Tech-Stack
Um diese Herausforderungen zu meistern, haben wir einen schlanken, aber robusten Tech-Stack aufgebaut, der auf bestehenden Systemen des Kunden aufbaut und keine teuren, proprietären Insellösungen erfordert.
- CRM-System (HubSpot): Diente als Single Source of Truth für Vertragsdaten und Kundenstatus. Über Webhooks wurden Statusänderungen in Echtzeit an das Automatisierungssystem gemeldet.
- Zapier (Custom Workflows): Als Orchestrierungsschicht verknüpften wir die verschiedenen APIs. Hier wurden die Logik-Entscheidungen getroffen, wie z. B. die Prüfung der Schwellenwerte.
- Airtable: Diente als temporäre Datenbank und Audit-Log. Jeder Payout-Antrag wurde hier mit allen Metadaten (Vertrags-ID, Betrag, Zeitstempel, Status) protokolliert, bevor er an die Bank ging.
- Bank-API (Open Banking): Die direkte Schnittstelle zu dem Geschäftskonto des Kunden. Sie ermöglichte das Auslösen von Überweisungen ohne manuelles Banking-Interface und lieferte Bestätigungen in Echtzeit zurück.
- Power BI: Das zentrale Dashboard für die Finanzabteilung und das Management. Es visualisierte die Pipeline der Payouts in Echtzeit und wies auf Abweichungen von der Norm hin.
Umsetzung: Von der Analyse zum Go-Live
Die Umsetzung erfolgte in drei klar definierten Phasen über einen Zeitraum von acht Wochen. Unser Ansatz war iterativ: Wir haben zuerst die Daten sauber gemacht, dann die Logik automatisiert und schließlich die Ausführung an die Bank gekoppelt.
Phase 1: Datenkonsolidierung und Regeldefinition (Woche 1–3) In dieser Phase haben wir uns nicht mit der Technik beschäftigt, sondern mit der Logik. Gemeinsam mit der Finanzabteilung haben wir alle Payout-Szenarien kartografiert. Wir haben definiert, welche Datenfelder zwingend aus dem CRM übernommen werden müssen und wie die Berechnungsformeln für die Auszahlungen lauten. Parallel dazu haben wir die API-Anbindung zwischen dem CRM und unserem Zwischenablage-System (Airtable) eingerichtet. Das Ziel war es, einen Datensatz zu erzeugen, der zu 100 % vollständig und konsistent ist, bevor er in den nächsten Schritt geht.
Phase 2: Workflow-Automatisierung und Logik-Implementierung (Woche 4–6) Nun kam die eigentliche Automatisierung ins Spiel. Wir haben die Workflows in Zapier entwickelt. Der Trigger war einfach: Sobald ein Vertrag im CRM den Status ‘Aktiv’ erhält, wird ein Payout-Antrag in Airtable generiert. Hier kam die kritische Logik zum Tragen. Das System prüft automatisch:
- Ist der Betrag unter dem definierten Schwellenwert (z. B. 1.000 €)?
- Gibt es bereits einen offenen Payout für diesen Kunden?
- Stimmen die Bankdaten mit dem hinterlegten Kundenprofil überein?
Wenn alle Kriterien erfüllt sind, wird der Antrag als ‘Freigegeben’ markiert. Ist ein Kriterium nicht erfüllt oder liegt der Betrag über dem Schwellenwert, wird der Antrag als ‘Manuelle Prüfung erforderlich’ markiert und eine Benachrichtigung an den CFO gesendet. Diese Zwei-Augen-Prinzip-Logik war der Schlüssel zur Akzeptanz des Systems in der Finanzabteilung. Es gab keine Blackbox, sondern einen transparenten, nachvollziehbaren Prozess.
Phase 3: Parallelbetrieb und Go-Live (Woche 7–8) Bevor das System produktiv geschaltet wurde, haben wir zwei Wochen lang einen Parallelbetrieb durchgeführt. Das alte manuelle Excel-System und das neue automatische System liefen gleichzeitig. Jeden Abend haben wir die Ergebnisse beider Systeme verglichen. Ziel war es, eine Übereinstimmungsquote von 100 % zu erreichen, bevor wir den manuellen Prozess stillgelegt haben. In dieser Phase haben wir auch die Schulungen der Mitarbeiter durchgeführt. Der Fokus lag nicht auf dem ‘Wie’ der Technik, sondern auf dem ‘Was’ der neuen Verantwortlichkeiten. Wer prüft welche Fälle? Wie werden Abweichungen eskaliert?
Wie wir die Zahlen messen
Um die Wirkung der Maßnahme objektiv zu belegen, haben wir drei zentrale Kennzahlen definiert, die wir vor und nach dem Go-Live über einen Zeitraum von drei Monaten gemessen haben.
- Abrechnungszeit: Wir haben den Zeitstempel des Vertragsschlusses im CRM mit dem Zeitstempel der ausgeführten Banküberweisung verglichen. Daraus haben wir die Durchschnittsdauer in Werktagen berechnet. Vorher lag dieser Wert bei 4,5 Tagen, da die manuelle Zusammenführung und Freigabe Tage in Anspruch nahmen.
- Manuelle Eingriffe: Wir haben gezählt, wie viele Payout-Anträge im Airtable-System den Status ‘Manuelle Prüfung’ erhielten, im Verhältnis zur Gesamtzahl der Anträge. Vorher war dieser Wert bei 100 %, da jeder einzelne Vorgang manuell in Excel erfasst und geprüft werden musste.
- Fehlerquote: Wir haben die Anzahl der korrigierten Rechnungen oder rückgängig gemachten Überweisungen durch die Gesamtzahl der Transaktionen geteilt. Ein Fehler wurde definiert als jede Transaktion, die nach der Ausführung eine manuelle Korrektur erforderte (z. B. falscher Betrag, falscher Empfänger).
Die Daten wurden wöchentlich aus dem Power BI-Dashboard exportiert und in einem separaten Mess-Protokoll dokumentiert, um Manipulationen oder statistische Ausreißer durch saisonale Effekte auszuschließen.
Ergebnis: Effizienz und Transparenz
Nach drei Monaten im produktiven Betrieb zeigte sich ein deutlicher Unterschied in der Effizienz und Genauigkeit. Die Abhängigkeit von manueller Kontrolle sank drastisch, und die Finanzabteilung konnte sich wieder auf strategische Aufgaben konzentrieren, statt im Daten-Dschungel zu versinken.
| Metrik | Vorher | Nachher | Veränderung |
|---|---|---|---|
| Abrechnungszeit | 4,5 Werktage | 1,8 Werktage | -60 % |
| Manuelle Eingriffe | 100 % | 12 % | -88 % |
| Fehlerquote | 4,2 % | 0,3 % | -93 % |
Die Reduktion der Abrechnungszeit um 60 % war das zentrale Ergebnis. Was früher vier bis fünf Tage dauerte, wurde nun innerhalb von 1,8 Werktagen abgeschlossen. Dies war möglich, weil die Daten bereits im Moment des Vertragsschlusses in das System flossen und die Freigabe-Prozesse digital und parallel statt sequenziell abliefen.
Gleichzeitig stieg die Zufriedenheit der Kunden, da Auszahlungen pünktlicher und nachvollziehbarer wurden. Die Fehlerquote von 0,3 % bedeutet, dass auf über 300 Transaktionen pro Monat weniger als eine manuelle Korrektur erforderlich war. Das war ein Quantensprung von 4,2 % zuvor.
Ein unerwartetes, aber wertvolles Nebenprodukt war die verbesserte Cashflow-Sichtbarkeit. Da die Payouts nun in Echtzeit im Dashboard sichtbar waren, konnte das Management erstmals verlässliche Prognosen für die nächsten 30 Tage erstellen. Die Lücke zwischen ‘Verkauft’ und ‘Bezahlt’ wurde von einem unscharfen Schätzwert zu einem präzisen, datenbasierten Wert.
Learnings und Was wir heute anders machen würden
Der Erfolg dieses Projekts hing weniger an der Software selbst, sondern an der klaren Definition der Geschäftsregeln. Ohne saubere Payout-Logik wäre die Automation nur Chaos automatisiert. Wir haben gelernt, dass 50 % der Projektzeit in die Phase der Regeldefinition und Datenbereinigung investiert werden muss, bevor man an die technische Umsetzung geht. Ein ‘Quick Win’ mit unklaren Regeln führt immer zu einem ‘Quick Fix’ nach dem Go-Live.
Ein weiteres wichtiges Learning war das Change Management. Die Finanzabteilung hatte anfangs erhebliche Skepsis gegenüber der Automatisierung. Die Angst vor Jobverlust und die Sorge vor intransparenten Systemen waren groß. Durch die Einbindung in die Design-Phase und die transparente Fehleranalyse im Testlauf wurde das Vertrauen aufgebaut. Wir haben gezeigt, dass die Automatisierung nicht die Kontrolle entzieht, sondern sie verstärkt, indem sie Ausreißer sichtbar macht.
Was wir heute anders machen würden:
Erstens hätten wir die Bank-API-Integration früher im Projekt gestartet. Die technischen Hürden bei der Authentifizierung und der Testumgebung der Bank waren größer als erwartet und haben den Zeitplan in Woche 5 leicht verzögert. Bei einem ähnlichen Projekt würden wir die technische Machbarkeitsprüfung der Bank-Schnittstelle in Woche 1 parallel zur Logik-Definition starten.
Zweitens hätten wir das Dashboard für das Management noch früher eingeführt. Ursprünglich war es nur für die Finanzabteilung gedacht. Aber als das Management die Echtzeit-Daten sah, stieg die Motivation im gesamten Unternehmen, die Datenqualität im CRM zu verbessern, da die Auswirkungen ihrer Eingaben sofort sichtbar wurden. Ein früheres ‘Showcase’ hätte die interne Akzeptanz noch schneller gesteigert.
Letztlich hat sich die Investition in die API-Integration gelohnt, da sie die Skalierbarkeit für das nächste Kundenwachstum sichert. Das System ist nun in der Lage, ein Transaktionsvolumen von 10x dem aktuellen Niveau zu bewältigen, ohne dass zusätzliche Personalressourcen in der Finanzabteilung benötigt werden. Das ist der eigentliche Hebel für das weitere Wachstum des Unternehmens.