Rollen und Verantwortlichkeiten innerhalb eines Business-Intelligence-Teams

Der Start mit Power BI war für mich die gleiche Erfahrung wie für viele meiner Kollegen – obwohl es außerhalb unseres Verantwortungsbereichs lag, gab es einen Bedarf an der Technologie und wir begannen mit der Verwendung nach nur einem begrenzten Training. Dies würde im Allgemeinen dazu dienen einige kleine, individuelle Projekte zu automatisieren. Kleine Erfolge führten dazu noch mehr Berichte zu erstellen und als die Projekte größer wurden, wurden sie schließlich zu komplex, um sie alleine zu bewältigen.

Zu diesem Zeitpunkt wurde ich dem Entwicklungsteam für Business Intelligence (BI) und den unterschiedlichen Verantwortlichkeiten vorgestellt, die sie haben würden. Ich begann zunächst mit Data Engineers und später mit Business Analysten, Projektmanagern, UI-Experten und mehr zu arbeiten. Ich hatte jedoch kein gutes Verständnis dafür, wie diese verschiedenen Rollen ihre Verantwortlichkeiten in der BI-Entwicklung definierten und teilten, bis ich zu einem Softwarehaus kam.

In diesem Beitrag beschreibe ich die unterschiedlichen Rollen in einem BI-Team und einige wichtige Überlegungen zur Zusammenarbeit, aus Sicht eines Power BI-Entwicklers. Der wichtigste Teil jeder BI-Entwicklung werden der Zweck, die Daten und die Endbenutzer des Berichts sein, aber die Richtung der Entwicklung und die Aufteilung der Verantwortlichkeiten herauszufinden, wird immer ein entscheidender Bestandteil für eine erfolgreiche Bereitstellung sein.

Vorstellung des Entwicklungsteams

Damit ein ganzes Team an einem BI-Projekt arbeitet, muss es groß genug sein, um die Kosten zu rechtfertigen. In gewisser Weise ist es einfacher alleine zu arbeiten – ohne jegliche Zeitverzögerung. Kleinere Projekte können erfolgreich mit einem Power BI-Entwickler durchgeführt werden, der direkt mit dem Kunden zusammenarbeitet. Der Single-Developer-Ansatz kann jedoch später zu Komplikationen führen, insbesondere wenn das Projekt Aufgaben erfordert, die über die Fähigkeiten des Entwicklers hinausgehen. Das Engagement von Nicht-Power-BI-Entwicklern im Team wird exponentiell wertvoll, je komplexer das Projekt und die erforderlichen Ergebnisse sind.

Es gibt ein paar Checkpoints, die ganz am Anfang eines jeden Projekts gelöst werden müssen, aber die Einigung über den Zweck, das Datenmodell und die Endbenutzer des Berichts ist immer entscheidend – denn Unklarheiten in diesen Bereichen verursachen die meisten Kopfschmerzen, wenn das Projekt in vollem Gange ist. Dies gilt insbesondere, wenn die Mitglieder Ihres Entwicklungsteams keine Erfahrung mit Power BI haben. Bei der Zusammenarbeit mit Nicht-Power-BI-Entwicklern in einem BI-Projekt ist es jedoch eine der wichtigsten Aufgaben, Verantwortlichkeiten zwischen den Personen (auch implizit) festzulegen. Das liegt daran, dass sich die Größe des Teams mit jedem Projekt ändern kann und auch ohne eine Person, die die Verantwortlichkeiten einer Rolle erfüllt, die Arbeit abgeschlossen werden muss. Daher habe ich festgestellt, dass die Arbeit mit Power BI oft mit unterschiedlichen Rollen einhergeht.

Data Engineer

Der Data Engineer (DE) in Ihrem Projekt ist wahrscheinlich die Person, auf die Sie sich als Power BI-Entwickler am meisten verlassen. Ihre Aufgabe innerhalb eines BI-Projekts wäre es, Daten für die Aufnahme in Power BI verfügbar zu machen, das aus Folgendem besteht:

• Beschaffung von Daten aus der Datenbank oder den Dateien des Kunden
• Transformation der Daten mit verfügbaren ETL-Tools und Best Practices
• Unterstützung bei der Festlegung der geeigneten Methode zur Aufnahme der Daten in Power BI
• Erstellen aller notwendigen Ansichten/Tabellen/gespeicherten Prozeduren
• Data Exploration und Testen

Ein DE wäre erforderlich, um in Datenbanken zu navigieren, aber nicht alle Projekte erfordern eine. Power BI verfügt über Power Query als natives ETL-Tool, und das Verständnis von Datenbanken, SQL und Sternschemamodellierung ist ein Muss für die meisten offenen Power BI-Positionen. Daher gibt es durchaus Fälle, in denen es kein DE gibt, wie z. B. ein Projekt, welches Excel-Dateien verwendet oder wo der BI-Entwickler diese Rolle vollständig übernehmen soll.

Die optimale Zusammenarbeit mit einem DE findet statt, wenn das Datenmodell in Stein gemeißelt ist. Der Data Engineer erstellt alle Fakten- und Dimensionstabellen, die in den Bericht gezogen werden sollen. Dies ist selten der Fall und am besten werden zunächst alle Daten zur Verfügung gestellt und der BI-Entwickler modelliert sie beispielsweise innerhalb von PowerQuery. Funktionalitäten können aus DAX-Berechnungen erstellt werden und sobald sie vom Kunden akzeptiert wurden, sollten alle berechneten Spalten, Dimensionstabellen und Faktentabellen als Best Practice in die Datenbank verschoben werden. Obwohl dieser Ansatz nicht universell auf alle Projekte angewendet werden kann, gewährt er dem BI-Entwickler Autonomie über das Datenmodell, um die Best Practices von Power BI anzupassen und reduziert den Aufwand, Ansichten bei jeder Modelländerung neu zu erstellen und zu aktualisieren – obwohl dies bei Daten nicht der Fall ist, dass sie jederzeit frei verfügbar sind.

Technischer Architekt

Der Technische Architekt (TA) leitet normalerweise die Discovery Sessions, um den Zweck und die Bedürfnisse des Projekts mit dem Kunden zu besprechen. Es wäre Sache des TA, die folgenden Informationen in Bezug auf den Zweck des Power BI-Berichts festzulegen:

 

1. Die technische Machbarkeit der Daten — Gut genug, um verwendet zu werden? 
2. Technische Abhängigkeiten — Gibt es potenzielle Blocker? 
3. Nicht-funktionale Anforderungen — Was ist die erforderliche Aktualisierungszeit? 
4. Security — Native Power BI Security oder eine andere Wahl? 
5. Aktualisieren von Daten — Wie oft und wann? 
6. Distribution — Wie werden Endbenutzer den Bericht sehen? 
7. Power BI Lizenzierung — Gibt es Lizenzbeschränkungen? 
8. Verwendungsszenarien — Wie wird der Bericht genutzt? 
9. Architekturdiagramme

Die Zusammenarbeit mit einem starken TA kann einem weniger erfahrenen Power BI-Entwickler die Struktur geben, um das Projekt autonom voranzutreiben. Technische Architekten beteiligen sich normalerweise nur an den frühen Phasen des Projekts, an der Entdeckung und Planung und es wäre der Business Analyst, der die Verantwortung dafür übernimmt, die Projektanforderungen mit dem Kunden zu besprechen.

Ein TA entlastet den Power BI-Entwickler nicht von seiner gesamten Verantwortung während der Ermittlung. Stattdessen sollte es das Gespräch des Entwicklers mit dem Kunden ermöglichen, sich auf Anforderungen, erwartete visuelle Elemente und UI/UX zuzubewegen. Ohne einen TA besteht das Hauptrisiko darin, dass einige Aspekte der Architektur unklar bleiben.

Projektmanager

Der Projektmanager (PM) ist die Person, die vom Kunden für das gesamte Projekt verantwortlich gemacht wird. Es liegt in ihrer Verantwortung, das Engagement des Teams im Projekt mit dem Kunden auszuhandeln, manchmal die Verträge zu unterzeichnen, Kostenvoranschläge zu erstellen und einen klaren Überblick über die Budgetierung zu geben. Diese Aktionen sollten immer außerhalb des Aufgabenbereichs eines BI-Entwicklers liegen und beinhalten:

1. Backlog Tracking (Jira / DevOps / Monday.com)
2. Zeitschätzungen für den Backlog
3. Backlog anordnen, Meilensteine erstellen
4. Budgetverhandlungen führen
5. Kundenerwartungen managen

Der Hauptbeitrag eines PM ist das Ressourcenmanagement und die Verwaltung der Beziehung zum Kunden. Sie schaffen eine Barriere zwischen dem Entwickler und der Bürokratie des Projekts, was wahrscheinlich eines der besten Dinge an der Arbeit in einem Softwarehaus im Vergleich zur Freiberuflichkeit ist. Die schwierigsten Gespräche, in Bezug auf ein Projekt, werden immer einen Zusammenhang mit der Ressourcenbudgetierung haben und der Power BI-Entwickler sollte mit angemessenen Schätzungen für die Backlog-Elemente beitragen.

Business Analyst

Der Business Analyst (BA) soll geschäftliche Anforderungen in technische übersetzen. Während sich dies von der Aufgabe des TA in dem Sinne unterscheidet, dass ein Technischer Architekt die Architektur festlegt, führt der BA das Projekt weiter, berät den Kunden zu Fortschritten und neuen Anforderungen und trägt die Verantwortung für Folgendes:

1. Technische Dokumentation,
2. Geschäftsanforderungen aufnehmen und als technische Backlog übertragen
3. Mock-ups
4. Das Team mit KPIs/Measures/Kalkulationslogik vertraut machen 
5. Abhängigkeiten des Systems verstehen 
6. Backlog Update
7. Demos für Kunden

Ein Business Analyst sollte der Fachexperte für das Projekt sein und sich am intensivsten mit dem Kunden beschäftigen. Das ideale Szenario ist, wenn der BA über fundierte Kenntnisse der Technologie verfügt und in der Lage ist, die Geschäftsanforderungen vom Kunden an die Entwickler und umgekehrt präzise zu übersetzen – die Arbeit der Entwickler in Demonstrationen und Updates für den Kunden zu präsentieren.

Der Kunde

Auch der Auftraggeber trägt in einem Projekt eine maßgebliche Verantwortung. Es ist Sache des Kunden den Geschäftszweck und die Anforderungen zu definieren. In der Welt von Power BI gehören dazu auch Informationen zur Architektur – die Zusammenarbeit mit dem TA, um festzulegen, welche Technologie/Sicherheit/Lizenzierung verwendet werden sollte, aber auch um Informationen darüber bereitzustellen, wie diese Anforderungen erfüllt werden sollten. Es kann Sache des Teams sein, Blocker zu identifizieren, aber in vielen Fällen ist es Sache des Kunden eine Lösung bereitzustellen.

Darüber hinaus sollte der Kunde die Entwicklungs-/Produktionsumgebung für den Power BI-Service sowie alle in der Produktion zu verwendenden Technologien bereitstellen. Aus diesem Grund ist es wichtig zu klären, was das Ergebnis des Projekts sein soll – sollen Berichte in Produktionsumgebungen innerhalb des Mandanten des Kunden veröffentlicht werden oder erwartet er PBIX-Dateien als Ergebnisse? Gibt es UI/UX-Anforderungen, denen der Bericht folgen sollte wie z. B. die Themen oder das Logo des Kunden?

Für einen Power BI-Entwickler sollte die Zusammenarbeit mit dem Kunden während der Discovery-Phase eines jeden Projekts am intensivsten sein. Alle Anforderungen und die Architektur sollten idealerweise früh festgelegt werden – aber das ist nicht immer der Fall. In Situationen, in denen die Anforderungen nicht genau definiert sind oder im Laufe des Projekts entwickelt werden, könnte die Einführung eines agilen Zyklus mit Sprints und geplanten Updates auch der beste Weg nach vorne sein.

Data Scientist

Der Data Scientist (DS) ist keine herkömmliche Ergänzung eines BI-Teams, da die meisten BI-Projekte keine solche Rolle benötigen. Wenn der Kunde jedoch nach maschinellem Lernen, künstlicher Intelligenz oder anderen hochkomplexen Algorithmen sucht, ist es immer großartig einen DS involviert zu haben. Die Rolle eines DS innerhalb eines BI-Projekts besteht darin Folgendes herauszufinden:

1. Ist Data Science für dieses Projekt geeignet?
2. Sind die Daten gut genug, damit Data Science einen Mehrwert liefern kann?
3. Welche Software/Infrastruktur/Sprachen sind erforderlich, um die Algorithmen auszuführen?
4. Welche Technologie wird benötigt, um Algorithmen zum ETL-Prozess hinzuzufügen?
5. Was sind die Best Practices, um die Ausgabe dieser Algorithmen anzuzeigen?

Es gab definitiv Projekte, bei denen ich als Power BI-Entwickler nach einem geeigneten Algorithmus suchen musste, um Erkenntnisse aus unübersichtlichen Daten zu gewinnen. Die Konsultation eines DS und seine Arbeit bei der Anwendung dieser Algorithmen sind jedoch immer besser als ein Power BI-Entwickler, der versucht das ideale Data-Science-Szenario zu ergründen und es in das Projekt zu implementieren.

Zusammenfassung

In einem Power BI-Projekt gibt es viele verschiedene Rollen, die alle erfüllt werden sollten. Wie bereits erwähnt, gibt es nicht immer genug Personal, um alle beschriebenen Rollen zu besetzen und folglich muss das Team mehr Verantwortung übernehmen, um sicherzustellen, dass das Projekt reibungslos läuft. Das mag zunächst entmutigend sein, aber ich glaube, dass dies auch eine der besten Möglichkeiten ist, sich weiterzuentwickeln – die Übernahme von Verantwortung in echten Projekten bietet die Möglichkeit, verschiedene Aspekte von Power BI aus erster Hand kennenzulernen und sollte nicht gescheut werden. Nachdem ich die Erfahrung gemacht habe, allein und mit einem etablierten Team zu arbeiten - auch wenn ich ein größeres Team bevorzuge, habe ich am meisten davon gelernt, alleine zu arbeiten und dazu gedrängt zu werden, Rollen alleine auszufüllen.