"Легко сказать: мы переходим к процессному управлению. Но очень непросто это сделать"

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

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

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

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

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

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

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

— На пресс-конференции вы упомянули, что следующим этапом планируете внедрение управления знаниями. Что имеется в виду?

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

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

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

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

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

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

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

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

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

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

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

— Что было самым сложным в проекте?

Любой руководитель, который возьмется применять сервисный подход у себя в компании, столкнется с огромной сложностью, о которой надо знать заранее. Очень легко сказать: мы переходим к процессному управлению. Но очень непросто это сделать. Хотя, казалось бы, что может быть проще – определить менеджера по управлению плановыми работами. Не хозяйственника, который будет отвечать за те или иные функции, а менеджера, ответственного за плановые работы по всем хозяйствам. Но выделить менеджеров процессов, которые 100% своего времени будут заниматься этой работой, оказывается самым сложным в этой задаче. Часто думают, что это появится само собой, потом. Не появится. Пока конкретно не будет определен человек, который головой отвечает за процесс, ничего не будет.

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