Настройка политики деловых поездок для крупных компаний — непростая задача. От нее зависят затраты организации на командировки и комфорт сотрудников во время путешествий. ВипСервис, один из крупнейших российских поставщиков тревел-услуг, обновил систему управления тревел-политикой в своем онлайн-инструменте бронирования Портбилет TMC.
В статье расскажем, как наша команда помогла ВипСервис перейти от жестко заданных наборов правил к гибкому «конструктору» ограничений. Рассмотрим новые возможности, которые появились у клиента для индивидуальной настройки политики командировок. Также поделимся сложностями, с которыми столкнулись при разработке, и как их преодолели.
О клиенте и продукте
ВипСервис – один из крупнейших российских поставщиков тревел-услуг, обслуживающий в год более 13 миллионов пассажиров. Для корпоративных клиентов холдинг предлагает в числе прочего инструмент онлайн-бронирования Портбилет TMC, развитием и поддержкой которого с 2020 г. занимается команда Work Solutions. Помогает самостоятельно, либо при поддержке агентов, купить авиа- и железнодорожные билеты, забронировать гостиницу, оформить трансфер и другие услуги для путешествий.
Задача
В инструменте онлайн-бронирования Портбилет TMC была возможность настраивать политику путешествий в отношении авиа, железнодорожных и отельных услуг для каждого клиента. Тревел-политика – это набор правил, который регламентирует оформление разных типов тревел-услуг и может вводить ограничения. Например, лимиты стоимости билетов по направлениям и отелей в разных городах, разрешенные классы обслуживания, запрещенные дни вылета, допустимые типы вагонов др.
По одному и тому же типу услуг возможно было создавать несколько фиксированных наборов правил. Присваивать их отдельным пользователям или их группам, либо распространять их на всю компанию по умолчанию.
Система отслеживала соблюдение тревел-политики и показывала информацию о наличии или отсутствии нарушений по каждому найденному варианту в результатах поиска. Оформить услугу, которая не соответствует правилам, можно было только после утверждения уполномоченным лицом на стороне клиента. Это происходило тоже через систему онлайн-бронирования, либо услугу нельзя было оформить вообще – в зависимости от настроек конкретного клиента.
Прошлая версия содержала большой набор правил с жестко фиксированной структурой. Некоторым организациям не хватало гибкости и возможности комбинировать разные условия самостоятельно. Тогда требовался дополнительный ручной контроль, и возникал риск ошибок из-за человеческого фактора.
Еще тревел-политика должна отображать как ограничения, так и рекомендации. Например, у компании заключен договор с гостиничной сетью, который предусматривает размещение на льготных условиях. Тогда персоналу проще сразу видеть такие варианты в результатах поиска как рекомендуемые. Это может касаться как гостиниц, так и авиаперелетов и других типов услуг.
У многих компаний правила и ограничения на выбор услуг для путешествий зависят от факторов, которые могут меняться за время работы человека в компании. Это может быть должность, подразделение и т.д. В начальной реализации возможно было назначать набор ограничений группе конкретных пользователей, а не динамически по какому-то признаку.
Приведем пример: если сотрудник переходил в другое подразделение, то нужно было вручную переместить его из одной группы в другую, чтобы ограничения тревел-политики в отношении этого работника изменились. Для компаний с большим штатом этот подход был неудобным.
Решение
Для решения задачи мы полностью переработали существовавшую тогда концепцию тревел-политики.
Было:
- Фиксированный набор правил со строго определенной структурой;
- Наборы закреплены за отдельными сотрудниками и группами конкретных лиц, также есть вариант для использования по умолчанию;
- Правила содержат одно или несколько условий, невыполнение которых означает нарушение и запрет на оформление услуги без согласования;
- Набор ограничений можно настроить для трех типов услуг: авиа, ж/д и отели.
Пример схемы работы:
Стало:
- Правила собираются по принципу конструктора: можно задать произвольное сочетание условий, набор которых также расширили;
- Правила (а не их наборы) могут присваиваться отдельным сотрудникам, прежним группам, объединяющим конкретных людей, а также динамическим группам;
- Невыполнение условий не означает их нарушение;
- Возможность настраивать тревел-политику для трансфера и аэроэкспресса в дополнение к авиа, ж/д и отельным услугам.
Покажем на примерах, что изменилось:
Теперь динамические группы автоматически формируются из сотрудников по заданному признаку, например: все имеющие грейд 1, все из подразделения «Администрация» и т.п. Когда у пользователя меняется этот признак, он автоматически покидает текущую группу и прикрепляется к другой, которая соответствует новому значению этого признака (если такая есть). Привязку правила можно задавать, комбинируя условия. Например, «Для всех сотрудников из подразделения «Маркетинг», кроме И.И. Иванова». Если привязка не задана, правило по умолчанию распространяется на всех сотрудников компании.
Выше мы говорили о том, что невыполнение условий правила не означает их нарушение. В новой тревел-политике требовалось запрещать пользователям какие-то услуги, а также поощрять оформление каких-то других вариантов с заданными параметрами. В старой версии можно было только запрещать. Поэтому все, что не соответствовало условиям, считалось нарушением.
Теперь система работает по обратному принципу: если все условия выполнены, то она должна совершить действия, которые настраиваются в самом правиле. Например, можно помечать услуги, которые соответствуют этим условиям, знаком нарушения и не разрешать оформлять их без согласования. Либо, наоборот, помечать как рекомендуемые варианты или совсем не показывать в результатах поиска. В случае, когда хотя бы одно условие не выполнено, такое правило игнорируется.
Пример схемы работы:
С какими сложностями столкнулись
В формировании новой концепции тревел-политики, столкнулись со сложностями. Одна из них возникла из-за отказа от назначения сотрудникам фиксированного набора правил.
В прежней версии можно было узнать, какая тревел-политика закреплена за пользователем, перейти к ней и просмотреть назначенные ему правила. Но для динамических групп такой подход был уже невозможен, поскольку сотрудник может принадлежать к нескольким разным группам одновременно по разным признакам (грейд, должность, подразделение, город и т.п.). Поэтому отказались от единого источника ограничений. Но возникла другая сложность – а если правила из разных источников будут противоречить друг другу?
Например, по одному из правил, для сотрудников в должности A перелет бизнес-классом – всегда нарушение. По другому же – для работающих в филиале в городе B перелеты бизнес-классом разрешены, если время в пути составляет более 5 часов. И есть сотрудник, работающий в филиале в городе B на должности A, то есть он принадлежит сразу к обеим динамическим группам: по должности и по подразделению. На него распространяются оба эти правила. И как поступать в таком случае?
Решили, что для ситуаций, когда на сотрудника распространяются сразу несколько правил, приоритеты нужно отдавать не самим правилам, а действиям, которые должна выполнять система при соблюдении их условий. Так, если несколько разных правил для одного и того же сотрудника в одной и той же ситуации предусматривают противоположные действия, приоритет отдается более «строгому».
Предложили решение заказчику, он поддержал и утвердил. По умолчанию теперь выбирается более консервативный вариант, который экономит средства клиента. При этом, клиент может обратиться за корректировкой более строгого правила, если нужно исключить из него какого-то сотрудника.
В новой тревел-политике также нужно было обеспечить агентам возможность просматривать все правила, действующие на конкретного пользователя или группу. Для этого внедрили фильтрацию правил по разным критериям, в том числе по конкретному сотруднику.
Еще одной сложностью было то, что у клиентов агентства уже была настроена тревел-политика по старым правилам со сложной структурой. Необходимо было конвертировать их в новые так, чтобы переход прошел для клиентов бесшовно. Новые настройки должны были выдавать тот же результат, что и прежние. Это был большой объем работ. Спроектировали алгоритмы конвертации старых правил в новые, протестировали и аккуратно перенесли все на новые рельсы.
Теперь, чтобы добавить новое правило политики, достаточно выбрать работников, на которых оно будет распространяться, добавить условия применения правила в любой необходимой комбинации, а также отметить, какие действия система должна выполнить при соблюдении этих условий:
Например, нужно добавить отдельное правило для сотрудника Петрова: при перелете в, из или через Новосибирск цена перелета более 13 т.р. будет считаться нарушением. Такой перелет потребует авторизации (согласования) уполномоченного лица со стороны клиента, а также указания причины нарушения.
Заполняем форму:
Пример готового правила:
Что это дало заказчику
Внедрение новой концепции «конструктора» позволило автоматизировать работу с наборами ограничений клиентов, которые имеют сложные нестандартные условия. Помогло свести к минимуму риск ошибок, возникающий из-за необходимости ручного контроля. «Конструктор» особенно полезен для заказчиков, сотрудники которых оформляют себе услуги путешествий сами, без помощи агента. Это облегчает кастомизацию тревел-политики в перспективе. Так случается из-за того, что любой добавленный критерий можно использовать во всех возможных сочетаниях с уже имеющимися, создавая правила разной сложности.
Заключение
Изначально тревел-политика ВипСервиса представляла собой фиксированные наборы правил, закрепленные за отдельными пользователями или группами. Однако по мере роста клиентской базы появилась необходимость в более гибкой системе, позволяющей комбинировать различные условия и создавать сложные наборы ограничений с учетом особенностей каждой компании.
Мы внедрили концепцию «конструктора» правил, где администраторы могут свободно задавать условия применения политики и связанные с ними действия системы. Правила могут назначаться как отдельным работникам или группам конкретных работников, так и динамическим группам, формируемым по заданным критериям. Это позволило автоматизировать процесс применения политик при изменении статуса сотрудников. Теперь возможно не только ограничивать доступ к услугам, но и рекомендовать подходящие варианты. Были проработаны механизмы разрешения конфликтов между правилами и обеспечения бесшовного перехода от старой системы.
Решение позволило значительно упростить и автоматизировать управление тревел-политикой для корпоративных клиентов, снизить риск ошибок и адаптировать систему под конкретные запросы каждой компании.
