• Aucun résultat trouvé

BPM Lifecycle

Dans le document GESTION DE PROCESSUS AVEC SOA ET BPM (Page 34-38)

2 L’entreprise et le SI

4.2 BPM Lifecycle

Le point 4.2 répondra à la question de recherche se demandant « En quoi le BPM Lifecycle est-il un concept qui permet à l’entreprise de gérer ses processus et de les améliorer ? ».

4.2.1 CONCEPT GÉNÉRAL

Le BPM Lifecycle est une méthodologie dérivée de l’approche PDCA (Plan-Do-Check-Adjust). Elle recourt au concept d’itération qui implique que l’exécution de la dernière phase donne lieu au retour à la première phase du cycle. Les auteurs qui écrivent sur le BPM ont plusieurs interprétations du BPM Lifecycle. Celle qui sera utilisée dans ce travail est celle exposée par Michael Hammer dans l’ouvrage Handbook on Business Process Management I (Brocke & Rosenmann, 2009). Elle est constituée de 5 phases distinctes dont la Figure 14 décrit le séquencement. Chaque phase va faire interagir des acteurs différents et va amener au traitement de tâches spécifiques. L’étude distincte de chaque phase sera l’objet des points 4.2.2 et suivants.

Sa qualité de standard est perceptible au fait qu’il est devenu un outil commun pour les personnes en charge de la gestion des processus. Le recours au BPM Lifecycle est donc garant d’une gestion des processus qui soit à la fois intelligible pour tous les acteurs et standardisée au niveau de la méthode de projet.

FIGURE 14: BPM LIFECYCLE

BPM : gérer l’organisation par les processus 34 4.2.2 LA PHASE GOAL SPECIFICATION /STRATEGY DEFINITION

La phase Goal Specification / Strategy Definition est la première phase du BPM Lifecycle.

Elle implique deux impératifs pour le management. En premier lieu, l’instance dirigeante doit être capable de définir un but que l’organisation entend atteindre. Pour cela, elle se doit de procéder à une réflexion sur la valeur attendue par le client quant aux prestations ou produits qu’elle est à même de lui livrer. En parallèle, elle devra définir comment atteindre ce but : c’est l’objet du Strategy Definition. Ces deux inputs devront ensuite être mis en forme pour être transformés en réalité. Il faudra donc penser aux moyens à allouer au projet, à la planification aux rôles à donner aux différents acteurs et définir en termes très clair le but poursuivi par le projet et la forme qu’il doit prendre. La bonne exécution de cette phase est capitale pour que la suite de projet puisse se dérouler dans les meilleures conditions. En vertu du concept d’agilité défini au point 4.1.3, c’est en impliquant le plus tôt possible le top management dans des décisions qu’il sera possible d’atteindre les meilleurs résultats.

Il est à noter que la première phase du BPM Lifecycle est dans les faits rarement la première à être utilisée dans un projet concernant un processus. Elle ne l’est que lors de la première itération sur un projet de processus. Elle sera, dans les itérations suivantes, consécutive à la phase de Process Improvement.

4.2.3 LA PHASE DESIGN

La phase de design peut être considérée comme une phase intermédiaire entre le Plan-Do du modèle PDCA. Elle va transformer les besoins du management en une représentation abstraite des tâches et des séquencements nécessaires à l’exécution du processus. Cette phase, mise sous la responsabilité de spécialistes appelés business process analysts est absolument nécessaire pour définir un modèle qui soit à la fois compréhensible de la part du management, des acteurs et des utilisateurs du processus ainsi que des informaticiens et spécialistes métiers.

Le but de la phase design est donc de proposer une modélisation du processus qui soit « un même langage » pour tous les acteurs du projet et qui garantisse à chacun d’entre eux que les aspects importants relatifs à leurs fonctions y soient mentionnés. Pour parvenir à ces fins, le recours à un langage de modélisation est une nécessité. Le langage BPMN 2.0 (voir 4.4) est un standard reconnu et partagé et sera utilisé dans ce travail. Il permet de définir et de représenter :

 Les acteurs du processus ;

 Les opérations selon leur type ;

 Les types d’interactions entre les acteurs ;

BPM : gérer l’organisation par les processus 35

 Les séquences et les éventuelles conditions.

Par ce biais, il sera question de déterminer un processus qui soit optimal, tenant compte des limitations en termes de ressources et des conditions d’optimalité exprimées dans la phase 1 du BPM Lifecycle.

4.2.4 LA PHASE IMPLEMENTATION

La phase d’implémentation est consécutive à celle de design. Elle a pour objectif de faire des spécifications et du concept de processus développé lors du design une réalité qui met en œuvre les ressources de l’organisation délivrant de la valeur. Ces ressources peuvent être de différentes natures. On notera deux grands types : les ressources humaines et celles qui sont intégrées dans le SI de l’entreprise. L’implémentation d’un processus consiste à la fois en l’exécution de tâches selon la séquence donnée du processus, mais aussi en la mise sur pied des interfaces qui vont permettre aux utilisateurs de lancer le processus et d’interagir avec le SI.

Une implémentation de processus va se faire par le biais d’un logiciel spécialisé dans la gestion de processus qui soit à même d’appeler des tâches et les exécuter selon la description donnée par la modélisation. Afin de rendre possible l’exécution successive des tâches, le paradigme de l’orientation service sera alors requis. Chaque tâche devenant un service qu’il est possible d’appeler par son interface. Ainsi, les fonctions informatiques et les acteurs du processus seront appelés à agir selon les principes de SOA. La propriété d’orientation service des services utilisés sera promue par le Service Layer (voir 3.3.1) et si cela est nécessaire techniquement par la présence d’un ESB. Il existe plusieurs bases technologiques pour l’exécution de processus. Comme cela a été vu au point 3.3.7, BPMN 2.0 sera la norme utilisée pour ce travail.

4.2.5 LA PHASE DE PROCESS RUNTIME

Une fois le processus implémenté et rendu exécutable, vient le temps pour le processus de devenir une réalité dans l’organisation dans laquelle il existe. Cette réalité prend forme avec des ressources informatiques mobilisées sous la forme d’interfaces visuelles qui permettent l’interaction avec le processus, la formation d’utilisateurs et le monitoring du processus pour s’assurer de son bon fonctionnement. Ce monitoring est aussi réalisé dans le BPM. En plus du monitoring des ressources, il est nécessaire d’appliquer une métrique de performance au processus pour s’assurer qu’il est optimal et qu’il corresponde aux attentes formulées dans la première phase du BPM Lifecycle. Pour se faire, le recours à des KPI (Key Performance

BPM : gérer l’organisation par les processus 36 Indicators) est nécessaire. Ces KPI sont à mettre en lien avec le BPMM et particulièrement le niveau 4 de BPMM qui est défini au point 4.3.6.

Il est aussi à noter que si l’entreprise veut s’inscrire dans une démarche processus de long terme, il sera extrêmement important durant cette phase de s’assurer que les utilisateurs font une expérience optimale du processus tel qu’il est développé et que leurs remarques puissent-être saisies et intégrées par le biais de la dernière phase du BPM Lifecycle qui sera le sujet du point suivant.

4.2.6 LA PHASE DE PROCESS IMPROVEMENT

Une fois le processus exécuté au sein de l’entreprise, il faut encore s’assurer de son suivi, et notamment de s’assurer qu’il desserve toujours le modèle d’affaire. Si le processus devait devenir désuet et ne plus correspondre aux besoins et s’il devait s’avérer ne plus être optimal d’un point de vue économique, ce serait alors à la phase du process improvement de gérer les améliorations possibles.

Si l’exécution des 4 phases précédentes est à même de garantir que le projet se déroule le mieux possible et selon des responsabilités et des rôles établis, elle ne peut en aucun cas garantir que le résultat soit parfait, ni même suffisant par rapport à ce qui a été défini par l’organisation. La dernière phase est garante qu’il soit possible de reprendre un projet peut-être imparfait, mais elle permet aussi de réaliser des itérations plus courtes qui peuvent permettre de montrer plus rapidement des résultats sur lesquels un retour de la part du maître d’ouvrage – soit celui qui est à l’origine du projet et des besoins – est possible.

BPM : gérer l’organisation par les processus 37

Dans le document GESTION DE PROCESSUS AVEC SOA ET BPM (Page 34-38)

Documents relatifs