UDDI

SOA promeut la découverte des services de son architecture. UDDI (Universal Description, Discovery and Integration) est une norme qui permet la mise sur pied d’un annuaire de services. Son implémentation, décrite à la Figure 13 est basée sur l’utilisation de SOAP et de WSDL. Le premier va permettre la communication avec l’annuaire et le second servira à la description des services disponibles.

FIGURE 13: IMPLÉMENTATION DE UDDI (KRAWLER, 2009)

SOA : Emergence d’un modèle d’architecture SI 30 3.3.7 BPEL

Si SOAP, WSDL et UDDI sont des normes fondamentales qui offrent des standards de communication fondamentaux à SOA, il reste un service de la norme WS-* qui doit être mentionné ici car il est spécialisé dans ce qui est l’objet d’implémentation de ce travail. Il s’agit de BPEL (Business Process Execution Langage). BPEL est un service spécialisé dans l’exécution des business process. Basé sur la norme XML, il permet d’exécuter des fonctions successives en régissant leur appel, les éventuelles conditions et les séquencements. Il ne sera néanmoins pas utilisé dans ce travail car l’avènement d’une norme telle que BPMN 2.0 qui sera décrite au point 4.4 et qui permet à la fois la modélisation et l’exécution n’a pas rendu son recours pertinent. Toutefois, de nombreuses solutions SOA et BPM l’utilisent encore pour instancier des processus. Les solutions se chargeant de transformer par un fonctionnement complexe des graphiques de modélisation en fichiers BPEL exécutables.

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

4 BPM : GÉRER L ’ ORGANISATION PAR LES PROCESSUS 4.1 Bases conceptuelles

Au point 4.1, la question de recherche se demandant « Qu’est-ce que BPM, pourquoi l’utiliser ? » sera traitée.

4.1.1 D^ÉFINITION

Pour Gartner, le Business Process Management (BPM) est « une discipline du management qui traite des business process à titre d’actifs qui contribuent directement à la performance de l’entreprise par le biais d’excellence opérationnelle et d’agilité » (Gartner, 2013).

En prêtant attention à cette définition, on constate qu’il s’agit donc d’une approche qui considère l’entreprise dans son entier sous le prisme des processus. Qu’ils soient définis comme des actifs leur donne la qualité d’être les moyens mis à disposition du management pour réaliser une performance économique. En devenant ces moyens, ils deviennent donc aussi les variables de décision par lesquelles une entreprise va être capable de maximiser la valeur qu’elle pourra générer. En parlant d’excellence opérationnelle et d’agilité, cette définition donne aussi une direction aux objectifs managériaux pour faire du BPM une approche à même de faire performer l’entreprise d’un point de vue économique.

On notera que le concept de BPM a une qualité holistique : en effet, c’est l’organisation dans son entier qui est vue par le biais des processus et non pas une partie de cette dernière. En considérant les processus, le management considère toute sa structure et peut réfléchir à l’organisation de celle-ci en termes de totalité, même si son action pourra par la suite ne concerner qu’une sous-partie de l’organisation.

4.1.2 HISTORIQUE

Pour expliquer dans quel contexte l’approche BPM a éclos, il est nécessaire de faire un détour par l’histoire de la théorie des organisations. Susan Morley considère que l’approche BPM doit son existence à 4 sources principales (Morley, 2011) qui sont reprises et dont elle a de chacun hérité d’un concept. La première de ces sources est le Just in Time (JIT) développé dans l’industrie japonaise dans la première moitié du XXème siècle. Cette théorie qui veut que la production d’un produit succède à la commande et ne génère pas de stock a été la première à considérer le liage des besoins entre consommateurs et producteurs. Un élément essentiel de BPM, puisque dans cette théorie, c’est la satisfaction finale du client qui influence l’exécution de la totalité du processus.

BPM : gérer l’organisation par les processus 32 On doit la seconde influence conceptuelle au Total Quality Management (TQM). Celui-ci va généraliser le concept du next step is a customer qui signifie que chaque tâche est cliente de la précédente. De la sorte, il va permettre un liage entre les tâches avec un mécanisme rétroactif en cas de plainte de la part du client sur un défaut et un concept qui va permettre au processus d’être trans-organisationnel. Etant donné que le lien de clientèle est entre chaque tâche, le passage d’une organisation à l’autre pour un processus n’est pas de nature différente.

La troisième influence est celle de la comptabilité analytique qui, dans les années 60, a mis en exergue la limite d’une vision hiérarchique de l’organisation découpée en sous unités ou en métiers (voir Figure 5) dans leur contribution à créer de la valeur et qui, elle aussi fera naître le concept de chaîne de valeur, soit un ordonnancement de processus créant un produit qui parcoure l’organisation de manière transversale.

Enfin, le process re-engineering proposé par Hammer et Champy, notamment au travers de leur ouvrage Reengineering the Corporation: Manifesto for Business Revolution (Hammer&Champy, 2003) va faire de la notion de processus l’élément clé pour repenser une organisation. C’est de cette dernière démarche que naîtra ensuite un certain nombre d’outils et de méthodes que l’on identifie désormais comme faisant partie du BPM.

4.1.3 LE BUT DU BPM : L’AGILITÉ

La pratique du BPM n’est en soi pas une finalité. Il s’agit d’un ensemble de moyens mis en place pour permettre à une entreprise de devenir agile. Par agilité, on entend « une qualité qu’une entreprise possède lorsqu’elle est capable de s’adapter rapidement à un environnement d’affaires changeant tant au niveau des défis que des opportunités. Il s’agit d’une démarche d’amélioration continue qui optimise les coûts, la qualité et les délais de livraison. Elle implique le top management de l’entreprise afin d’implémenter très rapidement les nouvelles stratégies et de contrôler les variables clés du modèle d’affaire, ceci dans le but d’obtenir un avantage concurrentiel » (Cummins, 2009).

Cette définition permet de comprendre que l’agilité est un défi. Un défi qui demande à la fois une compréhension de la part du management et son implication jusque dans les plus hautes sphères de la direction. Mais pour pouvoir modifier les processus au besoin, il faut aussi compter sur des outils qui permettent le changement et le déploiement de l’agilité, ainsi que sur une infrastructure du SI qui rende possible ces changements organisationnels.

Comme cela été vu dans le point 3, SOA possède les caractéristiques pour supporter un changement grâce à ses propriétés fondamentales. Quant à l’intégration de l’agilité dans l’organisation, celle-ci se fera grâce aux outils BPM présentés à la suite de ce travail.

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

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

4.3 BPMM

Le point 4.3 répondra à la question de recherche suivante : « Comment le niveau de sensibilité d’une organisation aux processus peut-il être évalué et amélioré ? »

4.3.1 CONCEPT

Le BPMM (Business Process Maturity Model) «est une norme définie par l'Object Management Group (OMG) qui propose de fournir une grille d'analyse de la maturité des processus métier d'une entreprise. » (BPMS Maîtriser la complexité, 2012). Cette norme est définie par l’OMG, soit la même organisation qui définit BPMN 2.0. Les deux concepts sont ainsi compatibles et complémentaires.

Le recours à cette norme permet de disposer d’un standard pour juger du niveau de conscience et d’importance donnée aux processus dans une organisation. Les différents niveaux de la norme seront exposés ci-dessous. Sa spécification utilisée ici pour décrire les 5 phases constitue le document BPMM Specification disponible sur la page du site OMG (OMG, 2013). Il existe des Maturity Models dans de nombreux domaines de la gestion d’entreprise et le point 3.1.1 a été l’occasion de mentionner celui dévolu à SOA. Dans ce travail, la présentation d’un tel modèle pour les processus a été retenue car les processus et leur gestion représentent la cible de ce travail, contrairement à SOA qui a un rôle de participant.

4.3.2 REPRÉSENTATION DES NIVEAUX

Le BPMM est un modèle à 5 niveaux que la Figure 15 présente. Le premier niveau représente le plus faible niveau de prise en compte des processus dans l’organisation alors que le niveau 5 représente quant à lui la situation optimale. Chaque niveau porte un nom qui décrit la situation générale des processus. Le passage d’un niveau à un autre est possible par le recours à une itération du BPM Lifecycle.

BPM : gérer l’organisation par les processus 38 mais à l’impératif d’exécuter les tâches pour obtenir un résultat qui ne fait pas l’objet d’une définition préalable. D’une manière générale, « la capacité d’exécuter un processus est celle des individus et pas de l’organisation » (OMG, 2013). Cela implique que si une personne avec une compétence donnée devait quitter l’organisation, la compétence au sein même de celle-ci serait perdue et nécessiterait d’être à nouveau développée.

Comme l’exécution du processus est directement liée aux personnes, c’est aux qualités intrinsèques de celles-ci que l’organisation reconnaît son fonctionnement. On verra alors souvent des situations de crise devoir être gérées par le biais d’actions « exercice pompier ».

A ce niveau, les processus ne sont rarement documentés puisqu’un processus repose la plupart du temps sur une seule personne. Et s’ils sont documentés, leur exécution ne suit pas ou rarement la description formelle qui en est faite.

4.3.4 NIVEAU 2:MANAGED

Au niveau 2, il y a une prise en charge des processus, mais celle-ci est locale. Cela signifie que ce sont des cadres intermédiaires, situés entre le top management et le déroulement des opérations qui permettent à leurs subalternes de s’organiser et de faire en sorte que les processus suivent une certaine logique.

BPM : gérer l’organisation par les processus 39 Comme la gestion des processus est locale, il n’y a pas de guidelines pour toute l’organisation. Dans ces circonstances, une prise en charge d’une problématique de processus dans un département et une prise en charge dans un autre département de la même problématique pourra donner lieu à deux processus différents pour traiter le même cas.

Les considérations pour optimiser les processus portent sur ce qui importe directement au département : des délais, des coûts et des aspects de performance qui sont reliés à l’unité organisationnelle qui gère les processus, mais pas pour la totalité de l’organisation. Le client final n’est pas pris en considération dans l’amélioration des processus, en ce sens que les processus choisis ne sont pas end-to-end.

4.3.5 N^IVEAU 3:STANDARDIZED

Il s’agit du premier niveau du modèle BPMM où la gestion des processus est pensée pour l’organisation en entier. La documentation des processus est réalisée de manière générique afin qu’elle puisse-t-être utilisée dans tous les départements de l’organisation pour des problèmes donnés et que la solution proposée soit partout de la même forme. A ce niveau, il existe une responsabilité définie dans l’organisation qui se charge des processus, de leur application et de leur gestion.

Les processus sont organisés selon une typologie qui distingue les processus opérationnels, les processus de soutien et les processus décisionnels. Elle tente de standardiser ceux-ci et de généraliser les processus qu’elle identifie comme étant les meilleures pratiques. La performance donné d’un processus en relation avec un besoin. L’existence d’une valeur qui soit quantifiable permet d’effectuer un controlling des processus et de déterminer les actions correctives qui seront à même d’améliorer le processus. (NB : on comprend ici le lien entre la

Les processus sont organisés selon une typologie qui distingue les processus opérationnels, les processus de soutien et les processus décisionnels. Elle tente de standardiser ceux-ci et de généraliser les processus qu’elle identifie comme étant les meilleures pratiques. La performance donné d’un processus en relation avec un besoin. L’existence d’une valeur qui soit quantifiable permet d’effectuer un controlling des processus et de déterminer les actions correctives qui seront à même d’améliorer le processus. (NB : on comprend ici le lien entre la