Five engagements, every figure with its status
Engagements of the firm and its founder, anonymized: the context, the approach, the deliverables, the duration and results whose status is shown. An identified potential is not a realized saving: we never add them up.
Four statuses, from estimate to invoice
A figure changes status as the action moves forward. The status sits next to every value, on this page as on the home page.
Identified
Computed on the observed cost, amortized or billed, never on a list price. It is a potential, not yet a decision.
Validated
Accepted by the owner of the resource or by management. The action is decided; it is not executed yet.
Realized
Change executed or purchase made. When the gain is an avoided cost, for example a renewed reservation, it is presented as such.
Verified in the invoice
Measured in the billing data, before and after, resource by resource or line by line. A credit, a one-off correction or a scope reduction is never counted as a saving.
Two other labels. Deliverable: a measurement, analysis or product handed over to the client, or work done with its teams, with no savings amount. Measured lead time: the time observed between two stages of the engagement. The method also has a Planned status (date and change or order reference): no figure published here carries it.
The cases at a glance
Generic sector, wide size range, three key results. Each card leads to the detailed case and to the closest offer.
An Azure bill already partly optimized
A few million euros of cloud spend a year.
- Identified about 29% of the Azure bill in potential savings
- Validated about 6.5% of the Azure bill in actions validated after six weeks
- Realized less than 1% of the bill executed excluding reservations after six weeks, measured in the invoice for nearly all actions
Cloud procurement of a large services group
Several tens of millions of euros of cloud spend a year.
- Identified register of 67 levers, €1.4M to €2.7M a year
- Validated €0.6M to €1.2M a year of decided actions
- Verified in the invoice €0.2M to €0.3M a year, annualized
A mature AWS foundation, potential quantified lever by lever
AWS bill of €5M to €15M a year.
- Identified incremental potential of about 10% to 25% of the AWS bill
- Identified about 4% of the bill by switching off non-production that runs around the clock
- Deliverable reporting faithful to the reference values above 99%
SAP non-production: a sequenced Start & Stop
Eligible non-production compute in the order of €0.2M a year.
- Deliverable about three in four analyzed VMs running around the clock
- Identified about 29% of non-production compute with a weekend shutdown, in simulation
- Identified about 61% with a night and weekend shutdown, in simulation
On-premises and cloud costs brought together by application
In the order of one to two million euros of cloud a year. Engagement led by the founder.
- Deliverable full on-premises cost brought down to a monthly cost, application by application
- Deliverable comparable TCO by migration wave
- Deliverable billed prices checked SKU by SKU
Cases published subject to the clients' agreement.
An Azure bill already partly optimized
29% of the bill identified as savings, first changes in four weeks, savings tracked down to the invoice.
Context. The Azure foundation, several dozen subscriptions and several hundred VMs, was run by a managed service provider and already partly optimized: nearly 80% of standard-family vCPUs were covered by reservations (audit measurement). Access was limited to read-only, with no contractual billing scope, and every action had to go through a change at the managed service provider after validation by the entity concerned. Switching off non-production was held back by the fear of losing the benefit of reservations, and management expected savings delivered within one to three months without overloading local teams.
Approach. Read-only collection: amortized billing, inventory, 30 days of per-minute metrics, native recommendations and backup. Savings computed on the observed cost, never on the public price, with cautious written rules: production is not resized, software packages with certified sizes are excluded from Start & Stop, and usage is reduced before reserving. Resources covered and not covered by reservations are mapped, so that non-production can be switched off without losing a discount. The action plan, in French and English, has one line per resource and per action (evidence, effort, risk, prerequisites); each entity validates it online, then it becomes a list of changes for the managed service provider. A Savings Tracker follows every action from identified to verified in the invoice, comparing daily cost before and after. The approach was then extended to Google Cloud with the same levers. Robustness check: the audit replayed on an anonymized copy of the data finds 22 key totals out of 22 within 1%.
Deliverables. Configurable analysis workbook built entirely on formulas; management summaries, global and by entity, in French and English; presentation to the technology leadership; action plans by entity with online validation; change lists by VM and batches of changes without downtime; Savings Tracker from identified to verified in the invoice; right-sizing, Start & Stop and Green IT KPIs by entity; Google Cloud assessment with plans by scope; self-service collection procedure.
Sector: consumer goods, international group organized in several entities.
Size: a few million euros of cloud spend a year.
Clouds: Azure, then Google Cloud.
Duration: 15-day audit spread over six weeks, then execution of the quick wins and FinOps run.
Results, frozen after six weeks:
- Identified about 29% of the monthly Azure bill in potential savings, about 28% net of overlaps between levers.
- Identified nearly half of this potential in quick wins, reachable in less than six weeks with at most three days of effort per lever.
- Deliverable more than 1,200 findings documented resource by resource, and about 97% of the cost attributed to an entity or to the central teams.
- Validated 12 changes launched or ready at the managed service provider four weeks after the start, for about 1.6% of the Azure bill.
- Validated about 6.5% of the Azure bill in actions validated after six weeks; nearly half of this amount comes from management decisions on backup.
- Realized less than 1% of the bill executed after six weeks excluding reservations, measured in the invoice for nearly all actions.
- Realized avoided cost: an expiring reservation was renewed after right-sizing instead of falling back to on-demand rates, about 1.4% of the bill. This gain is estimated against the on-demand rate; it is not a reduction of the invoice.
- Verified in the invoice on the first 60 or so realized actions, the savings measured in daily billing exceed the initial estimate; about three actions in four are deletions of unattached disks.
- Identified about 16% of the Google Cloud bill in potential savings, more than 40% of it in quick wins.
- Deliverable Google Cloud assessment delivered the day after the read-only collection.
- Deliverable starting point measured by entity: 77% of VMs correctly sized (cautious rule with double confirmation) and 26% of eligible non-production (excluding software packages with certified sizes) under Start & Stop.
Cloud procurement of a large services group
Technical optimization put back under ownership, up to the first savings verified in the invoice.
Context. Procurement controlled negotiated discounts and commitments, but technical optimization (right-sizing, clean-up, scheduling, licensing) was almost absent: in the year before the engagement it accounted for 0.4% of Azure savings (assessment measurement), the rest coming from discounts, reservations and Azure Hybrid Benefit. The FinOps team only had read access to costs, and thousands of native recommendations remained undecided. The Cloud category plan set a FinOps savings line to deliver within the year, while generative AI was driving spend growth.
Approach. Data-based assessment: 12 months of FOCUS exports, the existing savings tracker and a maturity questionnaire, every estimate flagged as such. Multi-cloud register of levers, with owner, decision and status. Execution campaigns by owner, with reminders and escalation, and decision packs by business unit, settled line by line. Savings Tracker with four statuses (verified in the invoice, decided or purchased, potential, not counted) and hygiene rules: no credit, one-off correction or scope reduction is counted as a saving. AI spend put under governance rather than cut: owner, budget, alerts, cost per million tokens compared by model and by access channel. Cloud category plan and group FinOps business case handed to Procurement.
Deliverables. FinOps maturity assessment of the IT department (short and detailed versions) and assessment workbook; register of levers and half-year action plan; Savings Tracker and monthly savings reviews for the steering committee; decision packs by business unit; licensing review with threshold calculators; Cloud category plan and group FinOps business case.
Sector: business services, international group.
Size: several tens of millions of euros of cloud spend a year on the main scope.
Clouds: Azure, AWS and Google Cloud.
Duration: about 8 months, assessment then execution task force.
Results
- Identified indicative estimate: potential of 10% to 15% of Azure spend beyond current practices, partly included in the register of levers below (amounts not cumulative).
- Identified register of 67 levers across three clouds, for €1.4M to €2.7M a year.
- Validated €0.6M to €1.2M a year of decided actions (three-year commitments on the three clouds, non-production scheduling, disks, backup and storage policies), with an effect expected on the following invoices. Part of them is already purchased, hence realized: the engagement tracking does not separate the two amounts yet, published together under the Validated status.
- Verified in the invoice €0.2M to €0.3M a year, annualized; nothing is counted before it shows in the invoice.
- Verified in the invoice SQL Server license line down 12% in the first month, then at a 27% rate of decrease the following month, excluding the correction of a one-off double-licensing peak.
- Deliverable 10 execution campaigns run with 33 owners.
- Validated on an AWS scope, more than 1,600 recommendations accepted and more than 400 explicitly rejected by their owners.
- Identified review of a software licensing line quantified at 4% to 11% of that line, not counted before technical validation.
A mature AWS foundation, potential quantified lever by lever
Allocation and commitments already well managed: potential of 10% to 25% of the AWS bill quantified lever by lever, and industrialized cost reporting.
Context. About twenty product teams are accountable for their budget. Allocation was mature (near-complete tagging, showback and chargeback in place) and commitments already well managed; usage optimization lagged behind. Several inconsistent cost views confused the product teams, and reporting relied on many manual exports.
Approach. Fresh-eyes report after two months: maturity assessed pillar by pillar, five priorities and a roadmap in four quarterly increments. Start & Stop indicators on EC2 and on databases measured on actual hourly usage rather than on configuration, crossing the scheduling tag with observed behavior. Two-year optimization plan: 18 levers quantified with a low and a high estimate, with dependencies, owner, target quarter and confidence level, separating new potential from actions already realized or committed. Industrialized reporting of amortized costs, from detailed billing data to the BI tool, with handover documentation.
Deliverables. Fresh-eyes report (full version and one-page summary); EC2 and database Start & Stop indicators by team and by environment; two-year optimization plan, with commitment coverage and savings, action plan and reconciliation with the existing backlog; cost and savings tracking dashboard (realized, committed, qualified); automated amortized cost workbook; handover documentation.
Sector: financial services and insurance, large group.
Size: AWS bill of €5M to €15M a year.
Cloud: AWS.
Duration: about five months, within the client's team.
Results
- Deliverable actual Start & Stop adoption measured on about 60% of non-production EC2 instances, but on only one non-production database in six.
- Identified some thirty instances tagged for Start & Stop but running around the clock (broken automations), and more than 150 instances running continuously with no schedule, targeted first.
- Identified about 4% of the AWS bill to capture by switching off non-production that runs around the clock.
- Identified incremental potential of about 10% to 25% of the AWS bill, excluding actions already realized or committed, of which about 3% to 6% of the bill in high-return quick wins.
- Deliverable industrialized reporting, faithful to the reference values above 99% on each of the five data flows.
SAP non-production: a sequenced Start & Stop
On Azure, up to 61% of non-production compute cost identified as avoidable, in simulation, with a night and weekend shutdown.
Context. The SAP non-production environment, on Azure, is run by a managed service provider, and commitments are managed centrally by the client. No Start & Stop was in place. Stopping an SAP system requires strict sequencing: the HANA database is stopped last and restarted first, high-availability clusters start together, and the running window must cover the working hours of every delivery team.
Approach. Daily amortized cost read VM by VM, to separate VMs running continuously from those already stopped, excluding a temporary sandbox. Simulation of two schedules by VM type: HANA database, application servers and peripheral services. An SAP-aware stop and start sequence written. One assumption was corrected during the study: nodes first assumed to be standby belonged to high-availability clusters and could not be switched off permanently. Prerequisites set before any rollout: SAP-aware orchestration, dependency mapping, batch calendar, pilot on a development system.
Deliverables. Start & Stop analysis summary (PDF and presentation); simulation workbook configurable by VM and by schedule; VM inventory and billing status; SAP stop and start sequence; prerequisites, limitations and risks; four-step trajectory, from alignment to rollout by VM type.
Sector: industry, international group.
Size: eligible non-production compute in the order of €0.2M a year.
Cloud: Azure.
Duration: targeted study on one month of amortized billing.
Results
- Deliverable about three in four analyzed VMs running around the clock, with no Start & Stop.
- Identified about 29% savings on non-production compute with a weekend shutdown, in simulation.
- Identified about 61% savings with a night and weekend shutdown, in simulation.
- Deliverable HANA databases account for over half of the base cost, hence of the gain: their sequencing drives the result.
On-premises and cloud costs brought together by application
A common basis to decide the migration waves on a comparable TCO.
Context. A hybrid IT estate where on-premises (virtualization, Unix, mainframe, storage, backup, network, licenses) weighs several times the cloud. A migration to the public cloud was under way, and its consumption was growing fast. On-premises cost was not broken down by application, while every migration wave had to be decided on a comparable TCO and billing had to be checked against contractual commitments.
Approach. Near real-time FinOps reporting platform (billing export, data warehouse, BI tool) carrying allocation to departments and business lines, Build & Run budgets, a monthly reforecast, anomaly detection and tagging compliance. Full on-premises cost model industrialized and brought down to a monthly cost per application. On-premises versus cloud TCO by application and by migration wave. Prioritized optimization backlog: commitments, right-sizing, containers, storage, intensive computing on spot capacity. Billing checked SKU by SKU against the contractual price grid, and supplier committees.
Deliverables. FinOps reporting platform with allocation, budgets and alerts; full on-premises cost calculator and its update documentation; single on-premises and cloud dashboard by application; TCO by migration wave; prioritized optimization backlog; roles, processes and quarterly FinOps committee.
Sector: financial services and insurance, large group.
Size: in the order of one to two million euros of cloud a year, against on-premises costs several times higher.
Platforms: virtualization, Unix, mainframe and public cloud.
Duration: more than a year, engagement led by the founder.
Results. No savings amount or volume is published for this case.
- Deliverable full on-premises cost model brought down to a monthly cost for each application, across virtualization, Unix and mainframe.
- Deliverable on-premises and cloud costs brought together by application in a single dashboard, the basis for the TCO of the migration waves and for IT decisions.
- Deliverable every cloud project attached to its application code for showback.
- Deliverable billed prices checked SKU by SKU against the contractual price grid.
- Deliverable cost anomaly detection and alerts, in the reporting platform.
Does your situation look like one of these cases?
Thirty minutes to identify the right entry point and what it will produce for you, with the same statuses for every figure.