Como conduzir um diagnóstico de TI antes do planejamento

Por que diagnóstico rigoroso antecede bom planejamento

Muitos gestores de TI pulam diagnóstico e vão direto para "plano de TI". Resultado: decisões no escuro. "Vamos para cloud" sem saber o que há em on-premise. "Vamos implementar data lake" sem conhecer qualidade dos dados existentes. "Vamos modernizar arquitectura" sem entender débito técnico real.

Diagnóstico rigoroso evita isto. Oferece verdade factual sobre estado atual, capacidades, gaps. Cria base sólida para decisões. Também gera buy-in: quando stakeholders veem dados sobre estado atual, acreditam em necessidade de mudança.

Diagnóstico não é auditoria punitiva (encontrar culpados). É ferramenta de planejamento construtiva (entender realidade).

Estrutura de diagnóstico: cinco dimensões críticas

Diagnóstico bem estruturado avalia cinco dimensões:

1. Infraestrutura e arquitetura: Que sistemas existem? Hardware, software, banco de dados, rede, armazenamento. Idade, suporte, capacidade. Qual é o padrão de comunicação? Centralizado, distribuído, cloud-first? Débito técnico — quanto de sistema legado exige manutenção constante?

2. Aplicações e dados: Que aplicações críticas rodam? Qual é sua saúde (uptime, performance, suporte)? Dados: onde estão, como são protegidos, qualidade. Silos ou integrados? Capacidade de analytics? GDPR/LGPD compliance?

3. Processos de operação: Como são identificados incidentes? Como é feita mudança? Existe documentação? Automatização? SLAs definidos? Capacidade de disaster recovery? Documentação de processo está atualizada?

4. Segurança e conformidade: Políticas existem? Como é acesso controlado? Existe análise de risco? Qual é status de conformidade (NRs, LGPD, ABNT, ISO)? Há incidentes recentes que revelam gaps?

5. Pessoas e governança: Time de TI: tamanho, skill mix, capacidades principais e gaps. Rotatividade. Governança: existem comitês, decisões estruturadas? Alinhamento com negócio? CIO tem acesso a board?

Metodologia de coleta de dados

Diagnóstico combina múltiplas fontes de dados para triangulação (confirmação cruzada).

Entrevistas estruturadas: Com stakeholders chave (CIO, leads de infraestrutura, leads de aplicações, diretores de negócio, CFO). Questões pré-preparadas para consistência. Duração: 1-2 horas cada. Objetivo: entender narrativa, prioridades, problemas que todos concordam.

Surveys online: Para população maior (TI técnica, áreas de negócio). 10-15 perguntas. Rápido de coletar, fácil de analisar. Objetivo: validar que problemas identificados em entrevistas são sistêmicos, não isolados.

Varredura técnica automatizada: Scan de rede, inventário de ativos, análise de logs. Ferramentas: SolarWinds, Splunk, ServiceNow, ou assessoria automatizada de cloud providers. Objetivo: dados factuais sobre infraestrutura (versões, capacidade, utilização).

Revisão documental: Rotas técnicas, documentação de processos, políticas de segurança, SLAs, últimos planos de TI. Objetivo: entender intenção versus realidade (documentação frequentemente não reflete operação).

Observação in loco: Visitar data center, observar operação, conversar com técnicos em ambiente deles. Objetivo: entender pressões e restrições reais não formalizadas.

Como mapear inventário de sistemas e ativos

Inventário é alicerce de diagnóstico. Sem saber "o que temos", impossível planejar.

Inventário deve incluir:

• Servidores: Localização, SO, versão, suporte fim-de-vida, capacidade (CPU, RAM, disk), utilização atual, proprietário (qual departamento depende)
• Aplicações críticas: Nome, vendor, versão, suporte, uptime SLA, usuários impactados, impacto de downtime, integração com outros sistemas
• Banco de dados: DBMS, versão, tamanho, crescimento, backups, DR, proprietário
• Rede: Topology, velocidade, redundância, WAN links, cloud connectivity
• Armazenamento: SAN/NAS, capacidade, utilização, crescimento anual, backup
• Segurança: Firewalls, IDS/IPS, antivírus, backup, DR

Formato: spreadsheet simples ou ferramenta de CMDB (Configuration Management Database). Importante: manter atualizado post-diagnóstico, não virar documento que fica desatualizado em 6 meses.

Avaliação de débito técnico e risco

Débito técnico é custo "invisível" — sistemas antigos que funcionam mas custam manutenção constante, tecnologias obsoletas, falta de documentação, processos manuais que poderiam ser automatizados.

Diagnosticar débito técnico requer:

1. Identificar sistemas com suporte em risco de fim-de-vida: Versão antigos, vendor descontinuou, patches já não disponíveis. Exemplo: Windows Server 2003 (suporte terminou 2015).
2. Quantificar esforço de manutenção: Quanto de FTE (full-time equivalent) é dedicado a "apagar incêndios" versus evoluir sistema? Manutenção > 40% é sinal de débito alto.
3. Mapear dependências de sistema quebrado: Quantas aplicações dependem deste banco de dados legado? Quantos usuários seriam impactados por downtime?
4. Estimar custo de não fazer: "Se não modernizarmos isto em 2 anos, qual é risco de falha? Custo desta falha?"

Risco técnico é frequentemente invisível para negócio até que falha. Diagnóstico torna explícito, permitindo decisão baseada em dados.

Avaliação de maturidade de processos

Maturidade de processos — quão bem TI executa — é diferente de maturidade de infraestrutura.

Frameworks para avaliar maturidade: CobiT 2019 (governance e management), ITIL (service management), ISO 27001 (segurança), CMMI (processos de desenvolvimento).

Para cada processo crítico (incident management, change management, asset management, security, backup/recovery), avaliar:

• Nível 1 (Ad-hoc): Não tem processo; cada vez é diferente
• Nível 2 (Repetível): Processo existe mas não documentado, executado inconsistentemente
• Nível 3 (Definido): Processo documentado, treinado, executado consistentemente
• Nível 4 (Gerenciado): Processo tem métricas, acompanhado, otimizado continuamente
• Nível 5 (Otimizado): Processo é continuamente melhorado, inovado

Maioria de PMEs está em nível 1-2 para maioria dos processos. Isto não é problema se a organização é pequena; escalabilidade muda quando cresce. Diagnóstico revela em que processos o foco deve estar para crescimento.

Avaliação de capacidade de equipe e skill gaps

Análise de pessoas é frequentemente negligenciada em diagnóstico. Mas é crítica.

Avaliar:

• Tamanho do time: Quantos FTE em TI? Quantos por função (infraestrutura, aplicações, suporte, segurança)?
• Distribuição de skills: Quem conhece legacy? Quem conhece cloud? Há especialistas em segurança, dados, arquitetura?
• Gaps de skill: Para plano de 3 anos, que skills serão necessários? Faltam? Podem treinar internamente ou precisam contratar?
• Rotatividade: Quantas pessoas saem por ano? Por que saem?
• Capacidade de absorver mudança: Time é resistente ou receptivo a modernização?
• Liderança: CIO tem visão? Consegue comunicar? Tem credibilidade no board?

Skill gap é frequentemente maior que orçamento como limitador de transformação. Diagnóstico revela isto.

Estruturação de findings em roadmap de recomendações

Diagnóstico culmina em documento de recomendações que alimenta planejamento.

Estrutura recomendada de relatório:

Executivo summary (2 páginas): O que ouvimos, estado atual (scorecard), 3-5 recomendações chave, investimento estimado, ROI esperado, riscos principais.

Análise por dimensão (20-30 páginas dependendo da profundidade): Para cada dimensão (infraestrutura, aplicações, processos, segurança, people), descrever estado atual, benchmarks, gaps identificados, recomendações priorizado (rápidas, médio, longo prazo).

Roadmap de transformação (visual + timeline): Sequência de iniciativas, dependências, timeline, investimento, proprietário de cada iniciativa.

Business cases detalhados (por iniciativa): Investimento, benefícios esperados, payback, riscos, critérios de sucesso.

Apêndices: Dados brutos, lista de entrevistados, metodologia de diagnóstico, glossário.