В разные времена задача сокращения издержек в компании «Российские железные дороги» приобретала различные экономические или политические оттенки. Решая ее сегодня, компания от анализа требований, которые возникают в нынешних быстро меняющихся экономических условиях.
Долгие годы руководство МПС, а потом и РЖД принимало управленческие решения на основании данных статистической отчетности, обрабатываемых с применением традиционных методов статистического анализа. По словам директора по развитию Центра фирменного транспортного обслуживания ОАО РЖД Елены Кунаевой, за последние годы требования существенно изменились.
«Нам необходимо работать с более детальной информацией, — рассказывает она. — Поэтому от усредненных показателей мы стараемся отходить, уделяя все большее внимание объемам услуг или потерь, выраженных в деньгах. Как следствие, возникла необходимость преобразовать наши информационные системы из отображающих в управляющие».
Электронная синхронизация
Двенадцать лет назад в тогда еще Министерстве путей сообщения РФ была создана система фирменного транспортного обслуживания, предназначенная для формирования маркетинговой политики и реализации услуг железнодорожных грузовых перевозок. В настоящее время эта система не ограничивается выполнением маркетинговых функций, но также обеспечивает оперативную обработку огромного объема информации о грузовых перевозках. Тогда, в середине 90-х годов, требовалась ежемесячная обработка почти 1,5 млн. документов для приема груза к перевозке и примерно такого же количества документов для оформления дополнительных услуг.
В результате пришлось решать две непростые и очень важные задачи. Во-первых, требовалось создать хранилище данных, которое позволяло бы производить аналитическую обработку информации огромных объемов. И такое хранилище было создано. Во-вторых, предстояло повысить качество транспортного обслуживания за счет создания более эффективного документооборота. Для этого был осуществлен реинжиниринг действующих решений и разработана централизованная система «Электронная транспортная накладная» (ЭТРАН), которая изначально задумывалась как инструмент централизованного оформления перевозочных документов. Со временем ее возможности расширились в соответствии с потребностям сбытовой системы РЖД: появились прием заявок от клиентов, их согласование, оформление перевозочных документов, предварительные расчеты провозной платы и пр. — достаточно большое число функций по различным направлениям деятельности.
Когда разработка системы ЭТРАН только начиналась, перед разработчиком — компанией «ИнтэлЛекс» была поставлена задача создать систему, которая должна была автоматизировать жесткое соблюдение регламентов операций по принятым бизнес-правилам. «Система ЭТРАН должна работать в строгом соответствии с утвержденными нормативными документами. Ничего другого привнесено в систему быть не может. Если у кого-то возникнет желание эти правила нарушить, то система не должна ничего такого допустить, — поясняет Кунаева. — Это был один из принципов, продиктованных нами, и он же стал самой большой проблемой, когда мы начали перевод наших сотрудников на использование новой информационной среды. Мы слышали от них: “А мы привыкли иначе”, “А раньше можно было по-другому”. Каждый хотел привнести что-то свое, тем самым нарушив технологию транспортного обслуживания, оформления или расчетов перевозочного процесса».
Еще одно жесткое требование, выдвигавшееся изначально, — система ЭТРАН должна быть централизованной. Раньше все программно-технические решения развертывались на уровне региональных (дорожных) вычислительных центров (их в компании 17). У каждого вычислительного центра была возможность внести в программное обеспечение свои изменения, и возникала опасность нарушения целостности правил. Кроме того, велики были трудозатраты на поддержку в актуальном состоянии всех систем на местах. Необходимо было сделать так, чтобы только главный вычислительный центр РЖД имел возможность устанавливать новую версию и никто нигде не смог вмешаться в этот процесс.
«Окончательное решение о разработке системы ЭТРАН было утверждено в феврале 2001 года, — вспоминает Кунаева. Перед тем как его подписать, первый заместитель МПС, буквально занеся над документами руку, задал мне вопрос: “А не остановим ли мы всю страну?” Мы сознательно не пошли на одновременное полнофункциональное внедрение ЭТРАН на всей территории России. В качестве опытных полигонов были выбраны Красноярская и Куйбышевская железные дороги, так как там работали наиболее инициативные кадры, готовые внедрять новые решения. К тому же на Куйбышевской дороге инициативы исходили не только от ИТ-персонала, но и от структур транспортного обслуживания. Это важно, поскольку при решении подобных вопросов необходимо единство пользователей и специалистов по ИТ».
Везде функционал ЭТРАН подключался пошагово, начиная с более простых документов и переходя затем к более сложным, в том числе международным документам. Только после того когда все заработало, можно было двигаться дальше. Примечательно, что период наращивания функционала всегда занимал не менее трех месяцев. Также интересно, что на первом этапе внедрения сервера приложений локальные вычислительные центры играли роль дублирующих. «Через три-четыре месяца эксплуатации в опытном режиме специалисты локальных вычислительных центров предлагали своим пользователям переключиться на серверы главного вычислительного центра», — рассказывает Кунаева.
По ее словам, РЖД получили солидный экономический эффект благодаря точности взыскания провозных платежей, потому что «зашитые» в систему правила расчетов минимизировали риски ошибок. Искажения, вызванные несвоевременным обновлением версий системы, теперь исключены. Объективная информация сразу же передается в смежные системы для проведения бухгалтерских проводок и оформления документов налоговой отчетности, обеспечивая тем самым снижение налоговых рисков компании и повышая точность финансового учета. «Если раньше база данных отправления и база данных прибытия были не всегда корректными (не всегда совпадали), то теперь создан один единый электронный документ: что грузоотправитель передает нам в электронном виде, то мы и принимаем. И здесь мы получили колоссальный эффект благодаря сокращению издержек», — так оценивает сегодня Кунаева результаты внедрения системы ЭТРАН.
Новая история
Новые требования возникли, когда стали появляться новые субъекты транспортного рынка. «Если раньше клиент, обращаясь к МПС, а потом к РЖД, мог получить комплексную услугу, то теперь ему придется заключать договор с собственником подвижного состава и только после этого организовывать железнодорожные перевозки. Раньше вагоны принадлежали МПС и мы ими управляли по нашим принципам и законам, теперь из процесса выпало звено “вагоны”: у их собственника в рамках договора с грузоотправителем возникла необходимость подсыла вагонов в точку погрузки груза, это означает необходимость оформления документов на порожний рейс», — изложила Кунаева суть реорганизации системы перевозок.
Для крупных собственников автоматизированные средства оформления документов — это не красивые игрушки, а реальная необходимость. Оформление документов на порожний рейс при парке в 20 тыс. вагонов уже влечет за собой существенные затраты, а при парке в 200 тыс., как, например, у Первой грузовой компании, столь высокие затраты становятся слишком большими.
И независимым собственникам вагонов, и РЖД необходимо более эффективно управлять собственным парком вагонов, чтобы оптимизировать их подсыл в точку погрузки. «Мы должны сокращать свои издержки за счет минимизации порожних пробегов, простоев вагонов под различными операциями или в их ожидании, поэтому нам пришлось отказаться от технологии, которую мы называли регулировкой, когда на основе определенного набора сведений делался прогноз о примерном местоположении и количестве порожних вагонов. Точность этого прогноза была невелика, и возникла необходимость решать оптимизационную задачу, которая у нас получила название “адресная подсылка порожняка”», — пояснила Кунаева.
Для решения этой задачи в 2006—2007 годах была задумана и реализована автоматизированная система динамического распределения порожних вагонов (АС ДРПВ). Исполнителем проекта стала компания «ИнтэлЛекс».
В современных условиях необходимо иметь данные, например, не вообще о ста вагонах (скажем, цементовозах) на Московской дороге, а о 20 вагонах в точке А, 30 — в точка B и 50 — в точке С. Избыточность парка в точках, где он не востребован, и, наоборот, его недостаточность там, где вагоны нужны, приводит к экономическим рискам. В конечном счете это невыгодно ни РЖД, которое теряет доходы, потому что не перевозит грузы, ни грузоотправителю, который упускает свои возможности.
На первый взгляд задача проста: имея заявки грузоотправителя, включающие графики подачи вагонов под погрузку в определенное место, и имея для этого парк подвижного состава, который может быть использован, информационная система должна увязать потребности с возможностями (с учетом состояния вагонов, их технической и коммерческой пригодности) и в качестве результата передать в систему ЭТРАН сообщение на формирование комплекта перевозочных документов. Однако масштаб задачи и дополнительные требования к системе, которую предстояло разработать, настораживали, прежде всего потому, что цена ошибки могла быть крайне высока.
На первом этапе проекта был выбран наиболее подходящий для реализации в автоматизированной системе математический метод. Одним из важных критериев выбора алгоритма стала возможность его выполнения на современных аппаратных средствах. В ходе реализации была произведена оптимизация под конкретные аппаратные платформы. На втором этапе было реализовано ядро системы, включая расширенную функциональность. В мае 2007 года АС ДРПВ запустили в эксплуатацию для управления парком цементовозов общим числом в 17 тыс. вагонов.
Решение реализовано на основе трехуровневой архитектуры «клиент-сервер». Высокоскоростные расчеты математической модели, оптимизирующей перемещение порожних вагонов на основе различных критериев (с целью максимизации прибыли, выполнения всех заказов, сокращения порожнего пробега), выполняют серверы на базе процессоров Intel под управлением Windows Server 2003 или Sun SPARC под управлением Sun Solaris. Клиентская часть системы реализована для рабочих станций на платформе Windows.
Уже на стадии опытной эксплуатации АС ДРПВ удалось получить определенные результаты оптимизации использования парка РЖД, увидеть узкие места и получить более подробную информацию о техническом состоянии вагонов. Однако на фоне преимуществ обострялись и риски. Во-первых, до появления новых возможностей специалисты РЖД не обладали актуальной информацией о техническом состоянии вагонов. Это важно, поскольку ряд грузоотправителей, особенно работающих с международными перевозками, предъявляет повышенные требования к состоянию вагонов. Между тем их изъяны ранее нигде не фиксировались.
Второй риск связан с соблюдением нормативных сроков доставки. Когда система осуществляет «привязку» вагонов под заявку, есть риск, что вагон не успеет пройти расстояние за указанное время (например, если испортится погода в Новороссийске, порт будет перерабатывать грузы в меньшем объеме, это приведет к задержке вагонов).
«Мы рассматривали подобные обстоятельства как риски, которые не позволят системе продемонстрировать ожидаемую эффективность. С другой стороны, появилась возможность выявить наши узкие места и понять, где кроются проблемы, с которыми надо серьезно разбираться», — считает Кунаева.
На сегодняшний день реализован алгоритм только по одному оптимизационному критерию — минимизации расстояния подсылки вагонов. Это объясняется сложностью оптимизации процесса, охватывающего большое количество объектов. Со временем планируется оптимизировать целый комплекс показателей, определяющих экономическую целесообразность подсыла вагонов, в частности стоимость порожнего пробега, учет груза, который находился в вагоне перед его разгрузкой, необходимость направления вагона в ремонт или на очистку и пр., обеспечив таким образом дальнейшее сокращение издержек РЖД.
