Портал №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\исполнитель с необходимыми изменениями отношений (дополнительные деньги и компетенции со стороны заказчика).


Добавить комментарий для Nargiza SuleymanovaОтменить ответ

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

  • Рубрики

  •  
  • Авторы

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

    • Метрики потока создания ценности
      Свой первый отчёт с данными о работе процесса в ИТ я сделал где-то в самом конце 90-х годов. Я тогда работал в поддержке, мне было важно понять как быстро мы выполняем заявки,
    • Я понял только то, что ничего не понял
      На тему услуг написано довольно много самых разных статей, т.к. оказание услуг – самый распространенный вид человеческой деятельности. Банковские услуги, гостиничные услуги, юридические услуги, логистические услуги; парикмахер, курьер, айтишник – все это деятельность в сфере услуг. Моя работа тоже относится к этой же сфере, поэтому не могу не поделиться своими наблюдениями, или, как говорится, поговорить о наболевшем.
    • DevOps-путешествие American Airlines
      Несколько лет назад компания American Airlines начала путешествие, которое первоначально было направлено на преобразование DevOps в ИТ, но в дальнейшем набирало обороты и переросло в преобразование доставки продуктов, охватывающее весь бизнес.
    • Чтение признаков: Паттерны диаграммы рассеяния (Lead Time Scatterplot)
      Научившись определять общие закономерности в диаграмме рассеяния времени цикла, вы сможете заметить проблемные области до того, как они разрастутся. Сегодня мы покажем вам, как распознать наиболее распространенные модели диаграммы рассеяния и объясним, что они означают для вашего проекта.
    • Проблемные зоны цифровой трансформации
      Управление на основе гибких методологий подразумевает наличие гибкой команды, занимающейся развитием цифрового продукта. Однако, такие команды не возникают сами собой, их
    • Чтение знаков: Паттерны Канбан CFD
      Чтобы улучшить рабочие процессы, сначала нужно понять, как определить проблемные области. Метод Канбан использует визуальные методы для оценки ваших процессов. Диаграмма совокупных потоков Канбан является особенно мощным инструментом. На них фиксируется количество задач в каждом состоянии процесса через регулярные промежутки времени, как правило, ежедневно или еженедельно.
    • Краткое руководство по DevOps для не ИТ-руководителя бизнеса
      Тщательно продумайте, как выглядит успех. В цифровом мире это скорость, гибкость, контроль и оперативность, а не составление планов и следование им. Именно эти новые ИТ-практики принесут вам эти преимущества. Они уже принесли их многим другим предприятиям, которые встали на этот путь и, в некоторых случаях, разрушили отрасли.
    • 8 тенденций развития IT Service Desk в 2022 году
      Корпоративная служба поддержки ИТ в настоящее время находится в «идеальном шторме» для изменений или, точнее, в «идеальном шторме» для необходимости изменений. Случилось так
    • 6 худших вещей, которые продакт-менеджеры говорят инженерам
      Каждый хороший продакт-менеджер — полиглот. Он говорит на нескольких языках. Конечно, вы можете не говорить бегло на французском, итальянском или мандаринском. Но вы
    • На какой курс пойти, чтобы узнать про практику Х?
      Этот вопрос вы, наши слушатели, задаёте довольно часто. К тому же появились новые курсы категории VAP. Так что было бы удобно иметь под рукой справочник. Ну что же, вот оно:
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT