Ein Interview mit Lucients Power BI Experten Walter Putz über den von ihm entwickelten Power BI Praxis Workshop
FL: Hier mit mir ist Walter Putz, Experte, Trainer und Consultant bei Lucient für Power BI. Er hat Lucients Power BI Praxis Workshop entwickelt, bei dem er sich dem Thema aus 3 Blickwinkeln nähert.
Was hat Dich dazu gebracht, den Power BI Praxis Workshop zu entwickeln und anzubieten?
WP: Die Erfahrung von bisherigen Workshops war, dass viele Stakeholder nicht so recht wussten, wie man PowerBI anwendet, welche Möglichkeiten es jetzt gibt. Da denke ich vor allem an die Unterschiede zwischen Power BI On-Premises und Power BI Web Service und was sich daraus für Fragen ergeben.
FL: Was ist denn eigentlich der Unterschied-für Power BI zwischen Web Service und On-Premises für die Praxis?
Das Management muss entscheiden: Power BI Web Service oder On-Premises
WP: Von den Updatezyklen ist es ein riesiger Unterschied. Im Web Service wird monatlich upgedatet. On-Premises wird dreimal im Jahr upgedatet. Das ist ein ganz wesentlicher Unterschied. Es gibt für Power BI als Web Service ein eigenes Power BI Desktop genauso wie für Power BI On-Premises. also von Software-Installation gibt es einen Unterschied. Die Funktionen, die rund um Power BI Reports angeboten werden, sind im Web Service viel umfangreicher. Es gibt zum Beispiel im Web Service sogenannte Dashboards. Das heißt, man kann Grafiken aus mehreren Reports auf eine Seite zusammenziehen. Das gibt es On-Premises nicht. Darüber hinaus ist von der Datenhaltung natürlich ein riesiger Unterschied, ob die Daten jetzt die Firewall quasi verlassen, wenn wir ins Web Service gehen oder wenn man On-Premises bleibt, wo die Daten eigentlich das eigene Netzwerk nie verlassen.
FL: Wenn wir an Kunden denken, die schon ähnliche Workflows besucht haben. Mit welchen Erwartungen und Intentionen kommen die an uns heran?
WP: Die haben ganz unterschiedliche Erwartungen. Sie möchten eigentlich nur, dass Power BI funktioniert. Meine Gegenfragen sind dann meistens: Wo sollen die Daten liegen? Welche Datenformate haben sie? Wie soll das ganze aussehen? Wir werden damit gleich vor viele Fragen gestellt, die viel Impact haben: Darf ich die Daten in die Cloud hochladen? Gibt es da irgendwelche Policies? Welche Möglichkeiten habe ich, gerade was die Cloud betrifft? Welche Möglichkeiten habe ich organisationsfremde Partner für die Reports reinzuholen? Weiters ergeben sich eine ganze Menge an Fragen, die nicht zuletzt an ganz datenbanktheoretischen Dingen rühren, wie zum Beispiel das Aufbereiten der Daten, die dargestellt werden sollen.
Das Management muss wissen, was hier passiert
FL: Wer sind denn eigentlich die Stakeholder im Unternehmen, die dabei sein sollten? Es gibt ja unterschiedliche Verantwortlichkeiten, vielleicht auch Eitelkeiten. Wer sollte, wer darf, wer muss mitreden?
WP: Am besten ist es für eine BI Lösung bzw. Power BI-Lösung, wenn, sie relativ weit oben in der Organisation aufgehängt ist. Das Management soll wissen, was hier passiert, weil es typischerweise die es sind, die die solche Lösungen konsumieren. Aber ganz wesentlich ist natürlich die IT, weil die letztendlich dieses Ding servicieren, warten und administrieren müssen. Es ist wesentlich, dass die Leute, die die Daten zur Verfügung stellen können, die Applikationsverantwortlichen zum Beispiel von ERP Systemen mit an Bord sind. Abschließend natürlich auch die Leute, die letztendlich die Reports selbst machen sollten. Wir sollten schon im Hinterkopf behalten, dass Power BI zur Gruppe der Selfservice BI-Lösungen gehört. Das heißt, geeignete Anwender sollten in der Lage sein, basierend auf einem guten Datenmodell selbst Reports zu erstellen, jedenfalls aber verändern und anpassen zu können.
Die Rolle der IT
FL: Vielleicht jetzt naiv gefragt Wir erfahren ja die ganze Zeit vom Marketing, speziell von Microsoft, Power Bi ist ein SelfService BI für die User. Wozu brauchen wir die IT überhaupt?
WP: Die IT spielt da eine ganz wesentliche Rolle. Sie muss die Prozesse bereitstellen, damit die
Daten ordentlich aufbereitet zur Verfügung gestellt werden. Wir reden da von einem klassischen Sternmodell. Was steckt dahinter? Die klassische Vertriebsauswertung, die aus einer Standardsoftware kommt, liefert uns Daten wie zum Beispiel welcher Kunde welches Produkt an einem bestimmten Datum gekauft hat. Informationen, die wir in dem Zusammenhang nicht haben, sind, welche Produkte wurden zum Beispiel nicht verkauft werden. Üblicherweise kriegen wir in diesen Auswertungen immer nur die Produkte, die verkauft wurden. Ebenso bekommen wir nicht die Kunden, die nichts gekauft haben, sondern nur die Kunden, die tatsächlich gekauft haben: Oft ist aber für solche Fragestellungen viel interessanter: Welche Kunden haben länger nichts gekauft? Nur muss die Power BI Lösung da auf die Gesamtzahl der Kunden zugreifen können, um diese Frage danach letztendlich beantworten zu können. Das ist in vielen Projekten zu Beginn eigentlich die größte Herausforderung, Außerdem dass diese Daten regelmäßig, richtig und genau zur Verfügung gestellt werden. Die IT muss diese Prozesse ja letztendlich zur Verfügung stellen. Wenn das Datenmodell dann entsprechend gut in einem Sternmodell aufgebaut ist, dann können wir nämlich auch sehr leicht die Daten eruieren, die wir nicht haben. Nämlich wer hat wann nicht bestellt oder welcher Kunde hat welches Produkt nicht bestellt? Je sauberer diese Datenaufbereitung passiert, je einfacher und schöner modelliert dieses Datenmodell ist, umso einfacher können wir Self Service betreiben.
FL: Sie haben den Workshops ja aus 3 Blickwinkeln entwickelt. Um welche drei Blickwinkel handelt es sich da?
Lucients Power BI Experte Walter Putz
WP: Ich würde das tatsächlich in drei Gruppen sehen: Die klassischen Admins, die in der Früh reinschauen und sagen: „Jawohl, der Datentransfer von unserem ERP-System in unser Datawarehouse ist erfolgreich durchgelaufen.“ Die überlegen sich: „Schafft man diese Transformationsprozesse im Zeitfenster, das wir in der Nacht haben?“ Dann gibt es die klassischen Developer oder Datenbankentwickler (das hängt von der Größe der Organisation ab, das kann man nicht so ganz klar trennen). Die sind dafür verantwortlich, das Datenmodell zu generieren und zu denormalisieren, wie wir das so schön nennen. Zusätzlich gibt es noch die User oder Power User, die sich auch mit der Gruppe der Developer überschneiden. Die erstellen später die Reports und greifen auf die Daten zu. Abschließend haben wir noch die reinen User, die diese Reports konsumieren und in der Früh ins Büro kommen oder auf ihrem Smartphone oder Tablet ihre Reports oder Dashboards anschauen können und dort auch ihre Informationen managementtauglich bekommen.
FL: Gehen wir bitte einen Schritt zurück. Was für Art von Kunden im Sinne von Größenordnung oder Branchen interessieren sich normalerweise für den Workshop?
WP: Power BI ist in den Ks von den KMUs (kleinere und mittlere Unternehmen) angekommen. Wir haben in den Workshops, die ich in der letzten Zeit gehalten habe, Unternehmen mit 5,10 Mitarbeitern, die nicht die klassische BI Infrastruktur aufbauen wollen, aber zum Teil Microsoft 365 mit einer Power Bi Pro-Lizenz haben. Die nutzen dann einen kleinen abgespeckten Bereich. Gleichzeitig gibt es durchaus große Unternehmen, die Ihre bestehenden Datawarehouse Landschaften mit Cognos oderBusiness Objects haben, um nur einige zu nennen. Die wünschen eine modernere agilerer und interaktivere Lösung, aber nicht nur im Sinne der Usability. Es soll eben kein neues Projekt gestartet werden, nur um von einem 3D Diagramm in ein Balkendiagramm zu wechseln. Von daher ist die Bandbreite von Unternehmen sehr groß.
Admins, Devs, User und ihre typischen Herausforderungen
FL: Gehen wir nochmals zu den Rollen zurück. Was sind die größten Herausforderungen für die Administratoren, die auf uns zukommen?
WP: Für die Administratoren ist eine der ganz großen Herausforderungen die Entscheidung: „Gehen wir in die Cloud? Nehmen wir das Web Service oder nehmen wir On-Premises?“ Da stellt sich sehr oft die Frage: „Gibt es bereits eine Cloud bzw. eine Cloud Policy? Dürfen wir Daten in die Cloud legen? Um welche Daten handelt es sich?“ Wenn es um Endbenutzerdaten geht, ist die Hürde für den Weg in die Cloud oft relativ hoch.
FL: Ist das eher eine technische oder eine politische Frage?
WP: Das ist vor allem eine rechtliche bzw. politische Frage, die bei den Admins aufgehängt ist, die hier eine Entscheidung treffen müssen. Dann stellt sich eine weitere Frage. Power BI ist ja nur eines von ganz vielen Tools, die in Microsoft 365 zur Verfügung gestellt werden und gerade in größeren Unternehmen stellt sich die Frage, wer administriert jetzt wirklich die Power BI. Da geht es jetzt weniger darum, wie die Datenquellen zur Verfügung gestellt werden. Das ist Just-Doing. Die Frage ist eher: „Wer ist für Berechtigungen zuständig? Wie organisiert man zum Beispiel Work Spaces? (Work Spaces sind die Denkeinheit im Power BI Web Service, wo die Reports veröffentlicht werden) Und last not least stellt sich natürlich die Frage: „Wo liegen dann die Daten wirklich? Liegen sie in irgendwelchen On-Premises Datenbanken und man braucht ein Gateway? Wie aktuell können die Gateways sein? Wie löst man das in Bezug auf die Security? Wobei technisch ist das als machbar. Das ist eben die Konfiguration. Spannend ist, wo dies in der Organisation tatsächlich aufgehängt wird.
FL: Mit welchen Jobprofilen oder Position haben wir es üblicherweise zu tun? CIOs? Heads of IT-Infrastructure? Oder gar IT-Admins?
WP: Letztendlich ist es der DBA, der das von der Datenbankseite her triggert. Der DBA ist allerdings nicht derjenige, der den Microsoft 365 Tennant konfiguriert. Das ist so ein riesiger Themenbereich. Da müssen mehrere Rollen zusammenspielen. Letztlich liegt das meist in Teilverantwortungen des Head of Cloud Infrastructure oder Head of IT-Infrastructure je nach Organisationsform im Unternehmen.
FL: Die zweite Gruppe, die Du hervorgehoben hast, sind die Entwickler, die Developer. Was sind deren größte Herausforderungen in einem Power BI Projekt?
WP: Die Developer haben die Herausforderung, dass sie eigentlich das, was sie über normalisierte Datenbanken gelernt haben, ganz bewusst vergessen müssen, um sich denormalisierte Datenmodelle zu überlegen, die für Analysesysteme optimiert sind. Oft ist hier weniger Erfahrung und theoretisches Knowhow vorhanden, was aber wesentlich ist, um Datenmodelle entsprechend aufbereiten zu können, die dann letztlich die Basis für Selfservice BI bilden zu können?
FL: Wenn wir jetzt von Selfservice BI reden, wo kommen dann tatsächlich die User ins Spiel und was sollten die können?
WP: Ich versuche die idealtypischen Power BI Report Ersteller so zu beschreiben: IT-affine Zahlenjunkies, die Lust haben, sich mit dem Ganzen zu beschäftigen. Wer sagt: „Ich mag mich nicht mit IT beschäftigen und Zahlen sind mir auch zuwider.“, der wird sich mit Power BI schwertun, obwohl es hübsche bunte Bilder gibt. Aber eigentlich ist das Zahlenwerk darunter das Spannende. Was man sich auch überlegen muss, ist ein Power BI Lifecycle. Man hat sein wunderbares Modell, die Daten aus dem ERP-System, aus dem CRM-System, dem Webshop oder woher auch immer. Man hat auch saubere Prozesse, wie diese Daten aufbereitet werden können. Da wir von Self Service BI reden, sind die User in der Lage, sogenannte Mashups zu bauen, also andere Datenquellen zu integrieren. Zum Beispiel mit den Vertriebszahlen die Einwohnerzahlen der entsprechenden Orte zu verknüpfen, um so eine Relation herzustellen, eventuell Umsatz je Einwohner. Diese Zahl könnte interessant sein. Dann geht der Ball zurück an den Developer oder den Admin, um sicherzustellen, dass diese Zahlen akkurat und aktuell gehalten werden und wo man diese herbekommt. Das wäre ein Fall, wo ein User-Experiment nach einer Schleife zu Developern und Admins, die das Datenmodell erweitern, sozusagen in den Regelbetrieb übergeht.
Ebenso kann es gut sein, dass man irgendwelche neuen Berechnungen- sogenannte Measures – findet, wo es Sinn macht, die weiter vorne anzusiedeln. Das soll heißen, sie als Kennzahl ins ursprüngliche Datenmodell einzubauen, damit sie nicht jeder User von Neuem berechnen braucht.
Warum „Accesseritis“ vermieden werden sollte
FL: Das sind wir ja, glaub ich, in der in der Nähe von einem Begriff, den Du häufig in Power BI Praxis Workshops verwendest: „Accesseritis“ Was verstehst Du darunter?
WP: (lacht) Ja, die die Accesseritis ist einer meiner Lieblingsbegriffe, die ich gerne verwende. Es hat Mitte der 90er Jahre diese „Accesseritis gravita“ gegeben. Man hat damals ein Tool in die Hand bekommen, mit der man leicht eine Datenbank und damit auch ein Front End erzeugen konnte. Jeder, der sich ein bisschen damit beschäftigt hat, konnte so seine kleine Schatten-IT bauen. Ich auch damals. Was ist passiert? Es haben sich aus großen Daten, kleine Datentöpfchen gebildet. Wenn dann nach dem Umsatz gefragt wurde, sind mindestens 5 Zahlen kursiert, weil in jeder Access-Datenbank irgendeine andere Berechnung enthalten war, die für sich durchaus richtig war, aber im Gesamtkontext nicht vergleichbar. Diese Gefahr sehe ich auch in Power BI, ein sehr handsames Tool, mit dem man sehr schnell lustige Auswertungen machen kann. Wie die Datenbasis ausschaut, ist da und dort wieder sehr relativ und im Prinzip kann jeder wieder so seine eigene BI Lösung bauen. Und wenn man dann in die Unternehmen schaut, werden die Reports dann sehr oft auch nicht veröffentlicht, sondern werden in einzelnen Filesystemen zur Verfügung gestellt und wer Zugriff hat, kann sich dieses File anschauen, vielleicht verändern, adaptieren oder sich seine eigene Subversion daraus bauen. Diese Herausforderung sehe ich auch bei Power BI.
FL: Kommen wir mal zum Workshop selbst. Arbeiten Sie vor Ort lieber mit Beispieldaten unter Laborbedingungen oder mit echten Daten?
WP: Ich vermeide mit Echtdaten zu arbeiten aus einem ganz einfachen Grund. Erstens kenne ich die Daten dort nicht und kann auf bestimmte Situationen, die ich erklären möchte, nicht eingehen. Zweitens kommt es bei Echtdaten nahezu unvermeidlich zur Diskussion, warum bei einem bestimmten Kunden eigentlich kein Umsatz gemacht wurde oder warum von einem bestimmten Artikel nur so viel verkauft wurde. Das ist dann extrem zermürbend und verbraucht viel Zeit. Daher nehme ich das Datenmaterial lieber mit bzw. arbeite mit Online-Labs. Dort hat man auch alle Berechtigungen, und kann Dinge ausprobieren. In den Unternehmensdaten fehlen wieder irgendwelche Zugänge bzw., sind nicht freigeschalten und es dauert ewig dies zu bekommen. Daher schätze ich die Laborumgebungen sehr.
Die Mächtigkeit der Datumsdimension als Aha-Erlebnis für Workshopteilnehmer
FL: Was sind denn typische Aha-Erlebnisse der Kunden im Power BI Praxis Workshop? Was überrascht sie typischerweise?
WP: Eine der ganz wesentlichen Dimensionen, die man in BI Systemen verwendet, ist die Datumsdimension. Diese Datumsdimension liefert im Prinzip einen Überbau über alles, was wir an Datumsinformationen haben. Das geht vom klassischen Datum über Wochennummern bis zu irgendwelchen Kombinationen von Jahr und Woche. Das ist die Basis gerade im Power BI für die sogenannte Datums- oder Zeitintelligenz. Dies ist der Schlüssel für ganz viele weitere Auswertungen. Sehr oft kommen die Anforderungen über Excel-Sheets. Excel ist relativ großzügig. Ich kann mittendrin die Datentypen ändern, eine neue Spalte hinzufügen für das nächste und übernächste Jahr beispielsweise. Im Power BI muss man diese Dinge stärker berechnen. Dafür sind sie sehr viel dynamischer und ich kann viel leichter in die Zukunft oder in die Vergangenheit schauen, weil wir eben diese Datumsdimension haben. Es glauben mir viele Einsteiger in die Thematik oft nicht, dass das so ein wesentlicher Kern ist.
Ein anderer Punkt ist, dass viele sagen: „Wir bekommen von unserem Software-Hersteller halt diese Auswertung.“ Aber dann fehlt für ein vollständiges Bild oft die gesamte Kundenliste oder die vollständige Artikelliste. Die Auswertung vom Hersteller zeigt oft nur, wer tatsächlich was gekauft hat. Tatsächlich könnte aber auch interessant sein, wer was nicht gekauft hat. Da heben unsere Kunden oft die Augenbrauen und meinen: „Ja, spannend, das könnten wir brauchen.“
FL: Was ist es, was die Kunden konkret aus dem Power BI Praxis Workshop mitnehmen?
WP: Die nehmen Erfahrung mit. Das ist ein ganz wesentlicher Teil und ganz klassisch ein Werkzeug, mit dem sie sofort loslegen können. Ich bin da etwas Ralph Kimball-getriggert. Ein erstes Tool, das man verwenden kann, ist das sogenannte Bus-Diagramm. Damit lässt sich ein Überblick erstellen, wo man mit seinem Datawarehouse hinmöchte. Der Kunde kann sein Bus-Diagramm ausfüllen und sich die wichtigsten Aspekte vor Augen holen. Er hat nach dem Workshop einen roten Faden mit dem er loslegen und vor allem die richtigen Fragen stellen kann.
FL: Als Abschlussfrage in Zeiten der Pandemie. Sollte der Power BI Praxis Workshop onsite stattfinden oder funktioniert er auch online?
WP: Ich habe beides regelmäßig durchgeführt. Es macht beides Sinn.
FL: Wie viele Tage oder wie viel Zeit sollte man sich für einen Power BI Praxis Workshop nehmen?
WP: Das hängt so ein bisschen auch von der Teilnehmergröße ab und wie weit man da jetzt verschiedene Gruppen reinnehmen will. Aber ich würde mal sagen 2 bis 4 Tage sind sicherlich brauchbare Größenordnungen. In einem Tag kann man mal mit einer Gruppe starten. Aber dass man da jetzt richtig ins Handeln kommt und dann mal was gesehen hat, ist eher schwierig. Aber für eine Vorführung als Appetizer kann auch das reichen.
FL: Vielen Dank für das Gespräch
WP: Sehr gerne, ich freue mich, darauf weitere Power BI Praxis Workshops durchzuführen!
Das Interview wurde von Fritz Lechnitz durchgeführt
