Oracle HCM Cloud Redwood : comment une TMA peut pérenniser et valoriser votre SIRH ?

Le passage en production d’un projet SIRH n’est pas une fin en soi, mais le début de sa véritable vie au sein de l’entreprise. Avec l’avènement de la nouvelle interface Redwood d’Oracle HCM Cloud, cette transition entre la phase de déploiement (Build) et le maintien en conditions opérationnelles (Run) prend une toute nouvelle dimension. De ce fait, la Tierce Maintenance Applicative (TMA) ne se résume plus au traitement des incidents.

Rachel MAALOULY, Consultante Senior et Pilote de Run multi comptes chez SQORUS, décrypte pour nous les enjeux de ce passage en mode support et partage ses bonnes pratiques pour tirer le meilleur parti de la technologie Redwood.

En quoi la technologie Redwood modifie-t-elle l’approche de la TMA par rapport aux générations précédentes ?

La technologie Redwood révolutionne l’expérience métier par une agilité accrue des processus RH. Elle favorise des interactions fluides et décloisonnées entre des modules qui étaient auparavant plus isolés. Sur le plan technique, Redwood permet aux administrateurs de bénéficier de multiples avantages, notamment avec l’intégration de Visual Builder Studio (VBS). Cette console permet de réaliser des paramétrages allant du plus simple au plus complexe, voire même de créer des pages entières, renforçant considérablement l’autonomie des équipes métiers.

Si Redwood ne modifie pas l’approche TMA en tant que telle, il y contribue grandement dans la mesure où les avancées technologiques sont aujourd’hui très rapides. L’approche en silos, où le projet se terminait avant que la TMA ne prenne le relais, n’est plus préconisée. Aujourd’hui, la co-construction est indispensable. Les équipes TMA et Projet doivent donc travailler main dans la main

Quels sont vos conseils vos conseils pour réussir la transition entre l’équipe projet et l’équipe TMA sur Oracle HCM Cloud ?

Pour éviter le syndrome du « mur » entre le Build et le Run, l’anticipation est le maître-mot. Une approche purement séquentielle conduirait inévitablement à l’échec. Voici les quatre piliers fondamentaux recommandés par SQORUS pour une transition fluide :

1. L’intégration en amont : L’intégration des équipes Run (TMA) dès les phases de Build et Care, avant le Go-Live, permet d’assurer la continuité et la pérennité de la solution. Leur présence permet de capitaliser sur les décisions du projet et de finaliser les sujets complexes non résolus.

2. La transmission rigoureuse de la documentation : L’équipe projet peut fournir un historique complet (livrables, matrices RACI, PV…). Par exemple, savoir pourquoi une fonctionnalité a été choisie permet à la TMA d’anticiper son obsolescence potentielle.

3. Une communication réelle et décloisonnée : La TMA ne vient pas faire de l’ingérence dans le projet, elle vient comprendre l’environnement qu’elle devra piloter à 98 % du temps par la suite.

4. L’anticipation des compétences : Nous conseillons une préparation de 2 à 6 mois à l’avance en identifiant les modules à venir et les besoins en experts techniques ou fonctionnels.

Comment la TMA SQORUS gère-t-elle des releases trimestrielles pour qu’elles ne deviennent pas des contraintes ?

Quatre montées de version par an peuvent sembler impressionnantes pour un client. Notre rôle est avant tout de rassurer : nous transformons ces releases en opportunités grâce à une méthodologie bien rodée. Nous commençons par un décryptage technologique de la documentation Oracle pour en faire un retour formalisé au client. Ensuite, nous anticipons grâce à nos clients « early adopters », ce qui nous permet d’anticiper les bugs de régression sur des environnements en avance de phase. Enfin, nous gérons les tests de non-régression tout en créant de la valeur sur la plateforme.

Dans un contexte où la solution évolue en permanence, quel est le rôle de la TMA dans la conduite du changement et l’adoption par les utilisateurs finaux ?

Le rôle de la TMA va bien au-delà de la résolution technique : c’est une mission d’acculturation continue du client. Face à une solution comme Redwood qui évolue tous les trimestres, la formation des utilisateurs n’est jamais vraiment terminée. Et si les clients disposent d’un niveau de maturité élevé, le défi de la TMA est de les challenger et de les orienter.
Si l’accompagnement au changement consiste à aligner les processus RH du client sur les meilleures pratiques standard de l’outil, il faut parfois savoir dire « non » à de fausses bonnes idées. Par exemple, la volonté de tout personnaliser complique drastiquement les futures montées de version. Ce qui n’est pas toujours facile à entendre.

Pourquoi une entreprise aurait-elle intérêt à confier cette TMA à un partenaire plutôt que d’internaliser complètement ce support ?

Confier sa TMA à SQORUS, c’est s’assurer d’une approche qui conjugue technicité et intelligence collective. Là où le marché propose souvent des fonctionnements très segmentés avec un turnover important, SQORUS se démarque par la stabilité de ses équipes. Nous mettons en place un système de Pilote et Co-pilote pour chaque compte. Si l’un fait défaut, l’autre prend le relais. Et comme nos consultants conservent une ancienneté moyenne d’un à deux ans auprès du même client, l’historique relationnel est important. Notre réseau interne représente également un avantage certain. SQORUS a mis en place dès le début une forte synergie entre ses différentes divisions (RH, Finance EPM, IT). Par exemple, si un problème RH est lié à une interface technique complexe, le pilote TMA RH fera immédiatement appel aux experts de la division IT.

Enfin, la force de frappe d’un cabinet expert permet de capitaliser sur les retours d’expérience (Rex). Un avantage concurrentiel majeur, particulièrement dans l’écosystème d’Oracle HCM Cloud. Lorsqu’un de nos clients se trouve confronté à un point de blocage technique ou fonctionnel sur une implémentation ou une customisation spécifique de Redwood, il est hautement probable que ce scénario ait déjà été traité et résolu au sein de notre communauté interne de consultants. Ainsi, le problème, qui pourrait immobiliser une équipe interne non spécialisée pendant plusieurs jours, est souvent résolu en quelques heures par nos consultants ayant déjà géré cette situation chez un autre client early adopter.

FAQ