Moteur de planification / annualisation, déroulement et temps de calcul

Les calculs de plannings et d’annualisation peuvent être découpés en 3 ou 4 phases :

1. Préparation du calcul : le moteur récupère les informations nécessaires au bon déroulement du calcul (contenu des plannings sur la période du calcul, charges des différentes tâches calculées, paramètres de calcul des personnes concernées, affectations de contrats / structures / polyvalences), etc. Les plannings sont verrouillés pendant la phase de préparation afin d'éviter qu'ils soient modifiés pendant le calcul. 
2. Légalisation : le moteur tente de trouver une solution légale pour chacune des personnes ajoutées au calcul, en les traitant une par une. Le recuit simulé est lancé une fois pour chaque personne à légaliser. 
3. Optimisation (seulement s’il s’agit d’un calcul de type optimisation) : le moteur tente d’optimiser la solution globale composée de toutes les personnes légalisées à l’étape précédente. Le recuit simulé est lancé une seule fois pour l’ensemble des personnes à optimiser.
4. Ecriture des résultats : les résultats calculés par le moteur sont écrits en base de données (plannings pour le calcul d’horaires, durées annualisées pour le calcul d’annualisation) ainsi que différentes statistiques sur le déroulement du calcul. Les plannings sont déverrouillés à la fin du calcul au moment de l'historisation par le moteur.

Durée des différentes phases

La durée de la phase de préparation est globalement proportionnelle à la période sélectionnée pour le calcul et au nombre de personnes à calculer (il peut y avoir quelques variations en fonction du nombre de tâches à calculer, de la quantité de charges existant pour ces tâches, du nombre de fiches de paramètres de calcul appliquées aux personnes et aux tâches et du nombre de personnes ayant des programmations d’horaires fixes).

La durée de la phase de légalisation dépend, elle aussi, de la période sélectionnée et du nombre de personnes à calculer, mais pas de manière proportionnelle car elle diffère selon les personnes (qui ont généralement des plannings et des paramètres différents). Si une personne ne peut pas être légalisée (en raison de paramètres de calculs incohérents ou de plannings saisis qui ne permettent pas de respecter les paramètres de calcul) ou s’il n’existe que très peu de solutions permettant de respecter ses paramètres saisis, le moteur va tester et rejeter beaucoup de solutions. Pour éviter qu’il ne passe trop de temps à chercher une solution qui n’existe pas ou qui est très difficile à trouver, un paramétrage est ajouté : la durée maximum de légalisation.

Généralement, on dit que le moteur fonctionne par recopie dans un souci de gain de temps : il construit un planning pour la première personne illégale. Ensuite, il recopie ce premier horaire légal trouvé pour toutes les personnes illégales suivantes, tant que cela fonctionne. 

La durée de la phase d’optimisation dépend essentiellement de la température initiale, de la température finale et du nombre d’itérations, et dans une moindre mesure du nombre de tâches calculées. C’est la seule phase qui ne dépend ni de la période du calcul, ni du nombre de personne à calculer (ou quasiment pas). Le nombre d’itération modifiable dans le paramétrage du calcul n’est utilisé que pour cette phase. Pour les calculs sur une longue période ou comportant beaucoup de personnes, cette phase est généralement plus courte que la phase de légalisation.

La durée de la phase d’écriture des résultats est directement proportionnelle à la période sélectionnée pour le calcul et au nombre de personnes à calculer.

D’un point de vue technique, toutes ces durées dépendent aussi fortement des performances de la machine sur laquelle s’exécutent l’instance de Timesquare et le moteur de calcul.

La première et la dernière phase dépendent aussi des performances du serveur de base de données et de la connexion réseau entre la machine sur laquelle s’exécutent l’instance de Timesquare et le moteur de calcul et le serveur de base de données.

Programmation par contrainte

Pour rappel, le principe de la programmation par contraintes (PPC) est de modéliser un problème à l'aide de variables et de contraintes qui relient ces variables entre elles. Ensuite, on applique les opérations liées aux contraintes pour restreindre les valeurs que peuvent prendre chaque variable jusqu'à atteindre un état stable, puis on affecte aléatoirement une valeur à l'une des variables. On recommence le cycle jusqu'à obtenir une solution dans laquelle toutes les variables ont une valeur unique ou on constate qu'il n'y a pas de solution possible.  

Exemple

• Heure de début de journée : 08:00
• Heure de fin de journée : 19:00
• Durée minimum de plage unique (jour sans coupure) : 05:00
• Durée maximum de plage unique (jour sans coupure) : 07:00

On peut réduire ces domaines :

La plage peut uniquement finir au plus tôt qu'à 09:00 + 05:00 = 14:00

La plage peut uniquement commencer au plus tard à 19:00 - 07:00 = 12:00

Lorsque tous les domaines sont stables, on choisir une variable à laquelle on affecte une valeur aléatoire parmi son domaine. Par exemple on fixe l'heure de début = 10:15. On recommence la réduction des domaines, etc.

Lors du placement d’un modèle horaire hebdomadaire, le moteur s'appuie sur la programmation par contraintes (PPC) afin de forcer le choix des solutions qui respectent certains paramètres lors du calcul des bornes variables d’un modèle horaire hebdomadaire.

Modélisation des modèles horaires hebdomadaires à bornes variables

Dans un premier temps, les paramètres pris en compte sont les suivants (en plus des paramètres déjà pris en compte pour le placement des modèles quotidiens) :

• Durée hebdomadaire minimum / maximum
• Durées hebdomadaires autorisées
• les paramètres du groupe PD10 (excepté "Durées quotidiennes identiques")
• Jours identiques
  • Jours identiques : optimiser sur les coupures
  • Jours identiques : delta autorisé sur début de journée
  • Jours identiques : delta autorisé sur fin de journée
  • Jours identiques : inclure les plages d'absences partielles

Le placement des modèles horaires quotidien applique également de la PPC pour s’assurer que les bornes variables calculées permettent de respecter un certain nombre de paramètres de calculs.

L’impact sur les performances n’est pas négligeable lorsque des modèles horaires à bornes variables sont utilisés (aucun impact s’ils ne sont pas utilisés) : le temps d’optimisation est beaucoup plus long. En contrepartie, la légalisation des personnes est quasi instantanée dans la plupart des cas.

Durée maximum de légalisation

La durée maximum de légalisation est une durée en secondes au-delà de laquelle le moteur doit arrêter d’essayer de légaliser une personne et passer à la suivante, même si l’algorithme du recuit n’a pas encore atteint la température finale.

Le paramétrage de cette durée est nécessairement empirique car il dépend de la problématique de chaque client, voire de chaque calcul :

• Si la valeur est trop faible, un grand nombre de personnes risquent de ne pas être légalisées alors qu’elles auraient (peut-être) pu l’être.
• Si la valeur est trop grande, les personnes non légalisables (ou difficilement) vont considérablement allonger le temps de calcul.
• Si la valeur dépasse le temps nécessaire au recuit pour atteindre la température finale, elle est inutile.

La durée maximum de légalisation d’une personne peut rallonger le temps de calcul de manière très importante s’il y a beaucoup de personnes illégales ou difficilement légalisables. En effet, toute personne illégale consommera entièrement la durée maximum de légalisation (et celles difficilement légalisables en consommeront une bonne partie).

Dans ce cas, la phase de légalisation peut constituer la majeure partie de la durée du calcul et expliquer sa lenteur.

Par exemple, sur un calcul de 200 personnes, si 50 personnes sont illégales avec une durée maximum de légalisation à 10s, cela veut dire que 500s seront nécessairement consommées pour ces personnes illégales, soit 8 minutes 20s (sans compter le temps pour légaliser les 150 autres). Si la durée maximum de légalisation est à 30s, cela fera 25 minutes.

Nombre d'itérations

Les lenteurs de calcul liées à la légalisation n'ont pas de rapport avec le nombre d’itérations car cette valeur n’est utilisée que pour l’optimisation.

Pendant la légalisation, le nombre d’itérations n’est pas modifiable dans le paramétrage du calcul, il est défini dans les réglages de l’application.

Période de calcul et période étendue

La durée de la période de calcul est susceptible d'impacter la durée du calcul. Par exemple, un calcul pour une période d'une semaine sera plus rapide qu'un calcul pour une période d'un mois.

Par ailleurs, certains paramétrages sont susceptibles de rallonger la période de calcul (que l'on appelle période étendue). C'est le cas des paramètres par période qui nécessitent pour être bien pris en compte d'étendre la période de calcul. C'est également vrai pour certains paramètres par personne.

Exemple 1 : je souhaite lancer un calcul d'une semaine du lundi au dimanche mais j'ai un paramètre de calcul qui indique une amplitude entre le samedi et le lundi.

Exemple 2 : je souhaite lancer un calcul d'une semaine du lundi au dimanche mais j'ai un paramètre de calcul qui indique un nombre de nocturnes maximum sur 2 mois glissants.

Contraintes liées au paramétrage

Les personnes illégales ou difficilement légalisables peuvent être dues à un paramétrage très contraignant que le moteur ne sait pas bien traiter ou à un problème de paramétrage incohérent.

Exemple de cas pratiques de paramétrage à vérifier :

• Utilisation de modèles horaires qui ne sont pas en phase avec les attentes en matière de couverture. Exemple : Des modèles horaires à bornes variables (pour la coupure) qui commencent à 08h et finissent à 17h alors que les charges des tâches commencent à 09h et se terminent à 18h.
• Durée hebdomadaire maximum d'une tâche qui n'est pas en phase avec le besoin à couvrir, ni avec la durée maximum par jour. Exemple : une tâche A et une tâche B ayant respectivement une durée hebdomadaire maximum de 04h00 et 02h00 avec un besoin à couvrir de 40h chacune et 12 personnes qui ont la compétence. Au mieux, je pourrai avoir 48h00 pour l'une et 24h00 pour l'autre. Il y aura donc forcément du manque.
• Incohérence entre un paramètre par personne (la durée minimum/maximum sur une tâche A par exemple) et un paramètre par tâche
• Utilisation abusive des poids

Prise en compte des plannings INI ou MOD en cours dans la préparation du calcul de plannings

Il est possible de définir dans les réglages du logiciel la ou les versions de plannings qui doivent être utilisées lors de la préparation du calcul des plannings INI ou MOD.

Pour le calcul du planning initial, si je sélectionne l'option "Initial uniquement", le moteur ne tient compte que des plannings présents dans l'initial. C'est le fonctionnement "historique".

Si je sélectionne l'option "Initial + Modifiable", le moteur prend en compte les plannings issus du modifiable à la place des plannings issus de l'initial lorsqu'ils existent. Cependant, il ne modifie et ne sauvegarde aucun planning modifiable lors du calcul.

Si la granularité du modifiable est différente de celle de l'initial, il n'est pas possible de sélectionner "Initial + Modifiable".

Pour le calcul du planning modifiable, si je sélectionne l'option "Modifiable uniquement", le moteur vérifie la présence de plannings initiaux validés sur toute la période étendue du calcul. Les personnes pour lesquelles il existe du planning initial non validé sur cette période étendue ne seront pas calculées.

Si je sélectionne l'option "Initial + Modifiable", le moteur prend en compte les plannings initiaux lorsque ceux-ci ne sont pas validés (et qu'il n'existe donc pas de plannings modifiables). Les personnes seront donc calculées même si elles ont des plannings initiaux non validés. Cependant, le moteur ne modifie et ne sauvegarde aucun planning initial lors du calcul.

Si la granularité du modifiable est différente de celle de l'initial, il n'est pas possible de paramétrer la préparation ni de lancer de calcul sur le modifiable.