TLDR: FinOps is neither software nor a cost-cutting program. It is the ability to understand cloud spending collaboratively before trying to optimize it. Anyone who tinkers with costs without transparency is guessing. The first step is simple: Look at your cloud bill for the last three months and answer one question. Do you know why the largest line items are so high?

"Why does this cost so much?"

"I don’t know exactly."

CFO and IT lead, Friday morning, the cloud bill from the last quarter on the table. Silence. Both know the answer is unsatisfactory. Neither knows what the next step should be.

We have this conversation more often than we’d like. In different companies, with different numbers, but always with the same pattern. The cloud bill goes up. No one can explain precisely why. And the reaction is usually one of two options: Either the topic is postponed ("We’ll look at it next quarter"), or people reflexively search for savings without understanding where the money is actually going.

Neither leads anywhere. And this is exactly where FinOps begins.

The problem is not the bill, but the gap in between

FinOps stands for Financial Operations. The term comes from the FinOps Foundation, a non-profit that formalized the framework. But forget the formal definition for a moment. In practice, it is about something very simple: treating cloud costs like any other business expense. With transparency. With accountability. With a point of view on whether the spend is worth it.

Sounds obvious. It isn’t.

With classic on-premises IT, the budget was relatively fixed. Once you bought a server, it ran whether you used it or not. That enforced a strange kind of discipline. In the cloud, everything is different. Resources are created at the push of a button. A developer needs a test environment? Three minutes later, it’s running. Does anyone ask about it again three months later? Usually not. Is it still running anyway? Usually yes. At your expense.

This elasticity is both the cloud’s biggest advantage and its biggest cost driver. And this is the gap FinOps closes: not between "too expensive" and "cheaper," but between "we don’t know what we’re paying for" and "we understand every franc."

When companies talk to us about cloud costs for the first time, the sentence is almost always: "We need to reduce our cloud costs." That is not wrong. But it is the wrong starting question. Because sometimes higher cloud costs are a good sign. The business is growing. A product launch was successful. The engineering team operated at sprint speed. The right question is: Are we getting the value we expect for what we spend? That is the difference between cost reduction and cloud financial management.

(We described this in more detail in an earlier post about uncontrolled cloud costs.)

The FinOps framework describes three phases: Inform, Optimize, Operate. First, create transparency. What is running where, who deployed what, how much does it cost, who owns it? This phase is more tedious than it sounds. Tagging structures are missing. Historical data is fragmented. Teams have resources spread across multiple accounts. Only when you can see what is running can you assess what is truly necessary. Idle resources, oversized instances, development environments that do not shut down at night. The classic levers we described in our post on reducing cloud costs for SMEs. And then the part most people underestimate: ongoing operations. A one-time cleanup does little if the same problems reappear three months later. Who is responsible for which costs? What does the monthly review look like? What happens when a team exceeds its budget? That requires processes, not tools.

Why it works differently in SMEs (and still works)

The FinOps framework comes from an enterprise context. Companies with million-dollar cloud budgets, dedicated FinOps teams, and dedicated tooling infrastructure. For a Swiss SME with 80 employees and annual cloud spend of CHF 80,000, that is overkill.

You do not need the full framework. You need the principles.

What we repeatedly implement in SME projects is a lean version. A basic tagging structure: resources are labeled by team, project, or cost center. Technically not complex, but it requires agreement on the system. A monthly cost review: half an hour, IT and Finance, numbers on the table. What has increased, what has changed, what needs a decision? And clear ownership: Who is the point of contact when a specific cost line increases? That must be defined before the problem appears.

Not a sophisticated program. But a beginning that works.

The biggest conceptual difference from a classic cost-cutting program: FinOps is not purely an IT topic. Traditional cost management often runs in one direction. The CFO looks at the total bill, sends an email to IT, IT tweaks something somewhere, then things are quiet for a while. The underlying problem remains. FinOps works differently because it shifts responsibility. Business units see their own costs. Engineering teams know what their architecture decisions cost. Finance understands why cloud spending rises in certain months.

That sounds simple. In practice, it is the hardest part. We have supported companies where the technical side (tagging, dashboards, cost alerts) was in place within a few weeks. But the question of which team is responsible for which spend, and how that fits into existing budget logic? Six months of alignment. And that is normal. FinOps is a cultural change that also happens to include tool usage. Not the other way around.

(By the way, the same principle applies to SaaS licenses. We have supported companies where a formal license audit brought the first real clarity.)

What failed FinOps implementations had in common: too much tool, too little process. A new dashboard does not solve a governance problem. FinOps as a pure IT project without Finance at the table. Perfectionism in structures before anyone even starts. And the most common mistake: positioning FinOps only as a savings program, so engineering teams see it as a threat instead of a tool.

Look at your cloud bill for the last three months, broken down by service type, and answer one question honestly: Do you know why the largest items are so high?