Demandez à la plupart des équipes si elles ont un processus d’approbation et elles diront oui. Puis demandez-leur de vous montrer la dernière approbation qu’elles ont donnée, qui l’a approuvée, ce qu’elles ont vu au moment de l’approuver, quelle version elles ont validée, quand exactement ça s’est passé, et regardez la confiance s’évaporer de la pièce.
La vérité est que la plupart des « processus d’approbation » ne sont que des habitudes. Quelqu’un montre quelque chose à quelqu’un d’autre, l’autre personne dit quelque chose comme « ça me semble bien », et c’est considéré comme approuvé. Ce qui fonctionne bien jusqu’à ce que le client demande pourquoi le texte a changé, ou que le service juridique signale quelque chose qui n’a jamais été examiné, ou que deux personnes se souviennent de la même conversation de façon complètement différente.
Nous avons vu ce scénario dans des agences, des équipes opérationnelles, des services RH, des services clients, partout où le travail nécessite une validation humaine avant d’avancer. La version informelle de l’approbation est tellement répandue que la plupart des gens ne la considèrent même pas comme un problème jusqu’à ce qu’ils soient au milieu d’un malentendu très coûteux.
L’approbation qui vivait dans un fil de discussion
Voici un scénario plus courant que quiconque ne voudrait l’admettre. Une agence envoie un projet à un client. Le client répond dans un fil d’e-mail : « Ça semble bien, allez-y. » Le chargé de compte interprète cela comme une approbation finale. Trois semaines plus tard, quand la campagne est en ligne, le client dit qu’il n’a jamais approuvé la version finale, seulement le projet. Il y a maintenant un litige, des appels très tendus, et une relation qui est un peu moins bonne qu’avant.
Personne n’a menti. Personne n’agissait de mauvaise foi. Le processus d’approbation était juste trop vague pour protéger l’une ou l’autre des parties. Il n’y avait aucune trace de ce qui avait été vu exactement, quand et par qui. Un emoji pouce en l’air dans un fil d’e-mail n’est pas un contrat, mais pour beaucoup d’équipes, c’est tout comme.
À quoi ressemblent réellement les approbations structurées
Nous avons intégré des workflows d’approbation dans Gript pour que, quand quelque chose nécessite une validation, tout le processus se passe à l’intérieur du travail, pas dans un canal parallèle que personne ne peut retracer après.
Vous assignez un réviseur. Il reçoit une notification. Il voit l’élément réel, dans son contexte complet, avec tout ce dont il a besoin pour prendre une décision. Il approuve ou rejette, avec un commentaire optionnel. Cette décision est enregistrée, horodatée, et visible pour tous ceux qui ont accès au tableau. Terminé.
Pas de relances. Pas d’ambiguïté. Pas de conversations « attends, avons-nous eu l’approbation pour ça ? » le matin d’un lancement.
La partie que les gens n’anticipent pas avant d’en avoir besoin : la trace
Au-delà du fait que les approbations se passent proprement, les workflows structurés vous donnent quelque chose que les approbations informelles ne peuvent jamais offrir : un enregistrement. Pas parce que vous êtes paranoïaque, mais parce que dans trois mois, quelqu’un va poser la question. Quelqu’un pose toujours la question.
« Qui a approuvé ça ? » « Le service juridique a-t-il examiné la version finale ? » « Quand le client a-t-il approuvé le changement de périmètre ? » Si vous avez un workflow d’approbation structuré, vous pouvez répondre à ces questions en une dizaine de secondes. Sinon, vous faites défiler de vieux messages Slack en espérant que la réponse est quelque part.
Nous avons construit cette fonctionnalité en partie parce que nous en avons eu assez de voir de bonnes équipes se retrouver dans des problèmes évitables, non pas parce qu’elles étaient désorganisées, mais parce que leur processus d’approbation vivait quelque part où personne n’avait pensé à regarder. Le ramener dans le travail lui-même avait tout son sens.