La description des processus

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 construction 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.

E2E macro process

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: la collecte de l’information doit avoir été au minimum initialisée. 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ègle métier: 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.

4 réflexions au sujet de « La description des processus »

  1. Les flèches roses dédiées à la methode Bottum up et et déscendante ne sont elles pas à l’envers ?
    Bravo ce site très bien construit et qui donne envie de faire ce métier

    1. Bien vu, merci pour le coup d’oeil! J’ai corrigé le schéma… Et merci également pour votre commentaire, Stéphan, cela m’encourage continuer d’alimenter ce blog 🙂

      1. Alice, il y a un livre « modéliser les processus » qui apparaissait sur votre site. Je ne le retrouve pas. Avez vous un ouvrage en tête et des exemples de SFG/SFD.

        Je suis un ancien opérationnel/métier manager de transition et me faisais la réflexion que dans ma boite (un intégrateur CRM) il y a beaucoup trop de littérature et pas de représentations type logigrammes ce qui me surprend un peu dans une boite tres MOE ….et c’est aussi exactement ce que vous pointez du doigt sur votre site

        Ils sont peu orientés besoin client en plus, mais apparemment c’est moi qui comprend pas, ce que je suis prêt à entendre dans une certaine mesure..

        1. Je ne vois pas trop de quel livre vous parlez, Stéphan. Cependant, il existe pas mal de littérature sur le sujet. Personnellement, j’aime beaucoup le RUP, mais malheureusement, c’est un contre-exemple de ce que je viens de vous dire car il n’existe plus de publications sur le sujet (sauf en occasion, vous pouvez chercher par exemple « Le guide pratique du RUP » chez Campus Press, de Per Kroll et P. Krutchen).
          Après, il y a de bons livres généralistes (par ex « Maîtriser les processus de l’entreprise »), ou encore des livres décrivant l’application de méthodes comme le célèbre Business Process Modeling (par ex, « Business Process Management – Practical Guidelines to Successful Implementations » ).
          Ce que vous décrivez de votre entreprise – concernant le manque de « sensibilité » aux besoins des clients – est l’une des raisons pour lesquelles je souhaite promouvoir les bonnes pratiques de la business analysis :). Cela dit, il convient d’identifier qui sont nos clients… Les clients finaux de l’entreprise pour laquelle nous travaillons? Un service / département interne? Une autorité réglementaire? Le comité stratégique de l’entreprise? Notre rôle, à nous, business analysts, est d’identifier leurs besoins tacites, cachés ou explicites suite à une nécessité de changement, puis de les traduire ensuite en solutions métier, opérationnelles et/ou techniques. Il ne nous appartient pas de prendre une décision stratégique à la place des dirigeants de l’entreprise. Par exemple, si le choix de votre hiérarchie est de privilégier la rentabilité de l’entreprise au détriment du besoins de ses clients, même si cela vous peut vous poser un problème éthique, votre rôle en tant que BA sera de réfléchir à une solution pour que cet objectif de rentabilité soit atteint. Ce qui n’empêche pas, pendant le cadrage, de vous assurer que ces objectifs de rentabilité au détriment du service rendu aux clients sont bien ceux à atteindre… Ce n’est qu’un exemple, bien sûr, pour bien préciser le périmètre du travail de Business Analyst.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *