← Alle Texte

Fertiges Werkzeug kaufen oder selbst bauen

Software

Zu dieser Frage gibt es viele Texte, und sie enden fast alle gleich: Es kommt darauf an, meistens beides, situativ entscheiden. Das ist nicht falsch. Es hilft nur niemandem, der ein Angebot vor sich liegen hat.

Was fehlt, ist eine Rechnung. Nicht meine mit erfundenen Zahlen, sondern eine, die du mit deinen eigenen aufmachen kannst. Die Größen dafür kennst du fast alle, und wo du eine nicht kennst, kannst du sie erfragen.

Warum die übliche Antwort nicht weiterhilft

Weil sie die Entscheidung an ein Gefühl zurückgibt. „Standard für Standardprozesse, individuell für die Lücken dazwischen“ klingt vernünftig und lässt genau die Frage offen, um die es geht: Ist mein Fall eine Lücke oder nicht?

Dazu kommt, dass die Texte zu diesem Thema überwiegend von Softwarehäusern stammen. Die verdienen an Eigenentwicklung. Das macht ihre Argumente nicht falsch, aber es erklärt, warum die Kostenseite bei ihnen meist im Ungefähren bleibt. Auf einer der bestplatzierten Seiten steht die Überschrift, die Frage nach den Kosten werde oft falsch gestellt — und darunter keine einzige Zahl.

Also rechnen wir.

Die Rechnung über fünf Jahre

Fünf Jahre, weil das ungefähr die Zeit ist, die eine Anwendung im Betrieb bleibt, bevor sie grundlegend erneuert wird. Kürzer gerechnet gewinnt der Kauf fast automatisch, länger gerechnet der Eigenbau. Fünf Jahre sind ein fairer Rahmen.

Seite A: fertiges Produkt kaufen

Seite B: selbst bauen lassen

Wenn beide Summen weniger als etwa zwanzig Prozent auseinanderliegen, entscheidet nicht der Preis, sondern die Frage, welches Risiko dir lieber ist: Abhängigkeit von einem Anbieter oder Abhängigkeit von einem Entwickler.

Die zwei Posten, die fast nie auftauchen

Diese beiden habe ich in keinem der Vergleiche gefunden, die zu dieser Frage ranken. Sie verschieben das Ergebnis erheblich.

Die Handarbeit, die trotzdem bleibt

Ein fertiges Produkt bildet neunzig Prozent deines Ablaufs ab. Die restlichen zehn Prozent macht jemand von Hand: Werte nachtragen, die das Programm nicht kennt. Eine Liste exportieren und in einer Tabelle aufbereiten, weil die eingebaute Auswertung die benötigte Sicht nicht hat. Einen Vorgang doppelt erfassen, weil zwei Programme nichts voneinander wissen.

Rechne diese Zeit aus: wie oft pro Woche, wie viele Minuten, mal zweiundfünfzig, mal fünf Jahre. Bei einer halben Stunde täglich sind das über fünf Jahre mehr als sechshundert Stunden. Diese Zahl gehört auf Seite A, weil sie bei einer maßgeschneiderten Lösung entfiele.

Manchmal ist das auch die einfachere Erkenntnis: Wenn die Handarbeit nur daher rührt, dass zwei Programme nicht miteinander sprechen, ist die Antwort weder Kauf noch Eigenbau, sondern eine Verbindung zwischen beiden. Das ist um Größenordnungen billiger als beides.

Die Preissteigerung im Abo

Mietsoftware wird teurer. Nicht dramatisch von einem Jahr aufs andere, aber verlässlich. Wer heute rechnet und den heutigen Preis mal sechzig Monate nimmt, rechnet zu günstig.

Setz einen jährlichen Aufschlag an — welchen, ist deine Einschätzung, aber null ist falsch. Und prüf im Vertrag, ob Preisanpassungen geregelt sind und wie lange du kündigen kannst. Der Unterschied zwischen jährlicher und dreijähriger Bindung ist bei einer Preiserhöhung genau der Unterschied zwischen Verhandeln und Zahlen.

Was klar für ein fertiges Produkt spricht

In diesen Fällen brauchst du gar nicht erst zu rechnen.

Was für etwas Eigenes spricht

Auch hier ist die Liste kurz und ziemlich eindeutig.

Häufig kommt die Frage übrigens gar nicht aus dem Nichts, sondern weil der Betrieb aus einer Tabelle herausgewachsen ist. Dann lohnt der Zwischenschritt: Vielleicht ist die passende Größe nicht ein System, sondern eine schlanke Datenbank mit Eingabemaske.

Der dritte Weg

In vielen Fällen ist die Antwort keine Entscheidung, sondern eine Aufteilung: Standardprodukte für die Standardaufgaben, dazu ein kleines eigenes Werkzeug für die Stelle, an der der Betrieb anders arbeitet als alle anderen.

Das ist deutlich billiger als eine große Eigenentwicklung und deutlich brauchbarer als ein verbogenes Standardprodukt. Die Bedingung dafür ist, dass die beteiligten Programme Daten austauschen können — sonst entsteht genau die Handarbeit wieder, die man loswerden wollte.

Zu der Zahl mit den dreißig bis vierzig Prozent

Beim Recherchieren stößt man auf die Angabe, Unternehmen gäben im Schnitt dreißig bis vierzig Prozent ihrer Lizenzkosten noch einmal für Anpassungen und Behelfslösungen aus, zugeschrieben an ein bekanntes Marktforschungshaus.

Diese Zuschreibung ließ sich nicht bestätigen. Die Angabe findet sich bei einem Anbieter, der Eigenentwicklung verkauft; der angegebene Verweis führt auf eine allgemeine Übersichtsseite, nicht auf einen Bericht, und weder Jahr noch Titel werden genannt. Andere auffindbare Aussagen desselben Hauses betreffen andere Sachverhalte.

Ich verwende die Zahl deshalb nicht, und du solltest es auch nicht. Nicht weil die Größenordnung unplausibel wäre — Anpassungen kosten wirklich viel —, sondern weil eine Zahl mit falschem Absender in einer Entscheidungsvorlage schlimmer ist als keine Zahl.

Die Frage dahinter bleibt wichtig und lässt sich besser stellen: Ist die geplante Anpassung im Produkt vorgesehen oder wird sie daran vorbeigebaut? Vorgesehene Anpassungen überleben Updates. Alles andere muss bei jeder neuen Version nachgezogen werden, und genau dort entsteht der Aufwand, den niemand eingeplant hat.

Wann Eigenbau eine schlechte Idee ist

Drei Fälle, unabhängig vom Ergebnis der Rechnung.

Niemand kann beschreiben, was es können soll. Wer ein Produkt kauft, bekommt die Entscheidungen eines Herstellers mitgeliefert. Wer bauen lässt, muss sie selbst treffen. Wenn im Betrieb Uneinigkeit darüber herrscht, wie der Ablauf aussehen soll, wird das Projekt teuer und das Ergebnis unbeliebt.

Es soll ein bestehendes Produkt nachgebaut werden. Wenn die Anforderung dem entspricht, was es zu kaufen gibt, ist der Nachbau die teure Variante desselben Ergebnisses.

Der Betrieb kann die Abhängigkeit nicht tragen. Eigene Software braucht jemanden, der sie versteht. Wenn nicht geklärt ist, wer das ist, wenn die Zusammenarbeit endet, fehlt eine Voraussetzung. Wie eine saubere Übergabe aussieht, steht im Text über den Betrieb.

Wie du zur Entscheidung kommst

Mach beide Spalten auf, mit deinen Zahlen. Für Seite A holst du zwei bis drei Angebote und fragst ausdrücklich nach Einrichtung, Zusatzmodulen und Preisanpassung. Für Seite B holst du eine Schätzung und fragst nach Betrieb und Wartung.

Dann trag die verbleibende Handarbeit auf beiden Seiten ein. Das ist der Punkt, an dem die Rechnung ehrlich wird, und meistens auch der, an dem sie sich entscheidet.

Wenn danach immer noch Gleichstand herrscht, nimm das fertige Produkt. Nicht weil es besser ist, sondern weil es die Entscheidung ist, die sich leichter zurücknehmen lässt.

Wenn du beide Spalten aufmachen willst und unsicher bist, welche Posten hineingehören, gehen wir sie gemeinsam durch. Der Digital-Check ist ein Gespräch und eine Einschätzung, kein Angebot.

Digital-Check starten