Quase todos os sistemas conseguem recolher aprovações. Um botão, um nome, uma data. A razão pela qual os fluxos de aprovação continuam a correr mal é que recolher uma assinatura é o quarto fácil do problema, e os outros três quartos são invisíveis até alguém contestar uma decisão.
Isto é o que tem de ser verdade.
A ordem faz parte da decisão
Quando as aprovações são recolhidas em paralelo — toda a gente é chamada ao mesmo tempo, ganha quem carregar primeiro — a sequência não transporta informação nenhuma. Isso é aceitável quando os aprovadores são intermutáveis, e normalmente não são.
Uma cadeia típica é revisto por quem conhece o caso, depois aprovado por quem tem o orçamento, depois referendado por quem é dono do risco. Cada passo existe porque o anterior aconteceu. Chamar os três em simultâneo significa que quem tem o orçamento aprova antes de alguém ter confirmado que o caso está sequer correcto, e a aprovação dessa pessoa passa a valer menos do que o registo sugere.
Ordenar produz ainda algo valioso de graça: em cada momento há exactamente uma pessoa por quem o caso está à espera. «Com quem é que isto está?» passa a ter resposta, e a fila deixa de ser um mistério.
Autoridade não é o mesmo que acesso
É na aprovação que estes dois mais se confundem, e é essa confusão que transforma um controlo numa formalidade.
Poder abrir um caso, poder editá-lo e poder aprová-lo são três permissões diferentes. Quando colapsam numa só, quem preparou o caso consegue aprová-lo, e a separação que a cadeia inteira existe para criar desaparece — não por má-fé, apenas porque o sistema nunca as distinguiu.
O teste é seco: quem montou o caso consegue aprová-lo? Se sim, a aprovação regista que alguém concordou consigo próprio.
Uma decisão é tomada contra um estado, não contra um caso
Esta é a falha que sobrevive a todos os outros controlos, e vale a pena ser preciso.
Uma aprovação dada na terça-feira foi dada contra os documentos e os valores tal como estavam na terça-feira. Se o caso for editado na quarta e a aprovação continuar a ser mostrada como válida, o registo passa a afirmar que alguém aprovou uma coisa que nunca viu.
Ninguém fez nada de errado. O registo está errado à mesma, e está errado exactamente da forma que um auditor foi treinado para procurar.
Há duas saídas honestas, e escolher entre elas é uma decisão de produto a sério:
- Invalidar a qualquer alteração. Qualquer edição depois de uma aprovação devolve a cadeia. Seguro, e irritante quando a edição era uma gralha num número de telefone.
- Invalidar em alteração material. Só as edições aos campos e documentos de que a decisão dependia é que a repõem. Mais gentil de usar, e obriga a declarar, antecipadamente, sobre que partes de um caso é que uma decisão assenta.
A segunda é melhor e custa uma conversa que ainda ninguém teve. A primeira é defensável. O que não é defensável é a terceira opção — deixar a aprovação de pé e torcer para que ninguém edite nada.
Aprovação parcial é um estado, não uma folha de cálculo
Quando uma cadeia tem três aprovadores e um já disse que sim, o caso não está «aprovado» e também não está «pendente». Está algures em concreto, e isso precisa de um nome.
Os sistemas a que falta esse estado acabam a segui-lo fora de si próprios — uma coluna algures, uma convenção sobre assuntos de e-mail — e a partir daí o estado real de um caso vive em dois sítios que discordam. Nomeá-lo no fluxo não custa nada e elimina o sistema paralelo.
O que um bom registo de aprovação contém
Seis coisas, e se faltar alguma vai senti-lo na primeira contestação:
- Quem decidiu.
- O que decidiu — aprovou, recusou, ou devolveu para correcção.
- Quando.
- Contra o quê: o estado do caso naquele momento.
- A sua posição na cadeia, e quem estava à espera atrás dele.
- O comentário que deixou, sobretudo numa recusa.
A quarta é a que mais vezes falta e é a que faz o trabalho. Sem ela tem um nome e uma data agarrados a uma coisa que entretanto mudou de forma — o que não é o registo de uma decisão, é o registo de que houve uma decisão.