Neben dem klassischen Development von Extraktoren, Datenmodellen sowie Kennzahlen und Visualisierungen in BI-Apps und Reports gibt es zahlreiche Themen, die Business Intelligence Projekte abrunden und die zu deren Erfolg signifikant beitragen. In der folgenden Auflistung wird auf diese näher eingegangen.

"Was steckt eigentlich hinter dieser Kennzahl?" – Oder: Glossar
Aufgrund einer Vielzahl an Datenquellen, mehrschichtigen Datenarchitekturen und Self-Service-BI, wo Userinnen und User eigene Apps und Reports anlegen, ist es essentiell, einen Business Glossar anzulegen, damit die Zahlen in den Apps und Reports untereinander vergleichbar bleiben. Userinnen und User interessiert, welche Daten generell zu Verfügung stehen, wie aktuell sie sind, wie die Formeln lauten die hinter Kennzahlen stecken, woher die in diesen Formeln verwendeten Attribute stammen, was die Kennzahl inhaltlich aussagt oder wo die Kennzahl noch verwendet wird? Erreicht kann das über einen Datenkatalog/Glossar werden, dessen Metadaten dazu verwendet werden können, Apps und Reports anzureichern und somit in der Entwicklung und Nutzung einen Mehrwert zu generieren.

"Wo sind die Daten?" – Oder: Monitoring
Extraktoren laden im Idealfall je Datenquelle und je Tabelle die Daten in die BI-Umgebung. Das hat den Vorteil, dass bei fehlerhaften Reloads aus den Quellsystemen nur eine Tabelle failed und nicht mehrere. Dieser fehlerhafte Load einer Tabelle kann durch aktiviertes Alarming (entweder automatische Nachricht via z.B. Slack oder Microsoft Teams oder E-Mail an eine Admin-Gruppe) schnell identifiziert werden. CPU- und Memory-Usage können gemonitored werden, um etwa feststellen zu können, ob Peaks Apps zum Leaken bringen oder ob Memory-Treshholds für Apps eingehalten werden. Zudem macht es Sinn, sich beim Aufsetzen des BI-Environments Monitoring-Apps zu installieren, die es ermöglichen, Apps, Reports und Lizenzen zu monitoren und anhand derer Fragen wie beispielsweise "Welche ist die meistgenutzte App?", "Welche App wird kaum verwendet?", "Wie schaut die Lizenznutzung aus, wie verändert sie sich über die Zeit, werden neue Lizenzen benötigt?" geklärt werden können. Empfehlenswert ist auch, ein Monitoring der Datenqualität durchzuführen und hierbei Regeln zu definieren, die bestimmte Datensätze markieren, z.B. „Attributswert ist im Quellsystem nicht befüllt“ oder „Attributswert ist falsch befüllt“ usw.

"Damit habe ich ja noch nie gearbeitet!" – Oder: Userinnen und User abholen
Für ein frühes Onboarding der Userinnen und User reicht es in der Regel aus, eine erste App bzw. einen ersten Bericht mit Produktivdaten zu haben. Idealerweise ist der Zugang dazu einfach über Single-Sign-On in einem Cloud-Environment möglich, ohne VPN-Zugriff, ohne Beantragung einer Lizenz, ohne zusätzlichen Usernamen. Begleitend dazu genügt die Verteilung eines kurzen und knackigen Handouts, welches die wichtigsten Funktionen und die Verwendung der App bzw. des Berichts beschreibt. Auch der App-Owner / die App-Ownerin soll für Supportthemen bekannt sein. In einer zeitnahen Schulung kann dann auf weitere hilfreiche Features wie Alarme, Kommentare, Subscriptions, Advanced-Analytics-Funktionen oder KI-Insights eingegangen werden um hier nur einige davon zu nennen.

"Der Wert kann aber nicht stimmen!" – Oder: Datenqualität
BI-Apps und Reports stehen oder fallen mit der Datenqualität. Erst, wenn diese gewährleistet ist, wird man Userinnen und User abholen und für die dauerhafte Nutzung motivieren können. Im Zweifel gilt: Es ist besser, weniger Daten anzuzeigen, als falsche. Denn mit falschen Daten wird der App oder dem Bericht nicht mehr vertraut und die Akzeptanz unter den Userinnen und Usern schwindet. Ein weiterer Punkt sind fachlich gleiche aber technisch uneinheitliche Daten, da sie beispielsweise aus unterschiedlichen Quellsystemen kommen und nicht vereinheitlicht wurden. Zahlen werden durch diese uneinheitlichen Stammdaten schwerer vergleichbar. Ein häufiger Fall ist auch, dass in Quellsystemen Pflichtfelder nicht befüllt werden müssen, die später in BI-Apps und Reports jedoch als solche verwendet werden (z.B. in Filtern). Das verzerrt die Datenlage. Abhilfe schaffen hier zum Beispiel Monitoring-Apps, die solche Fälle aufzeigen und fehlende Attributswerte markieren, sodass sie in den Quellsystemen nacherfasst werden können.

"In der App finde ich den Filter nicht mehr, aber der war doch schon mal da!" – Oder: Regeln und Vorgaben
Gedanken zu Beginn der App- und Berichtsentwicklung zielen mitunter häufig auf das Thema Konsistenz ab – Konsistenz in den Berichten und Konsistenz im Entwicklungsprozess. Themen sind hierbei die Verwendung einheitlicher Farben und Logos (Stichwort CI/CD), die Verwendung von Vorlagen und Themes (Aufbau eines Sheets, Header, Footer, Farben, letzter Ladezeitpunkt der Daten, App-OwnerIn), Platzierung von inhaltlich gleichen Filtern an der selben Stelle je Sheet, Verlinkung von Dokumentation und Glossar usw. Diese Maßnahmen tragen dazu bei, dass sich Userinnen und User wesentlich besser in den Apps und Berichten zurechtfinden können. Im Entwicklungsprozess relevant sind die einheitliche Namensgebung von Apps und Reports, der Speicherort und dessen Strukturierung, Versionierung, Entwicklungsrichtlinien und schlussendlich der Test, ob diese Vorgaben auch eingehalten werden.

"Der Aufruf des Berichts dauert heute viel länger als sonst" – Oder: Verfügbarkeit & Performance
Für Userinnen und User sind Verfügbarkeit und Performance einer App oder eines Berichts essentiell. Beide müssen zum benötigten Zeitpunkt abrufbar sein, sprich 24/7. Außerdenm müssen sie schnell öffnen und die Responsezeit bei der Änderung eines Filters muss kurz sein. Cloud-BI-Environments skalieren ihre Ressourcen entsprechend, um Verfügbarkeit und Performance zu gewährleisten. Die BI-Umgebung kann auch hinsichtlich CPU- und Memory-Usage gemonitored werden, um etwa feststellen zu können, ob Peaks zu bestimmten Zeiten Apps zum Leaken bringen oder ob Memory-Tresholds für Apps zu Bottlenecks führen.

"Aber da habe ich noch Plandaten in einem Excel" – Oder: Integration weiterer Datenquellen
Häufig kommt von Userinnen und Usern der Wunsch, Daten einzubinden, die bis jetzt noch nicht in den standardmäßig eingebundenen Datenquellen für die Entwicklung von Apps und Reports zur Verfügung stehen, sondern beispielsweise in Microsoft Ecel – ein Standardfall. Das Einbinden von Microsoft Excel und vieler weiterer externer Datenquellen ist natürlich möglich. BI-Tools liefern dazu zahlreiche Connectoren mit, die in ihrer Anwendung sehr intuitiv sind. Folgende Punkte sollte man aber im Falle einer solchen Anforderung überlegen:

Liegen die Daten doch schon bereits anderenorts in einer anderen Form gespeichert vor? Benötigt noch jemand im Unternehmen diese Daten? Werden diese Daten regelmäßig aktualisiert, was passiert dabei? Sind die Daten für die individuelle Verwendung gedacht oder wird die App für mehrere Userinnen und User veröffentlicht?

Geladen sind die Daten in der Regel schnell, doch sie in den Gesamtkontext zu stellen, bedarf dann doch etwas mehr an Überlegungen. Ansonsten kann es nachgelagert zu Problemen kommen. In einem Excel-Sheet kann sich etwa die Struktur (neue Spalten) ändern, was zu Fehlern in der Datenaktualisierung von BI-Apps und Reports führen kann.

"Mir fehlt da der Zugriff!" – Oder: Security
"Right for data" und "need for data" stehen sich hier häufig gegenüber, denn Daten wollen einerseits breit genutzt werden, andererseits muss der Zugriff auf sensitive Daten geschützt und zielgruppenspezifisch gesteuert werden. Erreicht wird das primär über Benutzer- und Gruppenberechtigungen auf Arbeitsbereich-, App- und Datensatz-Ebene (row-level-security). Zusätzlich kann über Benutzerrollen gesteuert werden, ob berechtigte Userinnen und User beispielsweise Daten aus Apps exportieren dürfen, neue Apps veröffentlichen können, Inhalte einer App teilen sollen usw. Ferner kann eine Kategorisierung von Attributen dazu beitragen, diese zu kennzeichnen – in der Art private, company, public – um in weiterer Folge auf diese Kategorisierung hinzuweisen und deren Verwendung nur im entsprechenden Kontext zuzulassen. Zu Beginn sollten aber grundsätzlich nur jene Daten in die Apps geladen werden, die auch tatsächlich dort Verwendung finden. Dazu macht es Sinn, das verwendete Set an Daten möglichst nahe an der Quelle entsprechend den Anforderungen einzugrenzen.