Жизнь одной из крупнейших в мире транспортной компании ОАО «РЖД» такова, что требует одновременно решать и чисто технологические, и инфраструктурные, и организационные проблемы. О том, как это происходит, рассказывает Сергей Фирстов, главный инженер вычислительного центра Свердловской железной дороги.

Intelligent Enterprise: Для начала давайте опишем ИТ­ландшафт Свердловской железной дороги. Какова здесь история развития ИТ?

Сергей Фирстов: Развитие ИТ у нас началось с образования в феврале 1964 года лаборатории электронно­вычислительной техники, которая в июне 1968­го была преобразована в вычислительный центр. Он решал самые разные задачи — такие, как автоматизация билетно­кассовых операций, внедрение систем прогнозирования основных показателей поездной, грузовой и коммерческой работы, освоение базовых модулей системы R/3 разработки SAP и множество других. Техническая база менялась от ЭВМ «Урал­2, ­4, ­14» до первой ЕС­1022, установленной в 1976 году. Эпоха ЕС ЭВМ длилась до 1996­го, когда в ИВЦ появились ЭВМ класса IBM­4381 и HDS­6215. В настоящее время центральный вычислительный комплекс базируется на старших моделях серверов серий z и p компании IBM и на линейке серверов Sun. На них работают тринадцать комплексных АСУ, покрывающих в общей сложности свыше 3200 задач.

Большая часть наших крупных АСУ имеют долгую историю развития. Например, автоматизированная система оперативного управления перевозками потребовала более 6000 человеко­лет работы программистов, а всем известная система «Экспресс» — более 3000 человеко­лет. В середине 90­х годов при переходе с ЕС ЭВМ на современную серверную платформу IBM нам пришлось преодолеть примерно двадцатилетнее отставание от мировых лидеров в развитии вычислительной техники и операционных систем. Выбор новой платформы в тот момент был в первую очередь обусловлен особенностями унаследованных программных приложений.

Развитие сети передачи данных на Свердловской железной дороге также прошло несколько этапов. Пока строилась современная корпоративная сеть, было создано множество локальных АРМов, сейчас их у нас около 350 типов, из которых 125 — собственной разработки. Программные приложения строились для служб и отдельных предприятий дороги. Практически в каждом отделении и на крупных станциях устанавливались серверы линейного уровня. Был полный «зоопарк» платформ — кто что достал, на том и работали. На этой базе развивались разобщенные приложения, использовались практически все известные СУБД.

Однако с принятием в феврале 1996 года Коллегией МПС «Концепции информатизации железнодорожного транспорта России» были разработаны долгосрочные и среднесрочные программы информатизации отрасли. Железные дороги вернулись к централизованному финансированию в сфере развития ИТ и сетей связи. В качестве первого шага консолидации информационных ресурсов мы просто физически собрали с большинства станций серверы и передали их в отделения, а часть отделенческих серверов передали в ИВЦ. Основой такой централизации стали имеющиеся возможности систем жизнеобеспечения ИВЦ и серверных отделений дороги. Вторым этапом был постепенный переход на блейд­серверы компании HP. А следующий этап состоял в консолидации данных, в ходе которой часть приложений мы перевели на основную для центрального вычислительного комплекса СУБД DB2.

Столь значительные преобразования в области ИТ на железной дороге не могли не вызвать и серьезных организационных изменений…

Конечно, сейчас мы вместе с отраслью находимся на третьем этапе реформирования. В 2007 году планируется все ИВЦ дорог собрать в одну вертикаль под ГВЦ «РЖД», что позволит проводить единую политику информатизации и построить современную систему управления отраслью, обеспечив, с одной стороны, централизацию управления, а с другой — относительную самостоятельность филиалов в условиях рынка. В 2005 году в штат нашего ИВЦ вошли все линейные ИТ­подразделения. В службе информатизации и в ИВЦ с учетом филиалов на линии и на предприятиях дороги работает около тысячи человек. Сейчас у нас свыше 15 тысяч компьютеризированных рабочих мест, мы обслуживаем более сотни серверов из нескольких сотен, имеющихся на дороге.

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

Расскажите об этом подробнее: как у вас организована разработка приложений?

Разработка основных программных приложений для нужд ОАО «РЖД», как правило, выполняется централизованно. В ИВЦ ведутся более частные разработки для нужд дороги, в том числе по построению различных форм отчетности на основе данных централизованных систем. Помимо этого есть разработки по техническим заданиям конкретных служб. Раньше под определенную задачу набирался коллектив, создавалась отдельная структура, которая ее и решала. И так было до «конца социализма». Потом догадались, что у нас нет столько специалистов, чтобы под каждую задачу организовывать отдельную структуру, и всех разработчиков собрали в один отдел. Это удалось, но попытки выделить группу программистов только на новые разработки оказались не совсем удачными. Лучше прошла интеграция по направлениям — удалось уйти от конкретных людей для конкретных задач. При этом появилась некая взаимозаменяемость сотрудников.

Здесь проблема в жизненном цикле нашего программного продукта. Допустим, мы даем молодым специалистам новую, перспективную задачу, они пишут АРМ, который переходит в стадию эксплуатации. Если специалист пишет хорошо и быстро, то для него находятся вторая, третья и так далее задачи, и все они проходят тот же путь. И хотя формально программист за задачу уже не отвечает, реально он поддер­живает всё, что когда­либо написал. Через два­три года он уже нагружен десятком задач, и разрабатывать что­то новое у него просто физически не хватает сил. Мы проходили этот цикл много раз, но проблема оставалась. При этом специфика железной дороги требует высокой оперативности в устранении любых сбоев. Мы можем поднять специалиста посреди ночи, чтобы он решил проблему с разработанным им приложением, и, как правило, он справляется с этим быст­рее, чем кто­либо еще. И так, увы, происходит постоянно.

Есть еще проблема в оформлении разработок в соответствии с современными стандартами. Чтобы реорганизовать разработку программного обеспечения, ставилась задача внедрить правила, по которым она должна вестись. Процессы на дорогах типовые, и процент разработок, используемых более чем в одном месте, довольно высок. В результате возникла идея создания фонда алгоритмов и программ с целью снизить дублирование. Есть соответствующее указание МПС, фонд существует и объединяет все более­менее стоящие разработки. Замечу, что с внешними разработчиками еще сложнее, поскольку они всегда хотят привязать к себе клиента.

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

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

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

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

Как вы решаете кадровые проблемы?

С точки зрения кадров Екатерин­бург — город перспективный, у нас почти два десятка крупных вузов, в основном технических. Базовым для железных дорог региона является Уральский государственный университет путей сообщения (УрГУПС). В период реформирования экономики университет выжил в значительной мере за счет поддержки со стороны железных дорог, и сейчас в нём неплохая материальная база и преподавательский состав. Я сам преподаю в УрГУПС и считаю, что это очень полезно для дороги, да и для собственного развития тоже. Читая лекции на трех старших курсах, неплохо знаю студентов. У нас они пишут дипломы, проходят практику в ИВЦ и в филиалах, так что и сюрпризов удается избежать, и от кадрового дефицита мы себя в значительной мере обезопасили, приглашая на работу лучших из них.
Связи университета с дорогой позволяют нам напрямую участвовать в подготовке кадров, прямо и непосредственно влиять на специализацию студентов в зависимости от реального спроса. Например, внедрение продуктов SAP в РЖД потребовало большого количества специалистов, и в университете были организованы курсы. Когда с развитием инфраструктуры информатизации стало очевидно, что вопросы безопасности информационных систем решаются недостаточно эффективно и требуются соответствующие специалисты, данная специализация была введена в университетскую программу. Выпускники этого направления не только закрывают потребности дороги, но и пользуются большим спросом на предприятиях региона.

Или другой пример: уже давно мы используем возможности пакетной обработки данных через IBM MQ Series, а для интеграции приложений применяем IBM WebSphere. Это хорошее средство, но есть у него и минусы. Прежде всего IBM WebSphere дорог с точки зрения обучения. Подобрать специалистов по этому продукту довольно сложно, спрос на них очень высок. Хотя в последние три года ИТ­обучение хорошо поставлено в рамках РЖД в целом, все серьезные курсы централизованы на базе ГВЦ ОАО «РЖД», куда при необходимости приглашаются практически любые обучающие компании.

Но несмотря на это проблемы с кадрами есть, и очень значительные. Тенденция такова: люди идут в университет на целевую подготовку — дорога платит за их обучение. После трехгодичной отработки на дороге они уходят в газовые, нефтяные, энергетические компании, затем в консалтинговые фирмы в Москве и наконец уезжают работать за рубеж. У нас бывали ситуации, когда люди уходили целыми отделами. Так случилось, например, со специалистами по Cisco — пока строили корпоративную сеть, мы их всему научили, наши администраторы получили уникальный опыт, поскольку подобных сетей и такого оборудования почти ни у кого тогда не было. А потом наши сотрудники были просто нарасхват. Примерно то же самое произошло со специалистами­энергетиками, обслуживающими импортные ИБП. Но больше всего сложностей с текучестью кадров мы испытали в процессе внедрения SAP R/3, так как специалистов катастрофически не хватало.

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