Портал №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 не будет опубликован.

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • Внедрение ИИ для вашей службы поддержкиВнедрение ИИ для вашей службы поддержки
      Но что на самом деле означает внедрение ИИ для возможностей ITSM вашей организации, особенно для службы технической поддержки?
    • Бесплатная конференция IT-Entrance для тех, кто хочет стать айтишниками
        28 мая в Минске пройдет бесплатная 11-я международная конференция IT-Entrance. Это мероприятие для тех, кто хочет попасть в IT, для начинающих IT-специалистов уровня junior с
    • ITIL 4 Specialist: High-velocity IT. Что внутри?
      В дополнение к уже опубликованным обзорам курсов по направлению Managing Professional (MP) сертификационной линейки ITIL4, сегодня мы рассмотрим еще один модуль – ITIL 4 Specialist: High-velocity IT (HVIT).
    • Весення уборка в бэклоге продукта: порядок за четыре шага!
      Каждая команда, которая ведёт разработку ПО в соответствии с практиками Agile, имеет бэклог продукта или по крайней мере думает, что он у неё есть. Кажется, что это очень простой инструмент, но на практике я регулярно сталкиваюсь с неумением им пользоваться для планирования работы разработчиков. Давайте попробуем разобраться, для чего нужен бэклог продукта и как извлечь из него максимум пользы. 
    • Warranty и Utility в ITIL4
      У услуг, которыми мы управляем в рамках Service есть две основные характеристики: гарантия — Warranty и Utility — полезность. Эти характеристики нужны нам, чтобы определить, будет ли услуга способствовать достижению результатов, которые нужны пользователю, а как следствие — создавать для них ценность.
    • Шесть практик для лучшего взаимодействия бизнеса и ИТ
      Хотели бы вы, чтобы руководители предприятий и ИТ могли лучше работать вместе, совместно работать над проектами и в полной мере обмениваться информацией? Если вы похожи на большинство ИТ-руководителей, ответ — да. Преимущества эффективного сотрудничества между бизнесом и ИТ включают в себя специальные проекты, которые лучше соответствуют бизнес-целям, улучшенное управление изменениями и более активное участие в новых инициативах.
    • Используйте технологии для повышения эффективности рабочего процесса вашей ИТ-команды
      Эффективное рабочее место создает, так сказать, хорошо смазанную машину, повышая итоговую прибыль и, как следствие, успех вашего бизнеса. Дополнительное время на работе не всегда означает большее достижение. Важно то, что вы делаете с тем временем, которое у вас есть, а это все об эффективности рабочего процесса.
    • Хранение данных и «внутренний хомяк»
      Хранение информации, которая больше не пригодится, сопряжено со огромным количеством рисков. Иллюстрация этому — череда сливов персональных данных пользователей крупных сервисов, которую мы могли наблюдать с января по март. Кажется, что предприятиям нужны правила, когда и как избавляться от данных.
    • Action BiasAction Bias — известная ловушка, в которую мы всё равно постоянно попадаем
      Action Bias: склонность к реагированию и действию, даже если это не приведёт к положительным результатам. «Делать хоть что-то» создаёт иллюзию загрузки ресурсов полезной работой.
    • бэклог27 антипаттернов бэклога продукта
      Эта статья показывает 27 распространённых антипаттернов продуктового бэклога, включая процесс уточнения бэклога продукта, ограничивающих успех вашей Скрам-команды.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT