BI-Anforderungen BI-spezifisch erheben (Update 2019)

Dieser Artikel wurde am 15. März 2017 das erste Mal veröffentlicht. Nun lesen Sie die aktualisierte Fassung aus Juni 2019.

Probleme der Anforderungserhebung

In praktisch jedem BI-Vorhaben geht es um Anforderungen. Denn Anforderungen kommunizieren „was gewollt“ ist von einem Auftraggeber. Bei dieser Kommunikation gibt es im Wesentlichen zwei Problemstellungen: Die erste bezieht sich auf den Aspekt, dass Auftraggeber häufig nicht das bekommen, was sie wirklich benötigen. Dies ist in der berühmten Zeichnung in „Abbildung 1 Was der Kunde wirklich benötigt“ dargestellt:

01_WasDerKundeWirklichBenötigt
Abbildung 1: Was der Kunde wirklich benötigt (Quelle: Unbekannt, mit Ergänzungen von Raphael Branger)

Die zweite Problemstellung hängt mit dem Umstand zusammen, dass sich Anforderungen im Laufe der Zeit ändern können. Daraus kann sich vor allem bei langen Implementationszyklen ergeben, dass zum Zeitpunkt der Anforderungserhebung zwar durchaus Einigkeit herrschte zwischen Auftraggeber und Auftragnehmer, was „gewollt“ ist. Bis die Lösung jedoch in Betrieb geht, haben sich wesentliche Anforderungen bereits wieder verändert:

Anforderungen können sich im Laufe der Zeit verändern
Abbildung 2: Anforderungen können sich im Laufe der Zeit verändern

Natürlich gibt es kein einfaches Patentrezept, um diesen Herausforderungen in der Praxis Herr zu werden. Es sind viele verschiedene Einflussfaktoren, die es zu optimieren gilt. Gerade das Thema „Geschwindigkeit“ ruft nach einer agilen Vorgehensweise – auch und gerade in BI-Projekten. Dazu habe ich bereits verschiedene Artikel geschrieben, unter anderem Schritte zu mehr Agilität in BI-Projekten. In diesem Artikel beschreibe ich unter anderem die Wichtigkeit der Standardisierung. Das gilt auch für die Anforderungserhebung. Leider hilft die klassische Literatur zum Thema Anforderungsmanagement dabei nicht so viel – sie ist entweder zu allgemein oder zu stark auf die Softwareentwicklung fokussiert. So haben wir bei der IT-Logix in den vergangenen rund zehn Jahren ein Framework entwickelt, welches uns und unseren Kunden in BI-Projekten hilft, Anforderungen standardisiert und BI-spezifisch zu erheben. Und weil jedes Kind auch einen Namen braucht, heisst unser Framework IBIREF (IT-Logix Business Intelligence Requirements Engineering Framework)

Übersicht IBIREF

Das IBIREF gliedert sich dabei in drei Bereiche:

Abbildung 3: Bereiche Anforderungsmanagement
Abbildung 3: Bereiche des IBIREF
  • Im Bereich der Anforderungsinhalte geht es um die Frage, zu was für Themen man sich in einem BI-Projekt hinsichtlich Anforderungen überhaupt Gedanken machen sollte. Weiter unten in diesem Artikel gehe ich noch etwas näher darauf ein.
  • Im Bereich des Anforderungsanalyse-Prozesses definiert das Framework mögliche Vorgehensweisen zur Erhebung der Anforderungsinhalte. Unsere bevorzugte Form ist dabei ein iterativ-inkrementelles (aka „agiles“) Verfahren (das Thema agiler Entwicklungsprozess im Kontext von User Stories habe ich hier behandelt) – es ist aber natürlich genau so gut möglich, die Anforderungsinhalte in einem klassischen Wasserfallprozess upfront zu erheben.
  • Abhängig von der Prozessvariante haben wir im Weiteren verschiedene Hilfsmittel geschaffen, um die Anforderungserhebung zu vereinfachen und zu beschleunigen. Dazu gehören verschiedene Checklisten, Formulare und Folien.

Übersicht Anforderungsinhalte

Nun möchte ich einen ersten Einblick in die Strukturierung möglicher Anforderungsinhalte geben:

Folgend ein paar Erläuterungen je Themenbereich:

  1. Um ein BI-Vorhaben richtig einordnen zu können, benötigt es grobe Anforderungen, welche dem Projektumfeld entspringen. Was sind die Projektziele und der Projektumfang? Welche Geschäftsfelder und -prozesse sollen durch die zu erstellende BI-Lösung unterstützt werden? Welche Rahmenbedingungen fachlicher, organisatorischer oder technischer Natur gelten?
  2. Als zweites Themengebiet finden wir Anforderungen an die Organisation und Prozesse. Man erinnere sich: Ein BI-System ist weit mehr als nur Daten verarbeitende Technologie. Im Kern geht es immer um Menschen: Menschen, welche das System nutzen. Menschen, welche das System entwickeln und warten und natürlich braucht es auch Menschen, welche das System betreiben und den Endanwendern Support bei der Benützung anbieten. Die vorhandenen Bedürfnisse müssen analog zu den technischen Anforderungen erhoben und mit den Beteiligten diskutiert werden.
  3. Sofern die zu erstellende BI-Lösung ein Datawarehouse (DWH) umfasst, gilt es die Anforderungen an diese Systemkomponente zu erheben. Die eigentlichen Datenanforderungen teilen wir dabei in zwei Bereiche auf: Die Zielperspektive gibt Auskunft zu den gewünschten Kennzahlen, Dimensionen und damit verbundenen Anforderungen wie z.B. Historisierung oder der Bedarf für Hierarchien. Das ist alles gut und recht – man darf aber auch die Quellenperspektive nicht ausser Acht lassen. Denn viele Anforderungen für das DWH ergeben sich aus der Beschaffenheit der Quelldaten, Stichwort (fehlende) Datenqualität. Zudem gilt es Anforderungen rund um das Thema Metadaten und Sicherheit im Kontext des DWHs abzuklären.
  4. Der Bereich BI-Applikation dreht sich um alle Frontendanforderungen. Das beginnt mit der Definition der benötigten Informationsprodukte (also Reports, Dashboards etc.), deren Zielpublikum, Zweck und Dateninhalte. Im Folgenden kann man sich sodann Gedanken machen, wie die Benutzer zu und in den Informationsprodukten navigieren und welcher Logik die Selektionsmöglichkeiten folgen. Ein zentraler Aspekt stellt die Visualisierung der Daten dar, sei es in Form von Tabellen oder Diagrammen. In diesem Bereich unterstützen weitergehende Standards wie die IBCS den Anforderungserhebungsprozess erheblich (eine Übersicht unserer Blogbeiträge zu IBCS). Im Unterpunkt Funktionalitäten geht es um Anforderungen wie zum Beispiel Exportieren oder Kommentierung. Bei der Verteilung interessiert es, über welche Kanäle die Informationsprodukte den Benutzern zugänglich gemacht werden. Und auch im Bereich der BI-Applikation gilt es Fragen zur benötigten Sicherheit zu stellen.
  5. Das Thema Anforderungsmetadaten geht vielfach unter – es ist aber von Vorteil, es möglichst früh im Projekt zu klären. Es geht dabei darum, welche Art von Zusatzinformationen je Anforderung gesammelt werden soll. Muss man wissen, wer eine Anforderung verantwortet? Wann sie erhoben und wann wieder verändert wurde? Werden – im Rahmen der Anforderungserhebung – auch gleich Akzeptanzkriterien erhoben?
  6. Zu guter Letzt geht es um Anforderungen an die benötigte Dokumentation und an die Ausbildung, welche für die Benutzung und Administration des BI-Systems benötigt wird.

Zusammenfassung

In diesem Artikel habe ich aufgezeigt, dass die Anforderungserhebung allgemein aber gerade auch in BI-Projekten eine Herausforderung darstellt. Mit unserem IBIREF-Framework setzen wir auf ein standardisiertes Vorgehen unter Zuhilfenahme von BI-spezifischen Hilfsmitteln. Dies ermöglicht es unseren Kunden und uns, Anforderungen präziser, vollständiger und in kürzerer Zeit zu erfassen und damit die Qualität der zu erstellenden BI-Lösung zu steigern.

Veranstaltungshinweis: Besuchen Sie den MAKE BI Event am 1. Juli 2019. Ich werde dort u.a. in der Session D1 zum Thema Anforderungserhebung im Kontext der Releaseplanung sprechen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert