Der SaaS-Entscheidungsbaum: Kaufen, selbst bauen oder vorhandene Tools erweitern?

Key Facts: SaaS-Kaufentscheidungen bei Mid-Market-Unternehmen

• Durchschnittliche Evaluierungsdauer: 84 Tage vom ersten Demo bis zum unterzeichneten Vertrag bei Deals über 25.000 USD/Jahr (Gartner, 2025 B2B Buying Benchmarks).
• Vendor-Shortlist pro Deal: 3 bis 5 bei typischen Mid-Market-Deals; Enterprise-Deals kommen im Schnitt auf 6 bis 8 (Forrester SaaS Buying Pulse).
• Entscheidungsträger pro Deal: Im Durchschnitt 6,8 bei einem Mid-Market-B2B-Softwarekauf, gegenüber 5,4 im Jahr 2020 (Gartner B2B Buying Journey).
• Win-Rate bei strukturierten vs. ad-hoc-Entscheidungen: Teams mit einem dokumentierten Entscheidungsframework berichten ein Jahr nach dem Kauf von einer 2,3-fach höheren Tool-Nutzungsrate als Teams, die Framework-Schritte überspringen (McKinsey Software Buying Study).
• Tool-Überschneidungen bei Mid-Market-Unternehmen: 30 bis 40 % der SaaS-Tools weisen Funktionsüberschneidungen mit mindestens einem anderen Tool im Stack auf (Productiv State of SaaS).

Der COO hatte ein Problem: Genauer gesagt drei. In einem einzigen Quartal kamen drei separate Teams mit dem Wunsch „Wir brauchen schnell etwas" zur Führungsebene. Alle drei Anfragen wurden genehmigt. Alle drei Tools wurden gekauft. Als der IT-Leiter vier Monate später den Stack analysierte, stellte er fest, dass zwei der Tools erhebliche Funktionsüberschneidungen aufwiesen und eines Funktionen doppelte, die das Unternehmen bereits achtzehn Monate zuvor in einer lizenzierten Plattform besessen hatte.

Niemand hatte dabei wirklich einen Fehler gemacht. Jedes Team hatte einen echten Bedarf und eine echte Lösung gefunden. Aber niemand hatte die eigentliche Frage gestellt: Sollten wir überhaupt etwas kaufen?

Diese Frage (kaufen, selbst bauen oder vorhandene Tools erweitern) klingt offensichtlich. Sie ist es nicht. Die meisten Unternehmen überspringen sie vollständig, weil sie Arbeit erfordert, bevor die Vendor-Gespräche beginnen, und die Vendor-Gespräche einfacher sind. Das Demo ist bereits eingeplant. Der Trial läuft bereits. Die Kaufentscheidung fällt, bevor das Entscheidungsframework überhaupt angewendet wird.

Dieser Leitfaden liefert Ihnen genau dieses Framework. Er richtet sich an Unternehmen mit 50 bis 500 Mitarbeitenden, die SaaS-Entscheidungen schnell genug treffen, dass ein formaler Beschaffungsprozess übertrieben wirkt, aber langsam genug, dass Tool Sprawl echte Budget- und Produktivitätsfolgen hat.

Warum die Standardantwort immer „Kaufen" lautet

Der SaaS-Markt hat den Weg des geringsten Widerstands direkt auf einen Kauf ausgerichtet. Kostenlose Trials beseitigen Reibung. Product-Led Growth (PLG) sorgt dafür, dass sich Tools im Unternehmen verbreiten, bevor die Beschaffung davon erfährt. Laut Gartners Forschung zum Software-Kaufverhalten initiieren Endnutzer mittlerweile über 60 % der Softwarekäufe, oft unter Umgehung von IT und Beschaffung. AI-Vendor-Pitches in 2025 und 2026 haben eine neue Dimension hinzugefügt: Jede Funktion sieht aus wie eine Plattform, und jede Plattform verspricht, drei Tools zu ersetzen, die Sie bereits besitzen. Bevor Sie einen Vendor evaluieren, lohnt sich ein Blick auf wie Sie einen SaaS-RFP durchführen, der keine sechs Wochen verschwendet, denn der RFP-Prozess setzt voraus, dass Sie die Kaufentscheidung bereits getroffen haben.

Die Standardantwort lautet „kaufen", weil sie am leichtesten zu verteidigen ist. Sie können ein Demo vorweisen. Sie können auf eine Case Study verweisen. Sie können ein Team in zwei Wochen produktiv machen. Der Eigenentwicklung dauert Monate, und die Erweiterung eines vorhandenen Tools erfordert, dass jemand dieses Tool gut genug versteht, um zu wissen, was es wirklich kann.

Doch die Kosten des automatischen „Kaufens" summieren sich. Die Anzahl der Tools wächst. Verträge verlängern sich automatisch. Die Anzahl der Lizenzen driftet. McKinseys Forschung zu Software-Ausgaben zeigt, dass Unternehmen die Gesamtkosten für Software konsequent um 30 bis 50 % unterschätzen, wenn sie nur Lizenzgebühren berücksichtigen. Und irgendwann schaut der CFO auf eine SaaS-Kostenposition, die 40 % pro Jahr gewachsen ist, ohne eine klare Erklärung dafür, was dieser Betrag gebracht hat. Die Folgen dieses übersprungenen Schritts zeigen sich in dem SaaS-Sprawl-Problem, einem Muster, das bei fast jedem Mid-Market-Unternehmen mit schnellem Wachstum auftritt.

Das Entscheidungsframework verschiebt den Ausgangspunkt von „Welcher Vendor?" zu „Sollten wir überhaupt kaufen?"

Der vierästige Entscheidungsbaum

Der Build-vs-Buy-vs-Adopt-Entscheidungsbaum

Der Build-vs-Buy-vs-Adopt-Entscheidungsbaum ist ein dreiästiges Framework, das eine strukturierte Frage erzwingt, bevor ein Vendor-Gespräch beginnt: Build (intern entwickeln, wenn die Funktion zum Wettbewerbsvorteil beiträgt), Buy (ein zweckgebautes SaaS-Tool lizenzieren, wenn die Funktion nicht zum Kerngeschäft gehört und der Vendor-Markt reif ist), oder Adopt (eine bereits im Stack vorhandene Funktion erweitern, wenn die Abdeckung bei 70 % oder mehr liegt). Der Baum wird der Reihe nach durchlaufen: zuerst Kern vs. Nicht-Kern, dann Entwicklungskosten, dann Bestandsstack-Audit, dann Reife des Vendor-Markts. Es wird beim ersten Ast gestoppt, der eine vertretbare Antwort liefert.

So funktioniert das Framework. Gehen Sie jeden Ast der Reihe nach durch. Beim ersten Ast, der eine klare Antwort liefert, hören Sie auf.

Ast 1: Handelt es sich um eine Kern- oder Nicht-Kernfunktion?

Kernfunktionen sind Tätigkeiten Ihres Unternehmens, die Sie differenzieren oder unmittelbar Umsatz generieren. Nicht-Kernfunktionen sind unterstützende Aktivitäten: Dinge, die jedes Unternehmen braucht, die aber keine Quellen von Wettbewerbsvorteilen sind. Das Build-vs-Buy-Framework der Harvard Business Review formuliert diese Unterscheidung rund um strategische Kontrolle: Lagern Sie aus, was Commodity ist, und behalten Sie, was proprietär ist.

Für die meisten Mid-Market-Unternehmen sieht das so aus:

Kern: Wie Sie verkaufen, wie Sie liefern, wie Sie Kunden halten, wie Ihr Produkt funktioniert.

Nicht-Kern: Ausgabenmanagement, Terminplanung, Dateispeicherung, HR-Administration, IT-Ticketing.

Wenn der Bedarf wirklich zum Kern gehört, verdient die Eigenentwicklung ernsthafte Überlegung. Nicht, weil Eigenentwicklung immer besser ist, sondern weil das Outsourcing des eigenen Differenzierungsmerkmals ein strategisches Risiko birgt, das der Aufkleberpreis nicht widerspiegelt.

Wenn der Bedarf nicht zum Kern gehört, entwickeln Sie nicht selbst. Weiter zu Ast 2.

Ast 2: Wie sehen die Entwicklungskosten wirklich aus?

Die meisten Unternehmen erstellen keine echte Kostenschätzung, bevor sie die Eigenentwicklung verwerfen. Die Einschätzung lautet „Wir müssten Engineers einstellen", und das Gespräch geht weiter. Das ist die richtige Antwort für die meisten Nicht-Kernfunktionen, aber für Kernfunktionen verdient sie eine echte Zahl.

Ein grundlegendes Kostenarbeitsblatt für die Eigenentwicklung sieht so aus:

Die letzte Zeile wird von Unternehmen konsequent unterschätzt. Wenn Ihre Engineers Produktfeatures entwickeln könnten statt eines internen Workflow-Tools, umfassen die wahren Kosten der Eigenentwicklung auch den Umsatz, den Sie nicht generiert haben.

Wenn die Entwicklungskosten über einen 3-Jahres-Horizont deutlich höher ausfallen als SaaS-Alternativen (was bei Nicht-Kernfunktionen meistens der Fall ist), weiter zu Ast 3. Das vollständige TCO-Modellierungsframework für SaaS behandelt dieses Fünf-Kategorien-Kostenmodell detailliert, einschließlich Implementierungs-, Integrations- und Ausstiegskosten, die ein einfacher Lizenzvergleich nicht berücksichtigt.

Ast 3: Kann ein vorhandenes Tool das leisten?

Bevor Sie etwas Neues kaufen, prüfen Sie, was Sie bereits besitzen. Dies ist der Schritt, den die meisten Unternehmen überspringen, weil er erfordert, dass jemand sich tatsächlich in vorhandene Tools einloggt und versteht, was sie können.

Die zu stellenden Fragen:

• Hat eine aktuelle Plattform diese Funktion nativ oder per Konfiguration?
• Hat eine aktuelle Plattform diese Funktion auf der Roadmap (innerhalb von 90 Tagen)?
• Gibt es eine Integration oder Automatisierung zwischen zwei vorhandenen Tools, die diesem Bedarf nahekommt?
• Gibt es nicht genutzte Lizenzen in einem vorhandenen Tool, das diese Funktion hat?

Dieses Audit sollte eine Person ein bis zwei Tage in Anspruch nehmen, keine sechs Wochen. Sie suchen nach einer vorhandenen Funktion, die nah genug ist, nicht nach einer perfekten Übereinstimmung.

Die folgende Komplexitäts-Scorecard für Integrationen hilft Ihnen zu beurteilen, ob das Erweitern eines vorhandenen Tools wirklich einfacher ist oder ob Sie damit nur eine Art von Aufwand gegen eine andere austauschen:

Wenn zwei oder mehr Kategorien „Hoch" ergeben, ist die Erweiterung in der Praxis wahrscheinlich teurer als der Kauf eines zweckgebauten Tools.

Wenn Ihr bestehender Stack eine echte, ausreichend gute Funktion hat, erweitern Sie ihn. Falls nicht, weiter zu Ast 4.

Ast 4: Ist der Vendor-Markt reif?

Die Reife des Vendor-Markts ist wichtig, weil sie Ihr langfristiges Risiko bestimmt. Forresters SaaS-Marktanalyse unterscheidet zwischen Kategorie-Leadern mit mehr als fünf Jahren Track Record und aufstrebenden Herausforderern, die sich noch in Produkt-Markt-Fit-Zyklen befinden, eine Unterscheidung, die unmittelbar beeinflusst, wie Sie Ihre Vertragsbeziehung gestalten sollten. Der Kauf in einem reifen Markt bedeutet:

• Mehrere etablierte Vendor mit mehr als fünf Jahren Track Record
• Klare Funktionsdifferenzierung (nicht nur Marketingdifferenzierung)
• Referenzkunden in Ihrer Branche und Ihrer Größenordnung
• Standardvertragsbedingungen mit bekannten Verhandlungspunkten

Der Kauf in einem unreifen Markt, insbesondere in der aktuellen AI-SaaS-Welle, bedeutet:

• Vendor sind 12 bis 18 Monate alt und haben Seed- oder Series-A-Finanzierung
• Feature-Roadmaps sind groß; die Produktionskapazität ist begrenzt
• Die Preisgestaltung ist experimentell und wird sich ändern
• Referenzkunden sind handverlesene Early Adopters

Das bedeutet nicht, dass Sie nicht bei neuen Vendor kaufen sollten. Es bedeutet, dass Sie Ihre Vertragsgröße an die Reife des Markts anpassen sollten. Ein Pilot für 500 USD/Jahr ist ein anderes Risiko als ein Jahresvertrag über 50.000 USD mit einer zweijährigen Auto-Renewal-Klausel.

Entscheidungsregel: Bei einem reifen Markt kaufen Sie mit standardmäßiger Sorgfalt. Bei einem unreifen Markt kaufen Sie mit begrenztem Engagement (jährlich, nicht mehrjährig; Pilot-Umfang, kein vollständiges Rollout) und bauen einen Neubewertungsauslöser in den Vertrag ein. Speziell für AI-native Tools hilft die Evaluierung von AI-fähigen SaaS-Tools dabei, echte Funktionen von Marketing-Versprechen zu trennen, bevor Sie eine mehrjährige Verpflichtung eingehen.

Häufige Fehler an jedem Ast

Punktlösungen, die vorhandene Lizenzen duplizieren

Der häufigste und teuerste Fehler. Ein Team kauft ein Projektmanagement-Tool, weil es nicht mag, wie das vorhandene Projektmanagement-Tool des Unternehmens konfiguriert ist. Die Lösung ist kein neues Tool. Sie ist ein besseres Konfigurationsgespräch oder Training zum vorhandenen Tool.

Bevor Sie einen neuen Kauf genehmigen, verlangen Sie vom Antragsteller zu dokumentieren, ob ein vorhandenes Tool bereits 70 % oder mehr des Bedarfs abdeckt.

Selbst entwickeln, was man für 200 USD/Monat kaufen könnte

Engineering-Zeit ist teuer. Ein Senior Engineer kostet 150 bis 200 USD/Stunde. Wenn ein SaaS-Tool für 200 USD/Monat existiert, muss die Eigenentwicklung gegenüber dem SaaS-Tool mindestens 7.200 USD jährlichen Mehrwert liefern, nur um bei den ersten 30 Entwicklungsstunden die Gewinnschwelle zu erreichen. Das ist selten der Fall.

Ausnahme: Wenn die vorhandene SaaS-Lösung ein Datenschutz-, Compliance- oder Sicherheitsproblem schafft, das interne Tools vermeiden. Das berechnet sich anders.

Erweiterungslogik, die Datensilos erzeugt

Die Erweiterung eines vorhandenen Tools klingt nach geringem Aufwand, bis Sie feststellen, dass die Integration einen Datenfluss erzeugt, der in drei Systemen lebt und nur von einer Person verstanden wird. Wenn diese Person das Unternehmen verlässt, bricht die Integration zusammen, und niemand weiß warum.

Bevor Sie eine Erweiterung genehmigen, dokumentieren Sie den Datenfluss, weisen Sie einen Verantwortlichen zu, und bestätigen Sie, dass die Integration allein aus der Dokumentation wiederhergestellt werden kann.

Die Entscheidung dauerhaft verankern

Das Entscheidungsframework funktioniert nur, wenn es angewendet wird, bevor der Demo-Kalender voll ist. Der praktische Weg, dies durchzusetzen:

1. Verlangen Sie ein einseitiges Brief, bevor eine Vendor-Evaluierung beginnt. Das Brief beantwortet: Welches Problem lösen wir, welchen Ast des Entscheidungsbaums haben wir durchlaufen, und warum sind wir bei „kaufen" gelandet?

2. Machen Sie den IT-Leiter oder einen designierten SaaS-Verantwortlichen jedes Mal zu einem festen Teil von Ast 3. Sie kennen den Stack. Der Antragsteller tut das nicht immer.

3. Legen Sie einen Überprüfungsauslöser für jeden Kauf über 10.000 USD/Jahr fest. Ein Jahr danach prüft jemand, ob das Tool genutzt wird, ob es etwas anderes dupliziert, und ob der ursprüngliche Bedarf noch besteht.

4. Verfolgen Sie stillgelegte Tools als Erfolgskennzahl. Wenn Sie nur neue Tool-Käufe messen, erfassen Sie nur die Hälfte des Problems.

Messen, ob das Framework funktioniert

Sie wissen, dass das Entscheidungsframework funktioniert, wenn:

• Tool-Überschneidungen beim jährlichen Stack-Audit abnehmen
• Die Zeit bis zur Entscheidung bei Software-Käufen sinkt (weil das Framework zirkuläre Diskussionen reduziert)
• Budget aus stillgelegten oder konsolidierten Tools als Posten in der Jahresübersicht erscheint
• IT-Tickets zu Tool-Verwirrung oder Reibung durch doppelte Tools abnehmen

Das Ziel ist nicht, Software-Entscheidungen zu verlangsamen. Es geht darum, zwanzig Minuten strukturiertes Denken vorzuziehen, die vier Monate Bereinigung verhindern.

Wie Rework den Entscheidungsbaum in der Praxis unterstützt

Das Framework funktioniert nur, wenn das einseitige Brief, das Ast-3-Stack-Audit und die Genehmigung des IT-Leiters vor dem Vendor-Demo stattfinden, und genau hier scheitern die meisten Mid-Market-Teams. Rework Work Ops (ab 6 USD/Nutzer/Monat) gibt dem SaaS-Verantwortlichen einen einzigen Ort, um jeden Entscheidungsbaum-Durchlauf zu dokumentieren: die Problembeschreibung, welcher Ast die Antwort geliefert hat, die Ergebnisse des Bestandsstack-Audits und den Genehmiger, und leitet alles ohne Slack-Nachfragen an die richtigen Stakeholder weiter.

Work Ops-Templates ermöglichen es Ihnen, das einseitige Brief zu standardisieren, sodass jede neue Tool-Anfrage dieselbe Struktur befolgt. Das Workflow-Routing sendet Ast-3-Überprüfungen direkt an den IT-Leiter oder designierten SaaS-Verantwortlichen mit einer harten Sperrung, bis diese ihr Einverständnis erteilen. Da Work Ops neben Rework CRM/Sales Ops (ab 12 USD/Nutzer/Monat) liegt, erhalten kommerzielle Tool-Entscheidungen, die Revenue-Teams betreffen, dieselbe strukturierte Überprüfung wie Operations-Tools, ohne separaten Workflow, ohne separates Tool. Der 12-Monats-Überprüfungsauslöser für Käufe über 10.000 USD/Jahr kann als wiederkehrende Aufgabe geplant werden, die mit dem ursprünglichen Entscheidungsdatensatz verknüpft ist, sodass nichts automatisch verlängert wird, ohne dass ein Mensch überprüft hat, ob es noch genutzt wird.

Weiterführende Artikel

• TCO-Modellierung für SaaS: Jenseits des Aufkleber-Preises, was die Kaufentscheidung wirklich kostet, sobald Sie sie vollständig modellieren
• SaaS-Konsolidierung: Wann Sie ein Tool kürzen vs. behalten sollten, der Prüfprozess für die Bereinigung bereits getroffener Entscheidungen
• Das SaaS-Sprawl-Problem: Anzeichen und Lösungsansätze, was passiert, wenn niemand den Entscheidungsbaum angewendet hat
• Beschaffung vs. operativer Besitz: Wer entscheidet über SaaS und wann, Governance, damit dieses Framework greift
• CRM-Käufer-Checkliste, wie die Build-vs-Buy-Entscheidung speziell bei der CRM-Auswahl aussieht
• AI-Tools-Stack für Mid-Market-Teams, wie der Entscheidungsbaum bei der Evaluierung von AI-fähigen Plattformen angewendet wird