Les étapes clés du SIRH et leurs enjeux

Dans cet épisode, nous allons étudier les grandes étapes clés d’un projet SIRH et les enjeux qui y sont attachés.

À entendre certains, le SIRH serait juste un logiciel RH dont il suffirait de se séparer pour le remplacer par un autre de temps en temps. Évidemment, si c’était aussi facile que la mise à jour d’une app sur son smartphone ça se saurait !

Et oui, le SIRH est un système, parfois complexe, qu’il faut savoir faire vivre. Il fait donc l’objet d’une urbanisation. Et cela ne se fait pas aussi facilement en effet que de simplement changer une application informatique.

Et pour se faire, il y a un ensemble d’étapes, de la réflexion à l’entretien du système, et chacune d’entre elles a ses propres enjeux. Alors, les étapes clés du SIRH et leurs enjeux, c’est quoi l’histoire ?

Au fond, comme dans tout projet, ce n’est pas la peine de finasser, il y a 3 grandes phases :

1. une phase avant le projet qui consiste à définir ce que l’on veut,
2. une phase de réalisation
3. et une phase de vie du projet.

Et en matière de SIRH c’est pareil, peut-être avec des mots parfois un peu différents. Mais commençons par le début. La phase de définition de ce que l’on veut faire. Et le début c’est quoi ?

La politique RH ! Avant même de faire un diagnostic du SIRH, de ses points forts et des améliorations possibles, des trous dans la raquette, etc. la base c’est bien la politique RH et comment le SIRH va en constituer l’un des bras armés.

Et cette phase qui consiste à exprimer le rôle que le SIRH doit jouer pour rendre cette politique RH possible est clé car un SIRH en tant que système a une architecture dont les propriétés peuvent, ou pas, porter les exigences de la politique RH. Il faut donc ici traduire les invariants de la politique RH, c’est-à-dire ce qui n’est pas négociable, en propriétés attendues du SIRH.

Là, l’enjeu est double. D’abord un enjeu de maïeutique, car l’expression de ces enjeux politiques et leur traduction en propriétés de système est parfois difficile à formaliser, quand il y a une politique claire, ce qui n’est pas toujours le cas. Et ensuite parce qu’il y a les enjeux cachés, qui peuvent relever par exemple des jeux de pouvoir et des susceptibilités internes, et qu’il n’est pas facile de les lire.

Un exercice à la croisée des chemins entre le conseil RH et le conseil SIRH qui est d’autant plus difficile que peu d’acteurs allient cette double culture avec suffisamment de recul politique et d’expérience pour discerner ce qui relève des invariants, donc essentiels, de ce qui l’est moins.

L’étape d’après, toujours dans la phase de définition de ce que l’on veut, c’est celle du diagnostic de la situation SIRH actuelle. Et pour cela, on procède de deux manières. D’abord une analyse processus par processus et une analyse plus globale de l’ensemble. En utilisant le plus souvent des méthodes aussi classiques qu’un SWOT par exemple ou des grilles de cotation multi-critérielles.

Et là, comme souvent, l’enjeu n’est pas dans la méthode et encore moins de se réfugier derrière l’illusion de la rationalité des tableaux de chiffres. Au fond, l’enjeu est double. Trouver la bonne maille de découpage des processus, qui peut être différente d’un processus à l’autre d’ailleurs, pour coller à la nature des enjeux du projet. Et ensuite, de faire preuve d’honnêteté dans le regard que l’on porte sur la situation. Pas de concession !

C’est vrai qu’on peut parfois être juge et partie, parce qu’on n’ose pas avouer qu’on s’est trompé et qu’on préfère édulcorer tel ou tel faiblesse d’un système qu’on a choisi ou pour des raisons politicardes internes etc. Bref, comme souvent, la lucidité du diagnostic, donc la pertinence de la lecture du problème, est souvent clé !

Une fois que l’on a identifié les problèmes à résoudre et que l’on a su établir un ordre de priorité raisonnable au regard des enjeux politiques et de ses invariants, il convient alors de décider de ce que l’on vise. A savoir une architecture cible, avec des applicatifs identifiés. Et là on formule des scenarii avant d’en choisir un.

Là l’enjeu c’est l’hygiène du raisonnement, en étant le moins influencé par les discours techno-marketing du marché, ce qui n’est pas simple. Mais avec rigueur logique et intellectuelle on en arrive à la cible à viser qui se matérialise dans un schéma directeur qu’il va falloir ensuite mettre en œuvre.

Et c’est l’objet de la phase suivante au travers de projets dont la première étape est cahier des charges – appel d’offres. Inutile d’entrer dans le détail pour savoir ce que c’est mais arrêtons-nous un instant sur les enjeux. Le premier, c’est un cahier des charges compréhensible pour ceux à qui on l’adresse.

Tu veux dire que l’enjeu ce n’est pas de détailler où on doit cliquer et quel genre de fenêtre ça ouvre et s’il faut un scroll vertical ou pas mais bien de faire comprendre la substantifique moelle de ce que tu veux faire ? Et bien oui !

Et d’avoir une stratégie d’appel d’offres réaliste au regard du marché. Ce n’est pas la peine de définir un mouton à cinq pattes pour t’apercevoir que personne ne répond. Ce n’est d’ailleurs pas idiot, si on le peut sur un plan formel, de regarder le marché avant car il peut être source d’idées auxquelles on n’aurait pas pensé, comme de faire un appel d’offre ciblé à quelques éditeurs identifiés pour ne pas perdre de temps. Une question d’équilibre et de lecture du marché ou un enjeu de réalisme.

Et une fois choisi, il faut bien mettre en œuvre le projet. Sachant que certains éditeurs intègrent leurs produits eux-mêmes et que, pour d’autres, il faut faire appel à un intégrateur, recommandé ou pas, ce qui peut en soi modifier les logiques d’appels d’offres d’ailleurs

Et là l’enjeu c’est un enjeu de pragmatisme et de rigueur. Combien de fois sous-estime-t-on la complexité des reprises de données, la complexité des interfaces, ou combien de fois est-on trop ambitieux sur les délais oubliant la charge que représente une recette fonctionnelle, ou tout bêtement les vacances, ou la pénurie de compétences sur le marché qui fragilise les prestataires, auprès de qui il ne suffit pas de se décharger de ce risque.

Bref un jour tout est là et ça marche. Encore faut-il faire vivre le projet dans le temps et c’est la 3^ème phase. Alors on pense naturellement à la maintenance de tout cela, qu’elle soit corrective pour corriger les bugs mais aussi évolutive car rien de ce que nous avions imaginé au début n’est gravé dans le marbre.

Et diable que cela peut coûter cher dans le temps quand on a oublié qu’un château c’est sympa mais qu’il faut avoir les moyens de l’entretenir ! Bref, anticiper avant ce que cela va coûter après ! Et dieu sait qu’avec l’augmentation des contraintes, y compris légales ou de sécurité, ça ne risque pas de baisser.

Là encore, la complexité du marché exige réalisme et pragmatisme bien sûr mais aussi lucidité. Entre les politiques de versioning des éditeurs, les éventuels empilements de prestataires différents et la complexité du muti-contracting il est parfois difficile de retrouver ses petits !

En résumé, il y a 3 phases pour un projet SIRH : 1 – définir une architecture cible pour répondre à la fois aux enjeux de la politique RH et aux défauts du SIRH actuel ; 2 – mettre en œuvre les choix en faisant appel à des éditeurs et des intégrateurs ce qui signifie faire des appels d’offre et 3 – faire vivre le SIRH en assurant la maintenance corrective et évolutive en oubliant jamais que l’entretien coûte cher aussi !

J’ai bon cheffe ?

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