Der kritische Ton in den vorangegangen Beiträgen soll keineswegs die Sinnhaftigkeit von BI-Lösungen in Frage stellen, aber auch hier gilt es das richtige Augenmaß zu finden.

BI-Projekte können erst dann als erfolgreich gewertet werden, wenn sie tatsächlich zu den Unternehmenszielen beitragen. Ist dies nicht der Fall, ist es egal ob es am falschen Umgang mit den Ergebnissen, den falschen Fragestellungen/Anforderungen, der Datengrundlage oder der Programmierung lag.

Wenn Sie weitere Informationen zum Thema BI suchen, empfehle ich Ihnen einige aktuelle Beiträge der Computerwoche:

• Sascha Alexander versucht in seinem Artikel einige Empfehlungen für den Start von Business Intelligence Projekten zu geben, damit Ihnen das nicht passiert.
• Heinrich Vaske beschreibt: So managen Sie BI-Projekte.
• Christa Manta schildert, dass CIOs beim Thema BI häufig in der Falle sitzen.

In diesem Sinne wünsche ich Ihren BI-Projekten zum Abschluss dieser kleinen Reihe:

Gutes Gelingen!

================
BI auf schlossBlog:
================

In Teil 1 der Reihe finden sie eine Definition von BI und grundlegende Anforderungen von Kennzahlsystemen.
In Teil 2 wurde das Anforderungsdilemma in BI-Projekten beschrieben.
In Teil 3 rückt das Augenmerk auf die Unternehmensleitung und deren Umgang mit BI.
Teil 4 beschäftigt sich mit den elementaren Themen Datenqualität und Datenbereitstellung.
Im vorliegenden fünften Teil wird resümiert, was ein erfolgreiches BI-Projekt ausmacht.

Seit Ur-Zeiten der IT gilt das alte Grundprinzip: Garbage in – garbage out.

Was nützen die besten Auswertungen und Bericht, wenn die Datengrundlage nichts wert ist. Und manches ERP-System oder andere Applikation strotzt nur vor Datenleichen. In fast allen Migrationsprojekten sind deshalb vor der eigentlichen Migration aufwändige Bereinigungen und Analysen erforderlich. In den Auswertungen hat bis dahin die schlechte Qualität offenbar nicht gestört…

Datenqualität ist eine Facette, die nächste Frage ist, ob nicht Äpfel mit Birnen verglichen werden. Gerade wenn unterschiedliche Vorsysteme einbezogen werden, ist beim besten Willen nicht selbstverständlich, dass alle Vorsysteme unter einer Größe  X auch das Gleiche verstehen, das sie gleiche Berichtszyklen haben, etc.  Die Tücke liegt im Detail. Schnell läuft man Gefahr sich in einer Scheingenauigkeit zu verlieren, die nichts anderes wiedergibt als die mittlere Krankenhaustemperatur. (Das Messen der Körpertemperatur eines Patienten mag für den Arzt ja aufschlussreich sein, aber der Durchschnittswert aller Patienten in einer Klinik ist nur mehr eine äußerst fragwürdige Größe.)

Nachdem BI die Unternehmensziele im Visier hat, geniessen BI-Projekte meist auch eine überproportionale Management Attention. Mitunter tappt dann auch die Unternehmensleitung selbst in das Anforderungsdilemma. Interessant ist, was mit den Ergebnissen aus den BI-Systemen passiert:

Dienen sie als Entscheidungsgrundlage?

Oder lediglich der Rechtfertigung längst getroffener Entscheidungen?

Werden Sie überhaupt genutzt?

In einem Unternehmensbereich eines Großkonzerns wurden aufwändig die FuE-Kosten ermittelt. Es wurde eigens ein zusätzliches Kontierungstool mit SAP-Anbindung eingeführt. Die Berichterstattung ging an drei Köpfe in der Bereichsleitung. In einem Gespräch Jahre später bestätigte mir der Assistent einer der drei Köpfe, dass zwei der drei Adressaten nie auch nur einen der Berichte angeschaut hätten. Der Dritte nahm die Berichte um seine eigenen Hochrechnungen in Excel zu plausibilisieren. Ausschlaggebend war aber Excel und nicht die Kostenauswertung aus SAP.

BI-Projekte stecken häufig in einem Anforderungsdilemma.

Denn sie wissen nicht, was sie wollen…

Statt klar auf die Ziele und Vorgaben zu fokussieren verlieren sich viele Anforderer in der Fragestellung, welche Informationen könnten vielleicht noch nützlich sein und welche Berichte gab es in der Vergangenheit. In einem großen Datawarehouse-Projekt, dass das Reporting über verschiedene ERP-Systeme und Unternehmensbereiche zusammenführen sollte, führte dies dazu, dass die Spezifikation des neuen Reportings quasi aus den Spezifikationen aller Altsysteme plus zusätzlicher, neuer Anforderungen bestand. Ein Monster war geboren, aber der eigentliche Projektauftrag und die Vorgabe Cross-Selling-Potentiale zu schöpfen wurden schier erdrückt.

… aber jeder kann mitreden…

Das Fatale an Reporting-Themen ist, das fast jeder meint mitreden zu können bzw. zu müssen. Und dies gilt leider nicht nur für die Inhalte, sondern auch für das Layout. Welche Hintergrundfarbe und wohin mit dem Button… Die Diskussionspunkte sind unzählig und wer die Evolutionsstufen eines einzelnen Berichts verfolgt, wird mit Entsetzen feststellen, welche teilweise auch unsinnigen Anforderungen eingebaut, umgebaut und manchmal auch wieder ausgebaut werden.

… und sie sind unersättlich.

Die letzte wesentliche Erkenntnis für die Anforderungen an BI-Systeme (oder Reporting-Systeme im allgemeinen) ist, dass diese nie abgeschlossen sind. Informationen erwecken neue Informationsbedürfnisse. Ganz gleich, ob diese sinnvoll sind oder nicht. Change Requests sind vorprogrammiert. Eine sinnvolle Vorgehensweise ist daher, den eigentlichen Projektscope zunächst relativ eng und eindeutig zu gestalten und möglichst schnell auf ein CR-Verfahren in dem den einzelnen Anforderungen Preisschilder umgehängt werden  umzusteigen. Es ist immer wieder erstaunlich wie sehr so ein Preisetikett Dringlichkeit und Wichtigkeit von Anforderungen relativiert.

In fünf Beiträgen wird hier das Thema Business Intelligence (kurz: BI) aufgegriffen. Unter diesem Modebegriff versammeln sich…

…Verfahren und Prozesse zur systematischen Analyse (Sammlung, Auswertung und Darstellung) von Daten in elektronischer Form. Ziel ist die Gewinnung von Erkenntnissen, die in Hinsicht auf die Unternehmensziele bessere operative oder strategische Entscheidungen ermöglichen. Dies geschieht mit Hilfe analytischer Konzepte und IT-Systeme…

Also salopp zusammengefasst: Hinter BI verbergen sich Kennzahlensysteme und Reporting.

Hans-Ulrich Küpper (Amazon Affiliate Link) beschreibt welchen Anforderungen Kennzahlensysteme grundsätzlich genügen sollten:

(1) Kennzahlen sollten einfach und klar sein.
(2) Kennzahlensysteme sollten nicht zu komplex sein (Küpper empfiehlt daher eine hierarische Struktur).
(3) Kennzahlen haben eine Indikatorfunktion.
(4) Kennzahlen und Kennzahlensysteme sollten partizipativ hergeleitet werden.

ad 1: Mit der Einfacheit und Klarheit ist es in der Praxis häufig schnell vorbei. Wer einmal zwei Vertriebskaufleute im Anlagenbau über die vermeintlich eindeutige Größe Umsatz hat streiten hören, der weiß was ich meine… Wann wird denn ein Auftragseingang zum Umsatz? Wie wird mit Skonti, Rabatten und Gutschriften umgegangen? Der Phantasie in solchen Diskussionen sind leider keine Grenzen gesetzt.

ad 2: Warum sollten die Systeme nicht zu komplex sein? Nun, weil Personen sich nur über eine begrenzte Zahl von Zielen steuern lassen. Mit zunehmender Komplexität weicht die Klarheit dem Information Overkill.

ad 3: Klar – Kennzahlen sollen etwas Aussagen, sonst könnten wie sie uns sparen…

ad 4: Die partizipative Herleitung hat vor allem mit den Themen Akzeptanz und Verständnis zu tun. Das System ist nicht aufoktruiert und entspricht den eigenen fachlichen Anforderungen. Die Mitarbeiter, die mit dem Reporting arbeiten, wissen darüber hinaus, was sich dahinter verbirgt, was gemessen oder hochgerechnet wird, und sind daher auch in der Lage die Ergebnisse zu interpretieren.