Comme dit précédemment, je vais découper les processus en plusieurs pool.
Du haut vers le bas, des grandes fonctionnalités vers les plus petites.
La couche d'implémentation sera décrite dans d'autres processus, j'utiliserais ces processus comme service - ça c'est pas gagné :-) -.
Découper les processus apportent plusieurs avantages :
- Une meilleure lisibilité.
- Une maintenance simplifiée
En terme de lisibilité, il est important de penser à ceux qui devront lire mon processus.
Si j'utilise un seul énorme process mon collègue n'aura pas de soucis à décrypter les appels, les boucles, les API, les différents messages et les variables ...Mais mon DG non, il va jeter un coup d'œil éffaré, me dire que c'est un truc d'informaticien, va refermer la page en me disant qu'il me fait confiance tout en pensant que je ne suis pas capable de montrer quelque chose de clair.
Et les directeurs des différents services pareil et les utilisateurs pareil.
Il faut bien que je le fasse valider quand même ce processus !
Je dois donc découper mon processus pour m'adresser à chacun.
En terme de maintenance les actions sont courtes, le serveur les nommera par le nom de la pool dans laquelle elles sont décrites, on saura donc de suite ou est l'erreur et la couche d'implémentation étant décrite comme un service toute la technique (API,BD ...) est géré et modifié en dehors du process principal.
Voila ce que cela donne.
C'est la vue que je vais présenter à mon DG, c'est clair, concis, quelques annotations, c'est la vue d'ensemble du processus.
Voyons la vue pour saisie des infos compta:
C'est la vue que je vais présenter au directeur du service compta et à l'utilisateur . Chaque tache est clairement et simplement identifié.
Voyons maintenant le détail de vérif info et saisie.
Chaque process est validé par l'utilisateur, on appelle les infos de l'ERP, s'il manque des infos on les créés ici même, et on continue la saisie. C'est la couche fonctionnelle et on cache la technique un peu rebutante à l'utilisateur dans un subprocess.
Terminons par le subprocess.
Il y aura encore un pool d'interface pour les appels au service.
Voila, je rappelle que je n'ai aucune expérience en BPM, je ne fais que décrire ce qui me sempble être le plus judicieux. Si quelqu'un a une autre approche, je suis preneur.
A lire sur le site d'Intalio :
bpms, best practices
