Prontidão não é um KPI — é evidência
Esta página descreve como se prova prontidão do lado do Dono de Obra: o que tem de estar fechado, o que tem de ser testado, o que tem de ser operável, e como evitar a armadilha do “parece verde”.
Conhecimento negativo (o que “parece” prontidão — mas não é)
Uma unidade pode estar “95% completa” e ainda assim não ser operável. O risco está no 5%: permissões, interlocks, causa-efeito, energia, purgas, utilidades, segurança, e testes integrados.
Checklists sem rastreio (ITRs, dossiês, testes, assinaturas e condições) criam prontidão aparente. A prontidão real é auditável: o “porquê” e o “como sabemos” vêm juntos.
Arranque é um sistema acoplado: pessoas, energia, interlocks, utilidades, procedimentos, sobressalentes, permissões e operações. Se uma peça falha, o sistema inteiro sofre — e a previsão colapsa.
O que é prontidão do lado do Dono de Obra
Energia, utilidades, permissões, segurança, integrações, procedimentos e “handover” funcional. O ponto não é “ter documentos”: é ter condições reais para operar.
A maior parte das falhas surge na integração: interlocks, causas-efeito, loops, telecoms, sequências operacionais e resposta a anomalias. É aqui que “verde” se torna “vermelho”.
Prontidão inclui a pergunta difícil: “e quando algo falhar?” Alarmes, respostas, planos de contingência, sobressalentes, equipa e estabilidade operacional.
O que a liderança recebe (na linguagem certa)
O que está fechado, o que não está, o que é reversível e o que não é. Inclui impactos prováveis e decisões expostas — sem linguagem de conforto.
O arranque é sustentado por condições ou por esperança? Identifica pontos de rutura e ações que realmente estabilizam a trajetória.
O que bloqueia, quem resolve, e o que fica desbloqueado. A prontidão real é construída por fecho de interfaces — não por percentagens.