BPM/Urbanisation du SI : faut-il modéliser l’existant ?

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.

À propos de Hicham AIT BASLAM

Une expérience de 16 ans, passée dans le conseil et le management de grands projets complexes à dimension internationale impliquant des équipes pluridisciplinaires et hétérogènes culturellement, à traiter de problématique d’intégration (FrontOffice, BackOffice) et d’architecture SI, d’alignement du SI sur la stratégie de l’entreprise, d’amélioration continue de la qualité, des process de delivery et la performance des équipes. Elle est constituée sur le terrain par la direction de nombreux centres de delivery et programmes de la phase amont jusqu’à la réalisation et livraison, marquée aussi par la Transformation et Refonte de plusieurs SI Stratégique, par le redressement de projets informatiques en difficultés, Business développement de plusieurs SSII, développement de nouvelles offres sur le marché. Toutes ces expériences m’ont permis d’avoir une vision générale des systèmes d’information éclairés sous différents angles et sur les solutions globales à haute valeur ajoutée. Mon expérience, en tant que directeur de projet, manager « évangéliste » de l’agilité, et compte tenu de ma croyance profonde dans les valeurs de l’agilité pour les petites, moyennes ou grandes organisations, m’a conduit à travers la France et l’Afrique. J’ai eu suffisamment de chance pour être impliqué dans de vraies mutations organisationnelles et transformation SI basées sur les disciplines et les pratiques du manifeste Agile et l’approche DevOps. Aujourd’hui, je me positionne dans le management de business unit, centre de delivery, la direction des projets à fort dimension (Internationale, Managériale, Business, Technologique), je me consacre entièrement à accompagner de grands comptes à réussir la transformation de leur SI, la transition vers l’agilité et à la traduction de la vision stratégique en résultat.

Publié le 22/10/2009, dans Architecture SOA, Urbanisation, et tagué . Bookmarquez ce permalien. Poster un commentaire.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :