TL;DR: Die meisten FinOps-Teams verfolgen zu viele Metriken und handeln bei zu wenigen. Die Metriken, auf die es wirklich ankommt, lassen sich in vier Kategorien einteilen: finanzielle (Budgetabweichung, Prognosegenauigkeit), operative (Auslastung, Commitment-Abdeckung, Right-Sizing-Potenzial), Waste-bezogene (ungenutzte Ressourcen, verwaister Storage, nicht zugeordnete Ausgaben) und geschäftliche (Unit Economics, Kosten im Verhältnis zum Umsatz). Welche Metriken Priorität haben, hängt vom Reifegrad ab. Ein Team in der Crawl-Phase braucht Sichtbarkeits-Metriken. Ein Team in der Run-Phase braucht Unit Economics. Und unabhängig vom Reifegrad gilt: Eine Metrik ohne dahinterliegende Handlungsebene ist nichts weiter als ein Dashboard.
An Cloud-Kostendaten mangelt es FinOps-Teams nicht. AWS Cost Explorer, Google Cloud Billing, Azure Cost Management, Drittanbieter-Plattformen – die Daten sind da. Schwieriger ist es, im Rauschen das Signal zu finden: jene konkreten Zahlen, die zeigen, wo sich Waste anhäuft, ob die Optimierungsarbeit greift und ob die Cloud-Ausgaben schneller oder langsamer wachsen als das Geschäft, das sie tragen.
Genau an dieser Lücke zwischen Daten und Signal scheitern die meisten Metrik-Frameworks. Teams bauen Dashboards mit 40 KPIs, halten monatliche Reviews ab, die in Kostenarchäologie ausarten, und tun sich schwer, Engineering-Leads zu erklären, auf welche Zahl es im aktuellen Sprint tatsächlich ankommt. Laut Gartner erfassen nur 43 % der Unternehmen Cloud-Kosten auf Unit-Ebene – die meisten Teams können ihre Cloud-Rechnung also gar nicht mit den Produkten und Kunden verknüpfen, die sie verursachen.
Dieser Artikel ist keine erschöpfende Liste aller Cloud-Kosten-Metriken. Er ist ein Framework, um zu entscheiden, welche Metriken in welcher FinOps-Reifephase Aufmerksamkeit verdienen, welche Handlungen sie auslösen sollten und wo die häufigsten Tracking-Fehler Teams in die falsche Richtung lenken.
Was sind Metriken zur Cloud-Kostenoptimierung und warum brauchen FinOps-Teams ein Framework?
Metriken zur Cloud-Kostenoptimierung sind quantitative Signale, die das Ausgabeverhalten in der Cloud mit Geschäftsergebnissen verknüpfen. Sie helfen FinOps-Teams, Waste zu finden, die Wirkung von Optimierungsmaßnahmen zu validieren und künftige Ausgaben so präzise zu prognostizieren, dass sich Planungsentscheidungen darauf stützen lassen.
Die Definition ist einfach. Die Anwendung nicht. Die Herausforderung liegt darin, die richtigen Metriken für die Frage auszuwählen, die Ihr Unternehmen gerade tatsächlich stellt.
Zu viele Metriken zu verfolgen führt zum gleichen Ergebnis wie gar keine zu verfolgen. Wenn jede Zahl gleich viel Gewicht bekommt, wird nichts priorisiert. Reviews werden rückblickend statt handlungsleitend. Engineers schalten ab, weil das Signal-Rausch-Verhältnis zu schlecht ist, um Aufmerksamkeit zu rechtfertigen.
Ein gestufter Ansatz löst das. Statt einer flachen Liste mit 30 KPIs ordnet ein gestuftes Framework die Metriken nach Kategorie und Reifegrad. Jede Stufe beantwortet eine andere Frage: Haben wir unsere Ausgaben klar im Blick? Nutzen wir Ressourcen effizient? Beseitigen wir Waste? Wachsen unsere Cloud-Ausgaben im Verhältnis zum Wert, den sie generieren?
Das Crawl/Walk/Run-Modell der FinOps Foundation passt hier nahtlos. Teams am Anfang brauchen Sichtbarkeits-Metriken, Teams in der Mitte Optimierungs-Metriken, reife Teams Effizienz- und Business-Value-Metriken. Stufen zu überspringen beschleunigt die Ergebnisse nicht – es schafft nur Reporting-Komplexität ohne die Datenqualität, die sie tragen könnte.
Welche Metrik-Kategorien treiben FinOps-Ergebnisse?
Vier Metrik-Kategorien decken das gesamte Spektrum der FinOps-Entscheidungsfindung ab: finanzielle Metriken, die Budget- und Prognosegesundheit erfassen, operative Metriken, die messen, wie effizient Ressourcen laufen, Waste-Metriken, die ungenutzte und verwaiste Ausgaben sichtbar machen, und geschäftliche Metriken, die Cloud-Kosten mit dem Wert verbinden, den das Unternehmen erzeugt. Jede Kategorie beantwortet eine andere Frage und sollte andere Handlungen auslösen.
Finanzielle Metriken: Budgetabweichung und Prognosegenauigkeit
Die Budgetabweichung misst die Lücke zwischen geplanten und tatsächlichen Cloud-Ausgaben – ausgedrückt in Prozent. Sie ist die häufigste finanzielle Metrik im Cloud-Kostenmanagement und zugleich diejenige, die am häufigsten fehlinterpretiert wird.
Eine negative Abweichung (weniger ausgegeben als geplant) sieht auf dem Dashboard gesund aus, kann aber Unterauslastung oder verzögerte Projekte kaschieren. Eine positive Abweichung (Mehrausgaben) lohnt eine genauere Prüfung nur, wenn Sie organisches Wachstum von echtem Waste trennen können. Teams, die jede positive Abweichung als Problem behandeln, budgetieren am Ende zu konservativ und schnüren den Engineering-Teams die Luft ab, die sie eigentlich unterstützen sollen.
Die Prognosegenauigkeit misst, wie eng Ihre vorhergesagten Ausgaben am Ende eines Abrechnungszeitraums mit den tatsächlichen übereinstimmen. Branchen-Benchmarks werten 10 bis 15 % Abweichung für die meisten Unternehmen als akzeptabel; Teams mit ausgereifter Commitment-Strategie und stabilen Workloads erreichen häufig 5 % oder besser. Die Metrik ist wichtig, weil ungenaue Prognosen Folgeprobleme erzeugen: Finance-Teams bauen Puffer in Tech-Budgets ein, Engineering-Teams bekommen mitten im Sprint überraschende Kostenwarnungen, und die Führungsebene verliert das Vertrauen in FinOps als Planungsfunktion.
Beide Metriken verbessern sich durch dieselbe Grundlagenarbeit: saubere Kostenzuordnung, durchgesetzte Tagging-Praxis und Sichtbarkeit auf Account-Ebene, die Anomalien erkennbar macht, bevor sie sich zu Abweichungen aufschaukeln.
Operative Metriken: Auslastung, Commitment-Abdeckung und Right-Sizing-Potenzial
Auslastungs-Metriken messen, wie viel einer bereitgestellten Ressource Ihre Workloads tatsächlich verbrauchen. CPU- und Speicherauslastung auf Compute-Instanzen sind die bekanntesten Beispiele; der Schwellenwert für Right-Sizing-Kandidaten hängt vom Workload-Typ ab. Die meisten Teams markieren Instanzen mit einer durchschnittlichen CPU-Auslastung unter 20 bis 30 % als prüfungswürdig, wobei latenzsensitive Workloads eine höhere Bereitstellung als Puffer rechtfertigen können.
Auslastung allein ist ein unvollständiges Signal. Ein Cluster mit 15 % CPU-Auslastung ist entweder überdimensioniert – oder korrekt dimensioniert für eine Workload, die unter Spitzenlast auf 90 % hochschießt. Auslastungs-Metriken sagen Ihnen nur, wo Sie hinsehen sollen. Ob die Ressource richtig dimensioniert ist, zeigt sich erst, wenn Sie Peak-, Durchschnitts- und Perzentil-Verhalten gemeinsam betrachten.
Die Commitment-Abdeckung erfasst den Anteil der berechtigten Workloads, die durch Reserved Instances, Savings Plans oder Committed Use Discounts abgedeckt sind. Für die meisten Organisationen, die AWS, Google Cloud oder Azure in großem Maßstab betreiben, gehören nicht abgedeckte On-Demand-Ausgaben auf stabilen Workloads zu den kostenintensivsten Effizienzlücken, die sich schließen lassen. Ein Team mit 40 % Commitment-Abdeckung auf Workloads, die rund um die Uhr laufen, lässt erhebliche Einsparungen liegen.
Das Right-Sizing-Potenzial ist die aggregierte geschätzte Einsparung, die sich durch das Verkleinern oder Anpassen überdimensionierter Ressourcen in Ihrer Umgebung erzielen lässt. Es ist handlungsleitender als der reine Auslastungsprozentsatz, weil es die Chance in Euro ausdrückt – der Einheit, auf die Engineering- und Finance-Verantwortliche gleichermaßen reagieren.
Waste-Metriken: ungenutzte Ressourcen, verwaister Storage und nicht zugeordnete Ausgaben
Waste-Metriken identifizieren Cloud-Ausgaben, die keinen Geschäftswert erzeugen. Sie sind die Optimierungsziele mit höchster Priorität, weil die Einsparungen nahezu risikofrei sind: kein Performance-Kompromiss zu analysieren, kein Stakeholder zu überzeugen, keine Architekturänderung nötig.
Zu den ungenutzten Ressourcen zählen gestoppte Instanzen, die weiter Gebühren verursachen, Load Balancer, die noch an stillgelegten Services hängen, und Entwicklungsumgebungen, die an Wochenenden und Feiertagen weiterlaufen. Die Einzelkosten pro ungenutzter Ressource sind selten groß. Die Summe über eine mittelgroße Engineering-Organisation hinweg ist es fast immer.
Verwaister Storage entsteht, wenn Compute-Ressourcen beendet werden, ihre angehängten Volumes, Snapshots und Backups aber nicht. Object-Storage-Buckets aus eingestellten Projekten, Datenbank-Snapshots aus längst nicht mehr existierenden Umgebungen und Log-Archive, die ihre Aufbewahrungsfrist überdauert haben, fallen alle in diese Kategorie. Verwaister Storage ist besonders verbreitet in Organisationen, die beim Bereitstellen von Infrastruktur schnell sind, ohne beim Abschalten dieselbe Disziplin mitzubringen.
Nicht zugeordnete Ausgaben sind Cloud-Kosten, die sich wegen fehlender oder inkonsistenter Tags keinem Team, Produkt oder Cost Center zuweisen lassen. Das ist eine Waste-Metrik anderer Art: Sie steht nicht für Ressourcen, die keinen Wert liefern, sondern für Ressourcen, deren Wert unbekannt ist. Was sich nicht zuordnen lässt, lässt sich auch nicht optimieren – und nicht zugeordnete Ausgaben sind der Frühindikator für eine Governance-Lücke, die sich mit wachsender Umgebung immer schwerer schließen lässt.
Geschäftliche Metriken: Unit Economics und Kosten im Verhältnis zum Umsatz
Geschäftliche Metriken sind der Punkt, an dem FinOps von einer Kostensenkungs- zu einer strategischen Funktion wird. Unit Economics – ausgedrückt als Kosten pro Kunde, pro Transaktion, pro API-Aufruf oder pro aktivem Nutzer – beantworten die Frage, an der finanzielle Metriken scheitern: Sind diese Cloud-Ausgaben effizient im Verhältnis zum Geschäftswert, den sie erzeugen?
Ein Unternehmen, das 2 Millionen Dollar pro Monat für Cloud-Infrastruktur ausgibt und den Umsatz um 40 % pro Jahr steigert, steht ganz anders da als eines mit derselben Rechnung und stagnierendem Wachstum. Die Gesamtausgaben als Metrik behandeln beide Situationen identisch. Kosten im Verhältnis zum Umsatz oder Kosten pro Einheit Geschäftsleistung unterscheiden sie.
Unit Economics verändern auch das Gespräch mit Engineering-Teams. Einem Team zu sagen, sein Service kostet 180.000 Dollar pro Monat, führt selten zu Handlung. Ihm zu sagen, sein Service kostet 0,23 Dollar pro aktivem Nutzer und der Marktführer liegt bei 0,11 Dollar, führt zu einem Design-Gespräch. Die Metrik verknüpft Cloud-Kosten mit Produktleistung – in einer Sprache, mit der Engineers etwas anfangen können.
Unit Economics aufzubauen bedeutet, Cloud-Billing-Daten mit Geschäftsdaten zu verknüpfen – konkret mit der Anwendungsschicht, die Infrastrukturkosten den Produkten und der Kundenaktivität zuordnet, die sie tragen. Das ist technisch anspruchsvoller als das Tracken von Auslastung oder Budgetabweichung, weshalb es eine Metrik der Reifephase ist. Aber genau hier liegen auch die Optimierungsentscheidungen mit der größten Hebelwirkung.
Wie wählen Sie die richtigen Metriken für Ihren FinOps-Reifegrad?
Das Crawl/Walk/Run-Framework der FinOps Foundation liefert eine brauchbare Landkarte für die Priorisierung von Metriken. Die richtigen Metriken sind nicht die anspruchsvollsten verfügbaren. Es sind jene, die zu den Fragen passen, die Ihr Unternehmen mit der vorhandenen Datenqualität und dem vorhandenen Tooling gerade tatsächlich beantworten kann.
Frühe Phase: Sichtbarkeits-Metriken
In der Crawl-Phase ist das Hauptproblem, dass Kosten nicht sichtbar oder zuordenbar sind. Sie sehen eine Gesamtrechnung. Sie sehen nicht, welche Teams, Services oder Produkte sie treiben. Die Metriken, die hier zählen, sind grundlegend: Tagging-Abdeckungsrate, Kosten nach Account und Service sowie Budgetabweichung nach Geschäftseinheit.
Die Tagging-Abdeckung ist eine Input-, keine Output-Metrik: Sie misst, wie viel Ihrer Cloud-Ausgaben die Attributionsmetadaten trägt, die alles Weitere überhaupt erst möglich machen. Teams, die diesen Schritt überspringen und direkt zu Optimierungs-Metriken vorpreschen, optimieren am Ende die sichtbaren Teile der Infrastruktur, während sie die unsichtbaren ignorieren.
Das Ziel in der Crawl-Phase ist nicht perfekte Optimierung. Es geht darum, die Basis zu schaffen, die Optimierung überhaupt möglich macht.
Mittlere Phase: Optimierungs-Metriken
In der Walk-Phase ist die Sichtbarkeit da und das Team bereit zu handeln. Die jetzt entscheidenden Metriken identifizieren Optimierungschancen und validieren, dass Maßnahmen reale Einsparungen bringen: Commitment-Abdeckung, Right-Sizing-Potenzial, Waste als Anteil an den Gesamtausgaben und Prognosegenauigkeit.
Die Commitment-Abdeckung verdient in dieser Phase besondere Aufmerksamkeit. Sie ist einer der ertragreichsten Optimierungshebel und erfordert relativ wenig operativen Aufwand, sobald eine Einkaufsdisziplin etabliert ist. Teams, die Ziele für die Commitment-Abdeckung festlegen und einen Prozess zur quartalsweisen Überprüfung und Anpassung aufbauen, erzielen in der Regel nachhaltige Einsparungen, die sich über die Zeit aufsummieren.
Auch die Prognosegenauigkeit wird in dieser Phase wichtig, weil das Team nun regelmäßig mit Finance und Führung über Cloud-Ausgaben spricht. Prognosen, die konstant um 20 % oder mehr danebenliegen, untergraben die Glaubwürdigkeit des FinOps-Teams als Planungsfunktion – ganz gleich, wie viel Waste es beseitigt hat.
Reife Phase: Effizienz- und Business-Value-Metriken
In der Run-Phase verfügt das Team über stabile Sichtbarkeit, aktive Optimierungsprogramme und verlässliche Prognosen. Die jetzt zählenden Metriken verbinden Cloud-Leistung mit Geschäftsleistung: Unit Economics, Kosten im Verhältnis zum Umsatz und Effizienzquoten nach Workload oder Produkt.
In dieser Phase wird auch die Anomalieerkennung zum strategischen statt reaktiven Werkzeug. Reife Teams nutzen Kostenanomalie-Warnungen nicht nur, um ausufernde Ausgaben abzufangen, sondern auch, um frühe Signale architektonischer Ineffizienzen zu erkennen – etwa einen neuen Service, der dreimal so viel Compute verbraucht wie sein Vorgänger, einen Batch-Job, der mehr Daten scannt als erwartet, oder ein Feature, das einen überproportionalen Anteil an Egress-Gebühren erzeugt.
Die DataHub-Funktion von DoiT verknüpft Cloud-Billing-Daten direkt mit Geschäftsmetriken und macht Unit Economics greifbar, ohne dass eine eigene Datenpipeline gebaut werden muss. Für Teams, die Sichtbarkeit und Optimierungsdisziplinen etabliert, die Datenschicht für messbare Unit Economics aber noch nicht aufgebaut haben, ist sie die Brücke vom Walk- zum Run-Stage-Reporting.
Was sind die häufigsten Fallstricke beim Tracking von Cloud-Kosten-Metriken?
Einige weit verbreitete Metriken sehen nützlich aus, führen FinOps-Teams aber immer wieder in die Irre. Zu wissen, wo die Fallen liegen, spart die Zeit und Glaubwürdigkeit, die es kostet, hineinzulaufen.
Reines Auslastungsdenken ist der häufigste Fehler. Hohe Auslastung sieht nach Effizienz aus – und oft ist sie das auch. Aber ein Kubernetes-Cluster mit 90 % CPU-Auslastung stößt möglicherweise an Performance-Grenzen, die Antwortzeiten der Anwendung verlangsamen. Eine Datenbank mit 85 % Speicherauslastung drosselt vielleicht Queries. Auslastung ohne Performance-Kontext verwechselt Ressourcendruck mit Ressourceneffizienz. Verfolgen Sie Auslastung neben Performance-Metriken – nicht als Ersatz für sie.
Das Tracken der Gesamtausgaben, das Wachstum bestraft, setzt die falschen Anreize. Ist der primäre KPI des FinOps-Teams die Senkung der gesamten Cloud-Ausgaben, wird es auf Ausgabensenkung optimieren – manchmal auf Kosten der Engineering-Geschwindigkeit oder Produktfähigkeiten, die überhaupt erst zur Cloud-Nutzung geführt haben. Gesamtausgaben sind ein nützlicher Input für das Gespräch, keine Erfolgsmetrik. Kosten im Verhältnis zum Umsatz oder Kosten pro Einheit Geschäftsleistung sind der bessere Näherungswert dafür, ob die Cloud-Ausgaben gesund sind.
Intent-blinde Analyse wendet generische Benchmarks auf Workloads mit spezifischem Zweck an. Ein Machine-Learning-Trainingsjob, der während der Datenvorverarbeitung mit 40 % GPU-Auslastung läuft, ist nicht überdimensioniert. Er läuft in der Vorverarbeitungsphase einer Pipeline, die im Training auf 95 % hochschießen wird. Eine Disaster-Recovery-Umgebung, die die meiste Zeit stillsteht, ist keine Verschwendung. Sie ist Versicherung. Right-Sizing-Empfehlungen, die den Zweck der Workload ignorieren, senken Kosten und Zuverlässigkeit gleichzeitig.
Das Anhäufen von Vanity-Metriken – mehr Metriken zu verfolgen, weil mehr nach Gründlichkeit aussieht – erzeugt Reporting-Overhead ohne analytische Tiefe. Wenn eine Metrik nicht mit einer Entscheidung oder Handlung verbunden ist, verbraucht sie Aufmerksamkeit, die den handlungsleitenden Metriken fehlt.
Wie bauen Sie eine Metrik-Praxis auf, die Cloud-Kosten wirklich senkt?
Metriken ohne dahinterliegende Handlungsebene sind Dashboards. Eine Zahl, die geprüft, besprochen und abgeheftet wird, optimiert nichts. Eine Zahl, die eine definierte Reaktion auslöst – etwa eine Right-Sizing-Empfehlung an ein bestimmtes Engineering-Team, eine Commitment-Abdeckungslücke, die eine Einkaufsprüfung anstößt, oder eine Prognoseabweichung, die eine Anomalieuntersuchung aktiviert – bringt Ergebnisse.
Der Unterschied zwischen Teams, die Metriken wirkungsvoll nutzen, und solchen, die es nicht tun, läuft meist auf drei Praktiken hinaus. Sie definieren Reaktionsschwellen, bevor sie sie brauchen: Fällt die Commitment-Abdeckung unter X %, wird die Einkaufsprüfung ausgelöst. Sie weisen Verantwortlichkeiten für Metriken zu: Jemand ist für die Prognosegenauigkeit verantwortlich, so wie jemand für die Uptime verantwortlich ist. Und sie sorgen dafür, dass Metrik und Ergebnis eng verzahnt sind: Wenn eine Right-Sizing-Empfehlung umgesetzt wird, werden die Einsparungen gemessen und an das Team zurückgemeldet, das sie umgesetzt hat.
Automatisierung verstärkt alle drei Praktiken. Manuelle Metrik-Reviews skalieren nicht, wenn die Infrastruktur wächst. Teams, die Anomalieerkennung, Tag-Compliance-Durchsetzung und die routinemäßige Identifikation von Waste automatisieren, machen Engineering-Aufmerksamkeit frei für die Optimierungsarbeit, die Urteilsvermögen erfordert – Architekturentscheidungen, Commitment-Strategie und Workload-Design.
Der State-of-FinOps-Report 2025 der FinOps Foundation zeigt, dass Workload-Optimierung und Waste-Reduzierung für über 50 % der FinOps-Praktiker weiterhin höchste Priorität haben – und die Teams, die auf beiden Feldern am schnellsten vorankommen, verfolgen nicht mehr Metriken. Sie handeln bei weniger, aber besseren Metriken – und das schneller.
Die FinOps-Plattform von DoiT liefert Teams die Analytics, Anomalieerkennung und das DataHub-Business-Metric-Mapping, um vom Tracken zum Handeln zu kommen. Wenn Ihre Metrik-Praxis Ihrem Tooling entwachsen ist, sprechen Sie mit unserem Team und erfahren Sie, wie DoiT Cloud-Kostendaten in automatisierte Handlung verwandelt.
Häufig gestellte Fragen
Was sind die wichtigsten Metriken zur Cloud-Kostenoptimierung für ein neues FinOps-Team?
Ein neues FinOps-Team sollte mit drei Metriken beginnen: Tagging-Abdeckungsrate, Kosten nach Account und Service sowie Budgetabweichung nach Geschäftseinheit. Diese Metriken der Sichtbarkeitsschicht schaffen die Attributionsgrundlage, die alles Weitere möglich macht. Auslastungs- und Waste-Metriken sind schwerer umzusetzen, solange Kosten noch keinen spezifischen Teams oder Workloads zugeordnet werden können. Bauen Sie zuerst die Basis auf und legen Sie dann Optimierungs-Metriken darüber, sobald die Ausgaben sichtbar und zugeordnet sind. Der Versuch, zu optimieren, bevor man klar sieht, erzeugt Einzellösungen, die sich nicht aufsummieren.
Wie unterscheiden sich Unit Economics von Auslastungs-Metriken?
Auslastungs-Metriken messen, wie viel einer bereitgestellten Ressource eine Workload verbraucht. Unit Economics messen, wie viel es kostet, eine Einheit Geschäftswert zu liefern: einen bedienten Kunden, eine verarbeitete Transaktion, einen abgeschlossenen API-Aufruf. Auslastung sagt Ihnen, ob eine Ressource genutzt wird. Unit Economics sagen Ihnen, ob ihre Nutzung effizient ist im Verhältnis zu dem, was das Unternehmen dafür bekommt. Ein stark ausgelastetes Cluster, das eine Workload mit geringem Wert fährt, sieht auf einem Auslastungs-Dashboard gesund aus – und auf einem Unit-Economics-Report schwach. Die beiden Metriken beantworten unterschiedliche Fragen, und reife FinOps-Praktiken brauchen beide.
Was ist ein guter Zielwert für die Prognosegenauigkeit von Cloud-Kosten?
Die meisten Organisationen werten 10 bis 15 % Abweichung zwischen Prognose und Ist als akzeptabel. Teams mit ausgereifter Commitment-Strategie, stabilen Workloads und sauberer Kostenzuordnung erreichen häufig 5 % oder besser. Aufschlussreicher ist der Blick auf die Richtungsgenauigkeit: Eine Prognose, die konstant 12 % zu niedrig liegt, ist ein Kalibrierungsproblem, das sich beheben lässt. Eine Prognose, die mal 5 % zu hoch und mal 25 % zu niedrig liegt, deutet auf ein Datenqualitäts- oder Attributionsproblem hin, das kein Prognosemodell lösen wird. Verbessern Sie zuerst die Tagging-Abdeckung und die Sichtbarkeit auf Account-Ebene und arbeiten Sie dann daran, die Abweichungsspanne zu verengen.