Build vs. Buy ist die falsche Frage. Fragen Sie, was sich verzinst.

Irgendwann liegt die Frage in jedem Budgetmeeting auf dem Tisch: selbst entwickeln oder kaufen? Sie klingt nach einem Kostenvergleich, und genau das ist sie fast nie. Wer eine Lizenzgebühr neben eine Aufwandsschätzung stellt, vergleicht zwei grundverschiedene Dinge, nämlich eine laufende Ausgabe mit einem Vermögenswert, als wären sie dasselbe.

Der Vergleich scheitert dabei in beide Richtungen. Er unterschätzt die Kosten des Kaufens, weil nur die Lizenzgebühr in die Tabelle wandert, während Workarounds, Integrationsaufwand und Prozesskompromisse dort nie auftauchen. Und er unterschätzt den Wert der Eigenentwicklung, weil ein Vermögenswert, der jedes Quartal besser wird, nicht in eine Zelle passt, die für einen Abo-Preis gedacht war. Zwei Zahlen, beide falsch. Am Ende entscheidet die lauteste Stimme im Raum.

Wir arbeiten deshalb mit einem einfachen Rahmen, auch dort, wo unsere eigene Beteiligung auf dem Spiel steht: Fragen Sie nicht, was billiger ist. Fragen Sie, was sich verzinst.

Gemietete Software verliert ab der Unterschrift an Wert

Ein SaaS-Abo löst die heutige Version Ihres Problems mit der heutigen Version eines fremden Produkts. Oft ist das genau richtig: Lohnabrechnung, E-Mail, ein CRM für einen Standard-Vertriebsprozess. Das sind Commodity-Probleme, und Commodity-Probleme verdienen Commodity-Lösungen. Sie zu kaufen ist kein Kompromiss, sondern Disziplin.

Achten Sie aber darauf, was Sie tatsächlich mieten: einen Ablauf, der für den Durchschnitt aller Kunden des Anbieters entworfen wurde. Ihr Betrieb driftet von diesem Durchschnitt ab, Quartal für Quartal, hier eine Preisregel, dort ein Ausnahmeprozess. Für diese Differenz zahlen Sie eine zweite, unsichtbare Gebühr: die Tabellen-Schicht. Exporte, erneutes Eintippen, Workarounds, „die Datei, die nur eine Sachbearbeiterin pflegt“. Niemand budgetiert sie, und sie wächst exakt in dem Maß, in dem sich Ihr Geschäft von anderen unterscheidet.

Die Miete hat versteckte Klauseln

Die Lizenzgebühr ist der sichtbare Teil des Preises. Die unsichtbaren Teile verdienen es, benannt zu werden, denn sie treffen Sie genau dann, wenn es am wenigsten passt. Preise pro Nutzerplatz sind eine Steuer auf Wachstum: Das Werkzeug kostet am meisten in dem Quartal, in dem Sie am meisten einstellen. Preiserhöhungen folgen dem Lock-in: Verlängerungsangebote haben die Angewohnheit, sich zu verdoppeln, sobald Ihre Daten, Ihre Integrationen und die Gewohnheiten Ihres Teams im Produkt liegen. Die Roadmap gehört nicht Ihnen: Das Feature, von dem Ihr Betrieb abhängt, kann eingestellt, in eine höhere Preisstufe verschoben oder schlicht nie umgesetzt werden, und Ihr einziges Mittel dagegen ist ein Support-Ticket.

Dazu kommt die Schwerkraft der Daten. Nach drei Jahren liegen die Wechselkosten eines tief eingebetteten SaaS-Werkzeugs oft höher als die Kosten, die Fähigkeit von Anfang an selbst aufgebaut zu haben. Das liegt nicht an der Qualität der Software, sondern daran, dass ein Ausstieg Export, Migration, Umschulung und ein Quartal operatives Risiko bedeutet. Lock-in ist keine Verschwörung, sondern das Geschäftsmodell. Es verdient nur eine Zeile in der Vergleichstabelle, und die bekommt es nie.

Eigene Software verzinst sich, wenn Sie die richtigen Dinge entwickeln

Individualsoftware verhält sich in der Bilanz und im Betrieb anders. Jeder Ablauf, den sie aufnimmt, jede Integration, die hinzukommt, jede Ausnahme, die sie zu behandeln lernt, macht die nächste Verbesserung billiger. Das ist der Zinseszinseffekt: derselbe Mechanismus wie bei einbehaltenen Gewinnen, angewandt auf Prozesswissen.

Die Schleife ist konkret. Das System erfasst Ihre Daten in Ihrer Struktur, wodurch die nächste Integration eine Woche dauert statt eines Monats. Diese Integration holt einen weiteren Ablauf unter ein Dach und macht damit den nächsten Automatisierungskandidaten sichtbar. Jedes Inkrement landet auf dem vorherigen, nicht daneben. Nach fünf Jahren unterscheiden sich ein gemieteter Stack und eine eigene Plattform nicht durch die Featureliste: Die eine hat fünf Jahre lang Ihr Betriebswissen angesammelt, die andere die Roadmap eines fremden Anbieters.

Die Effekte zweiter Ordnung werden unterschätzt. Neue Mitarbeiter lernen Ihren tatsächlichen Prozess kennen und nicht ein generisches Werkzeug plus einen Ordner voller Workaround-Dokumente. Die Due Diligence bei einem Verkauf oder einer Finanzierungsrunde geht schneller, wenn der Betrieb in einem System lesbar ist, denn Käufer zahlen für Abläufe, die sie lesen können. Und die Software selbst steht als Vermögenswert in den Büchern, was sich über einen Stapel Abos nicht sagen lässt.

Entwickeln Sie nur dort selbst, wo Ihr Prozess das Produkt ist. Kaufen Sie überall dort, wo Ihr Prozess derselbe ist wie bei allen anderen.

Der Test besteht aus einer einzigen Frage: Wenn dieser Ablauf doppelt so gut wäre wie der Branchenstandard, würden Ihre Kunden das merken? Lautet die Antwort Ja, etwa bei der Angebotsgeschwindigkeit einer Spedition, der Schadenbearbeitungszeit eines Versicherers oder der Aufnahme in einer Klinikgruppe, dann ist dieser Ablauf ein Vermögenswert, der sich verzinst, und verdient eigene Software. Lautet sie Nein, kaufen Sie die Commodity und wenden sich Wichtigerem zu.

Zwei Quadranten verdienen eine Anmerkung. In „Kaufen, dann anpassen“ sollten mittelständische Unternehmen häufiger leben, als sie es tun: Behalten Sie den Commodity-Kern und entwickeln Sie nur die dünne Schicht, die abbildet, was Sie von anderen unterscheidet, also die Preislogik über dem Standard-CRM oder die Ausnahmebehandlung über dem Standard-ERP. Und „das Beste kaufen“ ist wörtlich gemeint, denn bei Commodity-Abläufen ist das teure Werkzeug fast immer billiger als das billige plus die Reibung, die es erzeugt.

Die Rechnung, die es am Ende entscheidet

Besteht der Ablauf den Test, wird aus der Entscheidung eine Amortisationsfrage, und die gehört ehrlich gerechnet: Entwicklungskosten plus Betriebskosten auf der einen Seite, eingesparte Stunden, vermiedene Fehler und freigesetzter Umsatz auf der anderen. In unseren eigenen Angeboten gilt dabei eine feste Grenze: Übersteigt die Amortisation zwölf Monate, raten wir von der Eigenentwicklung ab, und wir halten diese Empfehlung schriftlich fest.

Rechnen Sie mit echten Zahlen, nicht mit Hoffnungen. Auf der Kostenseite stehen die Aufwandsschätzung, die Wartung (eine vernünftige Planungsgröße sind 15-20 % der Entwicklungskosten pro Jahr), das Hosting und die interne Zeit, die das System bindet. Auf der Ertragsseite stehen die voll gerechneten Stunden, die der Ablauf heute verbraucht, die Kosten seiner Fehler und der Umsatz, den kürzere Durchlaufzeiten freisetzen. Wird die Ertragsseite von einer weichen Zeile „strategischer Wert“ dominiert und tragen die harten Zahlen sie nicht, dann sagt Ihnen die Rechnung: kaufen.

Drei Fehler sind dabei die häufigsten. Der erste: Commodity-Software aus Stolz selbst zu entwickeln. „Wir sind besonders“ stimmt für die Lohnabrechnung nicht, und der Eigenbau tritt gegen Produkte mit tausend Personen Vorsprung an. Der zweite: differenzierende Software aus Ungeduld zu kaufen. Das Abo startet schnell, und dann wächst die Tabellen-Schicht darum herum, bis der Geschwindigkeitsvorteil aufgebraucht ist. Der dritte: das Richtige mit dem falschen Zuschnitt zu entwickeln. Eine v1, die alles abdecken will, kommt zu spät und trifft auf einen Betrieb, der längst aufgehört hat, an sie zu glauben. Eine v1 sollte so schmal sein, dass sie fast peinlich ist, und trotzdem tatsächlich benutzt werden.

Die üblichen Einwände, ehrlich beantwortet

„Wir sind kein Softwareunternehmen.“ Das müssen Sie auch nicht sein. Sie brauchen einen Verantwortlichen auf Ihrer Seite des Tisches und einen Partner, der für den Rest geradesteht, so wie Sie ein Gebäude besitzen, ohne ein Bauunternehmen zu führen. Was Sie nicht tun sollten: entwickeln lassen, ohne die Wartungsfrage schriftlich geklärt zu haben.

„Individualsoftware wird zum Altsystem.“ Schlecht entwickelte Individualsoftware wird das, und jedes SaaS-Werkzeug, dem Sie entwachsen, ebenfalls; nur lässt sich ein Anbieter nicht refaktorieren. Software auf langweiliger, verbreiteter Technologie, dokumentiert und mit Tests abgedeckt, bleibt ein Jahrzehnt lang wartbar. Das ist ein Kriterium für die Auswahl des Partners, kein Argument gegen den Besitz.

„Was, wenn der Anbieter unser Feature nächstes Jahr liefert?“ Dann wird Ihr gemietetes Werkzeug besser, für Sie und für jeden Wettbewerber, der es am selben Nachmittag mietet. Die Features, die ein Anbieter ausliefert, sind per Definition genau die, die Sie nicht von anderen unterscheiden. Auf die Fähigkeit, für die Kunden Sie überhaupt wählen, können Sie nicht warten.

Die Entscheidung hat ein Haltbarkeitsdatum

Build vs. Buy ist keine Entscheidung, die man einmal trifft, sondern ein Portfolio, das man umschichtet. Ein Ablauf, der vor drei Jahren Commodity war, kann heute dort liegen, wo Sie sich vom Wettbewerb absetzen; beim Kunden-Onboarding sehen wir diesen Weg besonders häufig. Und eine Fähigkeit, die Sie 2019 selbst entwickelt haben, kann inzwischen eine Commodity sein, die drei Anbieter besser verkaufen. Prüfen Sie das Portfolio deshalb einmal im Jahr: Besteht jedes eigene System den Zinseszins-Test noch, und was kostet die Tabellen-Schicht, die sich um jedes größere Abo gelegt hat?

Seien Sie ebenso bereit, eigene Software abzuschalten, wie sie zu entwickeln. Ein individuelles Werkzeug stillzulegen, dessen Ablauf zur Commodity geworden ist, ist kein Eingeständnis des Scheiterns, sondern ein Portfolio, das funktioniert. Gefährlich ist die Trägheit in beide Richtungen: die eigene Differenzierung zu mieten, weil Eigenentwicklung riskant wirkt, oder ein Altsystem zu pflegen, weil es einmal teuer war. Die Bilanz interessiert nicht, was eine Lektion gekostet hat, sondern was sich von hier an verzinst.

Der erste Schritt

Nehmen Sie Ihre Tabellen-Schicht auf. Jeder Workaround ist ein Hinweis Ihres Betriebs darauf, wo er den gemieteten Werkzeugen bereits entwachsen ist. Beziffern Sie diese Stunden ehrlich, wenden Sie den Zinseszins-Test an, und die Entscheidung trifft sich meist von selbst. Die Liste wird länger sein, als Ihnen lieb ist, und das ist der gesunde Zustand: Sortieren Sie nach Amortisation, arbeiten Sie von oben nach unten, und lassen Sie den gemessenen Ertrag jedes Projekts den Mut für das nächste finanzieren.

Und wenn eine Eigenentwicklung die Hürde nimmt, halten Sie sie an dem Maßstab fest, der den Fall für sie gemacht hat: eine Kennzahl, benannt vor der ersten Zeile Code, lauffähige Software in Wochen statt in Quartalen, und ein Zuschnitt, der schmal genug ist, um fast peinlich zu sein. Eigene Software verzinst sich nur, wenn sie in Betrieb geht, benutzt wird und weiter den Betrieb um sich herum aufnimmt. Das ist keine Frage der Strategie mehr, sondern eine der Umsetzung.