Cahier des charges : Gestion des Temps et de …€¦ · Web viewAttention, même si le cahier des charges est détaillé il ne peut être envoyé tel quel pour un appel d’offre

Cahier des charges : Gestion des Temps et de l’Activité

document.docx

TABLE DES MATIÈRES1 Avant-propos.....................................................................................................................4

1.1 Comment utiliser le cahier des charges........................................................................41.2 Cadrer le projet..............................................................................................................4

2 PRESENTATION DE L’ENTREPRISE..............................................................................6

2.1 La mission, les activités.................................................................................................62.2 Présence de l’entreprise................................................................................................6

3 OBJECTIFS ET PERIMETRE DU PROJET......................................................................7

3.1 Les objectifs et enjeux de changement.........................................................................73.2 Le périmètre organisationnel du projet..........................................................................73.3 Le périmètre fonctionnel du projet.................................................................................8

4 DESCRIPTION DE L’ORGANISATION ET DES ACTEURS............................................9

4.1 Les instances du projet.................................................................................................94.2 La gouvernance métier..................................................................................................94.3 L’organisation du projet...............................................................................................10

5 DESCRIPTION DU SYSTEME D’INFORMATION..........................................................11

5.1 Les principaux outils SIRH actuels..............................................................................115.2 Le schéma directeur cible...........................................................................................115.3 Le projet GTA dans le schéma directeur SIRH...........................................................11

6 MACRO PLANNING DU PROJET GTA..........................................................................127 DESCRIPTION DES BESOINS GTA..............................................................................13

7.1 Gestion des dossiers des collaborateurs....................................................................137.2 Planification.................................................................................................................13

7.2.A Le planning........................................................................................................147.2.B Profil horaire ou Journée type...........................................................................157.2.C Cycle de travail..................................................................................................157.2.D Activité...............................................................................................................167.2.E Autres éléments impactant la planification........................................................16

7.3 Calendrier des jours particuliers..................................................................................177.4 Les éléments variables................................................................................................17

7.4.A Heures supplémentaires et repos compensateur.............................................177.4.B Titres Restaurants.............................................................................................187.4.C Gestion automatique des majorations et primes...............................................18

7.5 Planification sous contrainte........................................................................................197.6 Populations..................................................................................................................20

7.6.A Gestion du personnel externe...........................................................................207.6.B Forfait jour (cadres)...........................................................................................207.6.C Horaires mensuels (employés, maitrises, cadres)............................................207.6.D Modulation.........................................................................................................207.6.E Personnel externe (intérimaire, prestataire)......................................................21

P a g e 1 | 63

document.docx

7.7 Les Absences..............................................................................................................21

7.7.A Liste des absences attendues...........................................................................217.7.B Fonctionnement des absences.........................................................................227.7.C Recueil de présence..........................................................................................23

7.8 Les compteurs.............................................................................................................23

7.8.A Compteurs Congés Payés................................................................................237.8.B Compteurs Congés de fractionnement.............................................................247.8.C Compteurs Congés d’ancienneté......................................................................247.8.D Compteurs Congés RTT, JNT...........................................................................247.8.E Compteurs absences conventionnelles............................................................257.8.F Compteur des repos compensateurs................................................................257.8.G Autres contingents d’absences et de présences...............................................27

7.9 Gestion du CET...........................................................................................................277.10 Reporting.....................................................................................................................287.11 Les alertes...................................................................................................................29

7.11.A Les types d’alertes............................................................................................297.11.B Workflow en cas d’alerte...................................................................................29

7.12 Traçabilité....................................................................................................................307.13 La signature électronique............................................................................................30

8 SELF SERVICE GESTION DES TEMPS........................................................................31

8.1 CET.............................................................................................................................318.2 Planning......................................................................................................................318.3 Gestion des absences / présences et éléments variables..........................................318.4 Le workflow.................................................................................................................328.5 Gestion des compteurs...............................................................................................32

9 POINTAGE......................................................................................................................3310 CONTROLE D’ACCES................................................................................................3511 INTERFACES..............................................................................................................37

11.1 Les différentes interfaces............................................................................................3711.2 Echanges entre le SIRH et les autres applications.....................................................37

12 PRESTATIONS DE SERVICE ATTENDUES..............................................................38

12.1 La solution...................................................................................................................3812.2 Périmètre de la prestation...........................................................................................3812.3 Maintenance légale et conventionnelle.......................................................................38

13 PRINCIPES DIRECTEURS D’ARCHITECTURE.........................................................39

13.1 Mode progiciel.............................................................................................................3913.2 Solutions Saas............................................................................................................3913.3 Principes d’intégration dans le SI................................................................................3913.4 Supervision des flux inter-applicatifs...........................................................................4013.5 Intégration avec le portail de l’entreprise....................................................................4113.6 Poste de travail/Mobilité..............................................................................................4113.7 Messagerie..................................................................................................................42

14 SECURITE APPLICATIVE ET QUALITE DES TRAITEMENTS..................................43

14.1 Authentification............................................................................................................43

P a g e 2 | 63

document.docx

14.2 Gestion des mots de passe.........................................................................................4314.3 Provisioning des identités utilisateurs.........................................................................4314.4 Gestion des habilitations et provisionning...................................................................4414.5 Protection des données...............................................................................................4414.6 Qualité des données...................................................................................................4414.7 Auditabilité...................................................................................................................4414.8 Service-Level Agreement (SLA) et maîtrise des SLA.................................................4514.9 Supervision de la disponibilité des applications..........................................................4514.10 Supervision traitements........................................................................................4514.11 Service Level reporting.........................................................................................4614.12 Protection physique des données.........................................................................4614.13 Réversibilité..........................................................................................................46

15 PERFORMANCE.........................................................................................................48

15.1 Contraintes réseaux....................................................................................................4815.2 Exigences de temps de réponse.................................................................................4815.3 Supervision de la performance....................................................................................48

16 PRESTATIONS TECHNIQUES...................................................................................49

16.1 Tests de performance.................................................................................................4916.2 Maintenance et support applicatif...............................................................................49

P a g e 3 | 63

document.docx

1 AVANT-PROPOS

1.1 Comment utiliser le cahier des charges

Attention, même si le cahier des charges est détaillé il ne peut être envoyé tel quel pour un appel d’offre. En effet, ce sont des informations générales et non propres à votre organisation. Pour l’adapter à votre structure, vous trouverez des zones à remplir. Ces zones sont facilement reconnaissables elles se présentent sous cette forme : [texte à modifier]. Des conseils, indications sont présents tout le long du cahier afin de vous aider à le compléter. De plus, nous vous faisons des propositions que vous pouvez garder ou bien supprimer. Le cahier comprend à la fois les données fonctionnelles et les données techniques.Dans II Cadrer le projet, vous trouverez un tableau récapitulatif des grands thèmes présents dans le cahier. Vous pouvez, à votre guise laissé ce tableau lors de l’envoi auprès de l’éditeur car il permet d’avoir rapidement une idée de l’ampleur du projet. Les thèmes sont sous forme de lien hypertexte afin de vous permettre d’accéder plus rapidement à la partie concernée. Ce lien vous permettra de compléter le chapitre et de connaître le détail des parties.

1.2 Cadrer le projet

Ci-dessous les besoins fonctionnels décris dans le cahier des charges.

Le dossier du personnel ☐

La planification (profil horaire, cycle de travail, planning) ☐

Calendriers des jours (exemple jours fériés, …) ☐

Les éléments variables ☐

La planification sous contrainte ☐

Les populations ☐

Gestion des absences ☐

Gestion des compteurs ☐

Gestion du CET ☐

Rapport / requête ☐

P a g e 4 | 63

document.docx

Les alertes ☐

Traçabilité de l’activité ☐

Signature électronique ☐

Le portail : la gestion du CET ☐

Le portail : la gestion des planning ☐

Le portail : la gestion des absences, présences et des éléments variables ☐

Le portail : le workflow ☐

Le portail : la gestion des compteurs ☐

P a g e 5 | 63

document.docx

2 PRESENTATION DE L’ENTREPRISE

2.1 La mission, les activités

[A compléter avec la présentation de votre entreprise : vous pouvez mettre le CA, l’effectif…]

2.2 Présence de l’entreprise

[A compléter avec les informations de votre entreprise : l’organisation, la localisation, les sites, groupe, France, Europe, international…)]

P a g e 6 | 63

document.docx

3 OBJECTIFS ET PERIMETRE DU PROJET

3.1 Les objectifs et enjeux de changement

L’objectif global du projet est la mise en œuvre d’un outil de planification et de gestion des temps permettant de faciliter la gestion quotidienne des managers, des salariés, et des services Ressources Humaines.

Les principaux objectifs du projet sont :

Sécuriser les actes de gestion et gagner en productivité ; Mettre fin aux suivis « manuels », à la gestion « papier » et aux saisies multiples et

redondantes entre la paie et les différents fichiers « Excel » ; Automatiser les accords d’entreprise pour en éviter les interprétations multiples et diverses

dans leurs applications sur les différents sites ; Simplifier et améliorer l’architecture actuelle pour gagner en efficacité (planification, gestion

des temps, paie) aussi bien pour les opérationnels que pour les ressources humaines (RH) ;

Garantir le respect de la réglementation du travail ; Permettre une gestion prévisionnelle des plannings ; Partager les règles de gestion et les bonnes pratiques ; Faciliter le pilotage et le reporting pour les opérationnels et pour les RH ; Donner de la visibilité en temps réel sur les temps et activités (prévisionnel et réalisé) ou

encore sur les compteurs d’absences et de présence ; Fiabiliser les données constitutives de la paie ; Faciliter l’application et le suivi des règles du travail.

3.2 Le périmètre organisationnel du projet

Les conventions collectives :

IDCC Convention collective

La population gérée dans le futur SIRH : [Remplir le tableau suivant avec les entités concernées par le projet.

P a g e 7 | 63

document.docx

Dans le tableau, inscrire « optionnel » permet de ne pas exclure d’office un éditeur. On peut par exemple écrire « optionnel » pour une entité ayant un réglementaire autre que français et ayant peu de collaborateur.]

Optionnel / Obligatoire Société Entités Etablissements Effectif Pays

La gestion des sociétés optionnel devra faire l’objet d’un coût séparé « en option » dans la synthèse financière du soumissionnaire.

3.3 Le périmètre fonctionnel du projet

L’entreprise souhaite disposer d’un système de Gestion des temps avec les fonctionnalités suivantes (chaque module devra embarquer un moteur de workflow) : [supprimer les fonctionnalités qui ne vous concernent pas ou inversement, rajouter si vous souhaitez d’autres fonctionnalités]

Dossier collaborateur ; Gestion des alertes ; Réalisation de reporting ; Gestion des temps ; Gestion de l'activité ; Gestion de l’absentéisme ; Gestion du présentéisme ; Gestion de la modulation / annualisation ; Gestion des forfaits jours ; Gestion des titres restaurant ; Gestion des instances représentatives du personnel (IRP) ; Gestion des habilitations (limiter les accès en fonction du profil utilisateur) ; Gestion des compteurs d’heures ; Gestion des absences ;

P a g e 8 | 63

document.docx

Portail des absences ; Gestion de la planification ; Gestion du personnel externe ; Gestion de mot de passe ; Gestion de l'accès ; Gestion des interfaces ; Planification sous contrainte.

P a g e 9 | 63

document.docx

4 DESCRIPTION DE L’ORGANISATION ET DES ACTEURS

4.1 Les instances du projet

Les instances de décision du projet sont les suivantes :[Détailler les instances de gouvernances du projet]

4.2 La gouvernance métier

La gouvernance métier repose sur des profils clés : [Modifier si les informations ne correspondent pas à votre gestion de projet et compléter la charge de travail]

ACTEURS METIER

CHARGE (EN %) VISION MISSION

SPONSOR 10% jusqu’à 30% durant certaines phases

Stratégique Responsable de l’alignement et du bon fonctionnement des processus clésDéfinit une feuille de route des changements stratégiques à mener pour assurer l’efficacité des processusAnime les communautés en interaction pour faciliter et garantir l’identification et l’évaluation des besoins, la priorisation et le déploiement des changements

Directeur de projet

Stratégique / Opérationnel

Analyse en continu les processus existants pour identifier de nouvelles opportunités

P a g e 10 | 63

Nom de l'instanceFréquence des réunionsRôle

Comité de pilotageTrimestrielTiens les objectifs du projets, valide les changements, suis l'avancement

Comité de projetMensuelOrienter, promouvoir, livrer, implémenter

document.docx

d’améliorationSupervise l’environnement métier (IT, juridique, concurrentiel) et identifie les opportunités et menaces potentielles sur les processus existantsAssure l’identification, l’analyse et la redirection vers les bonnes personnes des incidents liés aux systèmes et des demandes d’évolutions

Chef de projet

Opérationnel S’assure que la conception du processus et du système d’information réponde aux besoins métiersRevoit, discute et donne des directions sur la conception du processus en collaboration avec le sponsor et les directeursPilote les équipes mobilisées autour de la conception, la réalisation, les tests et le déploiement du processus visé et de la solution

Réfèrent METIER

Stratégique / Opérationnel

Représente les besoins d’un métier, connaît le processus complet sur son métierSuit les développements, les tests et l’implémentation de la solution technique, et valide l’adéquation du produit avec les besoins définis

Les soumissionnaires devront présenter leur organisation projet et l’équipe projet miroir à celle mise en place.

4.3 L’organisation du projet

[Modifier en fonction de votre organisation de travail]

P a g e 11 | 63

document.docx

P a g e 12 | 63

Sponsor

Chef de projet Référent technique Référent métier

Directeur

document.docx

5 DESCRIPTION DU SYSTEME D’INFORMATION

5.1 Les principaux outils SIRH actuels

[Remplir le tableau et détailler les données]

Sociétés Outils

Paie

Formation

5.2 Le schéma directeur cible

Le projet GTA s’inscrit dans le cadre du schéma directeur SIRH.[Exemple à adapter]

5.3 Le projet GTA dans le schéma directeur SIRH

[Réaliser le Schéma directeur visé]

P a g e 13 | 63

GTAPaie

Echange de données

document.docx

Les éditeurs préciseront leur mode de fonctionnement pour l’alimentation et la synchronisation des dossiers et des référentiels GTA avec les systèmes ci-dessus.

P a g e 14 | 63

document.docx

6 MACRO PLANNING DU PROJET GTA

Le déploiement de la solution consistera : [Choisir le mode de déploiement vous correspondant entre les deux propositions ci-dessous en rouge]

À passer en production (utilisation de l’ancienne et la nouvelle solution) quelques sites pilotes pendant 2 à 3 mois puis de déployer les autres sites en mode « Big Bang »

A réaliser un déploiement en mode « Big bang »

Le soumissionnaire fera une préconisation de déploiement appropriée au contexte du projet.La consultation est composée du lot « Gestion des temps et activités ». L’éditeur devra se positionner sur l’ensemble des fonctionnalités attendues.

[Compléter le tableau en fonction des lots attendus]

Lot Obligatoire / option Description Pays Date limite de mise en

production souhaité

1 Gestion de la planification France 1er trimestre 20XX

Gestion des activités Europe

Portail Monde

Planification sous contrainte Belgique

Signature électronique

Dossier collaborateur

Moteur de workflow

Gestion des alertes

Réalisation de reporting

Gestion des absences

Gestion de mot de passe

Gestion de l'accès

P a g e 15 | 63

document.docx

Le soumissionnaire proposera un planning réaliste pour toute la partie projet et mise en production.

Ce planning devra tenir compte des éléments suivants :

Objectif d’une mise en production : [Inscrire la date de mise en production attendue] [Détailler s’il y a d’autres contraintes à signaler à l’éditeur (exemple période noire)]

P a g e 16 | 63

document.docx

7 DESCRIPTION DES BESOINS GTA

7.1 Gestion des dossiers des collaborateurs

Le dossier collaborateur devra être suffisamment complet pour gérer l’ensemble des fonctionnalités liées à la GTA. De ce fait, l’historique des contrats sera nécessaire pour calculer correctement certains compteurs ou appliquer certaines règles (temps de travail, Heures, succession de contrat, temps de repos, continuité des plannings…).

Il devra être possible de créer des dossiers collaborateurs manuellement ou de les importer via interfaces de l’outil de gestion de la paie puis de le créer en automatique dans l’outil de gestion des temps.L’outil devra permettre le rapprochement des données entre le dossier créé manuellement et celui généré automatiquement.Le soumissionnaire expliquera précisément comment gérer ce point dans sa solution.

7.2 Planification

[Décrire votre organisation]Exemple : Le dossier collaborateur présent dans la paie est créé et/ou modifié dans l’outil de GTA. Les codes horaires en provenance de l’outil de gestion de la paie, permettent d’alimenter le planning théorique moyen du salarié (notion d’horaire contractuel). Un manager, accède à l’outil de GTA afin d’effectuer la planification. Il accède à l’ensemble de la population qu’il gère. Le manager applique un code planning théorique (horaire type) à chaque collaborateur. En situation courante, le manager planifie son équipe au moins 5 semaines en avance. Les évènements impactant la planification sont saisis au fil de l’eau (exemple : arrêt maladie). Chaque semaine écoulée fait l’objet d’une validation qui permet de verrouiller le « réalisé ». Les plannings sont imprimés et sont signés par les salariés.

Le manager (N+1) :

Manager 1 de son équipe et d’elle-même Manager 2 : planifie l’activité, le planning (plage horaire et redéfinition des jours travaillés)

de son équipe et d’elle-même

Manager N+2 :

Manager N+2 : planifie l’activité, le planning (plage horaire et redéfinition des jours travaillés) du personnel des magasins.

Service RH (RH) :

P a g e 17 | 63

document.docx

Service RH : doit pouvoir planifier l’activité, le planning de l’ensemble du personnel de tous les magasins / services.

Doit pouvoir avoir la même vue que chaque personne utilisant la GTA (explication, comprendre, corriger, …).

Le manager doit pouvoir redéfinir le planning « type/réel » en indiquant les plages horaires, ainsi que les jours travaillés.

7.2.A Le planning

Les 3 types de planning sont attendus :

1. Un planning théorique, non impacté par les absences. A l’embauche d’un collaborateur le Service RH affecte le collaborateur au cycle et à la plage horaire qui lui sont dédiés. La gestion des rotations des cycles permet de déterminer le planning annuel de ce collaborateur de manière automatique.

2. Un planning prévisionnel, impacté par les absences prévisionnelles. Il est effectué au fil de l'eau en fonction des demandes de congés en respectant les délais imposés (exemple deux mois en avance pour pose de CP, etc…).

1. Le planning réalisé, impacté des absences prévisionnelles et non prévues.

Le système devra :

Permettre de consulter le planning par société / établissement / site / équipe ; Permettre de saisir les éléments impactant la planification au fur et à mesure (exemple :

arrêt maladie) ; Permettre, de valider chaque semaine écoulée afin de verrouiller le « réalisé » ; Sortir un état afin que les plannings soient imprimés et signés par les salariés ; Sortir un état permettant de vérifier où en est la planification ; Permettre de récupérer des éléments interfacés et de les afficher sur le planning :

o Chiffre d’affaire objectivé ;o Heures à planifier objectivées ;o Calcul d’un ratio de productivité ;o Chiffre d’affaire réalisé sur les semaines écoulées ;o Horaires d’ouverture et fermeture du site ;o Visualiser les différents types de semaine de modulation (haute, basse, …) ;o Nombre d’heures planifiées ;o Compteur de suivi de modulation ;o Compteurs de CP/RTT/Jours non travaillés (forfaits jours).o Chiffre d’affaire réalisé sur les semaines écoulées…

Permettre de générer des alertes bloquantes et non bloquantes (paramétrables) lors de l’élaboration du planning ;

Couvrir la fonction « d’activité ». Il est attendu de pouvoir affecter tout ou partie d’une plage horaire planifiée à une personne, un code activité ;

Permettre la planification par journée / ½ journée / par plage horaire ; Alerter les responsables, grâce à des messages visuel lors de la saisie, de l’ensemble des

règles à respecter (légal, conventionnel, accord d’entreprise : exemple respect du repos quotidien, …) ;

P a g e 18 | 63

document.docx

Proposer des visualisations du planning permettant de s’assurer qu’une ressource a été planifiée sur l’ensemble des plages d’ouverture des magasins ;

Permettre de retrouver simplement un « code planning » déjà existant ; Permettre de créer facilement un code planning inexistant ; Permettre d’afficher les compteurs des heures planifiées sur le planning (par salarié et par

équipe, en respectant des règles par compteur : avec ou sans stagiaires, …) ; Permettre de copier/coller des plannings d’un salarié à l’autre ou de reporter une

planification passée sur une période définie ; Permettre de gérer au travers de la planification le « détachement » d’un salarié ; Gérer les cas de multi contrat ; Permettre de valider les plannings par anticipation (validation et blocage d’une période non

arrivée à échéance) ; Permettre de suivre les heures effectuées au titre d’un remplacement ; Permettre de visualiser qui est planifié pour une date donnée (exemple : un dimanche, un

jour férié) ; Permettre d’identifier facilement les jours fériés ; Gérer les salariés extérieurs à l’entreprise (stagiaire, intérimaire…) ; Permettre de générer un état de suivi des jours récupérés De dater les jours travaillés ayant permis l’acquisition de récupération Permettre la planification des CDD même si la date de prolongation n’a pas encore été

saisie. Uniquement la date de sortie physique du salarié doit bloquer la planification ; Alerter pour le suivi des fins de CDD.

Le soumissionnaire apportera une réponse précise et détaillée à chacun des points listés ci-dessus.Le soumissionnaire proposera, un ensemble de Reporting permettant d’aider davantage à la planification.

7.2.B Profil horaire ou Journée type

Le profil horaire (ou journée type) décrit les éléments caractérisant l’horaire d’un jour, en termes de plages, de durées, autorisations, interdictions, obligations ….Le système cible devra permettre de gérer de façon illimitée, tous les cas de profils horaires pouvant exister au sein du groupe.

Exemple :

Horaires de Matin (5h-13h ; 7h-13h ; 8h-12h ;7h30-12h ; …) Horaires d’Après midi (13h-21h ; 13h-18h ; …) Horaires de Nuit (21h-2h ; 21h-5h ; …)

[Décrire le fonctionnement souhaité] : Exemple : Le groupe pourra créer et administrer les différents profils horaires et journées type. Un contrôle d’existence devra être fait lors de la création de ces profils horaires, afin d’éviter des doublons. Ce contrôle d'existence s’appuiera sur le code ainsi que sur les données (pour ne pas se retrouver avec deux codes différents mais avec les mêmes données)

P a g e 19 | 63

document.docx

7.2.C Cycle de travail

[Si vous n’êtes pas concerné par le paragraphe suivant vous pouvez le supprimer. Sinon compléter le tableau en fonction de vos souhaits.]Le cycle de travail est une succession de profils horaires sur une période donnée. La future solution devra permettre de gérer tous les cas de cycles de travail possible.

Nom du cycle Cocher les configurations qui vous concernent

2*8

3*8

4*8

5*8

Cycle sur X semaines alternées

Travail tous les 1ers jeudis de chaque mois

Sans cycle de travail

Cycle qui change fréquemment

La solution devra en outre :

Être en mesure de définir un référentiel commun des cycles horaires (année (modulation), mois-type, semaine-type, jour-type, cycles sur plusieurs semaines …) ;

Permettre de dérouler une semaine type, un mois type, un cycle, sur une année complète ; Gérer les temps partiels : capacité à traiter un nombre illimité de temps partiels ; Gérer les entrées/sorties (impact plannings, interface paie pour les sorties, …) ; Gérer les forfaits en jours et en heures ; Gérer des plages (fixes et variables) ; Permettre de définir pour chaque type d’horaire (et/ou cycle), des attributs associés (pause,

paniers…) ; Gérer les salariés travaillant les jours de repos, de férié, de dimanche et la nuit ; Permettre une saisie collective des cycles (par exemple, affecter un cycle à une équipe

donnée) ; Permettre d’éditer un planning théorique (par salarié et/ou par équipe et/ou par

compétence) ; Permettre l’export des plannings vers un outil de type bureautique (exemple : Microsoft

Excel).

P a g e 20 | 63

document.docx

Le soumissionnaire devra présenter les modalités de gestion des cycles de travail.

7.2.D Activité

[Conserver le paragraphe si vous êtes amené à réaliser la gestion des plannings par activité]

L’outil doit permettre de gérer l’activité du personnel.Cette activité est saisie heure par heure par les [compléter en fonction de votre organisation] (prévoir une liste de code type d’activité et des codes de regroupement des activités).Le système devra être en mesure de contrôler les écarts entre la planification et la saisie de l’activité. S’il y a un écart, une alerte devra prévenir le responsable.

7.2.E Autres éléments impactant la planification

L’entreprise sera très attentive aux possibilités suivantes du système :

Capacité pour le hiérarchique de saisir une demande d’astreinte prévisionnelle de son collaborateur ;

Modification de poste (passage par exemple d’un poste de matin à un poste d’après-midi) ; Modification de cycle de travail avec date d’effet ; Saisie (ou intégration si badgeuse) des heures en plus ou en moins. Le système devra

déterminer seul s’il s’agit des heures de nuit, week-end, dimanche ou férié… ; Le planning initial devra être conservé afin de mesurer l’écart avec le réalisé ; Le système devra gérer les limitations de jours prévues par la règlementation en vigueur.

7.3 Calendrier des jours particuliers

[Détaillez dans ce paragraphe si vous attendez l’affichage d’un calendrier particulier. Exemple : le calendrier des jours fériés belges, d’Alsace Lorraine…).]Le calendrier des jours particuliers inclut le calendrier des jours fériés de

XXX

7.4 Les éléments variables

7.4.A Heures supplémentaires et repos compensateur

Les heures supplémentaires ne constituent pas un mode de gestion normal et doivent conserver un caractère exceptionnel. Dans ce contexte elles sont soumises à la validation du manager.

a Le traitement

[Expliquez le traitement des heures complémentaires et supplémentaires en vous expliquant l’ensemble des cas existant au sein de votre organisation. Si dessous un canevas pour vous aider.]]

P a g e 21 | 63

document.docx

Les heures complémentaires et supplémentaires sont traitées de manières différentes suivant les situations :

Dans le cas d’un accord de modulation : Dans le cas de l’acquisition de jours de Réduction de Temps de Travail : En fonction du statut :

b La valorisation (calcul)

[Si vous souhaitez que la valorisation des heures supplémentaires et complémentaires se fassent dans l’outil GTA détaillez vos règles. Si vous utilisez le légal, le conventionnel, du spécifique…Ci-dessous un canevas pour vous aider. N’oubliez pas de rajouter vos attentes particulières.]

La valorisation des heures complémentaires et supplémentaires est basée sur les règles légales.

Suivant le choix du salarié la compensation des heures supplémentaires s’effectue suivant différents modes :

Heures supplémentaires effectuées et majorations payées Heures supplémentaires effectuées et majorations récupérées Heures supplémentaires effectuées et heures normales récupérées

Le projet devra prendre en compte l’ensemble des calculs. Le paiement ou la compensation des heures supplémentaires restant soumis à la validation du manager.

7.4.B Titres Restaurants

[Si vous n’êtes pas concernés, supprimez ce paragraphe. Sinon détaillez vos spécificités.]

Dans le cadre de la gestion des titres restaurant, la solution devra :

Prévoir des interfaces avec les sociétés [mettre le nom du prestataire des titres restaurant] pour communication des commandes ;

Permettre le calcul et la génération du fichier de commande suffisamment tôt afin que les tickets restaurants soient disponibles au début du mois suivant.

Le système de gestion des temps devra être en mesure de gérer l’attribution des chèques déjeuné sur chaque semaine.

Respecter la règle suivante :

Exemple :Si contrat de travail <15 heures : 2 ticketsSi contrat >=15 et <=25 : 3 ticketsSi contrat >25 et <35 : 4 ticketsSi contrat >=35 : 5 tickets

Il faut prendre en considération les avenants, et les tranches ou nombre de tickets sont susceptibles d’être revus.

P a g e 22 | 63

document.docx

7.4.C Gestion automatique des majorations et primes

[Détaillez le fonctionnement de votre organisation.]

Ci-après quelques règles de calcul de certaines variables dont la liste définitive et les règles seront approfondies lors des spécifications détaillées : [Détaillez vos différentes primes]

Nom de la prime Population concernée

Condition de déclenchement Règle de calcul

HEURES MAJORE

HEURES MAJ NUIT

PRIME DE NUIT

PRIME DE DIMANCHE

INDEMNITE JOUR FERIE

PRIME DE REMPLACEMENT

PRIME D’ASTREINTE

PANIER NUIT

PANIER JOUR

P a g e 23 | 63

document.docx

7.5 Planification sous contrainte

[Si vous n’êtes pas concernés par ce paragraphe supprimer le]Le planning prévisionnel s'établit automatiquement à partir des profils horaires et/ou cycle de travail, des compétences et des demandes d’absences.Ce planning devra être établi dans le respect des contraintes réglementaires (légales, conventionnelles et accords d’entreprises).L’aide à la planification devra s’appuyer d’éléments propres à l’entreprise (chiffres d’affaires, horaire d’ouverture et de fermeture …)Il devra être généré sur [XX année / mois / semaines] complète, avec des vues par semaine, mois, trimestre, semestre, année.

Le système doit être en mesure de s’appuyer sur les éléments suivants pour réaliser le planning prévisionnel : [Compléter le tableau suivant.]

Types d’élément aidant à la planification Cocher les éléments correspondant

Heures planifiées

Heures d’absences

Compteur de suivi de modulation

Compteurs de CP/RTT/Jours non travaillés (forfaits jours)

Solde en provenance de la paie

Chiffre d’affaire objectivé

Heures à planifier objectivées

Calcul d’un ratio de productivité

Chiffre d’affaire réalisé sur les semaines écoulées

Règles légales et conventionnelles

Des semaines hautes, basses (modulation)

Des horaires d’ouverture et fermeture

Compétences à couvrir

Des ressources disponibles

P a g e 24 | 63

document.docx

Ouverture le samedi et/ou le dimanche

Absence du salarié

Distance domicile travail du salarié

La qualification du salarié

La solution doit permettre d’intégrer d’autres éléments d’aide à la planification demandés ultérieurement. Dans sa réponse, le soumissionnaire devra détailler le mode de fonctionnement de sa solution.

Le manager doit pouvoir planifier leurs équipes en tenant compte des semaines hautes ou basse et des indications tiers remontée (CA, heures travaillées objectif).

7.6 Populations

Conserver les populations qui vous concernent. Vous pouvez compléter pour chaque paragraphe avec vos caractéristiques.

7.6.A Gestion du personnel externe

La solution devra être en mesure de gérer ce type de personnel : [supprimer quand vous n’êtes pas concernés ou bien rajouter les cas propres à votre structure]

Intérimaire ; Stagiaire ; Prestataire ; Vacataire.

En fonction de certaines règles, la solution devra être en mesure d’impacter ou non des compteurs d’heures et d’absences.Par ailleurs, ce type de personnel ne devra pas intégrer les interfaces GTA vers Paie.

Le soumissionnaire indiquera par ailleurs s’il a déjà eu à mettre en place des interfaces vers certaines agences d’intérim.

7.6.B Forfait jour (cadres)

Un état des jours de présence au trimestre (possibilité de l’avoir mensuellement) avec validation hiérarchique et un état imprimable pour signature du salarié et du responsable. Un récapitulatif annuel donnant le détail par type d’absences est également souhaitable.

P a g e 25 | 63

document.docx

Mode de pointage : [présent par défaut]. Gestion en jours, prévoir un compteur pour voir l’avancée du forfait annuel.

7.6.C Horaires mensuels (employés, maitrises, cadres)

Un état mensuel récapitulant le détail de chaque semaine (heures de présences, plages, absences…) avec le détail des heures de récupération prises et à prendre.

Mode de pointage : [présent par défaut, gestion en plages]. Un code planning se décline en un horaire individualisé qui se recopiera chaque semaine automatiquement. Cet horaire type devra respecter les plages de présences imposées (accord temps de travail). Le planning type doit permettre le positionnement de temps de pause (pause déjeuner, pause-café…)

7.6.D Modulation

Les salariés doivent réaliser un quota d’heure annuel. Le nombre d’heure hebdomadaire peut varier en fonction de plusieurs critères (semaine haute, semaine basse, heures objectivée, …)

Mode de pointage : [Pas de pointage pour ces salariés, ils correspondent à la population dont les plannings sont réalisés par le responsable. En cas de retard et/ou d’absence, le responsable saisie une absence correspondante.]Le système doit pourvoir suivre le nombre d’heure à réaliser, le nombre d’heure planifié et le nombre d’heure réalisé.

7.6.E Personnel externe (intérimaire, prestataire)

Mode de pointage : [Pas de pointage pour ces salariés, ils correspondent à la population dont les plannings sont réalisés par le responsable. En cas de retard et/ou d’absence, le responsable saisie une absence correspondante.]Le système doit pourvoir suivre le nombre d’heure à réaliser, le nombre d’heure planifié et le nombre d’heure réalisé.

Le soumissionnaire indiquera pour chacun des points les modalités de gestion dans sa solution.

7.7 Les Absences

Le catalogue d’absences doit reprendre l’ensemble des éléments déjà utilisé par la société. On distinguera deux catégories d’absences :

1. Les absences avec compteurs de droit, hors absences sécurité sociale2. Les autres absences, y compris les absences sécurité sociale

Les soldes de l’ensemble des compteurs d’absences devront pouvoir être gérés sur [XXX] années.

P a g e 26 | 63

document.docx

7.7.A Liste des absences attendues

Ces motifs d’absences devront être mis en place afin de pouvoir gérer au mieux les échanges entre le système de GTA et le système de Paie.[Compléter le tableau avec vos absences]

NOM DE L’ABSENCE TYPE D’ABSENCE CODE

ABSENCE NON PAYÉE Absence SS et non payée

CONGÉ SANS SOLDE Absence SS et non payée

GRÈVE Absence SS et non payée

MATERNITÉ Absence SS et non payée

MISE À PIED Absence SS et non payée

CONGÉ PATERNITÉ Absence SS et non payée

MALADIE Absence SS et non payée

ACCIDENT DE TRAVAIL Absence SS et non payée

ACCIDENT DE TRAJET Absence SS et non payée

CONGÉ PARENTAL Absence SS et non payée

RÉUNION Mission et Formation

FORMATION Mission et Formation

REPOS COMPENSATEUR Repos

REPOS Repos

CONGÉ PAYÉ – JOURNÉE Tout type de congés

CONGÉ ANCIENNETÉ Tout type de congés

RTT Tout type de congés

MARIAGE ENFANT Tout type de congés

MARIAGE FRÈRE SŒUR - PÈRE – MÈRE Tout type de congés

P a g e 27 | 63

document.docx

DÉCÈS CONJOINT Tout type de congés

DÉCÈS ENFANT Tout type de congés

DÉCÈS ASCENDANT - DESCENDANT - FRÈRE - SŒUR –

Tout type de congés

JOUR FÉRIÉ Tout type de congés

CONGÉ CONVENTIONNEL Tout type de congés

CONGÉ MARIAGE Tout type de congés

SUSPENSION DE CONTRAT Suspension

7.7.B Fonctionnement des absences

[Compléter les tableaux ci-dessous]Les absences se calcul :

Cocher selon le fonctionnement

Jours calendaires

Jours ouvrables

Jours ouvrés

La prise :


Jours

Demi-journée

Heures

P a g e 28 | 63

document.docx

Le traitement de l’absence :


Pareil dans tous les établissements

Différentes selon les établissements

Pareil pour toutes les populations

Différentes selon le statut du salarié

[Décrire les différences et les cas particuliers présents dans l’entreprise]

Exemple :Absences autorisées payées de type congés payés ou RTT (jours ouvrables voir calendaires sur les établissements ouverts le dimanche ou demi-journée).SIEGE : l’employé fait la demande à son manager via le Libre-Service Employé.Site : l’employé effectue une demande papier pour effectuer sa demande d’absence auprès de son manager. Le support papier est signé conjointement par l’employé et le manager. Le manager saisi l’absence dans l’outil de GTA.Absences de type sécurité sociale : le salarié informe son manager et / ou le service Ressources Humaines et transmet son arrêt au service Ressources Humaines. Le service Ressources Humaines saisie l’absence.

7.7.C Recueil de présence

La future solution devra permettre de gérer plusieurs possibilités de recueil de la présence :[Compléter les tableaux ci-dessous]

Cochez selon l’attendu

Déclaration de présences

Présence par défaut sur la base du planning théorique

Pointage via badgeuses [Si mis en place dans votre structure]

Déclaration de présence en ligne

P a g e 29 | 63

document.docx

7.8 Les compteurs

7.8.A Compteurs Congés Payés

Le fonctionnement de l’outil :[Compléter les tableaux ci-dessous]

Cocher le mode de fonctionnement

Calculés par la paie

Calculés par la GTA

Si ces compteurs sont calculés par le système de paie, quels sont les éléments à intégrer en GTA :


Les compteurs de paie par fréquence régulière

Rien

Un compteur dynamique déduisant le nombre de jours demandé

Affichage :


En cours d’acquisition

Acquis

Solde

Si les compteurs sont calculés par la GTA :

P a g e 30 | 63

document.docx

Cocher votre mode de fonctionnement

Acquisition en jours cumulés

Application stricte du légal (sur 4 semaines consécutives)

Acquisition au mois le mois

Acquisition différente si temps partiel

[S’il y a plusieurs possibilités dans la structure il est possible de décrire pour chaque entité le fonctionnement. De plus, préciser le nombre de congés payés en fonction de la structure ou du statut. Décrire le calcul pour la proratisation en cas d’entrée / sorti.]

7.8.B Compteurs Congés de fractionnement

[Compléter les tableaux ci-dessous]

Le fonctionnement de l’outil :







Rien


7.8.C Compteurs Congés d’ancienneté



P a g e 31 | 63

document.docx







Rien


Si calculé en GTA : mode d’acquisition :


A la bascule

Acquisition au mois anniversaire

7.8.D Compteurs Congés RTT, JNT







P a g e 32 | 63

document.docx



Rien


Si calculé en GTA : mode d’acquisition :


Au premier jour de la période de référence

Au mois le mois

[S’il y a plusieurs possibilités dans la structure il est possible de décrire pour chaque entité le fonctionnement. De plus, préciser le nombre de congés payés en fonction de la structure ou du statut. Décrire le calcul pour la proratisation en cas d’entrée / sorti.]

7.8.E Compteurs absences conventionnelles








Rien

P a g e 33 | 63

document.docx



Cocher votre mode de fonctionnement

Acquisition en jours cumulés

Application stricte du légal (sur 4 semaines consécutives)

Acquisition au mois le mois

Acquisition différente si temps partiel

[S’il y a plusieurs possibilités dans la structure il est possible de décrire pour chaque entité le fonctionnement.]

7.8.F Compteur des repos compensateurs

La solution devra permettre de gérer des compteurs de récupération :

a Gestion d’activité exceptionnelle (récupération)







Rien


P a g e 34 | 63

document.docx


Détaillez le mode de fonctionnement

ExempleLes heures de récupérations ne pourront être demandées au responsable hiérarchique qu’à partir d’une demi-heure par jour. (Pas d’incrémentation à la minute). Les récupérations ne seront pas majorées (1 heure = 1 heure). Le compteur de récupération doit avoir une durée de « vie » d’un mois de paie, sinon remise à zéro. Laisser la possibilité de prolonger le compteur manuellement si nécessaireRécupération d’heure (à poser en ½ journée ou journée complète) compteur d’heure à mettre en place.

b Dimanche travaillé







Rien




ExempleLorsque les salariés travaillent un dimanche, ils doivent le récupérer. La GTA doit donc pouvoir gérer le dimanche travaillé d’une part, et ensuite lorsque le salarié va poser la récupération du dimanche, il faut qu’il puisse sélectionner quel Dimanche il récupère. La récupération du dimanche est une récupération non valorisée (1 jour de REPOS supplémentaire par rapport aux repos habituels, pas d’heures associées).

P a g e 35 | 63

document.docx

c Gestion du repos compensateur légal







Rien




ExempleIl devra s’appuyer sur la réglementation en vigueur (légale, conventionnelle, accords ou usages) pour le calcul.

7.8.G Autres contingents d’absences et de présences

Liste non exhaustive d’autres compteurs :

Cocher les contingents

Contingent heures de délégation

P a g e 36 | 63

document.docx

Contingent de repos compensateur

Contingent d’heure de récupération

Mode de calcul :







Rien




[S’il y a plusieurs possibilités dans la structure il est possible de décrire pour chaque entité le fonctionnement.]

7.9 Gestion du CET

[Conserver le paragraphe si vous êtes concernés. Et compéter avec vos informations. Décrire les spécificités du CET par exemple, CET monétisé, déblocage exceptionnel.]La solution devra permettre de gérer les CET :

P a g e 37 | 63

document.docx

Gestion des règles d’alimentation du CET (jours, primes, …) ; Gestion des règles de transfert vers d’autres supports (PERCO) avec éventuellement

abondement ; Gestion des droits et des compteurs ; Visualisation des compteurs ; Demande de transfert vers le CET (avec paramétrage des règles et automatisation des

transferts) ; Demande de transfert du CET vers un autre support.

Le soumissionnaire précisera les modalités de gestion de ce type de compteur, notamment comment la solution cible gère les différentes provenances du CET (CP, RTT… : création de compteurs différents en fonction du motif de transfert, autre mode ? ...)

7.10 Reporting

[Supprimer la section si vous ne souhaitez pas que la solution intègre un outil de reporting. Sinon, compléter si besoin la liste avec vos propres exemples.]

La solution devra être en mesure soit d’embarquer un module de requête soit d’exporter des données afin de pouvoir réaliser des requêtes via un outil tiers.Les états suivants, à titre d’exemple, devront être couverts par le projet :

Liste des absences non validées triées par manager ; Récapitulatif par type d’absence : salariés triés par type d’absence ; par exemple salariés

qui ont pris des CP sur le mois M ; Etat des absences nécessitant un justificatif sur le mois M ; Etat sur le statut des contingents de Repos Compensateur Légal et de Récupération (droit ;

pris ; solde) avec une sélection possible par manager ; Etat des heures supplémentaires par site avec le nombre d’heures supplémentaires payées

et le détail par tranche de valorisation et par salarié ; Etat indiquant par jour le nombre d’heures effectuées avec le nombre d’heures théoriques,

le nombre d’heures réelles et la différence. Cet état devra indiquer pour chaque catégorie un cumul à la semaine ;

Etat indiquant le suivi des absences Etat indiquant le suivi des compteurs de congés payés Etat indiquant le suivi de la planification Etat indiquant le suivi des jours de présence

Le système devra en outre offrir la possibilité aux utilisateurs de créer leurs propres requêtes sur des données saisies et/ou calculées. Les états ainsi que les requêtes créées par les utilisateurs devront être éditables sur les outils pack office et Adobe ou équivalent.

P a g e 38 | 63

document.docx

7.11 Les alertes

7.11.A Les types d’alertes

Le soumissionnaire devra présenter les différents types d’alertes possible. Notamment les alertes pour aider à la planification et au respect des règles légales et conventionnelles.

Voici un exemple des alertes attendues : [Compléter avec des exemples d’alertes que vous attendez.]

Types Alerte Niveaux

Repos hebdomadaire légal 35 h consécutives

Repos quotidien légal 11 h

Durée hebdomadaire maximale 48 h, 44 h en moyenne sur 12 semaines

Durée quotidienne maximale 10 h

Nombre de nuits consécutives (conventionnel) 5 nuits consécutives de 8 h/nuit soit 40 h par semaine

Pour les cadres au forfait jour Travail annuelle 214 jours

Visite médicale 1 mois avant

Habilitation électrique 3 mois avant

Validation permis poids lourd

En cas de dépassement du crédit d’heures de délégation autorisées

Arrivée à terme d’une période

Lors d’une embauche

Suivant un évènement donné

Visite de reprise maternité

Visite de reprise accident de travail

Visite de reprise maladie

P a g e 39 | 63

document.docx

Cette liste d’indicateurs d’alertes n’est pas exhaustive, et sera complétée lors des phases d’analyse.Il faut pouvoir choisir si l'alerte sera bloquante ou non à la saisie en fonction des contraintes métier. Le paramétrage de simple alerte doit être possible.La future solution devra être en mesure de ne pas bloquer la saisie en dépit des alertes affichées.

7.11.B Workflow en cas d’alerte

[Supprimer le paragraphe s’il ne vous concerne pas. Si vous souhaitez un workflow de validation des alertes, veuillez compléter le paragraphe.]La future solution devra être en mesure de ne pas bloquer la saisie en dépit des alertes affichées.Dans un tel cas, un système de workflow émette une demande de validation auprès du responsable. Les motifs d’alertes doivent être saisis pour une durée limitée. Le délai d’alerte doit être paramétrable, ainsi que le destinataire de l’alerte.

Exemple de système de workflow :

Pour les habilitations, c’est le manager qui est alerté. Pour les visites médicales des services production et maintenance, c’est le manager et le

GRH qui sont alertés. Pour les autres services, c’est uniquement le GRH qui est alerté. Lorsque des services différents sont alertés, le message passé doit être adapté au rôle du

service.

Ce type d’alerte peut être transmis sous différentes formes aux personnes destinataires.

Pop-up à l’écran, Texte informatif mis en valeur, Texte informatif imprimé sur des documents….

7.12 Traçabilité

Il est important pour le service RH de pouvoir tracer l’activité des manager sur l’outil de gestion des temps.Pour cela la solution devra être en mesure de restituer quelques états de « traçabilité » :

Liste de connexion de date à date Suivi nominatif et daté des modifications effectuées dans la base

P a g e 40 | 63

document.docx

7.13 La signature électronique

Le soumissionnaire indiquera également s’il en mesure de proposer une validation via une signature électronique (exemple : validation des plannings salarié/employeur par signature électronique).

P a g e 41 | 63

document.docx

8 SELF SERVICE GESTION DES TEMPS

[Vous pouvez supprimer les paragraphes qui ne vous concernent pas et détailler les autres avec vos attentes spécifiques.]

Le projet devra fournir une solution de dématérialisation de type libre-service employé et libre-service manager ;

8.1 CET

La solution devra permettre :

De visualiser les compteurs ; De transférer des jours vers le CET (avec paramétrage des règles et automatisation des

transferts) ; De transférer du CET vers un autre support (exemple la vers la paie pour monétiser les

jours).

8.2 Planning

Les plannings doivent être validés (mensuellement) :

Par le collaborateur d’une part ; Par le manager d’autre part.

Le salarié doit pouvoir voir son planning détaillé ainsi qu’un planning succinct des jours de travail de ses collègues. Le manager doit pouvoir voir et gérer le planning de l’ensemble de son équipe.

8.3 Gestion des absences / présences et éléments variables

La future solution devra pouvoir gérer tous les types d’absences possibles. Il devra être possible de poser tout type d’absence et de déclaration de présence directement dans le logiciel. L’outil devra être capable de :

Permettre la saisie d’une absence par un salarié et qu’elle soit validée par son responsable ;

Permettre la gestion des Heures de délégation – hors temps de travail ; Permettre au salarié de choisir si des heures sont payées ou récupérées ; Permettre au manager ou cadre de déclarer leur présence.

P a g e 42 | 63

document.docx

8.4 Le workflow

Le soumissionnaire indiquera s’il est possible au travers de sa solution de valider directement via les mails générés ou si le mail renvoi nécessairement à l’application où une action de validation est seulement disponible.

Le moteur de workflow devra embarquer les fonctionnalités suivantes :

Système de validation simple : [Décrire le workflow attendu Exemple validation des CP par le N+1 ; validation des absences nécessitant un justificatif par le N+1 et le RH] ;

Système de validation multi directionnel : N vers N+1 et vers N+1 bis (en cas de rattachement multiples du salarié par exemple) ;

Gestion des messages (accusés de réception, réponses automatiques, informations, …) ; Les circuits de validation devront être tracés (un reporting de tracking est souhaitable) la

DRH pourra visualiser qui a fait quoi et quand ; La DRH aura la main pour attribuer les droits en termes de Workflow ; Le système devra permettre la délégation des Workflows vers un autre utilisateur, sur tout

ou partie des workflows.

8.5 Gestion des compteurs

La solution devra permettre la visualisation dynamique des principaux compteurs (CP, RTT, RC, CET…).

P a g e 43 | 63

document.docx

9 POINTAGE

[Si vous ne souhaitez pas mettre en place de solution de pointage ou que vous n’utilisez pas de solution de pointage, vous pouvez supprimer le paragraphe.]

[Répondre aux différentes questions.]

Avez-vous une solution de pointage au sein de l’entreprise ?

Cocher

Oui

Non

Si oui,Quelle est la solution de pointage installée ? [Détaillez les références de la solution utilisée, le nombre de site sur lequel le pointage est réalisé.]

Référence Site Type de population

Nombre de salarié

Badge

Puce RFID

Planning théorique

Terminal

Pointage dématérialisé à travers un système d’exploitation

Exploitez-vous les données liées au pointage ?

Cocher

Oui

P a g e 44 | 63

document.docx

Non

La solution doit-être en mesure de s’interfacer avec l’outil de pointage actuel.

Si non,Souhaitez-vous mettre en place une solution de pointage ?

Cocher

Oui

Non

Avez-vous choisi la solution de pointage que vous souhaitez mettre en place ?

Cocher

Oui

Non

Si oui, détaillez le prestataire et la solution choisie.

Si non, [Détaillez vos attentes (quel type de pointage, centralisé ou décentralisé, combien de site, combien de salarié)

Souhaitez-vous exploiter-vous les données liées au pointage ?

Cocher

Oui

Non

Le prestataire doit proposer une solution de pointage, détaillez les capacités de l’outil de pointage que vous possédez. L’éditeur doit spécifier les contraintes techniques liées au système de pointage. L’éditeur précisera si c’est une solution qui lui est propre où s’il fait appel à un prestataire tiers pour installer la solution de pointage.

P a g e 45 | 63

document.docx

10CONTROLE D’ACCES

[Si vous ne souhaitez pas mettre en place de solution de contrôle d’accès ou que vous n’utilisez pas ce type de contrôle, vous pouvez supprimer le paragraphe.]

[Répondre aux différentes questions.]

Avez-vous une solution de contrôle d’accès au sein de l’entreprise ?

Cocher

Oui

Non

Si oui,Quelle est la solution de contrôle d’accès installée ? [Détaillez les références de la solution utilisée, le nombre de site sur lequel le pointage est réalisé.]

Référence Site Type de population

Nombre de salarié

Badge

Puce RFID

Planning théorique

Terminal

Pointage dématérialisé à travers un système d’exploitation

Biométrique

Exploitez-vous les données liées au contrôle d’accès ?

Cocher

Oui

P a g e 46 | 63

document.docx

Non

La solution doit-être en mesure de s’interfacer avec l’outil de contrôle d’accès actuel.

Si non,Souhaitez-vous mettre en place une solution de contrôle d’accès ?

Cocher

Oui

Non

Avez-vous choisi la solution de contrôle d’accès que vous souhaitez mettre en place ?

Cocher

Oui

Non

Si oui, détaillez le prestataire et la solution choisie.

Si non, [Détaillez vos attentes (quel type de contrôle d’accès, centralisé ou décentralisé, combien de site, combien de salarié)]

Souhaitez-vous exploiter-vous les données liées au contrôle d’accès ?

Cocher

Oui

Non

Le prestataire doit proposer une solution d’accès, détaillez les capacités de l’outil d’accès que vous possédez. L’éditeur doit spécifier les contraintes techniques liées au système de pointage. L’éditeur précisera si c’est une solution qui lui est propre où s’il fait appel à un prestataire tiers pour installer la solution de pointage.

P a g e 47 | 63

document.docx

P a g e 48 | 63

document.docx

11 INTERFACES

11.1 Les différentes interfaces

[Décrire ici l’ensemble des applications qui interagissent avec l’outil de gestion des temps. Les interfaces permettent la communication entre les outils. Ne pas oublier de noter si un nouvel outil est en cours de mise en œuvre.

Compléter le tableau suivant :]

Outil de départ Outil d’arrivée Données Fréquence

GTA Paie Absences et compteurs Journalière

Paie GTA

Absences saisies en paie (correctif ou absences de type SS non gérée en GTA)

Journalière

Paie GTA Dossier salarié Journalière

GTA Module Formation

Module Formation GTA

GTA Module Formation

GTA Compta)

ERP GTA

GTA Paie

GTA Finance / compta

Les éditeurs devront préciser leur capacité à s’intégrer avec les solutions SIRH ci-dessus et préciser leurs expériences en la matière.

P a g e 49 | 63

document.docx

11.2 Echanges entre le SIRH et les autres applications

[Détailler ce paragraphe avec vos spécificités techniques si vous choisissez le mode Saas. Sinon à supprimer.Exemple : A noter que les solutions SIRH et ERP seront hébergées sur des sites distincts.Les échanges sont principalement orientés batch quotidien et basés sur l’échange de fichiers.L’entreprise prévoit d’intégrer sont SIRH à son ERP par transfert de fichier via TradeXpress selon le standard SFTP.Le soumissionnaire indiquera donc ses capacités :

A réaliser des extractions différentielles de données depuis le SIRH ; A exporter des données du SIRH sous la forme de fichier ; A transférer ces fichiers suivant le protocole SFTP ; A intégrer des données dans le SIRH à partir de fichier reçu ; A faire des exports de données en bulk API via un connecteur déployé On-premise.]

P a g e 50 | 63

document.docx

12PRESTATIONS DE SERVICE ATTENDUES

[Décrire le service que vous attendez]

12.1 La solution

Cocher votre choix. Si le choix n’est pas fixe vous pouvez sélectionner les deux.

SAAS

Licence

12.2 Périmètre de la prestation

La prestation du soumissionné doit couvrir :

L’implémentation du système d’information de gestion des temps et des activités ; L’implémentation de solutions de saisie dématérialisées (outils de mobilités : tablette,

smartphone).

12.3 Maintenance légale et conventionnelle

[Vérifier que ce fonctionnement corresponde à vos attentes.]

L’éditeur devra prendre en charge la maintenance légale et conventionnelle.Le mode de fonctionnement suivant est attendu :

L’éditeur effectue la veille légale et conventionnelle ; L’éditeur informe des changements ; L’éditeur intégré les évolutions après validation ; L’éditeur s’assure de la non régression des paramétrages existants et du bon

fonctionnement des évolutions.

P a g e 51 | 63

document.docx

13PRINCIPES DIRECTEURS D’ARCHITECTURE

[Conserver le paragraphe vous correspondant entre Mode progiciel et Saas. Les deux si vous n’avez pas fait votre choix.]

13.1 Mode progiciel

L’éditeur devra préciser les prérequis (serveur, langage, bande passante, nécessaire pour l’intégration de la solution en mode on-premise (licence, acquisition).

L’entreprise utilise aujourd’hui les données suivantes : [Compléter avec vos données :]

Navigateur : Système d’exploitation : Messagerie : Bande passante : Serveur :

13.2 Solutions Saas

L’entreprise souhaite souscrire les services applicatifs RH et paie en mode SaaS afin d’éviter la prise en charge de l’hébergement des solutions et leur exploitation.

Le soumissionnaire doit prouver sa capacité à :

Héberger les solutions relatives à ces services sur les environnements de paramétrage, qualification et production ;

Gérer l’intégration des services, même pour des solutions qui seraient hébergées sur des sites différents ;

Réaliser l’exploitation applicative et technique de l’ensemble des environnements projet, de production et de secours qui seraient nécessaires à la mise en place des solutions et au bon fonctionnement des services SIRH.

Le soumissionnaire fournira donc une description de son environnement d’hébergement. L’entreprise attend du soumissionnaire qu’il propose une infrastructure permettant le respect des exigences en matière de SLA, disponibilité et d’intégrité précisées ci–après.

13.3 Principes d’intégration dans le SI

[Ce paragraphe est à adapter à votre structure.]Les principaux points d’intégration du SIRH de l’entreprise correspondent :

P a g e 52 | 63

document.docx

Aux échanges entre le SIRH et autres applications : ERP, Annuaire d’Entreprise, portail intranet… ;

Aux échanges entre les sous-systèmes du SIRH.

La solution proposée par le soumissionnaire devra permettre de s’interfacer :

Avec d’autres applications Saas et On-premise du SI ; Avec la solution intranet du portail d’entreprise qui fédérera l’ensemble des accès aux

solutions applicatives de l’entreprise via un service d’authentification unique des utilisateurs. [A conserver si vous avez un intranet interne.]

Par ailleurs la solution SIRH est garante des référentiels RH de l’entreprise. Elle devra donc être en mesure de propager les données de ces référentiels dans le SI entreprise.

De plus, la structure organisationnelle de l’entreprise et les identités utilisateurs devront être synchronisés de façon cohérente sur l’annuaire de l’entreprise Active Directory et les applications de l’entreprise. [A conserver si vous avez un annuaire d’entreprise.]

Ces différents principes sont détaillés dans le chapitre suivant.

L’entreprise recommande une intégration basée sur les standards technologiques du marché :

En termes de protocoles d’échange (SFTP, API web service, REST) ; En termes de sécurité (TLS, SSL).

Le soumissionnaire indiquera donc ses capacités à intégrer entre-elles les différents sous-systèmes SIRH selon les standards recommandés par l’entreprise.

13.4 Supervision des flux inter-applicatifs

[Pas nécessaire en mode progiciel.]Le soumissionnaire décrira les procédures qu’il met en place pour assurer :

La supervision des échanges entre les sous-systèmes du SIRH ; La supervision des échanges entre les sous-systèmes du SIRH et les autres applications ; La reprise des interfaces entre les sous-systèmes du SIRH ; La reprise des interfaces entre les sous-systèmes du SIRH et les autres applications.

Le soumissionnaire précisera en particulier :

Les reporting mis à disposition pour suivre les traitements d’intégration associés aux échanges ;

La gestion des alertes sur incidents lors d’un traitement d’intégration ; La gestion du « root cause analysis ».

P a g e 53 | 63

document.docx

13.5 Intégration avec le portail de l’entreprise

[A conserver si portail d’entreprise et mode Saas]L’entreprise prévoit un accès unifié aux services du SIRH. La solution SIRH devra donc permettre l’accès fédéré à l’ensemble de ses Briques via un Portail RH dédié.

Par défaut, les salariés accèdent au portail RH depuis le Portail d’Entreprise, via une authentification SSO. Néanmoins, les salariés pourront accéder directement au portail RH depuis une url sur leur poste de travail.

Le soumissionnaire indiquera comment il compte sécuriser les deux modes d’accès décrits.

13.6 Poste de travail/Mobilité

[A conserver si mode Saas et a adapter à votre structure.]

Tous les employés de l’entreprise devront pouvoir accéder au Portail RH depuis leur poste de travail ou un poste de travail banalisé, dès lors que celui-ci est connecté au réseau et authentifié.

Le soumissionnaire dont la solution ne serait pas développée en full web, précisera la technologie qu’il propose en termes de virtualisation des applications et les conditions d’hébergement associées. Il détaillera en particulier les impacts financiers associés compte tenu des attentes de l’entreprise.

Par ailleurs, certains utilisateurs doivent pouvoir consulter le portail RH depuis l’extérieur et de manière sécurisé, via leur poste de travail, des tablettes ou des smartphones.

Le soumissionnaire indiquera les moyens qu’il préconise pour sécuriser ces accès externes (contrôle de plage IP, VPC, etc.) et la capacité de portabilité des solutions sur mobile. Il devra également indiquer dans son dossier technique les prérequis en termes de configuration du poste de travail/ tablette/ smartphone et du réseau pour assurer une utilisation optimale de leur solution, notamment en mobilité.

Le soumissionnaire précisera à minima les prérequis techniques suivants :

Version minimale de navigateur Web ; Version minimale du système d’exploitation ; Version minimale des plugins (ex. Flash Player) ; Résolution minimale ; Version minimale de la suite office ; Version minimale de PDF (pour les imports/ exports) ; Version minimale de pilotes d’impression.

P a g e 54 | 63

document.docx

13.7 Messagerie

[A conserver si mode Saas]L’entreprise utilise actuellement la solution de messagerie [compléter avec le nom de votre messagerie.]Le soumissionnaire indiquera :

Les niveaux d’intégration avec ces solutions de messagerie, en particuliers pour la synchronisation des calendriers ;

Les modes de sécurisation des envois de mails vers ces solutions.

P a g e 55 | 63

document.docx

14SECURITE APPLICATIVE ET QUALITE DES TRAITEMENTS

14.1 Authentification

[A conserver si mode Saas, SSO ou AD et a adapter.]

L’entreprise dispose d’un annuaire d’entreprise (Active Directory) et prévoit une authentification unique SSO des utilisateurs sur l’ensemble des services applicatifs.

L’entreprise prévoit la mise en œuvre d’une solution d’Identity Provider SSO pour authentifier les utilisateurs, et fournir un jeton SSO aux applications accédées, dont les applications SIRH. Le portail d’entreprise permettra de fédérer les accès utilisateurs et réaliser la première authentification.

Le soumissionnaire indiquera les protocoles d’échanges sécurisés d'informations d'identités supportés par les sous-systèmes du SIRH pour la délégation d’authentification : SAML2.0 ou Web SSO.

14.2 Gestion des mots de passe

[A conserver si mode Saas]L’entreprise préconise la délégation d’authentification via le protocole [SAML2.0] afin de renforcer la sécurité autour de l’accès à ses solutions applicatives et notamment pour éviter de mettre en place une gestion des mots de passe en interne.

Si le protocole [SAML2.0] n’est pas supporté, les soumissionnaires préciseront donc les procédures d’administration des mots de passe relatifs à leur solution.

14.3 Provisioning des identités utilisateurs

[Conserver si interface avec d’autres outils et à adapter. Ici interface avec l’annuaire via une solution d’identity management.]

La création/suppression d’utilisateur dans la structure Organisationnelle du SIRH, doit être impactée sur le reste du SI l’entreprise.

L’entreprise prévoit la mise en œuvre d’une solution d’Identity Management pour fédérer le provisioning des identités utilisateurs sur l’annuaire d’entreprise et sur l’ensemble des applications de l’entreprise.

Le soumissionnaire doit prévoir une interface de provisioning entre le SIRH et la solution d’Identity Management.

P a g e 56 | 63

document.docx

Le soumissionnaire détaillera comment il propose de provisionner les identités utilisateurs des autres sous-systèmes du SIRH.

14.4 Gestion des habilitations et provisionning

Plusieurs profils d’utilisateur avec des niveaux d’accès différents aux fonctions et aux données du SIRH seront identifiés dans le cadre de la mise en œuvre de la solution SIRH.

Par ailleurs, l’accès à certaines données sensibles sera protégé, même aux administrateurs, pour des questions de confidentialité.

Le soumissionnaire détaillera les principes de gestion des habilitations et du provisionning des profils applicatifs dans le SIRH qu’il recommande, en décrivant notamment la procédure de création d’un nouvel utilisateur.

14.5 Protection des données

[A conserver si mode Saas]Le soumissionnaire précisera si l’accès aux données du SIRH s’opère via un accès direct aux tables de données ou via des APIs.

14.6 Qualité des données

L’entreprise prévoit de réaliser un contrôle qualité à priori des formats de données saisie.Ce contrôle vise à éviter le traitement ultérieur des rejets notamment lors de la gestion de la paie.

Le soumissionnaire précisera la capacité de sa solution à gérer nativement des contrôles qualité sur le format de données saisie dans les champs de sa solution SIRH.

14.7 Auditabilité

[A conserver si mode Saas]

L’entreprise doit garder la possibilité de contrôler que le soumissionnaire respecte bien ses engagements. L’entreprise souhaite pouvoir évaluer le niveau de sécurité lié à l’accès des utilisateurs au service et également vérifier son adéquation aux besoins exprimés.

Le soumissionnaire détaillera les procédures et outillages sur lesquels il souhaite s’appuyer :

Pour assurer le suivi du respect de la qualité de service sur laquelle il s’engage ; Pour vérifier la sécurité des accès utilisateurs.

P a g e 57 | 63

document.docx

Il précisera également s’il rend ces informations visibles en temps réel pour l’entreprise, via une console de supervision, ou en batch, via l’extraction d’un fichier par un connecteur en utilisant une API de la solution.

Par ailleurs, les rapports d’audit issus des audits réalisés en interne par le soumissionnaire et les plans d’actions de mise en œuvre des recommandations seront transmis à l’entreprise. Le soumissionnaire précisera à quelle fréquence sont réalisés ces audits.

L’entreprise se réserve également le droit de mener des audits externes, éventuellement via des tiers auditeurs n’ayant aucun lien avec des concurrents du soumissionnaire. Ce dernier s’engage à faciliter le travail des auditeurs, sans toutefois perturber la délivrance du service.

Dans tous les cas, l’application des plans d’actions pour la mise en œuvre des recommandations issues de l’audit seront de la responsabilité du soumissionnaire.

14.8 Service-Level Agreement (SLA) et maîtrise des SLA


L’entreprise attend que le service soit disponible 24h/24, 7j/7 avec un taux de disponibilité de 99,99%.

Seuls les environnements de production sont soumis à des critères de qualité de service stricts.

Le soumissionnaire précisera sa capacité et son niveau d’engagement quant à la poursuite sans interruption au même niveau de service.Il détaillera ses engagements de SLA, Recovery Time Objective (RTO) (peut se traduire par la durée maximale d'interruption admissible) et Recovery Point Objective (RPO), (désigne la durée maximum d'enregistrement des données qu'il est acceptable de perdre lors d'une panne) sur les solutions proposées pour les cas suivants : sinistre mineur, sinistre majeur avec bascule sur un site de secours.

De plus, le soumissionnaire détaillera sa stratégie de maintenance et d’arrêt du service pour les montées de version : durée de l’arrêt, délai de prévenance, message d’alerte, etc.

14.9 Supervision de la disponibilité des applications

[A conserver si mode Saas]Le soumissionnaire détaillera comment il détecte une indisponibilité de service.

Il détaillera le processus de remontée d’incident en cas d’indisponibilité de la solution SIRH, en précisant si la remontée d’alerte peut s’effectuer via trappe SNMP.

14.10 Supervision traitements


P a g e 58 | 63

document.docx

Le soumissionnaire indiquera comment il mesure la volumétrie et détecte les échecs liés aux traitements exécutés sur ses serveurs.

Il précisera notamment le processus de remontée d’alertes et les modes de visualisation possible des traitements en cours d’exécution, ainsi que les statistiques des traitements exécutés.

14.11 Service Level reporting

[A conserver si mode Saas]L’entreprise prévoit de suivre des statistiques liées à la réalisation des niveaux de services pour identifier les tendances positives et négatives relatives à un service en particulier ou à la globalité de la solution.

Le soumissionnaire détaillera le format, la granularité et la fréquence des rapports qu’il produit sur le respect de ses engagements de niveau de service et comment il met ces rapports à disposition de l’entreprise.

De plus, il détaillera les procédures et l’outillage sur lesquels il s’appuie pour assurer le suivi du respect de ses engagements de niveau de service, pour chaque service de sa solution.

14.12 Protection physique des données

[A conserver si mode Saas]L’entreprise souhaite se prémunir de toute perte physique de ses données.

La solution proposée par le soumissionnaire doit prévoir des possibilités de sauvegarde, d’archivage et de purge. Le mécanisme d’archivage doit permettre le rechargement simple des données.

Le soumissionnaire précisera :

Sa procédure de réplication des donnés vers un Datacenter de secours ; Sa stratégie sauvegarde et restauration des données ; Les possibilités d’export des données sur un format à plat ; Les certifications dont ils disposent : SAS70 Type II, ISO 27001…Disponibilité/Scalabilité.

L’entreprise prévoit dans un premier temps une amplitude d’usage représentant au maximum une [compléter avec votre quantité d’utilisateurs] simultanés.

Le soumissionnaire indiquera sa capacité à assurer une montée en charge du SIRH et les impacts associés en termes de SLA et de coûts. Il indiquera par ailleurs, les modes de contrôle et mesure des performances.

14.13 Réversibilité


P a g e 59 | 63

document.docx

En cas de fin ou d’interruption du contrat, l’entreprise doit pouvoir :

Récupérer l’ensemble des données et informations lui appartenant dans les meilleures conditions ;

Etre assuré du transfert des activités en cours en interne ou vers un tiers désigné et du maintien du service par le soumissionnaire jusqu’à la prise en main du repreneur.

Dans ce cadre, le soumissionnaire précisera sa procédure de mise en place d’un plan de réversibilité pour le transfert de compétences, la restitution ou le transfert puis la destruction des données de l’entreprise. Il indiquera notamment les coûts propres à la réversibilité, ainsi que les délais sur lesquels il s’engage (constitution du plan de réversibilité, mise en œuvre complète du plan de réversibilité).

L’entreprise souhaite pourvoir récupérer ses données dans des formats de fichiers standards exploitables.

Le soumissionnaire détaillera comment il assure la restitution des données dans des conditions exploitables par le repreneur.

Enfin, le soumissionnaire décrira les mesures prises pour maintenir le système en condition opérationnel durant la période de réversibilité.

P a g e 60 | 63

document.docx

15PERFORMANCE

15.1 Contraintes réseaux

Le soumissionnaire indiquera la bande passante moyenne des sous-systèmes mise en œuvre.

15.2 Exigences de temps de réponse

[A conserver si mode Saas]Le niveau de performance demandé sur le SIRH est d’atteindre :

Des temps de réponse transactionnels inférieurs à 3 s dans 95% des cas, depuis le poste de client utilisateur ;

Des temps de réponse sur report, inférieurs à 10 s dans 95% des cas, depuis le poste de client utilisateur.

Le soumissionnaire détaillera ses engagements de performance sur les solutions proposées et les temps de réponse mesurés.

15.3 Supervision de la performance

[A conserver si mode Saas]L’entreprise souhaite disposer d’un reporting sur les temps de réponse minimum, maximum et moyen sur l’instance du SIRH.

Le soumissionnaire détaillera les mesures de performance réalisées, les moyens mis en œuvre pour effectuer ces mesures, et les moyens mis à disposition de l’entreprise pour consulter le KPI et vérifier la bonne tenue des performances des infrastructures dédiées à l’entreprise : reporting, page d’administration, etc.

P a g e 61 | 63

document.docx

16PRESTATIONS TECHNIQUES

16.1 Tests de performance

Le soumissionnaire fournira un benchmark de son application apportant une vision synthétique sur les performances des environnements et sur les statistiques et habitudes de fréquentation de sa solution. Sinon il définira les modalités, pour réaliser un test de performance sur un périmètre représentatif.

16.2 Maintenance et support applicatif

[A conserver si mode Saas]Le soumissionnaire indiquera les moyens qu’il met en place et qui visent au maintien de l’application dans un état lui permettant de remplir sa fonction selon les SLA défini avec l’entreprise.

Le soumissionnaire détaillera l’organisation qu’il met en place, procédures et les tarifs associés pour :

Ses prestations de correction des incidents fonctionnels et techniques afin de la maintenir en conformité avec les spécifications, indépendamment de toute évolution fonctionnelle ou technique (maintenance corrective) ;

Ses prestations de support applicatif pour répondre aux questions de l’entreprise ; Ses prestations d’évolution fonctionnelle (module supplémentaire ou remplacement de

fonction) et/ ou technique (nouveau socle logiciel, nouvelle version du socle logiciel existant, montée de version de composants).

P a g e 62 | 63

Documents

Cahier des charges : Gestion des Temps et de …€¦ · Web viewAttention, même si le cahier des charges est détaillé il ne peut être envoyé tel quel pour un appel d’offre