Les 11 erreurs du projet SIRH (3/3)

Vous arrivez en cours de route ? Suivez le lien pour reprendre les erreurs du projet SIRH depuis le début

8. Perdre de vue les critères prioritaires de choix du futur système cible

Le cahier des charges permettra de définir les fonctionnalités à couvrir, les règles de gestion à mettre en place et les différentes législations en vigueur dans l’entreprise. Il sera néanmoins utile d’identifier les critères de choix de la future solution et donc de définir les points stratégiques de ce choix.

Les priorités se mesurent sur quatre axes :

• Organisationnel.
• Fonctionnel (Fonctions, données et restitutions).
• Intégration dans le SI de l’entreprise.
• Technique.

Ce sont les priorités définies sur chacun de ces axes qui permettront de figer les critères de choix de la solution.

9. Consulter l’ensemble du marché des progiciels

Il est tentant de consulter un grand nombre d’éditeurs. Mais trop de consultations entraîne une charge très lourde et ne permet pas d’approfondir l’étude détaillée des propositions. Il est donc préférable,dans une phase préliminaire, de faire une rapide analyse du marché et de s’en tenir aux seuls progiciels répondant aux priorités qui auront été définies dans la phase précédente.

En conséquence, il convient de :

• Retenir au maximum trois progiciels en phase de consultation.
• Elaborer une grille de réponse qui sera envoyée en annexe au dossier de consultation et sur la base de laquelle les éditeurs seront amenés à répondre. Cette grille sera axée sur les priorités qui auront été définies. Elle sera constituée de questions ouvertes. Elle doit être limitée et doit permettre d’identifier “comment” la fonction ou le concept sera géré.

10. Considérer la mise en place d’un nouveau système d’information RH comme un projet atypique

La mise en oeuvre d’un nouveau système d’information RH doit être abordée comme tout projet de déploiement informatique. Il répond aux mêmes exigences,il est soumis aux mêmes écueils :

• Ne pas mettre en place une structure de conduite du changement adaptée aux enjeux organisationnels et humains.
• Ne pas définir une organisation apte à prendre toutes les décisions nécessaires à l’avancement du projet ; ceci implique un engagement participatif du management.
• Ne pas affecter, sur le projet, les ressources ad hoc avec la disponibilité suffisante, notamment durant les phases de conception et de recette. A titre d’exemple, la phase de recette estimée en moyenne au départ à 20% de la charge du projet, représente en fait 40% de la charge réelle.
• Ne pas considérer la fiabilisation et la reprise des données comme un sous projet à part entière.
• Ne pas se limiter, lors des phases de recette, à la vérification du bon fonctionnement des fonctions sensibles comme la paie par exemple, mais bien s’assurer que l’ensemble des processus du projet est parfaitement couvert.

Des expériences antérieures nous ont prouvé qu’une application correctement recettée permettait de diminuer la charge de maintenance de 80% lors de la première année de fonctionnement.

11. Mettre en place une organisation qui ne soit ni évolutive, ni pérenne

Il est donc nécessaire de :

• Se doter d’une équipe capable de maintenir et de faire évoluer l’ensemble des applications.
• Définir précisément le rôle et les responsabilités des différents intervenants : les utilisateurs, l’équipe de maintenance,l’équipe de production. Ces aspects sont couverts par le biais de contrats de service entre les différentes entités.
• Gérer les aspects règlementaires qui, par définition, sont très évolutifs dans le domaine de la gestion des Ressources Humaines, et nécessitent la mise en place d’une cellule de veille légale qui aura en charge de mettre en oeuvre toute évolution jugée pertinente par l’entreprise, dans le respect du standard du progiciel. Cette cellule se doit de comporter des éléments issus du fonctionnel et de la technique, ce qui permet de conserver une cohérence globale du système d’information.