Voici une chose que mes collègues et clients soupçonnent peu à mon sujet : je suis passionné par la psychologie humaine (me voilà démasqué !). Quel est le rapport avec le monde des processus ? C’est une partie capitale et je ferai l’affirmation suivante : on ne peut pas définir un processus performant si l’on ne prend pas en compte la psychologie humaine. Plus qu’une prise en compte, elle doit être le carburant principal.

Le travers le plus courant est celui de la logique qui consiste pour une personne ou un groupe de personne qui souhaite mettre en place une démarche processus de se draper de la noble logique pour justifier toutes ses décisions. Si cela peut paraître… logique, ce raisonnement à ses limites : celle de la psychologie humaine qui est bien souvent illogique selon l’inconscient collectif. Tout ne peut pas être argumenté et défendu par l’argument de la logique ne serait-ce que pour la simple et bonne raison que la logique est comme le bon sens : pas si universel que nous l’imaginons.

Vous voulez des exemples ? Pourquoi les incitations financières finissent par ne plus avoir d’effet ou pire par démotiver alors que la logique voudrait que plus d’argent est toujours mieux ? Pourquoi lorsque 2 personnes peuvent se partager une somme d’argent que l’on leur donne seulement s’ils sont d’accord, un phénomène fait que si l’un veut avoir plus de 70 %, l’autre préfère abandonner ses 30 % (de l’argent gratuit !) plutôt que de se sentir lésé ?

La logique voudrait qu’un centre d’appel soit entièrement régit par les processus. La réalité c’est que nous avons tous horreur de parler à des conseillers qui lisent des scripts et parlent comme des robots. L’illogique, c’est ce que font d’autres entreprises qui laissent leurs conseillers libres, ne mesurent pas le temps qu’ils passent au téléphone ou ne leurs imposent pas de lire un script (ce qui ne signifie pas qu’il n’y a pas de processus d’ailleurs). Et tous les tests montent que leurs clients sont très satisfaits.

La logique voudrait que lors d’un recrutement si la personne ne convient pas l’on s’en sépare à moindre coût. L’illogique c’est lorsque une entreprise vous propose un mois de salaire à l’issue de votre période d’essai si vous ne vous sentez pas bien. Juste une incitation pour essayer de garder les plus motivés qui marche.

Il existe des centaines d’exemple de cet acabit. Ils ne sont pas logiques mais ils marchent. Un dicton populaire dit aussi « On ne fait pas boire un âne qui n’a pas soif ».

Le paradoxe des processus, c’est qu’après tout l’un des fondements de la démarche est de définir LA bonne manière de faire une série d’activité donnée.  Cela supposerait qu’il suffit de prendre « ce qu’il y a de mieux » et de le déployer / diffuser pour que la performance se répande comme une traînée de poudre à l’image de la mode qui consistait à vouloir copier le modèle Suédois / Danois / Allemand. Ainsi quoi de plus simple que de prendre la meilleure pratique et de la personnaliser en fonction d’un contexte en adaptant quelques mots de vocabulaire ? Si cela vous semble ridicule, c’est ce qu’essaie pourtant de faire des dizaines d’entreprise à des degrés divers. Encore une fois, c’est une approche logique.

Si l’humain est, dans le discours populaire, au centre pourquoi est-il si malmené par les démarches processus ? Pourquoi est-il souvent considéré comme une menace de l’approche ? Pourquoi de trop nombreuses fois est-il même ignoré dans les approches ?

C’est ce que j’appelle le paradoxe des processus où l’on souhaite souvent régir un comportement et créer une habitude tout en laissant peu de place à l’initiative en oubliant parfois que la matière première est humaine.

Ce paradoxe rend évidemment la mise en place de ces approches délicates mais diablement intéressantes et leur réussite ne peut se faire qu’à condition de prendre en compte la psychologie humaine et cela va bien plus loin que d’inclure une phase de « conduite du changement » dans le plan projet !

La nouvelle année débutant tout juste, je souhaite qu’elle soit exceptionnelle pour vous !

Ce moment de l’année est l’occasion de passer en revue les écueils les plus courants des projets BPM pour partir sur de bonnes bases. Je n’ai pas au quotidien pour focus principal le côté négatif des choses mais parfois un inventaire est salutaire pour mettre à plat les plus gros risques auxquels nous sommes quotidiennement exposés dans les projets.

Ces écueils, même si certains sont connus, sont à ne pas oublier et il faut à mon sens surveiller que le projet ne tombe pas dans l’un d’entre eux comme le lait sur le feu tout au long du cycle de vie.

Le monde est rempli d’évidence et tout était si évident que cela nous aurions certainement d’autres problèmes à résoudre. La plupart de ces écueils ne sont d’ailleurs pas propres au BPM mais à la gestion de projet au sens large.

D’ici là et en toute modestie, voici la liste :

Écueil N°1 : trop de promesses, pas assez de résultats

L’un des écueils les plus courants, c’est le fait sur-promettre et de sous-réaliser. L’intégration « sans couture », le déploiement « one click », la modélisation directement exécutable… Le BPM ne manque pas de promesses. Il faut bien promettre et promouvoir cela fait parti du processus de diffusion des pratiques. Ce qui est plus délicat, c’est de mettre en oeuvre les solutions et d’atteindre les résultats promis. Comme pour tout projet, les facteurs sont multiples (parties prenantes, technologies, jeu de pouvoir, enjeu social…) et ne font qu’augmenter le risque potentiel de ne pas atteindre les promesses faites.

Pour réduire ce risque, il est indispensable de découper les grandes promesses en objectifs intermédiaires pour manger l’éléphant une bouchée à la fois. Cela apporte plusieurs bénéfices : un objectif qui parait atteignable, plus motivant que des bénéfices techniques ou virtuels, appréciation du pragmatisme…

Evident ? Attendez la suite !

Écueil N°2 : une mauvaise communication sur les objectifs du projet

A mes débuts lorsque je parlais de mon métier de consultant BPM il arrivait souvent que mon interlocuteur me dise « Ah mais en fait tu est là pour virer les gens ! ». Évidemment à ce moment là, je savais que j’avais échoué dans mon explication et au fur et à mesure j’ai enfin trouvé une manière simple et claire d’expliquer ce que je fais. Non le BPM n’est pas là pour faire en sorte de réduire les ETP pas plus qu’il est destiné à remplacer tout le monde par des processus. Le BPM redonne du sens au travail quotidien en rappelant le pourquoi.

Tout comme je communiquais mal les objectifs du BPM, les projets communiquent mal leurs objectifs. Les failles arrivent souvent à 2 niveaux : le management ne croit pas au projet et donc ne le vend à pas ses équipes (par « vendre » j’entends qu’il n’y a aucun transfert d’enthousiasme) ou les objectifs sont confus ou mal exprimés.

Encore une fois, c’est un cas d’école mais pourtant cela arrive chaque jour dans les projets. D’ailleurs plus les projets sont importants plus la tendance est d’avoir des objectifs complexes ou ambitieux qui sont incompris par les opérationnels. Ces objectifs ne sont souvent pas formulés pour les personnes qui vont subir le changement et entrainent logiquement une résistance voire un rejet.

Communiquer régulièrement et sincèrement est un bon moyen de passer et rappeler les bons messages. Attention ici : le bullshit est immédiatement détecté et ne fera qu’empirer les choses. Dans ce cas mieux vaut ne rien faire.

Écueil N°3 : un besoin flou ou changeant

Comment arriver à atteindre un objectif s’il est mal défini ou qu’il change en cours de route ? Ici le lien avec l’écueil N°1 est évident.

Écueil N°4 : voir la solution au travers de l’outil

Attendre trop de l’outil, notamment qu’il apporte une solution à des problèmes d’organisation, est un classique. C’est malheureusement confier bien trop d’importance au moyen qu’est l’outil. Si la technologie permet de faciliter les choses ou d’y répondre de façon innovante, cela ne reste qu’un moyen qu’il faut mettre en oeuvre de façon raisonnée.

Le besoin doit exister en dehors de l’outil et il doit être formalisé avant le choix d’une solution.

Écueil N°5 : vouloir faire répondre l’outil à 100 % des besoins

Il y a des personnes passionnées par les outils et les solutions techniques et d’autres qui veulent faire plier à leur volonté les technologies qui les entourent. Si l’argent et le temps n’étaient pas un problème, cela pourrait être un petit jeu amusant, un défi technologique. La réalité, c’est que plus l’on personnalise une solution technique, plus les risques classiques sont forts : dépendance à un éditeur, coût de maintenance plus élevé, fuite en avant dans la personnalisation…

Ce type d’écueil fait qu’à la fin les participants du projet éprouvent un sentiment de honte et font la remarque : « avec tout ce que l’on a personnalisé, nous aurions aussi bien fait de développer entièrement un nouvel outil ».

Tous les besoins ne sont pas bons à outiller. C’est d’ailleurs un véritable test pour évaluer ceux qui vous conseillent ou prennent les décisions : savent-ils dire non ?

Écueil N°6 : sous-estimer les compétences requises

Je vais prêcher pour ma paroisse mais je constate très souvent que les décideurs sous-estiment les compétences requises pour mettre en oeuvre un projet BPM. Il y a bien entendu une préoccupation des coûts et souvent un souhait de maitrise en interne qui sont compréhensibles et tout à fait logiques mais il y a un moment pour tout. Il y a confusion entre simple et facile.

Dessiner des boites et des traits (facile) ne produit pas grand chose et nécessite une méthode et une approche (pas simple). Ne pas prendre en compte cet écueil conduit à ce que les participants ne croient même pas à ce qu’ils font (« comment dessiner des boites va nous faire avancer ? ») et bien entendu le communiquent. La prophétie auto-réalisatrice de l’échec est en marche.

La différence de résultat entre avoir les bonnes compétences et faire « à la débrouille » est sans commune mesure. Pourquoi pensez-vous que certains coiffeurs sont payés 10 fois plus que d’autres ? Pourquoi pensez-vous que les services de communication font appel à des traducteurs professionnels et non à la secrétaire ou à un étudiant ? Tout le monde sait écrire (facile) mais est-ce pour autant que nous pouvons tous écrire un best-seller ?

D’après mon expérience, ce facteur est le plus critique lorsqu’il s’agit de prévoir le degré d’atteinte des objectifs d’un projet : y-a-t-il les bonnes personnes à bord ?

Écueil N°7 : pas ou peu d’accompagnement du changement

Vous avez réussi les premières étapes du projet mais vous réalisez avec horreur que les équipes ne sont pas favorables à ce changement. Certaines personnes résistent et résisteront toujours au changement mais cela n’est pas une raison pour négliger cette phase. La pédagogie et l’accompagnement terrain sont essentiels pour assurer la transition entre les anciennes pratiques et le nouvelles.

Avez-vous rencontré ces écueils (ou d’autres) ? Comment les avez-vous contourné ?

Il y a globalement 2 types de projets processus qui existent. Du moins, pour ceux que j’accompagne !
Le premier est poussé par des gens qui croient en la méthode et aux outils de modélisation. Souvent passionnés et prêts à fournir un effort important, ces personnes n’ont pas le soutien de leur direction. Elles profitent au mieux d’une fenêtre ouverte pour tenter de démontrer l’intérêt pour leur entreprise. Souvent, l’approche adoptée, c’est de construire un référentiel d’entreprise. Ici, nous sommes dans la cartographie et le recensement.

L’autre type, c’est le projet processus justement tiré par un projet d’une autre nature. Là, quelqu’un d’assez haut placé et possédant un pouvoir de décision l’exerce pour lancer un projet processus (gestion du risque, Lean Six Sigma…) ou donner une forte couleur processus à un projet d’une autre nature (réoganisation, projet de refonte SI). L’approche sera ici plus « quick & dirty ». Il faut avoir une méthodologie simple et prête à être déployée. Dans ce type de configuration le souhait de mener une démarche d’amélioration continue au travers des processus est rarement exprimé.

Malheureusement les projets dits de référentiel ne durent pas. Ils demandent un travail important pour être réalisés et cet effort fini souvent par disparaitre du paysage comme il est arrivé. Un projet de cette nature peut durer plusieurs années, le temps que celui qui le porte se décourage ou change d’affectation. Durant ce laps de temps, il arrive que des bénéfices directs (financiers) ou indirects soient tirés des travaux de modélisation. Typiquement, ce peut être le fait que le cadrage du nouveau projet soit facilité par la compréhension et l’analyse réalisée en amont ou encore la formation plus rapide des nouveaux arrivants via l’intranet diffusant les nouveaux processus.
Si vous êtes dans cette situation, il est critique de vous raccrocher à un projet et de pouvoir démontrer par A+B l’intérêt de la démarche. J’ai tendance à croire que s’il n’y a pas un soutien affirmé de la direction cela équivaut tôt ou tard à un arrêt de mort. Le soutien n’étant évidemment pas synonyme d’une longue vie

Les projets processus eux n’ont pas vocation à durer (ce qui est la définition même d’un projet). Lorsque le projet est livré, les travaux autour des processus de ce projet s’arrêtent également et la question se pose de savoir qui va gérer le référentiel restant.

Evidemment, ces 2 types de projets ne recouvrent pas l’ensemble des possibles car il existe la situation où l’entreprise gère véritablement ses processus. Dans ce cas, le référentiel vit et est utilisé au quotidien. Les processus sont gérés comme des actifs de l’entreprise. L’activité est améliorée au travers du pilotage par les processus sans tomber dans le travers du « tout processus » et l’équilibre délicat est trouvé. Peu importe le point de départ de la démarche processus, il convient d’en déterminer la vie future avec clairvoyance : tous les référentiels n’ont pas vocation à être maintenus.

Avec l’expérience, j’ai de plus en plus tendance à me méfier de la précision. Serais-je un adepte du flou ? Loin de là. Mais il y a un travers que je constate trop souvent : la confusion entre précision et exactitude.

Vous pouvez constater ça au quotidien. Un tel vous sort ses analyses chiffrées précises pour étayer son point de vue, un autre économiste vous démontre son idée en utilisant l’ensemble des faits historiques d’une précision incroyable ou encore cette personne qui vous vante les mérites de son produit en listant une longue liste de caractéristiques. Chacun d’entre eux est très précis et l’un des biais humain va être de confondre la qualité des données de l’argumentaire avec ce que l’on essaie de démontrer.

Lorsqu’on parle processus, nous n’échappons évidemment pas à la règle. Le travers courant, c’est de vouloir en faire trop. L’excès d’une bonne chose en fait une mauvaise chose. Si la démarche prouve son utilité, elle sera inévitablement étendue mais comment fixer sa limite ? A quelles entités ? Comment limiter les indicateurs que l’on va suivre ? Comment réduire le nombre de processus à piloter ?

Trop souvent, ces choix ne sont pas fait. Le non-choix est un fait un choix de l’organisation et de ses acteurs : celui de la précision en espérant qu’elle mènera à l’exactitude. Si cela peut arriver, les coûts seront décuplés. Je me méfie de la précision lorsque je sens qu’elle est un recours pour cacher le manque d’exactitude. Mieux vaut une approche 80 / 20 qui tire la majorité des bénéfices en un temps et un coût raisonnable.

J’ai récemment eu une discussion intéressante avec l’un des modélisateurs d’un projet que j’encadre. Celui-ci cherchait à démontrer l’intérêt, d’un point de vue business, de la modélisation de processus à son supérieur, autrement dit, il cherchait à démontrer le fameux ROI des travaux en cours.

Le projet en question est ambitieux : il s’agit de documenter les processus d’une organisation internationale pour pouvoir apprécier les différences, les comparer et faire émerger les meilleures pratiques. Au total ce sont plus d’une dizaine de pays concernés et chacun est amené à utiliser l’outil de modélisation et la méthode pour exprimer au mieux sa manière de fonctionner. L’enjeu est donc important, les ressources engagées notables.

Notre échange mis en évidence un point important car les attentes n’étaient pas entièrement cohérentes avec les objectifs du projet. En effet, comment mesurer le ROI issu de la comparaison des processus entre chaque pays ? La réponse n’est pas évidente et si l’organisation espère bien « améliorer » le business, cela ne se traduira pas forcément par un chiffre d’affaires plus élevé mais, de manière plus évidente, par une mise sous contrôle voire une réduction des dépenses. Dans tous les cas, ce n’est pas une affirmation que je ferais dans ce contexte.

Bien entendu, améliorer le business à l’aide des processus est possible mais dans ce cas l’approche devrait être différente. Encore une fois, l’objectif de la modélisation est critique, le pourquoi agi comme des oeillères. N’espérez pas doubler votre chiffre d’affaires en mettant à disposition de vos équipes une base de connaissance.

Les interrogations étaient cependant multiples et très intéressantes :

« Si l’augmentation du chiffre d’affaires n’est pas l’objectif, à quoi sert donc la modélisation ? Quelles entreprises modélisent ? N’est-ce pas ce que cherche toutes les entreprises qui initient ce type de démarche ? Améliorer notre résultat, c’est pourtant bien ce que nous ont vanté les éditeurs de BPMS lors de la dernière présentation ! »

Je passe sur le discours des éditeurs qui est nécessairement vendeur et simpliste. Il est vrai dans le fond mais la réalité est évidemment plus nuancée. Ensuite, qui modélise ? Qui utilise des démarches orientées processus ? Encore une fois, tout dépend de ce que l’on entend par « démarche processus ». Cela va de la simple description de procédure, à la création d’un référentiel local ou international et multilingue, au pilotage opérationnel (BAM) à la gestion du risque et de la conformité, à la mise en place d’un workflow…

La meilleure réponse que j’ai pu donner à ce moment là était : les organisations qui modélisent sont celles qui sont complexes, mal organisées ou celles qui traitent des sujets à haut risque (probabilité faible mais conséquence de la concrétisation du risque élevée) et potentiellement un peu des 3. Les autres n’ont pas le besoin ni même les ressources pour initier de telles démarches.

Améliorer le chiffre d’affaires est évidemment une douce musique aux oreilles des décideurs, les éditeurs le savent bien. Pour autant, j’ai souvent constaté que les bénéfices des travaux de modélisation étaient plus « mous » et intangibles : partager une vision, rapprocher les équipes, faciliter la communication, éviter les erreurs, améliorer les temps de réponses…

Tout ceci contribue in-fine à la fameuse amélioration du chiffre d’affaires mais si c’est un argument vendeur, il est bien plus réaliste pour une organisation dont la maturité processus est faible de commencer par viser l’amélioration de son propre fonctionnement.

J’ai eu l’opportunité de participer à la publication du livre « BPMN Handbook 2.0« . Ma contribution, c’est un chapitre intitulé « BPMN and Business Strategy: One Size Does Not Fit All » co-écrit pour apporter une vision d’ensemble.

Nous y décrivons ce que l’on pense être la « bonne » utilisation de BPMN et sa bonne place dans l’échiquier des normes et méthodes.

Finalement, c’est assez paradoxal car j’étais un supporter important de cette notation à tel point que le précédent nom de domaine de ce blog en comportait le mot. Avec le temps, j’ai remis en perspective les apports de BPMN à la discipline BPM et si je garde une affection particulière pour un langage normé et expressif comme BPMN, je dois reconnaitre que son utilisation dans mon quotidien, sur l’amélioration opérationnel et dans ma relation avec les personnes du métier, est quasi-inexistante.

Je reste convaincu que BPMN est très utile dans la mise en oeuvre opérationnel des processus mais force est de constater qu’il peine à séduire les managers. Si je devais me risquer à une prévision, je dirais que BPMN n’arrivera jamais à le faire. Il demeurera un outil particulier avec une fonction essentielle mais il ne deviendra pas l’espéranto du BPM qu’essaient de nous vendre les éditeurs et les informaticiens.

Il y a 2 raisons à cela : BPMN est trop compliqué et il est trop précis.

Il est trop compliqué car le nombre de symboles graphique est trop important. La solution en vogue depuis quelques années, c’est d’utiliser un jeu réduit de symboles mais cela revient à ne plus vraiment faire du BPMN : vous n’êtes plus « compatible » avec les autres modélisation BPMN susceptibles d’utiliser le BPMN complet, vous créez une adaptation du standard ce qui n’est pas souhaitable.

Enfin, il est trop précis. Il permet d’exprimer du détail inutile pour les modèles à destination des managers. De ce fait, il apporte un niveau de complexité dispensable. Ce travers d’informaticien est à éviter comme la peste. La beauté et l’élégance sont le résultat de l’essentiel, du suffisant, pas du plus complet possible. Les enjeux sont énormes : l’exploitation des modèles et leur maintien dans le temps, 2 défis suffisamment élevés sans BPMN.

BPMN n’est pas nécessaire pour les managers car ils ne se concentrent pas sur les détails qui intéressent les personnes en charge de la mise en oeuvre du workflow.

Il n’est pas à bannir, son intervention est indispensable lorsqu’il faut exécuter des processus mais ne vous laissez pas aveugler par toutes les qualités qu’on lui vante, après tout « One size doesn’t fit all » !