Projets

La RATP joue une Rhapsodie de sept ans pour refondre son SIRH

Le projet Rhapsodie de la RATP a abouti à la refonte complète du SIRH (système d'information « ressources humaines ») de l'entreprise. Le contexte très particulier de la RATP rendait l'opération particulièrement complexe. Malgré tout, le choix d'un progiciel du marché assez souple (HR Access) s'est révélé être le plus approprié. La bascule s'est effectuée en janvier 2008, après sept ans de travail.

PublicitéQuelle était la situation initiale du SIRH de la RATP ? Pourquoi avoir engagé le projet Rhapsodie pour sa refonte ? Celui dont nous disposions avant le projet Rhapsodie avait été mis en place dans les années 70 en Cobol 68 puis 74 sur des matériels Bull (comme les DPS 9000), et était orienté « gestion administrative ». Il n'y avait aucun historique des emplois occupés (mais juste du déroulé de carrière en terme d'indice hiérarchique), aucune GRH au sens propre. Techniquement, il se composait de très nombreux programmes Cobol gérant de multiples fichiers à plats ou bases de données « réseaux » mais il n'y avait aucune base de données relationnelle dans le système central et l'architecture applicative était de type « plat de spaghetti ». Il n'y avait aucun fichier central de référence mais chaque sous-système disposait de ses propres données mises à jour de façon croisée. Par la suite, a été mis en oeuvre un infocentre sous base de données Oracle qui compilait les données avec un cycle de plusieurs jours. Toutes les évolutions du système étaient évidemment très lourdes et pouvaient impacter des centaines de fichiers. Cela était parfois tellement complexe que certaines réorganisations de l'entreprise furent retardées de plusieurs mois pour nous laisser le temps de mettre à jour le système informatique ! Enfin, dans le cadre du Papy Boum, les agents maîtrisant ces technologies partaient de plus en plus à la retraite. Cet ancien SIRH devenait donc un véritable boulet dans une entreprise en pleine mutation. La complexité même d'une refonte n'a-t-elle pas été le principal obstacle ? Bien sûr. Outre la lourdeur d'une évolution du SIRH, toute la paye était gérée dessus sans aucun droit à l'erreur ou à l'interruption de service. Et il comportait de très nombreux liens avec de multiples applications très sensibles comme, par exemple, la planification des activités des personnels de conduite et de stations. Remettre en cause le SIRH, c'était remettre en cause un tiers du SI ! La première refonte massive d'applications sous les anciennes technologies a concerné le SI financier. Celui-ci a été basculé sous Oracle Applications puis nous avons eu à gérer le passage à l'an 2000. Ce n'est qu'à partir de 2001 que nous avons pu nous pencher sur le SIRH pour un chantier qui a duré jusque fin 2007. Quels objectifs ont été fixés au projet Rhapsodie ? La Direction Générale a fait preuve d'un soutien sans faille le long de ces sept années mais avait fixé, avec la DSI, deux objectifs techniques et managériaux : une forte conduite du changement intégrant une redéfinition des processus RH et une urbanisation du système d'information, le développement d'une offre pour le management avec des outils améliorés d'aide à la décision et au pilotage. Pourquoi avoir opté pour un progiciel du marché malgré votre situation très spécifique ? Quels autres choix techniques avez-vous effectués ? La véritable question de fond, dès le départ, était en effet de choisir entre un progiciel du marché et la réalisation d'un nouveau spécifique. Les spécificités de la RATP sont très fortes : régime social spécial, nombreux métiers générant des règles de gestion spécifiques ... En 2001, nous avons donc commencé par une étude pour savoir si l'option d'un progiciel du marché était possible et, dans l'affirmative, choisir le bon progiciel. Nous avons étudié les principaux produits du marché : SAP a été écarté car (du moins à l'époque) il imposait des règles trop contraignantes, PeopleSoft disposait d'un module de paye insuffisant par rapport aux besoins... Notre choix s'est porté sur HR Access. Puis nous avons validé ce choix en 2001 via un prototypage, autant sur le plan technique que sur celui de la réponse aux besoins métier, ainsi que sur la capacité du progiciel à communiquer avec les autres logiciels de notre SI. Si cela avait échoué à ce stade, nous serions partis sur un produit spécifique. Nous avons donc acquis les licences nécessaires et nous avons poursuivi. Un des grands avantages offerts par HR Access était son architecture intégrée faisant reposer l'ensemble des traitements sur une base de données unique. Nous avons ainsi pu constituer la base de données agents de référence pour toute l'entreprise. Le coeur du progiciel, en particulier le moteur de paye, est réalisé en Cobol généré. L'architecture mise en oeuvre respectait les préconisations de la DSI : SGBD Oracle, interface web Java et système d'exploitation Unix. Aujourd'hui, nous réalisons nos applications plutôt sous Linux et PostGreSQL mais, dans le cas d'un progiciel, nous sommes obligés de prendre en compte la politique de l'éditeur. L'infocentre du SIRH a été réécrit avec ReportNet de Cognos dans une architecture de type Datawarehouse. Après la validation du choix technique, avez-vous opté pour une évolution progressive ou bien un big bang ? Pour commencer, nous avons choisi de mettre en oeuvre un module (celui consacré à la formation) pas très complexe mais nécessitant malgré tout la constitution du référentiel des agents qui serait utilisé ensuite. Cela nous a permis de valider nos méthodes sur un module moins sensible que la paye. Nous avons mis en oeuvre le module de gestion de la formation en 2003. Pour la suite, le découpage du système d'information RH existant ne se recoupant pas, bien entendu, exactement avec les fonctions des modules HR Access, une migration progressive aurait été très complexe, imposant la réalisation de nombreuses interfaces frustrantes et surtout des évolutions lourdes sur le SI existant. Nous avons donc opté pour une mise en oeuvre globale des modules de paye et de gestion administrative. Malgré tout, pour éviter l'effet tunnel (plusieurs années sans avancées significatives), la direction a demandé au projet de livrer régulièrement des outils d'aide au pilotage et de mener des expérimentations sur des unités pilotes (avec des versions prototypes) permettant de mesurer la faisabilité et l'acceptabilité des changements de processus. Simultanément, nous avons effectué une urbanisation du SI. Ceci nous a conduit à définir précisément la répartition des fonctions et des responsabilités entre le SI RH et les autres SI de l'entreprise, à identifier des objets métiers génériques (regroupement de données permettant de représenter les informations telles que nécessaires aux SI tiers), réaliser les référentiels portant ces objets et les mécanismes d'accès à ces référentiels. Ce travail nous a permis de piloter les évolutions nécessaires sur l'ensemble des systèmes sur toute la durée du projet, en évitant les remises en cause « existentielles » en cours de développement. Désormais, les systèmes tiers sont interfacés au travers de grands référentiels intermédiaires et de mécanismes d'échanges standardisés pour éviter de retrouver nos bons vieux plats de spaghettis... En 2005-2006, nous avons effectué une conception détaillée du nouveau SIRH et la réalisation en 2006-2007. Nous avant eu en parallèle à gérer d'importantes évolutions sur le système existant, le gel total des évolutions durant la durée du projet étant impossible sur un domaine soumis à des décisions réglementaires, sociales et organisationnelles. Janvier 2008 était une date impérative de bascule. En effet, il était exclu d'effectuer une bascule en cours d'année, car cela aurait conduit, par exemple, à devoir gérer les traitements réglementaires annuels de paye sur 2 systèmes. De ce fait, un retard d'un mois ou deux aurait signifié un retard d'un an. De plus, la volonté de stabiliser néanmoins au minima le système existant dans la dernière année de la réalisation avait conduit la direction à repousser à l'arrivée du nouveau système la mise en place de certains mesures. Enfin, l'importance du changement porté à l'occasion de la mise en place de Rhapsodie avait nécessité une formation lourde de plusieurs centaines de personnes. Un retard était donc exclu pour ces raisons. Quelle gestion de projet avez-vous mis en oeuvre ? Le SIRH étant très sensible avec une obligation de flexibilité et de réactivité aux demandes d'évolution de l'entreprise (organisationnelles, réglementaires ou sociales), nous avons opté pour une maîtrise interne du projet. Ainsi, bien que nous ayons choisi une prestation de réalisation externe en nous appuyant sur IBM, à l'époque éditeur de HR Access, les équipes IBM (jusqu'à 80 prestataires simultanés) travaillaient sur le même plateau que la maîtrise d'ouvrage et la maîtrise d'oeuvre de la RATP. Le pilotage des travaux faisait l'objet d'un suivi serré et quotidien. Nous n'avons pas eu à déplorer de clash sérieux ou de difficultés que nous n'ayons pas su surmonter sur les sept ans du projet grâce à cette intégration des équipes. L'organisation dynamique du projet (en terme d'instances et de pilotage des travaux) a naturellement évolué au cours des phases selon que nous étions dans des phases de construction de l'architecture, de réalisation de la solution ou de préparation du démarrage, la réactivité demandée et la nature des décisions à prendre n'étant pas la même. Quels ajouts métiers Rhapsodie a-t-il permis ? Tout d'abord, cela nous a permis de mettre en adéquation le SI RH avec la réalité de l'entreprise (prise en compte de la décentralisation) et de passer d'un système essentiellement administratif à un vrai système d'information RH. Il s'agissait d'une condition nécessaire pour accompagner l'évolution du processus métier RH. En terme de pilotage, le nouvel infocentre sous ReportNet de Cognos offre, outre les données élémentaires provenant du SI RH, des données plus élaborées permettant l'établissement de tableaux de bord très riches à destination des gestionnaires et des managers. Quel est le coût et le ROI de ce projet ? Le taux interne de rentabilité de l'investissement est de 12% et, tout en augmentant le service rendu de la fonction RH aux managers et aux salariés, 300 emplois seront à terme redéployés.