Endgültiges Hühnerfarm-Modell als Beispiel für System Dynamics

Im letzten Post habe ich ein einfaches Modell einer Hühnerfarm vorgestellt und in Aussicht gestellt, das Modell weiter auszubauen. Im Folgenden möchte ich auf drei Aspekte eingehen, die in System Dynamics zentral sind:

Gleichgewicht

Policies

Einheiten

Ein Modell im perfekten Gleichgewicht

In Verbessertes System Dynamics Modell einer Hühnerfarm haben wir einen nichtlinearen Verlauf des Hühnerbestandes erhalten. Das ist unschön, weil sich kein Unternehmen solche Schwankungen leisten kann. Wer eine Hühnerfarm betreibt stellt sich doch vor, die verkauften Hühner durch Nachzüchtungen einszueins zu ersetzen, so dass stets gleich viele Hühner vorhanden sind. Das wäre ein perfektes Gleichgewicht. Wir starten mit 1000 Hühnern, verkaufen jeden Vormittag eine Anzahl, die jedoch am Nachmittag durch den Nachwuchs wieder ersetzt werden, so dass sich am Abend eines jeden Tages immer schön 1000 Tiere im Stall befinden.

Wir versuchen daher, unsere Farm so zu betreiben, dass sie das perfekte Gleichgewicht beachtet. Dazu benötigen wir gewisse Richtlinien bezüglich Nachzüchtung und Nutzung. Solche Richtlinien, der Policies, zu finden, ist eine der Hauptfunktionen eines System Dynamic Modells. Natürlich brauchen wir auch Richtlinien für unknown knowns, d.h. für den Eintritt möglicher Risiken. Wir wissen, dass es gewisse Hühnerkrankheiten gibt und mit welchem Erfolg sie behandelt werden können. Solche Dinge können wir in unser Modell einbetten und damit "spielen", um zu sehen, wie sie sich auf unseren Betrieb auswirken würden.

Das Modell habe ich zunächst dahingehend verbessert, dass ich einen Zwischenbestand Kücken eingebaut habe. Darunter subsumiere ich sowohl die 21 Tage in Brut befindlichen Eier als auch die Kücken, die z.B. 100 Tage lang nicht verkauft werden können. Grundsätzlich gilt: Es genau so viel neue Hühner wie Eier, die ich 120 Tage zuvor in den Brutkasten gelegt habe. Was also in den Bestand Kücken hinein läuft, kommt 120 Tage später dort wieder als ausgewachsene Hühner heraus. Irgend etwas, das in der Brut- und Wachstumszeit schief gehen könnte, habe ich zunächst einmal ausser Acht gelassen. So etwas nennt man pipeline delay: Was vorne rein geht, kommt hinten mit einer gewissen Verzögerung wieder heraus.

Weiter habe ich gesagt, dass jeden Tag genau so viele Eier in den Brutkasten gelegt werden, wie ich vorher Hühner verkauft habe. Das ist eine Policy. Vielleicht hat der Betrieb mehrere Angestellte, die unbedingt sicherstellen müssen, dass die verkauften Hühner sofort dadurch ersetzt werden, dass ebenso viel Eier in den Brutkasten gelegt werden.

Um zum Modell zu gelangen, klicken Sie in das Bild oder folgen diesem Link.

Policies oder Richtlinien

Ein Problem bieten die ersten 120 Tage. In dieser Zeit ist es nicht ratsam, etwas aus dem Hühnerbestand zu entnehmen, denn das würde das Gleichgewicht beträchtlich stören. Ich schlage vor, dass diese Zeit durch ein Investment überbrückt werden muss. Im übrigen verkaufe ich einfach so viele Hühner, wie ich über dem Anfangsbestand habe, so dass ich immer gleich viele Hühner wie am ersten Tag habe. Wenn also nach 120 Tagen die erste Nachzucht zum Bestand der Hühner hinzukommt, verkaufe ich sofort diese Anzahl (vorausgesetzt, es ist ein Markt vorhanden).

Diese Policies ergeben für den Verkauf folgende Formel:

IfThenElse([Hühner]-[Anfangsbestand Hühner]>{0 Stk},
([Hühner]-[Anfangsbestand Hühner])/[Nutzungszeit],
Step(120, 1)0.1[Hühner]/[Nutzungszeit])

Das liest sich so: Wenn ich mehr Hühner habe als am Anfang, so verkaufe ich den Überschuss in einer gewissen Zeit, hier in einem Tag.
Wenn der Hühnerbestand unter den Anfangsbestand fällt, dann verkaufe ich jeden Tag einen Zehntel, ausgenommen in den ersten 120 Tagen, in denen ich unter keinen Umständen etwas verkaufe.
Dieser Zehntel ist völlig willkürlich und muss am Modell getestet werden. Normalerweise fällt der Hühnerbestand nie unter den Anfangsbestand, es sei denn durch Tod einzelner Hühner. Aber eigentlich hoffe ich, die Hühner zu verkaufen, bevor sie sterben.

Die zweite Policy ist für die Zurücklegung von Eiern zwecks Nachzüchtung. Wir haben gesagt, dass wir so viele Eier in den Brutkasten legen, wie wir Hühner verkauft haben. Da wir in den ersten 120 Tagen nichts verkaufen, müssen wir eine Richtlinie haben, wie viele Eier wir in dieser Zeit ausbrüten.

Wenn wir es mit der Nachzüchtung etwas zu gut meinen, kann es passieren, dass die Anzahl Hühner und somit auch die Anzahl Eier stark anwachsen. Für diesen Fall müssen wir eine Policy haben, wie viele Eier ausgebrütet werden sollen. Wir können z.B. einen Prozentsatz der vorhandenen Eier nehmen.

Die Formel, die zur Anwendung kommt, lautet:

IfThenElse([Eier]>{1000 Stk},
0.015*[Eier]/[Taktperiode],
{100 Stk/Days}+Step(120, {-100 Stk/Days})+[Nutzung])

Wenn wir mehr als 1000 Eier haben - dem Anfangsbestand der Hühner - legen wir bloss 1.5 Prozent davon in den Brutkasten.
Wenn wir 1000 oder weniger Eier haben, dann brüten wir in den ersten 120 Tagen jeden Tag 100 Eier aus und danach stets genau so viele, wie wir vorher Hühner verkauft haben.

Dieses Modell führt dann zu folgendem Resultat:

Zufällige Schwankungen

Wir sehen, dass es sich im perfekten Gleichgewicht befindet. Aber das entspricht kaum der Realität, denn es gibt einige Zufälligkeiten:

Nicht jedes Huhn legt täglich genau ein Ei. Einige legen gar nichts, andere zuweilen zwei

Während des Brütens kann ein Ei zu Schaden kommen

Schwächliche Kücken überleben die Kückenzeit nicht

Die erste Zufälligkeit können wir dadurch simulieren, dass wir die Legemenge, also die Anzahl Eier, die ein Huhn pro Tag legt, als Zufallsvariable abbilden. Sie sei normalverteilt mit Mittelwert 1 und einer gewissen Standardverteilung.

Interessant, welche Auswirkung das auf den Hühnerbestand hat: er fällt auf ca. 700 Hühner ab.
Die anderen Zufälligkeiten können mit den eingebauten Abflüssen der Bestände "Kücken" und "Hühner" simuliert und studiert werden.

Betriebswirtschaftliche Faktoren

Die Hühnerfarm soll zumindest selbtstragend sein, auch hier wäre ein perfektes Gleichgewicht, in welchem der Gewinn stets verschwindet, ideal. Der Gewinn ist die Differenz zwischen dem Erlös und den Kosten. Der Erlös ergibt sich aus den verkaufen Eiern, z.B. zu 10 Centimes pro Ei und Tag, sowie aus den verkauften Hühnern, z.B. zu 2 Euro pro Huhn und Tag. Die Kosten werden in der Betriebswirtschaft meist als Polynom dritten Grades modelliert, abhängig von den Produktionseinheiten. Ich habe hier eine Kostenfunktion in Abhängigkeit der Anzahl Hühner gemäss meinem Artikel
Konstruktion ertragsgesetzlicher Kostenfunktionen eingesetzt.

Mit dieser Kostenfunktion wird der Betrieb erst nach ca. anderthalb Jahren Gewinnbringend. Danach steigt aber der Gewinn stetig an. Er kann zunächst zur Schuldentilgung verwendet werden.

Im Moment ist betriebswirtschaftliche Teil des Modells völlig terminal, d.h. er keinen Feedback auf das übrige Modell. Das ist nicht im Sinne der System Dynamics, die immer in Kreisen denkt. Der Gewinn muss in einer nächsten Version z.B. auf die Nutzung Einfluss nehmen, indem sie z.B. solange runtergefahren wird, bis sich der Gewinn auf einem gewissen niederen Niveau einpendelt. Oder der Gewinn könnte in einen Risikotopf abfliessen, der zur Überbrückung grösserer Ausfälle dienen kann.

Einheiten

Ein wichtiger Aspekt systemdynamischer Modelle sind die Einheiten. Jede Grösse hat Einheiten. Flüsse haben stets eine Einheit pro Zeit, z.B. Liter pro Sekunde. In unserem Fall haben wir es mit Hühnern, Kücken und Eiern zu tun. Damit wir nicht bei jedem Fluss umrechnen müssen, was je nach Implementierung mehr oder weniger mühsam ist, habe ich mir erlaubt, in Stück zu rechnen. Damit haben die Eier, die Kücken und die Hühner dieselbe Einheit, Stück (Stk). Die Flüsse dazwischen haben dann die Einheit Stk/Days, denn unser Modell basiert auf Tagen (das kann man im insightmaker unter Settings einstellen). Sind die Einheiten falsch gesetzt, reklamiert der insightmaker bei der Simulation. Nebst der Programmierung der Richtlinien, bzw. Policies, muss man also immer auch die Einheiten im Auge behalten und gegebenenfalls debuggen. Daher sind die meisten Modelle, auf die Sie im insightmaker frei zugreifen können, dimensionless konstruiert. Das gilt zwar als "Todsünde", setzt sich aber halt wegen des Mehrausfwandes durch.

Warum sind Einheiten so wichtig? Weil sie ein erstes und wichtiges Indiz zur Richtigkeit des Modells geben. Auch ausserhalb der System Dynamics wäre es ratsam, stets die Einheiten mitzunehmen. Z.B. sieht man an der Einheit der Geschwindigkeit - Kilometer per Stunde - wie sie berechnet wird: nämlich eine Strecke in Kilometern geteilt durch eine Zeit in Stunden.

Ich habe das gesamte Modell mit Einheiten hinterlegt. Um eine Konversion bin ich spätestens bei der Berechnung des Erlöses nicht herum gekommen. Aus Stück werden Euros. Insightmaker stellt aber noch eine weitere Methode zur Verfügung. Er kann z.B. Zentimeter und Meter zusammen addieren, weil er "weiss", dass ein Meter 100 Zentimeter sind. So könnte man insightmaker auch sagen, dass ein Huhn einfach aequivalent zu 2 Euros sind (falls der Hühnerpreis 2 Euros beträgt). Damit wäre insightmaker fähig, Hühner und Euros zusammen zu addieren, weil er glaubt, dass Hühner einfach eine andere Bezeichnung für ein Zweieurostück ist. Ich ziehe jedoch die direkte Umrechungsmethode vor, bei der ich die Anzahl Stück mit dem Preis "Euro/Stück multipliziere. Die Stück kürzen sich und es bleiben Euros übrig.

Nochmals: CLD

Erinnern Sie sich? Im Artikel Wie kann man aus Wirkungsnetzwerken simulationsfähige Stock-Flow-Modelle bauen? bin ich von dem Causal Loop Diagram (CLD)

gestartet und habe daraus in mehreren Schritten dieses Stock-Flow-Modell entwickelt, das Sie, wie gewohnt, selber simulieren. Sie können das Modell auch kopieren und dann auf Ihrer Kopie herum experimentieren. Versuchen Sie es! Sie landen dort, wenn Sie diesen Link Huehnerfarm anklicken. Wenn Sie nicht schon früher einen gratis insightmaker account angelegt haben, ist es jetzt an der Zeit.

Das CLD enthält keine Flüsse und keine weiteren Variablen, als bloss die beiden Bestände "Hühner" und "Eier", was einige Autoren veranlasste, CLD zu kritisieren (s.z.B. Drei Stolperfallen der qualitativen Modellierung ). Aber wir sehen in unserem Modell, dass tatsächlich gilt:

Je mehr Eier, desto mehr Hühner - Je weniger Eier desto weniger Hühner
Je mehr Hühner, desto mehr Eier - Je weniger Hühner desto weniger Eier