Build vs. Buy: Wie Finanzteams die Entscheidung in der Praxis treffen

Das Versprechen der Eigenentwicklung

Wir alle kennen das Szenario: Ein internes Tool funktioniert nicht richtig, die IT-Abteilung schlägt vor, „etwas Eigenes“ zu bauen, und das Management nickt – weil es sich nach Kontrolle, Flexibilität und Unabhängigkeit anhört.

Die Argumente sind immer dieselben: „Wir wissen am besten, was wir brauchen.“ „Keine Software passt zu 100%.“ „Langfristig sparen wir Lizenzkosten.“ Wie sieht das in der Praxis aus?

Was die Zahlen zeigen

Laut der Standish Group sind nur 31% aller individuellen IT-Projekte erfolgreich – gemessen an Zeit, Budget und Funktionsumfang. Gartner beziffert die Gesamtkosten: Für jeden Euro, der in die Entwicklung fließt, fallen 4–5 Euro für Wartung und Weiterentwicklung an.

Auch große Unternehmen mit entsprechenden Budgets sind davor nicht geschützt: Lidl investierte über sieben Jahre mehr als €500 Mio. in eine SAP-Eigenanpassung – und ersetzte sie am Ende durch eine Standardlösung. Nike verlor über $100 Mio. durch eine so stark angepasste Planungssoftware, dass sie wie ein Eigenbau scheiterte.

Werner Vogels, CTO von Amazon Web Services

„Stop spending money on undifferentiated heavy lifting.“ – Was kein Differenzierungsmerkmal gegenüber dem Wettbewerb ist, kann eingekauft werden.

Die versteckten Kosten des Eigenbaus

Die Entwicklungskosten sind nur die Spitze des Eisbergs:

Wartungskosten

15–20% der Entwicklungskosten – jährlich. Ein System für €500.000 kostet danach €75.000–100.000 pro Jahr.

Personalrisiko

Die Entwickler:innen, die das System gebaut haben, verlassen das Unternehmen. Das Wissen geht mit – und das System wird zur Black Box.

Opportunitätskosten

Alle Entwickler:innen, die an einem internen Finance-Tool arbeiten, fehlen beim eigentlichen Produkt.

Regulatorisches Risiko

E-Invoicing-Pflicht, GoBD-Updates, DSGVO-Änderungen – jede regulatorische Änderung muss selbst umgesetzt werden.

Build vs. Buy im direkten Vergleich

Kriterium	Eigenentwicklung	Spezialisierte Lösung
Time to Value	12–24 Monate	Wochen bis wenige Monate
Erfolgsquote	31% (Standish Group)	Bewiesenes Produkt am Markt
Wartung	15–20% p.a. + eigenes Team	Im Preis enthalten
Regulatorik	Jede Änderung selbst umsetzen	Proaktive Updates vom Anbieter
Gesamtkosten (5 Jahre)	4–5x der Entwicklungskosten	Planbare Lizenzkosten

Die Falle des lokalen Maximums

Hinter vielen Build-Entscheidungen steckt ein Muster, das in der Optimierung als „lokales Maximum“ bekannt ist: Ein bestehendes System wird über Jahre hinweg verbessert – neue Skripte, mehr Workarounds, zusätzliche Schnittstellen. Jede einzelne Verbesserung ist nachvollziehbar. Aber in Summe entsteht ein immer komplexeres Gebilde, das sich nur noch schwer verändern lässt.

Das Problem: Inkrementelle Verbesserungen können nicht über einen bestimmten Punkt hinausführen. Wer ein Excel-basiertes Abstimmungssystem immer weiter automatisiert, wird irgendwann an eine Grenze stoßen – egal wie viel Entwicklungszeit investiert wird. Der Sprung zu einer grundsätzlich anderen Architektur (etwa einem System, das Belege nativ versteht statt Zellen zu parsen) erfordert, das lokale Maximum zu verlassen.

Genau das fällt schwer. Das bestehende System funktioniert ja – irgendwie. Es hat Jahre an Anpassungen hinter sich. Alle kennen es. Der Wechsel fühlt sich riskant an, obwohl das eigentliche Risiko darin liegt, auf einem Plateau stehenzubleiben, während sich der Markt weiterbewegt.

Typisches Warnsignal

„Wir sind zu komplex für eine Standardlösung.“ – In vielen Fällen ist das nicht echte Komplexität, sondern Prozessschulden: historisch gewachsene Sonderlösungen, die nie bereinigt wurden. Die wirklich individuellen Teile einer Finanzabteilung (strategische FP&A-Arbeit, Bewertungsentscheidungen) sind typischerweise die, die menschliches Urteilsvermögen erfordern – nicht Automatisierung.

Wann Eigenentwicklung Sinn ergibt

Gartner formuliert dafür eine einfache Regel: Nur dann selbst bauen, wenn zwei Bedingungen gleichzeitig erfüllt sind:

Es ist Kern des Wettbewerbsvorteils

Kund:innen wählen das Produkt wegen genau dieser Fähigkeit.

Es gibt keine passende Lösung am Markt

Bei Finanzprozessen kommt das extrem selten vor – es bräuchte schon eine echte Nischenanforderung, die kein spezialisierter Anbieter abdeckt.

Argumente für den Eigenbau

Zwei Einwände gegen den Einkauf, die berechtigt sind:

Datensouveränität

Finanzdaten gehören zu den sensibelsten Datenkategorien. Aber: Wer intern automatisiert, braucht ebenfalls LLMs – und schickt die gleichen Daten an OpenAI, Anthropic oder Google. Spezialisierte Anbieter bieten hier oft dedizierte Instanzen, EU-Hosting und AVV-Verträge als Kernprodukt.

Abhängigkeit vom Anbieter

Ein Anbieter kann übernommen werden, Preise erhöhen oder sein Produkt einstellen. Offene Datenformate und Exportmöglichkeiten reduzieren dieses Risiko erheblich.

Drei Fragen, die bei der Entscheidung helfen

Ist dieser Prozess ein echter Wettbewerbsvorteil – oder notwendige Arbeit, die keinen Unterschied zum Wettbewerb macht?

Haben wir die Kapazität, dieses System über Jahre hinweg zu warten und regulatorisch aktuell zu halten?

Was könnten unsere Entwickler:innen stattdessen bauen, das tatsächlich Umsatz generiert oder Kund:innen bindet?

Fazit

Für standardisierte Finanzprozesse wie Rechnungseingang, Abstimmung und Reporting zeigen die Zahlen ein klares Muster: Der Aufwand für Eigenentwicklung liegt oft deutlich über den Erwartungen. Gleichzeitig besteht die Gefahr, ein lokales Maximum zu optimieren, statt den Sprung zu einer grundlegend besseren Lösung zu machen.

Das heißt nicht, dass Eigenentwicklung nie funktioniert – es heißt, dass die Ressourcen an anderer Stelle möglicherweise mehr Wirkung entfalten.