Что за программа сирена

Самыми громкими новостями за последнюю неделю стали новости о переходе основных отечественных авиакомпаний – Аэрофлота и Сибири на отечественные инвенторные системы и системы бронирования. Аэрофлот ушёл с отечественного ПО в 2002 году. Сибирь почти в то же время. Примерно 2004-2005 год. Обе авиакомпании ушли в Габриэль, Аэрофлот вскоре полностью перешёл на американский Сэйбр, а Сибирь не так давно осела в Амадеусе.

Нужно сказать, что отечественные системы были не столь плохи – вполне добротная Сирена-2000, сам в ней всё хранил, обросла она всевозможными фишками, в принципе, была достаточно мощной, по крайней мере, ЮтЭйр на ней сидел до самого перехода на Леонардо, с поддержкой всех особенностей. Хотя разрекламированные фишки вроде мильных билетов, множества тарифов больше относятся к ГРС (Глобальная распределительная система) Сирена-Трэвэл, так как в инвенторной системе хранится только ресурс мест – то есть, расписание, ресурс мест и рейды со своими статусами.

Банально ввод рейса выглядел просто. В текстовом и скоростном терминале (я работал в центрах ХБР и МОС, ТЮЦ вроде тоже неплохо бегал, про остальные не скажу) вбивалась команда «НК,РАС», после чего в текстовой масочке вводилось расписание рейса (номер, период, дни недели, города, аэропорты вылета и назначения, терминалы, время), потом команда «НК,РЕС» — вводим ресурс мест. Так же в новой масочке – номер рейса, период и количество мест по всем подклассам по всем сегментам рейса (это здесь те самые места по подклассам, где указано, сколько мест по мильным билетам, сколько по дешёвым, сколько по дорогим, но тарифов и сборов здесь нет, только буква подкласса и количество мест). Потом создаются рейды, чтобы связать расписание и ресурсы – «РД,номер рейса,период,дни», а потом можно и продажи открывать «СО,С,номер рейса,период,дни».

ВОЗДУШНАЯ ТРЕВОГА НА ТЕЛЕФОН — УКРАИНА. Где скачать и как настроить приложение? Слушать онлайн!

Конечно, это всё уже подустарела. У новой системы Леонардо графический интерфейс, она приятная наощупь и не пугает белыми буквами на синем фоне. Но в текстовом интерфейсе был важный плюс – скорость работы.

Экран наличия мест ГРС Сирена-Трэвэл

ГРС тоже не отставала – появились мили, куча плюшек у УПТ (условия применения тарифов) из 20 с лишним глав, бонусные мили, карты, обмен с другими системами. В принципе, Сирена была велосипедом для любого кассира, с неё все начинали. Габриэль, кстати, была не на много более user-friendly. Наиболее доступным и простым был графический интерфейс Сэйбра, но, столкнувшись с его глючностью, я перешёл на native, а в центровке у меня стоял именно текстовый терминал, на котором я легко мог спрогнозировать загрузку на любой рейс, а также подблокировать места в случае вылета центровки за буйки.

Пожалуйста, интерфейс Астры

Кроме того, у Сирены-Трэвэл есть мощнейшие движки Oxygen для работы интернет-сайтов (вон у Победы работает и ещё у кучи перевозчиков – ИрАэро, Нордстар и т. д.). Система регистрации Астра выглядит более топорно, но массовый сбой за ней помню только один, лет семь назад, в то время как у Аэрофлота падение Сэйбра каждый год, это только то, что попадает в СМИ.

Сигнальные сирены. Как это работает (How It’s Made) ? Сезон 18 HD ⚙

А сколько раз из-за более мелких сбоев рейс сажали по шахматке (!, и это нацпер) и центровали по телефону. У MySirena вообще нет конкурентов – это система для выписки билетов на чартеры по спискам Эксель, которая в одно бронирование включала до 30 пассажиров. Даже Аэрофлот ей пользовался. В разработке Либра – новая система центровки, которая создаётся в том числе бывшими сотрудниками Аэрофлота и не будет уступать Sabre Load Manager.

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

Именно наличие альтернативных и отработанных продуктов позволило в кратчайшие сроки мигрировать Победе, вроде ни у кого нет вопросов к работе. Аэрофлот уже частично перешёл, сейчас проходит завершающий этап, после перехода сохранятся все функции, кроме некоторых, которые решили доработать. Ну и приложение для iOS, но его не жалко особо – там сейчас вообще ничего путного нет. У меня в App Gallery от Хуавей всё отлично работает – рекомендую переходить. Два года назад купил Honor 30 со 128 Гб памяти – ничего не подвисает, всё работает великолепно, четыре камеры, включая основную с 40 мегапикселями. Никого не призываю, это так)

До 2022 года Сиреной пользовались большинство авиакомпаний страны. Самый лучший пример – ЮтЭйр. Собственные стойки саморегистрации, бонусная программа, стыковки с другими перевозчиками, продажа билетов из любой системы бронирования.

Сибирь переходит на неизвестный мне ранее продукт – ОРС (онлайн резервейшн систем), который произошёл после покупки Ванцевым Таиса. Таис – ответственный за недосистему Сирена-2.3, от которой позже все отказались. Знаменита тем, что позволяла заказчикам чартеров заниматься продажами на рейсы в обход перевозчика. У меня были такие заказчики, которые ей пользовались, но чартер есть чартер. Не страшно, что часть дохода пройдёт мимо перевозчика – там копейки.

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

Но Ванцев, видимо, вдохнул жизнь в Таис. Они снова заработали, но с их новым творчеством ещё не знакомился. Возможно, что-то получится неплохое, но только благодаря Ванцеву. Он действительно профессионал, а ТАИС себя запятнал.

Об истории конфликта можно говорить очень долго. Сирена-2000/Сирена-Трэвэл и Сирена-2.3 отпочковались из одной советской Сирены. Однако вполне адекватная работа Сирены-Трэвэл (бывший Комтех-Н) сделала её фаворитом всех перевозчиков. Сирена-2.3 какое-то время мигрировала по окошкам кассиров, да и где-то пропала. Связка Сирена-2000 + сеанс ТКП стали доминирующими и имелись почти у 100% кассиров.

1. Размещать больше форму со сбором на пиво не буду. В переводах на развитие канала не нуждаюсь, так как пишу регулярно для аудитории, это моё увлечение, ну не блогер я профессиональный. Однако, форма сбора была полезна, чтобы я видел, что читателю особенно что-то понравилось и писал чаще на данную тематику. Поэтому напишу номер карты, куда можно сбросить на кружку пива/мороженое ребенку/цветы жене: 2202 2019 3089 2183.

2. Копия данной статьи расположена на платформе Livejournal по адресу:

Источник: dzen.ru

Через какую хитро закрученную схему вы получаете авиабилет

Так в Сирене выглядит бронирование по маршруту Москва (Внуково) — Краснодар и обратно

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

Учёт билетов в тетрадке всё ещё ведётся в некоторых авиакомпаниях (последний раз такое мы видели буквально в прошлом году в Латинской Америке). В СССР же он вёлся до 1972 года, когда появилась первая сеть из авиакасс в четырёх сотнях городов, соединённых с центральным компьютером. Женщину вынули, автомат поставили. Там, где компьютеров не было, диспетчер связывался с ближайшим центром, где компьютер был.

Эти прекрасные романтические времена, когда Аэрофлот фактически повлиял на изобретение советских сетевых протоколов — первая Сирена работала на аналоге UDP с 97% доставкой. Прогресс советских баз данных и прочих технологий, которые сейчас воспринимаются как антураж Фаллаута, — через несколько витков эволюции превратился в связку из нескольких систем, которые, собственно, и выписывают вам билет.

• Авиакомпании выгружают свои тарифы, расписания и доступные билеты в инвенторные системы (собственные «хранилки»).
• GDS соединяют инвенторные системы разных компаний и позволяют искать билеты в них. К этим системам подключаются продавцы и берут в них билеты для своих клиентов.
• В мире есть несколько больших GDS, и одна из них — отечественная Сирена.

Инвенторная система (CRS)

Основа распределения мест авиакомпании — это инвенторная система. По сути, это расширенный аналог тетрадки с записями мест. В инвенторной системе как минимум хранится расписание рейсов и наличие мест на них, а также занятые места связываются с пассажирами.

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

Вход и выход простые: вы можете получить из инвенторной системы расписание и наличие мест либо указать, что одно из свободных мест нужно занять вот таким-то пассажиром. Конечно, современные инвенторные системы обладают чуть более широким функционалом, чем просто хранение данных и два внешних API-вызова, но про это дальше.

Инвенторные системы обычно объединяются с какой-то инфраструктурой в контур, который сертифицируется для хранения персональных и банковских данных, прочих чувствительных материй. Всё это вместе обычно называется хостом авиакомпании.

Поднять хост — это целый бизнес, потому что вам нужно развернуть ЦОД, в него натаскать своих серверов, всё это сертифицировать по российским стандартам и множеству зарубежных (начиная с PCI DSS и заканчивая…). Также сверху поставить решение, которое обеспечит совместимость со всеми мировыми системами продажи билетов. И ещё нужно это всё поддерживать. Получается достаточно дорого, поэтому хосты обычно строятся и группируются теми, кто способен один раз отработать процесс создания инфраструктуры под них и поддержки ПО.

Собственно, Сирена (та самая система резервирования авиабилетов) эволюционировала, в частности, в Сирену-Трэвел, которая поддерживает хосты для российских авиакомпаний. Вообще, держать хост у кого-то — общемировая практика. Насколько я знаю, собственные хосты (не SaaS и не аутсорс) поддерживают Эмирейтс и Туркиши. В России вообще нет ни одной авиакомпании, имеющей хост не в виде SaaS.

Глобальная распределительная система (GDS)

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

Очевидно, был запрос на систему, которая собирала бы все данные со всех хостов и давала возможность решить задачу коммивояжёра на полном графе. Чтобы пассажиру можно было полететь из Нового Уренгоя в Париж с какими угодно пересадками так, как ему нравится: быстрее всего, дешевле, с остановкой в Стамбуле на сутки, без Лондона (потому что там у него нет визы) и так далее.

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

Но суперхост — идея нежизнеспособная.

Во-первых, исторически это было невозможно. Из-за технических ограничений тех лет просто нельзя было держать базу данных такого размера. Для понимания — первая советская Сирена была разделена на региональные подсистемы, в которых кластеризовались рейсы по авиакомпаниям нескольких схожих направлений. Примерно до середины 1990-х это было около 60 разных «дробных» баз в разных регионах, и нужна была какая-то связка между ними.

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

В итоге понадобилась надстройка, умеющая собирать расписания и доступность мест с хостов.

Системы, которые опрашивали хосты таким образом, стали современными GDS.

Упрощённо, GDS умеет собирать всё подмножество расписаний хостов, делать поиск на нём и показывать пассажиру (или кассиру) варианты, как добраться из точки А в точку Б, а потом отправлять в инвенторную систему запрос на занятие мест.

То есть это такая обёртка поверх CRS, ставшая, по сути, интерфейсом к хостам.

Соответственно, в случае Советского Союза и России дальше появилась интеграция ГРС Сирена с Сиренами-2000 (региональными инстансами и хостами авиакомпаний). С единого терминала можно было заказывать любой рейс.

Поисковая нагрузка

Инвенторные системы по своей архитектуре очень часто легасевые либо просто не предназначенные для высоких нагрузок. В них нужно отправлять целевой запрос: «Дайте расписание конкретного рейса в определённый день. Фиксируем: есть свободные места, вот эти два займите вот этими пассажирами». Поиск по десяткам разных дат и сотням рейсов они не выдержат в силу своего устройства.

А как раз GDS стали прослойкой, которая вполне может отдавать тысячи комбинаций, то есть делать поиск по запросам типа «что у вас вообще есть в Магадан?» или искать с гибкими датами. Для рейса, например, в Эквадор с плавающей датой отбытия нужно было бы сделать от 50 до двух–трёх тысяч запросов в хосты, если бы не было GDS. Соответственно, GDS ещё обеспечивает синхронизацию своих расписаний с хостами, обращаясь в них не каждый раз, а только по изменению на хосте.

Тарифы

Любой тариф должен быть представлен в некотором универсальном виде, позволяющем понять, как он применяется и при каких условиях. В итоге сейчас для нас на практике есть два набора стандартов: общемировой и отечественный. Они совместимы, конечно, но правила тарифной сетки хранятся в двух разных компаниях. У нас это центр расписания и тарифов (ЦРТ). GDS использует базу данных ЦРТ для того, чтобы понять, как и какую услугу считать.

Исторически было так: сначала авиакомпания просто говорила, сколько стоит перелёт и это записывалось в билет в графу «тариф». Затем по ряду причин из тарифа стали выделять сборы: аэропортовый сбор за услуги воздушной гавани и терминала, топливный сбор, госпошлина и дистрибутивный сбор.

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

Этим всем занимается система взаиморасчётов (СВВТ), а ЦРТ — часть СВВТ.

Расчёт тарифа перед продажей билета

Усложнение GDS

Представьте, что вам нужно пересадить человека между двумя авиакомпаниями — сделать connected flight, то есть с гарантией доставки. Опять же, в первом приближении выглядит просто: нужно посмотреть, есть ли у компании А и компании Б соглашение, а потом сформировать один билет из двух сегментов по этому соглашению. Но тут необходимо учесть множество деталей. Например, укладывается пересадка в MCT или нет (это минимальное время от прибытия самолёта до конца посадки другого, зависит от особенностей аэропорта: по проверкам, расстоянию, досмотрам ручной клади и багажа). А если на одном рейсе пассажиру можно 7 кг ручной клади в одной сумке, а на другом 10 кг в любых рекомбинациях — какое правило применять и показывать в тарифе?

И это только стыковки М1. Последние годы развиваются стыковки М2 — новое поколение, когда GDS объединяет две несвязанные соглашениями авиакомпании (или даже авиакомпанию с железнодорожными и автобусными перевозчиками). А иногда система продажи авиабилетов вообще продаёт вам билет на поезд и автобус в М2-стыковке.

В случае Сирены М2 стыковки делались с Deutsche Bahn для доставки по Германии сначала рейсом Аэрофлота в страну, а потом поездами по ней. Сейчас их по понятным причинам уже нет.

Опять же, когда вы начинаете собирать в GDS железнодорожные билеты из АСУ Экспресс (из более консолидированной GDS железных дорог), подтягивать автобусные билеты из аналогов хостов автобусных перевозчиков или их аналогов GDS, то возникает непреодолимое желание интегрировать в систему вообще всё. Сирена в какой-то момент торговала даже билетами на концерты, раз уж инфраструктура имеется. Но поскольку это был не их бизнес, довольно скоро пришли профильные игроки вроде Партера и написали более специализированные и более конкурентные системы.

Следующая задача для GDS — код-шер и интерлайн-перелёты. Например, летит один физический самолёт, но в нём два рейса: один, скажем, S7, а второй — Air France. Формально его выполняет одна из авиакомпаний, а вторая включила его в свою сетку расписания как собственный. Технически можно хранить все такие рейсы в хостах как свои, то есть загружать расписания вообще всех авиакомпаний, с которыми есть соглашения. На практике обычно такое решение используется редко из-за роста базы (и стоимости содержания хоста), и такие рейсы очищает и склеивает между собой уже GDS.

Оплаты

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

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

GDS в итоге должна иметь ещё какой-то сервис, который позволяет заплатить за билет, а не просто его найти и выписать. У нас в России это транспортная клиринговая палата (ТКП). Фактически это компания, которая заключает договоры с каждым из участников, обеспечивает их деятельность банковскими гарантиями или депозитами и делает так, что деньги от клиента в конечном итоге поступят продавцу. Поскольку она ещё и К, там происходит взаимозачёт, и только потом движение денег.

Что получается

• Авиакомпании держат свои расписания и наличие мест в хостах.
• Хосты обычно находятся на инфраструктуре компаний, делающих GDS.
• GDS объединяет хосты, добавляет тарифные правила, делает стыковки, обеспечивает взаиморасчёты через клирингового партнёра.
• Один хост может быть подключён к нескольким разным GDS.
• Хосты могут синхронизироваться с другими хостами партнёрских авиакомпаний, используя GDS как шину.
• GDS может стыковаться с другой GDS или аналогом на другом виде транспорта.
• GDS не видна пассажиру, он видит TA или OTA — конечных продавцов билетов.

Теперь про комиссии. В России Сирена преимущественно берёт комиссию с агентств за выписанный билет. Западная практика — GDS платят агентствам как дистрибьюторам, а авиакомпании, соответственно, платят GDS сбор (11 евро) за каждый сегмент. Сирена — первоисточник контента с билетами. Уже агентствам интересно подключаться к ней и получать от неё сервис.

Ещё один отличный вопрос: откуда тогда тут иностранные компании, которые как-то влияют на наших перевозчиков? В силу определённых особенностей, до появления 153-ФЗ про «приземление» персональных данных, авиакомпании с международными полётами часто сотрудничали с иностранными GDS-операторами для содержания у них хостов.

К примеру, Аэрофлот раньше покупал эту услугу у Sabre (и ещё покупает формально, но могу ошибаться), а S7 — у Amadeus. Хост, соответственно, соединялся с несколькими разными GDS, включая Сирену. GDS выступала в роли дистрибьютора билетов, например, у Сирены сейчас 15 тысяч точек продажи и 800 агентств-партнёров (включая нас и других онлайн-продавцов билетов, например, но мы случай немного особый, поскольку сотрудничаем с четырьмя разными GDS и имеем ещё прямые договоры с рядом перевозчиков). Есть страны СНГ, где большинство точек продажи Amadeus, например, поэтому если хочется продавать билеты из этой страны — партнёрство с ними как с GDS становится почти обязательным.

Когда стало невозможно сотрудничать с западными компаниями, возникла необходимость переноса хостов. Был норматив, который требовал переносить хосты в РФ, но перевозчики откладывали сколько могли. В феврале наступил дедлайн. Например, недавний переезд Победы из Navitaire в Сирену — как раз перенос хоста.

Теперь перейдём к вопросу, почему при проблемах с GDS может пострадать продажа билетов у самой авиакомпании. Ещё более интересным следствием того, что GDS фактически выступают умным интерфейсом к хостам, стало то, что напрямую через хост продавать не очень удобно. Даже когда авиакомпания создаёт свой сайт, ей часто удобно продавать не впрямую, а через GDS, пользуясь уже готовыми сервисами код-шера, интерлайна, подключением к ТКП и так далее. Единственное исключение — оформление продаж услуг вроде бортового питания. В итоге, если вдруг из-за санкций с вами перестаёт работать GDS, нужно быстро поменять систему, через которую сделан магазин на сайте, иначе отвалятся и собственные продажи тоже.

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

Это ещё не всё, погодите!

У OTA вроде нас могут быть собственные средства, которые обогащают всю эту историю. Во-первых, для ускорения поиска, чаще всего используются объёмные кеши сопоставления данных GDS по расписаниям, тарифным правилам и дополнительным услугам. Чтобы показать клиенту информер со стоимостью билетов по его хитрому маршруту на ближайшую плюс-минус неделю, используются именно собственные кеши, иначе GDS сложились бы под шквалом запросов. Собственные кеши нужны и для того, чтобы опрос GDS занимал не 5–10 минут, а секунды — просто проверить даты обновлений хостов и получить инкремент.

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

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

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

• бронирование авиабилетов
• gds
• сирена

• Блог компании Туту.ру
• Управление проектами
• Транспорт

Источник: habr.com

Глава 2. Анализ отечественной системы бронирования Сирена

2.1 Появление первой отечественной системы бронирования

В 1964 г. лаборатория №17 Института проблем управления Российской Академии Наук объявила о начале работ по созданию нового класса больших компьютерных систем с мультидоступом к удаленной базе данных в реальном масштабе времени, получивших название автоматизированных систем массового обслуживания (АСМО), включая методы расчета и проектирования. Постепенно это научно-техническое направление приобрело огромную популярность в СССР.

В партнерстве с ИПУ РАН работали десятки научно-исследовательских организаций и предприятий, производивших технические средства. Начиная с 1965 г. и почти до начала 90_х годов лаборатория возглавляла разработку и сопровождение первой в СССР, крупной АСМО для нужд Аэрофлота СССР — «СИРЕНА».

В рамках этого проекта были реализованы передовые идеи, которые в дальнейшем стали основополагающими для вычислительных систем самого разнообразного назначения, а именно: — удобный человеко-машинный интерфейс, — удаленный множественный доступ к базе данных в режиме on-line, — быстрая обработка транзакций, и др. В итоге на территории СССР было образовано несколько десятков компьютерных центров системы «СИРЕНА», связанных друг с другом разветвленной сетью и обслуживающих несколько тысяч кассовых терминалов.

Вот вехи развития «СИРЕНЫ»: 1973: Начало эксплуатации системы «Сирена_1» ГВЦ Гражданской Авиации в Москве. Используемые ЭВМ — М_3000, М_6000. 1975: Ввод в действие системы «Сирена» в Ростове-на-Дону. Используемые ЭВМ — М_7000, М_4030. При этом оба центра были изолированы друг от друга и хранили только собственные ресурсы.

1980: Создание системы «Сирена_2» в Риге и Москве. Используемые ЭВМ — СМ_2, затем СМ_2М. Объединены в сеть центры Москвы, Риги, Ростова-на-Дону, Киева, Свердловска. 1992: Создание проекта «Сирены_2М» — начало применения персональных ЭВМ типа IBM PC в центрах обработки данных вместо СМ_2М, а затем и в качестве рабочих мест кассира. 1996-97: Создание проектов «Сирена_2.3», «Сирена_2000».

Расширенный набор услуг, функций, отвечающий современным потребностям.

2.2 Характеристика системы бронирования сегодня

• реализовать международную технологию продажи пассажирских перевозок с учетом сложившейся внутренней специфики;
• поддерживать два языка (русский и английский);
• сосредоточить весь ресурс в одном центре с целью максимального контроля за ходом его реализации;
• управлять своими ресурсами и проводить независимую тарифную политику;
• осуществлять взаимодействие с международными системами бронирования (например «Amadeus»), расширяя сеть продажи;
• учитывать требования пассажиров о специальном обслуживании;
• формировать списки пассажиров для Системы Управления ОтправкамиАстра, итоговую информацию по результатам продажи для Системы Управления Доходами Primax , получать статистику отправок.

• автоматизировать функции оформления пассажиров, багажа и ручной клади, документирования рейса, допродажи билетов на стойках регистрации, информирования пассажиров и служб аэропорта и многое другое;
• реализовать международную технологию регистрации пассажиров и багажа с учетом сложившейся внутренней специфики;
• поддерживать два языка (русский и английский);
• использовать аппаратуру АТВ (печать посадочных талонов с магнитной полосой, печать багажных бирок со штрих-кодами);
• использовать электронные весы;
• проводить одновременную регистрацию нескольких рейсов с одной стойки и рейса с нескольких стоек;
• вести автоматический расчет платного, сверхнормативного, ценного багажа, печать квитанций оплаты сверхнормативного багажа;
• осуществлять динамический контроль предельной коммерческой загрузки рейса с учетом груза и почты.

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

1. Большой объем ресурсов, доступных с одного экрана.
2. Удобство работы кассира.
3. Более полная, чем в любом ЦБА тарифная информация по всем авиакомпаниям, обеспечивающая автоматический расчет стоимости при продаже и возврате билета.
4. При работе через Сирена-Трэвел обеспечивается полный УЧЕТ и контроль работы кассиров и субагентов агентства.
5. Возможность бронирования мест в гостиницах с любого агентского терминала, как одновременно с продажей авиаперевозки, так и отдельно.
6. Сирена-Трэвел позволяет всем агентам перейти к единой технологии бронирования.
7. При этом в системе будет создано одно PNR для всех сегментов рейсов, входящих в маршрут из различных систем бронирования, и автоматически будут созданы PNR во всех системах бронирования авиакомпаний, в которых размещены ресурсы рейсов, входящих в данный маршрут.

1. Сирена-Трэвел функционировала в режиме опытной эксплуатации с 1 июня 2000 года. В тестировании приняли участие: Главагентство, ЦАВС Тюмени, Хабаровска, Казани, Самары, Краснодара, Оренбурга, Киева, Красноярска, Саратова.
2. Тестирование системы показало, что программное обеспечение Сирена-Трэвел соответствует рекомендациям IATA, что подтверждается наличием интерфейса с системой «Сирена-3», являющейся аналогом SABRE.
3. С 15.04.01 введена в промышленную эксплуатацию Распоряжением Министерства транспорта Российской Федерации, что позволяет всем терминалам сети передачи данных «Сирена» иметь доступ к ресурсам авиакомпаний, размещенным в центрах бронирования «Сирена — 2000» и «Сирена-3».

Источник: studfile.net