Business case de TI: como justificar investimento ao sócio não técnico

Para aprovar um investimento em TI, traduza o problema técnico em dinheiro, tempo ou risco, com número e premissa explícita. É isso que um sócio não técnico consegue comparar com os outros gastos que já avalia. Quem apresenta latência, arquitetura ou débito técnico recebe “depois a gente vê”.

O sócio raramente resiste a tecnologia. A justificativa chegou na língua errada. Este texto mostra como montar o business case, o que evitar e como usar fontes para o risco.

O que é um business case de TI?

É um documento curto que pede uma decisão e mostra por que ela compensa. Ele responde quatro perguntas:

• Qual é o problema, em uma frase sem jargão?
• Quanto custa manter como está?
• Quanto custa resolver, e o que muda depois?
• O que acontece, e com que chance, se nada mudar?

Uma página basta. Se o sócio precisa de um glossário para ler, o documento falhou.

Quais são as três moedas que um sócio não técnico entende?

Decisão de negócio usa dinheiro, tempo e risco. Escolha ao menos uma e traduza o problema para ela.

Dinheiro. Compare o custo de manter a situação atual com o custo de resolver. Inclua o que não aparece na fatura: retrabalho de gente qualificada, sistema fora do ar, penalidade evitável.

Tempo. Meça quanto tempo da equipe, ou do próprio sócio, o problema consome. Diga o que esse tempo liberado permitiria fazer no lugar.

Risco. Descreva o que acontece se nada mudar: perda de dado, queda em momento crítico, vazamento, cliente perdido por falha evitável. Risco bem apresentado é dado de decisão, não ameaça.

Como transformar “precisamos modernizar” em um pedido aprovável?

Troque a afirmação técnica por uma conta com premissa.

Pedido fraco: “Precisamos modernizar esse sistema.”

Pedido forte: “O processo atual consome X horas por semana da equipe de atendimento em retrabalho. Ao custo de Y por hora, isso soma Z por ano, se o volume se mantiver.”

Os números X e Y vêm da sua operação. Meça antes de escrever. A segunda versão permite comparação direta com qualquer outro investimento que o sócio avalia.

Não exija precisão perfeita. Exija premissa visível. Use este molde:

1. Com base em [dado disponível],
2. a estimativa é [número],
3. considerando [premissa].

Se o sócio discordar da premissa, a conversa muda para a premissa, e não para o jargão. Isso já é progresso.

Como apresentar risco de TI sem parecer alarmismo?

Separe probabilidade de impacto e ancore cada uma em referência concreta. “Isso pode ser desastroso” não convence ninguém, porque todo pedido de investimento vem com algum alarme.

Boas âncoras, em ordem de força:

• Incidente da própria empresa. Um sistema que já caiu, um acesso que já vazou, um backup que nunca foi restaurado.
• Dado de fonte primária. Pesquisa reconhecida ou lei, com nome, ano e recorte.
• Quase acidente. Um problema que a empresa viu de perto e não tratou como sinal.

Dois exemplos de fonte primária que um business case brasileiro pode usar:

Ransomware em empresas menores. O Verizon Data Breach Investigations Report de 2025 registra ransomware em 88% das violações de dados ocorridas em pequenas e médias empresas, contra 39% nas grandes. O recorte importa: é a parcela das violações analisadas que envolveu ransomware, e não a parcela das empresas atingidas. Fonte: Verizon, DBIR 2025.

Sanção da LGPD. A Lei Geral de Proteção de Dados prevê multa simples de até 2% do faturamento da empresa, limitada, no total, a R$ 50 milhões por infração. A multa é um dos instrumentos de sanção; o texto também prevê advertência. Fonte: ANPD, regulamento de dosimetria e a Lei 13.709/2018, art. 52.

Use esses dados como contexto, não como previsão para a sua empresa. Eles mostram que o tipo de risco existe. A probabilidade para o seu caso depende dos seus controles, e o business case deve dizer isso.

Como calcular o custo de manter como está?

Comece pelo que já existe na operação e some em três linhas:

• Horas perdidas. Quantas horas por semana a equipe gasta em retrabalho, contorno manual ou espera por sistema. Multiplique pelo custo da hora e por 52.
• Interrupções. Quantas vezes o problema parou a operação no último ano, por quanto tempo e o que deixou de ser vendido ou entregue naquele período.
• Dependência de uma pessoa. O que para se essa pessoa sair, ficar doente ou ficar indisponível. Descreva o impacto sem dramatizar.

Não invente a conta. Se faltar dado, diga qual dado falta e como você vai obtê-lo. Um business case que admite o limite do que sabe ganha credibilidade, e o sócio entende que o número pode ser revisado.

Quais erros derrubam um business case de TI?

• Começar pela ferramenta. “Precisamos de tal plataforma” é solução. Comece pelo problema.
• Pedir tudo de uma vez. Divida em etapas com decisão em cada uma. Isso reduz o risco para quem aprova.
• Misturar fato e opinião. Marque o que foi medido, o que foi relatado e o que é estimativa.
• Prometer retorno garantido. Nenhum investimento em tecnologia elimina o risco. Mostre o que muda e o que continua exposto.
• Esconder o custo recorrente. Licença, suporte e manutenção entram na conta desde o início.

O que o sócio quer ver antes de assinar?

Quatro coisas, nesta ordem:

1. A decisão pedida. Aprovar o quê, até quando, com qual responsável.
2. O custo de não decidir. Em dinheiro, tempo ou risco, com premissa.
3. As alternativas. Pelo menos duas além de “não fazer nada”: por exemplo, resolver parcialmente ou adiar com data marcada.
4. O critério de sucesso. Como todos vão saber, em 90 dias, se funcionou.

Alternativas dão ao sócio algo que ele valoriza: escolha. Um pedido com uma única saída parece pressão.

Quando apresentar o business case de TI?

Antes do incidente. O business case mais fraco é o que chega depois do dano: deixa de ser prevenção e vira justificativa de algo que já aconteceu. A decisão passa a ser reativa por definição.

Apresentado com o problema ainda hipotético, o mesmo pedido custa menos e a conversa gira em torno de opções, não de culpa. Por isso vale ter alguém que olhe tecnologia de forma contínua, com mandato para trazer o assunto antes que ele vire urgência.

Quem deve escrever o business case quando não há líder de TI?

Quem tem mandato para decidir sobre tecnologia e acesso aos fatos. Em empresa média, esse papel costuma ficar espalhado: o desenvolvedor sabe do sistema, o financeiro sabe do orçamento, o sócio decide, e ninguém junta os três.

Esse vazio é o que a Direção de Tecnologia da AleffTech ocupa. Ela funciona como um Head de TI terceirizado. Cuida de riscos, prioridades, custos, roadmap, fornecedores e decisões, e delega a execução. O sócio recebe o pedido já traduzido em dinheiro, tempo e risco, com premissas visíveis e alternativas, e decide com clareza.

Depois da contratação, o onboarding inclui um diagnóstico executivo, que levanta os fatos necessários para priorizar. Ele faz parte da Direção; não é um serviço à parte.

Se hoje o seu investimento em TI parece óbvio para quem vê por dentro e difícil de aprovar para quem decide o orçamento, o gargalo está na tradução, não na vontade. Converse com a AleffTech sobre a Direção de Tecnologia e veja se o modelo tem fit com a sua empresa.

Checklist final antes de levar ao sócio

• O problema cabe em uma frase sem jargão?
• Há ao menos uma moeda (dinheiro, tempo ou risco) com número?
• Toda estimativa mostra a premissa?
• O risco separa probabilidade de impacto?
• Todo dado externo tem fonte primária, nome e ano?
• Existem duas alternativas além de não agir?
• A decisão pedida tem responsável e prazo?
• Você mediu os números de entrada, em vez de supor?