Databricks und Planung oder einfache Eingabe

Motivation

Databricks hat sich zu einer wichtigen Datenplattform für Unternehmen entwickelt. Diese Plattform wird durch die Ankündigung der Zusammenarbeit von SAP mit Databricks gestärkt. 

Dank der guten KI-Möglichkeiten in Databricks kann man sich viele Daten z.B. für eine Planung vorschlagen lassen.  

Doch, was macht man, wenn man feststellt, dass einzelne Daten fehlen, die man nicht aus einer vorhanden Datenquelle generiert oder manuell korrigieren muss? Welche Möglichkeiten hat man dazu in Databricks? 

In dieser Blog-Serie möchten wir genau diese Möglichkeiten für eine Planung in Databricks untersuchen und darstellen, was möglich ist. 

Dazu fangen wir in diesem ersten Blog mit der Frage an, was Planung eigentlich ist, bzw. was genau die technischen Anforderungen für eine Erfassung von Zahlen sind. Die möglichen Szenarien beginnen bei einer einfachen Dateneingabe und reichen bis hin zur komplexen Planungsanwendung. 

Nicht jedes Anwendungsszenario benötigt alle Anforderungen. Daher hilft die erste Analyse bei der Überprüfung des eigenen konkreten Anwendungsfalls. 

In den folgenden Blogs werden wir beschreiben, wie und welche der Anforderungen wir davon schon in Databricks umsetzen konnten. 

Was ist Planung?

Wenn wir untersuchen wollen, ob eine Planung mit Databricks möglich ist, müssen wir zunächst definieren, was Planung ist, bzw. welche Anforderungen für eine Planung an das Tool zu stellen sind. Dabei werden wir feststellen, dass es nicht den einen Planungsprozess gibt und, je nach fachlicher Anforderung, unterschiedliche technische Anforderungen nötig sind. Wir werden dann einzelne Punkte analysieren und unsere Ergebnisse in den folgenden Blogs beschreiben. 

Hier ein paar Beispiele von Funktionen, die für verschieden Anforderungen an eine Planung nötig sind.  

Einfache Erfassung von Daten

Beginnen wir mit der Erfassung von Daten, auch wenn dies eigentlich keine richtige Planung ist, sondern eher als „Eingabemaske“ zu bezeichnen ist. Die Erfassung von Texten und Zahlen, die nicht aus einer vorhandenen Quelle kommen, sind schon erste einfache Varianten einer Planung. Dies kann z.B. schon für einfache Steuerungen in der Beladung von Daten verwendet werden. 

Kombinieren von Anzeige- und Erfassungsspalten

Die Erfassung von Planzahlen neben vorhandenen Ist-Zahlen kommt dem Begriff der Planung schon näher, z.B. wenn die Verkaufszahlen für verschiedene Produkte des vergangenen Jahres vorliegen und die Zahlen für das folgende Jahr geplant werden sollen. Hierfür müssen vorhandene Daten in eine tabelle angezeigt und in einer zusätzlichen Spalte Planzahlen erfasst werden. Dabei ist sicherzustellen, dass der Planer nur in der Planspalte die zahlen erfasst und die anderen Spalten nicht ändern kann. Im Beispiel in Abblidung 1 sind die zu ändernden Zellen farblich hervorgehoben und eindeutig zu erkennen.

Abbildung 1: Beispiel einer einfachen Budgetplanung von Produkten in der SAC mit folgenden Funktionen 

1: Kopieren von Ist-Zahlen
2: Erfassung auf einem Hierarchie-Knoten und Verteilung auf Produkte
3: Einfügen einer neuen Zeile, die noch nicht in den Ist-Daten existiert

Verteilung von Planzahlen bei Erfassung von aggregierter Ebene

In großen Planungen werden die Werte häufig auf sehr detaillierter Ebene benötigt (z.B. Produkt, Monat), aber die eigentliche Erfassung erfolgt auf einer viel höhere Ebene (z.B. Jahr und Produktgruppe). Eine initiale Verteilung soll nach bestimmten Regeln erfolgen, z.B. analog vorhandener Ist-Daten und, wenn diese fehlen, gleichverteilt. Diese initiale Verteilung kann dann von einem Planer angepasst werden. (s. Abb. 1 – Punkt 1) 

Neben der reinen Verteilungsfunktionalität stellt sich hier schnell die Frage, was manuell erfasst werden und was von einer KI vorgeschlagen werden soll. Aber auch ein KI-Vorschlag sollte sicher (noch) ein Mensch überarbeiten, da die KI evtl. nicht alle Rahmenbedingungen berücksichtigt (z.B. geplante Neuerscheinungen, neue Geschäfte, …). Auch bei der Überarbeitung der KI-erzeugten Daten wird solch eine Verteilungsfunktion benötigt. 

Stammdaten in der Planung und neue Zeilen

Sollen in einer Planung neue Kombinationen / Zeilen erfasst werden, ist für eine konsistente Planung entscheidend, dass nur gültige Stammdaten verwendet werden. Es ist wichtig, dass bei der Erfassung neuer Zeilen eine Verprobung gegen die Stammdatentabellen möglich ist. Diese kann auch als Eingabehilfe verwendet werden. So vermeidet man Schreibfehler in der Planung, die die Qualität der Planung reduzieren. 

Diese Stammdatentabellen können dann auch weitere Merkmale enthalten, nach denen das Reporting bzw. die Planung zusammengefasst werden können, z.B. Produktgruppen als Eigenschaften der Produkte. 

In einigen Fällen ist es nötig, während der Planung neue Stammdaten anzulegen. Hier ist sicherzustellen, dass diese konsistent angelegt werden und zu den späteren Ist-Zahlen zugeordnet werden können. 

Audit-Merkmale und Eingaben rückgängig machen

Häufig soll in einer Planung nachvollziehbar sein, wer welche Zahlen wann und wie geändert hat. Dazu sind die Änderungen mit User und Zeitstempel zu hinterlegen. Dies setzt voraus, dass alle Änderungen nur als Delta gespeichert werden (s. Tabelle 1). 

Wenn Daten so gespeichert werden, ist es möglich, eine Funktion zu implementieren, die Datenänderungen rückgängig macht. 

Tabelle 1: Delta – Erfassung mit Zeitstempel 

Parallele Planung / Eingaben von mehreren Anwendern 

Bei größeren Planungsanlässen werden sicher mehrere Anwender gleichzeitig Daten erfassen wollen. Damit diese nicht die Zahlen des jeweils anderen löschen, kann man mit folgenden einfachen Prüfungen arbeiten (s. Abb. 2.): 

  • Gar keine Prüfung, alles speichern 
    Werden die Daten nur selten oder von einem User geändert, sind sicher keine Einschränkungen nötig. Je häufiger mehrere Anwender Zahlen erfassen, desto höher ist die Wahrscheinlichkeit, dass sie gegenseitig Zahlen überschreiben. Werden immer alle angezeigten Daten beim Sichern weggeschrieben, überschreibt ein User 1 dabei Zahlen, die er eigentlich gar nicht geändert hat mit seinen alten Werten, die User 2 inzwischen geändert hat. Je länger er mit der Erfassung beschäftigt sind, desto größer dieses Risiko. 
  • Nur geänderte Daten speichern, sonst keine Prüfung 
    Um das Risiko des versehentlichen Überschreibens zu reduzieren, hilft es schon, nur die geänderten Daten zu sichern, evtl. sogar mit einem Zeitstempel. Dann können mehrere User an unterschiedlichen Werten gleichzeitig Änderungen vornehmen. Außerdem kann man Änderungen nachverfolgen (s. Abb. 2). Hier gewinnt dann immer der Letzte, der die Zahlen ändert. 
  • Warnung, wenn Zahlen gleichzeitig geändert werden 
    Als gleichzeitig gilt, wenn die Änderung zwischen dem Lesen der Werte in den Cache der einzelnen User und dem Sichern erfolgt (s. Abb. 3). Hier muss entschieden werden, wie zu verfahren ist. Andernfalls kann es passieren, falls nur das Delta der Änderung gespeichert wird, dass der Endwert nicht der Wert eines Users ist, sondern die Summe aller Änderungen. 
  • Sperren 
    Der sicherste, aber aufwendigste Ansatz ist, die Werte zu sperren, sobald ein Anwender einen bestimmten Bereich zur Planung öffnet. Dann erhalten andere Anwender eine Warnung, dass die Planzahlen und die Daten für die Änderung derzeit durch einen User gesperrt sind. Von diesem klassischen löst man sich aber in modernen Anwendungen. Sperren erhöhen den Implementierungsaufwand und werden manchmal gelöscht, wenn die Anwendung nicht korrekt beendet wird. Dadurch kommt es immer wieder zu fehlerhaften Sperrmeldungen, die den Planungsprozess behindern. In der älteren Planung von SAP im BW (SAP BPC) erfolgt die Planung mit einem Sperrkonzept. In der neueren Planung in SAC hat SAP auf die Sperren verzichtet. Auch bei Microsoft sperrt man inzwischen ein Dokument auf einem zentralen Laufwerk nicht mehr exklusiv, wenn es geändert wird. 

Abbildung 2: Parallele Planung – User 1 und User 2 können ohne Sperre gleichzeitig unterschiedliche Werte ändern und sichern. Beide Änderungen werden berücksichtigt. 

Abbildung 3: Parallele Planung – User 1 und User 2 wollen gleichzeitig den selben Wert ändern. Hier muss geklärt werden, wie der Konflikt gelöst wird. 

Administration und Steuerung der Planung

Eine Planung muss gesteuert werden. Bei regelmäßigen Planungen, z.B. einem Forecast, muss ein Administrator festlegen, welches der aktuelle erste Planmonat für diese Runde sein soll. Alle Layouts sollten sich dann entsprechend anpassen. 

Außerdem muss eine Planung geöffnet und geschlossen werden können. Nach Planungsende sollen die Zahlen nicht mehr verändert werden, bzw. die Zahlen sollen nach einer Prüfung nur für bestimmte Länder gesperrt werden. Andere Länder müssen evtl. noch nacharbeiten. 

Versionierung

Während einer Planung können unterschiedliche Versionen nötig sein. Z.B. beginnt die Budgetplanung mit einer ersten Planung durch die Fachbereiche. Im anschluss wird das gesamtergebnis geprüft, bestimmte Bereiche müssen dann ihre Planung anpassen. Alternativ kann ein optimistisches und ein pessimistisches Szenario erfasst werden. All dies ist in unterschiedlichen Versionen festzuhalten. Diest ist durch ein geeignetes versionskonzept zu unterstützen.

Funktionen für die Initialisierung / Planungsvorbereitung

Planungen beginnen häuftig nicht mit einem leeren Blatt, sondern werden initial aus den Ist-Daten mit einer einfachen %-Anpassung erstellt. Für diese Planungsvorbereitung sind diverse Funktionen, beispielsweise Kopierfunktionen, nötig (s. Abb. 1 – Punkt 2). Eventuell kann dies bereits auch schon mit einem KI-Tool über die einfachen Vorgaben hinaus verbessert werden.

Überblick der Funktionaltitäten

Hier geben wir über alle vorgestellten Funktionalitäten einen Überblick: 

Tabelle 2: Überblick der Funktionalitäten

Weiteres Vorgehen

Wie beschrieben, sind für eine Planung unterschiedlichste Anforderungen nötig, wobei nicht für jede Planungsanwendung alle Anforderungen nötig sind. 

Daher werden wir die Anforderungen getrennt analysieren und prüfen, was sich mit welchem Aufwand in Databricks umsetzen lässt. Unsere Ergebnisse werden wir in den nächsten Blogs veröffentlichen.  

Wir sind ebenso gespannt wie Sie, wie weit mir bei diesen Anforderungen mit Databricks kommen. 

Erstellt im Juli 2025

Ansprech­partner

Frank Liebrand
Head of Sales
Ilya Kirzner
Consultant
Michael Ochmann
Michael Ochmann
Consultant
Burcin Ince
Consultant
Ahmet-Ömer Özgen
Consultant
biX Consulting
Datenschutz-Übersicht

Diese Website verwendet Cookies, damit wir dir die bestmögliche Benutzererfahrung bieten können. Cookie-Informationen werden in deinem Browser gespeichert und führen Funktionen aus, wie das Wiedererkennen von dir, wenn du auf unsere Website zurückkehrst, und hilft unserem Team zu verstehen, welche Abschnitte der Website für dich am interessantesten und nützlichsten sind.