Architecture de l'automatisation des achats

Que signifie réellement l'automatisation des achats ?

"L'automatisation des achats" couvre un ensemble d'approches, allant de l'automatisation des flux de travail basée sur des règles quichemine une demande d'achat à travers une chaîne d'approbation fixe, à l'automatisation des processus par la robotique (RPA) qui manipule les écrans existants comme le ferait un humain, jusqu'à l'automatisation intelligente qui intègre une logique de compréhension ou de rapprochement de documents. Les recherches évaluées par des pairs décrivent la RPA comme l'utilisation de programmes logiciels low-code pour automatiser les processus métier répétitifs et routiniers, et la qualifie de technologie dont la croissance est la plus rapide dans la catégorie des logiciels d'entreprise. Aucune de ces approches ne remplace le processus procure-to-pay ; elles s'y intègrent, chacune prenant en charge une étape spécifique et bien définie, ce qui explique pourquoi la question pertinente est de savoir quelles étapes de ce architecture de la chaîne procure-to-pay sont suffisamment routinières pour être confiées à un logiciel et lesquelles nécessitent encore le jugement d'une personne.

Quelles étapes du flux de travail sont automatisées en premier, et pourquoi ?

Quatre étapes reviennent fréquemment comme des candidates privilégiées à une automatisation précoce, car chacune présente un volume élevé, est régie par des règles et débouche sur un résultat clair de réussite ou d'échec : l'acheminement et l'approbation des demandes d'achat, le rapprochement tridirectionnel entre le bon de commande, le reçu et la facture, l'émission du bon de commande une fois la demande approuvée, ainsi que le traitement des exceptions de facturation pour les anomalies signalées par le rapprochement tridirectionnel. L'analyse comparative actuelle des achats révèle que l'automatisation améliore la capacité à tirer parti des remises sur volume, à consolider les achats et à réduire les coûts ainsi que les erreurs liés aux tâches manuelles, ce qui est le cas si l'on considère ces étapes comme un point de départ plutôt que comme l'ambition totale. Le même travail de benchmarking ajoute une condition qu'il convient de prendre au sérieux : la standardisation des processus contribue à garantir que la recherche de rapidité ne se solde pas par une augmentation des erreurs, donc l'automatisation d' flux de travail des bons de commande qui n'est pas encore standardisé ne fait qu'accélérer l'incohérence, car la standardisation doit avoir lieu en amont ou en parallèle de la conception.

Quels contrôles le parcours automatisé doit-il préserver ?

Deux principes de contrôle sont repris sans modification des achats manuels, et un flux de travail automatisé doit les exprimer par logiciel plutôt que de supposer qu'ils survivent à la migration. Le premier est la séparation des tâches : les directives fédérales de contrôle font autorité en la définissant ainsi : répartir les tâches et responsabilités clés entre différentes personnes afin de réduire le risque d'erreur, de mauvaise utilisation ou de fraude, en séparant les responsabilités d'autorisation des transactions, de traitement et d'enregistrement, d'examen des transactions et de gestion des actifs associés, de sorte qu'aucun individu ne contrôle tous les aspects clés d'une transaction ou d'un événement. Le second est l'autorisation : les transactions sont autorisées et exécutées uniquement par des personnes agissant dans les limites de leurs attributions. Dans un processus manuel, cela se traduit par des personnes distinctes traitant un bon de commande à des bureaux différents. Dans un processus automatisé, ces éléments doivent apparaître sous la forme d'un modèle de rôle, d'une configuration de seuil d'approbation et d'une carte des permissions qu'un robot ou un moteur de flux de travail ne peut pas contourner silencieusement sous prétexte qu'il peut techniquement écrire dans tous les champs qu'il peut atteindre.

Comment planifier le déploiement d'une approche axée d'abord sur la gouvernance ?

Où les intégrations ERP existantes échouent-elles réellement, et d'où proviennent les silos de données ?

Le point de connexion entre une plateforme d'automatisation des achats et l'ERP est l'endroit où se concentre le risque de gouvernance en pratique. C'est également là qu'un silo de données se crée si l'automatisation conserve sa propre copie distincte des données de fournisseurs, de budget ou d'approbation au lieu de traiter l'ERP comme le référentiel unique. Le guide d'intégration d'un éditeur d'automatisation formule clairement le risque d'accès : un connecteur doté d'un accès plus large que ne l'exige sa fonction peut lire des données qu'il ne devrait jamais voir et modifier des champs qu'il ne devrait jamais toucher. Un accès étendu est généralement accordé par commodité lors de la configuration, et non parce que le flux de travail en a besoin, et il convient de le considérer comme un point de contrôle fourni par le fournisseur à tester plutôt que comme une simple affirmation concernant le produit d'un fournisseur particulier. Le même guide mentionne un deuxième mode de défaillance, plus discret : une piste d'audit qui couvre les actions humaines mais laisse les décisions automatisées sans enregistrement est incomplète et générera des non-conformités lors de tout audit sérieux. Si un robot approuve une facture, cette décision nécessite le même enregistrement que l'approbation d'une personne : quelle logique a été appliquée, quelles données ont été utilisées et quel a été le résultat.

Pourquoi une automatisation non vérifiée coûte-t-elle plus cher qu'elle ne permet d'économiser ?

La tentation est grande de considérer l'automatisation comme un simple problème de déploiement : configurer l'outil, l'appliquer au processus et le lancer. Les recherches fondamentales sur la vérification des flux de travail mettent en garde contre l'omission de l'étape intermédiaire. En étudiant de manière générale les systèmes de gestion des flux de travail, les chercheurs ont constaté que les conséquences, cependant, sont que peu de flux de travail sont rigoureusement vérifiés avant d'être déployés dans la pratique, ce qui entraîne souvent la nécessité de corriger les erreurs de manière ponctuelle et souvent à des coûts prohibitifs. Cette constatation précède de deux décennies les plateformes d'automatisation low-code d'aujourd'hui, et le problème sous-jacent n'a pas disparu : la spécification d'un flux de travail est un élément logique, et une logique qui n'a pas été vérifiée quant aux choix, séquences et exceptions qu'elle doit réellement gérer échoue de la même manière qu'un humain ou qu'un bot l'exécute, à ceci près que le bot échoue plus rapidement et à plus grande échelle. Les langages de spécification des flux de travail doivent prendre en charge la spécification des moments de choix, de l'exécution séquentielle, du parallélisme, de la synchronisation et de l'itération. précisément parce que les processus réels ont besoin de tout cela, et qu'un projet pilote qui n'exerce que le chemin nominal n'a pas du tout vérifié le flux de travail.