Headless-Commerce-TCO: ein Modell, auf das sich eine Entscheidung stützen kann

1. Die Entscheidungsfrage festlegen

Das Modell vergleicht konkrete Optionen mit identischem fachlichem Umfang. Typische Optionen sind: die bestehende Plattform gezielt verbessern, die Storefront entkoppeln oder vollständig auf eine neue Plattform wechseln. Unterschiede im Funktionsumfang dürfen nicht stillschweigend als Vorteil der Architektur verbucht werden.

Legen Sie Zeitraum, Währung, steuerliche Behandlung, interne Verrechnung und Startzeitpunkt fest. Die 24 Monate dienen hier als gemeinsamer Vergleichsrahmen und sagen nichts über die wirtschaftliche Nutzungsdauer aus. Laufen Verträge oder Investitionszyklen länger, ergänzen Sie einen längeren Horizont.

• Baseline und jede Zieloption schriftlich abgrenzen.
• Pflichtumfang, optionale Funktionen und bewusst ausgeschlossene Arbeiten trennen.
• Einmalige, laufende und nutzungsabhängige Kosten getrennt erfassen.
• Für jede Annahme und Datenquelle eine verantwortliche Person benennen.
• Alle Beträge auf denselben Preisstand und dieselbe Währung umrechnen.

2. Die TCO24-Formel

Die Grundformel trennt die Anfangsinvestition vom monatlichen Betrieb. Sie ist bewusst so einfach gehalten, dass sich jede Zahl bis zur Rechnung, zum Vertrag, zum Gehaltsband oder zum Mengentreiber zurückverfolgen lässt.

TCO24 = Build₀ + Migration₀ + Enablement₀ + Σ(m=1..24)[Platformₘ + Cloudₘ + SaaSₘ + Peopleₘ + Operationsₘ + Securityₘ + Changeₘ] + ExitProvision₂₄. Risiken werden zunächst getrennt berechnet, damit feste Ausgaben und unsichere Ereignisse nicht vermischt werden.

3. Delta-TCO: Es zählt die Differenz zur Baseline

Entscheidend ist die Differenz zu einer realistischen Baseline: ΔTCO24 = TCO24(Zieloption) − TCO24(Baseline). Ein negatives Delta bedeutet, dass die Zieloption günstiger ist. Ein positives Delta muss durch zusätzlichen Deckungsbeitrag, vermiedenes Risiko oder strategisch notwendige Fähigkeiten gerechtfertigt sein.

Auch die Baseline kostet Geld. Dazu gehören verbleibende Lizenzen, notwendige Upgrades, Wartung, manuelle Prozesse, Aufwand für Incidents und Änderungen, die ohnehin anstehen. Versunkene Kosten dürfen Sie dagegen nicht noch einmal als künftige Ausgabe ansetzen.

4. Optional: Kapitalwert (NPV) bei unterschiedlich verteilten Zahlungen

Wenn die Optionen sehr unterschiedliche Zahlungszeitpunkte haben, ergänzen Sie den Kapitalwert. NPV = C₀ + Σ(t=1..24)[Cₜ / (1 + rₘ)^t]. Cₜ ist der Netto-Cashflow im Monat t. Bei einer reinen Kostenbetrachtung werden Auszahlungen durchgängig entweder als positive Kosten oder als negative Cashflows geführt. Mischen Sie die Vorzeichen nicht.

Der monatliche Diskontsatz rₘ wird aus einem von Finance freigegebenen Jahreszins abgeleitet und nicht vom Projektteam festgelegt. Bei kurzen Horizonten ist der Effekt oft klein. Vorauszahlungen, lange Parallelphasen oder spät anfallende Exit-Kosten lassen sich damit aber sauberer vergleichen.

• Den NPV nur ergänzend zur nominalen TCO ausweisen.
• Diskontsatz, Zahlungsmonat und Vorzeichenkonvention dokumentieren.
• Vorauszahlungen aus Verträgen im tatsächlichen Zahlungsmonat erfassen.
• Nutzen-Cashflows getrennt von den Kosten zeigen, bevor ein Netto-NPV gebildet wird.

5. Die vollständige Kostentabelle

Die Tabelle ist das Arbeitsgerüst des Modells. Ordnen Sie Kosten nicht nur nach Anbieter, sondern auch nach der Fähigkeit, die sie verursacht, und nach ihrem Treiber. So bleibt sichtbar, ob Kosten mit Traffic, Bestellungen, SKUs, Märkten, Deployments oder Teamkapazität wachsen.

6. Eingabedaten und ihre Qualität

Beobachtete Daten gehen vor Schätzungen: Rechnungen, Billing-Exporte, Verträge, die tatsächliche Teamauslastung, Incident-Tickets, Release-Historie und Trafficprofile. Angebote sind Eingaben für die Zieloption, aber kein Beleg dafür, wie viel später tatsächlich genutzt wird.

Jede Eingabe bekommt ein Vertrauensniveau. Hoch heißt: gemessener oder vertraglich festgelegter Wert. Mittel heißt: nachvollziehbar abgeleitet. Niedrig heißt: unbestätigte Annahme. Sensitivitätsanalysen konzentrieren sich auf Werte mit niedrigem Vertrauen und großer Wirkung auf die TCO.

• Monatliche Orders, Sessions, API-Requests und Datentransfer aus demselben Zeitraum verwenden.
• Spitzen- und Durchschnittslast nicht verwechseln.
• Rabatte, Mindestabnahmen, Freikontingente und Preisstaffeln zeitlich korrekt abbilden.
• Interne Vollkosten mit Finance abstimmen; das Gehalt allein ist nicht der Kostensatz.
• Kapazität für die Roadmap von Kapazität für Betrieb, Support und Incidents trennen.
• Wechselkurseffekte nur mit freigegebener Annahme oder als eigenes Szenario berücksichtigen.

7. Base, Peak und Downside rechnen

Eine einzelne Prognose verdeckt Unsicherheit. Das Base-Szenario bildet die freigegebene Planung ab. Peak prüft saisonale oder kampagnenbedingte Last und vertragliche Staffeln. Downside prüft schwächeres Wachstum, eine verzögerte Migration und ausbleibende Einsparungen.

Downside meint dabei nicht die maximale technische Last, sondern den schlechteren wirtschaftlichen Verlauf: längerer Parallelbetrieb, spätere Kündigung des Altvertrags, mehr manuelle Nacharbeit oder geringere Akzeptanz. Verändern Sie nur dokumentierte Treiber und verzichten Sie auf beliebige Prozentaufschläge.

• Die Treiber je Szenario tabellarisch nebeneinanderstellen.
• Keine Einsparung buchen, bevor die Abschaltung technisch und vertraglich möglich ist.
• Kapazitätsgrenzen und Preisstaffeln ausdrücklich testen.
• Die Ergebnisse je Szenario als TCO, Delta-TCO und Kosten je Geschäftseinheit darstellen.

8. Unit Economics mit Geschäftstreibern verbinden

Unit Economics im Sinne von FinOps setzen Technologieausgaben ins Verhältnis zu einer fachlichen Einheit. Im Commerce eignen sich zum Beispiel Kosten pro Bestellung, pro aktivem Kunden, pro Markt oder pro erfolgreichem Checkout. Die Einheit muss zur Entscheidung passen und für alle Optionen gleich definiert sein.

Kosten pro Bestellung = zurechenbare Commerce-Kosten / erfolgreich angenommene Bestellungen. Weisen Sie zusätzlich fixe und variable Anteile aus. Sinken die Stückkosten bei wachsendem Volumen, kann das ein Skaleneffekt sein. Niedrige Stückkosten bei ausgelagerten Teamkosten deuten dagegen oft nur auf eine unvollständige Zuordnung hin.

9. Risikoadjustierte Kosten

Unsichere Ereignisse gehören nicht als pauschaler Puffer in jeden Kostenblock. Führen Sie ein Risikoregister mit Ereignis, Ursache, Bandbreite der Eintrittswahrscheinlichkeit, finanzieller Auswirkung, Gegenmaßnahme und Verantwortlichem. Die erwarteten Risikokosten werden als Σ(Wahrscheinlichkeitᵢ × Auswirkungᵢ) ausgewiesen.

Risikoadjustierte TCO24 = TCO24 + erwartete Risikokosten24. Das ist eine Planungshilfe und keine Vorhersage. Abhängige Risiken dürfen nicht einfach addiert werden, denn Migrationsverzug, Parallelbetrieb und verspätete Vertragskündigung beschreiben unter Umständen dasselbe Ereignis.

• Wahrscheinlichkeiten als begründete Bandbreiten erfassen, ohne Scheingenauigkeit.
• Die Auswirkung ohne bereits eingerechnete Kosten bestimmen.
• Die Kosten der Gegenmaßnahme getrennt ausweisen.
• Das Restrisiko nach der Maßnahme neu bewerten.

10. Nutzen nicht als Kostenersparnis ausweisen

Headless kann schnellere Experimente, neue Kanäle oder weniger manuelle Arbeit ermöglichen. Das sind Nutzenhypothesen. Dokumentieren Sie sie mit Wirkmechanismus, Messgröße, Baseline, Verantwortlichem und dem frühesten Monat, in dem sie wirken können.

Nehmen Sie Nutzen nur dann in den Business Case auf, wenn die Kausalkette belastbar ist. Ein schnelleres Frontend garantiert keine höhere Conversion. Eine neue Architektur führt nicht zu häufigeren Releases, wenn Freigaben oder Produktprozesse der eigentliche Engpass bleiben.

11. Prognose und Ist-Kosten laufend steuern

Mit der Freigabe ist das Modell nicht erledigt. Spielen Sie monatlich Ist-Kosten und Mengen ein, erklären Sie Abweichungen nach Preis, Nutzung, Umfang und Zeitplan und aktualisieren Sie die Prognose. FinOps ist eine wiederkehrende Zusammenarbeit von Engineering, Finance und Fachbereich.

Legen Sie Tags, Accounts, Kostenstellen oder andere Zuordnungen vor dem Build fest. Gemeinsame Kosten werden nach einer dokumentierten Regel verteilt. Die Zuordnung muss nicht perfekt sein, wohl aber stabil und für Entscheidungen brauchbar.

• Monatlicher Abgleich von Prognose und Ist mit Engineering, Finance und Product.
• Abweichungen nach Preis, Menge, Architektur und Planverzug einordnen.
• Budgets und Anomalien mit Verantwortlichem und Reaktionsweg versehen.
• Ungenutzte Umgebungen, überdimensionierte Ressourcen und doppelte Tools regelmäßig prüfen.
• Modellversion und geänderte Annahmen protokollieren.

12. Entscheidungskriterien und Freigabepunkte

Die günstigste Option ist nicht automatisch die richtige. Die Entscheidung verbindet die TCO mit Pflichtfähigkeiten, Umsetzbarkeit, Risiko und Umkehrbarkeit. Legen Sie die Schwellenwerte intern fest, statt fremde Benchmarks zu übernehmen.

13. Checkliste zur Abnahme des TCO24-Modells

Entscheidungsreif ist ein Modell, wenn eine unbeteiligte Person jede wesentliche Zahl und Formel nachvollziehen kann und die Option auch im Downside-Szenario kontrolliert endet.

• Baseline und Zieloption haben denselben Pflichtumfang.
• TCO24 umfasst Build, Migration, Enablement, Run, Change und Exit.
• Das Delta-TCO wird gegen eine realistische Baseline gerechnet.
• Der NPV verwendet ausschließlich einen von Finance freigegebenen Diskontsatz.
• Jede Eingabe hat Quelle, Verantwortlichen, Einheit, Zeitraum und Vertrauensniveau.
• Base, Peak und Downside verändern dokumentierte Treiber.
• Altvertrag und Parallelbetrieb enden nicht vor dem realistisch möglichen Termin.
• Die Personalkosten enthalten Betrieb, Rufbereitschaft, Upgrades und Incident-Arbeit.
• Unit Economics beruhen auf einer stabilen fachlichen Einheit.
• Risikokosten sind von festen Kosten getrennt und nicht doppelt gezählt.
• Nutzenhypothesen haben Baseline, Wirkmechanismus und Messplan.
• Der Abgleich von Prognose und Ist sowie die Kostenzuordnung gehören zum laufenden Betrieb.
• Die Go/No-go-Kriterien wurden vor der Anbieterentscheidung beschlossen.