Nach Erfahrungen des Autors ist es oftmals schwierig für den Fachbereich, sämtliche Anforderungen an einen Bericht/Datenwürfel/etc. im Vorfeld zu kennen. Neben grundsätzlicher Umsetzungsfehlern kommt es viel häufiger zu Missverständnissen. Die Hauptursache ist meist eine Informationsasymmetrie. Das bedeutet, dass ein unterschiedlicher Wissensstand beider Parteien (IT und Fachbereich) vorliegt und eine Seite öfters auf der anderen Seite Kenntnisse als gegeben ansieht und daher nicht ausformuliert. Fehlerkorrektur im Nachhinein bedeutet Mehraufwand und ist damit eine der „7 Verschwendungen“ im Lean Management und sollte so gut es geht vermieden werden.

Um dieses Problem im Analytics- und Reportingbereich zu vermeiden, kann folgende „DEU“-Vorgangsweise in drei Phasen hilfreich sein:

1. Definieren
   • Mit Requirements Engineering ermitteln, WAS gewünscht wird und WIE es umgesetzt wird.
   • Die Kennzahlendefinition in einem Business Intelligence Competence Center (BICC) abstimmen und dokumentieren
2. Entwerfen
   • Mit Prototyping einen erstem Entwurf erstellen und abstimmen
   • Nochmals im Requirements Engineering nachschärfen
3. Umsetzen
   • Umsetzen der abgestimmten Inhalte
   • Zum Schluss Tests und Abnahme durch den Fachbereich

Folgende Abbildung fasst die drei Phasen zusammen:

Grafik 1: Die drei Phasen des "DEU" (Quelle: Eigene Darstellung)

Definieren

Für größere Projekte ist ein Anforderungsdokument unumgänglich, und daher ein Pflichten- und/oder Lastenheft zu erstellen. Je nach Anlass kann es bei (internen) Projekten interessant sein, beide Dokumente in einem Dokument zusammenzufassen. Es ist wichtig in dieser Phase zu ermitteln, was der Fachbereich im Detail benötigt, um eine optimale Lösungsberatung zu ermöglichen.

Wenn konkret Kennzahlen im Fokus sind, sollte auf jeden Fall ein BI Competence Center vorhanden sein, um diesen bei der entsprechenden Dokumentation zu unterstützen. Besonders in größeren Unternehmen ist eine einheitliche Sicht der Kennzahlen von eminenter Bedeutung. Sollte es nicht möglich sein ein BICC zu unterhalten, so sollten die Kennzahlen auf jeden Fall ausreichend (im Lastenheft) dokumentiert werden. Dabei sollten der Zweck, die Berechnung (Formel), Gliederungsmöglichkeiten, Datenquellen, Interpretation und Klassifikation festgehalten werden.

Folgende Abbildung zeigt eine beispielhafte Definition in tabellarischer Form (ohne Anspruch auf Vollständigkeit):

Grafik 2: Beispielhafte Defintion von Kennzahlen (Quelle: Eigene Darstellung)

Entwerfen

Bevor etwas umgesetzt wird, muss zuerst ein Umsetzungsplan vorhanden sein. Neben des IT-internen Entwurfs des Lösungsdesigns inkl. der Architektur, kann dem Fachbereich ein Prototyp angeboten werden. Dies ist sinnvoll, da hier ein erster Eindruck des Endprodukts entsteht und Missverständnisse frühzeitig offenbart werden. In dieser Phase steht die Funktionalität und nicht die Optik im Fokus.

Wenn der Zugriff auf Daten logisch erfolgt, ist die Erstellung eines Prototypen sehr schnell mit tatsächlichen Daten möglich. Unter logischer Integration wird der Zugriff auf Daten mittels einer „Verknüpfung“ verstanden, so wie eine Verknüpfung auf ein Programm am Desktop eines Computers. Einen kurzen Artikel zur Einführung in ein logisches Datawarehouse finden Sie auf der Homepage von tdwi. Ansonsten sollte das Verhältnis zwischen Aufwand und Nutzen beim Prototyping im Fokus bleiben. Als Praxisbeispiel wird an dieser Stelle auf die Nutzung von MS Excel und Power Pivot verwiesen. Sollte der Fachbereich Datenwürfel von einem Microsoft SQL Server beziehen, kann hier sehr schnell ein ident aussehendes Produkt zur Verifikation der Funktionsweise erstellt werden.

Folgende Grafik veranschaulicht das Praxisbeispiel:

Grafik 3: Beispielhafte Nutzung von Power Pivot zum Protoyping (Quelle: Eigene Darstellung)

Umsetzen

Nach der Abstimmung und gegeben Falls Ergänzung der Anforderungen, kann nun mit der Umsetzung begonnen werden. Sollte eine Vielzahl an Kennzahlen benötigt werden, so bietet sich das SCRUM-Prinzip an. Hierzu werden die Kennzahlen(gruppen) in mehreren Sprints eingeteilt, um eine Abnahme bzw. Nacharbeit parallel zur Weiterentwicklung zu ermöglichen.

Zu guter Letzt sollten alle Kennzahlen verifiziert und komplett abgenommen (und dokumentiert) worden sein. Ohne diese Abnahme ist es nicht ratsam diese produktiv zu setzen.

Schlussbetrachtung

Diese Vorgangsweise stellt eine von vielen Möglichkeient dar, Projekte im Reporting- und Analyticsumfeld umzusetzen. Der Autor hat sehr positive Erfahrungen damit gemacht, naturgemäß wird diese Vorgangsweise nicht für jede Situation passen. Diese oder ähnliche Herangehensweisen helfen beiden Seiten: der IT, weil durch die Zeitersparnis der Nacharbeit die Produktivität erhöht wird und dem Fachbereich, der diese Zeitersparnis dazu nutzen kann, sich auf die Kernaufgabe zu fokussieren -> in der Regel bedeutet das kurz gesagt „Geld verdienen“.

Über den Autor

Markus Rotter, MA ist seit den 2000ern in der IT tätig und hat in dieser Zeit Erfahrungen mit IT-Management, Business Intelligence, Datawarehousing, Datenbanken, Systemadministration, IT-Architekturen, Mitarbeiterführung und Projektmanagement gemacht.