Todo time de operações eventualmente constrói uma biblioteca de SOPs. Documentos detalhados, seções claras, formatação consistente. Então um auditor pede os controles que rodaram no último trimestre, e a resposta honesta é: aqui está o documento que escrevemos, mas não conseguimos provar que foi seguido. Esse gap — entre o SOP como documento e o SOP como registro de execução — é o modo de falha mais comum em programas de compliance.
Um SOP — Standard Operating Procedure, ou Procedimento Operacional Padrão — é um documento que define exatamente como uma tarefa recorrente deve ser executada. Diferente de uma política (que define o que é necessário) ou de uma diretriz (que define o que é recomendado), um SOP define precisamente como o trabalho é feito: a sequência de etapas, quem é responsável por cada uma, quais insumos são necessários e como o output deve parecer.
Três coisas separam um SOP útil de documentação performática. Primeiro: especifica owner por papel, não por nome — 'o Gestor Financeiro aprova esta etapa' sobrevive à rotatividade, 'Marcos aprova esta etapa' não. Segundo: define uma sequência que não pode ser reordenada — o requisito de evidência da etapa 4 pressupõe que a etapa 3 foi concluída. Terceiro: produz um registro ao final de cada run — não um status de conclusão, mas prova de que a pessoa específica no papel específico completou a etapa específica com o output específico.
O motivo pelo qual a maioria dos programas de SOP falha não é redação ruim — é que SOPs existem onde são criados, não onde o trabalho acontece. Um PDF numa wiki é consultado antes da tarefa. Um SOP embutido na ferramenta de workflow é executado durante a tarefa. A diferença é se o SOP é um artefato de referência ou um runtime. Artefatos de referência ficam desatualizados. Runtimes são aplicados.
Um SOP útil tem quatro componentes: (1) o escopo — o que cobre e em quais condições se aplica; (2) a sequência — cada etapa em ordem com o papel responsável; (3) o padrão de evidência — como se parece a prova de conclusão em cada etapa; (4) a versão e a data de revisão — quem é o owner, quando foi aprovado por último e o que gerou esta versão. Sem o quarto componente, não é possível provar em uma auditoria que o SOP em vigor quando o trabalho foi feito é o que o time realmente seguiu.
O ponto de partida prático: escolha o SOP que causou mais problemas no último ciclo de auditoria. Não o mais complexo — o que teve mais momentos de 'não conseguimos produzir a evidência'. Escreva-o como documento de quatro componentes. Depois construa-o como um workflow. Execute os dois em paralelo por um ciclo. Depois disso, o workflow é o SOP.