Duquesne Group Duquesne Group

English version
Recherche et Analyse

Pour éclairer les décideurs dans le domaine de la Continuité d'Activité et de la Sécurité de l'Information, Duquesne Group propose ses analyses et réflexions issues de ses réalisations concrètes en clientèle. Observation critique du terrain par nos experts, contacts permanents avec les principaux acteurs du domaine et expérience vécue dans nos missions de conseil sont nos principales sources. Contactez-nous pour en savoir +
French version
Research

To support decision makers in the management and optimisation of information systems, Duquesne Group delivers in-depth analyses of information technologies, their implementations and their markets. Our research is based on critical observation of the market by our analysts and their on-going contacts with the vendor community, together with hands-on, practical experience from our consulting work. Contact us to find out more


Grands projets = grands problèmes ?

Les refontes d'applicatif importantes sont elles vouées à l'échec ?


La presse rapporte régulièrement des difficultés graves dans des projets importants de refonte d’applicatifs autour d’un progiciel du commerce. Nous constatons nous-mêmes dans nos missions des situations difficiles qui peuvent devenir graves si l’on n’y remédie pas. De quoi s’agit-il au juste et que peut-on prévenir ?



Grands projets = grands problèmes ?
Des projets au coeur de l'entreprise

D’abord, il faut noter que ces projets en difficulté sont fondamentaux pour l’entreprise : ils consistent à mettre en place un grand applicatif inconnu des utilisateurs pour remplacer une multitude de petites applications bien connues et maîtrisées mais jugées obsolètes. Dans ce contexte, les enjeux sont très importants et les risques nombreux.

Dans ces grands projets de refonte, la gestion du changement auprès des usagers est complexe et souvent délicate. Leur environnement de travail est largement bousculé sur une période longue (et qui s’allonge en fonction des problèmes découverts). Néanmoins, ce point est en général bien anticipé et les grands prestataires vendent à cette occasion de nombreux jours-hommes sur le thème « gestion du changement ».

On peut également citer une multitude d'autres facteurs assez connus qui peuvent poser problème tels que l'adéquation des spécifications et leurs changements éventuels en cours de route, les rebondissements de la politique interne, l'efficacité de la gestion du projet, l'exhaustivité des tests ou encore le management opérationnel et contractuel des sous-traitants.

Toutefois, un autre aspect - moins visible - nous semble être aussi très important : les choix de progiciels par les MOA sont trop souvent faits sur une analyse et des comparaisons de fonctionnalités des produits et uniquement là-dessus. Les middlewares sous-jacents, les systèmes matériels et les OS, sont totalement occultés. Cette absence de vision sur la technologie matérielle est quelquefois renforcée par l’existence de ‘GIE de production’ qui ne sont pas impliqués au début des projets et pour lesquels les MOA pensent que tout ira bien.

Un regard qui sous-estime des points dangereux

En conséquence, les points suivants ne sont pas étudiés et les difficultés qu’ils recèlent ne sont donc pas anticipées :

• L’infrastructure technique que les progiciels vont nécessiter : victime de la mode « IT doesn’t matter » ce point est considéré comme l’intendance qui suivra… moyennant quoi l’on voit débarquer en salle machine des serveurs divers et variés, des systèmes de stockage répondant à des principes d’architecture différents de ceux qui sont connus en interne, des middleware multiples, trois à quatre serveurs d’applications en n exemplaires, des SGBD divers tournant sur les deux ou trois OS majeurs du marché, bref une partie du Cebit (le Sicob n’existant plus…) arrive subrepticement en salle , face à des exploitants mis devant le fait accompli !

• L’architecture technique au sens du matériel et du middleware n’est donc pas sous contrôle : il va falloir apprendre à produire avec des éléments disparates, des ruptures de traitements, des systèmes à fiabilité incompatibles, bref, il va falloir définir des scénarios de panne et de reprise très complexes et aboutissant à limiter les interrelations pour éviter les situations inextricables...souvent il est trop tard quand on s’aperçoit de cela ! et construire une vision architecturale transverse devient un challenge.

• « L’ approche données » est aussi souvent mise à mal par ce type de projets. Le progiciel apporte son modèle à lui qui diffère a priori des autres modèles présents en entreprise. Ce point est d’ailleurs courant et connu depuis que les bases de données existent pour aider à le résoudre. Le problème c’est qu’il est souvent négligé dans ces projets, ou mis à plus tard lorsque le client tombe dessus…lors de la reprise de ses données. Les solutions sont alors très délicates à construire si l’on veut conserver un SI de qualité. Il est nécessaire alors d’ouvrir un sous-projet « système d’échange » comme un pis allé ; ce système assurant les échanges de données avec le reste du SI et souvent entre le nouveau et l’ancien qui n’est pas encore supplanté. Ce système d’échange, à moitié provisoire, à moitié durable devient un « point unique de défaillance » de premier ordre ! Et il n’est pas vu comme tel !

• La transition est, elle aussi, mal étudiée : estimant qu’elle doit être la plus courte possible, il est courant de penser « on verra quand on y sera » ! Or le Diable se cache dans les détails de la transition. Les allongements de projets que provoquent les points ci-dessus, augmentent la période de cohabitation entre le nouveau qui n’est pas entièrement là et l’ancien qui n’est pas parti encore (et qui demeure obligatoire pour tel ou tel cas sous-estimé au départ). Une zone de douleur dite de recouvrement est alors indispensable à étudier et à planifier en tant que telle sur des périodes non négligeables (allant jusqu'à 18 mois voire trois ans dans des projets de grande complexité) et en prévoyant souvent des lots de transition (jusqu’à trois) dépendant des produits et modules installés.

• Enfin, dernier aspect et non des moindres : en agissant ainsi il est difficile aux acheteurs de négocier les coûts. Ayant une architecture technique éparpillée entre fournisseurs et technologies, aucune masse critique n’est atteinte qui permettrait de négocier des volumes. Avec une phase de recouvrement ancien/nouveau longue, les économies escomptées ne se réalisent pas encore alors que les dépenses sont bien là. Bref, incapacité à négocier et surconsommation passagère sont le lot commun de ce type de situation, alors que la direction voyant cela rogne sur les dépenses.

• Pour être complet, il faudrait ajouter le fait que l’exploitation n’a pas été prévue en amont et que l’exploitant se retrouve à devoir comprendre la production à réaliser, procédurer les actions diverses à mener (surveillance, pilotage, administration, planification, résilience etc.) et que cela coûte en temps et efforts. Mais cela n’étant pas propre à ce type de projet, nous le notons par souci de précision sans le développer.

Trois pistes à explorer

Face à ces problèmes, il n’est pas de recette miracle, surtout lorsque la machine est lancée. Il y a toutefois quelques recommandations que l’on peut faire en aval de ces projets. Elles vont dans trois directions :

1. Rechercher des invariants d’infrastructure au début des choix de progiciel : cela permet de limiter les possibles sur un nombre restreint de technologies permettant d’obtenir du volume et des prix dans la durée. Cela nécessite d’avoir une ‘vision transverse infrastructure’ ayant un poids dans la négociation et le choix des progiciels. Une séparation ‘MOA-utilisateur’ / ‘GIE exploitant’ est un handicap alors qui n’est pas insurmontable toutefois. L’argument à faire valoir alors est que limiter la diversité, c’est aussi réduire les coûts de possession.

2. Définir un ‘gardien des données’ dès le début de ce type de projet. Même s’il n’arrivera pas à tout centrer sur son modèle, sa préoccupation portée avec attention dès le début permettra de sensibiliser tous les acteurs et de limiter les éclatements au strict nécessaire. Les investissements indispensables à faire dans ce domaine seront alors plus pertinents et pérennes.

3. Ajouter la facilité de transition technique dans les critères de choix des lotissements du progiciel. Plutôt que de lotir contraint et forcé en fonction des retards des développements et du paramétrage, pourquoi ne pas prendre en compte la facilité de transition de l’ancien vers le nouveau et rechercher un découpage en lots qui permette vite lot par lot de tourner la page ? Parmi d'autres critères applicatifs et organisationnels, ce critère ne sera bien sûr pas le seul, mais la sensibilisation à la transition qu’il apporte est salutaire.

Face à de grands projets de ce type en cours de lancement ou déjà engagés, en plus d’un regard critique et discriminant sur les fonctionnalités, la préoccupation devrait porter sur les ‘invariants techniques’, la maîtrise des modèles de données et la facilité de transition technique par lots. Rien de cela ne peut se faire sans impliquer toutes les parties prenantes de l’informatique.

Emmanuel Besluau
Vendredi 15 Mars 2013

Home Home    Mail Mail    Print Print    Zoom + Zoom +    Zoom - Zoom -    Share Share


Dans la même rubrique :
< >

Dimanche 30 Septembre 2012 - 16:13 Et si Louis Blériot avait été informaticien ?


Duquesne Research Newsletter