Rien que la vérité sur le Process Mining

Tout comme les rapports annuels, le contenu des requêtes est bien vérifié, car elles doivent résister à l'examen judiciaire par des avocats, des auditeurs et des juges. Elles fournissent donc des informations précieuses sur la situation actuelle du marché. Un exemple récent de l'impact des prises de position judiciaires est la déclaration d'un cadre d'Apple sur la fonction de recherche, qui a déclenché une baisse du cours d'Alphabet². 

Les principaux fournisseurs de PM

Particulièrement explosif : Celonis, leader dans le domaine du Process Mining (PM) selon Gartner, se voit contraint d'engager des poursuites judiciaires contre SAP. Cela indique des difficultés importantes dans l'interaction entre les deux entreprises. Concrètement, Celonis reproche à SAP de bloquer de manière ciblée l'accès aux données SAP avec des outils tiers - donc également avec des solutions de Celonis. De nombreux reproches mentionnés dans la plainte sont de nature juridique et sont secondaires pour cet article. Ce qui est plus intéressant, ce sont les déclarations qui donnent un aperçu de l'état pratique de l'utilisation du Process Mining : Y a-t-il de nouvelles connaissances ? Des progrès technologiques ou de contenu ?

Cet article fait suite à un article³ de l'année 2022 dans le magazine E3. Il s'agissait alors de six malentendus entre les exigences des clients et les possibilités ou les limites du "Process Mining". La conclusion était alors que les outils de Process Mining sont supposés avoir certaines capacités pour lesquelles il existe des approches plus appropriées dans d'autres outils ou directement dans le système ERP de SAP. Pourquoi le Process Mining se heurte-t-il souvent à des limites dans SAP ? 

La vérité sur les journaux d'événements

Une promesse centrale de PM est l'analyse de processus commerciaux réels sur la base de ce que l'on appelle les Event Logs - des traces numériques que chaque transaction laisse dans le système. C'est précisément ce qui est souligné dans la plainte (point 24) : chaque processus commercial génère une empreinte numérique qui devrait pouvoir être analysée. La réalité dans les systèmes SAP est toutefois différente. De tels journaux d'événements n'y existent généralement pas avec la profondeur et la structure qui seraient nécessaires à une gestion de projet efficace. Il existe certes des tables qui représentent certains processus, comme les relations entre prédécesseurs et successeurs (par exemple la table VBFA) ou les protocoles de modifications (par exemple CDHDR). Mais ces informations ne montrent qu'une partie de l'image globale.

Prenons un exemple : Dans le cadre du traitement d'une commande client, de nombreux processus consécutifs sont automatiquement déclenchés - par exemple le transfert des besoins à la planification des besoins. Ces processus intégratifs, souvent exécutés par ce que l'on appelle des "enregistreurs", ne sont souvent saisis que de manière incomplète dans les logs standard. La situation devient particulièrement complexe lorsque des calculs de prix ou des déterminations de comptes entrent en jeu - des domaines qui ne sont guère pris en compte dans de nombreux outils de Process Mining. Dans la pratique, cela conduit les entreprises à devoir recourir à des analyses complémentaires coûteuses. Selon la question posée, d'autres sources de données doivent être évaluées et combinées individuellement. Cela est certes possible - mais seulement avec un savoir-faire SAP approfondi et des efforts techniques considérables.

Conclusion : celui qui croit que le Process Mining est possible dans les systèmes SAP simplement "en appuyant sur un bouton" se trompe. La réalité est complexe - et la vérité sur les Event Logs nettement moins lisse que ce que les promesses marketing laissent supposer.

Process Mining ou ERP ?

Dans la pratique, la GP est souvent promue avec l'argument qu'elle apporte des avantages concrets dans les affaires courantes - par exemple pour le contrôle des factures des créanciers ou pour éviter les doubles paiements (point 27 de la plainte). Mais cet exemple montre précisément à quel point certaines analyses PM sont en réalité redondantes : En effet, de tels mécanismes de contrôle existent depuis longtemps dans tous les systèmes ERP courants - y compris SAP. Lorsque les fabricants de PM font malgré tout de la publicité pour de telles fonctions, ils se retrouvent rapidement en difficulté pour s'expliquer. Ils risquent en effet de se contenter de reproduire des fonctions ERP déjà existantes, souvent à des coûts plus élevés et avec des lacunes potentielles en termes d'actualité et de qualité des données. 

C'est justement par rapport à un système ERP moderne comme SAP S/4 Hana, qui est équipé d'outils d'analyse performants, qu'il devient de plus en plus difficile pour les solutions PM externes d'offrir une réelle valeur ajoutée. SAP S/4 Hana propose une centaine d'applications d'analyse standardisées, par exemple pour le suivi des commandes des clients, qui permettent précisément d'obtenir de tels aperçus - directement dans le système ERP, sans outils externes.

Conclusion : lorsque les systèmes de gestion de projets promettent des fonctions que l'ERP maîtrise depuis longtemps, il en résulte non seulement de la confusion, mais aussi une double infrastructure douteuse. Avec les progrès techniques des plates-formes ERP modernes, la marge de manœuvre des outils de gestion de projets externes se réduit donc de plus en plus. 

Où se situe la vérité sur le processus cible ? Au point 30 de la plainte, il est affirmé que les données réelles d'un Event Log permettent de déduire le processus cible initial. Mais cela n'est pas défendable. Un Event Log - surtout s'il est incomplet - montre uniquement ce qui s'est réellement passé, et non ce qui était prévu ou planifié.

Pour comprendre le déroulement prévu (le "flux théorique") d'un processus, il faudrait analyser les paramètres du Customizing dans le système ERP. Ceux-ci définissent les instructions concrètes du processus qui ont été fixées par le client lors de l'introduction du système ou de l'adaptation en cours. Sans cette configuration, la vision du processus théorique reste lacunaire.

Un autre problème : dans le monde du Process Mining, il manque souvent des analyses de cause à effet fondées. Les paramètres de contrôle issus des données de base - par exemple la manière dont un matériau est planifié ou dont une commande est évaluée - sont à peine pris en compte. Pourtant, ce sont précisément ces paramètres qui ont une influence déterminante sur le comportement du processus.

Cette négligence n'est pas un phénomène nouveau : la modélisation classique des processus était déjà confrontée à ce problème. L'approche de la gestion des processus se concentre traditionnellement sur les processus observables et non sur les mécanismes de contrôle plus profonds du côté du système.

Conclusion : si l'on veut vraiment comprendre l'état souhaité d'un processus, l'analyse du Customizing et des données de base est incontournable. Mais pour cela, il faut des méthodes spécialisées - comme le Reverse Business Engineering (RBE)⁴ - qui ont été développés précisément dans ce but. Le Process Mining seul ne suffit pas ici.

12 à 36 heures avant la vérité

Un point faible central dans la pratique du PM semble être l'extraction des données. Il ressort du point 124 que Celonis a utilisé une technologie SAP dépassée pour la connexion des données : le Remote Function Call (RFC) avec Abap. Le problème est que SAP ne supporte plus cette méthode. Le point 141 montre clairement à quel point l'ancienne solution était inefficace : l'extraction de données de 100 tables prenait environ douze heures. 

Les nouvelles approches, par exemple via OData, nécessitent même jusqu'à 36 heures. Cela montre qu'une véritable connexion de données en temps réel entre le système PM et le système ERP n'a jamais existé - car les données analysées étaient toujours vieilles d'au moins une demi-journée. Une estimation des coûts (que l'on espère exagérée) montre que le téléchargement alternatif de 100 Go de données via SAP Datasphere pourrait coûter jusqu'à 30.000 dollars. Dans le monde du cloud, il semble donc qu'il n'y ait plus de mise à disposition gratuite de données. 

En outre, la question se pose de savoir pourquoi l'analyse des PM doit être effectuée de manière globale.
100 Go de données sont transférés ? Avec une approche analytique plus ciblée, beaucoup moins de données pourraient suffire - souvent, 1 Go par requête suffirait.

Une ancienne et deux nouvelles vérités

L'approche du Process Mining a aujourd'hui pris un coup de vieux. On pourrait établir un parallèle avec l'histoire des fournisseurs de boutiques en ligne comme Intershop : Dans les années 2000, ils étaient considérés comme des espoirs du marché numérique. Aujourd'hui, s'ils existent encore, ils ne sont généralement que des fournisseurs de niche au succès économique limité. Dès la fin des années 2000, il était clair que la suite ERP intégrée s'imposerait à long terme. Les fournisseurs d'outils de gestion de projets semblent désormais connaître un sort similaire.

En outre, les outils de gestion des projets ont depuis longtemps abandonné leur objectif initial, à savoir l'analyse des journaux d'événements. Leur "faim de données" croissante pèse de plus en plus sur les systèmes. Parallèlement, S/4 Hana et sa base de données en mémoire ont considérablement amélioré les capacités d'analyse au sein du système ERP. Les analyses dans le sens du suivi des processus peuvent aujourd'hui être représentées directement dans l'ERP - les outils PM deviennent de plus en plus superflus. Leur champ d'application utile s'en trouve considérablement réduit.

A cela s'ajoute le fait que : Dans le monde du cloud, les requêtes illimitées de données et l'utilisation élevée des ressources ne vont plus de soi. Si, à l'avenir, des modèles d'IA doivent également être entraînés pour la gestion de projet - ce qui est probable - la concurrence pour la puissance de calcul et l'accès aux données va encore augmenter. Il reste à voir quelles solutions juridiques ou quels compromis seront trouvés. La suite au prochain numéro ...

Malentendu vs. réalité

Malentendu 

• Diagnostic rapide des problèmes
• Un aperçu complet
• Analyse de la conformité/des risques
• Analyse sur plusieurs systèmes
• Vue de bout en bout
• Automatisation

Réalité

• Effort important avec les outils PM
• D'autres outils plus simples
• Ne fait pas partie de PM
• Limites existantes
• Possibilité limitée
• Généralement via ERP ou add-ons

(1) Lien vers la plainte.

(2) Lien vers l'article du Frankfurter Allgemeine

(3) Rétro-ingénierie pour les bibliothèques de logiciels comme SAP R/3; (4) article : Hufgard, Wenzel (1999) : Reverse Business Engineering - Dériver des modèles à partir de systèmes R/3 productifs. Dans : Electronic Business Engineering. 4e congrès international d'informatique de gestion. S. 425-441.