Le sens de la décision
Une validation doit rendre la décision traçable, pas seulement accélérer les rappels. Définissez l'objet approuvé, la version examinée et les conséquences. Une modification ultérieure peut nécessiter une nouvelle décision ; sinon, l'historique décrit un objet que personne n'a validé.
Rôles et alternatives
Commencez par les rôles et leurs limites. Une petite équipe peut utiliser une file commune avec décisions enregistrées. Un autre circuit exigera délégation, escalade et séparation entre demandeur et valideur. Précisez les règles d'absence et d'expiration. Le silence ne vaut pas accord sans règle métier explicite.
Parcourir le changement
Dans un achat fictif, un salarié soumet fournisseur, montant et justification. Le responsable valide cette version. Si le service achats change le fournisseur, une nouvelle revue s'impose. En son absence, un délégataire nommé reçoit la demande avec une trace de délégation. Distinguez attente, accord, refus et version remplacée.
Vérifier les échecs
La livraison d'un courriel ne prouve pas l'accord. Des clics répétés ne doivent pas créer plusieurs commandes. Enregistrez durablement la décision et rendez l'action finale répétable sans doublon. Testez retrait, refus, ancien onglet et validations simultanées. Toute correction doit expliquer le changement au lieu d'effacer le passé.
Conserver une décision que chacun peut reconstituer
Séparez demande, décision et commande résultante. Donnez une identité à chacune et gardez la version examinée. Enregistrez personne, pouvoir à cet instant, date et justification requise. L'historique doit permettre de comprendre les faits sans ouvrir une messagerie privée ni deviner la pièce jointe courante.
Parcourez les actions concurrentes avec l'exploitation. Deux valideurs peuvent ouvrir la même version ; le premier rend la seconde vue obsolète. La seconde action doit expliquer son résultat sans écraser. Une demande retirée ne doit pas devenir commande par clic tardif. Précisez si toutes les validations sont nécessaires, si un refus termine le circuit et quels changements réinitialisent les accords.
Distinguez problème de règle et problème de transmission. Un achat approuvé mais non reçu par le système reste approuvé, avec exécution en attente ou échouée. Redemander l'accord confond autorisation et transport. Répétez uniquement l'opération manquante avec une identité empêchant les doublons. Prévoyez une réparation contrôlée et tracée, puis vérifiez la commande obtenue. Examinez les dérogations pour repérer une exception légitime récurrente.
Une matrice d'acceptation courte
| Cas | Preuve à examiner |
|---|---|
| Fournisseur modifié après accord | La nouvelle version exige une revue ; l'ancienne décision n'autorise pas le remplacement. |
| Deux valideurs simultanés | Les résultats sont clairs, sans écrasement ni commande supplémentaire. |
| Échec du message après accord | La décision subsiste ; la reprise n'ouvre pas une nouvelle validation et ne répète pas l'achat. |
| Délégation expirée | L'action suivante vérifie le pouvoir actuel et refuse la délégation expirée tout en conservant les actes antérieurs légitimes. |
Convenir de ces règles
Qui demande, décide, délègue et déroge ? Quelles modifications annulent l'accord ? Que se passe-t-il à l'échéance ? Apportez une demande courante et une exception contestée à la discussion sur l'automatisation, avant de dessiner les écrans.