Chaque projet de technologie d'entreprise a une version de cette histoire. La construction se déroule bien. L'intégration semble propre. La date de lancement tient. Ensuite, la plateforme entre en production et l'équipe opérationnelle découvre qu'un flux de travail qu'elle fait quarante fois par jour n'existe nulle part dans le système. Non pas parce que les développeurs l'ont manqué. Parce que personne n'a demandé à son sujet avant que les exigences ne soient écrites.
Ce n'est pas un échec technologique. C'est un échec de documentation des processus. La technologie a fait exactement ce qu'on lui a dit de faire. Le problème, c'est qu'on lui a dit de faire les mauvaises choses, ou pas assez des bonnes choses, parce que la réalité opérationnelle de l'entreprise n'a jamais été entièrement cartographiée avant que la construction commence.
La méthodologie LEAN est souvent discutée dans le contexte de la fabrication ou de la logistique. Les principes s'appliquent directement aux logiciels et à la livraison des plates-formes. L'idée centrale est la même partout où vous l'appliquez. Le gaspillage dans un système est presque toujours causé par des transitions de processus peu claires, des étapes redondantes que personne n'a jamais remises en question, et des hypothèses intégrées au travail que personne n'a écrites.
La lentille LEAN appliquée à la livraison de plates-formes
La réflexion LEAN commence par la cartographie de la chaîne de valeur. Vous documentez chaque étape d'un processus, qui la possède, combien de temps elle prend, ce qui la déclenche, et ce qu'elle produit. Vous cherchez les étapes qui n'ajoutent pas de valeur. Vous cherchez les points de transition où l'information se perd. Vous cherchez les lieux où le processus attend plutôt que de progresser.
Appliquées à la construction d'une plateforme, ces questions ressemblent à interroger les opérations avant d'écrire les exigences techniques. Que fait réellement votre équipe aujourd'hui ? Parcourez-moi chaque étape. Que se passe-t-il quand quelque chose va mal ? Que se passe-t-il quand cela fonctionne parfaitement ? Combien d'exceptions existent au flux standard ? À quoi ressemble un nouveau dossier quand il entre dans le système, et à quoi ressemble-t-il quand il le quitte ?
La plupart des équipes de projet sautent ce travail. Elles commencent par l'état final souhaité et travaillent à rebours. Le résultat est un système qui gère bien le cas idéal et s'arrête silencieusement chaque fois qu'un cas limite du monde réel arrive. Les cas limites arrivent tous les jours.
Avant toute décision architecturale, avant toute sélection de fournisseur, avant que toute exigence technique soit écrite, quelqu'un doit poser une question. Que fait réellement votre équipe, étape par étape, quand elle traite ce type de travail aujourd'hui ? Pas ce qu'elle devrait faire. Ce qu'elle fait réellement. Le delta entre ces deux réponses est l'endroit où la plupart des projets échouent.
À quoi ressemblait vraiment le problème de demande de fournisseur
La place de marché Empower Global a été construite pour soutenir 120 marques détenues par des Noirs vendant sur une plateforme unique. Cela signifiait un processus d'intégration des fournisseurs. Et un processus d'examen des fournisseurs. Et un processus d'approbation des fournisseurs. Et un mécanisme pour identifier les vendeurs qui gaspilleraient le temps de l'équipe ou endommagent activement l'intégrité de la plateforme.
Avant que TechSparq automatise le flux de travail dans Salesforce Service Cloud, le processus d'examen était manuel et lent. Les demandes arrivaient. Quelqu'un les lisait. Quelqu'un faisait un jugement sur le fait que le fournisseur répondait aux normes de la place de marché. Quelqu'un assurait le suivi. Parfois. Quelqu'un suivait l'état de chaque demande dans une feuille de calcul qui était toujours légèrement à jour. Les mauvais acteurs n'étaient pas détectés rapidement. Les fournisseurs qualifiés attendaient des semaines pour des réponses qu'ils auraient dû recevoir en jours. L'équipe passait la majorité de son temps d'examen à faire un travail qu'un système bien conçu pouvait faire automatiquement.
C'est un diagnostic LEAN. L'équipe avait un travail clair qui ajoutait de la valeur à faire. Ils devaient évaluer les fournisseurs avec des demandes complexes ou ambiguës. Prendre les décisions d'approbation finale. Construire des relations avec des fournisseurs solides. C'était le travail qui valait leur temps. Tout le reste, le criblage initial, la disqualification des mauvais acteurs évidents, le routage des demandes vers le bon examinateur, le suivi du statut, les communications de suivi, était du bruit opérationnel. Travail nécessaire. Mais un travail qui ne devrait pas exiger une décision humaine à chaque étape.
Comment nous avons conçu l'automatisation. Et pourquoi la conception a précédé la construction.
La première chose que nous avons faite était de cartographier le processus. Pas le processus tel qu'il devrait fonctionner. Le processus tel qu'il fonctionnait réellement quand les choses tournaient mal, quand les demandes étaient limites, quand un fournisseur semblait qualifié sur le papier mais soulevait des préoccupations à l'examen. Nous avons documenté chaque point de décision. Nous avons identifié chaque étape où un humain prenait un jugement d'appel, et nous avons demandé si ce jugement d'appel exigeait l'intelligence humaine ou s'il suivait un ensemble de règles qui pouvaient être codées.
La plupart des critères de disqualification étaient des règles. Demandes incomplètes. Documentation manquante. Catégories de produits en dehors du champ d'application de la place de marché. Localisations en dehors de la géographie soutenue. Points de prix incompatibles avec le positionnement de la place de marché. Aucun de ceux-ci n'exigeait un examen humain. Ils exigeaient une liste de contrôle que Salesforce Service Cloud pouvait exécuter automatiquement, en secondes, à la soumission.
La logique de qualification était plus nuancée. Nous avons construit un système de notation dans Service Cloud qui a évalué les demandes de fournisseurs par rapport à un ensemble de critères définis. Les demandes qui ont obtenu un score au-dessus d'un seuil ont accédé à un examen léger. Les demandes qui ont obtenu un score dans une bande intermédiaire ont fait l'objet d'un examen plus approfondi avec une fiche de contexte pré-remplie de sorte que l'examinateur avait tout ce dont il avait besoin sur un écran. Les demandes qui ont obtenu un score inférieur au minimum ont été automatiquement déclinées avec une réponse modélisée qui était respectueuse et laissait la porte ouverte pour une renouvellement.
Le résultat était que le temps d'examen de l'équipe s'est concentré sur les demandes qui les nécessitaient réellement. Ils ont arrêté de passer des heures sur les soumissions qui n'allaient jamais être approuvées. Ils ont arrêté de chasser les mises à jour du statut des demandes à travers une feuille de calcul. Ils ont arrêté de manquer les suivi parce que le système gérait le flux de travail de communication. Leur énergie a été consacrée aux décisions qui exigeaient du jugement.
Ce que la conception de processus LEAN produit réellement dans une construction de plateforme
Le travail d'automatisation sur Empower Global n'était pas remarquable en raison de la technologie. Salesforce Service Cloud est une plateforme mature avec des outils de flux de travail bien documentés. Toute équipe Salesforce compétente peut construire l'acheminement et la notation automatisés dans Service Cloud.
Ce qui l'a rendu efficace était l'architecture des processus qui a précédé la configuration. Nous avons passé du temps à cartographier le flux de travail réel avant d'ouvrir la plateforme. Nous avons identifié les véritables points de décision. Nous avons demandé à l'équipe opérationnelle de nous parcourir chaque scénario dont elle se souvenait, y compris les scénarios difficiles, y compris les exceptions, y compris les choses qui avaient mal tourné. Nous avons documenté ce qui avait l'air bon et ce qui disqualifiait et ce qui était incertain et ce que chacun devait déclencher dans le système.
Ce travail n'est pas glamoureux. Il ne figure pas dans un plan de projet en tant que livrable avec une date limite. C'est le type de préparation qui est sauté quand une équipe est sous pression pour montrer des progrès visibles. Et le sauter est exactement pourquoi les plates-formes sont construites qui ne correspondent pas à la réalité opérationnelle qu'elles étaient censées servir.
La méthodologie LEAN vous donne un cadre pour forcer ce travail à se produire avant la construction. Cartographie de la chaîne de valeur avant l'architecture. Définition des 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 reconstruisez pas les flux de travail après le lancement pour correspondre à ce que l'équipe a réellement besoin.
Le flux de travail de fournisseur Empower Global est un exemple d'un principe qui s'applique à chaque implémentation de plateforme. La technologie n'est pas la partie difficile. La partie difficile est de savoir ce que la technologie doit faire avant de commencer à construire. Cette connaissance vient du temps passé avec l'équipe opérationnelle à cartographier les flux de travail réels, pas à lire un document d'exigences écrit par quelqu'un qui n'a jamais regardé l'équipe travailler.
Ce que cela signifie pour votre prochain projet de plateforme
Si vous prévoyez une implémentation de plateforme ou un projet d'automatisation de flux de travail important, la chose la plus utile que vous pouvez 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. Demandez-leur ce qui se casse. Demandez-leur ce qui prend trop de temps. Demandez-leur ce qu'ils souhaiteraient que le système puisse faire qu'il ne peut pas actuellement faire. Demandez-leur ce qu'ils font quand un dossier arrive qui ne correspond pas au modèle normal.
Ensuite, cartographiez ce que vous entendez. Documentez chaque étape. Marquez les points de décision. Identifiez les points de transition. Trouvez l'attente. Trouvez la redondance. Trouvez les hypothèses qui sont dans la tête de quelqu'un et non 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 exigent du jugement humain, et lesquelles ne devraient pas exister du tout parce qu'elles sont du gaspillage pur déguisé en procédure.
Les organisations technologiques qui le font correctement construisent des systèmes que leurs équipes opérationnelles utilisent réellement et en qui elles ont confiance. Celles qui le sautent construisent des systèmes qui accumulent des contournements jusqu'à ce que le système soit fonctionnellement abandonné même s'il s'exécute techniquement.
La différence n'est pas la plateforme. C'est la discipline des processus qui a précédé la construction.
Votre plateforme devrait fonctionner de la façon dont votre équipe fonctionne réellement.
TechSparq applique la conception de processus LEAN à chaque engagement de plateforme. Nous cartographions la réalité opérationnelle avant d'écrire une exigence technique. Si vous planifiez une construction de plateforme, une automatisation de flux de travail, ou une révision opérationnelle post-lancement, commencez par une conversation sur le processus avant la technologie.
Réserver une consultation en architecture des processus ↗︎