J'ai passé ma journée d'hier sur la modélisation d'un processus de gestion des incidents d'un centre de services d'un ministère, dans le cadre d'un alignement avec ITIL. La modélisation de processus, plus encore que la modélisation de logiciel, donne souvent des diagrammes très compliqués si elle ne suit pas les principes de la modélisation agile, en particulier Model with a purpose et Assume simplicity.

La représentation des processus, ça devient vite une usine à gaz[1] en particulier dans 2 cas :

  • si on cherche à montrer dans une vue globale[2] tous les processus et toutes les communications possibles entre ces processus : documents ou produits, événements, appels...
  • si on cherche à montrer dans un workflow[3], tous les enchainements possibles des travaux réalisés.

L'outil a aussi son importance pour maîtriser la complexité des processus. Nous utilisons le Composer d'EPF, qui permet de bien séparer les aspects méthode[4] des aspects processus[5] et offre des constructions avancées et puissantes, en particulier les capability patterns. EPF Composer est basé sur le langage SPEM de l'OMG, qui apporte toutes les notions de l'orienté objet, adaptées aux processus.

Notes

[1] ou un plat de spaghetti

[2] qu'on appelle cartographie des processus

[3] avec un diagramme d'activité

[4] pour simplifier, c'est la partie statique : les rôles, les produits et les tâches

[5] le côté dynamique et l'assemblage des éléments de la partie méthode pour construire un processus