Make or Buy bei Software: Wann sich Eigenentwicklung im Mittelstand lohnt
Selbst bauen oder kaufen? Die Entscheidung hängt weniger vom Können ab als von Differenzierung und laufenden Kosten. Sechs Kriterien, eine Fünf-Jahres-Rechnung und der dritte Weg aus Standard plus Ergänzung.
Von Oktay Sönmez
Ein Großhändler braucht ein Werkzeug für die Tourenplanung seiner Fahrer. Der Vertriebsleiter hat drei Standardlösungen angesehen, keine passt genau. Der IT-Leiter schlägt vor, es selbst zu bauen, ein Entwickler sei ja da. Zwei Jahre später existiert eine Anwendung, die nur dieser eine Entwickler versteht, und der hat gekündigt. Die Entscheidung zwischen Eigenentwicklung und Kauf gehört zu den folgenreichsten in der IT eines Mittelständlers, und sie wird oft aus dem Bauch getroffen. Dabei lässt sie sich mit wenigen Kriterien sauber treffen.
Die eigentliche Frage: Was unterscheidet uns
Software lohnt sich selbst zu bauen, wenn sie etwas abbildet, das das Unternehmen von Wettbewerbern unterscheidet und das keine Standardlösung in dieser Form leistet. Ein Konfigurator, der die eigene Produktlogik abbildet, eine Kalkulation mit Regeln, die über Jahre entstanden sind, ein Kundenportal, das die eigenen Prozesse spiegelt. Für alles andere, also Buchhaltung, Lohnabrechnung, E-Mail, Dokumentenablage, Zeiterfassung oder Standard-CRM, gibt es ausgereifte Produkte, die günstiger und sicherer sind als jede Eigenentwicklung. Die erste Frage lautet deshalb nicht „Können wir das bauen?“, sondern „Ist dieser Prozess bei uns wirklich anders, und bringt dieser Unterschied Geld?“.
Die Kosten über fünf Jahre rechnen
Der Vergleich der Anschaffungskosten führt in die Irre. Eine Eigenentwicklung kostet nach der Fertigstellung weiter: Fehlerbehebung, Anpassung an neue Betriebssysteme und Browser, Sicherheitsupdates, Erweiterungen, Dokumentation, Einarbeitung neuer Entwickler. Als Faustwert liegen die jährlichen Kosten für Wartung und Weiterentwicklung bei fünfzehn bis fünfundzwanzig Prozent der ursprünglichen Entwicklungskosten. Bei gekaufter Software fallen Lizenz oder Abonnement, Anpassungen, Schnittstellen und gelegentlich Beratung an. Beides gehört über fünf Jahre nebeneinandergestellt:
| Kostenart | Eigenentwicklung | Kauf |
|---|---|---|
| Einmalig | Entwicklung, Test, Einführung | Lizenz, Einrichtung, Anpassung, Datenübernahme |
| Laufend | Wartung, Weiterentwicklung, Betrieb, Personalrisiko | Abonnement oder Wartungsvertrag, Updates, Support |
| Versteckt | Abhängigkeit von Einzelpersonen, fehlende Dokumentation | Abhängigkeit vom Hersteller, Preiserhöhungen, Funktionslücken |
| Beim Ausstieg | Kein Käufer, Wissen geht verloren | Datenexport, Vertragslaufzeit |
Sechs Kriterien für die Entscheidung
- Differenzierung: Verschafft die Funktion einen Vorteil im Markt, oder ist sie Grundausstattung?
- Marktangebot: Gibt es Produkte, die achtzig Prozent des Bedarfs abdecken? Dann ist der Rest meist durch Anpassung oder Verzicht lösbar.
- Änderungsgeschwindigkeit: Ändern sich die Anforderungen monatlich, spricht das für Eigenentwicklung oder eine stark anpassbare Plattform.
- Verfügbare Kompetenz: Gibt es mindestens zwei Personen, die die Entwicklung tragen können, intern oder bei einem verlässlichen Partner?
- Integrationsbedarf: Muss die Lösung tief in ERP oder Produktionssysteme eingreifen? Dann sind Schnittstellen das eigentliche Thema, unabhängig von Make or Buy.
- Lebensdauer: Wird die Lösung länger als fünf Jahre gebraucht? Je länger, desto schwerer wiegen die laufenden Kosten.
Wer bei Differenzierung und Änderungsgeschwindigkeit klar mit Ja antwortet und bei der Kompetenz abgesichert ist, hat gute Gründe für die Eigenentwicklung. In allen anderen Fällen ist Kauf die sicherere Wahl.
Der dritte Weg: Kaufen und ergänzen
In der Praxis ist die Entscheidung selten rein. Häufig ist die beste Lösung ein Standardprodukt für den Kern und eine kleine Eigenentwicklung für den Teil, der das Unternehmen unterscheidet, angebunden über Schnittstellen. Ein Standard-ERP mit einem selbst gebauten Konfigurator, ein gekauftes Ticketsystem mit einer eigenen Auswertung, ein Standard-Shop mit einer individuellen Preislogik. Low-Code-Plattformen bieten dafür einen Mittelweg, bei dem Fachabteilungen mit überschaubarem Aufwand ergänzen können, was dem Standard fehlt. Entscheidend ist, dass der eigene Anteil klein, dokumentiert und von mehr als einer Person beherrschbar bleibt.
Typische Fehlentscheidungen
Zwei Muster sehen wir immer wieder. Das erste ist die Eigenentwicklung aus Bequemlichkeit: Ein Mitarbeiter kann programmieren, die Anforderungen sind unklar, und statt sie zu klären, wird einfach angefangen. Das Ergebnis ist eine Anwendung, die genau das tut, was der Entwickler verstanden hat, und die niemand außer ihm ändern kann. Das zweite Muster ist der Kauf aus Angst: Ein Standardprodukt wird gewählt, obwohl es den entscheidenden Prozess nicht abbildet, und anschließend mit so vielen Anpassungen versehen, dass Updates des Herstellers nicht mehr eingespielt werden können. Am Ende hat das Unternehmen die Nachteile beider Wege: Lizenzkosten und eine Individualentwicklung, die niemand gewollt hat. Beide Muster lassen sich vermeiden, wenn die Anforderungen vor der Entscheidung schriftlich vorliegen und die sechs Kriterien ehrlich beantwortet werden.
Wenn Eigenentwicklung, dann richtig
Fällt die Entscheidung für den Eigenbau, gelten Mindestanforderungen: Der Quellcode liegt in einer Versionsverwaltung, die dem Unternehmen gehört. Es gibt eine Dokumentation, die ein neuer Entwickler in zwei Tagen versteht. Automatisierte Tests sichern die wichtigsten Funktionen. Für den Betrieb ist geregelt, wer Updates einspielt und wer bei Ausfall erreichbar ist. Und es gibt ein jährliches Budget für Wartung, das nicht bei der ersten Sparrunde gestrichen wird. Wer diese Punkte nicht sicherstellen kann, sollte nicht bauen.
Fazit
Make or Buy ist keine Frage des Könnens, sondern der Differenzierung und der laufenden Kosten. Standardsoftware für alles, was nicht unterscheidet, Eigenentwicklung nur für den Teil, der Geld bringt und sich schnell ändert, und in jedem Fall eine Rechnung über fünf Jahre: Mit diesem Vorgehen bleibt die Entscheidung begründbar und das Unternehmen handlungsfähig, auch wenn der eine Entwickler geht.
Veröffentlicht am 21. April 2026 von Oktay Sönmez, STG Beratung (Kompetenzwerk Deutschland GmbH, Stuttgart). Themen: Make or Buy, Softwareauswahl, Eigenentwicklung, IT-Strategie.
