Gerade läuft in vielen IT-Abteilungen derselbe Moment ab. Der Server ist sichtbar alt, der Support des Herstellers läuft aus, der Geschäftsführer fragt nach „Neu kaufen oder in die Cloud gehen“, und auf dem Tisch liegen zwei Angebote, die auf den ersten Blick kaum vergleichbar sind. Genau an dieser Stelle reicht der Preis auf dem Papier nicht mehr aus, weil er nur einen Teil der Wahrheit zeigt.
TCO Berechnung ist deshalb kein Controlling-Schmuck, sondern das einzige saubere Werkzeug, wenn eine IT-Entscheidung über Jahre wirken soll. In Deutschland ist diese Logik im IT- und Fuhrpark-Kontext fest etabliert, weil sie den gesamten Lebenszyklus betrachtet, also Betrieb, Wartung, Verwaltung, Nutzung und Außerbetriebnahme zusammenzieht, statt nur den Anschaffungspreis zu betrachten. Für IT-Projekte wird dafür häufig ein Zeitraum von mindestens drei, besser fünf Jahren angesetzt, damit Durchschnittswerte belastbar werden und sich Alternativen fair vergleichen lassen. PandaNerds Leitfaden zur CBA passt gut als ergänzende Lektüre, weil dort die saubere Kosten-Nutzen-Abgrenzung ebenfalls im Mittelpunkt steht.
Wer nur den Kaufpreis vergleicht, vergleicht in Wahrheit nur den Einstieg, nicht die Gesamtwirkung einer Entscheidung.
Warum der Anschaffungspreis bei IT-Investitionen nicht reicht
Ein typisches Szenario aus dem Mittelstand sieht so aus, dass ein lokaler Server nach Jahren stabiler Arbeit an sein Supportende kommt. Der Vertrieb will keine Unterbrechung, die Geschäftsführung will eine klare Zahl, und die IT soll bitte schnell sagen, ob ein neuer Server günstiger ist als ein Cloud-Umzug. Genau dann kippt die Diskussion oft in Listenpreise, obwohl die eigentlichen Kostentreiber ganz woanders liegen.
Bei der TCO Berechnung geht es darum, den sichtbaren Preis mit den verborgenen Folgekosten zu verknüpfen. In der Praxis sind das nicht nur Hardware oder Abo-Entgelte, sondern auch Wartung, Lizenzverlängerungen, Support, interne Administration, Schulung, Ausfallzeiten und der Aufwand für spätere Anpassungen. In deutschsprachigen Quellen wird die Logik deshalb ausdrücklich als Vergleich über den Nutzungszeitraum beschrieben, nicht als Momentaufnahme eines Angebots. Das gilt für Hardware, Software und Services ebenso wie für Serverlandschaften und Flottenentscheidungen. Total Cost of Ownership im IT- und Fuhrpark-Kontext
Was im Alltag gern vergessen wird, sind die kleinen Posten, die sich in Summe schwerer auswirken als erwartet. Strom und Kühlung laufen weiter, Lizenzen müssen erneuert werden, und jede Stunde, die jemand aus dem Team für Patchen, Dokumentieren oder Einrichten aufwendet, ist ebenfalls Teil der Wirtschaftlichkeit. Die klassische Kaufpreisbetrachtung blendet genau diese Punkte aus. Deshalb ist TCO nicht nur ein Rechenmodell, sondern eine Korrektur auf die tatsächliche Belastung des Unternehmens.
Praktische Regel: Wenn zwei Angebote nur beim Startpreis verglichen werden, fehlt fast immer der teuerste Teil der Rechnung.
Die sinnvolle Frage lautet also nicht „Was kostet das morgen?“, sondern „Was kostet es uns über den Nutzungszeitraum?“. Erst mit dieser Sicht wird aus einem Server-Refresh oder einem Cloud-Projekt eine echte Investitionsentscheidung. Und genau deshalb lohnt sich die Mehrjahresbetrachtung, die in der IT mindestens über drei bis fünf Jahre gedacht werden sollte. TCO über mehrere Jahre normieren
Kostenarten sauber strukturieren
Bevor auch nur eine Zahl in die Tabelle wandert, braucht die TCO Berechnung ein sauberes Raster. Sonst vermischen sich Beschaffung, Betrieb und Nebenaufwand, und am Ende ist nicht mehr nachvollziehbar, warum eine Variante teurer wirkt als die andere. Ich arbeite dafür konsequent mit drei Blöcken, Einmalkosten, laufenden Betriebskosten und indirekten Kosten.
Die drei Kostenblöcke
Einmalkosten sind alles, was nur am Anfang oder bei einem klaren Wechsel anfällt. Dazu gehören Beschaffung, Installation, Migration, Erstkonfiguration und Schulung. Bei Cloud-Projekten fallen hier oft auch Einführungsaufwände, Schnittstellenanpassungen und die Vorbereitung des Betriebsmodells an.
Laufende Betriebskosten entstehen während der Nutzung. In der IT sind das etwa Strom, Kühlung, Lizenzen, Wartungsverträge, Support, Cloud-Compute, Storage und Personalaufwand für Verwaltung und Betrieb. Hier liegt oft der größte Unterschied zwischen On-Prem und Cloud, weil die Rechnungsarten völlig anders aussehen.
Indirekte Kosten sind die Positionen, die viele Modelle unterschätzen oder ganz auslassen. Dazu zählen Ausfallzeiten, Produktivitätsverlust, interne Verwaltung, Dokumentation, Audit-Aufwand und Compliance-Kosten. Gerade im deutschen Mittelstand ist der Compliance-Block mit NIS-2 deutlich wichtiger geworden, weil Risikoanalyse, Nachweispflichten und laufende Dokumentation echte Ressourcen binden.
| Kostenraster für die TCO-Berechnung | Typische Posten | Erfassungsform |
|---|---|---|
| Einmalkosten | Beschaffung, Installation, Migration, Schulung, Erstkonfiguration | einmalig je Projekt oder Rollout |
| Laufende Betriebskosten | Strom, Kühlung, Lizenzen, Wartung, Support, Cloud-Nutzung, Personal | monatlich, jährlich oder pro Nutzungszyklus |
| Indirekte Kosten | Ausfallzeiten, interne Verwaltung, Dokumentation, Audit, Compliance | über Stunden, Vorfälle oder pauschale Prozessanteile |
Ein praxisnaher Blick auf Facility- und Gebäudebetrieb zeigt die gleiche Logik, nur in einem anderen Gewand. Wer Prozesse sauber trennt, sieht Kostenstellen klarer, und genau dabei hilft auch ein strukturierter Rollenblick wie im Bereich Facility Management bei Schumm & Rösch, weil dort Verwaltungs-, Betriebs- und Kontrollaufgaben getrennt gedacht werden. Das ist für IT-Projekte nützlich, wenn Betrieb und Governance nicht in einem Sammelposten verschwinden sollen.
Ein guter TCO-Ansatz macht nicht alles komplizierter, sondern trennt sauber, was im Alltag ohnehin getrennt anfällt.
Formel, Zeitfenster und Diskontierung
Die Grundlogik ist schlicht, aber nur dann belastbar, wenn der Zeitraum sauber festgelegt ist. TCO = Summe aller Kosten über den Lebenszyklus. In der Praxis heißt das, dass Einmalkosten und Folgekosten in einer gemeinsamen Zeitleiste landen und erst danach auf einen durchschnittlichen Jahreswert normiert werden.
Für IT- und Cloud-Vorhaben in Deutschland ist ein Nutzungszeitraum von mindestens drei bis fünf Jahren der übliche Rahmen, weil erst dann echte Durchschnittswerte entstehen. Genau dieser Zeitraum macht die Berechnung fair, denn ein Angebot mit niedrigen Einstiegskosten kann über mehrere Jahre teurer sein als eine Variante mit höherem Anfangsbetrag. Die Normierung auf einen Jahreswert ist deshalb erst am Ende sinnvoll, nicht am Anfang.
So funktioniert die Reihenfolge
- Zielzustand definieren. Was soll die Lösung leisten, und welche Nutzungsphasen gibt es?
- Kostenarten sammeln. Alle Einmal- und Folgekosten erfassen, realistisch und mit tatsächlichen Preisen.
- Zeitleiste aufbauen. Jede Position bekommt mindestens einen vollständigen Zyklus.
- TCO je Alternative berechnen. On-Prem, Cloud oder Hybrid getrennt rechnen.
- Sensitivität prüfen. Die stärksten Annahmen gegenchecken.
Die Diskontierung kommt ins Spiel, wenn Zahlungen zeitlich weit auseinanderliegen. Dann ist ein Euro in Jahr eins wirtschaftlich nicht dasselbe wie ein Euro in Jahr fünf. Bei kurzen Zeiträumen und niedrigen Zinsen fällt der Unterschied oft klein aus, bei längeren Laufzeiten und größeren Zahlungsblöcken kann er jedoch die Rangfolge verschieben. Deshalb sollte jede professionelle TCO-Tabelle den Barwert zumindest dokumentieren, auch wenn der Fokus im Mittelstand oft auf der praktischen Vergleichbarkeit liegt.
Faustregel: Erst den Nutzungszeitraum festlegen, dann die Kosten verteilen, erst ganz am Ende auf Jahreswerte oder Barwerte normieren.
Beispielrechnung On-Prem versus Cloud über fünf Jahre
Für die Entscheidung zwischen lokalem Server und Cloud hilft nur ein direkter Vergleich mit denselben Rahmenbedingungen. Das Beispiel unten ist bewusst pragmatisch gehalten, damit man das Raster in ein eigenes Spreadsheet übernehmen kann. Es zeigt nicht „die eine Wahrheit“, sondern eine realistische Rechenlogik für ein kleines bis mittleres Unternehmen.
Annahmen für die Rechnung: ein lokales IT-Setup mit Server, Storage, Wartung, Strom, etwas internem Betriebsaufwand und einer Cloud-Variante mit laufender Nutzung und etwas mehr laufender Koordination. Wer die Nutzungsintensität höher oder niedriger ansetzt, verschiebt natürlich das Ergebnis. Genau deshalb gehört die Annahme dokumentiert, nicht versteckt.
| Beispielrechnung On-Prem versus Cloud über 5 Jahre | On-Prem (5 J.) | Cloud (5 J.) |
|---|---|---|
| Anschaffung, Hardware und Erstaufbau | 12.000 € | 3.000 € |
| Migration, Einrichtung, Erstkonfiguration | 3.000 € | 4.000 € |
| Lizenzen und Plattformnutzung | 5.000 € | 15.000 € |
| Wartung und Support | 6.000 € | 4.000 € |
| Strom und Kühlung | 4.000 € | 0 € |
| Interner IT-Aufwand für Betrieb | 7.000 € | 8.000 € |
| Administration, Dokumentation, Anpassungen | 3.000 € | 5.000 € |
| Gesamtkosten über 5 Jahre | 40.000 € | 39.000 € |
| Durchschnitt pro Jahr | 8.000 € | 7.800 € |
Die Tabelle zeigt die typische Verschiebung. On-Prem startet mit höherem Kapitalbedarf, die Cloud verteilt mehr Kosten in die laufende Nutzung. In diesem Beispiel liegt die Cloud nach fünf Jahren leicht vorn, aber nur knapp. Der Hebel sitzt nicht bei der ersten Rechnung, sondern bei Lizenzen, internem Personal und laufendem Betriebsaufwand.
Wer das Thema tiefer in Richtung Vor- und Nachteile lokaler Systeme einordnen will, findet einen passenden Perspektivwechsel in diesem Beitrag zur On-Premise-Lösung. Für die eigene Entscheidung bleibt trotzdem wichtig, dass die Rechnung nur dann trägt, wenn die internen Stunden wirklich mitgerechnet werden. Genau daran scheitern viele vermeintlich günstige Vergleiche.
Sensitivitätsanalyse und typische Kostentreiber
Eine einzelne TCO-Zahl sieht ordentlich aus, ist aber ohne Stresstest kaum belastbar. In der Praxis frage ich immer zuerst, welche Annahmen das Ergebnis am stärksten verschieben würden. Das sind selten die kosmetischen Posten, sondern die großen Treiber hinter Betrieb und Support.
Die wichtigsten Hebel im Alltag
Energie und Kühlung spielen bei On-Prem eine direkte Rolle, weil sie an das eigene Rechenzentrum oder den Serverraum gebunden sind. Cloud-Auslastung wirkt anders, weil ungenutzte Kapazitäten oder falsch geplante Dienste sofort in der Rechnung auftauchen. Supportaufwand und interne Personalstunden sind oft noch größer, weil sie in vielen Angeboten nicht sauber sichtbar gemacht werden.
Für einen einfachen What-if-Test reicht es, die wichtigsten Annahmen gedanklich oder im Spreadsheet um ungefähr ein Drittel nach oben und unten zu verschieben und das Gesamtergebnis neu zu bewerten. Genau dieser pragmatische Blick schützt vor Scheinsicherheit. Wenn schon ein moderater Wechsel bei Auslastung oder Support die Rangfolge dreht, ist die Entscheidung nicht stabil genug.
Die typischen Unterschätzungen in deutschen KMU sehe ich immer wieder an denselben Stellen. Interne IT-Zeit wird zu knapp angesetzt, Ausfallzeiten werden weich formuliert, und Compliance-Aufwand landet in keinem eigenen Feld. Gerade bei NIS-2 sind Risikoanalyse, Sicherheitsmaßnahmen, Dokumentation und laufende Pflege keine Randthemen mehr, sondern echte Kostenblöcke.
Merksatz: Wenn eine TCO-Rechnung nur mit Idealwerten funktioniert, taugt sie nicht für eine Geschäftsführungsentscheidung.
Eine saubere Sensitivitätsanalyse muss kein Statistikprojekt sein. Sie soll zeigen, ob die Entscheidung stabil bleibt, wenn sich die Wirklichkeit etwas anders entwickelt als geplant. Dafür reicht oft schon eine klare Matrix mit den wichtigsten Treibern, den Annahmen und dem Effekt auf die Gesamtkosten.
Wer Cloud-Kosten zusätzlich eingrenzen will, sollte die laufenden Betriebsannahmen kritisch prüfen und mit sauberer Nutzungsmessung arbeiten. Ein nützlicher Praxisbezug dazu findet sich im Beitrag zu Cloud Cost Optimisation, weil dort die operative Sicht auf Verbrauch und Steuerung im Vordergrund steht.
Spreadsheet-Vorlage und Datenquellen
Eine brauchbare TCO Berechnung braucht keine schwere Software, sondern eine saubere Tabellenstruktur. In der Praxis hat sich eine Vorlage mit fünf Tabs bewährt, weil sie vom Input bis zur Auswertung durchgängig bleibt. Wer das konsequent aufsetzt, kann Angebote deutlich schneller vergleichen.
Aufbau der Vorlage
Eingabemaske. Hier stehen Projektname, Nutzungszeitraum, Alternativen, Diskontierungsannahme und Verantwortliche. Das ist die Stelle, an der die Rahmenbedingungen dokumentiert werden, nicht erst in der Auswertung.
Kostenraster. In diesem Tab landen die Kostenblöcke aus der Struktur oben, mit Spalten für Position, Betrag, Intervall und Variante. Wichtig ist, dass CapEx und OpEx nicht vermischt werden.
Zeitleiste. Dieser Tab verteilt die Kosten über die Nutzungsjahre. Genau hier zeigen sich oft Fehler, wenn einmalige Migrationskosten irrtümlich als laufende Positionen auftauchen.
Sensitivität. Hier werden die empfindlichsten Annahmen variiert, etwa Supportstunden, Energie oder Auslastung. Das macht die Entscheidung belastbarer.
Auswertung. Dieser Tab verdichtet alles auf Gesamtkosten, Jahreswert und Vergleich der Alternativen.
Als Datenquellen taugen im Alltag vor allem Dinge, die ohnehin vorhanden sind. ERP- und Buchhaltungsdaten liefern reale Anschaffungspreise, Stromrechnungen zeigen laufende Energiekosten, Lizenzverträge bilden die monatlichen oder jährlichen Gebühren ab. Ticketsysteme helfen bei Supportzeiten, und die Zeiterfassung der internen IT ist die beste Quelle für Betriebsaufwand, wenn man ihn ehrlich rechnen will.
Ein sauberer Tabellenaufbau nützt nur dann, wenn die Datenquelle zum Posten passt. Wer interne Stunden schätzt statt misst, baut sich schnell eine schöne, aber fragile Rechnung. Genau deshalb lohnt sich ein Blick auf Betriebsmodelle wie im Umfeld von mr. clean AG Gebäudereinigung und Hauswartung, weil dort nachvollziehbare Aufgaben- und Zeitstrukturen ebenfalls den Unterschied zwischen sauberer Planung und Bauchgefühl machen.
TCO-Berechnung im Unternehmen verankern
Die Methode wird erst dann wertvoll, wenn sie in jedem Investitionsantrag gleich genutzt wird. Dafür braucht es keine lange Richtlinie, sondern eine kurze Pflichtliste, die bei jedem IT-Projekt abgearbeitet wird. So wird die TCO Berechnung nicht zur Einmalübung, sondern zum Standard im Entscheidungsprozess.
Die Checkliste für den nächsten Vorschlag
- Lebenszyklus definieren. Der Zeitraum muss vor der Kalkulation feststehen.
- Alle Kostenpositionen erfassen. Einmal-, laufende und indirekte Kosten gehören in die Liste.
- Folgekosten realistisch schätzen. Interne Stunden, Support und Compliance nicht weichzeichnen.
- Sensitivitätsanalyse durchführen. Die größten Annahmen auf Stabilität prüfen.
- Ergebnis im Business Case dokumentieren. Die Annahmen müssen später nachvollziehbar bleiben.
Drei Fehler sehe ich in der Beratung besonders häufig. Erstens werden interne Personalkosten vergessen, obwohl sie bei Betrieb und Abstimmung viel ausmachen. Zweitens verschwindet Compliance-Aufwand im Sammelposten, obwohl NIS-2 und Audit-Pflichten echte Arbeit erzeugen. Drittens rechnen Teams mit Listenpreisen, obwohl im echten Einkauf Vertragskonditionen und individuelle Rahmenbedingungen zählen.
Die beste TCO-Tabelle ist nicht die mit den meisten Formeln, sondern die, die im Entscheidergespräch standhält.
Für Unternehmen mit Cloud-Vorhaben ist außerdem wichtig, die Migrationslogik separat zu betrachten, statt alles in einer Mischrechnung zu verstecken. Ein praxisnaher Anschluss dazu findet sich bei den Cloud Migration Strategies, weil dort der Übergang vom alten in das neue Betriebsmodell im Fokus steht. Genau an dieser Stelle entscheidet sich oft, ob die TCO sauber oder nur scheinbar sauber ist.
Wenn Sie Ihre nächste Server-, Cloud- oder Security-Entscheidung belastbar rechnen wollen, nehmen Sie die eigene TCO-Vorlage jetzt ernsthaft auseinander, prüfen Sie die internen Stunden und dokumentieren Sie die NIS-2- und Audit-Aufwände separat. Sprechen Sie mit Deeken.Technology GmbH über eine konkrete TCO-Bewertung für Ihre IT-Infrastruktur, damit aus einer Bauchgefühl-Entscheidung ein sauberer Business Case wird.
