Chaque projet de commerce électronique à grande échelle a une version de cette histoire. La plateforme fonctionne. Les données se synchronisent. Le lancement tient le calendrier. Puis l'équipe opérationnelle s'aperçoit qu'un flux de travail qu'elle exécute cinquante fois par jour n'existe nulle part dans le système. Le problème n'est pas l'absence de développeurs talentueux. C'est que personne n'a jamais demandé à l'équipe ce qu'elle fait réellement avant d'écrire les exigences.
C'est un échec de cartographie des processus, pas un échec technologique. La plateforme a fait exactement ce qu'elle a été programmée pour faire. Sauf qu'elle a été programmée pour faire les mauvaises choses, ou pas assez des bonnes choses, parce que la réalité opérationnelle du métier n'a jamais été entièrement documentée avant la construction.
La méthodologie LEAN est née dans la fabrication automobile pour éliminer le gaspillage et accélérer la livraison. Les principes s'appliquent directement à l'automatisation des processus métier. Le concept central demeure le même partout où vous l'appliquez. Le gaspillage dans un système vient presque toujours de trois sources : les transitions de processus qui ne sont jamais définies, les étapes redondantes que personne n'a remises en question, et les règles métier qui existent seulement dans la tête des gens et nulle part ailleurs.
La cartographie des processus doit précéder l'automatisation
La réflexion LEAN commence par la cartographie de la chaîne de valeur. Vous documentez chaque étape que vos équipes font actuellement, qui la possède, combien de temps elle prend, ce qui la déclenche, et quel résultat elle crée. Vous cherchez les étapes qui n'ajoutent aucune valeur. Vous identifiez où l'information se perd entre les transitions. Vous trouvez où le processus attend au lieu d'avancer.
Quand vous appliquez cela aux processus fournisseurs, cela signifie interroger le métier avant d'ouvrir votre plateforme. Que fait réellement votre équipe d'approvisionnement aujourd'hui? Montrez-moi chaque étape. Que se passe-t-il quand une demande de fournisseur est ambiguë ou incomplète? Combien de variables existent vraiment? À quoi ressemble un dossier entrant comparé à un dossier approuvé? Quelles règles disqualifient automatiquement un fournisseur?
La plupart des équipes qui lancent une automatisation sautent ce travail. Elles commencent par l'état final souhaité et travaillent à rebours. Le résultat est un système qui excelle quand tout est parfait et qui échoue silencieusement quand les cas réels arrivent. Les cas réels arrivent tous les jours.
Avant toute décision d'architecture, avant toute sélection de plateforme, avant que la première exigence soit écrite, quelqu'un doit poser une seule question. Qu'est-ce que votre équipe fait réellement, étape par étape, quand elle traite une demande de fournisseur? Pas ce qu'elle devrait faire selon le manuel. Ce qu'elle fait vraiment. L'écart entre ces deux réalités est l'endroit où la plupart des implémentations se cassent le nez.
Comment 120 marques fournisseurs ont révélé les failles du processus
La plateforme Empower Global a été créée pour permettre à 120 marques détenues par des Noirs de vendre par une seule place de marché. Cela signifiait établir un processus d'intégration des fournisseurs. Un processus d'examen des demandes. Un processus de qualification. Et un système pour identifier les vendeurs qui allaient causer des problèmes ou endommager la réputation de la plateforme.
Avant que TechSparq automatise le flux dans Salesforce Service Cloud, le processus était entièrement manuel et ralentissait à chaque étape. Les demandes arrivaient. Quelqu'un les lisait. Quelqu'un prenait une décision sur la qualification. Quelqu'un relançait les demandes manquantes. Parfois. Quelqu'un suivait le statut dans une feuille de calcul qui était toujours légèrement obsolète. Les mauvais acteurs n'étaient pas détectés rapidement. Les fournisseurs qualifiés attendaient plusieurs semaines pour des décisions qui auraient dû prendre quelques jours. L'équipe passait 60 pour cent de son temps d'examen à faire du travail qu'une plateforme bien conçue pourrait automatiser en secondes.
C'est la signature d'un problème LEAN. L'équipe avait un vrai travail à faire qui demandait du jugement. Ils avaient besoin d'évaluer les demandes complexes. Prendre les décisions finales sur les cas limites. Construire les relations stratégiques avec les meilleurs fournisseurs. C'était le travail qui justifiait leur temps. Tout le reste, le criblage initial, l'élimination des disqualifications évidentes, le routage automatique des demandes, le suivi du statut, les notifications de suivi, était du bruit opérationnel. Cela devait être fait. Mais pas par des gens à chaque étape.
Pourquoi la conception du processus a précédé l'automatisation
La première chose que nous avons faite a été de cartographier la réalité opérationnelle. Pas le processus idéal. La façon dont l'équipe travaillait réellement quand les choses étaient ambiguës, borderline, ou problématiques. Nous avons documenté chaque point de décision. Nous avons identifié où l'intelligence humaine était vraiment requise versus où le processus suivait simplement une règle.
La plupart des critères de disqualification étaient des règles binaires. Demandes incomplètes. Documentation manquante. Catégories de produits hors du périmètre. Localisations non supportées. Points de prix incompatibles avec le positionnement de la plateforme. Aucun de ces critères ne demandait un jugement humain. Ils demandaient une liste de vérification que Salesforce Service Cloud pouvait exécuter automatiquement en quelques secondes dès la soumission.
La logique de qualification était plus nuancée. Nous avons conçu un système de notation intégré à Service Cloud qui évaluait chaque demande par rapport aux critères définis. Les demandes avec un score élevé passaient à un examen rapide. Les demandes avec un score moyen allaient à un examen approffondi avec une fiche de contexte pré-remplie permettant à l'examinateur de voir tout ce dont il avait besoin sur un seul écran. Les demandes avec un score bas recevaient un refus automatisé respectueux qui laissait la porte ouverte pour une nouvelle candidature.
Le résultat a été que le temps d'examen de l'équipe s'est concentré entièrement sur les demandes qui exigeaient un jugement réel. Ils ont arrêté de passer des heures sur des dossiers qui n'allaient jamais être approuvés. Ils ont arrêté de chercher le statut des demandes à travers une feuille de calcul. Ils ont arrêté de manquer des relances parce que le système gérait tout. Leur énergie a été libérée pour les décisions qui comptaient vraiment.
Comment l'architecture des processus transforme les résultats de plateforme
L'automatisation chez Empower Global n'était pas remarquable pour la technologie utilisée. Salesforce Service Cloud est une plateforme mature avec des outils de flux bien documentés. N'importe quelle équipe Salesforce compétente peut mettre en place l'acheminement automatisé et la notation.
Ce qui l'a rendue efficace a été l'architecture de processus qui a précédé chaque ligne de configuration. Nous avons passé du temps à cartographier le flux réel avant d'ouvrir le système. Nous avons identifié les points de décision critiques. Nous avons demandé à l'équipe opérationnelle de nous parcourir chaque scénario dont elle se souvenait, incluant les scénarios difficiles, les exceptions, les choses qui avaient mal tourné. Nous avons documenté ce qui passait, ce qui échouait, ce qui était incertain, et ce que chacun devait déclencher dans la plateforme.
Ce travail n'est pas glamoureux. Il n'apparaît jamais dans un plan de projet comme un livrable daté. C'est le type de préparation que les équipes sautent quand elles sont sous pression pour montrer de la vélocité. Et c'est exactement pour cela que les plateformes se créent qui ne correspondent pas à la réalité opérationnelle qu'elles supposément supportent.
La méthodologie LEAN vous donne le cadre pour forcer ce travail à arriver avant la construction. Cartographie avant l'architecture. Définition de processus avant la configuration. Réalité opérationnelle avant exigence technique. C'est plus lent au début. C'est dramatiquement plus rapide à la fin, parce que vous ne passez pas six mois à reconstruire les flux pour correspondre à ce que le métier a toujours vraiment eu besoin.
Empower Global est un exemple d'un principe qui s'applique à chaque implémentation de plateforme eCommerce. La technologie n'est jamais la partie difficile. La partie difficile est de savoir ce que la technologie doit faire avant de commencer. Cette connaissance vient du temps passé avec l'équipe opérationnelle à cartographier les flux réels, pas de la lecture d'un document d'exigences écrit par quelqu'un qui n'a jamais observé le métier en action.
Ce que cela signifie pour votre prochaine implémentation fournisseur
Si vous planifiez une automatisation des processus fournisseurs ou une implémentation eCommerce majeure, la chose la plus précieuse que vous puissiez faire avant votre première réunion technique est de passer du temps avec les gens qui font le travail opérationnel. Regardez-les travailler. Posez des questions sur ce qui se casse. Demandez ce qui prend trop de temps. Demandez ce qu'ils souhaiteraient que le système puisse faire. Demandez comment ils gèrent les cas qui ne correspondent pas au modèle normal.
Ensuite, documentez ce que vous avez appris. Cartographiez chaque étape. Marquez les points de décision critiques. Identifiez les transitions où l'information se perd. Trouvez les points d'attente. Trouvez la redondance. Trouvez les règles qui existent seulement dans les têtes des gens et pas dans aucun système.
Cette carte est votre architecture de processus. Elle vous dit ce que la plateforme doit faire avant que quelqu'un ne touche un écran de configuration. Elle vous dit quelles étapes doivent être automatisées, lesquelles demandent du jugement humain, et lesquelles ne devraient pas exister du tout parce qu'elles sont simplement du gaspillage.
Les organisations technologiques qui font cela correctement créent des systèmes que leurs équipes métier utilisent vraiment et en qui elles ont confiance. Celles qui le sautent créent des systèmes qui accumulent les contournements jusqu'à ce que le système soit essentiellement abandonné même s'il s'exécute techniquement.
La différence n'est pas la plateforme. C'est la discipline de processus qui a précédé la construction.
Votre plateforme doit fonctionner comme votre métier fonctionne réellement.
TechSparq applique la cartographie LEAN à chaque implémentation de plateforme. Nous documentons la réalité opérationnelle avant d'écrire une ligne d'exigences. Si vous planifiez une automatisation de fournisseurs, une implémentation eCommerce à l'échelle, ou une transformation post-lancement, commencez par une conversation sur le processus avant la technologie.
Planifier une consultation d'architecture des processus ↗︎