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

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.

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.

Die Zusammenfassung meiner beiden Beiträge für das Projektmagazin von Anfang des Jahres gibt es jetzt als Präsentation:

Oder im Original beim Projektmagazin (Abodienst):
Teil 1: Ablauf und Organisation
Teil 2: Das Excel-Toolset

Es klingt fast nach Slapstick oder Comedy, was Sven Rimbach zu berichten weiss. Er hat uns einen Dialog  über abnahmerelevante Fehler gebloggt. Komik und Tragik liegen nahe beieinander. Leider kann ich mir nur zu gut vorstellen, dass dieser Dialog so auch stattgefunden hat. Da werden die Testergebnisse und ggf. auch die Abnahmekriterien und Fehlerklassen solange umgedeutet, bis das herauskommt, was man eh wollte. Süffisant möchte man da anmerken: Wozu noch testen…

Übersetzungsprobleme sind zugegebenermaßen ein Lieblingsthema von mir. Aktuell wieder zu finden in einem Interview im CIO-Magazin mit Klaus Rausch (Ex-HypoVereinsbank-CIO, heute CTO beim Schweizer Dienstleister Avaloq) mit dem passenden Titel:

Wenn Anwender der IT das Programmieren erklären

Siehe auch:
#144 Übersetzungsprobleme: IT und Business
#131 IT versteht Business nicht

Przemysław Bielicki berichtet auf AgilSoftwareDevelopment.com über den Einsatz agiler Methoden in einer vom Wasserfallmodell geprägten Umgebung und insbesondere wie direkte Kommunikation zum Rettungsanker für ein bereits halb-totes Projekt wurde (Englisch).

Agil hin oder her – unabhängig von der Diskussion über agile Vorgehensweisen unterstreicht das Beispiel vor allem eines: Die Bedeutung von Kommunikation in der Projektarbeit.

Meine These: Stimmt die Kommunikation in einem Projekt, dann ist die Vorgehensweise „fast schon egal“…

Nachtrag (22.05.09): Hier die Fortsetzung des Kollegen Bielicki.

Lean Management war eigentlich ein Schlagwort der 90er.

Nun hat Lean Management die Gemeinde der Agilen Softwarentwicklung erreicht:

MacPM: Projekmanagement – Von Scrum to Scrum-ban
Henrik Knisberg: Kanban vs Scrum

Da trifft die eine Modewelle (Agile SW-Entwicklung) auf eine schon wieder etwas eingestaubte Welle (Lean Management, Kanban & Co).

Dabei sollten wir doch alle besser die Kirche im Dorf lassen: Nicht der Titel, sondern was dahinter steckt, ist interessant – gesunder Menschenverstand!!

Nichts kann „leaner“ sein als nicht-hierarische agile Vorgehensweisen. Und agile Vorgehensweisen sind in hohem Maß geprägt von Selbstorganisation. Selbstorganisation ist für mich das Zauberwort.

Dogmatisch sind nur unsere Ettiketten „Lean Management“, „Agiles Projektmanagement“, etc. …

In dem manchmal etwas schmalbrüstigen pmhut weist Lynda Bourne zurecht darauf hin, dass agiles Vorgehen keine eigene Methodologie darstellt, sondern, selbst Projektmanagement (also Organisation oder auch Selbstorganisation) erfordert. Für mich schließt sich hier der Kreis.

Heute erschienen in der neuen Ausgabe des Projektmagazins ist Teil 2 meines Artikels über Testmanagement in IT-Projekten. Während es in Teil 1 noch um die Grundlagen ging, beinhaltet Teil 2 vor allem eine Excel-Vorlage. Kommerzielle Test-Suiten sind als Test-Werkzeug häufig überdimensioniert, da ihr Leistungsumfang die Anforderungen vieler IT-Projekte übersteigt und ihre Nutzung meist nur rudimentär erfolgt. Die vorgestellte einfache Excel-Lösung kann der Anwender leicht an seine spezifischen Fragestellungen anpassen und weiterentwickeln.