Ça y est, on a identifié nos macros besoins et les acteurs qui y répondent. (Cf Comment choisir sa solution de GTA ?)

Il nous faut alors passer sur une étape micro : le cahier des charges !

Composition du cahier des charges.

Alors que mettons dans un cahier des charges ? C’est finalement le premier cadrage du projet à venir. On va donc identifier les services et les SI impactés (MOA RH, MOE IT, MOA Métier…).

On fera donc un chapitrage par grande problématique :

• Les enjeux du projet.
• Les acteurs du projet.
• Les besoins.
  • Architecture technique et pré-requis.
  • les besoins fonctionnels et la présentation des processus RH.
  • la cartographie des flux.
• Détail du réglementaire.
• Liste des exigences
• Critères de sélection.

Les processus RH.

Cette partie, souvent négligée, est impérative pour un choix posé et d’avenir pour une solution de GTA. En effet, les processus vont indiquer quand, comment et pourquoi les différents acteurs vont utiliser la solution.

L’impact de ces processus doit se traduire en termes ergonomique et de synoptique d’utilisation. L’enjeux derrière est le temps d’utilisation et la facilité de compréhension de la solution.

Les processus organisationnels

Quels sont les principaux processus :

• Création d’un site.
• Changement de convention collective
• Réorganisation structurelle.
• Fusion/Acquisition et cession.
• …

Focalisons nous sur la création d’un site…

A ce jour, je ne connais pas de solution qui va nous permettre de réaliser ce processus de façon fiable, genre processus guidé. En effet, la création d’un site va nécessiter un ensemble de paramétrage (le site, les structures organisationnelles, les roulements, les accès manager et RH…). Et pourtant, tant que ce paramétrage ne sera pas cohérent avec le réglementaire et ses prérequis mais aussi cohérent avec les processus RH, je ne pourrais pas utiliser ce site.

Les processus RH

Voici une liste non exhaustive de processus RH :

• La création d’une ressource (CDI, CDD, Interim)
• La mutation.
• Le prêt de personnel
• la gestion des absences
• la mise à disposition
• …

La encore, focalisons nous sur un cas : la gestion des absences. En théorie c’est assez simple, mais par exemple si l’employé est un manager, cela nécessite de gérer son « remplacement ». Autre cas, l’activité de l’entreprise peut nécessiter aucune réduction de charge (exemple l’été sur la côte, on est même en surcroît de charge), alors toute absence devra être « remplacée ».

Le réglementaire

C’est au départ et au final l’enjeux du projet. Il convient donc de décrire parfaitement l’ensemble des objets à intégrer. (J’utilise le mot objet à bon escient : il provient d’une façon de programmer des années 90. On programmait un ensemble, les compteurs et les règles de calculs en un tout cohérent et autonome).

Voici encore une fois une liste non exhaustive :

• Les compteurs de présence (badgeages, retards, heures effectives, heures validées, heures en plus, heures supplémentaires/complémentaires…).
• Les compteurs d’absences (CP, RTT, COR/CRN, RECUP, MALADIE…).
• Les compteurs d’événements (déplacements, mission, délégation…)
• Les compteurs de primes (Heures de nuit, habillage, salissure, froid…).
• les alertes légales, conventionnelles.
• Les compteurs analytiques ou budgétaires…

Pour chacun de ces cas, il faudra décrire les entrants, ce sont les éléments déclencheurs du calculs (ex Article 36), les calculs déjà réalisés utilisés en entrants, les règles de calculs nominales (il peut y en avoir plusieurs en fonction du site/convention collective/accord local), les cas particuliers (proratisation).

C’est à cette étape que l’on se rend compte sur les gros groupes, que certaines zones de flou existent. A cela on rajoute, l’usage qui prévaut sur l’accord.

Pourquoi ce niveau de détail ?

• Car cela permet de dimensionner le projet pour l’intégrateur et il peut s’engager.
• Mais surtout cela permet d’identifier les zones de flou qu’il faudra régler durant la phase de spécification détaillée du projet.
• Enfin d’un point de vu budgétaire, cela pose la question d’une réponse manuelle pour les cas particuliers.

Votre niveau de détail va dégager des exemples qui pourront être illustrés par le prestataire lors de sa démo…

La liste des exigences

Cette liste est importante : elle n’a qu’un but au regard de la maturité des solutions du marché, disqualifier les solutions qui n’auraient pas la ou les fonctionnalités ayant le ROI attendu.

On trouvera les exigences de chaque acteur : techniques, fonctionnelles, ergonomique (utilisateurs), le support, la documentation.

A ce titre, il est assez rare que la RoadMap éditeur soit dans les exigences pour autant, le choix qui devra être fait porte sur une convergence a court terme mais aussi a long terme.

Ça y est, une fois relus, vous êtes prêt à envoyer votre cahier des charges et à passer à la phase suivante. A ce stade, vous avez fait le plus dur : être honnête, exhaustif… Les réponses seront donc au niveau ne votre cahier des charges.