Make or Buy in der Produktentwicklung

Kaum eine Frage beschäftigt Produktteams so sehr wie die Make-or-Buy-Entscheidung: Bauen wir ein Feature selbst, oder kaufen wir eine bestehende Lösung dazu? Die Antwort ist selten eindeutisch, aber wer sie systematisch angeht, spart Zeit, Geld und vermeidet technische Schulden.

Das Kernproblem

Jedes Feature, das du selbst entwickelst, bindet Kapazitäten, die du nicht in dein Kernprodukt stecken kannst. Jedes Feature, das du zukaufst, schafft Abhängigkeiten, die du später vielleicht bereust. Die Kunst liegt darin, die richtige Balance zu finden.

Praxisbeispiel: Personensuche in einem Versicherungs-Partnersystem

Ein aktuelles Projekt aus der Versicherungsbranche zeigt, wie komplex Make-or-Buy-Entscheidungen in der Realität sind.

Die Ausgangslage: Ein großer Versicherungskonzern betreibt ein Partnersystem, das alle Geschäftsbeziehungen abbildet – Kunden, Vertragspartner, Zeugen, Partnerfirmen und interne Organisationseinheiten. Eine neue Anforderung lautet: Die Partner sollen über eine Personensuche (Name, Geburtsdatum, Adresse, Rolle) im System schnell und zuverlässig gefunden werden können.

Das eigentliche Problem: Das zugrundeliegende Datenmodell ist ein Historienschwebe-Konzept – jede Entität wird über mehrere Versionen und Zeiträume abgebildet. Wer war wann in welcher Rolle aktiv? Welche Adresse galt zu welchem Zeitpunkt? Das Modell ist für korrekte Historienführung optimiert – nicht für Suche. Eine einfache Volltextsuche greift hier zu kurz, weil der relevante Datensatz vom Kontext abhängt (Zeitraum, Rolle, Beziehungstyp).

Hinzu kommt: Die Fachseite ist unsicher, ob komplexe Suchfunktionen wie Fuzzy-Suche oder phonetische Suche den Endanwendern tatsächlich einen Mehrwert bieten. Oft ist das Finden des richtigen Partners weniger ein technisches Suchproblem als eine Frage des korrekten Kontexts – und hier stößt jedes allgemeine Suchtool an seine Grenzen.

Die Make-Option: Eine eigene Suchkomponente entwickeln, die das Historienschwebe-Modell versteht, die Daten gezielt für die Suche aufbereitet und eine an die Fachdomäne angepasste Oberfläche bietet.

Die Buy-Option: Ein im Versicherungsumfeld etabliertes Identity-Resolution- oder Master-Data-Management-Tool integrieren, das bereits mit historischen Personenmodellen umgehen kann.

Entscheidungskriterien im Überblick

Kernkompetenz

Frage: Ist die Suchfunktion Teil deines Produktversprechens? Wenn dein Produkt eine Suchplattform ist, dann ja. Wenn es ein Versicherungsverwaltungssystem ist, dann nein – die Suche ist ein unterstützendes Feature.

Bei unserem Versicherungskunden ist die Personensuche ein Hilfsmittel, nicht das Kernprodukt. Das spricht für Buy.

Entwicklungs- und Betriebskosten

Die Kosten für eine Eigenentwicklung werden häufig unterschätzt:

• Initialentwicklung: Datenmodell-Analyse, Aufbereitung der Historienschwebe, Indexierung, API, UI – schnell 8-12 Wochen
• Testen: Korrektheit der historischen Ergebnisse, Grenzfälle bei Rollenwechseln – aufwändiger als eine reine Volltextsuche
• Betrieb: Der Suchindex muss bei jeder Datenmodell-Änderung gepflegt werden
• Wartung: Neue Beziehungstypen oder Rollen erfordern Anpassungen der Suchlogik

Eine Buy-Lösung kostet monatliche Lizenzgebühren, dafür sind Entwicklung und Betrieb beim Anbieter – allerdings nur, wenn der Anbieter das Historienschwebe-Modell abbilden kann.

Time-to-Market

In der Versicherungswelt sind regulatorische Vorgaben oft der Treiber. Wenn die Personensuche in drei Monaten live sein muss, ist Buy meist der einzige Weg. Eine Eigenentwicklung ist planbar, aber du trägst das volle Risiko.

Integration und Abhängigkeiten

Buy-Lösungen kommen mit eigenen APIs, Datenformaten und Vertragsbedingungen. Ein Anbieterwechsel kann teuer werden. Make-Lösungen geben dir die volle Kontrolle – aber auch die volle Verantwortung.

In unserem Fall zeigt sich: Keines der Standardprodukte bildet das Historienschwebe-Konzept zufriedenstellend ab. Der Kunde steht vor der Wahl, entweder ein Buy-Produkt anzupassen (was die Wartbarkeit verschlechtert) oder ein eigenes Such-Feature zu bauen (was Ressourcen bindet). Eine finale Entscheidung steht noch aus.

Wann Make die richtige Wahl ist

• Das Feature ist deine Kernkompetenz und differenziert dein Produkt vom Wettbewerb
• Du hast das Team und die Zeit für Entwicklung und Betrieb
• Die Anforderungen sind so spezifisch, dass kein Standardprodukt passt – wie im Beispiel das Historienschwebe-Modell
• Du willst keine Abhängigkeit von einem Drittanbieter eingehen

Wann Buy die richtige Wahl ist

• Das Feature ist unterstützend und nicht Teil deines Produktversprechens
• Es gibt etablierte Anbieter, die die Domäne bereits abdecken
• Die Time-to-Market ist kritisch
• Du willst Entwickler-Kapazität auf das Kernprodukt konzentrieren

Der hybride Weg

Oft ist die beste Antwort nicht Make oder Buy, sondern eine Kombination. Ein Standardprodukt für die Basis, ergänzt um domänenspezifische Eigenentwicklung für das, was den wirklichen Unterschied macht. Wichtig ist, die Grenze sauber zu ziehen: Der Suchindex selbst kann zugekauft sein – die Logik, die dein Datenmodell versteht, ist der Teil, den du selbst bauen musst.

Entscheidungsmatrix

Ich empfehle ein einfaches Raster:

Zähle die Bewertung pro Spalte zusammen. Meist zeigt sich schnell, welche Richtung die richtige ist.

Fazit

Die Make-or-Buy-Frage stellt sich in jedem Produktteam immer wieder. Der wichtigste Rat: Sei ehrlich zu dir selbst, ob ein Feature wirklich deine Kernkompetenz betrifft. Viel zu oft wird "Make" gewählt, weil es sich kontrollierter anfühlt – dabei bindet es Ressourcen, die an anderer Stelle dringend gebraucht werden.

Im Zweifel: Kauf dazu, was nicht dein Kernprodukt ist. Aber unterschätze nicht die Domänenkomplexität – manchmal führt kein Weg an einer Eigenentwicklung vorbei, wenn die fachlichen Anforderungen zu spezifisch sind.