SABSUS

КЛИЕНТСКИЙ СЕРВИС · УСТРОЙСТВО ОЧЕРЕДИ

Одна очередь или отдельные: сравнение при той же команде

Один сотрудник уже свободен, а клиент продолжает ждать другого. Иногда причина в обязательном навыке или назначенном специалисте. Иногда — только в том, что заявка заранее попала в отдельную очередь. Чтобы различить эти случаи, сравните две схемы на одних и тех же событиях.

Редакция SABSUS · · Источники проверены 12 октября

Какое решение принимает руководитель

Нужно решить, закреплять ли ещё не начатые обращения за отдельными сотрудниками сразу при поступлении или оставлять их в общей очереди до освобождения допустимого исполнителя. Число сотрудников, состав обращений и длительность работы могут остаться прежними; меняется момент выбора исполнителя.

Это другой вопрос, чем расчёт количества операторов через Erlang C. Там одна общая очередь уже является предпосылкой. Здесь сравниваются сама общая очередь и две раздельные, без стационарных вероятностных формул и без обещания, что объединение всегда улучшит каждый клиентский результат.

В статье Harchol-Balter и Scully The most common queueing theory questions, раздел 2.3 pooling представлен как переход от отдельных очередей к одной, обслуживаемой теми же параллельными ресурсами. Ниже используется только эта структура сравнения. Числа и последовательность событий — оригинальный учебный пример, а не перенос результатов компьютерной системы на реальную сервисную команду.

Сначала подтвердите взаимозаменяемость

В примере два сотрудника обслуживают обычные запросы к сервисной стойке. Каждый может выполнить любую из четырёх работ за указанное время и принимает только одну одновременно. Нужные рабочие места доступны, дополнительных переходов, подготовки и обязательного закрепления клиента за конкретным человеком нет.

Если запрос требует отдельного навыка, доступа к данным, оборудования или согласованного специалиста, свободный сотрудник может не быть допустимым. Объединение списков это ограничение не снимает. Для нескольких одновременно обещанных работ используйте отдельную проверку всего набора назначений.

Microsoft описывает очереди как способ собирать и распределять работу между их участниками; методы назначения учитывают, в частности, навыки, доступность и ёмкость. Microsoft Learn: queues for unified routing. Это пример условий маршрутизации, а не подтверждение нужной настройки в SABSUS.

Четыре запроса: одинаковый вход для обеих схем

Все данные вымышлены. Время измеряется минутами от общего нуля. До начала оба сотрудника свободны. Работа не прерывается после старта, клиент не уходит из очереди, повторных запросов нет. Длительности заданы точно для этого короткого расчёта; в живом процессе их пришлось бы оценивать и проверять.

  • A поступает на отметке 0, занимает 8 минут.
  • B поступает на отметке 0, занимает 2 минуты.
  • C поступает на отметке 1, занимает 2 минуты.
  • D поступает на отметке 2, занимает 2 минуты.

В обеих схемах A сразу начинает у сотрудника 1, B — у сотрудника 2. Для раздельного варианта заранее задано направление: C поступает в очередь сотрудника 1, D — сотрудника 2. Внутри каждой очереди действует порядок поступления; переходить в соседнюю после этого нельзя.

В общем варианте ещё не начатые запросы ждут вместе. Освободившийся сотрудник берёт самый ранний ожидающий запрос. На отметке 2 сначала учитываются завершение B и поступление D, затем выбирается следующая работа. C пришёл раньше D, поэтому первым выбирается C. Для одновременных поступлений заранее нужен устойчивый порядок; на наш выбор между C и D это не влияет.

Две отдельные очереди: свободный сотрудник рядом с ожиданием

Сотрудник 1 выполняет A с 0 до 8, затем C с 8 до 10. C поступил на 1 и ждёт семь минут. Сотрудник 2 выполняет B с 0 до 2, затем сразу D с 2 до 4. После отметки 4 он свободен, но по правилам этой схемы не забирает C из чужой очереди.

Ожидание A, B, C, D: 0, 0, 7, 0 минут. Сумма — 7, среднее по всем четырём запросам — 1,75 минуты. Завершения: A = 8, B = 2, C = 10, D = 4.

На интервале 4–8 одновременно существуют свободный сотрудник 2 и ещё не начатая работа C, которую он по условиям способен выполнить. Это конкретный признак потери возможности из-за разделения очередей. Если бы C требовал только сотрудника 1, тот же внешний рисунок не доказывал бы такую потерю.

Общая очередь: тот же труд, другие моменты начала

A и B начинают как прежде. На отметке 2 сотрудник 2 заканчивает B и берёт ожидающего с отметки 1 клиента C: работа идёт 2–4. D поступает на 2, ждёт до 4 и обслуживается 4–6. Сотрудник 1 завершает A на 8; начатую A никто не останавливает и не передаёт.

Ожидание A, B, C, D: 0, 0, 1, 2 минуты. Сумма — 3, среднее — 0,75 минуты. Завершения: A = 8, B = 2, C = 4, D = 6.

Общее ожидание сократилось на четыре минуты, а последняя из четырёх работ закончилась на 8 вместо 10. Но D стало хуже: он ждёт две минуты вместо нуля и получает результат на 6 вместо 4. Улучшение общего итога не является обещанием улучшить результат каждого человека.

Полезной работы в обоих вариантах ровно 8 + 2 + 2 + 2 = 14 сотруднико-минут. На одинаковом горизонте 0–10 два сотрудника дают 20 доступных минут, из которых 14 заняты: в обеих схемах 70%. Свободные минуты иначе расположены во времени. Нельзя объявить рост производительности, поменяв вместе со схемой конец измеряемого периода.

Что этот пример подтверждает, а чего не подтверждает

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

Результат может измениться, если другой сотрудник работает медленнее с некоторыми запросами, нужна передача контекста, очереди имеют разные обещания или клиент согласовал определённого исполнителя. Тогда сначала меняются условия модели, а затем пересчитывается расписание. Нельзя оставить прежние две минуты C, если перенос фактически добавляет обучение или проверку.

Общая очередь также не означает автоматического объединения всех приоритетов. Если часть клиентов должна обслуживаться по отдельным обязательствам, нужен явный порядок выбора и проверка последствий. Правила приоритета и старения ожидания отвечают на эту отдельную задачу.

Работы, которые уже начаты, сохраняют исполнителя в нашем сравнении. Их остановка или перенос требуют другого решения о допустимости, сохранённом результате и сроках, как в разборе прерывания срочной задачей.

Как проверить объединение на своих данных

  1. Выделите группу действительно взаимозаменяемых запросов и исполнителей. Запишите исключения до сравнения, а не убирайте неудобные случаи после него.
  2. Соберите время поступления, начала и окончания работы, первоначальную очередь и фактического исполнителя. Отдельно отметьте недоступность, обязательный навык и ожидание данных клиента.
  3. Проиграйте те же поступления при двух правилах, не меняя длительности произвольно ради хорошего результата. Если длительность зависит от исполнителя, используйте соответствующие подтверждённые оценки.
  4. Сравните не только общий итог, но и клиентов, которым стало хуже, нарушение обещаний и интервалы «есть допустимый свободный исполнитель, но работа ждёт».
  5. Перед пилотом согласуйте порядок назначения, перехода между очередями и сохранения ответственности. После пилота проверьте фактическое выполнение, включая качество и повторную работу.

У обращения должен сохраняться один идентификатор и исходный момент ожидания. Перенос между списками не создаёт нового клиента и не обнуляет возраст запроса. Подробности передачи владельца относятся к правилам распределения и подтверждённой передачи; здесь достаточно не потерять их при смене устройства очереди.

Приёмочные проверки и вывод

  • В обоих вариантах сохранены четыре поступления, два сотрудника и 14 минут полезной работы.
  • Раздельные очереди дают ожидание 7, общая — 3 минуты суммарно.
  • D отдельно показывает ухудшение с нуля до двух минут ожидания.
  • 70% занятости сравниваются на одном горизонте, а не на двух разных.
  • Ограничение навыка нельзя заменить разрешением обслуживать любого.
  • Начатые работы не прерываются, исходная история обращений сохраняется.

Для обсуждения процесса в SABSUS подходят CRM и задачи. Общую очередь, допустимость исполнителей, порядок назначения и выгрузку событий нужно подтвердить в конкретной конфигурации. Встроенная симуляция или автоматическое объединение очередей здесь не предполагаются.

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

Источники проверены 12 октября 2026 года. Все числа учебные; статистические гарантии и решение о сокращении штата из них не следуют.