Joomla-Visites | Statistiques de fréquentation pour Joomla! Statistics

Skip to content

Vous naviguez ici :Accueil arrow Concepts arrow Articles « Technique » arrow BPMN et les processus d’exécution : Quand allons-nous apprendre ?
BPMN et les processus d’exécution : Quand allons-nous apprendre ? Version imprimable
28-07-2008


Un tour rapide sur les blogs et sur quelques articles récents nous donne un aperçu des discussions sur BPMN et à quoi il devrait servir. Il semble y avoir des discussions sans fin sur le pourquoi et le comment et sur la facilité, ou pas, de sa mise en œuvre.

Nous constatons actuellement que la question qui se pose est de savoir si BPMN est la bonne Notation/approche pour les analystes métier. Je pense qu’il est peut être temps de nous rappeler qui joue quel rôle dans une organisation, et ce qu’ils sont supposés lui apporter, après il sera toujours possible de réfléchir à quels outils et quelles notations sont les plus appropriés.

Je veux, dans cet article, esquisser un parallèle avec la Modélisation des données, un domaine qui est bien établi et où tout le monde a un rôle à jouer.
Au plus bas niveau, nous avons les administrateurs de base de données. Ils vivent dans le pays des « modèles physiques » et savent qu’ils ont à les ajuster, casser certaines règles et en ajouter d’autres, pour s’assurer que la base de données est aussi performante que possible.

Donc, du point vue du BPMS (Business Process Management System : application de gestion des Processus ) il y a un rôle précis d’administrateur BPM, quelqu’un qui serait familier avec le moteur d’exécution et qui saurait ajuster le «Modèle physique d’exécution» de telle manière qu’il fonctionne à son maximum.

Pour ce genre de personne, BPMN a du sens car c'est une notation très proche de la vision modéliser/coder/exécuter. J’estime que BPMN est la bonne approche pour ce type de personne.

Montons d’un niveau et nous avons notre analyste de données, ces personnes vivent dans le royaume des « modèles logiques ». Leurs informations proviennent des analystes métier et des analystes système. Ils étudient les problèmes métier et les besoins systèmes d’un point de vue « données ».

Il crée ensuite des modèles logiques à partir de modèles conceptuels. Ils savent que personne n’attend une mise en œuvre efficace d’une base de données à partir de leur modèle.

En effet, ça demande de travailler et d’adapter le modèle logique qu’ils ont créé pour créer un modèle physique optimal. Même s’ils utilisent Chen, Bachman ou UML comme notation, ça n’a aucune incidence pour les analystes métier ou les analystes système. Est-ce que BPMN peut être utilisé dans ce domaine ? Oui, probablement, et les analystes métier BPMS peuvent endosser ce rôle.

De nouveau, quelqu’un avec des connaissances particulières est indispensable pour s’assurer que le modèle est complet et cohérent. Il sera aidé par un outil de modélisation approprié avec des règles de modélisation (il est remarquable que, pendant plusieurs années, les analystes de données refusaient d’utiliser des outils qui les forçaient à avoir de la rigueur.

Le résultat ? Des centaines et des milliers d’heures humaines perdues dans la construction de modèles incohérents qui ne pouvaient pas être utilisés pour générer de bons modèles physiques et de bonnes bases de données).

Remontons encore pour trouver nos analystes système dont le rôle est de suivre les besoins métiers et de les traduire systématiquement en spécifications qui peuvent être mises en œuvre. Ce sont des personnes qui commencent à tenir compte des plateformes techniques, des logiciels et des normes de l’entreprise pour les bases de données etc.

Leur métier inclut le fait d’aider à la création et à la cohérence des systèmes qui permettront de résoudre les problèmes métiers identifiés.

Comme information en entrée, ils doivent recevoir les « modèles conceptuels de données » avant toutes choses. Mais nous savons que les modèles conceptuels ne sont qu’une collection de « machins » que le métier a estimé comme des données pertinentes avec des lignes qui indiquent qu’il y a une relation entre elles sans préciser de quel type elle est. Nous avons donc besoin d’un rôle identique pour notre monde du BPMS, un « analyste système BPMS ».

Enfin nous arrivons à l’analyste métier, son rôle est d’aider le métier à identifier et résoudre les problèmes métiers qui peuvent éventuellement demander des systèmes ou une automatisation.

Si vous pensez vraiment qu’on devrait les orienter vers un niveau de mise en œuvre inférieur, regarder le site de theiiba et lisez le paragraphe « Body of Knowledge ». Je viens juste de finir de revoir ce qui sera bientôt la version 2.0. Vous verrez que le business analyste en a déjà assez à apprendre. En effet, ils doivent acquérir beaucoup de nouvelles compétences pour être efficaces dans ce qu’ils font.

De mon point de vue, la dernière chose qu’ils pensent devoir apprendre c'est une nouvelle notation de bas niveau car les personnes de l’informatique ont trouvé ça trop dur d’apprendre le langage métier.

Donc si on veut avoir une discussion efficace à propos de la modélisation et des notations des processus métier, je suggère d’en parler avec de vrais business analyste pour voir quel genre d’approche « conceptuelle » simple leur semble la plus adaptée.

Ensuite, il sera possible d’étudier la meilleure manière de créer des modèles « logiques » pour nos analystes systèmes et au final, on pourra permettre aux administrateurs BPMS de jouer jusqu'à plus faim avec la notation BPMN qui a été créée pour eux et pour ceux qui s’y sentent à l’aise.

Un autre groupe de personnes dont nous n’avons pas encore parlé, les « architectes », un groupe qui est apparu brusquement et qui grossit de plus en plus que ce soit dans le domaine des applications, des logiciels ou de l’entreprise. La plupart ne semblent exister que sous la protection du DSI. La place de « responsable architecture métier d’Entreprise » est déjà occupée par le DG.

Contrairement à ce que m'a récemment dit un des architectes seniors qui a sous-entendu que j’étais trop « ancienne école » et, que je devais m’habituer à ce que les processus soient tous automatisés et que le métier se fera aussi bien sans les individus, que le modèle économique du 21e me siècle était : l’architecture d’entreprise, l’architecture métier (en utilisant MDA), les modèles de processus métier (avec BPMN), l’automatisation de processus.

Ce sont les individus qui utilisent le système, qui sont propriétaires et qui font leur métier et ce sont donc les individus qui doivent être aidés par le système. Donc une discussion plus poussée avec les personnes permettra de découvrir leurs problèmes et rendra plus facile l’obtention de budget et de ressources pour construire et mettre en œuvre un système.

Si cette façon de penser me rend «ancienne école » alors je le suis, mais si nous croyons vraiment que nous allons vers un monde uniquement composé d’exécution de processus sans intervention humaine alors c’est un triste jour pour le genre humain (d’intéressant problèmes et questions en termes de gestion du changement sont à prévoir également).

Bien sur ce n’est que mon opinion et je suis sur que beaucoup ne seront pas d’accord avec moi, c’est pour eux que j’ai choisi d’écrire, s’il vous plait ne m’écrivez pas pour me parler des origines et du but de BPMN, j’étais à la réunion d’origine ou l’idée a été pour la première fois évoquée par deux personnes, deux éditeurs autour d’une BIère à Londres, il y a quelques années.

Je comprends tout à fait pourquoi BPMN a été créé et j’accepte aussi que les choses aient changé depuis.


Mark McGregor
Source : Mark McGregor's - Process Performance Blog


Vous souhaitez partager cet article :

FacebookLinkedinViadeoTwitter
 
< Précédent   Suivant >
[ Retour ]

Les choix de BPMS

Recevez notre newsletter