Migration à iso fonctionnalités ou saut technologique et fonctionnel

Toutes les applications métiers ne sont pas logées à la même enseigne, chaque système d’information est différent, ne serait ce que d’un point de vue urbanisation du SI. Cependant il est un point commun à bon nombre d’applications métier : la migration. Celle ci peut se faire selon deux directions, qui n’engendrent pas les mêmes coûts et n’ont pas les mêmes délais.

Quelques définitions

Migration : Processus organisationnel permettant de transférer une application métier depuis un environnement technique (généralement ancienne technologie) vers un autre environnement technique (généralement nouvelle technologie). Le résultat attendu d’une migration est de disposer d’une application ayant la même couverture fonctionnelle que le système de départ, mais à un moindre coût de maintenance correctrice ou évolutive. Aujourd’hui, avec l’Internet et l’architecture N-tiers, c’est également les bénéfices de l’aspect client serveur universel qui sont attendus.

Périmètre fonctionnel constant : Une application métier est l’expression informatique, informatisée d’un métier. Celui ci évolue de par les règles propres du métier, voire les lois, règlements et autres directives touchant une profession. Pour des raisons de cadre contractuel, de gestion de projet et de périmètre fonctionnel, il est nécessaire, à un moment donné de la relation entre le client et l’équipe en charge de réaliser la migration, de définir et de figer le périmètre fonctionnel du SI initial pour qu’il permette de comparer le système initial au système livré en ordre de marche .

Migration et périmètre : la contrainte

Dès lors que la migration nécessite de figer une application fonctionnelle qui tends à évoluer, il y a une forte contrainte temps à gérer.

• D’une part la contrainte temps liée à l’ancien système sur lequel les évolutions de périmètre ont du être ralenties en vue de la venue du futur système cible.
• D’autre part la contrainte temps liée à la conception, réalisation, livraison, acceptation du futur système. Plus cette étape est longue, plus le SI prend du retard fonctionnel.

Enfin les évolutions qui n’ont pu être faites sur le système initial, peuvent être prises en compte dans le système cible, mais il y a de forte chances que celles ci ne soient intégrées au nouvel SI dans une ultime étape d’évolutions fonctionnelles.

Si ces évolution n’étaient pas prévues dans le cadre contractuel initial, il faut alors envisager des coûts supplémentaires et forcement des délais.

La Migration technique et fonctionnelle

Autre voie qu’il est possible d’envisager comme une alternative à la précédente : la migration technique mais qui prendrait en compte les évolutions fonctionnelles non présentes dans le SI initial, mais envisagées. Nous pouvons également ajouter les évolutions fonctionnelles permises par le changement de technologies, bien que celles ci doivent être rares, elles sont généralement liées à l’ergonomie et l’optimisation du poste de travail que peuvent apporter les nouvelles technologies.

Cette dernière voie ne semble pas être pratiquée sur le terrain, en effet elle ne permet pas une recette applicative facile (la cible est mouvante), il n’est pas aisé de distinguer la part due au changement technologique de la part du au changement fonctionnel. Cette voie semble sur le papier du moins, moins coûteuse en temps mais nécessite une excellente maîtrise du SI