+7(499) 450-28-09

Интервью разработчиков АСУ и сотрудников автовокзалов

16.10.2014

Приложение к статье "Автоматизированные системы управления автовокзалами России". Интервью разработчиков АСУ и сотрудников автовокзалов.

Содержание:

Основное интервью ООО «ИТТ»
Второе интервью ООО «ИТТ»
Интервью ижевского автовокзала

Основное интервью «КВЦ-Сервис»
Интервью санкт-петербургского автовокзала

Основное интервью ООО «Артмарк»
Интервью барнаульского автовокзала

Основное интервью ЗАО «ТАИС»
Второе интервью ЗАО «ТАИС»
Интервью щелковского автовокзала

Основное интервью SWD Factory
Второе интервью SWD Factory
Интервью псковского автовокзала


Основное интервью ООО «ИТТ»

На вопросы отвечал директор ООО «ИТТ» Сергей Соловьев, г. Ижевск, продукт «Авибус: Управление автовокзалами».


Как вы видите историю появления АСУ автовокзалами, когда появились первые решения и где? Какова история создания Вашего продукта, этапы его развития?

Известная нам история промышленной автоматизации автовокзалов началась с “КВЦ-сервис” в 2003 году на предприятии «Тулаавтотранс». Самописные решения, не получившие распространения, существовали еще в эпоху DOS и присутствовали на рынке еще в 90х годах. В СССР заметных решений по автоматизации скорее всего не было, разве что на высоких отраслевых уровнях, хотя пассажиропоток был в разы больше, чем в современной России. Решение от «КВЦ-сервис» охватило центральные районы России, где высокая плотность населения, и автобусный транспорт на междугороднем направлении наиболее популярен. Южные регионы, конечно, сильно отличаются по популярности автобусных перевозок в большую сторону, но за счет менталитета региона вопрос об их автоматизации остро не стоит до сих пор. Логично, что первое решение появилось в регионе с наибольшим спросом на автобусные пассажирские перевозки и совпало с периодом, когда персональные компьютеры стали более-менее доступны для бизнеса и потребителей.

Примерно с 2006 года начинается бум разработок систем автоматизации автовокзалов, пик его приходится на 2007-2008 год. За это время появляются все основные решения, присутствующие на рынке на сегодняшний день.

Компания «ИТТ» выросла из отдела разработки компании «Райс» (risecompany.ru), а именно из проекта по автоматизации автовокзалов.

В августе 2008 года ко мне, руководителю отдела разработки компании «Райс», обратился клиент «Автовокзалы Удмуртии» (avokzal.udm.ru) в лице Корняева Дмитрия с задачей на разработку автоматизированной системы управления автовокзалами. «Автовокзалы Удмуртии» на тот момент планировали крупное расширение программы автоматизации на большом количестве своих объектов. Существующее решение от «КВЦ-сервис» и предложение по расширению на его основе не удовлетворяло клиента: высокая заявленная стоимость сопровождения, ограниченность ресурсов разработчика, закрытый код решения.

Под моим руководством была собрана команда разработчиков, в том числе с привлечением outsourcing разработчиков компании IzhTC, и уже через 3 месяца (январь 2009) появилась первая версия «Райс: Управление автовокзалами», которая позволила клиенту избавиться от проблем, связанных с недостатками предыдущего решения, и оперативно начать автоматизацию своих автовокзалов. Было принято решение выделить проект в отдельное направление, таким образом была основана компания «ИТТ». Решение получилось настолько удачным, что было отмечено министерством транспорта УР во внутреотраслевой рассылке. Почти сразу появился второй крупный клиент – «Башавтотранс» bashauto.ru, с большим количеством новых и серьезных задач. Суммарная сложность нового проекта оказалась в несколько раз больше первоначального, разработанного для «Автовокзалов Удмуртии», что позволило вывести решение на новый качественный уровень уже к июлю 2009 года.

В 2010 году был автоматизирован автовокзал «Южный» в Казани и несколько небольших клиентов. Удачное внедрение в Башкирии повлекло за собой большое количество встреч и демонстраций системы на примере «Башавтотранс», велась работа по доработке решения в тесном взаимодействии с их же ИТ-отделом.

2011 год был очень успешным, в этот год появились крупные клиенты из Самары, Омска, Томска и Челябинска. В сотрудничестве с «Автовокзалами Удмуртии» и компанией «Мифорс» было разработано терминальное решение по продаже билетов.

В 2012 году появились клиенты из Тольятти, Белгорода, Братска, Владимира, Нижневартовска, Семипалатинска, Хакасии. В Республике Казахстан появился партнер, взявший на себя доработку и внедрение решения под локальных клиентов, его первым проектом было внедрение системы в Усть-Каменогорске.

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

В начале лета 2014 года состоялся релиз версии 2.0 и переимнование системы в «Авибус: Управление автовокзалами».


Что из себя представляют АСУ для автовокзалов сегодня? В технологическом смысле – что они умеют? Как Вы позиционируете по функционалу свою АСУ? Чем она отличается от остальных решений? Как Вы видите своего заказчика?

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

Наше решение основано на платформе, признанной стандартом в сфере автоматизации, – это платформа «1С Предприятие 8». Система имеет весь необходимый функционал, но отличается от других решений наличием компонент для современного технологичного автовокзала и открытым для изменений кодом. Упор делается на мобильность (независимость от локальной инфраструктуры), технологичность и современность, поэтому в нашем решении есть компоненты модуля продажи билетов через интернет, мобильного приложения рабочего места кассира и перронного контролера, терминалы самообслуживания, открытый протокол связи, универсальный информационный дисплей (табло расписания рейсов, экран покупателя, рекламный экран), развитая сетевая архитектура, позволяющая продавать билеты своих удаленных и даже чужих автовокзалов.

Мы видим своими заказчиками всех участников рынка, так или иначе связанных с продажей билетов на пассажирский автобусный транспорт, начиная с независимых перевозчиков и туристических агентств в качестве агентов по продаже и заканчивая крупными объединениями автовокзалов регионального масштаба. Всех их объединяет одно – желание быть современными, независимыми и технологичными в своей деятельности. Эти желания и стали причиной появления нашего решения на рынке, и исходили они от нашего первого заказчика – ОАО «Автовокзалы Удмуртии».


Чего еще не умеют современные АСУ? Будущее АСУ – каким оно Вам видится? И отдельно – будущее Вашего продукта? Каковы ближайшие и стратегические перспективы? Что Вы планируете предложить в ближайшей новой версии продукта?

В настоящее время АСУ умеют пожалуй больше, чем требует рынок, возможно, все АСУ в скором времени обзаведутся возможностью отслеживать автобусы по GPS или ГЛОНАС, автоматически выполнять диспетчерские функции, научатся автоматически сканировать документы, повысится связность различных систем. Все эти нововведения запланированы и в нашем решении. В ближайшем будущем возможна интеграция различных решений друг с другом, и интеграция эта нам видится на рыночных принципах, а не на принципах создания над-интегратора. Также в контексте готовящегося закона «О прямых смешанных перевозках» можно ожидать интеграцию АСУ автовокзалов в единую систему продажи билетов на различные виды транспорта (авиа, ж/д и морской транспорт, такси).

Версия 2.0 нашего решения содержит множество нововведений:
  • Легкая интеграция с «чужими» вокзалами, в том числе и автоматизированными другими программами, как для продажи билетов, так и для совместного использования транзитных рейсов без квоты мест.
  • Возможность организовать работу нескольких автовокзалов в одной информационной базе.
  • Полное соответствие закону о защите персональных данных.
  • Возможность использовать внешнее приложение на Qt как рабочее место кассира.
  • Возможность полноценной работы даже на узких каналах связи, что позволяет обойтись без создания распределенных баз для каждой автостанции, т.к. для продаж может быть достаточно и мобильного канала.
  • Продажа билетов трансагентствами и собственными кассовыми пунктами без установки «1С».
  • Веб-интерфейс, позволяющий работать с программой из браузера или тонкого клиента.
  • Ускорение работы кассира и диспетчера за счет оптимизации структуры данных.
  • Приведение терминологии и логики работы в соответствие с правилам перевозок.
  • Отсутствие необходимости в первоначальных настройках: начальная поставка содержит уже заполненные по умолчанию данные (льготы, возвраты и т.п.) в соответствии с правилами перевозок.
  • Реализация возможности работы в «облаке» – приложение как сервис (SaaS).
  • Новое мобильное приложение – рабочее место перронного контролера и оператора автостанции.

Какие страны лидируют сегодня в автоматизации транспорта? На каком «месте» находится Россия?

К сожалению, достоверной информации о том, как обстоят дела с автоматизацией во всем мире, у нас нет. Есть информация о наших ближайших соседях, Европе и Востоке. На Украине присутствует очень зрелое и массовое решение от ВПИ, разработчики даже говорят об АСУ национального масштаба. Восточная Европа использует решение от SWD Factory. Наверное, трудно выделить какие-то конкретные страны, находящиеся на лидирующих позициях, можно говорить о всех развитых странах как об одном эшелоне, в котором не на последних местах присутствует Россия.

В России история АСУ автовокзалами насчитывает около 20 лет, за это время решения стали зрелыми и выполняют все задачи, которые перед ними ставит рынок.

Как государство помогает законодательно, налогами, фондами, дотациями, программами и другими путями внедрению АСУ для автовокзалов и росту автоматизации транспорта в России? И какова практика в других странах?

В России помощь по использованию АСУ на автовокзалах со стороны государства оказывается разве что косвенно. Одним из направлений в развитии транспортной инфраструктуры можно считать разработка закона “О прямых смешанных перевозках”, конечно если его реализация не будет зарегулирована со стороны государства или структур, ему подконтрольных. Также местные власти понимают важность автовокзалов в социальной инфраструктуре и помогают в реализации проектов по строительству новых объектов. Напрямую государство на влияет на задачи, связанные с внедрением и использованием АСУ.

Сейчас работает единый центр сбора информации о пассажирах со всего транспорта на базе ФГУП «Защитаинфотранс», скорее всего единая государственная система, планируемая в законе “О прямых смешанных перевозках”, будет базироваться на этом же ресурсе. В дальнейшем это должно плодотворно повлиять на решение транспортных задач. Уже сейчас требование о выгрузке информации о пассажирах вынуждает автовокзалы внедрять у себя программные решения, можно, конечно, считать и это помощью для производителей решений по автоматизации со стороны государства.

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

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


Как Вы взаимодействуете с другими производителями АСУ? Нужно ли это вообще, чтобы разные продукты работали в единой системе, между ними были бы налажены «мосты»? И как именно Вы видите возможную интеграцию?

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

В системе «А» система «Б» может быть представлена как один из участников системы «А», только с расширенным доступом к информации, для этого потребуется создать центры консолидации информации в каждой системе, в итоге это будет рыночная система без лишних звеньев.


Какие технологические решения Вы используете – какие языки программирования, операционные системы, базы данных, веб-серверы и так далее? Используете ли Вы разработки класса Open source под свободными лицензиями? Интегрированы ли в Ваше решение мобильные приложения, терминалы самообслуживания и веб-ресурсы?

Наше решение основано на платформе 1С, которая, в свою очередь, стала отраслевым стандартом. Также очень важно, что код нашего решения открыт для изменения любым специалистом по 1С, рынок которых гораздо больше, чем программистов на других языках. Кроме того в нашем решении присутствуют специализированные инструменты, такие как рабочее место кассира или мобильное рабочее место, написанные на кросс-платформенном фреймворке Qt(C++). Все решения, кроме приложения для Android, работают на самых распространенных операционных системах – Microsoft Windows и Linux. Для хранения данных используются зарекомендовавшие себя базы данных Microsoft SQL, IBM DB2, Oracle или бесплатная PostgreSQL. В решении заложена возможность связывать между собой автовокзалы даже различных организаций, что позволяет продавать билеты чужих автовокзалов.

Также наше решение использует сервисы Яндекс для своей работы и выгрузки данных для поисковой системы. В нашем решении реализована, помимо компоненты для сайта, единая площадка по продаже билетов через интернет – сайт edukmame.ru (с 2015 года bilet.do). Есть приложение для терминалов самообслуживания, приложение дисплея покупателя и табло рейсов и расписания, о мобильном приложении я уже упоминал.

Что касается свободных лицензий и продуктов Open source, в нашем решении присутствует поддержка PostgreSQL и Linux систем, в качетсве веб-сервера может быть использовано Apache, на этом все и заканчивается.


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

После приобретения решения "Авибус: Управление автовокзалами" следует этап внедрения системы на предприятии. Мы проанализировали типовые сценарии внедрения (небольшой автовокзал, перевозчик, крупный собственник) и предоставили их в виде таблицы с примерной оценкой временных затрат.


Небольшой автовокзал с одной или несколькими кассами и сайтом.


 
Подготовка
– Определение необходимого количества рабочих мест, проверка наличия необходимого оборудования и назначение ответственного.
– Согласование комплекта поставки и оплата.
12д
 
 
 
 
Настройка и обучение
– Первоначальная установка системы.
– Знакомство с программой, изучение документации, эксперименты в демонстрационной базе данных.
– Доработка системы под особенности предприятия (при необходимости).
– Настройка системы (сборы, услуги, правила продаж, льготы, пользователи) и заполнение данных (расписание, билеты, автобусы, перевозчики).
– Настройка торгового оборудования.
– Обучение персонала (кассиров, диспетчеров, агентов) на демонстрационной базе данных.
– Проведение аттестации сотрудников.
10д
10д
 
 
 
Начало работы
– Определение даты запуска системы и начало предварительной продажи билетов в одной кассе (по законодательству – 10 дней).
– Опытная эксплуатация системы, доработка (при необходимости).
– Ввод всей системы в эксплуатацию.
24д
Итого на внедрение


После приобретения решения "Авибус: Управление автовокзалами" следует этап внедрения системы на предприятии. Мы проанализировали типовые сценарии внедрения (небольшой автовокзал, перевозчик, крупный собственник) и предоставили их в виде таблицы с примерной оценкой временных затрат.


Небольшой автовокзал

Небольшой автовокзал с одной или несколькими кассами и сайтом. Оценка необходимого времени на внедрение решения "Авибус: Управление автовокзалами".


 
Подготовка
– Определение необходимого количества рабочих мест, проверка наличия необходимого оборудования и назначение ответственного.
– Согласование комплекта поставки и оплата.
12д
 
 
 
 
Настройка и обучение
– Первоначальная установка системы.
– Знакомство с программой, изучение документации, эксперименты в демонстрационной базе данных.
– Доработка системы под особенности предприятия (при необходимости).
– Настройка системы (сборы, услуги, правила продаж, льготы, пользователи) и заполнение данных (расписание, билеты, автобусы, перевозчики).
– Настройка торгового оборудования.
– Обучение персонала (кассиров, диспетчеров, агентов) на демонстрационной базе данных.
– Проведение аттестации сотрудников.
10д
10д
 
 
 
Начало работы
– Определение даты запуска системы и начало предварительной продажи билетов в одной кассе (по законодательству – 10 дней).
– Опытная эксплуатация системы, доработка (при необходимости).
– Ввод всей системы в эксплуатацию.
24д
Итого на внедрение


Перевозчик

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


 
 
Подготовка
– Определение необходимого количества рабочих мест, проверка наличия необходимого оборудования и назначение ответственного.
– Знакомство с программой, изучение документации, эксперименты в демонстрационной базе данных.
 
 
Настройка и обучение
– Настройка системы (сборы, услуги, правила продаж, льготы, пользователи) и заполнение данных (расписание, билеты, автобусы, перевозчики).
– Настройка торгового оборудования.
– Обучение персонала (кассиров, диспетчеров, агентов) на демонстрационной базе данных.
10д
10д
 
 
 
Начало работы
– Определение даты запуска системы и начало предварительной продажи билетов в одной кассе (по законодательству – 10 дней).
– Оплата выбранных услуг.
– Ввод системы в эксплуатацию.
17д
Итого на внедрение


Крупный собственник

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


 
 
Подготовка
– Определение необходимого количества рабочих мест, проверка наличия необходимого оборудования, стабильного канала связи и назначение ответственного.
– Подготовка плана внедрения на всех узлах.
– Согласование комплекта поставки и оплата.
11д
 
 
 
 
 
2д*N
1д*N
 
1д*N
 
 
Настройка и обучение
– Первоначальная установка системы.
– Знакомство с программой, изучение документации, эксперименты в демонстрационной базе данных.
– Доработка системы под особенности предприятия (при необходимости).
– Настройка системы (сборы, услуги, правила продаж, льготы, пользователи) и заполнение данных (расписание, билеты, автобусы, перевозчики).
– Создание распределенных баз узлов, их настройка (пользователи, план обмена).
 
Внедрение системы на узлах (N – количество узлов)
– Настройка на узле торгового оборудования, сервера, СУБД, резервного копирования.
– Обучение персонала (кассиров, диспетчеров, агентов) на демонстрационной базе данных.
– Проведение аттестации сотрудников.
10д
10д
 
 
 
 
 
Начало работы
– Определение даты запуска системы и начало предварительной продажи билетов в одной кассе (по законодательству – 10 дней).
– Опытная эксплуатация системы, доработка (при необходимости).
– Ввод узла в промышленную эксплуатацию.
– Внедрение системы на следующем узле.
– Ввод всей системы в эксплуатацию.
24+2*N
 
Итого на внедрение
пример: при N=10, внедрение займет 44 дня.

Независимый перевозчик с несколькими маршрутами, но без автовокзала, с одной или несколькими кассами и возможно сайтом.


 
 
Подготовка
– Определение необходимого количества рабочих мест, проверка наличия необходимого оборудования и назначение ответственного.
– Знакомство с программой, изучение документации, эксперименты в демонстрационной базе данных.
 
 
Настройка и обучение
– Настройка системы (сборы, услуги, правила продаж, льготы, пользователи) и заполнение данных (расписание, билеты, автобусы, перевозчики).
– Настройка торгового оборудования.
– Обучение персонала (кассиров, диспетчеров, агентов) на демонстрационной базе данных.
10д
10д
 
 
 
Начало работы
– Определение даты запуска системы и начало предварительной продажи билетов в одной кассе (по законодательству – 10 дней).
– Оплата выбранных услуг.
– Ввод системы в эксплуатацию.
17д
Итого на внедрение


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


 
 
Подготовка
– Определение необходимого количества рабочих мест, проверка наличия необходимого оборудования, стабильного канала связи и назначение ответственного.
– Подготовка плана внедрения на всех узлах.
– Согласование комплекта поставки и оплата.
11д
 
 
 
 
 
2д*N
1д*N
 
1д*N
 
 
Настройка и обучение
– Первоначальная установка системы.
– Знакомство с программой, изучение документации, эксперименты в демонстрационной базе данных.
– Доработка системы под особенности предприятия (при необходимости).
– Настройка системы (сборы, услуги, правила продаж, льготы, пользователи) и заполнение данных (расписание, билеты, автобусы, перевозчики).
– Создание распределенных баз узлов, их настройка (пользователи, план обмена).
 
Внедрение системы на узлах (N – количество узлов)
– Настройка на узле торгового оборудования, сервера, СУБД, резервного копирования.
– Обучение персонала (кассиров, диспетчеров, агентов) на демонстрационной базе данных.
– Проведение аттестации сотрудников.
10д
10д
 
 
 
 
 
Начало работы
– Определение даты запуска системы и начало предварительной продажи билетов в одной кассе (по законодательству – 10 дней).
– Опытная эксплуатация системы, доработка (при необходимости).
– Ввод узла в промышленную эксплуатацию.
– Внедрение системы на следующем узле.
– Ввод всей системы в эксплуатацию.
24+2*N
 
Итого на внедрение
пример: при N=10, внедрение займет 44 дня.


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

Необходимо отметить, что платформа 1С является стандартом, и внедрение решения, на ней основанного, является тривиальной задачей практически для любого системного администратора или специалиста по 1С. Этот факт выгодно отличает наше решение от других и позволяет нашим специалистам участвовать при внедрении только в качестве консультантов.

После успешного внедрения предприятие получает полгода бесплатного технического обслуживания. Техническая поддержка осуществляется нашими специалистами по установленному тарифу (от 900 до 1 200 р. в час в зависимости от объема работ), а также может быть организована специалистами из штата автовокзала, для этого требуется всего лишь квалификация специалиста по 1С.


Сколько стоит Ваш продукт? Какие есть типы «пакетов», лицензий и так далее? Уточните для типовых автовокзалов: небольшого, среднего, крупного. Как Вы зарабатываете на своем продукте?

Стоимость нашего решения для установки на ресурсах предприятия состоит из 2х частей: первая – это стоимость 1С, вторая – это стоимость нашей конфигурации. Стоимость определяется количеством лицензий, необходимых для обеспечения работы заданного количества пользователей. В свою очередь, в нашем решении имеются продукты, не требующие лицензий 1С (рабочее место кассира на Qt, мобильное рабочее приложение), они лицензируются отдельно. Пользователей можно разделить на 2 типа: те, что работают в интерфейсе 1С (диспетчеры, руководители, старшие кассиры) и те, что работают в отдельных приложениях (рабочее место кассира, компонента для сайта, мобильное приложение и т.д.), это различие и определяет тип лицензий, необходимых для приобретения, их можно назвать лицензиями «1С пользователя» и «Специального пользователя». Все лицензии можно приобрести пакетами по 1, 5, 10, 20 и 50 штук, чем больше лицензий в пакете, тем ниже стоимость каждой.


Наименование

Цена

Базовая поставка (лицензия на 1 рабочее место)

27 000 р.

Лицензия на 5 рабочих мест «1С пользователь»

48 600 р.

Лицензия на 10 рабочих мест «1С пользователь»

93 150 р.

Лицензия на 20 рабочих мест «1С пользователь»

175 500 р.

Лицензия на 50 рабочих мест «1С пользователь»

421 200 р.

Лицензия на 1 рабочее место «Специальный пользователь»

7 000 р.

Лицензия на 5 рабочих мест «Специальный пользователь»

24 000 р.

Лицензия на 10 рабочих мест «Специальный пользователь»

46 000 р.

Лицензия на 20 рабочих мест «Специальный пользователь»

87 000 р.

Лицензия на 50 рабочих мест «Внешнее подключение»

210 000 р.


Цены на вариант SaaS подключения пока находятся в разработке и будут составлять примерно 900 р. за «1С пользователя» и 450 р. за «Специального пользователя» ежемесячно.

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


Чего сейчас России не хватает для внушительного роста уровня автоматизации автовокзалов? Каков Ваш «месседж» – послание для читателей?

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

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

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


Второе интервью ООО «ИТТ»

На вопросы отвечал директор ООО «ИТТ» Соловьев Сергей, г. Ижевск, продукт «Авибус: Управление автовокзалами».


Как создаются продукты такого уровня сложности? Что для этого необходимо: какие знания, ресурсы, специалисты, фреймворки и технологии?

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


Какова роль Open source в Вашем продукте? Насколько сильно в Ваш продукт интегрированы бесплатные технологии с открытым кодом?

Наше решение доступно для использования в среде Open source операционной системы Linux. Также система поддерживает Open source базу данных PostgreSQL, есть и Android приложение для планшетов. В нашей разработке некоторые модули ядра полностью закрыты, все оставшиеся – открыты и могут быть изменены программистами заказчика. Закрытые модули довольно сложны и не требуют частых изменений. В целом, я смотрю положительно на открытый код.


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

Как уже отмечалось ранее, большое преимущество в плане безопасности дает нам использование готовой платформы 1С. Большинство вопросов решаются как раз функционалом платформы, кроме того, существует огромное сообщество пользователей и разработчиков 1С, и все, что этим сообществом наработано, применимо в нашем продукте.

Что касается защиты персональных данных, платформа 1С сертифицирована ФСТЭК и соответствует закону о защите персональных данных. Для удовлетворения всех требований законодательства необходимы дополнительные действия со стороны автовокзалов, например, обеспечить физическую безопасность серверной комнаты.

Насчет шифрования отмечу, что в стандартных конфигурациях 1С данные не шифруются, но существует разграничение прав доступа, и, кроме того, системой фиксируются все события, связанные с обращением к персональным данным. Также предусмотрена возможность настраивать резервирование данных средствами СУБД. Во второй редакции у нас планируется внедрение механизма резервирования данных через интернет с определенной периодичностью, то есть в случае повреждения основной базы данных резервная копия будет актуальна практически полностью за исключением данных за несколько последних минут. Может пропасть, например, всего 5-6 билетов, и особенного вреда не будет.

В целом, если рассматривать сценарии взлома, то риск, конечно, есть всегда. При самом негативном сценарии автовокзал может полностью остановить свою деятельность. Но, как правило, у автовокзалов остается возможность использовать бланки строгой отчетности, то есть продавать по-старинке, даже если основная система встала. Правда потом придется вручную внести данные в систему. На практике такого не было ни разу, насколько я знаю, но мне известен реальный случай атаки в Самаре. Это была хакерская атака типа «отказ в обслуживании» (DDoS), и, насколько мне известно, вокзал справился.


Какие технические новинки планируется реализовать в системе в ближайшем будущем (ближайшая версия), а какие в среднесрочной перспективе (несколько лет)? Как могут эволюционировать АСУ для автовокзалов в долгосрочной перспективе (с позиции "научной фантастики", например)?

Ближайшее будущее я вижу так: на вокзалах не будет кассиров, будут лишь терминалы. Терминалы уже созданы, но дело в том, что до сегодняшнего дня в основном используется труд кассиров. Несомненно нас ждет объединение всех вокзалов в единую среду, в единую сеть. Я думаю, это произойдет лет через пять, не раньше. Систем будет много разных, как и сейчас, но все они будут объединены, скорее всего будет существовать единый сайт, как у РЖД, где можно получить информацию по рейсам и купить билет для поездок по всей стране. Возможно, такой сайт сделает «Яндекс», но для этого сначала должна быть подготовлена информационная инфраструктура на автовокзалах.


Как технически реализовать объединение нескольких систем в единое информационное поле для удобства пассажиров? Какие технологии для этого потребуются, какие знания, какие вычислительные мощности? Какие сценарии объединения возможны? Каково Ваше послание коллегам – разработчикам других систем?

Наш лейтмотив – дать возможность вокзалам выбирать. Пусть вокзалы сами решают, как им автоматизироваться. Например, одни могут смотреть в сторону «облачных» решений, другие – на вариант приобретения продукта для установки его на свои собственные серверы. В целом, сценарии объединения могут быть разные, но я считаю, что, скорее всего, сеть будет частично децентрализованной, а какая-то информация будет храниться на центральных серверах над-системы. В целом, считаю, что менталитет крупных вокзалов пока что не ушел в сторону «облаков». Крупные игроки как раз стараются держать данные именно на своих серверах, самостоятельно все это обслуживать, защищать и так далее. А как будет в итоге – покажет время.


Интервью ижевского автовокзала

На вопросы отвечал сотрудник центрального автовокзала г. Ижевска Дмитрий Корняев, установлен продукт «Авибус: Управление автовокзалами» от ООО “ИТТ”.


Сколько человек обслуживают АСУ на Вашем автовокзале и какие у них должности и навыки?

В данный момент 4 человека обслуживают 25 автовокзалов и автостанций. Начальник отдела обеспечивает бесперебойное функционирование основных бизнес-процессов (Автоматизированная система продажи билетов на платформе 1С Предприятие). Инженер отдела обслуживает Windows серверы, Active Directory, MS-SQL и т.п. Сетевой администратор – все сетевое оборудование, *nix-серверы, сайт, почту, прокси и т.п. Инженер отдела (эникейщик) осуществляет мелкое обслуживание пользователей, оргтехники. Все сотрудники оказывают техническую поддержку пользователей.


Сколько компьютерной техники занято под АСУ на Вашем автовокзале?

Центральный автовокзал (центральный и самый крупный узел) использует 21 единицу. Из них 6 – серверы. Все распределенные узлы – 40 единиц. Из них 17 – сервер/рабочее место.


Как влияют сбои (свет, интернет) на работоспособность АСУ?

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

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


Чего Вам не хватает и хотелось бы еще от АСУ?

Хотелось бы повысить уровень квалификации конечных пользователей системы. Мы за планомерное развитие IT-сферы, в том числе развитие и интеграцию дополнительных сервисов (терминалы, мобильные технологии и т.д.).Также не хватает интеграции с прилегающими профильными АСУ.


Основное интервью «КВЦ-Сервис»

На вопросы отвечал заместитель директора ООО «КВЦ-Сервис», г. Тула, продукт «Автоматизированная система продажи билетов».


Как вы видите историю появления АСУ автовокзалами, когда появились первые решения и где? Какова история создания Вашего продукта, этапы его развития?

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

В 1990 году аналогичная система была внедрена на автовокзале в г. Калуге. В 1995 году была разработана и внедрена сначала в Туле, а затем в Калуге, новая система, выполненная на базе персональных компьютеров. В качестве серверной ОС использовалась Novell NetWare 3.12, на рабочих станциях устанавливалась MS DOS 6.22. В 1997 году, в связи с изменением в Законодательстве РФ, в системе стали использоваться контрольно-кассовые машины: Элвес-10-03Ф, ЭКР 2102Ф, Ока. И система начала устанавливаться на новых объектах: автовокзалах Рязани, Орла, Курска, Брянска.

В 1999 году в системе стали использоваться фискальные регистраторы. Расширилась и география установленных систем.

В 2003 году появилась гибридная версия, в которой часть АРМ (автоматизированных рабочих мест) была реализована по старой схеме (Novell NetWare 3.12 и MS DOS 6.22), а часть АРМ функционировали под управлением Windows. Такая система была установлена на автовокзале г. Санкт-Петербурга. Немного позднее появилось приложение для сети агентств, также продающих автобусные билеты.

А в 2005 году появилась новая версия – 8.01, полностью выполненная для работы под Windows. Далее были переводы автовокзалов на 8-ю версию, постоянные модернизации системы (последний релиз системы имеет индекс 8.2.5.32), объединение автовокзалов в коллективную систему продажи билетов, разработка различных сервисов и, в том числе, для работы через интернет. И, конечно, внедрение системы на новых объектах.


Чего еще не умеют современные АСУ? Будущее АСУ – каким оно Вам видится? И отдельно – будущее Вашего продукта? Каковы ближайшие и стратегические перспективы? Что Вы планируете предложить в ближайшей новой версии продукта?

Мы не занимались сравнительным анализом автоматизированных систем различных разработчиков. Этот вопрос лучше задать тем автовокзалам, которые работали с различными системами. Если автовокзал использует ту или иную систему для работы, значит, система имеет право на существование.


Как государство помогает законодательно, налогами, фондами, дотациями, программами и другими путями внедрению АСУ для автовокзалов и росту автоматизации транспорта в России? И какова практика в других странах?Этот процесс в России протекает стихийно.

Никакой государственной программы развития сети автоматизированных автовокзалов нет.


Как Вы взаимодействуете с другими производителями АСУ? Нужно ли это вообще, чтобы разные продукты работали в единой системе, между ними были бы налажены «мосты»? И как именно Вы видите возможную интеграцию?

Можно рассматривать два варианта реализации Единой системы продажи билетов. Первый – Единая система продажи автобусных билетов как аналог системы, используемой в РЖД, то есть возможность покупки любых автобусных билетов на любых автовокзалах. Это не самая удачная идея. Такую продажу имеет смысл организовывать только между теми автовокзалами, между которыми существует стабильный пассажиропоток, то есть у пассажиров есть спрос на обратные билеты. Именно здесь и имеет смысл объединять системы различных разработчиков, используя протоколы обмена данными и шлюзы. Например, мы видим перспективу сотрудничества с разработчиками автоматизированных систем продажи билетов, установленных в Вологодской и Липецкой областях. Это «приграничные» области с регионами, использующими нашу автоматизированную систему.

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

Второй вариант – создание единого ресурса по продаже автобусных билетов в режиме on-line. На этом ресурсе может быть размещена информация с различных автовокзалов, автоматизированных системами различных разработчиков. Это и есть фактически Единая система продажи билетов, так как пассажир, посетивший такой ресурс, может купить нужные билеты на автобусы, отправляющиеся с различных автовокзалов.

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


Какие технологические решения Вы используете – какие языки программирования, операционные системы, базы данных, веб-серверы и так далее? Используете ли Вы разработки класса Open source под свободными лицензиями? Интегрированы ли в Ваше решение мобильные приложения, терминалы самообслуживания и веб-ресурсы?

Автоматизированная система продажи билетов реализована в среде разработки Delphi. В качестве базы данных используется бесплатная СУБД Firebird. В качестве серверных ОС могут использоваться Windows 2008, 2012 Server или Linux – что ближе заказчику. Клиентские рабочие станции работают под Windows от XP до 8. Все интернет-приложения выполнены на PHP, веб-сервер – Apache. Для удобства пассажиров с системой интегрирован интернет-магазин «Мир электронных билетов», мобильное приложение находится в стадии разработки.


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

Внедрение системы на маленьком автовокзале занимает 2-3 дня, на большом – до 7 дней. Сначала формируется база данных перевозок, выполняемых автовокзалом, и почти параллельно начинается обучение. Обучение производится по категориям сотрудников, обычно – два двухчасовых занятия. Далее – установка оборудования по рабочим местам и ввод системы в эксплуатацию. После запуска системы в течение двух дней – оказание оперативной помощи на объекте заказчика. Дальнейшее сопровождение производится через удаленный доступ и телефонные консультации.


Сколько стоит Ваш продукт? Какие есть типы «пакетов», лицензий и так далее? Уточните для типовых автовокзалов: небольшого, среднего, крупного. Как Вы зарабатываете на своем продукте?

У нас есть такое понятие – базовая стоимость установки одного рабочего места – 30 000 рублей. Базовая стоимость используется для экспресс-оценки стоимости внедрения. А затем идут скидки: за объем внедрения (чем крупнее объект, тем больше скидка), для постоянных клиентов, которые автоматизируют второй и последующие объекты. Для многих клиентов размер скидки может достигать до 40% от базовой стоимости. Кроме того, часто используется вариант оплаты с рассрочкой до 3 и более месяцев.

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

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

Стоимость сопровождения начинается от 3 000 рублей в месяц и зависит от количества автоматизированных объектов у заказчика.

Интервью санкт-петербургского автовокзала

На вопросы отвечал сотрудник санкт-петербургского автовокзала Елена Савченко, установлена система «Автоматизированная система продажи билетов» от “КВЦ-Сервис”.


Сколько человек обслуживают АСУ на Вашем автовокзале и какие у них должности и навыки?

Систему обслуживают два человека. Первый – администратор БД. Должность – главный специалист отдела программирования УИТ. Навыки – знания принципов работы СУБД + программирование. Второй – системный администратор. Должность – главный специалист отдела системного администрирования. Навыки работы с ЛВС. В принципе, для работы с тульской системой особых навыков не требуется.


Сколько компьютерной техники занято под АСУ на Вашем автовокзале?

24 рабочих места + сервер БД + сетевое хранилище.


Как влияют сбои (свет, интернет) на работоспособность АСУ?

Сбои по напряжению нивелируются установленным мощным ИБП на сервере. Сделаны соответствующие настройки: при длительном отсутствии напряжения в электросети при разряде батарее более 50% от ИБП идет команда на сервер и выполняется штатный shutdown сервера. После подачи напряжения заряжается батарея и при заряде более 50% посылается команда на сервер start. 10 минут загрузки, и можно работать. Такая ситуация крайне редкая – 1 раз в 2 года, в остальное время кратковременные сбои не влияют на работу системы.

При отсутствии интернета тульская система продолжает работать со своей БД, кассиры только не могут продавать билеты с других автовокзалов, а билеты на рейсы АВ СПб – пожалуйста. Вопросы по восстановлению интернета решаются в соответствии с договором с провайдером в течение 2-х часов, при этом кассиру не нужно перезагружать компьютер, чтобы подключиться к интернету.


Чего Вам не хватает и хотелось бы еще от АСУ?

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


Основное интервью ООО «Артмарк»

На вопросы отвечал заместитель директора ООО «Артмарк» Константин Измалков, г. Барнаул, продукт «Е-автовокзал».


Как вы видите историю появления АСУ автовокзалами, когда появились первые решения и где? Какова история создания Вашего продукта, этапы его развития?

В прошлом все было государственным и никто шибко в эффективности автовокзалов не разбирался. И первоначально все велось на бумаге – продажа билетов, весь документооборот. Этот прототип продажи билетов перешел в автоматизированные системы, которые начали создаваться с распространением персональных компьютеров. Тогда же, собственно, появилась сама возможность заниматься автоматизацией. Потому что ранее, фактически, и речи не могло быть об автоматизации более мелких объектов, пока компьютеры занимали целые помещения.

Одна из первых программ для автовокзалов была сделана КВЦ. У нас же была потребность коммерческой организации. Наш первый вокзал тогда только акционировался и стал коммерческой структурой, перед ним встали вопросы зарабатывания денег и эффективности труда. Поэтому они заинтересовались автоматизацией, а мы продукт для них и разработали. Наша первая версия была создана в 1995 году, опираясь не те технологии, которые тогда были актуальны. В 2000 году вышла новая версия продукта, которая стала опираться на современные технологии. Таким образом наша система выросла с одного вокзала, и мы начали внедрять ее в другие места.


Что из себя представляют АСУ для автовокзалов сегодня? В технологическом смысле – что они умеют? Как Вы позиционируете по функционалу свою АСУ? Чем она отличается от остальных решений? Как Вы видите своего заказчика?

Современная АСУ – это продажа билетов всеми возможными способами. Через интернет, через терминалы, мобильные телефоны и планшеты. Плюс чтобы пассажир всегда получал полноценную информацию и смог бы потом эффективно воспользоваться этой информацией и совершить, собственно, поездку. Мы считаем своим конкурентным преимуществом то, что мы не делаем закрытую систему, пусть она и закрыта с точки зрения кода. У нас есть открытые протоколы, которые позволяют сотрудничать с другими системами. Все, кто пользуются нашей автоматизацией, могут, например, соединяться с другими системами. При этом наш идеал заказчика – тот, который понимает, что ему надо. Ну и, соответственно, мы еще любим заказчиков, которые эффективно пользуются тем, что уже нами в продукте создано.


Чего еще не умеют современные АСУ? Будущее АСУ – каким оно Вам видится? И отдельно – будущее Вашего продукта? Каковы Каковы ближайшие и стратегические перспективы? Что Вы планируете предложить в ближайшей новой версии продукта?

Мы в следующую версию продукта закладываем возможности, которые позволят объединить несколько разных автовокзальных систем в глобальную систему. В любом случае запрос на это есть и со стороны автовокзалов, и со стороны пассажиров. Есть на это как бы социальный заказ, который толкает нас именно к разработке подобного функционала. При этом понятно, что все вокзалы никогда не перейдут на какой-то один продукт, будет смешанная система. Поэтому мы на это и ориентируемся и закладываем интеграцию с другими системами, которые разработаны другими компаниями. Мы этим занимаемся уже три года, релиз планируем в мае 2014. При этом мы считаем, что ожидать общей же системы можно лишь тогда, когда у других разработчиков возникнет понимание, что нам всем надо объединяться. При этом в каких-то сферах мы остаемся конкурентами, а в чем-то работаем вместе. И никто не покушается на те системы, которые работают на вокзалах уже сейчас. И возможно все придет к тому, что те продукты, которые не будут взаимодействовать с другими, они просто отомрут. А те, которые будут готовы сотрудничать с другими системами, они как раз и будут развиваться.


Какие страны лидируют сегодня в автоматизации транспорта? На каком «месте» находится Россия?

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


Как государство помогает законодательно, налогами, фондами, дотациями, программами и другими путями внедрению АСУ для автовокзалов и росту автоматизации транспорта в России? И какова практика в других странах?

Скорее всего, в других странах навряд ли государство помогает. Потому что в основном частный капитал сам по себе эффективно работает. У нас же половина вокзалов принадлежит государству, а государство – это неэффективный собственник. В ближайшее время возможна дальнейшая приватизация автовокзалов. Тогда рынок будет развиваться. В общем, сначала надо создать рынок, который будет жить по своим рыночным правилам, а государство при этом не будет мешать. Сейчас у нас в России скорее наблюдается борьба государства и частного сектора. И в этой борьбе сжигается много ресурсов, которые могли бы быть направлены на развитие отрасли.


Как Вы взаимодействуете с другими производителями АСУ? Нужно ли это вообще, чтобы разные продукты работали в единой системе, между ними были бы налажены «мосты»? И как именно Вы видите возможную интеграцию?

Мы очень активно наладили взаимодействие с системой РАЙС (прим. редактора – сегодня компания «РАЙС» переименована в ООО «ИТТ», выпускаемый продукт называется «Авибус: Управление автовокзалами»). Работаем с другими системами локального характера. Вообще есть системы, которые закрываются сами в себе. Это не продуктивно, как я считаю. Неизбежное будущее – объединение. Рыночный подход предусматривает удовлетворение потребностей и автовокзалов, и пассажиров. Закрытые системы связывают развитие автовокзалов, которые не могут взаимодействовать с другими участниками рынка. Думаю, что на объединение уйдет еще 2-3 года.


Какие технологические решения Вы используете – какие языки программирования, операционные системы, базы данных, веб-серверы и так далее? Используете ли Вы разработки класса Open source под свободными лицензиями? Интегрированы ли в Ваше решение мобильные приложения, терминалы самообслуживания и веб-ресурсы?

Основной язык – С++, начинаем использовать Java, используем PHP. Базы данных – Oracle. Операционные системы – все, которые поддерживает Oracle. Операционные системы рабочих станций – Windows. Активно используем продукты Open source, например, для реализации модуля системы отчетов – JasperServer. Еще активно используем OpenVPN. Порядка 50% технологий у нас как раз на базе Open source.


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

Внедрение для маленького автовокзала – от 4 часов. Среднего – несколько дней. Большого – от месяца и до трех. Первый этап – понимание бизнес-процессов вокзала, куда мы планируем установить систему, и оптимизация бизнес-процессов, чтобы вокзал мог безболезненно развернуть систему. Возможны на этом этапе доработки системы с нашей стороны. Далее – установка рабочих мест. В среднем для вокзала с пассажиропотоком в 10 000 пассажиров в день – порядка недели занимает развертывание. Далее – обучение. После этого договариваемся о поддержке, которую мы будем оказывать вокзалу в дальнейшем. Например, консультации, какие-то моменты по дополнительным настройкам системы.


Сколько стоит Ваш продукт? Какие есть типы «пакетов», лицензий и так далее? Уточните для типовых автовокзалов: небольшого, среднего, крупного. Как Вы зарабатываете на своем продукте?

Мы продукт передаем бесплатно. За него денег не берем. Мы зарабатываем на дальнейшем обслуживании. Стоимость – от 2 до 30 тыс. р. в месяц за обслуживание.


Чего сейчас России не хватает для внушительного роста уровня автоматизации автовокзалов? Каков Ваш «месседж» – послание для читателей?

У нас в России все больные с безопасностью. И именно это оттягивает на себя 50% тех бюджетов, которые можно было бы заработать. Мы обвешиваем весь вокзал камерами, ставим где только можно всевозможные рамки, делаем бронированные автобусы. По сути мы с этой безопасностью исключаем из экономики страны очень много денег, которые в ближайшее время не позволяют создать ничего другого хорошего кроме самой безопасности. Скоро будем ездить на танках и 10 человек охраны. Раньше вот не требовали паспорт для покупки билета, сейчас требуют. И человек уже как бы подумает, ехать ему или не ехать на автобусе, например, на межгород. Люди кооперируются и едут на личных машинах. Из-за этого рынок недополучает те финансы, которые могли бы помочь развиваться. Это конфликт рынка и государства. Это подрывает экономику страны. И это оказывает прямое влияние и на разработку автоматизированных систем.

В данном случае у нас государство не может быть локомотивом всех инноваций. Примеры тому – «Сколково», «Роснано». Вроде с этого года сделали для организаций, которые занимаются разработкой программного обеспечения, какие-то льготы. Но там тоже свои нюансы. Поэтому хотелось бы минимизировать вмешательство государства посредством «правильных» законов. Это приведет к стабильности и позволит сфере развиваться.


Интервью барнаульского автовокзала

На вопросы отвечал ведущий специалист отдела перевозок барнаульского автовокзала Ирина Красильникова, установлен продукт «Е-автовокзал» от ООО “Артмарк”.


Сколько человек обслуживают АСУ на Вашем автовокзале и какие у них должности и навыки?

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


Сколько компьютерной техники занято под АСУ на Вашем автовокзале?

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


Как влияют сбои (свет, интернет) на работоспособность АСУ?

У нас есть дизельный генератор на случай отключения света. Есть и резервный канал интернета.


Чего Вам не хватает и хотелось бы еще от АСУ?

Хотелось бы, чтобы все вокзалы объединялись в единую сеть. Надо понимать, что это было бы очень полезно и удобно для пассажиров.


Основное интервью ЗАО «ТАИС»

На вопросы отвечал коммерческий директор ЗАО «ТАИС» Владимир Ловский, г. Москва, продукт TAIS AUTO.


Как вы видите историю появления АСУ автовокзалами, когда появились первые решения и где? Какова история создания Вашего продукта, этапы его развития?

Вначале мне бы хотелось уточнить, что мы говорим не об АСУ автовокзалами в целом, а только о системах продажи перевозок на автобусных междугородных маршрутах. Для таких систем можно применить сокращение АСПБ (автоматизированная система продажи билетов).

Первая АСПБ под названием «Автовокзал» была внедрена в Московском Центральном автовокзале на Щелковской в 1989 году компанией ЗАО ТАИС, тогда еще кооперативом. Эта система стала первой собственной разработкой ТАИС, коллектив которой вырос из группы разработчиков Общесоюзной системы бронирования авиабилетов «Сирена-2».

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

Единственным принципиальным отличием от современных систем резервирования в авиации было то, что продажа в каждом ЦОД осуществлялась только на прямые рейсы, отправляющиеся из данного транспортного узла. Чтобы продать обратную перевозку, кассир должен был «войти» в ЦОД, контролировавший пункт возвращения, и в нем купить обратный билет. Ограниченные возможности каналов связи не позволяли создать единый на всю страну ЦОД, через который бы продавались все авиационные перевозки. Именно поэтому к 1995 году количество центров Сирены-2 достигло пятидесяти, после чего она была заменена более современной системой «Сирена-2.3».

АСПБ «Автовокзал» также имела ЦОД с подключенной сетью терминалов, впоследствии замененных на компьютеры. ЦОД системы размещался в здании Центрального автовокзала на Щелковской. Компьютеры кассиров (будем их также называть по традиции терминалами) размещались, в основном, в этом же здании. Кроме того, некоторое количество терминалов было установлено в других автовокзалах Москвы для продажи билетов на маршруты только из Центрального автовокзала.

Поскольку ТАИС до начала 2000-х продолжал развивать многоцентровую архитектуру системы «Сирены-2.3» – наследницы «Сирены-2», то разработчики прошли все этапы развития данной технологии. На последнем этапе существования этой системы центры «Сирены-2.3» взаимодействовали между собой автоматически, обмениваясь необходимой информацией о наличии мест, расписании и тарифах. А агент мог обращаться только в свой ЦОД, продавая при этом ресурсы, размещенные в других центрах.

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

В 10-е годы текущего столетия стала очевидна неэффективность многоцентровой архитектуры, так как с появлением электронного билета и продаж в режиме онлайн через веб-сайты агентств и авиакомпаний сложность программного обеспечения ЦОД «Сирены-2.3» возросла многократно. С другой стороны, качество каналов связи и Интернета как передающей среды выросло настолько, что появилась возможность собрать ресурсы всех ЦОД в один.

Заметим, что именно по моноцентровой схеме сегодня продают свои перевозки авиакомпании во всем мире. Они выбирают одну из систем резервирования, размещают в ней ресурсы мест и открывают к ним доступ агентам через различные каналы дистрибуции. Например, «Аэрофлот» размещает свои ресурсы в системе Sabre Sonic, а S7 в системе Gabriel. Обе системы находятся в Соединенных Штатах.

Поэтому к 2005 году ТАИС внедрил новую моноцентровую многофункциональную систему TAIS Airline Solution для авиации, а в 2006 заменил старую систему «Автовокзал» на новую TAIS AUTO. Центр обработки данных TAIS AUTO был перенесен в специализированный Московский дата-центр. А терминалы кассиров и администраторов установлены на всех Московских автовокзалах, входящих в юрисдикцию Мострансавто, также частично в Подмосковье.

В настоящее время TAIS AUTO может продавать перевозки на пригородные и междугородные маршруты Мострансавто с любого терминала, обслуживает от 6 до 8 миллионов пассажиров в год и вполне способна взять на себя продажу перевозок не только Мострансавто, но и автобусных перевозок по всей России. Для подключения к системе новых автовокзалов и автостанций не требуется специальное техническое оснащение и технический персонал на каждом объекте. Достаточно связать рабочие места кассиров по Интернету с ЦОД TAIS AUTO и провести обучение нового персонала.


Что из себя представляют АСУ для автовокзалов сегодня? В технологическом смысле – что они умеют? Как Вы позиционируете по функционалу свою АСУ? Чем она отличается от остальных решений? Как Вы видите своего заказчика?

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

Такая система является достаточно простой и удобной для автоматизации одного автовокзала. Однако она плохо подходит в следующих случаях:

  1. Требуется разместить ресурсы компании-перевозчика по всей ее маршрутной сети, а не в отдельном автовокзале.
  2. Необходимо создать единый Интернет-ресурс в рамках региона (области, края, республики) с целью онлайн продаж автомобильных перевозок. В этом случае возникает сложнейшая задача синхронизации ресурсов разных систем. Она многократно усложняется, если это системы разных разработчиков.
    Даже создание простого справочного веб-сайта, отражающего не только более-менее постоянное расписание и тарифы, но и наличие мест, уже превращается в сложную техническую задачу.
  3. Перед статистическими органами региона ставится задача контролировать процесс продажи перевозок в режиме, приближенном к онлайн. Можно передавать статистическую информацию в центр из систем, установленных на автовокзалах региона, однако в этом случае потребуется создание центральной учетной системы, способной взаимодействовать с системами, имеющими разные интерфейсы и форматы данных.

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

В завершение этой мысли отметим, что несколько лет назад Минтранс РФ собирал совещание представителей автовокзалов и разработчиков АСУ по продаже билетов, на котором разработчики взяли на себя обязательство объединить свои локальные системы в единую многоцентровую систему. К сожалению, как мы и предупреждали на том совещании, из этой «затеи» пока ничего не вышло.

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

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

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

Другое дело, если бы автовокзалы отказались от агентской функции, а перевозчики передали бы ресурсы в единую моноцентровую систему, обслуживающую один или несколько регионов. К сожалению, сегодня это может быть осуществлено только властью вышестоящих органов, скорее всего, на уровне Минтранса РФ. На наш взгляд, незаинтересованность автовокзалов и руководства отрасли в изменении существующего порядка вещей является основной причиной отставания коммерческих АСУ на автомобильном транспорте.

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


Чего еще не умеют современные АСУ? Будущее АСУ – каким оно Вам видится? И отдельно – будущее Вашего продукта? Каковы ближайшие и стратегические перспективы? Что Вы планируете предложить в ближайшей новой версии продукта?

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

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

Однако полноценное внедрение ЭБ в регионе требует организации комплексных схем продаж, о которых мы говорили выше. А для такой разработки нужны определенные инвестиции и также понимание того, что участники рынка автоперевозок реально заинтересованы в развитии систем и технологий, и что наша система найдет новых пользователей. К сожалению, мы не получили до сих пор заказа на внедрение технологии ЭБ со стороны своего основного пользователя – Мострансавто. При этом ЗАО «ТАИС» полностью обеспечено заказами на разработку современных средств продажи авиационных перевозок со стороны авиакомпаний и трэвел-агентств.


Какие страны лидируют сегодня в автоматизации транспорта? На каком «месте» находится Россия?

Если под «автоматизацией транспорта» понимать, все-таки, предмет нашего разговора, а именно автоматизацию продажи перевозок, или коммерческую деятельность отрасли, то следует говорить о каждом виде транспорта отдельно.

Автоматизация коммерческой деятельности на авиационном транспорте происходит на внегосударственном уровне силами перевозчиков (авиакомпаний) и трэвел-агентов. Регулятором здесь выступают международные организации ATA (США) и IATA (остальной мир). Россия здесь мало в чем отстает от других стран, за исключением доли онлайн продаж авиаперевозок, однако, это направление также активно развивается.

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

Как государство помогает законодательно, налогами, фондами, дотациями, программами и другими путями внедрению АСУ для автовокзалов и росту автоматизации транспорта в России? И какова практика в других странах?

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

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


Как Вы взаимодействуете с другими производителями АСУ? Нужно ли это вообще, чтобы разные продукты работали в единой системе, между ними были бы налажены «мосты»? И как именно Вы видите возможную интеграцию?

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

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

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

Первый уровень – действующие сегодня системы перевозчиков и автовокзалов, которые в авиационной среде принято называть «инвенторными». Инвенторные системы хранят ресурс перевозчиков и предоставляют к нему доступ собственным агентам (в данном случае кассирам автовокзалов).

Второй уровень – единая «дистрибутивная» или распределительная система (РС), обслуживающая агентов и взаимодействующая с инвенторными системами по единому интерфейсу. Именно эта система способна будет поддержать в дальнейшем все виды агентской деятельности, включая онлайн продажи.

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

ТАИС готов участвовать в данном проекте, взяв на себя его техническую реализацию.


Какие технологические решения Вы используете – какие языки программирования, операционные системы, базы данных, веб-серверы и так далее? Используете ли Вы разработки класса Open source под свободными лицензиями? Интегрированы ли в Ваше решение мобильные приложения, терминалы самообслуживания и веб-ресурсы?

Все эти решения в той или иной степени применяются в наших разработках для авиации, однако TAIS AUTO построена по классическому принципу. Операционная система для серверов ЦОД – Unix, СУБД – Sybase, язык программирования С++. Клиентские приложения (терминалы) реализованы в среде Windows.


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

Внедрение системы на любом автовокзале сводится к развертыванию клиентских программ на рабочих местах администраторов и кассиров и к подключению этих рабочих мест к ЦОД. Другими словами, сроки внедрения полностью зависят от заказчика. ТАИС осуществляет эксплуатацию ЦОД в режиме 24*7 и оказывает консультации пользователям.


Сколько стоит Ваш продукт? Какие есть типы «пакетов», лицензий и так далее? Уточните для типовых автовокзалов: небольшого, среднего, крупного. Как Вы зарабатываете на своем продукте?

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

Услуги системы TAIS AUTO также оплачиваются через количество проданных минус возвращенных билетов за отчетный период (месяц). Терминалы предоставляются бесплатно, независимо от их количества.

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

Чего сейчас России не хватает для внушительного роста уровня автоматизации автовокзалов? Каков Ваш «месседж» – послание для читателей?

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


Второе интервью ЗАО «ТАИС»

На вопросы отвечал коммерческий директор ЗАО «ТАИС» Владимир Ловский, г. Москва, продукт TAIS AUTO.


Как создаются продукты такого уровня сложности? Что для этого необходимо: какие знания, ресурсы, специалисты, фреймворки и технологии?

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

Само программирование может вестись в разных системах и на разных языках. Все зависит от объемов продаваемых перевозок и, соответственно, от потоков запросов в систему.


Какова роль Open source в Вашем продукте? Насколько сильно в Ваш продукт интегрированы бесплатные технологии с открытым кодом?

Мы используем только базовый Unix. Все остальные системы – профессиональные и покупные, например, база данных Sybase. Сама наша система полностью написана нашей организацией и не использует чужие разработки.


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

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

Основная защита направлена на сохранность информации в центральной базе данных. Здесь основной защищаемой информацией являются паспортные данные пассажиров.

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

Какие технические новинки планируется реализовать в системе в ближайшем будущем (ближайшая версия)? Какие в среднесрочной перспективе (несколько лет)? Как могут эволюционировать АСУ для автовокзалов в долгосрочной перспективе (с позиции "научной фантастики", например)?

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


Как технически реализовать объединение нескольких систем в единое информационное поле для удобства пассажиров? Какие технологии для этого потребуются, какие знания, какие вычислительные мощности? Какие сценарии объединения возможны? Каково Ваше послание коллегам – разработчикам других систем?

Это слишком сложный вопрос для одного простого ответа (я имею в виду сценарии объединения систем). Частично я уже отвечал на него в предыдущем письме. Кроме того, можно прочитать соответствующую статью на нашем сайте http://tais.ru/press/articles/3551/.


Интервью щелковского автовокзала

На вопросы отвечал сотрудник “Мострансавто”, в ведении которого находится и щелковский автовокзал г.Москвы, Шитов Евгений, установлен продукт TAIS AUTO от ЗАО “ТАИС”.


Сколько человек обслуживают АСУ на Вашем автовокзале и какие у них должности и навыки?

Три программиста выполняют ведение базы данных. Их задачи: заполнение базы, ведение расписания, рейсовой, маршрутов, тарифов.


Сколько компьютерной техники занято под АСУ на Вашем автовокзале?

У нас девять касс, администратор, справочная – по компьютеру. Плюс у нас прокси-сервер для интернета. А все остальное у нас в ЦОДе, мы удаленно подключаемся к серверу. Главное, чтобы был интернет.


Как влияют сбои (свет, интернет) на работоспособность АСУ?

Интернет – у нас два канала. Если один неисправен, то работает резервный. Чтобы два канала не работало, такого у нас еще не было. Поэтому работоспособность – 24 часа в сутки. Есть бесперебойники, чтобы как-то реагировать на отключение света. Есть, на самый крайний случай, возможность продавать билеты вручную через кассовый аппарат, если совсем отключили свет и надолго. Это, конечно, не очень удобно, потому что нет аналитики, отчетности. Нужно все потом вручную вбивать в базу.


Чего Вам не хватает и хотелось бы еще от АСУ?

Естественно, хотелось бы продаж билетов через интернет и удаленных рабочих мест для агентов по продажам билетов. Это была бы дополнительная прибыль. Например, продажи через посредников, допустим, "Евросеть". Потом, не хватает интеграции с ж/д и авиацией, чтобы расширить круг продажи, хотелось бы этого тоже. Чтобы можно было в самых различных кассах покупать и автобусные билеты.


Основное интервью SWD Factory

На вопросы отвечал председатель правления SWD Factory д.т.н. Борис Кадиш, г. Рига (Латвия), продукт BusTicketPro.


Как вы видите историю появления АСУ автовокзалами, когда появились первые решения и где? Какова история создания Вашего продукта, этапы его развития?

Наша первая система продажи автобусных билетов и учета рейсов BalticLines была разработана в 2003 году по заказу Рижского Международного автовокзала. В настоящее время к системе подключены все 33 автовокзала Латвии. В 2009 году разработана новая система по заказу крупнейшего автоперевозчика Литвы. Система внедрена в Вильнюсском и еще 5 автовокзалах Литвы. В 2011 году разработана новая система BusTicketPro. В 2012 система внедрена в Псковавтотранс, к системе подключены 25 автовокзалов, автостанций и линейных сооружений Псковской области. В формате SaaS систему использует крупнейший Латвийский перевозчик NORDEKA, а также Шведский перевозчик Travelshop.


Что из себя представляют АСУ для автовокзалов сегодня? В технологическом смысле – что они умеют? Как Вы позиционируете по функционалу свою АСУ? Чем она отличается от остальных решений? Как Вы видите своего заказчика?
Функции нашей системы:   
  • Продажа билетов (кассы, агентства, терминалы самообслуживания);
  • Продажа билетов в интернете как с собственных сайтов перевозчиков/автовокзалов, с    сайтов билетных агенств, так и с агрегированного сайта системы BusEurope.eu;
  • Ведение маршрутов, расписаний, тарифов, остановок;
  • Гибкое управление скидками;
  • Справочная служба (расписания, фактическое прибытие, тарифы, скидки, наличие мест);
  • Регистрация фактического времени прибытия/убытия автобусов;
  • Обработка нестандартных ситуаций;
  • Широкий спектр отчетов;
  • Экспорт данных в бухгалтерскую систему;
  • Интеграция с кассовым аппаратом, фискальным принтером и терминалом приема платежей банковскими карточками;
  • Возможность    вывода необходимых данных на информационные табло на перронах прибытия/отправления автобусов;
  • Защита данных от несанкционированного доступа, обеспечение конфиденциальности данных.
  • Наличие «автономного» режима работы, в случае кратковременного отсутствия доступа в интернет.    
Особенности нашей системы:
  • Гибкий аппарат настраивания функций для каждого пользователя системы;
  • Масштабируемость системы: от автоматизации отдельного    перевозчика/автовокзала до автоматизации автобусных перевозок целого региона или страны.
  • Возможность пользователю самостоятельно подключать новые рабочие места, новые автостанции, а также самостоятельно формировать агентские сети;
  • Система предлагается в формате «Программное обеспечение как услуга» (SaaS);
  • Возможность работать в «автономном режиме» при    кратковременном отсутствии доступа в интернет;
  • Система изначально интегрирована с Европейским сайтом продажи автобусных билетов в Интернете Buseurope.eu.

Наши заказчики – как отдельные перевозчики и/или автовокзалы, так и региональные предприятия, обеспечивающие организацию пассажирских перевозок и обслуживание пассажиров на объектах транспортной инфраструктуры региона.


Чего еще не умеют современные АСУ? Будущее АСУ – каким оно Вам видится? И отдельно – будущее Вашего продукта? Каковы ближайшие и стратегические перспективы? Что Вы планируете предложить в ближайшей новой версии продукта?    

Я думаю, что тут будет вещей две. Вообще цель всего нашего труда – приблизить услугу автотранспортной перевозки ближе к пассажиру, сделать так, чтобы для него все было максимально комфортно и удобно. Поэтому исходя из этого и должны развиваться подобные системы. Например, необходимо вводить в строй мобильные способы покупки билета – например, через смартфон. Они уже, в целом, есть и у нас. Именно к электронным билетам, не привязанным к бумаге, надо двигаться, считаю. Это делает жизнь пассажира удобнее.

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


Какие страны лидируют сегодня в автоматизации транспорта? На каком «месте» находится Россия?

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


Как государство помогает законодательно, налогами, фондами, дотациями, программами и другими путями внедрению АСУ для автовокзалов и росту автоматизации транспорта в России? И какова практика в других странах?

Про Россию я не знаю, у меня есть информации по Латвии, Литве, Эстонии – там государство никак не помогает. При этом государства даже борются с автовокзалами. Идет даже удушение автовокзалов. ЕС и эти комиссии, которые разрабатывают все эти «белые книги» и стратегии, оторваны от жизни. Притом они как бы всего лишь рекомендуют, а не требуют. Они, в целом, пишут правильные вещи, но никто не решает, как это будет профинансировано. А автовокзал сам не всегда может потянуть какие-то нововведения, как и сами перевозчики.


Как Вы взаимодействуете с другими производителями АСУ? Нужно ли это вообще, чтобы разные продукты работали в единой системе, между ними были бы налажены «мосты»? И как именно Вы видите возможную интеграцию?

Один из наших проектов Buseurope.eu представляет собой комплексную систему продажи автобусных билетов в Интернете, взаимодействуя с билетными системами различных автобусных перевозчиков. Система предоставляет возможность приобрести билет в более чем 2 500 мест назначения в 23 странах Европы. Система предполагает интеграцию с билетными системами перевозчиков/автовокзалов/других сайтов и предоставляет возможность пассажиру выбрать оптимальный вариант поездки. Кроме того, если между пунктом отправления и пунктом назначения отсутствует прямой рейс, система по запросу пользователя автоматически ищет вариант поездки с пересадками, количество которых задается пользователем. Для интеграции используется собственный программный интерфейс API, реализованный на основе web-сервисов.

В 2012 году наша компания в рамках европейского проекта eCoach по заказу Европейской Ассоциации автовокзалов принимала участие в разработке информационной платформы для обеспечения возможности формирования общеевропейского сайта по предоставлению пользователю расписания автобусов. При этом использовался стандарт SIRI.

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


Какие технологические решения Вы используете – какие языки программирования, операционные системы, базы данных, веб-серверы и так далее? Используете ли Вы разработки класса Open source под свободными лицензиями? Интегрированы ли в Ваше решение мобильные приложения, терминалы самообслуживания и веб-ресурсы?
Система реализована как многоуровневое Java-приложение, разработанное в соответствии с индустриальной Java-архитектурой (Java Enterprise Edition – JavaEE), для СУБД Oracle под управлением ОС Linux. Сервер приложений – JBOSS, web-сервер – Apache.
На рабочих станциях кассира используется операционная система Windows. В системе имеются:
  • мобильные приложения для водителя и для пассажира;
  • возможна интеграция системы с терминалами самообслуживания;
  • возможна интеграция с информационными табло на платформах;
  • возможна интеграция с веб-сайтами перевозчиков/автовокзалов, их партнеров и агентов.

Сколько времени занимает внедрение Вашей системы для типового автовокзала (маленького, среднего, большого)? Какие основные этапы выделяются, как то: подготовка, развертывание, обучение и прочее? Какова длительность каждого этапа для разных видов автовокзалов (маленького, среднего, большого)? Какую поддержку Вы оказывается заказчику после внедрения?
Независимо от размеров автовокзала, процесс внедрения состоит из следующих этапов:
  • Настройка системы в соответствии с требованиями заказчика;
  • Установка системы на демо-сервере;
  • Обучение сотрудников заказчика;
  • Установка системы на реальный сервер;
  • Ввод исходных данных в систему силами персонала заказчика (при необходимости помогаем автоматизировать процесс);
  • Запуск системы в эксплуатацию.

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


Сколько стоит Ваш продукт? Какие есть типы «пакетов», лицензий и так далее? Уточните для типовых автовокзалов: небольшого, среднего, крупного. Как Вы зарабатываете на своем продукте?
Примерная стоимость приобретения или размер ежемесячной абонентской платы (включая внедрение):
  • Малое    предприятие (1-2 кассира, 1 руководитель)
    300 Евро – первоначальный взнос, 1,5-2% от стоимости проданных через систему билетов – ежемесячный платеж, обеспечивающий поддержку системы.
  • Среднее предприятие (3-4 кассира, 1 диспетчер, 2 руководителя)
    500 Евро – первоначальный взнос, 1,5-2% от стоимости проданных через систему билетов – ежемесячный платеж, обеспечивающий поддержку системы.
  • Крупное предприятие (5-10 кассиров, 2 диспетчера, 4-5 руководителей)
    1 000 Евро – первоначальный взнос, 1,5-2% от стоимости проданных через систему билетов – ежемесячный платеж, обеспечивающий поддержку системы.

Чего сейчас России не хватает для внушительного роста уровня автоматизации автовокзалов? Каков Ваш «месседж» – послание для читателей?    

Есть ситуации, когда выигрывают все. Особенно если выигрывают пассажиры, то однозначно выигрывают остальные участники рынка. И поскольку автобусные перевозки имеют у нас глубокие корни, все это обязательно надо развивать.


Второе интервью SWD Factory

На вопросы отвечал руководитель проекта из компании SWD-Factory Аркадий Иванов, г. Рига (Латвия), продукт BusTicketPro.


Как создаются продукты такого уровня сложности? Что для этого необходимо: какие знания, ресурсы, специалисты, фреймворки и технологии?

Все началось с того, что появились заказчики, которые были заинтересованы в получении продукта. Мы периодически собирались, и в результате этих встреч зародилось техническое задание. А дальше все пошло по классической форме разработки программного обеспечения.

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

Все люди имели высшее образование или учились. До этого у нас был пилотный проект с Америкой. Мы получили опыт на том проекте, накопили наработки. Соответственно, перенесли свой опыт на «автобусный» проект. Поскольку у нас был хороший опыт разработки на базе Java, мы использовали ее в этом проекте. А вообще мы сторонники открытых и свободных технологий. Из операционных систем используем Linux, те дистрибутивы, которые сертифицированы Oracle, потому что у нас как раз эта база данных.


Какова роль Open source в Вашем продукте? Насколько сильно в Ваш продукт интегрированы бесплатные технологии с открытым кодом?

Мы стараемся использовать именно технологии с открытым кодом, потому что когда есть возможность править исходники программ, можно что-то всегда изменить изнутри программы. При этом мы обычно отсылаем свои наработки в Open source-сообщество. В общем, мы используем достаточно много свободных библиотек, из закрытых продуктов у нас, по-моему, ничего нет. И стараемся при этом использовать продукты под более свободными лицензиями Apache и BSD, чем GPL.


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

Чисто на программном уровне у нас есть защита – например, в случае нескольких неудачных попыток авторизации мы отбрасываем подключение. Потом, у нас есть привязка по ip-адресам, то есть рабочие станции могут работать только с доверенных адресов. Еще, в том числе, ограничивается время работы кассира – например, с 8:00 до 18:00.

На системном уровне у нас есть ряд спецсредств, файрволов, настроек ядра Linux, настроек веб-сервера Apache. Так мы решаем вопросы защиты и противодействия взломам. При этом у нас есть опыт противодействия реальным атакам.

Относительно персональных данных. В целом, критические данные, такие как коды платежных карточек или адреса проживания, – такие данные у нас в системе не хранятся. Когда человек покупает у нас билет или платит карточкой, то задача сбора данных – это задача банка или той процессинговой платежной системы, с которой мы работаем. Они отвечают за свою сторону защиты. А мы – за данные о билете, вот это у нас хранится. В том числе, место в автобусе, стоимость и, может быть, информация по самому пассажиру. К примеру, для России надо обязательно вводить паспортные данные при продаже-покупке билета. Для Евросоюза эта информация не обязательная.

Относительно самых негативных сценариев. Всегда есть план «Б». В той же Латвии, если ты не можешь купить билет на автовокзале, то можно приобрести билет в автобусе. Поэтому даже если на какое-то время в самом негативном сценарии система выведена хакером из строя, то уехать люди все равно смогут. При этом все данные хакер может удалить только за 15-20 минут времени – это максимальные потери. Все остальное резервируется. В общем, потенциальные потери не очень большие. При этом еще раз обращаю внимание, что мы в системе вообще не храним действительно критические данные – те же коды платежных карт. Поэтому для хакеров как бы нет особенно интересной информации.

Еще один «хакерский» сценарий – выпустить себе поддельный билет. Если теоретически размышлять, то чтобы это сделать, необходимо находиться в системе достаточно долго и подделать многие вещи. При этом есть специальные методы противодействия этому и встречные проверки. Но, конечно, чем глубже мы погружаемся в цифровые решения, тем выше становится цена ошибки. Хотя на данном этапе мы чем-то большим в принципе не рискуем.


Какие технические новинки планируется реализовать в системе в ближайшем будущем (ближайшая версия)? Какие в среднесрочной перспективе (несколько лет)? Как могут эволюционировать АСУ для автовокзалов в долгосрочной перспективе (с позиции "научной фантастики", например)?

Думаю, в ближайшем будущем, если говорить именно о сфере продаж билетов, будет упор на бесконтактные платежи и уход от наличности к безналичному расчету. Например, сейчас уже есть карточки с NFC чипами, плюс в телефонах есть такие модули. Факт оплаты такой картой – если Вы ее приложили к считывающему устройству. У Вас при этом может быть виртуальный абонемент, с которого могут списываться Ваши поездки. Но есть встречная ситуация, которая несколько ограничивает распространение новых технологий. Общество стареет, и пожилым людям новые фишки сложно использовать. Поэтому старые подходы и решения к продаже билетов будут отходить постепенно. Но все при этом, так или иначе, движется в сторону прогресса.

При этом я надеюсь, что когда-нибудь соберутся представители разных областей – автобусные перевозки, ЖД, авиа. И договорятся о едином билете. Я уверен, это будет очень удобно для пассажира. Чтобы не надо было по разным кассам бегать. Идея красивая. Но есть много нюансов, даже не технических, а политических. Если руководители высшего уровня все-таки наконец-то снизойдут со своих высот до нужд пассажиров, то технические объединение будет реализовано. Технологическая база для этого уже есть. Не хватает только политических договоренностей.


Как технически реализовать объединение нескольких систем в единое информационное поле для удобства пассажиров? Какие технологии для этого потребуются, какие знания, какие вычислительные мощности? Какие сценарии объединения возможны? Каково Ваше послание коллегам – разработчикам других систем?

Технически все это возможно. У нас три системы объединены в рамках проекта BusEurope.eu, это шаг в направлении всеобщей интеграции. Сама жизнь сейчас заставляет людей быть мобильными. Молодежь, например, хочет посмотреть мир. Чтобы для пассажиров это было проще сделать, различным системам нужно договориться о протоколах и форматах обмена. В первую очередь, обмен расписаниями. Второе – обмен оперативными изменениями. Третье – предоставление возможности продавать билеты друг друга.

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


Интервью псковского автовокзала

На вопросы отвечал генеральный директор “Псковавтотранс” Алексей Семенов , установлен продукт BusTicketPro от компании SWD Factory.


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

Сколько компьютерной техники занято под АСУ на Вашем автовокзале?

На Центральном Псковском автовокзале с программой работает восемь рабочих мест (6 касс, 1 диспетчерская, 1 начальник автовокзала). На небольших автостанциях чаще всего имеется только одно рабочее место, которое обеспечивает работу и в режиме кассы, и в режиме диспетчерского сопровождения. На сегодня к программе подключено в целом по Псковской области на 23 линейных сооружения пятьдесят два рабочих места.

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


Как влияют сбои (свет, интернет) на работоспособность АСУ?

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


Чего Вам не хватает и хотелось бы еще от АСУ?

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