TCO im E-Commerce: Warum der Projektpreis nur der Anfang ist

Wer ein Angebot für einen neuen Onlineshop erhält, kann die Projektkosten meist gut nachvollziehen. Implementierung, Lizenzen und Hosting sind klar kalkuliert und lassen sich problemlos vergleichen. Schwieriger ist dagegen einzuschätzen, was der Shop nach dem Go-live tatsächlich kosten wird.

Denn mit dem laufenden Betrieb beginnt ein wesentlicher Teil der Total Cost of Ownership. Ein Magento-Shop wird häufig fünf bis sieben Jahre genutzt, bevor eine grundlegende Modernisierung oder ein Replatforming notwendig wird. Während dieser Zeit fallen Ausgaben für Wartung, Weiterentwicklung und den technischen Betrieb an, die in der ursprünglichen Projektkalkulation oft nur teilweise berücksichtigt sind.

Eine vollständige TCO-Betrachtung sollte deshalb nicht mit dem Go-live enden. Sie umfasst auch die Kostenkategorien, die den Shop über mehrere Jahre begleiten, sowie die Fragen, mit denen sich mögliche Kostentreiber bereits vor Projektbeginn besser einschätzen lassen.
 

Der Projektpreis umfasst vor allem die Ausgaben, die bis zum Go-live anfallen. Ein großer Teil der Gesamtkosten entwickelt sich jedoch erst im anschließenden Betrieb und begleitet den Shop über mehrere Jahre.

Für die Kalkulation ist es deshalb sinnvoll, einmalige und wiederkehrende Ausgaben getrennt zu betrachten. Die Aufwände für Implementierung und Migration lassen sich zu Projektbeginn meist noch recht verlässlich planen. Auch Design und Testing sind in der Regel klar im Angebot ausgewiesen. Schwieriger ist es bei den Positionen, die erst nach dem Go-live relevant werden. Dazu zählen unter anderem Lizenzen, Hosting und Wartung. Auch die kontinuierliche Weiterentwicklung wird in der ursprünglichen Kalkulation häufig nur teilweise berücksichtigt.

Aus unserer Projekterfahrung entfallen auf Implementierung und Lizenzen über einen Zeitraum von fünf Jahren häufig nur etwa 15 bis 25 Prozent der Gesamtkosten. Wie hoch der Anteil im Einzelfall ausfällt, hängt stark vom jeweiligen Setup und seiner Komplexität ab. Welche Größenordnung die späteren Ausgaben erreichen können, zeigt das folgende Beispiel.

Ein mittelständischer Fashion-Shop mit rund 20 Millionen Euro Jahresumsatz startet auf Magento-Basis. Im ursprünglichen Projektbudget sind Implementierung, Lizenzen und Hosting berücksichtigt. Zusammengenommen belaufen sich diese Positionen über fünf Jahre auf rund 480.000 Euro.

Nicht vollständig eingeplant sind dagegen die Aufwände, die erst im laufenden Betrieb anfallen. Dazu zählen die Wartung und die kontinuierliche Weiterentwicklung des Shops. Auch regelmäßige Performance-Optimierungen verursachen zusätzliche Ausgaben. Kommt es während einer umsatzstarken Phase zu einem längeren Ausfall oder wird später ein Replatforming notwendig, erhöht sich die Gesamtsumme noch einmal deutlich.

Das ursprüngliche Projektbudget bildet in diesem Beispiel damit nur rund ein Viertel der tatsächlichen Gesamtkosten ab. Die Zahlen dienen zur Veranschaulichung, zeigen aber ein typisches Muster: Mit zunehmender technischer Komplexität steigen über die Jahre auch die Aufwände für Betrieb, Weiterentwicklung und mögliche spätere Anpassungen.
 

Eine vollständige TCO-Betrachtung geht deutlich über die Positionen hinaus, die im ursprünglichen Projektangebot aufgeführt sind. Implementierung und Lizenzen werden dort meist vollständig erfasst, beim Hosting ist das häufig nur teilweise der Fall. Wartung und Weiterentwicklung sind dagegen oft zu knapp angesetzt. Andere Aufwände, die erst im Betrieb relevant werden, fehlen im Angebot meist vollständig.

Die angegebenen Spannen dienen als Orientierung und basieren auf unterschiedlichen Shop-Setups. Sie bilden keine feste Kostenverteilung und lassen sich deshalb nicht einfach zu 100 Prozent addieren.

Besonders stark wirkt sich die laufende Weiterentwicklung aus. Neue Funktionen, zusätzliche Schnittstellen oder die Expansion in weitere Märkte kosten über mehrere Jahre oft mehr als die ursprüngliche Implementierung. Im Projektangebot wird dieser Aufwand trotzdem häufig nur teilweise berücksichtigt.

Auch technische Schulden können später teuer werden. Im laufenden Betrieb bleiben sie oft lange unbemerkt. Sichtbar werden sie meist erst bei größeren Updates, wenn alte Abhängigkeiten oder individuelle Anpassungen zusätzlichen Entwicklungsaufwand verursachen.

Ähnlich ist es beim Replatforming. Wenn sich ein Shop nur noch mit großem Aufwand warten oder erweitern lässt, kann ein Neuaufbau sinnvoller sein als weitere Einzelanpassungen. Wie teuer dieser Schritt wird, hängt stark vom Zustand der bestehenden Architektur ab.

Viele dieser Kosten sind im ursprünglichen Angebot nicht sichtbar. Über mehrere Jahre können sie jedoch einen großen Teil der Gesamtkosten ausmachen. Dazu gehören auch Verluste, die durch langsame Prozesse oder verzögerte Weiterentwicklungen entstehen.

Ein weiterer Risikofaktor sind Ausfallzeiten. Laut einer Studie von Splunk und Oxford Economics verlieren große Unternehmen durch Downtime rund 9 Prozent ihres Jahresgewinns, wenn auch die indirekten Folgen berücksichtigt werden (Quelle: Splunk/Oxford Economics, 2024).
 

Obwohl die klassische Projektkalkulation viele spätere Kosten nicht erfasst, wird sie in der Praxis weiterhin häufig genutzt. Ein Grund dafür ist, dass die nötigen Informationen an verschiedenen Stellen liegen. Die Projektkosten stehen direkt im Angebot. Die laufenden Ausgaben müssen dagegen meist aus mehreren Budgets und Verantwortungsbereichen zusammengetragen werden. Verglichen wird deshalb oft nur das, was sofort verfügbar ist.

Hinzu kommt, dass Entscheidungen selten über einen Zeitraum von fünf oder mehr Jahren betrachtet werden. Wer heute eine Plattform oder einen Anbieter auswählt, ist einige Jahre später möglicherweise nicht mehr für den laufenden Betrieb verantwortlich. Die späteren Folgen spielen bei der ursprünglichen Kalkulation deshalb oft nur eine geringe Rolle.

Auch getrennte Budgets erschweren den vollständigen Blick. Die Projektkosten werden häufig an anderer Stelle geplant als die Ausgaben für Betrieb und Weiterentwicklung. Bei der eigentlichen Entscheidung sitzen deshalb nicht immer alle Personen mit am Tisch, die die späteren Kosten realistisch einschätzen könnten.

Das ist kein Fehler einzelner Beteiligter, sondern eine Folge der üblichen Planungsprozesse. Häufig endet die wirtschaftliche Betrachtung mit dem Go-live, obwohl ein großer Teil der Ausgaben erst danach anfällt. Eine TCO-Analyse bezieht deshalb auch den Betrieb, die Weiterentwicklung und mögliche Risiken der folgenden fünf bis sieben Jahre ein.
 

Viele Entscheidungen, die später die Total Cost of Ownership beeinflussen, fallen bereits zu Beginn eines Projekts an. Dazu gehören das Frontend, das Hosting-Modell und die Anbindung externer Systeme. Sie bestimmen über Jahre hinweg, wie gut sich ein Shop warten, erweitern und stabil betreiben lässt.

Ein leistungsfähiges Frontend allein reicht dabei nicht aus. Damit es seine Vorteile im Betrieb ausspielen kann, müssen Hosting und technische Prozesse darauf abgestimmt sein. Gleichzeitig lässt sich eine ungeeignete Frontend-Architektur nicht dauerhaft durch zusätzliche Infrastruktur ausgleichen.

Die TCO sollte deshalb schon berücksichtigt werden, bevor eine Plattform oder ein Anbieter ausgewählt wird. Welche Faktoren die laufenden Kosten später besonders stark erhöhen können, zeigen wir im Artikel „TCO-Treiber im E-Commerce: Was einen Shop langfristig teuer macht“. Dort geht es um wachsende Komplexität, nachlassende Performance und die Folgen von Störungen.
 

Mit vier Fragen lassen sich mögliche Lücken im Angebotsvergleich schnell erkennen:

• Wie hoch sind die jährlichen Betriebskosten, wenn Wartung und Weiterentwicklung realistisch mitgerechnet werden?
• Welche Leistungen sind im Projektangebot nicht enthalten, zum Beispiel Monitoring, Incident-Handling oder regelmäßige Performance-Optimierungen?
• Wie verändern sich die Kosten, wenn Traffic, Bestellvolumen oder Systemanforderungen deutlich wachsen?
• Welche Reaktionszeiten gelten bei Störungen und wer übernimmt im Ernstfall welche Verantwortung?

Nicht jede dieser Fragen muss sofort bis ins Detail beantwortet werden. Entscheidend ist zunächst, zu erkennen, an welchen Stellen Annahmen fehlen oder Verantwortlichkeiten noch nicht klar geregelt sind. Genau dort können im laufenden Betrieb zusätzliche Kosten entstehen.
 

Der Projektpreis zeigt nur einen Teil der tatsächlichen Kosten. Ein großer Teil fällt erst nach dem Go-live an, wenn Wartung, Weiterentwicklung und der laufende Betrieb über mehrere Jahre berücksichtigt werden.
Eine TCO-Betrachtung schafft hier mehr Transparenz. Sie hilft dabei, Angebote realistischer zu vergleichen und früh zu erkennen, welche Entscheidungen später zusätzliche Kosten verursachen können.
 

Was gehört zur TCO eines Onlineshops?

Zur Total Cost of Ownership gehören alle Kosten, die über den gesamten Lebenszyklus eines Onlineshops anfallen. Dazu zählen unter anderem Implementierung und Lizenzen, Hosting, Wartung und Updates, Weiterentwicklung, Betriebskomplexität, Performance-Folgekosten, Incident- und Ausfallkosten, technische Schulden sowie ein späteres Replatforming.

Welcher Zeitraum ist für eine TCO-Betrachtung sinnvoll?

In der Regel fünf bis sieben Jahre. Über diesen Zeitraum wird ein Magento-Shop häufig betrieben, bevor eine grundlegende Modernisierung oder ein Replatforming notwendig wird. Erst dann zeigt sich, wie sich die laufenden Kosten tatsächlich entwickeln.

Warum reicht der Projektpreis nicht aus?

Der Projektpreis bildet vor allem die einmaligen Kosten bis zum Go-live ab. Aus unserer Projekterfahrung machen Implementierung und Lizenzen über fünf Jahre häufig nur 15 bis 25 Prozent der Gesamtkosten aus.

Welche Kosten werden besonders oft übersehen?

Vor allem Weiterentwicklung, Betriebskomplexität, Performance-Folgekosten, Incident- und Ausfallkosten, technische Schulden sowie ein späteres Replatforming. Diese Positionen sind in Projektangeboten häufig gar nicht oder nur teilweise berücksichtigt.

Wann sollte die TCO berechnet werden?

Möglichst vor der Plattform- und Anbieterentscheidung. Viele Faktoren, die die späteren Betriebskosten beeinflussen, werden bereits zu Beginn eines Projekts festgelegt.