La modélisation des processus est devenue courante au cours des dernières années. Il s’agit d’un exercice délicat qui peut être difficile pour les personnes peu préparées. Dans cet article, nous vous proposons dix règles pratiques et éprouvées pour produire des modèles utiles et les réaliser rapidement.
L’importance de la modélisation des processus
Du côté des informaticiens, de nombreuses démarches de conception, d’urbanisation et d’architecture d’entreprise reposent sur la modélisation des processus. Ces méthodes commencent à se diffuser du côté des utilisateurs et à attirer l’attention des décideurs. Parallèlement, de nombreuses entreprises réorganisent en permanence leurs processus pour les optimiser et les adapter aux évolutions de leur métier.
Cependant, bien modéliser n’est pas donné à tout le monde. Récemment, dans une grande entreprise, la Direction des Opérations a demandé à trois personnes de modéliser le même processus. Résultat : trois résultats complètement différents ! Imaginez un architecte fournir trois plans différents pour un même bâtiment, ou un constructeur de PC fournir trois 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é réside dans l’application de règles simples pour obtenir un modèle 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 !
Les dix règles concrètes de modélisation des processus
1) Distinguer processus et procédure
Il est crucial de bien comprendre la différence entre processus et procédure. Un processus décrit 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 multicanal 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.
2) Se limiter à trois niveaux de description
Il est préférable de n’utiliser que trois éléments pour décrire les processus : la tâche, l’activité et le processus lui-même. Un quatrième niveau de description est utile lorsqu’il s’agit de décrire les procédures, avec la notion d’opération.
3) Définir les tâches par la transformation d’un objet métier
Chaque tâche doit modifier un objet métier. Une tâche doit avoir une valeur ajoutée en modifiant un objet. Une action qui ne modifie rien n’a pas de valeur ajoutée et ne doit pas être décrite.
4) Faire porter toutes les règles de gestion par des tâches
Les règles de gestion doivent être portées par des tâches. Il n’est pas nécessaire d’ajouter une règle ou une tâche pour indiquer l’enchaînement des tâches.
5) Appliquer une démarche ‘bottom-up’
Il est recommandé de décrire d’abord le niveau le plus fin, les tâches. Ensuite, regrouper ces tâches en activités en fonction de règles précises. Cela évite de reproduire les règles existantes et facilite l’identification des é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 par lesquels l’objet métier est passé. Certains événements doivent toutefois 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é est une suite de tâches qui portent sur un même objet métier. Regrouper ces tâches sur un même objet permet d’éviter les ruptures de charge, qui sont coûteuses.
8) Déterminer les rôles à partir des activités
Le rôle doit être déterminé en fonction des activités à réaliser. Il est plus économique de faire exécuter une activité de bout en bout par le même agent, sauf pour des raisons de sécurité et de contrôle.
9) Distinguer les pouvoirs des compétences
Les compétences nécessaires à l’accomplissement des activités ne doivent pas intervenir lors de la description d’un processus. Elles seront prises en compte dans un deuxième temps, au moment de définir les moyens nécessaires pour exécuter les tâches.
10) Tenir compte des intérêts de toutes les parties prenantes
Les bornes d’un processus doivent être déterminées en tenant compte des intérêts de toutes les parties prenantes. Un processus ne s’arrête que lorsque les intérêts de toutes les parties prenantes sont satisfaits.
En conclusion, ces règles garantissent un référentiel de processus homogène et amènent à se poser les bonnes questions lors de la modélisation d’un processus. Elles permettent de distinguer ce qui est vraiment invariant de ce qui dépend des moyens utilisés. Un modèle construit avec ces règles permettra de trouver des leviers d’optimisation et de déterminer les fonctions à implémenter dans le système informatique.
(Remerciements: Rendons à César ce qui lui appartient: la majorité de ces règles sont une contribution de Rhapsodies Conseil. Merci également au Club des Pilotes de Processus, dont sont tirés quelques exemples cités.)
