Recolher uma assinatura é o quarto fácil do problema. Os outros três quartos ficam invisíveis até alguém contestar uma decisão, e são o assunto deste capítulo.
Monte uma
Volte ao seu processo Motor claim - third party, abra Approvers, e acrescente três pessoas por esta ordem:
- Gestor de sinistros — quem conhece o caso.
- Responsável de sinistros — quem carrega o orçamento.
- Diretor de sinistros — quem é dono do risco.
Grave. Todos os dossiês novos deste processo passam a carregar essa cadeia.
Porque é que a ordem não é decoração
Cada passo existe porque o anterior aconteceu. O responsável aprova um caso que alguém confirmou estar correto; o diretor contra-assina uma coisa que quem tem o orçamento aceitou.
Pergunte a toda a gente ao mesmo tempo — ganha quem clicar primeiro — e deita isso fora. Quem carrega o orçamento aprova antes de alguém ter verificado que o caso está sequer certo, e a sua aprovação passa a valer, em silêncio, menos do que o registo sugere.
Ordenar traz ainda uma coisa de graça: em cada momento há exatamente uma pessoa por quem o caso está à espera. «Com quem é que isto está?» passa a ser uma pergunta com resposta.
Vê-lo a acontecer
Submeta um dossiê deste processo. Como tem aprovadores, é encaminhado para Waiting decision em vez de para processamento.
- O primeiro aprovador vê-o. Mais ninguém é questionado ainda.
- Aprova → o caso passa a Partially approved, e o segundo aprovador é questionado.
- Os três aprovam → segue para processamento.
- Qualquer um recusa → Rejected.
- Qualquer um devolve o caso para correção, com motivo → Returned, e a cadeia recomeça sobre a versão corrigida.
O Partially approved ganha o seu lugar
Quando uma cadeia tem três aprovadores e um disse que sim, o caso não está «aprovado» e também não está «pendente». Os sistemas sem esse estado acabam a segui-lo fora de si próprios — uma coluna numa folha de cálculo, uma convenção sobre assuntos de e-mail — e a partir desse momento o estado real de um caso vive em dois sítios que discordam.
Recusa, e o que acontece a seguir
Uma recusa é uma decisão, não um erro. O aprovador tem de dizer porquê — uma recusa sem motivo não é aceite — e é esse motivo que torna a recusa legível seis meses depois.
Um caso recusado vai a um sítio: Returned. Reabrir repõe todos os aprovadores a pendente e limpa os campos de falha, para que o caso recomece a cadeia em vez de levar aceitações velhas para uma segunda volta.
Essa reposição é o comportamento certo e vale a pena perceber porquê. Se o caso está a ser corrigido, as aprovações anteriores foram dadas contra uma versão que já não existe.
Autoridade não é acesso
Abrir um caso, editá-lo e aprová-lo são três permissões diferentes.
Quando colapsam numa só, quem preparou o caso pode aprová-lo, e a separação que a cadeia inteira existe para criar desaparece — não por má-fé de ninguém, apenas porque o sistema nunca as distinguiu.
O teste é bruto, e vale a pena aplicá-lo a todos os processos que configurar: quem montou o caso pode aprová-lo? Se a resposta for sim, a aprovação regista que alguém concordou consigo próprio.
O que um bom registo de aprovação guarda
| Quem | O aprovador |
| O quê | Aprovado ou recusado |
| Quando | O momento em que foi registado |
| Onde na cadeia | A sua posição, e portanto quem estava à espera atrás |
| Porquê | O seu comentário |
Cinco das seis coisas que importam. A sexta é o assunto da secção seguinte, e é aquela a que a maior parte dos sistemas de aprovação nunca responde.
A pergunta que vale a pena fazer a qualquer sistema de aprovações
Uma aprovação dada na terça-feira foi dada contra o caso tal como estava na terça-feira.
Se o caso for editado na quarta e a aprovação continuar a aparecer como válida, o registo passa a afirmar que alguém aprovou uma coisa que nunca viu.
Há duas respostas defensáveis:
- Invalidar em qualquer alteração. Simples, segura, e ocasionalmente irritante — uma gralha corrigida recomeça a cadeia.
- Invalidar em alteração material. Melhor na prática, e obriga-o a definir «material», o que é trabalho a sério e vale a pena fazer.
Há uma terceira resposta, e não é defensável: deixar a aprovação de pé e esperar que ninguém edite nada.
No DOK Genius, reabrir um caso repõe a sua cadeia. Ao configurar os seus próprios processos, seja deliberado sobre o que uma edição significa na sua organização, e escreva-o — esta é uma questão de política que um produto não pode decidir por si.
O que deve ter agora
- Um processo com uma cadeia ordenada de três.
- Um dossiê que passou por Waiting decision e por Partially approved.
- Um recusado e reaberto, para ter visto a reposição.
- Uma resposta honesta ao teste «quem prepara pode aprovar?» para cada um dos seus nove processos.