Como documentar processos de TI para fins de governança

Por que documentação é crítica (além de burocracia)

Documentação é frequentemente vista como overhead — tempo que poderia ser gasto em "trabalho real". Mas documentação bem feita reduz risco, melhora qualidade e economiza tempo no longo prazo.

Benefícios práticos:

• Onboarding: novo membro do time lê documentação em vez de perder semanas aprendendo "do jeito que fazemos aqui".
• Consistência: sem documentação, cada pessoa faz "seu jeito". Resultado: variabilidade e risco.
• Auditoria: quando auditor pergunta "como vocês resolvem incidente crítico?", você tem resposta documentada.
• Melhoria contínua: documentação torna visível o processo — você vê ineficiências que não via quando estava "na cabeça".
• Conhecimento não se perde: quando alguém sai, conhecimento fica documentado.

Segundo COBIT 2019 e ITIL 4, documentação de processos é pilar de governança, não nice-to-have^[1].

Níveis de documentação: da visão estratégica ao procedimento executável

Documentação não é "tudo ou nada". Há níveis diferentes, cada um com propósito diferente.

Três níveis principais:

• Visão estratégica (nível 1): "O que é este processo? Por que existe? Que impacto tem para a empresa?" Documento de 1-2 páginas. Público: executivos, auditores.
• Fluxo do processo (nível 2): "Como o processo funciona? Que passos principais? Quem é responsável? Que sistemas são usados?" Documento + fluxograma. Público: gestores, membros do time.
• Procedimento executável (nível 3): "Passo a passo para executar. Que fazer se X acontecer? Que telas clicar em qual sistema?" Documento detalhado com prints de tela. Público: operadores, novos membros.

Estrutura de um processo documentado

Quando descrever um processo, incluir elementos padrão que o tornam completo e auditável:

Elementos de um processo bem documentado:

1. Nome e identificação: nome único (ex: "INC-01: Gestão de Incidentes"), código se houver.
2. Objetivo: "O que este processo faz?" "Que problema resolve?"
3. Escopo: "A que se aplica? A quem?" (ex: "todos os incidentes de severidade 1 e 2")
4. Entradas (inputs): "Que informação ou documento inicia o processo?"
5. Atividades/passos: "Que ocorre? Em que ordem?" Numerado ou flowchart.
6. Saídas (outputs): "Que resultado o processo entrega?"
7. Responsáveis: "Quem executa cada passo? Quem aprova?"
8. Sistemas envolvidos: "Que ferramentas são usadas? (ex: ITSM, Jira)"
9. Métricas: "Como sabemos que processo está funcionando?" (ex: SLA, tempo médio)
10. Frequência: "Quanto de vezes por dia/semana/mês este processo ocorre?"
11. Variações e exceções: "E se algo inesperado acontecer?" (ex: "Se cliente não responde em 48h")
12. Data de criação e ultima atualização: rastreabilidade.
13. Proprietário: quem é responsável por manter documentação atualizada.

Metodologia de captura: como não perder informação e não sobrecarregar time

Capturar processo sem parecer "entrevista infinita" é arte. Métodos diferentes para contextos diferentes.

Métodos de captura:

• Entrevista individual: conversa de 30-60 minutos com quem executa. Bom para processos simples. Rápido. Risco: viés pessoal ("eu faço assim, mas outros fazem diferente").
• Workshop em grupo: reúne múltiplas pessoas. Discutem o processo junto. Reduz viés. Menos eficiente em tempo. Melhor para processos complexos com múltiplos atores.
• Observação: você acompanha execução do processo. Vê o que realmente é feito (não o que as pessoas dizem que fazem). Tempo-intensivo. Ideal para validar depois de entrevista.
• Análise de logs/registros: olhar para tickets fechados, logs de sistema. Valida se descrição está alinhada com realidade. Complementa entrevistas.

Recomendação: combinar métodos. Entrevista + workshop + observação spot-check = melhor resultado.

Ferramentas para documentar: da planilha ao BPM

Ferramenta deve ser apropriada ao porte. Evitar over-engineering (grande ferramenta para PME) e under-engineering (planilha para empresa grande).