Wenn ein konservativer, geschäftskritischer Fachbereich auf neue Technologien mit anderen, kreativen Möglichkeiten trifft, führt das zu Reibungen, aber auch zu Ergebnissen, die andere Personen auf neue Ideen bringen können. Bei dem hier geschilderten Anwendungsfall geht es um die Ermittlung einer kurzfristigen Erfolgrechnung (KER) unter Nutzung von NoSQL-Technologien. Einer Aufgabenstellung, die für beide Seiten sehr lehrreich war.

Erinnern Sie sich noch an die Werbespots von Apple mit Justin Long und John Hodgman als menschlicher Apple und Personal Computer? Ähnlich wie in den Werbespots sind die beiden Bereiche Finance Controlling und Data Science zu betrachten. Der eine eher konservativ, geschäftskritisch, mit etablierten Methoden und Verfahren; der andere mit einem Zoo voller verschiedener Werkzeuge für den kreativen Umgang mit Daten. Insbesondere wenn dann auch noch NoSQL ins Spiel kommt, mag man glauben, dass keinerlei Berührungspunkte existieren. Dennoch eignen sich neue Technologien auch für etablierte Bereiche und können diese bereichern und auf neue Ideen bringen.

Bei einer kurzfristigen Erfolgsrechnung (sog. KER) handelt es sich um die Aufstellung kaufmännischer Kennzahlen und den Vergleich über Zeiträume. Unter anderem wird hierbei auch häufig von Deckungsbeitragsrechnung oder Betriebsergebnisrechnung gesprochen. Eine KER wird vom Controlling daher aus der kaufmännischen Software generiert (z.B. SAP FiCo) und zumeist nur als Datei oder tatsächlich noch auf Papier an Bereichsleiter oder die Geschäftsführung übergeben.

Ergänzend zu der standardisierten Aufstellung sollte es in dem hier geschilderten Fall möglich sein, dass die Berechnung der KER unter Berücksichtigung von Filtermöglichkeiten ad hoc durch einen Endanwender möglich sein soll. Das bedeutet, dass nicht mehr nur ausschließlich das Controlling die Erfolgsrechnung generieren kann, sondern auch jeder Fachbereich selbständig für sich. Dementsprechend müssen die Werkzeuge aus dem Data Science einmal konfiguriert und benutzerfreundlich bereitgestellt werden.

Die Generierung einer Erfolgrechnung mag auf den ersten Blick nicht direkt als Aufgabe für einen Data Scientist wirken, schließlich sind die Daten und deren Aufbau bekannt, genauso wie die Form des Endergebnisses. Dennoch stellen sich der Vielzahl bekannter Variablen, genauso viele unbekannte gegenüber. Denn wenn ein relationales Modell einfach in eine neue Technologie (NoSQL) überführt wird, hat man nichts dabei gewonnen. Erst der kreative Einsatz neuer Methoden und der etwas andere Umgang mit bekannten Daten führt zu einer Verbesserung und neuen Idee.

Daten

Bei den zu verarbeitenden Daten handelt es sich um Buchungsdaten (SAP Export), Plandaten (csv-Export aus einem Planungssystem) und um manuelle Informationen aus Excel (als csv-Dateien). Insgesamt sind es mindestens neun Datenquellen unterschiedlicher Qualität. Insbesondere bei den manuell erstellten Excel-Daten muss mehrfach geprüft werden, ob die Dateien in dem vereinbarten Format vorliegen. (Gerade bei manuell gepflegten Daten greift Murphys Law – immer!)

Die Inhalte der Excel-Daten reichern die anderen beiden Quelldaten durch weitere Informationen an. Hierbei handelt es sich u.a. um Mappinginformationen zur Ergänzung kurzer Schreibweisen oder maskierter Inhalte, damit diese durch Endanwender gelesen werden können. Beispielsweise sind Kostenstellen in Unternehmensbereiche, Abteilungen und Produktgruppen zu entschlüsseln.

Bei den Buchungsdaten aus dem SAP-System handelt es sich um die monatlichen Saldenwerte eines Kontos, die granular auf Kostenstelle, Marke, Periode und weitere Merkmale heruntergebrochen wurden. Damit wird also nicht pro Monat ein Kontensaldo übergeben, sondern eine Vielzahl von Salden je Konto, je nachdem, wie viele Merkmale geliefert werden.

Beispiel für eine Zeile aus dem SAP-Export:

Je Periode (im Regelfall: Monate) wird eine Datei geliefert; dabei ist aus dem Dateinamen die Betriebszugehörigkeit und die Periode abzulesen. Es gilt zudem, dass ein Unternehmen in mehr als 12 Perioden pro Jahr Buchungen durchführen kann (in diesem Fall bis zu 16).

Die Buchungsinformationen und alle weiteren Dateien werden mit einer Java-Anwendung in die NoSQL-Datenbank importiert. Hierbei wird auf eine multi-model Datenbank zurückgegriffen, um im späteren Verlauf verschiedene NoSQL-Technologien nutzen zu können (z.B. documentstore, graphdb, multi-value und bi-temporal).

Modellierung

Für jede Datenquelle wird eine Datensatzart genutzt. Relational gesprochen bedeutet das eine Tabelle je Quelle oder für Benutzer von document stores: eine “collection” für gleichartige Dokumente.

Bei der gewählten Datenbank wird allerdings nicht zwischen verschiedenen “collections” unterschieden. Nur durch ein Feld je Datensatz wird der Typ des Datensatzes festgelegt. In der Anwendung wird dieses Feld interpretiert und der Datensatz entsprechend angezeigt (anhand von Templates für die JSON-Ausgabe). Da – wie bei document stores üblich – die Dokumente ein dynamisches Schema aufweisen, können sich alle Datensätze in ihrer Art und Ausprägung (Key/Values) unterscheiden.

Als Ergänzung zu den bisherigen Quelldaten werden innerhalb der Datenbank weitere Datensätze für das Layout der KER-Ausgabe angelegt. Diese beschreiben im Prinzip nur die Reihenfolge und den Inhalt der späteren Ausgabe (dazu später mehr).

Nach dem Import der Datensätze werden innerhalb der Datenbank zwischen den Datensätzen Verlinkungen (Graphen) etabliert. So zeigen beispielsweise alle Buchungen auf das jeweils betroffene Konto oder eine KER-Ergebniszeile auf eine Kontengruppe. Aus der Skizze zum Datenmodell können die relevanten Verlinkungen abgelesen werden.

Anzumerken ist hier, dass ein Konto in mehreren Kontengruppen auftreten kann. Eine einzelne n:m-Verlinkung wird daher in diesem Fall über separate Datensätze abgehandelt und nicht in einem Datensatz mit einer Unterstruktur. Das wäre zwar auch möglich, erschwert und verlangsamt allerdings etwaige Aktualisierungen, da die csv-Quelle nur eine Zeile je Zuweisung liefert.

Für die Speicherung der Buchungsinformationen wird auf die Funktionalität der bi-temporalen Datenhaltung zurückgegriffen. Hierbei erhält jeder Feldinhalt in einem Datensatz (optional) den Vermerk des Gültigkeitszeitpunktes. Neben dem Transaktionszeitpunkt (wann wurden die Daten gespeichert) ist also auch erkennbar ab (oder auch bis) wann ein Inhalt gültig ist. Dabei ist zu beachten, dass “nicht-gültig” etwas anderes ist, als “falsch”. In dieser Art der Verwendung steht “nicht-gültig” für “nicht mehr aktuell” oder auch “noch nicht aktuell”.

Durch diese Art der Datensatzspeicherung reduziert sich die Anzahl der Buchungsdatensätze auf einen Bruchteil des ursprünglichen Datenbestandes. Beispiel: Es werden jeden Monat 10.000 Buchungen geliefert. Für 16 Monate ergeben sich somit 160.000 Datensätze. Da diese bi-temporal gespeichert werden, bleibt es bei 10.000 Datensätzen in der Datenbank mit je max. 16 Gültigkeitswerten je Feld (für jede Periode).

Hier sei noch angemerkt, dass ein Wert so lange gültig ist, bis ein anderer Wert diesen ergänzt. Wird also für Januar ein bestimmter Wert geliefert und im Laufe des Jahres nicht geändert, bleibt dieser bestehen und wird nicht nochmal gespeichert. Statt 16 Einträgen, bleibt es also bei einem.

Ergänzend dazu stellt sich die Frage zum Umgang mit den Perioden 13 bis 16. Da ein Jahr nur 12 Monate besitzt, können diese nicht einfach mit einem falschen Datum gespeichert werden. Hier greift allerdings der Umstand, dass speziell in diesem Anwendungsfall erst am Ende eines Monats durch den Monatsabschluss alle Buchungen korrekt sind. Innerhalb eines Monats ist das nicht der Fall. Es gibt also genau einen (und nur einen) korrekten Zeitpunkt, an dem die Werte korrekt und gültig sind. Die Werte einer Buchung zu diesem Zeitpunkt werden also nur zu einem Tag in dem Datensatz gespeichert.

Schaut man sich nun den Screenshot des Datensatzes mit den Monatswerten an, fällt auf, dass die Salden-Werte (im Feld “SAP-Werte”) jeweils zum Zweiten eines Monats gespeichert wurden. Da es nur einen gültigen Wert je Monat gibt, ist das Datum irrelevant (es hätte auch der Dritte oder Vierte des Monats sein können). Für jede Periode größer 12 wurde einfach vorgesehen, dass diese ab dem 13.12. eines Jahres hinterlegt werden (d.h. für Periode 14 der 14.12.; Periode 15 der 15.12. usw.). Und da zum Anfang eines Jahres alle Buchungen zu bestimmten Konten auf Null gesetzt werden müssen (also zum 01.01.) bietet sich der Zweite eines Monats an.

Nach dem Einlesen aller gelieferten csv-Dateien, erfolgt die Erzeugung von weiteren Datensätzen für das Layout der Ergebnisrechnung. Diese werden einmalig angelegt und können über eine Benutzeroberfläche vom Anwender angepasst werden.

Wie in der Skizze zum Datenmodell zu erkennen, besteht das Layout der KER aus zwei Datensatztypen. Einmal aus der Layout-Definition (nur ein Datensatz) und zum Zweiten aus mehreren Ergebniszeilen, die jeweils über einen Datensatz beschrieben werden.

Beide Datensatztypen bestehen dabei fast ausschließlich aus Linkfeldern (Graphen). Das KER-Layout verweist damit auf die beteiligten Zeilen in der Reihenfolge, wie sie später angezeigt werden; ein Datensatz für eine KER-Zeile verweist auf die jeweiligen Kontengruppen.

In einem zusätzlichen Textfeld einer KER-Zeile wird zudem die Formel eingetragen, über die bei der späteren Anzeige ad hoc das Ergebnis der jeweiligen Zeile berechnet wird (in dem abgebildeten, einfachen Fall nur die Summe zweier Kontengruppen). Dazu steht serverseitig die Bibliothek der Google V8 Javascript-Engine zur Verfügung.

Der Screenshot der Ergebniszeile zeigt zudem die Verwendung von “multi-values” in einem Datensatz. Hierbei können verschiedene Inhalte in einem Feld abgelegt und auch mit anderen Feldern kombiniert werden. In diesem Fall gehören jeweils eine Kontengruppe und der prozentuale Bezug zueinander. Andere Anwendungsfälle sind bspw. die Bankverbindungen oder Kontaktdaten einer Person, da diese auch aus mehreren, zusammengehörenden Feldern bestehen und jede Person mehrere besitzen kann.

Bis hierher wurden die Daten importiert, das Datenmodell aufgebaut und die Datensätze miteinander verlinkt. Aus der NoSQL-Trickkiste nutzen wir die bitemporale Datenhaltung, Graphen, multi-values und document stores. Dadurch wird die Anzahl der Datensätze reduziert und das Datenmodell vereinfacht. Im nächsten Schritt geht es darum, die KER-Ausgabe aufzubereiten und die Ergebnisse – unter Berücksichtigung von Filtermöglichkeiten – mit Hilfe von serverseitigem JavaScript zu berechnen.

Anwendung

Der Anwendungsfall KER-Liste ist im Rahmen eines Gesamtprojektes ein Teilaspekt. Daher wurde auf vorhandene Werkzeuge zurückgegriffen, um mit den gegebenen Mitteln den maximalen Nutzen zu erreichen.

Als System steht eine multi-model NoSQL-Platform zur Verfügung, die mehrere Bereiche der NoSQL-Welt abdeckt und nicht nur eine Datenbank beinhaltet, sondern gleich ein ganzes Arsenal an Werkzeugen, um Lösungen zu erschaffen. Dazu gehört unter anderem auch eine standardisierte Webanwendung, in der durch einfache Konfigurationen Anwendungen definiert werden und die es ermöglicht, die serverseitige Bibliothek der Google V8 Javascript-Engine zu nutzen. Dadurch wird ein Großteil des Anwendungsfalles aus der Softwareentwicklung herausgelöst und an den Fachbereich übertragen.

Hierbei ist zu beachten, dass der Data Scientist sich nicht von dem Fachthema vollständig lösen kann. Ein Grundverständnis ist notwendig, um zu verstehen, wie die Problemlage ist und was das Endergebnis sein soll. Genauso muss der Fachbereich Grundlagen des Datenhandlings und des Systems verstehen. Nur beide zusammen können in einer transparenten Kommunikationsstruktur Lösungen erarbeiten.

Nach der Konfiguration des Datenmodells und dem Import der Daten wurde alles Weitere in der Standardanwendung der NoSQL-Plattform umgesetzt. Dieses beinhaltet unter anderem die Konfiguration der Erfolgsrechnung, wie auch den JavaScript-Teil zur Ermittlung der Ergebnisse und später auch die grafische Ausgabe in Form eines Dashboards mit den gleichen Filter-Möglichkeiten der KER-Ausgabe.

Um innerhalb der Anwendung die kurzfristige Erfolgsrechnung zu erzeugen, wird auf die Funktion von Listen zurückgegriffen. Diese können, ausgehend von einem Datensatz, die Graph-Strukturen auflösen und so hierarchische Ausgaben erzeugen. Als Ergänzung dazu ist eine Integration von Javascript innerhalb der Listen möglich, so dass Berechnungen serverseitig durchgeführt und Ergebnisse zur Anzeige gebracht werden können. Darüber hinaus ist die Nutzung über eine HTTP API möglich, um die Anwendung ggf. später durch weitere Funktionen zu erweitern.

Ausgehend von dem definierten Datensatz für das KER-Layout ermöglicht die Listenfunktionalität die Konfiguration von sog. Sublisten (also Listen in Listen in Listen in …). Hierbei verfolgt die Liste die Graphenstruktur und bringt die jeweiligen Datensätze zur Anzeige. Durch das genutzte Modell ist der Startpunkt somit ein einzelner Datensatz, zu dem dann hierarchisch alle weiteren Datensätze dazu geladen werden.

Die entstehende Baumstrukur ist im ersten Schritt leer und muss im Anschluss durch JavaScript gefüllt werden. Dazu wird einerseits auf die Inhalte aus der untersten Ebene zurückgegriffen, um die Saldenwerte zu lesen; andererseits auch auf die hinterlegten Formeln jeder Ergebniszeile, um mit den Summen der Kontengruppen die Ergebnisse zu ermitteln.

Das Zauberwort bei der Nutzung von Javascript heißt hier “eval”. Durch diese Funktion werden Strings als Script evaluiert. Im Detail werden durch reguläre Ausdrücke die Begriffe in den Formeln (Namen der Kontengruppen) durch die Summenwerte der jeweiligen Kontengruppe ersetzt und danach mit Hilfe von “eval” ausgeführt. Das Ergebnis wird dann an die entsprechende Position in der Liste geschrieben.

Im Weiteren erhalten bestimmte Werte noch unterschiedliche Formate, um den kosmetischen Aspekt zu erfüllen. Am Ende erhält der Anwender eine KER-Liste.

Filter

Die Generierung einer vollständigen KER dauert bis zu fünf Sekunden. Dabei liegen bis zu 40.000 Buchungsdatensätze zu Grunde. Durch einen interaktiven Filter kann der Anwender den Umfang der Liste und die Berechnung entsprechend einschränken. Folgende Felder aus den Buchungsdatensätzen stehen dabei für Filterkombinationen zur Verfügung:

• Buchungskreise (Filialen): 14
• Geschäftsbereich (Abteilung): 32
• Kostenstelle: 56
• Marke: 9
• Absatzkanal: 12

Hierbei kann der Anwender jede beliebige Kombination in jeder erdenklichen Reihenfolge zur Filterung nutzen. Die Liste wird entsprechend neu berechnet und in unter fünf Sekunden zur Anzeige gebracht (wegen der reduzierten Datenmenge häufig in unter einer Sekunde).

Als Ergänzung zu den Filtermöglichkeiten kann auch der zeitliche Aspekt berücksichtigt werden. Da die Buchungsinformationen bitemporal gespeichert wurden, besteht in der Liste die Möglichkeit, ein beliebiges Datum zu wählen und sich die Werte dazu anzeigen zu lassen.

Gesamtfunktion und Ausblick

Durch den generalistischen Ansatz des Datenmodells und der gewählten Datenbank konnte nicht nur die kurzfristige Erfolgsrechnung in der üblichen, tabellarischen Form ausgegeben werden. Ferner wurde eine grafische Ausgabe mit der Bibliothek d3.js realisiert, so dass jede Führungskraft in der Lage ist, eine ad hoc Analyse durchzuführen. (Ich spreche hier gerne von KRV-tauglich. “Kinder, Rentner, Vorstände”).

Derzeitig wird JavaScript innerhalb von Listen genutzt, um bei Bedarf Werte zu errechnen. Als Ausblick steht hier in Kürze die Möglichkeit zur Verfügung, dass Scripte auch innerhalb von Datensätze abgelegt und autonom von der Datenbank selber ausgeführt werden. Das hat zur Folge, dass Objekte (Datensätze) Algorithmen beinhalten und selbständig Informationen suchen und generieren.

Verwendete NoSQL-Methoden

• document store
• GraphDB
• multi-Value
• Bitemporal

Erwähnte Technologien, Produkte und Marken in diesem Artikel

• CortexDB (Multi-Model Datenbank)
• NoSQL
• SAP
• Excel
• Google V8
• d3.js

Der hier beschriebene Anwendungsfall soll zeigen, dass Data Science nicht nur Endergebnisse liefert, die quasi durch eine “black box” entstanden, dessen Vorgehensweise nur eingeweihte Personen beherrschen und beurteilen können. Es ist vielmehr so, dass die “Wissenschaft” das Wissen dafür schafft, damit ein “normaler” Anwender mit den Daten umgehen kann und einen Mehrwert daraus erhält.