Система заявок на отпуск: прозрачные политики и утверждения

Что ломается в большинстве процессов заявок на отпуск

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

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

Главная цель проектирования системы заявок на отпуск скучная, но важная: корректные балансы, понятные утверждения и один источник правды. Если баланс верный, но утверждения непонятны, менеджеры будут спрашивать «Я уже это одобрял?» Если утверждения идеальны, но календарь неверен, команды всё равно будут пересекаться.

Четыре группы полагаются на один и тот же процесс, но по разным причинам:

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

«Читаемый рабочий процесс» означает, что вы можете посмотреть шаги и объяснить их простым языком: что запускает заявку, кто утверждает, что происходит при отклонении и что записывается обратно (баланс, статус, календарь). Если вы не можете объяснить это быстро, люди будут обходить систему.

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

Базовые данные, которые нужны (без излишней сложности)

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

Начните с небольшого набора основных объектов, которые можно объяснить за минуту:

• Employee: кто запрашивает отпуск (и кто его утверждает).
• TimeOffRequest: сама заявка (даты, тип, статус).
• Policy: правила для типа отпуска (PTO, больничный, неоплачиваемый).
• Balance: текущая доступная величина для сотрудника и политики.
• Approval: решения и комментарии, связанные с заявкой.

Для заявок поля, которые предотвращают реальные проблемы, не модные — они конкретные. Сохраняйте дату и время начала и окончания, отметку о частичном дне и часовой пояс сотрудника на момент запроса. Добавьте короткую причину и разрешите вложения, если ваш HR-процесс требует подтверждений (например, справку от врача). Держите вложения опциональными, чтобы не блокировать обычный PTO.

Статусы должны быть небольшими и предсказуемыми: draft (сохранено, но не отправлено), submitted, approved, rejected и canceled. Избегайте лишних статусов, например «в ожидании HR», если это действительно не нужно.

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

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

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

Правила политики: делайте их ясными и тестируемыми

Хорошие политики намеренно скучны. Люди должны предсказывать результат до нажатия «Отправить». В проектировании системы заявок на отпуск самый быстрый способ потерять доверие — это когда одна и та же заявка в одну неделю утверждается, а в другую — отклоняется.

Начните с именования типов отпусков и напишите по одному простому предложению для каждого. Отпуск или PTO — это планируемое время отсутствия. Больничный — непланируемое время по состоянию здоровья. Неоплачиваемый отпуск — время без оплаты. Родительский отпуск часто имеет особые сроки и документы. Компенсируемый отдых (comp time) зарабатывается за переработки и тратится как PTO.

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

Правила подачи — это место, где обычно возникает путаница. Будьте конкретны по срокам уведомления, датам блокировок и минимальному допустимому отрезку времени. Например: «Заявки на отпуск должны быть поданы за 5 рабочих дней, за исключением экстренных случаев, одобренных HR» — это тестируемо. «Подавайте заранее» — нет.

Правила переноса и истечения срока должны помещаться в одно предложение. Пример: «До 40 часов переносятся на следующий год и истекают 31 марта.» Если нужно второе предложение — это сигнал, что политика слишком сложна.

Простой способ держать текст политики и логику правил в синхронизации:

• Дайте каждому правилу короткий ID (например, PTO-NOTICE-5D)
• Храните текст на понятном языке рядом с конфигурацией правила
• Добавляйте 2–3 примера случаев на правило (утверждено или отклонено) как тесты
• Меняйте текст политики только когда меняется конфигурация правила (и наоборот)

Пример: сотрудник на испытательном сроке запрашивает 2 часа PTO на завтра. Система должна заблокировать заявку по двум причинам, которые легко прочесть: «PTO начинается через 60 дней» и «для PTO требуется уведомление за 5 рабочих дней». В AppMaster держите эти сообщения рядом с узлами правил, чтобы обновления не расходились.

Начисления: шаблоны, которые вызывают путаницу

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

Одна распространённая путаница — смешивание стилей начисления. Некоторые компании добавляют часы каждый платёжный период, другие ежемесячно, кто-то начисляет по отработанным часам, а кто-то даёт полный годовой объём на фиксированную дату. Проблемы возникают, когда вы храните только «баланс» и забываете «как он был заработан». Храните чёткий журнал событий: grant (выдача), accrue (начисление), adjustment (корректировка) и usage (использование).

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

Лимиты и отрицательные балансы вызывают тикеты «кажется неверно». Если вы разрешаете перенос до лимита, применяйте лимит в конкретный момент (конец года, конец периода начисления или сразу после начисления). Если отрицательные балансы разрешены, определите предел и что происходит при увольнении.

Правила округления создают тихое рассогласование. Выберите один уровень округления (минуты, четверти часа или полдня) и применяйте его одинаково к начислениям и использованию. Если начисления в минутах, а заявки в полднях, сотрудники всегда будут считать систему некорректной.

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

Простой чек-лист, предотвращающий большинство споров:

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

В AppMaster это обычно соответствует таблице Transactions и небольшому бизнес-процессу, который пересчитывает балансы при утверждении или корректировке заявки.

Утверждения менеджера: простая маршрутизация с учётом крайних случаев

Процесс утверждения менеджера должен отвечать на один вопрос: кто может уверенно сказать «да»? Если пытаться моделировать каждый нюанс организационной структуры, дизайн системы заявок на отпуск становится нечитаемым и тяжелоисправимым.

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

Одноступенчатые и многоступенчатые утверждения

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

Распространённые читаемые шаблоны:

• Одноступенчатое: менеджер утверждает стандартный PTO и неоплачиваемый отпуск.
• Двухступенчатое: сначала менеджер, затем HR для типов отпуска, требующих документов или проверок политики.
• Второй утверждающий: добавьте руководителя отдела, когда отсутствие влияет на совместное покрытие (например, on-call ротации).
• Автоодобрение: низкорисковые заявки (1–2 часа на приём) или время, уже предварительно согласованное в расписании.
• Без менеджера: утверждение только HR для подрядчиков или ролей без явного руководителя.

Делегирование, отклонения и повторные подачи

Утверждения ломаются, когда утверждающий отсутствует. Сделайте делегирование первоклассным правилом, а не ручным обходом. Если менеджер помечен как вне офиса, направляйте к делегату; если делегата нет — к менеджеру его уровня выше (или к HR как запасной вариант). Всегда логируйте, какое правило выбрало утверждающего.

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

Практический пример: Алекс запрашивает 3 дня больничного. Система направляет заявку менеджеру, но поскольку это тип отпуска, требующий контроля политики, HR получает второй шаг только после одобрения менеджера. Если менеджер в отъезде — делегат утверждает, и в журнале видно причину.

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

Правила валидации перед пропуском заявки

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

Начните с правил бронирования. Проверки на перекрытия должны ловить конфликты с существующими утверждёнными отпусками и ожидающими заявками. Будьте явными по частичным дням: храните дату плюс простую метку, например AM, PM или часы, чтобы полдня случайно не превратились в целый день. Также решите, что делать с выходными и праздничными днями: блокировать их или учитывать, но не засчитывать в количество дней.

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

Чистый набор проверок, покрывающий большинство случаев:

• Даты корректны (начало раньше конца, тот же часовой пояс, выбор полудня не пропущен)
• Нет перекрытия с существующими отпусками (включая полдня)
• Подсчёт дней исключает выходные и праздники (согласно вашей политике)
• Требуемые вложения присутствуют для конкретных типов отпусков (например, больничная справка)
• Баланс достаточен (проверка при отправке и повторно при утверждении)

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

Делайте сообщения об ошибках справедливыми и исправимыми. Говорите, что не прошло, где и как это исправить. Например: «Ваша заявка перекрывается с утверждённым PTO 12 марта (PM). Выберите другое время или отредактируйте существующую заявку.»

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

Пошагово: читаемый рабочий процесс, который можно построить и поддерживать

Хороший дизайн системы заявок на отпуск приятен тем, что каждая заявка идёт по одному пути, и у каждого решения есть одна понятная причина. Самый простой способ сохранить читаемость — разделять данные политики (что именно правила) и логику рабочего процесса (что происходит при нажатии «Отправить»).

Вот последовательность, которая остаётся простой даже при добавлении новых типов отпусков:

• Поместите все типы отпусков и правила в одно место (названия, права, перенос, блокировки). Если правило не записано здесь, его не должно быть нигде больше.
• Моделируйте балансы как временную линию, а не одно число. Храните начальный баланс, заработанное (accrual), использованное и корректировки, чтобы объяснить любой баланс на любую дату.
• Соберите форму заявки с ранними проверками. Валидируйте даты, полдня, перекрытия, сроки уведомления и «достаточный баланс к дате начала» до начала этапов утверждения.
• Маршрутизируйте утверждения, используя небольшой набор ролей (сотрудник, прямой менеджер, HR). Добавляйте исключения как данные (например, «нужна проверка HR, если 10+ дней»), а не как жёсткие коды.
• Создавайте события в календаре только после утверждения и рассматривайте их как синхронизированную копию, которую можно обновлять или отменять при изменениях заявки.

Сохраняйте рабочий процесс читаемым, записывая каждое решение простым языком (например: «Отклонено: перекрывается с утверждённым отпуском»). Если вы используете визуальный инструмент вроде редактора бизнес-процессов AppMaster, называйте шаги так, как их прочёл бы человек.

Перед запуском тестируйте реальные сценарии: заявки с прошедшей датой, менеджер в отпуске, смена политики в середине года и правка после утверждения. Если результат удивляет HR — правило ещё не достаточно ясно.

Интеграция с календарём, которая остаётся точной со временем

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

Для содержимого события держите его минимальным и последовательным. Хороший дефолт: короткий заголовок вроде «Out of office — Alex Kim» плюс тип отпуска, если это важно («PTO», «Sick»). Минимизируйте детали в целях приватности. Многие команды предпочитают показывать событие как «Занят» и хранить причины, балансы и заметки только в заявке.

Рассматривайте события календаря как зеркало, а не источник

У каждой заявки должен быть стабильный внутренний ID, и каждое событие календаря должно хранить этот ID (в пользовательском поле или описании). Тогда можно смело создавать, обновлять и удалять нужное событие при изменениях заявки.

Статусы — то место, где системы расходятся. Решите заранее, показываются ли предварительные заявки. Если показываете, делайте отличие очевидным (например, префикс «Pending» в заголовке и другой статус доступности). При утверждении обновляйте то же событие, а не создавайте новое. Если заявка отменена или отклонена после того, как была видна — удаляйте событие, чтобы календарь не врал.

Часовые пояса и «странные» дни

Часовые пояса особенно проблемны для целодневных и частичных отпусков. Храните начало и конец как точные метки времени в локальном часовом поясе сотрудника и также сохраняйте этот часовой пояс в заявке.

Используйте события «весь день» только для настоящих полных дней. Для частичных дней создавайте события с явным временем (например, 13:00–17:00), чтобы коллеги в других зонах видели правильное пересечение.

• Полный день: событие «весь день» в часовом поясе сотрудника
• Частичный день: событие с началом и концом во временных метках
• Многодневный: события «весь день» подходят, но проверьте правило по включению/исключению даты окончания

Если синхронизация с календарём падает, не скрывайте это. Поставьте в очередь задачу, повторяйте с бэкоффом и показывайте явный статус «Календарь не обновлён» с ручной кнопкой «повторить синхронизацию». В AppMaster это обычно фоновая задача плюс админ-экран с неудавшимися попытками, чтобы HR мог исправить проблему без правки заявок.

Частые ошибки и как их избежать

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

Ошибка 1: логика начисления спрятана в исключениях

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

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

Ошибка 2: потоки утверждений разветвляются бесконечно

Бесконечные ветвления утверждений невозможно тестировать, и менеджеры не понимают, почему заявка ушла к кому-то ещё.

Более безопасный шаблон:

• Один дефолтный утверждающий (обычно прямой менеджер)
• Один опциональный второй утверждающий (HR или руководитель отдела) по простым условиям
• Один явный запасной, если утверждающий в отъезде (делегат или следующий руководитель)
• Одно финальное состояние заявки (approved, rejected, canceled)

Ошибка 3: смешивание текста политики и формул в одном поле

Текст политики для людей (что считается, кто имеет право). Математические правила для системы (ставка, лимиты, округление, перенос). Храните их отдельно, чтобы менять формулировки без трогания расчётов и тестировать формулы отдельно.

Ошибка 4: правки и отмены не записываются

Если вы перезаписываете заявки, вы теряете «почему» за изменением баланса.

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

Ошибка 5: часовые пояса и праздники — послеthought

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

Быстрая проверка перед запуском

Перед объявлением всем пройдитесь по короткому набору проверок с реальным сотрудником, менеджером и представителем HR. Вы хотите убедиться, что система кажется очевидной, а не просто рабочей.

Используйте этот чек-лист как ворота go/no-go для проекта:

• Видимость баланса: сотрудник видит текущий баланс и как предстоящий утверждённый отпуск его изменит (чтобы не обнаружить отрицательный баланс позже).
• Ясность политики: каждое правило написано простым языком (перенос, блокировки, минимальное уведомление, полдня) и логика точно соответствует словам.
• Полезные валидации: когда заявка блокируется, сообщение говорит, что изменить (даты, тип отпуска, часы, отсутствующее вложение), а не просто «ошибка» или «нельзя».
• Готовность менеджера к решению: менеджер может утвердить на одном экране с достаточным контекстом (остаток баланса, пересечения по команде, заметки по передаче обязанностей) и может запросить изменения без долгого переписки.
• Календарь и аудит: события создаются и синхронизируются при утверждении, изменении и отмене, и каждое изменение статуса логируется с указанием, кто и когда его сделал.

Быстрый практический тест: создайте заявку, утвердите её, отредактируйте даты, затем отмените. Если на любом этапе остаётся неправильный баланс, устаревшее событие в календаре или необъяснимый статус — исправьте это до запуска.

Если вы строите это в AppMaster, называйте каждый шаг по действию пользователя (Submit, Validate, Route to Manager, Update Balance, Create/Update Calendar, Log Event), чтобы поведение оставалось понятным по мере развития политик.

Пример сценария: от заявки до события в календаре

Новый сотрудник Майя начинает 10 марта. Ваша система поддерживает ежемесячное начисление, поэтому Майя получает PTO первого числа каждого месяца. 12 апреля она запрашивает частичный день: 3 часа в следующую пятницу на медицинский приём.

Что видит каждый:

• Сотрудник (Майя): текущий баланс, сколько часов съест эта заявка, и явное предупреждение, если баланс уйдёт в минус.
• Менеджер: краткое резюме (дата, часы, заметка по покрытию) с опцией утвердить, отклонить или делегировать.
• HR: политика, использованная в расчёте, журнал аудита и возможность пересчёта при изменении правил.

Майя отправляет заявку. Её менеджер в отпуске, поэтому система проверяет настройку делегирования и маршрутизирует к исполняющему обязанности менеджеру. Исполняющий обязанности утверждает.

При утверждении происходят две вещи: заявка фиксируется к версии политики, использованной в расчёте, и создаётся событие в календаре «Maya — PTO (3h)» на правильную дату и время. Майя сразу видит статус «Approved» и отметку в календаре «Added.»

В июне HR меняет политику (например, начисление увеличивается после 90 дней). Балансы нужно пересчитать, но прошлые утверждённые заявки не должны изменяться незаметно. Система пересчитывает текущий баланс Майи с эффективной даты вперёд, сохраняя запись до/после в аудите.

Через неделю Майя меняет дату заявки (приём перенесён). Так как отпуск уже был утверждён, изменение становится новой «Change request», который возвращается к делегированному утверждающему. После повторного утверждения существующее событие календаря обновляется (тот же ID), а не дублируется.

Это легко моделируется в AppMaster: один путь утверждения, одна проверка делегирования, один шаг создания/обновления календаря и отдельное действие пересчёта, которое HR может запускать при изменении политики.

Следующие шаги: выпустите первый релиз и итерационно улучшайте

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

Перед добавлением новых правил определите, где хранится источник правды. Если ваша HR-система — мастер, то ваше приложение в основном должно проверять, маршрутизировать утверждения и синхронизировать результаты обратно. Если ваше приложение — мастер, вам нужны более явные журналы аудита и план на случай изменений HR-данных (новый менеджер, смена отдела, дата увольнения).

Практический план первого релиза:

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

Запишите 5–10 реальных тест-кейсов и прогоняйте их после каждого изменения. Берите кейсы из вашей команды, а не абстрактные примеры. Например: кто-то запрашивает пятницу в четверг, кто-то меняет заявку после утверждения, или менеджер утверждает, пока сотрудник в другом часовом поясе.

Если вы строите с помощью no-code, видимость важнее функций. В AppMaster вы можете держать модель данных (типы отпусков, балансы, утверждения) и рабочий процесс в визуальных редакторах, чтобы HR и операторы видели, что система реально делает. Вы также можете экспортировать чистый исходный код по мере эволюции политик, не накапливая временные исправления.

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