Les équipes investissent des semaines dans l’automatisation de workflows et se heurtent toujours aux mêmes goulots d’étranglement. Le coupable habituel n’est ni l’outil d’automatisation, ni l’intégration, ni la personne qui l’a construit. C’est une erreur de classification commise avant même de placer le premier nœud : elles ont corrigé le workflow alors que le processus était défaillant, ou repensé le processus alors qu’un seul workflow était mal configuré. Comprendre la différence entre un processus métier et un workflow n’est pas un exercice de vocabulaire. Cela détermine la couche que vous devez réellement corriger.
Ce que les équipes apprennent trop tard
- Les workflows existent au sein des processus : les traiter comme une seule et même chose revient à optimiser la mauvaise couche.
- L’ampleur du changement indique quelle couche est défaillante ; automatiser sans ce diagnostic ne fait qu’accélérer le problème.
- Un workflow intégré à un processus défaillant n’échoue pas : il s’exécute parfaitement et aggrave la situation.
Ce qu’est réellement un processus métier (et pourquoi la définition reste floue)
Un processus métier est une séquence structurée et transverse d’activités conçue pour apporter de la valeur à un client ou atteindre un objectif organisationnel précis. Il couvre plusieurs équipes, systèmes et décisions. Il produit un résultat mesurable. Et il existe à un niveau stratégique, ce qui signifie qu’une personne disposant de l’autorité sur l’ensemble de la séquence en est responsable.
C’est sur ce dernier point que la confusion commence. La plupart des équipes utilisent indifféremment les termes « processus » et « workflow » parce qu’ils désignent tous deux des séquences d’étapes. Mais un processus métier répond à la question suivante : que cherchons-nous à accomplir, et comment l’ensemble de l’organisation y contribue-t-il ? La réponse concerne généralement plusieurs services, plusieurs outils et plusieurs fonctions.
Prenons l’onboarding client comme exemple courant. Différents responsables au sein d’une même entreprise peuvent le décrire de manière très différente, et ils ont tous partiellement raison, car il implique le transfert depuis les ventes, le provisionnement des comptes, l’adoption du produit et les opérations de facturation. C’est cette ampleur qui est révélatrice. Un processus métier couvre l’ensemble de ces activités. Il ne réside dans aucune d’entre elles en particulier.
La définition reste floue parce que les outils SaaS modernes ont facilité l’automatisation de séquences de tâches sans jamais cartographier le processus auquel ces tâches appartiennent. Vous pouvez créer un processus de recrutement en un après-midi dans un outil de recrutement sans jamais vous demander s’il est relié au processus d’onboarding, au SIRH ou à la file de provisionnement IT. L’outil a accéléré la mise en place. L’absence de cadre de processus l’a rendu fragile.
Ce qu’est un workflow et où il s’inscrit dans un processus
Un workflow est le parcours d’exécution concret, au niveau des tâches, pour une partie du travail. C’est le comment à l’intérieur du quoi plus large du processus. Là où un processus métier répond à la question « que doit accomplir cette organisation ? », un workflow est une séquence précise d’actions, de décisions et de transferts qui accomplit une unité répétable de ce travail.
Le mot clé est « répétable ». Un workflow se concentre sur une séquence unique et définie : qui fait quoi, dans quel ordre et sous quelles conditions. Il tend à être automatisable, ou au moins partiellement automatisable, précisément parce que le schéma est prévisible.
La manière dont IBM présente cette distinction est utile : un workflow est un système de gestion des tâches répétitives dans un ordre particulier au sein de structures plus complexes. Cette « structure plus complexe » est le processus. Un workflow est la couche d’exécution d’une partie de cette structure.
Cette frontière est importante en pratique. Lorsqu’une équipe dit que « notre workflow d’approbation est défaillant », elle veut généralement dire l’une des deux choses suivantes : soit les étapes ne sont pas correctement routées (un problème de workflow), soit la séquence d’approbation ne devrait tout simplement pas exister sous sa forme actuelle (un problème de processus déguisé en problème de workflow). Savoir auquel vous avez affaire permet de gagner des semaines.
Workflow vs processus : la différence fondamentale en matière de périmètre, d’abstraction et d’impact organisationnel
Voici comment les deux concepts se comparent selon les dimensions qui comptent réellement lorsque vous devez décider lequel corriger :
| Dimension | Processus métier | Workflow |
|---|---|---|
| Périmètre | Transverse ; couvre les équipes, systèmes et décisions | Séquence de tâches unique ; généralement au sein d’une équipe ou fonction |
| Niveau d’abstraction | Stratégique ; définit ce que fait l’organisation et pourquoi | Opérationnel ; définit comment une partie précise du travail est accomplie |
| Responsable | Responsable du processus (souvent un VP, responsable des opérations ou chef de service) | Responsable d’équipe, responsable des opérations ou personne ayant construit l’automatisation |
| Impact organisationnel | Affecte les revenus, l’expérience client ou les coûts à grande échelle | Affecte l’efficacité et la rapidité dans un périmètre défini |
| Outils généralement requis | Plateformes BPM, outils de cartographie des processus, cadres de gouvernance | Logiciels d’automatisation de workflows, gestionnaires de tâches, outils no-code/low-code |
| Quand l’utiliser | Lorsque le même problème réapparaît entre les équipes ou après chaque correction | Lorsqu’une séquence de tâches précise est inefficace ou exécutée manuellement |
Deux éléments ne figurent pas dans ce tableau, mais comptent pour l’amélioration et la conception des processus : l’horizon temporel et la réversibilité. Une modification de processus est une décision structurelle avec des délais plus longs. Une modification de workflow peut souvent être annulée en un après-midi. Si vous ne savez pas à quelle couche vous intervenez, demandez-vous combien de temps il faudrait pour annuler ce que vous êtes sur le point de faire.
La formulation pratique de Businessmap reste valable ici : le processus est l’objectif plus large, le workflow est l’exécution métier structurée d’une partie de cet objectif. Ils ne sont pas en concurrence. L’un contient l’autre.
La hiérarchie que personne n’explique : comment workflows et processus fonctionnent ensemble
Un processus métier contient plusieurs workflows. Chaque workflow gère une séquence de tâches répétable au sein du flux plus large. IBM le décrit directement : les processus métier sont des structures plus complexes composées de plusieurs workflows, systèmes, données et personnes.
Le processus global est donc le conteneur. Les workflows sont les composants qu’il contient. Un processus métier de bout en bout tel que l’onboarding client ne comporte pas une seule séquence d’exécution. Il en comporte plusieurs, exécutées dans l’ordre ou en parallèle, chacune étant détenue par une équipe ou un système différent :
- Un workflow de signature de contrat ; - Un workflow de provisionnement de compte ; - Un workflow de séquence d’e-mails d’introduction ; - Un workflow de configuration de la facturation.
Chacun traite une partie du processus plus large. Chacun peut, en principe, être automatisé indépendamment. Mais ils ne génèrent de valeur que dans le cadre du processus global. Automatisez le workflow de signature de contrat de manière isolée, et vous obtenez des contrats signés qui restent dans une file d’attente parce que l’étape de provisionnement est toujours manuelle. L’automatisation a fonctionné. Le résultat, non.
C’est à ce stade que « processus et workflow » cesse d’être une distinction entre synonymes pour devenir une décision de conception. Lorsque vous construisez une automatisation, la question « quel workflow suis-je en train de résoudre ? » constitue un point de départ valable. Mais elle doit être immédiatement suivie de : « et où ce workflow se situe-t-il dans le processus plus large ? » Sans cette seconde question, vous obtenez des fragments optimisés.
Exemple de workflow au sein d’un processus métier
L’onboarding des employés est l’un des exemples les plus clairs. Le processus d’onboarding couvre les RH, l’IT, la finance et l’équipe directe de la nouvelle recrue. Il englobe tout, de l’acceptation de l’offre jusqu’à la fin des 90 premiers jours. C’est le processus, et il implique plusieurs workflows.
Un workflow gère le processus d’approbation des accès aux systèmes : une demande est soumise, le responsable l’approuve, puis l’IT provisionne les comptes. C’est un workflow. Un autre gère le processus d’onboarding pour la configuration de la paie : les RH soumettent les informations de recrutement, la finance configure la paie et une confirmation est envoyée. C’est un workflow différent. Un troisième peut couvrir la commande d’équipements.
Chaque workflow est autonome. Chacun passe par des systèmes différents avec des responsables différents. Mais tous s’inscrivent dans le processus global d’onboarding des employés. Et si le processus d’onboarding présente un problème, corriger un seul workflow d’approbation ne le résoudra pas, car le problème ne se trouve pas dans les étapes. Il se trouve dans les transferts entre les workflows, ou dans le fait que personne ne possède la séquence de bout en bout.
C’est généralement là que le ticket commence.
Lorsque la frontière entre processus et workflow devient réellement confuse
À une certaine échelle, un workflow commence à ressembler à un processus. Le workflow de gestion des leads dans une entreprise de 200 personnes, par exemple, peut impliquer cinq outils, trois équipes et une douzaine de branches conditionnelles. S’agit-il toujours d’un seul workflow, ou est-il devenu un processus à part entière ?
Il s’agit d’une confusion réelle, et pas seulement d’un désaccord terminologique. La formulation de Tallyfy est utile ici : confondre les deux pousse les équipes à optimiser la mauvaise chose. Le mécanisme compte. Lorsque vous traitez comme un workflow unique ce qui est en réalité un processus, vous l’attribuez à un seul responsable, le cadrez comme un seul projet d’automatisation et négligez les dépendances transverses qui le feront échouer en production.
Voici le test pratique que j’utilise : si le goulot d’étranglement suit le travail au-delà des frontières entre équipes, même après l’avoir corrigé à un endroit, vous êtes probablement face à un processus, et non à un seul workflow. Si le goulot d’étranglement est isolé à une tâche ou à la séquence d’exécution d’une équipe, il s’agit probablement d’un problème de workflow unique.
Workflow vs processus métier : critères de décision pour choisir la couche à corriger
La plupart des équipes savent que quelque chose est cassé. Peu savent à quelle couche le corriger. Voici comment j’aborde les cinq critères réellement utiles.
- Périmètre du changement
Si la correction exige de modifier la manière dont plusieurs équipes se transmettent le travail, vous êtes à la couche processus. Si elle ne modifie que les étapes de la séquence de tâches d’une seule équipe, il s’agit d’un problème de workflow. Faites une cartographie rapide : le comportement défaillant franchit-il la frontière d’un service ? Cette frontière est le signal.
- Niveau d’abstraction
Les problèmes de processus se manifestent sous forme de questions récurrentes sur les règles : « Pourquoi faisons-nous cela ? » ou « Qui est responsable du résultat ici ? » Les problèmes de workflow se manifestent sous forme de questions d’exécution : « Pourquoi cette étape prend-elle trois jours ? » ou « Qui approuve cela avant la suite ? » Si vous vous demandez pourquoi cette chose existe, c’est une question de processus. Si vous vous demandez pourquoi elle est lente ou défaillante, c’est une question de workflow.
- Impact organisationnel
Les échecs au niveau du processus affectent les objectifs métier dans plusieurs services : attrition client, fuite de revenus, lacunes de conformité. Les échecs de workflow affectent l’efficacité au niveau des équipes : SLA non respectés, reprises manuelles, accumulation dans les files de tâches. L’ampleur de la douleur en aval vous indique quelle couche est responsable.
- Gouvernance ou rapidité
La refonte d’un processus exige des parties prenantes, des validations et une conduite du changement. Elle est plus lente. Les modifications de workflow peuvent être effectuées par la personne responsable de l’automatisation. Elles sont plus rapides. Si la correction ne peut pas être autorisée par une seule personne disposant d’un après-midi dans son agenda, elle se situe probablement à la couche processus.
- Outils et compétences nécessaires
L’amélioration d’un processus métier nécessite généralement des outils de cartographie des processus, des ateliers transverses et une personne capable de conserver une vision d’ensemble. Corriger ou automatiser un workflow nécessite des outils d’exécution et quelqu’un capable de les configurer. Si vous avez besoin d’un facilitateur et de trois responsables de service dans une salle, vous êtes à la couche processus. Si vous avez besoin d’un créateur de workflows et de deux heures, vous êtes à la couche workflow.
🤔 Réfléchissez à ceci :
Les équipes qui confondent workflows et processus ne perdent pas seulement du temps à corriger la mauvaise chose : elles automatisent parfois une séquence de tâches qui ne devrait pas exister du tout. L’automatisation s’exécute parfaitement. Le résultat qu’elle devait produire n’a jamais été valable. Ce n’est pas une inefficacité. C’est un coût irrécupérable avec un tableau de bord vert.
Gestion des processus métier vs gestion des workflows : quand la discipline compte
La gestion des processus métier (BPM) est une discipline de gestion à l’échelle de l’entreprise. Elle s’intéresse à la gouvernance, à la mesure et à la conception de séquences interdépartementales qui apportent de la valeur. Une initiative BPM se demande si un processus doit exister sous sa forme actuelle, qui est responsable de ses résultats et comment sa performance est mesurée dans le temps. C’est une question différente de « comment router cette approbation ».
La gestion des workflows est une pratique opérationnelle. Elle coordonne qui fait quoi, dans quel ordre, pour une tâche donnée. Elle gère le routage, les approbations, les notifications et l’automatisation locale. Elle ne se demande généralement pas si la séquence de tâches est justifiée. Elle suppose que la séquence est valide et optimise son exécution.
Les deux disciplines sont légitimes. Elles visent des problèmes différents. Les plateformes BPM, telles que celles proposées par SAP Signavio ou Blue Prism, sont conçues pour la gouvernance des processus à grande échelle : modélisation interdépartementale, analytique, conformité et cycles d’amélioration continue. Elles disposent de la structure organisationnelle nécessaire pour reposer régulièrement la question de la gouvernance au fil du temps. Les logiciels de gestion des workflows, y compris la plupart des outils no-code et low-code, se concentrent sur la rapidité et l’exécution au niveau des tâches.
La formulation de Tallyfy est claire : le BPM demande si une opération devrait exister, tandis que la gestion des workflows demande qui fait quoi et quand. Ce n’est pas une distinction subtile. L’un relève de la stratégie. L’autre de l’exécution.
Les équipes se trompent lorsqu’elles utilisent une discussion sur le BPM pour masquer ce qui est en réalité un problème d’exécution de workflow, ou lorsqu’elles choisissent un outil de workflow pour un dysfonctionnement réellement situé au niveau du processus. Un responsable des opérations qui gère des processus métier dans trois services n’a pas besoin d’un nouveau compte Zapier. Il a besoin d’un système de gestion des processus ou, au minimum, d’un responsable transverse capable de conserver une vision globale.
Ce que l’automatisation des workflows gère bien — et ce qu’elle ne couvre pas
L’automatisation des workflows élimine de façon fiable les étapes manuelles, impose le séquencement et accélère l’exécution au niveau des tâches. Si une personne copie manuellement des données entre trois outils chaque matin, l’automatisation des workflows résout ce problème. Si un e-mail d’approbation reste deux jours dans la boîte de réception de quelqu’un parce qu’il n’existe aucun routage, l’automatisation des workflows résout aussi ce problème. Elle est efficace pour exécuter de manière cohérente une séquence définie sans intervention humaine.
En revanche, elle ne peut pas repenser la logique du processus dans lequel elle s’inscrit. Voici une idée reçue que je vois souvent remonter au support : les équipes supposent que mettre en œuvre l’automatisation des workflows équivaut à une transformation complète des processus métier. Ce n’est pas le cas. Cela signifie que le processus actuel s’exécute plus rapidement, ce qui n’a de valeur que si ce processus mérite d’être exécuté.
Si vous utilisez un logiciel d’automatisation de workflows pour automatiser une séquence défaillante, vous disposez désormais d’une séquence défaillante qui s’exécute à la vitesse d’une machine. La valeur des outils qui automatisent et utilisent l’automatisation des workflows dépend entièrement du fait que la séquence automatisée valait la peine d’être exécutée au départ.
C’est là que Latenode s’inscrit dans la pile technologique. Lorsqu’un responsable des opérations d’une entreprise SaaS en croissance connecte son CRM, sa plateforme de facturation et son outil de support via Latenode afin d’automatiser la séquence entre contrat et compte provisionné, il s’agit d’un cas d’automatisation de workflow au sein d’un processus d’onboarding défini. Le processus a d’abord été cartographié. L’automatisation du workflow prend en charge une partie à forte friction. C’est le bon ordre.
Là où la gestion des workflows et la gestion des processus se rejoignent réellement
Le terrain intermédiaire est plus utile que ne le laisse penser cette opposition. Une pratique de gestion des workflows bien conçue génère les données qui justifient la refonte des processus. Les métriques de débit, la profondeur des files d’attente, les taux d’erreur et les échecs de transfert sont tous des signaux au niveau du workflow qui s’accumulent pour former des preuves au niveau du processus.
C’est le modèle de cycle de vie que Signavio et SAP décrivent : la gestion des workflows s’intègre dans le cycle de vie BPM comme couche d’exécution et de mesure. Vous exécutez les workflows, recueillez les données issues de leur analyse, identifiez les domaines où le processus sous-performe systématiquement et utilisez ces éléments pour piloter la refonte du processus. Le cycle efficace d’amélioration des processus est le suivant : cartographier le processus, l’exécuter via des workflows, mesurer les écarts, repenser.
Un logiciel de gestion des workflows qui vous donne de la visibilité sur l’exécution, et pas seulement sur l’achèvement, constitue le lien entre les deux disciplines. Un workflow Latenode qui enregistre les nombres de tentatives, les codes d’erreur et les échecs au niveau des nœuds fournit au responsable du processus des données concrètes indiquant où la séquence échoue, des informations dont il a besoin avant de repenser quoi que ce soit.
Conception des workflows et optimisation des processus : là où la plupart des équipes commencent mal
Le problème de séquence est presque toujours le même. Les équipes commencent à automatiser des workflows individuels avant d’avoir cartographié le processus auquel ces workflows appartiennent. Le résultat : des fragments optimisés qui ne se connectent pas.
J’ai vu ce scénario se reproduire suffisamment souvent pour reconnaître le schéma rapidement. Quelqu’un crée un workflow de capture de leads. Puis un workflow de scoring des leads. Puis un workflow d’e-mails de suivi. Trois mois plus tard, l’équipe dispose de diagrammes de workflows pour chacun, d’une documentation complète, de taux d’exécution solides, et d’un taux de conversion lead-vers-clôture qui n’a pas bougé. Parce que les workflows ne se transmettent pas proprement le travail, les données ne circulent pas de manière cohérente et personne ne possède la séquence de bout en bout. Ils ont construit l’automatisation des workflows et des processus de l’intérieur vers l’extérieur : tâche par tâche, sans cadre métier global.
L’idée reçue à l’origine de cela est que « workflow » et « processus métier » sont interchangeables, donc que construire des workflows revient à construire le processus. Ce n’est pas le cas. Construire des workflows, c’est exécuter le processus. Le processus doit exister d’abord, au moins sous la forme d’une cartographie approximative de qui fait quoi, dans quel ordre, et du résultat attendu. Sans ce cadre, vous construisez des fragments optimisés appartenant à un processus que personne n’a défini.
Commencez par l’objectif métier plus large. Cartographiez la séquence complète d’activités nécessaire pour l’atteindre, même de manière approximative. Identifiez les transferts. Trouvez ensuite la partie de cette séquence qui génère le plus de friction et mettez en place l’automatisation du workflow à cet endroit. C’est l’ordre qui produit une automatisation connectée, et non des chaînes de tâches isolées.
La vérification pratique avant de lancer un projet d’automatisation : pouvez-vous dessiner le processus dans lequel ce workflow s’inscrit ? Si la réponse est non, « c’est compliqué » ou « cela dépend de la personne à qui vous demandez », vous n’êtes pas encore prêt à automatiser. Cartographiez d’abord. Construisez ensuite une automatisation des workflows et des processus qui soit connectée.
Types de workflows et cadre de processus requis pour chacun
Tous les workflows n’entretiennent pas la même relation avec leur processus parent. Leur type est important pour déterminer si vous pouvez les automatiser indépendamment ou si vous devez d’abord repenser le processus.
Les workflows séquentiels exécutent les étapes dans un ordre fixe, l’une après l’autre. La structure du workflow est prévisible. Ils peuvent généralement être automatisés indépendamment, car la séquence est contenue et les dépendances sont claires. Les schémas de ces workflows sont généralement simples et linéaires.
Les workflows parallèles se divisent en branches simultanées qui fusionnent plus tard. Chaque workflow de ce type se compose de parcours qui doivent être terminés avant que la fusion puisse avoir lieu. Ils sont eux aussi souvent automatisables indépendamment, mais la condition de fusion constitue un point d’échec fréquent : lorsqu’une branche se termine et que l’autre est retardée, le workflow se bloque sans explication.
Les workflows à états et conditionnels sont routés selon des données ou des événements. Ce sont ceux qui ont le plus de chances d’être profondément intégrés à des processus transverses. Lorsque la logique de routage encode des règles métier, et non de simples règles de tâche, le workflow porte des décisions au niveau du processus. Avant d’automatiser, vérifiez si ces conditions de routage sont stables ou si elles évoluent avec les politiques métier. Si elles évoluent avec les politiques, le workflow devra être repensé à chaque changement de politique. Il s’agit d’un problème de cadre de processus, et non de configuration du workflow.
Les workflows fondés sur des règles fonctionnent de manière similaire aux workflows conditionnels, mais sont pilotés par des règles métier explicites : seuils d’approbation, exigences de SLA, conditions de conformité. Ils se situent à la frontière entre la gestion des workflows et la gouvernance des processus. Chaque workflow de ce type doit être examiné avant automatisation afin de confirmer que les règles sont à jour et détenues par une personne qui les mettra à jour lorsque la politique changera.
Outils de workflow vs outils de gestion des processus : lequel utiliser et dans quel cas
Les outils d’automatisation des workflows et les plateformes BPM ne se disputent pas le même rôle. Ils résolvent des problèmes différents à des échelles organisationnelles différentes.
Les outils de workflow — la catégorie SaaS freemium et intermédiaire — gèrent le routage des tâches, les approbations et l’automatisation de séquences spécifiques. Ils sont conçus pour l’exécution : une personne construit un workflow, cartographie les étapes, configure les déclencheurs, puis l’outil l’exécute. Les produits de cette catégorie sont accessibles aux profils non techniques, rapides à configurer et adaptés aux problèmes au niveau des équipes. Choisir le bon outil de workflow dépend de la couverture d’intégration, du niveau de logique personnalisée requis et de la personne qui le maintiendra dans six mois.
Les logiciels de gestion des processus métier, y compris les plateformes d’entreprise de SAP Signavio, IBM et fournisseurs similaires, prennent en charge la modélisation de processus interdépartementaux, l’analytique, la simulation et la gouvernance. Ce sont des outils institutionnels. Ils nécessitent du temps d’onboarding, des responsables de processus en interne et l’adhésion de l’organisation pour générer de la valeur. Ils ne sont pas inadaptés aux PME, mais l’argument du ROI est différent pour une entreprise de 40 personnes et une autre de 4 000 personnes.
| Catégorie d’outil | Idéal pour | Utilisateurs typiques | Ce que cela ne résout pas |
|---|---|---|---|
| Outils d’automatisation de workflows | Routage des tâches, connexions API, séquences répétables | Opérations, marketing ops, RevOps, responsables du support | Gouvernance interdépartementale, modélisation des processus |
| Logiciels d’automatisation des processus métier | Automatisation à grande échelle d’étapes de processus définies | IT d’entreprise, spécialistes BPM | Conception du processus, conduite du changement à l’échelle de l’organisation |
| Logiciels de gestion des processus métier | Conception, mesure et gouvernance des processus de bout en bout | Responsables de processus, architectes d’entreprise | Exécution rapide au niveau des tâches, corrections de workflows individuels |
La question pratique avant tout achat est la suivante : cherchez-vous à exécuter une séquence plus rapidement, ou cherchez-vous à comprendre et repenser la manière dont la valeur circule dans l’organisation ? Le premier cas est un problème d’outil de workflow. Le second est un problème de discipline BPM.
🤔 Attendez.
La plupart des équipes qui recherchent un logiciel de workflow sont en réalité confrontées à un problème de processus qu’aucun outil de workflow ne pourra résoudre. Et la plupart des équipes qui recherchent des plateformes BPM obtiendraient des résultats plus rapides en corrigeant d’abord un ou deux workflows concrets. Le choix d’un outil est d’abord un problème de diagnostic avant d’être une comparaison de fonctionnalités. Si vous ne pouvez pas clairement indiquer quelle couche est défaillante, acheter un logiciel ne vous aidera pas.
Boucler la boucle : ce que cela change réellement au niveau de la mise en œuvre
Voici la version pratique de tout ce qui précède. Avant de cadrer le prochain projet d’automatisation, passez en revue quatre questions :
- Pouvez-vous dessiner le processus complet auquel appartient ce workflow, y compris la personne responsable de chaque transfert ? 2. Le problème est-il isolé à la séquence d’exécution d’une équipe, ou couvre-t-il plusieurs services ? 3. Si vous corrigez ou automatisez ce workflow aujourd’hui, le résultat s’améliorera-t-il, ou quelque chose en amont ou en aval le bloquera-t-il ? 4. Qui est responsable du processus dans lequel ce workflow s’inscrit, et cette personne a-t-elle validé la modification du workflow ?
Si vous ne pouvez pas répondre à la première question, vous n’êtes pas prêt à automatiser. Ce n’est pas une critique. C’est l’information la plus utile que je puisse donner à quelqu’un sur le point de passer trois semaines à construire quelque chose qui ne fera pas évoluer le résultat.
Les équipes que j’ai vues réussir n’ont pas de meilleurs outils ni de budgets plus importants. Elles ont d’abord cartographié le processus, même approximativement, même sur un tableau blanc. Elles ont identifié l’endroit où la séquence était la plus défaillante. Elles ont corrigé cette partie. Elles ont observé le résultat. Puis elles ont étendu la démarche.
C’est tout. Construisez la carte avant de construire l’automatisation.
