Lorsqu’on entre dans une démarche de modélisation de processus métier, il y a 3 écueils fréquents qu’il faut absolument éviter.

Traditionnellement et encore en majorité aujourd’hui, c’est l’IT qui initie les démarches de modélisation car l’intérêt dans la refonte d’un SI est évident. Le chef de projet SI réalise que l’un des meilleurs moyens de capturer le besoin métier est encore de décrire le métier et il supporte naturellement l’initiative processus.

Si, dans une entreprise dont la maturité processus est balbutiante peu d’écueils seront rencontrés, lorsque cette même organisation progresse et donne de l’ampleur à la démarche processus les risques apparaissent de créer des distorsions dans le projet processus qui vont produire des effets non-recherchés et donc coûteux.

Ainsi, après qu’un noyau de personnes ai été sensibilisé à l’approche processus, l’entreprise sera peut-être tentée par un déploiement au niveau d’une sous-branche de la même approche pour l’ensemble des raisons possibles qu’une entreprise a de mettre en place une telle démarche mais très vite voici les 3 caractéristiques qu’il faudra garder en tête :

- le coût

- l’intégrité du référentiel

- l’adéquation de la modélisation et de l’objectif poursuivi

1- Coût

Mon référentiel coûte-t-il trop cher à développer ou à entretenir ? Voici la question que fini par se poser une organisation ayant entamé cette démarche. Même en cas de gains évident apportés par l’approche processus, une organisation se pose naturellement la question du coût de maintien.

Ce coût peut être impacté par 2 éléments : le coût logiciel et bien sûr le coût en main d’oeuvre.

Je ferais ici le parallèle avec la bourse. En bourse il est connu que pour vraiment connaitre la performance d’un portefeuille, il faut regarder sur une longue, très longue période qui permet d’avoir un point de vue objectif car les gains d’aujourd’hui sont souvent effacés par les pertes de demain ce qui produit, in fine, un résultat très moyen pour un gestionnaire lambda.

Avec l’ensemble des coûts processus, le risque est souvent situé aux moments charnières : ces moments où l’on risque de remettre en cause des décisions par exemple : le changement de l’outil de modélisation ou encore le changement de méthode. Si l’on aimerait que cela n’arrive pas, la réalité nous rappelle que ces évènements arrivent tôt ou tard et c’est en ayant les bonnes personnes à bord qu’il est possible de limiter le coût de telles opérations, voir évidemment de les prévenir.

2- Intégrité du référentiel

L’intégrité est définie par la cohérence entre un modèle de niveau x et un autre modéle de niveau x. Autrement dit, mon référentiel est-il de qualité, est-il homogène ? Le coût de la non-qualité est ici aussi sournois mais bien réel. Que faire d’un référentiel dont la qualité n’est pas égale ? Si faire le travail une fois représente un coût non-négligeable, le refaire est évidemment un gaspillage regrettable.

Pour tirer parti du référentiel et s’assurer qu’il reste la pièce maitresse en laquelle les responsables de processus ont confiance, il faut en assurer l’intégrité par des règles (vérifiées manuellement ou automatiquement) précises et comprises.

3- Adéquation de la modélisation aux objectifs poursuivis

Enfin, ces règles doivent être adaptées aux objectifs. Si une organisation est entièrement modélisée avec la même approche, c’est probablement que la méthode n’a pas été adaptée aux objectifs de chaque entité/direction et qu’un nombre important d’heures ont été mal utilisées.Il convient souvent de mettre en place un projet processus dans le projet.

La modélisation dont le seul but est de documenter reste marginale car ses bénéfices, sur l’ensemble d’une organisation, sont difficiles à évaluer. L’amélioration opérationnelle reste à privilégier et ses objectifs sont différents selon le contexte : la méthode doit prendre ceci en compte.

Comme le disait Darwin, ce n’est pas le plus fort qui survit, mais celui capable de s’adapter !

Popularity: 16% [?]

Il y a 2 grandes fonctions d’encadrement et de support qui me passionnent particulièrement et dont je parle dans ce blog : l’urbanisation du système d’information et l’approche processus.

Il est intéressant de voir que chaque entreprise possède sa propre manière de combiner ces 2 fonctions.

L’urbanisation du système d’information s’attache à définir, mettre à jour et faire respecter les choix de structuration du système d’information. Ainsi, les équipes d’urbanistes interviennent dans les projets liés au système d’information pour contraindre au respect des éléments définis mais aussi pour apporter de l’aide sur l’intégration au reste du système d’information. Bien entendu, la plupart du temps ce rôle sera vécu comme une contrainte par les équipes projets. Pour un urbaniste, tout est système.

L’approche processus consiste à modéliser, analyser et organiser l’entreprise sous forme de processus. Bien moins contraignant qu’il n’y parait, cette approche est le saint graal de bien des services/départements car elle rend l’activité régulière, compréhensible et prévisible. Pour un business analyst, tout est processus.

Ces 2 approches ont pour objectif commun d’apporter de la valeur à l’entreprise (avec valeur signifiant quelque chose pour le métier : time to market, taux de défaillance…) et d’en simplifier le pilotage (moins d’applications, moins d’interlocuteur, moins d’intervention humaine redondante) et c’est pour cela que l’urbanisation du SI et l’approche processus s’accordent particulièrement bien. Cela consiste à définir les processus des « systèmes de l’organisation ».

Alors, comment faire travailler harmonieusement ces 2 cellules ensemble et avec le reste de l’entreprise ?

Organisation

Dans une organisation orientée projet, chaque projet devrait être dirigé par un chef de projet dont le cadre de travail découle de l’entente entre l’urbaniste (SI) et le business analyst (métier). Si le métier évolue, il est analysé par les business analyst qui déterminent le processus métier à mettre en place/modifier (QUOI / POURQUOI).

L’urbaniste intervient dans la concrétisation du projet et son intégration pratique avec l’existant (COMMENT). Pour moi, il joue aussi le rôle d’architecte d’entreprise. Il n’est pas seulement plongé sur les interfaces SI entre applications mais aussi sur l’implication métier de ses choix.

Tout projet faisant intervenir une modification du système d’information doit impliquer l’urbaniste et son acolyte le business analyst pour qu’ils définissent les conditions et le contexte futur de fonctionnement.

Métier

La fonction de l’urbaniste et du business analyst pourrait se résumé à « Traduire les objectifs stratégiques en actions concrètes dans les projets ». Ces rôles devraient donc être permanent dans l’entreprise – ils ne naissent pas avec un projet et meurent à la fin avec lui.

Je recommande vraiment d’avoir 2 personnes qui se comprennent et qui s’entendent bien.

Je ne pense pas qu’avoir une expérience dans le métier même de l’entreprise soit important : prenez un fabricant de meuble, une expérience opérationnelle dans le métier n’est absolument pas une garantie que le business analyst comprendra mieux le métier. Je pense qu’il veut mieux regarder du côté de la capacité/volonté d’apprendre et de comprendre le véritable métier. L’idéal étant d’avoir identifié un référent métier (le futur propriétaire du processus « business process owner ») qui sera en mesure d’expliquer l’histoire du métier dans l’entreprise.

Personnes

Il est évident qu’il faut les « bonnes » personnes dans chacune des fonctions. Il y a des caractéristiques essentielles qu’il faudra retrouver :

• capacité à manipuler des concepts abstraits
• capacité à communiquer (informer, discuter et convaincre)
• capacité à naviguer dans l’organisation et à comprendre le « véritable » métier (être aussi à l’aise avec le DSI qu’avec un conseiller client et pourvoir apporter à chaque fois des réponses adaptées aux inquiétudes des gens)

La plupart du temps, il n’est pas nécessaire d’avoir de grosses équipes pour occuper ces rôles. Parfois, une seule et même personne peut jouer l’urbaniste et le business analyst dans le cadre d’un projet. C’est quelque chose qui ne me choque pas et pour les raisons que j’ai évoqué, c’est assez naturel.

L’urbanisation du SI devrait donc être une activité permanente et son pendant métier, le business analyst, également. Ces 2 rôles ont une capacité qui devient de plus en plus importante dans les entreprises : celle de rendre simple et compréhensible une organisation en un mot « lisible ». Ils rencontreront des difficultés pour s’intégrer aux projets si la nouvelle donne n’est pas imposée. On préfèrera ainsi avoir le business analyst qui travaille « en parallèle » du projet mais ce type de choix ne donnera pratiquement aucun résultat concret (confirmant ainsi par la même occasion que la plupart des projets SI échouent…).

Vers un meilleur résultat des projets de changement des organisations !

Popularity: 35% [?]