Die Erstellung eines Planungscubes in SQL Server 2012, also eines direkt beschreibbaren Cubes, ist einfacher als häufig angenommen. Mit dem FLEX-Reporting! Standardcube und einem solidem Konzept wird aus dem standardisierten Reportingcube mit wenigen Handgriffen ein dynamischer Planungscube. Der Planungscube steht seit FLEX-Reporting! Release 3.1 als Zusatzmodul zur Verfügung.

Wesentlich für den reibungslosen Betrieb der Controllingprozesse ist, dass der Planungscube als eigenständiges Objekt parallel zum unveränderten Reportingcube bereit gestellt wird und die beiden Datamarts mittels der bewährten FLEX-Konnnektoren für den gezielten Datenaustausch verbunden werden.

Schritt 1: Vorbereitungen

Zuerst wird eine eigene "Planungs-Instanz" für den Betrieb des Planungscubes am SQL Server 2012 entsprechend dem FLEX-Reporting! Installationsleitfaden eingerichtet, analog zur schon vorhandenen "Reporting-Instanz". Damit wird sichergestellt, dass der operative Reportingbetrieb niemals beeinträchtigt wird und die "Planungs-Instanz" optimal für den Planungsprozess gestaltet werden kann. Damit die neue "Planungs-Instanz" zu einer effektiven Planungsumgebung wird, sind lediglich die folgenden Schritte notwendig.

Schritt 2: Reduktion des Cubes und planungskonforme Benennung

FLEX-Reporting! arbeitet mit 14 Standarddimensionen mit je 3 parallelen Hierarchien - es ist unwahrscheinlich dass so viele Dimensionen für die Planung nützlich sind. Die Reduktion erfolgt sehr unkompliziert im SSAS-Projekt (Visual Studio), bei dieser Gelegenheit sollten auch gleich die abstrakten Hierarchien mit sprechenden Namen versehen werden. Das Resultat kann dann etwa für die Kostenstellenplanung so aussehen:

Natürlich können sämtliche Cube-Objekte auf die individuellen Bedürfnisse ganz einfach umbenannt werden, wesentlich für die Erstellung des Planungscubes ist die Reduktion der Struktur um die nicht relevanten Dimensionen. Damit wird das Datenvolumen so gering als notwendig gehalten und die Benutzer können sich nicht im Datenmodell verirren.

Schritt 3: Reduktion der Dimensionen und planungsspezifische Anpassungen

Die Dimensionstiefe ist auf die tatsächliche Planungsebene zu reduzieren, unnötig tiefe Strukturen erzeugen unnötige Splashings bei der Dateneingabe. Damit wird die maximale Performance erreicht, Scheingenauigkeiten durch technische Top-Down Verteilung von vornherein vermieden und Irrtümer in Bezug auf den zu verantwortenden Planungslevel ausgeschlossen.

Die Dimensionen sollten nicht nur abgeflacht sondern auch um nicht relevante Strukturteile reduziert werden um fehlerhafte Eingaben auszuschliessen. So sollten in einer Kostenstellenplanung etwa keine Projekte oder Innenaufträge verfügbar sein. Die Zeitdimension ist jedenfalls auf den Monatsultimo zu reduzieren und nicht planungsrelevante Zeiträume am besten aus der Zeitdimension entfernen. Die Dataunit-Dimension wird häufig auf die zwei Einträge "Lokalwährung" und "Menge" reduziert, die tatsächlichen Einheiten werden bei der Datenübergabe in den Reportingcube aus den anderen Stammdaten "zurückgeholt".

Hier ist schon erkennbar, dass es auch konzeptionell in vielen Fällen Sinn macht, für die Planung eigene Stammdaten zu führen, dies wird durch die unter "Schritt 1" bereitgestellte separate "Planungs-Instanz" problemlos ermöglicht. Reporting-idente Stammdaten können unkompliziert mit Query-Tables in Excel "angezapft" werden sodaß auch keine Stammdaten doppelt gewartet werden müssen.

Schritt 4: Aktivieren der Writeback-Funktionalität

Nach all den nützlichen Vorbereitungen kommt der eigentliche Knackpunkt, der Cube wird jetzt für das Rückschreiben aktiviert. Dies geschieht am besten im SSAS Projekt (Visual Studio) im Reiter "Partitionen", rechter Mausklick auf die gewünschte Partition (im FLEX-Reporting! Standard gibt es ohnehin nur eine Partition):

Im SQL Server Datenbankmodul wird nun eine relationale Tabelle für die zurückzuschreibenden Werte angelegt, wir nennen diese "T_FACT_Performance_Writeback":

FERTIG, der Cube ist ab sofort beplanbar!

Hinweis: um die Writeback-Funktionalität aktivieren zu können muss der Cube bestimmte Merkmale erfüllen. So darf etwa die Kontointelligenz im Planungscube nicht aktiviert sein.

Schritt 5: Los geht`s!

Von nun an kann mit jedem planungstauglichen Frontend der Cube in Echtzeit beschrieben werden. Im nächsten Blogbeitrag sehen wir, wie das mit der Excel 2010 Pivottabelle bewerkstelligt wird.

Schritt 6: Datenflüsse

Für die Erstbefüllung des Planungscubes mit Bewegungsdaten wird am einfachsten im CORE_DWH ein Quellview angelegt mit den entsprechenden Filterungen und "Abflachungen" in den Dimensionselementen. Dieser View wird mit dem Standard-Konnektor für SQL Server an den Planungscube angebunden. Die Stammdaten werden ohnehin eigenständig definiert (ggfs. mit Excel Query-Tables auf die bestehenden Stammdaten).

Für die Überführung ausgewählter, validierter Planungsstände aus dem Planungscube in den Reportingcube wird ein entsprechender View auf die relationale Writeback-Tabelle des Planungscubes angelegt und mittels Standard-Konnektor für SQL Server an den Reportingcube angebunden.

Die Bereitstellung des Planungscubes einschliesslich der Views für die Datenflüsse ist in wenigen Stunden realisiert und einsatzbereit.