Cartographie du plat de nouilles

autoroute-charlesIl est rare et plutôt déconseillé de modifier l’ensemble du système d’information d’une entreprise en une seule fois. Un projet de SI mobilise massivement le personnel pendant le temps de sa création et de son déploiement. Il est préférable de traiter le sujet par morceaux.
Cependant, il est important que les différents métiers dialoguent entre eux. L’absence d’échanges internes, c’est la maladie mortelle des entreprises. Il faut donc que les outils de ces métiers dialoguent aussi entre eux.

Constater

Le système d’information d’une entreprise devient rapidement une marqueterie d’applications, d’âges, de technologies et de langages divers. Ces applications sont reliées entre elles par des liaisons qui au fur et à mesure transforment le système d’information en plat de nouilles, tous les programmes étant reliés entre eux par des interfaces qui les solidarisent.
L’interface est le cauchemar de la maintenance. Reliant entre eux deux sous-systèmes de technologies et de langages différents, il est un point faible du réseau de l’entreprise. Il faut constamment le surveiller pour s’assurer qu’aucune information ne s’est perdue. Resynchroniser des applications dont l’interface a cessé de fonctionner pendant un moment est un exercice qui peut s’avérer particulièrement périlleux et qui s’apparente à la reprise de donnée (voir Jivaro song).
Si ces interfaces fonctionnent bien, on finit par les oublier, ce qui s’avèrera problématique en cas de remplacement ou d’opération de maintenance lourde de l’une des applications.
C’est le travail des urbanistes en système d’information de garder la mémoire des différentes applications, de leurs liaisons, de leurs technologies, et donc effectuer la cartographie du plat de nouille.

Anticiper

Si rien n’est fait, au fur et à mesure que l’entreprise numérise ses différentes fonctions, le nombre d’applications augmente et le nombre de liaisons entre applications s’accroit encore plus vite.
L’urbaniste va s’efforcer d’anticiper cette évolution et réfléchir à la manière d’organiser le système d’information pour éviter cette inflation. Cette action se fait en amont du lancement de n’importe quel projet d’application. Elle va consister à analyser les quatre couches que comprend un système d’information d’entreprise :
Premier niveau : les métiers. On est très en amont de tout applicatif ; l’objectif est de définir les grandes fonctions de l’entreprise. En théorie, toute entreprise a les mêmes fonctions, production, commercialisation, achat, comptabilité, trésorerie, ressources humaines, etc. En pratique, les frontières peuvent être floues, et peuvent varier suivant la taille de l’entreprise, par exemple, la comptabilité peut absorber la gestion budgétaire, la trésorerie, les achats, ou il peut s’agir de métiers complètement différents. De plus l’organisation de l’entreprise peut privilégier une structuration par zones géographiques (par agences, par régions, par pays), plutôt que par grandes fonctions. Enfin il peut y avoir des cas où il est intéressant de séparer des fonctionnalités. Par exemple, l’entreprise peut avoir plusieurs lignes de produits, s’adressant à des clients différents, utilisant des composants différents, et réaliser par des acteurs différents. Il s’agit donc de métiers différents.
Deuxième niveau, les processus. A l’intérieur de chaque métier, il faut décrire sommairement les processus fonctionnels d’échanges d’informations. Qui parle à qui, quand, où, pourquoi, comment et pour dire quoi. Quelles sont les principales données qui sont conservées, quelles sont les référentiels partagés. Cette définition des processus opérationnels devrait être cohérente avec la cartographie des métiers. Chaque métier rassemble des personnes participant aux mêmes processus.
Troisième niveau les applications. Quelle application outille, accompagne quel processus. De préférence, les acteurs d’un même processus ne devraient avoir à utiliser qu’une application. Ceci réduit les coûts de formation et d’apprentissage. De même un référentiel ne devrait être renseigné que par une seule équipe.
Quatrième niveau : les machines. Autant que possible, toutes les applications d’un même métier devront être sur les mêmes machines, avec les mêmes règles de continuité de service (il est difficile d’expliquer à un chef de service que de telle heure à telle heure ses agents pourront utiliser telle application et que telle autre aura une plage horaire d’utilisation différente).
Le résultat devrait être une cohérence générale entre les quatre niveaux, métiers, processus, applications, machines. Si les quelques règles succinctement exposées sont respectées, le système d’information de l’entreprise n’est pas le plat de nouille, mais un jardin à la française, ordonné, simplifié.

Préconisation

Face à la panique ambiante, les hommes du système d’information ont compris l’intérêt de mettre de l’ordre. Les urbanistes et architectes sont associés aux projets, invités à proposer les améliorations.
L’urbaniste pose un diagnostic, à coup d’entretiens et de réunions de travail qui s’apparentent aux séances du dictionnaire de l’Académie française et aux commissions d’enquêtes sur l’accident de Challenger. Il propose des préconisations visant à simplifier la vie des acteurs, réduire le nombre de liaisons entre applications, apporter plus de souplesse aux changements organisationnels, et à long terme réduire les couts de la maintenance. . Ils rédigent des règles, ajoutent de la cohérence pour aller vers un idéal d’organisation, de stabilité qui fait la joie des techniciens.
Qui dit règles, dit gardiens des règles. Comme partout l’urbanisme numérique a ses ayatollah, qui défendent avec vigueur la cohérence du système et s’élèvent contre les hérésies, ou parfois simplement les nouveautés.
Mais les urbanistes doivent composer avec les demandes des maîtres d’ouvrage. Ceux-ci attendent du système d’information de la réactivité, de la capacité à s’adapter. Nouveaux produits, nouveaux besoins, gains de productivité sont les besoins attendus et non cohérence et rigueur.
Entre adaptabilité et cohérence, les concepteurs développeurs naviguent à vu, cherchant la solution la plus simple (faire fonctionner les règles dans un contexte imprévu est difficile et couteux)
Cette situation a au moins un avantage. Elle procure régulièrement du travail aux urbanistes car on a toujours besoin que quelqu’un mette un peu de clarté dans le désordre.

Nota

L’illustration de cette chronique est une oeuvre de Charles Léobon

 

Cet article, publié dans developpement, informatique, système d'information, est tagué , , . Ajoutez ce permalien à vos favoris.

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 )

Photo Google+

Vous commentez à l'aide de votre compte Google+. 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 )

w

Connexion à %s