Les plateformes pour revisiter les processus de l’entreprise numérique

Les plateformes pour revisiter les processus de l'entreprise numérique
Digitalisation à marches forcées, télétravail, logistique intégrée au CRM exploitant mieux l’IoT et le sans contact, collaboration étendue, les thèmes rencontrés dans les récents billets, explorant les impacts de la crise sanitaire, suggèrent que l’époque est à la remise en cause des organisations et des pratiques. C’est donc certainement le bon moment pour revisiter l’automatisation des processus de l’entreprise numérique dont l’objectif est généralement la réduction des coûts, des risques, des taux d’erreurs ou l’amélioration de la conformité.

De multiples technologies existent dans ce domaine : BPMS, “Low-code”, outils collaboratifs agiles, workflows des ERP et logiciels SaaS, PaaS orientées intégration d’API… Ces technologies, apparues à différentes époques, voulant maîtriser les échanges et les flux de travaux, se recouvrent parfois entre-elles.

publicité

Ce billet cherche donc à clarifier quelques principes à garder en tête, avant de vouloir planter transformer son organisation avec ces technologies, qui ne vont pas manquer de revenir plus fort sur le devant de la scène.

C’est en 1998 que Michael Hammer, ingénieur de formation et professeur au MIT, a amené avec son collège James Champy, une vision orientée processus dans le management des entreprises (Reengineering the Corporation: A Manifesto for Business Revolution).

La science de l’ingénieur, déjà présente à cette époque dans les usines pour la production, se généralise à toute l’entreprise, que ce soit pour commander une gomme, recruter un salarié ou prospecter un client.

Il est important de noter que cette vision processus s’est développée dans la sphère académique, en dehors des outils informatiques, qui ont vu ensuite l’opportunité commerciale de la supporter. D’où le développement des premiers outils de “dessin” des processus pour en gérer la documentation et permettre aux “process owner” de les partager et de les contrôler.

Des outils plus sophistiqués sont alors apparus pour “coder” cette vision et ces processus afin de les automatiser et de les déployer plus facilement qu’avec un manuel de procédures.

Les ERP ont été les premiers, car ils avaient un temps d’avance avec l’automatisation des usines (MRP/MRP2 – material request planning) qu’ils supportaient depuis leur origine, puis des moteurs de workflow qui ont cependant eu du mal à exister en dehors des applications. On parle bien d’automatiser les processus, donc d’automatiser l’enchaînement des tâches, éventuellement entre différents services voire entreprises, et non pas l’automatisation des tâches elles-mêmes. 

La première idée à garder en tête est celle du continuum du scope de l’automatisation de la collaboration, de la tâche au processus, vers le pilotage des processus de l’entreprise, mais sans oublier les processus reposant sur l’humain et la collaboration plus informelle entre salariés, de plus en plus outillée.

 

Ce lien entre processus et collaboratif, c’est l’éclairage amené par GreenSI par rapport à d’autres visions plus centrées sur la technique. L’humain reste le moteur de workflow le plus efficace quand tout ne peut être écrit à l’avance, comme en période de crise. Le développement de l’agilité a aussi montré que c’est un très bon moteur quand l’engagement de l’équipe est essentiel pour la performance et donc qu’il fait plus pour la performance en distribuant les tâches que ce que ferait une machine. L’entreprise numérique est donc loin d’être une entreprise déshumanisée.

Les outils collaboratifs, comme Trello, permettent aux utilisateurs de créer des workflows d’équipe très agiles, quand les modules des ERP permettent eux de déployer massivement des processus standards, mais avec une prise en main réservée à des spécialistes.

Les plateformes “low code” peuvent être vues comme un intermédiaire entre ces deux approches. En effet, le “low code” met, dans la main des utilisateurs finaux, la couverture du cycle de vie d’une application depuis le design, la navigation, les tests, le déploiement et la gestion des versions. Un pouvoir qui peut être utilisé pour outiller des processus.

C’est pourquoi le dernier billet de GreenSI (se désintoxiquer de l’e-mail pour mieux collaborer) fait le lien entre les outils collaboratifs et le “low code”, qui embarque de plus en plus cette possibilité de faire des worflows, en plus de pouvoir designer (sans coder) des interfaces applicatives – généralement des formulaires – qui outillent la collaboration. 

L’engouement actuel pour le “low code”, dominé jusqu’à présent par des spécialistes comme Mendix, Appian ou Outsystems, a certainement été réveillé ces dernières années par l’entrée sur ce marché de généralistes comme Microsoft, Google, Salesforce ou encore ServiceNow, dont le nouveau patron, Bill McDermott, a passé 17 ans chez SAP où il a mené la transition de l’éditeur vers le cloud. AWS a également annoncé la semaine dernière Amazon Honeycode, un service “low code”, entièrement géré sur son cloud, qui permet de construire rapidement des applications mobiles et web, avec un concepteur visuel d’applications reposant sur une base de données AWS.

IBM ayant aussi sa plateforme “low code”, on en déduit que l’avenir du cloud, semble passer par le PaaS et le “low code”, car les cinq plus grands fournisseurs mondiaux de cloud ont maintenant une offre. 

En revanche, l’autre engouement du moment, la RPA pour automatisation robotisée des processus, est destinée à l’automatisation des tâches (et non des processus). C’est ce qu’elle fait en virtualisant un poste de travail (avec une VM) pour y faire travailler son agent virtuel, sans modifier les applications. Les plateformes RPA sont excellentes dans l’automatisation des tâches humaines. SAP, leader de l’ERP, a racheté l’acteur français Contextor en 2018, n’en pas indifférent. Les gains de productivité peuvent alors être importants, ce qui stimule parfois l’envolée des coûts des licences des éditeurs…

On pourrait donc croire que la RPA un moyen rapide de mise en œuvre de l’automatisation des processus, mais c’est une approche considérée fragile sur des périmètres larges qui crée rapidement de la dette technique (les robots et l’approche VM ne supportent pas les modifications des applications). La RPA donne donc généralement des boutons aux architectes SI.

C’est une technologie tactique et non une technologie fondatrice. Son terrain de jeu, ce sont les applications anciennes, que justement on ne veut pas (ou on se sait pas) modifier, en attendant (ou en espérant) leur remplacement un jour. La dette applicative des mainframes se trouve dans cette catégorie.

À l’autre extrême du continuum, on trouve la gestion intelligente des processus métier (iBPMS) qui vise à unifier l’entreprise autour de ses processus. On reviendra sur l’intelligence et on restera prudent avec cette approche globale si la culture de l’entreprise n’est pas adaptée à une gestion centralisée, au risque de dépenser une énergie énorme en conduite des changements. L’iBPMS ne doit donc pas être un projet technique porté par la DSI, mais bien un projet de transformation. L’enjeu est la possibilité de faciliter l’intégration et la surveillance des processus à l’échelle de l’entreprise.

L’iBPMS, c’est l’évolution des systèmes BPMS historiques, centrés sur la documentation des processus et l’optimisation du séquencement des étapes de processus, en particulier lorsque des tâches non automatisées sont traitées manuellement ou que le processus s’étend sur plusieurs départements.

Ces plateformes se sont étoffées pour rester compétitives et aller au-delà de la documentation pour fournir un environnement de développement des processus. Elles visent certainement à moyen terme à réunifier tous le continuum, mais le mieux est parfois l’ennemi du bien.

On y retrouve IBM, mais aussi Pegasystem ou Appian.

Les plateformes iBPMS nécessitent des compétences et des ressources spécifiques. Une fois en place, elles amènent la gestion du cycle de vie complet des processus métier, contrairement aux autres technologies. Encore faut-il que ce soit un besoin et que cela délivre de la valeur.

Au final, la diversité des technologies, sur l’ensemble du continuum de la collaboration, incite donc à bien réfléchir en amont à la portée des processus à automatiser et à l’imbrication qu’ils ont entre eux. 

Pour GreenSI, la plateforme qui traite tous les cas n’existe pas, ce qui renforce le besoin d’API entre ces plateformes qu’il faudra intégrer dans une vision de bout en bout. Pour cela, les bonnes questions à se poser pour digitaliser une organisation concernent le scope et la nature des processus :

  • Est-on capable de décrire le processus ? sa variabilité demande t-elle une attention humaine permanente ?
  • A-t-on besoin d’agilité pour reconfigurer rapidement les processus ?
  • Quel est la durée des processus (minute, heure, jour, semaine…) et donc le besoin d’asynchronisme des tâches ?
  • Doit-on automatiser des tâches simples effectuées par des humains dont la plateforme doit capter les événements ?
  • Inversement, doit-on escalader vers des humains des cas particuliers rencontrés par la plateforme ?
  • Doit-on automatiser des tâches complexes demandant l’appel a des processus imbriqués ?
  • Doit-on monitorer les processus et leur efficacité globale ?

Les réponses à ces questions doivent aider à bien se positionner sur le continuum.

Finalement, vingt-deux ans après les travaux de Michael Hammer, la réingénierie des processus de l’entreprise est toujours d’actualité. Elle demande de bien séparer les concepts d’orchestration des processus, d’automatisation des tâches, et de la réflexion pour rendre ces processus résilients, omnicanaux ou sans contact.

Le besoin de documentation est aussi plus fort qu’à l’origine avec les exigences du RGPD, pour les processus qui voient circuler des données personnelles et qui doivent identifier et en cataloguer les traitements.

Cependant le moteur unifié pour faire tourner les processus de l’entreprise quel que soit la forme de l’orchestration n’existe pas encore. Cette réingéniérie doit donc savoir s’appuyer sur les technologies disponibles, y compris sur les technologies collaboratives, et parfois les orchestrer entre-elles. Elle ne doit pas subir les choix, nécessairement hétérogènes, voire incohérents, des multiples applications outillant déjà certaines tâches métiers.

Enfin, ne vous attendez pas à ce que ces outils optimisent les processus pour vous. Le développement de l’intelligence artificielle dans les workflows des ERP, avec de l’apprentissage sur les données de l’entreprise, va certainement se développer. SAP et Salesforce ont déjà des réalisations à montrer, mais on en est au tout début et surtout pas sur tout le continuum.

Cet éclairage met donc en avant le besoin d’urbanisation de la collaboration, au sens large, à l’intérieur ou avec les partenaires et clients. Cette urbanisation se traduit nécessairement par l’urbanisation des flux et échanges d’événements entre applications ou plateformes. C’est peut-être le retour d’une équipe “SI et organisation” qui doit amener de la cohérence et de la simplification à l’échelle de l’entreprise. 

Leave a Reply

Your email address will not be published. Required fields are marked *