Сегодня в России уже есть несколько попыток внедрения ОТМ исключительно для автоматизации железнодорожных перевозок. И поскольку к одному из таких проектов я имею непосредственное отношение, а об остальных время от времени доходят разные вести, то уже можно сделать некоторые наблюдения, которыми я и собираюсь поделиться. Собственно о своем железнодорожном проекте я обязательно еще расскажу подробнее, но в другой раз. А сейчас на повестке дня вопрос более глобальный — быть ли ОТМ на рельсах в России и подойдет ли отечественная колея?
Как известно и не раз уже звучало со страниц этого блога, ОТМ — это система в вышей степени универсальная и с ее помощью в теории можно смоделировать любой вид перевозки и любыми видами транспорта. Но как только дело дойдет до практики попробуйте только заявить это истинным железнодорожникам со стажем и вас тут же поднимут на смех. И когда мне (отнюдь не специалисту по железнодорожным перевозками) довелось столкнуться с суровой реальностью информатизации в этой сфере, то оптимизма значительно поубавилось.
Разумеется, если организация железнодорожных перевозок поручена профессиональному экспедитору, который берет на себя все вопросы взаимодействия с РЖД и владельцами подвижного состава, то в этом случае для конечного клиента в ОТМ такая перевозка ничем не будет отличаться от других. Такая же твердая ставка, тот же процесс согласования и исполнения. Обычно так и бывает при небольших и нерегулярных отправках по железной дороге. Но если стоит задача создать полноценное комплексное решение, которое будет тесно взаимодействовать со специализированными информационными системами РЖД и дочерних структур, то в этом нужно по-настоящему разбираться и быть готовым к серьезной работе.
Всемогущий ЭТРАН
История автоматизации на железной дороге столь же богата, как и история самих железных дорог. Почетное место в современной части этой истории занимает компания ИнтэлЛекс со своей разработкой — системой ЭТРАН, которая в 2012 году отметила свой 10-летний юбилей. Ниже несколько слов с сайта ИнтэлЛекса чтобы не пересказывать:
ЭТРАН (Электронная ТРАнспортная Накладная) — это автоматизированная система централизованной подготовки и оформления перевозочных документов. Система впервые включает клиента (грузоотправителя, грузополучателя, экспедитора) в технологический цикл приема заявок и оформления перевозок, обеспечивая ему возможность оформления заявки на перевозку, подготовки электронной накладной, получения итоговых документов, получения результатов расчетов провозной платы по перевозкам и отслеживания хода перевозок грузов со своего рабочего места. Также, клиенту предоставляется возможность получения информации обо всех грузах, отправленных в его адрес.
В основу системы положены требования, установленные Уставом железнодорожного транспорта Российской Федерации и Правилами приема заявок на перевозку грузов железнодорожным транспортом.
Изначально созданная как прикладной инструмент система ЭТРАН на седьмом году своего существования перешла к функционированию в качестве полноценной учетной системы, способной контролировать бизнес-процессы грузоперевозок.
В настоящее время система ЭТРАН эксплуатируется в промышленном режиме «7х24» и охватывает 100% железнодорожных грузоперевозок на территории Российской Федерации. На сегодняшний день к системе подключено свыше 26 000 пользователей из более чем 5 000 организаций (в том числе подразделений ОАО «РЖД»). В месяц оформляется свыше 136 000 заявок и более 1 000 000 накладных.
О существовании такой всеобъемлющей системы я впервые услышала на Техстройконтракте при внедрении ОТМ, но на этом проекте никому даже в голову не пришло их интегрировать. Дело в том, что речь шла не более чем о десяти накладных в месяц, с которыми легко справиться и вручную, а результаты занести в ОТМ.
Но любая система, которая претендует на автоматизацию железнодорожных перевозок, в безусловном порядке должна двусторонне интегрироваться с ЭТРАН, полностью заменяя собой полноценное рабочее место в этой программе, а в идеале и самого работника на этом месте. Это означает, что какую-то часть ЭТРАН, включая справочники, документы, логику и последовательность процессов, нужно просто повторить, например, в ОТМ, а затем не забывать актуализировать при возможных изменениях. При этом надо понимать, что речь идет не о взаимодополняющем, а скорее о конкурирующем функционале, который собственно только ЭТРАН не ограничивается.
Волшебный Rail-Тариф
Поскольку до того, как начать оформлять заявки и накладные, грузоотправители предпочитают заранее узнать размер провозной платы, то кроме ЭТРАН потребуется интеграция и с хорошим тарифным калькулятором. Пример такого бесплатного калькулятора есть на сайте РЖД и называется он Справочный расчет провозной платы, что уже намекает на возможные неточности в этом расчете. Гораздо более широко используется коммерческая программа компании СТМ Rail-Тариф, разработчики которой заслуживают огромного уважения потому что постоянно поддерживают тарифную базу в актуальном состоянии с учетом всех изменений и многочисленных особенностей. Программа производит расчет с подробной информацией о действующих скидках, индексах и коэффициентах.
Здесь уже можно прийти к пониманию того, что тарифный калькулятор ОТМ становится совершенно бесполезен, а взамен придется разработать довольно сложное интеграционное решение для формирования запроса ставки во внешней системе и возврата ответа в ОТМ. Сложность такой разработки еще и связана с тем, что тот же Rail-Тариф использует огромное количество различных атрибутов и справочников, которые так или иначе участвуют в расчете, а это значит, что для корректного обращения к сервису нужно все это повторить, при чем на каждой конкретной перевозке, для которой мы хотим узнать ставку. Если же мы остановимся на самых основных атрибутах, например, род вагонов и код ЕТ СНГ, а остальные просто будем устанавливать в значения по умолчанию, то в большинстве случаев мы получим неточности в расчете. Поэтому тут или все или ничего.
Еще одно важное замечание относительно тарификации: если кроме собственно провозной платы требуется отразить плату за пользование арендованным подвижным составом, то тут тоже все не так то просто. Дело в том, что эти расходы относятся уже к другому поставщику и должны быть отражены как вторичный сбор к основной перевозке. В теории в ОТМ существуют специальные правила для автоматического создания вторичных сборов, но на практике гибкостью они не отличаются и к тому же тарифы постоянно меняются и могут зависеть от совершенно неформализованных факторов.
В итоге чтобы получить в ОТМ достоверную картину плановых расходов по железнодорожной перевозке придется изрядно потрудиться, при чем как в плане доработки ОТМ по созданию несвойственного интерфейса, так и в плане ручных действий пользователей по внесению порой «разовых» тарифов и перерасчету стоимости. В утешение можно сказать, что если на первоначальном этапе обойтись примерными данными, но на более поздних этапах можно будет загрузить данные о фактических расходах и сопоставить с первоначальными расчетами.
Быть или не быть?
После того, как прикинули тариф, возвращаемся к ЭТРАН и оформлению заявок на перевозку, железнодорожных транспортных накладных и нашему вопросу: быть или не быть интеграции? Точно можно сказать, что ключевую информацию для формирования документов в ЭТРАН почерпнуть из ОТМ можно: количество вагонов, их тип, плановые даты отгрузки, характер и количество груза. Но чтобы эти данные можно было действительно использовать придется либо справочники ОТМ приспособить под хранение ссылок на справочники ЭТРАН, либо где-то держать таблицу соответствия одного другому. А дальше нужно разобраться с каждой операцией, которую позволяет выполнять ЭТРАН и создать ее аналог в ОТМ, который будет выполнять отправку данных по интеграции, либо получать данные и раскладывать их по объектам ОТМ. В конечном итоге все сведется к набору статусов перевозок в ОТМ, которые будут сменять друг друга по мере продвижения по процедуре. При желании вообще можно интегрировать все со всем — нужна только уверенность, что овчинка стоит выделки в вашем конкретном случае. Не зря методология предусматривает оценку объема потока данных по каждому предполагаемому интерфейсу интеграции. По результатам этой оценки принимается решение о целесообразности разработки или о ее замене ручными операциями ввода данных.
Вездесущая дислокация
Дальше начинается фактическое исполнение, а для железнодорожных перевозок это означает необходимость получения и автоматизированной загрузки дислокации по каждому вагону или контейнеру. К счастью такой интерфейс наиболее типичен для ОТМ и тут нужно только определиться с источником данных о дислокации.
Кстати, если задаться вопросом откуда же берутся данные о дислокации вагонов по всей территории РФ, то в конце концов следы приведут в Отраслевой центр внедрения новой техники и технологий, созданный совместно РЖД и ВНИИЖТ. Проект, в результате которого появилась Система автоматической идентификации подвижного состава (САИ ПС) на сети железных дорог, совершенно поразил меня своими грандиозными масштабами. Именно такие достижения, на мой взгляд, знаменуют настоящие качественные прорывы, которые принципиально меняют свою область. Звучит все очень просто: бортовые датчики, стационарные считыватели и концентрация сообщений со всех пунктов сбора данных. Но когда представляешь какое количество станций и подвижного состава нужно было оборудовать, да и вообще придумать такое надежное и безотказное оборудование, то становится понятна вся сложность такой задачи. Тем не менее задача решена и это достижение давно уже воспринимается как должное.
В результате как на сайте РЖД, так и на многочисленных коммерческих сайтах по слежению за вагонами доступна информация о дислокации подвижного состава. Если обращаться к первоисточнику, то следует заключить договор с ЦФТО РЖД для доступа к Электронной Торговой Площадке Транспортных Услуг (ЭТП ТУ), которая даст возможность получать информацию о дислокации и операциях с грузами, вагонами, контейнерами по запросу или в регламентном режиме. Казалось бы получать информацию напрямую удобно и надежно, но при небольших объемах довольно дорого, потому и появилось огромное количество сайтов, которые предлагают те же самые справки о дислокации из тех же самых источников по сходной цене, а то и вовсе бесплатно. Но в любом случае формат этих сообщений регламентирован и давно известен, а значит вполне подлежит загрузке в ОТМ, разумеется, при условии синхронизации справочников станций и операций.
Отправление с платформы ОТМ
Подводя итог этим наблюдениям я бы сказала так — для железнодорожных перевозок ОТМ является скорее не гарантией успеха, а всего лишь предпосылкой к нему, хорошей основой для серьезной, полномасштабной разработки. Но надо признать, что это уже не мало, потому что качественная производительная платформа, а также четкая универсальная архитектура — это большой задел. Многие системные элементы не придется изобретать с нуля. Другое дело, что коробочные «лучшие практики» скорее всего во многом останутся не востребованными, поскольку в большинстве их вытеснят заимствованные бизнес процессы из внешних систем, которые в этой области являются законодателями мод.
Счастливого пути!
