Approssimando numeri da una curva a campana?

Question

Sono stato sbattere la testa contro un muro su questo.

Sto lavorando su un progetto in cui il cliente possiede un call center e vuole stimare il numero di persone necessarie per lavorare in slot di mezz'ora su una campagna inserendo un ora di punta, una stima delle persone necessarie a quell'ora e presumibilmente una deviazione standard. Questo dovrebbe poi "a ventaglio" i valori agli altri slot (decrescenti su entrambi i lati del picco).

Se questo è un grafico che si avrebbe la metà slot orari sul asse x (1 a 48) e il numero di persone necessarie lungo l'asse y, che apparirebbe come una curva a campana con il picco essendo al picco specificata ora.

Come posso ottenere valori approssimativi dei seggi necessari per ogni slot mezz'ora? Qualsiasi punto nella giusta direzione sarebbe molto apprezzato!

P.S. Lavorare in .NET se qualcuno sa di eventuali librerie che può fare questo.

Answer 1

È possibile ottenere il Forumula per la funzione di densità di probabilità (insieme a una libary NET) qui

Comunque, io lavoro in un call center software me stesso al mio lavoro, e posso dirvi i posti a tempo pieno non sono mai distribuiti normalmente. Di solito ci sono ~ 2-3 sovrapposte distribuzioni normali, una distorta a sinistra e uno a destra distorta a seconda del momento della giornata (mattina, tardo pomeriggio) e tipo di campagna (B2B al B2C).

Per una stima più precisa Vorrei raccomandare mantenere una storia di precedente attività / carico nel vostro call center (qual è il carico medio ad ogni intervalli di mezz'ora) quindi utilizzare che, come la linea di base della distribuzione, adattarne le dimensioni per la carico massimo previsto e la durata della chiamata previsto. Questo è ciò che facciamo in ProtCall, e noi siamo di solito a destra nel 90% - 95% del carico effettivo. A volte. A volte ci manca di un fattore 10.

EDIT:

Ok, ho preso un po 'di tempo a guardare come si stima carichi e distribuzione standard non sta per arriva da nessuna parte. Date un'occhiata a un paio di screenshot dalle nostre tabelle e vedrai come ci ha offerto la distribuzione appare in realtà.

Quello che dovete fare (in pratica):

1. del campione Il numero di chiamate effettuate ogni minuto (il numero di chiamate che abbiamo avuto da quando 60 secondi fa)
2. Salva quei campioni in una tabella: timeofday, CallsMade
3. Carica quei campioni e li scala. (Es. Se il nostro tavolo totale è 10.000 chiamate e si stima la nostra nuova attività di avere 4.000 chiamate al giorno, moltiplicare tutto per 0,4. Si può scala da nr stimato di chiamate o (più acuratelly) per numero stimato di tempo di conversazione-minuti al giorno)

In alternativa, se avete semplicemente una tabella con una voce riga per ogni chiamata effettuata si può semplicemente:

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

per contare le chiamate effettuate ogni ora. Sarà campione per ora, non per minuto, ma potrebbe essere sufficiente per darvi la linea di base

Answer 2

Hmmm

Sarei sorpreso se la distribuzione delle chiamate durante il giorno (24 ore da mezzanotte a mezzanotte) era normale (cioè seguì la curva a campana). Tuttavia, se questo è ciò che il cliente ha ordinato, così sia. Ma prima di andare molto più in là, fare un po 'di ulteriori indagini.

è il presupposto che il cliente può specificare un dev std corretta?

Le chiamate non verranno distribuiti normalmente circa l'ora di punta in un giorno, a meno che l'ora di punta sembra essere 12:00 - se il cliente crede veramente che la distribuzione delle chiamate è unimodale tra le 00:00 e 23: 59, quindi scommetto che la modalità non è alle 12:00.

Come uno dei tuoi intervistati ha già detto, è possibile trovare le formule e le implementazioni della distribuzione normale abbastanza facilmente.

Ma se volete stupire il vostro cliente e costruire un modello migliore, mi piacerebbe iniziare con qualche semplice messa in coda.

Answer 3

Credo che questo non è davvero una risposta, ma l'industria telefonica utilizza il Erlang come unità di misura per questo tipo di problemi, che deriva dalla lunghezza media chiamata e il numero medio di chiamate simultanee in un periodo.