Als ich im Herbst 2015 zum jährlichen Workshop bei der regionalen Vertriebsniederlassung eines deutschen Automobilherstellers in Südostasien zu Besuch war, empfing mich am ersten Vormittag einer der Regional Sales Manager mit den Worten: „Du, wir haben da noch einen Anschlag auf Dich vor. Ich weiß, diese Woche ist schon komplett mit Trainings und Abteilungsworkshops ausgeplant. Aber es gibt da ein neues Projekt, das sehr wichtig für uns alle ist und schnell gemacht werden müsste. Es geht um ein Bonussystem für unsere Investoren und betrifft alle Abteilungen, daher kennen und akzeptieren alle die Priorität. Wir sind sicher, Ihr und DeltaMaster könnt uns dabei helfen. Es passt genau zu unseren sonstigen Themen. Wäre übrigens klasse, wenn es Ende dieser Woche fertig wäre!“ – kein Scherz, keine Übertreibung. Ganz erfahrener IT-Berater, bewahrte ich Gesichtsausdruck und Körperhaltung und hörte ich mir ruhig die Projektanforderungen im Detail an:

• Ziel war die Implementierung eines Bonus-/Prämiensystems für externe Geschäftspartner (Im-porteure/Investoren) in etwa 25 Ländern.
• Grundlage für die Bonusberechnung bilden jeweils zirka zehn Bewertungskriterien (Kennzahlen) aus fünf Abteilungen: Sales, Aftersales, Marketing, Public Relations und Business Development. Die Anzahl der Kriterien und deren Semantik sollten jedoch variabel sein.
• Pro Kriterium war eine hochindividuelle Berechnungslogik gefordert: Je nach prozentualer Ziel-erreichung sollte im einfachsten Fall eine proportionale Bonifikation erfolgen, es müsste jedoch auch möglich sein, diverse Zusatz-/Ausschlusskriterien, Bonussprünge, Intervalle etc. zu be-rücksichtigen.
• Existierende Kennzahlen, die bereits im Data Warehouse vorliegen, sollten im Sinne der Effizienz nicht mehr manuell bereitgestellt werden müssen, sondern automatisch aus dem BI-System abgerufen werden. Darüber hinaus waren jedoch auch vereinzelt manuelle Eingaben zusätzli-cher Basisgrößen und Zielwerte gewünscht.
• Großer Wert wurde auf die Transparenz und Variabilität des Rechenwerks für Office-Anwender gelegt: Man wollte keine „Black Box“ innerhalb eines Backendsystems, damit Flexibilität für Än-derungen/Ergänzungen, Sonderfälle etc. und größtmögliche Unabhängigkeit vom externen Dienstleister (BC) und der eigenen Zentral-IT bei der deutschen Konzernmutter gegeben sind.
• Die Inbetriebnahme sollte tatsächlich innerhalb einer Woche erfolgen, da die erste Bonusrunde bereits im nächsten Monat anstand.

Abbildung 1: Zielerreichungskurven für ausgewählte Bonuskriterien

Danach bat ich zunächst um etwas Bedenkzeit. Mir war klar, dass unter diesen Umständen keine Lehrbuchlösung mit OLAP-Writeback und komplexen Berechnungen in SQL oder im MDX-Cubeskript in Frage kam. Also was tun: Die Anforderung ablehnen und den Kunden enttäuschen? Ein Projekt mit prohibitiv hoher Aufwandschätzung anbieten? An einen Subunternehmer abspielen?
Irgendwann kam mir der Gedanke zu einer möglichen Lösung: Warum das Pferd nicht von hinten aufzäumen? Anstelle die bisherige Excel-Lösung abzuschaffen und den Prozess und die Berechnungslogik ins Data Warehouse bzw. DeltaMaster zu verlagern, könnte es doch andersherum funktionieren: Der Wunsch war ja eigentlich nur, einerseits existierende Informationen „aus DeltaMaster“ (in Wirklichkeit aus dessen Grundlage, dem MSAS-OLAP-Cube) wiederzuverwenden, und andererseits die Ergebnisse der Bonuskalkulation zum Reporting in DeltaMaster zur Verfügung zu stellen.
Die Möglichkeit, in Excel mit Daten aus relationalen und multidimensionalen Quellen zu arbeiten, ist weithin bekannt, wird jedoch aus nachvollziehbaren Gründen in unseren Projekten üblicherweise nicht thematisiert – immerhin bestünde die Gefahr, dass einzelne Excel-affine Anwender sonst ihre eigene lokale BI-Lösung parallel zu DeltaMaster „basteln“. Hier jedoch erschien mir diese Option charmant. Also erklärte ich dem Sales Manager meine Idee:

• Ausgangspunkt war die gemeinsame Erstellung einer Excel-Arbeitsmappe, die mit Hilfe von Microsoft-Standardfunktionalität die vorhandenen KPIs aus Analysis Services abruft.
• Diese Datei diente der eigenständigen Definition und Pflege der gewünschten, sogar weitge-hend bereits vorbereiteten Berechnungslogik sowie die Ergänzung der manuellen Eingaben durch den Kunden selbst innerhalb der gewohnten Excel-Umgebung.
• Der Kunde übernahm ebenfalls eigenständig die Vorbereitung eines tabellarischen Ausgabe-formats für die berechneten Boni mittels Excel-Funktionalität.
• Ich hatte lediglich eine kleine Erweiterung des OLAP-Modells (eine neue KPI-Dimension sowie eine neue MeasureGroup) sowie den automatischen Reimport der Ausgabedaten ins Data Wa-rehouse per SQL Server Integration Services (SSIS) für das Reporting und die Analyse mit Del-taMaster vorzubereiten.

Der Kunde sah die Vorteile des Ansatzes und gab mir sofort grünes Licht. Am Montagabend war klar: Der Aufwand für Implementierung und Know-how-Transfer an den Sales Manager betrugen weniger als einen Tag. Der Kunde war glücklich und ich erleichtert, denn das fachliche Know-how und die Ver-antwortung den für Betrieb und die inhaltliche Korrektheit blieben so beim Kunden anstatt bei BC.
Für die detailinteressierten Leser hier noch einige Hinweise zur Umsetzung in Excel. Der Einstieg zur Datenabfrage aus Analysis Services erfolgt über das Menü Daten:

Abbildung 2: Abruf externer Daten aus MSAS in Excel

Nach Auswahl von Server

Abbildung 3: Serverauswahl

Datenbank und Cube

Abbildung 4: Datenbank-/Cubeauswahl

werden die Verbindungsinformationen in einer Datei mit der Endung .ods (Office Data Source) ge-speichert:

Abbildung 5: Speichern der ODC-Datei

Hier ist es bei der Verwendung der Excel-Datei durch mehrere Benutzer natürlich sinnvoll, die ODC-Datei auf einem allen Beteiligten zugänglichen Netzlaufwerk abzulegen (pragmatische Empfehlung: im gleichen Verzeichnis wie die XLSX). Wie im Screenshot ersichtlich ist, wird der Pfad zur ODC-Datei in der Excel-Datei gespeichert.
Im letzten Schritt kann eine neue Pivottabelle an beliebiger Stelle der Excel-Datei angelegt werden:

Abbildung 6: Pivottabelle anlegen

Abbildung 7: Pivottabelle in Excel

Der Inhalt der Pivottabelle ist unerheblich, wichtig einzig der nächste Schritt: die Umstellung auf den Formelmodus im Menü Optionen:

Abbildung 8: Formelmodus aktivieren

Im Anschluss wird schnell klar, welche Möglichkeiten sich nun eröffnen:

• Überschriften in Zeilen-/Spaltenköpfen rufen mit Hilfe der Funktion CubeElement Dimensions-elemente oder Measures ab.
  =CUBEELEMENT(; )
• Datenzellen fragen mit Hilfe der Funktion CubeWert (CubeValue bei englischen Installationen) unter Verwendung expliziter Adressierung oder mit Hilfe Zellverknüpfungen Tupel ab.
  =CUBEWERT(; [; ReferenzN])

Abbildung 9: CubeWert-Funktion mit Zellreferenzen

Um bei der Datenabfrage mit CubeWert Fehler zu vermeiden, ist unbedingt zu beachten, dass die Referenzierung (d.h. die Bildung von MDX-Tupeln durch eine beliebige Anzahl Parameter) die Dimen-sionen in wahlfreier Reihenfolge anspricht und die Referenzen als Wert übergeben werden. Wenn also eine CubeWert-Funktion auf eine Zelle verweist, in der wiederum mit Hilfe der CubeElement-Funktion die Wertart „Ist“ mit der ID 1 abgefragt wird, empfängt die CubeWert-Funktion nur den Wert 1, nicht etwa den vollen MDX-Namen „[Wertart].[Wertart].[Wertart].&[1]“. Das kann zu Problemen führen, wenn im Datenmodell IDs dimensionsübergreifend nicht eindeutig sind.
Letztlich sei auf die Möglichkeit hingewiesen, auch nachträglich den gewünschten Modus der Aktuali-sierung der aus MSAS abgerufenen Daten einzustellen. Hierzu kann über das Menü Daten im Eintrag Verbindungen die ODC-Datei editiert werden:

Abbildung 10: Datenverbindungen anzeigen

Abbildung 11: Liste der Datenverbindungen (ODC-Dateien)

Über die Schaltfläche Eigenschaften gelangt man zu dem Dialog, der die gewünschten Einstellungen anbietet:

Abbildung 12: Verbindungseigenschaften zur Datenaktualisierung

Wir haben in unserem Projekt gute Erfahrungen mit der Option „Aktualisieren beim Öffnen der Datei“ gemacht, da diese nach unseren Tests auch beim Öffnen durch SSIS wirkt.
Mein Fazit des spontanen und unkonventionellen Kleinprojekts „DeltaMaster-Excel-Hybrid“:

• In manchen Fällen sind pragmatische, ergebnisorientierte Lösungen im Sinne des Kunden der eigenen Überzeugung von Lehrbucharchitekturen/-prozessen vorzuziehen.
• Ein Planungsprojekt mit OLAP- oder Hybrid-Writeback hätte einen Aufwand von 30-50 Tagen, anschließende Betriebsverantwortung unsererseits und das Risiko großer Komplikationen bis hin zum Imageverlust für DeltaMaster und BC bedeutet.
• DeltaMaster ist und bleibt beim Kunden gesetztes Medium für die Ergebnisausgabe an die Ge-schäftsführung und hat damit maximale positive Sichtbarkeit.
• Die Lösung ist inzwischen im zweiten Jahr aktiv und findet trotz Fluktuation beim Kunden (neuer Sachbearbeiter mit minimalen IT-Kenntnissen) hohe Akzeptanz, da sie komplett eigen-ständig beherrscht wird.