Exemplos de POP: 3 procedimentos operacionais padrão
Veja três exemplos de POP com etapas, sistemas e exceções. Entenda o que incluir e como manter o procedimento atualizado.
Um exemplo de procedimento operacional padrão é útil quando mostra as etapas, os sistemas e as exceções na prática, não apenas uma lista de tópicos. A seguir, veja três exemplos detalhados, a estrutura de um procedimento fácil de manter, como documentá-lo no fluxo de trabalho e como verificar se ele ainda representa o que acontece na prática.
O que é um procedimento operacional padrão?
Um POP descreve como executar uma tarefa recorrente: quem faz o quê, em que ordem, em qual sistema e como agir quando o fluxo habitual não se aplica. Ele oferece à equipe uma referência comum para realizar o trabalho e treinar novas pessoas. Sua qualidade depende de quando foi a última vez que alguém o comparou com o trabalho real.
Qual é a diferença entre um POP, uma política, uma instrução de trabalho e um mapa de processos?
Estes documentos têm objetivos diferentes:
- Uma política registra as decisões da organização. Por exemplo: “Todas as faturas acima de 10.000 precisam de aprovação dupla.”
- Uma instrução de trabalho explica como executar uma etapa específica, como usar uma tela, um campo ou um botão. O POP diz o que acontece em seguida; a instrução de trabalho explica como executar aquela etapa.
- Um mapa de processos mostra como o trabalho flui entre funções e sistemas. Um POP descreve uma tarefa com mais detalhes. Confira nosso guia de mapeamento de processos.
Escreva o POP pensando em quem executa o trabalho, incluindo as situações em que essa pessoa precisa tomar uma decisão ou lidar com uma exceção.
Três exemplos de procedimentos operacionais padrão
Cada exemplo usa uma tabela de etapas com função, sistema, resultado esperado e caminho para exceções. Esses detalhes facilitam a execução do procedimento e a comparação com o trabalho registrado nos seus sistemas.
Exemplo 1: Tratamento de exceções em faturas nos serviços compartilhados
Este procedimento começa quando uma fatura não passa pela conciliação de três vias. A coluna de exceções explica o que fazer quando uma etapa não sai como planejado.
| Etapa | Responsável | Sistema | Resultado | Se algo der errado |
|---|---|---|---|---|
| 1 | Analista de contas a pagar | ERP | Caso de exceção criado com o código do motivo | Sem código do motivo: encaminhe à liderança de contas a pagar antes de investigar |
| 2 | Analista de contas a pagar | ERP, portal do fornecedor | Diferença identificada: preço, quantidade ou entrega | Preço dentro da tolerância de 2%: registre a fatura e anote a variação |
| 3 | Comprador | ERP | Confirmação de que os produtos foram recebidos conforme o pedido | Comprador indisponível por 2 dias: encaminhe ao gerente de categoria |
| 4 | Analista de contas a pagar | ERP | Nota de crédito solicitada ou fatura aprovada para pagamento | Fornecedor contesta a nota de crédito: siga o procedimento de contestação e não deixe o caso em aberto |
| 5 | Liderança de contas a pagar | ERP | Caso encerrado com o motivo registrado | Mesmo código de motivo aparece por três meses seguidos: solicite uma alteração no processo |
A última linha permite que a equipe sinalize um problema recorrente para revisão. Ela não parte do princípio de que todas as exceções precisam da mesma solução.
Exemplo 2: Recebimento e armazenagem de mercadorias
| Etapa | Responsável | Sistema | Resultado | Se algo der errado |
|---|---|---|---|---|
| 1 | Operador de recebimento | WMS | Entrega conferida com base no ASN | Sem ASN: registre o recebimento manualmente e sinalize o fornecedor |
| 2 | Operador de recebimento | WMS | Quantidade e danos registrados | Dano identificado: fotografe, coloque o palete em quarentena e avise a equipe de compras |
| 3 | Inspetor de qualidade | QMS | Decisão de liberação do lote | Lote retido: mantenha os produtos em quarentena e não inicie a armazenagem |
| 4 | Operador de armazém | WMS | Produtos armazenados no local sugerido | Local bloqueado: use o espaço de armazenamento excedente e registre a alteração |
| 5 | Operador de armazém | WMS | Estoque disponível para separação | Recebimento registrado após o horário limite: confira se os pedidos em aberto precisam ser replanejados |
Exemplo 3: Triagem de incidentes em uma central de serviços de TI
| Etapa | Responsável | Sistema | Resultado | Se algo der errado |
|---|---|---|---|---|
| 1 | Agente da central de serviços | ITSM | Incidente registrado com serviço, impacto e urgência | Não foi possível falar com o usuário: registre o incidente em nome dele e anote a origem |
| 2 | Agente da central de serviços | ITSM, CMDB | Prioridade definida pela matriz de impacto e urgência | Grupo responsável pela resolução contesta a prioridade: encaminhe ao responsável pelo serviço, sem renegociar sem registro |
| 3 | Grupo responsável pela resolução | ITSM | Diagnóstico e tentativa de solução dentro do prazo do SLA | A solução exige uma alteração: vincule o registro da alteração e mantenha o incidente aberto |
| 4 | Agente da central de serviços | ITSM | Confirmação do usuário e encerramento | Usuário não confirma em até 3 dias: encerre o incidente com o motivo registrado |
O que deve constar em um POP?
Use esta estrutura como ponto de partida para seu próximo procedimento operacional padrão:
- Objetivo e escopo: Explique o que o procedimento abrange e o que fica de fora. Limites claros ajudam a manter cada POP focado em uma tarefa.
- Evento de início: Identifique o evento que inicia o procedimento para que quem o consulta saiba quando ele se aplica.
- Funções: Descreva as responsabilidades por função, não por pessoa. As pessoas mudam; as funções tendem a permanecer.
- Etapas numeradas e sistemas: Descreva cada etapa, quem a executa e qual sistema utiliza.
- Caminho para exceções: Explique o que fazer quando o fluxo normal não se aplica. Inclua desvios comuns, não apenas o cenário ideal.
- Controles e evidências: Informe o que registrar, onde registrar e por quanto tempo manter os registros.
- Responsável e histórico de revisões: Identifique a pessoa responsável e registre a data e a natureza de cada alteração.
- Evento de revisão: Especifique o que deve levar à revisão, como uma mudança de sistema, regulamentação ou equipe, ou uma alteração mensurável na performance.
O histórico de revisões mostra o que mudou e quando. Um evento de revisão dá um motivo para reavaliar o procedimento antes que ele fique desatualizado.
Como conferir se um POP está pronto para uso?
Antes de publicar ou revisar um procedimento, pergunte:
- O escopo informa o que o POP não abrange?
- O evento de início está claro logo no começo?
- Cada etapa identifica uma função, um sistema e o resultado esperado?
- As etapas executadas em um aplicativo mostram a tela que a pessoa verá?
- O procedimento explica o que fazer quando o fluxo normal não se aplica?
- Há uma pessoa responsável identificada e um histórico de revisões?
- Um evento específico indica quando o procedimento deve ser revisado?
- Você consegue comparar o procedimento com os dados do Event Log e já conferiu as diferenças com a pessoa responsável pelo processo?
Se você não consegue responder à última pergunta, comece identificando quais sistemas registram o trabalho. Assim, você pode conferir se o procedimento ainda reflete o que acontece na prática e transformar a gestão do POP em um ciclo de revisão, em vez de apenas arquivar um documento.
Como gerenciar POPs
Criar um POP é só metade do trabalho. Gerenciar um programa de POPs é mais difícil: definir onde o procedimento fica, qual versão está atualizada e quem deve revisá-lo. Mesmo que você use um software dedicado à gestão de POPs ou uma pasta de documentos, manter uma cópia por equipe é uma receita para deixar o procedimento desatualizado. O ProcessMind mantém o procedimento junto do processo que ele descreve, para que a governança acompanhe o conteúdo:
- Adicione o procedimento à atividade que ele descreve. Cada processo tem uma árvore de documentação com seções configuradas uma vez para cada ambiente. Assim, todos os procedimentos começam com as mesmas seções de descrição, escopo, funções, objetivos e governança. Adicione seções personalizadas conforme as necessidades da organização e mantenha a instrução de trabalho junto da etapa correspondente, em vez de deixá-la em uma pasta que alguém precisa localizar.
- Revise o procedimento junto com o restante do processo. Um processo pode passar pelos estados de rascunho, em revisão, aprovado, publicado, desativado e arquivado. Quem revisa encontra as tarefas no filtro Aguardando minha revisão. A aprovação também pode gerar uma versão publicada na mesma etapa, evitando que um documento seja aprovado em um lugar e alterado em outro.
- Comente onde o trabalho acontece. Adicionar comentário na etapa inicia uma conversa sobre a atividade. Assim, uma dúvida sobre um campo, um controle ou uma exceção fica junto da instrução, em vez de se perder na caixa de entrada.
- Mantenha o histórico de versões. O Histórico de versões registra o que mudou, quando e por quem. A publicação define qual versão as pessoas podem consultar.
- Use as funções do modelo. A matriz RACI do documento é preenchida com as funções atribuídas às atividades do modelo. Assim, as responsabilidades descritas no texto correspondem às do diagrama.
- Capture as etapas na tela onde o trabalho acontece. Faça uma captura de tela ou grave a tela dentro do ProcessMind, recorte a imagem para mostrar os controles relevantes, oculte informações pessoais diretamente na imagem salva e adicione instruções em Markdown. O editor também pode detectar campos que provavelmente contêm dados confidenciais. As caixas continuam editáveis para você corrigi-las antes de salvar. A captura fica anexada à atividade como um artefato.
- Exporte o documento para quem precisa de um arquivo. Use Word para ciclos de revisão e sistemas de qualidade, Markdown para controle de versões e PDF ou impressão para distribuição e arquivamento. Nas configurações de exportação, você define se o arquivo deve listar também os elementos do modelo ainda sem documentação, os diagramas do processo e a matriz RACI por atividade. Listar os elementos sem documentação costuma ser a maneira mais rápida de identificar lacunas no procedimento.
O documento é apenas uma parte. A outra é a conferência, que também deve acontecer no mesmo lugar: compare as etapas documentadas com as atividades registradas nos seus sistemas e decida se é o treinamento, o documento ou o processo que precisa mudar. Uma alteração aprovada volta para a documentação com seu próprio status de versão.
Vale deixar claros dois limites. O ProcessMind organiza os registros e fornece evidências para revisão, mas não certifica a conformidade nem substitui a aprovação exigida pelo seu sistema de gestão da qualidade ou a biblioteca de políticas mantida pela equipe jurídica. Ferramentas de captura de tela fora deste fluxo de trabalho, como o Scribe, também registram como alguém executa uma tarefa. E uma wiki pode continuar sendo suficiente para um pequeno conjunto de procedimentos mantidos por uma equipe. Mas nem uma wiki nem um repositório separado de documentos mostram se o procedimento ainda corresponde ao trabalho.
Por que os procedimentos escritos ficam diferentes do trabalho realizado?
Os procedimentos ficam desatualizados porque o trabalho muda depois que alguém os documenta. Isso não significa necessariamente que a documentação foi malfeita. É um sinal de que o processo evoluiu.
O procedimento se baseia na memória. Um workshop registra como as pessoas entendem o processo, o que pode refletir a forma como ele foi planejado, e não como é executado. É fácil deixar passar exceções, embora elas possam representar boa parte do trabalho.
As equipes criam soluções alternativas. Alguém encontra um caminho mais rápido para um caso comum e compartilha com os colegas. Se atualizar o POP dá mais trabalho do que seguir a solução alternativa, o documento pode ficar para trás.
Os sistemas mudam. Um campo muda de nome, uma verificação passa a ser automática ou o limite para aprovação é alterado. O procedimento pode continuar descrevendo a configuração anterior.
É difícil perceber a mudança. Um documento escrito não mostra quando o trabalho começou a ser feito de outra forma. Sem evidências do processo, talvez você precise pedir às pessoas que reconstruam o que aconteceu.
O que mantém um procedimento atualizado
Um documento guardado em uma pasta não consegue responder a isso sozinho. Manter o procedimento vivo pode ajudar: ele continua vinculado ao processo e à atividade que descreve. Assim, uma mudança em uma etapa e uma mudança na documentação são revisadas em conjunto pelas funções já definidas no modelo. A versão publicada é a única fonte confiável que sua equipe consulta no Process Portal, e cada exportação vem desse registro, não de uma cópia editada localmente.
Duas coisas ajudam a manter essa visão fiel à realidade. A verificação de conformidade mede a diferença entre o processo documentado e as atividades registradas pelos seus sistemas. Assim, você pode observar os desvios em vez de apenas suspeitar que existem. A governança de processos deixa claro quem é responsável por essa visão, e a governança e a publicação são onde ficam o processo de revisão e o histórico de versões.
Um procedimento escrito só fica desatualizado depois que o trabalho já mudou, e, a essa altura, ninguém sabe dizer quando isso começou. Manter o procedimento junto ao processo e à atividade que ele descreve é a única forma que conheço de perceber a mudança logo no início. Consulte o documento e as evidências em conjunto, ou um deles estará sempre desatualizado.
Como criar um POP com dados de eventos?
Os dados de eventos mostram quais etapas as pessoas executam nos sistemas que já registram o trabalho, como um ERP, um ITSM ou um WMS. Use esses dados junto com o conhecimento sobre o processo para elaborar e revisar um procedimento. Essa é uma das aplicações de Process Mining:
-
Carregue o Event Log
Identifique o ID do caso, a atividade e a data e hora registradas nos sistemas que acompanham o processo. Use uma única definição de caso e um único intervalo de tempo para manter os dados comparáveis. -
Mapeie os dados no processo documentado
Compare a sequência registrada com as etapas do POP. Algumas etapas documentadas aparecem em todos os casos, outras são raras e algumas não aparecem. Vale investigar cada uma dessas situações. -
Analise as variações
Meça a frequência de cada caminho, onde o trabalho fica parado e quais etapas se repetem. Uma variação nos dados é um motivo para investigar, não uma prova de que o trabalho está errado. -
Inclua no POP as variações relevantes
Transforme as variações recorrentes em linhas de exceção, indicando uma função, um sistema e o resultado esperado, como nos três exemplos acima. Depois, peça às pessoas que executam o trabalho que confirmem o que os dados não mostram.
Você pode usar dados do processo para verificar um procedimento, mas eles não explicam todas as decisões nem definem como o processo deveria funcionar. Confirme as descobertas com quem executa e é responsável pelo trabalho. Aproveite para definir uma pessoa responsável e um critério para iniciar a revisão: um procedimento sem responsável acaba ficando desatualizado.
Where to Go From Here
You have a procedure and a way to check it. Compare the documented steps with the activity your systems already record, and use the differences to decide what to review with your process team.
