Quem trabalha com tecnologia em empresas de médio e grande porte conhece a cena: a diretoria pergunta por que o orçamento de TI cresce ano após ano sem que a entrega acompanhe, enquanto o time interno acumula chamados, projetos atrasados e lacunas de segurança que ninguém consegue fechar sozinho. Montar um business case para serviços gerenciados de TI é a forma de tirar essa conversa do campo da percepção e levá-la para o terreno dos números — custo real do modelo atual, risco quantificado e critérios objetivos de decisão.
Este guia foi escrito para decisores de tecnologia que precisam defender internamente a migração para um MSP diante de um CFO cético e de uma diretoria que só aprova verba com evidência. Em vez de passos genéricos de manual, o texto percorre o que costuma faltar nas propostas: o cálculo do TCO interno com turnover e horas não faturáveis, os gatilhos concretos que justificam a mudança, a comparação estruturada entre operação interna, modelo híbrido e provedor dedicado, e os KPIs contratuais — SLA, MTTR, disponibilidade — que transformam promessa em cláusula mensurável.
Também trata da aderência à LGPD e à ISO 27001 como argumento de risco e de custo, e traz um roteiro para responder às objeções mais comuns na hora da apresentação. Nenhum documento sério promete imunidade a ataques ou vazamentos; o que se busca aqui é reduzir probabilidade, encurtar tempo de resposta e tornar a conformidade demonstrável.
O que é um business case para serviços gerenciados de TI (e o que ele não é)
Um business case para serviços gerenciados de TI é um documento estruturado que quantifica, em termos financeiros e operacionais, a justificativa para migrar parte ou toda a operação de tecnologia de um modelo interno para um provedor especializado. Ele parte de uma premissa simples: a diretoria não aprova verba com base em percepção técnica, mas em evidência de retorno, redução de risco e alinhamento estratégico. O documento precisa responder a três perguntas centrais — quanto custa manter o modelo atual, quanto custa migrar para um MSP e qual o impacto dessa mudança em prazos, riscos e capacidade de entrega.
O que ele não é: um business case não é um pedido de cotação disfarçado, um relatório técnico de vulnerabilidades ou uma lista de reclamações sobre o time interno. Também não é uma promessa de que o provedor resolverá todos os problemas. Em ambientes que lidam com dados sensíveis — instituições financeiras, processadoras de Pix, operadoras de saúde —, nenhum documento sério deve prometer proteção absoluta contra ataques ou vazamentos. O business case correto trabalha com redução de probabilidade, encurtamento de tempo de resposta e conformidade demonstrável, nunca com garantia de imunidade.
Quando faz sentido abrir um business case de MSP: os cinco gatilhos mais comuns
Decisores raramente acordam um dia decididos a terceirizar a TI. O movimento quase sempre nasce de um evento concreto que expõe a fragilidade do modelo atual. Identificar o gatilho correto é o primeiro passo para dimensionar o escopo do business case e escolher as métricas que vão sustentá-lo. Os cinco gatilhos mais recorrentes em empresas de médio e grande porte se agrupam em três categorias: custo, risco e capacidade.
Gatilhos de custo: custo oculto do modelo interno
O gatilho de custo aparece quando a folha de TI cresce sem que a entrega acompanhe. O orçamento anual de tecnologia sobe, mas os projetos atrasam, o backlog de chamados aumenta e a diretoria começa a questionar o retorno. O problema é que a maior parte do custo do modelo interno não está na planilha óbvia: está em horas não faturáveis, retrabalho, ferramentas subutilizadas e na diferença entre o salário nominal e o custo efetivo de um especialista sênior no mercado brasileiro.
Se o time precisa cobrir Azure, Microsoft 365, segurança e monitoramento 24x7, a conta raramente fecha com dois ou três profissionais generalistas. O business case de custo nasce quando o CFO percebe que o custo por chamado resolvido ou por servidor gerenciado está subindo sem ganho proporcional de qualidade.
Gatilhos de risco: lacunas de segurança, compliance e continuidade
O gatilho de risco é o mais urgente e o mais difícil de ignorar. Ele surge quando uma auditoria aponta não conformidade com a LGPD, quando um cliente exige evidências de controles que a empresa não consegue apresentar ou quando um incidente — ransomware, vazamento, indisponibilidade de um serviço crítico — quase interrompe a operação. Em setores regulados, como o financeiro, a ausência de um processo formal de gestão de vulnerabilidades ou de um plano testado de recuperação de desastres pode inviabilizar contratos e parcerias.
Nesse cenário, o business case deixa de ser apenas sobre dinheiro e passa a ser sobre continuidade do negócio. A pergunta que sustenta o documento é: quanto custa um dia de indisponibilidade do ambiente que processa transações? O documento deve quantificar esse custo e compará-lo ao investimento em monitoramento proativo, gestão de patches e resposta a incidentes.
Gatilhos de capacidade: falta de especialistas e rotatividade do time
O terceiro gatilho é estrutural: a empresa não consegue contratar nem reter os especialistas de que precisa. Profissionais com certificação Microsoft em arquitetura Azure, segurança e identidade são escassos e disputados. Quando um colaborador-chave pede demissão, o conhecimento do ambiente sai pela porta — e a reposição pode levar de três a seis meses, quando acontece. A rotatividade elevada transforma a TI interna em um ciclo permanente de treinamento e perda de conhecimento.
Um MSP com equipe certificada dilui esse risco: o conhecimento fica no contrato, não em uma pessoa. O business case de capacidade quantifica o custo de cada saída (recrutamento, onboarding, queda de produtividade) e o risco de posições críticas descobertas. Ele também considera a cobertura de especialidades que uma operação interna dificilmente sustenta sozinha: segurança ofensiva, FinOps, governança de identidade e conformidade com normas como a ISO 27001.
Como calcular o custo real do modelo atual (TCO interno)
O coração de qualquer business case de MSP é o cálculo do TCO (custo total de propriedade) do modelo interno. A maioria das empresas subestima esse número porque olha apenas para a folha de pagamento. O TCO correto soma três camadas: pessoas, ferramentas e o custo invisível da indisponibilidade. Sem esse cálculo, a comparação com a proposta do MSP fica injusta — compara-se o custo aparente do interno com o custo total do terceirizado.
Salários, encargos, turnover e horas não faturáveis
A primeira camada começa no salário bruto, mas não termina nele. Encargos trabalhistas no Brasil adicionam, em média, entre 60% e 80% sobre o salário. Benefícios, bônus, plano de saúde e treinamento elevam ainda mais o custo. A isso se soma o turnover: cada substituição custa entre 50% e 150% do salário anual do profissional, considerando recrutamento, entrevistas, onboarding e a curva de aprendizado até o novo colaborador atingir produtividade plena.
As horas não faturáveis são o componente mais negligenciado. Um time interno não dedica 100% do tempo a atividades de alto valor: parte significativa é consumida por tarefas repetitivas, reuniões, documentação e apagamento de incêndios. Se um analista sênior passa 30% do tempo em atividades operacionais que poderiam ser automatizadas ou delegadas, esse percentual é custo puro. O business case deve estimar, com base em relatórios de chamados e timesheets, quantas horas mensais são perdidas em trabalho de baixo valor.
Ferramentas, licenças, treinamento e infraestrutura
A segunda camada do TCO inclui tudo o que a empresa paga para manter a operação de pé: licenças de monitoramento, antivírus, backup, firewall, ferramentas de gestão de chamados e plataformas de segurança. Muitas dessas licenças são subutilizadas — compradas em um momento de urgência e abandonadas depois. O business case deve inventariar cada ferramenta, seu custo mensal e sua taxa real de uso.
Treinamento também entra aqui: manter certificações Microsoft atualizadas exige investimento contínuo em cursos e exames, que expiram e precisam ser renovados. Infraestrutura física — servidores, storages, links redundantes, energia — adiciona depreciação, manutenção e atualização tecnológica. Um MSP dilui parte desses custos em sua base de clientes, transformando despesas fixas em variáveis. O documento precisa mostrar essa diferença de estrutura de custos com clareza.
Custo da indisponibilidade e do retrabalho
A terceira camada é a que mais pesa em setores que dependem de transações digitais. O custo da indisponibilidade pode ser calculado de forma simples: receita média por hora multiplicada pelas horas de parada, somada a multas contratuais, danos reputacionais e horas extras da equipe para recuperar o ambiente. Uma empresa que processa R$ 500 mil por hora em transações e fica quatro horas fora do ar não perde apenas R$ 2 milhões em receita — perde também a confiança de clientes e parceiros.
O retrabalho é o primo silencioso da indisponibilidade. Cada correção mal feita, cada patch aplicado às pressas, cada configuração improvisada gera trabalho futuro. O business case deve estimar esse percentual com base no histórico de chamados reincidentes e incidentes repetidos.
Comparando cenários: interno, híbrido e MSP dedicado
Um business case sólido não apresenta apenas duas opções — interno versus terceirizado. Ele compara pelo menos três cenários, porque a diretoria precisa entender o espectro de decisão. O cenário interno mantém a operação como está, com seus custos e riscos conhecidos. O cenário híbrido terceiriza apenas camadas específicas — monitoramento, service desk ou segurança — mantendo a arquitetura e a estratégia sob controle interno. O cenário MSP dedicado transfere a operação completa para um provedor, com SLAs contratuais e responsabilidade definida.
A comparação deve usar a mesma régua para os três cenários:
- Interno: custo fixo alto, flexibilidade de mudança baixa, cobertura limitada ao horário comercial, risco concentrado em pessoas-chave.
- Híbrido: custo intermediário, terceirização de picos e especialidades, exige governança madura para coordenar provedor e time interno.
- MSP dedicado: custo previsível em contrato, cobertura 24x7, SLAs mensuráveis, risco diluído em equipe multidisciplinar.
Para operações que dependem de conformidade estrita — como ambientes financeiros e processadores de Pix —, o MSP dedicado tende a se justificar mais rápido, porque a responsabilidade sobre controles e evidências fica contratualmente definida. O business case precisa recomendar um cenário, mas apresentar os três com números honestos.
Métricas e KPIs que sustentam o business case
Números financeiros sozinhos não convencem uma diretoria técnica. O business case precisa ancorar a decisão em KPIs operacionais que transformem promessas do MSP em obrigações contratuais mensuráveis. Esses indicadores servem a dois propósitos: justificar o investimento no momento da aprovação e criar a régua de cobrança depois que o contrato estiver ativo. Sem KPIs definidos, o business case vira um documento de intenções.
SLAs, MTTR, disponibilidade e tempo de resposta
Os SLAs (acordos de nível de serviço) são a espinha dorsal de qualquer contrato de MSP. Eles definem, em números, o que o provedor se compromete a entregar: disponibilidade de 99,5% ou 99,9%, tempo de resposta para chamados críticos, prazo de resolução por severidade. O MTTR (tempo médio para reparo) é um dos indicadores mais reveladores: mede quanto tempo, em média, o ambiente fica degradado após um incidente. Uma operação interna sem processos maduros costuma apresentar MTTR muito superior ao de um MSP com runbooks e automação.
O business case deve comparar o desempenho atual com o SLA proposto. Se o MTTR interno para incidentes críticos é de 8 horas e o MSP oferece 2 horas, a diferença se traduz diretamente em menos tempo de indisponibilidade e menos perda financeira. O mesmo vale para tempo de resposta: um service desk gerenciado com atendimento 24x7 muda a experiência do usuário final, que deixa de esperar o horário comercial para ter seu problema tratado. Para detalhes sobre o que esperar de um service desk terceirizado, vale consultar o que inclui o serviço.
Indicadores de segurança e conformidade (LGPD, ISO 27001)
Segurança é difícil de quantificar, mas não impossível. O business case pode usar indicadores como tempo médio para aplicação de patches críticos, percentual de ativos com endpoint protection atualizado, número de vulnerabilidades abertas por severidade e tempo de detecção de ameaças. Esses números, quando comparados a benchmarks de mercado, mostram se a operação atual está acima ou abaixo do aceitável para o setor.
A conformidade adiciona outra camada: a LGPD exige que a empresa demonstre controles adequados sobre dados pessoais, e normas como a ISO 27001 exigem um sistema de gestão de segurança documentado e auditável. Um MSP com processos maduros entrega evidências prontas para auditorias — logs centralizados, políticas de acesso, relatórios de gestão de vulnerabilidades. O business case deve quantificar o custo de produzir essas evidências internamente versus recebê-las como parte do contrato.
Produtividade do usuário final e experiência do colaborador
O impacto da TI na produtividade do usuário final é o KPI mais subestimado dos business cases. Cada hora que um colaborador fica sem acesso a e-mail, sistemas ou arquivos é uma hora de trabalho perdida — e esse custo se multiplica pelo número de funcionários afetados. Se 200 colaboradores perdem 30 minutos por semana com problemas de TI, são 100 horas semanais de produtividade evaporada, o equivalente a mais de dois funcionários em tempo integral.
A experiência do colaborador também afeta retenção: empresas com TI lenta e burocrática enfrentam mais reclamações internas e mais pressão por ferramentas alternativas — o chamado shadow IT, que cria riscos de segurança invisíveis. O business case pode incluir uma pesquisa interna de satisfação com a TI atual e projetar o ganho com tempos de resposta menores e resolução no primeiro contato. O SSO (single sign-on), por exemplo, reduz fricção de login e chamados de reset de senha — um ganho mensurável em produtividade e segurança.
Análise financeira: ROI, payback e TCO
A análise financeira é onde o business case ganha ou perde a aprovação. Três indicadores são essenciais: TCO comparado em um horizonte de três anos, ROI (retorno sobre o investimento) e payback (tempo para recuperar o investimento inicial). O horizonte de três anos captura custos de transição, estabilização do serviço e ganhos recorrentes, sem se estender demais em premissas incertas.
O cálculo começa com o TCO interno projetado para três anos: salários e encargos com reajustes, custos de turnover esperado, licenças, treinamento, infraestrutura e o custo estimado de indisponibilidade baseado no histórico. Em seguida, projeta-se o custo do MSP para o mesmo período: mensalidade do contrato, custos de transição e onboarding, e eventuais serviços adicionais. A diferença entre os dois cenários é o benefício financeiro bruto.
O ROI é calculado dividindo o benefício líquido (economia gerada menos custo do MSP) pelo investimento total. Um business case realista raramente promete ROI de 300% no primeiro ano: a transição tem custos, e o ganho se acumula a partir do segundo ano. Empresas com custo oculto alto — muito retrabalho, cobertura limitada, rotatividade elevada — tendem a ter payback mais curto.
Um ponto frequentemente ignorado: a análise deve incluir o custo de não fazer nada. Manter o modelo atual não é gratuito — é uma decisão que carrega os custos e riscos identificados no TCO. O business case precisa deixar explícito que o status quo tem um preço, e que esse preço tende a crescer com o aumento da complexidade do ambiente e das exigências regulatórias.
Riscos, premissas e plano de mitigação do business case
Nenhum business case sobrevive a uma diretoria experiente sem uma seção honesta de riscos e premissas. Omitir riscos não os elimina — apenas transfere a descoberta para o momento da implementação, quando o estrago é maior. A seção de riscos demonstra maturidade do proponente e antecipa objeções que, de outra forma, surgiriam na reunião de aprovação.
Os riscos mais comuns em uma migração para MSP incluem:
- Transição mal planejada: perda de conhecimento durante a transferência de responsabilidades; mitigação com onboarding estruturado e documentação obrigatória.
- Dependência do provedor (lock-in): dificuldade de trocar de MSP no futuro; mitigação com cláusulas de saída, propriedade dos dados e documentação completa do ambiente.
- Expectativas desalinhadas: a diretoria espera redução imediata de custos, mas o primeiro ano tem despesas de transição; mitigação com comunicação clara do cronograma financeiro.
- Resistência interna: o time atual teme pela própria posição; mitigação com plano de realocação, requalificação ou transição gradual.
- Premissas otimistas demais: SLAs irrealistas ou economia superestimada; mitigação com cenários conservador, base e otimista.
As premissas precisam ser explícitas e defensáveis: taxa de turnover esperada, custo médio de contratação, horas de indisponibilidade projetadas, crescimento do ambiente. Cada premissa deve ter uma fonte — histórico interno, benchmark de mercado ou estimativa declarada como tal. Um business case com premissas transparentes é mais difícil de refutar do que um com números misteriosos.
Como apresentar o business case para a diretoria e o financeiro
A apresentação é tão importante quanto o documento. Diretores e CFOs têm pouco tempo e muita exposição a propostas infladas: eles leem o resumo executivo, escaneiam os números e fazem perguntas diretas. O business case precisa ser construído para esse ritual de aprovação, não para ser arquivado como leitura completa.
Resumo executivo em uma página
O resumo executivo deve caber em uma página e responder, sem jargão técnico, às quatro perguntas que a diretoria faz: qual é o problema, quanto custa hoje, quanto custa a solução e o que acontece se não fizermos nada. A estrutura recomendada é: um parágrafo de contexto, um quadro comparativo de custos em três anos, os três principais riscos do modelo atual e a recomendação com payback e ROI estimados.
Números devem aparecer em destaque, não escondidos em prosa. Um quadro com TCO interno versus TCO MSP, lado a lado, vale mais do que três páginas de explicação. O resumo também deve antecipar a pergunta mais comum do financeiro: "quando o investimento se paga?" — e responder com um número, não com uma promessa.
Respondendo às objeções mais comuns (custo, perda de controle, lock-in)
Três objeções aparecem em praticamente toda reunião de aprovação de MSP. A primeira é o custo: "já temos um time interno, por que pagar mais?". A resposta está no TCO comparado — o custo real do interno, com turnover, horas não faturáveis e indisponibilidade, frequentemente supera o do MSP quando calculado corretamente. A segunda é a perda de controle: "vamos ficar reféns do provedor?". A resposta está na governança contratual — SLAs, relatórios mensais, reuniões de revisão e cláusulas de saída. Sobre o que exigir nos relatórios, vale consultar o que devem conter os relatórios.
A terceira objeção é o lock-in: "e se quisermos trocar de provedor?". A resposta está na preparação do contrato: propriedade de toda a documentação, credenciais e configurações; ausência de ferramentas proprietárias que impeçam a saída; e um plano de transição reversa testado. Um MSP sério não se opõe a essas cláusulas — pelo contrário, elas sinalizam que a relação será baseada em desempenho, não em aprisionamento. Para evitar armadilhas na contratação, o guia sobre erros comuns ao contratar lista os pontos de atenção.
Modelo de business case para MSP: estrutura e checklist de seções
Um modelo pronto acelera a construção do documento e garante que nenhuma seção crítica fique de fora. A estrutura recomendada para um business case de MSP segue uma lógica de convencimento progressivo: contexto, diagnóstico, opções, números, riscos e plano de ação. Cada seção responde a uma pergunta específica do processo decisório.
A estrutura completa inclui:
- Sumário executivo: uma página com problema, números-chave, recomendação e payback.
- Contexto e gatilhos: o que motivou a abertura do business case — custo, risco, capacidade ou combinação.
- Diagnóstico do modelo atual: TCO interno detalhado em três camadas (pessoas, ferramentas, indisponibilidade).
- Cenários comparados: interno, híbrido e MSP dedicado, com custos e riscos de cada um.
- KPIs e SLAs propostos: métricas operacionais, de segurança e de experiência do usuário.
- Análise financeira: TCO em três anos, ROI, payback e cenários conservador, base e otimista.
- Riscos e mitigação: riscos de transição, operacionais e contratuais, com plano de resposta.
- Plano de implementação: fases, marcos, responsáveis e critérios de sucesso.
- Critérios de seleção do provedor: o que avaliar nas propostas, incluindo certificações e referências.
- Recomendação final: cenário escolhido, justificativa e próximos passos.
O checklist de validação antes da apresentação deve confirmar: todas as premissas estão documentadas com fonte? Os números do TCO interno foram calculados com dados reais, não estimativas soltas? Os SLAs propostos são mensuráveis e verificáveis? Os riscos incluem plano de mitigação com responsável? O resumo executivo responde às quatro perguntas da diretoria em uma página? Se a resposta for sim para todas, o business case está pronto para a defesa. A etapa seguinte — avaliar fornecedores — tem critérios próprios, detalhados em como avaliar um provedor.
