Une automatisation utile commence par une situation précise. Le bon sujet n’est pas forcément le plus spectaculaire : c’est celui dont les entrées, les décisions et la suite peuvent être observées.

Décrire un passage, pas un département.

« Automatiser l’administration » ne définit pas un chantier. « Rattacher les bons de livraison reçus à leur dossier transport » permet déjà d’identifier une entrée, une action et une sortie.

Choisissez une tâche que l’équipe peut montrer sur des exemples récents. Notez où elle commence, ce qui doit être retrouvé et comment la personne sait qu’elle est terminée.

Regarder les exceptions avant le volume.

Un flux fréquent n’est pas automatiquement un bon candidat. Les cas ordinaires, les documents difficiles et les décisions qui demandent du contexte doivent être examinés ensemble.

Les situations ambiguës ne sont pas une note de bas de page. Elles définissent le circuit de contrôle humain et les limites de l’automatisation.

  • Quelles informations peuvent manquer ?
  • Qu’est-ce qui peut se contredire ?
  • Qui tranche aujourd’hui ?
  • Que se passe-t-il si le traitement arrive trop tard ?

Vérifier les accès et les responsabilités.

L’information existe-t-elle dans une source autorisée ? L’outil de destination permet-il la modification attendue ? Un responsable est-il désigné pour chaque décision ?

Le périmètre doit être possible dans les outils et les droits réellement disponibles. Une démonstration sur un fichier isolé ne répond pas à ces questions.

Mesurer avant de décider.

Relevez le temps consacré à la tâche, sa fréquence, les reprises et les coûts de contrôle. Comparez ces observations au coût et aux contraintes du chantier.

L’audit 6x37 doit pouvoir conclure à un périmètre plus petit, à une préparation préalable ou à l’absence d’intérêt du chantier. Le développement n’est pas une décision prise d’avance.

Explorer la solution ou la méthode
Toutes les publications