Как раскрутить магазин, который физически не примет больше людей: считаем мощность сервисной точки

[Aleksandr_Lar]

Если перейти от наивного велесипедирования процесса к более строгой оценке, то лучше вооружиться формулой Поллачека-Хинчина, представив, что у вас каждый консультант - это одноканальная система массового обслуживания. Исходя из этого можно сделать дальнейший шаг: представить работу магазина как набор режимов с разной интенсивностью заявок - каждая заявка в данном случае будет равна одному покупателю, который обслуживается консультантом.

Дальше можно усложнять модель, детализируя процесс обслуживания, в том числе описывая пространство магазина.

[mybiusty]

Поллачек-Хинчин тут полезен одним: он показывает, что ожидание определяется не средним временем обслуживания, а его дисперсией. При одинаковом среднем приём "30 или 60 минут" и приём "45 ± 3" дадут разное ожидание. Это как раз то, ради чего в конце я прошу медиану и девяностый перцентиль, а не среднее - без второго момента модель считает не то.

Но два допущения M/G/1 у нас не выполняются. Поток не пуассоновский: люди приходят по записи, интенсивность задаём мы сами, а случайность уезжает в отмены и опоздания. И консультант - не независимый канал: два специалиста делят одну примерочную, так что это не M/G/2, а система с блокировкой на общем ресурсе, где второй канал простаивает в ожидании кабины.

Есть и третье отличие, уже не техническое. Переполнение у нас проявляется не как очередь в зале, а как срок записи. Человек не стоит и ждёт - он видит "ближайшее окно через две недели" и не записывается вовсе. То есть потери идут не от времени ожидания, а от отказа на входе, и функция потерь получается разрывной.

Поэтому ваш следующий шаг - набор режимов с разной интенсивностью - мне кажется точнее одной формулы. Чем бы вы описывали ограничение "два канала, одна кабина": блокировкой или конечным числом позиций в системе?

[Aleksandr_Lar]

>Поток не пуассоновский: люди приходят по записи, интенсивность задаём мы сами, а случайность уезжает в отмены и опоздания.

Вот для такой задачи я в своё время смещал акценты, изменив восприятие системы массового обслуживания: во-первых, если правильно подобрать границы режимов, то внутри режимов из детерминированного процесса мы получаем стохастический, что уже позволяет "натянуть" распределение Пуассона. А во-вторых, у нас здесь уже получается что-то похожее на сетевой коммутатор, который ряд задач вынужден считать последовательно.

>Чем бы вы описывали ограничение "два канала, одна кабина": блокировкой или конечным числом позиций в системе?

В данном случае я бы предложил представить ситуацию как "система с конечной очередью (буфером, если угодно)", что позволяет оценить показатель "потеря заявки" - это уже величина позволяющая выявить узкое место записи. То есть продавцы выступают не как независимый элемент СМО, а как часть СМО, состоящая из последовательного соединения "записи", "продавцов", "кабинки" и чего ещё учесть потребуется.

Не помню, правда, как это считается в теории, в практике обычно используют частное приближение формулы Эрланга С, где используется размер конечной очереди, вариации входящего потока и времени обработки и, собственно, интенсивность заявок. Навскидку, у нас размер очереди в этом случае определяется именно "продавцами" и "кабинкой", а собственное время обслуживания заявки узлом СМО - это именно работа продавца, то есть вариацию мы считаем по продавцу. Кстати, из этого подхода хорошо видны условия, в которых у нас появится заметное число отказов, и что с этим делать.

Тут гораздо интереснее вопрос, каким образом провести "вырождение формул" до того вида, от которого у стороннего человека не начнётся испуганное икание.

[mybiusty]

Конечная очередь с буфером ложится точно, и буфер у нас физический: это горизонт записи. Календарь открыт на сколько-то дней вперёд, и "потеря заявки" - это не человек, ушедший из очереди, а человек, который увидел ближайшее окно через две недели и не записался вовсе. Измеряется прямо: доля тех, кому показали дату и кто не подтвердил. Мы такое не считаем, а надо бы - это и есть отказ в вашей терминологии.

С последовательным соединением соглашусь наполовину. "Запись - консультант - кабина" выглядит как цепочка узлов, но кабина не отдельный узел: она захватывается внутри обслуживания и держится не весь приём. Разговор, подбор моделей с полки, оформление идут вне неё. То есть это один узел с двумя ресурсами, и всё решает доля приёма, проведённая в кабине. Если она, скажем, шестьдесят процентов, то предельная мощность точки - не два консультанта, а одна целая шестьдесят семь сотых: кабина упирается раньше людей. Этой доли у меня в цифрах нет, и, судя по всему, её никто не меряет, хотя снимается она секундомером за неделю.

Про приближение - у меня в голове это поправка вида полусумма квадратов коэффициентов вариации входа и обслуживания к эрланговскому ожиданию, Аллена-Куннана. Она же объясняет, почему разброс "тридцать или шестьдесят минут" бьёт сильнее, чем кажется.

А насчёт вырождения формул: по-моему, до одной величины. Коэффициент загрузки. Ожидание растёт как ро на единицу минус ро, то есть при восьмидесяти процентах загрузки оно вчетверо больше, чем при пятидесяти - и это единственное, что владельцу точки нужно унести с собой. Дальше он сам задаёт правильный вопрос: не "сколько дать рекламы", а "сколько у меня сейчас свободного времени в записи".

[Aleksandr_Lar]

>С последовательным соединением соглашусь наполовину. "Запись - консультант - кабина" выглядит как цепочка узлов, но кабина не отдельный узел: она захватывается внутри обслуживания и держится не весь приём.

Такую схему я бы сравнил с нашими любимыми коммутаторами: у коммутатора есть два узких места - входной и выходной порт. Понятно, что у коммутатора огромный буфер (кажется, около 3 мегабайт), процессор коммутатора умеет запускать параллельную обработку событий, но порты являются точками последовательного приёма и передачи кадров, поэтому в частных решениях ТМО для телекома важной величиной является "скорость передачи" - величина, характеризующая максимальную интенсивность передачи информации портом. То есть в вашей модели я бы предложил представить две модели: внешнюю - где всё объединено в один узел, и внутреннюю, где существует явный односторонний граф, включающий в себя узел "записи", два узла "продавцов" и узел "кабинка". Мне видится, что так можно декомпозировать задачу и разделить цели развития.

>Ожидание растёт как ро на единицу минус ро, то есть при восьмидесяти процентах загрузки оно вчетверо больше, чем при пятидесяти - и это единственное, что владельцу точки нужно унести с собой. Дальше он сам задаёт правильный вопрос: не "сколько дать рекламы", а "сколько у меня сейчас свободного времени в записи".

Я бы со своей стороны предложил вообще представить демонстрационные материалы в виде графиков. Один график - это время обработки заявки в зависимости от количества клиентов, второй график - вероятность отказа ("не записи клиента") в зависимости от количества желающих. Добавить визуализацию деления на периоды (то есть "режимы" - с разбиением по будним дням, будним, хаха, вечерам, субботам и так далее). Ну и разбавить слайдами с формулами и графами, чтобы солидно выглядело - будет довольно впечатляющая презентация: "У меня бизнес по науке рассчитан!"

[mybiusty]

Про две модели соглашусь сразу, и цели у них правда разные. Внешняя нужна владельцу: сколько людей в день точка принимает и с какого момента реклама начинает вредить. Внутренняя отвечает на другой вопрос - куда вкладывать следующие деньги. И ответ там неочевидный: если кабина занята, условно, шестьдесят процентов приёма, то второй консультант даёт заметно меньше, чем кажется, а вторая кабина без второго консультанта не даёт ничего вовсе. Это разные инвестиции с разным сроком, и без разделения узлов их не различить.

У коммутатора буфер дешёвый и нейтральный: кадр в очереди не портится. У нас буфер - это горизонт записи, и заявка в нём имеет срок годности. Чем дольше человек ждёт своей даты, тем выше вероятность, что он не придёт вовсе: передумает, найдёт другое решение, решит, что ему это не нужно. То есть буфер не сглаживает пик, а конвертирует его в потери с задержкой. Поэтому "увеличить буфер" - открыть запись на два месяца вперёд - у нас не решение, а способ красиво потерять тех же людей позже.

Про графики: второй, вероятность отказа от числа желающих, важнее первого, он показывает не мощность, а точку, после которой каждый следующий рубль рекламы покупает несостоявшийся визит. Строить его мне пока не из чего - нужна та самая доля не записавшихся после показа ближайшей даты. Если доберусь до замера, покажу оба графика и посмотрим, совпадёт ли форма кривой с тем, что даёт приближение.

А слайды с формулами.... Ценность тут не в том, чтобы выглядело научно, а в том, что владелец перестаёт покупать трафик, который физически не сможет обслужить. Для этого хватает одной цифры загрузки - всё остальное нужно тому, кто решает, что строить дальше.