Автоматизация отпусков: заявка, календарь и согласование изменений

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

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

Какую задачу решает этот процесс

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

Процесс должен помочь участникам:

1. принять заявление с нужными исходными данными;
2. найти пересечение с подтверждёнными отсутствиями и другими рассматриваемыми заявками;
3. проверить наличие заместителя по правилу подразделения;
4. провести заявку по действующему маршруту согласования;
5. записать в общий календарь только подтверждённое отсутствие;
6. при переносе заменить прежнюю версию, а не создать рядом ещё одно активное событие.

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

Какие данные и правила подготовить

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

«Условное» не означает необязательное во всех случаях. Например, заместитель может требоваться только для отдельных должностей, а производственный календарь — только для определённого расчёта. Это условие должен задавать утверждённый регламент, а не разработчик по догадке.

Короткий заполненный образец без клиентских данных:

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

Как связать заявление и календарь

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

Основной маршрут можно описать так:

черновик → на согласовании → согласовано → подтверждённое отсутствие

Отклонение и отзыв лучше оформить отдельными переходами:

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

Статус «согласовано» и статус «подтверждённое отсутствие» разделены намеренно. Между ними могут находиться обязательные кадровые проверки, состав которых определяет заказчик. Пока эти проверки не описаны, автоматизация не должна считать их выполненными.

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

Как согласовать пересечения и замену

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

Карточка конфликта должна отвечать на четыре вопроса:

• какие заявки пересекаются;
• какие календарные даты совпали;
• требуется ли заместитель по правилу подразделения;
• кто принимает решение, если основной согласующий недоступен.

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

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

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

Как обработать перенос и отмену

Перенос меняет не старую запись задним числом, а версию заявки. Такой подход позволяет восстановить последовательность решений и понять, почему календарь изменился.

Для переноса процесс должен выполнить одну логически целостную операцию:

1. создать новую версию заявки с новыми датами;
2. отозвать прежнее согласование по правилу заказчика;
3. сохранить автора и причину изменения;
4. заменить календарное событие по стабильному ID заявки;
5. уведомить сотрудника, заместителя и согласующих.

Главный инвариант: для одной заявки существует не более одного активного календарного события. Если обновление прервалось, нельзя одновременно показывать старую и новую версии как действующие. Конкретный способ обеспечить целостность зависит от API, версии, тарифа и прав подключаемых систем; его проверяют до разработки.

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

Учебный пример: путь от входных данных до результата

Ниже — синтетический пример, а не клиентский кейс и не результат внедрения Switch On AI. Все имена, номера и даты условные. Учебные даты показывают только конфликт покрытия и не используются для расчёта законного отпуска, рабочего времени или кадрового баланса.

Анна П. и Борис К. занимают условную должность «дежурный специалист». Анна подала заявку A-101 на период 10.11.2026–14.11.2026. Борис подал A-102 v1 на период 12.11.2026–16.11.2026.

Для включительных календарных интервалов начало пересечения равно более поздней начальной дате:

max(10.11, 12.11) = 12.11.

Конец пересечения равен более ранней конечной дате:

min(14.11, 16.11) = 14.11.

В учебном примере совпадают три календарные даты: 12, 13 и 14 ноября. Это сигнал конфликта покрытия, но не расчёт продолжительности отпуска по кадровым правилам.

Руководитель оставляет A-101 v1 без изменения. Для A-102 он предлагает новый период 17.11.2026–21.11.2026. Старая версия A-102 v1 отзывается, а A-102 v2 проходит согласование заново по действующему маршруту.

После переноса более позднее начало — 17.11, а более ранний конец — 14.11. Начало оказалось позже конца, поэтому пересечения нет.

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

Как проверить результат перед запуском

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

Дополнительно проверьте отзыв и повторную доставку одного события. Повтор обработки не должен создавать вторую запись. После переноса поиск по стабильному ID заявки должен возвращать только актуальную активную версию.

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

Что согласовать для внедрения

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

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

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

Switch On AI может разработать ИИ-помощника, бота или интеграцию для операции «согласование дат с учётом отсутствий и замещения» после проверки данных и API. Бот уместен как диалоговый вход и канал статусов. Обычная интеграция подходит для предопределённой передачи данных и обновления календаря. ИИ-помощник нужен только там, где есть задача работать с неструктурированным запросом или материалами; кадровые решения и правила он не устанавливает.

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

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

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