Un guide pour dirigeants sur l’utilisation des données d’événements afin de reconstruire les processus réels, révéler l’attente, les variantes et les reprises, puis repenser le processus effectivement exécuté plutôt que celui décrit dans les procédures.
Questions abordées dans cette perspective
- Où les parcours réels des commandes, colis et expéditions s’écartent-ils du processus documenté et quelles variantes créent une attente, des reprises, des défaillances de service ou des coûts significatifs ?
- Quelles sémantiques d’événements, quels identifiants, quelle qualité de données et quelle gouvernance sont nécessaires avant d’utiliser les constats du Process Mining pour des décisions de redesign ou de contrôle ?
- Comment la direction doit-elle utiliser le Process Mining pour prioriser la simplification, la refonte et l’automatisation sur plusieurs sites sans institutionnaliser une complexité de processus inutile ?
Les organisations de traitement des commandes et de logistique savent en général comment leurs processus sont censés fonctionner : la séquence attendue est documentée dans les procédures opératoires standard, les configurations système, les supports de formation et les routines de management. La difficulté est que le processus réellement exécuté par des milliers de commandes, colis, mouvements de stock et événements de transport correspond rarement exactement à cette conception. Les commandes attendent entre les étapes, les exceptions créent des parcours alternatifs, des contournements locaux deviennent permanents, certaines transactions système sont enregistrées après l’activité physique, les priorités changent pendant le poste et les sites font évoluer leurs propres variantes d’un processus initialement commun. Le Process Mining permet à la direction de reconstruire ces parcours réels à partir des données d’événements opérationnels et de comparer le processus que l’entreprise pense exécuter avec celui que les clients et les collaborateurs vivent effectivement. Sa valeur ne réside pas dans un nouveau schéma de processus, mais dans la capacité à identifier où s’accumulent l’attente, la reprise, la complexité et les défaillances de contrôle, puis à prioriser la refonte sur la base de faits plutôt que d’ateliers, d’anecdotes ou de moyennes.
Le processus documenté et le processus exécuté sont deux objets de management différents
Une procédure opératoire standard est indispensable : les collaborateurs ont besoin d’une façon de travailler définie, les systèmes ont besoin de règles et de contrôles et le management d’une base pour former et responsabiliser les équipes. Elle reste toutefois une représentation du comportement attendu, et non un enregistrement exhaustif de ce qui s’est produit. Dans un environnement de traitement des commandes à fort volume, des milliers de cas peuvent suivre des parcours légèrement différents parce qu’un stock manque, qu’une commande est partiellement prélevée, qu’un carton est rejeté par l’automatisation, qu’une étiquette transporteur échoue, qu’une remorque part plus tôt, qu’un client modifie une instruction ou qu’une équipe locale adopte un contournement pour protéger le service. Ces écarts ne signifient pas automatiquement que l’opération est mal contrôlée. Le problème apparaît lorsque la direction ne peut plus distinguer la variation légitime de la complexité évitable.
Les ateliers classiques d’amélioration des processus reconstruisent souvent l’opération à partir d’entretiens, d’observations et de l’expertise métier. Ces méthodes restent essentielles parce que les journaux d’événements expliquent rarement l’intention, le jugement local ou les contraintes physiques à l’origine d’une activité. Elles sont cependant exposées à un biais courant : chacun décrit le processus qu’il connaît, celui dont il est responsable ou celui qui devrait exister. Un superviseur peut décrire avec précision le parcours normal prélèvement-emballage-expédition tout en voyant peu les boucles d’exception qui touchent une minorité de commandes mais consomment une part disproportionnée du temps de management. Le Process Mining inverse le point de départ : il observe d’abord la séquence des événements enregistrés pour chaque cas, puis mobilise l’expertise opérationnelle pour expliquer les motifs observés.
Un processus documenté représente le modèle opérationnel voulu par l’entreprise ; il ne prouve pas que le travail suit ce modèle. Le Process Mining apporte des preuves sur le processus exécuté, mais ces preuves doivent encore être interprétées : un journal d’événements enregistre ce que les systèmes ont observé, pas toutes les conditions physiques ni toutes les décisions managériales qui ont influencé le résultat.
Ce que le Process Mining reconstruit réellement
Conceptuellement, le Process Mining repose sur trois éléments : un identifiant de cas, un événement ou une activité et un horodatage indiquant quand cet événement s’est produit. Dans l’exécution des commandes, le cas peut être une commande, une ligne de commande, un colis, une expédition, une palette, un retour ou un mouvement de transport selon la question étudiée. Les événements peuvent correspondre au lancement de la commande, à une demande de réapprovisionnement, au début ou à la fin du prélèvement, à la fin de l’emballage, à l’induction sur trieur, à la création d’une exception, à la mise en staging, à la manifestation, au chargement ou au départ. En ordonnant ces enregistrements chronologiquement par cas, l’entreprise peut reconstruire les parcours effectivement suivis par des milliers ou des millions d’objets plutôt que de s’appuyer sur un schéma représentatif unique.
Ce modèle en apparence simple devient plus exigeant dans les opérations d’entreprise, car un même engagement client existe souvent à plusieurs niveaux simultanément. Une commande de dix lignes peut se diviser en plusieurs tâches de prélèvement, plusieurs contenants et deux colis qui quittent le site sur des mouvements de transport différents. Une expédition peut être manifestée avant le chargement physique, tandis que le scan du transporteur intervient après le départ. Un colis peut passer plusieurs fois par le même événement de tri parce qu’il recircule. Si ces relations sont mal modélisées, le résultat peut être visuellement convaincant mais opérationnellement faux. La qualité de l’intelligence de processus dépend donc autant de la compréhension des sémantiques métier que de la collecte des horodatages.
Le temps d’attente compte souvent davantage que le temps de traitement
L’un des principaux intérêts du Process Mining dans le traitement des commandes tient au fait que les indicateurs classiques de productivité mettent l’accent sur le travail actif, alors que le temps de cycle client inclut tout ce qui se passe entre les activités. Une commande peut ne nécessiter que quelques minutes de prélèvement, d’emballage et de manutention directe, mais passer des heures à attendre un lancement, un réapprovisionnement, une consolidation, la résolution d’une exception ou un départ de transport. Chaque service peut afficher une productivité proche de sa norme alors que la commande de bout en bout reste lente, simplement parce que le retard se situe aux interfaces.
L’analyse événementielle rend ces interfaces visibles. La direction peut comparer le temps entre le lancement et le premier prélèvement, entre l’achèvement des différentes zones et la consolidation, entre la fin de l’emballage et le tri ou entre le staging et le départ physique. Elle peut surtout segmenter ces durées par profil de commande, niveau de service, site, équipe, jour, type d’exception et autres conditions d’exploitation. L’objectif n’est pas de calculer une moyenne supplémentaire, mais de comprendre dans quelles conditions l’attente se forme et si elle est inhérente au service ou produite par la façon dont le travail est séquencé et gouverné.
Les variantes révèlent le processus que l’entreprise exécute réellement
La plupart des processus de traitement des commandes n’ont pas un seul chemin. Ils ont un chemin dominant et une longue traîne de variantes. Certaines sont attendues parce que certains types de commandes exigent un traitement spécifique ; d’autres signalent des reprises, des interventions manuelles, des contrôles système manquants ou des contournements opérationnels. Un modèle de Process Mining peut montrer quelles variantes sont les plus fréquentes, lesquelles consomment le plus de temps, lesquelles sont corrélées aux engagements manqués et lesquelles créent des boucles répétées. Le débat d’amélioration ne porte alors plus seulement sur la conformité de la procédure, mais sur la justification économique et opérationnelle des parcours observés.
Une erreur courante consiste à se concentrer uniquement sur le parcours le plus fréquent. Celui-ci peut représenter la majorité des commandes et bien fonctionner, tandis qu’un petit nombre de variantes d’exception concentre l’essentiel des défaillances de service et du travail manuel. Inversement, un parcours rare peut être parfaitement légitime parce qu’il soutient une exigence client spécifique. La fréquence ne suffit donc pas à fixer la priorité. Il faut la croiser avec l’impact sur le service, la consommation de main-d’oeuvre, le coût des exceptions, la valeur client et le risque de contrôle.
L’analyse de conformité distingue la flexibilité légitime d’une défaillance de contrôle
L’analyse de conformité compare le processus exécuté à un modèle de référence et identifie les écarts. Dans un environnement de traitement des commandes, elle peut faire apparaître des commandes expédiées sans étape qualité attendue, des colis ayant contourné un scan, du travail libéré avant que les prérequis d’inventaire ne soient satisfaits ou des activités transport enregistrées dans un ordre inattendu. Ces constats peuvent être importants, car un écart peut aller d’un simple artefact d’horodatage à une véritable rupture de contrôle.
La direction doit donc éviter d’assimiler tout écart à une non-conformité. Les opérations d’entreprise comportent volontairement des chemins alternatifs pour les clients prioritaires, les pannes d’équipement, les retours, les matières dangereuses, les produits réglementés ou d’autres situations. La bonne question de gouvernance est de savoir si la variation est connue, autorisée et contrôlée. Un modèle mature distingue les variantes approuvées des comportements inexpliqués et permet d’investiguer les écarts récurrents sans imposer une uniformité inutile à des cas qui exigent réellement un traitement différent.
Le Process Mining peut révéler des reprises que les KPI traditionnels masquent
La reprise disparaît souvent dans les indicateurs agrégés parce que la deuxième ou la troisième tentative d’une activité est comptée comme du travail réalisé, plutôt que comme la preuve d’un premier passage en échec. Un colis qui entre plusieurs fois dans le tri, une commande renvoyée à plusieurs reprises vers la gestion des exceptions, une tâche de réapprovisionnement rouverte parce que le stock n’est pas trouvé ou une expédition remanifestée après un changement de transporteur peuvent consommer de la capacité sans apparaître clairement dans un reporting départemental. Les séquences d’événements rendent cette répétition visible lorsque le même cas revient à une activité antérieure ou suit une boucle absente du parcours prévu.
La portée économique dépasse la transaction répétée elle-même. La reprise consomme du temps, de la capacité machine, allonge les files, augmente le temps de cycle, multiplie les manipulations et exige souvent une intervention de supervision. Lorsqu’une boucle récurrente est identifiée, la bonne réponse n’est pas simplement de la supprimer du modèle. Il faut comprendre pourquoi le cas revient dans l’activité, si la cause vient de la qualité des données, du stock, de l’équipement, des règles métier, de la formation ou d’un processus amont et si l’élimination de la cause produit un meilleur résultat de bout en bout.
Les données d’événements doivent être fiables avant que le processus puisse l’être
Le Process Mining peut donner une impression trompeuse de précision parce que les journaux paraissent objectifs. En pratique, les systèmes enregistrent les transactions selon leur propre logique technique et l’horodatage ne représente pas toujours l’événement physique supposé. Une fin de prélèvement peut être enregistrée après plusieurs prélèvements physiques ; un statut transporteur peut arriver par interface après le départ réel ; deux systèmes peuvent utiliser des horloges mal synchronisées. Des événements manquants peuvent donner l’impression qu’une étape a été contournée, tandis que des doublons peuvent créer de fausses boucles.
Une mise en oeuvre sérieuse commence donc par la sémantique des événements et la lignée des données. L’organisation doit savoir quel système produit chaque événement, quelle condition métier le déclenche, si l’horodatage correspond à la survenue de l’événement ou à son ingestion dans le système, quels identifiants le relient aux commandes et aux expéditions et quelles lacunes sont connues. Ce travail est moins spectaculaire qu’une visualisation du processus découvert, mais il détermine si le management peut utiliser l’analyse avec confiance pour des décisions de redesign ou de contrôle.
L’exécution des commandes en entreprise exige des événements provenant de plusieurs systèmes
Aucune application ne contient généralement le processus complet. L’OMS porte la demande et la promesse client, le WMS le stock et les tâches d’exécution, les WES/WCS le comportement de l’automatisation, le TMS la planification des mouvements et des transporteurs, tandis que les équipements et plates-formes de scan produisent des événements physiques. Les retours, le service client et les systèmes financiers peuvent ajouter d’autres étapes. L’intelligence de processus devient beaucoup plus puissante lorsque ces sources sont reliées autour d’entités métier communes plutôt qu’étudiées comme des processus système isolés.
Cela explique aussi pourquoi une analyse techniquement complète dans un seul système peut manquer le problème d’entreprise. Un WMS peut montrer qu’un colis a quitté le processus d’expédition à l’heure alors que le TMS montre que le départ linehaul a été manqué ; le processus entrepôt semble sain tant que les événements transport ne sont pas reliés. Inversement, la logistique peut sembler responsable d’un retard de livraison alors que le colis est entré très tard dans le réseau après une longue exception de traitement des commandes. Le Process Mining de bout en bout dépend donc d’un modèle de données d’entreprise qui préserve les relations entre commandes, colis, sites, transporteurs, routes et engagements clients.
Process Mining et Business Intelligence répondent à des questions différentes
La Business Intelligence agrège généralement des mesures par dimensions : volume par site, productivité par équipe, service par transporteur, coût par lane ou backlog par processus. Le Process Mining organise l’information autour des séquences et des transitions, ce qui le rend particulièrement utile lorsque la direction veut comprendre comment un résultat s’est construit. Les deux approches sont complémentaires. La BI peut montrer qu’un niveau de service s’est dégradé ; le Process Mining peut révéler que les cas touchés empruntent disproportionnellement un parcours d’exception particulier ou accumulent un temps d’attente excessif entre deux activités.
Cette distinction est importante parce que certaines organisations tentent de reproduire le Process Mining à travers des tableaux de bord de plus en plus complexes. Un dashboard peut calculer des temps entre étapes connues, mais lorsque les variantes, boucles et parcours optionnels se multiplient, l’analyse devient difficile à maintenir. À l’inverse, le Process Mining ne doit pas remplacer un reporting opérationnel simple lorsque la séquence n’est pas pertinente. La bonne architecture utilise chaque méthode pour les questions auxquelles elle répond le mieux, sur un socle de données commun et gouverné.
Scénario opérationnel illustratif : la procédure disait que le retard venait du prélèvement
Une opération multi-sites constate un temps de cycle dégradé sur une classe de commandes et se concentre d’abord sur le prélèvement, car les commandes semblent rester plus longtemps que prévu à cette étape. Les ateliers identifient plusieurs améliorations possibles, mais la reconstruction événementielle montre qu’une part importante des commandes est lancée avant que tous les emplacements forward nécessaires soient réapprovisionnés. Les commandes entrent en picking, rencontrent une rupture, passent en exception, attendent le réapprovisionnement puis reviennent au picking. Le WMS attribue une grande partie de ce temps à la phase globale de prélèvement alors que le retard dominant vient de l’interaction entre la logique de lancement et la disponibilité du stock.
La vue issue du Process Mining modifie la décision d’amélioration. Le management peut séparer les commandes ayant suivi le parcours normal de celles entrées dans la boucle liée au réapprovisionnement, quantifier le temps supplémentaire créé par cette boucle et identifier les conditions de lancement qui y sont associées. La réponse n’est donc pas d’ajouter des préleveurs, mais d’adapter les critères d’éligibilité au lancement et la priorité du réapprovisionnement, puis de mesurer si la variante diminue. La valeur de l’analyse vient de l’identification du mécanisme créant le retard, pas d’une visualisation plus détaillée du même KPI.
Utiliser le Process Mining pour prioriser la refonte, pas pour automatiser chaque variante
Une fois les variantes réelles visibles, la tentation existe de traiter chaque différence comme une opportunité d’automatisation. Cette approche peut institutionnaliser la complexité au lieu de la réduire. Si un parcours d’exception existe parce que deux systèmes ne s’accordent pas sur l’état du stock, automatiser l’exception peut accélérer le contournement tout en conservant le problème de données. Si une validation manuelle n’existe que parce qu’une ancienne règle d’approbation n’a jamais été supprimée, la bonne conception peut consister à supprimer l’étape plutôt qu’à la numériser.
Une séquence de redesign rigoureuse demande donc si l’activité est nécessaire, si la variation est légitime, si le processus peut être simplifié, si une règle déterministe peut traiter la condition restante, puis seulement si l’automatisation ou une logique décisionnelle plus avancée apporte de la valeur. Le Process Mining fournit les preuves nécessaires pour choisir où intervenir, mais il ne détermine pas à lui seul la refonte. Les exigences client, le risque, les contraintes technologiques, l’économie et l’expertise opérationnelle restent indispensables.
Le Process Mining multi-sites exige une sémantique commune sans imposer des opérations identiques
Les organisations en réseau tirent une valeur particulière du Process Mining parce qu’elles peuvent comparer comment un même processus nominal est réellement exécuté d’un site à l’autre. Un site peut avoir davantage de variantes en raison de son mix produit, un autre s’appuyer davantage sur la gestion manuelle des exceptions, un troisième présenter un temps d’attente nettement plus long avant le départ transport. Ces différences permettent d’identifier des pratiques transférables ou des conditions structurelles qui expliquent pourquoi les comparaisons brutes de productivité peuvent être trompeuses.
L’analyse n’est crédible que si le réseau partage une sémantique commune des événements. Si un site enregistre « pack complete » à la génération de l’étiquette alors qu’un autre l’enregistre après fermeture physique, une partie de la différence apparente de cycle vient de la mesure. La gouvernance d’entreprise doit donc harmoniser le sens des événements et identifiants critiques tout en préservant les différences locales légitimes. L’objectif n’est pas de rendre tous les sites identiques, mais de rendre le processus suffisamment comparable pour distinguer la variance structurelle de la variance d’exécution évitable.
Construire la capacité autour d’une question de management
Les programmes de Process Mining peuvent devenir des projets technologiques exploratoires lorsque l’organisation commence par charger tous les événements disponibles et cherche ensuite des motifs intéressants. Un meilleur point de départ est une question de management liée à un résultat économiquement important : pourquoi les commandes premium manquent leur cutoff, pourquoi un retour met plusieurs jours à redevenir vendable, pourquoi un site consomme davantage de main-d’oeuvre pour le même service ou pourquoi une exception particulière mobilise autant de supervision. Le périmètre des événements, la définition du cas et la frontière du processus peuvent alors être conçus autour de cette question.
Une fois un ou deux problèmes matériels résolus, le modèle d’événements peut être étendu et réutilisé. Cette approche progressive construit la compréhension institutionnelle de la qualité des données, de la sémantique des processus et de l’interprétation, tout en évitant un investissement de plate-forme important qui produit de belles cartes mais peu de changement opérationnel. Le succès se mesure à la capacité à identifier plus fiablement les causes de processus, à réduire la variation évitable et à redessiner le travail avec davantage de confiance.
Conclusion : trouver le processus avant de le transformer
La transformation du traitement des commandes et de la logistique commence souvent par une cartographie parce que la direction a besoin d’une vision commune de la façon dont le travail devrait circuler. Le risque est de traiter cette carte comme une description fidèle de ce qui se passe vraiment. Les opérations à fort volume accumulent des variantes par les exceptions, le comportement des systèmes, les contournements locaux, l’évolution des exigences client et les décisions pratiques prises par les collaborateurs pour maintenir le service. Avec le temps, le processus exécuté peut s’éloigner sensiblement du modèle voulu alors même que chaque équipe pense appliquer le même standard.
Le Process Mining donne aux dirigeants un moyen d’examiner cet écart de façon systématique en reconstruisant les cas à partir des événements, en révélant où le travail attend, boucle, dévie et traverse les frontières système. Sa valeur est maximale lorsque l’entreprise traite les données d’événements comme des preuves à interpréter, relie l’analyse aux résultats clients et économiques et utilise les constats pour simplifier et repenser le processus avant de l’automatiser. La question stratégique n’est donc pas de savoir si l’organisation possède un processus documenté, mais si la direction peut démontrer comment il est réellement exécuté, identifier les variantes qui comptent et prendre des décisions de transformation à partir de l’opération qui existe plutôt que de celle que chacun suppose exister.
