Make or Buy: Standardsoftware kaufen oder Individualsoftware bauen?

Make or Buy ist die älteste Frage der Unternehmens-IT — und sie wird fast immer falsch gestellt. Denn in der Praxis lautet die Antwort selten „kaufen“ oder „bauen“. Sie lautet: kaufen, und die Lücke schließen.

Das klassische Make-or-Buy stammt aus der Fertigung: Zylinderkopf selbst gießen oder zuliefern lassen? Bei Software führt diese Entweder-oder-Logik in die Irre, weil Software sich kombinieren lässt. Niemand muss DATEV nachbauen, um einen DATEV-Prozess zu verbessern. Aber genau das steht — sinngemäß — in erstaunlich vielen Anforderungsdokumenten, die wir zu sehen bekommen.

Wir haben diese Debatte seit 2018 auf vielen Tischen gesehen — in Kanzleien, in Handwerksbetrieben, im Maschinenbau. Dabei fällt auf: Die Entscheidung wird selten rational getroffen. Mal treibt die Angst vor Abhängigkeit Richtung Eigenbau, mal drückt die IT-Leitung Richtung Standard, weil sie den Wartungsaufwand fürchtet. Beides sind legitime Sorgen — aber keine Entscheidungsgrundlage. Deshalb haben wir die Frage in vier prüfbare Teilfragen zerlegt.

Vier Fragen, die die Entscheidung tragen

Wenn bei uns eine Make-or-Buy-Frage auf dem Tisch liegt, gehen wir vier Fragen durch. In dieser Reihenfolge, weil jede Frage die nächste überflüssig machen kann.

1. Ist der Prozess Commodity oder differenzierend? Buchhaltung, Lohn, E-Mail: Commodity — hier gewinnt praktisch immer Buy. Der Prozess dagegen, mit dem ihr euch vom Wettbewerb unterscheidet, ist ein Make-Kandidat. Wer sein Differenzierungsmerkmal aus der Standard-Schublade nimmt, hat per Definition keines.
2. Deckt Standardsoftware mindestens 80 % ab? Und — wichtiger — sind die fehlenden 20 % verhandelbar? Manchmal ist es billiger, den eigenen Prozess ans Werkzeug anzupassen als umgekehrt. Manchmal sind die 20 % aber genau der Teil, an dem das Geschäft hängt.
3. Wie stabil ist der Prozess? Eigenbau lohnt sich für Prozesse, die sich eingeschwungen haben. Was sich quartalsweise neu erfindet, ist bei konfigurierbarer Standardsoftware besser aufgehoben.
4. Was kostet die Lücke pro Woche? Erst diese Zahl macht die Diskussion ehrlich. Eine Lücke, die zehn Stunden Handarbeit pro Woche kostet, rechtfertigt anderes Geld als eine, die einmal im Monat nervt.

Die vier Fragen klingen simpel, aber sie erledigen die meisten Diskussionen erstaunlich schnell. In der Praxis scheitern Make-or-Buy-Debatten nämlich selten an fehlender Analyse — sie scheitern daran, dass Frage eins nie gestellt wurde. Wenn ein Unternehmen erst einmal ausgesprochen hat, dass seine Lohnabrechnung kein Differenzierungsmerkmal ist, löst sich die Hälfte des Anforderungsdokuments von selbst auf.

Der dritte Weg, der im Lehrbuch fehlt

Die meisten realen Fälle, die wir seit 2018 gesehen haben, sind weder Make noch Buy. Das Standardsystem steht längst — SAP, DATEV, Shopware, ein Branchen-ERP — und es funktioniert im Kern. Was fehlt, ist ein Stück. Drei Muster aus echten Anfragen:

• SAP Business One läuft seit Jahren, aber die Außendienst-Mitarbeiter tippen Aufträge abends in Excel ab, weil das Modul keine Offline-Erfassung hat. Die Antwort war nicht „SAP ersetzen“, sondern eine kleine Erfassungs-App, die über die offizielle Schnittstelle in SAP schreibt.
• Ein Shopware-Shop mit Standard-Lageranbindung, aber kundenspezifischer Preislogik: Staffeln, Vertragsrabatte, individuelle Konditionen. Statt den Shop umzubauen: eine schlanke Preis-Engine als API-Schicht davor. Der Shop selbst blieb unangetastet.
• Eine Steuerkanzlei mit DATEV, deren Mandanten Belege per WhatsApp und Mail schicken — jemand ordnet jeden Beleg manuell zu und benennt ihn um. Die Lösung ist ein Importer, der liest, zuordnet und nach DATEV lädt. Wie so eine Dokumenten-Automatisierung arbeitet, haben wir separat beschrieben.

In allen drei Fällen blieb das gekaufte System die Basis — und ein kleines, eigenes Stück Software hat die Lücke geschlossen. Kostenpunkt: Patch- oder Modul-Größe, nicht Plattform. Das ist fast immer eine Größenordnung günstiger als der Ersatz des Systems, und es riskiert nichts von dem, was bereits funktioniert.

Der dritte Weg hat einen Nebeneffekt, den wir anfangs unterschätzt haben: Er ist reversibel. Wer neben dem System baut, kann das kleine Werkzeug ersetzen, erweitern oder abschalten, ohne dass das Kerngeschäft davon etwas merkt. Wer sein System ersetzt hat, hat diese Option nicht mehr — Migration ist eine Einbahnstraße.

Wann Buy klar gewinnt

Damit das nicht falsch verstanden wird: Wir verdienen unser Geld mit Individualsoftware — und trotzdem beginnt unsere Beratung oft mit „kauft das“. Die klaren Buy-Fälle:

• Der Prozess ist Commodity und branchenweit gleich — Buchhaltung, Lohn, Kalender, E-Mail.
• Ein etablierter Anbieter trägt die Compliance-Last mit: GoBD, DSGVO, zertifizierte Schnittstellen.
• Ihr braucht das Ergebnis in Wochen, und der Prozess lässt sich zumutbar an die Software anpassen.
• Das eigentliche Problem ist Bedienkomfort, nicht fehlende Funktion — das löst neue Software ohnehin nicht.

Wann Make gewinnt

Auf der anderen Seite gibt es Konstellationen, in denen Standardsoftware auf Dauer die teurere und schwächere Wahl ist:

• Der Prozess ist euer Differenzierungsmerkmal — das, wofür Kunden euch statt den Wettbewerb wählen.
• Die Lücke kostet messbar Stunden pro Woche, und kein Anbieter hat sie im Programm.
• Standardsoftware würde nur mit tiefem Customizing passen — und tief customizte Standardsoftware ist die teuerste Form von Individualsoftware, mit Update-Schmerz obendrauf.
• Ihr wollt Daten und Code besitzen, ohne Lizenz-Lock-in und ohne Anbieter-Abhängigkeit.

Die Fünf-Jahres-Rechnung, die beide Lager vergessen

Der häufigste Fehler auf der Buy-Seite: Lizenzkosten werden als einmalig gedacht. Sind sie nicht. Pro Nutzer, pro Monat, jedes Jahr ein bisschen teurer — über fünf Jahre kommt bei dreißig Nutzern schnell eine sechsstellige Summe zusammen, für Software, die euch am Ende trotzdem nicht gehört. Dazu kommen die stillen Posten: Customizing-Dienstleister, Schulungen und die Arbeitszeit, mit der euer Team die verbleibenden Lücken manuell überbrückt.

Der häufigste Fehler auf der Make-Seite: Der Bau wird als Endpunkt gedacht. Ist er nicht. Software lebt — Hosting, Sicherheits-Updates, Anpassungen, wenn sich ein angebundenes System ändert. Wer Individualsoftware kalkuliert, sollte Pflege von Anfang an als jährlichen Posten einplanen. Ehrlich verglichen wird also nie „Kaufpreis gegen Baupreis“, sondern: fünf Jahre Gesamtkosten gegen fünf Jahre Gesamtkosten — inklusive der Handarbeit, die jede offene Lücke Woche für Woche kostet.

Wir dachten, wir brauchen ein neues ERP. Wir brauchten eine App fürs Lager und zwei Schnittstellen.Sinngemäß aus mehreren Erstgesprächen der letzten Jahre

Ein Wort zu tiefem Customizing

Der teuerste Weg ist fast immer der scheinbare Kompromiss: Standardsoftware kaufen und sie dann so lange verbiegen, bis sie passt. Damit holt man sich die Nachteile beider Welten ins Haus — man bezahlt Lizenz und Entwicklung, besitzt den Code trotzdem nicht, und jedes Hersteller-Update wird zur Zitterpartie, weil niemand weiß, ob die eigenen Anpassungen es überleben. Wenn die nötigen Anpassungen über Konfiguration hinausgehen, ist das für uns das deutlichste Signal, die Lücke außerhalb des Systems zu schließen — daneben, über die offizielle Schnittstelle, mit eigenem Code.

Unsere Empfehlung als Reihenfolge

1. Kaufen, was Commodity ist — und zwar so unverbogen wie möglich.
2. Konfigurieren statt customizen. Jede tiefe Anpassung an Standardsoftware bezahlt ihr bei jedem Update erneut.
3. Lücken schließen mit kleinen, eigenen Werkzeugen neben dem System — über die offiziellen Schnittstellen.
4. Bauen nur, was euch unterscheidet — dann aber richtig: mit Discovery vorab und eigenem Code-Besitz.

Diese Reihenfolge ist unspektakulär, und genau das ist der Punkt. Sie verhindert die beiden teuren Extreme: das Fünf-Jahres-Projekt „neues ERP“, das am Ende doch wieder Lücken hat — und den Wildwuchs aus zwanzig Insellösungen, die niemand mehr wartet. Dazwischen liegt ein Portfolio aus gekauftem Fundament und wenigen, gezielten Eigenbauten. Das ist bei fast allen unserer Kunden das Zielbild.

Wie wir solche Projekte in drei Größen denken — Patch, Modul, Plattform, mit öffentlichen Preisspannen — steht auf unserer Studio-Seite. Und falls ihr gerade vor genau dieser Entscheidung steht: Im ersten Gespräch beantwortet sich Make-or-Buy meistens von selbst.