Software Ownership Economics Report 2026

Executive Summary

„Einmal bauen, für immer besitzen“ ist eine strategische These – keine universelle Rechenregel. Eigene Software kann wiederkehrende Lizenzkosten ersetzen, spezifische Prozesse besser abbilden und einen kontrollierbaren technischen Vermögenswert schaffen. Sie kann zugleich teurer, riskanter oder langsamer sein, wenn der Scope instabil, die Nutzung klein, der Betrieb unterschätzt oder die Organisation nicht in der Lage ist, Ownership tatsächlich zu tragen.

Dieser Report modelliert deshalb nicht nur nominale SaaS-Ausgaben gegen einen Build-Preis. Er trennt:

• vermiedene SaaS-Kosten,
• Initialentwicklung,
• Betriebs- und Wartungskosten,
• Delivery-Verzögerung,
• Kostenüberschreitung,
• Remediation-Risiko,
• Zeitwert des Geldes,
• 36- und 60-Monats-Horizont,
• ad hoc, standardisierten und gemanagten Betrieb,
• bilanzielle Prüfung nach IAS 38.

Die Szenarien sind ausdrücklich keine Kundenfälle und keine FW-Delta-Angebote. Sie sind reproduzierbare Rechenmodelle mit offengelegten Annahmen.

Zitierfähige Kernergebnisse

1. [CALCULATED] In den fünf Basisszenarien liegt der nominale Break-even zwischen 21,3 und 33,3 Monaten.
2. [CALCULATED] Zwei der fünf Szenarien zeigen nach 36 Monaten nominal positive Einsparungen, aber einen negativen Barwert bei acht Prozent. Nominale Ersparnis und wirtschaftlicher Vorteil sind daher nicht identisch.
3. [CALCULATED] Im 50.000-Läufe-Szenariomodell liegt die Wahrscheinlichkeit eines positiven 36-Monats-NPV je nach Fall zwischen rund 24,6 und 99,6 Prozent.
4. [CALCULATED] Über 60 Monate wird der NPV in den modellierten Parameterräumen fast immer positiv; dies ist eine Eigenschaft der gewählten Szenarien, keine Marktaussage.
5. [CALCULATED] Im Self-Hosted-Betriebsmodell stellen Arbeitskosten bei kleinen und standardisierten Profilen den größten TCO-Block dar; der Serverpreis allein erklärt die Wirtschaftlichkeit nicht.
6. [OBSERVED] IAS 38 verlangt für die Aktivierung eines immateriellen Vermögenswerts unter anderem Identifizierbarkeit, Kontrolle und erwarteten wirtschaftlichen Nutzen. Nicht jede Entwicklungsausgabe erfüllt diese Kriterien.
7. [OBSERVED] Bei SaaS-Konfiguration und -Customizing wird häufig kein vom Kunden kontrollierter immaterieller Vermögenswert anerkannt; zusätzlicher, separat kontrollierter Code kann anders zu beurteilen sein.
8. [INTERPRETATION] Ownership wird wirtschaftlich, wenn die vermiedene wiederkehrende Kostenbasis groß, der Prozess stabil und der Betrieb standardisiert ist. Kleine oder volatile Anforderungen sprechen häufiger für Buy oder Hybrid.

---

1. Ergebnisübersicht

1.1 Deterministisches Basismodell

Szenario	vermiedene SaaS/Monat EUR	Build EUR	Owned Run/Monat EUR	nominaler Break-even Monate	NPV 36M EUR	NPV 60M EUR
A – Kleines internes Tool	1.000	25.000	250	33,3	-968	12.234
B – Teamplattform	2.500	50.000	625	26,7	10.081	43.084
C – Bereichssystem	5.000	100.000	1.250	26,7	20.162	86.168
D – Enterprise-Funktion	10.000	250.000	2.500	33,3	-9.675	122.337
E – Plattformkonsolidierung	25.000	400.000	6.250	21,3	200.812	530.842

1.2 Risiko-adjustiertes Szenariomodell

Die Monte-Carlo-Analyse verwendet offengelegte, hypothetische Verteilungen für Build-Kosten, Betriebsaufwand, SaaS-Wachstum, Delivery-Verzögerung und Remediation. Sie ist kein empirisch kalibriertes Marktmodell.

Szenario	P(NPV>0), 36M	NPV P10 36M	Median 36M	P90 36M	Median 60M
A – Kleines internes Tool	24,6 %	-7.125	-2.339	1.849	16.257
B – Teamplattform	83,9 %	-2.402	7.973	17.171	54.501
C – Bereichssystem	83,7 %	-4.755	15.634	34.372	108.724
D – Enterprise-Funktion	25,1 %	-71.254	-23.032	18.586	163.202
E – Plattformkonsolidierung	99,6 %	97.298	188.984	274.609	655.584

1.3 Warum Szenario A und D bei 36 Monaten schwach sind

Beide Fälle besitzen im Verhältnis zur monatlich vermiedenen Kostenbasis einen hohen Initialaufwand. Das deterministic model zeigt nominale Break-even-Werte von 33,3 Monaten. Sobald Diskontierung, Verzögerung und Kostenrisiko hinzukommen, reicht der Rest des 36-Monats-Fensters oft nicht aus, um den initialen Cash-Abfluss aufzuholen.

Das bedeutet nicht, dass diese Builds „schlecht“ sind. Mögliche zusätzliche Nutzen wurden im Basismodell nicht monetarisiert:

• neue Umsatzfähigkeit,
• bessere Datenqualität,
• geringeres Compliance-Risiko,
• geringere Prozesszeit,
• höhere strategische Option,
• vermiedene zukünftige Migration,
• Eigentum am Code.

Ein Business Case darf diese Nutzen ergänzen – aber nur mit eigenem Beleg und eigener Sensitivität.

---

2. Forschungsdesign

2.1 Forschungsfrage

Unter welchen transparenten Kosten-, Risiko- und Zeithorizontannahmen ist eigene Software gegenüber weiterem SaaS-Bezug oder einem Hybridmodell wirtschaftlich?

2.2 Entscheidungsalternativen

Alternative	Typische Stärke	Typisches Risiko
Buy/SaaS	schnelle Einführung, externer Betrieb, breite Standardfunktionen	wiederkehrende Kosten, Roadmap- und Exit-Abhängigkeit
Build/Owned	exakte Prozessabbildung, Codekontrolle, keine Seat-/Task-Lizenz	Initialkosten, Scope-, Delivery- und Betriebsrisiko
Hybrid	Standardfunktionen kaufen, Differenzierung selbst besitzen	Integrations- und Grenzflächenkomplexität
Delay	Informationsgewinn und Liquidität erhalten	fortgesetzte Ineffizienz und steigende Wechselkosten

2.3 TCO-Gleichung

NPV Ownership =
PV(vermiedene SaaS-Kosten)
- Initialentwicklung
- PV(Betrieb)
- PV(Wartung und Remediation)
- PV(Parallelbetrieb und Migration)
- PV(Residualrisiko)
+ PV(optional quantifizierter Zusatznutzen)

Die Rechnung muss mindestens drei Perspektiven ausweisen:

1. nominaler Cashflow,
2. abgezinster Cashflow,
3. risiko-adjustierte Verteilung.

2.4 Monte-Carlo-Annahmen

Parameter	Verteilung	Annahme
Build-Multiplikator	triangular	0,90 / 1,00 / 1,35
Owned-Run-Multiplikator	triangular	0,85 / 1,00 / 1,40
jährliches SaaS-Wachstum	triangular	0 % / 7 % / 16 %
Delivery-Verzögerung	gerundete triangular	0 / 1 / 6 Monate
große Remediation	Bernoulli	20 % Wahrscheinlichkeit
Remediationkosten	triangular	5 % / 12 % / 30 % des Builds
Diskontsatz	fixed	8 % p.a.
Simulationen	fixed	50.000 je Szenario
Seed	fixed	20260729

[LIMITATION] Diese Verteilungen sind transparente Stressannahmen. Sie wurden nicht aus einem repräsentativen Projektportfolio geschätzt.

---

3. Synthese: Die sechs ökonomischen Fallen

3.1 Der falsche Vergleichszeitraum

Ein Build mit zwei Jahren Nutzungsdauer kann unattraktiv sein, derselbe Build bei fünf Jahren hochprofitabel. Der Horizont darf nicht passend zum gewünschten Ergebnis gewählt werden. Er muss aus realistischer Restnutzungsdauer, Strategie und Technologiezyklus abgeleitet werden.

3.2 Der Serverpreis als Ablenkung

Eine VM für 30 Euro im Monat sagt wenig über produktive TCO. Relevante Kosten entstehen durch:

• Updates,
• Backups und Restore-Tests,
• Monitoring,
• Security,
• Incident Response,
• Datenbankpflege,
• Verfügbarkeitsarchitektur,
• Dokumentation,
• Ownership und On-call.

3.3 Vollständige SaaS-Vermeidung ab Tag eins

In realen Migrationen existiert häufig Parallelbetrieb. Ein System kann technisch live sein, während Datenabgleich, Schulung und Rollout weiterlaufen. In dieser Phase fallen SaaS- und Owned-Kosten gleichzeitig an.

3.4 Nullwert für Risiko

Ein Build kann verspätet oder teurer werden. Ein SaaS-Anbieter kann Preise erhöhen oder Funktionen entziehen. Beide Seiten besitzen Risiko. Ein ehrlicher Business Case modelliert nicht nur das Risiko der bevorzugten Alternative.

3.5 Bilanzaktivierung als automatische Ersparnis

Aktivierung verändert die zeitliche Ergebniserfassung, nicht die zugrunde liegende Zahlung. Außerdem müssen die konkreten Ansatzkriterien erfüllt sein. „Quellcode vorhanden“ allein ist keine bilanzielle Entscheidung.

3.6 Strategischer Nutzen ohne Messplan

Ownership kann Datenzugang, Geschwindigkeit, M&A-Readiness oder Produktdifferenzierung verbessern. Solche Nutzen sind real möglich. Ohne Ausgangswert, Zielmetrik und Attribution werden sie jedoch zu Werbezahlen.

---

Teil I - Ownership-TCO und Build/Buy/Hybrid

I.1 Forschungsfrage

Unter welchen Kosten- und Zeitannahmen wird der Aufbau eines eigenen Systems wirtschaftlich günstiger als die Fortsetzung eines SaaS-Modells?

Der Report beantwortet nicht, was ein konkretes Projekt kosten wird. Er stellt ein Modell bereit, in das reale Angebots-, Vertrags- und Betriebskosten eingesetzt werden können.

---

I.2 Warum einfache SaaS-versus-Build-Vergleiche scheitern

Ein häufiger Vergleich lautet:

SaaS: 3.000 Euro pro Monat
Build: 60.000 Euro einmalig
Break-even: 20 Monate

Diese Rechnung unterschlägt mindestens:

• Betrieb
• Wartung
• Security Updates
• Monitoring
• Backup
• Support
• Änderungen
• Ausfallrisiko
• internes Product Ownership
• Kapitalkosten
• Migration
• Parallelbetrieb
• Exit
• Restwert
• unterschiedliche Leistungsumfänge

Umgekehrt unterschlagen reine Build-Kritiken häufig:

• steigende Seats
• Usage Overage
• Add-ons
• Enterprise-Gates
• Integrationskosten
• fortlaufende Agentur- oder Admin-Aufwände
• Wechselkosten
• Preisänderungsrisiko
• verlorene spezifische Prozessvorteile

Ein belastbarer Vergleich muss dieselbe fachliche Leistung, denselben Zeitraum und dieselbe Risikogrenze abbilden.

---

I.3 Modell

3.1 Variablen

Symbol	Bedeutung
S	monatlich vermiedene SaaS-Ausgabe
B	einmalige Build- und Einführungskosten
O	monatliche Kosten des eigenen Betriebs
T	Betrachtungszeitraum in Monaten
r	Diskontsatz
M	einmalige Migrations-/Parallelbetriebskosten
R	erwarteter Restwert oder Wiederverwendungswert

Das vereinfachte Kernmodell dieses Reports setzt M = 0 und R = 0, damit die zentralen Variablen sichtbar bleiben. In realen Business Cases müssen beide ergänzt werden.

3.2 Nominale TCO

SaaS-TCO(T)  = S × T
Owned-TCO(T) = B + O × T
Nominale Ersparnis(T) = SaaS-TCO(T) − Owned-TCO(T)

3.3 Nominaler Break-even

Break-even in Monaten = B / (S − O)

Die Formel ist nur sinnvoll, wenn S > O. Wenn der eigene monatliche Betrieb genauso teuer oder teurer als die vermiedene SaaS-Ausgabe ist, entsteht in diesem vereinfachten Modell kein Break-even.

3.4 Barwert

Der Report verwendet acht Prozent effektiven Jahresdiskontsatz. Der äquivalente Monatszins lautet:

r_m = (1 + 0,08)^(1/12) − 1

Der Barwert der monatlichen Nettoersparnis:

NPV(T) = −B + Σ[t=1..T] ((S − O) / (1 + r_m)^t)

Ein positiver NPV bedeutet nur, dass die modellierten Einsparungen unter dem gewählten Diskontsatz die Anfangsinvestition übersteigen. Er garantiert keine erfolgreiche Umsetzung.

---

I.4 Szenarien

Alle fünf Szenarien sind [SCENARIO]. Die Namen beschreiben Größenordnungen, nicht reale FW-Delta-Kunden.

Szenario	SaaS / Monat	Build	Owned Run / Monat	Break-even Monate	nominal 36 M.	nominal 60 M.	NPV 36 M.	NPV 60 M.
A – Kleines internes Tool	€1.000	€25.000	€250	33.3	€2.000	€20.000	€-968	€12.234
B – Teamplattform	€2.500	€50.000	€625	26.7	€17.500	€62.500	€10.081	€43.084
C – Bereichssystem	€5.000	€100.000	€1.250	26.7	€35.000	€125.000	€20.162	€86.168
D – Enterprise-Funktion	€10.000	€250.000	€2.500	33.3	€20.000	€200.000	€-9.675	€122.337
E – Plattformkonsolidierung	€25.000	€400.000	€6.250	21.3	€275.000	€725.000	€200.812	€530.842

Rundung: Euro auf volle Beträge; Break-even auf eine Nachkommastelle.

4.1 Szenario A – kleines internes Tool

• SaaS: 1.000 Euro/Monat
• Build: 25.000 Euro
• Betrieb: 250 Euro/Monat

Nach 36 Monaten beträgt die nominale Ersparnis 2.000 Euro. Unter Berücksichtigung des Diskontsatzes ist der Barwert jedoch rund −968 Euro.

[INTERPRETATION] Ein nominaler Break-even kurz vor dem Ende des Betrachtungszeitraums ist kein überzeugender Investment Case. Schon eine kleine Verzögerung oder Änderung kann den Vorteil beseitigen.

4.2 Szenario B – Teamplattform

• SaaS: 2.500 Euro/Monat
• Build: 50.000 Euro
• Betrieb: 625 Euro/Monat

Der nominale Break-even liegt bei 26,7 Monaten. Der Barwert nach drei Jahren beträgt rund 10.081 Euro, nach fünf Jahren rund 43.084 Euro.

4.3 Szenario C – Bereichssystem

Szenario C skaliert B proportional. Deshalb bleibt der Break-even identisch zu B. Absolute Ersparnis und Risiko sind jedoch höher.

[INTERPRETATION] Derselbe Break-even bedeutet nicht dasselbe Risikoprofil. Ein 100.000-Euro-Projekt benötigt stärkere Governance, Abnahme und Änderungsdisziplin als ein 50.000-Euro-Projekt.

4.4 Szenario D – Enterprise-Funktion

Mit 250.000 Euro Build-Kosten und 10.000 Euro vermiedener SaaS-Ausgabe ist die nominale Drei-Jahres-Ersparnis positiv, der Drei-Jahres-NPV aber negativ.

Das illustriert den Unterschied zwischen:

• „nach 36 Monaten wurden mehr Rechnungen vermieden als nominal ausgegeben“ und
• „die zeitlich gewichteten Einsparungen rechtfertigen die Kapitalbindung“.

4.5 Szenario E – Plattformkonsolidierung

Szenario E hat den schnellsten Break-even, obwohl die Anfangsinvestition mit 400.000 Euro am höchsten ist. Ursache ist die hohe monatliche Nettoersparnis.

[INTERPRETATION] Große Builds sind nicht automatisch langsamer wirtschaftlich. Entscheidend ist, wie viele wiederkehrende Kosten sie tatsächlich ersetzen und ob der Scope stabil bleibt.

---

I.5 Sensitivität

Die folgende Tabelle normalisiert das Modell. Build-Multiple beschreibt die Build-Kosten als Vielfaches der monatlichen SaaS-Ausgabe. Run-Quote beschreibt die eigenen monatlichen Betriebskosten als Anteil der vermiedenen SaaS-Ausgabe.

Build-Kosten	Run = 10 % von SaaS	Run = 25 %	Run = 40 %
12 × Monats-SaaS	13,3	16,0	20,0
24 × Monats-SaaS	26,7	32,0	40,0
36 × Monats-SaaS	40,0	48,0	60,0

Interpretation

• Bei Build-Kosten in Höhe von 12 Monats-SaaS-Ausgaben bleibt der Break-even selbst bei 40 Prozent Run-Quote bei 20 Monaten.
• Bei 36 Monats-SaaS-Ausgaben und 40 Prozent Run-Quote liegt der Break-even bei 60 Monaten.
• Je höher der dauerhafte eigene Betrieb, desto weniger trägt die Ownership-These allein.

---

I.6 Vollständige TCO-Komponenten

6.1 SaaS-Seite

Kostenblock	Beispiele
Subscription	Seats, Agenten, Hosts, MTU, MAR, Tasks, Credits
Add-ons	AI, API, Sandbox, SSO, Audit, Support
Einführung	Onboarding, Partner, Migration, Training
Betrieb	interne Administration, Rollen, Datenpflege
Integration	Middleware, Connector, Custom Code
Wachstum	zusätzliche User, Daten, Aktionen, Umgebungen
Risiko	Preiserhöhung, Planänderung, Produktende
Exit	Export, Parallelbetrieb, Migration, Vertragsrestlaufzeit

6.2 Ownership-Seite

Kostenblock	Beispiele
Discovery	Prozessaufnahme, Datenmodell, Scope
Build	Design, Engineering, Tests, Migration
Infrastruktur	Compute, Storage, Netzwerk, Backup
Betrieb	Monitoring, Updates, On-call, Support
Security	Hardening, Scans, Patch-Prozess
Änderungen	neue Anforderungen, APIs, regulatorische Anpassung
Personal	Product Owner, Administrator, Entwickler
Risiko	Verzögerung, Fehlplanung, Schlüsselpersonen
Exit/Replacement	Übergabe, Dokumentation, Neuplattform

[RECOMMENDATION] Ein Business Case muss mindestens einen realistischen, einen pessimistischen und einen Stressfall enthalten.

---

I.7 Entscheidungslogik: Build, Buy oder Hybrid

Build wird plausibler, wenn …

• der Prozess strategisch differenzierend ist,
• die Anforderungen über mehrere Jahre stabil genug sind,
• monatliche SaaS-Kosten substanziell sind,
• Seat- oder Usage-Wachstum den Preis stark erhöht,
• eigene Datenmodelle einen Wettbewerbsvorteil schaffen,
• Schnittstellen und Workflows dauerhaft benötigt werden,
• Source Code, Deployment und Datenkontrolle einen eigenständigen Wert haben,
• ein kompetenter Betreiber vorhanden ist.

Buy bleibt plausibler, wenn …

• der Prozess weitgehend Commodity ist,
• der Bedarf klein oder temporär ist,
• der Anbieter laufend komplexe externe Regeln pflegt,
• Time-to-value wichtiger als langfristige TCO ist,
• Betriebskompetenz fehlt,
• Produktanforderungen noch stark schwanken,
• der Marktstandard Interoperabilität erleichtert,
• ein Wechsel relativ günstig bleibt.

Hybrid ist häufig optimal

Beispiele:

• Standard-CRM plus eigene Event- und Integrationsschicht
• SaaS-Identity plus eigene Fachanwendung
• Managed Datenbank plus eigener Application Layer
• n8n- oder Open-Source-Runtime plus eigene Nodes und Workflows
• Cloud Storage plus portable Datenformate und Exit-Automation

[INTERPRETATION] Ownership muss nicht bedeuten, jedes Infrastrukturprimitive selbst zu entwickeln. Es bedeutet, die differenzierende Logik und den Exit bewusst zu kontrollieren.

---

I.8 Bilanzielle Einordnung

IAS 38 behandelt immaterielle Vermögenswerte. Software kann grundsätzlich ein immaterieller Vermögenswert sein, wenn die einschlägigen Definitions-, Kontroll- und Ansatzkriterien erfüllt sind. Für Entwicklungsprojekte gelten zusätzliche Kriterien, unter anderem technische Realisierbarkeit, Absicht und Fähigkeit zur Fertigstellung, erwarteter wirtschaftlicher Nutzen, verfügbare Ressourcen und verlässliche Kostenermittlung.

Wichtig:

• Forschungskosten und Entwicklungsaufwendungen sind nicht gleichzusetzen.
• Nicht jede Eigenentwicklung darf aktiviert werden.
• Nicht jede Code-Übergabe erzeugt automatisch Kontrolle im bilanziellen Sinn.
• Wartung und laufender Betrieb sind nicht automatisch Teil eines aktivierbaren Vermögenswerts.
• Bei SaaS-Konfiguration und -Customizing kann der Kunde häufig keinen separaten kontrollierten Software-Vermögenswert ansetzen; die konkrete Behandlung hängt von Vertrag und Leistung ab.

[RECOMMENDATION] Jede Aktivierungsaussage auf fwdelta.com muss deshalb lauten:

Eigene Software kann, abhängig von Kontrolle, Entwicklungsphase und erfüllten Ansatzkriterien, als immaterieller Vermögenswert bilanzierbar sein.

Nicht:

Eigene Software ist nach IAS 38 immer aktivierbar.

Dieser Report ersetzt keine Bilanzierungsberatung.

---

I.9 Risikoaufschlag und Real Options

Das vereinfachte Modell bewertet nicht den Optionswert schneller Kündbarkeit. SaaS kann einen realen Vorteil besitzen:

• geringe Anfangsinvestition,
• schneller Start,
• monatliche oder jährliche Kündbarkeit,
• Produktentwicklung durch den Anbieter,
• Verlagerung von Betriebsrisiko.

Eigene Software kann andere Optionen schaffen:

• freie Weiterentwicklung,
• Anbieterwechsel auf Infrastruktur-Ebene,
• Wiederverwendung von Komponenten,
• Integration ohne Planlimits,
• Verkauf oder Übertragung des Codes,
• geringere Grenzkosten zusätzlicher Nutzer.

Eine erweiterte TCO sollte diese Optionen als Szenariowerte berücksichtigen, nicht als garantierten Geldbetrag.

---

I.10 Datenanforderungen für einen realen Audit

Für ein konkretes Unternehmen benötigt das Modell:

1. letzte zwölf SaaS-Rechnungen,
2. Nutzer- und Usage-Entwicklung,
3. Add-ons und Overage,
4. interne Admin-Zeit,
5. Integrations- und Agenturkosten,
6. Vertragslaufzeiten,
7. Preissteigerungsklauseln,
8. Export- und Exit-Bedingungen,
9. fachliche Muss-Anforderungen,
10. realistische Build-Angebote,
11. Infrastruktur- und Betriebskonzept,
12. Änderungsbudget,
13. Diskontsatz,
14. Restwertannahme,
15. Risiko- und Verzögerungsszenario.

---

---

Teil II - Self-Hosted Operations TCO

II.1 Forschungsfrage

Wie verändert sich die 36-Monats-TCO eines Self-Hosted-Systems, wenn neben Infrastruktur auch Betriebsarbeit, Upgrades, Incidents, Initial Enablement und Managed Fees modelliert werden?

Nicht beantwortet werden:

• ob Self-Hosting günstiger als ein konkretes SaaS-Produkt ist,
• wie hoch reale Ausfallkosten sind,
• welche Architektur für einen Kunden geeignet ist,
• welche Providerpreise in drei Jahren gelten,
• welche Personalkosten ein Unternehmen tatsächlich trägt,
• ob Managed Operations einen bestimmten SLA-Wert liefert,
• welche steuerliche oder bilanzielle Behandlung gilt.

---

II.2 Profilannahmen

Profil	Infra/Monat	Routine/Monat	Upgrade/Quartal	Incidents/Jahr	Arbeitsrate
Micro	35 €	2 h	4 h	2 × 2 h	75 €/h
Standard	180 €	6 h	8 h	4 × 4 h	100 €/h
Critical	650 €	16 h	16 h	8 × 6 h	125 €/h

Profile

Micro

Ein einzelnes oder kleines internes System mit begrenztem Traffic, überschaubarem Datenvolumen und niedriger Kritikalität.

Standard

Eine produktive Business-Anwendung mit Monitoring, Backups, regelmäßigen Upgrades und mehreren Integrationen.

Critical

Ein geschäftskritischer Service mit höherer Redundanz, häufigeren Incidents, strengeren Change-Prozessen und größerer Betriebsverantwortung.

[CRITICAL] Die Namen sind Szenariobezeichnungen. Sie entsprechen keiner Norm und keiner garantierten Architektur.

---

II.3 Betriebsmodelle

3.1 Ad hoc

• minimale zusätzliche Infrastruktur,
• manuelle Eingriffe,
• wenig Initial Enablement,
• höhere laufende Routine- und Incidentarbeit,
• Wissen stärker personengebunden.

3.2 Standardized IaC + Runbooks

• Infrastrukturaufschlag von 15 Prozent im Modell,
• initiale Standardisierung,
• Infrastructure as Code,
• wiederholbare Deployments,
• dokumentierte Runbooks,
• reduzierte Routine-, Upgrade- und Incidentzeit.

3.3 Managed Operations

• Infrastrukturaufschlag von 30 Prozent im Modell,
• externer monatlicher Managed Fee,
• kleinere interne Restverantwortung,
• reduzierte interne Upgrade- und Incidentzeit,
• vertragliche Service- und Eskalationsleistung als eigener Kostenblock.

[INTERPRETATION] Managed Operations darf nicht als „Server plus ein paar Stunden“ modelliert werden. Der Wert liegt wesentlich in reservierter Verantwortung und Betriebsfähigkeit.

---

II.4 Berechnungslogik

Nominale TCO

TCO 36M
= Infrastruktur 36M
+ interne Arbeit 36M
+ Managed Fees 36M

Die interne Arbeit enthält:

Initial Enablement
+ Routinebetrieb
+ Upgrades
+ Incident Handling

Barwert

Monatliche beziehungsweise periodisierte Zahlungen werden mit einem Jahresdiskontsatz von 8 Prozent auf den Stichtag abgezinst.

NPV = Summe(Cashflow_t / (1 + r)^(t/12))

Der Barwert ist keine Investitionsberatung. Er macht nur früh und spät anfallende Kosten vergleichbarer.

Nicht monetarisiert

• Downtime,
• Umsatzverlust,
• regulatorische Folgen,
• Datenverlust,
• Mitarbeiterfluktuation,
• Bus Factor,
• Opportunity Cost,
• Security Breach,
• Vendorwechsel,
• Restwert eigener Automatisierung und Dokumentation.

---

II.5 Ergebnisse

Profil	Betriebsmodell	Infra 36M	Arbeitszeit	interne Arbeit	Managed Fee	nominale TCO	Barwert 8 %
Micro	Ad hoc	1.260 €	132,0 h	9.900 €	0 €	11.160 €	9.885 €
Micro	Standardized IaC + runbooks	1.449 €	116,8 h	8.760 €	0 €	10.209 €	9.385 €
Micro	Managed operations	1.638 €	43,4 h	3.255 €	12.600 €	17.493 €	15.724 €
Standard	Ad hoc	6.480 €	360,0 h	36.000 €	0 €	42.480 €	37.607 €
Standard	Standardized IaC + runbooks	7.452 €	290,0 h	29.000 €	0 €	36.452 €	33.188 €
Standard	Managed operations	8.424 €	103,6 h	10.360 €	32.400 €	51.184 €	45.950 €
Critical	Ad hoc	23.400 €	912,0 h	114.000 €	0 €	137.400 €	121.603 €
Critical	Standardized IaC + runbooks	26.910 €	692,8 h	86.600 €	0 €	113.510 €	102.759 €
Critical	Managed operations	30.420 €	240,8 h	30.100 €	90.000 €	150.520 €	134.909 €

Interpretation pro Profil

Micro

[CALCULATED] Standardisierung spart gegenüber Ad hoc nominal 951 Euro beziehungsweise 8,5 Prozent. Der Effekt bleibt begrenzt, weil Initial Enablement bei kleinem Umfang einen großen Anteil besitzt.

[CALCULATED] Managed Operations liegt 6.333 Euro über Ad hoc. Das kann für ein unkritisches System unwirtschaftlich sein, sofern keine Verfügbarkeits-, Security- oder Personalgründe den Servicewert rechtfertigen.

Standard

[CALCULATED] Standardisierung reduziert die nominale TCO um 6.028 Euro beziehungsweise 14,2 Prozent.

[INTERPRETATION] Bei wiederkehrender Betriebsarbeit beginnt sich Automatisierung zu amortisieren. Das Modell zeigt genau den Bereich, in dem IaC, Runbooks und standardisierte Upgrades von „Engineering Hygiene“ zu einer wirtschaftlichen Kontrolle werden.

[CALCULATED] Managed Operations kostet 8.704 Euro mehr als Ad hoc, reduziert die interne Arbeitszeit jedoch von 360,0 auf 103,6 Stunden.

Critical

[CALCULATED] Standardisierung reduziert die nominale TCO um 23.890 Euro beziehungsweise 17,4 Prozent.

[CALCULATED] Managed Operations kostet 13.120 Euro mehr als Ad hoc, reduziert die intern modellierte Arbeitszeit von 912,0 auf 240,8 Stunden.

[INTERPRETATION] Bei kritischen Systemen kann die freigesetzte interne Kapazität wertvoller sein als die nominale Differenz. Das muss jedoch über Service-Level, Reaktionszeit und Business Impact belegt werden – nicht über den Begriff „managed“.

---

II.6 Die Arbeitskosten dominieren

Ad hoc

Profil	Anteil interner Arbeit an nominaler TCO
Micro	88,71 %
Standard	84,75 %
Critical	82,97 %

Standardized IaC + Runbooks

Profil	Anteil interner Arbeit
Micro	85,81 %
Standard	79,56 %
Critical	76,29 %

Beim Managed-Modell sinkt der interne Arbeitsanteil auf rund 19 bis 20 Prozent, weil ein großer Kostenblock als externer Managed Fee ausgewiesen wird. Das bedeutet nicht, dass „Arbeit verschwindet“; sie wird vertraglich eingekauft.

Der Server ist sichtbar, weil er eine Rechnung hat. Betriebsarbeit ist gefährlich, weil sie oft nur Kalenderzeit ist.

---

II.7 Was zum Routinebetrieb gehört

Ein seriöses Betriebsbudget umfasst mindestens:

• Betriebssystem- und Runtime-Patches,
• Container- und Dependency-Updates,
• Backup-Überwachung,
• Restore Tests,
• Zertifikate und Domains,
• Secrets Rotation,
• Log- und Metrikprüfung,
• Disk, Memory, CPU und Queue Capacity,
• Datenbankwartung,
• Security Advisories,
• Benutzer- und Zugriffsreviews,
• Kosten- und Ressourcenprüfung,
• Dokumentation,
• Bereitschaft für Incidents.

[RECOMMENDATION] Jede Tätigkeit erhält Owner, Frequenz, erwartete Dauer und Nachweisartefakt.

---

II.8 Initial Enablement als Investition

Im Modell enthält Standardisierung initial:

Profil	Initiale Enablement-Arbeit
Micro	40 h
Standard	80 h
Critical	160 h

Managed Operations enthält im Szenario 20, 40 beziehungsweise 80 Stunden internen Enablement-Aufwand.

Typische Ergebnisse:

• IaC Repository,
• CI/CD,
• Baseline Hardening,
• Monitoring und Alerts,
• Backup/Restore,
• Runbooks,
• Secrets Management,
• Inventar,
• Ownership,
• Change- und Incident-Prozess.

Diese Artefakte können über mehrere Jahre Wert erzeugen. In der Rechnung werden sie vollständig als Kosten behandelt; ein Restwert wird nicht angesetzt.

---

II.9 Managed Operations richtig bewerten

Ein Managed-Angebot sollte nicht nur monatlichen Preis nennen. Es sollte definieren:

• Coverage Hours,
• Response und Resolution Targets,
• Severity-Modell,
• Patch-SLA,
• Backup- und Restore-Verantwortung,
• On-Call,
• Change Windows,
• Security Monitoring,
• Incident-Kommunikation,
• Reporting,
• Ausschlüsse,
• Exit und Dokumentationsübergabe.

Economic Capacity Value

[SCENARIO] Wenn ein Managed-Modell im Standard-Profil 256,4 interne Stunden über 36 Monate freisetzt, ist die Frage nicht nur, was diese Stunden laut Rate kosten. Entscheidend ist, ob die Organisation sie tatsächlich für höherwertige Arbeit verwenden kann.

Capacity Value
= freigesetzte Stunden
× realisierbarer Wert pro Stunde

Dieser Wert wird im Hauptmodell bewusst nicht angesetzt, weil er organisationsspezifisch ist.

---

II.10 Vergleich mit SaaS

Ein fairer SaaS-versus-Self-Hosted-Vergleich benötigt dieselbe Funktions- und Servicegrenze.

SaaS-Seite

• Subscription,
• Seats und Usage,
• Support,
• Integrationen,
• Export und Egress,
• interne Administration,
• Vertrags- und Renewal-Aufwand,
• Anpassungsgrenzen,
• Exit.

Self-Hosted-Seite

• Build/Implementation,
• Infrastruktur,
• Betrieb,
• Upgrades,
• Security,
• Support,
• Change Requests,
• Incident Risk,
• Dokumentation,
• Restwert und Portabilität.

[CRITICAL] Dieser Report setzt keine SaaS-Kosten ein. Er darf deshalb nicht allein zur Behauptung verwendet werden, Self-Hosting spare einen bestimmten Prozentsatz.

---

II.11 Sensitivitäten

Die Ergebnisse reagieren besonders auf:

1. Arbeitsrate,
2. Routinezeit,
3. Incidenthäufigkeit und -dauer,
4. Initial Enablement,
5. Managed Fee,
6. Kritikalität und Redundanz,
7. Wachstums- und Migrationsereignisse.

Arbeitsrate ±25 Prozent

Da Arbeitskosten in vielen Szenarien dominieren, verschiebt eine um 25 Prozent höhere oder niedrigere Rate die TCO deutlich stärker als kleine Serverpreisänderungen.

Incident Tail Risk

Das Modell verwendet Durchschnittswerte. Ein einzelner schwerer Incident kann die gesamte Jahresrechnung übersteigen. Kritische Systeme benötigen deshalb:

• Backup und Restore,
• Redundanz,
• getestete Failover,
• Security Monitoring,
• Incident Commander,
• Postmortem.

---

II.12 Entscheidungsregel

Self-Hosting ist wirtschaftlich plausibel, wenn:

• der Prozess strategisch oder differenzierend ist,
• Nutzung hoch und relativ stabil ist,
• Abhängigkeit oder Datenkontrolle wichtig ist,
• Betrieb standardisierbar ist,
• ein klarer Owner existiert,
• Exit- und Restwert relevant sind.

SaaS kann wirtschaftlich besser sein, wenn:

• Bedarf unsicher oder kurzlebig ist,
• Commodity-Funktion ausreicht,
• internes Betriebswissen fehlt,
• Compliance-/Supportwert des Anbieters hoch ist,
• ein schneller Start wichtiger als Ownership ist,
• Wechselkosten beherrschbar bleiben.

---

---

4. Bilanzielle Einordnung: IAS 38 ohne Marketingverkürzung

4.1 Grundprinzip

IAS 38 behandelt immaterielle Vermögenswerte. Für Software ist unter anderem zu prüfen, ob eine identifizierbare, nicht monetäre Ressource ohne physische Substanz vorliegt und ob die Organisation diese Ressource kontrolliert. Bei selbst geschaffenen immateriellen Vermögenswerten gelten zusätzliche Anforderungen, insbesondere die Trennung von Forschungs- und Entwicklungsphase sowie die Nachweisbarkeit technischer Realisierbarkeit und künftigen wirtschaftlichen Nutzens.

4.2 SaaS und Konfiguration

Die IFRIC-Agenda-Entscheidung zu Konfigurations- und Anpassungskosten in Cloud-Computing-Arrangements betont, dass der Kunde häufig nicht die zugrunde liegende Anwendung kontrolliert. Dann entsteht aus der Konfiguration regelmäßig kein separates immaterielles Asset des Kunden. In bestimmten Konstellationen kann zusätzlicher Code, den der Kunde kontrolliert, separat zu prüfen sein.

4.3 Praktische Dokumentation

Ein Projekt, das eine bilanzielle Prüfung ermöglichen soll, braucht mindestens:

• klare Projektphasen und Genehmigungszeitpunkte,
• Trennung Forschung/Entwicklung,
• dokumentierte technische Realisierbarkeit,
• Budget und Ressourcenfreigabe,
• erwarteten wirtschaftlichen Nutzen,
• Kontroll- und Nutzungsrechte,
• verlässliche Kostenerfassung,
• Nutzungsdauer und Abschreibungsmethode,
• Impairment- und Abbruchregeln.

[CRITICAL] Ob und in welcher Höhe aktiviert werden darf, entscheidet die zuständige Bilanzierungsfunktion beziehungsweise der Abschlussprüfer im konkreten Sachverhalt.

---

5. Entscheidungsrahmen

5.1 Build ist tendenziell plausibel, wenn …

• der Prozess strategisch differenziert,
• die Anforderung über mehrere Jahre stabil,
• die vermiedene Lizenzbasis substanziell,
• Daten und Logik kontrolliert werden müssen,
• der Scope klar begrenzbar,
• Betriebskompetenz vorhanden oder einkaufbar,
• ein realistischer Exit aus dem Build selbst möglich ist.

5.2 Buy ist tendenziell plausibel, wenn …

• die Funktion Commodity ist,
• die Nutzerzahl klein,
• Geschwindigkeit wichtiger als Eigentum,
• Anforderungen sich stark ändern,
• regulatorische oder operative Last durch den Anbieter sinnvoll getragen wird,
• ein funktionierender Export und Wettbewerb bestehen.

5.3 Hybrid ist tendenziell plausibel, wenn …

• Identität, Billing oder Collaboration Standard bleiben können,
• Differenzierungslogik in eigener Schicht liegt,
• Daten in kontrolliertem Modell repliziert werden,
• Integrationen offen und versioniert sind,
• SaaS austauschbar statt systemführend bleibt.

5.4 Mindest-Hurdle

Vor Freigabe eines Builds sollte ein Board-Paper mindestens zeigen:

1. Base, Downside und Upside,
2. 36- und 60-Monats-NPV,
3. Break-even,
4. Delivery- und Scope-Risiko,
5. Betriebskosten inklusive Arbeit,
6. Exit aus dem eigenen System,
7. Nicht-finanzielle Nutzen mit Messplan,
8. klare Entscheidung, welche SaaS-Kosten tatsächlich entfallen.

---

6. Visualisierungsspezifikation

Chart 1 - NPV 36 vs. 60 Monate

• Daten: FDR-2026-03_ownership_tco_base_scenarios.csv
• Typ: gruppierte Balken
• Null-Linie sichtbar
• nominale Ersparnis nicht mit NPV mischen

Chart 2 - Monatliche kumulierte Cashflows

• Daten: FDR-2026-03_monthly_cashflows_60m.csv
• fünf getrennte Small Multiples
• nominal und PV nicht in derselben Linie ohne klare Legende

Chart 3 - Monte-Carlo-Verteilung

• Daten: FDR-2026-03_monte_carlo_summary.csv
• P10/Median/P90 als Intervalle
• Hinweis: Verteilungen sind Szenarioannahmen

Chart 4 - Sensitivitätsmatrix

• Daten: FDR-2026-03_sensitivity_grid_36m.csv
• Heatmap je Szenario
• X: SaaS-Baseline-Multiplikator
• Y: Build-Kosten-Multiplikator
• Farbe: 36M-NPV

Chart 5 - Self-Hosted TCO-Komponenten

• Daten: FDR-2026-03_selfhosted_tco_results.csv
• gestapelte Balken: Infrastruktur, Arbeit, Managed Fees

---

7. Reproduzierbarkeit

Datendateien

• data/FDR-2026-03_ownership_tco_base_scenarios.csv
• data/FDR-2026-03_monthly_cashflows_60m.csv
• data/FDR-2026-03_monte_carlo_parameters.csv
• data/FDR-2026-03_monte_carlo_summary.csv
• data/FDR-2026-03_sensitivity_grid_36m.csv
• data/FDR-2026-03_selfhosted_tco_profiles.csv
• data/FDR-2026-03_selfhosted_tco_results.csv

Reproduktionscode

scripts/FDR-2026-03_reproduce_tco_model.py

Pflichtregeln

• keine Kundenclaims aus Szenarien machen;
• keine Monte-Carlo-Wahrscheinlichkeit ohne Parameterdatei zitieren;
• NPV und nominale Ersparnis nicht vermischen;
• zusätzliche Nutzen separat ausweisen;
• Bilanzierung nicht als garantierte Aktivierung formulieren;
• alle Währungen und Diskontsätze sichtbar machen.

---

8. Grenzen

1. Die Szenarien sind hypothetisch.
2. Die Monte-Carlo-Verteilungen sind nicht empirisch kalibriert.
3. Steuern, Finanzierung, Restwerte und Inflation außerhalb der SaaS-Preisannahme sind nicht vollständig modelliert.
4. Opportunitätskosten des internen Teams können höher oder niedriger sein.
5. Projektabbrüche wurden nur indirekt über Kostenmultiplikatoren erfasst.
6. Sicherheits- und Compliance-Nutzen sind nicht monetarisiert.
7. SaaS-Rabatte und Mindestabnahmen fehlen, sofern nicht im individuellen Modell ergänzt.
8. Aktivierung nach IAS 38 ist sachverhaltsabhängig.
9. Software kann technisch oder wirtschaftlich schneller obsolet werden als angenommen.
10. Ein positiver NPV ersetzt keine Architektur-, Security- oder Delivery-Prüfung.

---

9. Zitierhinweise

Zulässig:

„Im offengelegten FW-Delta-Szenariomodell lagen die nominalen Break-even-Zeiten zwischen 21,3 und 33,3 Monaten. Die Ergebnisse sind keine Kundenfälle.“

Nicht zulässig:

„Eigene Software amortisiert sich immer nach spätestens 33 Monaten.“

Zulässig:

„Die Simulation zeigt, dass ein 36-Monats-Horizont bei kleinen oder kapitalintensiven Builds deutlich unsicherer sein kann als ein 60-Monats-Horizont.“

Nicht zulässig:

„FW Delta hat bewiesen, dass Build immer günstiger ist.“

---

10. Versionshistorie

• 1.0 · Juli 2026 · Deterministisches 36-/60-Monats-Modell, drei Betriebsmodelle und 50.000-Läufe-Szenarioanalyse konsolidiert; IFRS-Einordnung ergänzt.
• Live-Version offen · Vor Publikation IFRS-Quellen und alle Rechenartefakte gegen die finale Fassung prüfen.

---

11. Quellen

1. IFRS Foundation, „IAS 38 Intangible Assets“, https://www.ifrs.org/issued-standards/list-of-standards/ias-38-intangible-assets/, abgerufen im Juli 2026.
2. IFRS Foundation, „Configuration or Customisation Costs in a Cloud Computing Arrangement (IAS 38)“, https://www.ifrs.org/projects/completed-projects/2021/configuration-or-customisation-costs-in-a-cloud-computing-arrangement-ias-38/, abgerufen im Juli 2026.
3. IFRS Foundation, „IFRIC Update March 2021“, https://www.ifrs.org/news-and-events/updates/ifric/2021/ifric-update-march-2021/, abgerufen im Juli 2026.
4. European Commission, „Data Act explained“, https://digital-strategy.ec.europa.eu/en/factpages/data-act-explained, abgerufen im Juli 2026.
5. Verordnung (EU) 2023/2854 – Data Act, https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng.
6. Zapier, „Pricing“, https://zapier.com/pricing, abgerufen im Juli 2026.
7. n8n, „Pricing“, https://n8n.io/pricing/, abgerufen im Juli 2026.
8. Microsoft, „Power BI pricing“, https://www.microsoft.com/de-de/power-platform/products/power-bi/pricing, abgerufen im Juli 2026.
9. Tableau, „Pricing“, https://www.tableau.com/pricing, abgerufen im Juli 2026.
10. HubSpot, „Sales Hub pricing“, https://www.hubspot.com/pricing/sales, abgerufen im Juli 2026.
11. FinOps Foundation, „FinOps Framework“, https://www.finops.org/framework/, abgerufen im Juli 2026.
12. AWS, „Pricing Calculator“, https://calculator.aws/, abgerufen im Juli 2026.
13. Microsoft Azure, „Pricing calculator“, https://azure.microsoft.com/en-us/pricing/calculator/, abgerufen im Juli 2026.
14. Hetzner Docs, Price adjustment 2026, https://docs.hetzner.com/general/infrastructure-and-availability/price-adjustment/, abgerufen im Juli 2026.
15. Hetzner, Cloud, https://www.hetzner.com/cloud/, abgerufen im Juli 2026.
16. Hetzner, Object Storage, https://www.hetzner.com/storage/object-storage/, abgerufen im Juli 2026.
17. OVHcloud, Public Cloud pricing, https://www.ovhcloud.com/en/public-cloud/prices/, abgerufen im Juli 2026.
18. OVHcloud, Object Storage, https://www.ovhcloud.com/en/public-cloud/object-storage/, abgerufen im Juli 2026.
19. Scaleway, Pricing, https://www.scaleway.com/en/pricing/, abgerufen im Juli 2026.
20. Scaleway, Object Storage, https://www.scaleway.com/en/object-storage/, abgerufen im Juli 2026.
21. DigitalOcean, Droplet pricing, https://www.digitalocean.com/pricing/droplets, abgerufen im Juli 2026.
22. DigitalOcean Docs, Backups pricing, https://docs.digitalocean.com/products/backups/details/pricing/, abgerufen im Juli 2026.
23. NIST SP 800-218, Secure Software Development Framework, https://csrc.nist.gov/pubs/sp/800/218/final, abgerufen im Juli 2026.
24. CNCF, Cloud Native Security Whitepaper, https://www.cncf.io/reports/cloud-native-security-whitepaper/, abgerufen im Juli 2026.
25. IFRS Foundation, „IAS 38 Intangible Assets“ (issued standards, 2026), https://www.ifrs.org/content/dam/ifrs/publications/html-standards/english/2026/issued/ias38.html, abgerufen im Juli 2026.
26. IFRS Interpretations Committee, „Configuration or Customisation Costs in a Cloud Computing Arrangement (IAS 38)“, Agenda Decision, März 2021, https://www.ifrs.org/projects/completed-projects/2021/configuration-or-customisation-costs-in-a-cloud-computing-arrangement-ias-38/tentative-agenda-decision-and-comment-letters/, abgerufen im Juli 2026.
27. IASB, „Intangible Assets – Definition of intangible asset and supporting requirements (SaaS test case)“, Staff Paper AP17, Juli 2026, https://www.ifrs.org/content/dam/ifrs/meetings/2026/july/iasb/ap17-changes-definition-guidance-saas-test-case.pdf, abgerufen im Juli 2026.

---

Disclosure und Haftungsausschluss

FW Delta verkauft individuelle Softwareentwicklung und kontrollierte Infrastruktur. Ein positiver Ownership-Business-Case kann daher dem wirtschaftlichen Interesse des Herausgebers entsprechen. Gegenmaßnahmen dieses Reports sind offene Annahmen, negative Szenarien, Barwertrechnung, Grenzen und reproduzierbarer Code.

Der Report ist keine Bilanzierungs-, Steuer-, Rechts-, Finanzierungs- oder Anlageberatung. IAS 38 und SaaS-Konfiguration müssen im konkreten Abschluss mit qualifizierten Fachpersonen beurteilt werden.