Pourquoi une analyse de risques et comment prévenir ?

Une analyse de risques au niveau de l’étude de cadrage permet d’anticiper certaines difficultés pouvant intervenir dans le cadre d’un projet de mise en œuvre. C’est également un outil de communication au niveau de l’équipe projet « maitrise d’ouvrage » permettant une prise de conscience collective des écueils.
N’oublions pas le point mentionné ci-dessus dans la rubrique « Qui choisir comme utilisateurs clefs »
La réussite d’un projet SIRH est directement liée à l’équipe participant au projet

Les principales causes de disfonctionnements d’un projet SIRH sont liées à un problème de disponibilités des ressources tant sur la partie maitrise d’ouvrage que sur la partie maitrise d’œuvre.

Les risques potentiels peuvent être :

• Au niveau de la maitrise d’ouvrage car les utilisateurs clefs participant au projet sont trop pris par leurs tâches quotidiennes et ont beaucoup de difficultés à dégager du temps pour leur projet. Or ils constituent une pièce maitresse dans la mesure où ils sont d’une part les seuls à avoir la connaissance des règles et processus RH et d’autre part les seuls à être aptes à prendre des décisions. Il est donc nécessaire de s’assurer de cette disponibilité,
• Au niveau de la maitrise d’œuvre. Les intégrateurs et/ou éditeurs présentent généralement en avant vente l’équipe future du projet. Ce sont souvent des experts ayant beaucoup d’expérience tant sur le plan du domaine traité que sur le progiciel SIRH retenu. Mais quelles garanties à l’entreprise de disposer de cette équipe dans la durée de son projet ? Il nous semble nécessaire contractuellement de veiller à s’assurer de ce point. En effet, certains progiciels sont actuellement en pénurie de ressources sur le marché.
• L’absence de communication sur le projet. C’est un point essentiel. Un projet en construction ne doit pas rester sans communication auprès des utilisateurs qui seront amenés à utiliser l’outil. Un rejet de leur part lors de la mise en exploitation de l’outil peut avoir des incidences importantes. Il faut qu’ils aient le sentiment, même s’ils ne participent pas au projet, d’être concernés et informés des décisions prises et de son état d’avancement. Une lettre d’information mensuelle par exemple sera la bienvenue.
• Le Change Management est fondamental et c’est souvent cette partie qui n’est pas traitée dans le projet dans sa phase importante (faute de budget car on arrive au terme du projet) : le déploiement de la solution. Il est en effet nécessaire de former et d’accompagner les utilisateurs lors de la mise en exploitation de l’outil.
• Au niveau du progiciel. Certaines besoins constituent des éléments structurants qui ne pourront pas être traités par du paramétrage ou des développements spécifiques (à éviter). Je pense notamment à des fonctionnalités comme la paie multiple, la gestion de la rétroactivité, les processus RH décentralisés via l’intranet, la gestion des multi-contrats, les mutations de collaborateurs en cours de période mensuelle, la gestion des organismes de formation, la gestion de l’organisation (structure arborescente décrivant l’organisation fonctionnelle et juridique de l’entreprise), le processus d’évaluation des collaborateurs,….
• Au niveau du budget. En principe, le budget du projet est connu au moment de la signature avec le prestataire. Des dérives sont néanmoins toujours possibles (fonctionnalités omises dans le cahier des charges, mauvaises évaluation de la charge par le prestataire, ….). Des avenants sont relativement fréquents dans les projets de mise en œuvre.