Der Vertrieb sieht einen verfügbaren Artikel, während das Lager die letzte Einheit bereits für einen anderen Auftrag reserviert hat. Im Einkauf liegt gleichzeitig eine Bestellung, deren Liefertermin nur im E-Mail-Verlauf dokumentiert ist. Solche Situationen zeigen, dass Warenwirtschaft mehr umfasst als eine Artikelliste: Sie verbindet Entscheidungen über Bestand, Beschaffung und Kundenversprechen.

Eine individuelle Warenwirtschaft kann diese Zusammenhänge sichtbar machen. Ihr Nutzen entsteht jedoch nicht durch möglichst viele Kennzahlen auf einer Startseite, sondern durch ein verlässliches Modell der betrieblichen Vorgänge. Wer ein solches System plant, sollte deshalb bei Bewegungen, Zuständigkeiten und Ausnahmen beginnen. Das folgende Beispiel beschreibt mögliche Anforderungen; es steht nicht für ein tatsächlich durchgeführtes Kundenprojekt.

Stammdaten sind die gemeinsame Sprache

Artikelnummern, Einheiten und Varianten müssen eindeutig sein. Wenn ein Produkt im Einkauf als Karton und im Verkauf als Einzelstück geführt wird, braucht es eine nachvollziehbare Umrechnung. Auch Lieferantenartikelnummern, Verpackungseinheiten und interne Bezeichnungen sollten getrennt gespeichert werden. Eine zusätzliche Textspalte löst solche Beziehungen nur vorübergehend.

Vor der Migration sind Dubletten, ungenutzte Felder und uneinheitliche Schreibweisen zu untersuchen. Ein Unternehmen kann sonst eine technisch moderne Anwendung mit den Widersprüchen der bisherigen Listen starten. Für wichtige Stammdaten sollte feststehen, wer sie anlegen und verändern darf. Änderungen an Einheiten oder Varianten können Auswirkungen auf offene Aufträge haben und benötigen gegebenenfalls besondere Prüfungen.

Bestand ist mehr als eine Zahl

Physisch vorhanden, reserviert, gesperrt und erwarteter Wareneingang sind verschiedene Zustände. Eine sinnvolle Bestandsanzeige unterscheidet sie. Verfügbare Menge lässt sich nicht zuverlässig darstellen, wenn Reservierungen nur als Kommentar am Auftrag stehen. Ebenso sollten beschädigte oder noch nicht geprüfte Waren nicht automatisch als lieferbar gelten.

Ein robustes Modell dokumentiert Bestandsbewegungen mit Bezug zum auslösenden Vorgang. Wareneingang, Entnahme, Umlagerung, Inventurkorrektur und Storno haben unterschiedliche Bedeutungen. So kann später nachvollzogen werden, wie ein Bestand entstanden ist. Die reine Überschreibung einer aktuellen Zahl verschleiert dagegen die Ursache einer Abweichung und erschwert sowohl Fehlersuche als auch Abstimmung zwischen Abteilungen.

Gleichzeitige Buchungen berücksichtigen

Wenn zwei Personen auf denselben Bestand zugreifen, darf die Anwendung eine Reservierung nicht nur anhand eines zuvor geladenen Bildschirmwertes erlauben. Prüfung und Buchung müssen auf Datenbankebene zusammenpassen. Transaktionen können zusammengehörige Änderungen als Einheit behandeln. Die PostgreSQL-Dokumentation erläutert dieses Prinzip anhand mehrerer Schritte, die gemeinsam erfolgreich sein oder gemeinsam verworfen werden sollen. Das konkrete Sperr- und Konfliktverfahren hängt vom gewählten System ab.

Vom Bedarf zur Bestellung

Ein niedriger Bestand ist ein Hinweis, aber noch keine fertige Einkaufsentscheidung. Wiederbeschaffungszeit, Mindestbestellmenge, offene Lieferungen und Nachfrage spielen ebenfalls eine Rolle. Die Anwendung sollte deshalb zeigen, auf welcher Grundlage ein Bestellvorschlag entsteht. Automatisch erzeugte Vorschläge bleiben prüfbar, wenn Herkunft und Annahmen sichtbar sind.

Ein fiktiver Großhändler könnte Bestellungen zunächst sammeln und erst nach Freigabe an den Lieferanten übermitteln. Teillieferungen müssen anschließend dem ursprünglichen Auftrag zugeordnet werden. Bleibt ein Rest offen, ist dieser ausdrücklich sichtbar. Preisabweichungen und geänderte Termine gehören in einen definierten Bearbeitungsweg, statt in voneinander getrennten E-Mail-Postfächern zu verschwinden.

Auftragserfassung und Kundeninformationen

Bei der Auftragserfassung treffen kaufmännische und logistische Anforderungen aufeinander. Ansprechpartner, Lieferadresse, Preisvereinbarung und gewünschter Termin müssen zusammenpassen. Außerdem ist zu unterscheiden, welche Angaben vom Stammdatensatz übernommen werden und welche bewusst für diesen Auftrag gelten. Eine spätere Adressänderung darf bereits abgeschlossene Vorgänge nicht unbeabsichtigt umschreiben.

Hilfreich sind klare Statuswerte mit verständlichen Übergängen. Ein Auftrag kann erfasst, geprüft, freigegeben, teilweise geliefert oder abgeschlossen sein. Jeder Status sollte eine fachliche Bedeutung haben. Wer einen Auftrag ändern darf, ist nicht zwingend auch zur Freigabe berechtigt. Besonders bei Stornierungen und Mengenänderungen muss die Bestandswirkung nachvollziehbar bleiben.

Schnittstellen gezielt einsetzen

Shops, Versanddienste, Buchhaltung und Lieferantenportale können relevante Daten liefern oder benötigen. Eine Schnittstelle sollte jedoch nicht automatisch alle vorhandenen Felder übertragen. Zunächst ist zu klären, welches System für einen Artikel, eine Adresse oder einen Zahlungsstatus die führende Quelle ist. Erst danach werden Datenfluss, Aktualisierung und Fehlerbehandlung festgelegt.

Ein Import braucht Prüfungen für Pflichtfelder, Datentypen und eindeutige Schlüssel. Erneutes Einlesen derselben Lieferung darf nicht unbemerkt doppelte Bestandsbewegungen erzeugen. Fehlerhafte Datensätze sollten mit verständlicher Ursache zurückgestellt werden können. Ein technisches Protokoll allein reicht nicht, wenn Beschäftigte den Vorgang anschließend fachlich korrigieren müssen. Der Artikel über APIs und Schnittstellen vertieft diese Übergänge.

Automatisierung mit kontrollierbaren Grenzen

Wiederkehrende Abläufe eignen sich besonders für Automatisierung, wenn ihre Regeln klar sind. Beispiele sind Hinweise auf niedrige Bestände, die Vorbereitung wiederkehrender Bestellungen oder das Erzeugen einer Versandliste nach Freigabe. Die Automatisierung sollte nicht zugleich eine fehlende Entscheidung kaschieren. Unvollständige Lieferadressen oder widersprüchliche Preise benötigen einen erkennbaren Ausnahmeprozess.

Für automatisierte Aufgaben sind Verantwortliche, Wiederholungsregeln und Abbruchbedingungen erforderlich. Wird ein Hintergrundprozess unterbrochen, muss er anschließend sicher fortgesetzt werden können. Außerdem sollten Beschäftigte sehen, ob ein Vorgang geplant, erfolgreich abgeschlossen oder fehlgeschlagen ist. Unsichtbare Automatisierung schafft neue Unsicherheit, sobald ihr Ergebnis nicht mit der Erwartung übereinstimmt.

Auswertungen verständlich definieren

Umsatz, Auftragseingang, Lagerwert und Lieferfähigkeit beantworten unterschiedliche Fragen. Ein Dashboard sollte diese Größen nicht vermischen. Beim Lagerwert ist beispielsweise relevant, welches Bewertungsverfahren verwendet wird und ob gesperrte Bestände einbezogen sind. Eine grafische Darstellung ohne Definition kann verschiedene Abteilungen zu widersprüchlichen Schlussfolgerungen führen.

Für jede Kennzahl sollten Quelle, Berechnung, Zeitraum und Aktualisierungsstand dokumentiert sein. Fachlich Verantwortliche müssen Vergleichswerte prüfen können. Geht es um steuerliche oder handelsrechtliche Anforderungen, sind die dafür geeigneten Fachsysteme und Prüfungen einzubeziehen. Eine individuelle Warenwirtschaft ist nicht allein aufgrund ihrer Funktionsbezeichnung eine rechtskonforme Buchhaltung oder revisionssichere Archivierung.

Webbasierte Bedienung richtig planen

Eine Webanwendung kann zentrale Daten über Browser zugänglich machen und die Verteilung von Programmversionen vereinfachen. Das ist im Lager allerdings nur hilfreich, wenn Geräte, Scanner, Netzabdeckung und Arbeitsumgebung berücksichtigt werden. Kleine Schaltflächen auf einem Bürobildschirm sind kein geeigneter Maßstab für eine mobile Lageroberfläche.

Ein Pilot sollte einen vollständigen, aber begrenzten Ablauf abdecken: beispielsweise Wareneingang, Einlagerung und Entnahme einer Artikelgruppe. Parallel werden Berechtigungen, Sicherungen und Wiederherstellung geprüft. Für Störungen braucht es ein abgestimmtes Ersatzverfahren. Wer diese Punkte früh betrachtet, vermeidet, dass die eigentliche Einführung an alltäglichen Betriebsbedingungen scheitert.

Inventur und Korrekturen nicht nachträglich ergänzen

Die Inventur ist ein guter Prüfstein für das Datenmodell. Ein gezählter Bestand und der zuvor berechnete Bestand können voneinander abweichen. Die Anwendung sollte beide Informationen nachvollziehbar behandeln und eine bestätigte Korrektur als eigenen Vorgang erfassen. Wird lediglich die aktuelle Zahl ersetzt, verschwinden Ursache, Prüfweg und Verantwortlichkeit aus dem fachlichen Zusammenhang.

Ähnliches gilt für Retouren. Eine zurückgesendete Ware ist nicht automatisch wieder verkaufsfähig. Sie kann zunächst geprüft, gesperrt oder einem besonderen Lagerbereich zugeordnet werden müssen. Welche Zustände erforderlich sind, hängt von Produkten und betrieblichen Vorgaben ab. Bereits ein kleiner Pilot sollte deshalb mindestens eine Rückgabe und eine korrigierte Buchung enthalten.

Für die Einführung kann eine überschaubare Artikelgruppe mit unterschiedlichen Eigenschaften ausgewählt werden: ein Einzelstückartikel, ein Produkt mit Verpackungseinheit und eine Variante mit gesperrtem Bestand. An diesen Beispielen lässt sich prüfen, ob Mengeneinheiten, Reservierungen und Rücknahmen zusammenpassen. Die Auswahl sollte typische Komplexität zeigen, ohne den gesamten Betrieb gleichzeitig umzustellen.

Schließlich braucht jede Bestandskorrektur eine angemessene Berechtigung. Wer Ware erfasst, darf nicht zwingend jede Differenz selbst freigeben. Eine verständliche Trennung von Erfassung und Bestätigung kann fachliche Kontrollen unterstützen. Welche Nachweise aufbewahrt werden müssen, wird mit den zuständigen kaufmännischen und gegebenenfalls rechtlichen Fachpersonen abgestimmt.

Von einer Liste zu verlässlichen Abläufen

Der Kern einer guten Warenwirtschaft ist ein nachvollziehbarer Zusammenhang zwischen Daten und Vorgängen. Eine gemeinsame Oberfläche kann diesen Zusammenhang unterstützen, wenn fachliche Regeln, Datenqualität und technische Sicherung zusammen entwickelt werden. Je deutlicher Ausnahmefälle beschrieben sind, desto belastbarer lässt sich der erste Entwicklungsumfang begrenzen.

Unser ERP-Anwendungsbeispiel zeigt eine mögliche Oberfläche mit ausdrücklich fiktiven Daten. Für eine konkrete Anwendung würde GRITTMANN zunächst Bewegungen, Zuständigkeiten und vorhandene Systeme aufnehmen. Darauf folgt ein Konzept, dessen Nutzen und Grenzen anhand tatsächlicher Arbeitsabläufe überprüfbar sind.

Quellen und weiterführende Dokumentation

Fachliche Grundlagen und ergänzende Hinweise der jeweiligen Herausgeber. Links zuletzt geprüft am 06.03.2026.