Методы, основанные на анализе хронологических данных за ка­кой-то интервал времени, например за последние полчаса, опери­руют такими показателями, как средняя скорость ответа, задан­ный уровень обслуживания и т. п. Давайте рассмотрим подробнее распространенный метод Average Speed of Answer (ASA), основан­ный на определении средней скорости ответа за какой-либо отре­зок времени, чаще всего — за последние полчаса. Схематично это выглядит так.

Предположим, в операторский центр поступил вызов опре­деленного типа. Система определяет, что среднее время ожида­ния для вызовов данного типа за последние полчаса составило 2 минуты. Поэтому она экстраполирует этот показатель и на вновь прибывший вызов и прогнозирует, что он также прождет 2 минуты. Через каждые полчаса показатель ASA снова пересчи­тывается.

Такая схема вполне работоспособна, но лишь в случае равно­мерной нагрузки. Однако, как мы уже не раз говорили, постоянная равномерная нагрузка для операторского центра — вещь идеальная и потому недостижимая. А как только происходит скачкообразное нарастание потока вызовов, любой метод, основанный на анализе не текущей, а уже прошедшей ситуации, начинает буксовать. Опе­ративная ситуация-то резко изменилась и оказалась достаточно да­лека от той, что была 10, а тем более 20 минут назад. И чем дальше, тем больше расчетное время ожидания расходится с реальным.

Схематично данный процесс показан на рисунке 3.3.

Из приведенного графика видно, сколь неточно работает дан­ная методика. Например, уже для 30-го звонка предполагаемое время ожидания, рассчитанное по методу ASA, может составить 3 минуты, в то время как в действительности оно будет состав­лять 13 минут. Разве можно принимать адекватные решения, ба­зируясь на такой недостоверной информации?