Das BI-Projekt – ein Marathon
8 Tipps für eine erfolgreiche Einführung und den erfolgreichen Betrieb von BI-Lösungen. Ein persönlicher Blick auf ein hochaktuelles Thema.
Lesedauer: 20 Minuten
Aus der Sicht eines erfahrenen Projektleiters wird ein Fachgespräch zwischen zwei Freunden wiedergegeben. Es geht um die Entwicklung eines BI-Projektes und die Herausforderungen, Selbstzweifel sowie die Bereitschaft, Hilfe durch einen erfahrenen Mentor und das Team zuzulassen, um so den Weg mit all seinen Hindernissen und Tücken erfolgreich zu beschreiten.
Vor einigen Wochen traf ich einen alten Freund wieder, den ich zuletzt vor vielen Jahren gesehen hatte und der sich in der Zwischenzeit in einem größeren mittelständischen Unternehmen etablieren konnte. Jetzt sollte er ein zuvor gescheitertes BI-Projekt im Kontext der Migration zu einem neuen ERP-System mit beeindruckender Funktionalität übernehmen – welche faszinierenden Analyse-Chancen sich hier bieten!
Aber warum ausgerechnet er dafür ausgewählt worden war, verstand er nicht. Denn auf den ersten Blick erschien ihm das eine denkbar undankbare Aufgabe zu sein. Und als BI-Spezialist sah er sich auch nicht.
So eine Aufgabe mag tatsächlich zunächst undankbar wirken. Doch ich kannte ihn als strukturiert arbeitenden, verlässlichen und kommunikativen Menschen. Warum sollte er ihr nicht gewachsen sein? Und: Sich näher mit der Thematik befassen zu müssen, hat Vorteile. Große Vorteile.
Er fragte mich nach meinen Erfahrungen. Worauf er achten müsse? Was er vermeiden könne? Ob ich Tipps geben könne? Ich versprach, darüber nachzudenken. Denn die erste Schwierigkeit ist, dass kein BI-Projekt dem anderen gleicht. Natürlich nicht. Unternehmensgröße, Branche, Budget, verfügbares Personal und andere Rahmenbedingungen nehmen maßgeblich Einfluss auf die Gestaltungsoptionen.
Aber es gibt bestimmte Gemeinsamkeiten. Wenn ich auf die Erfahrungen der letzten gut zwanzig Jahre blicke, dann gibt es durchaus Aspekte, die eigentlich immer wichtig sind. Manche davon erscheinen trivial, werden in der Praxis aber trotzdem häufig vernachlässigt. Oder sogar bewusst ignoriert – ja, das gibt es leider tatsächlich.
Ich habe ihm bei einem gemeinsamen Abendessen eine Woche später meine persönlichen Top-8 mitgegeben.
Seine erste Frage: Wenn ich mir das so ansehe, ist das ein ziemlich großer Berg von Aufgaben, der da vor uns liegt. Wie geht man so etwas an?
Ganz einfach, wie ein Bergsteiger: In Etappen, sage ich.
1. „Think Big – Start Small “
Häufig wird bei BI-Projekten der initiale Fehler gemacht, möglichst schnell möglichst viel Funktionalität und möglichst viele Daten für möglichst viele Stakeholder bereitzustellen. Das scheitert vielfach. Weil verschiedene Bedingungen nicht erfüllt sind: Die Datenqualität stimmt nicht, die Funktionalitäten werden nicht ganzheitlich gedacht, die Technik hakt, die Stakeholder sind nicht geschult, eine einheitlich konzipierte Vorgehensweise mit Richtlinien und einer Architektur fehlt. Und ganz sicher noch einige Punkte mehr, für die hier der Platz nicht ausreicht. Dann passiert das, was einer BI-Lösung den Todesstoß versetzt: Das Management traut den Zahlen nicht. Die Lösung wird unglaubwürdig, verliert an Akzeptanz, wird eingestampft.
Ziel muss also sein, das Vorhaben von Beginn an in seiner gesamten Komplexität im Blick zu haben. Also vom Ende her zu denken. Wie muss die Gesamtlösung vom Grundsatz her aussehen, welchen Rahmen muss sie bereitstellen, um alle zukünftigen (noch unbekannten) Anforderungen erfüllen zu können. Die hohe Kunst (der BI-Architektur) ist es, die Lösung so zu entwerfen, dass später Teile ergänzt werden können, ohne dass plötzlich Inseln und unnötige Schnittstellen entstehen. Gleichzeitig muss sorgfältig fachlich priorisiert entschieden werden, womit konkret begonnen wird. Das kann dort sein, wo der größte Leidensdruck herrscht, das kann aber auch dort sein, wo es die komplexesten Zusammenhänge gibt. Letzteres Vorgehen ist sehr beliebt, denn klappt es dort, klappt es überall. Beispielsweise im Vertrieb oder im finanzwirtschaftlichen Controlling. Wenn alles stabil läuft, wird der nächste Punkt auf der Prioritäten-Liste bearbeitet. Baustein um Baustein wächst die Lösung heran.
Das geht nicht von heute auf morgen. Es braucht insbesondere zu Beginn Zeit, die man sich nehmen sollte. Denn dann kann die Implementierung neuer Funktionalitäten im weiteren Verlauf immer schneller erfolgen, weil Erfahrungen gesammelt und weil Mechanismen und Verfahren etabliert wurden, die sicherstellen, dass das Ergebnis den Erwartungen entspricht. Sicher. Verlässlich. Dann kann man zuverlässiger sagen, wie viel Aufwand sich hinter der berüchtigten Bitte „Ich brauche doch nur dieses eine Feld“ verbirgt und wie lange es dauern wird, bis diese neue Funktionalität zur Verfügung steht.
Würde man überhastet und ohne den Blick auf das Ende starten, würden neben einer Vielzahl von Risiken nicht nur bezogen auf das fachliche Ergebnis, sondern auch auf technische Zusammenhänge, mit großer Wahrscheinlichkeit hohe technische Schulden entstehen. Etwas, das grundsätzlich, aber gerade jetzt in der Zeit schwierigster Wettbewerbsbedingungen, die rasches und zielgenaues Handeln erfordern, niemand wirklich braucht (es gibt schon genug alte Schulden…).
„Okay, klingt sehr sinnvoll und auch umsetzbar“, sagt er. „Jetzt wird aber immer wieder über Tools gesprochen, ehe es überhaupt losgegangen ist. Ist das nicht zu früh?“
„Nicht grundsätzlich immer. Aber in vielen Fällen ja“, entgegne ich.
2. Erst das Datenmodell, dann das Tool
Irgendwann hat man mal etwas über Business-IT-Alignment gelernt. Nicht: IT-Business-Alignment. Die IT ist nie Selbstzweck, sie soll das Business bestmöglich unterstützen (wenngleich in der Praxis die IT natürlich häufig bestimmte Vorgaben macht: die berühmten Tool-getriebenen Sachzwänge). Das gelingt aber nur, wenn sich das Business zuvor umfassend mit seinen Anforderungen beschäftigt hat. Dieser Punkt ist nicht zu verwechseln mit Agilität versus inhärentem Hang zur Starrheit linearer Vorgehensmodelle. Es geht mitnichten darum, ein abschließendes Lastenheft schreiben zu müssen. Es geht vielmehr darum, sich ganz grundsätzliche Gedanken über das Datenmodell zu machen, das man aufbauen und nutzen möchte. Und erst dann im Rahmen einer umfassenden Analyse zu fragen, mit welchem Tool (oder welcher Tool-Sammlung) man dieses Datenmodell sicher befüllen und sinnvoll erschließen kann. Doch leider gibt es immer noch vielfach Überlegungen wie etwa „Da haben wir doch schon ein Tool“, „Von dem Hersteller beziehen wir schon andere Lösungen, das böte sich doch an“ oder „Ich habe gelesen/gehört, das Tool A soll besonders gut sein“. Zudem sollte man dem spontanen Gedanken widerstehen, erst einmal mit Tool B zu starten und dann weiterzusehen. Das mag alles korrekt sein, und am Ende entscheidet man vielleicht tatsächlich so, vielleicht aber auch nicht. Und: Gerade Provisorien halten bekanntlich sehr lange.
Der Grundsatz Datenmodell vor Tool gilt insbesondere, wenn abweichend von klassischen BI-Lösungen, die auf einem Data Warehouse mit multidimensionalem Datenmodell in relationalen Datenbanken basieren, neue Architekturkonzepte eingesetzt werden, bei denen es nicht den einen physischen Ort gibt, an dem Daten aufbewahrt werden. Bei denen ergänzend oder ausschließlich nicht-relationale (NoSQL-) Modelle eingesetzt werden oder Data Lake und Cloud-Konzepte. Und in denen neben den altbekannten CI-Daten verstärkt NCI-Daten einbezogen sind. Oder „Echtzeitanforderungen“ erfüllt sein müssen (Jederzeit einen Überblick über das Unternehmensgeschehen haben).
Datenmodelle, die das erfüllen, müssen von Beginn an auf Flexibilität und insbesondere Skalierbarkeit ausgelegt sein. Wenn bei Änderungen ein Redesign notwendig wird, hat man einen kostspieligen, zeitraubenden und nicht zuletzt imageschädigenden Fehler gemacht.
„Wenn ich es richtig verstanden habe“, sagt er, „ist das erste Projekt auch deshalb gescheitert, weil die Berichte irgendwie nicht gut waren. Datenqualität ist also zentral?“
„Unbedingt“, sage ich und lehne mich vor. „Das ist so zentral, zentraler geht es nicht.“
3. Ohne Datenqualität ist alles nichts
In vielen BI-Projekten stellen die Beteiligten fest, dass es um die Datenqualität nicht gut bestellt ist. Wenn das so ist, dann bedeutet das größte Gefahr für die gesamte Lösung. Denn es geht um Glaubwürdigkeit und Akzeptanz (siehe auch Tipp 1). Es ist jedoch hilfreich, diesen Umstand, so ärgerlich er sein mag, als Chance zu begreifen. Zugegeben: Es beginnt eine meist mühsame, kleinteilige Suche nach den Ursachen. Doch eine intensive Beschäftigung belohnt mit verschiedenen Erkenntnissen und Erfolgen.
Datenqualität ist niemals automatisch hoch. Um im weiteren Verlauf eine hohe Datenqualität sicherstellen zu können, bedarf es zweier wichtiger Voraussetzungen: Erstens: Einem Ende-zu-Ende-Prozessverständnis und Zweitens einer Vielzahl automatisierter Abstimmprozesse. Zu Erstens: Wer das Thema BI ernst nimmt, ist dann erfolgreich, wenn er ein Bewusstsein aller an einem Prozess Beteiligten für das Thema Datenqualität erreicht, und zwar insbesondere dann, wenn für die unmittelbar Betroffenen in einem Prozessschritt Qualitätsprobleme keine Rolle im operativen Geschehen spielen, es aber allen sehr wohl bewusst ist, dass diese Qualitätsprobleme später anderen Beteiligten vor die Füße fallen und letztlich die Reputation der Lösung schädigen. Das Ende-zu-Ende-Prozessverständnis führt also zu gemeinsamer Verantwortung. Das ist ein sehr wertvolles Asset in der Zusammenarbeit (und für die gesamte Unternehmenskultur).
Zu Zweitens: Gerade wenn Daten (global) verteilt sind, ist es wichtig, fortlaufend möglichst viele hilfreiche Abstimmungen zwischen Systemen durchzuführen, um inhaltliche Inkonsistenzen und Implausibilitäten so früh wie möglich erkennen zu können, ebenso wie versteckte technische Störungen, die zu unterschiedlichsten Fehlern und merkwürdigsten Effekten führen können. Diese Abstimmungen lassen sich weitgehend automatisieren. Im Idealfall werden Probleme so früh sichtbar, dass die Empfänger der jeweiligen Informationen den Fehler gar nicht bemerken, weil er korrigiert werden konnte, ehe er sich in Berichten oder Analysen manifestiert hat.
Doch beides, Ende-zu-Ende-Prozessverständnis und Abstimmungen, gibt es nicht zum Nulltarif. Für ein Ende-zu-Ende-Prozessverständnis ist gute Kommunikation zentral (siehe Tipp 5), für Abstimmungen muss Zeit (und gegebenenfalls Budget für Spezialtools) investiert werden (siehe nachfolgenden Tipp). Beides muss daher im Projektplan berücksichtigt werden.
Er lehnt sich entspannt zurück. „Irgendwie war mir das klar“, sagt er. „Aber wie ist das mit Ressourcen allgemein und vor allem Geld und Zeit?“
Ich lehne mich ebenfalls wieder zurück und überlege kurz, ehe ich antworte: Gut, Budget und Personentage sind wichtig und müssen geplant werden, keine Frage. Aber in diesem Kontext ist noch ein wenig mehr zu beachten.
4. Geld und Zeit sind (nicht) alles
Früher war Speicherplatz unendlich kostbar. Man rang um jedes Gigabyte. Das ist heute anders und mag Fluch oder Segen sein. Wichtig ist, dass allen Beteiligten bewusst ist, dass eine gute BI-Lösung Geld kostet. Immer. Und nicht nur mit Bezug auf den Speicherplatz. Gut bedeutet in diesem Kontext, dass sie möglichst ganzheitlich konzipiert wurde und skaliert (siehe Tipps 1 und 2). Hier im Sinne guter (IT-)Governance langfristig zu denken, kostet, lohnt sich aber langfristig in jedem Fall. Es hilft nicht, nur auf die reinen Betriebskosten als Zahl zu achten und dem Mantra zu folgen: 10 Prozent gehen immer. Irgendwann ist eine Lösung totgespart, das Team ausgelaugt und frustriert, und irgendwann passiert dann das, was jeder verdrängt: Die Lösung ist aufgrund eines übersehenen, marginalisierten Störungsrisikos nicht verfügbar und/oder strukturell beschädigt. Ein Monatswechsel ohne (Finanz-)Berichte beispielsweise ist eine schöne Erfahrung. In einer solchen Situation fehlen Fachleute für eine schnelle Lösung, weil sie entweder nicht mehr da sind oder nie da waren.
Vergleichbares gilt für die Zeit. Sie ist immer knapp, häufig das knappste Gut überhaupt, denn neue Fachleute sind nicht von heute auf morgen gefunden und eingestellt, und Externe müssen sich erst einmal in der Organisation und ihrer Semantik orientieren. Nun wird – gerade heute – von manchen Fachbereichen ungeduldig argumentiert: Ich kann nicht warten, es ist sehr wichtig, ich habe ja schließlich Budget dafür. Selbstverständlich kann man (dezentrale) Workarounds auf Basis von Schatten-IT installieren, wenn es objektiv betrachtet (Stichwort IT-Governance) gar nicht anders geht. Denn das Business steht im Vordergrund. Besser ist hingegen immer, es gar nicht so weit kommen zu lassen. Oder wenn es schon notwendig ist, so schnell wie möglich einen Pfad zur Ablösung des Workarounds zu definieren, was aber wiederum Geld und Zeit kostet.
„Aber sag mal“, will er jetzt wissen, „Stichwort IT-Governance. Ist das nicht auch viel Kommunikation?“
„Und ob“, sage ich. „Ich habe da eine nette Anekdote zum Thema Kommunikation: Einmal saß ich – noch relativ neu im Thema und am Anfang eines Projekts – bei meinem Lenkungsausschussvorsitzenden im Büro. Ich habe“, erklärte ich ihm, „das Gefühl, ich bin im Projekt irgendwie unproduktiv. Ich renne den ganzen Tag im Haus herum und rede mit Leuten.“ Er lehnte sich entspannt zurück, verschränkte die Arme hinter dem Kopf, grinste breit und entgegnete: „Dafür werden Sie bezahlt.“
5. Gute Kommunikation ist entscheidend
Jede BI-Lösung ist anspruchsvoll. Und zwar insbesondere mit Blick auf die Semantik. Wie nehmen die Zielgruppen die Informationen auf? Haben alle das gleiche (fachliche) Verständnis? Wichtig ist, über Ziele, Vorgehensweisen, Prioritäten, Zeitpläne, Budgets und einzubringende Ressourcen zu sprechen. Und darüber, wie es im Maschinenraum aussieht. So früh wie möglich. Fortlaufend, nicht punktuell. Im agilen Vorgehen ist das selbstverständlich. Es sollte aber auch dann selbstverständlich sein, wenn nicht rein agil vorgegangen wird. Dabei gibt es unterschiedliche Wege: Das direkte persönliche Gespräch mit den Verantwortlichen in den Fachbereichen ebenso wie kleine wöchentliche oder monatliche Meetings mit Roundtable-Charakter abseits von Lenkungsausschuss- oder Projektsitzungen. Newsletter und andere informative Aktivitäten im Intranet können ergänzend hilfreich sein.
Gerade wenn es um Aufwandsschätzungen und Erwartungen auf fachlicher Seite geht, ist es wichtig, genau erklären zu können, wie die technischen Strukturen „ticken“. Es geht dabei nicht darum, im Detail vorzustellen, welche Technologien wie eingesetzt werden. Das kann für die Zielgruppe interessant sein – oder auch nicht. Viel wichtiger ist es, technische Zusammenhänge so anschaulich aufzubereiten, dass Beteiligten ohne umfassendes Tech-Wissen bewusst wird, dass die Aufnahme weiterer Daten (egal aus welcher Quelle) oder die Erstellung bestimmter Analysen einen definierbaren Aufwand zur Folge hat und es von außen mitunter leichter aussehen kann, als es von innen gesehen ist. Data Analytics etwa ist nicht umsonst ein sehr anspruchsvolles Teilgebiet der Mathematik.
Hilfreich ist es – je nach Fall –, die betriebliche Mitbestimmung von Beginn an einzubeziehen. Eine vertrauensvolle Kommunikationsbeziehung erlaubt es vielfach, Daten einzubeziehen und so Dinge umzusetzen, die sonst in dieser Form vielleicht nicht möglich wären. Eine klare Zielsetzung und das explizite Ausschließen bestimmter Optionen sind die Basis dafür, dass sich Vorteile aus einem komplizierten Setting ziehen lassen.
„Das hast Du Deinen Lenkungsausschussvorsitzenden tatsächlich so gefragt?“ Er schaut mich ungläubig an, vielleicht dachte er, ich sei zu naiv.
„Ja, klar“, antworte ich. „Wobei Du wissen sollst, er war damals so etwas wie mein Mentor. Du hast schon Recht, es kann auch klug sein, so eine Frage für sich zu behalten. Aber ich finde, eigentlich sollten alle, die solche großen Aufgaben übernehmen und nicht bereits viel Erfahrung mitbringen – und selbst dann – einen Mentor haben. Das ist sehr hilfreich – auch für den Abgleich Eigen-/Fremdbild. Gerade hier im BI-Kontext, wenn Kommunikation zentral ist. Und nicht immer wagt Dein Team, Dir Kritik ehrlich zu kommunizieren – obwohl es schön wäre, wenn es das täte. Dein Mentor schon.“
„Hat Dein Team …?“, will er jetzt wissen.
„Ja, hat es, und es war manchmal zwar ein Stich, aber wenn man offen für Feedback ist, wächst man daran und das ist dann auch gut für das Team, die Führung und das Ergebnis. Jedenfalls ging es mir so. Versuche es.“
„Eigentlich“, will er jetzt wissen, „ist das doch eine Endlosaufgabe?“
„Stimmt“, entgegne ich.
6. Ein BI-Projekt endet nie
Das widerspricht der allgemeinen Definition von Projekt. Ist aber tatsächlich so. Denn mit dem Essen kommt der Appetit. In nur wenigen anderen Bereichen wecken Entwicklungen so viele Begehrlichkeiten wie gute Berichte und Analysen. Der Wunsch nach mehr ist also zwangsläufig. Daher ist es so wichtig, flexibel sein zu können und eine Lösung zu haben, die skaliert (siehe Tipps 1 und 2). Doch hier ist noch ein anderer Punkt wichtig: Die Verankerung des Themas in der Organisation. Als hilfreich hat sich erwiesen, in Releasezyklen zu denken. Dann folgt ein Projekt auf das andere. Gleichzeitig befinden sich immer mehr Teile der Lösung im laufenden Betrieb. Es wird Supportanfragen geben, Anforderungen müssen gesammelt, bewertet und in die Planungen aufgenommen werden, IT-Systeme müssen erweitert oder Fehler behoben werden. Eine elegante organisatorische Möglichkeit zur Strukturierung all dieser Aspekte ist das Business Intelligence Competence Center (kurz BICC). Ein BICC vereinigt alles zum Thema BI an einer Stelle. Es verkürzt Wege, hilft Synergien zu erschließen und verhindert Doppelarbeiten. Es entwickelt Schulungen und bearbeitet abschließend eingehende Tickets. So wird das ehemals als Projekt gestartete Vorhaben zur fest verankerten Daueraufgabe.
„Ich habe gehört, dass es Beschwerden gab, weil manchen Leuten die Tools wieder weggenommen worden sind. Wie geht man mit diesem Thema prinzipiell um? Hattest Du das Thema bei Dir auch schon mal? “
„Und ob!“, antworte ich. „Das ist ein dickes Brett“, ergänze ich nach kurzem Überlegen.
7. Nutzergruppen sollen und dürfen Verantwortung übernehmen, aber nicht überfordert werden
Selbst wenn eine Gruppe fachlich im gleichen Themenspektrum arbeitet, ist sie nie ganz homogen. Es gibt immer einzelne Personen mit mehr Erfahrung, umfassenderer Kenntnis, schnellerer Auffassungsgabe und so weiter. Das ist normal. Daher ist es hilfreich, sich so früh wie möglich darüber Gedanken zu machen, wer wie womit erreicht werden soll. Eine häufig gestellte Frage ist, warum nicht alle beliebig Auswertungen erstellen dürfen. Weil es nicht alle müssen. Es ist stets von zentraler Bedeutung, zu klären, warum welche Anforderungen gestellt werden. Komplexe Analysetools sind mächtige Werkzeuge. Sie kosten einerseits viel Geld und erfordern aufwändige Schulungen, andererseits können sie in der Anwendung zu Überforderung führen, selbst wenn das vielleicht nicht unmittelbar so empfunden wird. Doch was, wenn das Datenmodell doch nicht korrekt verstanden wurde? Und ganz unabhängig davon: Braucht es wirklich an allen Stellen umfassende Funktionalität? Eher nicht. Es kann entlastend sein, Berichte und Analysen nur zu nutzen, ohne Risiko, einen Fehler in der Anwendung zu machen. Es braucht aber dann, und das ist wichtig, eine Stelle, an die sich die Nutzenden wenden können, wenn sie einen Bedarf für weitere Informationen sehen (siehe vorausgehenden Tipp). Diese Stelle muss dann aber – entsprechend ausgestattet – auch zeitnah reagieren können.
„Immer wieder lese ich“, schildert er, „dass man mit KI und anderen neuen Tools tolle Sachen machen kann.“
„Allerdings“, antworte ich ihm. „Gerade KI spielt im BI-Kontext eine Schlüsselrolle. Aber auch andere Innovationen. Da werden wir in den nächsten Jahren noch jede Menge interessanter Dinge sehen.“
8. Neue Technologien sind vielversprechend, aber mit Augenmaß zu verwenden
In letzter Zeit wächst der verständliche Wunsch, so detailliert und zeitnah wie möglich über den Zustand der eigenen Organisation respektive den eigenen Verantwortungsbereich informiert zu sein. Noch besser wäre, wenn wir in unseren Berichten bereits heute lesen könnten, was sich morgen wie entwickeln wird – oder was für uns wichtig ist, obwohl wir das noch gar nicht so wahrgenommen haben (Proaktive Berichterstattung).
Mithilfe neuester Datenbanktechnologien (beispielsweise In-Memory) lassen sich Auswertungszeiten drastisch verkürzen. So kann ein Echtzeitgefühl entstehen. Das kann nützlich sein, kann aber vom Wesentlichen ablenken. Ein Zuviel an Informationen kann letztlich zu Fehlentscheidungen führen. Schnell ist etwas als vermeintlicher Trend erkannt, was in Wahrheit ein zufälliges Ereignis ist.
Mithilfe einer Künstlichen Intelligenz wiederum können wir große Datenmengen auf Korrelationen und Trends hin untersuchen. Alle diese Aspekte sind spannend und interessant. Man muss aber, gerade beim KI-Einsatz, sehr sorgfältig prüfen, ob die Algorithmen so entwickelt wurden, dass sie nutzen und nicht schaden. Man muss verstanden haben, wie sie arbeiten, ihre Entscheidungen nachvollziehen können. Das ist, obwohl es leicht scheint, diesen Punkt zu umgehen, ein nicht verhandelbares Muss. Denn sonst kann das einerseits zu Reputationsrisiken führen (KI stellt Sachverhalte einseitig, also mit unerwünschtem Bias dar), andererseits können Falschinformationen zu teuren Fehlentscheidungen führen oder andere kritische Risiken entstehen lassen. Es gehört mit zu den schwierigsten Aufgaben, diese Prüfung durchzuführen. Dieser Punkt ist daher Kür in einem BI-Vorhaben, die man nur mit professioneller Unterstützung absolvieren sollte. Größere Unternehmen können hierzu unter Umständen auf entsprechende Fachleute zurückgreifen, kleinere Unternehmen sollten sinnvollerweise externe Unterstützung einbeziehen.
„Das heißt“, fragt er zusammenfassend, als ich meinen letzten Punkt erläutert habe, „ich muss umsichtig agieren, kann aber in einem BI-Projekt viel gewinnen: genaue Kenntnisse über die Verantwortlichkeiten (was in der Zusammenarbeit und bei der Klärung von Problemen generell immer hilfreich ist) und Prozesse in meinem Unternehmen. Genaue Kenntnisse über die Daten, die wir haben und was man mit ihnen machen kann.“
Ich nicke. „Genau das ist ein Vorteil, den nicht nur Du als die leitende Person aus der Mitwirkung in einem BI-Projekt oder einem BICC ziehen kannst. Nein, alle Beteiligten profitieren von der interdisziplinären Zusammenarbeit, die sich automatisch ergibt. Insbesondere, wenn immer mehr Themen in die Berichterstattung und Analyse aufgenommen und Data-Lake-Konzepte genutzt werden. Doch das geschieht nicht automatisch, Dein Auftraggeber (die Unternehmensleitung) und Du, Ihr müsst das wollen und aktiv fördern.“
Jetzt nickt er. Das ist echte Teamarbeit und die Nutzung der jeweiligen Stärken der Beteiligten, das ist ihm sofort klar, denn eigentlich ist das in allen Projekten so und sollte selbstverständlich sein. Hier jedoch ist diese Dimension besonders groß, weil BI nicht irgendein Projekt ist, sondern ein unternehmensweites Vorhaben und in seiner Mehrdimensionalität und Vielschichtigkeit zum Erhalt der strategischen Wettbewerbsfähigkeit beiträgt – heute und mehr noch in der Zukunft.
„Und ist es dann nicht sinnvoll, sich in besonderer Weise den Daten zuzuwenden, sind sie doch künftig mehr denn je der Rohstoff, aus dem – durchaus mithilfe von BI – neue Geschäftsmodelle entstehen“, will er abschließend wissen.
Ich nicke wieder. „Absolut. Du hast den Kern verstanden. Gerade Data Lakes können im Gegensatz zum sorgfältig kuratierten Datenmodell eines klassischen Data Warehouse schnell ein toxischer Datensumpf werden, wenn man nicht von Beginn an systematisch und auf Basis eines Gesamtentwurfs (siehe Tipp 1) steuert. Ein guter Gedanke ist daher (ob mit oder ohne Data Lake), in eine umfassende Data Governance zu investieren (siehe Lesetipp). Sie hilft nachhaltig, alle Fragen im Umgang mit Daten als zentralem Element nicht nur in BI-Lösungen, sondern auch im gesamten Unternehmen strukturiert zu lösen.“
„Was mich noch interessiert“, sagte er, „warum hast Du bei unserem allerersten Treffen, als ich Dir berichtet habe, was ich aktuell mache, eigentlich so spontan von einem ‘Marathon’ gesprochen, den ich vor mir habe?“
„Das kann ich Dir schnell beantworten“, entgegnete ich: „Weil sich eine BI-Einführung wie ein Marathon anfühlt. Man lernt bei den Vorbereitungen und beim Lauf eine Menge über sich selbst und seine Umgebung. Man hat nur Erfolg, wenn man seine Kräfte richtig einteilt. So ist es auch bei einem BI-Projekt. Du wirst an mich denken.“ Wir grinsen beide.
„Jedenfalls wünsche ich Dir, dass Dich diese Tipps bei Deiner Arbeit unterstützen. Insbesondere, weil Du ins kalte Wasser geworfen wirst. Wenn ich diese Tipps alle selbst schon früher gekannt – und vor allem beherzigt – hätte, hätte ich vielleicht manchen Fehler nicht gemacht. Heute würde ich sie allen, die im Kontext ERP-basierter oder -naher BI-Lösungen tätig sind, mit auf den Weg geben.“
Er bedankte sich. Jetzt fühle er sich irgendwie besser gerüstet. Als wir schon bezahlt hatten und vor dem Restaurant standen, fiel ihm noch ein letzter Punkt ein: „Hast Du Lesetipps, wenn ich mal was genauer wissen und mich nicht vor meinem Team blamieren will?“
Ich hob mit gespielter Strenge den Zeigefinger: „Du blamierst Dich nicht. Im Gegenteil. Erstens kann man nie alles wissen. Und zweitens weiß Dein Team, wo Deine Stärken liegen und wohl auch, warum Du ausgewählt wurdest und was Deine Aufgaben sind. Ich jedenfalls habe die Erfahrung gemacht, dass es immer positiv aufgenommen wird, wenn die Expertise der Teammitglieder durch Einholen von Meinungen und – ja – auch Rat, aktiv geschätzt wird. Erinnere Dich an den Kommunikationsaspekt. Alle haben ihre jeweiligen Stärken und zu spüren, dass das er- und anerkannt wird, habe ich als wichtigen motivierenden Faktor erlebt. BI ist immer Teamarbeit. Hast Du vorhin auch selbst gesagt. Niemand kann alleine eine BI-Lösung aufbauen. Alle müssen sich aufeinander verlassen können und am gemeinsamen Ziel arbeiten.
Aber wenn Du mich schon so fragst, es ist immer hilfreich, auf gute objektive, wissenschaftliche Literatur zurückzugreifen, um sich seine eigene Meinung zu diesen und vielen weiteren Punkten bilden und dann individuell entscheiden zu können. Außerdem könnte Dich auch jemand aus Deinem Team um eine Empfehlung bitten. Es gibt fast unendlich viel, sehr gute Literatur zum Thema. Ich maile Dir im Nachgang – ganz subjektiv – meine drei Favoriten, wenn Du mal Zeit fürs Weiterlesen hast:“
- Baars, H./Kemper, H.-G.: Business Intelligence & Analytics – Grundlagen und praktische Anwendungen: Ansätze der IT-basierten Entscheidungsunterstützung.
4. Aufl. SpringerVieweg, Wiesbaden 2021 - Bauer, A./Günzel, H.: Data-Warehouse-Systeme: Architektur, Entwicklung, Anwendung. 4. Aufl. dpunkt.verlag, Heidelberg 2013
- Gluchowski, P.: Data Governance: Grundlagen, Konzepte und Anwendungen. dpunkt.verlag, Heidelberg 2020
„Ja, das Zeitproblem, wer hat das nicht“, sagt er. „Aber es stimmt, mitunter ist es hilfreich, sich die Zeit dafür zu nehmen“.
Wir grinsen beide und verabschieden uns. Ich bin sehr gespannt, was er mir über sein Projekt einmal berichten wird. Vielleicht hat er dann einen neunten oder zehnten Tipp für mich?
Über den Autor
Prof. Matthias Knoll
ist Professor für betriebliche Informationsverarbeitung an der Hochschule Darmstadt. Zuvor war er mehrere Jahre als Projektleiter eines BI-Projekts tätig.
