La description des processus

(temps de lecture moyen: 3 min)

• La description des processus : un livrable incontournable
• Ma méthodologie en 7 étapes
• Mes bonnes pratiques pour décrire les processus

La description des processus a pour objectif de formaliser de manière conceptuelle et synthétique les processus d’une organisation. Ceux-ci peuvent être orientés métier ou IT.

L’objectif principal est d’identifier les bonnes pratiques à améliorer ou à harmoniser.

La description des processus : un livrable incontournable

Décrire les processus existants est un prérequis indispensable à la conception de la solution cible. Omettre cette phase est fortement déconseillé, car :

• La solution cible risque d’être définie sur la base d’un diagnostic erroné ;
• Les exceptions ou particularités peuvent être oubliées ;
• La vision d’ensemble et la raison d’être du changement risque de ne pas être formulées correctement ni, par conséquent, partagées ;
• Enfin, la perception de la nécessité d’un changement n’étant pas claire pour toutes les parties prenantes, l’acceptation de la solution cible rencontrera inévitablement de fortes résistances. Ces résistances nécessiteront, au mieux, une débauche d’énergie de la part de l’Organisation pour faire passer le changement, et au pire, provoqueront un refus actif ou passif (contournement de la nouvelle solution) conduisant à un échec de son implémentation.

La démarche de description des processus peut / doit également être réalisée pour formaliser la solution cible, notamment pour obtenir un consensus partagé, clair et non ambigu des parties prenantes de ce que sera l’état futur du système.

Ma méthodologie en 7 étapes

Voici une synthèse de la méthodologie que j’utilise pour décrire les processus existants.

1. En prérequis: le recueil de l’information doit avoir été au minimum initialisé. La description des processus peut débuter sans attendre la fin de cette étape ; elle sera améliorée au fur et à mesure.
2. Choix de la méthodologie: selon le contexte projet, le Business Analyst optera pour une méthodologie descendante ou ascendante (aussi appelée « bottom-up »).
   
   • Descendante : cartographie des macro-processus, puis décomposition en activités et tâches. Éventuellement, on pourra descendre au quatrième niveau opérationnel – cela dépendra de la population d’utilisateurs visée par la description des processus.
   • Ascendante : identification des tâches, puis regroupement logique par activités et enfin définition des macro-processus. Cette méthode permet d’éviter les doublons et aide à identifier des tâches communes à plusieurs activités.
   • Les étapes suivantes sont applicables à la méthode descendante.
3. Identification des macro-processus. Nommez les en utilisant un nom commun (par exemple « facturation »)
4. Organisation séquentielle des macro-processus. Il ne peut y avoir de macro-processus parallèles. Si tel est le cas, demandez-vous si vous n’êtes pas en train de décrire une activité ou une tâche. Regroupez les par objectif.
5. Identification et organisation temporelle logique des activités.
   
   • Celles-ci peuvent être parfois traitées en parallèle par les utilisateurs. Dans ce cas, essayez de les séquencer de la manière la plus logique ou selon leur usage le plus habituel. L’essentiel est de noter toutes les activités.
   • Nommez-les en utilisant un nom commun (par exemple, « contrôle cohérence BL / devis »)
6. Identification des tâches et séquencement de manière stricte.
   
   • Indiquez également les critères de décision décrivant l’enchaînement des tâches.
   • Nommez-les en utilisant un verbe d’action à l’infinitif. Cette sémantique vous permettra d’identifier les « fausses » tâches et de les exclure du diagramme.
7. Relecture de l’enchaînement global des macro-processus / activités / tâches :
   
   • Détaillez ou regroupez des niveaux de manière itérative.
   • Veillez à ce que cette étape se fasse en étroite collaboration avec les interlocuteurs métier.

Dans le cas de la méthodologie ascendante (« bottom-up ») : son utilisation est recommandée notamment lorsque vos interlocuteurs métier ne sont pas habitués à conceptualiser leur travail. Un autre avantage est de permettre l’identification des tâches / activités en doublon. Dans ce cas, commencez par décrire les tâches, puis regroupez-les par activités et enfin par macro-processus.

 

Mes bonnes pratiques pour décrire les processus

• Règles métiers: celles-ci doivent être décrites au niveau des tâches.
• Opération: si vous utilisez la méthode ascendante, commencez par la description des tâches et non pas des opérations qui les composent. Vous reviendrez ultérieurement sur ces dernières si votre client souhaite des procédures à ce niveau de détail.
• Tâche : une tâche doit modifier un objet métier. Sinon, elle ne doit pas être conceptualisée Par exemple, « lire la documentation source » ne modifie pas l’objet « documentation source » et n’est donc pas une tâche.
• Activité: faites 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.