Pourquoi le même poste doit piloter votre SI et vos méthodes métier

Deux responsables, un système qui ne sert personne

Dans beaucoup de PME et d'ETI, le système d'information et les méthodes métier ont deux propriétaires différents, et aucun des deux n'a mandat sur l'ensemble. D'un côté, un responsable informatique gère l'ERP, les serveurs, les licences, les accès. De l'autre, un responsable méthodes ou process optimise des workflows sur un tableau blanc ou dans un fichier Excel, sans autorité sur le système censé les faire vivre. Les deux font leur travail correctement. Le problème n'est pas une compétence qui manquerait d'un côté ou de l'autre, c'est qu'aucun des deux postes, pris isolément, ne peut faire tenir l'un dans l'autre.

Le signal se reconnaît dans une scène précise : un atelier de refonte de process produit un schéma cible propre, validé en comité, avec des étapes claires et des gains identifiés. Sa mise en œuvre dépend d'une demande de paramétrage ERP qui atterrit dans un backlog informatique, à côté d'un renouvellement de licence et d'un ticket de serveur. Personne dans ce backlog ne porte l'enjeu métier du ticket, et la priorisation se fait sur des critères techniques (urgence, complexité de développement) qui n'ont rien à voir avec le goulot d'étranglement que l'atelier venait de documenter. Le process reste beau sur le papier, et le système reste une boîte noire que personne ne pilote vers l'efficacité opérationnelle.

Ce schéma se répète sous des formes légèrement différentes selon le métier, mais la structure reste identique : une couche méthodes qui pense le travail tel qu'il devrait se dérouler, et une couche système qui ne reçoit cette pensée que filtrée par un ticket, une priorité technique, et un délai qui n'a rien à voir avec l'urgence opérationnelle réelle. Plus l'entreprise grandit, plus ce filtre s'épaissit, parce que le volume de tickets grandit avec elle, sans que personne n'ait jamais explicitement décidé qui tranche entre eux au nom de la production.

Pourquoi cette frontière ne tombe jamais d'elle-même

Cette séparation découle d'une logique de poste qui semble aller de soi : l'IT gère des serveurs et des licences, les méthodes optimisent des process, et entre les deux, un fossé que personne n'a explicitement pour mission de combler. Les projets de transformation échouent rarement par manque de technologie. Ils échouent parce que la technologie reste pensée « côté informatique », c'est-à-dire selon ce qui est simple à configurer ou déjà prévu par l'éditeur, plutôt que « côté utilisateurs », c'est-à-dire selon ce qui débloque réellement un goulot de production. Le système d'information suit alors sa propre logique interne, celle de l'éditeur et des choix techniques passés, au lieu de suivre la logique opérationnelle de l'entreprise qui l'utilise.

Ce défaut d'arbitrage se voit particulièrement dans les PME qui ont grandi vite sans jamais internaliser une fonction SI avec un vrai mandat transversal.

Le budget qui sépare ce que l'organigramme sépare déjà

La séparation se retrouve presque toujours aussi dans la manière dont les budgets sont construits : une ligne « informatique » qui couvre licences, hébergement et maintenance, une ligne « organisation » ou « amélioration continue » qui couvre les ateliers et les formations. Chaque responsable optimise la ligne qu'on lui a confiée. Le responsable méthodes n'a aucune raison de regarder le coût d'une évolution ERP avant de la demander, puisque ce coût ne pèse pas sur son budget. Le responsable SI n'a, symétriquement, aucune raison de prioriser une demande méthodes au-dessus d'un renouvellement technique, puisque son budget à lui se mesure en disponibilité du système, pas en gain opérationnel terrain. Les deux budgets sont correctement gérés, séparément, et c'est précisément cette bonne gestion séparée qui entretient le fossé.

« Le défaut, c'est qu'ils n'avaient pas de DSI en interne. Et donc en fait, même leur manière de penser les projets, la gestion de la donnée, n'était pas du tout adaptée à une entreprise de cinquante personnes. »

L'absence d'un porteur SI interne ne se traduit pas par un système qui manque de fonctionnalités. Elle se traduit par une manière de penser les projets qui reste dimensionnée pour une structure plus petite, où personne n'a jamais eu à arbitrer entre une contrainte technique et un besoin métier parce que personne n'avait les deux casquettes à la fois.

Fusionner, pas juxtaposer

Chez Leando, ce principe s'appelle fusionner, pas juxtaposer : confier l'ERP et les méthodes métier à la même personne force un alignement structurel que deux postes séparés ne produiront jamais d'eux-mêmes. Une entreprise agro-industrielle d'environ deux cents salariés, organisée autour d'un ERP central, a pris cette décision en confiant les méthodes à la personne qui pilotait déjà l'ERP. Le changement ne tient pas à une compétence supplémentaire acquise du jour au lendemain, il tient à ce que cette personne ne peut plus traiter le système comme une contrainte technique extérieure à son propre travail : elle doit le faire évoluer au service de l'efficacité opérationnelle, parce que c'est désormais elle qui répond, seule, des deux résultats.

Ce qui change concrètement dans l'arbitrage quotidien

Avant la fusion, une demande de paramétrage venue d'un atelier de production attend son tour dans la même file qu'un renouvellement de certificat serveur, arbitrée par quelqu'un qui n'a pas vu le goulot d'étranglement de ses propres yeux. Après, la même demande est arbitrée par quelqu'un qui connaît à la fois le coût technique de l'implémenter et le coût opérationnel de ne pas le faire. Le système d'information devient, concrètement, un outil de productivité piloté par celui ou celle qui connaît les points de blocage du terrain, pas une ressource technique gérée indépendamment des besoins qu'elle est censée servir.

Cette bascule change aussi la manière dont les décisions se prennent en amont, pas seulement l'arbitrage du backlog une fois le projet lancé. Un atelier de refonte de process ne se termine plus par un schéma cible qu'il faudra « faire valider par l'informatique » dans un second temps, avec le risque de découvrir trop tard qu'une partie de l'ambition n'est pas réalisable dans le système actuel. La faisabilité technique et le gain opérationnel s'évaluent ensemble, au même moment, par la même personne, ce qui évite l'aller-retour classique entre un atelier métier enthousiaste et une contrainte technique qui douche une partie du travail de cadrage une fois découverte.

Ce que ce principe exclut, et où il s'arrête

Ce principe n'est pas une solution universelle, et il ne remplace pas deux mécanismes qui ressemblent de loin, mais qui répondent à un problème différent. Il ne remplace pas un rôle de traduction entre métier et technique mobilisé le temps d'un projet ou d'une mission externe : nous détaillons cette fonction, temporaire par nature, dans notre article sur le pont entre métier et technique. Fusionner SI et méthodes est une décision organisationnelle permanente, indépendante de tout projet en cours. Il ne remplace pas non plus les critères à vérifier quand vous recrutez un profil combinant plusieurs fonctions pour porter un projet précis, traités dans notre article sur le poste qui combine trois fonctions : ce cas concerne un recrutement de projet, le nôtre une réorganisation de l'existant.

Le principe exclut aussi de l'appliquer à une PME qui n'a encore aucune fonction SI identifiée. Fusionner suppose qu'il existe déjà deux rôles à rapprocher. S'il n'en existe aucun, le sujet n'est pas de fusionner mais d'en créer un premier avec un vrai mandat, ce qui précède ce principe dans la maturité d'une organisation plutôt que de s'y substituer.

La vraie limite, enfin, tient à la taille du périmètre couvert. Tant que le système d'information et les process métier restent lisibles par une seule tête, la fusion accélère les arbitrages sans les appauvrir. Passé un certain volume, généralement quand plusieurs départements dépendent du même système avec des logiques métier qui divergent, cette même personne devient le goulot d'étranglement de toutes les décisions. Le signal à surveiller n'est pas la taille de l'entreprise en elle-même, c'est le temps que cette personne met à répondre à une demande d'arbitrage : s'il s'allonge malgré une charge de travail stable, le moment est venu de redécouper le périmètre, avec un mandat partagé plutôt qu'un retour à deux silos qui ne se parlent plus.

Le test à faire sur votre organigramme

Regardez qui porte, sur votre organigramme, la responsabilité du système d'information et qui porte celle des méthodes ou process. Si ce sont deux cases différentes, posez une question simple : partagent-elles un indicateur commun, ou chacune est-elle évaluée sur son propre périmètre, sans lien entre les deux ? Dans la grande majorité des PME que nous rencontrons, la réponse est la seconde, et c'est précisément ce qui maintient le fossé. Avant même de renommer des postes, donnez à une seule personne l'arbitrage du prochain backlog d'évolutions ERP et observez si la vitesse de décision change. Si elle change, vous venez de trouver votre prochain chantier d'organisation, sans qu'il ait fallu recruter qui que ce soit.