Business Intelligence zweiter Ordnung lebe hoch, aber …

Ich habe des Öfteren darüber referiert, dass BI aus meiner Sicht zu oft als Selbstzweck betrachtet wird. Hypewörter, wie “data-driven” oder “Big Data” verstärken diesen Effekt. BI wird in Unternehmen kontextlos betrachtet, was letztendlich dazu führt, dass BI Projekte zu technokratisch und technologiefokussiert aufgesetzt werden.

Der eigentliche Sinn von BI wird damit aber nicht tangiert. Um das näher zu erläutern, möchte ich erst einmal BI aus meiner Sicht definieren und daraus den Sinn von BI ableiten, bevor ich den am Anfang geschilderten Fakt an einem speziellen Beispiel darauf reflektiere.

Was ist eigentlich BI?

Unter Business Intelligence (ab sofort mit BI abgekürzt) verstehe ich das Beschaffen und Verwalten von Daten, um aus diesen Informationen zu generieren, die wiederum zum Bewerten und Untermauern von Entscheidungen in Unternehmen dienen.

BI ist also niemals kontextlos, sondern steht stets im Kontext der jeweiligen zu treffenden Entscheidungen in den jeweiligen Business Domänen (Einkauf, Vertrieb, Logistik, …).

Unter BI-Tool verstehe ich ein Sammelsurium verschiedenen technischer Funktionalitäten. Zum einen ist an dieser Stelle eine Datenbank zu nennen, mit einem für die jeweilige Anwendung, in diesem Fall “BI Anforderungs- und Releasemanagement”, adäquates Datenmodell. Des Weiteren spielt hier aber auch ein Frontend (Userinterface) eine Rolle, welches zur Eingabe von Daten dient, aber auch zur Ausgabe von Daten, die aus erkenntnistheoretischen Gesichtspunkten so dargestellt werden sollten, dass die Menschen daraus effizient und effektiv Informationen generieren können.

Was ist daraus abgeleitet der Sinn von BI?

Aus der oben gegebenen Definition leitet sich relativ leicht der Sinn von BI ab. Unternehmen benötigen BI, um ihr Business besser zu machen. Das Wort “besser” muss pro Unternehmen dediziert definiert werden. An dieser Stelle kommt für mich der Glaube ins Spiel. Manager müssen in bestimmten Domänen ihres Business, sei es nun Einkauf, Vertrieb, Logistik etc., einen Glauben darin entwickeln in wie ihnen Daten helfen können, um daraus belastbarere Informationen ableiten zu können, die wiederum zu einer belastbareren Entscheidungsgrundlage führen. Ich rede hier vom Glauben, da zum Zeitpunkt der Entscheidung, die auf diesen Informationen beruhen, der Manager nicht objektiv bemessen kann, ob die Entscheidung richtig ist. Diese Bewertung funktioniert stets in der Zukunft. Jede Entscheidung ist als eine Wette in die Zukunft.

BI darf also niemals kontextlos, wie in vielen Unternehmen der Fall, betrachtet werden, sondern stets im Zusammenhang mit der jeweiligen Businessdomäne und den Daten, die zu besseren Entscheidungen führen.

BI zweiter Ordnung

BI zweiter Ordnung

Diesen Sinn im Kopf habend, kommt man natürlich schnell dazu, BI auch für BI anzuwenden. BI zweiter Ordnung quasi. Genauer geht es mir darum, BI in Unternehmen für das BI Anforderungs- und Releasemanagement einzusetzen. Was meine ich damit genau?

Auf Basis dieser BI Anwendung kann man Anforderungen seitens der Fachbereiche besser verstehen. Mit diesem Tool kann man quasi auch Anforderungen, die in den Köpfen der Fachbereichsmitarbeiter unbewusst schlummern und nicht wirklich artikulierbar sind, heraus kitzeln, in dem fragenbasiert die Anforderungen erfragt und strukturiert dokumentiert werden.

  1. Müssen in diesem Prozessschritt Entscheidungen getroffen werden, die auf Analyse von Daten beruhen (Ich kann mir keine Situation denken, wo das nicht der Fall)? Wenn ja, beantworten der restlichen Fragen.
  2. Welche Merkmale/ Dimensionen benötigen Sie für die Analyse?
  3. Welche Kennzahlen sollen ausgewertet werden?
  4. Wie soll die Analyse dargestellt werden?
  5. Wer sind die Empfänger der Analyse?
  6. Wie aktuell müssen die Daten für die Analyse sein?
  7. Werden historische Daten benötigt? Wenn ja, bis wie lange in die Vergangenheit zurück sollten die Daten mindestens vorliegen?
  8. Muss die Analyse automatisch generiert und versendet werden?
  9. Wie oft und wann wird die Analyse benötigt?
  10. Benötigen Sie analytische Funktionalitäten, wie beispielsweise Data Mining?
  11. Welche Reportingszenarien kommen zum Einsatz (today-is-yesterday, yesterday-is-today, today-and-yesterday, today-or-yesterday)?

Hat man diese Anforderungen beiderseitig verstanden, Fachbereich und IT, und strukturiert dokumentiert, hat man eine Basis geschaffen, nachhaltige Entscheidungen zu fällen. In der IT entsteht so also die Möglichkeit haben, Anforderungen, die seitens des Business an BI gestellt werden, beispielsweise über Dashboards und Reports zu bewerten. Beispiele für konkrete Fragestellungen könnten sein.

  1. Bis zu welchem Grad können wir die Anforderung mit der derzeitigen Lösung bereits abdecken?
  2. Welche zusätzlichen Daten (Kennzahlen, Merkmale, …) benötige ich, um die Anforderung umzusetzen?
  3. Kann ich einen bestehenden Cube mit diesen Daten erweitern? Wenn ja, muss dafür die Berechtigungsteuerung auf diesem Cube angepasst werden?
  4. Existiert die angeforderte Kennzahl, die der Fachbereich anfordert bereits in meinem Datenmodell?
  5. Falls der Name dieser Kennzahl stimmt, ist auch die Semantik dahinter die gleiche? Wird die Kennzahl gleich berechnet?

Mein derzeitiges Feedback auf diese Anforderung

Diese Diskussion habe ich in verschiedenen BI-Foren in Xing platziert und habe für mich ernüchternde Antworten bekommen. Einen Geschmack davon können Sie beispielsweise hier gewinnen. Ich habe den Eindruck gewinnen müssen, dass meine Anforderung, BI für das Anforderungs- und Releasemanmagement im BI zu verwenden (übrigens macht der Einsatz von BI für das grundlegende Anforderungs- und Releasemanagement, nicht nur im BI, Sinn), nicht verstanden wurde. Das ist für mich aber auch nicht so verwunderlich, wenn ich mir das grundsätzliche Verständnis von BI in Unternehmen, wie am Anfang meines Posts geschildert, anschaue. Es bestätigt diese Sichtweise.

Wenn ich also für mein Business, beispielsweise Einkauf, Vertrieb, Unternehmensplanung und -steuerung BI einsetze, warum dann nicht für ein BI Anforderungs- und Releasemanagement? In allen Fällen geht es darum Entscheidungen auf Basis von Informationen zu treffen, die ich mir mit Hilfe von BI-Tools generieren kann.

Und noch etwas bleibt hinzuzufügen, was sogar für ein BI-Standardtool spricht. Ich glaube nicht, dass sich ein BI Anforderungs- und Releasemanagement branchen- und industrieübergreifend so arg unterscheidet. Auf keinen Fall werden die Anforderungen an solch ein Tool spezifischer sein, als sie es für die jeweiligen Businessdomänen sind. Und in diesen Bereichen sind wir sehr wohl bereit über den Einsatz von BI-Standardtools zu sprechen.

Ich bin der festen Überzeugung, hat man erst einmal den eigentlichen Sinn und Zweck von BI für den Einsatz in Unternehmen verstanden, kommt man nicht umhin, BI auch für das Anforderungs- und Releasemanagement für BI einzusetzen.

Dann möchte ich also den Titel dieses Posts finalisieren.

BI zweiter Ordnung lebe hoch. Dafür müssen wir aber erst einmal BI erster Ordnung aus dem Schlaf holen.

1 Star2 Stars3 Stars4 Stars5 Stars (2 Bewertung(en), Durchschnitt: 3.00 von 5)
Loading ... Loading ...
This entry was posted in Management und Leadership and tagged , , , . Bookmark the permalink.

6 Responses to Business Intelligence zweiter Ordnung lebe hoch, aber …

  1. Hallo Herr Dethloff,

    natürlich bin ich Ihnen direkt von XING hierher gefolgt und habe Ihren Beitrag verschlungen. In vielen Punkten gebe ich Ihnen recht. Vor allem hier: “dass BI Projekte zu technokratisch und technologiefokussiert aufgesetzt werden”. Man kann sogar sagen, dass es durch das Marketing in der Branche komplett Tool-getrieben ist.

    Da die Einführung ener BI Lösung weniger als Projekt, sondern als komplexer Prozess mit fortlaufender Entwicklung zu betrachten ist, eignen sich herkömmliche lineare Modelle hier nur sehr bedingt.

    Ob wir BI als Basis für BI verwenden können, wäre zu prüfen. Denn die Unterschiede von Projekt zu Projekt, Branche zu Branche, Unternehmen zu Unternehmen sind sehr groß.

    Es käme auf einen Versuch an. Sollen wir diesen starten? Wenn Sie ja sagen, würde ich prüfen, ob ich die Ressourcen bei uns im Haus bekomme.

    Grüße aus dem Süden

    Alexander Beck

  2. Ulrik Frueh says:

    Hallo,
    Meine Bachelorarbeit trug das Thema “Competitive Intelligence in mittelständischen Unternehmen”.

    Mein Verständnis von BI ist folgendes: BI ist das analysieren von vorhandenen Daten des Data Warehouse eines Unternehmens. Natürlich werden damit auch die Signale am Markt inkludiert. Was man hier aber anmerken muss, dass meist die quantitative Datenbasis zu gering ist um eine qualitative Trendprognose abzugeben. Hier kommt Competitive Intelligence ins Spiel. CI beschreibt das sammeln und analysieren von externen Daten (Datenbanken, Magazine, Blogs, etc.) sowie das analysieren der Trendsignale. Signale sind noch nicht gleich qualitative Informationen, ein Signal muss anschließend erst auf dessen Informationsgehalt/grad bewertet werden.

    Kurz noch was zu BI:
    BI können meiner Ansicht nach nur Unternehmen nutzen, die Stammdaten-technisch top aufgestellt sind. Da dies aufgrund von Firmenübernahmen, etc. meist nicht der Fall ist befindet sich meiner Ansicht nach die Disziplin BI noch in der Entstehungsphase.

    lg Ulrik Frueh

  3. Hallo Herr Frueh,

    Warum müssen die Daten, auf deren Basis man Entscheidungen trifft, unbedingt aus einem DWH kommen? Ist es nicht egal, woher die Daten kommen? Hauptsache ist doch, dass man sich bewusst darüber ist, welche Daten man benötigt, oder?

    Auch beim Thema Qualität der Stammdaten muss “top” abhängig der fachlichen Anforderungen definiert werden. Im Risikomanagement im Bankenwesen kann die Qualität nicht hoch genug sein, oder auch grundsätzlich im externen Rechnungswesen. Beim Kampagnenmanagement beispielsweise, wo man Kunden selektieren möchte, kann man u.U. auch mit weniger Qualität am Kundenstamm leben.

    Grundsätzlich muss ich stets thematisieren, warum man BI in bestimmten Bereichen einsetzen möchte. Daraus und nur daraus ergeben sich dann Anforderungen an Architektur, einzusetzende Tools, erforderliche Datenqualität und Datentiefe und -breite.

    BG, Conny Dethloff

  4. Hallo Herr Früh,

    noch ein Nachtrag zu Ihrem Zitat

    Was man hier aber anmerken muss, dass meist die quantitative Datenbasis zu gering ist um eine qualitative Trendprognose abzugeben.

    Prognosen sind stets eine Wette in die Zukunft. Diese Wette ist besser, je besser meine Informationsbasis dafür ist. Hier mache ich aber einen Unterschied zwischen Daten und Information. Die Daten sind in ausreichendem Maße vorhanden, nur wir verstehen es derzeit noch nicht, daraus für Entscheidungen ausreichend belastbare Information zu generieren. Details können Sie gerne hier in meinem Post Der Datenirrglaube – Wir leben (noch) nicht in einer Informationsgesellschaft nachlesen.

    BG, Conny Dethloff

  5. Pingback: Strobel

Leave a Reply

Your email address will not be published. Required fields are marked *