Un ami, qui intervient comme consultant dans une grande banque française me confirme, lors d'une rencontre récente, que, dans toutes les banques dans lesquelles il est intervenu, la distinction entre maîtrise d'ouvrage (MOA) et maîtrise d'oeuvre (MOE ) n'existe pas. Pire, elle est conçue comme sacrilège, car elle risque, selon ce que pensent les managers de la banque, d'inciter les clients de l'informatique à formuler leurs expressions de besoins « dans leur coin », sans réfléchir en commun avec la MOE pour trouver la solution qui intègre les exigences des uns et des autres. D'ailleurs, me dit mon interlocuteur, cette façon commune de penser est totalement en phase avec ce que disent les Anglo-saxons, qui ne connaissent que la notion de « bonnes pratiques », mais pas du tout la distinction entre MOA et MOE. D'ailleurs, l'anglais ne dispose pas d'un mot spécifique pour traduire l'idée de MOA.

Cette non-distinction me rappelle la difficulté que nous autres consultants en systèmes de management rencontrons quand nous voulons expliquer la différence entre processus et procédure. Alors que c'est très simple : un processus répond à la question « quoi faire ? », il fait donc apparaître des valeurs ajoutées, alors que la procédure répond à la question « comment le faire ? » Ce qui fait que la présentation graphique d'un processus est une succession de boîtes, à la manière d'un diagramme PERT, alors que le graphe d'une procédure présente des boîtes et des losanges, lesquels marquent les choix à faire.



Même si ce débat est déjà ancien, c'est l'arrivée de la version 2000 de la norme ISO 9001 qui permet de clore définitivement le débat. En effet, la grande nouveauté de cette version de la norme est qu'elle présente une vision systémique de l'entreprise alors que la version précédente, qui date de 1994, en présentait une vision cartésienne. Cette grande nouveauté, c'est la référence aux processus de l'entreprise. Cette norme, donc, explique qu'il y a deux visions complémentaires de l'entreprise : la vision selon sa structure, qui est souvent représentée sous forme d'organigrammes, et la vision transversale, selon les processus de celle-ci, qu'on regroupe traditionnellement en trois catégories : les processus de pilotage, les processus de réalisation et les processus support. Ces deux visions sont orthogonales, ce qui signifie qu'en général elles ne peuvent pas se superposer. L'exception se trouve dans le cas où l'entreprise choisit une structure décalquée sur le découpage en processus, ce qui peut être le symptôme d'une méconnaissance de l'approche processus.



Pour poursuivre la lecture de la tribune de Georges Jacovlev, expert en architecture fonctionnelle des systèmes d'information, rendez-vous dans notre espace Blog experts.