A maioria dos SOPs falha antes de ser testada. O problema não é o formato — é que são escritos para serem arquivados, não para serem seguidos. Um SOP de 12 páginas numa wiki é consultado uma vez e depois ignorado. Um SOP de 6 etapas embutido na ferramenta de workflow é executado toda vez. A diferença entre um SOP que é seguido e um que não é quase nunca é a qualidade da redação.
Comece pelo modo de falha, não pelo processo. Antes de escrever qualquer etapa, pergunte: quando esse processo quebra, onde ele quebra? A resposta diz onde o SOP precisa ser mais específico. Se quebra na etapa de aprovação — porque ninguém sabe quem aprova, ou as aprovações acontecem no Slack sem registro — então a etapa de aprovação precisa de mais detalhe. Se quebra nos handoffs — porque a pessoa que conclui a etapa 3 não notifica quem é responsável pela etapa 4 — então os gatilhos de handoff precisam ser explícitos.
Escreva para o papel, não para a pessoa. 'Marcos vai fazer upload do documento na pasta compartilhada' é uma etapa de SOP ruim. 'O Gestor de Compliance faz upload da versão assinada na pasta de auditoria até o fim do dia do prazo' é uma etapa boa. A diferença: a segunda especifica um papel (não um nome), uma ação, um destino e uma restrição de prazo. Toda etapa de SOP deve ter os quatro elementos.
Evidência não é um checkbox — é uma especificação. A parte mais importante de cada etapa de SOP não é a descrição da ação; é a definição de como se parece a prova de conclusão. 'Concluído' não é um padrão de evidência. 'Screenshot do e-mail de aprovação anexado ao registro da tarefa' é. 'Documento assinado na pasta de auditoria com formato [AAAA-MM-DD]-[nome-do-controle]-aprovado.pdf' é. Escreva o padrão de evidência antes de escrever a etapa.
Versione seu SOP desde o primeiro dia. Dê a ele um número de versão (v1.0), uma data de revisão específica e um owner por papel. Quando o SOP mudar, incremente a versão, registre o que mudou e por quê, e arquive a versão anterior. Em um contexto de compliance, o histórico de versões de um SOP é em si um artefato de evidência — mostra que a organização mantém e melhora seus padrões, não apenas os documenta uma vez.
O sinal de que seu SOP está funcionando não é que as pessoas dizem que o seguiram — é que os registros do workflow provam. Quando cada run de um workflow com SOP produz um registro com timestamp de quem fez o quê, quando, com qual evidência, você tem um programa de compliance. Quando ainda está perguntando 'você seguiu o processo?', você tem um projeto de documentação.