In der Business Intelligence scheint die Frage nach dem “Make or Buy” aus irgendwelchen Gründen ungleich präsenter zu sein als in den meisten anderen Software-Kategorien. Während Marke Eigenbau bei ERPs, CRMs, Marketing Clouds und anderen operativen Systemen klar in der Unterzahl ist, scheint sie im Feld von BI & Co für eine Vielzahl der Unternehmen die präferierte Option zu sein – zumindest bis zum ersten Mal die schmerzliche Erfahrung gemacht wird, das eigene BI-Projekt scheitern zu sehen, nachdem es bereits sechs- oder siebenstellige Euro-Beträge und monate- oder jahrelangen Zeitaufwand verschlungen sowie zur Einstellung diverser Mitarbeiter geführt hat, die nur schwer für andere Aufgaben eingesetzt werden können.
Warum bloß ist das so? Warum ist es für die meisten Unternehmen in der BI nicht genauso einleuchtend wie im Falle von ERP & Co, eine standardisierte (und auf dieser Basis anpassbare) Software zu kaufen, die deutlich schneller und billiger implementiert ist als ein Eigenbau – und dazu von echten Profis gemacht? Warum werden die Anforderungen an Reporting, Analyse bzw. datengetriebenes Arbeiten als so viel individueller eingestuft als die an operative Kernprozesse – oder anders gefragt: Wieso werden uns als Hersteller einer standardisierten BI-Software Individualisierungsmöglichkeiten so viel weniger zugetraut als es bei Herstellern von ERP & Co ganz selbstverständlich vorausgesetzt wird? Wieso greifen wegen dieser Fehleinschätzung so viele Firmen zum Eigenbau-Stack plus Visualisierung à la Tableau, Power BI oder Qlik und merken nicht, dass es sich bei der damit vermeintlich gewonnenen Gestaltungsfreiheit ganz einfach um den völlig generischen Charakter jener Tools handelt, die deshalb höchstens methodischen, aber keinerlei inhaltlichen Mehrwert liefern können? Fragen über Fragen, die ich mir bis heute nicht wirklich beantworten kann. In diesem Artikel möchte ich mich stattdessen der grundsätzlichen Fragestellung des “Make or Buy” annehmen, bevor ich mich beim nächsten Mal dem verwandten Thema der Individualisierungsansprüche widme. Ich hoffe, dem noch ziemlich unhinterfragten “Make”-Trend in der BI damit etwas Diskussionsstoff liefern zu können.
4 unbequeme Wahrheiten über selbstgebaute BI-Setups
Um dem Namen meines Blogs gerecht zu werden, lasst mich direkt mit der vollen Breitseite anfangen: Mit vier unbequemen Wahrheiten, weshalb den meisten Unternehmen die “Make”-Entscheidung in ihrer BI-Initiative spätestens mittel- bis langfristig mit voller Wucht auf die Füße fällt.
- 1 – Es wird Jahre dauern. 90% der Daten-Magie liegt unter der bunten Frontend-Oberfläche – Konzept, Entwicklung und Testing des vollständigen Setups (s.u.) werden aller Voraussicht nach mindestens ein bis zwei Jahre in Anspruch nehmen.
- 2 – Es wird furchtbar teuer werden. Da bei eigenen Lösungen keinerlei Skaleneffekte greifen, wirst Du für Technologie und Personal über eine Laufzeit von fünf Jahren am Ende mit Leichtigkeit mehr als 2 Mio. € hinlegen müssen (je nach Unternehmensgröße auch ein Vielfaches dieses Betrags).
- 3 – Du trägst das volle Risiko. Du wirst schwer in Personal und Infrastruktur investieren müssen – was eine hohe Kapitalbindung bedeutet, selbst wenn das Projekt scheitert.
- 4 – Am Ende wirst Du mit einer mittelmäßigen Lösung dastehen. Da die technische Herausforderung immens ist, tendieren selbstgebaute BI-Lösungen dazu, als Sammlung reiner ETL-Prozesse zu enden – wenn Du Glück hast, mit Excel und einem Visualisierungs-Tool als “Frontend”. Ziemlich sicher wird es keine einfach bedienbaren Tools für die wichtigste Nutzergruppe jeder modernen BI-Lösung geben: die operativen Teams (s. dazu auch meinen Artikel Niemand benutzt Dein BI-System).
Ja, das sind harte Wahrheiten, aber das macht sie leider nicht weniger wahr. Lass mich erklären, weshalb das so ist.
Warum ist es so schwer, selbst eine gute BI-Lösung zu bauen?
Die Antwort auf diese Frage setzt sich aus vielerlei Aspekten zusammen – die wichtigsten sechs möchte ich hier zusammenfassen. In der Skizze ist zu sehen, wo diese innerhalb eines klassischen Eigenbau-BI-Stacks (Verarbeitungsschichten plus Visualisierung und/oder Excel als “Frontend”) zu verorten sind.
- 1 – Nutzer wissen meist nicht wirklich, was sie brauchen – oder sie wollen, was immer ihnen gerade so einfällt. So oder so: Die Erfassung von Anforderungen sowie vor allem ihre Priorisierung sind kompliziert (und bleiben es auch im Laufe der Zeit).
- 2 – Ein echtes Lösungs-Frontend mit einfach zu nutzenden Tools für die operativen Teams ist eine Schlüsselanforderung moderner BI – aber erfordert in der In-House-Umsetzung eine Menge Expertise (Business und Tech) sowie enormen Personalaufwand (langfristig!). De facto verfügt deshalb kaum eine Eigenbau-BI über ein solches.
3 – Je umfassender das Setup, desto größer die Herausforderung, das zentrale Data Warehouse performant genug zu halten, um Abfragen auf allen erforderlichen Ebenen zu ermöglichen – detailliert und aggregiert.
4 – Komplexe Daten in ein konsistentes, nachhaltiges Datenmodell zu bringen, ist eine Schlüsselaufgabe, die Expertise sowie kontinuierliche Pflege erfordert – insbesondere, da Datenmodelle durch hinzukommende Quellsysteme und Anforderungen über die Zeit weiter wachsen.
5 – ETL-Prozesse von mehreren Systemen zu einem Data Warehouse zu entwickeln, ist nicht nur herausfordernd, sondern erfordert ununterbrochene Arbeit, da Quellsysteme sowie Output-Anforderungen sich laufend verändern und immer weiter wachsen.
6 – Integrationen zu Quellsystemen zu bauen, ist einmaliger Aufwand – doch sie am Laufen zu halten, erfordert kontinuierliche Pflege und Wartung.
Warum sind BI-Projekte so langwierig und teuer?
Auch die Antwort auf diese Frage gliedert sich in mehrere Aspekte auf – ich werde versuchen, anhand des folgenden Schaubilds eine möglichst kompakte Antwort zu geben. Dazu vorab: Natürlich ist die “Make”-Darstellung stark pauschalisiert, in Wahrheit sehen wir uns sowohl bei den Kosten als auch bei den Projektlaufzeiten einem breiten Spektrum gegenüber, abhängig von Unternehmensgröße und Projektambitionen. Unser Beispiel ist nahe dem unteren Ende dieses Spektrums zu verorten. Die “Buy”-Darstellung wiederum ist je nach Anbieter natürlich ebenso variabel; weil ich minubo, die Lösung meiner eigenen Firma, preislich am genauesten einordnen und jedem Unternehmen aus Handel und Herstellung natürlich auch in Sachen Lösungs-Scope und -Qualität nur ans Herz legen kann, habe ich sie für den “Buy”-Vergleich herangezogen.
“Make” und “Buy” im Fünf-Jahres-Vergleich:
Klicke aufs Bild, um die Ansicht zu vergrößern.
- Kosten im Vergleich: Dass die Kosten für eine selbstgebaute BI-Lösung so viel höher liegen als die für eine eingekaufte standardisierte Software, liegt eigentlich auf der Hand. Was bei der fertigen Software in Sachen Konzept und Entwicklung längst passiert ist und kostenmäßig auf eine Vielzahl an Kunden umgelegt werden kann, muss beim Eigenbau mit voller Kostenbelastung von vorne begonnen werden. Das bedeutet nicht nur hohen Personalaufwand zur Neuerfindung des Rades in Projekt und Entwicklung (also business- und techseitig), sondern auch Kosten für einen eigenen Tech-Stack von Hosting über ETL und Data Warehouse bis hin zu Visualisierungs-Tools sowie mehr oder weniger zusätzliche Kosten für externe Beratung. Bei den Tech-Kosten kommt als verstärkender Faktor in Hinblick auf die signifikant geringeren “Buy”-Kosten hinzu, dass die Kosten für den zentralen Tech-Stack des “Buy”-Anbieters nicht nur auf alle Kunden umgelegt werden können, sondern insbesondere bei Cloud-Anbietern wie minubo so starken Skaleneffekten unterliegen, dass die Tech-Kosten pro Kunde im Ergebnis nur einen Bruchteil dessen darstellen, was für einen eigenen Tech-Stack gezahlt werden müsste.
- Zeit bis zur produktiven Nutzung im Vergleich: Hier liegt der entscheidende Faktor fast noch mehr auf der Hand als bei den Kosten – eine fertige Lösung muss nicht erst gebaut, sondern nur noch implementiert werden. Im Falle von minubo bedeutet das ein unaufwändiges Onboarding, das sich auf die Anbindung der fertigen Lösung an die Quellsysteme des Kunden beschränkt. Da dies primär über standardisierte Schnittstellen erfolgt, bedeutet ein solches Onboarding einen Aufwand von wenigen Wochen, mit kaum bis geringem Aufwand auf Kundenseite. Während im Eigenbau also erst konzeptioniert, entwickelt und getestet wird, in der Regel mit diversen Verzögerungen durch ständig wechselnde Prioritätensetzung in der unternehmensinternen Projektagenda (oder durch Budgetüberraschungen innerhalb des BI-Projekts selbst), während langwierige Trial-and-Error-Prozesse durchlaufen werden, da interne Teams in der Regel natürlicherweise über weniger Fachexpertise und Erfahrung verfügen als spezialisierte Anbieter, kann mit einer eingekauften Lösung wie minubo bereits nach ein bis zwei Monaten produktiv gearbeitet werden. Alles, was auf dieser schnell implementierten (und in der Regel mindestens 80–90% der Kundenanforderungen abdeckenden) Basis an Individualisierung und Erweiterung des Lösungs-Scopse gewünscht wird, kann in der Folge parallel zur produktiven Nutzung umgesetzt werden.
Bei näherem Hinsehen wird also nicht nur klar, wo die besonderen Herausforderungen des “Make”-Ansatzes in der Business Intelligence liegen, sondern auch die immense Kluft zwischen “Make”- und “Buy”-Kosten sowie der jeweiligen Zeit bis zur produktiven Nutzung wird sichtbar.
Ja, auch der “Make”-Ansatz hat Argumente auf seiner Seite
Auch wenn ich selbst Lösungsanbieter bin, kann ich einzelne Aspekte der Argumentation der “Make”-Lobby natürlich durchaus nachvollziehen. In der folgenden Tabelle habe ich die Vor- und Nachteile beider Ansätze deshalb einmal zusammenfassend dargestellt (auch hier habe ich auf “Buy”-Seite minubo als Beispiel herangezogen):
Klicke aufs Bild, um die Ansicht zu vergrößern.
Es wird sichtbar, dass die Vorteile des “Make”-Ansatzes vor allem in den oberen drei Aspekten liegen: Anforderungsabdeckung, Kontrolle über das Setup sowie in-house Kompetenzaufbau. Ebenso klar wird allerdings, dass zumindest minubo als konkrete “Buy”-Alternative in diesen Aspekten ebenfalls konkrete Mehrwerte bietet, in Sachen Anforderungsabdeckung sogar sehr lange weit voraus ist, bis die Make-Variante nachziehen kann (wenn überhaupt, denn die Realitäten der Umsetzung unterscheiden sich zumeist doch gewaltig von der Wünsch-Dir-was-Feature-Liste aus der Anforderungssammlung). Ich kann angesichts dieser vergleichenden Aufstellung meine ungläubigen Fragen vom Anfang dieses Textes deshalb nur nochmal wiederholen: Wieso um Himmels willen wird die “Make or Buy”-Frage in Hinblick auf BI in so vielen Unternehmen überhaupt noch gestellt? …und noch dazu in so vielen Unternehmen mit “Make!” beantwortet (bis zum krachenden Scheitern der Projekte in nach meiner persönlichen Wahrnehmung mindestens 80% der Fälle)? Wenn mir das jemand erklären kann, meldet euch gerne bei mir unter lennard@minubo.com.
“Make and Buy” – immer eine Überlegung wert
Zum Abschluss des Artikels darf trotz dieses vorgezogenen “Buy”-Plädoyers ein wichtiger Aspekt nicht fehlen: das “Make and Buy”-Szenario. Im Kontext von Business Intelligence und Analytics ist “Make and Buy” aus meiner Sicht tatsächlich immer eine erwägenswerte Option; insbesondere, wenn die Eigenbau-BI dafür nicht erst von Null an erschaffen werden muss, sondern bereits vorhanden ist. Folgendermaßen könnte ein entsprechendes Szenario aussehen (erneut mit minubo als “Buy”-Beispiel):
Wir sehen, dass a) beide Stacks aus zum Teil unterschiedlichen, teils gemeinsamen Datenquellen gespeist werden, also inhaltlich unterschiedlich befüllte Data Warehouses enthalten; dass b) die beiden Data Warehouses sich mit diesen unterschiedlichen, sauber modellierten Datensätzen gegenseitig befüttern können, und dass c) die einfachen Visualisierungs- und/oder Excel-Frontends der Eigenbau-BI ergänzt werden durch das umfassendere und für jedermann bedienbare Frontend von minubo (mit Standard- sowie ggf. individuellen Tools). Außerdem werden d) operative Systeme aus der auch für diesen Case vorgesehenen minubo-Datenbank gespeist und ermöglichen auf diese Weise effiziente, intelligente Prozesse und Automatisierung. Insgesamt kann dieses Szenario (je nach Setup) z.B. folgende vier Vorteile mit sich bringen:
- Keine Zeit verlieren: Sei mit minubo schnell produktiv, während Du Deine eigene Lösung zu entwickeln beginnst.
- Nutzen, was schon da ist: In-house BI ist vom Daten-Scope her häufig auf das ERP-System beschränkt und richtet sich (schon aufgrund der für andere Nutzergruppen erhöhten Nutzungskomplexität der Frontends) in der Regel primär an Analysten und Controller – behalte, was für diese funktioniert, und ergänze es mit dem, was Deine breitere operative Nutzerbasis braucht.
- Finance- und Business-Sicht vereinen: minubo ist nicht primär auf Finance-Bedarfe ausgelegt, in-house BI dagegen hat häufig genau diesen Fokus – mit einem kombinierten Setup bringst Du beide fachlichen Welten zusammen.
- Kosteneffizient bleiben: Mute Dir die Schwerstarbeit in der Datenverarbeitung nicht selbst zu, sondern konzentriere Dich auf das Ergänzen dessen, was Du nicht kosteneffizienter einkaufen kannst.
Fazit & Ausblick
Soweit zur Frage “Make or Buy” – ich hoffe, es ist mir gelungen, darzustellen, weshalb der “Buy”-Weg im Kontext von Business Intelligence & Co für kaum ein Unternehmen weniger naheliegend sein sollte als im Kontext operativer Systeme wie (e)Commerce-Plattform, ERP oder CRM. Zu klar liegen die Vorteile einer eingekauften BI-Lösung auf der Hand – die nach Bedarf individualisiert, erweitert oder durch Eigenbau-Komponenten ergänzt werden kann. Zum Abschluss möchte ich es also einmal in aller Deutlichkeit sagen: Hört auf zu bauen – kauft!
Solltest Du Dich in Deiner BI-Initiative trotz allem für den “Make”-Ansatz entscheiden, habe ich zwei Empfehlungen für Dich:
- Die Commerce Intelligence Blaupause von minubo zur grundsätzlichen Herangehensweise an ein BI-Projekt bzw. zu dessen wichtigsten Erfolgsfaktoren
- Die “Commerce Reporting Standard”-Initiative von minubo und Project A, die mit ihrer Matrix der Transaktionskennzahlen Starthilfe in Sachen Datenmodell bereithält
Wenn Du Dich zur “Make or Buy”-Frage mal persönlich austauschen möchtest, melde Dich jederzeit gerne bei mir – ganz einfach per Nachricht an lennard@minubo.com. Im nächsten Artikel geht’s dann anknüpfend an den heutigen Beitrag nochmal konkret um das Thema Individualisierung.
