O que é orçamento

Orçamento é a tradução da estratégia em números. É um plano financeiro para um período, normalmente um ano, que diz quanto a organização espera receber, quanto pretende gastar e em quê. Quando a estratégia diz “vamos crescer no digital”, é o orçamento que mostra se isso vai acontecer de fato ou se é só uma frase.

Mais do que uma planilha, o orçamento cumpre quatro funções:

• Planejar: obriga a pensar antes em prioridades, riscos e premissas, como câmbio, reajuste de contratos e crescimento do número de usuários.
• Alocar: distribui um recurso escasso entre usos que competem entre si. Todo real aprovado para uma coisa deixa de estar disponível para outra.
• Coordenar: alinha áreas diferentes em torno dos mesmos números. A TI, o financeiro e o negócio passam a discutir a mesma base.
• Controlar: cria a referência para comparar o orçado com o realizado e agir quando os dois se afastam.

Na TI, o orçamento costuma se dividir em dois grandes grupos:

A migração para nuvem e SaaS vem deslocando o gasto de TI do CAPEX para o OPEX. O resultado é um orçamento mais flexível, mas também mais fácil de crescer sem que ninguém perceba: uma assinatura a mais aqui, uma máquina virtual esquecida ali.

Tipos de orçamento

Não existe um único jeito de orçar. Cada tipo parte de uma pergunta diferente e serve melhor a uma situação diferente:

Há ainda quem proponha abandonar o orçamento anual fixo. O movimento Beyond Budgeting, de Jeremy Hope e Robin Fraser, defende metas relativas, previsões contínuas e alocação de recursos sob demanda. ^[5]

Na prática, os tipos se combinam. Uma TI pode usar o OBZ para revisar o OPEX a cada dois ou três anos, o orçamento por programas para o portfólio de projetos e um rolling forecast trimestral para acompanhar tudo.

O que é orçamento base zero e suas origens

O orçamento base zero (OBZ, ou zero-based budgeting, ZBB) é um método em que cada gasto precisa ser justificado a partir do zero, a cada ciclo. O ponto de partida não é o valor do ano anterior: nenhuma despesa está garantida só porque já existia. ^[3]

Se esta atividade não existisse hoje, nós a criaríamos? Se sim, com que tamanho e de que forma?

O método se apoia em quatro conceitos, definidos por Peter Pyhrr ^{[1] [2]}:

• Unidade de decisão: a menor parte da organização para a qual faz sentido orçar e decidir. Pode ser um departamento, um serviço ou um projeto.
• Pacote de decisão: o documento que descreve o que a unidade faz, por que faz, quanto custa, quais alternativas foram avaliadas e o que acontece se deixar de fazer.
• Níveis de esforço: cada pacote é dividido em camadas. O nível mínimo é o que mantém a atividade viva; os níveis seguintes acrescentam serviço, qualidade ou alcance.
• Ranqueamento: todos os pacotes, de todas as unidades, são ordenados por prioridade. Os recursos vão sendo alocados de cima para baixo até acabar o dinheiro, na chamada linha de corte.

Origens

1. 1962O Departamento de Agricultura dos Estados Unidos tenta montar um orçamento a partir do zero. A experiência gera muito papel e pouca mudança, e é abandonada.
2. 1969–1970Peter A. Pyhrr, então na Texas Instruments, desenvolve o método para as áreas de apoio e de pesquisa da empresa e o publica na Harvard Business Review. ^[1]
3. 1973Pyhrr lança o livro Zero-Base Budgeting. Jimmy Carter, governador da Geórgia, leva o método para o orçamento do estado. ^[2]
4. 1977Já presidente, Carter determina o uso do OBZ em todo o governo federal americano. ^[4] O volume de papel e a resistência das agências fazem o método ser abandonado no início dos anos 1980.
5. Anos 2010O OBZ volta com força pelas mãos dos executivos brasileiros da 3G Capital, que levam a disciplina de custos da Ambev para Burger King, Heinz e Kraft. ^[8]

A história também traz um alerta. Em 2019, a Kraft Heinz registrou uma baixa contábil de cerca de 15 bilhões de dólares no valor das suas marcas, e parte dos analistas atribuiu o problema a anos de cortes que atingiram também o investimento em inovação e marketing. O OBZ é uma ferramenta para gastar melhor, não apenas para gastar menos.

Mudança dos processos tradicionais de orçamentação para o orçamento base zero

A diferença entre os dois modelos não está só na planilha, está no processo. No orçamento tradicional, o histórico é a base e a discussão gira em torno do acréscimo. No OBZ, a base é zerada e a discussão gira em torno do valor de cada atividade.

Orçamento tradicional

1. Históricorealizado do ano anterior
2. Ajuste+ inflação ou % de crescimento
3. Negociaçãopor conta contábil
4. Aprovaçãocorte linear se não couber

Orçamento base zero

1. Unidades de decisãoserviços e atividades
2. Pacotes de decisãoníveis e alternativas
3. Ranqueamentocom o negócio
4. Linha de corteaté o limite disponível
5. Acompanhamentoorçado × realizado

A mudança mais difícil é cultural. No modelo tradicional, o gestor aprende a defender o que já tem: pede um pouco a mais sabendo que haverá corte, e garante que a verba seja toda consumida até dezembro, porque sobra vira redução no ano seguinte. No OBZ, o gestor passa a justificar o que precisa, com alternativas e consequências. Isso exige que o financeiro e o negócio participem das decisões, e que a TI conheça os próprios custos com um nível de detalhe que muitas áreas não têm.

Como implantar e controlar de forma efetiva dentro de uma TI

Passo a passo da implantação

1. Garanta patrocínio e defina o escopo. O OBZ precisa do CIO e do CFO juntos. Comece pelo OPEX, onde o gasto recorrente se acumula sem revisão. Não é preciso passar tudo pelo OBZ todo ano: um rodízio em que cada serviço é revisto a cada dois ou três anos reduz o esforço.
2. Dê visibilidade aos custos. Monte o inventário de contratos, licenças, assinaturas SaaS, recursos de nuvem, pessoas e terceiros. Use uma taxonomia comum, como a do Technology Business Management (TBM), para ligar cada custo a um serviço. ^[6]
3. Defina as unidades de decisão por serviço. Organize por aquilo que a TI entrega, e não pelo plano de contas: ERP, colaboração, infraestrutura e nuvem, service desk, segurança, dados e projetos.
4. Monte os pacotes de decisão. Para cada unidade, descreva o objetivo, as alternativas avaliadas, os níveis mínimo, atual e incremental, o custo de cada nível e o risco de não fazer. Classifique cada pacote como manter, crescer ou transformar o negócio.
5. Ranqueie junto com o negócio. Use critérios explícitos: obrigação legal, risco de segurança, valor para o negócio e custo evitado. As áreas de negócio devem estar na mesa, porque são elas que sentem o que fica abaixo da linha de corte.
6. Transforme o ranqueamento em orçamento. Aprove os pacotes acima da linha de corte e registre as premissas: câmbio, reajuste de contratos por IGP-M ou IPCA, crescimento de usuários e datas de renovação.
7. Controle e revise continuamente. O OBZ não termina na aprovação. O acompanhamento mensal e a revisão trimestral mantêm o orçamento vivo, como mostra a seção de controle a seguir.

Exemplo de pacote de decisão: service desk

Alternativas avaliadas antes dos níveis: manter o atendimento interno, terceirizar o primeiro nível ou ampliar o autoatendimento com base de conhecimento e agente de IA. A alternativa escolhida foi manter o atendimento interno com mais autoatendimento, e ela foi detalhada em três níveis:

• Mínimo8 analistas, atendimento em horário comercial, prazo de solução de 8 horas para incidentes comuns.R$ 0,8 mi/ano
• Atual10 analistas, atendimento das 7h às 22h, prazo de solução de 4 horas.+ R$ 0,2 mi (R$ 1,0 mi)
• Incremental12 analistas, atendimento 24×7, prazo de solução de 2 horas.+ R$ 0,3 mi (R$ 1,3 mi)

Exemplo de ranqueamento e linha de corte

Com um orçamento disponível de R$ 10,0 milhões, os pacotes de todas as unidades são ordenados e financiados de cima para baixo:

Os R$ 0,5 milhão que sobram acima da linha não compram o pacote 8 inteiro. Ou ele é redesenhado, por exemplo renovando só os notebooks mais antigos, ou o valor vira reserva. A decisão fica explícita, com nome e consequência, em vez de um corte linear de 10% em todas as contas.

Onde procurar: alavancas por categoria de custo

Como controlar

• Orçado × realizado por unidade de decisão. Acompanhe mensalmente por serviço, e não só por conta contábil, e exija explicação para variações acima de um limite combinado, por exemplo 5%.
• FinOps para a nuvem. O gasto em nuvem muda todo dia e não espera o fechamento do mês. Use showback ou chargeback por área, alertas de anomalia e uma revisão semanal entre TI, financeiro e times de produto. ^[7]
• Rolling forecast trimestral. Reavalie os pacotes abaixo da linha de corte quando surgir folga, e rebaixe os que perderam prioridade. O ranqueamento é uma fila viva, não uma decisão anual.
• Reinvista parte da economia. Se toda economia vira corte no ano seguinte, as áreas aprendem a não economizar. Goldratt resumiu: “Puna as pessoas por suas melhorias e o processo de melhoria contínua vai parar de vez.” Combine antes que uma parte do que for economizado volta para a própria TI, em projetos de transformação.

Indicadores

Armadilhas comuns

• OBZ como corte linear disfarçado. Se o resultado já estava decidido antes dos pacotes, as áreas percebem, e o processo vira teatro.
• Cortar o que não aparece. Segurança, atualização de versões e débito técnico raramente ganham um ranqueamento contra projetos visíveis. O custo volta depois, como incidente ou como projeto emergencial.
• Burocracia demais. Pacotes longos e detalhados para gastos pequenos matam o método. Concentre o esforço nos itens que respondem pela maior parte do gasto.
• Fazer uma vez e esquecer. Sem acompanhamento, o gasto volta ao patamar anterior em um ou dois anos.
• Ranqueamento político. Sem critérios explícitos, vence quem fala mais alto, e não o que gera mais valor.

Conclusões

O orçamento base zero troca a pergunta “quanto a mais?” por “por que, quanto e de que forma?”. Na TI, onde contratos, licenças e recursos de nuvem se acumulam ano após ano sem revisão, essa troca costuma revelar gastos que ninguém escolheria de novo.

O método tem custo: exige conhecer os próprios gastos por serviço, envolver o negócio nas decisões e manter o acompanhamento depois da aprovação. Por isso funciona melhor aplicado com foco, começando pelo OPEX e revisando cada serviço em rodízio, e combinado com um rolling forecast e com práticas de FinOps.

O maior risco é confundir OBZ com cortar custos. Usado assim, ele sacrifica segurança, inovação e débito técnico, e o custo volta mais caro. Usado como deve, ele libera recursos do que só mantém a operação para o que transforma o negócio, e ensina a TI a gastar como dona.

Referências

1. Pyhrr, Peter A., "Zero-Base Budgeting", Harvard Business Review, novembro-dezembro de 1970.
2. Pyhrr, Peter A., Zero-Base Budgeting: A Practical Management Tool for Evaluating Expenses, John Wiley & Sons, 1973.
3. Wikipedia, "Zero-based budgeting", acesso em 24/09/2026, en.wikipedia.org/wiki/Zero-based_budgeting.
4. Carter, Jimmy, "Zero-Base Budgeting", memorando aos dirigentes dos departamentos e agências do Executivo, 14/02/1977, The American Presidency Project.
5. Hope, Jeremy; Fraser, Robin, Beyond Budgeting: How Managers Can Break Free from the Annual Performance Trap, Harvard Business School Press, 2003.
6. TBM Council, TBM Taxonomy, acesso em 24/09/2026, tbmcouncil.org.
7. FinOps Foundation, FinOps Framework, acesso em 24/09/2026, finops.org/framework.
8. Correa, Cristiane, Sonho Grande: como Jorge Paulo Lemann, Marcel Telles e Beto Sicupira revolucionaram o capitalismo brasileiro e conquistaram o mundo, Primeira Pessoa, 2013.

What a budget is

A budget is strategy translated into numbers. It is a financial plan for a period, usually a year, that states how much the organization expects to receive, how much it intends to spend, and on what. When the strategy says “we will grow in digital”, the budget is what shows whether that will actually happen or is just a sentence.

More than a spreadsheet, a budget serves four purposes:

• Plan: it forces you to think ahead about priorities, risks and assumptions, such as exchange rates, contract price adjustments and growth in the number of users.
• Allocate: it distributes a scarce resource among competing uses. Every dollar approved for one thing is no longer available for another.
• Coordinate: it aligns different areas around the same numbers. IT, finance and the business start discussing the same baseline.
• Control: it creates the reference for comparing budget against actuals and acting when the two drift apart.

In IT, the budget is usually split into two large groups:

The move to cloud and SaaS has been shifting IT spending from CAPEX to OPEX. The result is a more flexible budget, but also one that is easier to grow without anyone noticing: one more subscription here, a forgotten virtual machine there.

Types of budget

There is no single way to budget. Each type starts from a different question and fits a different situation:

Some go further and propose dropping the fixed annual budget altogether. The Beyond Budgeting movement, by Jeremy Hope and Robin Fraser, advocates relative targets, continuous forecasts and on-demand resource allocation. ^[5]

In practice, the types are combined. An IT department can use ZBB to review OPEX every two or three years, program budgeting for the project portfolio and a quarterly rolling forecast to track everything.

What zero-based budgeting is and where it came from

Zero-based budgeting (ZBB) is a method in which every expense must be justified from zero in each cycle. The starting point is not last year’s amount: no expense is guaranteed just because it already existed. ^[3]

If this activity did not exist today, would we create it? If so, at what size and in what form?

The method rests on four concepts, defined by Peter Pyhrr ^{[1] [2]}:

• Decision unit: the smallest part of the organization for which it makes sense to budget and decide. It can be a department, a service or a project.
• Decision package: the document that describes what the unit does, why it does it, how much it costs, which alternatives were considered and what happens if it stops.
• Levels of effort: each package is split into layers. The minimum level keeps the activity alive; the following levels add service, quality or reach.
• Ranking: all packages, from all units, are ordered by priority. Resources are allocated from the top down until the money runs out, at the so-called cut-off line.

Origins

1. 1962The United States Department of Agriculture tries to build a budget from zero. The exercise produces a lot of paper and little change, and is dropped.
2. 1969–1970Peter A. Pyhrr, then at Texas Instruments, develops the method for the company’s staff and research divisions and publishes it in the Harvard Business Review. ^[1]
3. 1973Pyhrr publishes the book Zero-Base Budgeting. Jimmy Carter, then governor of Georgia, brings the method to the state budget. ^[2]
4. 1977Now president, Carter orders ZBB across the entire US federal government. ^[4] The volume of paperwork and the agencies’ resistance lead to the method being dropped in the early 1980s.
5. 2010sZBB makes a strong comeback through the Brazilian executives of 3G Capital, who take Ambev’s cost discipline to Burger King, Heinz and Kraft. ^[8]

The story also carries a warning. In 2019, Kraft Heinz took a write-down of about 15 billion dollars on the value of its brands, and some analysts blamed years of cuts that also hit investment in innovation and marketing. ZBB is a tool for spending better, not just for spending less.

Moving from traditional budgeting processes to zero-based budgeting

The difference between the two models is not just in the spreadsheet; it is in the process. In traditional budgeting, history is the baseline and the discussion revolves around the increase. In ZBB, the baseline is reset and the discussion revolves around the value of each activity.

Traditional budgeting

1. Historylast year’s actuals
2. Adjustment+ inflation or growth %
3. Negotiationby ledger account
4. Approvalacross-the-board cut if it does not fit

Zero-based budgeting

1. Decision unitsservices and activities
2. Decision packageslevels and alternatives
3. Rankingwith the business
4. Cut-off lineup to the available limit
5. Trackingbudget × actuals

The hardest change is cultural. In the traditional model, managers learn to defend what they already have: they ask for a bit more knowing there will be cuts, and make sure the budget is fully spent by December, because anything left over becomes a reduction the following year. In ZBB, managers justify what they need, with alternatives and consequences. This requires finance and the business to take part in the decisions, and IT to know its own costs at a level of detail that many departments lack.

How to implement and control it effectively within IT

Implementation step by step

1. Secure sponsorship and define the scope. ZBB needs the CIO and the CFO together. Start with OPEX, where recurring spending piles up without review. Not everything has to go through ZBB every year: a rotation in which each service is reviewed every two or three years reduces the effort.
2. Make costs visible. Build an inventory of contracts, licenses, SaaS subscriptions, cloud resources, staff and third parties. Use a common taxonomy, such as Technology Business Management (TBM), to link each cost to a service. ^[6]
3. Define decision units by service. Organize by what IT delivers, not by the chart of accounts: ERP, collaboration, infrastructure and cloud, service desk, security, data and projects.
4. Build the decision packages. For each unit, describe the objective, the alternatives considered, the minimum, current and incremental levels, the cost of each level and the risk of not doing it. Classify each package as run, grow or transform the business.
5. Rank together with the business. Use explicit criteria: legal obligation, security risk, business value and avoided cost. Business areas must be at the table, because they are the ones who feel what falls below the cut-off line.
6. Turn the ranking into a budget. Approve the packages above the cut-off line and record the assumptions: exchange rates, contract price adjustments by inflation index, user growth and renewal dates.
7. Control and review continuously. ZBB does not end at approval. Monthly tracking and quarterly review keep the budget alive, as the control section below shows.

Example decision package: service desk

Alternatives considered before the levels: keep support in-house, outsource first-level support, or expand self-service with a knowledge base and an AI agent. The chosen alternative was to keep support in-house with more self-service, detailed in three levels:

• Minimum8 analysts, support during business hours, 8-hour resolution time for common incidents.BRL 0.8M/year
• Current10 analysts, support from 7 a.m. to 10 p.m., 4-hour resolution time.+ BRL 0.2M (BRL 1.0M)
• Incremental12 analysts, 24×7 support, 2-hour resolution time.+ BRL 0.3M (BRL 1.3M)

Example ranking and cut-off line

With an available budget of BRL 10.0 million, the packages from all units are ordered and funded from the top down:

The BRL 0.5 million left above the line does not buy all of package 8. Either it is redesigned, for example by refreshing only the oldest laptops, or the amount becomes a reserve. The decision is explicit, with a name and a consequence, instead of an across-the-board 10% cut on every account.

Where to look: levers by cost category

How to control it

• Budget × actuals by decision unit. Track monthly by service, not just by ledger account, and require an explanation for variances above an agreed threshold, for example 5%.
• FinOps for the cloud. Cloud spending changes every day and does not wait for month-end close. Use showback or chargeback by area, anomaly alerts and a weekly review among IT, finance and product teams. ^[7]
• Quarterly rolling forecast. Revisit the packages below the cut-off line when room opens up, and demote those that lost priority. The ranking is a living queue, not an annual decision.
• Reinvest part of the savings. If every saving becomes a cut the following year, departments learn not to save. Goldratt put it this way: “Punish people for their improvements and the process of ongoing improvement comes to a grinding halt.” Agree beforehand that part of what is saved goes back to IT itself, for transformation projects.

Indicators

Common pitfalls

• ZBB as a disguised across-the-board cut. If the outcome was decided before the packages, departments notice, and the process becomes theater.
• Cutting what is not visible. Security, version upgrades and technical debt rarely win a ranking against visible projects. The cost comes back later, as an incident or an emergency project.
• Too much bureaucracy. Long, detailed packages for small expenses kill the method. Focus the effort on the items that account for most of the spending.
• Doing it once and forgetting it. Without tracking, spending returns to its previous level within one or two years.
• Political ranking. Without explicit criteria, whoever speaks loudest wins, not what creates the most value.

Conclusions

Zero-based budgeting replaces the question “how much more?” with “why, how much and in what form?”. In IT, where contracts, licenses and cloud resources pile up year after year without review, this shift usually reveals spending that nobody would choose again.

The method has a cost: it requires knowing your own spending by service, involving the business in decisions and keeping up the tracking after approval. That is why it works best when applied with focus, starting with OPEX and reviewing each service in rotation, and combined with a rolling forecast and FinOps practices.

The biggest risk is confusing ZBB with cost cutting. Used that way, it sacrifices security, innovation and technical debt, and the cost comes back higher. Used as intended, it frees resources from what merely keeps operations running for what transforms the business, and teaches IT to spend like an owner.

References

1. Pyhrr, Peter A., "Zero-Base Budgeting", Harvard Business Review, November-December 1970.
2. Pyhrr, Peter A., Zero-Base Budgeting: A Practical Management Tool for Evaluating Expenses, John Wiley & Sons, 1973.
3. Wikipedia, "Zero-based budgeting", accessed 24/09/2026, en.wikipedia.org/wiki/Zero-based_budgeting.
4. Carter, Jimmy, "Zero-Base Budgeting", memorandum for the heads of executive departments and agencies, 14/02/1977, The American Presidency Project.
5. Hope, Jeremy; Fraser, Robin, Beyond Budgeting: How Managers Can Break Free from the Annual Performance Trap, Harvard Business School Press, 2003.
6. TBM Council, TBM Taxonomy, accessed 24/09/2026, tbmcouncil.org.
7. FinOps Foundation, FinOps Framework, accessed 24/09/2026, finops.org/framework.
8. Correa, Cristiane, Sonho Grande (Dream Big), Primeira Pessoa, 2013.

Che cos’è il budget

Il budget è la strategia tradotta in numeri. È un piano finanziario per un periodo, di solito un anno, che indica quanto l’organizzazione prevede di incassare, quanto intende spendere e per che cosa. Quando la strategia dice “cresceremo nel digitale”, è il budget a mostrare se accadrà davvero o se è solo una frase.

Più che un foglio di calcolo, il budget svolge quattro funzioni:

• Pianificare: obbliga a pensare in anticipo a priorità, rischi e ipotesi, come il cambio, l’adeguamento dei contratti e la crescita del numero di utenti.
• Allocare: distribuisce una risorsa scarsa tra usi in competizione. Ogni euro approvato per una cosa non è più disponibile per un’altra.
• Coordinare: allinea aree diverse attorno agli stessi numeri. IT, finanza e business discutono sulla stessa base.
• Controllare: crea il riferimento per confrontare budget e consuntivo e intervenire quando i due si allontanano.

Nell’IT, il budget si divide di solito in due grandi gruppi:

La migrazione verso cloud e SaaS sta spostando la spesa IT dal CAPEX all’OPEX. Il risultato è un budget più flessibile, ma anche più facile da far crescere senza che nessuno se ne accorga: un abbonamento in più qui, una macchina virtuale dimenticata là.

Tipi di budget

Non esiste un unico modo di fare il budget. Ogni tipo parte da una domanda diversa e si adatta meglio a una situazione diversa:

C’è anche chi propone di abbandonare il budget annuale fisso. Il movimento Beyond Budgeting, di Jeremy Hope e Robin Fraser, sostiene obiettivi relativi, previsioni continue e allocazione delle risorse su richiesta. ^[5]

In pratica, i tipi si combinano. Una funzione IT può usare lo ZBB per rivedere l’OPEX ogni due o tre anni, il budget per programmi per il portafoglio progetti e un rolling forecast trimestrale per seguire tutto.

Che cos’è il budget a base zero e le sue origini

Il budget a base zero (zero-based budgeting, ZBB) è un metodo in cui ogni spesa deve essere giustificata partendo da zero a ogni ciclo. Il punto di partenza non è l’importo dell’anno precedente: nessuna spesa è garantita solo perché esisteva già. ^[3]

Se questa attività non esistesse oggi, la creeremmo? Se sì, di che dimensione e in che forma?

Il metodo si basa su quattro concetti, definiti da Peter Pyhrr ^{[1] [2]}:

• Unità decisionale: la parte più piccola dell’organizzazione per cui ha senso fare il budget e decidere. Può essere un reparto, un servizio o un progetto.
• Pacchetto decisionale: il documento che descrive che cosa fa l’unità, perché lo fa, quanto costa, quali alternative sono state valutate e che cosa succede se smette di farlo.
• Livelli di impegno: ogni pacchetto è diviso in strati. Il livello minimo mantiene in vita l’attività; i livelli successivi aggiungono servizio, qualità o copertura.
• Classifica: tutti i pacchetti, di tutte le unità, vengono ordinati per priorità. Le risorse vengono assegnate dall’alto verso il basso finché finiscono i soldi, alla cosiddetta linea di taglio.

Origini

1. 1962Il Dipartimento dell’Agricoltura degli Stati Uniti prova a costruire un budget partendo da zero. L’esperimento produce molta carta e poco cambiamento, e viene abbandonato.
2. 1969–1970Peter A. Pyhrr, allora alla Texas Instruments, sviluppa il metodo per le funzioni di supporto e di ricerca dell’azienda e lo pubblica sulla Harvard Business Review. ^[1]
3. 1973Pyhrr pubblica il libro Zero-Base Budgeting. Jimmy Carter, governatore della Georgia, porta il metodo nel bilancio dello stato. ^[2]
4. 1977Divenuto presidente, Carter impone lo ZBB in tutto il governo federale americano. ^[4] La mole di documenti e la resistenza delle agenzie portano all’abbandono del metodo all’inizio degli anni Ottanta.
5. Anni 2010Lo ZBB torna con forza grazie ai manager brasiliani di 3G Capital, che portano la disciplina dei costi di Ambev in Burger King, Heinz e Kraft. ^[8]

La storia contiene anche un avvertimento. Nel 2019 Kraft Heinz ha registrato una svalutazione di circa 15 miliardi di dollari sul valore dei suoi marchi, e parte degli analisti ha attribuito il problema ad anni di tagli che avevano colpito anche gli investimenti in innovazione e marketing. Lo ZBB è uno strumento per spendere meglio, non solo per spendere meno.

Il passaggio dai processi di budget tradizionali al budget a base zero

La differenza tra i due modelli non sta solo nel foglio di calcolo, ma nel processo. Nel budget tradizionale, lo storico è la base e la discussione ruota attorno all’incremento. Nello ZBB, la base viene azzerata e la discussione ruota attorno al valore di ogni attività.

Budget tradizionale

1. Storicoconsuntivo dell’anno precedente
2. Adeguamento+ inflazione o % di crescita
3. Negoziazioneper conto contabile
4. Approvazionetaglio lineare se non rientra

Budget a base zero

1. Unità decisionaliservizi e attività
2. Pacchetti decisionalilivelli e alternative
3. Classificacon il business
4. Linea di tagliofino al limite disponibile
5. Monitoraggiobudget × consuntivo

Il cambiamento più difficile è culturale. Nel modello tradizionale, il manager impara a difendere ciò che ha già: chiede un po’ di più sapendo che ci saranno tagli, e si assicura che il budget venga speso tutto entro dicembre, perché ciò che avanza diventa una riduzione l’anno successivo. Nello ZBB, il manager giustifica ciò di cui ha bisogno, con alternative e conseguenze. Questo richiede che finanza e business partecipino alle decisioni, e che l’IT conosca i propri costi con un livello di dettaglio che molte funzioni non hanno.

Come implementarlo e controllarlo in modo efficace all’interno dell’IT

Implementazione passo per passo

1. Ottenere la sponsorizzazione e definire il perimetro. Lo ZBB ha bisogno di CIO e CFO insieme. Si parte dall’OPEX, dove la spesa ricorrente si accumula senza revisione. Non serve far passare tutto dallo ZBB ogni anno: una rotazione in cui ogni servizio viene rivisto ogni due o tre anni riduce lo sforzo.
2. Rendere visibili i costi. Costruire l’inventario di contratti, licenze, abbonamenti SaaS, risorse cloud, persone e fornitori. Usare una tassonomia comune, come quella del Technology Business Management (TBM), per collegare ogni costo a un servizio. ^[6]
3. Definire le unità decisionali per servizio. Organizzare in base a ciò che l’IT fornisce, non al piano dei conti: ERP, collaborazione, infrastruttura e cloud, service desk, sicurezza, dati e progetti.
4. Costruire i pacchetti decisionali. Per ogni unità, descrivere l’obiettivo, le alternative valutate, i livelli minimo, attuale e incrementale, il costo di ogni livello e il rischio di non farlo. Classificare ogni pacchetto come mantenere, far crescere o trasformare il business.
5. Stilare la classifica insieme al business. Usare criteri espliciti: obbligo di legge, rischio di sicurezza, valore per il business e costo evitato. Le aree di business devono sedere al tavolo, perché sono loro a sentire ciò che resta sotto la linea di taglio.
6. Trasformare la classifica in budget. Approvare i pacchetti sopra la linea di taglio e registrare le ipotesi: cambio, adeguamento dei contratti all’inflazione, crescita degli utenti e date di rinnovo.
7. Controllare e rivedere di continuo. Lo ZBB non finisce con l’approvazione. Il monitoraggio mensile e la revisione trimestrale mantengono vivo il budget, come mostra la sezione sul controllo qui sotto.

Esempio di pacchetto decisionale: service desk

Alternative valutate prima dei livelli: mantenere il supporto interno, esternalizzare il primo livello, oppure ampliare il self-service con una base di conoscenza e un agente di IA. L’alternativa scelta è stata mantenere il supporto interno con più self-service, dettagliata in tre livelli:

• Minimo8 analisti, supporto in orario d’ufficio, tempo di risoluzione di 8 ore per gli incidenti comuni.0,8 mln R$/anno
• Attuale10 analisti, supporto dalle 7 alle 22, tempo di risoluzione di 4 ore.+ 0,2 mln R$ (1,0 mln R$)
• Incrementale12 analisti, supporto 24×7, tempo di risoluzione di 2 ore.+ 0,3 mln R$ (1,3 mln R$)

Esempio di classifica e linea di taglio

Con un budget disponibile di 10,0 milioni di reais, i pacchetti di tutte le unità vengono ordinati e finanziati dall’alto verso il basso:

Gli 0,5 milioni che avanzano sopra la linea non bastano per l’intero pacchetto 8. O lo si ridisegna, per esempio rinnovando solo i portatili più vecchi, oppure l’importo diventa una riserva. La decisione è esplicita, con un nome e una conseguenza, invece di un taglio lineare del 10% su tutti i conti.

Dove cercare: leve per categoria di costo

Come controllarlo

• Budget × consuntivo per unità decisionale. Monitorare mensilmente per servizio, non solo per conto contabile, e chiedere una spiegazione per gli scostamenti oltre una soglia concordata, per esempio il 5%.
• FinOps per il cloud. La spesa cloud cambia ogni giorno e non aspetta la chiusura del mese. Usare showback o chargeback per area, avvisi sulle anomalie e una revisione settimanale tra IT, finanza e team di prodotto. ^[7]
• Rolling forecast trimestrale. Rivalutare i pacchetti sotto la linea di taglio quando si libera spazio, e retrocedere quelli che hanno perso priorità. La classifica è una coda viva, non una decisione annuale.
• Reinvestire parte dei risparmi. Se ogni risparmio diventa un taglio l’anno successivo, le funzioni imparano a non risparmiare. Goldratt lo ha riassunto così: “Punisci le persone per i loro miglioramenti e il processo di miglioramento continuo si arresterà del tutto.” Concordare prima che una parte di ciò che si risparmia torni all’IT stessa, per progetti di trasformazione.

Indicatori

Trappole comuni

• ZBB come taglio lineare mascherato. Se il risultato era deciso prima dei pacchetti, le funzioni se ne accorgono, e il processo diventa teatro.
• Tagliare ciò che non si vede. Sicurezza, aggiornamenti di versione e debito tecnico raramente vincono in classifica contro progetti visibili. Il costo ritorna dopo, come incidente o come progetto d’emergenza.
• Troppa burocrazia. Pacchetti lunghi e dettagliati per spese piccole uccidono il metodo. Concentrare lo sforzo sulle voci che rappresentano la maggior parte della spesa.
• Farlo una volta e dimenticarlo. Senza monitoraggio, la spesa torna al livello precedente in uno o due anni.
• Classifica politica. Senza criteri espliciti vince chi parla più forte, non ciò che genera più valore.

Conclusioni

Il budget a base zero sostituisce la domanda “quanto in più?” con “perché, quanto e in che forma?”. Nell’IT, dove contratti, licenze e risorse cloud si accumulano anno dopo anno senza revisione, questo cambio di prospettiva di solito rivela spese che nessuno sceglierebbe di nuovo.

Il metodo ha un costo: richiede di conoscere la propria spesa per servizio, coinvolgere il business nelle decisioni e mantenere il monitoraggio dopo l’approvazione. Per questo funziona meglio se applicato con focus, partendo dall’OPEX e rivedendo ogni servizio a rotazione, e combinato con un rolling forecast e con pratiche FinOps.

Il rischio maggiore è confondere lo ZBB con il taglio dei costi. Usato così, sacrifica sicurezza, innovazione e debito tecnico, e il costo ritorna più alto. Usato come si deve, libera risorse da ciò che si limita a mantenere l’operatività verso ciò che trasforma il business, e insegna all’IT a spendere da proprietaria.

Riferimenti

1. Pyhrr, Peter A., "Zero-Base Budgeting", Harvard Business Review, novembre-dicembre 1970.
2. Pyhrr, Peter A., Zero-Base Budgeting: A Practical Management Tool for Evaluating Expenses, John Wiley & Sons, 1973.
3. Wikipedia, "Zero-based budgeting", consultato il 24/09/2026, en.wikipedia.org/wiki/Zero-based_budgeting.
4. Carter, Jimmy, "Zero-Base Budgeting", memorandum ai responsabili dei dipartimenti e delle agenzie dell’esecutivo, 14/02/1977, The American Presidency Project.
5. Hope, Jeremy; Fraser, Robin, Beyond Budgeting: How Managers Can Break Free from the Annual Performance Trap, Harvard Business School Press, 2003.
6. TBM Council, TBM Taxonomy, consultato il 24/09/2026, tbmcouncil.org.
7. FinOps Foundation, FinOps Framework, consultato il 24/09/2026, finops.org/framework.
8. Correa, Cristiane, Sonho Grande, Primeira Pessoa, 2013.