Das Cloud-Audit ergab keine Beanstandungen. Tagging-Abdeckung bei 78 %, drei inaktive Instanzen zur Größenanpassung markiert, eine ungenutzte Reservierungsverpflichtung, die einer Überprüfung bedarf. Die Ingenieure haben die meisten Punkte umgesetzt. Sechs Monate später war die Cloud-Rechnung 11 % höher als vor dem Projekt.
Dieses Ergebnis ist nicht ungewöhnlich. Das Audit hat das getan, wozu es entwickelt wurde: Es hat die Infrastruktur zu einem bestimmten Zeitpunkt erfasst, sie an bekannten Benchmarks gemessen und Verbesserungen innerhalb des bestehenden Rahmens vorgeschlagen.
Die Analysten lagen nicht falsch, aber der Rahmen war es.
Wichtige Erkenntnisse
Ein Cloud-Audit bestätigt, dass Ausgaben bestehen und wo sie anfallen. Es kann nicht bestätigen, ob diese Ausgaben einen Ertrag generieren – denn die Kostenverteilung endet an der Grenze der Infrastruktur und erreicht nie die Ebene der Datenprodukte.
Die teuersten Probleme in einer Datenplattform sehen von außen betrachtet normal aus. Falsch konfigurierte Aufbewahrungsfristen, ineffiziente Pipeline-Algorithmen und qualitätsbedingte Wiederholungsläufe werden in einem Infrastrukturbericht alle als Standardaktivitäten erfasst.
Die Verfolgung der absoluten Cloud-Ausgaben in einer wachsenden Datenumgebung ist die falsche Kennzahl. Einheitskosten – pro Pipeline-Lauf, pro gespeichertem GB – decken Ineffizienzen auf, die Gesamtzahlen verbergen.
Eine viermal jährlich durchgeführte Cloud-Kosten-Governance in einer sich täglich verändernden Umgebung ist retrospektive Buchhaltung, keine Governance.
Was ein Cloud-Kosten-Audit tatsächlich aussagt (und wo seine Transparenz endet)
Was ein Cloud-Kosten-Audit tatsächlich aussagt (und wo seine Transparenz endet)
Ein Cloud-Audit erfasst die Infrastrukturausgaben: Rechenleistung, Speicher, Netzwerkübertragung, Dienste – aufgeschlüsselt nach Team, Projekt und Commitment-Stufe.
Es ermittelt, ob Ressourcen angemessen bereitgestellt sind, ob reservierte Kapazität tatsächlich genutzt wird und ob etwas ohne erkennbaren Eigentümer läuft. Dies sind echte Probleme, die es anzugehen gilt, und ein gut durchgeführtes Audit deckt sie zuverlässig auf.
Die Grenze ist die Infrastrukturebene. Ein Audit beantwortet die Fragen „Was kostet das und wem gehört es?“ – jedoch auf der Ebene eines Entwicklerteams oder eines Projektbudgets, nicht auf der Ebene eines bestimmten Datenprodukts oder einer Geschäftsfunktion.
Dieser Unterschied hat mehr Gewicht, als ihm in den meisten Gesprächen über Cloud-Finanzen beigemessen wird.
Stellen Sie sich einen Datensatz vor, dessen Wartung, Verarbeitung und Bereitstellung 5.000 £ pro Monat kostet. Aus Sicht der Infrastruktur ist er aktiv – er wird abgefragt, generiert Berichte und besteht jeden Zustandscheck. Das Projekt, zu dem er gehört, liegt im Budget. Die Abteilung, der er gehört, weist angemessene Cloud-Ausgaben auf. Jedes FinOps-Dashboard zeigt „grün“ an.
Die Kostenlücke bei Datenprodukten – warum die Abrechnung der Infrastruktur nicht ausreicht
Die Kostenlücke bei Datenprodukten – warum die Abrechnung der Infrastruktur nicht ausreicht
Dies ist der Kern dessen, was das Black-Hole-Syndrom beschreibt: Kosten fließen hinein, aber Erklärungen kommen nicht heraus. Die Abrechnungsdaten sind korrekt und die Kostenberichte detailliert.
Und doch können Finanzteams häufig einen erheblichen Teil der Cloud-Ausgaben nicht in einer Weise erklären, die für Geschäftsinteressenten aussagekräftig wäre – weil die Kostenverteilung an der Infrastrukturgrenze endet und niemals die Datenebene erreicht.
Die meisten Unternehmen können Ihnen sagen, wie viel sie im letzten Monat für BigQuery oder Databricks ausgegeben haben. Weniger können jedoch identifizieren, welche Datenprodukte diese Rechnung verursachen, welche Produkte ihre Kosten durch geschäftlichen Mehrwert decken und welche Kandidaten für eine Rationalisierung sind.
Studien bringen es auf den Punkt: Nur 43 % der Großunternehmen können die Kosten pro Datenprodukt berechnen. Diese Zahl gilt, noch bevor gefragt wird, ob diese Berechnungen mit einer Messgröße für den geschäftlichen Nutzen verknüpft sind oder ob sie tatsächlich in Entscheidungen einfließen.
Cloud-Governance, die an der Infrastrukturebene endet, liefert Zahlen, die auf den ersten Blick korrekt wirken, aber eher Inputs als Ergebnisse beschreiben. Ein Finanzteam, das diese Daten überprüft, ist nicht in der Lage, architektonische Entscheidungen zu treffen.
Ein Engineering-Team, das die Infrastrukturnutzung überprüft, fragt nicht, ob das von ihm gewartete Produkt überhaupt existieren sollte. Die Frage liegt zwischen diesen beiden Bereichen, weshalb sie oft unbeantwortet bleibt.
Ob Sie einen schnellen Einblick in Kostentreiber oder eine vollständige Optimierungsroadmap benötigen – FinDataOps folgt dem Triple-A-Modell und passt sich Ihren geschäftlichen Prioritäten an.
Sehen Sie in nur 3 Minuten, ob Ihr Unternehmen dem Profil entspricht, bei dem FinDataOps Daten- und KI-Kosten senken kann, und um wie viel.
Bewerten Sie Ihre FinDataOps-Bereitschaft
Ein 36.000-Pfund-Problem, das nie in einem Kostenbericht auftauchte
Ein 36.000-Pfund-Problem, das nie in einem Kostenbericht auftauchte
Ein Kunde hatte ein Data Lakehouse mit konfigurierten Zeitreise- und Aufbewahrungsrichtlinien. Auf dem Papier war die Konfiguration korrekt: Aufbewahrungsfenster waren definiert, historische Datenversionen waren für den Ablauf nach einer festgelegten Frist markiert.
In der Praxis erforderte das physische Entfernen abgelaufener Daten die Ausführung eines VACUUM-Prozesses. Niemand hatte dies automatisiert, weil es niemand bemerkt hatte.
Aus Sicht der Infrastruktur sah das Bild völlig normal aus: ein zeitlicher Datensatz, der stetig wuchs. Ein inkrementelles Wachstum in einer Datenplattform ist ein erwartetes Verhalten. Nichts in den Abrechnungsberichten deutete auf eine Anomalie hin.
Das Problem trat während einer routinemäßigen Backup-Übertragung zutage. Ein Job, der vor dem Kopieren die Datenmengen erfasst, meldete eine Zahl, die etwa 30-mal größer war, als es die logischen Tabellengrößen vermuten ließen.
Die Untersuchung deckte die Diskrepanz sofort auf: Die Tabellenmetadaten meldeten etwa 20 TB an aktiven Daten; der zugrunde liegende Speicher enthielt 100 TB an historischen Versionen, die bereits Monate zuvor hätten entfernt werden müssen.
Das Hinzufügen eines automatisierten Jobs zum Auslösen von VACUUM für die größten Datenprodukte löste das Problem in etwa zwei Tagen Entwicklungszeit. Die Einsparung belief sich auf rund 100 £ pro Tag – knapp 36.000 £ pro Jahr.
Ein standardmäßiges Cloud-Kosten-Audit hätte dies nicht aufgedeckt. Es hätte einen wachsenden Datensatz in aktiver Nutzung festgestellt und dies als normal angesehen. Um das Problem zu identifizieren, musste geprüft werden, ob der Aufbewahrungsmechanismus tatsächlich funktionierte und nicht nur konfiguriert war.
Drei Kostentreiber, die bei Infrastruktur-Audits regelmäßig übersehen werden
Drei Kostentreiber, die bei Infrastruktur-Audits regelmäßig übersehen werden
Das Aufbewahrungsproblem ist ein erkennbares Muster. Andere treten häufig genug auf, um direkt genannt zu werden.
Algorithmische Ineffizienz bei der Pipeline-Ausführung. Eine Pipeline, die mit quadratischer Komplexität verarbeitet, obwohl ein linearer Ansatz verfügbar ist, läuft pro Ausführung länger und verursacht daher bei Skalierung höhere Kosten. Die Infrastruktur protokolliert, dass die Pipeline lief und Rechenleistung verbraucht wurde. Sie bewertet jedoch nicht, ob diese Rechenleistung sinnvoll genutzt wurde.
Bei einer täglichen Arbeitslast summiert sich der Kostenunterschied zwischen einem effizienten und einem ineffizienten Algorithmus über Monate hinweg, ohne dass ein Alarm ausgelöst wird – da die Nutzung normal erscheint.
Fehler in der Datenqualität, die eine erneute Ausführung der Pipeline auslösen. Eine Pipeline, deren Ausführung 300 £ pro Durchlauf kostet, stößt vorgelagert auf ein Problem mit der Datenqualität – das bei der Erfassung übersehen wurde, da keine Validierungsprüfungen vorhanden sind.
Das Problem tritt eine Woche später zutage, als ein nachgelagerter Nutzer falsche Zahlen bemerkt. Die Behebung erfordert eine erneute Ausführung der Pipeline über den betroffenen Zeitraum: etwa 1.400 £ an direkten Kosten für die erneute Verarbeitung, noch bevor der Zeitaufwand für die Entwicklung berücksichtigt wird.
Der Abrechnungseintrag erscheint als normale Pipeline-Aktivität. Auf der Cloud-Rechnung gibt es keine Kategorie mit der Bezeichnung „vermeidbare Nacharbeit“.
Aktive Pipelines, die keine aktiven Verbraucher bedienen. Datenprodukte, die für einen Anwendungsfall erstellt wurden, der sich inzwischen geändert hat, laufen weiter, weil niemand sie explizit außer Betrieb genommen hat. Geplante Jobs werden ausgeführt, der Speicherplatz wächst, Rechenleistung wird abgerechnet.
Ohne einen Datenkatalog, der mit tatsächlichen Nutzungsmetriken verknüpft ist, verfügt die Plattform über keinen Mechanismus, um zu erkennen, dass der nachgelagerte Verbraucher seit sechs Monaten nicht mehr da ist.
Regelmäßige Audits können offensichtliche Fälle aufdecken; stillschweigend ungenutzte Ressourcen sind jedoch schwerer zu erkennen, wenn auf der Datenebene keine Observability vorhanden ist.
Lesen Sie mehr über die Optimierung von Cloud- und Datenkosten:
KPIs, die beweisen, dass das Betriebsmodell funktioniert – Quartal für Quartal
KPIs, die beweisen, dass das Betriebsmodell funktioniert – Quartal für Quartal
Der Instinkt sagt uns, den Erfolg daran zu messen, ob die gesamte Cloud-Rechnung sinkt. Für Unternehmen mit wachsenden Datenmengen liefert diese Kennzahl jedoch irreführende Ergebnisse: Die Rechnung wird im Laufe der Zeit steigen, da die Datenmengen zunehmen.
Die Frage ist, ob die Kosten proportional zum generierten Wert steigen oder schneller als dieser.
Nützliche Kennzahlen werden auf Einheitenebene ermittelt:
- Kosten pro Pipeline-Durchlauf. Bei Workloads, die inkrementelle Daten verarbeiten, sollte dieser Wert weitgehend stabil bleiben. Eine Pipeline, die im dritten Quartal doppelt so viel pro Ausführung kostet wie im ersten Quartal – ohne entsprechende Änderung des Datenvolumens – ist ein Signal, das es zu untersuchen gilt, bevor sich das Problem verschlimmert.
- Kosten pro gespeichertem GB. Die absoluten Speicherausgaben werden mit den Daten wachsen. Die Stückkosten pro Gigabyte sollten dies nicht tun. Wenn dies doch der Fall ist, sind die wahrscheinlichen Ursachen Fehler bei der Aufbewahrung, Duplikate oder die Speicherung in einer Ebene, die nicht zum tatsächlichen Zugriffsmuster passt.
- Prognosegenauigkeit. Der Anteil der Cloud-Ausgaben, der einen Monat im Voraus mit angemessener Genauigkeit vorhergesagt und zugeordnet werden kann. Eine geringe Prognosegenauigkeit ist kein Abrechnungsproblem – sie deutet darauf hin, dass Kostenentscheidungen getroffen werden, ohne dass die nachgelagerten finanziellen Konsequenzen sichtbar sind.
Nur etwa ein Drittel der Unternehmen setzt Kostenzuweisung durch automatisierte Richtlinien durch, was eine genaue Prognose strukturell erschwert, unabhängig davon, wie ausgefeilt die FinOps-Tools sind.
Was ein kontinuierliches Betriebsmodell tatsächlich erfordert
Was ein kontinuierliches Betriebsmodell tatsächlich erfordert
Der strukturelle Wandel besteht darin, die Cloud-Kosten-Governance als operative Funktion und nicht als Eingriff zu behandeln. Zwei Dinge machen dies konkret.
Erstens muss die Kostenverantwortung auf der Ebene der Datenprodukte und nicht nur auf der Ebene der Infrastruktur zugewiesen werden.
Jedes Datenprodukt sollte einen Verantwortlichen haben, der dafür Rechenschaft ablegt, ob die dadurch verursachten Kosten in einem angemessenen Verhältnis zum erbrachten Wert stehen. Diese Verantwortlichkeit erfordert Tools, die Kosten in dieser Granularität sichtbar machen – und einen Prozess, um auf die Daten zu reagieren. Ohne dies bleibt das Kostenbewusstsein auf das Finanzteam beschränkt und ist weit entfernt von den Teams, die die Entscheidungen treffen, welche die Ausgaben bestimmen.
Zweitens muss Governance in die Funktionsweise der Plattform eingebettet sein und nicht nur periodisch anhand dieser überprüft werden.
Tagging wird bei der Bereitstellung erzwungen und nicht in einem vierteljährlichen Audit überprüft. Die Aufbewahrung erfolgt automatisiert und hängt nicht davon ab, dass jemand daran denkt, einen Job auszuführen. Anomalien bei den Stückkosten lösen Warnmeldungen aus und werden nicht erst drei Monate später bei einer Budgetüberprüfung entdeckt.
Zwei Engagement-Modelle bieten dies:
- In einer Partnerschaftsstruktur ist ein externes Team kontinuierlich eingebunden – aktiv während der anfänglichen Implementierungsphase, dann in reduzierter Frequenz während der Wartung. Es liefert die Perspektive auf der Datenebene und die Kontinuität der Kostenüberwachung, die interne Teams neben ihren Lieferverpflichtungen oft nicht aufrechterhalten können.
- In einem Kompetenztransfermodell liegt der Fokus auf dem Aufbau interner Kompetenzen, damit das Unternehmen das Betriebsmodell nach Abschluss des Engagements eigenständig weiterführt. Keines der Modelle ist grundsätzlich überlegen. Beide erfordern dasselbe grundlegende Engagement: Cloud-Kosten-Governance als fester Bestandteil des Plattformbetriebs, mit definierten Verantwortlichkeiten, kontinuierlicher Messung und einem Prozess zur Umsetzung der aus den Daten gewonnenen Erkenntnisse.
Verwandeln Sie Cloud-, Daten- und KI-Ausgaben in vorhersehbare Geschäftsergebnisse.
Wir helfen Unternehmen dabei, wieder Transparenz über ihre Cloud- und Datenausgaben zu erlangen, die Prognosegenauigkeit zu verbessern und Governance direkt in die Liefer-Workflows zu integrieren.
Die ersten entscheidungsreifen Erkenntnisse werden in der Regel innerhalb von 10 Arbeitstagen geliefert.
Warum der Audit-Kalender die falsche Governance-Struktur ist
Warum der Audit-Kalender die falsche Governance-Struktur ist
Die Cloud hat Unternehmen, die mit unerklärlichen Rechnungen zu kämpfen haben, nicht im Stich gelassen. Die Erwartung, dass regelmäßige Überprüfungen eine kontinuierlich laufende Betriebsumgebung verwalten können, hat versagt.
Cloud-Ausgaben sind das Ergebnis technischer Entscheidungen, die täglich von Teams getroffen werden, die oft keinen Einblick in die finanziellen Folgen dieser Entscheidungen haben.
Eine von Boomi in Auftrag gegebene Forrester-Studie aus dem Jahr 2024 bestätigte, dass 72 % der Unternehmen ihre Cloud-Budgets überschritten haben – nicht weil die Technologie von Natur aus unvorhersehbar ist, sondern weil die darauf angewandten Governance-Strukturen zu selten sind, um die Entscheidungen abzufangen, die zu Mehrausgaben führen.
Das Risiko, das ein CFO trägt, ist nicht eine steigende Zahl. Steigende Kosten in einem wachsenden Unternehmen lassen sich rechtfertigen. Das Risiko besteht darin, sie nicht erklären zu können – nicht in der Lage zu sein, eine Cloud-Rechnung mit den umsatzgenerierenden Produkten, den Datenprodukten, die diese Teams versorgen, und den architektonischen Entscheidungen, die die Kostenstruktur bestimmt haben, in Verbindung zu bringen.
Wenn diese Verbindung nicht besteht, wird jedes Budgetgespräch zu einer Verhandlung, die auf Annahmen statt auf Fakten basiert.
Governance, die viermal im Jahr auf eine sich täglich verändernde Umgebung angewendet wird, ist keine Governance, sondern lediglich eine nachträgliche Abrechnung, die zu spät erfolgt, um noch etwas zu ändern.
