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% [?]

Le défaut de l’ingénieur et en particulier du développeur est plus répandu qu’on le souhaiterait. Mais en fait, lorsque je dis LE défaut, il conviendrait de dire LES défauts.

Parmi les écueils les plus courants, on trouve le fait de vouloir réaliser une fonction pour le défi technologique qu’elle représente et non pas pour répondre au besoin ou encore le fait de penser à son CV avant de répondre à la problématique.

Tout ceci est classique. Si vous êtes architecte logiciel, vous le savez déjà et si vous êtes chef d’équipe ou client vous le savez encore mieux

Je suis tombé sur un livre qui recense tous ces défauts. Plus qu’une collection, c’est un inventaire que je trouve exhaustif (pensez bien qu’il y a tout de même 97 défauts!) qui permettra de mieux comprendre les architectes logiciels.

Le livre est disponible sur Amazon mais il est possible de consulter gratuitement le Wiki sur lequel se trouvent une partie du contenu dont voici un extrait :

We often design over-engineered applications as a result of blindly pleasing customers to the greatest extent. We are so distracted by the details of the solutions that we offer, that we sometimes fail to see that we end up solving the wrong problems in the first place.

So here is a little suggestion: don’t just translate customer requirements into code, but strive to be a wise interpreter. In other words: design for needs, not wants.

You should challenge requirement definitions as, almost invariably, customers poorly define and understand their own actual needs.

All too often, they say they want a longer antenna when, in fact, they need a better reception. You should ask simple questions such as « why do you want this feature? » and « what is its benefit? » and you should keep inquiring until you obtain an adequate answer.

Once you have identified the underlying needs, you have the opportunity to look for alternative solutions. Don’t stop at the first good idea and don’t blindly trust your first instincts. As the French philosopher Alain (Émile Chartier) once said: « Nothing is more dangerous than an idea when it’s the only one you have. » Deliberately ask questions such as « this is a way of doing what? » and « how else can this be achieved? »

Incidentally, this is your best chance to reduce complexity in your applications: right at the source, where it matters most. Simple and elegant solutions are often incredibly hard to find and may not be there at all. But do not to give up too quickly, as you may miss tremendous opportunities.

by Claudio Perrone

Vous trouverez aussi des citations de nombreux professionnels :

• Don’t Put Your Resume Ahead of the Requirements (Nitin Borwankar)
• Chances Are, Your Biggest Problem Isn’t Technical (Mark Ramm)
• Communication Is King; Clarity and Leadership, Its Humble Servants (Mark Richards)
• Simplicity Before Generality, Use Before Reuse (Kevlin Henney)
• For the End User, the Interface Is the System (Vinayak Hegde)
• It’s Never Too Early to Think About Performance (Rebecca Parsons)

Si vous connaissez un architecte logiciel ou un développeur ce livre doit être en bonne place dans votre prochaine commande !

Si je parle de ceci sur un blog à priori dédié à la modélisation des processus métier et à l’urbanisation du SI, c’est que je pense que les business analyst et les urbanistes du SI ont de nombreux défauts en commun avec les développeurs… et je sais de quoi je parle !

Pour le commander :

Popularity: 4% [?]