Vous connaissez peut-être le principe de Peter. En résumé, c’est un principe qui dit que chaque personne tend à s’élever jusqu’au poste où elle est incompétente. L’une des variations de ce principe s’appelle l’incompétence par l’informatique et dit que :

• quelqu’un d’incompétent ne deviendra pas compétent si on lui colle un ordinateur,
• quelqu’un de compétent peut devenir incompétent avec un ordinateur.

Au delà du clin d’œil et pour revenir au sujet, l’ordinateur ou l’outil de modélisation ne fera qu’amplifier vos choix, fussent-ils bons ou mauvais. C’est pourquoi, le périmètre d’un projet processus ou d’urbanisation du SI est aussi important que la méthode qui sera utilisée pour décrire ces éléments dans le référentiel : il cadre le projet.

L’un des premières et inévitables questions concernera l’existant, le patrimoine (legacy) : faut-il le modéliser ? Faut-il capturer son fonctionnement, son essence ?

Il n’y a pas de réponse universelle car la question est trop générale.

Les mauvaises raisons pour modéliser l’existant

• Créer une documentation (temps passé*taux d’utilisation de la documentation = quelque chose proche de 0)
• Comprendre l’existant (question trop vague, particulièrement côté IT)
• Démontrer la capacité de l’outil (c’est l’éditeur qui sera content)
• Démontrer l’intelligence de l’équipe de modélisation (c’est le consultant qui sera content)

N’essayez pas de faire bouillir l’océan !

Les bonnes raisons pour modéliser l’existant

• Trouver une réponse à une question précise (confirmer/infirmer une hypothèse de la roadmap)
• Préparer un changement sur un périmètre défini
• Trouver un problème dans un domaine précis (diagnostique)

Savoir pourquoi on le fait

Le fait de disposer d’un patrimoine ne signifie absolument pas qu’il doit être modélisé. Il n’y a donc aucun impératif naturel à modéliser l’existant dans le seul but d’immortaliser son existence !

Comme pour n’importe quel projet de modélisation, sans objectif vous êtes condamné à modéliser trop en détail ou trop peu tout ceci pendant trop de temps. Si vous ne savez pas pourquoi vous le faites, vous ne saurez pas quand vous arrêter.

Un tel projet peu être catastrophique : dépense d’énergie et de ressources importantes, perte d’intérêt voir défiance envers le fait même de modéliser.

Il faut donc savoir pourquoi on le fait. Il y a de bonnes chances qu’un tel projet soit lancé pour apporter des réponses nécessaires à quelqu’un dans l’entreprise. Trouvez-le !

Être méthodique

Partir sur de bonnes bases est essentiel. Si un projet démarre sur de mauvaises suppositions, tous les modèles vont être influencés par ces suppositions.

Définissez ce que vous cherchez

Partant de la question de départ, il y a généralement 2 possibilités :

1. la réponse n’est pas identifiée
2. il y a une début de réponse mais elle est si incertaine ou imprécise que l’information n’est pas utile

Se laisser du temps

La modélisation en général est un travail itératif : la bonne réponse n’arrive que très rarement dès la première fois. La modélisation de l’existant l’est tout autant et le fait de s’attaquer à quelque chose d’existant ne facilite par le travail de modélisation pour une raison simple : la réalité est souvent beaucoup plus complexe que ce que l’on aurait décrit dans un modèle cible (donc n’ayant pas encore de réalité). La réalité n’apparaît jamais en une seule fois dès le premier modèle.

La modélisation de l’existant crée une charge supplémentaire qu’il ne faut pas négliger : celle de la mise à jour.  Chaque modèle devra être surveillé par un responsable afin d’être certain que le modèle décrit toujours la réalité. Un modèle dépassé perd beaucoup de sa valeur (voir toute sa valeur).

En clair, si vous voulez définir un To Be (votre cible), il est préférable d’avoir un As Is (existant) pour mesurer la différence et surtout pourvoir l’expliquer aux équipes qui exécutent le processus : « Qu’est-ce qui va changer ? ».

Cela permet aussi d’affiner ses réponses concernant la faisabilité de l’objectif et la probabilité de l’atteindre.

Modéliser l’existant est donc parfois nécessaire. N’ignorez pas la charge implicite que cela amène sur les épaules des responsables de processus.

Popularity: 9% [?]

En relisant mon article premier du nom sur cette question je me suis rendu compte d’une chose terrible : je n’avais pas parlé du client !

Voici un complément de description.

Qui est le client du BPM ? En règle générale, c’est l’entreprise elle-même.

Si les processus interne sont améliorés et que les collaborateurs sont plus disponibles pour les clients, ceux-ci seront plus heureux et l’entreprise améliorera ses chiffres. Voilà le principe sous-jacent (simplifié).

La philosophie du Business Process Management consiste donc à améliorer le fonctionnement de l’entreprise.

Une fois ceci dit, tout reste à faire.

Le BPM a un gros problème : sa valeur chiffrée est parfois impossible à définir et un projet mal cadré/géré peut rapidement rappeler les jours sombres de l’informatique où l’entreprise investie pour obtenir un ROI négatif (les projets ERP sont réputés pour ça!).

Les projets dont le résultat est directement visible sont généralement ceux où un problème opérationnel existe. Ce n’est peut être pas très « sexy » mais en remettant de l’ordre dans un processus malade, vous produisez un résultat direct pour l’entreprise – à supposé que le processus apporte quelque chose à l’entreprise. Le procesus sera donc efficace encore faut-il qu’il soit efficient.

Le deuxième domaine où le BPM produit des effets indiscutables est lorsque de l’automatisation est effectuée. Moins d’interventions humaines = moins d’erreurs et des coûts plus faibles. Une démarche BPM aide à savoir quoi automatiser et à bien l’intégrer aux autres processus, ceux avant et ceux après.

Le dernier domaine qui permet de profiter du BPM, ce sont les projets de refonte du SI. Dans ces projets, le risque de dérapage est important et la conséquence (financière) peut-être très importante. Le BPM permet de cadrer les projets SI en amenant le besoin du client de manière limpide. C’est donc autant un travail d’AMOA que de gestion du changement.

Faut-il faire du BPM si vous n’êtes pas dans l’une de ces 3 situations ? Ma réponse est que si vous n’êtes pas dans l’une de ces 3 situations vous avez de la chance ! Je parie que ça n’est pas le cas.

Si malgré tout vous décrivez vos processus sans but opérationnel, vous obtiendrez de belles procédures de travail qui n’apporteront pas grand chose à votre entreprise et remettre au goût du jour cette blague de consultant : « En moyenne combien de temps dure un projet BPM ? 2,5 DSI. »

Je pourrais donc définir le BPM par ceci :

Décrire le fonctionnement de l’entreprise en détaillant les tâches, rôles, données et règles de gestion nécessaires à son fonctionnement dans le contexte d’une amélioration opérationnelle.

Popularity: 4% [?]