Eigene BI bauen oder kaufen? Die 5-Jahres-Kostenrechnung, die viele E-Commerce-Unternehmen unterschätzen

Kurz zusammengefasst:

Dieser Artikel legt die Zahlen offen: Was kostet der Aufbau und Betrieb einer eigenen BI-Infrastruktur über fünf Jahre, für ein kleines, ein mittleres und ein großes E-Commerce-Unternehmen? Und wo lohnt es sich, einzelne Bausteine einzukaufen statt selbst zu bauen? Das Ergebnis vorweg: Über 5 Jahre ist der Kauf 60 bis 66 % günstiger, je nach Unternehmensgröße eine Ersparnis zwischen 320.000 € und 767.500 €, und produktiv in Wochen statt Monaten.

Wie wir auf diese Zahlen kommen und was sie für dein Unternehmen konkret bedeuten, egal ob klein, mittel oder groß, liest du im Detail in diesem Blogbeitrag.

Make or Buy ist überall, auch in der BI

Kein Händler produziert alles selbst. Eine Modemarke designt vielleicht eigene Kollektionen. Aber sie betreibt keine eigene Textilfabrik. Sie entscheidet bewusst, wo ihre Wertschöpfung liegt und was sie einkauft.

Genau dieselbe Entscheidung steht bei Business Intelligence an: Was will ich selbst bauen, betreiben und verantworten, und was kaufe ich besser ein? Die meisten Unternehmen unterschätzen dabei einen Faktor gewaltig: die Total Cost of Ownership (TCO) einer selbstgebauten BI-Infrastruktur. Nicht, weil die Tools teuer wären. Sondern weil den Personalaufwand dahinter kaum jemand vorher durchrechnet.

1. Der Rahmen: Wer ist gemeint, und was wird verglichen?

Betrachtet wird der Aufbau und Betrieb einer eigenen BI-Infrastruktur (bestehend aus Datenpipeline/ETL, Data Warehouse und Visualisierung) über einen Zeitraum von fünf Jahren: Jahr 1 (Setup plus anteiliger Betrieb) und der laufende Vollbetrieb ab Jahr 2.

Drei Unternehmensgrößen, drei Realitäten

Ein E-Commerce-Unternehmen mit 20 Mio. € Umsatz und keinem oder einem kleinen Tech-Team hat eine andere Ausgangslage als eines mit 150 Mio. € Umsatz und einem eigenen 20-köpfigen Tech-Team. Einheitliche Zahlen wären irreführend, deshalb unterscheiden wir drei Tiers:

Gehaltsannahme (Vollkosten inkl. ~25 % Nebenkosten, DACH-Gehälter): Data Engineer, DevOps/Admin und BI Analyst/PM werden jeweils mit ~90.000 €/Jahr bei 1,0 FTE angesetzt.

2. Die Wertschöpfungskette der BI: Was muss eigentlich gebaut werden?

Bevor über Kosten gesprochen wird, lohnt der Blick auf das, was überhaupt entsteht. Stell dir deine BI wie eine Lieferkette vor: Am einen Ende stehen rohe Daten aus deinen Systemen, am anderen Ende eine Entscheidung, die ein:e Mitarbeiter:in trifft. Dazwischen liegt eine Menge Arbeit:

1. ETL / Datenpipeline: Transport und Extraktion der Rohdaten
2. Transformation / Datenmodell: Business-Logik, Kennzahlen-Definitionen
3. Data Warehouse: Speicherung und performante Abfragen
4. Visualisierung / Frontend: Dashboards, Reports
5. Nutzung und Adoption: die Menschen, die damit arbeiten

Jeder dieser Bausteine kann selbst gebaut (Make), eingekauft (Buy) oder kombiniert werden (Make and Buy). Dieser Rahmen ist wichtig, weil die Make-or-Buy-Frage selten pauschal, sondern pro Baustein beantwortet werden sollte.

3. Die TCO-Übersicht: Was kostet der vollständige Build-Ansatz?

Die folgende Tabelle zeigt die Gesamtkosten für den kompletten Eigenbau (Make), mit anteilig berechneten Personalkosten in Jahr 1, weil das Setup nicht in jedem Tier gleich lange dauert.

Wichtig: Die Personalkosten in Jahr 1 sind anteilig berechnet, weil für das Setup 3, 5 bzw. 8 Monate angenommen wurden. Erst danach läuft der Vollbetrieb. Das heißt: In Jahr 1 fallen Setup-Kosten und anteilige Betriebskosten gleichzeitig an. Das macht Jahr 1 zur teuersten Phase im gesamten Zyklus.

4. Setup-Kosten im Detail: Was passiert in den ersten Monaten?

In der Setup-Phase läuft noch kein produktiver Betrieb. Das Team ist vollständig auf den Aufbau fokussiert. Typische Tätigkeiten: Architektur-Entscheidungen, Tool-Auswahl, Konnektoren einrichten, Datenmodell bauen, erste Reports, Dokumentation.

• Data Engineer (100 %): Baut alles auf: Architektur, Pipelines, Datenmodell, Konnektoren. Sequenziell, kein Schritt ohne den vorherigen.
• BI Analyst / PM (50 %): Definiert, was gebaut werden soll: Anforderungen, Kennzahlen, erste Dashboards. Startet erst, wenn Daten fließen.
• DevOps / Admin (20 %): Richtet die Infrastruktur ein: Cloud, Zugriffsrechte, Security. Schnell erledigt, die Hauptlast kommt erst im Betrieb.
  
  

5. Tool-Kosten p.a.: Warum Tools nicht das Problem sind

Die Tool-Kosten wirken auf den ersten Blick harmlos, und das sind sie auch. Der Personalberg dahinter ist das eigentliche Thema. Also lasst uns einen Blick in Toolkosten für DWH, Datenpipeline und Visualisierung werfen

DWH (BigQuery on-demand)

Datenpipeline (ETL + Transformation)

ETL und Transformation sind technisch zwei Schritte (Transport vs. Business-Logik), werden hier zusammengefasst.

Airbyte Cloud (Klein/Mittel), Fivetran (Groß), Transformation via dbt Cloud.

Visualisierung / Frontend

 Power BI Pro (Klein/Mittel) (~10 €/User/Monat), Tableau bei Groß (Mix Creator + Viewer – konservativ angesetzt, Vollausbau Creator wäre ~22.000 €).

Einordnung: ~3.650 € p.a. für Tools beim kleinen E-Commerce-Unternehmen klingt nach wenig. Und das ist es auch. Die eigentliche Frage ist: Wer betreibt das alles? Die Antwort: Menschen.

6. Personalkosten p.a.: Der eigentliche Kostentreiber

BI ist kein Projekt, sondern ein Dauerbetrieb. Und Dauerbetrieb braucht Menschen, dauerhaft. Drei Rollen sind dafür nötig:

• Data Engineer: Datenpipelines überwachen und warten, Fehler debuggen, wenn Quellsysteme sich ändern, neue Datenquellen anbinden, Datenmodell weiterentwickeln, Datenqualität sicherstellen. Es gibt keinen Zustand, in dem „alles fertig ist": Quellsysteme ändern sich kontinuierlich.
• DevOps / Admin: Cloud-Infrastruktur betreiben und überwachen, Kosten-Monitoring, Zugriffsrechte- und User-Management, Security und Compliance (DSGVO), Updates, Incident-Management.
• BI Analyst / PM (Doppelrolle): Reports und Dashboards erstellen, Ad-hoc-Analysen für Stakeholder, Datenqualität prüfen, Kennzahlen definieren, Anforderungen priorisieren, zwischen Business und Data Engineer übersetzen, Dokumentation pflegen.

Diese Doppelrolle ist ein Single Point of Failure. Beim kleinen E-Commerce-Unternehmen ist das oft eine interne Person, die „das auch noch macht", neben ihrem eigentlichen Job. Fällt sie aus, steht die gesamte BI still.

Je nach Unternehmensgröße werden diese Rollen aber nicht als Vollzeitstelle benötigt. Genau dieses Dilemma (zu klein für eine volle Stelle, zu wichtig für gar keine) beschreibt auch Marcus Anton, CEO der GOLDNER Fashion Group, aus eigener Erfahrung, als er über den Aufbau einer komplett eigenen Datenarchitektur nachdachte, die auch an den Realitäten des Arbeitsmarktes scheitern würde :

„Wir wollten eine komplette eigene Architektur aufbauen und sind nicht zuletzt aufgrund personeller Themen sofort zurückgeschreckt. Wir haben gesehen, wie schwer es ist, ein Team in entsprechenden Größenordnungen für so ein Projekt dauerhaft zu staffen. Wenn du ein Cloud-Setup haben willst, brauchst du keinen Vollzeit-Admin – aber versuch mal, eine 0,1-FTE-Stelle einzustellen."

Genau das ist der Kern des Personalproblems bei Eigenbau-BI: Die Aufgaben sind real und dauerhaft, aber sie lassen sich nicht in ordentliche, besetzbare Stellenprofile packen. Wie GOLDNER diesen Konflikt gelöst hat, ohne auf Datenhoheit zu verzichten, zeigt die Case Study „GOLDNER Fashion: AI-ready Datenarchitektur". Ein guter nächster Schritt, wenn dir dieses Dilemma aus dem eigenen Team bekannt vorkommt.

7. Der Eisberg: Was in den Zahlen nicht steckt

Die Euro-Beträge oben sind die Spitze des Eisbergs. Was darunter liegt, ist schwerer zu beziffern, aber potenziell größer als alle sichtbaren Kosten zusammen.

Versteckte Folgekosten im Betrieb

• Analyst braucht länger für Reports → höhere laufende Personalkosten
• Kein sauberer Semantic Layer → LLM-/KI-Integration nicht möglich
• Dokumentationsschuld wächst mit der Zeit
• BI konkurriert mit Webshop, Marketing-Tools und Co. und verliert strukturell, weil BI keinen direkt sichtbaren Revenue-Beitrag liefert
• Stagnierender Stack durch kontinuierliche Priorisierungskonflikte

Adoption-Kollaps (schwerwiegendster Fall)

• Schlechte UX oder Datenfehler → Vertrauensverlust bei Mitarbeitenden
• Rückfall auf Excel: Das Tool wird nicht mehr genutzt
• Macht alle vorherigen Investitionen faktisch wertlos

Diese Zahlen aus Abschnitt 3 gelten nur, wenn alles klappt: kein Adoption-Kollaps, kein schlechtes Datenmodell, keine Priorisierungskonflikte. In der Praxis ist genau das die Ausnahme, nicht die Regel.

8. Make or Buy: Zurück zur Wertschöpfungsfrage

Die Frage ist nicht „Baue ich alles selbst?". Die Frage ist: Wo liegt meine Differenzierung, und was kaufe ich besser ein?

Es gibt keinen Baustein, bei dem „Make" per se falsch ist. Aber für jeden Baustein sollte die Entscheidung bewusst getroffen werden, mit Blick auf Kosten, Risiko und Differenzierungspotenzial.

9. Der Zeit-Faktor: Was die TCO-Tabelle nicht zeigt

Kosten sind das eine. Zeit bis zur Produktivität ist oft der entscheidende Faktor und wird fast immer unterschätzt.

Make: Monate bis Jahre bis zur vollen Funktionalität

Die folgenden Werte sind Modellannahmen auf Basis typischer Projektverläufe plus Erfahrungswerte aus unseren Kundengesprächen bei mittelständischen E-Commerce-Unternehmen, keine Ergebnisse einer repräsentativen Studie.

So kommt die Zeile "Verlässliche, vertrauenswürdige Zahlen" zustande: Sie baut auf der Zeile "Erste stabile Reports" auf und addiert einen Puffer für Validierung und Vertrauensaufbau, also mehrere vollständige Reporting-Zyklen ohne größere Korrekturen, den Abgleich alter gegen neue Zahlen und das Beheben von Datenqualitätsproblemen, die erst im laufenden Betrieb sichtbar werden. Beim kleinen E-Commerce-Unternehmen zum Beispiel: Setup (~3 Monate) plus erste stabile Reports (+2–3 Monate) ergibt 5–6 Monate, danach kommen weitere Monate der Validierung hinzu, bis die Zahlen als verlässlich gelten, macht in Summe 6–12 Monate. Auch diese Bandbreite ist eine Modellannahme, keine feste Formel: Wie schnell Zahlen wirklich als vertrauenswürdig gelten, hängt stark von der Datenqualität der Quellsysteme und der Sorgfalt im Datenmodell ab.

So kommt die Zeile "Volle Funktionalität" zustande: Sie ist keine eigene Schätzung, sondern die Summe aus den zwei entscheidenden Etappen darüber: dem Zeitpunkt, ab dem verlässliche Zahlen vorliegen, plus der Zeit, bis diese Zahlen von der breiten Belegschaft im Alltag genutzt werden. Beim kleinen E-Commerce-Unternehmen zum Beispiel: 6–12 Monate bis zu verlässlichen Zahlen plus weitere 6–12 Monate bis zur breiten Adoption ergibt 12–24 Monate bis zur vollen Funktionalität. "Volle Funktionalität" bedeutet also nicht "erster Report ist fertig", sondern der Punkt, an dem die BI-Infrastruktur tatsächlich im Tagesgeschäft ankommt: verlässliche Zahlen, die von allen relevanten Teams genutzt und nicht mehr infrage gestellt werden.

In dieser Zeit: kein datengetriebenes Arbeiten, keine KI-gestützten Analysen, keine skalierbaren Reports, bei gleichzeitig laufenden Personalkosten.

Kauflösungen: Monate statt Jahre bis zur Produktivität. Setup-Dauer je nach Unternehmensgröße ~1–2 Monate (klein), ~3–4 Monate (mittel) bzw. ~4–6 Monate (groß). Der Rest (Datenmodell, Kennzahlen, Frontend) ist bereits fertig, und Mitarbeiter-Onboarding läuft parallel dazu.

10. Eine Lösung für jede Infrastruktur: Der modular-hybride Ansatz

Eingekaufte BI ist keine Entweder-oder-Entscheidung und kein Komplettpaket, das zwingend als Ganzes gekauft werden muss. Wer bestehende Tools oder Strukturen hat, muss diese nicht aufgeben. minubo bietet dafür drei Produktstufen, passend zur eigenen Infrastruktur:

Alle drei Produkte teilen sich dieselbe Basis: 800+ E-Commerce-Kennzahlen inkl. konsistenter Logiken und KI-Ready-Semantik, zuverlässige Extraktion aller relevanten E-Commerce-Quellen ohne eigenes Team und Anschlussfähigkeit ohne Vendor-Lock-in (Easy Connect zu Power BI, ChatGPT, Claude, n8n und mehr).

Hinweis zur TCO-Berechnung: Die Kostenvergleiche in diesem Artikel beziehen sich auf die minubo Suite als Gesamtpaket. Wer mit minubo DWH oder minubo Data einsteigt, zahlt entsprechend weniger. Die Logik bleibt dieselbe: Je mehr Bausteine eingekauft werden, desto geringer der interne Personalaufwand.

Wie ein solcher hybrider Ansatz in der Praxis funktioniert, zeigt wieder GOLDNER: Statt alles selbst zu bauen oder komplett extern zu vergeben, hat sich das Unternehmen für einen modular-hybriden Weg entschieden. Der datentechnische Kern (Extraktion, Aufbereitung, Modellierung) läuft standardisiert über minubo, während das GOLDNER-Team die volle Kontrolle über wettbewerbsentscheidende Custom-Logiken behält. Marcus Anton beschreibt das Ziel so:

„Wir wollten weg von 80/20 Mantainace hin zu 20/80 – damit das Team die Kraft, die es hat, in die Entwicklung reinstecken kann."

Wer verstehen will, wie sich Standardisierung und Individualität architektonisch sauber trennen lassen, findet die technischen Details (von der Orchestrierung über das Bronze-/Silver-/Gold-Prinzip bis zur Data API für LLM-Zugriffe) in der Case Study „GOLDNER Fashion: AI-ready Datenarchitektur".

11. Der direkte Kostenvergleich: Build vs. minubo Suite

Jetzt kommen wir zum Herzstück des Artikels. Die Tabelle macht auf einen Blick sichtbar, wie viel günstiger und wie viel schneller der Kauf-Ansatz sein kann.

Annahmen zur minubo-Personalzeile: In der Onboarding-Phase wird für Koordination und Anforderungsmanagement anteilig eine 0,5-FTE-Projektleitung angesetzt (gleiche Gehaltslogik, ~90.000 €/Jahr bei 1,0 FTE). Im laufenden Betrieb ist kein dauerhafter interner Personalaufwand für den Betrieb der Infrastruktur eingerechnet: Die infrastrukturnahen Aufgaben, die beim Build-Ansatz zur BI-Analyst/PM-Rolle gehören (Kennzahlen definieren, Dashboards und Reports bauen, Datenqualität prüfen, Dokumentation pflegen), übernimmt bei minubo der Anbieter. Was übrig bleibt, ist die eigentliche Business-Analyse, also das inhaltliche Auswerten und Interpretieren der Zahlen durch den Fachbereich. Dieser Aufwand fällt bei Make und Buy gleichermaßen an und wird deshalb bewusst aus dem Vergleich herausgehalten.

Kernaussagen aus der Tabelle:

• Über alle drei Unternehmensgrößen hinweg ist die minubo Suite im Jahr 1 zwischen 48 % und 61 % günstiger als der Build-Ansatz.

• Ab Jahr 2 liegt die laufende Ersparnis bei 63 % bis 68 %, trotz höherer Lizenzkosten, weil der Personalaufwand massiv sinkt.

• Über 5 Jahre summiert sich die Ersparnis auf 60 % bis 66 % der Gesamtkosten.

• Der Hebel ist nicht die Lizenz, sondern das wegfallende Personal: kein Data Engineer im Vollbetrieb, kein DevOps, kein BI-PM-Aufwand für Infrastruktur.

• Dazu kommt der Zeitvorteil: Kauflösungen sind bereits nach 1 bis 6 Monaten produktiv, der Build-Ansatz braucht 6 bis 24 Monate bis zur vollen Funktionalität, also bis Zahlen von der breiten Belegschaft im Alltag genutzt werden können.

• Und es geht nicht nur um Kosten, sondern um Risiko: Ein Eigenbau kann an genau den Faktoren aus Abschnitt 7 scheitern (Adoption, Datenmodell-Qualität, Priorisierung), eine eingekaufte Lösung ist bereits produktiv erprobt.

Abb. 1: Gesamtkosten über 5 Jahre, Eigenbau vs. minubo Suite, nach Unternehmensgröße.

Nicht vergessen: Jede Woche ohne datengetriebenes Arbeiten hat einen Preis, der in keiner Tabelle auftaucht: entgangene Entscheidungssicherheit, verpasste Marge, liegengelassene Automatisierungspotenziale.

12. Fazit: Drei Fragen, die du dir stellen solltest

Statt eines klassischen Fazits: ein konkreter Entscheidungsrahmen für dich.

Frage 1: Wo liegt meine Differenzierung? Welche BI-Bausteine sind wirklich einzigartig für mein Geschäft, und welche sind Commodity?

Frage 2: Was kann ich realistisch ownen? Habe ich das Team, die Zeit und die Priorisierungskraft, um BI dauerhaft intern zu betreiben und Mitarbeitende zur Nutzung zu bringen?

Frage 3: Was kostet mich jede Woche ohne produktive BI? Nicht nur in Euro, sondern in Entscheidungen, die ohne verlässliche Datenbasis getroffen werden.

Make or Buy ist keine Grundsatzentscheidung, es ist eine Frage pro Baustein. Und die Antwort darf sich mit deinem Unternehmen verändern. Was nicht variabel sein sollte: der Anspruch, so schnell wie möglich datengetrieben zu arbeiten.

Lass uns gemeinsam durchgehen, welche Bausteine für dich Sinn machen.

Häufige Fragen (FAQ) noch einmal auf den Punkt gebracht

Was kostet eine eigene BI-Infrastruktur im ersten Jahr? Je nach Unternehmensgröße zwischen ~108.150 € (kleines E-Commerce-Unternehmen, ~20 Mio. € Umsatz) und ~257.000 € (großes E-Commerce-Unternehmen, ~150 Mio. € Umsatz), inklusive Setup-Kosten, Tools und anteiligen Personalkosten.

Wie viele Vollzeitstellen bindet eine eigene BI-Infrastruktur dauerhaft? Im Vollbetrieb ab Jahr 2 sind es 1,0 FTE beim kleinen, 1,75 FTE beim mittleren und 2,5 FTE beim großen E-Commerce-Unternehmen, verteilt auf Data Engineer, DevOps/Admin und BI Analyst/PM.

Wie lange dauert der Aufbau einer eigenen BI-Infrastruktur bis zur vollen Funktionalität? Realistisch zwischen 12–24 Monaten (klein), 18–30 Monaten (mittel) und 24–36 Monaten (groß), von der ersten Architektur-Entscheidung bis zu breiter Mitarbeiter-Adoption.

Lohnt sich der Eigenbau einer BI-Infrastruktur überhaupt? Für Unternehmen, deren Kerngeschäft nicht Datenverarbeitung ist, selten. Der Personalaufwand für Betrieb und Pflege übersteigt über 5 Jahre die Kosten einer eingekauften Lösung um 60 bis 66 %, bei deutlich längerer Zeit bis zur Produktivität. Sinnvoller ist meist ein hybrider Ansatz: Standardisierte Basics einkaufen, Differenzierung selbst bauen.

Quellen für externe Tool-Preise: Google BigQuery Pricing, Airbyte Cloud Pricing, Fivetran Pricing, dbt Cloud Pricing, Microsoft Power BI Pricing, Tableau Pricing (Stand der Kalkulation: Juni 2026).