Accueil
 > Rapports de TEC > Blogue de TEC > Le « syndrome du cas par cas » : Comment vous assurer que...

Le « syndrome du cas par cas » : Comment vous assurer que vos processus d’affaires ne vous mèneront pas à un cas de gestion des exceptions

Écrit par : Jorge Garcia
Date de publication : juillet 24 2012

La personne sans éducation ne perçoit que le phénomène individuel,
la personne partiellement éduquée ne voit que la règle,
et la personne éduquée, l’exception.
—Franz Grillparzer

Pour réussir, de nos jours, les organisations modernes doivent chercher à être « axées sur les processus », c’est-à-dire, s’appuyer sur une architecture de processus d’affaires finement articulée. De plus, tous les échelons de l’organisation doivent reconnaître les processus d’affaires bien définis comme étant la clé d’une exploitation, d’une planification et d’une prise de décision réussie. Mais, parfois, les organisations peuvent se retrouver dans une situation où ils ne sont pas en mesure de développer un processus d’affaires efficace, et développent ainsi le « syndrome du cas par cas ».

Selon 6SixSigma , un processus d’affaires est :

Une collection d’activités qui permet de produire un ensemble défini de produits et de services. Tous les processus d’affaires dans une entreprise existent pour remplir la mission de l’entreprise; ils doivent être associés d’une façon ou d’une autre aux objectifs de la mission.Ainsi, pour fonctionner, le flux des activités doit être :

  • Consistant — Afin qu’il n’y ait pas de contradictions.
  • Cohérent — Afin qu’il soit valide, réel et complet pour les activités concernées.
  • Général — Afin de couvrir la grande majorité des cas et des exceptions.
  • Susceptible d’être répété — Afin qu’il puisse être répliqué chaque fois que le processus est nécessaire.

Aussi facile que cela puisse paraître, il arrive souvent que le cycle d’élaboration des processus soit bloqué, et les organisations sont confrontées à ce que j’appelle le « syndrome du cas par cas ». Le processus ne respecte pas les critères ci-dessus, et les éléments du processus sont donc gérés comme des exceptions ou des cas uniques. Bien que plusieurs facteurs mènent à ce syndrome, analysons quelques exemples qui apparaissent assez régulièrement.

Comment le syndrome du cas par cas se contracte-t-il?

Scénario 1 : Un échec avant même de commencer

  • Vous élaborez un processus.
  • Vous l’abandonnez avant même de le lancer. Ou, vous le lancez, mais vous n’obtenez pas le consensus des utilisateurs. Ils font tout en leur pouvoir pour abandonner le processus.

Vous élaborez un processus d’affaires, mais durant son développement, vous avez des difficultés à définir sa portée et son niveau de complexité. Vous rencontrez un niveau élevé de critique et une réticence quant à son adoption. Les parties prenantes ne le trouvent pas pertinent ou prédisent des problèmes majeurs qui entraveront l’exploitation efficace du processus.

Une fois le processus lancé, les personnes l’abandonnent ou l’utilisent de façon très limitée. La plupart des processus sont gérés à l’extérieur du système, un cas à la fois. Le système ne réussit finalement pas à automatiser le processus, et le processus n’est pas plus efficace ni facile à gérer.

Scénario 2 : À quoi bon?

  • Vous commencez à développer votre processus, en gardant en tête le secteur de l’entreprise qui l’utilisera.
  • Finalement, vous décidez que le processus est trop compliqué. Vous vous dites donc que ça ne vaut pas la peine de l’élaborer.

Vous avez commencé le travail d’élaboration, mais il semblerait que l’équipe ne se dirige nulle part, avec trop de restrictions et d’exceptions (sans compter les contraintes de temps). Après des séances intensives de discussion, de négociation et de frustration, il n’y a aucun consensus au sujet de la meilleure façon d’approcher le processus d’affaires. Les parties prenantes déterminent ultimement que les processus sont inadéquats pour l’automatisation et qu’il serait préférable d’effectuer les activités au cas par cas.

Avec toutes les compagnies de gestion des processus d’affaires à la disposition des organisations modernes, il serait logique de croire que ces situations ne se produisent plus, mais vous vous tromperiez. Elles existent, et elles sont plus fréquentes qu’elles ne devraient l’être. Étant donné que les processus d’affaires comprennent plus qu’une simple série d’étapes d’affaires, ils agissent en tant que système nerveux d’une compagnie. Un processus d’affaires demande une forte utilisation de données et une collaboration humaine sérieuse à plusieurs niveaux. Un processus est une ligne de commande verticale qui interagit considérablement avec les ressources externes.

En plus du degré d’interaction requis, la complexité des arbres de décision et les exceptions peuvent faire traîner un processus jusqu’à la « paralysie d’analyse »; un point d’inaction où il semble préférable d’éviter de s’engager à la création d’un processus qui pourrait être trop difficile à gérer.

Pourquoi contracte-t-on le syndrome du cas par cas?

Ronald G. Ross, dans son excellent article intitulé How Business Processes, Strategy, and Business Policies Relate , observe que :

Les modèles de processus d’affaires sont intuitifs. C’est pour cette raison que les gens les apprécient. Ils offrent des plans de gestion pour la coordination des tâches répétitives. Mais sont-ils suffisants pour créer une solution d’affaires optimale pour relever un défi d’entreprise? Non.

Donc, le problème n’est pas uniquement de créer et de déployer le modèle des processus, c’est également de permettre à tous les éléments de bien fonctionner ensemble. Par conséquent, cela concerne l’établissement de la bonne portée, la participation des bonnes personnes (parties prenantes) et la définition des bonnes règles d’affaires qui, comme le mentionne M. Ross, ne sont pas nécessairement intégrées dans le flux des processus.

Déployer un processus d’affaires peut être un échec en raison des causes suivantes :

  • Manque de consensus : vos parties prenantes peuvent ne pas voir la valeur des processus automatisés, car
    • L’équipe de gestion n’a pas communiqué les avantages correctement;
    • La communication entre les développeurs de processus et les utilisateurs du secteur d’activité est mauvaise;
    • L’équipe de développement n’a pas approché la complexité du processus avec la perspective appropriée.
  • Manque d’engagement : Les employés peuvent tout simplement ne pas vouloir s’engager à faire le travail nécessaire pour automatiser vos processus, car
    • Ils ne s’entendent pas sur l’approche à prendre pour l’élaboration du processus;
    • Ils ne participent pas à tous les aspects du projet, et pour cette raison, ne sont pas à l’aise avec la solution.
  • Analyse insuffisante : Vous n’avez pas regardé votre entreprise suffisamment en profondeur pour comprendre le réel problème.
    • Il est tentant de ne pas se salir les mains, et vous pouvez ne pas vous attribuer suffisamment de temps pour effectuer une analyse complète du processus;
    • Le travail de développement est toujours limité par des contraintes de budget et de temps, ce qui signifie que vous fournissez parfois une analyse qui n’est pas assez mûre;
    • On ne met pas assez d’effort dans l’établissement de l’ensemble des règles d’affaires.
  • Essayer de bâtir la mère de tous les processus : Plus vous manipulez un seul processus (le modeler pour qu’il prenne la bonne forme), plus vous aurez de risques qu’il échoue.
    • Le processus que vous tentez de développer est très complet ou compliqué : il implique plusieurs parties prenantes et nécessite la collaboration avec différents secteurs et différentes ressources;
    • Le processus doit remplir plusieurs objectifs au sein de l’organisation.

Peu importe la raison, les processus d’affaires finissent souvent totalement ou partiellement abandonnés et sont remplacés par une approche au cas par cas, car on croit qu’il y a trop d’éléments hors de notre contrôle et que l’effort pour créer un processus d’affaires nouveau et amélioré n’en vaut pas la peine.

Pourquoi devez-vous automatiser les processus de toute manière?

Malgré le fait que certains processus soient difficiles à développer et à déployer, il y a plusieurs avantages à mettre en place un processus d’affaires réussi. Par exemple :

  • L’exploitation de votre entreprise peut s’effectuer avec plus d’efficacité et de maîtrise, vous faisant économiser du temps et permettant à vous et à votre organisation de ne pas perdre la tête.
  • En définissant le processus, vous pouvez également démasquer les règles d’affaires qui gouvernent votre organisation et apprendre que votre entreprise n’est pas aussi unique ou compliquée que vous le pensiez.
  • L’exercice peut vous aider à définir ou redéfinir les tâches qui doivent être modifiées, créées ou qui doivent changer de propriétaire.
  • Le simple fait de savoir à quoi s’attendre d’un processus, lorsque vous aurez clairement mesuré les résultats que produit votre organisation, a le potentiel d’inciter l’amélioration au sein de l’organisation.

Plusieurs avantages directs et indirects peuvent provenir de l’établissement d’un ensemble approprié de processus d’affaires. En augmentant la maniabilité et la visibilité de l’information, ainsi qu’en soulignant la responsabilité des participants, vous pouvez créer la base d’une formule d’amélioration continue.

Comment arrêter de faire les choses au cas par cas et commencer à développer des processus qui fonctionnent.

Pour augmenter vos chances de succès, considérez les recommandations suivantes :

  • Commencez par trouver un consensus quant au problème d’affaires principal : qu’est-ce qui est la motivation première de l’automatisation d’un processus et, plus important encore, qu’elle est la portée initiale?
  • Faites participer toutes les personnes nécessaires afin qu’elles puissent faire partie de la solution. En même temps, vous obtiendrez leur engagement.
  • Définissez les règles d’affaires à l’avance. Ne présumez pas qu’elles apparaîtront durant le développement du processus d’affaires.
  • Divisez le problème en plus de pièces possible. Une organisation axée sur les processus est normalement capable de séparer les processus en leur forme de base, une idée principale des architectures orientées services (SOA).
  • Commencez par un petit processus principal afin de traiter le problème le plus pertinent. Cela permettra à votre équipe de s’entendre sur des problèmes spécifiques, d’accélérer le développement du processus et de réduire la frustration.
  • Faites évoluer le processus rapidement (cycle de développement flexible, etc.).
  • Échouez rapidement : si quelque chose ne fonctionne pas, vous voudrez le savoir le plus rapidement possible pour résoudre le problème ou essayer autre chose.
  • Arrêtez de vous plaindre. Une mauvaise attitude ne réglera pas vos problèmes de processus. Commencez par proposer des solutions et continuez à les essayer jusqu’à ce que vous trouviez la bonne.

En conclusion, j’abonde dans le même sens que plusieurs experts qui disent qu’un processus d’affaires n’est jamais terminé. Les processus doivent évoluer pour refléter une abstraction améliorée de l’entreprise. Je crois également que les exceptions existeront toujours et devront être gérées au cas par cas. Toutefois, il y a toujours des façons de réduire leur apparition en améliorant les processus et en bâtissant des scénarios solides de gestion des exceptions.

 
comments powered by Disqus

Recherches récentes :
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Others

©2014 Technology Evaluation Centers Inc. All rights reserved.