La modélisation des processus est devenue courante ces dernières années. Cet exercice délicat nécessite une préparation adéquate. Dans cet article, nous vous proposons 10 règles pratiques et éprouvées pour créer des modèles utiles et les réaliser efficacement.
L’intérêt de la modélisation des processus
La modélisation des processus est devenue essentielle pour les informaticiens, qui utilisent différentes méthodes de conception et d’urbanisation basées sur celle-ci. De plus, les utilisateurs et les décideurs commencent à s’y intéresser de plus en plus. Parallèlement, de nombreuses entreprises revoient constamment leurs processus pour les optimiser et les adapter à l’évolution de leurs activités.
La difficulté de bien modéliser
Cependant, la modélisation n’est pas donnée à tout le monde. Un exemple concret est une expérience vécue dans une grande entreprise, où trois personnes ont été chargées de modéliser le même processus, aboutissant à trois résultats complètement différents. Cela serait impensable pour un architecte qui fournirait trois plans différents pour un même bâtiment.
Bien modéliser ne dépend pas seulement des outils utilisés, mais aussi de la méthode. Il est essentiel d’appliquer des règles simples pour obtenir un modèle fidèle et utile. La maîtrise des notations BPMN ou UML ne suffit pas, tout comme savoir lire une partition ne fait pas de vous un Bach ou un Gainsbourg du jour au lendemain.
Pour remédier à cette situation, voici dix règles concrètes de modélisation des processus :
1) Distinguer processus et procédure
Cette règle bien connue est souvent mal appliquée. Un processus décrit 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. Cette distinction est indispensable pour identifier les règles communes et les séparer des contraintes liées aux moyens utilisés.
2) Se contenter de 3 niveaux de description
Il est fréquent de voir des modèles de processus qui se décomposent en de multiples niveaux de profondeur. Cependant, ces modèles deviennent rapidement inexploitables. Il est recommandé de n’utiliser que trois niveaux : la tâche, l’activité et le processus lui-même. Un quatrième niveau peut être ajouté pour décrire les procédures.
3) Définir les tâches par la transformation d’un objet Métier
Chaque tâche doit modifier un objet Métier, c’est-à-dire un élément manipulé quotidiennement par les acteurs de l’entreprise. Une tâche doit avoir une valeur ajoutée, ce qui signifie qu’elle doit effectivement modifier un objet. Les actions qui ne modifient rien n’ont aucune valeur ajoutée et ne doivent donc pas être décrites.
4) Faire porter toutes les règles de gestion par des tâches
Les règles de gestion doivent être incluses dans les tâches. Il est inutile d’ajouter une règle ou une tâche pour indiquer qu’une tâche doit être exécutée après une autre. Il est ainsi possible d’isoler les règles d’enchaînement et de faciliter l’utilisation d’outils d’orchestration de processus.
5) Appliquer une démarche ‘bottom-up’
Décrire d’abord les tâches, puis regrouper celles-ci en activités en fonction de règles précises. Cela évite de reproduire l’organisation et les règles existantes. Il suffit d’identifier l’objet Métier en jeu et l’état final de cet objet pour déterminer les étapes nécessaires.
6) Utiliser les événements avec parcimonie
Dans la plupart des cas, il est inutile de conserver une trace séparée des événements. Il suffit d’historiser les états successifs de l’objet Métier. Certains événements doivent figurer dans le modèle de processus, comme 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é regroupe les tâches qui portent sur un même objet et vise à faire passer cet objet par des états successifs de son cycle de vie. Cela permet d’éviter les ruptures de charge coûteuses en confiant idéalement cette série de tâches à un même agent.
8) Déterminer les rôles à partir des activités
Un rôle doit être déterminé en fonction des privilèges nécessaires à un même agent pour exécuter les tâches qui lui sont confiées. L’idéal est de faire exécuter une activité de bout en bout par le même agent. Ce ne sont donc pas les rôles qui doivent déterminer les activités, mais bien l’inverse.
9) Distinguer les pouvoirs des compétences
Les compétences nécessaires pour accomplir les activités ne doivent pas être prises en compte lors de la description d’un processus. Elles seront considérées lorsque les moyens nécessaires pour exécuter les tâches seront définis.
10) Tenir compte des intérêts de toutes les parties prenantes
Les intérêts de toutes les parties prenantes doivent être pris en compte pour déterminer les limites d’un processus. Un processus ne s’arrête que lorsque les intérêts de toutes les parties prenantes sont satisfaits.
En conclusion, appliquer ces règles garantit un référentiel de processus homogène. Cela évite d’avoir trop d’actions pour décrire un processus et conduit à se poser les bonnes questions lors de la modélisation. Un modèle construit avec ces règles permet d’optimiser l’organisation et de définir les fonctions à implémenter dans le système informatique.
Remerciements : cet article s’inspire des règles énoncées par Praxeme et des exemples cités par le Club des Pilotes de Processus.
