// vous lisez...

Les problématiques

Le poids de l’existant

Le phénomène dont je vais parler dans ce billet n’est à mon avis pas restreint au domaine de la Business Intelligence. Néanmoins il peut s’avérer très gênant pour la poursuite de l’activité de l’entreprise.
L’existant. Bien grand mot, et plus l’entreprise est âgée, plus l’existant est important : construit au fil du temps ou issu de rachat divers, les systèmes d’informations des entreprises évoluent avec elle.

Or dans le domaine du décisionnel les choses ont évolué à une vitesse folle depuis 10 ans : suivant la progression des capacités de traitement et de stockage, le décisionnel est passé, tout comme l’informatique de production, du stockage et traitement de quelques dizaines de Mega-Octets pour atteindre aujourd’hui le Peta-Octets sur des machines dédiées comme celles de Teradata !

Les données ont changé, les outils aussi.

Concentrons nous sur le système d’informations : il contient l’ensemble des données de l’entreprise et est donc utile à différents services. Dans une entreprise « classique » on retrouvera la compta, les achats, la direction, les commerciaux … Si on prend le secteur agroalimentaire on pourra aussi retrouver les caisses, les fichiers clients, etc. Une masse d’information qui cohabite et qui s’est enrichie depuis la création de l’entreprise. Vous vous en apercevrez certainement, l’entreprise évolue : c’est donc par couches successives que le système d’information s’est construit.

Ainsi on aura dans un premier temps développé des bases de données sous AS400, une batterie de scripts permettant de traiter les annuels, des tableaux Excel aux formules et macros titanesques : tout pour satisfaire le besoin utilisateur du moment.
Puis de nouveaux besoins sont apparus, l’entreprise a donc fait l’acquisition d’un progiciel de comptabilité sous Oracle 7, un autre de suivi des achats sous MySQL, des outils décisionnels … et enfin un ERP !

Comme vous pouvez le constater le tableau peut être très diversifié et sera différent d’une organisation à une autre. Voyez vous le problème se profiler à l’horizon ?

L’équilibre est fragile : une brique qui change et c’est l’ensemble des applications qui peuvent être impactées. Ce risque est d’autant plus grand lorsque les applications sont ancrées dans l’entreprise depuis longtemps. Citons entre autres :

  • Les développements spécifiques : vous avez codé un module supplémentaire pour une application en interne, ce module ne sera pas supporté par la nouvelle version.
  • Les conflits de versions : vous souhaitez faire évoluer votre base Oracle vers la dernière version afin de gagner en performance ou facilité d’utilisation. Impossible, votre ETL est trop ancien ! Il faut alors penser à migrer tous les scripts d’alimentation.
  • Connaissez vous les fonctions utilisés dans les scripts PL/SQL de plusieurs centaines de lignes que vous cachez au fin fond d’un serveur en priant chaque jour pour ne pas avoir à mettre votre nez dedans ?

Alors que faire ? Ne pas migrer ? Non, clairement : ce serait une erreur stratégique certainement fatale pour l’entreprise sur le long terme. Faire le choix de tout effacer et recommencer ? Non plus, cette solution est utopique dès lors que l’entreprise a un vécu décisionnel (ou informatique, tout simplement).

Du haut de ma modeste expérience de quelques mois, voici mon point de vue.

La première chose à faire est le recensement : il faut absolument connaitre son système d’information dans les moindres recoins afin de pouvoir envisager une migration sereine.
Vous pensez être à jour sur cette première remarque ? Attention, le raccourci « Monsieur Dupond est là depuis le début, il connait tout par cœur » est trop facile ; il faut FORMALISER ! En effet, la connaissance du système dans sa globalité est trop souvent tacite : les gens savent, ou savent qui sait, mais il faut absolument que cela soit écrit et validé. Il est donc préférable de procéder par étapes, en découpant par exemple par applicatif. On procède alors à des interviews des personnes clés afin de connaitre les versions des logiciels utilisés, leurs applications, les utilisateurs concernés … Une étape manuelle de recherche automatisée est aussi nécessaire : la règle d’or en la matière est de ne pas faire confiance à l’être humain, il omettra – volontairement ou non – de vous mentionner des informations capitales. Cet inventaire peut paraitre long et fastidieux, mais il aura au moins le mérite de remettre à plat tout votre historique. Il ne me semble pas opportun de faire une analyse trop approfondie : il n’est pas nécessaire de connaitre à ce stade dans le détail tout votre système. Contentez vous d’une analyse globale qui vous donnera une vue d’ensemble et mettra en avant les relations fortes entre les différentes briques
A qui assigner cette tâche ? Je pense qu’une société extérieure sera la plus à même de répondre correctement à la question. En effet, les personnes ne connaitront à priori pas votre système et seront donc plus à même d’effectuer une analyse complète et surtout non biaisée de votre existant.

Une fois votre état des lieux effectué, il faut alors prendre les bonnes décisions. Procédez par étapes et posez vous les bonnes questions : quelle activité est vitale pour l’entreprise ? Quelle application a un sérieux retard au point de pénaliser l’entreprise ? Est ce que la période est propice à une migration ? Cette dernière question est déterminante : pas question de migrer une partie d’un système décisionnel lorsque celui-ci est sollicité par tous les utilisateurs (pensez aux périodes de clôture comptable ou de forte activité d’un service). En effet, autant on pourra accepter un retard dans la livraison d’un applicatif, voir des bugs ou autres désagréments, autant une migration doit se dérouler sans accrocs pour ne pas pénaliser l’activité.

Revenons rapidement sur le premier point. Les étapes. Il faut hierarchiser : vous ne pouvez pas se faire chevaucher plusieurs migrations. En effet, si des pertes de performances apparaissent ou qu’une partie de vos applications ne sont plus fonctionnelles vous aurez alors énormément de mal à découvrir d’où provient la source de votre problème. Consultez donc les autres services, vous n’êtes pas tout seul dans l’entreprise !

Votre périmètre délimité, vous pourrez alors commencer la migration à proprement parler. Sachez vous entourer de personnes compétentes en mixant équipes internes et compétences extérieures. Il me parait dangereux de confier l’ensemble de la tâche à une société de service car celle-ci serait alors totalement maitre de votre système. A l’issue de la migration vous devez connaitre le nouveau système, comprendre les choix effectués afin de ne pas être totalement dépendants de ressources extérieurs.

Et vous ? qu’en pensez vous ? Avez vous déjà mené des migrations ? Ont-elles échoué ? Pourquoi?
Faites nous partager votre expérience et lancez le débat !

Discussion

Aucun commentaire pour “Le poids de l’existant”

Poster un commentaire