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.

Pourquoi étudier ou modéliser un processus métier (ou à quels processus faut-il s’intéresser) ?

Cette question a déjà été, en partie, abordée dans l’article précédent (paragraphe Processus métier, partie intégrante de la description d’un système d’informations). Il est clair, donc, que le processus métier retranscrit le déroulement des opérations, dans une organisation, selon la vision de ceux qui les exécutent, et surtout ceux qui utiliseront les futurs outils informatiques.

Pour ceux qui conçoivent et/ou fournissent des solutions informatiques, différentes visions du processus métier sont à discerner :

  • Les processus métier axés sur l’orchestration des activités. L’ordre et la synchronisation (résultats intermédiaires) sont essentiels pour le résultat final, et n’ont pas vocation à être revus ou changés par l’apport d’outils informatiques. Ils doivent être étudiés de manière précise afin que les outils destinés à les couvrir n’altèrent pas leur structure. Ils concernent généralement des métiers spécifiques, classés comme cœur de métier de l’organisation, ils font partie des activités principales de la chaine de valeur, et nécessitent souvent le développement d’outils spécifiques ou de la personnalisation d’outils standards.
  • Les processus métiers axés sur le résultat de sortie ou le sortant qui est produit. L’orchestration des activités passe en second plan du moment que le but est atteint. Dans ce cas, les outils informatiques ont plus de liberté et peuvent même être force de proposition. Ces processus n’ont pas besoin d’être étudiés systématiquement en détail. Ce sont souvent des processus de pilotage qui fournissent indicateurs et autres métriques. Dans l’industrie du logiciel, il existe des outils qui permettent de créer des solutions personnalisées (ex : solution de Business Intelligence).
  • Les processus métier dit ‘standards’, on les retrouve dans la plupart des organisations ou entreprises et ils regroupent les activités standard de la chaine de valeur (comptabilité, finance, RH, …). L’orchestration peut être revisitée, par souci d’optimisation, tant que le résultat final est atteint. L’industrie du logiciel propose des solutions, avec leurs propres processus métiers, prêtes à l’emploi. Ces outils prévoient une marge de personnalisation, ce qui permet de trouver un compromis entre les processus de l’outil et ceux de l’organisation.

Donc, on peut dire que :

L’étude et la modélisation des processus métier, n’est pas systématique pour pouvoir produire du logiciel.

Quand la modélisation s’impose (première catégorie de processus ci-dessus), il serait dommage de se priver de cet outil et mettre, de ce fait, le projet en risque (incompréhensions, ambiguïtés, …). Dans ce cas, le top-down s’impose (souvenez-vous, dans l’article précédent, la représentation du SI d’une organisation selon la vision des 4 couches de l’urbanisation). Le top, couche du haut, en l’occurrence la couche métier, dicte le besoin au down, couches du bas (couches informatiques). Par la suite, il se peut qu’il faille quand même apporter quelques ajustements aux processus pour prendre en compte l’utilisation de l’outil informatique.

Dans le cas où les solutions informatiques proposent déjà des processus métiers à travers leur propre vision, il peut être opportun, après la phase de personnalisation et de paramétrage, de modéliser les processus. Cela servira de référence pour d’autres processus de nature organisationnelle (management, accompagnement au changement, contrôles qualités, …). Cette démarche ou approche est aussi connue sous le nom bottom-up.

Quels processus modéliser en priorité ?

Un outil informatique est destiné à couvrir un ensemble de processus métier selon un périmètre plus ou moins étendu. Dans le cas où des processus seraient amenés à être étudiés et modélisés, pour les raisons abordées dans la section précédente, il faut prioriser les processus identifiés. Ci-dessous quelques points à prendre en compte pour établir cet ordre :

  • Certains processus utilisent des éléments (entrants ou ressources) produits par d’autres processus.
  • Certains processus utilisent des éléments (entrants ou ressources) sous condition d’état particulier (statut).
  • Certains processus déclenchent des événements qui lancent d’autres processus.

Il existe des outils ou techniques permettant de faire émerger ces aspects :

  • Le diagramme de flux : représentation des différentes entités impliquées dans les processus et les objets échangés.
  • Diagrammes d’état des objets métier : représentation de l’évolution d’un objet métier à travers tous ses statuts.
  • Décomposition des processus de plus haut niveau (macro) en sous-processus en représentant l’enchainement de ces processus.

C’est le recueil du besoin auprès des ‘sachant’ qui permet de décrire les processus métiers, mais ces techniques permettent de mieux préparer les ateliers, d’aller à l’essentiel et, par la suite, de mieux représenter la matière obtenue.

Selon quel niveau de détail (profondeur et transversalité) ?

Selon les standards, il existe 2 ou 3 niveaux de profondeur pour les processus, à partir du niveau le plus haut (macro-processus d’entreprise, processus, sous-processus). Ce sont les briques du niveau le plus bas qui seront ensuite représentées sous forme de modèle. Le modèle représente la décomposition du processus (ou sous-processus) en enchainement d’activités. Les activités peuvent être à leur tour décomposées en activités plus fines. Il est aussi possible d’introduire la notion de ‘tâche’ qui est le plus petit niveau de travail à accomplir pouvant être décrit.

Les outils informatiques viendront proposer des fonctions pour automatiser ou ‘informatiser’ certaines activités et tâches des processus métiers en proposant des fonctionnalités sous forme d’interfaces IHM et autres traitements.

C’est la spécification de ces fonctionnalités qui fixera le niveau de détail (profondeur) attendu d’un processus et l’étendue (périmètre) à étudier.

Ci-dessous, la hiérarchie des processus métier d’entreprise

Modéliser l’existant ou la cible ?

 Le fait qu’il existe un ‘existant’ et une ‘cible’ pour un processus métier, laisse présager qu’il y a du changement en vue dans l’organisation.

Dans le cas des processus de la première catégorie (axés sur l’orchestration des activités) qui dictent la manière de faire aux outils, la connaissance de la cible est primordiale et doit être représentée sous forme de modèle, partagée et validée. Cette vision permettra à l’informatique de fournir des outils alignés. La description des processus cible doit donc être faite en amont de l’étude informatique.

Dans le cas des processus dit ‘standards’, les outils proposent déjà une vision. L’étude informatique consistera à projeter l’entreprise à travers l’outil et à décrire les processus ‘cible’ incluant l’utilisation de cet outil.

On voit que la vraie question est ‘Modéliser avant ou après l’apport de l’outil’ et que, de toute façon, c’est la cible qui est intéressante car elle représente l’avenir.

Ceci dit, il est parfois utile de représenter un processus existant, bien qu’un changement soit imminent ; le but est alors de détecter d’éventuelles anomalies ou d’éventuels points d’amélioration, puis de proposer une alternative. Tout bon orateur vous le dira, on commence par une description de l’existant, pour en faire la critique, puis on annonce : « le changement, c’est maintenant ».

A suivre…

Dans le prochaine article, nous nous intéresserons plus à l’aspect ‘comment’ entreprendre la modélisation une fois que les processus devant être décris sont identifiés. Les questions qui relèvent en apparence de la forme sont tout aussi importantes et participent fortement à la réussite des projets.

2 réflexions au sujet de « Processus métiers en entreprise : pourquoi, comment (première partie) »

  • Ping : Processus métiers en entreprise : introduction et notions | Blog Objet Direct

  • 20 mars 2014 à 16 h 50 min
    Permalink

    Bravo pour cette série d’articles sur les processus métiers ! Des infos à la fois précises et didactiques, qui nous font bien comprendre l’importance de cette étape de modélisation des processus. Les processus métiers sont de plus en plus au coeur des préoccupation des dirigeants et des responsables métiers, car lorsqu’ils sont bien compris et bien mis en place, il peuvent véritablement faire la différence en matière de productivité et d’évolutivité du SI.

Laisser un commentaire

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