SaaS kauft Geschwindigkeit, Standardisierung und gebündelten Betrieb. Individualsoftware kauft Passform, Kontrolle und eigene Prioritäten – übernimmt dafür aber Produkt- und Betriebsverantwortung. Der Vergleich wird fair, wenn beide Optionen dieselbe Geschäftsfunktion und denselben Zeitraum abdecken.
Kurzantwort: SaaS gewinnt meist bei standardisierten Prozessen, schneller Einführung und fehlender eigener Betriebskapazität. Individualsoftware kann gewinnen, wenn ein stabiler, differenzierender Prozess deutlich kleiner als die Suite ist und hohe Nutzer-, Integrations- oder Änderungskosten vermieden werden. Eine Drei-Jahres-TCO-Rechnung muss Build, Betrieb und Exit vollständig enthalten.
Fachlich und quellenbezogen geprüft: 2026-07-23
Stufe 1 · Quick Win vor jedem Umbau
Ein Seat-Sprawl-Agent gleicht freigegebene Personal- oder Identitätsdaten, Vendor-Exporte, Aktivität, Rechnungen und Verlängerungen ab. Er legt verwaiste Seats, Doppeltools, falsche Editionen und Zombie-Abos in eine Review Queue – ohne Zugänge oder Verträge autonom zu ändern.
Zuerst werden Muss-Prozess, Nutzer, Daten, Rollen, Integrationen, Volumen und Servicelevel festgelegt. Features ohne reale Nutzung gehören nicht in den Wertvergleich. So wird vermieden, dass eine breite Suite gegen einen zu klein definierten Eigenbau antritt.
Die UK Government Digital Service empfiehlt bei Technologieentscheidungen, TCO, Datenkontrolle, offene Standards und spätere Wechselmöglichkeit gemeinsam zu betrachten. Diese Kriterien sind auch für private Mittelständler ein belastbarer Rahmen.
Beim SaaS liegen Hosting, Produkt-Roadmap und ein Teil des Supports beim Anbieter. Dafür gelten dessen Datenmodell, Release-Rhythmus, Pakete und Vertragslogik. Bei Individualsoftware kann das Unternehmen Scope und Änderungen priorisieren, muss aber Sicherheit, Qualität, Verfügbarkeit und Wartbarkeit verantworten.
Open Source kann zwischen beiden Polen liegen: eigener oder gemanagter Betrieb auf offenem Fundament. Auch hier entscheidet der TCO, nicht die Abwesenheit einer klassischen Lizenz.
Ein günstiger Start kann teuer werden, wenn jede Prozessänderung Beratung, Add-ons oder Edition-Upgrades benötigt. Umgekehrt kann ein Eigenbau nach dem Launch dauerhaft mehr kosten, wenn Architektur, Tests und Dokumentation vernachlässigt wurden.
Für beide Optionen werden drei Änderungsszenarien und ein Exit gerechnet: kleine Regeländerung, neue Integration, deutlich höheres Volumen und vollständige Datenübergabe. So wird Flexibilität zu einer prüfbaren Kostenposition.
Bei SaaS prüft der Pilot Passform, Konfiguration, Daten und Integration. Bei Individualsoftware prüft er Scope, technische Machbarkeit, Agentenqualität und Betriebsweg. Beide laufen mit denselben fachlichen Testfällen.
Ein Pilot darf ergeben, dass SaaS wirtschaftlicher bleibt. Diese Erkenntnis ist günstiger als ein Eigenbau, der nur deshalb fortgeführt wird, weil bereits Code entstanden ist.
| Kriterium | SaaS | Individualsoftware |
|---|---|---|
| Start | Konfiguration und Einführung auf vorhandener Plattform. | Scope, Architektur, Umsetzung und Abnahme müssen entstehen. |
| Passform | Standardprozess und verfügbare Konfiguration. | Auf den begrenzten eigenen Prozess zugeschnitten. |
| Betrieb | Vom Anbieter gebündelt, intern bleiben Administration und Datenverantwortung. | Cloud, Updates, Sicherheit, Monitoring und Support werden selbst verantwortet oder eingekauft. |
| Änderung | Abhängig von Produkt-Roadmap, Paket und APIs. | Eigene Priorität, aber jede Änderung braucht Budget, Tests und Deployment. |
| Exit | Vertrag, Exporte, Datenmodell und Integrationen bestimmen den Aufwand. | Code und Daten können kontrolliert werden; Team- und Infrastrukturabhängigkeit bleiben. |
Keine Option ist pauschal günstiger. Entscheidend sind derselbe Scope, derselbe Zeitraum und eine vollständige Zuordnung von internen wie externen Kosten.
Beispielrechnung mit Annahmen
Zeitraum: 36 Monate
In diesem Annahmen-Szenario ist SaaS über drei Jahre 92.700 Euro günstiger.
Alle Werte sind frei gewählte Annahmen. Bei mehr Nutzern, höherem SaaS-Preis, kleinerem Build oder längerem Zeitraum kann sich das Ergebnis ändern. Die Rechnung ist kein Marktpreis und keine Empfehlung.
Entscheidungscheck
Ist der fachliche Scope für beide Optionen identisch?
Sind interne Administration und Produktverantwortung eingerechnet?
Welche Änderungen sind in drei Jahren realistisch?
Wie werden Sicherheit, Verfügbarkeit, Backup und Support erbracht?
Sind Daten und Integrationen bei beiden Optionen exit-fähig?
Welcher Pilot misst Passform und Betrieb mit denselben Testfällen?
Vom Check in den Betrieb
Verträge, Rechnungen, aktive Nutzer, Geschäftsfunktionen, Daten, Integrationen und Verlängerungen werden in einer prüfbaren Entscheidungsbasis zusammengeführt.
Ergebnis: Ist-TCO, Quick Wins und ein klar abgegrenzter Kandidat
Ein begrenzter Prozess läuft mit denselben Testfällen, Qualitätskriterien, Sicherheitsregeln und Verantwortlichen wie die bestehende Lösung.
Ergebnis: Gemessene Qualität, Aufwand und belastbare Betriebskalkulation
Migration, Schnittstellen, Rollen, Dokumentation, Rückfallweg und Vertragsende werden stufenweise umgesetzt und fachlich abgenommen.
Ergebnis: Produktiver Zielprozess ohne unkontrollierten Big Bang
Nutzung, Fehler, Freigaben, Modell- und Infrastrukturkosten sowie neue Anforderungen werden regelmäßig gemessen und priorisiert.
Ergebnis: Nachvollziehbarer Betrieb statt neuem Kosten-Sprawl
Passende Agenten-Bausteine
Preis- und Produktangaben beziehen sich auf die verlinkten öffentlichen Quellen. Konditionen können sich ändern; maßgeblich ist das konkrete Angebot des jeweiligen Anbieters. Eigene Rechnungen sind separat als Annahme gekennzeichnet.
Öffentliche Leitlinie, Total Cost of Ownership, Datenkontrolle, offene Standards und die Möglichkeit eines späteren Technologiewechsels gemeinsam zu bewerten.
Abgerufen am 2026-07-23
Offizielle Strategie zu Wiederverwendung, digitaler Autonomie und einer TCO-Bewertung von Open Source einschließlich Exit-Kosten.
Abgerufen am 2026-07-23
Forschungsbericht, der KI in der Softwareentwicklung als Verstärker bestehender organisatorischer Stärken und Schwächen einordnet.
Abgerufen am 2026-07-23
FAQ
Wenn ein stabiler Prozess deutlich kleiner als die Suite ist und Nutzer-, Integrations-, Änderungs- oder Laufzeitkosten über den Betrachtungszeitraum höher sind als Build und verantworteter Betrieb. Ohne vollständigen TCO lässt sich das nicht seriös entscheiden.
Produktverantwortung, Architektur, Tests, Sicherheit, Hosting, Monitoring, Support, Dokumentation, Updates, Abhängigkeiten, Datenmigration und laufende Änderungen. Auch ein Exit zu einem anderen Team oder Technologie-Stack gehört in die Rechnung.
Einführung, Datenbereinigung, Integrationen, interne Administration, Zusatzmodule, Editionen, Schulung, Preisänderungen, Paralleltools und der spätere Export. Der sichtbare Seat-Preis ist nur ein TCO-Baustein.
Ja, bei geeigneten Aufgaben kann KI Analyse, Implementierung, Tests und Dokumentation unterstützen. Eine pauschale Produktivitätsquote ist aber nicht belastbar. Der eigene Pilot muss Aufwand, Review, Qualität und laufende Agentenkosten messen.
Drei Jahre sind ein praktikabler Start, weil Einführung und laufender Betrieb gemeinsam sichtbar werden. Bei langlebigen Kernsystemen sollte zusätzlich ein längerer Zeitraum mit Preis-, Änderungs- und Ablöseszenarien gerechnet werden.
Nächster Schritt
Im Kostenaudit erfassen wir Verträge, tatsächliche Nutzung, Integrationen, Datenexport und Betrieb. Das Ergebnis ist eine priorisierte Entscheidung: optimieren, konsolidieren, ersetzen oder bewusst behalten.
