La RPA est un parcours,
ce n’est pas qu’un projet

Les outils RPA de plusieurs fournisseurs ont évolué du stade de simples robots de station de travail à des logiciels d’entreprise complexes. Mais dans de nombreuses entreprises, la perception de la technologie RPA n’a pas réussi à tenir le rythme, car les fournisseurs sélectionnés ne pouvaient pas satisfaire les exigences informatiques et architecturales. Architecture Informatique : il y a une prise de conscience générale que les services informatiques ont besoin de nouvelles technologies pour être conformes aux critères d’architecture. Par exemple : technologie ouverte & extensible, stable et bien documentée ; compétences communes et solide conformité en matière de sécurité. Les outils RPA ne doivent pas faire exception. Architecture de Processus Opérationnels (BPA) : l’outil RPA sélectionné doit être capable d’automatiser tous les processus opérationnels clés. Que ce soit dans des environnements virtuels, en utilisant l’OCR, en faisant appel à l’intelligence cognitive etc. La BPA définit et documente ces processus clés, ainsi que les relations et les interdépendances, en en faisant un cadre parfait pour compiler les critères de sélection d’un fournisseur.

Le sens de la POC n’est pas de confirmer que la technologie RPA fait ce qu’elle prétend faire. L’objectif principal de la POC est de tester les hypothèses des études de cas, de valider le meilleur modèle de mise en œuvre et d’évaluer l’intégration RPA et les partenaires technologiques. Pourtant, pour de nombreuses entreprises, confirmer les capacités de la RPA demeure l’objectif de la POC.. Cette erreur amène traditionnellement à des circonstances dans lesquelles la POC ne prouve pas grand-chose, n’est pas exploitable et ralentit souvent l’élan RPA. Elle ne prouve pas grand-chose car un grand nombre d’études de cas confirme déjà que la technologie fonctionne. Elle n’est pas exploitable parce qu’une POC qui valide la RPA ne donne pas de visions sur son fonctionnement dans une entreprise spécifique. L’élan est stoppé parce qu’il n’y a pas de prochaine étape évidente. La POC doit être conçue pour poser les fondations de l’étape Pilote plus décisive dans ce parcours, et donner les réponses et les validations nécessaires pour l’accord d’aller plus loin dans l’Essai.

Des pipelines RPA mal gérés font qu’on se retrouve avec des candidats très difficiles pour des processus d’automatisation. C’est peut-être de l’excès de confiance, car on pourrait dire « La RPA ne sert à rien! ». Ou ce pourrait être une décision subjective de choisir un problème hautement complexe plutôt que des possibilités d’économies plus simples. Dans les deux cas c’est une erreur d’abandonner des priorités rigoureuses. Pour la première année du parcours de RPA, les processus sélectionnés doivent être de difficulté basse ou moyenne pour démontrer un potentiel cumulé d’économie d’1 ETP.

Certaines entreprises se retrouvent tellement engluées dans l’idée d’un processus entièrement automatisé de bout-en-bout qu’elles négligent la réalité de rendements décroissants. D’autres se focalisent tellement sur l’automatisation des étapes complexes des processus qu’elles ne pensent jamais à les supprimer en faisant une refonte de ces processus. Il est important de se rappeler de la nature peu coûteuse et peu invasive de la RPA. Contrairement à d’autres technologies d’automatisation, elle peut générer un ROI élevé avec une automatisation partielle des étapes du processus. Essayer de trop étendre l’automatisation dans un processus peut faire baisser le ROI en augmentant significativement les coûts de mise en œuvre. De la même manière, l’optimisation d’un processus est souvent une façon plus intelligente de faire des économies que configurer un robot pour des règles compliquées.