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) 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 hierarchische 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.

Josh Nankivel bringt es auf PM-Student auf den Punkt:

Project Managers Focus Too Much On Tools.

Tools Don’t Manage Projects. You Do.

In unsere Microblogging-Diskussion hatte ich Google Waves schon erwähnt. Bei //SEIBERT/MEDIA gibt Doreen Düring einen interessanten Ausblick auf Google Waves und stellt sogar die Frage, ob wir damit eine neue Stufe in der Unternehmenskommunikation erreichen werden.

Eine 80minütige Präsentation zu Google Waves gibt es auf YouTube:

Agile Softwareentwicklung hat auch bei Microsoft Einzug erhalten. Ein Bericht in Spiegel online hat zahlreiche Reaktionen in den einschlägigen PM- und Sofftwareentwicklungs-Blogs gefunden, z.B. bei Jens Coldewey, Danny Quick und last but not least Andreas Heilwagen.

Über Garr Reynolds Presentation Zen habe ich hier bereits berichtet. Stephan List hat jetzt dankenswerterweise das Buch noch einmal als Mindmap zusammengefasst. Die Zusammenfassung ist zum Einstieg etwas weniger geeignet, aber als Reminder wertvoll für alle, die das Buch gelesen haben. Zum Einstieg empfiehlt sich entweder das Buch selber oder Garr Reynolds Video auf Youtoube.

Hier war schon von einer Rückbesinnung auf das Wesentliche im Projektmanagement im Sinne eines Simplify your projects die Rede. Ähnlich fällt mitunter das Stichwort von einem Lean Project Management, was man gerne mit „schlankem Projektmanagement“ übersetzen möchte. Aber klassisches Lean Management hat einige Konotationen. In der Zweiten Revolution in der Automobilindustrie (Amazon Affiliate Link) von Womack, Jones und Roos werden nämlich 5 Grundsätze eingefordert:

1. Den Wert aus Sicht des Kunden definieren
2. Den Wertstrom identifizieren
3. Das Fluss-Prinzip umsetzen
4. Das Pull-Prinzip einführen
5. Perfektion anstreben

Das mag ja alles irgendwie richtig sein, trifft aber nicht den Kern dessen, was ich unter einem schlanken Projektmangement verstehen möchte. Ich würde vor allem auf zwei Aspekte fokussieren:

1. Transparenz
2. Kommunikation

Transparenz schließt nicht nur die Vorgehensweise im Projekt und die Projektergebnisse mit ein, sondern zuallererst den Projektauftrag.
Innerhalb des Projekts und zwischen Projekt und Stakeholdern spielt die Kommunikation die entscheidende Rolle, um die erforderliche Transparenz zu schaffen.
Kommunikation spielt aber darüber hinaus auch im sozialen System „Projekt“ einen wesentlichen Part. Deshalb kann beispielsweise Dokumentation Kommunikation nicht ersetzen. Dokumentation sorgt zwar ebenfalls für Transparenz, unterstützt aber nur nachrangig die Interaktion der Projektbeteiligten.

Auf diese zwei Aspekte zu fokussieren heißt natürlich nicht, alles, was im Projektmanagement an Werkzeugen und Theorien entstanden ist, einfach über Bord zu werfen. Vor dem Methoden-Overkill ist der Einsatz einer Methode aber immer zu hinterfragen:

Inwieweit trägt eine Maßnahme, Methode, Theorie oder Tool im Projekt zu Transparenz und Kommunikation bei?
Und natürlich: Inwieweit trägt sie zum Projektziel bei?