Cette semaine, j’aborde l’un des points clés de la mise en production de la RPA : comment bien définir les responsabilités et gérer les exceptions une fois le lancement de processus dans l’environnement de production.

Une fois développé et testé, le processus est déployé en production. Et la responsabilité pour le processus passe du développeur au contrôleur du processus (process controller).

L’intérêt du manuel opérationnel

Le manuel opérationnel est constitué par l’analyste et le développeur et sert de passage de témoin de responsabilités, entre le développeur ou créateur du processus et le contrôleur de processus qui supervise la main-d’œuvre numérique.

Véritable mode d’emploi du processus, le manuel opérationnel détaille les différentes tâches traitées par le processus, les résultats attendus (ou output), ainsi que les éléments de planification, les différents paramètres possibles du processus et le mode opératoire de gestion des exceptions.

D’ailleurs, même si le processus est exécuté par l’équipe de production RPA, souvent rattachée au centre d’excellence (CoE) interne, les résultats demeurent la responsabilité du métier commanditaire.

Le process controller : un rôle pivot

Le contrôleur de processus ou process controller est un rôle central, de l’équipe de production RPA. Il supporte et administre quotidiennement l’exécution des processus dans l’environnement de production.

Il s’assure de la bonne planification et exécution des processus, de la stabilité de l’environnement technique et investigue les problèmes identifiés en production ainsi que les exceptions impactant la performance du processus (ouverture de ticket auprès du support technique ou identification de demandes d’évolution).

L’évolution des processus automatisés en production est essentielle à la pérennité et à l’efficacité du programme. Cette évolution peut être dictée par une modification des systèmes (nouvelle version du système d’information cible par exemple) mais aussi du processus métier lui-même (nouvelles dispositions réglementaires, nouvelles étapes dans le processus).

La responsabilité des évolutions fonctionnelles et techniques des processus revient aux leads métier et IT respectivement, afin de garantir une prise en compte de ces évolutions le plus en amont possible, et à minima avant qu’elles impactent le processus automatisé.

Attention aux raccourcis, pas compatibles avec l'industrialisation de la RPA

On pourra être tenté, surtout au démarrage du programme RPA lorsque les différents rôles sont encore en cours de définition, de demander au process controller de modifier les processus en production pour résoudre les exceptions, souvent mineures, identifiées.

Cette approche ne permet ni l’industrialisation du programme RPA, ni la sécurisation de la chaîne de production. Il est préférable d’adopter une mécanique contrôlée de remontée des exceptions à l’équipe de développement afin que toutes les modifications suivent toute la chaîne de mise à jour des processus développés.

Cette approche permet aussi de s’assurer que l’environnement de production demeure toujours identique à celui de développement et facilite à son tour la maintenance à long terme.

Le contrôleur de processus pourra participer à la dernière série de tests fonctionnels (aussi connu sous le nom de user acceptance testing ou UAT), afin de s’imprégner en amont des nouveaux processus ou de valider les modifications apportées à la suite de ses retours.

Vous voulez en savoir plus ?

Formez-vous au rôle de contrôleur de processus sur Blue Prism University. Créez un compte gratuit ou connectez-vous pour y accéder.

La RPA en toute transparence

Dans cette série sans interdits, nous abordons la RPA en toute transparence, des vrais avantages de la solution au choix des processus à automatiser pour un impact maximal, en passant par les bonnes pratiques de mise en place.