Processus métiers en entreprise : pourquoi, comment (première partie)

Petite mise au point

Le précédent article nous a permis d’avoir une image plus claire du processus métier par rapport à la nébuleuse de définitions que l’on peut rencontrer sur les différents types de supports  à disposition (livres, web, cours, …).

Dans cet article, nous allons tenter d’éclaircir un peu plus l’aspect ‘pourquoi’ (utilité, utilisation) du processus métier, sachant que nous resterons concentrés sur les processus métier eux-mêmes, et non leur modélisation (outil de représentation), pour le moment, en nous limitant aux métiers de l’IT.

 Quelques questions intéressantes

Voici des questions qui reviennent dès que le thème des processus métier est abordé :

  • Pourquoi étudier ou modéliser un processus métier (ou à quels processus faut-il s’intéresser) ?
  • Quels processus modéliser en priorité ?
  • Selon quel niveau de détail (profondeur et transversalité) ?
  • Modéliser l’existant ou la cible ?

Les réponses à ces questions nécessiteraient des volumes entiers, et encore, uniquement pour défendre différentes visions inspirées par des contextes particuliers. Nous allons juste apporter, ci-dessous, quelques éléments de réponse.

Lire la suite

Processus métiers en entreprise : introduction et notions

Cet article est le premier d’une série destinée à vous familiariser avec les processus métiers et leur rôle fondamental dans la réalisation de systèmes informatiques répondant aux objectifs du métier.

Dans cette série d’articles, nous utiliserons et comparerons deux notations standards (UML et BPMN) à travers des exemples concrets. Nous tenterons de voir dans quel cas chaque notation est la mieux adaptée.

Processus métiers en entreprise

Définition (agrégation de différentes sources)

C’est un enchaînement d’étapes à réaliser pour répondre à un objectif métier identifié. Ces étapes sont des actions réalisées par différents acteurs et synchronisées par des échanges. Le processus métier crée de la valeur au sein d’une organisation.

Quelques représentations d’un processus

Représentation selon une notation spécifique (UML – Eriksson-Penker)

Lire la suite

Améliorer le rendu des diagrammes Enterprise Architect avec les styles visuels

Cet article présente dans un premier temps l’intérêt d’utiliser un référentiel de modélisation avec l’outil Enterprise Architect par rapport à un outil de dessin « BPMN ». Puis cet article aborde l’utilisation des styles visuels pour améliorer l’aspect visuel de vos diagrammes sous EA.

Un passage vital d’un outil de dessin vers un référentiel de modélisation

Contexte : dans le cadre d’un projet en clientèle, j’ai pris connaissance avec un collègue d’un ensemble de diagrammes BPMN définis par une équipe en charge de modéliser un ensemble de processus. Ces diagrammes BPMN étaient maintenus par un outil de modélisation BPM, « Bizagi BPMN Business Process Modeler ». L’aspect gratuit de ce freeware a probablement contribué à une adoption rapide au début du projet. L’aspect visuel des diagrammes de Bizagi était agréable et moderne. Mon collègue a rejoint ce projet afin de contribuer aux tâches en cours en apportant son expertise UML et BPMN.

Au bout d’un certain temps, je lui ai demandé son avis sur Bizagi par rapport à Sparx Enterprise Architect qui est utilisé pour d’autres aspects du projet. Sa réponse était claire : Bizagi est principalement un outil de dessin BPMN, comme peut l’être Ms Visio pour dessiner des diagrammes UML. Aussi il n’était pas possible de bénéficier des avantages d’un référentiel de modélisation, à savoir :

  • un explorateur pour parcourir la structure des modèles via les paquetages, diagrammes, et éléments
  • pouvoir construire un modèle navigable,
  • accéder aux propriétés de chaque élément du modèle (activité, gateway, etc.),
  • réutiliser la même activité (ou un autre élément) sur plusieurs diagrammes,
  • consulter les liens entre éléments du projet (traçabilité) de différents modèles (ex : exigences, analyse, conception, architecture…),
  • et encore bien d’autres fonctions (reverse/forward engineering, génération de document, etc.).

Le projet BPMN dans Bizagi étant devenu difficile à gérer et maintenir, un projet de modélisation a été créé sous EA pour reprendre l’ensemble des processus.

Appliquer les styles visuels pour améliorer le rendu de vos diagrammes BPMN

J’ai commencé par la suite à créer et maintenir des diagrammes BPMN2 dans EA. Les propriétés d’affichage disponibles par défaut sous EA pour les diagrammes BPMN étaient plutôt « basiques ». Dans un soucis de conserver un style d’affichage similaire aux diagrammes fournis jusqu’à présent aux utilisateurs, j’ai recherché des moyens simples dans EA pour appliquer un style d’affichage proche de l’outil Bizagi. Sans avoir atteint exactement le même rendu, j’ai pu facilement définir des styles d’affichages très similaires :

  • Evènement déclencheur BPMN2 :
    • couleur de fond = vert clair
    • couleur de la bordure = vert foncé

  • Evènement résultant ou final BPMN2 :
    • couleur de fond = rouge clair
    • couleur de la bordure = rouge foncé

  • Activités et gateways BPMN2 :
    • couleur de fond = bleu clair
    • couleur de la bordure = bleu foncé

La création de nouveaux styles visuels est très simple :

  • 1- sélectionner un élément puis définir ses aspects visuels : couleur de fond, couleur et épaisseur de trait/bordure, police de caractères.
  • Etape alternative : sélectionner un élément dont les aspects visuels ont déjà été définis puis cliquer sur l’icône « Get Style » de la barre d’outils du diagramme.
  • 2- cliquer sur l’icône « Save as New Style » de la barre d’outils du diagramme; EA demande la saisie du nom pour ce style visuel, par exemple « start event ».
  • Répétez ces étapes pour chaque style à définir.

Remarque : les styles visuels sont enregistrés dans votre projet EA (ex : fichier avec l’extension EAP), mais il n’est pas actuellement possible de les exporter via les « Reference Data » (utilisées pour exporter les images, templates RTF, matrices, etc.).

Après avoir créé vos styles visuels, ceux-ci se rajoutent à la liste suivante :

Voici un exemple de diagramme BPMN2 pour lequel j’ai appliqué ces nouveaux styles :

L’utilité des diagrammes incomplets : à la recherche d’une vision commune

Ce titre peut susciter des questions : pourquoi chercherait-on à produire quelque chose d’incomplet? Le but n’est-il pas plutôt d’avoir un modèle juste, correct, correspondant à ce que l’on cherche à réaliser?

Cet article présente une notion simple : le but des modèles est de représenter de manière visuelle le problème, ce pour favoriser les échanges entre les participants. Cette notion est compatible avec les méthodes itératives et agiles ; un modèle n’est pas produit pour être figé, mais pour évoluer au fur et à mesure de cycles ou itérations. Dans certains cas, un modèle aura uniquement pour but de se mettre d’accord sur ce que l’on cherche à réaliser, sans pour autant répercuter les changements sur ses diagrammes.

Il est donc fort probable que la première version d’un modèle ou diagramme soit incorrecte ou « fausse ». Lorsque l’on créé puis présente un diagramme, l’on ne cherche pas à avoir tout juste dès le départ ; le but est de susciter des réactions de la part des interlocuteurs MOA ou MOE, pour corriger et affiner les modèles (en direct lors d’un atelier par exemple avec un outil de modélisation comme Enterprise Architect, ou à postériori).

Les modèles nous permettent alors de se rapprocher d’une vision commune et partagée, ce qui va demander plus ou moins d’itérations et d’efforts selon le contexte et les besoins du projet. Une mise à jour itérative des modèles présente l’avantage de capitaliser sur les choix qui ont été pris par rapport aux impacts sur des évolutions et corrections ultérieures, sur de la maintenance, etc.

Retours d’expériences :

Pas plus tard qu’hier, un de mes collègues était ravi de l’utilité de mon diagramme BPMN « faux » dont l’objectif était de formaliser un processus global en vue d’une décision GO/NOGO : « le diagramme a déjà permis de lever des lièvres et de discuter avec le responsable fonctionnel ». A ce stade du projet, les retours des divers responsables peuvent être pris en compte pour arriver vers une vision partagée par tous, ce afin de pouvoir justifier la décision qui sera prise par la suite.

Les exemples sur l’utilité de diagrammes incomplets et non aboutis ne manquent pas ; j’ai eu l’occasion d’établir une cartographie fonctionnelle en travaillant avec deux équipes MOE travaillant sur deux produits en interaction. Chaque équipe m’a décrit et argumenté ses choix d’architecture, identifiant les échanges de données entre leurs applications et systèmes. Chacune de ces équipes avait également un avis plus ou moins abouti sur les choix faits par l’autre équipe. Les modèles UML générés à l’issue de cette étude ont permis non seulement de poser la vision aboutie d’un produit par son équipe de développeurs et d’architectes, mais aussi de mettre à disposition le fonctionnement du produit en interaction avec le leur.

C’est donc en partant d’un diagramme « évidemment » incomplet, que de nombreux échanges constructifs ont donné lieu à la représentation globale et transverse des produits existants, ce en vue de décisions d’architecture pour optimiser et améliorer certains aspects.