Requirements Engineering (RE) in Business Intelligence (BI) Reports

Zusammenfassung

Requirements Engineering (RE) beschränkt sich nicht auf die Entwicklungsprojekte. Requirements Engineering ist eine Disziplin, die immer angewendet werden kann, wenn es gilt, Anforderungen zu erheben. In unserem heutigen Beispiel sind es Anforderungen an einen Business Intelligence (BI) Report. Ich erläutere ihnen, wie ein minimales Requirements Engineering in der Zusammenarbeit zwischen Business und IT strukturiert sein muss.

Was sind eigentlich BI Reports?

BI definiere ich als Veredelung von rohen Informationen, eine „offiziellere“ Definition siehe Wikipedia. Wegen der fortschreitenden Digitalisierung des Geschäftsalltages werden immer mehr Daten über den Geschäftsgang erhoben. Klassische, weil eingängige Informationen werten beispielsweise aus, in welchem Marktsegment wie viele Produkte abgesetzt werden konnten. Solche Informationen – so meine Erfahrungen – interessieren immer zuerst und (fast) alle.

Beispiel eines BI Reports über historische Gewinne eines Handelsprodukts

BI bildet aber mehr ab als die reine Vertriebssicht. BI ist denn auch, Informationen sichtbar, lesbar zu machen, die normalerweise nicht lesbar sind. Dies ist insbesondere bei der Innenbetrachtung eines Unternehmens vorteilhaft. Es interessiert nicht nur, wie viele Kundenanfragen ein Supportteam abwickeln kann. Es könnte auch interessieren, welche Kundenanfragen welche Produkte betreffen. Dadurch könnte man Trend vorzeichnen, welches Produkt beispielsweise viele negative Kundenanfragen verursache – einen entsprechenden BI Report aber vorausgesetzt.

Und der BI-Report?

Der BI-Report letztlich ist die Aufbereitung, zweckmässige Visualisierung und Darstellung von Informationen, die in einem BI-System hinterlegt sind. Der BI-Report veredelt, verknüpft und bringt Informationen zusammen.

Beispiel von Verknüpfungen von unterschiedlichen Informationen in einem BI System

Also wieso braucht’s jetzt RE in BI?

Wir haben derzeit die Situation, dass Unternehmen so viel Daten wie noch nie sammeln, diese aber intern nicht sinnvoll, das heisst mit Mehrwert für das Unternehmen nutzen können. Daten werden aggregiert, transferiert, transformiert – und wie auch immer. Sie existieren, sie sind. Aber sie bieten keinen Mehrwert. Oder:

Daten, die ruhen – das ist wie Geld, das nicht arbeitet. Es ist eine Verschwendung.

Und was wären die RE Phasen?

Gemäss IREB beinhaltet RE folgende Disziplinen:

• Zieldefinition / Abgrenzung
• Erhebung von Anforderungen
• Spezifikation von Anforderungen
• Prüfen von Anforderungen

In der BI-Welt empfehle ich gemäss meinen Erfahrungen, folgende RE Disziplinen mit folgenden Aktivitäten und Lieferergebnissen zu verknüpfen.

Implementierung

Je nach dem, wie ein Unternehmen organisiert, implementieren unterschiedliche Rollen solche Reports. Ich habe Organisationen erlebt, wo beispielsweise wiederkehrende Reports, also meistens finanzielle oder für die Statistik relevante Reports von einem zentralen Kompetenzzentrum umgesetzt werden. Und einmalige Reports, also spontane Auswertungen, von den Fachabteilungen direkt entwickelt werden. Bei einem anderen Unternehmen beobachtete ich, dass alle BI Reports ausschliesslich von einem zentralen Kompetenzzentrum erbracht werden.

Aufjedenfall kann dank einer abgestimmten Anforderungsbeschreibung der notwendige Report rascher und mit mehr Qualität umgesetzt werden. Bei komplexen Reports ist ein seriöses Requirements Engineering unerlässlich, schliesslich gilt es die Ressourcen aller Beteiligten zu schonen. Ich selber durfte Projektsituationen erfahren, wo Unsummen in Reports investiert wurden, weil man zu Beginn auf ein Requirements Engineering verzichtete – wegen der Annahme, diese ein bis zwei Reports können dann ohne Probleme noch „am Schluss“ erledigt werden. Oder im normalen Geschäftsalltag einer normalen Abteilung musste der Abteilungsleiter Monate warten, weil die Umsetzung eines Reports unterschätzt wurde – weil eben die Anforderungen zuerst nicht erhoben, spezifiziert und abgestimmt worden sind. In solchen Situationen ist es für den Kunden recht frustrierend, Wochen, ja gar Monate für einen vermeintlichen „simplen“ Report zu warten, der aber fürs Tagesgeschäft unerlässlich ist.

Was macht eigentlich das Testing?

Ja, berechtigte Frage. Ein BI-Report muss auch getestet werden. Aber dies „bloss“ auf der Stufe eines Abnahmetests. Ein BI-Report, der auf einer Standardlösung (SAP, Oracle, etc.) basiert, verändert weder produktive Daten noch Systeme. Bei einer risikoorientierten Teststrategie wäre es vermessen, für jeden einzelnen BI-Report alle Teststufen durchzulaufen. Wohl aber bedingt eine Änderung der Datengrundlage, eine Änderung der produktiven Systeme ein Regressionstesten aller davon betroffener BI Reports.

Wie weiter?

Meine Erfahrung zeugt:

Gehen sie auch RE-mässig vor, wenn sie meinen, es braucht kein Requirements Engineering.

Die Erstellung solcher Reports ist ein heimlicher Kostentreiber. Immer mehr Datengrundlagen führen nämlich zu immer komplexeren Reports. Immer komplexere Reports wiederum erfordern immer mehr Abstimmung und Rücksprache. Gerade hier kann Requirements Engineering helfen, ein abgestimmtes, abgesprochenes und inhaltlich korrektes Lieferobjekt zu produzieren.

Praxisbeispiel in ihrem Unternehmen

Sie selber haben einen internen Dienstleister, der für sie ihre Reports entwickelt. Aber sie sind mit dessen Leistung unzufrieden? Dann helfen wir ihnen gerne, ihre Bedürfnisse RE-mässig aufzunehmen und ihrem BI-Team zu vermitteln. Kontaktieren sie uns einfach (https://www.swissq.it/firma/kontakt/). Denn sie wissen, was sie tun. Lassen sie es auch andere wissen. Wir sind ihre Übersetzer.