Ein Lebensmittelhersteller — 12 Personen, eigenes Lager, Großhandelskunden in ganz Polen. Drei Systeme, die jeden Tag dieselbe Realität in drei unterschiedlichen Sprachen beschrieben haben. Vier Monate später blieben nur zwei übrig, die im Hintergrund leise miteinander reden. Pro Woche bekam das Team zwölf Stunden zurück, und die Fehlerquote sank um 70 %.
Kontext: drei Systeme aus drei verschiedenen Epochen
Der Kunde produziert Lebensmittel unter eigener Marke sowie als Eigenmarke für Handelsketten. Das Team besteht aus zwölf Personen — drei Vertriebsmitarbeiter, der Auftragseingang, der Lagerleiter, die Buchhaltung und die Produktion. Wir haben Mitte 2025 angefangen zusammenzuarbeiten, nachdem uns ein befreundeter Verpackungslieferant empfohlen hatte, den wir ein Jahr zuvor bei einer ähnlichen Integration unterstützt hatten.
Wir trafen das typische KMU-Setup, das wir seit über einem Jahrzehnt sehen: Comarch Optima als zentrales ERP (Rechnungen, Buchhaltungslager, Stammdaten), ein separates Warehouse-Management-System (barcodebasiertes WMS, fünf Jahre zuvor für eine konkrete Ausschreibung gekauft) und ein Google-Sheet, in dem der Auftragseingang die Bestellungen der Stammkunden notierte. Jedes der drei Systeme war in seiner eigenen Welt korrekt. Das Problem begann dort, wo eine Welt endete und die nächste begann — also bei jeder Bestellung.
Ausgangspunkt: 12 Stunden pro Woche manuelle Doppelerfassung
Der Tagesablauf sah so aus: Eine Bestellung kam per E-Mail oder Telefon herein, der Auftragseingang tippte sie in das Google-Sheet. Nachmittags übertrugen zwei Personen die Bestellungen aus dem Sheet als Reservierungsbelege in Comarch Optima. Sie druckten eine Liste aus und brachten sie ins Lager. Der Lagermitarbeiter buchte die Auslieferungen ins WMS. Nach dem Versand ging eine Rückmeldung an den Auftragseingang — per E-Mail oder auf einem Klebezettel — und jemand stellte in Optima eine Rechnung aus. Der Lagerbestand in Optima wurde zweimal pro Woche aktualisiert, immer dann, wenn jemand Zeit fand.
Die Folgen waren absehbar. Bestellungen verschwanden zwischen Sheet und Optima — etwa zwei pro Woche. Der Bestand in Optima passte nicht zum tatsächlichen Bestand im Regal, weshalb der Vertrieb Kunden Ware versprach, die es gar nicht gab. Rechnungen gingen verspätet raus, manchmal an die falsche Adresse, weil der Kundendatensatz im Sheet ein anderer war als der in Optima. Reklamationen ließen sich nur durch das Durchforsten von drei Systemen und einem Mail-Archiv klären.
Wir haben das vor Projektstart gemessen. Das Team verlor etwa 12 Stunden pro Woche durch manuelle Doppelerfassung und Fehlerkorrektur. Fehlerhafte Belege (falsche Menge, falscher Kunde, falscher Artikel) lagen bei rund 80 pro Monat bei einem Volumen von 1 200 Bestellungen.
Was wir geprüft und verworfen haben
Der erste Reflex der Geschäftsführung war: „Lasst uns alles auf ein einziges, modernes System umstellen." Wir haben dieses Szenario durchgerechnet: Eine Migration weg von Optima hätte drei Monate Buchhaltungsarbeit bedeutet, das Risiko, die Belegshistorie zu verlieren (Comarch speichert Daten in einem spezifischen Format), und mehrere zehntausend Złoty für eine ERP-Lizenz, die niemand im Team kannte. Wir haben davon abgeraten.
Die zweite Option war ein iPaaS — Make (vormals Integromat) oder Zapier. Das funktioniert gut bei einfachen Flows, aber Comarch Optima hat keinen nativen Connector, und wir brauchten eine bidirektionale Synchronisation mit Transaktionsgarantien — eine Bestellung musste entweder vollständig oder gar nicht in Optima landen, keine Zwischenzustände. Make garantiert das nicht.
Wir entschieden uns für Option drei: ein dediziertes Middleware-System, in .NET geschrieben, das als Windows-Dienst auf dem Server des Kunden läuft, mit Optima über die Comarch-ERP-XL/Optima-API (BIS) und mit dem WMS über dessen REST-API kommuniziert. Das Google-Sheet haben wir durch ein schlankes Bestelleingangsformular ersetzt, das direkt mit der Middleware integriert ist.
Lösung: wie es technisch funktioniert
Architektur auf einen Blick:
Ablauf: Eine Bestellung kommt über das Formular herein, die Middleware validiert sie (existiert der Kontakt? sind die Artikel aktiv? ist das Kreditlimit eingehalten?), legt in Optima einen Beleg vom Typ Kundenreservierung an und gleichzeitig einen Versandauftrag im WMS. Der Lagermitarbeiter bestätigt den Versand mit dem Scanner, das WMS schickt eine Rückmeldung an die Middleware, die schließt die Reservierung in Optima ab und stellt die Rechnung aus.
Drei technische Entscheidungen, die hervorzuheben sind:
- Queue und Retry. Optima kann bei langen Operationen „hängen". Die Middleware ruft die API nie synchron auf — alles läuft über eine Queue mit Retry und Exponential Backoff. Antwortet Optima nicht, wartet die Bestellung, sie verschwindet nicht.
- Artikel-Mapping. Großhandelskunden verwenden eigene Produktcodes. Wir haben eine einfache Mapping-Tabelle gebaut — der Vertrieb sieht den Kundencode, Optima und das WMS sehen den internen Code.
- Audit-Log. Jede Zustandsänderung einer Bestellung wird mit Timestamp, Benutzer und Payload protokolliert. Reklamationen, die früher 30 Minuten Recherche kosteten, lassen sich heute in 2 Minuten klären.
Rollout: vier Monate, ein Wochenende Cut-over
Wir haben iterativ gearbeitet. Die ersten sechs Wochen — Analyse, Prozessmapping, Optima-Integration auf einer Testumgebung (die Comarch-BIS-API hat einige Eigenheiten, z. B. Session-Limits und spezifische Fehlercodes, die man kennen muss). Die nächsten sechs Wochen — WMS-Integration und Bestellformular. Die letzten vier Wochen — Tests mit echtem Traffic auf einem Staging-System, parallel zum bestehenden Prozess.
Der Cut-over erfolgte an einem Wochenende. In der ersten Woche arbeitete das Team mit einem unserer Engineers vor Ort (eine unserer Personen saß im Büro des Kunden und beantwortete Fragen in Echtzeit). Kleinere Korrekturen kamen laufend rein. Ab der dritten Woche nach dem Cut-over wechselten wir in den Remote-Support-Modus.
Ergebnis nach 6 Monaten Live-Betrieb
Zahlen sind die eine Seite. Die andere ist schwieriger zu messen: Der Vertrieb verspricht keinen Bestand mehr, den es nicht gibt, weil er den realen Lagerstand in Echtzeit sieht. Der Auftragseingang kümmert sich nicht mehr um Doppelerfassung, sondern um Reklamationen und neue Kunden. Der Lagerleiter muss der Buchhaltung nicht mehr erklären, warum mal wieder etwas falsch erfasst wurde.
Der schwierigste Teil des Projekts war nicht die Technik. Am schwierigsten war es, dem Team zu zeigen, dass wir ihnen nicht die Arbeit wegnehmen — sondern den schlechtesten Teil ihrer Arbeit.
Wie es weitergeht
Nach dem Go-live betreuen wir das System im SLA-Modus — 24/7-Monitoring, monatliche Log-Reviews, quartalsweise Updates auf neue Comarch-Optima-Versionen. Für 2026 ist die Anbindung eines zweiten Lagers geplant (der Kunde eröffnet eine Filiale bei Breslau) und der Ausbau des Bestellformulars zu einem B2B-Portal, in dem Stammkunden ihre Bestellungen selbst erfassen.
Das ist ein gutes Beispiel dafür, wie unsere Projekte funktionieren. Wir tauschen nicht alles aus. Wir kaufen keine neuen Systeme. Wir nehmen, was du hast, und bringen es dazu, als ein Ganzes zu arbeiten.
Hast du ein ähnliches Setup? Comarch Optima, ein Lagersystem, ein paar Excels? Reden wir 30 Minuten — unverbindlich — und schauen, ob sich das ordnen lässt.
Kostenloses Gespräch buchen →