Eine Schritt-für-Schritt-Anleitung zum Aufbau eines Simulationsmodells zur Analyse von Wachstumsszenarien in solchen Unternehmen
Ein Simulationsmodell zur Analyse von Wachstumsszenarien in Dienstleistungsunternehmen
Ich baue Simulationsmodelle gerne in kleinen Schritten auf und teste dabei Zwischenschritte. Das erleichtert es, Fehler zu finden (die unweigerlich passieren), während ich noch am Modell arbeite.
Damit Sie das leichter nachvollziehen können, habe ich für jeden Schritt ein eigenes Modell erstellt, Sie finden sie in unserem
GitHub-Repository.
Um Ihnen das Nachvollziehen zu erleichtern, habe ich die Liste der Annahmen, die dem Spiel zugrunde liegen, durchnummeriert:
Projektvolumen. Das durchschnittliche Projektvolumen beträgt 16 Personenmonate.
Projektdauer. Die durchschnittliche Projektdauer beträgt 2 Monate, d.h. 8 Projektdurchführungsmitarbeiter sind 2 Monate lang beteiligt.
Aufwand für die Suche. Der Aufwand für die Suche nach einem Lead und das Schreiben eines Vorschlags beträgt 4 Monate.
Projektakquisitionsdauer. Die Projektakquisitionsdauer beträgt 6 Monate, d.h. zwischen der Generierung des ersten Lead und dem Beginn eines neu akquirierten Projekts vergehen 6 Monate.
Marktbedingungen. Die Marktbedingungen sind perfekt, d.h. sowohl die Prospektions-auch die Akquisitionserfolgsquote liegen bei 100%.
Projektabwicklungsgebühr. Die Projektabwicklungsgebühr beträgt 17.600 EUR pro Personenmonat, d.h. der Tagessatz pro Berater beträgt 880 EUR.
Abrechnungsintervall. Die Projekte werden monatlich in Rechnung gestellt.
Inkassodauer. Die Inkassodauer beträgt 2 Monate, d.h. es dauert 2 Monate, bis die Einnahmen gesammelt sind und bei der Bank eintreffen.
Arbeitsplatzkosten. Die Arbeitsplatzkosten pro Mitarbeiter betragen 1000 EUR pro Monat (Miete, Laptop, Softwarelizenzen und Dienstleistungen...).
Gemeinkosten. Das Unternehmen hat Gemeinkosten von 306.000 EUR pro Monat (Managementkosten...).
Personal Gehalt. Das durchschnittliche Gehalt pro Mitarbeiter beträgt 100.000 EUR pro Jahr.
Einstellungsdauer. Die Einstellungsdauer für neue Mitarbeiter beträgt 3 Monate.
Anfängliches Bargeld. Das anfängliche Bargeld liegt bei 1.000.000 EUR.
Anfangliches Personal. Das Unternehmen hat anfangs 200 professionelle Mitarbeiter, von denen 20% für die Geschäftsentwicklung eingesetzt werden. Bei dieser Einstellung ist das Unternehmen stabil.
Anfäglicher Rückstand. Der anfängliche Rückstand an Projektwochen beläuft sich auf 320 Personenmonate, und die anfängliche Zahl der in der Verkaufspipeline befindlichen potenziellen Projekte/Vorschläge beträgt ebenfalls 320 Personenmonate.
Und hier ist das Spiel selbst, falls Sie noch keine Gelegenheit hatten, es zu spielen - das Ziel ist es, die Geldziele zu erreichen, indem Sie die richtige Anzahl von Mitarbeitern einstellen und entscheiden, wie viele von ihnen der Geschäftsentwicklung zugewiesen werden sollen:
Wie war Ihr Spielverlauf?
Haben Sie es geschafft, das Rätsel zu lösen?
Durch Versuch und Irrtum oder hatten Sie eine klare Strategie?
Lassen Sie uns ein Modell erstellen, das alle Annahmen des Spiels erfasst, mit dem wir dann das Spiel systematisch analysieren können.
Es ist am einfachsten, mit Bargeld und Cashflow zu beginnen, weil dies klar definierte Konzepte sind, die wenig zur Diskussion offen lassen. Außerdem sind sie in System Dynamics einfach zu modellieren.
Per Definition ist der Cashflow einfach die Differenz zwischen dem Geld, das in das Unternehmen fließt (z. B. wenn Kunden die Rechnungen bezahlen und wir die Einnahmen kassieren) und dem, das das Unternehmen verlässt (z. B. für Löhne und Arbeitsplatzkosten).
Das unten gezeigte Bestands- und Flussdiagramm fängt dies gut ein.
Lassen Sie uns nun das Modell quantifizieren. Unter Annahme Nr. 14 wissen wir, dass 160 professionelle Mitarbeiter für die Projektabwicklung eingesetzt werden und unter Annahme Nr. 6 wissen wir, dass jeder von ihnen 17.6 Tsd. EUR pro Monat umsetzt. Annahme Nr. 7 besagt, dass wir die Projektarbeit monatlich abrechnen.
Die Kosten sind das monatliche Gehalt (80Tsd./12) plus 1 Tsd. EUR Arbeitsplatzkosten und die Gemeinkosten von 306 Tsd. EUR (Annahmen Nr. 9, Nr. 10, Nr. 11). Dank der Annahme Nr.13 wissen wir auch, dass der anfängliche Bargeldbestand bei 1000 Tsd. EUR liegt.
So können wir die folgenden Werte definieren:
Beachten Sie, dass ich die Ein- und Auszahlungsflüsse deutlich von den Konvertern für Kosten und Sammelumsatz getrennt habe, anstatt die Zahlen direkt in den Strom zu addieren (z. B. durch Setzen von Einzahlungen=EinnahmenEinziehen statt Einzahlungen=EinnahmenEinziehen=160*17,600).
Der Grund dafür ist, dass ich meine Simulationslogik so weit wie möglich aus den Abläufen heraushalten möchte - das macht das Modell visuell eindeutiger und erleichtert auch das Refactoring des Modells (z. B. das Verschieben von Logik zwischen Diagrammen).
Wir sollten überprüfen, ob das Modell wie erwartet funktioniert: Der Cashflow sollte konstant sein und gleich Cashflow=160*17,6-200*(80/12+1)-306=976,67. Das bedeutet auch, dass wir nach 24 Monaten bargeld=1000+24*922,67=24440,08 haben sollten.
Ich habe die Werte unten aufgezeichnet und tabellarisch dargestellt, wie Sie sehen können, sind die Zahlen wie erwartet.
Eine weitere gute Praxis bei der Modellerstellung ist es, die Konstanten explizit zu modellieren: Es sollte keine "magischen" Werte geben, die nicht explizit benannt sind, da diese für jeden, der das Modell liest, schwer zu interpretieren sind (einschließlich Sie, wenn Sie später auf dieses Modell zurückkommen).
Also statt der Einstellung
sollten wir für jede Zahl explizit einen Bestand oder Konverter definieren. Das macht das Modell viel lesbarer, macht jede Gleichung einfacher zu lesen, zu verstehen und zu korrigieren.
Dies führt zu dem neuen Diagramm unten.
Ich habe das professionelle Servicepersonal aus zwei Gründen als Bestand (und nicht als Konverter) modelliert:
Wir wissen, dass sich die Anzahl des Personals im Laufe der Zeit ändern wird.
Wir können die Anzahl des Personals, die die Firma in einem bestimmten Monat hat, nicht sofort aus anderen Elementen im Modell berechnen - die einzige Möglichkeit, wie wir wissen können, wie viel Personal die Firma hat, ist die ursprüngliche Anzahl (in diesem Fall 200) zu kennen und dann die Anzahl des Personals zu addieren, die seitdem hinzugekommen sind (wir werden den Einstellungsprozess in Schritt 7 modellieren).
In System Dynamics werden Variablen, die sich so verhalten, mithilfe von Beständen modelliert.
Weil wir das Modell nur reorganisiert haben, ohne eine neue Logik hinzuzufügen, erwarten wir, dass sich nichts geändert hat. Trotzdem sollten wir prüfen, ob dies richtig ist.
Nachdem wir nun die Kostenseite modelliert haben, sollten wir einen Blick auf die Einnahmen Seite werfen. In jedem Unternehmen ist es wichtig, zwischen der Einnahmengeneration und deren tatsächlicher Sammlung zu unterscheiden, da das Unternehmen den Zeitraum dazwischen aus eigenen Geldmitteln finanzieren muss.
In unserem Fall ist das besonders wichtig, weil wir uns in einem Wachstumsszenario befinden und die Löhne des neuen Personals bezahlt werden müssen, bevor die Einnahmen, der sie machen, tatsächlich auf dem Bankkonto der PSF ankommt.
Gemäß der Spielannahme Nr. 8 gibt es eine durchschnittliche Inkassodauer von 2 Monaten. Daher können wir den Inkassoprozess als eine Forderung modellieren - der Zufluss wird durch die monatliche Einnahmen bestimmen, der Abfluss ist einfach der um die Inkassodauer verzögerte Zufluss.
Der Umsatz ist einfach die monatliche Projektabwicklungsgebühr mal die Abwicklungsrate. Unter Berücksichtigung unserer Annahmen über den Personaleinsatz (Nr. 8) liegt die Abwicklungsrate zunächst bei 160 Projektmonaten/Monat.
Beachten Sie, dass wir eine VERZÖGERUNG-Funktion verwenden, um EinnahmenEinziehen zu definieren - die VERZÖGERUNG-Funktion stellt sicher, dass EinnahmenEinziehen immer gleich dem Wert ist, den EinnahmenMachen 2 Monate zuvor hatte. VERZÖGERUNG-Funktionen sind sehr wichtig bei der Modellierung dynamischer Systeme, daher habe ich unten ein eigenes Kapitel hinzugefügt, um diese Funktion im Detail zu untersuchen.
Mit diesem Modell und diesen konkreten Werten erwarten wir, dass die Forderungen konstant bei Inkassozeit*Einnahmen liegen, was 2*17,6*160=5632 ist, und wir erwarten, dass sowohl EinnahmenMachen als auch EinnahmenEinziehen konstant und gleich den Einnahmen sind, was 17,6*160=2816 ist.
Die folgende Tabelle zeigt, dass sich das Modell korrekt verhält.
Da alles konstant ist, ist es leider schwierig zu sehen, ob unser Modell der Forderungen richtig funktioniert. Wir sollten also unser Modell mit einigen schwankenden Einnahmen testen, um zu sehen, ob die Einnahmenerhebung richtig verzögert - beachten Sie, dass dies ein reiner Test ist, die Werte, die wir für die Einnahmenerhebung verwendet haben, haben nichts mit den Spielannahmen zu tun.
Das Diagramm unten zeigt, dass sich unser Modell gut verhält. Die Form von EinnahmenEinziehen ist identisch mit der von EinnahmenMachen, nur dass das gesamte Diagramm um zwei Monate (d. h. um die Inkassozeit) verschoben ist.
Um dies besser zu veranschaulichen, hier ein weiteres Szenario, bei dem die Inkassozeit auf 1 Monat anstelle von zwei Monaten eingestellt ist, aber die gleichen monatlichen Einnahmen eingezogen werden.
Und wieder für eine Inkassozeit von 5 Monaten.
Und genau das passiert mit den Forderungen in diesen beiden Szenarien.
Bevor wir zu Schritt vier übergehen, sollten wir uns die Verzögerungsfunktion genauer ansehen - sie wird in System Dynamics sehr häufig verwendet und es ist wichtig, dass wir sie richtig verstehen.
Bei der Modellierung eines Geschäfts treten häufig Situationen auf, in denen wir Verzögerungen modellieren müssen. Eine Möglichkeit, dies zu tun, ist die Verwendung der VERZÖGERUNG-Funktion.
Die Verzögerungsfunktion VERZÖGERUNG(f,p,i) verzögert f einfach um p Perioden, wenn der aktuelle Zeitschritt t größer als p ist, sonst gibt sie den Anfangswert i aus:
VERZÖGERUNG(f,p,i)(t) = f(t-p) wenn t>=p
= i wenn t<p
Um zu veranschaulichen, wie die Verzögerungsfunktion funktioniert, habe ich unten ein kleines Beispiel eingefügt, das die Auswirkung der Verzögerungsfunktion auf einen einfachen Bestand zeigt, bei der der Zufluss eine beliebige Funktion ist und der Abfluss einfach der um die Verzögerungszeit verzögerte Zufluss ist.
Die folgende Grafik zeigt, was passiert, wenn der Abfluss gleich dem um 6 Zeitschritte verzögerten Zufluss ist - der Graph des Zuflusses wird einfach um 6 Zeitschritte nach rechts verschoben.
Beachten Sie, dass wir hier den Anfangswert gleich 0 gesetzt haben - wir brauchen den Anfangswert, weil die Verzögerungsfunktion "in der Zeit zurückblickt" (in diesem Fall um sechs Zeitschritte) und der Zufluss undefinierte Werte für negative Zeitschritte hat (weil die Simulation erst bei Zeitschritt 0 beginnt).
Die folgenden Diagramme zeigen, was mit dem Abfluss bei verschiedenen Verzögerungszeiten passiert.
In den folgenden Diagrammen halten wir die Verzögerungszeit konstant, spielen aber mit verschiedenen Anfangswerten.
In Schritt 3 haben wir die Einnahmen als das Produkt aus der Projektabwicklungsgebühr und der Projektabwicklungsrate definiert, beide waren in diesem Modell konstant. Bei der Spielannahme Nr. 6 wissen wir, dass die Abwicklungsgebühr konstant ist, aber natürlich hängt die Projektbereitstellungsrate davon ab, wie viele Projekte die PSF akquiriert hat und auch davon, wie viel Personal die PSF der Projektabwicklung zuweisen kann - wenn keine (neuen) Projekte akquiriert werden, dann wird die Abwicklungsrate (letztendlich) 0 sein, unabhängig davon, wie viel Personal die PSF den Projekten zuweist.
Wenn andererseits kein Personal für die Projektabwicklung eingesetzt wird, dann ist die Abwicklungsrate 0, unabhängig von der Anzahl der akquirierten Projekte.
In diesem Schritt modellieren wir die Projekte als einen Bestand mit einem Anfangswert von 320 Personenmonaten (zwei Monate Projektrückstand, Annahme Nr. 15). Der Abfluss ist gleich der Projektlieferquote, die ihrerseits gleich dem Minimum an Projekten und der Projektabwicklungskapazität ist. Für den Moment nehmen wir an, dass diese Kapazität konstant bei 160 Personenmonaten liegt (d.h. 160 Projektmitarbeiter liefern einen Monat Projektarbeit pro Monat).
Das Diagramm unten zeigt, wie der Projektrückstand in den ersten zwei Monaten stetig abnimmt und dann bei 0 bleibt - der Grund, warum er bei 0 abschneidet, ist, dass wir die MIN-Funktion verwendet haben, um den Abfluss Projektabwicklungsrate einzuschränken.
Zu Beginn beträgt die Abwicklungskapazität genau die Hälfte des Projektrückstands, sodass der Rückstand nach zwei Monaten auf Null fällt. Wir können uns diesen Mechanismus genauer ansehen, wenn wir verschiedene Werte für die Abwicklungskapazität verwenden - die Grafiken unten zeigen, dass, sobald der Projektrückstand unter die Projektabwicklungskapazität fällt, die Abwicklungsrate gezwungen ist, gleich dem Projektrückstand zu sein, bevor sie auf Null fällt.
Das sieht man noch besser, wenn man sich die konkreten Zahlen anschaut:
In unserem Modell in Schritt 4 haben wir angenommen, dass die Projektabwicklungskapazität konstant und gleich 160 ist - während dieser Wert zu Beginn der Simulation sicherlich richtig ist, wird er während des gesamten Spiels nicht konstant sein, da die Projektabwicklungskapazität von der Anzahl des professionellen Personals abhängt, die wir haben, und von dem Prozentsatz des Personals, das der Projektabwicklung zugewiesen ist (oder der Geschäftsentwicklung, je nachdem, wie man es betrachtet).
Das Diagramm unten zeigt, wie wir dies modellieren können - angesichts der Anzahl des Fachpersonals und der durchschnittlichen Arbeitsmenge, die pro Mitarbeiter pro Monat (dem "Arbeitsmonat") geleistet wird, können wir die Arbeitskapazität einfach als Produkt dieser beiden Zahlen berechnen. Die Geschäftsentwicklungskapazität ist dann gleich der Arbeitskapazität multipliziert mit dem Prozentsatz der Mitarbeiter, die der Geschäftsentwicklung zugewiesen sind, und die Projektabwicklungskapazität ist dann einfach die Differenz zwischen der Arbeitskapazität und der Geschäftsentwicklungskapazität (weil die Annahme ist, dass das Fachpersonal entweder in der Projektbereitstellung oder in der Geschäftsentwicklung arbeiten).
Die folgenden Gleichungen spezifizieren dies im Detail:
Wir können das Modell testen, indem wir die Projektabwicklungskapazität, die Projektabwicklungsrate und den Projektrückstand für verschiedene Geschäftsentwicklungszuordnungen vergleichen:
Langsam kommen wir dahin, unser Modell ist jetzt fast vollständig. Wir haben alle Bestände vorhanden, aber zwei davon - Projekte und Personal - haben noch keine Zuflüsse. Werfen wir zunächst einen Blick auf die Projektakquisitionsprozess.
Wenn wir einen Blick auf Nr. 3 unserer Annahmen werfen, wissen wir, dass es 4 Aufwand Monate dauert, einen Lead zu generieren und einen Vorschlag zu schreiben.
Wir wissen auch, dass ein Projekt, das wir erwerben, ein Volumen von 16 Personenmonaten haben wird (Annahme Nr. 1).
In Schritt 5 haben wir einen Konverter eingeführt, der unsere Geschäftsentwicklungskapazität verfolgt, sodass wir die Rate, mit der wir Vorschläge generieren, als berechnen können:
Aus Annahme Nr. 4 wissen wir, dass es sechs Monate dauert, um einen Vorschlag in ein Projekt zu verwandeln - wir modellieren dies mit einer Verzögerungsfunktion:
Beachten Sie, dass alle Vorschläge als Projekte enden, es gibt keinen Verlust - dies liegt daran, dass wir davon ausgehen, dass die Marktbedingungen perfekt sind (Annahme Nr.5).
Wie können wir diesen Teil des Modells testen?
Nun, im stabilen Zustand erwarten wir, dass die Anzahl der Vorschläge in der Pipeline gleich der Anzahl der Projekte im Projektrückstand ist. Die folgenden Diagramme zeigen, dass dies so ist:
Schauen wir uns nun an, was passiert, wenn wir den Prozentsatz des Personals, das für die Geschäftsentwicklung zuständig ist, nach 3 Monaten auf 40% erhöhen - wir erwarten, dass die Anzahl der Vorschläge steigt, sobald wir das tun. Da wir unser Personal für die Geschäftsentwicklung nur erhöhen können, indem wir Personal für die Projektabwicklung abbauen, würden wir erwarten, dass der Projektrückstand sofort steigt. Wir sollten jetzt mehr Vorschläge generieren, aber aufgrund der Akquisitionsdauer würden wir erwarten, dass sich dies erst in 6 Monaten auf den Projektrückstand auswirkt - daher sollte es ab Monat 9 zu einem steileren Anstieg des Projektrückstands kommen.
Unten habe ich sowohl die Graphen als auch die konkreten Werte der Vorschläge und des Projektrückstands in diesem Szenario angegeben - wie erwartet beginnt die Anzahl der Vorschläge zu steigen, sobald wir das Personal in die Geschäftsentwicklung umschichten. Der Projektrückstand beginnt sofort zu steigen, weil wir das Personal von der Projektabwicklung zur Geschäftsentwicklung umgeschichtet haben - im Monat 10 (d.h. 6 Monate nach der Umschichtung) werden die ersten Projekte akquiriert und damit beginnt der Projektrückstand noch schneller zu steigen - natürlich sollten wir bis zu diesem Zeitpunkt einige zusätzliche Projektmitarbeiter eingestellt haben, um dies zu kompensieren, wir können dies im nächsten Schritt testen.
Aber warum erreicht die Anzahl der Vorschläge mit 1280 Vorschlägen ihren Höhepunkt?
Ich musste selbst einen kleinen Moment darüber nachdenken: Im Monat 4 setzen wir 40% unseres Personals für die Geschäftsentwicklung ein. Sie fangen sofort an, Vorschläge mit einer Rate von 0,4*200*16/4=320 Projektmonaten pro Monat zu generieren.
Jeden Monat verlassen 160 Projektmonate den Vorschlagsrückstand und gelangen in den Projektrückstand. Die Verzögerung beträgt 6 Monate, sodass wir im Monat 10 erwarten, 160*6=960 zusätzliche Projektmonate in der Pipeline zu haben. Wenn wir diese zu den 320 Projektmonaten addieren, die sich bereits im Vorschlagsbestand befanden, kommen wir auf 960+320=1280. Im Monat 10 steigt die Anzahl der Projektmonate, die den Vorschlagsbestand verlassen, auf 320 an, was der Anzahl der eingehenden entspricht. Zu diesem Zeitpunkt liegt der Bestand an Vorschlägen also konstant bei 1280.
Das folgende Diagramm zeigt, dass sich die Projektvorschlagsrate wie erwartet von 160 auf 320 ändert.
Der einzige Aspekt unseres Modells, der jetzt noch fehlt, ist die Personalrekrutierung - die Rekrutierung ist anfangs gleich Null, aber die richtige Einstellung ist Teil der richtigen Spielstrategie.
Wir modellieren die Rekrutierung als eine einfache Bestands- und Flussstruktur, die eine von der Einstellungsdauer abhängige Verzögerung beinhaltet - das Bestands- und Flussdiagramm und die entsprechenden Gleichungen sind unten dargestellt - wir wissen, dass die Einstellungsdauer dank der Annahme Nr. 12 3 Monate beträgt.
Wir können nun das Szenario fortsetzen, das wir in Schritt 6 untersucht haben: In Zeitschritt 4 haben wir die Geschäftsentwicklungszuweisung auf 40% geändert, was zu einem Anstieg des Projektrückstands führte. Wir sahen auch, dass sich der Rückstand an Vorschlägen nach 10 Monaten einpendelt, mit einem Abfluss von 320 Projektmonaten pro Monat. Um so viele Projekte zu bearbeiten, brauchen wir 320 Mitarbeiter für die Projektabwicklung, daneben 80 Mitarbeiter für die Geschäftsentwicklung.
Da das Einstellen tatsächlich drei Monate dauert, müssen wir sie in Zeitschritt 7 einstellen.
Sobald sie ankommen, werden wir das Verhältnis der Geschäftsentwicklung ändern müssen, weil wir jetzt 80 Geschäftsentwickler und insgesamt 400 Mitarbeiter haben werden, also wird der Prozentsatz wieder bei 20% liegen.
Alles in allem führt dies zu einem 100%igem Wachstumsszenario. Lassen Sie uns prüfen, wie sich unser Modell verhält.
Wunderbar, wir haben jetzt ein vollständiges Modell. Wir sollten nun einige Vernunftprüfungen durchführen, um zu sehen, ob es korrekt funktioniert. Bevor wir das tun, sollten wir sicherstellen, dass wir alle Annahmen in die Liste aufgenommen haben. Bei der Erstellung von Modellen führen wir meist eine Excel Tabelle, in der alle Anforderungen und Annahmen bezüglich des Modells sowie alle Probleme, die auf dem Weg dorthin auftreten, festgehalten werden. Auf diese Weise können wir sicherstellen, dass wir nichts vergessen.
Die folgende Tabelle zeigt, welche Annahme in welchem Modellschritt behandelt wird.
Bevor wir anfangen, mit Wachstumsstrategien zu experimentieren, sollten wir sicherstellen, dass sich das Modell wie erwartet verhält.
Lassen Sie uns ein paar schnelle Berechnungen anstellen, um sicherzustellen, dass wir die zugrundeliegenden Annahmen verstehen ... das Unternehmen hat 200 professionelle Mitarbeiter, von denen 20% für die Geschäftsentwicklung zuständig sind. Das bedeutet, dass 160 Personen ständig an Projekten arbeiten. Der anfängliche Projektrückstand hat absolut 320 Monate, d.h. der Rückstand bezogen auf die Anzahl des Projektpersonals liegt 2 Monate in der Zukunft.
Schauen wir uns zuerst die Einnahmenseite an. Zu Beginn ist die PSF voll ausgebucht und arbeitet mit einer Rate von 160 Personenmonaten pro Monat, sodass das Unternehmen 160*17600 = 2,816,000 EUR pro Monat an Einnahmen aus Projekten.
Die Kostenseite ist etwas komplizierter: Jeder Mitarbeiter kostet 100000/12 = 8333 EUR an Gehältern und zusätzlich 1000 EUR Arbeitsplatzkosten, also 9333 EUR. Bei 200 Personen im Unternehmen ergibt dies 414,615 EUR an Personalkosten. Wir haben außerdem Gemeinkosten in Höhe von 306,000 EUR pro Monat, sodass die Gesamtkosten 1,839,333 EUR betragen.
Nimmt man all diese Zahlen zusammen, ergibt sich ein Bargeldzufluss von 976,667 EUR pro Monat. Ich habe diese Zahlen in der folgenden Tabelle zusammengefasst:
Beachten Sie, dass es sich hierbei um monatliche Zahlen handelt - wenn diese Zahlen stabil bleiben, dann wird das Unternehmen nach 2 Jahren zu Beginn des Monats 24, über Barmittel in Höhe der anfänglichen 1 Mio. EUR plus 23*976,667 verfügen, was 23.463 Mio.EUR ergibt.