Betriebswirtschaftliche Berichtssysteme unterscheiden zwei Typen von Kennzahlen: Flussgrößen und Bestandsgrößen.

Flussgrößen sind zeitraumbezogene Größen im Berichtssystem. Sie erlauben eine Summierung über die Zeit. Umsätze, Absätze, Wareneingänge oder viele Produktionszahlen sind bekannte Beispiele für Flussgrößen.

Spricht man dagegen von Bestand, kommen meist klassische Bezüge wie Materialwirtschaft oder Bilanz ins Gespräch. Bestandsgrößen sind aber in vielen weiteren Bereichen eines Unternehmens anzutreffen. Denken wir an Mitarbeiterzahlen, Fuhrparks, Maschinenparks, Immobilien, (Waren-)Stellflächen oder auch an Kassenbestände.

Was kennzeichnet Bestandsgrößen?

Bestandsgrößen betrachten immer einen Zeitpunkt. Eine Summierung über die Zeit macht keinen Sinn. Aggregationen wie Mittelwert, Minimum oder Maximum lassen sich jedoch bilden und sind auch inhaltlich plausibel.

In der Logistik wird neben dem physischen Bestand häufig nach weiteren operativen Kriterien wie Meldebestand, Sollbestand oder Mindestbestand unterschieden. Diese Kriterien sind für analytische Betrachtungen oft von sekundärer Bedeutung.

Warum sind Bestandsgrößen eine Herausforderung?

Unsere OLAP-basierten BI-Systeme ziehen viele ihrer Vorteile aus der Aggregation von Zahlen über Hierarchien hinweg. Die Zeit als eine der wichtigsten Betrachtungen in diesen Systemen ist für Bestandsgrößen nicht relevant. Es machen ausschließlich “Zeitsprünge” Sinn (vgl. Blog “Vom Umgang mit der Zeit”).

Es gilt auch immer die Frage zu klären, wie der Perioden-Endbestand ausgewiesen werden soll, wenn die Periode noch nicht vollständig abgeschlossen ist.

Microsofts SQL-Server (ab 2005) bietet die Möglichkeiten “LastNonEmpty” oder “LastChild” an. Dabei wird “LastNonEmpty” eingesetzt, wenn auch vor dem “Abschluss” auf dem verdichteten Element der aktuelle Periodenbestand ausgewiesen werden soll. “LastChild” gibt als Periodenwert den Wert des letzten Kindelementes aus. Hier muss natürlich sicher gestellt werden, dass das letzte Kindelement in der Hierachie gefüllt ist.

Um Bestände korrekt auszuweisen, ist immer eine Zählung mittels Inventur erforderlich. Im betrieblichen Alltag ist eine Bestandsbetrachtung auf Tagesebene häufig nicht nur sinnvoll sondern auch erfoderlich. Dabei werden kleinere Ungenauigkeiten (Schwund, Diebstahl usw.) bewusst in Kauf genommen, da eine Inventur zeitaufwändig und teuer ist. Man geht dann auf gerechnete Bestände zurück.

Viele Warenwirtschaftssysteme sind in der Lage, taggenaue (gerechnete) Bestandsdaten zu liefern. Bestandsveränderungen können sie aber meist nur unvollständig bereitstellen. Eine detaillierte Abbildung der Bestandssituation auf Tagesebene ist eine technische Herausforderung für das OLAP-System. Ein Beispiel aus dem Textilhandel soll dies verdeutlichen: Ein Handelsunternehmen hat 10.000 Artikel in (durchschnittlich) 6 Größen und 7 Farben in 50 Filialen im Angebot. Es ergeben sich somit etwa 21 Mio. Bestandsdatensätze pro Tag. Hält man diese Bestandsdatensätze an etwa 300 Öffnungstagen im Jahr vor, so ergeben sich 6,3 Milliarden Datensätze pro Jahr für dieses fiktive Unternehmen.

Kommt jetzt noch die oft gewünschte und technisch durchaus machbare stundengenaue Darstellung hinzu, würde dies die genannten Volumina nochmals um den Faktor 24 steigern.

Wie können Bestände “optimiert” vorgehalten werden

Berechnung der Veränderung mit Hilfe zweier Tagesbestände

Hier kommen die bereits bekannten und oft auch schon modellierten Flussgrößen in Betracht. Die betriebliche Praxis zeigt, dass sich nicht alle Bestandswerte jeden Tag verändern, d.h. (in unserem Beispiel) wird nicht jeden Tag in jeder Filiale in jeder Größe und in jeder Farbe ein Stück verkauft oder zusätzlich ins Sortiment aufgenommen. Vielmehr zeigt die Praxis, dass es in diesem Unternehmen höchstens 300.000 bestandswirksame Veränderungen pro Tag gibt. Diese Erkenntnis kann das Datenvolumen für die Bestandsdarstellung auf etwa 1,5% sinken lassen.

Die Veränderungen lassen sich im einfachsten Fall aus dem Vortagesbestand berechnen:

Veränderung = Akt. Tagesbestand – Vortagesbestand

Die Bestandsveränderung ist eine Flussgröße und kann über die Zeit kumuliert werden. Sie hat zusätzlich den Charme, mehr Tiefgang in die Analyse zu bringen, als dies mit den Beständen allein möglich ist.

Im BI-System wird ein initialer Anfangsbestand für das (Geschäfts-)Jahr implementiert. Der aktuelle (Tages-)Bestand ergibt sich dann als Summe aus dem initialen Anfangsbestand und den kumulierten Veränderungen diesen Jahres. Der Aufwand in dieser Variante liegt natürlich in der Berechnung der Veränderung, die täglich durchgeführt werden muss.

Besonderes Augenmerk ist bei der Ermittlung auf Preisveränderungen zu legen, da diese in den monetären Bestandsveränderungen auch ausgewiesen werden müssen.

Integration anderer Datentöpfe

Die oben genannten Bestandsveränderungen können auch als Summe der Lagerzu- und -abgänge ermittelt werden. Lagerzugänge sind wiederum die Summe aus Wareneingängen (von aussen) und Umlagerungen aus anderen Filialen. Lagerabgänge ergeben sich als Summe des Verbrauchs (im Beispiel der Verkauf der Bekleidung), Umlagerungen an andere Filialen und der Retouren nach außen. Zusätzlich sind noch die Inventurdifferenzen (meist einmal pro Jahr) mit abzubilden:

Veränderung = Zugang – Abgang +/- Inventurdifferenzen

Zugang = Wareneingang + Zulauf aus Umlagerungen

Abgang = Verbrauch/Verkauf + Abgang aus Umlagerung + Retoure

Als Datentöpfe kommen im Beispiel die logistischen Systeme und das Kassensystem in Betracht.

Sind alle Datentöpfe synchron, ergeben sich nach beiden Methoden gleiche Ergebnisse. Ist dies nicht der Fall, muss eine Ausgleichsposition geschaffen werden.

Auch hier muss besonders auf Preisveränderungen geachtet werden, wenn sie in den wertmäßigen Größen sauber abgebildet werden sollen.

Fazit

Die Integration von Beständen in Informationssysteme ist immer eine Herausforderung. Gründliche Überlegungen im Vorfeld der Implementierung helfen, den Informationsgehalt zu vertiefen und gleichzeitig das Datenvolumen zu optimieren.