BI-Anforderungen BI-spezifisch erheben

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:

Abbildung 4: Übersicht möglicher Anforderungsinhalte
Abbildung 4: Übersicht möglicher Anforderungsinhalte

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. Welche Geschäftsprozesse sollen durch die zu erstellende BI-Lösung unterstützt werden? Welche Rahmenbedingungen fachlicher, organisatorischer oder technischer Natur gelten? Was sind die Projektziele und der Projektscope?
  2. 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. Zudem gilt es Anforderungen rund um das Thema Metadaten und Sicherheit im Kontext des DWHs abzuklären.
  3. 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.
  4. 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?
  5. 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 mein Team und mich an unserem Workshop an der TDWI Europe Konferenz Ende Juni 2017 in München. Das Thema lautet „Übung macht den Meister: Anforderungen an ein Dashboard praktisch erheben“. Dabei werden wir das IBIREF-Framework (mit Fokus auf den Teil BI-Applikation) praktisch in Form von Rollenspielen nutzen und anwenden lernen. Melden Sie sich jetzt an – die Anzahl Plätze für diesen Workshop ist beschränkt!

 

Schreibe einen Kommentar

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