Como este tema funciona na sua empresa
Relatório de uma página, mensal ou bimestral, conversado direto com o dono. O foco é simples: os sistemas ficaram no ar, quanto gastamos e como andam um ou dois projetos. O risco aqui não é fazer demais, é não ter registro nenhum — sem relatório, a TI vira a área de quem só aparece quando algo quebra.
Relatório de duas a quatro páginas com seções fixas, apresentado à diretoria ou a um comitê. Precisa equilibrar operação, projetos, segurança e custo, e começar a mostrar tendência, não só o número do mês. É a fase em que o relatório deixa de ser um e-mail e vira um documento de governança.
Sumário executivo de uma página sustentado por dashboards e anexos analíticos, levado ao board ou ao comitê de governança. KPIs ligados a metas estratégicas e OKRs, SLA por área de negócio, risco formalizado e decisões pedidas ao colegiado. O relatório é parte do ciclo de governança, não um informe da TI.
O relatório mensal de TI para a diretoria é o documento periódico que traduz a operação de tecnologia em linguagem de negócio, respondendo a três perguntas que o executivo de fato tem: está sob controle?, estamos entregando o que foi prometido? e estamos gastando bem?. Diferente do relatório técnico — feito para a equipe, cheio de métricas de infraestrutura —, o relatório executivo parte do impacto no negócio: disponibilidade vira risco de receita, incidentes viram exposição, projetos viram entrega de valor e custo vira eficiência.
Por que a maioria dos relatórios de TI falha com a diretoria
Porque foram escritos para a equipe de TI, não para quem decide. O relatório mensal mais comum é também o pior: uma lista de chamados fechados, uptime de servidor em quatro casas decimais e jargão que a diretoria não lê. Ele descreve a operação em vez de explicar o que ela significa para o negócio — e por isso é ignorado.
Relatório técnico e relatório executivo não são a mesma coisa
São documentos diferentes, com públicos diferentes, e confundi-los é o erro de origem. O relatório técnico serve à própria TI: detalha incidentes por sistema, fila do service desk, status de patch, métricas de capacidade. É operacional e granular. O relatório executivo serve à diretoria: parte do impacto, mostra poucos indicadores, contextualiza cada número com um "e daí para o negócio?". Um não substitui o outro; o executivo é uma destilação do técnico, não um resumo dele.
A regra de ouro: toda métrica responde "e daí?"
Nenhum número entra no relatório executivo sem responder à pergunta "e daí, para o negócio?". "Uptime de 99,2%" não diz nada a um diretor; "duas horas de ERP fora do ar significaram pedidos parados na expedição naquela tarde" diz tudo. A tradução é o trabalho central do relatório — e o que separa um documento lido de um documento arquivado. Frameworks de gestão de serviço como o ITIL 4, da Axelos, e o COBIT 2019, da ISACA, organizam essa lógica ao tratar métricas de TI sempre vinculadas a objetivos de negócio.[1][2]
No Brasil, o relatório é a ferramenta para reposicionar a TI
Em muitas empresas brasileiras a TI ainda é vista como centro de custo — a área que consome orçamento e aparece quando algo cai. O relatório mensal é a principal alavanca para mudar essa percepção, porque é o único contato recorrente que a diretoria tem com a área. Mês após mês, um relatório que mostra valor entregue, risco controlado e custo eficiente reposiciona a TI como parceira de negócio; um relatório técnico só reforça o estereótipo de custo.
A estrutura do relatório, seção a seção
Um bom relatório executivo de TI tem sete seções fixas, na ordem em que a diretoria pensa: primeiro o resumo, depois operação, atendimento, projetos, segurança, custo e, por fim, riscos e decisões. Seções fixas tornam o documento comparável de um mês para o outro — e a comparação é o que revela tendência. Abaixo, cada seção com o que incluir e como traduzir.
1. Sumário executivo (a única parte que todos leem)
Três a cinco bullets no topo: o que está bem, o que preocupa e o que precisa de decisão. Boa parte da diretoria lerá só esta seção por inteiro, então ela tem de funcionar sozinha. Use frases de negócio, não de TI: "Operação estável no mês; projeto do novo e-commerce atrasou duas semanas por dependência de fornecedor; precisamos de aprovação do orçamento de backup até o dia 20." O sumário é uma promessa do resto do documento, não um índice.
2. Disponibilidade e operação (o "está no ar?")
Disponibilidade dos sistemas críticos, total de incidentes, incidentes graves (P1/P2) e tempo médio de recuperação (MTTR). O segredo é traduzir cada número em impacto: não basta "ERP com 99,5% de disponibilidade"; mostre "2h de indisponibilidade do ERP = pedidos parados na expedição". Liste apenas os sistemas que o negócio reconhece — ERP, e-commerce, sistema de atendimento — não cada servidor. Disponibilidade por sistema crítico é a forma de a diretoria ver o que o número significa.
3. Service desk e atendimento (o "a TI atende bem?")
Volume de chamados, percentual dentro do SLA, tempo médio de resolução e satisfação do usuário (CSAT). Aqui, mais do que em qualquer seção, tendência importa mais que o número do mês: 88% de SLA isolado não diz nada; 88% vindo de 82% há três meses conta uma história de melhora. Sempre mostre o histórico de três a seis meses ao lado do mês corrente.
4. Projetos e roadmap (o "estamos entregando?")
Status de cada projeto com farol (verde/amarelo/vermelho), percentual de avanço, marcos do mês e do próximo, e — o ponto crítico — o objetivo de negócio que cada projeto serve. Um projeto sem objetivo de negócio declarado não deveria estar no relatório executivo. "Migração de e-mail: 70%, no prazo" diz pouco; "Migração de e-mail (reduz custo de licença em X e melhora segurança): 70%, no prazo" amarra a entrega ao valor. Use o farol para que a diretoria veja em segundos onde olhar.
5. Segurança e conformidade (o "estamos protegidos?")
Incidentes de segurança, patches críticos pendentes, status de backup e recuperação, e itens de LGPD em aberto. Reporte risco, não tecnologia: a diretoria não precisa saber a CVE de um patch, precisa saber que "há três sistemas com patch crítico pendente, o que aumenta o risco de indisponibilidade e vazamento". Backup testado e recuperação validada merecem destaque próprio — é o item que vira tragédia quando ninguém olhou. Trate LGPD em tom operacional ("o que falta a TI fazer"), não jurídico.
6. Financeiro e custo de TI (o "estamos gastando bem?")
Orçado versus realizado (separando OPEX e CAPEX), gasto por categoria (nuvem, licenças, contratos, equipe) e ao menos um indicador de eficiência — custo de TI por colaborador ou TI como percentual da receita. A disciplina de ligar cada real gasto a um serviço e a um resultado de negócio é o núcleo do Technology Business Management (TBM), promovido pelo TBM Council.[4] Gasto por categoria mostra para onde o dinheiro vai; o indicador de eficiência mostra se ele está bem aplicado.
7. Riscos e decisões pedidas (o "o que precisa de você?")
Os três a cinco principais riscos com probabilidade, impacto e ação em curso — e, separadamente, o que está bloqueado aguardando decisão da diretoria. Esta seção fecha o ciclo: o relatório não é só prestação de contas, é também o canal pelo qual a TI pede o que precisa. "Renovação do contrato de nuvem vence em 45 dias e precisa de aprovação de orçamento" é uma decisão pedida; deixá-la implícita é desperdiçar o relatório.
KPIs de TI por área para apresentar à diretoria
Os KPIs certos são poucos, segmentados por área e sempre acompanhados da tradução de negócio. A tabela abaixo sugere os indicadores por seção do relatório, com o que cada um mede e como traduzi-lo — definições alinhadas a catálogos de métricas de serviço como os do ITIL 4 (Axelos) e da norma ISO/IEC 20000-1, de gestão de serviços de TI.[1][3]
Tabela de KPIs sugeridos por área
| Área | KPI | O que mede | Tradução para o negócio |
|---|---|---|---|
| Operação | Disponibilidade dos sistemas críticos (%) | Tempo no ar dos sistemas que o negócio depende | Quanto da operação ficou parada e o que isso custou |
| Operação | Incidentes graves (P1/P2) | Quantidade de paradas de alto impacto | Quantas vezes o negócio sofreu interrupção séria |
| Operação | MTTR (tempo médio de recuperação) | Quão rápido a TI restabelece um serviço | Tempo que o negócio fica parado quando algo cai |
| Service desk | % de chamados dentro do SLA | Cumprimento dos prazos acordados de atendimento | Se as áreas estão sendo atendidas no tempo combinado |
| Service desk | Tempo médio de resolução | Quanto demora para resolver uma solicitação | Quanto tempo o colaborador fica improdutivo esperando |
| Service desk | CSAT (satisfação do usuário) | Percepção de quem usa o atendimento | Se a TI é vista como facilitadora ou gargalo |
| Projetos | Projetos no prazo / em risco / atrasados | Saúde do portfólio com farol | Se as promessas de entrega estão sendo cumpridas |
| Projetos | % de avanço por projeto | Progresso contra o planejado | O quanto falta para o valor prometido ser entregue |
| Segurança | Patches críticos pendentes | Vulnerabilidades conhecidas sem correção | Risco aberto de indisponibilidade ou vazamento |
| Segurança | Status de backup e recuperação testada | Capacidade comprovada de recuperar dados | Se a empresa sobrevive a um desastre ou ataque |
| Segurança | Itens de LGPD em aberto | Pendências de adequação sob responsabilidade da TI | Exposição a risco regulatório e reputacional |
| Custo | Orçado vs. realizado (OPEX/CAPEX) | Aderência ao orçamento aprovado | Se a TI gasta dentro do combinado |
| Custo | Custo de TI por colaborador / % da receita | Eficiência do gasto em relação ao tamanho do negócio | Se a empresa gasta de forma proporcional e comparável |
| Risco | Top 3–5 riscos (probabilidade × impacto) | Exposições priorizadas com ação | O que pode dar errado e o que está sendo feito |
Por que poucos KPIs valem mais que muitos
Porque a diretoria decide com base no que consegue ler, e um painel com trinta indicadores não é lido — é folheado. O relatório executivo escolhe os poucos KPIs que respondem às três perguntas-chave e deixa o resto no relatório técnico ou nos anexos. Cada KPI a mais que não muda uma decisão é ruído que enfraquece os que importam.
Tendência importa mais que o número do mês
Um KPI sem histórico engana. "MTTR de 4 horas" pode ser ótimo ou péssimo dependendo de onde veio: 4 horas vindo de 8 é melhora; vindo de 2 é alerta. Por isso todo KPI no relatório deve aparecer com a série dos últimos três a seis meses ao lado do valor atual, em mini-gráfico ou seta de tendência. A diretoria não age sobre um ponto; age sobre uma direção.
Como os KPIs mudam por porte
Três a quatro KPIs bastam: disponibilidade dos sistemas críticos, custo de TI no mês e status de um ou dois projetos. Adicionar SLA formal ou OKR aqui é burocracia sem leitor. O objetivo é dar visibilidade básica ao dono, não montar governança.
Acrescente SLA do service desk, indicadores de segurança e acompanhamento de portfólio de projetos com farol. É o porte em que vale padronizar as seções fixas e começar a reportar tendência de forma consistente.
Some risco formalizado, conformidade (LGPD, normas), SLA segmentado por área de negócio e alinhamento a OKRs e metas estratégicas. O relatório executivo de uma página é a ponta de um conjunto de dashboards e anexos analíticos por área.
Como apresentar: traduzir operação em linguagem de negócio
A apresentação importa tanto quanto o conteúdo: o mesmo dado, mal apresentado, não é lido. Três princípios fazem o relatório funcionar com executivos — sumário no topo, faróis para leitura rápida e tendência sempre visível — e todos servem ao mesmo fim: deixar a diretoria entender em minutos o que levou um mês para acontecer.
Uma página de sumário, o resto como apoio
A diretoria lê uma página; o resto é referência. Concentre o essencial — situação, alertas e decisões — em uma página de sumário e deixe o detalhamento por seção como apoio, consultado só por quem quiser aprofundar. Inverter essa lógica (detalhe primeiro, conclusão no fim) é o erro que faz o documento ser abandonado na segunda página.
Faróis verde, amarelo e vermelho
O farol permite que a diretoria escaneie o relatório em segundos e saiba onde olhar. Verde é "sob controle", amarelo é "atenção, há ação em curso", vermelho é "precisa de decisão ou está em risco". Use o farol com critério: se tudo está sempre verde, ninguém confia; se há vermelho demais, perde o efeito. O farol direciona a atenção — ele não substitui a explicação ao lado.
Tendência sempre visível
Todo número relevante aparece com sua direção. Uma seta, um mini-gráfico de três a seis meses ou uma comparação com o mês anterior transforma um dado estático em uma narrativa. A diretoria quer saber se a situação melhora ou piora, não apenas onde ela está hoje — e a tendência é o que sustenta a decisão de agir ou esperar.
Linguagem de negócio, zero jargão
Cada termo técnico é uma barreira entre a TI e a decisão. Troque "latência", "throughput" e "CVE" por "lentidão para o usuário", "capacidade de processamento" e "falha de segurança conhecida". Se um termo técnico é inevitável, explique-o em uma linha. A meta não é simplificar o trabalho da TI; é fazer com que quem decide entenda o que está sendo decidido.
Erros comuns que tornam o relatório inútil
A maioria dos relatórios ruins repete os mesmos erros, e quase todos vêm de escrever para a TI em vez de para a diretoria. Conhecer a lista permite corrigir o documento antes que ele perca o leitor.
Despejar dado técnico sem tradução
O erro mais frequente é apresentar métricas de infraestrutura cruas — uptime de servidor, fila de chamados, uso de CPU — sem dizer o que significam para o negócio. Dado sem tradução é ruído. Para cada número, a pergunta "e daí?" precisa ter resposta escrita ao lado, não deixada para a diretoria adivinhar.
Reportar só o mês, sem tendência
Mostrar apenas o número do mês esconde a história. Um indicador isolado não diz se a situação melhora, piora ou está estável — e é exatamente a direção que orienta a decisão. Relatório sem série histórica força a diretoria a reagir a fotos soltas em vez de acompanhar um filme.
Misturar relatório técnico e executivo
Enviar à diretoria o mesmo documento que circula na equipe de TI sobrecarrega quem decide com detalhe que não usa. O executivo precisa de destilação, não de despejo. Mantenha o relatório técnico para a equipe e produza uma versão executiva enxuta — uma não é resumo da outra, são documentos com propósitos distintos.
Esconder o que precisa de decisão
Muitos relatórios listam status e omitem o pedido. Se há um contrato a renovar, um orçamento a aprovar ou um risco que só a diretoria pode endereçar, isso precisa estar explícito numa seção de decisões pedidas. Relatório que não pede nada vira informe passivo — e perde a chance de destravar o que a TI precisa.
Sinais de que seu relatório de TI precisa ser repensado
Se você se reconhece em três ou mais cenários abaixo, é provável que o relatório atual não esteja cumprindo seu papel junto à diretoria.
- A diretoria raramente comenta o relatório, faz perguntas ou toma decisões a partir dele
- O documento é praticamente igual ao que circula dentro da equipe técnica
- Os números aparecem só com o valor do mês, sem histórico ou tendência
- Há métricas de infraestrutura (uptime, CPU, fila) sem nenhuma tradução de negócio
- Não existe um sumário executivo no topo — o leitor precisa garimpar a conclusão
- Projetos são listados sem o objetivo de negócio que cada um serve
- Não há uma seção que diga claramente o que precisa de decisão da diretoria
- A TI continua sendo vista na empresa como custo, não como entrega de valor
Caminhos para estruturar o relatório mensal de TI
Há dois caminhos para montar e manter um relatório executivo que a diretoria leia, e a escolha depende da maturidade da TI e da complexidade do ambiente. Eles também se combinam: muitas empresas definem o modelo internamente e buscam apoio para automatizar a coleta de dados e os dashboards.
Viável quando há um gestor de TI que conhece o negócio e consegue traduzir operação em valor.
- Perfil necessário: gestor ou coordenador de TI com visão de negócio e noção de governança (ITIL/COBIT)
- Tempo estimado: 1 a 2 ciclos mensais para estabilizar o modelo e as seções fixas
- Faz sentido quando: o ambiente é gerenciável, os dados existem e o objetivo é começar com um modelo simples e replicável
- Risco principal: relatório refém de uma pessoa e coleta manual de dados que consome tempo e abre espaço para erro
Indicado quando o ambiente é complexo ou a empresa quer automatizar coleta e dashboards.
- Tipo de fornecedor: Consultoria de governança de TI (ITIL/COBIT), plataformas de ITSM, ferramentas de BI para dashboards e especialistas em IT Financial Management (TBM)
- Vantagem: metodologia pronta, catálogo de KPIs validado e dashboards que reduzem o esforço manual de fechamento mensal
- Faz sentido quando: há muitas fontes de dados, SLA por área e necessidade de governança formal junto ao board
- Resultado típico: relatório padronizado com coleta automatizada e tendência confiável em poucos ciclos
Precisa estruturar um relatório de TI que a diretoria realmente leia?
Se governança de TI, dashboards executivos e tradução de métricas em valor de negócio são prioridade, o oHub conecta você gratuitamente a consultorias de governança, plataformas de ITSM e especialistas em IT Financial Management. Em menos de 3 minutos, descreva seu cenário e receba propostas.
Solicitar orçamento de Gestão de TI
Confira no oHub as empresas da nossa rede nas categorias: Gestão de TI
Sem custo, sem compromisso. Você recebe propostas e decide se e com quem avançar.
Perguntas frequentes
O que deve conter um relatório mensal de TI?
Sete seções fixas: sumário executivo, disponibilidade e operação, service desk, projetos e roadmap, segurança e conformidade, financeiro e custo, e riscos com decisões pedidas. Cada seção traduz a operação em impacto de negócio, e o sumário no topo concentra o que está bem, o que preocupa e o que precisa de decisão.
Quais KPIs de TI apresentar para a diretoria?
Poucos e segmentados por área: disponibilidade dos sistemas críticos, incidentes graves e MTTR (operação); % de SLA, tempo de resolução e CSAT (service desk); status e avanço de projetos; patches pendentes, backup testado e itens de LGPD (segurança); orçado vs. realizado e custo por colaborador (financeiro). Cada KPI deve vir com tradução de negócio e tendência.
Como fazer um relatório de TI que o board entende?
Escrevendo para quem decide, não para a equipe técnica: uma página de sumário no topo, faróis verde/amarelo/vermelho para leitura rápida, tendência de três a seis meses sempre visível e zero jargão. Toda métrica precisa responder à pergunta "e daí, para o negócio?" — disponibilidade vira risco de receita, projeto vira entrega de valor.
Qual a diferença entre relatório técnico e relatório executivo de TI?
O relatório técnico serve à equipe de TI: é granular, detalha incidentes por sistema, fila e capacidade. O executivo serve à diretoria: é uma destilação que parte do impacto no negócio, mostra poucos indicadores e contextualiza cada número. Um não é resumo do outro — são documentos com públicos e propósitos diferentes, e confundi-los faz o relatório ser ignorado.
Com que frequência apresentar resultados de TI?
Mensal é o padrão para a maioria das empresas. Pequenas podem reportar mensal ou bimestral em uma página; médias mantêm o ritmo mensal com seções fixas; grandes combinam um sumário executivo mensal com dashboards em tempo real para acompanhamento contínuo. Independentemente da frequência, a tendência de três a seis meses importa mais que o número absoluto do mês.
Como mostrar o valor da TI para a empresa?
Traduzindo operação em resultado de negócio de forma recorrente: ligar cada projeto a um objetivo, mostrar disponibilidade como risco de receita evitado, apresentar custo com indicador de eficiência e reportar risco controlado. No Brasil, onde a TI ainda é vista como custo, o relatório mensal consistente é a principal ferramenta para reposicioná-la como parceira de valor.
Fontes e referências
- Axelos. ITIL 4 — IT Service Management. Axelos / PeopleCert.
- ISACA. COBIT — Control Objectives for Information and Related Technologies (COBIT 2019). ISACA.
- ISO/IEC. ISO/IEC 20000-1:2018 — Information technology — Service management — Part 1: Service management system requirements. 2018 (confirmada em 2023). International Organization for Standardization.
- TBM Council. The TBM Framework: Connecting Technology to Business Value. Technology Business Management Council.