Портал №1 по управлению цифровыми
и информационными технологиями

ITSM Консультант / Менеджер = ?

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

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

Так получилось, что этой весной мне пришлось думать, читать и спорить о сути и особенностях работы ИТ-консультанта вообще и 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»
Трёхдневный аккредитованный учебный курс

Комментариев: 15

  • Vladimir Lyaleko

    Уже несколько раз вижу эти заветные 82%, уверен большинство из таких проектов на самом деле ОЧЕНЬ успешные.

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

    Так рождаются проекты внедрения 15 процессов за 5 дней. Так рождаются сотни страниц документации, которые никто не читал, золотые системы автоматизации, которые никто не использует и т.д. Деньги заплачены, защита перед аудитором есть. Мега успешный проект. 

    Очень здорово, когда у консультанта есть достаточная репутация, самостоятельность, чувство собственного достоинства возможность отказаться от участия в подобных "проектах". Но что делать младшему консультанту, со светлыми мыслями в голове, которому сверху спускается подобный проект? С озвученным сроком проектирования процесса в 5 дней и отсутствием бюджета на командировку к заказчику? Увольняться? Боюсь такая возможность есть не у всех. Уверен, у большинства в карьере подобные проекты были…. 

    Но это конечно у другого большинства, у нас только консультанты плохие и заказчики не грамотные  все проекты успешные 🙂

    • Nargiza Suleymanova

      Владимир, спасибо за честный комментарий!

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

    • "Но что делать младшему консультанту, со светлыми мыслями в голове, которому сверху спускается подобный проект?"

      Лично для меня это очень простой вопрос – в таком случае нужно в тот же день собирать вещи и увольняться. Умные люди говорят, что время – самое ценное, что у нас есть. Тратить самое ценное на ерунду? Вот уж нет. Младшему консультанту со светлой головой будут очень рады в Cleverics, к примеру 🙂

      Но мир не чёрно-белый. Как быть, если работа явно не "в стол", но и шансов, что она принесёт пользу, вроде бы мало? Это намного более сложный вопрос, на мой взгляд. Отчасти ответ перекликается с текстом Наргизы – может, даже в безнадёжных случаях можно найти тех, кому правда нужно. Кто правда заинтересован.

       

  • Но самое сложное и трудное — проектный консалтинг

    По-моему, самое сложное – проекты диагностики, когда за 1-2 месяца надо "понять" организацию и суметь разработать для нее полезную, обоснованную и реалистичную программу развития. Это действительно сложно.

    грамотных заказчиков — тоже не большинство

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

    • Добавлю – в тот же четверг, уже другой мой заказчик возил меня лицом по столу, приговаривая "Это что за отчет по процессу Вы нам тут нарисовали??" (хотя "Вы" может быть было и с маленькой буквы – точно не знаю). И по привычке быстро подавив в себе желание до последнего патрона защищать и отстаивать свое решение, и начав слушать заказчика, я пришел к выводу, что отчет и правда можно улучшить. Т.е. он конечно содержал в себе все, что было нужно, но после доработки стал гораздо нагляднее, полезнее для принятия решения.

      Что тут можно сказать? Две вещи. Первое – спасибо заказчику. Второе (цитата с моей футблоки) – опыт позволяет нам ошибаться гораздо увереннее. Мы совсем не идеальны, как справедливо заметил выше Владимир (если я правильно понял его мысль).

    • Боюсь, наши заказчики – не вполне репрезентативная выборка. Вот Владимир выше написал о заказчиках, с которыми мы не работаем, а их ведь таких немало, верно? 
      Впрочем, я буду очень рад, если окажется, что хотя бы в этой части я ошибаюсь, и все проблемы – на стороне консультантов. Тогда путь к всеобщей гармонии окажется сущетственно короче… Вот только как бы это выяснить?

      • Боюсь, наши заказчики — не вполне репрезентативная выборка.

        Мне сложно судить. Почему-то я думаю, что в коммереском секторе таких большинство. В том числе и у Техносерва мне известны сложные, но очень адекватные заказчики, работать с которыми и интересно, и не бесполезно (не в корзину). Владимир, что скажете?

        • Vladimir Lyaleko

          Конечно, и таких заказчиков много особенно в коммерческом секторе, но и процент провалов подобных проектов значительно меньше 82%. Прежде всего потому, что заказчик действительно заинтересован в результате и часто исправляет \ корректирует ошибки консультанта, которые встречаются даже у самых самых. И даже если проект начинается, как проект проектирования процессов, заканчивается он почти всегда как проект орагнизационных изменений.  Следовательно 82%  это только про проекты, о которых я писал выше. Оставшиеся 18% говорят о том, что даже в коррумпированных конторах есть люди заинтерисованные в результате и большая удача если с ними удается наладить контакт

          Кстати сорри за офф топ: На Вашем курсе управление и совешенствование процессов, демонстрируется типовой план график ITSM проекта. В плане речь идет исключительно про проектирование, про организационные изменения не рассказывается. Как это отражать в плане тоже. Наверно курс пора обновлять 🙂

          • Курс давно обновлен настолько, что такой график там больше не демонстрируется 🙂 Совсем. Но по сути замечание верное, то был очень старый пример, мы многое поняли с тех пор. 

             

  • Vladimir Ivanov

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

  • Grigory Kornilov

    Консультант должен консультировать. Если он берется нести ответственность за что-то – он уже или PM или исполнитель.

    Зачастую заказчик и даже сам консультант забывают это и начинается:

    1. Консультирование, когда заказчик расчитывает на PM-ство и даже исполнение.

    2. Попытка PM- ства или исполнения при отсутствии компетенции.

    Уверен, в большенстве случаев от консультанта не ожидают "новых практик", а рассчитывают на внедрение подходящих к заказчику и уже удачно опробираванных.

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

      • Vladimir Lyaleko

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

        Говорить умеют многие, брать на себя ответственность за результат единицы. ИМХО безусловно 🙂

         

        • Grigory Kornilov

          Качественная консультация включает в себя в том числе и уведомление заказчика об отклонениях, видеть ситуацию в целом это правильно, если консультацию заказали на весь проект, а не только на время подготовки ТЗ … я бы формулировал определил потребность не как "взять ответственность при необходимости", а как согласиться на исполнение роли PM\исполнитель с необходимыми изменениями отношений (дополнительные деньги и компетенции со стороны заказчика).


Добавить комментарий для Роман ЖуравлёвОтменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM