Reporting ist ein Klassiker.
BI (Business Intelligence) und Big Data sind allgegenwärtige Buzz Words.
Zeit sich hier einmal dem Thema zu widmen und das nicht nur für Projektmanager.

Möglichkeiten und Grenzen von Big Data

Ein Beispiel für die Nutzung von Big Data ist der Fall des Autobahn-Snipers: Ein frustrierter LKW-Fahrer schießt während der Fahrt über mehrere Jahre aus seiner Fahrzeugkabine auf andere Fahrzeuge. Überführt wird er letztlich über eine systematische Auswertung von Kennzeichen-Erfassungen auf deutschen Autobahnen. Der Aufwand dafür beträchtlich, sowohl in finanzieller als auch in zeitlicher Hinsicht.
Nicht nur im Zusammenhang mit dem NSA-Skandal wird die Aussagekraft von Kommumikations-Metadaten immer wieder thematisiert. Dimitri Tokmetzis zeigt auf netzpolitik.org, was allein schon Metadaten über uns aussagen.
Oder haben Sie sich schon einmal gewundert, was soziale Netzwerke bereits über uns wissen ohne, dass wir es ihnen gesagt haben (z.B. weil unsere Kontakte uns in ihrem Adressbuch führen oder es ungewöhnliche Schnittmengen in den Kontakten unserer Kontakte gibt).
Big Data per se ist weder gut noch böse. Die Möglichkeiten sind einerseits beeindruckend aber andrerseits auch beängstigend. Wir können uns nicht davor verschließen, aber um so wichtiger ist eine kritische Auseinandersetzung mit dem Thema. Wir haben in der digitalen Welt bereits einen Kontrollverlust über unsere Daten erlitten .(Diese Tage erscheint hierzu das Buch: Das neue Spiel (Amazon Affiliate Link) von Michael Seemann – siehe auch sein Blog ctrl-Verlust.) Wer argumentiert, er hätte nichts zu verbergen, ist naiv, denn aus der Kombination an sich „harmloser“ Daten entsteht mitunter eine kritische Information. Stellen Sie doch einmal einen Kreditantrag oder unterziehen sich der Gesundheitsprüfung für den Abschluss einer Versicherung und Sie sind schneller in Erklärungsnöten, als Sie sich vorstellen können.

Garbage in – Garbage out

Worüber auch Big Data nicht hinwegtäuschen kann sind die elementaren Grundprinzipien der Datenverarbeitung. Nach wie vor gilt Garbage in – Garbage out. Nur in der Flut der Daten vergessen wir manchmal welches Datum tatsächlich ein Information enthält und welches nicht oder überbewerten oder missinterpretieren dessen Informationsgehalt. Wir können unser Reporting und unsere Prozesse beliebig optimieren, aber wenn der Inhalt nicht stimmt…

Nicht Äpfel mit Birnen vergleichen

Natürlich dürfen wir auch nicht Äpfel mit Birnen vergleichen (inhaltlich).
Und zeitliche Synchronität wäre für die Vergleichbarkeit auch schön.

Korrelationen nicht mit Kausalität verwechseln

Bei der Interpretation von Daten dürfen wir selbstverständlich auch nicht Korrelationen mit Kausalitäten verwechseln. Handelt es sich tatsächlich um Ursache-Wirkungsbeziehungen oder möglicherweise nur um 2 Symptome der gleichen Krankheit…

Unwort: Komplexitätsreduktion

Es ist i.d.R. eine irrige Annahme, dass sich Komplexität reduzieren lässt. Eine Reduktion hilft uns vielleicht bei der Erfassung des Überblicks oder in Bezug auf Facetten, sie reduziert aber nicht die Komplexität des realen Systems und verführt uns so zu möglichen Kurzschlüssen und Fehlentscheidungen. Wir sollten uns gerade auch bei der Erstellung von Reports und Auswertungen stets ihrer Unvollkommenheit bewusst sein. Mitunter ist hier weniger mehr: Wenige Zahlen, die wir aber vernünftig einordnen und erklären können, deren Grenzen uns bewusst sind, sind besser als pseudowissenschaftliche Tiefe, deren Grundannahmen auf fragilen Mauern stehen, uns aber aufgrund ihrer vermeintlichen Exaktheit eine falsche Glaubwürdigkeit suggeriert. Allzu oft tappen wir in eine psychologische Falle und glauben viel leichter an die Richtigkeit einer Aussage, weil sie vermeintlich bis auf 2-Nachkommastellen belegt ist.

Compliance Intelligence: Praxisorientierte Lösungsansätze für die risikobewusste Unternehmensführung (Amazon Affilliate Link)
Michael H. Brauer, Klaus-Dieter Steffen, Sven Biermann und Andreas H. Schuler
Schäffer-Poeschel , Stuttgart 2009
ISBN: 978-3791028774

Compliance Intelligence ist keine allgemeine Einführung in das Thema Compliance, sondern eine spezielle Herangehensweise an das Thema (insbesondere auch an die IT-Compliance) unter dem Einsatz von Werkzeugen der Business Intelligence. Es geht also darum, wie mit dem Einsatz von IT Compliance sichergestellt werden kann.

Den ganzen Beitrag lesen…

Mein Kollege Florian hat mich gestern Abend auf die Google Prognose zum European Song Contest aufmerksam gemacht (also noch vor der großen Tamtam in Düsseldorf). Und da stellt sich im Nachhinein doch die Frage nach der Schwarmintelligenz von Google. Nun, es mag beruhigend sein: Es scheint nicht weit her damit. Das tatsächliche Ergebnis liegt weit daneben.

Lena als Googles Nummer 1 wurde 10., Aserbaidschan als Gewinner war bei Google nur auf Platz 7, Italien als Zweitplatzierter war bei Google nur Schlußlicht.

Ist es also nicht weit her mit der Schwarmintelligenz?

Oder hat Google nur den „falschen Schwarm“ befragt/ausgewertet? Wahrscheinlich stammt die größte Zahl der europäischen Google-Nutzer aus Deutschland, was die Überschätzung von Lena erklären könnte. Die Punktevergabe erfolgt nicht repräsentativ. es gibt größere und kleinere Länder. Auch die nachbarschaftlichen Punkteschiebereien dürften die prognostischen Fähigkeiten überfordern. Google, die Datenkrake, hat sicherlich die größtmögliche Datenbasis und dennoch liegt die Prognose weit daneben. Wir wissen um die analytischen Fähigkeiten von Google, schließlich beruht das Google-Geschäftsmodell, die gezielte Platzierung von Werbung, darauf und dennoch hätte der berühmte Affe aus dem Wallstreet Journal (also ein Zufallsgenerator) wahrscheinlich nicht schlechter abgeschnitten. Und wenn Google bei einer Prognose so daneben liegt, wie sieht es dann in den prognostischen Modellen moderner BI-Systeme aus? Besser als beim Champion?

It is important to start the BI process by determining what questions youwant answered instead of trying to implement a solution that can answer any possible question.

Ken Withee, Microsoft Business Intelligence for Dummies, Hoboken NJ, 2010, S. 82

Ken Withee weist nicht nur auf die Tücken in BI-Projekten hin, sondern identifizeirt auch 10 Erfolgsfaktoren:
▶ Getting comfortable with an iterative approach
▶ Securing executive-level sponsorship
▶ Analyzing your current environment
▶ Creating an implementation plan
▶ Picking the right people for the implementation team
▶ Fostering an inclusive environment
▶ Establishing a culture of communication and collaboration
▶ Beginning with the right goals
▶ Minimizing risk
▶ Keeping the big picture in mind

Aus: Ken Withee, Microsoft Business Intelligence for Dummies, Hoboken NJ, 2010, S.  363

Eigentlich bezieht sich Ken Withee auf Microsoft BI-Lösungen, aber seine „10 pitfalls“ gelten auch für andere BI-Lösungen:

▶ Getting drenched with the waterfall methodology
▶ Buying shelf-ware that just sits there
▶ Letting politics destroy your BI project
▶ Disregarding IT
▶ Snubbing power users
▶ Ignoring business processes
▶ Promising extravagant results
▶ Failing to include everyone in the BI solution
▶ Skimping on the BI basics
▶ Misusing consultants

aus Ken Withee, Microsoft Business Intelligence for Dummies, Hoboken NJ, 2010, S. 355

• Nachdem hier schon öfter von Google Wave die Rede war, wollen wir auch über das Ende berichten – hier der Link zu heise online: Google Wave wird eingestellt
• Eine Accenture-Studie kommt zu dem Schluß, dass Cloud-Computing ein Vorreiter in Sachen IT-Sicherheit ist, denn die großen Anbieter hätten vergleichsweise hohe Sicherheitsstandards. Auf besondere juristische Fallstricke, die den Themen Cloud Computing/Offshoring /Outsourcing inne wohnen, geht der Artikel allerdings nicht ein.
• Das CIO-Magazin zitiert eine Rechenzentrums-Studie: Hochverfügbarkeitskonzepte und Disaster-Recovery-Pläne sind unzureichend vorhanden.
• Und noch einmal das CIO-Magazin: Mittelständler versuchen ihre Business Intelligence Projekte ohne Hilfe von außen umzusetzen.

Noch einmal der akutelle RiskNET-Newsletter: Hier wird in gewagter Weise ein Zusammenhang zwischen dem Einsatz der Tabellenkalkulation als einfaches Reporting- und Analysewerkzeug und der Finanzkrise hergestellt. Die Tabellenkalkulation sei aber mit der komplexen Finanzwelt überfordert, heißt es. Diesem Satz würde ich auch noch zustimmen. Die Schlußfolgerung, stattdessen entsprechende „strategische Cockpits“  einzusetzen, verkürzt die erforderliche Diskussion aber dramatisch:

Zum Einen ist sie Ausdruck einer blinden Technologie- und Modellgläubigkeit. Aber gerade die aktuelle Finanzkrise hat uns wieder einmal vorgeführt, wie dürftig selbst die ausgefeiltesten Modelle uns Analysewerkzeuge sind. Und auch der Satz vom Fool with a tool, der immer noch ein Fool ist, wird damit nicht außer Kraft gesetzt. Auch hier hat uns die Finanzkrise wieder gelehrt, wie wichtig es ist zu wissen was man tut und somit auch welchem Modell man folgt und v.a. wo seine Grenzen sind. Je perfekter ein Tool, umso mehr vergessen wir diese Grenzen.

Zum Anderen wird ein weiterer wesentlicher Aspekt vergessen: die eingesetzten Daten und ihre Qualität. Je ausgefeilter unser Werkzeug und je mehr Nachkommastellen es auswirft, umso mehr vertrauen wir ihm und vergessen auch hierbei wieder die Grundlage – nämlich die eingesetzten Daten. Auch hier gilt die alte IT-Weisheit: Garbage in, garbage out. Zugegebenermaßen haben Tabellenkalkulationen in der Regel keine ausgeprägte Validierung der Daten, aber das Problem ist nicht das Tool, sondern die Datenqualität und die Unbedarftheit derjenigen, die sich auf eine schwache Basis verlassen.

Eigentlich ist diese Ur-Regel der IT trivial und selbstverständlich. Die Praxis sieht aber anders aus: Werner Kurzlechner berichtet in einem Artikel für das CIO-Magazin, wie Unternehmen selbst im Bereich Business Intelligence (BI) mit der Datenqualität schludern.
Ich plädiere hier auf: Weniger ist mehr! Es ist meist besser den Datentopf samt Auswertungen kleiner zu lassen, aber dafür die Qualität im Griff zu behalten, denn was nutzen die schönsten Auswertungen, wenn sie nicht valide sind?

Passend zum voranstehenden Beitrag über das Scheitern von Projekten und passend zu der kleinen BI-Serie, die wir jüngst hier hatten, berichtet die Computerwoche über gescheiterte BI-Projekte. Und man staune: es scheitert zuerst an den Menschen und dann an den Daten…

Und hier noch einmal die Links zu den einzelnen Beiträgen der BI-Serie:

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.
In Teil 5 wird resümiert, was ein erfolgreiches BI-Projekt ausmacht.