Назначение и цели ПЭК авиакомпании «Аэрофлот» Название системы
Полное название системы: платформа электронной коммерции.
Краткое название системы: ПЭК.
Назначение системы
ПЭК должна стать универсальной платформой дистрибуции товаров и услуг, реализуемых авиакомпанией и ее партнерами для розничных, корпоративных, групповых клиентов, а также прямой агентской сети.
Цель выполнения работ
Целью внедрения ПЭК в ОАО «Аэрофлот» является:
привлечение дополнительных клиентов в канал онлайн продаж и получение дополнительного дохода;
получение дополнительного дохода от продажи дополнительных услуг.
Ключевые пользователи ПЭК
Ключевыми участниками взаимодействия с ПЭК будут являться:
розничные физические лица;
розничные юридические лица;
групповые клиенты;
корпоративные клиенты;
участники ПЛ «Аэрофлот Бонус»;
участники программы agency loyalty;
событийные клиенты;
блок-чартерные клиенты (агенты);
онлайн агенты;
офисы и колл-центр авиакомпании.
Требования к базовым принципам построения бизнес архитектуры ПЭК Общие требования к построению бизнес-модели ПЭК
Наиболее целесообразным представляется сервис-ориентированный подход к построению бизнес-модели ПЭК. В рамках этого подхода система рассматривается как набор независимых сервисов, выполняющих определённые фиксированные функции и снабжённые стандартизированными интерфейсами (средствами взаимодействия). При этом сервисы могут представлять собой бизнес-процесс более низкого уровня (бизнес-сервис).
Для взаимодействий (вызовов сервисов) должна использоваться сервисная шина предприятия (ESB), которая будет обеспечивать передачу параметров (запросов) сервисам, управлять очерёдностью запросов и выполнять другие технологические функции.
Бизнес-процессы должны представлять собой последовательности вызовов сервисов и обработки результатов их работы. Такой подход позволит реализовать блоки и фрагменты существующих бизнес-процессов в виде сервисов и использовать в рамках ПЭК.
Детальные требования к реализации сервис-ориентированного подхода должны быть выработаны на стадии технического проектирования. Необходимость использования сервисной шины предприятия (ESB) должна быть определена на стадии согласования технического решения с Заказчиком.
Требования к построению бизнес-архитектуры ПЭК Требования к реализации бизнес-процессов
Целевая бизнес-архитектура системы (и соответственно ИТ-архитектура) должна быть построена на основании бизнес-процессов дистрибуции услуг. Унифицированный процесс дистрибуции можно представить в виде последовательности локальных бизнес-процессов (рис. ).
Рисунок – Схема унифицированного бизнес-процесса дистрибуции услуг
Каждый из представленных локальных бизнес-процессов фактически является группой, включающей несколько вариантов реализации в зависимости от подходов к способам пакетирования услуг, модели продаж, порядка расчётов и способа оплаты, типа клиентской функции (покупка, замена, возврат) и т.п. Для однозначности терминологии далее под бизнес-процессом будет подразумеваться вариант реализации, а процессы, обозначенные на схеме, будут называться функциональной группой бизнес-процессов.
При создании ПЭК должны быть реализованы следующие базовые бизнес-процессы (табл. ). Подробное описание бизнес-процессов приведено в приложении А.
Таблица – Состав базовых бизнес-процессов
|
Функциональные группы бизнес-процессов
|
Инициация
|
Shopping
|
Booking
|
Ticketing
|
Оплата
|
Расчёты
|
Общие
|
Управление
|
Бизнес – процессы
|
Авторизация клиента
|
Выбор рейсов и тарифов
|
Бронирование авиапакета
|
Предоставление дополнительной информации об услуге
|
Оплата/возврат online банковской картой
|
Формирование отчетов о продажах авиабилетов
|
Обработка неуспешных завершений
|
Формирование Шаблона бизнес администратором
|
Регистрация клиента
|
Поиск и выбор бронирования авиапакета
|
Аннуляция бронирования авиапакета
|
Предоставление ваучеров
|
Оплата/возврат через агента
|
Формирование отчетов о продажах авиационных услуг
|
Оповещения
|
Формирование Шаблона Клиентом
|
Регистрация участника программы Аэрофлот бонус
|
Аннуляция авиабилетов и дополнительных услуг
|
Аннуляция бронирования авиапакета по TimeLimit
|
Выпуск и Предоставление электронных билетов
|
Оплата банковской картой через call-центр
|
Формирование отчётов о возвратах авиабилетов
|
Откат бронирований (в пакете)
|
Модификация Шаблонов (пакетных предложений)
|
Авторизация продавца (агента)
|
Обмен авиабилетов
|
Замена авиабилета
|
Предоставление ссылок на сайты поставщиков
|
Оплата/возврат наличными или банковской картой в офисе продаж
|
Формирование отчётов о возвратах авиационных услуг
|
Откат оплат (в пакете)
|
Деактивация Шаблонов (пакетных предложений)
|
Авторизация бизнес – администратора
|
Выбор услуги и занесение в корзину
|
Замена класса обслуживания
|
Формирование квитанций и справок
|
Зачёт/возврат оплаты с депозита корпоративного клиента
|
Расчёты с поставщиками услуг, забронированных с условием оплаты у поставщика
|
Перерасчёт валют
|
Ведение таблицы Дополнительных предложений бизнес – администратором
|
Регистрация продавца (агента)
|
Формирование, модификация и возврат авиапакета в рамках корзины
|
Добавление услуг в авиапакет
|
|
Оплата/возврат бонусными милями
|
Формирование отчётов о продажах неавиационных услуг с оплатой в ОАО «Аэрофлот»
|
Проверка допустимости операции
|
Ведение таблицы Установки свойств услуг бизнес – администратором
|
Регистрация корпоративного клиента
|
Возврат услуги из корзины
|
Бронирование услуги в корзине
|
|
Контроль данных транзакции
|
Формирование отчётов о возвратах не авиационных услуг
|
Синхронизация изменений в пакете
|
|
|
Замена услуги в корзине
|
Бронирование авиапакета в корзине
|
|
Оплата/возврат через агента с контролем агентского депозита
|
Расчеты с агентом за проданные авиабилеты и дополнительные услуги
|
Контроль TimeLimit
|
|
|
Модификация услуги в корзине
|
Бронирование корзины единой транзакцией
|
|
|
Расчёты с агентами за проданные и забронированные через терминал ПЭК авиабилеты и дополнительные услуги
|
Занесение данных о бронированиях в EMD
|
|
|
Выбор Шаблона для формирования Пакета
|
Аннуляция бронирования услуги в корзине
|
|
|
Расчёты с агентами за забронированные через терминал ПЭК не авиационные услуги, с условием оплаты у поставщика
|
|
|
|
Выбор видов услуг по Шаблону
|
Обработка корзины
|
|
|
Расчеты с агентом по возвратам авиабилетов и дополнительных услуг, оплаченных в ОАО «Аэрофлот»
|
|
|
|
Выбор услуги, определённого Шаблоном Вида, и занесение в Пакет
|
Аннуляция бронирования корзины по TimeLimit
|
|
|
Расчеты с агентом по возвратам авиабилетов и дополнительных услуг, оплаченных агенту
|
|
|
|
Формирование, модификация и возврат авиапакета с учётом установок Шаблона
|
Бронирование пакета услуг одной транзакцией
|
|
|
Расчёты с поставщиками по удержанным санкциям за возврат услуг
|
|
|
|
Возврат услуги из пакета, сформированного по Шаблону
|
Аннуляция бронирования услуги в пакете
|
|
|
|
|
|
|
Замена услуги в пакете, сформированном по Шаблону (обязательной и не обязательной)
|
Обработка пакета услуг (после замены, добавления, удаления и модификации услуг в пакете)
|
|
|
|
|
|
|
Модификация услуги в пакете, сформированном по Шаблону
|
Аннуляция бронирования пакета по TimeLimit
|
|
|
|
|
|
|
Формирование и предложение списка видов услуг
|
Расчёт сумм «к оплате» по пакету
|
|
|
|
|
|
|
Предложение услуг к выбору, выбор и занесение в пакет
|
Аннуляция дополнительных авиационных услуг
|
|
|
|
|
|
|
Поиск поставщиков выбранной услуги
|
|
|
|
|
|
|
|
Расчёт стоимости пакета
|
|
|
|
|
|
|
|
Возврат пакета услуг
|
|
|
|
|
|
|
|
Поиск альтернативных предложений
|
|
|
|
|
|
|
Общие бизнес-процессы (сервисы), функциональность которых не должна быть связана со способами пакетирования, каналами и моделями продаж, приведены в табл. .
Таблица – Общие бизнес-процессы (сервисы), функциональность которых не связана со способами пакетирования, каналами и моделями продаж
№
|
Группа
|
Бизнес-процесс (сервис)
|
Описание
|
|
Инициация
|
Авторизация клиента
|
Авторизация клиента через логин в системе бронирования ПЭК, либо через номер карты участника программы Аэрофлот бонус
|
|
Инициация
|
Регистрация клиента
|
Регистрация в ПЭК. Вызов сервиса Оповещений
|
|
|
Регистрация участника программы Аэрофлот бонус
|
В том числе выполняется регистрация в системе бронирования ПЭК (автоматически). Вызов сервиса Оповещений
|
|
Инициация
|
Авторизация продавца (агента)
|
|
|
Shopping
|
Поиск поставщиков выбранной услуги
|
Выполняется поиск других предложений по выбранной услуге (например: с минимальной ценой или с другими условиями оплаты)
|
|
Общие
|
Перерасчёт валют
|
Выполняет перерасчёт стоимости услуги в другую валюту с учётом свойств услуги, установленных Поставщиком. Перерасчёт может выполняться по курсу Поставщика (выполняется запрос в его ИС) либо по курсу ПЭК (запрос к компоненту ПЭК) – определяется так же соответствующим свойством Услуги
|
|
Shopping
|
Расчёт стоимости пакета
|
При добавлении/удалении любой услуги в любой пакет, а так же при изменении параметров услуги (например: количества гостиничных номеров) и перерасчёте стоимости услуги в другую валюту, выполняет перерасчёт стоимости пакета (во всех валютах) с установкой стоимости пакета к бронированию. Здесь же выполняется контроль соблюдения условий акций и скидок. Пересчитывается стоимость как текущего пакета, так и пакета, в который он вложен
|
|
Shopping
|
Поиск альтернативных предложений
|
Выполняется формирование параметров запроса на поиск услуги по свойствам текущего объекта «Услуга». Алгоритм (бизнес-правила) преобразования набора свойств в параметры должны быть разработаны на этапе технического проектирования и инкорпорированы в функциональность соответствующего модуля. Возможность сортировки списка услуг к выбору клиентом по признаку «сходства». Критерии оценки схожести услуг – предмет дополнительного анализа и формализации на этапе технического проектирования
|
|
Booking
|
Расчёт сумм «к оплате» по пакету
|
До бронирования все суммы по пакету и услуге «к оплате» – нулевые. По факту бронирования выполняется установка суммы «к оплате» по услуге и выполняется изменение суммы «к оплате» по всем пакетам, в которые входит данная услуга. То же происходит при аннуляции бронирования или его изменении. По Пакету и Услуге в общем виде рассчитываются суммы: всего к оплате, оплачено, к доплате, к возврату, санкции. Приведённый блок сумм имеется по каждой валюте, присутствующей в пакете
|
|
Ticketing
|
Предоставление дополнительной информации об услуге
|
|
|
Ticketing
|
Предоставление ваучеров
|
|
|
Ticketing
|
Выпуск и Предоставление электронных билетов
|
|
|
Ticketing
|
Предоставление ссылок на сайты поставщиков
|
|
|
Ticketing
|
Формирование квитанций и справок
|
|
|
Общие
|
Обработка неуспешных завершений
|
При неуспешном завершении любого бизнес-процесса группы «Booking» или «Оплата» производится установка специальных статусов объектов Услуга или Пакет (значения статусов приведены в таблице ХХХ – Статусные модели бизнес-процессов)
|
|
Общие
|
Оповещения
|
При выполнении любого бизнес-процесса групп «Booking» или «Оплата» (и некоторых других – определятся внутренней функциональностью) формируются текстовые оповещения для клиента и поставщика услуги и вызывается сервис Оповещений, который осуществляет отправку оповещения по каналам, определенным в свойствах объектов Клиент и Поставщик
|
|
Общие
|
Проверка допустимости операции
|
Выполняется перед любым бизнес-процессом групп «Booking» или «Оплата». Производит анализ блокирующих свойств услуги и пакета, выдаёт сообщение Клиенту, запрашивает и выполняет отмену блокировки
|
|
Общие
|
Синхронизация изменений в пакете
|
Выполняется перед возвратом, заменой или иным изменением услуги в синхронизированном пакете. Оценивается, а при необходимости запрашивает у Поставщиков, возможность изменения даты, места и длительности предоставления всех услуг по синхронизированному пакету, рассчитывает стоимость операции, запрашивает подтверждение Клиента
|
|
Общие
|
Контроль TimeLimit
|
Выполняется контроль всех пакетов на предмет соблюдения условий TimeLimit с оповещением Клиента (с заданной периодичностью) о необходимости выполнить действия и о возможных последствиях превышения TimeLimit. Здесь необходимо отслеживать не только отдельные услуги, но и их совокупности в пакетах (с учётом вложенности). При превышении TimeLimit запускаются соответствующие бизнес-процессы по автоматической аннуляции услуг с отправкой оповещений
|
|
Общие
|
Занесение данных о бронированиях в EMD
|
Опциональный бизнес-процесс, может выполняться после любых бизнес-процессов групп «Booking» или «Оплата». Выполняет запись данных бронирований в EMD системы Sabre
| Требования к общей функциональной архитектуре ПЭК
Предполагаемая схема общей функциональной архитектуры ПЭК приведена на рисунке .
Рисунок – Схема функциональной архитектуры ПЭК
Требования к единому информационному пространству
Все бизнес-процессы должны работать с общим набором полей данных, изменяя или дополняя его в соответствии с собственной функциональностью.
Общий набор полей данных бизнес-процессов фактически должен являться набором информационных объектов (далее – Объект) – аналогов объектов ООП, каждый из которых должен принадлежать одному из классов: клиент, поставщик, вид услуги и т. п. Объект должен содержать всю необходимую для работы системы бронирования информацию о конкретном «представителе» класса (клиенте, поставщике, услуге, пакете услуг и т.п.). Каждое поле в объекте (свойство) должно иметь значение (например: свойство «Фамилия» объекта «Клиент» должно иметь значение «Иванов»).
Набор объектов, формируемый в рамках сеанса, должен представлять собой единое информационное пространство сеанса, а совокупность значений их свойств в каждый конкретный момент времени должно определяться как «состояние информационного пространства».
Набор объектов и их свойства должны быть доступны для всех локальных бизнес-процессов и сервисов, находящихся на стороне ПЭК (сервисам на стороне систем поставщиков и партнёров он в явном виде не доступен). Каждый бизнес-процесс или сервис должен использовать только текущие значения свойств и изменять их в рамках собственной функциональности, также он должен иметь возможность формировать новые объекты, которые становятся доступны всем другим сервисам.
Порядок, способы и методы формирования объектов и изменения значений свойств должны зависеть только от текущего состояния (значений) свойств объектов и собственной функциональности бизнес-процесса (сервиса) и не должны зависеть от того, как и кто их формировал или изменял раннее, и кто и как будет работать с ними в дальнейшем.
Таблица – Минимальный набор видов информационных объектов (классов)
Наименование, тип
|
Содержание
|
Примечания
|
Клиент (покупатель). Справочный объект
|
Информация о клиенте (включая его идентификационные данные в ИС и в SSL)
|
Объект для физического лица – покупателя услуг
|
Корпоративный клиент. Справочный объект
|
Вся информация о корпоративном клиенте
|
Данный объект используется, если клиент – физическое лицо является субъектом корпоративного клиента
|
Продавец (агент). Справочный объект
|
Информация о продавце или точке продаж
|
«Продавцами» являются так же офисы и online площадки авиакомпании
|
Поставщик. Справочный объект
|
Информация о поставщике услуг
|
Это конечный поставщик услуги или консолидатор
|
Вид услуг. Справочный объект
|
Информация о виде услуг
|
Общая информация об услуге «Трансфер», «отель», «экскурсия» и т.д.
|
Сеанс. Функциональный объект
|
Общая информация о сеансе работы клиента с системой
|
Содержит как минимум дату и время начала и завершения сеанса, идентификаторы клиента и самого сеанса.
|
Пакет. Функциональный объект
|
Общая информация о наборе услуг, связанных по какому-либо признаку
|
В рамках сеанса может быть несколько пакетов, пакеты могут быть вложенными
|
Услуга. Функциональный объект
|
Информация о забронированной (предполагаемой к бронированию) услуге
|
Каждая услуга может входить в один единственный пакет. В пакете может быть несколько услуг одного вида
|
Пример схемы «вложенности» объектов приведён на рисунке , при этом, поскольку информационные объекты являются аналогами объектов ООП, то каждый вложенный объект должен создаваться как потомок объекта верхнего уровня и, соответственно, наследовать все его свойства.
Рисунок – Пример схемы единого информационного пространства
Базовые положения:
информация о сеансах и объектах, сформированных (изменённых) в рамках сеанса, должна сохраняться на внешних носителях. Хранение может быть распределённым (базы данных систем Online Redemption, ЕПР, Sabre и т.д.). Может потребоваться добавление в БД дополнительных таблиц и связей;
предполагается, что вся информация, необходимая для восстановления состояния информационного пространства сеанса должна быть доступна: хранится в специальных таблицах имеющихся баз данных либо может быть предоставлена исполнительными системами (Sabre, ЕПР и т.п.);
любая услуга (в том числе авиаперелёт) должна продаваться только в составе пакета (пакет может содержать единственную услугу).
Порядок создания информационных объектов (отражён и на схеме, рис. ):
1)Объект Услуга создаётся как потомок объекта Поставщик.
2)Объект Поставщик создаётся как потомок объекта Вид услуги.
3)Объект Вид услуги создаётся как потомок объекта Пакет
4)Объект Пакет создаётся как потомок объекта Пакет или объекта Сеанс
5)Пакеты могут быть вложенными, признаком вложенности является свойство пакета: ссылка на пакет верхнего уровня. Пакет может быть вложен только в один пакет.
6)В составе пакета могут быть одновременно как другие пакеты, так и не пакетированные объекты Вид услуги.
7)Пакет может обрабатываться: как только целиком, так и по отдельным услугам и вложенным пакетам, это определяется значением специального свойства пакета.
Требования к обеспечению взаимозависимости услуг в пакете
При построении локальных бизнес-процессов групп «Shopping», «Booking» и «Оплата» необходимо учитывать ограничения на отдельные операции, накладываемые свойствами Услуги или Пакета услуг.
Перечень условий (свойств) информационных объектов, оказывающих существенное влияния на допустимость отдельных операций, приведён в таблице . Приведены только блокирующие свойства (делают операцию не допустимой), свойства, накладывающие ограничения на выбор способов, методов и порядка выполнения бизнес-функций (например: ограничения на выбор допустимых способов оплаты) не рассматриваются.
Таблица – Перечень условий (свойств) информационных объектов, оказывающих существенное влияния на допустимость отдельных операций
|
Объект
|
Свойства
|
значение
|
описание
|
1
|
Пакет или Услуга
|
Дата+время последней установки статуса «Забронировано»
TimeLimit до следующего статуса – «Оплачено»
|
Текущие Дата и время отличаются от установленного для последнего статуса на величину превышающую TimeLimit
|
Исчерпан TimeLimit ожидания операции, соответственно необходимо сформировать пакет (услугу) заново. Объект автоматически получает статус «удалить»
|
2
|
Услуга
|
Дата+время начала предоставления услуги
|
Меньше текущих даты+времени
|
Услуга уже оказывается, изменение/возврат невозможно
|
3
|
Пакет или Услуга
|
Родитель
|
Да
|
Данная услуга или пакет является основной для других услуг пакета (например: авиаперелёт для услуги «приоритетный check-in»). Удаление такой услуги без удаления всего пакета невозможно.
|
4
|
Услуга
|
Потомок пакета
|
Да
|
Данная услуга продана в составе предустановленного пакетного предложения, соответственно её удаление или изменение возможно только вместе с пакетом
|
5
|
Услуга
|
Не возвращаемая
|
Да
|
Данная услуга не может быть возвращена в соответствии с офертой поставщика
|
6
|
Услуга
|
Синхронизирована по дате+времени начала или конца
|
Да
|
Дата начала (завершения) предоставления услуги синхронизирована с датой+временем начала (завершения) предоставления другой услуги пакета, соответственно изменения дат возможно только по всем синхронизированным услугам одновременно
|
7
|
Услуга
|
Синхронизирована по месту начала или конца
|
Да
|
Место начала (завершения) предоставления услуги синхронизировано с местом начала (завершения) предоставления другой услуги пакета, соответственно изменения места возможно только по всем синхронизированным услугам одновременно
|
Свойства «Родитель» и «Потомок» должны устанавливаться автоматически или по указанию Клиента, при формировании Услуги в пакете в зависимости от значения этого свойства, определённого на уровне описания вида услуги. Конкретный алгоритм запроса и автоматической установки должен быть разработан на этапе технического проектирования.
Указанные в таблице свойства синхронизации (по дате + времени и месту) должны устанавливаться для всех услуг пакета автоматически (если определено свойство пакета «синхронизированные услуги») или клиентом при его формировании.
Если свойства синхронизации установлены Клиентом, то они могут быть отменены только по его прямому требованию, свойства, установленные автоматически, изменению не подлежат. Приведённый набор блокирующих свойств является открытым и может быть расширен на этапе технического проектирования.
Анализ данных свойств должен выполняться специальным модулем (сервисом) контроля допустимости операции, который должен исполняться перед локальными бизнес-процессами.
|
