Ce document décrit en détail le module de prévision avancée des besoins en agents et comment Community utilise des clusters pour réduire considérablement le nombre d'agents requis grâce à la formation croisée des agents, fournissant ainsi une prévision plus précise du nombre d'agents nécessaires pour satisfaire la charge du centre de contact.
Pourquoi la prévision avancée des besoins en agents?
Community, comme la plupart des applications actuelles de gestion de la main-d'œuvre, fournit des prévisions des besoins en agents basées sur les formules mathématiques Erlang-C pour convertir les appels, les temps de traitement et les objectifs de service en agents requis. Bien que les formules Erlang-C se soient avérées fiables au fil du temps dans leurs calculs, elles ne tiennent pas compte des agents multiskills dans le centre de contact. La formule suppose que les agents seront dédiés à répondre uniquement à la demande d'une seule compétence.
Le concept derrière la stratégie de "clustering" est de regrouper les activités pour générer des besoins en effectif d'agents en analysant la matrice de formation croisée des agents impliqués dans un horaire. À mesure que la formation croisée augmente, le nombre d'agents requis pour satisfaire la demande dans une seule activité est réduit car, encore une fois, les agents sont partagés entre plusieurs activités. Le clustering doit être effectué de manière à ce que l'allocation soit proportionnelle au volume d'appels pour l'activité, mais relative au nombre d'agents qui ont également l'affectation de l'activité particulière.
Une fois les activités regroupées, elles peuvent être prévues comme une seule activité et les efficacités de la formation croisée des agents sont réalisées. Le cluster représente un groupe d'activités connexes, et pour l'activité membre d'un cluster, Community calcule une probabilité qu'un appel soit répondu par l'activité donnée dans le cluster donné. Plus la matrice de formation croisée pour les agents dans l'horaire est disjointe, plus il y aura de clusters.
Considérons un exemple typique.
(Pour tous les exemples présentés dans ce document, supposez un niveau de service de 80/20.)
Tout d'abord, supposons qu'il n'existe aucune formation croisée entre les agents affectés aux compétences ci-dessus. Cela apparaîtrait comme dans le tableau d'affectation des agents suivant :
Dans ce cas, la prévision des besoins en agents basée sur Erlang-C est parfaitement correcte, car aucune efficacité ne peut être réalisée grâce à la formation croisée des agents.
Maintenant, considérons l'autre extrême, où chaque agent est affecté à toutes les compétences disponibles. Dans ce cas, le tableau d'affectation des agents apparaît comme suit :
Le principe fondamental derrière l'algorithme de clustering est que la demande (volume de contacts et temps de traitement) pour les compétences couramment assignées peut être combinée en une seule compétence et re-prévue en utilisant la formule standard Erlang-C.
Dans l'exemple ci-dessus, tous les agents sont disponibles pour toutes les compétences, donc essentiellement la demande peut être
représentée comme une compétence composite unique. Dans ce cas, les éléments suivants seront prévus :
Dans cet exemple, nous pouvons voir que la formation croisée a permis un gain d'efficacité de 12 % pour les agents (8
agents) simplement en combinant les compétences formées en croisé. Notez que la colonne Temps de Traitement Pondéré est
le temps de traitement moyen pondéré par le volume calculé comme suit :
SOMME( Temps de Traitement Moyen * ( SOMME(Volume) ) )
Dans cet exemple :
(250 * (100 / 175) ) + (300 * (50 / 175) ) + (320 * (25 / 175) ) = 274 ttp
Cependant, dans la plupart des cas, la population d'agents n'est ni 100 % formée en croisé ni 0 %
formée en croisé. Le résultat est que la capacité à regrouper des activités couramment assignées est significativement
difficile. Pour accomplir cela, Community utilise un algorithme basé sur une équation quadratique pour
déterminer la similarité des compétences entre les agents. Le résultat est un ensemble de clusters d'activités et la
probabilité qu'un appel soit répondu par une activité donnée dans chaque cluster.
Comment Community génère-t-il les clusters ?
Les clusters fournissent la probabilité qu'un appel puisse être répondu dans une compétence d'un cluster. Dans l'exemple
entièrement formé en croisé ci-dessus, Community créerait un seul cluster qui représente toutes les compétences
et agents. Le résultat est que chaque compétence (activité) dans le cluster aurait une probabilité de 100 % d'être
satisfaite dans ce cluster, simplement parce qu'aucun autre cluster n'existe.
Cependant, si la formation croisée est fragmentée, plus de clusters en résultent, et les probabilités varieront
en fonction des clusters impliqués. Considérons une matrice de formation croisée plus réaliste :
Lors du processus de création d'une Prévision des Besoins en Agents, Community génère les
clusters basés sur la matrice ci-dessus. Le résultat est trois clusters pour chaque activité, en raison de la
fragmentation des activités en français et en espagnol. La matrice de clusters résultante apparaît comme
suit :
L'examen des clusters révélera que le Cluster 0 est la combinaison des activités en anglais et en
espagnol, le Cluster 1 est la combinaison des trois activités, et le Cluster 2 est la
combinaison des activités en anglais et en français.
Le Cluster 0 est le résultat de la formation croisée fournie par l'Agent2, qui est assigné uniquement à l'anglais et
à l'espagnol. Le Cluster 1 est le résultat de la formation croisée fournie par l'Agent3, qui est assigné aux trois
activités. Le Cluster 2 est le résultat de la formation croisée fournie par l'Agent1, qui est assigné uniquement
à l'anglais et au français.
Remarquez également que l'activité en anglais apparaît dans tous les clusters. La raison en est que tous les agents sont
assignés à l'activité en anglais, donc dans tous les clusters, il existe une chance qu'un appel offert à l'activité en anglais
soit répondu dans chaque cluster. Puisque tous les agents sont assignés à l'anglais, la probabilité est
répartie équitablement entre les clusters.
Que font les clusters ?
Encore une fois, les clusters fournissent la probabilité qu'un appel offert à une activité soit pris en charge par l'activité dans le cluster. Les probabilités pour une activité dans les clusters s'additionneront toujours à 100 (100 % de probabilité que l'appel soit répondu par l'activité dans un cluster). Essentiellement, pour une matrice de formation croisée donnée, les clusters fournissent les bonnes combinaisons d'activités à prévoir comme un seul groupe combiné. Le regroupement correct des activités se situe quelque part entre les deux extrêmes (aucune formation croisée et 100 % de formation croisée), et les clusters fournissent la stratégie de regroupement.
La première étape pour créer la prévision avancée est de déterminer le nombre de serveurs en fonction du volume et du temps de traitement pour toutes les activités incluses dans le cluster. Essentiellement, l'algorithme regroupe tout le volume pour toutes les activités ensemble, comme dans l'exemple de formation croisée à 100 % ci-dessus. Cependant, le volume des activités n'est pas inclus dans la demande regroupée si la probabilité qu'un appel soit pris en charge dans ce cluster est de 0. Le tableau suivant illustre la demande regroupée résultant des clusters définis ci-dessus :
Rappelez-vous que le Cluster 0 est une combinaison d'anglais et d'espagnol, qui contribuent respectivement à 100 et 50 appels au « pool » combiné. Le temps de traitement moyen pondéré est calculé comme décrit ci-dessus.
Le Cluster 1 est une combinaison des trois activités, résultant en une demande regroupée de 175 (100 + 50 + 25), et le Cluster 2 est une combinaison d'anglais et de français avec une demande regroupée de 125 (100 + 25).
L'algorithme calcule ensuite le nombre de serveurs pour l'ensemble de la demande combinée en utilisant les objectifs de service de l'activité actuelle. L'algorithme additionnera les serveurs proratisés dans tous les clusters où la probabilité est > 0. La formule ci-dessous fournit les serveurs regroupés pour une activité donnée :
Serveurs Regroupés = SOMME( wC * sP * ( cA / cP) )
Où :
• wC est le poids pour un cluster donné
• sP est les serveurs pour la demande regroupée
• cA est le volume pour l'activité donnée
• cP est le volume pour le pool donné
• En substituant nos valeurs pour les activités ci-dessus :
L'accumulation de toutes les exigences en agents est de 34 + 17 + 8, soit 59 agents. Comparé à la prévision initiale des exigences en agents basée sur Erlang C de 67, nous réalisons un gain d'efficacité de 10 agents, soit environ 15 % pour cet intervalle particulier. Remarque : toutes les valeurs pour les agents requis sont arrondies au nombre entier supérieur pour garantir que les niveaux de service souhaités sont atteints.
Le calcul de l'efficacité pour comparer la Prévision Standard à la Prévision Avancée est le suivant :
Heures de Personnel – Heures de Personnel Avancées / Heures de Personnel
Prévision pour des Objectifs de Service Dissimilaire
L'algorithme ci-dessus calcule l'effectif requis pour satisfaire la proportion de la demande regroupée d'une activité donnée en fonction des objectifs de service de l'activité. Bien que les valeurs de volume et de temps de traitement pour le pool soient utilisées pour plusieurs activités, les serveurs (agents) requis sont basés sur les objectifs de service spécifiques de l'activité. Par conséquent, l'exigence d'effectif résultante pour le pool est basée sur le niveau de service pour l'activité et, par conséquent, le montant proratisé reflète l'objectif de service individuel.
Considérons l'exemple ci-dessus avec un niveau de service pour l'espagnol à 90/10.
Le nombre de personnel résultant augmente pour le Cluster 0, reflétant le niveau de service accru requis
pour l'espagnol. Cependant, les autres activités ne sont pas affectées par l'objectif de service différent.
Valeurs de synthèse pour les activités parentes / Calcul des heures de dotation /
Calcul des ETP
La méthode pour afficher les besoins en agents au niveau d'une activité parente est la même entre
la prévision standard et la prévision avancée. Les heures de dotation à n'importe quel niveau de l'activité
sont calculées comme suit :
SOMME (Besoins en personnel par intervalle / Emplacements par défaut du système par heure)
Dans les exemples ci-dessus, si chaque intervalle entre 7h00 et 17h00 (inclus) nécessitait 59
agents, alors les heures de dotation au niveau parent seraient :
Agents requis * Emplacements/Heure * Heures (59 * 4 * 10) + 59 = 604 heures de dotation
Notez que les derniers 59 sont dus à l'inclusion de l'intervalle de 17h00 dans la prévision.
Le calcul des ETP basé sur les heures de dotation est :
Heures de dotation / 8,0 (Supposons qu'un ETP est un employé de 8 heures).
Ces valeurs pour une activité individuelle sont identiques à une activité parente.
Horaire standard Erlang vs. prévision avancée des besoins en agents
Community offre aux horaires la possibilité de choisir la méthode de prévision utilisée pour générer les horaires. Si la prévision avancée des besoins en agents est sélectionnée (en utilisant des méthodes de prévision basées sur les compétences), Community exporte la valeur des besoins en agents avancée pour l'intervalle. Si la prévision standard est sélectionnée, alors Community exporte la prévision d'agents basée sur Erlang standard. Cependant, dans les deux cas, le moteur d'optimisation optimisera la main-d'œuvre sur toutes les activités assignées.