Il est impossible d’accorder tous les acteurs d’un processus sur le niveau d’information à inclure dans un modèle, et c’est normal! Chaque classe d’audience a sa propre vision du processus (le terme perspective est communément employé pour décrire ce phénomène). Un VP ou un utilisateur final ne décrivent pas un processus de façon identique: le VP met en avant des objectifs que le processus doit atteindre tandis que l’utilisateur final décrit la façon dont il est évalué pour le processus: ses actions et les outils mis en œuvre.

Par abus de langage nous dirons que la perspective de l’utilisateur final est plus détaillée que celle du VP, mais il n’en est rien. Détailler la vision du VP, nous amène à passer des objectifs principaux aux sous-objectifs et non aux actions exécutées par les employés. Passer d’une perspective à une autre ce n’est pas détailler mais c’est convertir une attente en exigences!

Dans cet article je répondra à une question qui m’a souvent été posée: quel est le niveau de détail d’un processus?
Nous parlerons uniquement de business process et non de value chain ou de workflow technique qui sont aussi des processus mais pas du type que l’on appelle communément ‘business process’.

Les fonctions superflues sont supprimées!

Aucun objet ne doit être déposé dans le modèle sans apporter de valeur. Les fonctions décrivant un mouvement et non une intention sont soit des procédures que nous documenteront à un autre niveau de détail ou très souvent des fonctions sans valeur pour le processus. Voici quelques verbes caractéristiques de ces activités: envoyer et recevoir, ouvrir et copier. L’action de recevoir, implicitement fait référence à une envoie préalable, dès lors utiliser deux activités « Envoyer » et « Recevoir » ajoute de la redondance lorsque seule l’action de « Recevoir » suffirait à décrire la séquence.

Les instructions ne font pas partie du design d’un processus!

Work instructions ou encore procédures sont des termes faisant références au document fourni à des travailleurs (utilisateur finaux interne à l’entreprise) expliquant comment réaliser un travail. Ce type de document met l’accent sur le mouvement (défilement d’écran, clic de souris…) plutôt que sur l’objectif à atteindre. En suivant un tel document, le travailleur a très peu de flexibilité sur la façon de faire son travail. L’article sur les règles métiers (business rules) abordera ce sujet.

Un processus métier est constitué d’activité exécutées manuellement par des travailleurs et d’autres exécutées de façon automatique par des systèmes du SI (IT). Les instructions sont aux activités manuelles ce que le code est aux activités automatiques. Le code n’est pas détaillé dans un processus business alors pourquoi en serait-il différent pour les instructions humaines?

Quelques motivations pour ne pas documenter les instructions dans un business process:
- documenter les instructions augmente la complexité des modèles sans y apporter de la valeur. Le lecteur d’un business process apprécie les work instructions pour mieux réaliser ce que le travailleur fait concrètement et cela ne nécessite pas des boites et des flèches, une description textuelle liée à l’activité business est bien mieux adaptée.
- les travailleurs sont trop loin des objectifs business pour avoir une approche ‘processus’. Ils préfèrent en général recevoir leur instructions sous forme textuelle avec captures d’écrans. Documenter les instructions textuellement et sous forme de modèles duplique l’information et induit de l’effort additionnel de maintenance.

Quel est le bon niveau de granularité?

Un business process permet d’atteindre un ou plusieurs objectifs que l’on retrouve d’ailleurs dans le nom du processus (exemple: L’objectif du processus ‘Vendre une voiture’ est de faire du profit sur la vente de voiture tout en respectant les régulations en vigueur). Les blocs du business process seront les étapes permettant de réaliser les sous-objectifs actionnant l’objectif principal du processus. Idéalement chaque activité devrait représenter un sous-objectif.

On peut jouer avec les objectifs et sous-objectifs de la façon suivante:
Poser la question Pourquoi?: nous amène vers l’objectif
Poser la question Comment?: nous amène vers les sous objectifs puis vers les work instructions

Cette technique est utilisée dans le domaine de ingénierie d’exigences (requirements development) pour passer des business requirements aux user requirements puis aux solution requirements et vice et versa.

Lors de la définition de la bonne granularité une analogie peut être faite avec les Use cases. Je recommande comme lecture ‘Writting effective use cases’ de Alistair Cockburn. Alistair a su classifier les use cases par granularité des interactions décrites entre l’acteur et le système boite noire. Pour ceux habitués aux use cases le bon niveau de granularité d’un processus business correspond au use case de type user-goal. Le terme User-goal induit la notion d’objectif pour un utilisateur donné. Selon l’utilisateur questionné on n’obtient pas la même description du use case.

La question du niveau de détail vient donc avec une réflexion sur les points de vue qu’auront les divers acteurs du processus. Un modèle pour une audience donnée doit en illustrer les objectifs. Lorsque plusieurs audiences doivent être conciliées sur le même modèle, l’utilisation de diagrammes imbriqués (drilldown) pourra être faite. Naviguer d’un modèle à un autre reviendrait à passer d’objectifs aux sous-objectifs.

Voici quelques astuces de modélisation:
- Chaque activité doit produire un résultat de valeur pour la personne qui l’exécute. L’objectif de la tâche doit clairement être représenté dans le nom de cette activité.
- Au moins une activité par acteur/équipe/division/département impliqué dans le processus.
- Lorsqu’il y a plusieurs activités par acteur/équipe/division/département, se demander si elles ne peuvent pas être groupées si elles accomplissent le même objectif (se poser la question ‘pourquoi’).
- Lorsque le nom d’une fonction a deux verbes, se demander si elle ne pourrait pas être divisée en deux sous fonctions (sous-objectifs).

Les processus modélisés de façon trop complexe souffrent de plusieurs maux. D’une part, ils ne répondent pas aux attentes des lecteurs. Les objectifs business sont disséminées sous une masse d’autre information ce qui rend difficile la lecture du modèle  et obstrue la compréhension du processus. D’une autre part, le modèle nécessite de fréquentes mise à jour le rendant instable et plus coûteux en maintenance.

Il est donc naturel que le modélisateur doive parfois se poser la question: Dois-je inclure cette information dans mon diagramme?

Cette question n’a pas de solution générique. Un processus ne sera pas modélisé de la même façon selon le niveau d’abstraction souhaité ou encore selon la sensibilité de l’audience. Une information qui n’est pas hors scope (en dehors des bornes de notre processus), a certainement de la valeur pour quelqu’un mais en a-t-elle pour l’audience du modèle que vous réalisez? Est-ce que certaines classes d’informations à inclure ne se représenteraient pas mieux sous forme d’autres modèles distincts de celui du processus?

De nombreuses techniques de modélisations aident à répondre à ces problématiques:

• Définir les bornes du processus
• Manipuler la granularité de l’information
• Séparer les décisions des fonctions

Un article sera dédié pour chacun de ces concepts.

Le zoom est une technique séparant des modèles de granularité différentes. C’est le mécanisme utilisé pour passer d’un maillon de value chain à un processus ou d’une fonction de processus à un sous processus et ainsi de suite… Zoomer sur une activité apporte la réponse à la question ‘Comment cette activité est exécutée?’. Le zoom mène vers un modèle contenant un flux détaillant la fonction zoomée.  Inverser le mouvement de zoom revient à se poser la question ‘Pourquoi ce processus prend place et dans quel contexte?’. Rappelez-vous que vos modèles sont consultés par des lecteurs de perspectives bien différentes: certains voudront rester haut niveaux et ne découvrir que les principales actions de votre processus, d’autres seront intéressés aux plus petits détails exécutés par un acteur particulier. Pour satisfaire toutes ces classes de lecteurs il est nécessaire d’avoir différents niveaux de granularité et un mécanisme permettant de naviguer entre ces niveaux.

La première image de droite (source: ARIS community) illustre concrètement le mécanisme de zoom. La seconde fonction du processus est détaillée dans un sous processus sus forme de 3 nouvelles fonctions. Pur assurer une compréhension du sous-processus par le lecteur, les évènements entourant la fonction zoomée sont également reportés dans le sous processus en début et fin de flux.

En apparence l’interface pourrait s’apparenter au zoom: un clic nous fait passer d’un modèle à un autre. Bien que ces deux mécanismes soient physiquement identiques, ils sont conceptuellement très différents. Le zoom offre une navigation à travers des modèles de granularité différentes tandis que l’interface permet de naviguer entre des modèles de même granularité. Aussi toutes les fonctions décrites dans un modèle et ses sous-modèles (obtenus par zoom) appartiennent au même scope tandis que l’interface est une frontière du scope. L’interface permet de voyager d’un processus à un autre processus ou d’un sous-processus à un autre sous-processus de même niveau de granularité. Lorsque le but est de détailler une fonction d’un processus, le zoom devra être utilisé. Ainsi une interface ne doit être utilisée que comme point d’entré ou point terminal du modèle tandis qu’un zoom peut survenir à n’importe moment du processus.

La seconde image de droite (source: ARIS community) illustre ensemble les deux mécanismes. Le drilldown permet pour chacun des 3 maillons de la value chain d’accéder aux processus. Pour naviguer d’un processus à un autre des interfaces ont été créées (objets gris).