Tout ce que vous devez savoir sur la réingénierie des processus d’affaires

By Kate Eby | 26 October 2016 (mis à jour 4 août 2023)

De nos jours, la description de poste de chaque professionnel comprend l’amélioration des performances en termes de coût, de service et de qualité pour son entreprise. En réponse, la réingénierie des processus d’affaires (RPA) connaît une résurgence moderne. Bien que l’application de méthodologies de RPA puisse améliorer considérablement les processus, vous devrez toujours faire face à de nombreux défis et décider des éléments essentiels qui peuvent contribuer au succès ou à l’échec de la transition.

Dans cet article, nous allons examiner les concepts de base de la RPA, sa méthodologie, son cycle de vie, ses objectifs, les résultats et avantages attendus, et son histoire. Nous discuterons ensuite des critiques de la RPA, des facteurs prédisant le succès et l’échec de la RPA, et de la façon dont il s’intègre à vos technologies de l’information et à vos systèmes d’information existants. Nous examinerons également les perspectives de la combinaison des RPA avec d’autres méthodologies telles que Lean et Six Sigma, et parlerons de l’avenir de la RPA et de la façon dont vous pouvez et devriez l’appliquer dans votre entreprise. De plus, nos experts en RPA donnent leurs informations précieuses.

Qu’est-ce que la réingénierie des processus d’affaires ?

La réingénierie des processus d’affaires est une approche structurée visant à améliorer les performances d’une entreprise dans des domaines tels que les coûts, le service, la qualité et la rapidité grâce à des changements dans les processus (appropriés). Cette méthodologie de changement radical commence au niveau le plus élevé d’une entreprise et fonctionne dans les moindres détails pour réviser le système en peu de temps. En tant que refonte complète, la RPA diffère des autres méthodologies où les améliorations progressives résultent des mises à jour régulières des processus. Les entreprises qui subissent des RPA doivent réévaluer leurs fondamentaux et réformer leurs processus dans le but de la standardisation et de la simplification.

Les entreprises ambitieuses qui mettent en œuvre la RPA commencent par faire tout ce qu’il faut pour améliorer les performances de l’ensemble de l’entreprise. Voici des exemples d’objectifs spécifiques à une entreprise grâce à la RPA :

  • Prendre un processus décentralisé et nommer une personne qui en sera responsable

  • Redévelopper les objectifs de l’entreprise afin que les plans d’amélioration soient cohérents

  • Prendre un processus spécifique à un service et lui attribuer la coordination et l’intégration transversales

  • Passer d’une perspective produit à une perspective de processus

Le terme « réingénierie » suggère qu’un élément a déjà été développé et est en cours de redéveloppement. Dans ce cas, les processus de l’entreprise sont en cours de réaménagement. Les processus opérationnels sont les ensembles d’activités qui mènent à des objectifs ou des résultats spécifiques. Ils sont généralement effectués régulièrement et systématiquement. Dans la plupart des entreprises, les changements apportés à un processus pré-existant se produisent relativement lentement et progressivement. Avec la RPA, cependant, les outils les plus modernes sont utilisés à partir de la base, car l’entreprise repense les fondamentaux des processus, des idées et des conceptions existants.

Le terme « processus » se concentre sur la façon dont le travail est fait, et non sur les personnes spécifiques, leurs descriptions de poste ou les tâches qu’elles effectuent. La RPA s’intéresse davantage à la série d’étapes qui produisent le produit ou le service, de la conception à la création.  

La RPA peut apporter des améliorations considérables à la qualité et à la productivité de l’entreprise. Cependant, étant donné que la participation et l’implication des employés sont requises, la mise en œuvre de la RPA peut être très coûteuse et prendre beaucoup de temps. Une alternative à l’approche traditionnelle des réunions constantes est un logiciel d’aide à la décision de groupe (GDSS), qui aide à résoudre les problèmes non structurés ou semi-structurés en fournissant des plateformes de collaboration pour la génération d’idées et l’organisation, la résolution des conflits, la définition des priorités et la génération de solutions.

Un autre terme pour un GDSS est un système de travail collaboratif informatisé. La RPA est également connue sous le nom de refonte des processus opérationnels, de transformation de l’entreprise ou de gestion des changements de processus opérationnels.  

Méthodologie de cycle de vie de reingénierie des processus (PRLC)

Source :  Kai Simon

L’une des méthodologies les plus récentes proposées pour la RPA est le cycle de vie de reingénierie des processus (PRLC). Les six étapes séquentielles comprennent :

  1. L’examen de nouveaux processus

  2. L’initiation du changement

  3. Le diagnostic des processus

  4. La refonte des processus

  5. La reconstruction

  6. Le suivi des processus

Le PRLC préconise de revenir en boucle au début pour diagnostiquer les processus qui ont à nouveau besoin de changement.

Cela signifie que votre entreprise :

  • Examinera toutes les tâches qui fonctionnent pour atteindre le même objectif et les combinera.

  • Hiérarchisera le travail à l’endroit le plus logique. Les processus parallèles qui donnent le même résultat seront liés dans le processus, et non à la fin.

  • Se débarrassera des systèmes de contrôle inutiles et fera en sorte que les ressources du processus fournissent les données nécessaires.

Les objectifs de la réingénierie des processus d’affaires

Lors de la conception d’une méthodologie de RPA, l’entreprise doit prendre en compte son objectif. Lors de sa première introduction, le RPA s’est concentré sur le service à la clientèle, la vitesse, la compression, la flexibilité, la qualité, l’innovation et la productivité. Mais pour attirer les industries fortement réglementées et multinationales, Jochen Martin a remanié les objectifs de la RPA en 2011. Ils comprennent désormais la réduction des contacts, l’élimination des tâches, l’automatisation des tâches, l’intégration des processus, la réduction du temps d’attente, la qualité des données et l’exhaustivité des données. Ces objectifs se concentrent davantage sur la gouvernance et la conformité, et ils ont contribué à rebaptiser RPA sous le nom degestion des processus d’entreprise, le rendant à nouveau pertinent.

 

Jeff Tindall

According to Jeff Tindall, CSSLP, and Managing Director at Tindall Media, “‘We've always done it that way’ is one of the most dangerous phrases for any business. If you are not continually challenging yourself, then you are at risk to have the market pass you by. People and industries are becoming more receptive to market disruptors, and it is a real risk to new and established businesses.

« La refonte des processus opérationnels (RPA) est un élément essentiel pour toute entreprise saine. Je trouve très utile de réunir une équipe qui comprend de nouvelles personnes avec des perspectives différentes qui peuvent voir les choses sous un nouvel angle et fournir de nouvelles idées ». Il est également important d’inclure des experts en la matière qui restent au courant des changements du marché et des avancées technologiques.

« Changer pour changer » peut être tout aussi dangereux que « garder la même façon de faire ». Avant de commencer une RPA, assurez-vous de définir vos objectifs. Une analyse SWOT peut être utile pour identifier vos faiblesses et opportunités. C’est généralement un bon endroit pour concentrer vos efforts initiaux. Au fur et à mesure que vous développez vos nouveaux processus, réfléchissez à la façon dont vous mesurerez leur succès et à l’endroit où vous pourrez saisir ces données tout au long du processus.

« N’ayez pas peur d’expérimenter. Il existe de nombreuses options qui permettent le prototypage rapide de nouvelles solutions. Un prototype ou un projet pilote est un excellent moyen de tester une hypothèse sans faire un investissement important. Certaines des meilleures idées peuvent être effrayantes et risquées. Utilisez des prototypes et des pilotes comme point de contrôle pour atténuer vos risques ».

Des résultats et avantages attendus de la réingénierie des processus d’affaires

Beaucoup d’entreprises ont diminué leurs effectifs lors de la première vague de RPA, principalement en raison de l’introduction de la technologie de l’information. Les processus qui dépendaient de nombreux employés ont été réorganisés pour qu’ils aient besoin de moins, voire d’aucune personne pour les exécuter. Aujourd’hui, un projet de RPA suppose que la technologie est inhérente à l’entreprise, mais qu’elle peut nécessiter des mises à jour ou des améliorations. Les avantages et les résultats attendus ou la mise en œuvre de la RPA sont désormais :

  • Une efficacité accrue ; identifier les fonctions essentielles ainsi que celles qui sont inefficaces ou obsolètes

  • La réduction du coût global et du temps de cycle

  • Un travail utile pour le personnel ; le processus favorise une plus grande implication du personnel

  • Une amélioration de l’approche organisationnelle ; réaliser des règles commerciales du passé, ce qui réduit le temps d’activité des nouveaux produits et des processus

  • Une orientation commerciale plus solide

  • La croissance de l’entreprise ; améliorer la position de l’industrie grâce à des améliorations radicales

  • L’augmentation de la clientèle

  • Une structure d’entreprise démesurée, ce qui responsabilise les employés

Quels problèmes la RPA peut-elle résoudre pour votre entreprise ?

Pour aider votre entreprise à prospérer dans un environnement plus dynamique et changeant, vous devez prendre en compte sa structure et son comportement. La plupart des organisations visent à améliorer constamment les performances tout en réduisant le coût de leurs services et de leurs produits. Pour ajouter de la valeur à vos clients, vous devez d’abord comprendre leurs besoins. La RPA peut aider votre entreprise à évoluer et à résoudre ces problèmes :

  • Coûts opérationnels élevés

  • Plaintes des clients concernant une diminution de la qualité

  • Engorgements

  • Les cadres moyens affichent de mauvaises performances

  • Mauvaise répartition des ressources ou des tâches

  • Ne pas suivre la concurrence

  • Le retour sur investissement continue de diminuer, malgré les investissements en capital dans les processus actuels

  • Les améliorations progressives augmentent la complexité et les coûts du processus

  • Des processus considérablement brisés qui ont besoin de plus que de simples corrections

  • La responsabilité fragmentée des processus qui entraînent un manque de responsabilisation et de résolution de problèmes

L’histoire de la réingénierie des processus d’affaires

Michael Hammer a présenté la RPA pour la première fois dans un numéro de 1990 de la Harvard Business Review. Diplômé et professeur au Massachusetts Institute of Technology (MIT), Hammer voulait que les entreprises redessinent leurs opérations, et pas simplement en utilisant des ordinateurs pour accélérer les processus inefficaces. Son approche reflétait les exigences plus plates et plus centrées sur le client en matière d’âge de l’information et a tout changé au sein de l’entreprise, non seulement les processus, mais aussi les personnes, les responsables, les emplois et les valeurs.

Depuis lors, l’environnement moderne de l’entreprise est devenu hyperconcurrentiel et mondialisé, avec des clients exigeants et un accent nécessaire sur la gestion et l’innovation informatique, la réactivité, la rapidité et la qualité. Par conséquent, les entreprises ont dû chercher des moyens radicaux de livrer. Hammer a suggéré d’utiliser l’informatique pour examiner les hypothèses derrière les processus. Il s’est associé à James Champy pour le livre Reengineering the Corporation: A Manifesto for Business Revolution pour présenter leur méthodologie globale.

À peu près au même moment, Thomas H. Davenport et James E. Short du MIT ont publié un article sur la refonte des processus commerciaux. Leur version de la RPA plaçait l’informatique au cœur. Ils ont détaillé le travail en cours au MIT, à Harvard et dans plusieurs sociétés de conseil, et ils ont mis au point une approche à suivre pour d’autres. Bien que toujours en faveur d’un changement radical, leur stratégie de RPA était plus modeste, tempérée par la discipline de l’amélioration continue. Ils ont recommandé de sélectionner les processus les plus critiques, puis de les analyser et de les redessiner de façon itérative.

Grâce à ces efforts, les grandes entreprises se sont engagées à lancer leurs propres projets de RPA. Ils s’intéressaient à la façon de produire leurs marchandises plus rapidement. En 1993, on estime que 65 % des entreprises du Fortune 500 prétendaient avoir lancé ou prévu des efforts de RPA.    

En 1994, l’Informatics Process Group (IPG) de l’université de Manchester a introduit la méthodologie d’analyse et de conception des processus (PADM), un cadre pour les outils et techniques de RPA. Le PADM est issu du livre de recettes de modélisation des processus, qui décrit deux phases de technique  : la représentation et le raffinement. Les deux cadres offrent une amélioration continue et itérative des processus pour la RPA. Le PADM, cependant, essaie de gérer la relation entre la technologie et les processus.

Le PADM reconnaît que la relation entre l’informatique et le processus est réciproque : les changements dans l’informatique peuvent nécessiter des changements dans le processus, et les changements dans le processus peuvent nécessiter des changements dans l’informatique. L’ancienne méthode, qui préconisait un modèle centré sur l’informatique, s’est évanouie. Dans son livre Process Reengineering: The Key to Achieving Breakthrough Success, Lon Roberts a poursuivi l’accent mis par Hammer et Champy sur un modèle axé sur le client.   

Une étude d’Aphrodite Tsalgatidou a comparé quatre méthodologies de RPA : Hammer/Champy, Davenport, PADM et Ivar Jacobson. L’étude a comparé si les méthodologies de RPA recommandent une modélisation et une analyse détaillées de la situation en l’état, si elles soutiennent un changement progressif ou radical des processus opérationnels, et si elles suggèrent un examen de l’entreprise avant un projet de RPA. À partir de cette étude, Tsalgatidou a recommandé cinq phases pour un projet de RPA :

  1. Apprendre les processus

  2. Créer la vision de l’entreprise

  3. Modéliser et analyser les processus actuels

  4. Modéliser et analyser les processus futurs (à venir)

  5. Transition vers un effort de processus d’amélioration continue

Cette vague d’optimisme pour la RPA n’a pas duré longtemps. En 1995, le retour de bâton a frappé. Les professionnels qui avaient fortement soutenu l’utilisation de la RPA se sont retournés contre elle. Outre les projets mal réalisés et l’abus du concept, l’utilisation des RPA a diminué. Beaucoup des premiers partisans ont accusé le battage médiatique du concept lui-même.

Mais la RPA n’a pas complètement disparu. Les entreprises n’ont jamais vraiment cessé de retravailler les processus, mais les ont étiquetés différemment, surtout à mesure que l’Internet a gagné en importance. Dans les années 2000, les entreprises voulaient pouvoir offrir plus à leurs clients, et la RPA était un moyen d’y parvenir. Les nouveaux cadres de RPA sont différents de ceux développés dans les années 1990 parce que la technologie et l’Internet sont désormais intrinsèques ; les infrastructures sont en place. La RPA était considérée comme la précurseure du BPM d’aujourd’hui.

Subramanian Muthu, Larry Whitman et S. Hossein Cheraghi ont développé une autre méthodologie contemporaine pour la RPA en 1999. Leur approche consolidée a toujours perturbé une entreprise, mais a été structurée à l’aide d’un modèle glané à partir de cinq méthodologies différentes. Ce diagramme IDEF0 représente les fonctions de processus avec des cases qui indiquent les relations parent-enfant. Ce modèle comprend les étapes suivantes 

  • Préparation à la RPA

  • Cartographie et analyse du processus actuel

  • Conception des processus à venir

  • Mise en œuvre d’un processus de réingénierie

  • Amélioration continue

 

IDEF0 diagram BPR

D’autres sociétés de conseil se sont impliquées dans des méthodologies conçues de RPA qui produiraient de meilleurs résultats au cours des années 1990. Avec de petits ajustements, des entreprises comme Accenture, McKinsey & Company et Bain & Co. voulaient réduire le taux d’échec du projet RPA typique et se concentrer plutôt sur le potentiel de la méthodologie. Ils ont développé leurs propres modèles, avec un succès mitigé.

La RPA est aujourd’hui en cours de réapparition. Les objectifs et l’exécution sont différents ; la RPA n’est plus synonyme d’efforts massifs de réduction des effectifs, et les entreprises l’adoptent à nouveau pour leur avenir.

Aujourd’hui, la transformation Agile et la RPA orientée vers les objets sont largement utilisées et avec succès, en particulier dans le développement et le lancement de systèmes logiciels. La transformation Agile présente de nombreuses similitudes avec la RPA des années 1990, bien qu’elle ne soit pas aussi extrême. La RPA orientée vers les objets dépend de la modélisation des processus d’entreprise, qui présente vos processus comme un visuel complet pour mettre en évidence l’efficacité ou les problèmes. La modélisation peut aider à identifier la progression ou le statut de l’entreprise. Les efforts de modélisation se terminent souvent sous la forme d’un diagramme de flux de données (DFD), qui est une représentation graphique de vos processus à l’aide d’objets simples comme des rectangles, des cercles et des flèches, qui indiquent le chemin des informations.

Selon le livre d’Ivar Jacobson, The Object Advantage: Business Process Reengineering With Object Technology, ce type de modélisation reflète plus étroitement la réalité de l’entreprise. Les « objets » de ce type de RPA sont des occurrences d’informations ou de comportements qui signifient quelque chose pour l’entreprise, comme des clients spécifiques, des factures, des tâches professionnelles ou des événements. Les processus sont modélisés à l’aide de ces objets, ce qui clarifie le fonctionnement interne d’une entreprise. Ensuite, l’entreprise faire l’objet d’une ingénierie inverse ou prospective. L’ingénierie inverse est le modèle commercial existant tel quel. L’entreprise est étudiée et présentée. Dans le cadre de l’ingénierie prospective, l’entreprise ayant fait l’objet d’une rétroconception est repensée à l’aide de nouveaux processus. Dans la modélisation des processus, de nombreux programmes et professionnels utilisent le modèle de processus opérationnels et la notation (BPMN) comme un langage standardisé. Le BPMN peut aider à effectuer le processus de restructuration dans les projets RPA.

The Wealth of Nations (1776) d’Adam Smith est l’un des premiers précurseurs de la RPB. Il a écrit sur la division du travail et l’utilisation de domaines de travail distincts pour augmenter la productivité dans une usine d’épingles. Ses idées montraient une révision du processus qui était inouïe à l’époque, mais qui aurait un pouvoir perturbateur majeur.

En 1820, American Railway a également changé le mode de fonctionnement de l’entreprise. En mettant en œuvre de nouvelles procédures de commandement et de contrôle, l’entreprise a contribué à inaugurer une ère d’industrialisme et de capitalisme en Amérique.

Et en 1880, l’ingénieur mécanique américain Frederick Taylor, en tant que l’un des premiers consultants en gestion, a publié ses idées sur l’efficacité dans les affaires. Son livre The Principles of Scientific Management décrit les principes scientifiques de gestion qui donnent certains ensembles de travail à des employés formés et chargent les responsables de planifier le travail. Son influence et sa consultation ont changé le paysage des affaires et ont créé les bases des grandes réinventions des entreprises.

Les critiques de la réingénierie des processus d’affaires

Il est clair, d’après toute la littérature et les commentaires sur la RPA, qu’elle a eu un impact énorme lorsqu’elle a été introduite pour la première fois dans les années 1990. Il s’agissait d’une méthodologie complémentaire à l’époque où les ordinateurs et les technologies de l’information étaient introduits en masse sur le marché du travail. Il y avait peu de doute quand elle a livré des résultats aussi remarquables. Cependant, Holland et Kumar ont noté en 1995 qu’entre 60 et 80 % des initiatives de RPA ont échoué, bien qu’il soit prouvé que ces chiffres ont considérablement diminué au cours des dernières années. De plus, la RPA s’est taillée la réputation d’avoir causé des licenciements massifs, de sorte qu’elle était extrêmement impopulaire au sein de la main-d’œuvre.

Les principales critiques de RPA :

  • Les méthodologies utilisées pour mettre en œuvre la RPA ne répondent pas à l’évolution du paysage commercial.

  • Il n’y a pas de moyen de valider l’hypothèse que les processus sont le principal facteur limitant les performances ; les attentes sont largement exagérées.

  • La RPA ignore totalement le statut actuel de l’entreprise et suppose que « reprendre à zéro » est préférable.

  • Les changements progressifs peuvent être préférables pour un modèle commercial.

  • Il y a un biais culturel américain extrême dans l’utilisation de la RPA.

  • La RPA ignore les contraintes de l’organisation.

  • La RPA est une entreprise complexe et chronophage.

  • Les projets peuvent échouer.

  • L’adhésion est difficile. La RPA détruit ce que les gens savent et le remplace complètement, ce qui cause du stress.

  • La RPA n’est pas expérimentale, car elle peut nécessiter des ressources dédiées et un coût élevé.

Les critiques à l’égard de la RPA sont certainement difficiles à surmonter. Elles peuvent également être exactes. Il est important que chacun d’entre eux soit abordé avant ou pendant un projet de RPA, mais qu’il comprenne également ce qu’il faut traiter et ce qu’il faut ignorer, en particulier lorsque votre entreprise effectue un projet concurrent de planification des ressources d’entreprise (ERP), qui intègre un logiciel qui traite de vos données. Quelques mythes sur la RPA et l’ERP :

  • La RPA ne s’intègre pas bien aux projets ERP. Chaque fois que vous changez de logiciel, en particulier les logiciels de collecte et d’analyse de données, vos processus devront changer.

  • La mise en œuvre d’un nouveau système ERP améliorera les processus. La réalité est que le logiciel ERP n’est pas un logiciel d’amélioration des processus. Si vos processus sont obsolètes, l’ERP ne les corrigera pas.

  • Concentrez-vous uniquement sur le « à venir » et ne vous inquiétez pas de « l’actuel ». Nous apprenons de nos erreurs passées. Les processus actuels vous indiquent ce qui manque, commencez par là.

  • La RPA n’a pas besoin de gestion du changement organisationnel. La nature même de la RPA demande de bons principes de gestion du changement. Chaque fois que vous faites une amélioration, la gestion des changements doit être en vigueur.

  • Obtenez le logiciel avant le processus de RPA. Vous n’avez pas besoin d’avoir le logiciel d’abord ; vous pouvez réingénier les processus avant de choisir le logiciel.

  • Tous les processus doivent être révisés avant d’obtenir un nouveau système ERP. Vous pouvez simultanément mettre en œuvre l’ERP tout en effectuant la réingénierie de vos processus.

  • Faire l’ERP et la RPA en même temps sera coûteux. Au contraire, vous pouvez les exécuter ensemble pour faire des économies.

Les facteurs de l’échec et du succès de la RPA

Dans l’ensemble, les facteurs à l’origine de l’échec du RPA sont liés à une approche étroite et linéaire et aux écarts de communication entre les parties prenantes du projet. Les professionnels d’aujourd’hui mettent l’accent sur l’utilisation des systèmes d’information pour la RPA, qui s’aligne sur le rôle fondamental de l’informatique dans les affaires.

Pendant la première vague de RPA, Hammer et Champy ont énuméré les raisons suivantes pour lesquelles elle pourrait échouer. Celles-ci ont illustré les climats organisationnels des années 1990, mais sont toujours pertinentes :

  • L’entreprise tente de corriger un processus au lieu de le modifier. La reconnaissance de l’étendue des problèmes de l’entreprise.

  • L’organisation ne se concentre pas sur les processus opérationnels. L’analyse correcte des processus et la définition claire des objectifs.

  • L’entreprise ignore tous les éléments, à l’exception de la refonte des processus (par exemple, la réorganisation, le système de récompense, les relations de travail, la redéfinition de la responsabilité et de l’autorité).

  • Vous négligez les valeurs et les croyances des gens et vous récompensez plutôt les comportements qui présentent de nouvelles valeurs et de nouveaux comportements.

  • Vous êtes prêt à vous contenter de résultats négligeables.

  • Vous suspendez le processus trop tôt.

  • L’équipe impose des contraintes préalables à la définition du problème et à la portée de l’effort de réingénierie.

  • Vous permettez aux cultures d’entreprise et aux attitudes de direction existantes d’empêcher la réingénierie de décoller (par exemple, le consensus, la réflexion à court terme, l’évitement des conflits).

  • Vous essayez de forcer la réingénierie de bas en haut.

  • Vous nommez quelqu’un qui ne comprend pas la réingénierie comme le leader de l’effort. Fournir une formation adéquate au personnel sur les RPA.

  • Vous ne fournissez pas assez de ressources pour réingénier.

  • Vous enterrez la réingénierie dans l’agenda de l’entreprise.

  • Vous répartissez votre énergie sur trop de projets de réingénierie.

  • Vous commencez votre initiative de réingénierie lorsque le PDG est proche de la retraite. Une bonne gestion est requise.

  • Vous ne parvenez pas à distinguer la réingénierie des autres programmes d’amélioration de l’entreprise (amélioration de la qualité, alignement stratégique, dimensionnement des droits, partenariats client-fournisseur, innovation, autonomisation).

  • Vous vous concentrez exclusivement sur la conception et négligez la mise en œuvre, ou vous concevez des processus trop bureaucratiques.

  • Vous essayez de garder tout le monde heureux pendant le processus de réingénierie, mais cela ne satisfait personne. L’adhésion est importante, mais n’oubliez pas que la direction et les employés doivent s’engager à améliorer l’entreprise, et pas seulement leur service.

  • Vous hésitez quand les gens résistent à la réingénierie des changements.

  • Vous faites traîner l’effort trop longtemps. À l’inverse, passez le temps nécessaire pour corriger les processus qui sont obsolètes.

  • Vous ne constituez pas la bonne équipe. Les experts savent qu’il faut plus de travail pour reconcevoir que pour automatiser et que cela en vaut la peine. Ils sont également motivés et comprennent que Excel n’est pas le meilleur outil pour chaque correctif.

  • Vous ne disposez pas d’infrastructures adéquates. Cela peut conduire à l’optimisation ou à la hiérarchisation d’un service ou d’un processus spécifique aux dépens d’un autre.

  • Vous voyez le RPA comme un exercice ponctuel de réduction des coûts.

  • Vous n’avez pas d’œil sur l’industrie externe. L’équipe pourrait se perdre dans la vision future et se concentrer uniquement sur des correctifs d’efficacité internes.

Vous avez toujours toutes les raisons de penser que la RPA réussira lorsqu’elle sera présentée à une organisation aujourd’hui, quel que soit le nombre d’entreprises en faillite et la confusion qui entoure son utilisation. Quel que soit le type d’entreprise, quelques facteurs généraux, avec une attention particulière, pourraient garantir une RPA réussie :

  • Méthodologie éprouvée : utilisez des méthodes qui fonctionnent, surtout si elles ont déjà réussi dans votre entreprise.

  • Analyse de rentabilité : vous devez réfléchir et documenter une raison convaincante d’apporter des changements.

  • Adhésion du personnel : faites venir votre personnel dès le début d’un projet et laissez-le stimuler l’innovation.

  • Composition de l’équipe de la RPA : les initiatives de RPA doivent être parrainées par la direction, de préférence de la part de la haute direction. Ils ont également besoin d’équipes soigneusement choisies avec une connaissance approfondie de l’entreprise ou de la méthodologie. Cela peut signifier la responsabilité de la ligne du projet.

  • Analyse des besoins de l’entreprise : lors de l’analyse, vous devez prendre en compte la stratégie commerciale et les objectifs à long terme de l’entreprise.

  • Infrastructure informatique adéquate : le service informatique doit être en mesure de mettre en œuvre les processus reconçus ; les solutions informatiques seules ne peuvent pas transformer les processus.

  • Une gestion efficace du changement : vous devez gérer les attentes, le calendrier et l’impact sur l’entreprise.

  • Amélioration continue : la seule constante est le changement, comme le dit le vieil adage.

  • Les besoins des clients sont une priorité : la vision des processus axés sur le client doit orienter les pratiques commerciales.

  • Profitez des avantages liés aux coûts : la diminution du coût global rend l’entreprise plus compétitive dans son secteur d’activité.

  • Développez avec une optique stratégique : examinez tous les processus opérationnels, posez des questions pertinentes sur le fonctionnement des processus en l’état et la manière dont ils peuvent être améliorés au fil du temps.

  • Concentrez-vous sur les résultats : les processus doivent aller au-delà des tâches traditionnelles et des limites fonctionnelles.

  • Simplifiez le travail : évaluez objectivement les activités et les tâches afin d’éliminer celles qui ajoutent une complexité inutile et moins de valeur.

 

Ray McKenzie

According to Ray McKenzie, Founder, Principal, and content blogger at Red Beach Advisors, "Business process reengineering and redesign is continuously needed within enterprises and organizations to re-assess a process’s effectiveness along with identifying new, more efficient ways to perform daily functions. BPR is extremely valuable to companies that want to improve how they do business internally and externally and how they drive value to their customers.

« Pour toute organisation qui subit une mise en œuvre d’un examen ou d’une réingénierie des processus, je propose aux entreprises d’intégrer des données à l’appui pour mesurer l’efficacité actuelle des processus et développer des objectifs ciblés pour la mesure. Un processus qui est mis en œuvre pour améliorer le flux de travail, mais qui n’est pas mesuré, n’est pas un processus précis à mettre en œuvre. La mesure de la performance et de l’amélioration est la clé ».

Le facteur humain dans la réingénierie des processus d’affaires

Chaque discussion sur la RPA comprend des sections sur les processus et les aspects de l’informatique. Il serait toutefois négligent de laisser de côté le facteur humain. Tout projet de RPA réussi doit prendre en compte les personnes. Il est essentiel de s’attaquer aux réactions de motivation humaine au changement.

On ne soulignera pas assez que les entreprises doivent s’assurer que leurs employés sont motivés et disposent des ressources dont ils ont besoin pour s’informer sur les nouvelles technologies. Non seulement les processus changent dans la RPA, mais la façon dont les gens pensent et interagissent les uns avec les autres doit également changer. Les programmes d’incitation peuvent être un moyen d’assurer le succès de la RPA.

Comment la RPA est liée aux technologies de l’information et aux systèmes d’information

La technologie de l’information (IT) est un terme qui décrit le matériel, les logiciels et l’infrastructure réseau. Les systèmes d’information (IS) sont plus larges et englobent l’emploi de l’informatique et des systèmes ; il couvre les trois dimensions de l’informatique, de la gestion et de l’organisation. La RPA et l’IT/IS doivent être inséparables. Chaque projet de RPA réussi doit sa réussite relative à l’IT/IS.

Bien que la RPA ait ses racines dans la gestion informatique, il s’agit principalement d’une initiative commerciale. Pourtant, l’informatique a historiquement joué un rôle important dans la RPA, en reliant les responsables des processus et ceux qui le mettent en œuvre. Dans la première itération de la RPA, l’informatique a remplacé certains travailleurs humains dans les processus. Dans la dernière itération de la RPA, l’informatique sert d’infrastructure existante qui peut être optimisée. La mise en œuvre et l’amélioration de l’informatique permettent de gagner du temps et d’améliorer l’exactitude de l’échange d’informations, ce qui crée un avantage commercial. L’IS a permis la collaboration au sein d’une organisation et même au-delà des frontières organisationnelles.

Dans la RPA, l’informatique efficace permet :

  • De partager des bases de données

  • De développer des systèmes experts

  • De mettre en œuvre des réseaux de télécommunication

  • D’utiliser des outils d’aide à la décision

  • De disposer d’une communication de données et d’un service de télécommunication sans fil

  • D’interagir avec les clients sous plusieurs formats

  • D’identifier et suivre les informations et le personnel

  • De calculer à un niveau élevé et en déplacement

À l’inverse, les projets de RPA peuvent être dirigés vers ou agir dans le cadre d’une refonte des IT/IS. Avec les projets RPA, l’IT/IS d’une organisation peut prendre en compte :

  • Les mises à niveau vers la technologie client/serveur

  • La technologie de collaboration/groupware actuelle

  • L’informatique mobile

  • La technologie de capture des données

  • L’intégration des systèmes téléphoniques et informatiques

  • Les services Web et architecture orientée services

  • Le logiciel BPM, technologie d’imagerie ou système de gestion des flux de travail

  • L’ERP, la gestion de la relation client (CRM) ou la mise en œuvre de logiciels de gestion de la chaîne logistique (SCM)

  • La mise en œuvre du DSS, un entrepôt de données, l’intelligence d’affaires, l’exploration de données ou un logiciel de tableau de bord

  • L’évolution des services Internet, des domaines, de l’échange électronique de données ou des systèmes de commerce électronique

Mohammed Alsaigh note que le rôle des systèmes d’information dans la RPA se présente en trois étapes : avant le processus de conception, pendant le processus de conception et pendant la mise en œuvre. Avant le processus de conception, les IS peuvent créer des infrastructures et gérer leurs informations. Au cours du processus de conception, ils peuvent apporter de grandes quantités d’informations, les analyser et améliorer la capacité de l’entreprise à prendre des décisions éclairées. Au cours de la mise en œuvre, ils peuvent être utilisés pour améliorer les processus informatiques et communiquer les résultats continus de la RPA.

Les réussites de la RPA dans le monde réel

Voici des exemples de réussite de la mise en œuvre de la RPA par des entreprises bien connues :

  • Taco Bell a commencé le restaurant sans cuisine. Il est passé d’une entreprise régionale de 500 millions de dollars à une entreprise nationale de 3 milliards de dollars.

  • Hallmark a réduit sa durée de mise sur le marché de trois à quatre mois.

  • Ford a réduit ses effectifs payables de 75 %.

  • Mutual Benefit Life a amélioré l’efficacité de ses souscripteurs de 40 %.

  • Detroit Edison a réduit de 80 % les cycles de paiement des ordres d’exécution.

  • New Life Insurance a réduit le temps de traitement des demandes, passant de 22 jours à 17 minutes en moyenne.

Parmi les autres entreprises qui ont utilisé la RPA pour des révisions majeures, on peut citer IBM, AT&T, Sony, General Electric, Walmart, Hewlett-Packard, DEC, Kraft Foods, Citibank, Northwestern Bank, Bell Atlantic, GTE et Bank of America.

Réingénierie des processus d’affaires : méthodologies et programmes comparables

La RPA a une relation transversale avec de nombreuses autres méthodologies d’amélioration des processus. Il est courant que les cabinets de conseil aient une philosophie à laquelle ils adhèrent. Voici une liste de certaines méthodologies qui se comparent à la RPA, ainsi que leurs caractéristiques communes et leurs points de différenciation.

Gestion totale de la qualité (TQM) : largement considéré comme la mère des méthodes d’amélioration des processus, la TQM est une approche de gestion qui concerne principalement la productivité et les changements qui conduisent à la satisfaction des clients avec la participation de tous les membres de l’organisation. La TQM et la RPA visent tous deux à améliorer l’efficacité, mais là où la TQM se concentre sur l’amélioration continue, la RPA vise les innovations de produits. Bien que la RPA mette l’accent sur l’utilisation de l’informatique, la TQM met en évidence l’utilisation du contrôle statistique des processus. La TQM peut utiliser à la fois des approches descendantes et ascendantes, mais la RPA ne peut aller que du haut vers le bas. La plus grande différence est que la RPA apporte rapidement des changements majeurs, tandis que la TQM déploie de petites améliorations continues au fil du temps.

Six Sigma (SS) : beaucoup disent que la TQM a évolué pour se transformer en Six Sigma, qui est une approche axée sur les données qui se concentre sur la réduction des variations afin d’éliminer les défauts des processus. Son intention est un processus commercial sans erreur. À l’instar de la RPA, le Six Sigma exige de remettre en question le statu quo. Cependant, le Six Sigma utilise une méthode en cinq étapes « aligner et maintenir » pour identifier les causes profondes et ne pas reconcevoir complètement le processus comme la RPA. Les étapes de Six Sigma :

  1. Définir le problème

  2. Mesurer le processus actuel

  3. Analyser la cause des problèmes

  4. Améliorer le processus

  5. Contrôler

En utilisant Six Sigma dans les projets RPA, les entreprises peuvent obtenir :

  • Des outils et méthodes statistiquement significatifs pour développer des processus de qualité et éliminer les variations

  • L’assurance que les améliorations des processus sont axées sur les données, à l’aide de références, de cartes de pointage, de tableaux de bord et de mesures

  • Un langage commun d’amélioration des processus

  • La mise en phase, en veillant à ce que tous les livrables passent par les phases DMAIC (Définir, Mesurer, Analyser, Améliorer et Contrôler)

  • L’élimination des défauts de processus, des ferrailles et des remaniements afin que les coûts diminuent

  • Le niveau de qualité sigma qui compare les processus et représente la voix interne du client

L’utilisation de Six Sigma dans les projets RPA permet l’approche « du client au centre », une stratégie de bout en bout principalement guidée par la voix du client. Il doit permettre la collaboration de tous les segments de l’entreprise, même les partenaires externes, et être bien géré afin de définir le succès. Cette approche doit inclure des représentants ou, au moins, des commentaires du personnel de l’entreprise suivant :

  • Service à la clientèle : les personnes qui sont propriétaires du résultat de la production

  • Ceintures noires ou vertes Six Sigma : permettre la poursuite de l’institution de la SS dans l’entreprise

  • Finances : pour s’assurer que les améliorations permettent d’économiser de l’argent

  • Un consultant externe : en tant que participant objectif

  • Technologie de l’information : pour s’assurer que la technologie peut s’adapter aux améliorations proposées

  • Distribution : pour le point de vue des clients et des produits et l’adhésion

  • Juridique ou personnel responsable des audits : respect des normes juridiques ou de l’entreprise

  • Ressources humaines : assurer suffisamment de personnel et de soutien

Pour intégrer les projets de RPA à une approche DMAIC existante, les entreprises doivent commencer par aligner l’équipe de projet RPA et leurs ressources Six Sigma. De cette façon, vous pouvez identifier les opportunités Six Sigma au cours du projet RPA. Les entreprises ont d’autres moyens d’intégrer les projets de RPA à Six Sigma :

  • Rédaction d’une charte du projet Les chartes donnent l’analyse de rentabilité des projets et les guident. Elles fournissent également l’occasion de rédiger des indicateurs de base pour montrer la progression.

  • Utilisez le DMAIC pour résoudre les problèmes où les solutions ne sont pas connues.

  • Discutez des projets identifiés avec les parties prenantes clés. Cette discussion doit valider et hiérarchiser les projets, et alerter sur d’éventuels projets à gagner rapidement.

  • Transformez l’accent de vos stratégies sur des projets axés sur le client. Utilisez les objectifs stratégiques de l’entreprise pour décider des projets de grande valeur et de bonne portée.

Lean : le Lean est également fondé sur l’idée d’éliminer les pertes, généralement des couches de gestion supplémentaires pour placer tout le monde plus près du processus. De plus, le Lean a une orientation d’analyse où chaque étape est soigneusement évaluée, et seules les étapes à valeur ajoutée sont maintenues. Lean et RPA sont similaires en ce qu’ils atteignent rapidement des résultats, mais le Lean ne part pas de zéro comme la RPA le fait. Il demande aux employés d’examiner les processus franchement comme ils le feraient pour la RPA, mais le Lean se contente d’analyser ce qui ne fonctionne pas ou n’est pas pertinent au lieu de réingénier ces processus.

Kaizen : autre méthodologie d’amélioration continue, le Kaizen est une stratégie de travail à long terme de petits changements progressifs des processus. L’intention du Kaizen n’est pas similaire à celle de la RPA, car la RPA enseigne une refonte complète des processus opérationnels ainsi que de leurs systèmes et structures associés. La RPA est un projet défini, ce qui signifie qu’il a un début et une fin, tandis que le Kaizen est continu. Alors qu’une équipe de projet et une sélection de personnes au sein de l’entreprise peuvent effectuer des RPA, le Kaizen est une méthodologie, à la limite d’une philosophie, que tout le monde doit effectuer à l’échelle de l’entreprise.

Gestion des processus d’entreprise (BPM) : le BPM est à la fois une discipline de gestion et un système logiciel. Le BPM concerne l’automatisation et la réutilisation des processus tout au long d’un cycle de vie. Le succès du BPM, quelle que soit la culture de l’entreprise, est continu et progressif. La RPA est liée à la culture d’entreprise et présente un changement radical. De nombreux professionnels considèrent les méthodologies BPM et RPA complémentaires, car la RPA peut être faite bien avant que le BPM ne prenne le relais. Bien que des méthodologies telles que le BPM et l’intégration des processus opérationnels (BPI) se concentrent sur les bénéfices et la productivité de l’entreprise, la RPA met l’accent sur les besoins des clients et la mission organisationnelle. Les différences entre les méthodologies BPM et RPA sont les suivantes :

  • Le BPM est moins risqué. Le BPM se concentre sur l’automatisation des processus, et non sur une refonte complète. La RPA est plus risquée, car elle se concentre sur la refonte à partir de zéro.

  • Le BPM utilise ce qui existe déjà. Il se concentre sur un processus à la fois, et non pas sur l’ensemble des processus et sur la façon dont ils sont liés. La RPA commence fraîchement avec de nouveaux processus, en écartant les anciens.

  • Le BPM consiste à optimiser et à gérer les processus, et non à faire une refonte. La RPA est une refonte radicale.

  • Le BPM est une progression lente. Il est plus facile pour le personnel de l’accepter, car il est progressivement intégré. La RPA peut renverser l’entreprise ; même la vision et la mission de l’entreprise peuvent être repensées lors d’un projet de RPA.

  • Le BPM garantit la continuité. Le BPM se construit progressivement, de façon cyclique et continue. Les projets de RPA se déroulent rapidement et en une seule fois pour bouleverser « l’ordre des choses ».

Agile : utilisée principalement dans le développement de logiciels, cette approche de gestion est également de nature itérative. De petites parties du projet sont terminées à la fois, presque de façon modulaire. Les experts du secteur disent que la différence entre Agile et RPA est que, bien que les deux perturbent les processus, la RPA reste fidèle au même résultat, mais avec un moyen meilleur, moins cher et plus rapide d’y arriver. Agile produit un résultat complètement différent. Pour plus d’informations sur la gestion de projet Agile, lisez « Tout ce que vous devez savoir sur la gestion de projet Agile ».

Système d’aide à la décision (DSS) : le DSS (ou GDSS) est une application informatique informationnelle qui examine et analyse les données d’une entreprise pour aider à la prise de décision. Le DSS a été le premier IS à se concentrer sur la refonte des processus opérationnels. RPA et DSS partagent l’objectif d’améliorer radicalement les processus opérationnels. Cependant, le DSS se concentre sur une décision à la fois, tandis que la RPA se concentre sur l’ensemble de l’organisation.

Planification des ressources de l’entreprise (ERP) : l’ERP est une suite intégrée de logiciels de gestion d’entreprise qui peut aider à gérer et à automatiser les besoins de l’entreprise. Les experts dans le domaine pensent que sans la RPA, la mise en œuvre d’ERP échouera. Certains fournisseurs d’ERP font la promotion de leurs logiciels comme étant capables de dire aux entreprises comment leurs processus doivent fonctionner. Suresh Subramoniam a estimé que même le système ERP le plus adapté pourrait avoir un maximum de 80 % seulement avec les flux de travail existants d’une organisation. Il pose en outre qu’un événement de RPA rend la mise en œuvre d’ERP plus rapide, moins coûteuse et mieux acceptée par les employés.

L’avenir des méthodologies d’amélioration des processus

 

According to many experts, the future of BPR involves process management and the combination of methodologies. Tech advancements will keep BPR consultants busy for many years to come, because BPR will continue to evolve and adapt.

According to Steven Wallis, Co-Founder, Analyst, and Consultant at ASK MATT and writer at Foundation for the Advancement of Social Theory: Theory for a better world, “Business process reengineering currently only achieves its goals about 80 percent of the time. The strange thing is that TQM and culture change efforts are similarly effective.

Malgré les récits encourageants des entrepreneurs, les jeunes entreprises échouent à un rythme alarmant. Plus étrange encore, au niveau national, nos politiques nationales atteignent rarement leurs objectifs. Et bien sûr, sur le plan personnel, il est généralement connu que la psychologie n’est pas très efficace. Il y a de nombreuses explications à tous ces échecs : manque de financement, agendas contradictoires, participants qui résistent au changement.

« Les recherches de mes collègues et moi-même ont identifié une nouvelle perspective. Nous proposons que la « technologie sociale » de notre société, notre compétence sous-jacente ou notre capacité à comprendre nos organisations et à mettre en œuvre un changement réussi, n’est tout simplement pas à la hauteur de la tâche. En bref, dans le monde des affaires, nous travaillons avec des « couteaux de pierre et des peaux d’ours », tandis que les ingénieurs et les physiciens utilisent des gadgets et des engins très efficaces. Plutôt que de rejeter la responsabilité sur les personnes concernées, nos recherches montrent qu’il existe une « structure » sous-jacente à nos théories du changement.

« Nous utilisons l’analyse propositionnelle intégrative ou IPA (la méthodologie, et non la bière) pour évaluer la structure logique interne trouvée dans les théories commerciales, telles que celles utilisées dans la gestion du changement. L’IPA montre que les théories (lois) de la physique et de l’ingénierie ont une « profondeur » systémique de 100 %, c’est pourquoi elles sont si utiles. En revanche, les théories en sciences sociales (ainsi que les politiques et les plans stratégiques) ont généralement une profondeur de moins de 20 %. Donc, malgré le succès très limité de la RPA (et des méthodes et théories du changement connexes), nous espérons que nous apprendrons à créer des théories plus approfondies pour soutenir plus efficacement un changement réussi ».

 

Connie Moore

According to Connie Moore, Senior Vice President of Research at Digital Clarity Group and blogger at Digital Clarity Group, “When BPR was developed in the 1990s, the concepts were groundbreaking and valid. Much of what we do today comes from those resources; they were not discredited. The concepts were much like the ‘big bang’ in the industry, especially in terminology such as ‘obliterate.’ Professionals would go in and change everything by redoing it all.

« Cependant, ils étaient très littéraux dans la façon dont ils ont appliqué ces concepts. La portée des projets était trop importante. Les équipes ne savaient pas ce qu’elles faisaient ; ils ont peu utilisé la méthodologie. C’est à ce moment que la méthodologie a été discréditée.

« La méthodologie qui a remplacé la RPA était l’amélioration continue, car les entreprises ne pouvaient pas gérer de grands changements. Ils pourraient examiner leurs processus, les améliorer et les réexaminer pour voir comment les améliorer davantage. Étant donné que le changement est permanent et que rien ne reste inchangé, l’amélioration n’est jamais terminée. Il est alors logique d’avoir des personnes qualifiées avec une formation en méthodologie pour améliorer les choses. C’est ce qu’on appelle l’excellence opérationnelle.

« En particulier dans les secteurs fortement réglementés, où le service à la clientèle n’est pas un élément essentiel comme dans le commerce de détail ou les secteurs axés sur les clients, l’excellence opérationnelle est essentielle. Il s’agit de secteurs tels que le pétrole et le gaz, qui peuvent faire l’objet d’amendes, de sorte que leur excellence opérationnelle est nécessairement différente. L’excellence opérationnelle dans ces secteurs ressemble à une amélioration continue et à des processus rationalisés. Cela contraste avec les secteurs qui comptent sur l’expérience client.

« Parfois, les secteurs qui dépendent des clients oublient l’amélioration continue, mais les deux concepts d’excellence opérationnelle et d’expérience client doivent être connectés dans tous les secteurs. Cette vue d’ensemble est l’avenir de la RPA », a déclaré Moore.

Application de la réingénierie des processus d’affaires

D’après les leçons apprises dans les années 1990, les entreprises comprennent que la mise en œuvre de la RPA doit être guidée, sinon entièrement effectuée, par des experts. Au fil des ans, la RPA a connu un véritable engouement, est tombée en disgrâce, puis est revenue en grâce, et de nombreux sondages ont retracé non seulement ce qui a mal tourné, mais aussi ce qui pouvait être mieux fait. Voyons qui doit effectuer des RPA et combien vous devez vous attendre à dépenser.

Les cabinets de conseil peuvent s’assurer que cette entreprise risquée est effectuée correctement, ce qui permet à l’entreprise d’économiser du temps, de l’argent et de la frustration (et peut-être de sauver l’entreprise elle-même). Les consultants de ce secteur sont objectifs et immunisés contre la politique qui peut être inhérente à l’entreprise. Ils ont une multitude de « leçons apprises » qu’ils peuvent appliquer à chaque nouvel événement de RPA, ils peuvent communiquer efficacement ce qui se passe en fonction de cette expérience, et ils peuvent souvent assumer le poids d’être l’étranger qui « possède » la méthode au lieu qu’elle provienne d’une personne interne à l’entreprise. En plus des animateurs, un consultant peut également agir en tant que membres de l’équipe et experts en la matière.

 

Sean Martin

For example, Sean Martin, an expert in BPR, content marketing manager for Directive Consulting, gives his expertise in how to leverage social media interest: “As an online marketing firm, we are constantly innovating and re-innovating our strategies to account for a growing and adaptive market. BPR is a great way of doing this, and a lot of online marketing startups have somewhat prided themselves on their ability to reverse engineer certain functions and capabilities of their competition.

« Avec des messages écrits sur le monde post-digital et l’adaptation nécessaire des tendances omniprésentes des réseaux sociaux dans les tactiques de marketing et d’entreprise locales, la RPA est un excellent moyen de commencer à partir d’une vue d’ensemble et de revenir aux détails. Les entreprises de marketing qui le font représentent de plus en plus de trafic en ligne et génèrent d’énormes adeptes sur les réseaux sociaux, comme BuzzFeed, Twitter, Snapchat et Facebook. Ce sont des plateformes de réseaux sociaux en elles-mêmes, oui, mais ce qu’elles font, c’est innover dans la façon dont les utilisateurs interagissent avec Internet et c’est ce que nous devons tous faire en tant que spécialistes du marketing en ligne : repenser la façon dont les gens interagissent et façonner notre entreprise pour créer de nouvelles tendances au lieu de rattraper les anciennes.

Qui a fait et peut faire de la RPA ?

Les organismes privés, publics et gouvernementaux ont tous effectué des RPA. Les entreprises multinationales ont été les premières à s’occuper de projets de RPA, et le secteur bancaire a rapidement suivi. Même les petites entreprises peuvent bénéficier (et elles en ont) d’un programme de RPA pour rester compétitives. Maintenant, la RPA peut être encouragée par les entreprises de logiciels qui vendent des solutions ERP et BPM. La sagesse classique conseille que la RPA soit mise en œuvre dans des entreprises qui comptent au moins 20 employés (dont au moins quatre appartiennent à la direction), un fort engagement de la direction envers l’innovation et une infrastructure informatique développée.

Combien de temps prend la RPA et quel est son coût ?

Deux considérations principales sont au premier plan dans l’esprit de tout PDG lorsqu’il est question d’amélioration des processus : combien de temps cela prendra-t-il ? Combien cela coûtera-t-il ? Dans l’ensemble, les experts disent que chaque processus de RPA varie, mais prend environ 6 à 10 mois, selon le type d’entreprise et la société de conseil engagée pour la mise en œuvre. Le coût varie également, en fonction de la complexité des processus opérationnels. En 2000, une RPA a coûté entre 9 000 $ et 16 000 $. Actuellement, les sociétés de conseil ont une structure de paiement à laquelle elles adhèrent. La plupart garantissent que le coût du conseil est insignifiant à côté des 40 à 80 % d’économies qu’ils garantissent dans les processus.

 

Meilleurs outils de RPA

De nombreuses sociétés de conseil disposent d’outils propriétaires ou de systèmes logiciels préférés qu’elles utilisent dans leur mise en œuvre de RPA. Idéalement, ces outils devraient améliorer la clarté de leur vision, renforcer la cohérence de leurs efforts et respecter les meilleures pratiques, telles que l’utilisation d’une approche descendante, le travail avec une petite équipe d’experts (pas plus de 10 personnes) et la combinaison d’une méthodologie RPA avec une notation de modélisation. Ces outils se divisent en six catégories : la gestion de projet, la coordination, la modélisation, l’analyse des processus opérationnels, l’analyse et la conception des ressources humaines, et le développement de systèmes.

 

Norbert Nogrady

Norbert Nogrady, Managing Director & Co-owner of JCM Ltd., gives his advice on BPR and tools to his peers in the Telecom industry. “During my 20+ years career in the field of customer care, I managed a number of BPR projects at large multinational companies. In my experience, BPR is most valuable in the case where it is independent from the IT department and the chosen vendor after the implementation period — in practice, a few weeks after the implementation. Input shall be received from customer care and the related organizational units: sales, finance, legal, and others.

« Il est également important de mentionner que les projets de RPA ne seront réussis que dans la mesure où ses systèmes de soutien correspondent aux tâches à accomplir. À savoir, dans le cas où le service informatique choisit un système qui nécessite un codage, une paramétrisation et la configuration des processus par des professionnels de l’informatique, les projets de RPA seront longs et inefficaces.

« J’ai toujours préféré les systèmes dans lesquels les utilisateurs finaux peuvent configurer leurs processus dans une interface graphique dédiée et le système implémente immédiatement les processus créés de cette façon. Un bon exemple pour un tel projet de RPA est UPC (une entreprise multinationale de télécommunications en Europe, où j’ai été directeur du service à la clientèle). Dans ce cas, tous les superviseurs du service client, alias les chefs d’équipe, qui sont ainsi devenus responsables des processus, ont assisté à une formation d’une demi-journée en RPA (fournie par le fournisseur) et ont simplement créé leurs propres processus à l’aide de l’interface graphique du système mis en œuvre appelé xFLOWer. La mise en œuvre et le déploiement du projet n’ont pris que six semaines, et à la fin de cette période, nous avions le système opérationnel avec les processus opérationnels dont nous avions besoin. Par rapport à la moyenne de l’industrie de 9 à 12 mois, ce projet a été un énorme succès et la mise en œuvre extrêmement rapide de la RPA.

« Je recommande à quiconque envisageant de mettre en œuvre un projet de RPA de choisir un système de RPA/flux de travail qui possède des capacités similaires, par conséquent la durée du projet sera considérablement raccourcie et le projet sera un grand succès pour toutes les personnes impliquées ».

Outils de gestion des processus et de flux de travail

Les outils de gestion des processus, ou systèmes de gestion des processus d’entreprise (BPMS), sont des systèmes logiciels qui considèrent l’entreprise comme un ensemble de processus ou de flux de travail. Le BPMS permet aux entreprises d’optimiser de façon cohérente leurs processus en les modélisant, en les mettant en œuvre, en les exécutant et en les surveillant. Il s’agit d’une approche plus structurée que les logiciels de flux de travail, ou les logiciels de gestion des flux de travail (WfMS), dont la mission principale est simplement de modéliser et d’automatiser la direction des documents et des tâches. De nombreux projets de RPA utilisent le BPMS, et beaucoup d’autres utilisent le WfMS. Les autorités dans la mise en œuvre de la RPA ont leurs favoris en fonction de leurs besoins et de leur expertise.

Créer des processus d’entreprise et des flux de travail performants et automatisés grâce à Smartsheet

Donnez à vos employés les moyens de se dépasser grâce à une plateforme flexible conçue pour répondre aux besoins de votre équipe, et capable de s'adapter quand ces besoins changent. La plateforme Smartsheet facilite la planification, la capture, la gestion et la création de rapports sur le travail depuis n'importe où, ce qui permet à votre équipe d'être plus efficace et d'accomplir plus. Créez des rapports sur les métriques clés et obtenez de la visibilité en temps réel quant au travail grâce aux rapports de synthèse, aux tableaux de bord et aux flux de travail automatisés conçus afin d'aider votre équipe à rester connectée et informée. Quand les équipes bénéficient de clarté quant au travail en cours, elles peuvent accomplir bien plus dans le même temps. Essayez Smartsheet gratuitement, dès aujourd'hui.

 

Connectez votre personnel, vos processus et vos outils à l'aide d'une plateforme simple et conviviale.

Essayer Smartsheet gratuitement Get a Free Smartsheet Demo