ITIL — пассажирам

АЛЕКСАНДР ПОЗДЕЕВ: «Легко сказать: мы переходим к процессному управлению. Но очень непросто это сделать»

На Московской железной дороге реализуется масштабный проект реорганизации управления пригородным пассажирским комплексом на базе сервисно-процессного подхода по принципам ITIL/ITSM. В проекте создания Технологического центра управления участвуют компания «Ай-Теко» и HP, на базе программного продукта которой — Service Manager выполнена автоматизация системы управления.

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

Ваш проект представляется очень сложным. Можете ли вы кратко описать его суть?

С чего надо начинать проект по ITSM? Если вы скажете, что с создания Service Desk и процесса управления инцидентами, то это первая ошибка. Прежде всего надо понять, какие сервисы вы собираетесь предлагать заказчику.

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

Какой должен быть следующий шаг? Почему всегда начинают с инцидентов? У нас что, страна вечных пожаров? Дальше нужно то, из чего складывается сервис, — задекларированные плановые работы. Когда вы начнете понимать, что отклонения плановых работ от нормального выполнения порождают инциденты, вы можете строить процесс управления инцидентами в увязке с процессом управления плановыми работами. Дальше к инцидентам надо привязать проблемы. Но не стоит сразу начинать этот процесс, надо отложить его на полгода, а инциденты увязать с конфигурациями и на этой основе строить Service Desk. Затем можно перейти к управлению проблемами, затем — к управлению изменениями, это наиболее сложный процесс. И в каждом процессе надо продумывать объем реализации, чтобы не погрязнуть в лишних деталях, но и не сделать меньше необходимого. Наверное, года через два сложится ясная картина управления на базе этой ключевой группы процессов.

В какой стадии реализации сейчас находятся эти процессы?

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

Есть ли особенности реализации процессов управления сервисами в приложении к железнодорожным перевозкам по сравнению с традиционным ITSM?

Все во многом по-другому. Например, возьмем мониторинг. В ИТ-организации все решения, связанные с диагностикой инфраструктуры, принимаются в централизованной службе поддержки, на второй линии. В железнодорожной инфраструктуре 80% диагностики осуществляется путем индивидуальных осмотров, то есть принятие решений делегировано людям «вниз». Если основные квалификации сосредоточены непосредственно на местах, функции и полномочия единой диспетчерской принципиально меняются. Ее сотрудники фактически не обладают никакой квалификацией в технологических процессах, но при этом они должны иметь абсолютную власть с точки зрения управления. Это необходимо предусматривать в интеграционных тестах при создании Service Desk, когда вы соединяете инциденты с плановыми работами. Это лишь одна из сложностей, таких примеров наберется на отдельную брошюру.

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

Сообщалось, что следующим этапом вы планируете внедрение управления знаниями. Что имеется в виду?

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

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

Внедрение HP Service Manager сопровождалось большой работой по изменению технологической инфраструктуры. Расскажите об этом поподробнее.

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

На каком этапе сейчас реализация проекта?

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

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

Тиражирование опыта МЖД пройдет без проблем?

Мы реализовали типовые процессы управления на самой сложной дороге в РЖД. Если это работает у нас, в масштабах всей отрасли нерешаемых задач не будет.

Есть ли уже отклики от потребителя сервиса?

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