Lorenz Rossmann, Dr. Jan Christoph Munck
2.1 Status Quo analysieren
Während der Zielsetzungsphase eines Small-Data-Projekts werden die aktuelle Situation analysiert, die Ziele aus betriebswirtschaftlicher und auch aus technischer Sicht festgelegt sowie der Projektplan abgeleitet. Die Analyse der aktuellen Situation ist dabei die Grundlage für einen Business Case, in dem Kosten und Nutzen eines Small-Data-Projekts gegenübergestellt werden. Dabei werden sowohl die personellen und Daten-Ressourcen, die dem Projekt zur Verfügung stehen, als auch die Rahmenbedingungen und Annahmen betrachtet. Wichtige Elemente hierbei sind Struktur und Abläufe des zu automatisierenden Prozesses.
Zur Analyse des Status Quo in dem vorliegenden Beispielprojekt wurde das Format und der Prozess des Liquiditätsforecasting schematisch skizziert und erste Daten dazu gesichtet. In Tab. 1 ist beispielhaft der Auszug eines manuellen Liquiditätsforecasts einer Gesellschaft für einen Monat neben den eingetretenen Ist-Zahlen zu sehen.
| AUSGEWÄHLTER MONAT |
FORECAST (kEUR) |
IST-WERTE (kEUR) |
| ZAHLUNGSEINGÄNGE |
100 |
110 |
| Produkt |
50 |
55 |
| - Produkt A |
30 |
30 |
| - Produkt B |
20 |
25 |
| Dienstleistung |
30 |
35 |
| - Dienstleistung A |
20 |
23 |
| - Dienstleistung B |
10 |
12 |
| Ersatzteile |
15 |
15 |
| Sonstige Einnahmen |
3 |
3 |
| Zinserträge |
2 |
2 |
| ZAHLUNGSAUSGÄNGE |
80 |
85 |
| Kreditoren |
10 |
10 |
| Intercompany |
30 |
33 |
| Personal |
30 |
30 |
| Mieten |
5 |
5 |
| Anderes |
5 |
7 |
| SALDO |
20 |
25 |
| Prognosegüte |
= Absolut(Saldo-Differenz)/Summe der Ist-Zahlungseingänge und -ausgänge = 5 / 195 = 2,6 % |
Tab. 1: Beispielhafter Liquiditätsforecast einer Gesellschaft für einen Monat retrospektiv mit IST-Werten
In diesem stark vereinfachten Beispiel gibt es, wie in der Praxis üblich, mehrere Hierarchie- und Aggregationsebenen. An erster Stelle steht der Saldo. Dieser wird von der zweiten Ebene, der Differenz der Zahlungseingänge und Zahlungsausgänge gebildet. Die Zahlungseingänge und Zahlungsausgänge wiederum ergeben sich aus den Planungskategorien, die entweder selbst die Planungspositionen darstellen oder eine Aggregation mehrerer Planungspositionen sind (im Beispiel: Produkte und Dienstleistungen).
2.2 Ziele definieren
Ist der Status Quo geklärt, können Ziele definiert werden. Dabei wird zuerst die betriebswirtschaftliche Perspektive betrachtet. Das Ziel in unserem Fallbeispiel war es, prototypisch den Aufwand für Forecasts zu reduzieren, ohne die Prognosequalität im Vergleich zum bisherigen manuellen Vorgehen zu verlieren. Dafür wurden Landesgesellschaften ausgewählt, die in der Vergangenheit unterschiedlich gute Prognosen abgegeben hatten.
Die Ziele, die in der betriebswirtschaftlichen Sprache gesetzt werden, werden nun in technische Anforderungen übersetzt. Dafür werden typischerweise wenige Ziel-KPIs, die zum Use Case und Unternehmen passen, sowie der Benchmark anhand eines Vergangenheitszeitraums definiert.
Kern-KPI in dem Beispielprojekt war die Prognosegüte. Diese leitete sich aus der Abweichung (in Prozent) der vorhergesagten Zahlungseingänge und -ausgänge von den tatsächlich eingetretenen Werten ab. Der Benchmark-Zeitraum war Februar 2019 bis Januar 2020.
Anhand der Ziele kann dann abgeleitet werden, in welchem Fall ein Small-Data-Projekt weitergeführt und vertieft wird und in welchem Fall das Projekt gestoppt wird. In dem Beispielprojekt wurde dieses Ziel iterativ verfeinert. Die Vorgabe zu Beginn war nur, dass bei guten Ergebnissen ein entwickeltes Werkzeug in den Prozess integriert werden solle.
2.3 Projektplan entwerfen
Im nächsten Schritt wird ein Projektplan entworfen, in dem dargestellt wird, wie lange die Schritte zur Erreichung der definierten Ziele brauchen sollen. Dabei hängt die Dauer der einzelnen Schritte vom Status Quo ab. Stehen die Daten bereits strukturiert zur Verfügung und sind die Details des zu automatisierenden Prozesses dokumentiert, dauert die Vorbereitung, die oft einen Großteil der Projektdauer in Anspruch nimmt, weniger lang. Hat der Data Scientist einen kurzen Dienstweg zu den operativen Mitarbeitern, verkürzt sich diese Zeit nochmal, da offene Fragen schnell geklärt und Roadblocks beiseite geschafft werden können. Typischerweise werden Projektpläne nach jeder Phase re-evaluiert und an den Projektfortschritt angepasst. Dabei werden sowohl Werkzeuge (z. B. Tabellenkalkulation, SPSS, R, Python) und Methoden ausgewählt als auch Meilensteine für jede Phase sowie Abstimmungstermine festgelegt.
Die Abschätzung eines Projektplans anhand eines klaren Projektauftrags hilft in der Kommunikation und in der Initiierung der Arbeit. Der Plan und das verfeinerte Zielbild müssen aufgrund der vielen Abhängigkeiten und Komplexitäten des zu automatisierenden Prozesses jedoch gemeinsam iterativ überarbeitet werden.
In dem vorliegenden Beispielprojekt hatte die klare Kommunikation der Phasen und Inhalte gekoppelt mit der Etablierung eines gemeinsamen Vokabulars zusätzlich einen positiven Effekt auf die Veränderungsbereitschaft aller Beteiligten. Das hier generierte Wissen über das Projektvorgehen und die Arbeit mit Small Data hatte bereits vor dem Start der Arbeit mit Daten dazu geführt, dass weitere Use Cases besprochen wurden, die mit einer ähnlichen Metho...