Souscrire
Toutes les définitions du business process (processus métier) s’accordent à dire qu’il s’agit d’une séquence d’activités produisant de la valeur. C’est une définition en apparence simple qui s’avère beaucoup plus difficile à mettre en pratique lorsqu’on en arrive à la phase de modélisation.
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.
- documenter les work instructions augmente la complexité des diagrammes sans y apporter de la valeur. Nous apprécions juste les work instructions pour mieux réaliser ce que le end user fait concretement et cela ne nécessite pas des boites et des flêches, un document word est mieux adapté.
- l’expérience Orange nous a démontré que nos end-users préfèrent une documentation textuelle plutot que des diagrammes. Tout le monde dans l’organization ne réfléchi pas ‘process’.
Quel est le bon niveau de granularité?
C’est une question assez difficile et théoriquement je n’ai pas encore vue d’explication qui tienne la route.
Mettons de coté les VACD et parlons uniquement des processus par fonction.
Il faut revenir aux bases et se rappeller qu’est ce qu’un business process et quel objectif le processus essaie d’atteindre pour QUI. Cet objectif principal sera le nom du processus. Ses fonctions seront les sous-objectifs du processus.
Les sous-objectifs sont les principales fonctions permettant de réaliser l’objectif.
On sert de deux questions pour monter ou descendre le niveau de granularité et ça marche comme pour les requirements:
Pourquoi?: nous améne vers l’objectif
Comment?: nous améve vers les sous objectifs puis vers les work instructions
Un outil à utiliser pour le faire pourrait être le use case. Je pense que en règle générale le niveau de détail du use case (user-goal) est le bon pour le processus.
Sur l’intranet j’ai mis quelques idées sur la fiche des use cases: http://technical.intranet.orange.ch/ts_bus_arch/organization-view/bpa/practices/requirement-engineering/requirement-development/requirement-types/stakeholder-requirements/use-cases/use-cases-definition
et ici aussi: http://technical.intranet.orange.ch/ts_bus_arch/organization-view/bpa/practices/requirement-engineering/requirement-development/requirement-types/stakeholder-requirements/use-cases/use-cases-writting
Quelques astuces:
- Chaque fonction doit vraiment réaliser un outcome valuable pour la personne qui l’execute. L’objectif de la fonction doit clairement être représenté dans cette fonction.
- Au moins une fonction par acteur/équipe/divition/département.
- Lorsqu’il y a plusieurs fonctions par acteur/équipe/disivion/departement, se demander si elles ne peuvent pas être groupées si elles accompllissent le même objectif (se poser la question ‘pourquoi’).
- Lorsque le nom d’une fonction a deux verbes (interdit d’ailleurs), se demander si elle ne pourrait pas être divisée en deux sous fonctions (sous-objectifs).
Exemple:
Si tu as la séquence suivante faite par Finance:
‘Ouvrir un fichier’ -> ‘Copier des lignes’ -> ‘Coller les lignes plus bas’ -> ‘Enregister le fichier’ -> ‘Attacher le fichier à un email’ -> ‘Envoyer un email à toto’
Ce sont des work instructions qui réalisent un unique objectif qui est ‘Gérer la donnée X’ se découpant en deux sous objectifs ‘Mettre à jour la donnée X’ et ‘Informer le owner des changements’.
J’arrive à cela en faisant l’exercice suivant:
Pourquoi Ouvrir le fichier? -> Mettre à jour la donnée X
Pourquoi Copier les lignes? -> Mettre à jour la donnée X
Pourquoi Coller les lignes plus haut? -> Mettre à jour la donnée X
Pourquoi Enregistrer le fichier? -> Mettre à jour la donnée X
Pourquoi Enregistrer le fichier? -> Mettre à jour la donnée X
Pourquoi Attacher le fichier à un email? -> Informer le owner des changements
Pourquoi Envoyer un email à toto? -> Informer le owner des changements
Pourquoi Mettre à jour la donnée X? -> Gérer la donnée X
Pourquoi Informer le owner des changements? -> Gérer la donnée X
« Gérer la donnée » est le processus pour la division Finance.
Ce processus peut aussi très bien être un sous-objectif d’un processus plus grand qui traverse plusieurs division de l’entreprise et c’est à ce moment qu’on parle de VACD.
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).
