Sieben SaaS-Tools oder ein System? Wann individuelle Software sinnvoll ist

SaaS ist der günstigste Weg, um anzufangen. CRM, Formulare, Reporting, Automatisierung oder Support lassen sich in kurzer Zeit einführen, ohne ein eigenes Entwicklungsteam aufzubauen. Nach einigen Jahren läuft jedoch ein einziger Vertriebsprozess durch fünf bis sieben Produkte, und das Unternehmen finanziert ein großes System in Einzelteilen, obwohl es nie eines gekauft hat. Wie dieser Zustand entsteht, haben wir im Beitrag Ihr Unternehmen braucht nicht mehr Software. Es braucht weniger Chaos beschrieben. Dieser Text wiederholt die Problembeschreibung nicht, sondern behandelt das, was danach kommt: wie Sie entscheiden und wie Sie die Entscheidung mit Zahlen belegen.

Der Vergleich individuelle Unternehmenssoftware vs SaaS lässt sich so rechnen, dass das Ergebnis vor der Geschäftsführung und vor der Buchhaltung besteht. Die meisten Unternehmen entscheiden allerdings nach den zwei Zahlen, die über die tatsächlichen Kosten am wenigsten aussagen: nach dem monatlichen Abopreis und nach dem Angebotspreis für die Entwicklung. Beide sind lediglich Eintrittsgebühren in einen mehrjährigen Betrieb.

Entscheidend ist nicht die Lizenz, sondern der TCO

Total Cost of Ownership, auf Deutsch die Gesamtkosten des Eigentums, ist eine Methodik, die über den Anschaffungspreis hinausblickt und alles einrechnet, was Beschaffung und Betrieb zusätzlich kosten. Lisa M. Ellram hat sie Mitte der neunziger Jahre anhand von Fallstudien aus elf Unternehmen beschrieben, und für Software gilt dasselbe wie für den Materialeinkauf: Der Preis ist nur eine Position und in der Regel nicht die entscheidende.

Dass dies keine akademische Feinheit ist, zeigt eine Untersuchung der Lebenszykluskosten von dreißig IT-Anwendungssystemen von Rüdiger Zarnekow und Walter Brenner von der Universität St. Gallen. Bei einer Betriebsdauer von fünf Jahren entfallen 79 % der Lebenszykluskosten auf wiederkehrende Aufwände für Betrieb, Support, Wartung und Weiterentwicklung. Auf Planung und Erstentwicklung entfallen 21 %.

Die meisten Entscheidungen darüber, ob ein Prozess gebaut oder gekauft wird, fallen jedoch auf Basis dieses kleineren Fünftels, denn genau dieses steht im Angebot. Der Rest kommt später und verteilt sich auf Gehälter, auf den Support und auf die Zeit der Menschen, die es irgendwie lösen. Ebenso zuverlässig unterschätzt werden dabei der Betrieb einer Eigenentwicklung und die Verwaltung eines wachsenden Stapels an Abonnements.

Was wirklich in die TCO-Tabelle gehört

Die TCO-Tabelle hat zwei Spalten, den heutigen Stack und die vorgeschlagene Alternative, und in beiden dieselben Kategorien. Andernfalls vergleichen Sie nicht zwei Lösungen, sondern zwei Arten der Buchführung.

• Lizenzen, Verbrauch und ungenutzte Plätze. Neben dem Monatspreis gehört hierher, wie sich der Preis bei Wachstum verhält. Zylo weist im SaaS Management Index für 2026 aus, dass 78 % der IT-Verantwortlichen unerwartete Gebühren bei verbrauchsabhängigen oder KI-bezogenen Preismodellen festgestellt haben, dass 61 % wegen ungeplant steigender Kosten andere Projekte streichen mussten und dass Organisationen im Durchschnitt 36 % der SaaS-Lizenzen ungenutzt lassen. Die mittleren SaaS-Ausgaben je Mitarbeiter beziffert der Index auf 9.455 US-Dollar, im vorangegangenen Jahrgang wies er ein Wachstum von 21,9 % gegenüber dem Vorjahr aus. Das sind Daten aus den Portfolios großer Unternehmen. Für ein kleines Unternehmen gilt daraus die Richtung, nicht der absolute Wert.
• Integrationen und ihre Wartung. Der MuleSoft Connectivity Benchmark Report von Salesforce nennt für die durchschnittliche Organisation 897 eingesetzte Anwendungen, von denen nur 29 % verbunden sind, und IT-Teams verbringen 39 % ihrer Zeit mit Entwurf, Bau und Test eigener Integrationen. Diese Zeit ist ein Kostenblock wie jeder andere, nur stellt sie niemand in Rechnung.
• Menschliche Arbeit zwischen den Systemen. Eine im Harvard Business Review veröffentlichte Untersuchung beobachtete 137 Personen in zwanzig Teams aus drei Unternehmen der Fortune 500. Sie wechselten rund 1.200-mal täglich zwischen Anwendungen und Fenstern, ein Wechsel kostete etwas mehr als zwei Sekunden, und in Summe ergab das rund 9 % der jährlichen Arbeitszeit für das erneute Hineinfinden. In den TCO gehört das als Stundensatz mal Stunden.
• Sichtbarkeit der eigenen Ausgaben. Flexera berichtet im State of ITAM Report für 2026, dass 43 % der Organisationen einen Anstieg verschwendeter SaaS-Ausgaben gegenüber dem Vorjahr melden, bei KI-Software sind es 59 %, und dass nur 36 % vollständige Sichtbarkeit in ihre IT-Umgebung haben. Ohne sie lässt sich der TCO nicht rechnen, und die Entscheidung ist Raten mit Präsentation.

Nicht jede Funktion gehört in Individualsoftware

Einen eigenen Kalender, einen eigenen Mailclient oder eine eigene Buchhaltungssoftware zu entwickeln, wäre für die meisten Unternehmen eine unsinnige Investition. Der Grund ist wirtschaftlich: Es handelt sich um Funktionen, deren Entwicklung von Zehntausenden Kunden gleichzeitig finanziert wird. Eurostat weist aus, dass im Jahr 2025 52,7 % der Unternehmen in der EU kostenpflichtige Cloud-Dienste genutzt haben, am häufigsten für E-Mail (85,2 %) und für Finanz- oder Buchhaltungssoftware (58,2 %). Bei dieser Verbreitung baut niemand einen solchen Stückpreis für sich allein nach.

Wirtschaftlich sinnvoll wird eine eigene Lösung dort, wo der Prozess die Wettbewerbsfähigkeit bestimmt: Preislogik, Kapazitätsplanung, Vertriebsabläufe, Kundenportale oder die Arbeit mit einem eigenen Datenmodell. Die richtige Frage lautet deshalb nicht, ob gebaut oder gekauft wird, sondern: Welchen Teil des eigenen Funktionierens sollte ein Unternehmen strategisch selbst besitzen?

Dazu gehört auch, was Sie von einem Entwicklungsdienstleister üblicherweise nicht hören. Ein großer Teil der Anforderungen, die mit dem Satz „wir brauchen ein eigenes System“ kommen, lässt sich günstiger lösen: durch ein Lizenzaudit, durch eine ordentliche Konfiguration des Werkzeugs, das Sie bereits besitzen, durch die Verlagerung eines Prozesses in ein einziges bestehendes System statt in drei oder durch ein No-Code-Werkzeug, also eine Umgebung, in der Logik ohne Programmierung zusammengesetzt wird. Wenn sich das Problem für ein Zehntel des Preises lösen lässt, ist die Eigenentwicklung die falsche Antwort. Und wenn der Prozess selbst fehlerhaft ist, beschleunigt neue Software ihn lediglich, worüber wir im Text KI rettet keinen schlechten Prozess geschrieben haben.

In der Praxis gewinnt häufig eine hybride Architektur

Eine moderne Architektur bedeutet nicht, alles von null zu programmieren. Das Unternehmen behält externe Services für Zahlungen, E-Mail, Buchhaltung oder Authentifizierung und besitzt nur jene Schicht, die den eigenen Prozess, die eigenen Daten und die Benutzeroberfläche steuert.

Der Mechanismus ist einfach. Die eigene Schicht definiert das Datenmodell, also die Art, wie das Unternehmen Auftrag, Kunde, Kapazität und Preis benennt. Die übrigen Systeme werden dadurch zu austauschbaren Lieferanten von Funktionen statt zu Eigentümern der Wahrheit über das Unternehmen. Der Unterschied zeigt sich erst beim zweiten Werkzeugwechsel: Die Integration ändert sich, der Prozess nicht. Auch der Hybrid hat allerdings seine eigene Position in der Tabelle: Es sind mehr Schnittstellen zu warten, nicht weniger.

Einmal entwickeln heißt nicht kostenlos betreiben

Individualsoftware ist kein wartungsfreies Vermögen. Sie benötigt Hosting, Monitoring, Sicherheitsupdates und laufende Weiterentwicklung. Der Unterschied zum Abonnement liegt darin, dass die Investition ein Asset unter Ihrer Kontrolle schafft, nicht darin, dass die wiederkehrenden Kosten verschwinden.

Hinzu kommt das Realisierungsrisiko, das in Angeboten selten auftaucht. Bent Flyvbjerg und Alexander Budzier haben eine Stichprobe von 1.471 IT-Projekten analysiert und eine durchschnittliche Budgetüberschreitung von 27 % festgestellt. Wesentlicher ist die Form der Verteilung: Jedes sechste Projekt war ein sogenannter schwarzer Schwan mit einer durchschnittlichen Kostenüberschreitung von 200 % und einer Terminüberschreitung von fast 70 %. Das Risiko liegt also nicht im Durchschnitt, sondern im Rand der Verteilung, und je größer der einmalige Umfang, desto höher die Wahrscheinlichkeit, dort zu landen. Deshalb lohnt es sich, in kleinen Schritten zu bauen und nach jedem Schritt neu zu rechnen, ob der nächste noch sinnvoll ist.

Der Business Case über drei bis fünf Jahre

Auf einem Horizont von einem Jahr lässt sich nicht entscheiden. Eine eigene Lösung verliert im ersten Jahr in der Regel: Sie trägt die gesamte Investition und fast keine Einsparung. Rechnen Sie drei bis fünf Jahre und vergleichen Sie kumulierte Kosten, nicht die erste Rechnung. Das Modell braucht vier Eingaben:

1. Die Basis. Was der heutige Stack kostet, einschließlich der menschlichen Arbeit zwischen den Systemen.
2. Die Wachstumskurve. Wie sich die Basis bei doppelter Kundenzahl verhält. Bei Lizenzen, die pro Nutzer abgerechnet werden, wächst sie linear, bei einer eigenen Schicht meist nicht.
3. Die Investition und ihren Betrieb. Nicht nur den Entwicklungspreis, sondern auch das, was die folgenden fünf Jahre kosten werden.
4. Den Break-even. Das Jahr, in dem sich die kumulierten Kurven schneiden, und was geschieht, wenn es sich um zwölf Monate verschiebt.

Ein Modellbeispiel. Die Zahlen sind gewählte Annahmen zur Illustration der Rechnung, keine Messung aus einem realen Projekt. Ein Unternehmen mit 40 Beschäftigten führt einen Auftragsprozess über sechs Werkzeuge und zahlt für Lizenzen 2.200 Euro monatlich, also 26.400 Euro jährlich. Bei fünfzehn Prozent jährlichem Wachstum sind das über drei Jahre rund 92.000 Euro. Das Angebot für die eigene Schicht lautet 70.000 Euro. Würde dafür das Verhältnis aus der Studie der Universität St. Gallen gelten, in der die Erstentwicklung 21 % der Fünfjahreskosten ausmacht, ergäbe die Fünfjahressumme größenordnungsmäßig 330.000 Euro, also etwa 66.000 Euro pro Jahr.

An dieser Rechnung sind zwei Dinge wichtig. Das erste ist methodisch: 92.000 Euro sind eine Dreijahressumme, 330.000 Euro eine Fünfjahressumme, und vergleichen lassen sich nur gleich lange Zeiträume. Bei gleichem Horizont fällt die eigene Lösung in diesem Modell teurer aus, nicht günstiger. Das zweite ist unbequem: Die eingesparten Lizenzen allein bezahlen einen solchen Unterschied nicht. Der Business Case muss auf freigesetzter Kapazität der Mitarbeiter stehen, auf einer kürzeren Durchlaufzeit des Auftrags, auf Fehlern, die nicht mehr entstehen, oder auf Umsatz, den der heutige Stack nicht bedienen kann. Wenn sich davon nichts zumindest grob schätzen lässt, ist das Projekt nicht entscheidungsreif.

Die Investition wird zudem nicht mit null verglichen, sondern mit der besten Alternative, und das ist häufig eine weitere Stelle. Dem haben wir einen eigenen Text darüber gewidmet, ob ein Unternehmen ein System oder einen neuen Mitarbeiter braucht.

Signale, wann sich eine eigene Lösung lohnt und wann nicht

Eine Rechnung lohnt sich, wenn mehreres davon zutrifft

• Der betreffende Prozess ist eine Quelle Ihrer Wettbewerbsfähigkeit und keine administrative Pflicht.
• Die Kosten wachsen linear mit der Zahl der Personen oder Transaktionen, während der Nutzen des Werkzeugs nicht mitwächst.
• Der Anbieter hat das Preismodell geändert oder eine Funktion gestrichen, auf der Ihr Prozess aufsetzt.
• Ihr Angebot für Kunden ist dadurch begrenzt, was das Werkzeug zulässt, und nicht dadurch, was der Markt verlangt.

Es ist die falsche Antwort, wenn eines davon zutrifft

• Es geht um eine Standardfunktion, die ein fertiger Dienst genauso gut löst.
• Das Unternehmen hat noch kein Lizenzaudit gemacht und weiß nicht genau, wie viel es heute wofür bezahlt.
• Die Anforderungen ändern sich jeden Monat, und niemand kann sie auch nur für ein Quartal festschreiben.
• Im Unternehmen gibt es niemanden, der das System nach der Übergabe übernimmt und dafür verantwortlich ist.

Exit-Kosten sind keine Unbekannte mehr. Zumindest in der EU

Zum TCO gehört auch, was der Ausstieg kostet. Bis vor Kurzem ließ sich diese Position nicht beziffern, und so wurde daraus ein fatalistisches Argument im Stil von „im Lock-in sitzen wir ohnehin“. Die Regulierung hat das verändert. Nach Angaben der Europäischen Kommission ist der Data Act, also die Verordnung (EU) 2023/2854, seit dem 12. September 2025 anwendbar und erleichtert die Übertragung von Daten sowie den Wechsel zwischen Cloud-Anbietern. Die juristische Analyse der Kanzlei Latham & Watkins ergänzt, dass die Pflichten für IaaS, PaaS und SaaS gelten und dass Anbieter seit dem 11. Januar 2024 Wechselentgelte nur noch als Weiterberechnung direkter Kosten ohne Marge verlangen dürfen. Ab dem 12. Januar 2027 werden sie vollständig untersagt sein.

Die Folgen sind zweierlei und zeigen nicht in dieselbe Richtung. Der Preis des Ausstiegs sinkt, damit ist die Wahl eines fertigen Dienstes weniger riskant, ein schlecht gewähltes Werkzeug lässt sich austauschen. Zugleich sinkt die Hürde für die Übertragung von Daten auf eine eigene Infrastruktur, wodurch auch der Weg zur eigenen Lösung günstiger wird. In die TCO-Tabelle gehört deshalb eine Zeile mit Preis und Format des Exports. Testen lässt sich das heute und nicht erst bei der Trennung.

Die Entscheidung zwischen einem eigenen System und einem Abonnement ist keine Frage des technologischen Geschmacks, sondern der Frage, welchen Teil des eigenen Funktionierens ein Unternehmen besitzen will und ob es das auch in drei Jahren bezahlen kann. Die Antwort lässt sich nicht beim Softwareanbieter erfragen, denn dieser kennt sein Angebot und nicht Ihre Zahlen. Der erste Schritt ist nicht die Wahl der Technologie, sondern die Diagnose: Was kostet Ihr Stack heute, wie viel menschliche Arbeit erzeugt er um sich herum und welcher Teil davon ist eine Standardfunktion.

Was Sie mitnehmen

• Vergleichen Sie die Gesamtkosten des Eigentums und nicht den Abopreis oder den Entwicklungspreis. Laut der Studie der Universität St. Gallen macht die Erstentwicklung nur ein Fünftel der Fünfjahreskosten einer Anwendung aus.
• Rechnen Sie drei bis fünf Jahre und suchen Sie den Break-even, beide Seiten auf gleich langem Horizont.
• Bevor Sie irgendetwas bauen, machen Sie ein Lizenzaudit und konsolidieren Sie. Wenn sich das Problem für ein Zehntel des Preises löst, ist die Eigenentwicklung die falsche Antwort.
• Besitzen Sie den Prozess, der Sie unterscheidet, und kaufen Sie das, was Standard ist. Eine hybride Architektur ist meist der vernünftigere Kompromiss als eines der beiden Extreme.
• Das Risiko eines IT-Projekts liegt im Rand der Verteilung, nicht im Durchschnitt. Bauen Sie in kleinen, für sich nützlichen Schritten.