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?

Die Computerwoche gibt einen Überblick der gängigen CRM-Lösungen auf dem Markt. Beschrieben werden:

Pisa Sales GmbH – Pisa Sales
SAP AG – SAP CRM
CAS Software AG – CAS genesisWorld
Sage Software GmbH – Sage CRM
Oracle – Siebel CRM
Cursor Software – Cursor CRM
Salesforce.com – Salesforce CRM
Microsoft – Microsoft Dynamics CRM
Update Software – Update.seven

Lynda Bourne setzt sich mit der Neuauflage von PRINCE2 auseinander und zieht einen Vergleich zum PMBOK des PMI:

PRINCE2 sees the project starting much earlier and continuing through to the realisation of value by the organisation. This is quite likely correct from the perspective of an organisation initiating and managing internal projects.

There is very little difference in terms of the processes used to run a project between PRINCE2 and the PMBOK. What is different is PRINCE2 is totally focused on managing internal projects with organisational managers having a direct say in the management of the overall process and it provides an effective methodology for this circumstance. The PMBOK® Guide is a pure PM standard and has a more generic set of processes that can be adapted to a much wider range of circumstances and used in any situation (eg, a traditional project where the client contracts the project delivery organisation).