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

Провал “внедрения ITIL” – всегда проблема внедрения, а не ITIL

Опубликовано 9 декабря 2010
Рубрики: ITIL, Аналитика: точка зрения, Всё это - ЛЮДИ, Обо всём на свете, Процессы
Комментарии

Скептик: "В неуспешности использования ITIL в конкретной организации всегда кто-то виноват:

  • Вендор продал чудо-ягоду, наобещав лишнего;
  • Консультанты ведут теоретические рассуждения и ничего не меняют на практике;
  • Руководители устанавливают нереалистичные цели вроде "12 процессов за 12 месяцев" и при этом не выделяют финансирования;
  • Работа выполняется внешним подрядчиком, чья продуктивность измеряется количеством написанных документов и их объемом;
  • Никто не уделяет внимания человеческой составляющей в проекте…

ITIL – не формула и не инструкция. Поэтому не может привести нас ни к провалу, ни к успеху. Мы идем туда сами."

Также по теме:

Профессиональные деловые игры
для ИТ-департаментов и ИТ-компаний

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

  • Руслан

    Сверх скользкая тема. Если с людьми “что-то не то”, начальников этих самых людей можно смело распускать.

    ITIL это не бином Ньютона, “делать ITIL” (выполнять регламенты и пользовать систему автоматизации) может любой школьник. Если заказчик не может “инициировать” своих людей “делать ITIL”, ни вендор, не интегратор не сможет подавно. Тут мы снова возвращаемся к магии, заговорам и тарелочкам.

    • Роман Журавлёв

      а почему “с людьми что-то не то”? Вроде такого тезиса у Скептика нет?..

      • Руслан

        Смутил этот тезис:
        Никто не уделяет внимания человеческой составляющей в проекте…

        К слову, Скептику не мешало бы чётче формулировать, “человеческая составляющая” – это что за зверь? нет в v3 такого процесса! 😉

        Про что это?
        – про сопротивление изменениям?
        – про недостаток компетенции?
        – про сложность предметной области?
        – про мотивацию (бабки)?
        – про лень?
        – про саботаж?

        • Роман Журавлёв

          Ну, четче формулировать надо не столько Скептику, сколько переводчику. В оригинале эта фраза выглядит так:
          “Everyone ignores the people aspects and changes nobody”

          Думаю, что знаю, что он имеет ввиду.

          Вот цитата из него же (но из другого места):
          “Люди – Процессы – Технологии (People Process Technology) – это базовая модель, применяемая к любой ИТ-инициативе. (…)
          Важно выбрать верный порядок вовлечения этих элементов (люди, потом процессы, потом технологии) и поддерживать баланс элементов в дальнейшем.
          Мы часто начинаем с технологий, время от времени начинаем с процессов и почти никогда – с людей (культура, команда, поддержка, энтузиазм…).
          Технологии работают там, где они воспринимаются как инструмент, помогающий людям и поддерживающий процессы, там, где они были выбраны или спроектированы для процессов и людей, и там, где люди и процессы могут работать хорошо независимо от наличия технологий.
          Технологии помогают людям работать рациональнее и повышают стабильность процессов. Очень редко они делают возможным что-то, что не было возможно без них.
          Иначе говоря, хороший персонал может работать при плохих процессах и неэффективном ПО; хорошие процессы могут компенсировать неэффективность ПО; но установка лучшего ПО не может исправить плохие процессы, и лучшие в мире процессы не способны создать хороших людей.”

  • Павел Солопов

    Консультанты ведут теоретические рассуждения и ничего не меняют на практике

    Вот давно мучающий меня вопрос: А консультанты должны что-то менять самостоятельно невзирая на отношение к этому заказчика консалтинга? Или всё же дело консультантов давать советы, а реализовывать их должен сам заказчик?

    Я вот как-то больше склоняюсь ко второму варианту, но может быть я безнадёжно заблуждаюсь?

    • Дмитрий Исайченко

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

      • Олег Скрынник

        Получается, что есть две крайности.

        Первая – когда консультант отвечает за результат рублём. Стало клиенту после консалтинга лучше – получите больше, не стало – получите меньше. Такая практика (как и на рынке здравоохранения, кстати), в консалтинге носит случайный и единичный характер. Сложности с ней понятны: консультантам так работать рисково, оценить “стало лучше” – сложно, существенная часть улучшений, либо их отсутствия, зависит от самого клиента и т.д.

        Вторая крайность – консультант “даёт советы” и ни за что не отвечает вообще. Такое встречается сплошь и рядом, но, вполне возможно, это связано с незрелостью рынка, клиентов, низкой конкуренцией или чем-то ещё. Хочется верить, что такого рода “консультанты” не смогут выжить, однако жизнь показывает обратное.

        Истина, скорее всего, между этими двумя крайностями. Нет?

        • Павел Солопов

          Честно говоря, не совсем представляю истину, которая рядом…
          Это как? Консультант отвечает рублём но немножко?

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

          • Олег Скрынник

            “Между двумя крайностями” – я так думаю, что это не вопрос деления гонорара, а вопрос деления ответственности.

            Если за всё отвечает консультант – это глупо и не работает, по известным причинам.

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

            Тогда (продолжая собственные рассуждения) нужно описать, разграничить ответственность между двумя этими сторонами, консультантом и клиентом. Чтобы точно стало лучше, кто за что должен отвечать?

            • Павел Солопов

              А это реально? Насколько сложным получится “меморандум” о разграничении отвтетсвенности, есть ли инструменты контроля?
              Вы применяете это в своей практике?

              • Дмитрий Исайченко

                Применяем.

              • Олег Скрынник

                Предположим, проектируется какой-либо процесс управления. В нём определяется роль менеджера процесса. В большинстве случаев менеджер не является единственной ролью в процессе, есть и другие. Эти другие должны работать в рамках процесса и на пользу дела, менеджер должен обеспечить их работу в рамках и на пользу. Хотят они или не очень.

                Мне кажется, что провести границу “за что отвечает менеджер” и “за что отвечают другие роли процесса” можно. Наверное, можно и с парой консультант-клиент, разве нет?

                • Павел Солопов

                  Не очень удачная аналогия, её с таким же успехом можно закончить фразой “наверное можно и с парой врач-пациент, разве нет?”

                  И менеджер процесса и другие участники являются исполнителями, заказчиком же является кто-то иной, заказчиком их работы, имеется в виду. Это либо руководитель ИТ, либо предприятия, либо кто-то ещё из топов или их группа.
                  Для того, чтобы схема менеджер-участники процесса заработала, нужно чтобы Закзачик этого захотел. Он должен дать всем соответствующие права и вменить обязанности. В противном случае менеджер не сможет ничего сделать, если ему не дали прав влиять на участников процесса, а им не вменили в обязаности прислушиваться к менеджеру.
                  В этом случае мы получаем не управление процессом, а управление народными массами, где всё зависит от харизматичности менеджера.
                  Также и с консультантами, у консультанта нет рычагов влияния на сотрудников какой-либо организации, поэтому либо заказчик должен сказать: все слушайтесь их, и делайте что скажут. Либо должен сам слушать и затем уже транслировать на своих подчинённых.
                  Иначе опять же всё зависит от харизматичности консульатнта, удастся ли ему уболтать сотрудников принять новую модель работы или нет.

      • Павел Солопов

        Можно ли научить того, кто не хочет учиться. Ведь такие случаи нередки, когда обращаются к консультантам, но не готовы воспринимать новое и меняться.
        “сделайте нашу жизнь лучше, но не меняйте её…”

        • Олег Скрынник

          Вряд ли это чёрное и белое – хочет учиться, не хочет учиться. Градаций, наверное, сильно больше двух.

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

          Помнится на менеджерском курсе по ITIL v2 была классная картинка нормального распределения – как люди относятся к изменениям. На этом месте всегда возникала дискуссия что делать с теми, кто “против”.

          • Павел Солопов

            При определённой детеализации всегда можно найти полутона и оттенки, но не всегда это нужно.
            Думаю, что в данном случае нам достаточно укрупнённого уровня Хотят/не хотят меняться.
            Надо конечно сделать примечание, что речь здесь про потребителя/заказчика консалтинговой услуги. Само собой допускается вариант, когда проблема поставленная перед консультантом ставится так: помогите нам поменяться, чтобы сделать жизнь лучше, и подскажите, как быть с теми, кто меняться не хочет.
            Но когда сам заказчик не хочет меняться, вот тут беда.

            • Дмитрий Исайченко

              Почему? Большинство сотрудников не хотят меняться и это не беда – это естественно. Т.е. я хочу сазать – Заказчики тоже люди 🙂

              • Павел Солопов

                Дмитрий, давайте разложим по полочкам. Заказчиком работ является один или несколько человек, которые ставят задачу и принимают решение о успешности или неуспешности этих работ. Как правило это руководство организации, сотрудники же организации в этом случае являются объектом с которым собственно эти работы и проводятся.
                Объект может и не хотеть меняться и учиться, это становится дополнительной задачей, как решеить проблему его противодействия.
                Но если этого не хочет и Заказчик…
                Это примерно, как если вы зовёте строителей сделать вам ремонт в квартире, но говорите им “в квартиру я вас не пущу, но ремонт сделайте”.

                • Дмитрий Исайченко

                  Павел, я с Вами полностью согласен – прекрасная аналогия. Но соласитесь, и такое бывает на практике. Достаточно вспомнить избитую цитату из Салтыкова-Щедрина: “Они сидели день и ночь, и снова день, и снова ночь, и думали, как свое убыточное хозяйство превратить в прибыльное, ничего в оном не меняя”.

                  • Павел Солопов

                    Судя по многовековой традиции это претендует на “Лучшую практику”. 🙂

                    А намоните-ка мне невежде, чем там у классика всё закончилось?

                    • Дмитрий Исайченко

                      Павел, к стыду своему я в том же окопе невежд (грустно жму руку). Я понятия не имею чем закончилась эта история у классика. Но думаю – ничем хорошим.

                      Если узнаете ответ раньше, поделитесь пожалуйста 🙂

            • Олег Скрынник

              “При определённой детализации всегда можно найти полутона и оттенки, но не всегда это нужно. Думаю, что в данном случае нам достаточно укрупнённого уровня Хотят/не хотят меняться. “

              Мой любимый доктор Хаус считает, что все люди – идиоты. Если мы сводим до двух крайностей, то я, пожалуй, соглашусь с доктором 🙂

  • Роман Журавлёв

    То, что все люди – идиоты, считает Скотт Адамс в “принципе Дилберта”. Грегори Хаус считает, что все люди врут.
    Впрочем, тут может быть связь…

    • Олег Скрынник

      Ром, ты прав, конечно же. Просто Хаус так часто повторяет “You’re idiots!” что я привык думать, что он так про всех считает.
      А Скотт Адамс это заявляет прямо.

Добавить комментарий

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.