9 December 20257 Min. Lesezeit
Build gegen Buy ist einer der ältesten Streitpunkte der Softwarebranche, und meist fehlt dabei eine Spalte. Build heißt, Ihre eigenen Entwickler schreiben es. Buy heißt, das Produkt eines Anbieters erledigt es. Outsourcing ist weder das eine noch das andere: Es ist maßgeschneiderte Software, die Ihnen gehört und von Menschen gebaut wird, die nicht Ihre Angestellten sind, und ihr Risikoprofil unterscheidet sich von beiden.
Sie wegzulassen verzerrt die Diskussion in eine vorhersehbare Richtung. Teams, die keine interne Kapazität erübrigen können, schließen, dass sie kaufen müssen, und verbiegen dann zwei Jahre lang ihren Prozess um ein Produkt, das fast passt. Teams, die genau das haben wollen, was sie sich vorstellen, schließen, dass sie bauen müssen, und warten dann sechs Monate auf eine Einstellung. Die dritte Spalte schlägt oft beide, und sie steht selten auf der Folie.
Die drei Optionen beantworten verschiedene Fragen
Buy beantwortet: Ist dieses Problem für uns dasselbe wie für alle anderen? Build beantwortet: Ist unsere Fassung dieses Problems der Grund, warum Kunden uns wählen? Outsourcing beantwortet: Ist diese Arbeit für uns spezifisch, aber nicht das, was uns unterscheidet?
Diese dritte Kategorie ist riesig, und aus ihr stammt die meiste Enttäuschung über Standardprodukte. Ein internes Werkzeug, das zu Ihrem Betriebsmodell passt. Eine Integration zwischen zwei Systemen, die nur Sie zufällig gemeinsam betreiben. Eine Migration weg von etwas, das Ihnen in Eile verkauft wurde. Ein Portal für ein Kundensegment mit einer ungewöhnlichen Anforderung. Nichts davon ist differenzierend. Alles davon ist spezifisch.
Erst kaufen, und zwar ernsthaft
Der Standard sollte Kaufen sein, und die Hürde, davon abzuweichen, sollte hoch liegen. Ein ausgereiftes Produkt hat Jahre von Sonderfällen aufgenommen, an die Sie nicht gedacht haben, seine Wartung ist das Lohnkostenproblem eines anderen, und es funktioniert an dem Tag, an dem Sie dafür bezahlen, statt an dem Tag, an dem jemand fertig wird.
Die ehrlichen Einwände gegen Kaufen sind wenige. Das Produkt leistet die Sache wirklich nicht, und keine Konfiguration bringt es dorthin. Die kaufmännischen Konditionen skalieren schlecht mit Ihrem Wachstum. Die Daten müssen an einem Ort liegen, an den der Anbieter sie nicht legen wird, was für europäische Käufer mit strenger Datenschutzhaltung eine reale und keine theoretische Einschränkung ist. Oder die Fähigkeit ist das Produkt, dann haben Sie ohnehin nie eingekauft.
Der unehrliche Einwand lautet, dass es nicht so funktioniert, wie wir arbeiten. Manchmal stimmt das und ist teuer. Oft heißt es, dass das Produkt einen üblicheren Prozess verkörpert als Ihrer und dessen Übernahme eine Verbesserung wäre, die Sie nicht haben wollen. Das gehört benannt, bevor Sie ein Jahr Entwicklung darauf verwenden, ihr auszuweichen.
Intern bauen gegenüber den Bau auslagern
Sobald Sie entschieden haben, dass etwas maßgeschneidert sein muss, bleibt die Frage, wer es schreibt, und sie hängt an zwei Dingen: ob sich das Wissen intern aufsummieren muss und ob die Arbeit weitergeht, nachdem die erste Version ausgeliefert ist.
- Summiert sich auf und hört nie auf: intern bauen. Das ist der Kern, und eine Angestellte, die über Jahre Kontext ansammelt, ist der Vermögenswert.
- Spezifisch und wird meist einmal ausgeliefert: auslagern. Interne Werkzeuge, Integrationen, Migrationen, Portale. Das Wissen, auf das es ankommt, ist Dokumentation, keine Intuition.
- Spezifisch, dauerhaft, aber nicht unterscheidend: mit Blick auf Kontinuität auslagern. Staff Augmentation mit denselben benannten Personen funktioniert hier besser als eine Folge von Projekten.
- Unklar, was von beidem: Lagern Sie bewusst eine erste Fassung aus, entscheiden Sie mit etwas Echtem vor Augen, und halten Sie sich die Option offen, es wieder ins Haus zu holen.
Die letzte Zeile wird gern übersehen. Outsourcing ist ein billiger Weg herauszufinden, ob eine Fähigkeit eine feste Stelle verdient. Diese Frage über eine Einstellung zu beantworten kostet einen Recruiting-Zyklus und die Karriere eines Menschen, und sie falsch zu beantworten ist für alle teuer.
Die Kosten haben unterschiedliche Formen, nicht nur unterschiedliche Größen
Die drei allein über den Preis zu vergleichen verdeckt, worauf es ankommt: wann das Geld ausgegeben wird und was passiert, wenn Sie aufhören.
Kaufen bedeutet wiederkehrende Kosten, die klein anfangen und mit Ihrer Nutzung wachsen, und die enden, wenn Sie aufhören zu zahlen, zusammen mit der Fähigkeit. Intern bauen ist eine große feste Verpflichtung: Rekrutierung, Gehalt, Arbeitgeberbeiträge, die Monate, in denen die Stelle offen ist, und eine Person, die Sie nicht in einem Quartal abbauen können. Outsourcing liegt dazwischen: Es beginnt, wenn Sie beginnen, es endet mit einer Kündigungsfrist, und der Vermögenswert bleibt bei Ihnen.
Rechnen Sie alle drei über denselben Horizont, mindestens zwei Jahre, und legen Sie das offen, was üblicherweise weggelassen wird. Auf der Buy-Seite: Einführung, Integrationsarbeit, die Preiserhöhung bei der Verlängerung und die Kosten des Ausstiegs. Auf der Build-Seite: Rekrutierung, die leeren Monate und Steuerung. Auf der Outsourcing-Seite: die Einarbeitung, bevor jemand produktiv ist, und die interne Zeit, um sie zu führen. Die Rangfolge ändert sich oft, sobald das enthalten ist, und genau darum macht man es.
Die Antwort, bei der Sie vermutlich landen
In der Praxis machen die meisten Teams alle drei, und die nützliche Fähigkeit ist, die Grenzen zu ziehen, statt einen Sieger zu küren. Kaufen Sie die Standardware: Identität, Zahlungen, E-Mail, Analytics, den Finanzstack. Bauen Sie den Teil, der der Grund ist, warum Sie überhaupt jemand wählt. Lagern Sie die spezifische, aber nicht besondere Schicht aus, die beides verbindet, denn dort liegt das Arbeitsvolumen tatsächlich.
So gezogene Grenzen überstehen auch Wachstum. Wenn die ausgelagerte Schicht um eine Fähigkeit herum so groß wird, dass sie sich nicht mehr randständig anfühlt, ist das ein Signal, sie intern zu holen, und Sie haben dann sowohl das laufende System als auch die Dokumentation, gegen die Sie einstellen können. Das ist eine deutlich bessere Ausgangslage als eine Entscheidung im luftleeren Raum.
Eine Entscheidungsreihenfolge, die funktioniert
Stellen Sie die Fragen in dieser Reihenfolge, und die meisten Fälle klären sich an einem Nachmittag. Können wir es ehrlicherweise kaufen, einschließlich einer Anpassung unseres Prozesses? Wenn nein: Ist das die Sache, die uns unterscheidet? Wenn ja, stellen Sie ein und warten Sie. Wenn nein: Wird diese Arbeit unbefristet weiterlaufen und sich aufsummieren? Wenn ja, planen Sie damit, sie irgendwann intern zu holen, und lagern Sie sie jetzt mit diesem Ziel im Blick aus. Wenn nein, lagern Sie sie aus, behalten Sie den Code und die Konten und wenden Sie sich etwas Wichtigerem zu.
Der Fehlermodus, den diese Reihenfolge verhindert, ist der übliche: eine teure interne Eigenentwicklung von etwas, das das Team hätte kaufen können, finanziert dadurch, dass die wirklich differenzierende Arbeit liegen blieb, weil die dritte Spalte nie auf der Folie stand.