Nous l’avons vu dans de précédents articles : il est intéressant et rentable de connecter la GTA à différentes applications d’entreprise et pas qu’à la paie. Cette intégration n’est cependant pas sans risque et coûte en général bien plus cher que ce qu’on imagine initialement, au déploiement et dans la vie de l’application. Comment limiter les dérives ?
On ne le dira jamais assez : intégrer la GTA dans le SI de l’entreprise est une partie coûteuse et risquée d’un projet de gestion des temps, encore plus dans les grandes organisations. On peut même dire que c’est souvent un projet dans le projet qui peut représenter jusqu’à 50 % du budget global.
Pour réussir cette intégration et garantir une maintenance de qualité, il est indispensable de respecter plusieurs phases.
Intégration de la GTA : de quoi parle-t-on ?
Dans l’esprit des DRH ou des responsables SIRH, intégrer leur outil de GTA à la paie et à la gestion des intérimaires est une évidence. Mais d’autres communications automatiques sont en général mises en place avec un éventail bien plus large d’applications d’entreprise, qu’il s’agisse de la planification métier, de l’ERP, du contrôle des accès, de la monétique, ou encore des agendas électroniques.
Ces échanges de données sont souvent mis en œuvre progressivement, au fil des années et au gré des changements de logiciels métier. Il en résulte assez souvent une architecture complexe, difficile à maintenir et parfois peu documentée. Or, la gestion des temps est par nature un domaine très évolutif. Le coût de l’intégration de la GTA dans le SI d’entreprise et de sa maintenance dans la durée est souvent sous-estimé. Par conséquent, les ressources internes sont rarement dimensionnées à hauteur de la charge réelle.
- Cet article pourrait aussi vous intéresser : Intégration de la GTA au système d’information, limites et avantages
Recenser tous les flux nécessaires lors des spécifications
Dans l’urgence des projets, il est tentant de se dire que l’on va scinder les spécifications fonctionnelles d’un côté et les spécifications des interfaces de l’autre. Cependant, les relations entre ces deux aspects imposent souvent dans la réalité de les mener de front, à la fois pour codifier et structurer les données de façon cohérente entre les différentes briques du SI, mais aussi pour décider de la hiérarchie des flux : quel module est maître de la mise à jour de telle donnée, avec quelle fréquence, avec quelles contraintes organisationnelles ?
Il s’avère aussi nécessaire de penser les flux dans leur ensemble. Dans la réalité, on a tendance à privilégier les flux les plus visibles, tout particulièrement ceux avec la paie ou l’ERP. Mais urbaniser le SI à la GTA de façon cohérente impose de voir les flux de façon globale en recensant toutes les applications et données concernées par des communications automatiques.
Ne pas faire ce travail en début de projet expose à des risques sur les processus de mise à jour des données ou à des codifications incohérentes entre les différents modules.
- Cet article pourrait aussi vous intéresser : Gestion des temps standard vs spécifique, comment gérer les exceptions ?
Tester et retester les interfaces
La réalisation des flux ayant été faite, il ne faut pas sous-estimer le temps nécessaire pour vérifier que les échanges sont conformes. C’est particulièrement vrai de la communication avec la paie qui tolère assez mal les approximations en raison des risques sur le climat social en cas d’erreurs sur les fiches de salaire. Même si les flux de communication sont normalisés entre l’éditeur de GTA et celui de paie, cela ne garantit pas que les données échangées sont parfaitement conformes.
Il peut toujours subsister des problèmes de codification, de mapping de rubriques ou de calcul tout simplement. Pas d’autre solution que de tout tester en s’appuyant sur des jeux d’essai exhaustifs avec la paie, mais également avec toutes les autres applications connectées.
À noter aussi que la partie technologique des échanges mérite d’être soigneusement vérifiée. Que se passe-t-il en cas de rupture de communication ou de transfert partiel ? Quelles procédures de reprise ou traitement par exception sont possibles ? Comment sont gérées les corrections a posteriori, une situation fréquente et assez typique de la GTA ?
Les erreurs en paie sont très mal vécues par les salariés. S’ils peuvent se montrer compréhensifs lors d’un changement de système, leur patience trouve assez vite des limites si ces anomalies perdurent au-delà de 2 ou 3 mois. À noter aussi que les erreurs dans les interfaces nécessitent des corrections manuelles, et l’on peut se retrouver rapidement submergé par le nombre.
Le temps passé à faire et parfaire les tests d’intégration est parfois vécu comme fastidieux par les services RH lors du déploiement. Il n’en reste pas moins incontournable et l’expérience montre que c’est un très bon… investissement.
S’assurer des interfaces lors des montées de version
Garantir la continuité des échanges de données est une difficulté courante lors des montées de version d’une solution de GTA. Si les flux principaux sont souvent identifiés et documentés (typiquement la paie et l’ERP), il n’en est pas de même des flux moins visibles mis en place au fil des années et, parfois, totalement oubliés. Les difficultés apparaissent très souvent une fois que la montée de version de la GTA est effectuée avec des échanges qui ne fonctionnent plus : la mise à jour d’employés dans le système de contrôle d’accès, la connexion avec l’infocentre de l’entreprise, la récupération de contrats depuis la gestion d’intérimaires, etc.
Pour éviter ou limiter ces risques, il est indispensable de :
- recenser et de documenter tous les flux mis en place de ou vers la GTA ;
- vérifier avant chaque montée de version l’impact sur les flux existants ;
- mettre en place un environnement de test pour vérifier la continuité des échanges ;
- prévoir les ressources et le temps nécessaire pour la validation des communications.
Prévenir les pertes de compétences
Un groupe de 12 usines a récemment découvert que seule une personne dans son organisation maîtrisait toutes les communications mises en place de ou vers la GTA, et que les dizaines d’interfaces mises en place dans les sites au fil des années n’étaient documentées que de façon sommaire.
Comme c’est souvent le cas, cette prise de conscience s’est effectuée le jour où cet informaticien a posé sa démission, alors que lui-même alertait son employeur depuis longtemps sur les risques posés par une telle situation. Car non seulement il gérait la maintenance de toutes ces communications, mais il assurait par ailleurs la relation avec tous les éditeurs concernés, un point crucial pour prévenir les difficultés et anticiper les évolutions.
Ce cas est loin d’être isolé et la perte de compétence sur les communications entre la GTA et les autres applications peut devenir très critique. Il faut en effet recruter et former en urgence un nouveau spécialiste, retisser les liens avec les éditeurs, trouver des compétences et des solutions palliatives en cas de dysfonctionnements.
S’il n’existe pas de solution miracle, on peut néanmoins limiter les risques en :
- formant plusieurs personnes en interne et en maintenant la compétence dans la durée par une formation continue ;
- maintenant un lien durable avec les éditeurs qui interviennent dans les échanges de données avec la GTA, car eux aussi peuvent subir des pertes de compétences ;
- industrialisant tant que faire se peut les communications ;
- définissant des règles contractuelles claires entre les parties prenantes (qui fait quoi et comment), car, en cas de difficultés dans les échanges de données, les renvois de responsabilité sont la règle.
