REFONTE_SI 1

La refonte totale de votre SI : par où commencer ?

Décider la refonte totale de son système d’information demande un grand courage : comme on dit, « on sait d’où on part, mais on ne sait pas très bien où l’on va arriver, ni quand ». Et c’est pourquoi les DSI qui se lancent dans cette aventure peuvent avoir tendance à privilégier une approche « bottom up », ce qui revient à identifier des micro-services et à mettre en œuvre une programmation par objet, en s’appuyant éventuellement sur une méthode agile afin d’avancer par paliers.

Certes, il y aura des résultats, et on aura le sentiment d’avancer. Et même, il est très probable que les clients seront satisfaits car ils auront, dans un délai relativement court, un outil qui marche et qui répond à leurs besoins. Donc, n’allons pas chercher plus loin : tout le monde est content ; pourquoi se compliquer l’existence en cherchant d’autres voies ? « Le mieux est l’ennemi du bien », comme dit le proverbe …

Mais les ennuis viendront plus tard. L’entreprise se trouve dans la même situation qu’un éditeur de logiciels qui, pendant des années, a « collé des rustines » sur les logiciels existants afin de répondre rapidement aux demandes d’évolution de ses clients, et qui s’aperçoit un jour que toute nouvelle évolution va lui coûter très cher car il aura progressivement transformé son progiciel en une véritable usine à gaz, « un paquet de nouilles » dont on ne sait trouver ni l’entrée ni la sortie.

Il existe une solution pour éviter ces ennuis : adopter une démarche de type « schéma directeur ».

En pratique, le schéma directeur, c’est la cartographie des processus de l’entreprise. Attention : il existe deux définitions du processus, qu’il ne faut pas confondre. Ces deux définitions correspondent à deux univers mentaux complètement différents. D’un côté, il y a le « BPM » qui conduit à identifier des processus, certes, mais qui sont en fait des procédures.

Il faut ici passer par une parenthèse sémantique : on appelle « processus » un système qui produit une valeur ajoutée et qui répond à la question « quoi faire ? ». Et on appelle « procédure » un ensemble d’actions qui répondent à la question « comment faire ? ». Le BPM conduit à des procédures, pour la simple raison que c’est automatisable : on répond en effet à la question « comment faire ? ».

L’autre type de processus – celui qui nous intéresse – est le « processus ISO 9001 », puisque cette norme internationale explique qu’il y a deux visions de l’entreprise, selon que l’on regarde sa structure ou sa finalité, laquelle se traduit par une approche transversale, sous forme de processus. Le COBIT (« Control Objectives for Information and related Technology ») analyse que le nombre maximum de processus dans une entreprise est 34. En pratique, on en compte une dizaine dans une petite structure et de vingt à trente dans une grosse.

Construire la cartographie des processus – c’est-à-dire le schéma d’ensemble – ne nécessite que quelques jours. Ensuite, il faut procéder à la modélisation des différents processus, en décomposant ceux-ci en étapes. Chaque modélisation peut prendre entre un et six mois-homme, ce qui n’est pas considérable, surtout qu’on n’est pas obligé de tout faire en même temps : on peut commencer par le processus-cœur de métier et le ou les processus critiques. On obtient alors le référentiel fonctionnel des activités de l’entreprise. Au passage, si on utilise la méthode appropriée,
on aboutit à un processus optimisé, débarrassé de toutes les boucles de rétroaction parasites, ce qui procure à l’entreprise de nombreux gains de productivité.

Établir ce référentiel fonctionnel est fondamental. En effet, il va servir de guide pour la refonte du système d’information. On pourra objecter que les architectures techniques étant souvent très différentes des architectures fonctionnelles, on a peut-être fait du travail pour rien, tout au moins du travail ayant peu d’utilité pour cette refonte. Tout dépend comment on s’y prend …

Une méthode d’organisation appropriée permet de modéliser les processus de telle sorte que chaque étape de processus est un « objet fonctionnel autonome ». Cela signifie qu’il possède ses propres données et ses propres règles de gestion. Autrement dit, dans tout le système d’information, une donnée est créée ou modifiée dans une étape de processus et une seule.

On peut alors procéder à l’urbanisation, en adoptant comme règle qu’un objet technique correspond à un objet fonctionnel et un seul. Nous obtenons alors le véritable « alignement stratégique du système d’information », en ce sens que l’architecture du SI est le reflet exact de l’architecture fonctionnelle. Ainsi, grâce à ce référentiel fonctionnel, on peut procéder à la refonte en étant sûr que, à tout moment, la cohérence globale est respectée. Et l’équipe chargée de la refonte est ainsi libre de sa planification, puis qu’on a affaire à des objets fonctionnels autonomes, sans aucune surface de recouvrement entre eux.

Échanger gratuitement avec un Expert Digital

Afin de mieux vous accompagner dans vos projets, nous vous proposons un échange gratuit avec l’un de nos experts !

Leave A Comment

What’s happening in your mind about this post !