Inventurdifferenzen werden bei der Inventur sichtbar. Entstanden sind sie häufig bereits lange vorher. Durch Materialbewegungen, die nicht oder zu spät gebucht wurden. Durch Abläufe, die im System anders vorgesehen sind, als sie im Lager tatsächlich durchgeführt werden. Oder durch Systemfunktionen, deren Bedeutung im operativen Alltag nicht ausreichend bekannt ist.
In den bisherigen Beiträgen unserer Inventurserie haben wir bereits betrachtet, warum häufige Inventuren ein Warnsignal sein können, weshalb Inventurergebnisse nicht automatisch die tatsächliche Bestandssituation widerspiegeln, wie Fertigungsaufträge, Stücklisten und Materialflüsse Bestände beeinflussen und warum Inventurdifferenzen selten nur ein Lagerproblem sind.
Bereits erschienen in dieser Serie
Bei der Betrachtung von Inventurdifferenzen aus IT-Sicht schließt sich daran eine weitere Perspektive an: diese können auch dort entstehen, wo Lagerprozess, Systemabbildung und tatsächliche Systemnutzung nicht zusammenpassen. Das ist weder allein ein technisches Problem noch allein ein Problem des Lagers. Es ist eine Schnittstellenaufgabe. Sie lässt sich nur lösen, wenn beide Seiten verstehen, wie die andere arbeitet und welche Auswirkungen Entscheidungen im eigenen Bereich auf den gesamten Prozess haben.
Inhalt
Das System zeigt nur die erfasste Realität
Ein Warenwirtschafts- oder Lagerverwaltungssystem bildet Materialbewegungen, Bestände und Buchungen entsprechend der hinterlegten Prozesse ab. Die daraus entstehenden Auswertungen können technisch korrekt sein und trotzdem nicht vollständig mit der physischen Realität übereinstimmen. Das System zeigt nicht automatisch, was tatsächlich im Lager passiert ist. Es zeigt, was entsprechend der vorgesehenen Logik im System konfiguriert und programmiert wurde.
Welche konkreten Ursachen hinter Inventurdifferenzen stehen und warum sie selten nur im Lager entstehen, haben wir bereits im Beitrag „Ursachen von Inventurdifferenzen sind selten nur ein Lagerproblem“ betrachtet. Aus IT-Sicht interessiert an dieser Stelle etwas anderes: warum das System diese Lücke grundsätzlich nicht von selbst schließen kann und was das für die Zusammenarbeit zwischen Lager und IT bedeutet.
Der einzelne Vorgang wirkt möglicherweise klein. Wiederholt er sich jedoch täglich, an mehreren Arbeitsplätzen oder bei größeren Materialmengen, entsteht über die Zeit eine relevante Differenz. Nach einer Inventur werden festgestellte Abweichungen geprüft und die Bestände im System entsprechend korrigiert. Damit stimmen Systembestand und gezählter Bestand zunächst wieder besser überein. Die Ursache der Inventurdifferenz ist dadurch jedoch nicht automatisch behoben.
Passen realer Ablauf, Systemprozess und Systemnutzung weiterhin nicht zusammen, beginnen die nächsten Abweichungen bereits mit den folgenden Vorgängen.
Vor Ort zeigt sich, was eine Fehlermeldung nicht erklärt
In einem Lagerprojekt wurde ein neues System eingeführt und anschließend vor Ort getestet. Aus dem Lager kam die Rückmeldung, dass die Scanner nicht richtig funktionierten. Zunächst klang das nach einem technischen Fehler.
Erst während der Beobachtung vor Ort wurde sichtbar, dass sich mehrere Mitarbeitende mit demselben Benutzer angemeldet hatten. Das System war für diese parallele Nutzung nicht ausgelegt und konnte die Buchungsvorgänge deshalb nicht eindeutig verarbeiten. Die Scanner waren also nicht grundsätzlich defekt. Das Problem entstand durch die konkrete Nutzung des Systems.
Ein Supportticket mit der Beschreibung „Scanner funktionieren nicht“ hätte diese Ursache nur schwer erkennen lassen. Die Rückmeldung beschrieb das sichtbare Problem aus Sicht der Mitarbeitenden. Erst durch den Blick auf den tatsächlichen Ablauf wurde verständlich, was dahinterlag. Solche Situationen zeigen, warum Prozessbeschreibungen, Tickets und Abstimmungstermine allein nicht immer ausreichen. Sie bilden nur einen Ausschnitt ab.
Entscheidend ist, wie das System unter realen Bedingungen genutzt wird. Dazu gehören Zeitdruck, Arbeitswege, Schichtwechsel, verfügbare Geräte, Benutzeranmeldungen, Ausnahmen und pragmatische Lösungen, die sich im Alltag entwickelt haben. Das zeigt, dass die IT diese Zusammenhänge nur dann wirklich beurteilen kann, wenn sie den Prozess dort sieht, wo er tatsächlich stattfindet.
Gemeldetes Problem
„Scanner funktionieren nicht“
Tatsächliche Ursache
Bei mehreren Plätze ist derselbe Benutzer eingeloggt
Erst der Blick auf den realen Ablauf macht die Ursache sichtbar.
Verständnis entsteht nicht im eigenen Bereich
Zwischen Lager und IT entstehen schnell vereinfachte Erklärungen. Im Lager heißt es möglicherweise, das System sei zu kompliziert oder die IT verstehe den Prozess nicht. In der IT entsteht umgekehrt der Eindruck, dass die vorgesehenen Abläufe nicht eingehalten oder Funktionen falsch genutzt werden. Beide Wahrnehmungen können einen Teil der Realität abbilden. Sie lösen das Problem jedoch nicht.
Verständnis entsteht nicht dadurch, dass jeder seine Sicht nochmal erklärt oder in Meetings darüber diskutiert wird. Es entsteht dort, wo man die Arbeitsrealität des anderen kennenlernt.
Für IT-Verantwortliche, die Systeme für Lager oder Supply Chain betreuen, gehört deshalb mehr dazu als die technische Systemsicht: Sie sollten mehrere Tage, im Idealfall eine ganze Woche, im Lager mitlaufen, nicht als kurzer Rundgang, sondern als echter Einblick in die täglichen Abläufe. Wie funktioniert die Warenannahme? Wann wird Material gebucht? Welche Informationen stehen in diesem Moment zur Verfügung? Wie werden Scanner und Anwendungen genutzt? Welche Ausnahmen treten regelmäßig auf? Welche Wege müssen Mitarbeitende zurücklegen? Wie werden Inventurvorgänge im System vorbereitet, durchgeführt und nachbearbeitet? Ein Prozessdiagramm kann diese Fragen nur begrenzt beantworten.
Umgekehrt kann es hilfreich sein, Mitarbeitenden aus dem Lager Einblick in die Arbeit der IT zu geben. Sie können erleben, welche Meldungen im Support eingehen, welche Informationen für eine Fehleranalyse benötigt werden und welche Auswirkungen mehrere falsche oder verspätete Buchungen auf andere Systeme, Prozesse oder sogar Standorte haben können.
Auch die Bedeutung der eigenen Buchungen wird dadurch verständlicher. Eine Materialbuchung ist nicht nur ein einzelner Arbeitsschritt im Lager. Die Daten können in Planung, Einkauf, Produktion, Disposition, Bewertung und Controlling weiterverwendet werden. Eine Abweichung an einer Stelle kann deshalb Folgen an mehreren anderen Stellen auslösen.
Der Perspektivwechsel ersetzt keine Prozessbeschreibung und keine Schulung. Er schafft jedoch eine Grundlage dafür, dass beide Seiten nicht nur ihren eigenen Ausschnitt sehen. Wo die Zusammenarbeit bereits gut funktioniert, braucht es keine zusätzlichen Maßnahmen. Treten jedoch immer wieder dieselben Buchungsfehler, Missverständnisse oder Inventurdifferenzen auf, kann eine zeitlich begrenzte Hospitation eine sehr gezielte Investition sein.
Anforderungen müssen gemeinsam übersetzt werden
Mitarbeitende im Lager müssen keine fertigen IT-Anforderungen formulieren können. Sie kennen ihre Abläufe, Schwierigkeiten, Ausnahmen und die Stellen, an denen das System im Alltag nicht unterstützt. Die IT wiederum sollte eine Anforderung nicht nur wörtlich aufnehmen und technisch umsetzen. Sie muss verstehen, welches Problem dahinterliegt.
Ein Beispiel: Die Anforderung lautet, das System müsse künftig viermal im Jahr eine vollständige Inventur ermöglichen statt wie bisher einmal. Technisch lässt sich das umsetzen. Die eigentliche Frage lautet aber: Warum reicht eine Inventur pro Jahr nicht mehr aus?
Wird diese Frage nicht gestellt, entsteht eine Systemanpassung, die ein Symptom bedient, ohne die Ursache zu kennen. Möglicherweise ist die Bestandsgenauigkeit über das Jahr so gering, dass Verantwortliche dem System zwischenzeitlich nicht mehr trauen und mit häufigeren Zählungen gegensteuern, statt die Buchungsdisziplin oder die Systemnutzung zu verbessern. Die Anforderung wäre dann keine Weiterentwicklung, sondern ein Hinweis auf ein ungelöstes Problem an anderer Stelle.
Eine Anforderung, deren Ursache niemand kennt, ist kein Fortschritt – sie ist ein ungelöstes Symptom.
Diese Übersetzungsarbeit – von der formulierten Anforderung zur eigentlichen Ursache – gelingt am besten gemeinsam mit den Menschen, die den Prozess tatsächlich ausführen. Dabei geht es nicht darum, jede individuelle Arbeitsweise unverändert in einem System abzubilden. Ein Standardsystem braucht klare Regeln und nachvollziehbare Abläufe. Gleichzeitig darf eine Anforderung nicht allein deshalb umgesetzt werden, weil sie technisch machbar ist.
Genau an diesem Punkt entscheidet sich, ob aus einer Anforderung eine sinnvolle Verbesserung wird oder eine Sonderlösung, die nur ein Symptom verwaltet.
Ungeprüfte Sonderlösungen verursachen Folgekosten
Entsteht aus einer nicht ausreichend geklärten Anforderung eine Sonderlösung, wirkt diese häufig weit über den ursprünglichen Anlass hinaus. Nicht jede Abweichung vom Standard ist vermeidbar. Unternehmen haben unterschiedliche Produkte, Materialflüsse, Kundenanforderungen und organisatorische Rahmenbedingungen. Entscheidend ist deshalb nicht, Sonderlösungen grundsätzlich zu verhindern, sondern ihre Notwendigkeit und ihre Folgen bewusst zu bewerten.
Individuelle Funktionen, zusätzliche Auswertungen, besondere Buchungslogiken oder wiederkehrende Sonderabläufe verursachen nicht nur Aufwand bei der Einführung. Sie müssen dokumentiert, getestet und unterstützt werden. Auch bei späteren Änderungen, Updates oder Prozessanpassungen müssen sie erneut berücksichtigt werden. Dadurch entstehen dauerhafte Kosten, die im ursprünglichen Änderungswunsch häufig nicht vollständig sichtbar sind.
In unserem Beitrag zu unsichtbaren IT-Kosten haben wir bereits beschrieben, wie fehlende Standards, individuelle Lösungen und gewachsene Datenstrukturen langfristig Aufwand erzeugen. Derselbe Zusammenhang gilt auch beim Thema Inventurdifferenzen aus IT-Sicht.
Die zusätzliche Systemfunktion kann technisch sauber umgesetzt sein und trotzdem die falsche Antwort auf das eigentliche Problem darstellen. Wird beispielsweise eine wiederkehrende Zusatzlogik aufgebaut, um unzuverlässige Bestände auszugleichen, bleibt der zugrunde liegende Prozess möglicherweise unverändert. Das System verwaltet dann dauerhaft die Folgen einer Ursache, die an anderer Stelle weiterhin besteht.
Deshalb sollte vor einer Abweichung vom Standard geklärt werden, welches fachliche Bedürfnis tatsächlich vorliegt. Benötigt der Prozess wirklich eine individuelle Lösung? Oder soll die Anpassung einen Ablauf kompensieren, der nicht zuverlässig funktioniert, nicht verstanden wird oder im System nicht passend abgebildet ist?
Diese Unterscheidung ist für das gesamte Unternehmen relevant. Zusätzliche Prozessschritte, Systemanpassungen, Tests, Supportfälle und Abstimmungen binden Zeit und Geld. Gleichzeitig erhöhen sie die Komplexität und erschweren spätere Veränderungen. Eine technisch mögliche Sonderlösung kann deshalb wirtschaftlich trotzdem die schlechtere Entscheidung sein.
Verantwortung heißt, nach dem Warum zu fragen
Von einer Person, die ein System betreut oder einen Change technisch umsetzt, kann nicht erwartet werden, jede fachliche, rechtliche und wirtschaftliche Dimension allein zu bewerten. Genau deshalb braucht es klare Verantwortlichkeiten und geeignete Governance.
Gibt es eine Ende-zu-Ende-Prozessverantwortung, sollte diese beurteilen können, wie sich eine Änderung auf den gesamten Ablauf auswirkt. Die fachlich Verantwortlichen müssen erklären, welches Problem gelöst werden soll. Die IT sollte technische Abhängigkeiten, Risiken und Folgekosten transparent machen.
Bei größeren Abweichungen vom Standard kann zusätzlich ein geeignetes Entscheidungsformat erforderlich sein. Wie dies genau umgesetzt wird, ist zweitrangig. Entscheidend ist, dass Änderungen mit bereichsübergreifenden Auswirkungen nicht ausschließlich innerhalb eines einzelnen Silos entschieden werden.
Verantwortung bedeutet in diesem Zusammenhang nicht, jede Anforderung grundsätzlich abzulehnen oder den Fachbereich zu kontrollieren. Sie bedeutet, bei wiederkehrenden Sonderlösungen und auffälligen Abweichungen genauer hinzuschauen.
Bevor eine Sonderlösung entschieden wird, hilft ein Blick auf diese Fragen:
- ? Warum wird diese Änderung benötigt?
- ? Welches Problem soll sie lösen?
- ? Welche anderen Bereiche sind betroffen?
- ? Welche dauerhaften Aufwände entstehen?
- ? Gibt es eine Möglichkeit, die Ursache statt nur das sichtbare Symptom zu bearbeiten?
Gerade bei wiederkehrenden Zusatzprozessen sollte die IT hellhörig werden. Nicht, weil die Anforderung automatisch falsch ist, sondern weil sie ein Hinweis darauf sein kann, dass Prozess und System bereits länger nicht sauber zusammenspielen.
Bestandsqualität entsteht durch gemeinsame Verantwortung
Verlässliche Bestandsdaten entstehen dort, wo der reale Materialfluss, die vorgesehenen Prozesse und ihre Abbildung im System zusammenpassen. Dafür reicht es nicht, jeden Bereich für sich zu betrachten. Entscheidend ist das Zusammenspiel an den Übergängen.
Die Mitarbeitenden im Lager wissen, wie die Abläufe unter realen Bedingungen funktionieren, welche Ausnahmen auftreten und an welchen Stellen Buchungen im Alltag schwierig werden. Die IT kennt die Systemlogik, technische Abhängigkeiten und die Auswirkungen einzelner Änderungen. Prozessverantwortliche verbinden diese Perspektiven über Bereichsgrenzen hinweg. Führungskräfte schaffen den Rahmen, in dem Auffälligkeiten offen angesprochen und gemeinsam bearbeitet werden können.
Keine dieser Perspektiven allein bildet den gesamten Zusammenhang ab. Erst im Austausch wird sichtbar, ob ein Ablauf im System nicht passend hinterlegt ist, eine Funktion anders genutzt wird als vorgesehen oder eine Anforderung lediglich ein Symptom beschreibt.
Nach einer Inventur können festgestellte Differenzen geprüft und die Bestände entsprechend korrigiert werden. Belastbare Bestandsdaten entstehen jedoch nicht durch die Korrektur allein. Sie entstehen, wenn die Ursachen verstanden und Prozess, System und Nutzung gemeinsam weiterentwickelt werden.
Dafür braucht es die Bereitschaft, über den eigenen Arbeitsbereich hinauszuschauen, zuzuhören und konkrete Abläufe gemeinsam nachzuvollziehen. Das Ziel ist kein Kompromiss zwischen Lager und IT, sondern ein Prozess, der operativ funktioniert und im System verlässlich abgebildet werden kann.
Inventurdifferenzen gemeinsam einordnen
Besteht der Verdacht, dass wiederkehrende Inventurdifferenzen nicht ausreichend erklärt sind, betrachten wir das Thema im 4-Wochen-Intensiv Bestände im Griff gezielt. Wir prüfen, an welchen Stellen reale Abläufe, Buchungen, Systemabbildung und Verantwortlichkeiten nicht zusammenpassen, bewerten die relevanten Ursachen und legen konkrete nächste Schritte fest.
Geht es nicht nur um die Bestände, sondern um eine übergreifende Standortbestimmung des Unternehmens, bietet der Unternehmens-Check-Up den passenden Rahmen. Dabei betrachten wir gemeinsam mit der Geschäftsführung und den relevanten Bereichen das gesamte Unternehmen. Wir machen sichtbar, wo Handlungsbedarf besteht, welche Themen vertieft werden sollten und welche Bereiche bereits gut und tragfähig aufgestellt sind.
Was eine belastbare Ursachenklärung braucht
- Prozess vor Ort verstehen, nicht nur beschrieben
- Systemlogik und reale Nutzung gemeinsam prüfen
- Anforderungen auf ihre eigentliche Ursache prüfen
- Verantwortung an den Schnittstellen klar benennen
- Sonderlösungen bewusst statt automatisch entscheiden
Welcher Einstieg passt zu Ihrer Situation?
Im Erstgespräch klären wir, welcher Rahmen für die Ursachenklärung sinnvoll ist.