urbanisation-si.com

Comment bien cibler les destinataires d'une modélisation de processus métier pour ne pas ennuyer la MOA avec des diagrammes complexes et la MOE avec des diagramme innapropriés ?

Imaginons un instant que l'on veuille automatiser le processus de gestion d'anomalies de notre éditeur de logiciels ( voir les 2 articles précédents BPMN : processus exécutables, comment s'y prendre ? (1/3) et BPMN : processus exécutables, comment s'y prendre ? (2/3) ), nous devons décider quelles sont les parties à exécuter dans le moteur de processus et celles par des humains.

Le chargé de clientèle (account manager) ne doit pas s'occuper de remplir des formulaires, il doit juste envoyer un mail dans le cas ou un client rencontre une anomalie et il en reçoit un quand le processus est complètement réalisé.

Même chose pour le développeur.

Dans le cas ou le support 2ème niveau est assis non loin du développeur, le plus efficient est qu'il se déplace pour demander au développeur ou en est la résolution du problème plutôt que des aller retours de mail avec affectation de tâches.

Cette partie de la geston d'incidents reste donc manuelle, la collaboration entre le support de 2ème niveau et le développeur n'est pas du tout intégrée dans le moteur de processus exécutable.

Par contre le système crée un ticket au support 1^er et 2 ème niveau, ce système géré par le moteur de processus ( rôle ou acteur ) est modélisé par un « pool » dédié.

Ce système reçoit et analyse les mails envoyés par le chargé de clientèle et crée un ticket.

Si le support 1^er niveau décide que le ticket est destiné au support 2ème niveau, il remplit le formulaire du ticket et notamment la partie concernant la description du problème.

Le système de gestion de ticket redirige le ticket dans la corbeille de tâches du support 2ème niveau.

Quand l'anomalie est résolue ou la nouvelle fonctionnalité réalisée, le support 2ème niveau indique que sa tâche est terminée pour la prochaine release (version) du logiciel.

Le système de gestion de ticket appelle le service du système de gestion de fonctionnalité (product backlog).

Le moteur de processus exécutable a intégré une nouvelle fonctionnalité sans aucune intervention manuelle.

A la fin, le système de gestion de ticket envoie un mail au chargé de clientèle avec la description du traitement de la résolution de l'anomalie et ferme le ticket.

Le chargé de clientèle peut expliquer la solution au client en se basant sur les informations du ticket.

Cette manière de modéliser ensemble la gestion manuelle et automatisée dans un unique diagramme est juste un exemple donnant une bonne idée de l'approche basée sur le diagramme de collaboration.

Cela démontre que BPMN intègre l'alignement du métier et du ystème d'information dans le processus de modélisation.

On peut implémenter la modélisation de la partie automatisé par un moteur de processu exécutable (comme jBPM ou Bonitasoft) et montrer la modélisation de la partie manuelle aux différents participants, les supports 1^er et 2ème niveau et chargé de clientèle.

On peut ainsi étudier avec eux les évolutions et améliorations du processus métier.

La différenciation entre les 2 modèles permet par exemple de bien cibler les destinataires, de ne pas ennuyer la MOA avec des diagrammes complexes et la MOE avec des diagramme innapropriés.

Rhona Maxwel

@rhona_helena

« On voudrait bien s'adorer jusqu'à la tombe, mais des événements viennent défaire les voeux, déraciner les promesse, abîmer l'espérance. On achète, dans l'amour qui naît, un futur qui ne veut jamais exister. »

Yann Moix

Articles conseillés :

BPMN : processus exécutables, comment s'y prendre ? (1/3)

BPMN : processus exécutables, comment s'y prendre ? (2/3)

Tutoriel jBPM : étude de cas avec human task (partie 2/10)

BPMN : mais que dit la norme sur les sous-processus et la gestion des événements d'interruption et de remontée d'incidents ?

BPMN : la norme, toute la norme rien que la norme. L'exemple à lire en attendant une pizza.