Quelles sont les limites du process mining traditionnel ?
Bien qu'extrêmement puissantes, selon le professeur van der Aalst, les techniques traditionnelles de process mining présentent les limites suivantes :
- L'extraction et la transformation des données sont fastidieuses et doivent être répétées.
- Les interactions entre les objets ne sont pas capturées.
- La réalité 3D est compressée dans des journaux d'événements et des modèles 2D.
Pour comprendre chacune de ces limites, il est d'abord nécessaire de comprendre comment fonctionnent les processus modernes et comment les données qui leur sont associées sont stockées.
Un modèle de processus classique repose sur la notion de cas unique, c'est-à-dire l'hypothèse qu'un seul cas (ou instance de processus) se produit de manière isolée. Dans les journaux d'événements, comme celui ci-dessus, cette notion de cas unique est illustrée par le fait qu'il existe un identifiant de cas (Case ID) par événement.
Ce n'est pas ainsi que les événements se produisent dans le monde réel, ni la manière dont les données sont souvent stockées dans les systèmes d'information à partir desquels les données du journal d'événements sont extraites. Par exemple, le service commercial peut suivre ses processus à l'aide de documents numériques tels que les commandes. Lorsque vous appliquez des outils traditionnels de process mining au processus commercial des commandes, vous examinez un seul objet, la commande, et vous étudiez son parcours au sein du service commercial. Grâce à ces informations, vous pouvez identifier les domaines à améliorer et mettre en œuvre des changements de processus pour combler ces lacunes.
Cependant, le service commercial ne fonctionne pas en vase clos. Les événements qui se produisent au cours du processus de vente ont des répercussions sur d'autres services, tels que l'approvisionnement, la production, l'entreposage, la distribution, la finance, etc. De plus, différents services utilisent différents objets dans leurs processus. La production peut utiliser des ordres de fabrication, la finance des factures, l'approvisionnement des bons de commande, etc. Tous ces objets sont liés, car les processus sont liés.
Prenons l'exemple d'un client qui passe une commande de quatre articles en même temps. Un article est en stock et les trois autres doivent être fabriqués. Pour les articles qui doivent être fabriqués, trois ordres de fabrication sont créés. L'article en stock est emballé et expédié seul, tandis que les autres articles sont emballés ensemble et expédiés plus tard, une fois qu'ils ont été fabriqués. Une seule facture est ensuite envoyée au client.
Les processus impliquent généralement plusieurs objets (par exemple, des commandes, des articles, des ordres de fabrication, des expéditions et des factures) qui sont tous liés entre eux.
Cet exemple illustre comment un événement unique, la création d'une commande client, peut impliquer plusieurs objets (clients, commandes clients, articles de commandes clients, ordres de production, expéditions et Facturation) qui sont tous liés les uns aux autres. Par exemple, un client peut avoir plusieurs commandes (relation one-to-many). De même, une commande client peut contenir plusieurs articles et un article peut être inclus dans plusieurs commandes client (relation many-to-many). Pour gérer ces relations, les systèmes ERP, CRM, SCM et autres systèmes métier stockent souvent les informations dans ce qu'on appelle une base de données relationnelle.
Dans un modèle relationnel, les données sont organisées en tables composées de lignes et de colonnes. Les lignes sont appelées enregistrements, les colonnes sont appelées attributs et les tables sont des relations. Par exemple, dans une table de clients, chaque ligne peut correspondre à un enregistrement client individuel et chaque colonne est un attribut tel que le nom, l'adresse, le numéro de téléphone, etc. Si l'on reprend l'exemple de la commande ci-dessus, une table de commandes peut comporter une ligne/un enregistrement pour chaque commande et des colonnes/attributs pour des informations telles que le numéro de commande, la date et l'heure, le client, les articles commandés, le prix de chaque article, l'adresse de facturation, l'adresse de livraison, le mode d'expédition, etc.
Chaque ligne d'une table d'une base de données relationnelle possède un identifiant unique appelé clé. Par exemple, dans une table client, chaque client se verrait attribuer un identifiant client distinct qui serait utilisé comme clé primaire de la table. Dans la table des commandes, la clé primaire pourrait être un identifiant de commande. Chaque fois qu'un nouvel enregistrement est écrit dans une table, une nouvelle valeur de clé primaire est générée pour cet enregistrement.
Les clés primaires permettent au système d'accéder aux informations d'une table individuelle et sont également utilisées pour montrer les relations entre les tables. Par exemple, les lignes de la table des clients peuvent être liées aux lignes de la table des commandes en ajoutant une colonne d'ID client à la table des commandes. Chaque fois qu'un client effectue un nouvel achat, un enregistrement est ajouté à la table des commandes client, et l'ID client unique du client est ajouté en tant qu'attribut appelé clé étrangère (une clé unique provenant d'une ligne liée dans une autre table). Ce modèle fonctionne bien pour les relations one-to-many, où de nombreuses lignes d'une table ont une valeur de colonne qui est égale à la clé primaire d'une autre table.
Pour tenir compte des relations many-to-many, les clés primaires des tables associées sont souvent copiées dans une table supplémentaire qui sert à résoudre la relation entre les deux tables d'entités. Prenons par exemple la relation many-to-many entre les commandes client et les articles décrite ci-dessus. Vous pourriez avoir ici une table des commandes client, une table des articles et une troisième table de résolution. La table de résolution contiendrait au minimum une colonne pour chacune des clés étrangères des tables de commandes et d'articles (clés primaires de ces tables), ainsi qu'une nouvelle clé primaire créée à partir des deux clés étrangères.
Dans notre exemple simple de commandes et d'articles, au moins trois tables sont nécessaires pour définir la relation. Dans la réalité, il en faut beaucoup plus. Repensez au processus de commande décrit ci-dessus. Une seule commande client est liée à quatre articles, trois ordres de fabrication, deux expéditions et une facture. Chacun de ces objets est lié à d'autres objets, tels que des clients, des fournisseurs, des expéditeurs, etc. Il n'est donc pas difficile de comprendre pourquoi les systèmes d'information d'entreprise modernes, tels que les systèmes ERP, utilisent des bases de données contenant des centaines, des milliers, voire des centaines de milliers de tables.
Nous pouvons maintenant examiner les trois limites du process mining traditionnel mentionnées précédemment :
- L'extraction et la transformation des données sont fastidieuses et doivent être répétées. Le process mining classique nécessite d'extraire les données des bases de données relationnelles multi-tables du ou des systèmes d'information source vers un journal d'événements plat (c'est-à-dire une table) où chaque événement (c'est-à-dire une ligne) fait référence à un cas, une activité et un horodatage. Dans notre exemple de commande, chaque cas correspondrait à une commande spécifique, et nous pourrions poser une question telle que « Quelle est la raison la plus courante d'une commande bloquée ? ». Cependant, si nous voulions poser une question telle que « Quels clients paient leurs factures à temps ? », nous aurions besoin d'un journal d'événements différent avec les factures, et non les commandes, comme notion de cas. Nous devrions donc revenir aux données et effectuer une nouvelle extraction, ce qui peut être un processus long et fastidieux.
- Les interactions entre les objets ne sont pas capturées. Lorsque vous extrayez des données d'une base de données relationnelle et que vous les aplatissez dans un journal d'événements de process mining où chaque événement est un cas unique, vous perdez les interactions entre les objets définis dans les données sources. De même, tous les modèles de processus que vous générez à partir des données aplaties ne décrivent que le cycle de vie d'un cas isolé. Pour obtenir une transparence complète des processus, vous devez comprendre la relation entre tous les différents objets et types d'objets impliqués dans le processus.
- La réalité tridimensionnelle est réduite à des journaux d'événements et des modèles bidimensionnels. Dans le process mining traditionnel, un journal d'événements est créé pour chaque type d'objet et analysé séparément. Par exemple, nous créons un journal d'événements pour les bons de commande afin d'examiner le processus de commande, un journal d'événements pour les factures clients afin d'examiner le processus de comptabilité clients, un journal pour les factures fournisseurs afin d'analyser la comptabilité fournisseurs et un journal d'événements pour les bons de commande afin d'examiner le processus d'approvisionnement. Même si ces journaux d'événements plats sont liés via un modèle de données de cas connexes, nous compressons toujours des données et des modèles tridimensionnels centrés sur les objets en journaux d'événements et modèles de processus bidimensionnels centrés sur les cas.
Cet aplatissement des données entraîne des problèmes de convergence et de divergence.
La convergence se produit lorsqu'un événement est reproduit dans différents cas, ce qui peut entraîner une duplication involontaire. Prenons l'exemple du processus de commande client décrit ci-dessus. Si nous sélectionnons un article de commande client comme notion de cas, les événements au niveau de la commande client (par exemple, passer une commande) seront dupliqués pour chaque article de commande client lié à une commande client spécifique. Cette duplication des événements peut entraîner des diagnostics erronés.
La divergence se produit lorsqu'il existe plusieurs instances d'une même activité au sein d'un même cas. En reprenant l'exemple du processus de commande ci-dessus, si nous sélectionnons la commande comme notion de cas, les événements de niveau article (par exemple, sélectionner l'article) peuvent devenir indiscernables et sembler liés. Par exemple, les événements « prélever l'article » et « emballer l'article » ne se produisent qu'une seule fois par article et dans un ordre fixe (par exemple, vous prélevez l'article, puis vous l'emballez). Dans un journal d'événements de commandes client aplati, ces événements peuvent sembler se produire plusieurs fois et dans un ordre apparemment aléatoire pour un cas individuel.
