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
- Lizenz. Preis pro Nutzer und Monat, mal Anzahl der Nutzer, mal sechzig Monate. Denk daran, dass die Zahl der Nutzer steigt, wenn der Betrieb wächst.
- Einrichtung. Einmalig: Einführung, Datenübernahme, Schulung.
- Anpassungen. Was am Produkt geändert werden muss, damit es zu deinem Ablauf passt.
- Zusatzmodule. Der Posten, der beim Angebot gern fehlt und im zweiten Jahr auftaucht, wenn eine Funktion gebraucht wird, die im gewählten Tarif nicht enthalten ist.
- Verbleibende Handarbeit. Siehe unten. Der wichtigste Posten.
- Preissteigerung. Siehe ebenfalls unten.
Seite B: selbst bauen lassen
- Entwicklung. Der Angebotspreis, einmalig.
- Betrieb. Server, Datenbank, Sicherungen, Überwachung, mal sechzig Monate. Was dazugehört, steht ausführlich im Text über das, was nach dem Projekt anfällt.
- Wartung und Aktualisierungen. Laufend, nicht optional.
- Änderungen. Jedes Jahr kommt etwas dazu. Plan ein Budget ein, statt jede Kleinigkeit zu verhandeln.
- Abhängigkeit von einer Person oder Firma. Kein Geldposten, aber ein Risiko, das in die Entscheidung gehört.
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.
- Es geht um eine Standardaufgabe. Buchhaltung, Lohnabrechnung, Kassensystem. Hier steckt Jahrzehnte an Fachwissen und rechtlicher Pflege in den Produkten, das niemand nachbaut.
- Es gibt gesetzliche Anforderungen, die sich ändern. Der Anbieter pflegt das nach. Bei einer Eigenentwicklung müsstest du das beauftragen, jedes Mal.
- Es muss schnell gehen. Ein Produkt kann nächste Woche laufen.
- Der Ablauf ist nicht dein Unterscheidungsmerkmal. Wenn du dich über deine Rechnungsstellung nicht vom Wettbewerb abhebst, brauchst du dafür nichts Eigenes.
Was für etwas Eigenes spricht
Auch hier ist die Liste kurz und ziemlich eindeutig.
- Der Ablauf ist dein Unterscheidungsmerkmal und kommt in keinem Produkt vor. Wer versucht, das in Standardsoftware zu pressen, zahlt für Anpassungen und bekommt trotzdem nur eine Annäherung.
- Die Lizenzsumme wird über fünf Jahre sehr groß. Bei vielen Nutzern kippt die Rechnung irgendwann, und dieser Punkt lässt sich exakt bestimmen.
- Trotz gekaufter Software bleibt dauerhaft Handarbeit. Der Posten von oben. Wenn er groß ist, ist er das stärkste Argument.
- Du brauchst die Daten in einer Form, die dir gehört. Manche Produkte machen den Export mühsam. Wer damit weiterarbeiten will, sollte das vor dem Kauf prüfen.
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 →