10 règles pour bien modéliser vos processus - JDN web & tech http://www.journaldunet.com/solutions/expert/52335/10-regles-pour-bi...

Chronique de Guy Boizard

Directeur technique, Rhapsodies Conseil
17/09/12 10:00

La modélisation des processus s'est répandue au cours des dernières années. Elle est un
exercice délicat, surtout pour des personnes peu préparées. Cette chronique propose 10
règles pratiques et éprouvées pour produire des modèles utiles, et les réaliser
rapidement.

L’intérêt de la modélisation des processus n’est plus à démontrer. Du côté des

informaticiens, de nombreuses démarches de conception, d’urbanisation, d’»architecture
d’entreprise» se fondent sur la modélisation des processus ; ces méthodes commencent à
se diffuser du côté des utilisateurs et à attirer l’attention des décideurs. En parallèle, de
nombreuses entreprises refondent en permanence leurs processus pour les
optimiser et les adapter aux évolutions de leur métier.
Toutefois, bien modéliser n’est pas donné à tout le monde. Récemment, j’ai été témoin
de l’expérience suivante : dans une grande entreprise, la Direction des Opérations avait
demandé à 3 personnes de modéliser le même processus. A l’arrivée, elle a obtenu trois
résultats complètement différents ! Imagine-t-on un architecte fournir trois plans
différents pour un même bâtiment, ou un constructeur de PC fournir 3 plans différents
de la même carte-mère à son fabricant ?

Bien modéliser n’est pas un problème d’outillage, mais de méthode : la véritable

difficulté est d’appliquer des règles simples, pour aboutir à un modèle qui soit à la fois
fidèle et utile. Il ne suffit pas de maîtriser les notations BPMN ou UML : comme
pour la musique, savoir lire une partition ne fait pas de vous un Bach ou un
Gainsbourg du jour au lendemain !

Pour remédier à cette situation, il convient d'appliquer les dix règles concrètes de
modélisation des processus :
1) Distinguer processus et procédure : cette règle bien connue est dans les faits très
mal appliquée. Rappelons les définitions de l’AFNOR : un processus est un ‘ensemble
d'activités corrélées ou interactives qui transforme des éléments d'entrée en éléments de

1 sur 5 11/10/2012 14:21

10 règles pour bien modéliser vos processus - JDN web & tech http://www.journaldunet.com/solutions/expert/52335/10-regles-pour-bi...

sortie’ alors qu’une procédure est la ‘manière spécifiée d’accomplir une activité’.
Bref, le processus décrit uniquement les invariants, c’est-à-dire les règles
universelles applicables à toutes les organisations, indépendamment des moyens
utilisés pour son exécution. Les moyens sont à décrire dans les procédures. Par
exemple, une entreprise peut décider de mettre en place un processus unique et
multi-canal pour traiter les réclamations de ses clients. Ce processus se déclinera ensuite
selon différentes procédures, selon que la communication avec le client se fait par
courrier, par e-mail, ou par téléphone.

Distinguer processus et procédure est la condition indispensable pour identifier les

règles communes que l’entreprise s’impose – ou que le monde extérieur lui impose -, et
bien les séparer des contraintes liées aux moyens utilisés.

2) Se contenter de 3 niveaux de description : on rencontre parfois de superbes

« chaînes de valeur » où les processus se décomposent en poupées russes. Il est fréquent
de devoir explorer 6 ou 7 niveaux de profondeur. D’autres modélisateurs sont des
adeptes de la récursivité : un seul concept est mis en œuvre, par exemple l’activité, et
une activité peut contenir des activités, et ainsi de suite…
Problème : dans les deux cas, ces modèles s’avèrent très vite inexploitables. Par
exemple, il est très difficile au modélisateur de déterminer si l’action « contacter le
client » devrait se situer au niveau 4, 5 ou 6. Conséquence : le référentiel des processus
de l’entreprise contient de nombreux doublons, alors que chaque tâche et chaque activité
ne devraient être décrites qu’une seule fois.

Nous recommandons de n’utiliser que trois éléments pour décrire les

processus : au niveau le plus détaillé, la tâche, puis l'activité, et enfin le processus
lui-même. Un quatrième niveau de description est utile lorsque l’on veut décrire les
procédures : nous recommandons d’introduire la notion d’opération. Chaque tâche est
alors décrite comme une suite d’opérations. Par exemple, contrôler l’identité d’une
personne se décline en plusieurs opérations selon les pays et les supports (carte
d’identité, badge, passeport biométrique…)

3) Définir les tâches par la transformation d’un objet Métier : toute tâche doit
modifier un objet Métier. Par objet Métier, Rhapsodies Conseil entend un élément
manipulé au quotidien par les acteurs de l’Entreprise. Il est assez facile de dresser une
liste des principaux objets Métiers. Ce sont souvent les mêmes d’une entreprise à
l’autre : des produits, des commandes, des contrats, des matériels… La règle permet
alors de déterminer quelles sont les tâches qui sont vraiment nécessaires. En effet,
comme on l’entend souvent dire, une tâche doit avoir une valeur ajoutée. Un moyen
concret de s’en assurer, est de vérifier que la tâche a effectivement modifié un objet. A
l’inverse, toute action qui ne modifie rien n’a pas de valeur ajoutée, il est donc
totalement inutile de la décrire.
L’action « lire le courrier » par exemple n’a aucune valeur ajoutée : ce qui importe
vraiment, c’est de déterminer les tâches à exécuter suite à la réception de ce courrier.

2 sur 5 11/10/2012 14:21

10 règles pour bien modéliser vos processus - JDN web & tech http://www.journaldunet.com/solutions/expert/52335/10-regles-pour-bi...

4) Faire porter toutes les règles de gestion par des tâches : cette règle découle de la
précédente. Soit une tâche T1, qui permet de faire passer un objet O d’un état E1 à un
état E2. Pour cela, elle doit obéir à une série de règles de gestion. La tâche suivante aura
pour but de traiter tous les objets O qui sont dans l’état E2. A ce niveau de description,
il est totalement inutile d’ajouter une règle (ou pire, une tâche, comme on le voit
parfois) pour indiquer que lorsque la tâche T1 est terminée, alors il faut exécuter la tâche
T2. Ainsi, dès le départ, on isole tout naturellement les règles d’enchaînement, ce qui
facilite l’utilisation d’outils d’orchestration de processus (BPM, workflow).

5) Appliquer une démarche ‘bottom-up’ : c’est-à-dire décrire d’abord le niveau le

plus fin, les tâches. Celles-ci seront ensuite regroupées en activités, en fonction de règles
précises. Ceci évitera de reproduire l’organisation et les règles existantes : il suffit
d’identifier l’objet Métier en jeu, l’état final de cet objet, pour déterminer de proche en
proche les étapes nécessaires et les autres objets manipulés.
Exemple : pour un processus de recrutement, la dernière tâche peut être exprimée par
« confirmer l’adéquation du candidat au poste ». On en déduit les tâches antérieures :
contrat signé, poste de travail configuré, recrue formée,… Comme on le voit dans cet
exemple, on transcende les frontières de l’organisation, qui le plus souvent confie la
formation à une entité, la signature du contrat d’embauche à une autre, la configuration
du poste de travail à une troisième.

6) Utiliser les évènements avec parcimonie : dans la grande majorité des cas, il est
inutile de conserver une trace séparée des évènements. Il suffit d’historiser les états
successifs par lesquels l’objet Métier est passé, ce qui revient exactement au même. Par
exemple, il est bien évident que la tâche « valider une facture » fait passer la facture
à l’état validé ; il ne sert donc à rien d’enregistrer dans le système d’information un
évènement ‘facture validée’. Il suffit de mémoriser la date à laquelle la facture a été
validée, et ce, seulement si on en a vraiment besoin. Cette approche simplifie la mise en
œuvre du pilotage de l’activité (BAM) en se concentrant directement sur les résultats, et
non sur les évènements.

Bien entendu, certains évènements doivent figurer dans le modèle de processus.

C’est en particulier le cas des évènements indépendants de tous les acteurs : par
exemple, la fin du mois, pour déclencher un arrêté comptable.

7) Faire porter les activités sur un objet métier unique : une activité est une suite
de tâches qui portent sur un même objet, et qui a pour but de faire passer cet objet par
des états successifs de son cycle de vie. La raison de ce critère de regroupement est
purement économique : dans l’idéal, cette série de tâches devrait pouvoir être confiée à
un même agent, de manière à éviter les ruptures de charge, toujours coûteuses.

8) Déterminer les rôles à partir des activités, et non l’inverse : un rôle doit être vu
comme l’ensemble des privilèges nécessaires à un même agent (personne, système…)
pour pouvoir exécuter les tâches qui lui sont confiées.

3 sur 5 11/10/2012 14:21

10 règles pour bien modéliser vos processus - JDN web & tech http://www.journaldunet.com/solutions/expert/52335/10-regles-pour-bi...

Dans l’idéal, comme on l’a vu précédemment, il est plus économique de faire exécuter
une activité de bout en bout par le même agent. Toutefois, ceci n’est pas toujours
souhaitable, en particulier pour des raisons de sécurité et de contrôle. L’exemple
classique est le traitement des factures Fournisseurs : l’agent qui valide une facture ne
peut pas déclencher le règlement de celle-ci. Ceci aboutit à définir deux rôles distincts.
Contrairement à l’approche couramment pratiquée, ce ne sont donc pas les rôles qui
doivent déterminer les activités, mais bien les activités qui doivent déterminer les rôles.
Le titre de « Contrôleur de Gestion » par exemple, ne permet pas de déterminer les
différentes activités dont un contrôleur de gestion a la charge : celles-ci varient
fortement d’une organisation à l’autre. Par exemple, dans certaines entreprises, le
contrôleur de gestion approuve les commandes d’investissement; dans d’autres, il valide
les factures.

9) Distinguer les pouvoirs des compétences : les compétences nécessaires à

l’accomplissement des activités n’ont pas à intervenir lorsqu’il s’agit de décrire un
processus. Ces compétences seront à prendre en compte dans un deuxième temps
seulement, au moment de définir les moyens nécessaires pour exécuter les tâches, c’est-
à-dire lorsque l’on déclinera les procédures.
Choisir de spécialiser ou non des agents en fonction de leur compétences est une
décision purement économique : dans beaucoup de restaurants, le client va se servir
lui-même. Et dans certains restaurants, le client cuit lui-même son repas !

10) Tenir compte des intérêts de toutes les parties prenantes : ce sera notre critère
principal pour déterminer les bornes d’un processus. Un processus n’est que l’un des
chemins possibles parmi toutes les activités qui figurent au « catalogue » de
l’entreprise : il ne s’arrête que lorsque les intérêts de toutes les parties prenantes sont
satisfaits.
Par exemple, il y a quelques années, un opérateur de téléphonie mobile prenait la peine
d’appeler ses clients dans les 48 heures suivant leur achat d’un nouveau coffret, de
manière à s’assurer qu’ils arrivaient bien à l’utiliser. Par ailleurs, on oublie trop souvent
les intérêts de l’État, du partenaire à qui il faut verser une commission,… Bien entendu,
il ne s’agit pas de dire que toute l’Entreprise peut se réduire à un seul processus !

En conclusion, ces quelques règles basiques garantissent un référentiel de processus

homogène : éviter d’avoir 200 actions pour décrire un processus alors que 15 suffisent,
éviter des doublons du type « accorder un prêt » et « octroyer un crédit »… Avantage
tout aussi important, elles amènent à se poser les bonnes questions au moment de
modéliser un processus : et en particulier, distinguer ce qui est vraiment invariant, de
ce qui dépend des moyens utilisés. Un modèle construit avec ces règles permettra à
l’organisateur de trouver des leviers d’optimisation, et à l’informaticien, de trouver les
fonctions à implémenter dans le système informatique.

--------------------------------------

Remerciements : Rendons à César ce qui lui appartient : si la majorité de ces règles sont

4 sur 5 11/10/2012 14:21

10 règles pour bien modéliser vos processus - JDN web & tech http://www.journaldunet.com/solutions/expert/52335/10-regles-pour-bi...

ma modeste contribution, je remercie Praxeme qui dès 2003, avait clairement formulé la
règle N°3. Merci également au Club des Pilotes de Processus, dont sont tirés
quelques-uns des exemples cités.

Ajouter un commentaire...

Commenter avec...

Module social Facebook

Pour ou contre de la modélisation des processus

10 règles pour bien modéliser vos processus
Introduction - 6 outils de modélisation
La Saga du BPM : du processus métier au BPM (2eme partie)
Le contexte - Stratégie d'e-achat chez Technip
La modélisation au cœur de l'outil - Visual Studio 2010 : décryptage
ERP - Logiciel Open Source applications métiers

5 sur 5 11/10/2012 14:21