Mettre en œuvre le changement de manière efficace

Les responsables de processus se sentent souvent déçus par la direction parce que les responsables de leurs services s'en tirent toujours à bon compte en contournant les processus convenus. Après l'euphorie initiale, l'attention de la direction pour les projets de gestion des processus s'endort souvent. Une fois les modèles en place, il ne se passe rien. Dans ce qui suit, nous examinerons comment les gestionnaires de processus s'assurent que les projets de BPM survivent dans les activités quotidiennes et maintiennent l'adhésion de tous au cours des processus de changement.

En quoi consistent les projets BPM

Lorsque les projets BPM échouent, c'est souvent en raison d'attentes peu claires. Les projets de gestion des processus sont souvent dotés de la mission "d'introduire la gestion des processus". Cependant, la gestion des processus n'est pas un objectif, mais un ensemble de méthodes ; sans objectif, il devient toutefois difficile de mobiliser l'"attention de la direction" nécessaire au projet BPM. Bien sûr, il est logique d'utiliser des méthodes de gestion professionnelles dans l'entreprise. Et bien sûr, il faut plus d'efforts au début pour ancrer le savoir-faire et les bases des méthodes dans l'entreprise. C'est pourquoi il semble qu'un projet BPM vise à introduire le BPM. Mais les apparences sont trompeuses. Il s'agit de résoudre des problèmes organisationnels concrets : Le taux de clôture des prêts est trop faible, la ferraille en production est trop élevée, un nouveau logiciel doit être introduit, etc. Souvent, des groupes de projet distincts existent pour la solution de ces problèmes parallèlement au projet BPM - dans le pire des cas, même en concurrence avec celui-ci.

Pourquoi les projets BPM échouent

Les projets de BPM doivent souvent vivre avec des objectifs de cire : "Nous voulons apprendre à penser en termes de processus", disent-ils, "créer une conscience des processus", telle est la demande. Souvent, le modèle de processus est également vendu comme un objectif organisationnel - comme si le modèle lui-même avait déjà un certain effet. Ceux qui doivent travailler avec de tels objectifs sont dès le départ sur la voie de la défaite. Si, en revanche, la mission consiste à résoudre un problème spécifique, le projet se retrouve avec un vent arrière.

L'erreur numéro deux est la croyance erronée que l'on peut changer la réalité avec des processus modélisés. Ce n'est pas parce qu'un modèle de processus est publié que les gens ne s'y tiennent pas. Même si le chant d'éloge des instructions claires et des sanctions cohérentes est répété lors de la formation des dirigeants, on ne peut pas "prescrire" de nouveaux processus. Cette idée fausse est particulièrement insidieuse lorsque des modifications de processus sont intégrées dans un logiciel. Si le logiciel ne fournit que les "bons" champs et options de décision, les gens n'ont pas d'autre choix que d'utiliser le processus "correctement". Même le meilleur logiciel reste bloqué "dans le déploiement" si les utilisateurs n'en veulent pas.

Les gestionnaires de processus réduisent leur risque de frustration s'ils disent au revoir très tôt à quelques illusions qui se sont répandues dans la littérature sur la gestion des processus de production. Illusion numéro un : "Les processus peuvent être gérés - il suffit de bien les faire". En réalité, les processus sont des systèmes sociaux (comme toutes les organisations), et contrairement aux systèmes mécaniques, ils ne peuvent être contrôlés. Vous ne pouvez pas diagnostiquer la "panne" et la réparer par des instructions comme vous le feriez avec une machine. Ainsi, toute personne qui constate que les modèles de processus adoptés dégénèrent en déchets peut être rassurée par le fait qu'elle est en bonne compagnie (une faible consolation, il est vrai).

Deuxièmement, les actions étroitement couplées ne sont pas naturelles. Si une personne effectue deux fois le même flux de travail, il est peu probable qu'elle le fasse exactement de la même manière. Si deux personnes effectuent le même travail, la probabilité est encore plus faible. Il ne faut donc pas s'attendre à ce qu'un processus au sein d'une organisation suive le même schéma fixe encore et encore - le contraire serait normal. Et ce n'est pas parce qu'il existe un modèle de processus que cette tendance est simplement inversée.

Nécessité d'un moteur pour les processus de changement

Vous ne pouvez donc pas du tout déplacer les processus ? Oui, vous pouvez. Mais nous devons comprendre les règles qui rendent cela possible. Et cela concerne la capacité des organisations à apprendre. Les organisations apprennent lorsqu'elles remplacent par d'autres des structures et des processus de communication qui fonctionnaient (auparavant). Ils ne le font (tout comme les individus) que par nécessité. À savoir, lorsqu'ils n'obtiennent plus ce dont ils ont réellement besoin : par exemple, lorsque les clients ne sont plus disposés à payer le prix demandé, lorsque le public pose des exigences en matière d'émissions ou de normes sociales, lorsque les propriétaires formulent des attentes différentes en matière de rendement, lorsque le siège de l'entreprise prescrit l'utilisation de logiciels différents, etc. S'il n'y a pas besoin, rien ne se passe.

C'est le point essentiel de la gestion du changement : les responsables du processus doivent présenter le besoin d'adaptation sous une forme appropriée - de sorte que toutes les personnes concernées le comprennent et qu'il soit discuté dans les comités importants. De nombreuses directions d'entreprises ont fait un gâchis à ce sujet : De grandes réunions du personnel, des présentations PowerPoint avec beaucoup de graphiques et beaucoup de langage commercial que personne ne comprend.

Permettre des perceptions différentes des processus

Ainsi, les gestionnaires de processus peuvent aider à intégrer les questions importantes dans la communication : Ils rendent les processus et leur environnement visibles, c'est-à-dire les "clients" du processus et leurs attentes. Ils montrent à quel point un processus est différent ou uniforme dans l'organisation. Si les gens vivent le processus différemment, cela devient clair. L'objectif n'est pas de modéliser un processus "tel quel" syntaxiquement correct et uniforme le plus rapidement possible. L'objectif est plutôt de mettre la vie réelle sur la table sans censure. Et aussi improvisé et incohérent que cela puisse être. L'improvisation et les variations ne sont pas mauvaises en soi - de nombreux processus ne fonctionnent que grâce à ces structures subtiles. En revanche, lorsque les attentes et les exigences de l'environnement sont discutées, la nécessité d'une adaptation est mise sur la table. C'est maintenant - et seulement maintenant - que nous pouvons parler de changement. Mais comment modéliser un tel processus ? Partout, il y a des variantes, des "si" et des détails qui semblent importants pour les participants individuels, mais qui se déroulent à une "hauteur de vol" bien trop basse pour le responsable du processus. L'art consiste à percevoir cette information, à l'apprécier, à lui donner une place dans le modèle - sans le modeler ! Pour éviter tout malentendu, il ne s'agit pas de prendre des informations et de les écrire quelque part juste pour faire taire les gens. C'est une question de réflexion. Le modèle de processus actuel ne peut servir qu'à organiser grossièrement toutes ces informations. Il est utile d'enregistrer d'abord un "modèle de processus logique" qui ne répertorie que les étapes et les jalons théoriquement nécessaires du début à la fin. Ce modèle est un excellent "support" pour toutes sortes d'informations analogiques.

Modélisation des processus de communication sans interdiction de penser

Cette forme de modélisation du processus est un processus créatif et communicatif. Un programme de modélisation sur l'écran du projecteur étoufferait cette créativité. Mieux vaut une large table avec une glissière essuyable et des éléments BPMN à poser et à déplacer. Les lignes de séquence et de message peuvent être effacées et redessinées à tout moment, et toutes les informations analogiques sont simplement écrites sur la table. Il ne devrait y avoir aucune inhibition à la communication sur le processus ! Le facilitateur a également besoin d'un smartphone et d'un selfie maker. Il peut être utilisé dans l'intervalle pour geler l'état actuel de la discussion sur la table. Le selfie maker est nécessaire pour positionner l'appareil photo suffisamment haut au-dessus de la table. De cette façon, vous obtenez l'ensemble du processus sur la photo sans avoir à composer plusieurs photos.

Cadre formel pour la connaissance des processus analogiques

Malgré cette forme analogique de modération, il est logique d'utiliser le modèle et la notation des processus commerciaux (BPMN), qui sont des normes fixes, pour la modélisation. Le modèle BPMN structure les nombreuses informations analogiques supplémentaires. En outre, nous utilisons la force particulière de cette norme : Il est ici possible de modéliser la relation entre un processus et son environnement. Aucun autre langage de modélisation ne fait la distinction entre les événements "survenus" (nous attendons que quelque chose se passe "là-bas") et les événements "déclenchés" (nous donnons quelque chose au monde). Les pools du modèle montrent quels processus communiquent entre eux et comment - les lignes de message entre les pools indiquent les attentes mutuelles. Ceux qui connaissent bien la norme utilisent également le sous-processus d'événement pour saisir les éventualités et les cas spéciaux dans le modèle de processus, sans que le modèle n'éclate immédiatement toutes les limites.

Reconnaître l'appréciation permet le changement

Le résultat de cette modélisation est un modèle de processus approximatif avec beaucoup d'annotations et d'informations supplémentaires. La syntaxe correcte pour les puristes du BPMN est une question mineure. Il existe peut-être même plusieurs modèles différents, car les différentes parties prenantes voient le processus de manière très différente. Il ne s'agit pas du modèle, mais de la modélisation. Ce modèle reflète le processus réel "tel quel" : ses incohérences, ses fractures, ses attentes non satisfaites, ses inefficacités, mais aussi, malgré toute son improvisation, son incroyable fonctionnalité - et c'est ce qu'il faut apprécier : C'est l'énorme réussite du processus et de tous ceux qui y ont participé qui fait que malgré toute son incohérence, il fonctionne en quelque sorte. La modélisation classique du processus "tel quel" avec "analyse des points faibles" étouffe la volonté de changement des personnes concernées. La reconnaissance appréciative d'un processus est la clé pour amener les gens à s'occuper des chantiers et à rechercher ensemble de manière constructive un processus - un "processus cible". Le véritable défi de la gestion du changement n'est donc pas de trouver le meilleur processus. Il s'agit en fait de la volonté de toutes les parties concernées de se lancer ensemble dans la recherche de ce qui est nécessaire.