Он-то знал, почему ГС  вечно не хватает. Чтобы получить это звание,
необходимо выполнить пять докторских работ в не связанных между
собой областях и пройти трехгодичный курс специальной подготовки.
ГС получали к пятидесяти годам. В шестьдесят — семьдесят лет они
становились бесценными и буквально творили чудеса и в том же возрасте
вынуждены были оставлять свою деятельность и уходить на пенсию.

Гордон Диксон, "мистер Супстоун"

Так получилось, что этой весной мне пришлось думать, читать и спорить о сути и особенностях работы ИТ-консультанта вообще и ITSM-консультанта в частности. Сначала был курс ITSM Consultant/Manager, потом вебинар  об организационных изменениях в ITSM-проектах, а на этой неделе мы говорили об ИТ-консалтинге со слушателями программы MBA в Университете управления. 

И вот что получается. Консалтинг – неприлично широкое понятие. За этим словом скрываются работы по интеграции, техническому и техническому сопровождению, обучению, коучингу, проектированию и т.д., и т.п. 

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

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

Сложнее и труднее – методическое сопровождение, когда консультант точечно привлекается к планированию и реализации преобразований, выполняемых заказчиком самостоятельно. Здесь важно не только глубоко знать предметную область, но и отлично понимать контекст организации-заказчика, причем поддерживать актальность этого понимания, при том, что ни постоянного пребывания в этой организации, ни системного информирования консультанта о ее новостях формат методического сопровождения не предполагает, а сама эта работа часто ведется параллельно с другими. И главное, рекомендации консультанта в этом случае выходят за рамки справок о предметной области. Заказчик ждет оценок и советов, а не рассказа о том, что "и так можно, и вот так можно". 

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

Задачи проекта по реорганизации практик управления ИТ (такие проекты широко известны под псевдонимом "Внедрение процессов") можно сформулировать примерно так:

1. Проектирование новых практик управления ИТ (процедур, оргструктуры, интсрументов автоматизации…)
2. Проектирование механизмов контроля и совершенствования практик управления ИТ
3. Организация перехода из текущего состояния к спроектированному
4. Обеспечение закрепления новых практик, спроектированных в пп. 1 и 2

Не всегда в конкретном ITSM-проекте перед консультантами ставятся все перечисленные задачи. Вероятность их включения в охват проекта снижается от первого к четвертому пункту: новые практики консультанты проектируют почти всегда, а за их закрепление не отвечают почти никогда. Это, конечно, мое личное впечатление, статистики у меня нет. Впечатление основано на информации, полученной от участников и жертв многих ITSM-проектов, проведенных разными консультантами в разных компаниях за много лет.  И мне кажется, что у этой тенденции есть причины. Они таковы:

1. При согласовании проекта заказчиком и консультантом акцент делается не на целевом состоянии организации, а на конкретных инструментах, которых, по мнению заказчика, не хватает его организации: системах автоматизации, процедурах, знаниях… Заказчик при этом склонен пероценивать новые инструменты и свои  способности применять их, а также недооценивать сопротивление сотрудников изменениям.
2. Консультант стремится брать на себя формальную ответственность только за результаты проекта, которые он полностью контролирует. По мере движения от первой проектной задачи к четвертой число внешних факторов, влияющих на результат, растет, а непосредственно зависящих только от консультанта – падает.
3. Консультант не умеет решать задачи №№3 и 4: его компетенция – ITSM (например) и процессное управление, а не организационные изменения. Он этому не учился, знает об этом мало, и все, что знает, подтверждает сомнения из предыдущего пункта. 

Есть и другие, но этих причин вполне достаточно, чтобы исключить задачи по приживлению новых практик в организации из обсуждения на этапе продажи проекта и, разумеется, из самого проекта. Неудивительно, что после этого 82% ITSM-проектов не приносят ожидаемого полезного эффекта – результативность примерно как у проектов постройки летательных аппаратов для Red Bull Flugtag: там тоже число красиво падающих существенно превышает число хоть куда-то летящих, но в процессе постройки и запуска всем очень весело. Только там ведь и цель – чтобы было весело… 

На самом деле причины номер один и два суть следствия действия причины номер три. То есть для того, чтобы ITSM-преобразования проходили успешно, необходимо:

Формировать и развивать компетенции в области организационных изменений в среде ITSM-консультантов и ИТ-руководителей.  

• ITSM-консультант должен знать и уметь: предметную область (ITSM), управление процессами, управление проектами и управление организационными изменениями. Каждая область многослойна, в каждой есть свои своды знаний и стандарты, свои трудности и особенности, и во всем этом надо разбираться глубоко, широко и (не могу удержаться) на всех уровнях таксономии им. тов. Блума. 

Управлять ITSM-проектами как проектами организационных изменений, а не как проектами проектирования процессов и тем более не как проектами внедрения систем автоматизации.​​

• Заказчики ITSM-проектов должны соотвтетсвующим образом определять цели проектов и ставить задачи консультантам, и нанимать консультантов, способных такие задачи решать. 
• Методика ведения проектов – от проектирования до запуска новых практик – должна обеспечивать  реализацию организационных изменений. В частности, путем вовлечения персонала заказчика в проектирование и распространение новых практик.
• Руководство заказчика должно поддерживать проект на всех его этапах – явно, громко, словом и делом,  и именнно как проект изменения работы организации, а не как проект "внедрения ITIL".

Понятно, что такое встречается в жизни нечасто. Понятно, почему хороших ITSM-консультантов единицы, а если учесть, что и грамотных заказчиков – тоже не большинство, понятно, почему успешных проектов так немного.

Отрадно, что есть и хорошие консультанты, и грамотные заказчики, и успешные проекты. И есть достойная задача – делать так, чтобы и того, и другого, и третьего становилось больше. 

ИНТЕНСИВ С ТРЕНЕРОМ

Управление проектами на основе PRINCE2

Трёхдневный аккредитованный учебный курс