Systèmes d’information RH, les étapes à  suivre

Le coût du projet ne se limite pas à  celui de l’application.
Ne jamais se précipiter dans l’implémentation, Il faut prendre le temps nécessaire pour bien définir les besoins fonctionnels.

Loin d’être un effet de mode, la mise en place d’un système d’information ressources humaines (SIRH) répond aujourd’hui à un besoin mature de changer le parc des applications existantes… Mais, attention ! le coût du projet ne se limite pas à celui de l’application. D’autres actions d’accompagnement seront nécessaires au fur et à mesure de l’exploitation du système (nouveaux besoins, nouvelles versions, etc.).
Le projet comprend deux volets que sont l’avant et l’après-choix.
Avant de choisir, il faut d’abord commencer par la rédaction d’une check-list des besoins technico-fonctionnels réels. Suivent la consultation des éditeurs/intégrateurs et la définition d’une short list. Un système d’évaluation basé sur des critères est nécessaire pour orienter le choix. Par exemple, il faudra prévoir des fiches d’évaluation avec critères et des pondérations associées à ces critères (couverture fonctionnelle, références, coût …). La note finale sera déterminante, à côté du coût de la proposition, pour le choix final.
Selon le choix de l’entreprise, les consultations peuvent être restreintes comme elles peuvent faire l’objet d’un appel d’offres…
Une fois le choix arrêté, commence alors la phase de mise en place et d’implémentation.
Ce ne sont pas des dates à prendre seul ou dans la hâte. Tous les pré-requis et toutes les contraintes doivent être prises en compte dans une logique proactive : de la date de lancement de l’implémentation à la date de mise en production du système. Pour une bonne synchronisation, il faut prendre en compte la disponibilité de l’équipe projet par rapport à d’autres projets…
La fixation des délais est une autre paire de manches. Ils ne doivent être ni très longs ni très courts. Certes, réussir l’implémentation de son SIRH dans des délais courts et record est un challenge, mais c’est surtout un fantasme du directeur de projet qui ignore parfois les contraintes auxquelles l’équipe projet est confrontée. Par exemple : on risque de doubler ou de tripler sa charge de travail. On risque également de rater la phase d’étude et de convergence, si elle a été conduite dans la précipitation parce que l’équipe n’aura pas le temps d’exprimer ni d’étudier tous les besoins fonctionnels.
En tout cas, un véritable projet de conduite du changement doit accompagner le projet SIRH car il y a un besoin de temps de familiarisation avec le nouveau système, de temps de rodage, de temps de transfert de compétences… Inutile donc de se précipiter durant les phases d’implémentation surtout qu’on est encore accompagné par l’intégrateur !
Enfin, il ne faudrait ne pas oublier de désigner « un super user » ou principal utilisateur et un super administrateur parmi les membres de l’équipe projet. Ils seront le help desk pour le support en interne après la mise en production et une fois l’intégrateur parti.

Etude et de convergence. Il faut approfondir et prendre le temps nécessaire pour bien définir les besoins fonctionnels (gestion des arrêts maladie, planification des congés, paie…). C’est aussi l’occasion d’apprécier les pratiques RH, les règles de gestion RH, le processus RH et de les améliorer et ce, à travers des groupes de travail. Cette phase pourra être accompagnée par l’assistance à la maîtrise d’ouvrage (AMOA) pour que la définition des besoins soit étudiée et traitée en profondeur. Suite à cela, le cahier des charges définitif sera établi…
Car c’est la base du paramétrage et de la personnalisation du système qui sera testé en phase de recette (tests) et sera opérationnel en phase de mise en production.

La phase de recette (test). Attention ! on ne teste pas si le système marche ou pas. Fonctionnellement et techniquement, il doit marcher ; c’est la première garantie de l’éditeur du SIRH.
On teste plutôt l’exploitation fonctionnelle (et aussi technique) du système par rapport à toutes les personnalisations et paramétrages apportés durant les phases d’implémentation.
Cette phase de test doit être guidée par l’élaboration d’un cahier de tests fondé sur des scénarios de tests fonctionnels. Ces derniers doivent être inspirés des problématiques réelles de l’entreprise. Par exemple, une entreprise qui a un taux de turn-over assez élevé doit tester en profondeur toutes les fonctionnalités liées au processus de recrutement et gestion des départs avec tous les scénarios possibles (nouvelle embauche, réembauche, départ par démission ou par licenciement, etc.)
A la fin de cette phase et après traitement de toutes les anomalies, la date de mise en production peut être enfin arrêtée.