Какой квалификации, каких навыков не хватает подрядчикам, ведущим проекты для компаний финансовой корпорации «Уралсиб»? Об этом редактору CRN/RE Ольге Мельник рассказывает Андрей Пронин, заместитель главного исполнительного директора главной исполнительной дирекции информационных технологий. В беседе принимает участие Андрей Нарсия, также заместитель главного исполнительного директора главной исполнительной дирекции по ИТ.
CRN/RE: В сфере вашей компетенции контроль и мониторинг множества ИТ-проектов «Уралсиба». Как вы оцениваете уровень проектного управления интеграторских компаний?
Андрей Пронин: Как совершенно недостаточный. На мой взгляд, наблюдается острая нехватка ресурсов для ведения проектов, причем не на уровне технических специалистов, а на управленческом уровне. Проектная деятельность существенно отличается от постоянно выполняемой, есть набор методологий управления проектами, в том числе широко известный свод правил PMI. Но создается впечатление, что многие компании (поставщики услуг, интеграторы) этими методиками не владеют. Работа строится не на основе методики, а на честном слове, опоре на авторитеты, или как регулярно выполняемая деятельность. Постоянно нарушаются общие правила и рекомендации методологии проектного управления. Многие проекты неуспешны именно поэтому. Считаю, что это происходит из-за нехватки квалифицированных ресурсов, которые должны организовывать такую деятельность.
Проектное управление обоснованно считается более дорогим потому, что подразумевает следование неким правилам: составление отчетных документов, ведение плана-графика и пр. Возможно, не всему, что требует методология, нужно следовать в каждом проекте, но без ключевых принципов проект сразу обречен на провал. Если нет общего плана работ, если его не придерживаются, ничего хорошего не будет совершенно точно. Не обязательно всякий раз писать отчеты о рисках, проблемах, но цели и задачи, рамки проекта должны быть четко описаны, причем однозначным образом, понятным и заказчику, и исполнителю. Часто бывает совсем иначе, у каждой стороны свое мнение о том, что входит в данный проект, а что нет. Необязательно менеджер должен быть сертифицированным по PMI, но основы проектного управления, понимание особенностей именно этого вида деятельности у него быть должны. Есть основной вводный курс в обучении проектных менеджеров. Если бы каждый, кто берется управлять проектом, прослушал хотя бы этот курс, то вопиющих ошибок было бы меньше.
CRN/RE: Но управление «по понятиям» на российском рынке, в том числе ИТ, не новость и не диковинка. Может быть, если нет проектного управления «в чистом виде», то оно и не нужно?
А. П.: На одном авторитете руководителя проекты делать невозможно. Если компания большая, то одних только VIP-клиентов у нее достаточно много, и первое лицо при всем желании не удержит в голове все свои обещания и договоренности. Возникает узкое место, бутылочное горлышко такой компании. Только менеджеры, способные квалифицированно вести проектную деятельность, могут поддержать обещания первого лица. Иначе неминуемы постоянные срывы. Возможное исключение — очень крупный проект, в исполнении которого первое лицо заинтересовано настолько, что лично берется управлять им, уделяет ему большую часть своего времени.
По моему мнению, причина отсутствия проектного управления — просто нежелание. Проектное управление более сложное и более дорогое, здесь необходимо напрягаться. Проще, разумеется, всего этого не делать. До тех пор, пока деньги платятся и за такую работу, положение не изменится. Как только подрядчики поймут, что отсутствие грамотного проектного управления стало тормозом в их развитии, в получении доходов, тогда они и начнут учить своих сотрудников. Пока же уровень подготовки планов, уровень описания самих проектов довольно низкий. Судя по тем ошибкам, которые мы постоянно исправляем в предоставленных нам документах, средний уровень просто удручающий. Есть компании, которые могут представить нормальные качественные планы, но большинство других вообще этого не делают: просто не в состоянии.
CRN/RE: Обычно крупные заказчики, к которым безусловно относится и ваш холдинг, могут навязать подрядчикам удобные им правила игры.
А. П.: Конечно, как большой заказчик, мы можем «построить» любого подрядчика, но только если он вообще способен «строиться». Если нет, приходится отказываться от его услуг. Но бывает и так, что мы не можем отказаться по каким-то причинам и тогда идем на компромиссы. Очень многие подрядчики записывают в бюджет графу «управление проектом», но по итогам мы отказываемся ее оплачивать ввиду полного отсутствия такого управления.
Мы готовы платить за качественное проектное управление. Даже элементарные прикидки показывают, что только одно сокращение сроков (вернее, если выдерживать запланированные) проектов вполне окупает все затраты на методологически правильное управление. Ведь чаще всего проекты затягиваются из-за некорректного мониторинга, попросту говоря, из-за недостаточного контроля и «стимулирования» участников проекта со стороны проектного менеджера.
CRN/RE: Каким образом вы сами и другие менеджеры вашей компании получили навыки проектного управления?
А. П.: Несколько лет назад у нас в корпорации приняли решение о повышении квалификации всех менеджеров в проектном управлении, и все они прошли обучение. В компании были разработаны и приняты нормативные документы, основанные на PMI, но учитывающие сложившуюся практику и наши внутренние особенности. У нас создан институт проектных менеджеров, институт администраторов проектов. Все крупные корпоративные проекты, не только в ИТ, выполняются по методикам проектного управления.
CRN/RE: Сервисный подход в ИТ, сервисно-процессный метод управления ИТ: насколько вашей компании близки эти подходы, находите ли вы их у подрядчиков?
А. П.: Чтобы компания перешла на сервисно-процессный метод управления ИТ, она должна иметь соответствующий уровень зрелости. Это описание своей деятельности, внедрение основных ITIL-процессов: управление инцидентами, конфигурациями, изменениями, проблемами. Мы должны быть в состоянии описать свой каталог предоставляемых услуг, дать характеристики сервисов, определить метрики контроля их качества. До этого уровня как многие исполнители, так и многие заказчики еще просто не доросли. И требовать от незрелой компании в договоре соблюдения этих метрик невозможно. Такие исполнители обычно стараются метрики в договорах оспорить или вообще опустить. Многие интеграторы даже не имеют квалифицированного сервис-деска. Они еще не дозрели до того, чтобы профинансировать эту деятельность.
Формальных критериев оценки зрелости при выборе подрядчика у нас нет, но всегда есть экспертная оценка, в том числе по резюме предыдущих заказчиков. При проведении конкурсов мы стараемся повысить вес критериев отбора, связанных со зрелостью подрядчика, но не всегда это удается — у бизнес-подразделений могут быть свои, более весомые требования. Бывает так, что невозможность полной смены системы вынуждает продолжать работать с подрядчиком, который ее обслуживает, даже если он делает это плохо. «С крючка внедрения определенного ПО очень тяжело соскочить». Чаще всего дешевле мириться с низким уровнем сервиса, чем менять систему.
О том, как может и должен работать сервис-деск, мы судить можем. В «Уралсибе» собственный сервис-деск обслуживает около 20 тысяч обращений в месяц. Это централизованная система всей корпорации, по крайней мере для подразделений центральных офисов в Москве и Уфе и по всем централизованным системам. Формальные SLA с бизнес-подразделениями у нас уже есть, но только по части сервисов. Это 3 «пилотных» подразделения, 5 сервисов, проект по внедрению SLA у нас находится в самой активной фазе. Для пилотного внедрения выбраны подразделения, где показательная статистика по запросам, ну и соответственно те, которые сами согласились пойти на такой эксперимент. Среди сервисов были выбраны самые востребованные, обслуживание рабочих мест, например. Кроме того, те сервисы, по которым более подготовлены менеджеры. Хотя по ITIL у нас тоже прошло практически массовое обучение сотрудников ИТ на уровне среднего менеджмента, менеджеров сервисов и лидеров команд, примерно 40% всего ИТ-персонала такую подготовку прошли. Мы хотим попытаться оценить свою зрелость по CoBIT, считаем важным иметь такие оценки.
Андрей Нарсия: В последнее время мы стали включать в условия некоторых конкурсов наличие формальных критериев зрелости, скажем, при поиске подрядчика для заказной разработки требуем CMMI4. Сразу из 20 претендентов 16 отпали. Опыт показывает, что если у подрядчиков нет такой формальной сертификации, то у них нет и технологии разработки, и сроки проекта растягиваются многократно за счет того, что подрядчики якобы «не поняли», что нам нужно, постоянно возникают какие-то недоразумения. У нас есть опыт общения с компаниями, которые и на второй-то уровень CMMI с трудом могут претендовать. Вначале обещают сделать все что угодно за оговоренные деньги, лишь бы получить заказ, а потом начинаются многочисленные оговорки. Проект вместо 8 месяцев тянется 2 года. Почему? Потому что здесь нас не так поняли, тут нас не спросили, хотя должны были бы, и так далее.
Если мы говорим с компанией, у которой такой сертификат есть, то видим: процессы у подрядчика отстроены, он может четко сказать, сколько какие работы будут выполняться и почему, у него все разложено по полочкам. Нам сразу задают вопросы, связанные с постановкой задачи, и у нас есть уверенность, что сроки будут соблюдены. Разница в цене между двумя такими компаниями — в три раза. И нам внятно объяснили, почему у одной из них цена выше. Мы скорей согласимся с этой ценой, чем с продолжением неразберихи со сроками и функционалом другой компании. При этом возникает понимание, что у первой — реальная цена, а остальные просто морочат нам голову.
Два-три года назад имела значение только цена, она была главным фактором выбора. Теперь она тоже имеет значение, но не первостепенное. В конце концов, нам, как менеджерам корпорации, совершенно неинтересно выносить на внутренние комитеты обсуждение того, почему проект до сих пор не готов и в результате чего сложилась такая ситуация.
Что есть что
CoBIT — Control Objectives for Information and Related Technology, «Контрольные объекты для информационных и смежных технологий». Набор открытых документов, около 40 международных и национальных стандартов и руководств в области управления ИТ, аудита и ИТ-безопасности. В него входят технические стандарты, стандарты управления качеством, аудиторской деятельности.
CMMI4 — CMMI (Capability Maturity Model Integration) — международный стандарт качества, оценивающий уровень процессов разработки и сопровождения ПО. CMMI был разработан в 90-е годы Институтом разработки программного обеспечения (Software Engineering Institute, SEI) при университете Карнеги — Меллона (Carnegie Mellon University). CMMI предусматривает пять уровней зрелости компании. Для сертификации на 4-й уровень требуется определить все процессы производства и описать правила их адаптации к условиям конкретных проектов. При этом управление компанией в целом и проектами в частности должно базироваться на количественном анализе данных об осуществлении процессов. В России лишь несколько компаний имеют сертификат CMMI4, по CMMI3 сертифицированы десятки, почти все они — экспортеры ПО и услуг.
CRN/RE: Кроме заказной разработки, ведете ли вы какие-либо аутсорсинговые проекты? Есть ли у вас критерии передачи какой-либо деятельности на аутсорсинг?
А. П.: Если это деятельность временная и не занимает полный рабочий день, то ее можно передавать в профильные компании, и есть шанс, что такой аутсорсинг будет дешевле. Но если она занимает полный рабочий день собственного сотрудника, смысла передавать ее на аутсорсинг нет. Это будет дороже, хотя бы на тот же НДС. Это и есть наш критерий, результат практики. У нас был опыт передачи сервисов, не связанных с ИТ, таких как уборка помещений, питание сотрудников, и он оказался негативным.
Посчитать стоимость труда своих ИТ-специалистов мы можем очень точно, учитывая статистику сервис-деска, и такие расчеты мы делали и сравнивали с рыночным предложением. По нашим оценкам, получается, что своими силами дешевле.
А. Н.: У нас были переговоры с компаниями, заявлявшими, что у них есть сеть представительств и они могут оказывать нужные нам сервисы по всей территории, где мы действуем. Речь шла о поддержке корпоративной телекоммуникационной сети, она у нас единая, мы ее стандартизовали и хотели найти подрядчика, способного поддерживать ее на всей территории. Это было год назад. Но после подробной оценки предложений и расчета стоимости собственной поддержки мы эти попытки оставили, поскольку видно, что рынка таких услуг пока нет. Но и на местном уровне, в наших филиалах, когда есть выбор — либо отдать на ауторсинг какие-то функции, либо держать своего человека, — практика такая: сначала пытаются отдать, потом возвращаются к тому, чтобы это делал свой сотрудник.
Если говорить о централизации ИТ-деятельности, то у нас возможны разные варианты. Есть централизованные договоры на поставку ПК, например, и некоторых типов ПО, а вот от централизованной работы с «Консультантом» мы отказались, поскольку их канал дистрибуции построен совсем иначе, у них ПО регулярно обновляют местные компании, и локально сервис получается дешевле.
Так что схемы могут разнообразными, но вопрос компетенции, адекватной квалификации, готовности подрядчиков следовать нормам, уже ставшим для нас привычными, остается актуальным.