2009-11-06 27 views
2

Je me suis cogné la tête contre un mur sur celui-ci. Je travaille sur un projet où le client possède un centre d'appel et veut estimer le nombre de personnes nécessaires pour travailler dans des périodes d'une demi-heure sur une campagne en entrant une heure de pointe, une estimation des personnes nécessaires dans ce heure et vraisemblablement un écart-type. Cela devrait alors "déployer" les valeurs vers les autres emplacements (diminuant des deux côtés du pic).Approximation des nombres d'une courbe en cloche?

S'il s'agissait d'un graphique, vous auriez des demi-heures sur l'axe des abscisses (1 à 48) et le nombre de personnes nécessaires le long de l'axe des y, ce qui ressemblerait à une courbe en cloche. heure de pointe.

Comment puis-je obtenir des valeurs approximatives des sièges nécessaires pour chaque fente d'une demi-heure? Tout point dans la bonne direction serait très apprécié!

P.S. Travailler dans .NET si quelqu'un connaît des bibliothèques qui peuvent le faire.

+0

Je m'attendrais à ce qu'il y ait plusieurs pics. –

+0

Le client veut des distributions «emballées sous film rétractable», c'est-à-dire: un pic, deux crêtes, montée et descente cohérente, etc. Je commence par la plus simple dans l'espoir qu'une fois que j'en aurai une autre difficile! – user204616

Répondre

3

Vous pouvez obtenir la Préparations pour la fonction de densité de probabilité (avec un libary .NET) here

Cependant, je travaille sur un logiciel de centre d'appels moi-même à mon travail, et je peux vous dire que les ETP ne sont jamais normalement distribué. Il y a habituellement ~ 2 ou 3 distributions normales qui se chevauchent, l'une asymétrique gauche et l'autre asymétrique droite selon l'heure de la journée (tôt le matin, fin d'après-midi) et le type de campagne (B2B à B2C). Pour une estimation plus précise, je vous recommande de conserver un historique des activités/charges précédentes dans votre centre d'appels (quelle est la charge moyenne à chaque demi-heure d'intervalle), puis de l'utiliser comme base de distribution, en l'adaptant la charge maximale prévue et la durée d'appel estimée. C'est ce que nous faisons dans ProtCall, et nous avons généralement raison de 90% à 95% de la charge réelle. Parfois. Parfois, nous manquons d'un facteur de 10.

EDIT:

Ok, je pris un peu de temps pour voir comment nous estimer les charges et distribution standard ne va pas vous mènera nulle part. Jetez un oeil à un couple de screenshots de nos cartes et vous verrez à quel point la distribution ressemble réellement.

Ce que vous devez faire (essentiellement):

  1. Exemple le nombre d'appels effectués chaque minute (nombre d'appels que nous avions depuis il y a 60 secondes)
  2. Enregistrer ces échantillons dans un tableau: TimeOfDay, CallsMade
  3. Chargez ces échantillons et mettez-les à l'échelle. (c'est-à-dire si notre table totale a 10.000 appels et nous estimons que notre nouvelle activité pour avoir 4.000 appels par jour, multiplions tout par 0.4.Vous pouvez échelle par environ nr d'appels ou (plus acuratelly) par le nombre de temps de conversation minutes par jour environ)

Sinon, si vous avez simplement une table avec une entrée de ligne pour chaque appel effectué, vous pouvez simplement:

SELECT count(*),datepart(hour,[CalledOn]) as CalledOn from tableCalls group by datepart(hour,[CalledOn]) 

de compter les appels effectués chaque heure. Il prélèvera des échantillons par heure, par minute, mais il pourrait être assez pour vous donner la ligne de base

+0

Pensez-y plus vous avez complètement raison, ce qui le rend encore plus compliqué :( Alors oui, ils devraient préciser les heures de début et de fin (c'est-à-dire 9 heures-17 heures) et une heure de pointe. Avez-vous fait quelque chose comme ça dans votre logiciel de centre d'appel? Des pointeurs? – user204616

+0

Brillant, vous avez donné mes informations suffisantes pour que je puisse retourner au client et expliquer pourquoi ils veulent n'est pas la meilleure solution! Cheers – user204616

0

Je suppose que ce n'est pas vraiment une réponse, mais l'industrie du téléphone utilise le Erlang comme une unité de mesure pour ces types de problèmes, qui est dérivée de la durée moyenne des appels et le nombre moyen d'appels simultanés dans une période .

2

Hmmm

Je serais surpris si la distribution des appels pendant la journée (24 heures de minuit à minuit) était normal (c'est-à-dire suivi la courbe en cloche). Cependant, si c'est ce que le client a commandé, qu'il en soit ainsi. Mais avant d'aller plus loin, faites des recherches plus approfondies.

Est-ce que votre présomption que le client peut spécifier un dev correct? Les appels ne seront pas normalement distribués sur l'heure de pointe dans la journée, à moins que l'heure de pointe ne soit 12:00 - si le client croit vraiment que la distribution des appels est unimodale entre 00:00 et 23:00. : 59, alors je parie que le mode n'est pas à 12:00.

Comme l'a déjà dit un de vos répondants, vous pouvez facilement trouver les formules et les implémentations de la distribution normale. Mais si vous voulez impressionner votre client et construire un meilleur modèle, je commencerais par une simple mise en file d'attente.

+0

La présomption que le client peut spécifier un dev std est ... pas correct :(, en fait, ils ne le seront probablement pas.Mon pensée plutôt naïve était que je pouvais ajuster le dev std pour faire une courbe en cloche qui ressemble à peu près à l'ascension et à la chute d'un jour de centre d'appel normal. Pouvez-vous clarifier ce que vous entendez par "simp"? le queuing "? Merci – user204616

+0

Bien sûr il y a! bouchon sans vergogne (lien dans mon profil) .. – Radu094