Joomla-Visites | Statistiques de fréquentation pour Joomla! Statistics

Skip to content

Vous naviguez ici :Accueil arrow Concepts arrow Articles « Métier » arrow IBM s’engage dans la voie de l’analyse de processus
IBM s’engage dans la voie de l’analyse de processus Version imprimable


Depuis de nombreuses années, IBM s’est intéressé aux produits d’analyse de Processus. Dans une première étape, la société a particulièrement soigné les interfaces avec le produit BPM de la société Holosofx. IBM s’est ensuite engagé plus avant en prenant en charge directement la commercialisation du produit, pour finalement racheter la société Holosofx en 2002.

En 2003 IBM, après avoir poursuivi et accentué son effort d’intégration de Holosofx avec MQSerie Workflow, repositionne l’offre Holosofx comme un composant de WebSphere sous le nom de WebSphere Business Integration Modeller and Monitor tandis que MQSeries workflow devient WebSphere MQ Workflow. L’intégration des deux composants entre eux sous l’ombrelle WebSphere devient totale, au point que WebSphere Business Integration Modeller and Monitor (WebSphere BIM) permet à lui seul d’analyser, définir et développer les processus WebSphere MQ Workflow. Il s’agit la d’une position sans ambiguïté d’IBM en faveur des méthodes et outils d’analyse de processus, au point de leur donner une place en vue dans leur offre produit phare : WebSphere.

Une analyse des fonctionnalités de WebSphere BIM pour en évaluer la place en tant qu’outil d’analyse de processus nous a permis de conclure très positivement sur cette approche : WebSphere BIM a toutes les caractéristiques qui permettent de l’utiliser en support d’une phase d’analyse et de re-conception de processus. Sans vouloir rentrer dans les détails, il nous à semblé intéressant de présenter ici ces fonctionnalités qui pourraient paraître accessoires et qui pourtant peuvent être précieuses (voire indispensables) sur le terrain. L’utilité de ces caractéristiques a priori marginales ne se conçoit que dans le cadre d’une pratique réelle de l’analyse de processus en entreprise, les décrire et en montrer l’usage c’est aussi parler de cette pratique et de ses exigences.

   Les éléments d'une d'analyse de processus

Pour nous, l’analyse de processus est un travail d’équipe. Avec des membres en provenance d’unités différentes et qui exercent des métiers différents. L’objectif commun est de décrire, analyser et transformer un processus auquel chacun participe régulièrement. C’est un travail exigeant par le niveau de détails et la précision qu’il requiert. C’est surtout un travail qui ne peut se faire sans que le groupe acquière une compréhension commune, poursuive les mêmes objectifs, et accepte un centrage collectif de son propre travail d’analyse. Le plus grand risque est donc celui d’une dérive gigantesque dans des détails inutiles et spécifiques sans relation avec les buts poursuivis.
WebSphere BIM dispose des objets objectif, directive, règle, problème et classification qui contribuent tous a faciliter la construction de cet accord collectif. Pour chaque objet nous en donnons une description succincte tel qu’il est spécifié dans WebSphere BIM, suivie d’un mode d’emploi.

Un objectif a été défini pour régler un problème identifié, ou pour répondre à un besoin de l’organisation. Le problème identifié dans un processus pourrait être un trop grand nombre de plaintes des clients. L’objectif serait alors de réduire le nombre d’erreurs. Le besoin de l’organisation pourrait être d’augmenter la part de marché, l’objectif du processus serait alors de réduire le temps de cycle du processus. Chaque objectif est associé aux processus et aux unités concernées. Une mesure de performance peut être associée à chaque objectif. Elle constituera le moyen de mesure qui sera utilisé pour déterminer si l’objectif a été satisfait ou non. Un exemple de mesure d’objectif associé à un département pourrait être : pourcentage de refaits inférieurs à 2%. Un exemple de mesure d’objectif associé à un processus pourrait être : diviser par trois le temps de cycle. L’arbre des objectifs permet de les organiser selon une structure hiérarchique. Un objectif de haut niveau peut alors se décomposer en de nombreux objectifs concernant des unités et des processus différents.
Le retour permanent aux objectifs est le seul moyen rationnel d’orienter les débats et de couper court aux discussions en les ramenant aux objectifs. Il est donc essentiel de les avoir identifiés pour le processus en cours, d’avoir identifié les unités impliquées dans ces objectifs, et de les avoir situés dans l’arbre des objectifs de l’organisation. Les objectifs doivent aussi aider à mesurer l’importance des enjeux, et par la même permettre d’ajuster les efforts d’analyse en rapport avec cette importance. Leur quantification est une étape importante dans cette voie. La place qui leur est donnée dans le Modèle oblige à les définir, et permet d’y accéder aussi souvent que nécessaire.

Les Directives sont des principes organisationnels et opérationnels qui peuvent affecter les processus. Elles sont édictées pour des raisons variées : Qualité, sécurité, santé des employés ou des consommateurs, éthiques, légales, citoyennes, image, ou encore parce que « c’est ainsi que cela c’est toujours fait dans la maison ». Un processus est donc associé aux directives qui le concerne. Une directive peut être aussi associée à une ou plusieurs règles. Soit parce que ces règles sont des expressions plus détaillées de la directive, soit encore qu’elles expriment la manière dont l’organisation contrôle son application.
Les directives vont s’inscrire comme des contraintes à respecter. Et comme des contraintes qui ne se discutent pas, et qui devraient êtres (relativement) stables dans le temps et les organisations. Elles servent au groupe à s’orienter dans la conception du processus et à détecter ce qui devrait être invariant dans l’effort de réorganisation. Les directives constituent des points stables de référence qui permettent souvent de trancher entre plusieurs alternatives également possibles. Le travail qui consiste à énumérer ces directives est souvent révélateur de l’absence d’une vision commune de ce qui devrait gouverner un processus. Il est alors urgent d’y remédier pour constituer une base commune indispensable à la progression du groupe.

Les règles sont des détails précis des directives qui concernent l’exécution d’une tâche, ou la conception d’une application. Par exemple « toutes les demandes de prêt de plus de 50 000 Euros doivent être approuvées par un comité ».
La règle est rattachée à un principe en cela qu’elle traduit l’application à un cas particulier d’un principe plus général de partage des responsabilités. Rattacher des règles au principe qui leur à donné naissance permet de leur donner la même valeur de force que le principe. Par ailleurs du principe il devient possible d’accéder à l’ensemble de règles qui en découlent, et des processus impactés par chaque règle. Il est important de séparer les règles (découlant d’un principe) des simples conditions décrivant une manière de réaliser un processus dans une organisation particulière. Le groupe est (plus ou moins) libre de changer le processus et les conditions, alors qu’il ne peut que suggérer le changement des règles.

Les problèmes (issues) sont des difficultés identifiées dans la réalisation des tâches quotidiennes d’une organisation. Ils sont associés à un ou plusieurs processus.
L’utilisation des problèmes dans une phase d’analyse permet de laisser ouverts les points non résolus et de poursuivre le travail d’analyse sans risquer d’oublier les points à résoudre. Ceci est important dans la vitesse d’avancement d’un groupe en permettant de mémoriser des points importants mais dont la discussion bloquerait la dynamique du groupe, tout en garantissant à celui qui à levé le problème qu’il ne sera pas pour autant mis de côté.

La classification des tâches est une classification dans quatre catégories correspondant chacune à un point de vue différent :
- Valeur ajoutée : Forte, Oui, Nulle
- Contrôle qualité : Oui, Non
- Automatisable : Oui, Non
Dans toute discussion sur un processus qui comporte souvent plus d’une centaine de tâches, il est essentiel de savoir évaluer l’importance relative des tâches selon les différents points de vue possibles. Un accord du groupe sur la classification de chaque tâche selon les critères de valeur ajoutée, automatisation, et contrôle qualité fera gagner ultérieurement un temps précieux.



Aucun de ces objets et de leurs relations avec l’organisation et les processus ne jouent un rôle dans la description finale de ce que sera le processus informatisé. Aussi bien ces objets sont absent de outils de définition de processus des moteurs de workflow. Pourtant ces objets jouent en rôle a notre avis essentiel dans le travail de maturation d’un processus par un groupe d’analyse. Objectifs, directives et règles identifient les invariants du processus et les impératifs qui s’imposent à lui. Identifiés et acceptés il serviront de garde fous aux dérives fantasmatiques de chacun. Problèmes dés lors qu’ils sont identifiés, permettront de travailler et de progresser dans une représentation parcellaire et incertaine jusqu’à l’identification complète de ce qui est connu, probable et problématique. C’est alors avec bien plus d’efficacité qu’il deviendra possible de relativiser les problèmes (ce qu’il en reste) et de traiter ceux qui le méritent vraiment. Enfin la classification des tâches selon leur valeur ajoutée permettra d’aborder l’intérêt de leur automatisation plus ou moins poussée a bon escient. Un modèle d’analyse on le voit ne doit pas comporter que des objets du système objet de l’analyse (processus, organisation, tâche …) mais il doit aussi représenter les objets qui relient ce système cible à ses intentions (objectifs) à ses contraintes (directives, et règles), et à ses valeurs (valeur ajoutée). En cela il assistera pas seulement le groupe qui s’en équipe dans la représentation et la description des processus, mais aussi dans la relation du groupe avec le processus par rapport à la transformation qu’il opère sur lui.












Vous souhaitez partager cet article :

FacebookLinkedinViadeoTwitter
 
< Précédent   Suivant >
[ Retour ]

Les choix de BPMS

Recevez notre newsletter