Visão geral
A maioria dos times de compliance tem SOPs e workflows, e usa os termos de forma intercambiável sem perceber que estão descrevendo coisas diferentes. Essa confusão cria gaps reais: SOPs completos no papel mas inexecutáveis na prática, e workflows executados consistentemente mas sem evidência do padrão que seguiram. Entender a relação entre os dois é o que separa um programa de compliance de uma biblioteca de compliance.
Um SOP é um documento que define o padrão. Especifica o que deve ser feito, em que ordem, por quem e com qual evidência de conclusão. É estático, um registro do que a organização decidiu que é a abordagem correta. Quando um auditor pergunta 'qual é o seu processo para X?', o SOP é a resposta.
Um workflow é o runtime que executa o SOP. Atribui tarefas, aplica sequência, dispara handoffs, bloqueia aprovações e registra evidência. É dinâmico, uma execução ao vivo que produz um registro com timestamp do que realmente aconteceu. Quando um auditor pergunta 'me mostre que rodou corretamente no último trimestre', o registro do workflow é a resposta.
Transforme SOPs em registros de execução
O Cadenio executa seus SOPs como workflows ao vivo, atribuição por papel, gates de aprovação, evidência por run e vínculo de versão integrados. O padrão e a prova, no mesmo sistema.
Começar gratuitamenteA diferença importa mais em ambientes regulados. Um SOP sem workflow diz o que deveria ter acontecido, não consegue dizer o que aconteceu, quem era responsável quando houve desvio, ou se o desvio foi aprovado. Um workflow sem SOP diz o que aconteceu mas não se foi a coisa certa, não há padrão documentado para comparar. Compliance exige os dois: o SOP define o padrão, o workflow prova a aderência.
“O SOP define o padrão. O workflow prova a aderência.”
Existe um modo de falha comum para times que confundem os dois. Trate a ferramenta de workflow como biblioteca de SOP e você acaba com listas de tarefas sem padrão documentado, onde cada run pode divergir sem que ninguém perceba. Trate a wiki de SOP como ferramenta de workflow e você acaba com documentação que não prova nada: o SOP foi seguido porque alguém diz que sim, não porque o sistema registrou.
O modelo prático: mantenha SOPs no sistema de documentação (Notion, Confluence, SharePoint). Implemente-os como workflows executáveis na ferramenta de workflow. Versione os dois juntos. Quando o SOP muda, a versão do workflow muda. Quando o workflow produz um registro inesperado, você tem evidência para atualizar o SOP. Cada sistema faz o que faz melhor: o SOP é o padrão, o workflow é a prova.
SOP vs. workflow: quatro diferenças que importam em uma auditoria
A primeira é estático vs. dinâmico. Um SOP é criado uma vez e atualizado de forma deliberada, por meio de um ciclo formal de revisão e aprovação. Um workflow roda continuamente, a cada execução do processo, e produz um registro novo a cada vez. Um é uma especificação; o outro é um runtime. Você atualiza o SOP quando o padrão muda. O workflow atualiza quando a execução muda. Os dois devem andar juntos.
A segunda diferença é de ownership. Um SOP tem um autor e um dono de revisão, tipicamente o gestor do processo ou compliance manager, responsável por manter o padrão atualizado. Um workflow tem executores: as pessoas atribuídas a cada tarefa em cada run. Confundir quem é dono do documento com quem executa o processo é um dos gaps mais comuns que auditores apontam. Alguém pode aparecer como dono do processo no SOP e não ter papel atribuído no workflow real.
A terceira diferença é o que cada um produz. Um SOP produz um padrão, uma declaração de como a organização decidiu que o trabalho deve ser feito. Um workflow produz evidência: um registro com timestamp do que realmente aconteceu, quem fez, quando cada etapa foi concluída e o que foi submetido como prova. Auditores precisam dos dois. O padrão diz se seus controles são adequados. A evidência diz se você os seguiu.
A quarta diferença é como são versionados. SOPs seguem versionamento de documento: v1.0, v1.1, v2.0. Workflows seguem versionamento de execução: cada run é um registro vinculado à versão do processo que estava vigente quando rodou. Quando você atualiza o workflow, os runs históricos devem continuar mostrando o que estava em vigor quando foram criados. Isso é o que permite responder à pergunta do auditor: 'qual versão do processo governava os runs do T3?'
Quando atualizar o SOP vs. quando atualizar o workflow
Atualize o SOP quando o padrão muda: um requisito regulatório muda, um risco é reclassificado, ou a organização decide que uma abordagem diferente é a correta. O SOP é a resposta para 'o que devemos fazer?' Qualquer mudança nessa resposta exige revisão do SOP, com novo número de versão, sign-off de aprovação e registro do que mudou e por quê.
Atualize o workflow quando a execução muda: uma etapa é reestruturada, um gate de aprovação é adicionado ou removido, uma atribuição de papel muda, ou uma restrição de prazo é modificada. O workflow é a resposta para 'como realmente fazemos?' Mudanças na execução exigem atualização do workflow. Os dois devem acontecer juntos quando um causa o outro: atualizar o SOP sem atualizar o workflow correspondente cria um gap imediatamente.
O problema de sincronização é o achado de auditoria mais comum. Não que os times não tenham SOPs, e não que não tenham workflows, mas que os dois existem de forma independente, sem nenhum processo para mantê-los alinhados. Quando o SOP muda, ninguém atualiza o workflow. Quando o workflow deriva por ajustes informais, ninguém atualiza o SOP. O resultado é um programa de compliance que parece completo no papel mas produz evidência que não corresponde ao padrão documentado.
Três formas como times criam gaps entre SOPs e workflows
A primeira é usar uma wiki como ferramenta de workflow. Notion, Confluence e SharePoint são excelentes repositórios de SOP. Não são sistemas de execução de workflow. Quando times tentam rodar processos de compliance por uma wiki, tarefa atribuída em uma página, conclusão marcada editando o documento, não há aplicação de sequência, atribuição por papel nem evidência que sobrevive a uma auditoria. A wiki registra que alguém editou a página. Não registra que o processo foi concluído corretamente, pela pessoa certa, dentro da janela exigida.
A segunda é versionar o SOP mas não o workflow. A maioria dos times tem disciplina de versionamento de SOP. Poucos aplicam a mesma disciplina às definições de workflow. Quando um SOP é atualizado para v2.0, o workflow deve ser atualizado para refletir o novo padrão, e os runs históricos devem continuar vinculados à versão vigente quando rodaram. Sem esse vínculo, não é possível responder à pergunta que o auditor vai fazer: 'prove que o processo rodando no T3 correspondia ao padrão v1.2 em vigor na época.'
A terceira é rodar workflows sem um SOP por trás. O problema oposto: times constroem workflows eficientes na ferramenta de processo sem documentar o padrão subjacente. O workflow existe, roda de forma confiável e produz evidência. Mas não há documento declarando por que o processo está estruturado dessa forma, qual risco ele mitiga ou qual requisito regulatório ele atende. Um auditor pode ver que algo aconteceu. Não consegue avaliar se foi a coisa certa a fazer, ou se satisfez um requisito de controle específico.