C’est avec Gilles Ruffieux que je co signe le numéro 4 de cette série d’interviews d’acteurs de la vie économique romande.

J’ai eu souvent le plaisir de croiser et d’échanger avec Gilles et son nouveau challenge est une bonne occasion de faire le point sur sa vision du système d’information des PME, de la collaboration, mais également des responsabilités de l’équipe qui en a la charge.

Gilles Ruffieux est bien connu en Suisse romande pour sa pertinence notamment en matière d’ERP et d’outils de PLM.

Je le remercie d’avoir eu l’amabilité de répondre à ces quelques questions dont j’espère que vous apprécierez la pertinence des réponses.

Dans une PME, comment définir le rôle du responsable du système d’information ?

Traditionnellement, le Responsable des SI d’une PME est issu de la technique ou d’une spécialité (ERP notamment).
Il est celui qui doit faire que les systèmes fonctionnent et répondent aux besoins métiers.
C’est avec cette vision et ce périmètre que j’ai commencé chez Corum il y a presque 7 ans pour le transformer au fil du temps en un rôle fort que l’on pourrait définir comme le baryton du changement organisationnel de l’entreprise

Projets, production, quels sont les sujets les plus importants en terme de temps ?

La production, c’est la raison même d’exister de l’entreprise, son chiffre d’affaire et donc son présent et son futur immédiat.
Les projets d’organisation et de système d’information doivent permettre à l’entreprise de faire plus avec le même niveau de ressources, mais ne peuvent en aucun cas ralentir la production.
Ces projets s’inscrivent donc dans une temporalité différente de celle de la production.
Le challenge est donc de réussir à exploiter les périodes de charge plus faible pour faire avancer les projets.

Les métiers ou « business lines » sont-il proactifs en terme d’outils et d’applications ?

Cela dépend des personnes, de leur intérêt pour la technologie et de leurs expériences passées.
D’une manière générale, et par rapport à la philosophie que j’ai mise en place, nous préférons que la demande soit initiée par les métiers, il convient par la suite de trouver une solution pour que leur choix s’intègre dans l’architecture en place et dans les flux des autres métiers et processus, afin de ne pas déplacer un problème d’une équipe vers une autre.
C’est tout l’enjeu d’une fonction de support (transversale) dans une entreprise traditionnellement organisée selon une hiérarchie verticale.

De manière générale, nous avons souvent été force de proposition, faisant bénéficier les métiers de notre veille constante et intensive et de notre conviction qu’il est toujours possible de faire différemment pour faire plus efficacement.
Cependant, cela s’est toujours fait avec l’acceptation préalable des propositions par les métiers et aux travers de projets fortement participatifs, dont certains ont été menés suivant une méthodologie agile.
De mon point de vue, ce n’est qu’en impliquant les utilisateurs que l’ont peut réussir la gestion du changement.
Ma définition d’un projet réussi est celle d’un projet pleinement utilisé en production et pas d’un projet livré selon un cahier des charges. Nous n’avons jamais hésité à remettre l’ouvrage sur le métier si cela s’avérait nécessaire.

Comment apporter la qualité de service attendue par les métiers ?

La qualité de service d’un SI est une notion purement informatique et souvent subjective.
Je comparerais cela à définir la qualité de la relation dans votre couple, tout est une question de point de vue.

Nous avons bien sûr introduit des SLA afin de définir les délais d’intervention entre les métiers et l’informatique. Je dois dire que cela n’a pas été bien compris. Si les SLA sont nécessaires dans une relation avec un fournisseur, en interne, ils représentent plus un moyen d’établir des statistiques sur le taux de services du département informatique qu’un outil permettant l’établissement d’une confiance réciproque.
Hors c’est bien cette confiance qui est recherchée.

Il faut comprendre que la charge de travail est parfois tellement importante que même un problème que l’on peut qualifier de « confort, facilement contournable » selon notre SLA devient une source de perte de temps et de montée de stress.
Nous devons donc chercher à apporter le meilleur support possible en tout temps (best effort) afin d’empêcher cette montée de stress, qui est source d’insatisfaction.
C’est cependant une partie que j’affectionne, car pleinement inscrite dans le fonctionnement de l’être humain, même si elle est, sur le moment parfois un peu astreignante.
Sur un autre plan, c’est ce qui permet d’établir une relation de confiance avec les métiers et qui permet également de mettre le doigt sur des « quick win » à forte valeur ajoutée, dont nous n’aurions sinon peut-être pas entendu parler.

Quelle serait l’architecture la plus efficace pour une moyenne entreprise ?

Les PME sont en constante adaptation. Elles doivent supporter un cadre juridique de plus en plus réglementé, dans des marchés internationaux l’étant de moins en moins, avec une concurrence féroce et le continuel risque d’être dépassé par un concurrent plus innovant, venant d’ici ou d’ailleurs.
Le maître-mot est donc flexibilité, inventivité, pragmatisme et orientation résultat.
En terme de SI, cela se traduit par un système souple capable de s’adapter en tout temps et si possible à moindre coût.
C’est ce qui a été déterminant dans les choix technologiques que nous avons fait, pondérés par la qualité et la disponibilité des compétences sur le marché.
La meilleure des technos ne sert à rien si personne ne peut la faire fonctionner !

L’architecture idéale pour une entreprise du type de Corum, consiste, à mon avis, en un middleware de data (Entreprise Service Bus) concentrant les données en provenance des différents systèmes, les agrégeant et les restituant selon les besoins de chacun des métiers, middleware sur lequel viennent se connecter les applications métiers spécialisées, délivrant le service souhaité avec un maximum d’efficacité.
Le second avantage de ce type d’architecture est la souplesse qu’elle permet dans le remplacement d’une application métier devenue obsolète, car elle ne sera qu’en périphérie de l’architecture et le nombre de ses utilisateurs sera plus faible, facilitant le change management.
Pour finir, les données critiques métiers sont sous contrôle de la société et agrégées par métier.
C’est aussi une voie intéressante pour permettre la mise en place d’une vraie gouvernance des données.

Ce constat est le fruit de notre expérience, car notre architecture actuelle, fruit de notre stratégie initiale (architecture en 3 couches fonctionnelles, avec une couche pour le développement (CAO-PLM), une couche centrale avec l’ERP et les applications connexes (QM, WMS) et une couche marché avec un PIM, des applications IPAD et des extranets) est en fin de vie et devient limitative et coûteuse en maintenance. Raison pour laquelle, nous avons initié, il y a 18 mois environ, une transition vers le modèle précédement décrit, notre middleware devant à terme intégrer une couche collaborative afin de faciliter les interactions et collaborations entre les différentes personnes et métiers.
C’est cependant un long processus, on ne change pas les fondations de sa maison du jour au lendemain.

Quel est l’impact des projets collaboratifs et des « outils sociaux » ?

Je pense que la différence fondamentale entre une grande entreprise et une PME est la proximité et la connaissance des différentes compétences des uns et des autres.
Dans le premier cas, le profil sert à identifier les personnes ayant des compétences pouvant être utile pour résoudre une problématique, alors que dans le second cas, les gens vont travailler par affinité et choisir de demander de l’aide à une personne avec qui ils se sentiront à l’aise, même si cette dernière n’est peut-être pas la plus compétente pour les aider.
Comme j’aime à le répéter, la collaboration est la dernière liberté de l’employé, liberté qu’il va utiliser en choisissant avec qui et avec quel efficacité il va collaborer.

Dans une PME, les outils collaboratifs, doivent donc offrir une haute valeur d’usage métier et directement faciliter l’exécution d’un travail quotidien dense et extrêmement diversifié.
Ils devraient donc être intimement liés aux processus et traitement des autres systèmes de l’architecture en place.
Dans notre modèle du middleware collaboratif, ils en deviennent le liant, le chef d’orchestre et l’aiguilleur du ciel.
Notre modèle comprend également un calcul dynamique de l’importance des différentes informations qui sont présentées à chacun, afin de permettre de doper l’efficacité globale et la productivité.

Cette conception idéale d’un outil collaboratif est le fruit des essais que nous avons faits d’outils favorisant les discussions ou la capitalisation des expériences (forum, wiki) qui n’ont eu que peu de succès.
En effet, les discussions ayant lieu au café ou lors des repas et l’expérience, restant intimement liées aux personnes.

Quant aux outils sociaux orienté marché, nous avons présenté une stratégie très ambitieuse, à même de positionner Corum comme un des leaders dans ce domaine, stratégie qui est en cours d’implémentation, par étapes successives, comme c’est souvent le cas dans les PME, ce qui permet d’avancer tout en testant et repositionnant si nécessaire.

Vos projets à moyen terme, pour quels objectifs ?

Sur le plan technique, des réflexions ont été menées pour trouver le bon équilibre entre les applications critiques, externalisées sur des partenaires Cloud en Suisse, et celle devant rester en interne, afin de garantir un taux de service maximal avec un niveau d’internalisation des spécialités minimal.

Sur le plan stratégique, l’intégration des filiales devient une nécessité et des démarches ont été initiées dans ce domaine.
Par ailleurs, j’ai entrepris une segmentation des activités sous formes de services afin de permettre d’identifier clairement leur valeur ajoutée pour les différents métiers par rapport à leur coût.

Je ne serai pas contre plus l’acteur de ces changements, ayant pris la décision, après presque 7 ans de transformation et de très belles réussites, de partir pour écrire une nouvelle page de mon histoire personnelle.
Je laisse cependant Corum avec une architecture système digne d’un grand groupe horloger, prête à affronter les nouveaux défis qui sont les siens et fier d’avoir participé à cette aventure au service de cette magnifique marque.

——————

Merci Gilles, et comme selon une expression bien romande,  » Tout de bon ! »