Governd Data Discovery

Mit der Version 9.4.1 hat das Modul Visual Insight (Self-Service-Tool von MicroStrategy) eine Qualität erreicht, der ich aus folgenden Gründen absolute Praxistauglichkeit bescheinige:

Innerhalb von ein bis zwei Tagen Schulung kann dem (End-)Anwender der Umgang mit dem Tool vermittelt werden.
Der Business User kann weitere Datenquellen wie Excel, CSV oder andere Datenbanken einbinden, ohne auf die IT-Abteilung zugreifen zu müssen.
Er kann qualitätsgesicherte MicroStrategy-Berichte/Cubes als Datenbasis in seine Berichte einbinden, was mir besonders gut gefällt. Damit ist es ihm möglich, eigene Kennzahlen mit solchen aus dem Konzern-DWH zu vermischen.

Die Berichtsentwickler in den Fachbereichen können intuitiv eigene Berichte erstellen und die vorhandene zentrale BI-Infrastruktur nutzen. Daraus ergeben sich folgende Vorteile gegenüber einer kompletten Insellösung (Hinweis: Wenn ich im Folgenden von „Berichten“ spreche, sind damit auch Dokumente oder Dashboards gemeint.):

User Synchronisation: In den zentralen BI-Abteilungen ist dies technisch und/oder organisatorisch gelöst. Aufgaben wie das Eintreten und Ausscheiden von Usern, die Pflege der Security-Filter oder das Zurücksetzen von Passwörtern werden von der IT übernommen.
Berichte lassen sich über MicroStrategy beliebig verteilen. Die Anwender können sowohl über das Web als auch über Mobilgeräte oder MS Office zugreifen.
Nutzung der vorhandenen Infrastruktur inklusive der Back-up-Mechanismen
Nutzung bestehender Security Filter, die sicherstellen, dass der Enduser nur seine Dateninhalte sieht
Nutzung bestehender Objekte mit qualitätsgesicherten Kennzahlen (Cubes, Berichte, Metriken, Filter usw.) zur direkten Einbindung in die eigenen Berichte

Auch für IT- und Compliance-Abteilungen bietet dieser Ansatz einige Vorteile:

Die Anzahl zu verwaltender Tools reduziert sich. Dadurch wird beispielsweise die Überprüfung vereinfacht, ob die Beachtung von Datenschutzrichtlinien gewährleistet ist.
Mithilfe des Enterprise Managers lässt sich nachvollziehen, welche Anwender auf die Berichte zugreifen, genauer gesagt, welcher Bericht wie oft genutzt wird und welche Ressourcen dieser verbraucht. Des Weiteren kann ein dahingehendes Monitoring erfolgen, wie viele bereichsspezifische BI-Objekte es im Unternehmen gibt.
Ein vereinfachter Abgleich zentraler und dezentraler Kennzahlen ist möglich, da sich diese zumindest in einem Tool befinden.

Tipps, Tricks & Ideen für die Umsetzung

Alle Probleme, die sich aus der Verknüpfung der zentralen und dezentralen BI in einem MicroStrategy-Projekt ergeben, kann Visual Insight natürlich nicht lösen.

Verantwortlichkeit für veröffentlichte Berichte

Neben technischen Aspekten müssen insbesondere die Wartung des Systems und die inhaltliche Verantwortung für veröffentlichen Berichte sichergestellt werden. Das heißt, dass sich für jeden Bericht im System eine klare Verantwortlichkeit (Mitarbeiter, Abteilung oder Bereich) zuordnen lassen muss. Für den Endanwender ist es wichtig, dass hier nicht zuletzt deshalb Transparenz herrscht, damit er sich mit Rückfragen an die richtige Stelle wenden kann. Folgende Ansätze haben sich als praktikabel erwiesen:

Es gibt unterschiedliche Ordner, die nach Verantwortlichkeit gegliedert sind: Dieser Ansatz ist zwar einfach, hat aber den Nachteil, dass der Endanwender seine Berichte in vielen Ordnern suchen muss.
Es sind intelligente Navigationssysteme für die Dokumente vorhanden, die klar anzeigen, welcher Bereich den Bericht veröffentlicht hat: Dieser Ansatz ist sehr flexibel, bringt allerdings einen höheren Aufwand mit sich.

MSTR-Cube-Berichte

Berichte, die auf MicroStrategy-Cubes basieren, weisen in diesem Kontext zwei Vorteile auf:

Es lässt sich wesentlich einfacher sicherstellen, dass die richtigen Zahlen angezeigt werden, als dies bei klassischen ROLAP-Berichten (SQL) der Fall ist.
Muss ein Objekt (z. B. ein Attribut) ausgetauscht werden, kann dies einfach aus dem Cube entfernt werden. Die darauf basierenden Berichte/Dashboards funktionieren dann zwar nicht mehr, aber die IT kann handeln, ohne dass die Berichte im Vorfeld angepasst werden, was bei klassischen MSTR-Berichten der Fall ist. Der Fachbereich wird rechtzeitig informiert und muss dann entsprechend reagieren.

Der Nachteil von Cube-Berichten ist allerdings, dass diese bei Weitem nicht so flexibel sind wie die klassischen ROLAP-Berichte.

Begrenzung der Anzahl (X) an Berichten/Objekten

Die Fachbereiche können und sollen Berichte erstellen. Es gilt jedoch, zu vermeiden, dass in den Metadaten zigtausende Berichte gespeichert werden, deren Inhalt und Qualität niemand mehr kennt. Ursache einer solchen Situation ist zumeist, dass einmalig oder temporär benötigte Berichte beziehungsweise Entwicklungsstände von Berichten nicht gelöscht werden.

Erfahrungsgemäß trifft die allgemeine Forderung, das BI-System regelmäßig aufzuräumen, auf breite Zustimmung. Allerdings reagieren die Anwender meistens mit Widerstand, wenn sie die Aufforderung erhalten, ihre alten Berichte zu löschen oder diese an das neue Datenmodell anzupassen.

Der Vorteil bei diesem Ansatz liegt darin, dass es zumindest thematisiert wird und gegebenenfalls eskaliert werden kann, wenn ein Fachbereich die Zahl X überschreitet. Wichtig hierbei ist nicht so sehr die konkrete Zahl hinter dem X, sondern vielmehr, dass die Verhinderung eines unkontrollierten Wachstums an einer bestimmten Stelle im Konzern erfolgt. Als Konsequenz aus solchen Gesprächen kann sich durchaus ergeben, dass die Zahl X erhöht wird.

Löschung von ungenutzten Berichten

Mit dem Enterprise Manager lässt sich festhalten, wann welcher Bericht ausgeführt wurde. Wird ein Bericht über einen Zeitraum von einem Jahr nicht genutzt, so kann dieser gekennzeichnet werden. Wird er im folgenden Jahr ebenfalls nicht verwendet, sollte er gelöscht werden.

Kostenumlage hinsichtlich gespeicherter Objekte/Ausführungszeiten

Dies ist mein Favorit unter allen Optionen. (Leider konnte ich noch keinen Kunden überzeugen). Das Speichern von Objekten in den Metadaten wird in Rechnung gestellt. Das muss pro Bericht keine hohe Summe sein und kann sich beispielsweise auf 100 € im Jahr belaufen. Wenn der Fachbereich eine plausible Anzahl an Berichten erstellt, ist der Jahresbetrag überschaubar. Für 100 Berichte wären somit 10.000 € fällig. Kommt die Abteilung aber ihrer Wartungspflicht nicht nach, summieren sich die Beträge schnell und erreichen schwindelerregende Höhen.

Ein weiterer Ansatz im Hinblick auf die Kostenumlage ist die Einbeziehung der Rechenlast, die die Berichte auf der Datenbank auslösen. Erstellen die Fachbereich Berichte, die besonders lange Ausführungszeiten in den Systemen verursachen, behindert dies auch die anderen Anwender. Was hier zumeist Abhilfe schafft, ist das Tunen dieser Berichte. Ich bin überzeugt davon, dass hohe Kostenumlagen Fachbereiche motivieren würden, ihre Langläufer tunen zu lassen.

Ausgliederung aus dem Konzern-DWH

Dies ist die letzte und folgerichtige Konsequenz, wenn sich die Anforderung eines Bereiches als zu komplex beziehungsweise zu individuell darstellen, um sie sinnvoll in das zentrale DWH einzubinden. Die Gründe hierfür sind vielfältig, liegen aber häufig in der benötigten Sicht auf die Daten und den auszuwertenden Datenbereichen oder hängen mit den beteiligten Personen zusammen. Dies gilt insbesondere dann, wenn umfangreiche individuelle Entwicklungsarbeiten erforderlich sind, um die Anforderungen zu erfüllen, und diese nicht zur strategischen Ausrichtung des zentralen DWH passen. Die chronisch überlasteten DWH-Abteilungen sollten ihren Fokus auf die gemeinsame Sicht der Daten setzen.