ИИ в планировании смен: как на самом деле работают покрытие, отдых и справедливость

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

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

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

Главный шаг вперёд по сравнению с мышлением «все с 9 до 17» — определять потребность по временным интервалам, а не по дням. Цель покрытия звучит так: в эти часы, в этот день недели, в этой точке мне нужно столько-то людей в такой-то роли. День перестаёт быть единым блоком и превращается в профиль спроса, который растёт и падает.

Возьмём кофейню как разобранный пример. В понедельник могут быть нужны два бариста и один старший смены с 08:00 до 12:00, три бариста в обеденный пик с 12:00 до 15:00 и снова два с 15:00 до 18:00. Эти три интервала описывают реальную работу куда точнее, чем «пять человек в понедельник».

Затем решатель строит смены, пересекающие интервалы, и закрывает каждую требуемую позицию одним человеком на всё окно. Хороший движок показывает обе ошибки: недопокрытие, когда интервал не дотягивает до цели, и перепокрытие, когда вы платите за больше людей, чем нужно. Обе цифры должны быть видны до публикации, а не обнаруживаться в зале.

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

Технически жёсткие ограничения работают как фильтры, а не как баллы. Прежде чем движок ранжирует кандидатов на смену, любой, кто нарушил бы жёсткое правило, полностью исключается из списка. Это принципиально отличается от подхода со штрафами, где нарушение просто «дорого стоит»: дорогие правила ломаются в загруженные недели, фильтры — никогда.

Навыки показывают, зачем нужна такая строгость. Если позиция требует сертифицированного водителя погрузчика или сотрудника с правом закрывать точку, рассматриваться должны только люди с этой квалификацией. А когда подходящего кандидата нет, честное поведение — оставить смену открытой и указать причину: «нет доступного сотрудника с этим навыком при соблюдении правил отдыха», — а не тихо назначить кого-то без квалификации.

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

Классическая ошибка, которую это предотвращает, — закрытие с последующим открытием. Допустим, Дана закрывает точку во вторник в 23:00, а смена открытия в среду начинается в 07:00. Промежуток — восемь часов. Если настроенный минимум отдыха выше — скажем, одиннадцать или двенадцать часов, — движок попросту никогда не увидит Дану кандидатом на это открытие; ей, возможно, достанется дневная смена. Без одолжений, усталости и переговоров: назначение невозможно по правилу.

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

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

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

Счётчики — ещё и инструмент коммуникации. Когда сотрудник спрашивает «почему опять я?», менеджер, способный показать ротацию за последние шесть недель, получает ответ, которого график «на глазок» никогда не даст. График воспринимается справедливым, когда ротация видна, а не только когда она математически выверена.

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

Конкретный случай: два сотрудника полностью подходят для смены в четверг вечером. Назначение одной оставляет её в пределах договорных часов; назначение другого выталкивает его за недельный порог, в зону повышенной ставки. При прочих равных движок выбирает первую — и на десятках смен в неделю эти маленькие решения складываются в ощутимую разницу в фонде оплаты труда.

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

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

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

Здесь же живёт ответственность. Публикация графика — операционный и юридический акт компании, и за него отвечает человек. Хороший ИИ для смен сокращает путь от «пустой недели» до «черновика на проверку», но не убирает человеческую подпись в конце. К тому же команда больше доверяет графику, зная, что его утвердил менеджер.

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

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

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