CC BY
13
УДК 65.011.56
УЧЕТ ПАССАЖИРОВ НА АВИАТРАНСПОРТЕ
А. А. Стародубцев*, Д. В. Тихоненко
Сибирский государственный университет науки и технологий имени академика М. Ф. Решетнева Российская Федерация, 660037, г. Красноярск, просп. им. газ. «Красноярский рабочий», 31
E-mail: sparker4@mail.ru
Описана проблема учета пассажиров, с которой могут встретиться различные авиакомпании вне зависимости от размеров, а так же способы устранения данной проблемы.
Ключевые слова: авиакомпания, учет пассажиров, подсистема учета.
RECRUITMENT OF PASSENGERS ON AIR TRANSPORTATION A. A. Starodubcev*, D. V. Tihonenko
Reshetnev Siberian State University of Science and Technology 31, Krasnoyarsky Rabochy Av., Krasnoyarsk, 660037, Russian Federation
E-mail: sparker4@mail.ru
The article describes the problem of passengers accounting, with which different airlines can meet regardless of the size, as well as ways to eliminate this problem.
Keywords: airline, passenger registration, accounting subsystem.
В России огромное число авиакомпаний разных размеров. Каждый день они собирают большое количество данных о пассажирах. Перевозчики хранят информацию о бронировке и покупке билетов, данные кредитной карты, записи о предпочтениях посадочных мест и питания на борту самолета. Кроме того, составляется список пассажиров летевших определенным рейсом. Такой список, обычно, формируется автоматически за счет сбора данных авиакомпанией со своих собственных источников [1].
Данный подход является самым экономически выгодным для авиакомпаний, но он не идеальный. Основная проблема состоит в том, что в автоматически формируемый список может загрузиться информация о человеке, летавшем на таком же рейсе, но несколькими годами ранее. Это происходит из-за совпадения номеров билетов и рейсов. Помимо этого пассажир может сдать билет перед вылетом или просто не полететь, что также изменяет список фактически полетевших пассажиров.
Для устранения этих проблем используется ручной труд. Из аэропорта приходит документ с данными о пассажирах фактически полетевших тем или иным рейсов. После чего сотрудник сверяет пришедший список со списком в базе данных и устраняет неточности.
За неделю таких ситуаций возникает довольно большое количество. Помимо этого из-за большого количества пассажиров приходится проверять слишком большой объем данных для устранения всего лишь одной неточности. Также стоит учитывать человеческий фактор, ведь работник может не найти ошибку с первого раза или принять верные данные за неверные. Все это приводит к тому, что приходится затрачивать крайне много рабочего времени, которое можно было бы направить на более полезную для авиакомпании деятельность.
Казалось бы, самое простое решение это увеличить количество цифр в номере билета, однако это невозможно, так как номера унифицированы благодаря International Air Transport Association (IATA). Сам билет состоит из трех блоков. Первый отвечает за идентификацию авиакомпании, это первые три символа в номере, по которым любой специалист в авиаперевозках легко ответит, что это за авиакомпания. Эти номера присваивались не в определенном порядке,
Актуальные проблемы авиации и космонавтики - 2018. Том 2
а по договоренности с перевозчиками. Например, у American Airlines это 001, у Lufthansa 220, у Аэрофлота 555. Полный список можно проверить на сайте IATA. Официальное название этих трех символов - сток авиакомпании [2].
Следующие два символа - информация о бланке. Первая цифра указывает на тип бланка, вторая на количество купонов в билете. Несмотря на то, что практически весь мир завоеван электронным билетом, в нем все равно используются «бумажные» идентификаторы. В большинстве билетов это цифра 24, где 2 - это автоматическая билетопечать, а 4 -количество купонов. Этот формат был выбран, так как большинство бэкофисных систем в авиакомпаниях, агентствах и прочих компаниях умеют работать именно с таким форматом. А если в билете больше 4 купонов, то система бронирования выпишет несколько связанных билетов [2].
Оставшиеся восемь символов это порядковой номер билета. То есть сто миллионов номеров, которые авиакомпании, использует. И они регулярно используются по второму кругу через какое-то время, чаще всего через год, так как любой билет можно выписать не больше, чем на 330-360 дней вперед от текущей даты [2].
Для решения этой проблемы можно использовать информационные технологии. Существуют различные системы позволяющие сформировать единое информационное поле для решения задач планирования, учета, контроля и анализа авиатранспортных процессов в целом. Это могут быть автоматизированные систему управления (АСУ), информационно-аналитическая система (ИАС) поддержки принятия решений, корпоративная информационная система, система управления базами данных (СУБД) и т. д.
Несомненно, каждая из существующих на рынке систем обладает большим разнообразием функций, эффективно выполняет свое предназначение и занимает свое место среди подобных систем. Однако они обладают высокой стоимостью, а также их достаточно сложно адаптировать под нужды авиакомпании. Поэтому лучше всего решить данную проблему еще на стадии проектирования. Для этого необходимо ответственно подойти к выявлению и анализу требований пользователей.
Пользователи не идеальный источник информации. Большинство из них знают, как выполнять свою работу, однако далеки от понятия того, как переложить все это на компьютер и часто не могут изложить свои требования к будущей системе.
Обычно определения требований поручают аналитикам, которые проводят с пользователями интервью, выявляя их реальные потребности. Но даже аналитикам трудно получить непротиворечивый и в дальнейшем мало изменяемый список требований, если не использовать систематизированный подход к определению требований [3].
Основная цель рабочего процесса определения требований состоит в том, чтобы направить процесс разработки на получение правильной системы. А правильная система - это система, которая делает то, что необходимо и ничего более. Конечно, программистам трудно делать систему так, чтобы ничего от себя не приложить, и тем более ничего не забыть. Описание требований должно быть достаточно хорошим, для того чтобы между пользователями и разработчиками могло быть достигнуто понимание того, что система должна делать и чего не должна. В противном случае пользователи будут считать, что система может сделать для них все, а программисты не будут понимать, какие функции будущей системы обязательно должны будут включены в первую версию, и без них нельзя обойтись, а какие можно отложить до будущего релиза [3].
Можно определить следующие шаги рабочего процесса определения требований:
- выявление требований (сбор информации);
- анализ требований;
- спецификация (документация) требований;
- проверка требований.
Не стоит ждать, что все действия получится выполнить последовательно. Работая с пользователями, нужно будет задавать вопросы, выслушивать ответы и наблюдать за их действиями. Затем стоит обработать полученную информацию, классифицировать по различным категориям и соотнесете потребности с возможными требованиями к ПО. Потом необходимо оформить выработанные требования в виде письменных документов и диаграмм, предложить представителям пользователей подтвердить, что написанный вами текст точен и полон, и попросить их исправить
возможные ошибки. Этапы будут выполняться, чередуясь и периодически повторяясь. Этот итерационный процесс и есть процедура создания требований [3].
Если же проблема осталась не решенной или ее просто не учли, по каким, либо причинам, остается два варианта. Первый - это доработать уже готовый и внедренный продукт. Однако любая система будет очень большой и сложной в использовании, поэтому решить поставленную проблему с помощью штатных специалистов ИТ-отдела будет крайне тяжело. Вследствие чего авиакомпания будет вынуждена привлекать группу узкоспециализированных, высокооплачиваемых специалистов для решения проблемы. Однако такой подход могут позволить себе далеко не все организации из-за высоких денежных затрат.
Второй вариант решения проблемы это создание программного обеспечения специально для этих целей. Реализовать это можно как в виде подсистемы, так и в виде отдельной программы. Подсистема может быть внедрена в общую ИТ инфраструктуру предприятия. Она позволит взять на себя абсолютно всю работу по решению данного рода проблем, тем самым полностью автоматизировав бизнес-процесс. Отдельная программа же не будет иметь доступ к ИТ инфраструктуре предприятия и поэтому не сможет самостоятельно получать на вход данные или же вносить изменения в БД. Для этих целей все равно будет необходим оператор, однако выявлением ошибок будет заниматься сама программа без участия человека, что так же решает проблему.
С написанием такого рода ПО может справиться практически любой программист. Реализация данного проекта не займет много времени и будет достаточно дешевой. Финансовые затраты окупятся довольно быстро. К тому же ликвидация данной проблемы может позволить авиакомпании наращивать производственные мощности, поскольку не будет эффекта «бутылочного горлышка» из-за использования ручного труда.
Библиографические ссылки
1. Как авиакомпании и аэропорты используют ваши данные? [Электронный ресурс]. URL: https://www.aerotime.aero/ru/grazhdanskaya-aviaciya/10924-kak-aviakompanii-i-aeroporty-br-ispolzu-yut-vashi-dannye (дата обращения: 10.03.2018).
2. Почему в билете 13 цифр? [Электронный ресурс]. URL: https://medium.com/andgo-travel (дата обращения: 13.03.2018).
3. Определение требований к программному обеспечению [Электронный ресурс]. URL: http://www.caseclub.ru/articles/treb.html (дата обращения: 13.03.2018).
© Стародубцев А. А., Тихоненко Д. В., 2018
