Leitfaden

Was ein gutes Bestandsprotokoll festhält (und was den meisten fehlt)

Veröffentlicht am · 7 Min. Lesezeit

Jedes Bestandssystem zeigt Ihnen eine Zahl. Weniger zeigen Ihnen, wie diese Zahl zustande kam. Dieser zweite Teil, das Protokoll, ist das, wonach Sie greifen, sobald die Zahl falsch aussieht, und es ist nur so nützlich wie das, was es sich aufzuschreiben die Mühe gemacht hat. Ein Protokoll, das „Bestand geändert“ sagt, ohne Namen, ohne Grund und ohne Vorher und Nachher, ist kaum besser als gar kein Protokoll.

Dieser Leitfaden ist eine Checkliste. Er behandelt, was jede Zeile eines Bestandsprotokolls erfassen sollte, die zwei Arten von Änderungen, die die meisten Protokolle vergessen, und ein paar Regeln, die ein Protokoll vertrauenswürdig und lesbar halten, wenn es erst einmal Tausende Zeilen hat. Nutzen Sie ihn, um das System zu beurteilen, das Sie heute haben, ob Software, Tabelle oder Klemmbrett am Nagel.

Package Pal zwischen zwei Klemmbrettern, eines voller grüner Häkchen, das andere mit verstreuten roten Punkten.
Zwei Protokolle derselben Woche. Nur eines davon kann eine Frage beantworten.

Die sechs Dinge, die jede Zeile braucht

Betrachten Sie jede Protokollzeile als winzigen Vorfallsbericht. Fehlt eines dieser Dinge, gibt es eine Frage, die sie nicht beantworten kann.

  1. Welcher Artikel. Offensichtlich, aber er muss Umbenennungen und Löschungen überstehen. Eine Zeile, die auf „Artikel 214“ verweist, ist nutzlos, sobald Artikel 214 weg ist.
  2. Was sich geändert hat. Welcher Bereich (im Regal, bestellt, in Auslieferung, beschädigt) oder welche Angabe des Artikels.
  3. Um wie viel, oder von was zu was. Eine Bewegung braucht die Menge samt Einheit („−2,5 kg“, nicht „−2,5“). Eine Bearbeitung braucht den alten und den neuen Wert.
  4. Wer. Eine namentlich bekannte Person, nicht „admin“ oder ein gemeinsamer Tablet-Login. Wenn sich alle als „Lager“ anmelden, kann das Protokoll immer nur sagen, dass es das Lager war.
  5. Wann. Ein exakter Zeitstempel, vom System erfasst und nicht am Schichtende von einer Person eingetippt.
  6. Warum, und über welchen Weg. Ein optionaler Grund („beim Transport verdorben“, „Zykluszählung“) und der Kanal: von Hand, nach einem Scan, aus einer eingegangenen Bestellung, aus einer Baugruppen-Herstellung oder durch einen KI-Assistenten.

Die meisten Systeme erfassen bei Bestandsbewegungen die ersten fünf. Beim sechsten scheitern Protokolle still und leise: Ein −12 ohne Grund sieht gleich aus, ob es ein Verkauf, ein Missgeschick oder ein Diebstahl war, und genau diesen Unterschied hätten Sie wissen müssen.

Was den meisten Protokollen zuerst fehlt: Bearbeitungen

Protokolle verfolgen meist Mengen und ignorieren alles andere an einem Artikel. Doch einige der teuersten Fehler sind Bearbeitungen, keine Bewegungen:

  • Eine Schwelle wurde verschoben. Jemand senkt eine Warnschwelle von 18 auf 2, um eine lästige Warnung loszuwerden. Drei Wochen später ist der Artikel aus, und niemand wurde gewarnt. Ohne Bearbeitungsprotokoll hat die Warnung „einfach aufgehört zu funktionieren“.
  • Eine Einheit wurde umbenannt. Aus „Dose“ wird „Karton“, und jede Zählung seitdem bedeutet etwas Zwölfmal Größeres. Herauszufinden, wann das passiert ist, ist der Unterschied zwischen einer Korrektur in fünf Minuten und einer Neuzählung.
  • Ein Preis hat sich geändert. Ihr Lagerwert springt über Nacht. War das echt, oder hat jemand beim Stückpreis eine Null zu viel eingetippt?
  • Ein Lieferant wurde ausgetauscht. Nachbestellungen gehen plötzlich an den falschen Anbieter, und niemand erinnert sich, das geändert zu haben.

Eine Bearbeitungszeile braucht dasselbe Wer und Wann wie eine Bewegung, dazu den Wert vorher und nachher. „Warnschwelle: 18 → 2, von Sam, Dienstag 8:57 Uhr“ löst das Rätsel in einer Zeile.

Das Zweite: Löschungen

Einen Artikel zu löschen ist das Zerstörerischste, was man in einem Bestandssystem tun kann, und in vielen Werkzeugen auch das Stillste. Der Artikel verschwindet, und oft verschwindet sein Verlauf mit ihm. Das ist verkehrt herum. Der Moment, in dem ein Artikel gelöscht wird, ist genau der Moment, in dem Sie am dringendsten wissen wollen, wer es war, was er zu diesem Zeitpunkt enthielt und was vorher mit ihm passiert ist.

Ein gutes Protokoll behandelt eine Löschung als ein weiteres Ereignis: eine Zeile, die die Person und den Artikel nennt, während die Vergangenheit des Artikels erhalten bleibt. Noch besser ist es, wenn sich die Löschung rückgängig machen lässt, denn „hoppla“ ist der häufigste Grund, aus dem Dinge gelöscht werden.

Regeln, die ein Protokoll vertrauenswürdig halten

Zeilen werden nie bearbeitet, nur hinzugefügt

Wenn sich eine Protokollzeile bearbeiten lässt, beweist das Protokoll nichts. Fehler passieren, also ist die Korrektur eine neue Zeile, die die alte berichtigt. Die Spur zeigt dann sowohl den Fehler als auch die Korrektur, und genau das möchten ein Prüfer, eine Führungskraft oder Ihr zukünftiges Ich sehen.

Das System schreibt die Zeile, nicht die Person

Wer und wann sollten aus der Anmeldung und der Uhr kommen, nicht aus einem Feld, das jemand ausfüllt. Selbst gemeldete Protokolle driften zu dem hin, was bequem zu melden ist.

Jeder Weg schreibt in dasselbe Protokoll

Bestand bewegt sich durch manuelle Änderungen, Scans, eingegangene Bestellungen, Herstellungen und zunehmend durch KI-Assistenten. Wenn einer dieser Wege das Protokoll überspringt, hat das Protokoll einen blinden Fleck genau dort, wo irgendwann jemand nachsehen wird.

Regeln, die ein Protokoll lesbar halten

Ein Protokoll, das man nicht lesen kann, liest niemand. Zwei Gewohnheiten helfen sehr:

  • Rauschen zusammenfassen, niemals Bedeutung. Tippt eine Person innerhalb einer Minute fünfmal auf +1, erzählt eine Zeile mit +5 dieselbe Geschichte mit weniger Scrollen. Eine Änderung mit Grund oder eine Bearbeitung verdient aber jedes Mal eine eigene Zeile.
  • Zusammengesetzte Aktionen in Worten beschreiben. „Verwendet für die Herstellung von 2 × Sauerteigbrot“ auf einer Mehlzeile erklärt eine Entnahme, die sonst wie Schwund aussähe.

Und das Protokoll muss das System verlassen können, wenn Sie es brauchen: als Export mit Zeitraum für die Steuerberatung oder als filterbare Liste, wenn Sie in einem geschäftigen Monat nach einer einzigen Änderung suchen.

Ein kurzer Check Ihres aktuellen Systems

Nehmen Sie einen Artikel, der eine geschäftige Woche hatte, und versuchen Sie, diese Fragen allein aus Ihren Aufzeichnungen zu beantworten:

  • Wer hat die letzten drei Änderungen an seiner Menge vorgenommen, und warum?
  • Wie lauteten seine Warnschwelle und sein Stückpreis vor einem Monat?
  • Wenn ihn heute Morgen jemand gelöscht hätte, könnten Sie sagen, wer, und ihn zurückholen?
  • Welche seiner Änderungen hat ein KI-Assistent oder eine Integration vorgenommen statt einer Person?

Lautet eine Antwort „da müssten wir herumfragen“, ist das die Lücke. Tabellen sind ein häufiger Übeltäter: Der Versionsverlauf erfasst Zellbearbeitungen, aber nicht, wer welchen Artikel aus welchem Grund bewegt hat, und er geht bei einer Kopie oder einem Export leicht verloren. Mehr zu diesem Zielkonflikt lesen Sie in Anzeichen, dass Sie Tabellen entwachsen sind.

In Simple Inventory führt jeder Artikel diese Art von Protokoll automatisch: Bestandsbewegungen mit Mengen, Einheiten und optionalen Gründen, Bearbeitungen mit Werten vorher und nachher, Löschungen mit der Person, die sie vorgenommen hat (und einer Schaltfläche „Wiederherstellen“), und KI-Änderungen als KI gekennzeichnet. Zeilen lassen sich nicht bearbeiten, und der gesamte Verlauf lässt sich als CSV exportieren. Wie jede Zeile aussieht, zeigt die Audit-Trail-Funktion.


Für begrenzte Zeit kostenlos starten