Un SIRH intégré ou pas ?

Allez, un bon ERP qui fait tout et tu vas voir comment ça va marcher droit, tout le monde aligné, dans le même sens et le bon, celui que j’ai décidé, et encore c’est sans parler des gains de productivité, de qualité, bref de tout ! Autant te dire que mon choix est vite fait.

Ah quand le sens du contrôle domine, cette croyance que le processus s’impose et que les personnes s’y résoudront, de gré ou de force, que la loi, la règle et la norme modifient les comportements, bref… C’est parfois vrai, mais aussi parfois le fruit d’une idéologie un peu déconnectée du réel.

Entre la tentation du SIRH totalement intégré dans un seul et même outil et celle d’avoir autant d’outils sur-mesure que de besoins qu’on veut satisfaire au plus près, au-delà des postures idéologiques … comment éclairer cette question ? Alors, un SIRH intégré ou pas, c’est quoi l’histoire ?

Deux premiers jalons simples pour comprendre le sujet. D’abord, un SIRH c’est un ensemble plus ou moins intégré d’applications informatiques pour couvrir les processus RH de l’entreprise.

Cet ensemble qui forme un système, a des caractéristiques ou des propriétés. En l’occurrence, l’une d’entre elles, certainement l’une des plus structurantes, c’est son caractère plus ou moins intégré.

Qu’est-ce que cela signifie « intégré » ? Intégré dans quoi d’abord ? Et bien dans un logiciel unique. Dit autrement, est-ce toutes les fonctionnalités couvertes par mon SIRH sont logées dans un seul et même outil informatique ou dans plusieurs ?

Logé dans un seul et même outil, appelez-le comme vous voulez un logiciel, une application, un progiciel, bref un programme… cela signifie partager la même base de données, le même moteur de règles, la même gestion des droits et des habilitations, les mêmes couches basses applicatives comme la gestion de la sécurité, de la volumétrie etc.

A l’inverse, quand on a plusieurs applications, chacune d’entre elles a ses propres spécificités et il faudra bien que tout cela communique. Deux extrêmes donc : tous les machins RH dans le même truc informatique ou un bidule informatique pour chaque chose RH, avec toutes les nuances de machins trucs choses entre les deux.

Euh… tu voulais rendre le sujet accessible, on peut reformuler ton truc là ? Un seul logiciel pour tous les sujets RH ou une collection de plusieurs logiciels pour les traiter, cette collection pouvant être plus ou moins grande.

Un seul outil pour tout faire, c’est le principe d’un ERP – Enterprise Resource Planning – ou PGI en français pour Progiciel de Gestion Intégré : tous les processus de l’entreprise dans le même logiciel.

La supply chain, le manufacturing, la comptabilité, le contrôle de gestion, la gestion de la relation client, la RH , etc. Quand tu privilégies un outil intégré pour la RH, deux options s’offrent à toi : la partie RH d’un ERP qui intègre tout dont la RH ou ce qu’on pourrait appeler un ERP RH qui intègre toute la RH mais seulement la RH. Dans les 2 cas, la partie RH est intégrée.

Mais alors, comment choisir s’il vaut mieux intégrer ou au contraire démultiplier le nombre d’outils ? Honnêtement, un seul c’est plus simple non ?

Pas si simple. Prenons d’abord une analogie. D’un côté, un couteau Suisse, qui intègre un peigne, un tire-bouchon, une lime, une lame, une paire de ciseau etc.  Et de l’autre, une trousse à outils avec un peigne de compétition, un tire-bouchon professionnel, une gamme de couteaux adaptés à différents usages et une paire de ciseaux.

D’un côté, tout sous la main mais tu n’as pas un super tire-bouchon, ni de super couteaux, de l’autre, des outils de compétition mais il va falloir s’y retrouver dans le bazar de ta trousse à outils.

On voit bien que les avantages de l’un ne sont pas ceux de l’autre. Caricaturalement, un truc qui survole tout donc qui fait tout, certes, mais tout pas très bien, là où, dans la collection d’outils spécialisés, chaque outil fait super bien ce qu’il sait faire mais ne sait faire que cela et la multiplication des outils rend la cohérence d’ensemble très imparfaite.

Le premier prisme est celui-ci : on standardise, on normalise, on accepte de ne pas coller parfaitement au nec plus ultra ou de ce que l’on veut mais on bénéficie d’une plus grande cohérence ou alors on privilégie l’inverse.

On voit ici se dessiner donc des lignes de force faciles à comprendre : la volonté de normaliser, qui peut être celle du groupe par exemple, ou d’un acteur qui cherche à tenir les rênes par opposition à la satisfaction de besoins particuliers, qu’il s’agisse de ceux d’une filiale, d’un établissement ou d’un métier.

C’est peut-être là un des facteurs d’arbitrage les plus importants pour au moins une raison : c’est l’incarnation et le bras armé d’une culture et d’une politique en matière de contrôle et de liberté des entités, des métiers, du terrain.

Or, on sait que ce n’est pas en décrétant une norme ou une règle que les comportements locaux vont s’aligner. Ou alors à l’usure et au bout d’une longue période dont les coûts en tout genre, et notamment en guerres intestines, sont souvent colossaux.

On en arrive à une deuxième dimension, celle des coûts. En première lecture, plus on démultiplie, plus ça coûte cher. Une Rolls pour acheter le pain, une Ferrari pour les vacances et une Maserati pour les week-ends… Ou alors un seul véhicule à tout faire.

C’est sans compter sur la multitude des facteurs qui entrent en ligne de compte dans les faits. Les gros projets informatiques très intégrés sont souvent lourds, complexes, chronophages, leur mise en place est chaotique, le plus souvent avec une gestion de projet qui dérive, une conduite du changement qui n’en est pas une, des levers de boucliers de partout…

Bref, le puits des coûts cachés, les coûts imprévus et les dérives sur les délais, … Sans compter ce qui se passe après… Les traces sociales qui sont parfois indélébiles, les talents de bonne volonté qui sont partis de guerre lasse, les coûts induits par la normalisation en mécontentement des clients internes par exemple, que ce soit les managers ou les collaborateurs.

Et de l’autre côté, avec un choix judicieux non plus entre Rolls, Ferrari et tout le bastringue mais entre un vélo, une petite voiture électrique et un cheval de trait, ce n’est peut-être pas si coûteux mais quid de l’intégrité des données, du coût de maintien des interfaces, des dégâts d’une définition qui change dans un référentiel et pas dans un autre, des guerres pour avoir la main sur la gouvernance de telles ou telles données ou référentiel ?

Il n’y a donc pas de clé d’arbitrage simple sur le plan des coûts car en réalité c’est ce qu’on en fait et la manière plus ou moins pertinente et efficace de le faire qui fait la différence.

Un autre critère serait de s’interroger sur les besoins fondamentaux qu’on cherche à satisfaire en s’appuyant sur ce qui fait la force de l’intégration ou de son opposé. Prenons une analogie : une machine lavante et séchante ou une machine lavante et une machine séchante ?

C’est le volume de linge, la fréquence d’utilisation, etc. qui jouent beaucoup en faveur de l’un ou de l’autre. Dit en d’autres termes c’est en fonction des besoins et des critères qu’on estime importants ou non négociables.

Par exemple, sur la gestion administrative, la paie et la gestion des temps, j’ai des enjeux de pure productivité et de qualité intrinsèque de ce qui est produit et peu de diversité, car je n’ai qu’un seul réglementaire. Alors j’intègre tout ça dans un seul outil car cela favorise la productivité quand il n’y pas trop de customisation. Alors que sur les domaines comme la formation, le recrutement et la GPEC j’ai des besoins très différents pour chacun d’entre eux. Je choisis donc des applications différentes.

Et tu as alors un SIRH semi-intégré. Intégré pour le socle administratif et composite pour le reste. Autre exemple. Je suis dans un contexte mondial. Je laisse de la liberté locale pour tout ce qui relève des processus contraints par des réglementations locales, comme la paie par exemple et je laisse alors chaque pays choisir ses outils et la manière de les exploiter. Là, à l’inverse, c’est composite pour le socle administratif.

Mais tout ce qui relève du talent management, je l’intègre mondialement dans un seul outil parce que je souhaite que tous les collaborateurs soient équitablement traités en termes d’évaluation, entretiens etc. où qu’ils soient dans le monde. Du semi-intégré mais différemment du cas précédent parce que les besoins sont différents.

Et j’ajoute dans ton second exemple que tu seras tenté de mettre en place un infocentre RH ou un datawarehouse, appelle cela comme tu veux, pour que les données issues des systèmes de paie locaux puissent être aussi exploitées à des fins de visibilité groupe, pour un bilan social monde par exemple.

Ce qui nous conduit in fine à comprendre que la réponse à la question est bien une affaire d’architecture et d’urbanisation de ton système d’information et qu’il va falloir la penser dans un schéma directeur qui favorise la réussite de ta politique RH ou qui au moins en sert les invariants.

En résumé, il n’y a pas de réponse universelle et unique à la question de savoir s’il faut plus ou moins intégrer son SIRH mais des réponses en fonction des besoins RH et de la manière dont l’intégration ou son opposé peuvent les satisfaire. C’est le fondement de la réflexion sur l’architecture et l’urbanisation du SIRH.

J’ai bon chef ?

Oui tu as bon mais on ne va pas en faire toute une histoire.