Wenn Ihre Warenwirtschaft nicht alles kann, was Sie brauchen
Eine Warenwirtschaft mit einer Lücke muss nicht ersetzt werden. Wie eine eigene Oberfläche die Lücke schließt und das führende System dabei als einzige Quelle der Wahrheit respektiert.
Titelbild: KI-generiert (KI-Bildgenerator)
„Das kann unsere Warenwirtschaft leider nicht.“ Diesen Satz höre ich in fast jedem zweiten Erstgespräch mit einem mittelständischen Betrieb. Meistens klingt er wie eine Klage über ein kaputtes System. Meistens ist er das nicht.
Eine Warenwirtschaft ist dafür gebaut, Artikel, Aufträge, Rechnungen und Lagerbestände korrekt und widerspruchsfrei zu verwalten. Sie ist nicht dafür gebaut, jedem einzelnen Team im Betrieb eine Oberfläche zu geben, die zu dessen Alltag passt. Der Lagerist braucht etwas anderes als die Buchhaltung. Der Außendienst braucht etwas anderes als der Kunde, der seinen eigenen Auftragsstatus sehen will. Dass die Wawi das alles nicht in einer einzigen Oberfläche abdeckt, ist also kein Defekt am System. Es ist Arbeitsteilung, die im Betrieb noch fehlt.
Woran es in der Praxis tatsächlich hakt
Wenn ich genauer nachfrage, was „kann sie nicht“ konkret bedeutet, laufen die Antworten fast immer auf eine von vier Stellen hinaus.
Erstens: keine brauchbare mobile Ansicht. Wer draußen beim Kunden oder in der Halle arbeitet, öffnet keine Desktop-Maske mit zwanzig Feldern auf dem Handy. Die Folge ist der Zettel, die Excel-Liste, das Foto per WhatsApp — und am Abend trägt jemand alles noch einmal von Hand nach.
Zweitens: kein Zugang für Externe, der die richtige Breite hat. Ein Kunde soll seinen Auftragsstatus sehen dürfen. Nicht die Kalkulation dahinter, nicht die Aufträge anderer Kunden, nicht die interne Notiz vom letzten Anruf. Die Wawi selbst kennt für diesen schmalen Ausschnitt oft nur zwei Zustände: alles oder nichts.
Drittens: ein Sonderprozess, den die Standardsoftware nicht vorsieht. Eine Freigabekette mit zwei Unterschriften ab einem bestimmten Betrag. Ein Rabattmodell, das historisch gewachsen ist und sich nicht in ein Standardfeld pressen lässt. Diese Prozesse existieren im Kopf der Mitarbeiter und in keiner Maske — bis jemand krank wird oder kündigt.
Viertens: Reporting, das die falschen Fragen beantwortet. Die Wawi liefert Zahlen. Ob diese Zahlen die Frage beantworten, die sich der Betrieb tatsächlich stellt, ist eine andere Sache. Häufig landet dann eine Excel-Tabelle dazwischen, die jemand jeden Monat von Hand pflegt — bis sie beim nächsten Personalwechsel verwaist.
Vier verschiedene Lücken, eine gemeinsame Eigenschaft: Keine davon bedeutet, dass die Warenwirtschaft als Ganzes falsch ist. Sie bedeuten, dass ein bestimmter Ausschnitt fehlt.
Der teure Reflex: alles ersetzen
Der naheliegende Schluss aus „das kann unser System nicht“ ist trotzdem oft: dann brauchen wir ein neues System. Ich verstehe den Impuls. Eine Software, die an einer Stelle nervt, nervt gefühlt überall.
Nur ist der Systemwechsel selten das, was er auf der Folie im Erstgespräch verspricht. Jahre an historischen Daten müssen migriert werden, inklusive der Altlasten, die niemand mehr sauber dokumentiert hat. Individuelle Felder und Auswertungen, die über die Zeit gewachsen sind, existieren im neuen System erst einmal nicht. Jede Schnittstelle zur Finanzbuchhaltung, zum Onlineshop, zum Versanddienstleister muss neu gebaut und getestet werden. Das ganze Team lernt eine neue Oberfläche, während der laufende Betrieb weitergehen muss — Monate, in denen mehr schiefgehen kann als vorher.
Und am Ende des Wechsels steht oft dieselbe Erkenntnis wie am Anfang: Auch das neue System deckt nicht jeden Alltag jedes Teams ab. Keine Standardsoftware der Welt tut das. Die eine Lücke, wegen der der Wechsel losging, ist vielleicht geschlossen. Zwei neue sind an anderer Stelle entstanden.
Ein Systemwechsel ist manchmal richtig — wenn das Fundament selbst nicht mehr trägt, wenn der Hersteller die Pflege eingestellt hat, wenn das System für eine Betriebsgröße gebaut wurde, die längst überschritten ist. Aber das ist eine andere Diagnose als „an einer Stelle fehlt uns etwas“.
Was „die Wawi respektieren“ konkret bedeutet
Meine Antwort auf die vier Lücken von oben ist fast nie ein neues System. Es ist eine eigene, schmale Oberfläche — gebaut für genau die eine Sache, die fehlt, und für sonst nichts.
Der Teil, auf den es ankommt, ist nicht die Oberfläche selbst. Es ist die Regel dahinter: Die Warenwirtschaft bleibt die einzige Quelle der Wahrheit. Das heißt konkret:
Kein zweiter Datenbestand. Die neue Oberfläche legt keine eigene Kopie der Aufträge, Artikel oder Kundendaten an, die parallel gepflegt werden müsste. Zwei Bestände, die getrennt gepflegt werden, laufen über kurz oder lang auseinander — das ist keine Frage von Sorgfalt, sondern von Zeit.
Jede Lese- und Schreiboperation läuft über die Schnittstelle des führenden Systems zurück. Der Servicetechniker trägt seine Rückmeldung in der schlanken Oberfläche ein — sie landet über die API in genau demselben Auftrag, den die Buchhaltung in der Wawi sieht. Nicht als Export, nicht als nächtlicher Abgleich, sondern in dem Moment, in dem sie eingetragen wird.
Rollen und Berechtigungen werden übernommen, nicht neu erfunden. Wer in der Wawi heute eine bestimmte Information sehen darf, sieht sie auch in der neuen Oberfläche — nicht mehr und nicht weniger. Zwei getrennte Berechtigungslisten laufen genauso auseinander wie zwei getrennte Datenbestände.
Und der Umfang bleibt bewusst klein. Es geht nicht darum, die Warenwirtschaft „nebenbei schöner“ zu machen. Es geht darum, exakt die eine Lücke zu schließen, die den Alltag im Betrieb tatsächlich bremst.
Ein Beispiel aus der Praxis
Ein Handwerksbetrieb, anonymisiert: Das Team draußen bekam seine Aufträge morgens auf Papier ausgedruckt. Rückmeldungen — erledigt, verschoben, Material fehlt — kamen abends per Anruf oder gar nicht, und jemand im Büro tippte sie am nächsten Morgen nach. Zwischen „vor Ort erledigt“ und „in der Wawi sichtbar“ lag routinemäßig ein Tag, manchmal mehr.
Die Warenwirtschaft selbst hatte dafür keine brauchbare mobile Ansicht — das ist nicht ihr Zweck, und das ist in Ordnung. Statt das ganze System zu ersetzen, habe ich eine schlanke Oberfläche gebaut: Sie zeigt jedem Techniker morgens genau seine offenen Aufträge, gelesen direkt aus der Wawi über deren Schnittstelle. Eine Rückmeldung vor Ort — erledigt, Foto, Materialbedarf — schreibt sofort in denselben Auftrag zurück, den die Buchhaltung sieht. Kein Zwischenschritt, kein zweites System, kein Zettel.
Aufwand: rund zwei Wochen. Die Warenwirtschaft selbst blieb unangetastet — sie bekam nur einen zusätzlichen, sehr gezielten Zugang.
Ein zweites Beispiel, kleiner: Ein Kunde wollte, dass seine eigenen Kunden den Status ihrer Aufträge selbst nachsehen können, ohne jedes Mal anzurufen. Auch hier war die Antwort kein Kundenportal-Modul der Wawi mit sämtlichen internen Feldern, sondern eine schmale Ansicht, die genau einen Ausschnitt zeigt — Status, voraussichtliches Datum, nichts sonst — und diesen Ausschnitt live aus dem führenden System liest.

Wo dieser Ansatz an seine Grenzen kommt
Diese Lösung passt nicht auf jede Lücke, und ich sage das lieber vorher als hinterher.
Wenn die Schnittstelle der Warenwirtschaft die benötigte Information oder Operation überhaupt nicht hergibt, kann eine schlanke Oberfläche sie nicht herbeizaubern. Manche Hersteller öffnen ihre API nur teilweise, manche gar nicht. Dann ist die ehrliche Antwort tatsächlich eine Systemfrage — nicht mehr eine Oberflächenfrage.
Wenn der Hersteller seine Schnittstelle ändert oder abschaltet, ohne das rechtzeitig anzukündigen, bricht die zusätzliche Oberfläche mit ihr. Das ist kein Argument gegen den Ansatz, aber ein Argument dafür, so etwas nicht einmalig zu bauen und dann sich selbst zu überlassen — dafür braucht es dieselbe Art von laufender Betreuung wie bei jeder Software, die produktiv im Einsatz ist.
Und manchmal ist das eigentliche Problem gar keine fehlende Oberfläche, sondern ein Prozess, der selbst nie sauber definiert wurde. Eine Oberfläche kann einen unklaren Ablauf sichtbar machen. Sie kann ihn nicht reparieren. Wenn niemand im Betrieb genau sagen kann, wer wann welche Freigabe erteilt, ist das zuerst ein Gespräch, keine Softwarefrage.
Wie ich das angehe
Bevor ich irgendetwas baue, steht ein kurzer, bewusst unspektakulärer Ablauf:
Erst prüfen, was wirklich fehlt — nicht, was sich auf den ersten Blick wünschenswert anfühlt. Eine Wunschliste und eine tatsächliche Lücke sind zwei verschiedene Dinge, und nur die zweite rechtfertigt eine eigene Oberfläche.
Dann prüfen, was die Schnittstelle der Warenwirtschaft überhaupt hergibt. Das entscheidet, ob der Ansatz trägt oder ob die Antwort tatsächlich woanders liegt.
Den Umfang bewusst klein halten. Genau die eine Lücke schließen, nicht nebenbei ein zweites Projekt daraus machen.
Rollen und Berechtigungen aus dem führenden System übernehmen, nicht neu erfinden.
Und keine eigene Datenhaltung aufbauen, die auf Dauer gepflegt werden müsste. Was in der Wawi steht, bleibt die Wahrheit — auch nach dem, was ich gebaut habe.
Eine Warenwirtschaft, die nicht alles kann, ist normal. Jede kann das nicht — dafür ist keine gebaut. Die Frage ist nicht, ob man sie ersetzt. Die Frage ist, ob die fehlende Stelle eine eigene, schmale Oberfläche verdient, die das führende System respektiert, statt es zu verdoppeln.