Автоматизация командировок: заявка, лимит и подтверждённый маршрут

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

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

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

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

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

Процесс должен дать однозначный ответ на четыре вопроса:

1. Кто и зачем едет.
2. Какие даты и маршрут рассматриваются.
3. Какова предварительная оценка и какие лимиты применяются.
4. Кто принял решение именно по текущей версии.

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

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

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

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

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

Перед запуском владелец процесса также задаёт правила:

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

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

Такой образец показывает структуру данных, но не является клиентским файлом, результатом внедрения или проверкой конкретной системы.

Как собрать заявку на командировку

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

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

Обоснование должно связывать поездку с работой. Формулировки «по производственной необходимости» недостаточно: согласующему всё равно придётся выяснять цель. Полезнее написать: «Первая встреча — согласование требований по задаче A-17, вторая — приёмка этапа по задаче A-21».

В карточке нужно явно разделить три сущности.

Предварительная оценка показывает предполагаемые расходы на момент расчёта. Она может измениться и не означает, что деньги списаны.

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

Бронь появляется после выбора фактического варианта. Её статус и условия берут у используемого поставщика или из системы бронирования, а не выводят из суммы в заявке.

Например, запись «оценка — 20 000 ₽» нельзя автоматически превращать в «билет оплачен». До покупки корректный статус звучит так: «V1 ожидает решения» или «V1 согласована к бронированию».

Как провести согласование до покупки

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

Базовая последовательность выглядит так:

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

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

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

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

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

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

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

До нового решения действуют два ограничения:

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

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

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

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

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

Ниже — синтетический пример. Все имена, города, даты, суммы и рабочие задачи условны; это не кейс клиента Switch On AI и не результат теста внешнего сервиса.

Анна Соколова планирует две встречи в Казани: первую по условной задаче A-17, вторую по A-21. Исходный маршрут Москва — Казань — Москва назначен на условные даты 12–13 ноября. Административный отдел получил предварительную оценку 20 000 ₽. Условный руководитель Алексей Орлов согласовал версию V1, но бронь ещё не создавалась.

Затем организатор второй встречи перенёс её на день. Маршрут остался тем же, но даты стали 13–14 ноября, а новая предварительная оценка составила 23 000 ₽. Разница равна:

23 000 ₽ − 20 000 ₽ = 3 000 ₽.

Административный отдел не исправляет V1 задним числом. Он создаёт V2, указывает причину переноса и возвращает заявку на согласование. До ответа V2 имеет статус «ожидает повторного согласования», а V1 больше не считается актуальной для покупки.

Промежуточное решение состоит не в автоматическом одобрении дополнительных 3 000 ₽, а в остановке покупки. Согласующий рассматривает новую дату и оценку как единый набор условий. После явного решения административный отдел создаёт одну бронь для V2 и помечает V1 как историческую.

В примере намеренно нет перевозчика, названия тарифа, номера билета и условий возврата. Эти сведения появляются только из фактически выбранного варианта. Формулировка «одна актуальная бронь на V2» означает, что в рабочем процессе не осталось двух конкурирующих броней; она не доказывает оплату.

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

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

Отдельно проверьте четыре критерия приёмки:

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

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

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

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

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

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

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

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

Разбор удобно начать с одной операции: заявка на поездку → решение по конкретной версии → передача согласованного маршрута в корпоративный календарь. На странице услуг Switch On AI описаны возможные форматы решения. Следующий шаг — обсудить связку заявки, согласования и корпоративного календаря, выбрать один проверяемый сценарий и согласовать границы прототипа. Прототип помогает сверить требования, но не равен полноценному внедрению и не обещает заранее установленный эффект или срок.