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

Вопрос из зала: завоевание умов в ITSM-проекте

Опубликовано 15 июня 2012
Рубрики: ITSM, Вопрос из зала, Всё это - ЛЮДИ, Практика и опыт, Проекты
Комментарии

Александр Пешков снова спрашивает:

Mind the gapХотел бы обсудить очень практический вопрос.

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

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

Предлагаю обсудить "идеальную методику внедрения" с точки зрения завоевания умов.

ИНТЕНСИВ С ТРЕНЕРОМ
Управление проектами на основе PRINCE2
Трёхдневный аккредитованный учебный курс

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

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

  • Станислав Уштей

    Начните с основной развилки: 1.Выстраиваются денежные взаимоотношения между Бизнесом и Сервисной ИТ-комапнией? или 2. Нужно просто навести порядок – выстроить взаимоотношения между различными ИТ-подразделениями
    Ответы на все остальные вопросы – по большому счету следствие

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

    Я, наверное, становлюсь уже совсем старым, так как очередной раз затягиваю свою любимую песню: раньше было лучше, не то, что сейчас. Раньше был такой курс, IT Service Manager, длиною в две недели. Последний, десятый день обучения был почти полностью посвящён теме организационных изменений.

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

    Видимо, трава тогда была зеленее, а деревья – выше 🙂

    Могу посоветовать почитать книги по орг.преобразованиям, коих немало. Специфики ИТ здесь совсем немного, если не считать айтишников отдельной кастой (коей они, без сомнения, являются).

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

    Вот пример любопытных рассуждений и хорошей книжки: http://www.cleverics.ru/ru/subject-field/articles/246-influencing-people-in-itsm-projects

  • Vladimir Lyaleko

    В дополнении к статье Олега, рекомендую почитать Джона Коттера.

    У него много интересных книг, которые все пляшут от 8 шагов успешного изменения.

  • Alexander Peshkov

    Почему-то есть ощущение неполного дежавю. Восемь шагов – прекрасны, но где пользователи?
    Я уже тоже начинаю грустить по временам, когда трава была зеленее – ведь тогда деревья были выше и был курс итсм-мэн.

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

      Как где пользователи? Почти на каждом из восьми шагов.

      Вспомнил классную, почти детскую книжку – “Наш айсберг тает”. Коротко, по делу, на простой иллюстрации. Коттер – молодец!

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

    Для тех, кто любит ITIL, можно порекомендовать главу 5 (“5 Managing people through service transitions”) из книги Service Transition. Там около 20 страниц, довольно любопытных.

  • Alexey Lobachev

    Идеальная методика внедрения: “Идешь и делаешь”. Все остальное – Плачь Ярославны.

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

      Попробую перефразировать.

      Проектный характер работ по трансформации ИТ имеет как несомненные плюсы (сжатый срок, чёткая задача, определена ответственность), так и существенный минус – ограничение по времени. Организационные изменения не происходят за дни и недели, и не заключаются в применении какой-либо методики или выполнении набора известных действий. Напротив, это – ежедневная работа, требующая желания, настойчивости, умения убеждать, заражать, заставлять.

      В этом смысле я очень согласен с тезисом “Идёшь и делаешь”, другого пути нет.

      Угадал? 🙂

  • Alexey Lobachev

    Компания либо готова к этому, и тогда нужно срочно переходить, либо не готова, тогда нужно увольняться.

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

      интересно, откуда тогда берутся компании, которые готовы?

      • Alexey Lobachev

        Роман, ну ты ведь сам мне читал Саппорт… 🙂 Они есть и их много. Они берутся из необходимости целевого распределения средств, финансового учета; и как правило, это компании у которых деньги есть и нужды в финансировании они не испытывают. Они испытывают нужду в контроле и прозрачности расходов, в анализе эффективности вложенийи не в суе помянутым Миши Козлова ROI.

        • Alexander Peshkov

          Алексей, приведу пример из курса SLM, который читает Лариса Будкова (замечательно читает), одна из причин внедрять SLM – “у всех есть каталог услуг, и у нас будет”. Точно такая же история и с itsm в общем. Ну вот решили внедрять. Но как же сделать это правильно?
          1. засесть в “трюме” с экспертами, написать процессы, издать указ об их внедрении
          1.1. пакетом
          1.2. процесс за процессом
          1.2.1. один за другим по расписанию
          1.2.2. один за другим с доработкой внедряемых по ходу внедрения
          2. за какое-то время заранее начать продвижение itsm в пользовательской среде и среди айтишников, по итогам семинаров собрать требования и учесть их при написании процессов, написать процессы, провести серию подготовительных семинаров (с симуляцией), затем внедрять.
          2.1. пакетом
          2.2. процесс за процессом
          2.2.1. один за другим по расписанию
          2.2.2. один за другим с доработкой внедряемых по ходу внедрения
          Я к тому, что ни айтишники, ни пользователи никогда не готовы пересаживаться из старого, рваного и скрипящего, но удобного и привычного кресла в новое, красивое и кожаное, но незнакомое.
          Конечно, при запуске itsm-проекта менеджмент относительно готов к нему. Подчеркиваю, относительно, потому что чаще всего не понимает, к чему приведет проект. Считает, что это будет сказочная эффективность и экономия денег. Но скорее всего или не знает или не слышит, что внедрение скорее всего будет кровавым и сложным, придется пойти на непопулярные меры и тп. А что уж говорить о линейных менеджерах и специалистах, которым вся эта инициатива вообще по-барабану, им не нужна дополнительная нагрузка в виде изменения привычного рабочего режима.
          И вот мы видим, как на новоявленный сервис деск по телефону уже льются потоки г(рязи), айтишники что есть мочи ищут способ обойти процесс (даже не попробовав его использовать), а менеджеры высшего звена (которые не инициировали проект) прямым текстом говорят команде проекта о том, куда им идти с их инициативой.
          Я наверное, нарисовал достаточно тревожную картину, но она в чем-то напоминает правду, я думаю. По крайней мере, в некоторых внедренцах она может всколыхнуть воспоминания о былом.

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

  • Михаил Козлов

    ROI, конечно не Миши Козлова, а сам по себе 🙂

    Вот тут я описал свое ИМХО в отношении “откуда тогда берутся компании, которые готовы?”: http://www.slideshare.net/mkozloff/ltele

    Нужно работать в “рыночной” организации, уметь управлять ДИТом как бизнес-подразделением (включая умение продавать решения бизнес-задач и обоснование бизнес-кейсов на оснве ROI) и стремиться создавать новые продукты для клиентов организации на основе технологий. Т.е. стремиться стать CIO 2.0 (http://www.slideshare.net/mkozloff/cio-20)

    • Alexander Peshkov

      CIO 2.0 = CSO? >:]

      • Михаил Козлов

        Безопасность то здесь откуда на первом месте? 🙂

        • Alexander Peshkov

          Здесь не Security, а все же Service. Кстати, перечитал “зацепку”. Если там продукты, то как бы “и не в шубу рукав” 🙂

    • Alexey Lobachev

      ППКС. Не нужно заморачиваться и выделять переход в проект. Нужно просто делать очевидные вещи. Провести инвентаризацию услуг, компетенций и внешних контрактов. По максиму типизировать все от рабочих мест до услуг.
      А самое главное, относиться к своему ДИТ как к нормальной сервизной организации. Я люблю пример ресторана. Хороший официант не будет вам жаловаться на повара горячего цеха, тот на повара салатного и ты пы. На кухне есть заготовки, из них складываются блюда. Вы коммуницируете с официантом, в крайнем случае с администратором (но это уже Ахтунг).
      Вот попробуйте представить ДИТ хорошим рестораном, где клиент всегда прав и о нем всегда заботятся, а вы Шеф этого ресторана и от вас зависит слаженная работа. Вот тогда вам будет понятно, что нужно считать, что готовить заранее, кого как пинать, а кого как мотивировать. И не скидывайте проблемы ДИТ на основной бизнес. Вы такая же его часть, а если выдумали себе какую-то особую Роль, то это только тараканы в вашей голове. ИТСМ всего лишь сбор лучших практик и никто не мешает добавить в эту библиотеку вашу собственную главу 😉

      • Alexander Peshkov

        Обождите, тут есть небольшой пробел, в выражении “клиент всегда прав”. Обращаясь к вашей аналогии, я приду в “хороший ресторан” и начну там качать права “подайте мне немедля, пардон, диназаврятины и мамантятины, а так же жареных шорек” и скандалить буду страшно “как, у вас этого всего нет сию секунду?! да вы в своем уме? что вам не ясно, бегом мне доставьте все сюда, быстрее я сказал”. Что, это такое уж редкое явление, дивиантное поведение тех же юзеров? И что, это проблемы вежливого менеджера ресторана или поваров?
        Я не считаю, что клиент всегда прав – это чушь. Услуга – это одновременно и потребление и предоставление. Более того, услуга существует вообще только в момент ее предоставления и потребления. Значит, и ответственность обоюдная. Именно поэтому в хорошем ресторане всегда есть менеджер, который немедленно отреагирует на нестандартную ситуацию. У ДИТ зачастую проблем (и тараканов) куда меньше, чем у основного бизнеса..

        • Alexey Lobachev

          Я же уже говорил, бегите тогда от неадеквата, ничего у вас не выйдет. Идите в нормальную компанию. Менеджер вам не поможет, собственно вы и есть менеджер, владельцу нужны самостоятельные руководители, они не будут всем носы подтирать.
          У меня, почему-то всегда получается. 😉
          Если вы не разделяете подходы тех, у кого это работает и у вас свой путь, то тут вам никто помочь не сможет.
          Не нужно учить язык по словарю 😉

          • Alexander Peshkov

            Вопрос был “правильная методика внедрения”, а не “признаки необходимости побега”, и тем более “мольба о помощи” 🙂
            “Свой путь” – вещь достаточно субъективная, тогда нужно, видимо, сказать “я всегда сам изобретаю все велосипеды, на которых езжу”, но ведь это глупость какая-то. Таким образом, чаще всего берем готовый велик, либо срисовываем с чего-нибудь, адаптируя под свой рост и вес. Такая аналогия. Кто действует иначе? Нет, есть такие чудаки, я лично знаю пару человек, которые, видя процесс, написанный на основе какой-либо общепринятой методики начинают сразу вопить о том, что методики – это не библия и что нужно делать так как удобно ИМ, а не так, как сделали уже тысячи других людей и все получилось. Но как раз это – самое что ни на есть сопротивление изменениям, это не значит, что процесс плохой. Даже несколько наоборот. Если процесс вызывает вопли и рыдания – значит он хороший, значит он поднимает скрытые проблемы (предполагаем, что процесс написан все же адекватным человеком), которые раньше просто выходили с негативом на руководство и тонули в пучине производственных совещаний / корпоративных отношений / закулисных интриг / возвышенного молчания / чего угодно еще, но никак не решались.
            Кстати, подход о том, что при оказании услуг ответственность совокупная, естественным образом следует из понимания устройства услуги. Не вижу противоречий с “теми, у кого это работает”, я в этом убедился на последнем заседании, на котором докладывал один из тех самых экспертов международного уровня. Да и вообще, не понял этого тезиса. Чего я не разделяю-то? Того, что если вам в ухо заливают необоснованный негатив, нужно зажмуриться и повторять про себя мантру “клиент ВСЕГДА прав, нужно потерпеть”? Еще раз повторяю – это не так, клиент не всегда прав. Но тут вопрос в другом, именно с него я и начал – почему клиент бывает неправ? Да потому что иногда проекты начинаются не с завоевания умов, а с внедрения процессов. И только в этом смысле да, клиент всегда прав. Почему и рождается вопрос – а как правильно внедрять. “Пойти и делать” – красивый лозунг, конечно, но это не методика. Любой герой готов “пойти и делать”, но ведь если где-то нужен герой, значит там только что побывал идиот, не так ли? Если немного смягчить тон, то картина будет ровно следующая: если перед вами стоит задача, сколько нибудь более сложная, чем возведение бутерброда, лучше все же подумать, как ее реализовать с минимальными затратами ресурсов, в минимальные сроки, с максимальным качеством. Кажется, ничего не забыл 🙂

            • Alexey Lobachev

              И как, получается? Или должно получиться?

              • Alexander Peshkov

                Получается, хотя и не с той легкостью, что хотелось бы.
                В любом случае, я не понял концепции “хождения в нормальную компанию”. В смысле, нормальная – это какая (в контексте вопроса)? Ну и далее по теме – какую именно предлагаете методику внедрения? С условием, что “с нуля” (нет даже SD)?

                • Alexey Lobachev

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

  • Alexander Peshkov

    Тема стремительно выродилась, чего можно было ожидать. Вариант “ввести единый номер и единое мыло и все инвентаризировать + перевоспитать поддержку, чтобы она стала доброжелательной”, мне кажется, недостаточным.
    Предложу свой, как говорится, “критикуя – предлагай”. Итак, задолго до внедрения – семинары для топ-менеджеров, очень желательно, с кейсом, с игрой. Далее – семинар для руководителей структурных подразделений, так же, с игрой. Потом то же самое для ИТ-организации (ДИТ или аутсорсер). Потом повтор цикла.
    Только потом, собрав на семинарах предложения и тп – проектируем процессы и внедряем их, один за другим, с допилом и доведением до ума каждого процесса перед развертыванием следующего. Важный момент, первыми, видимо, все же должно внедрять конфиг. Потом уже единые номера, инциденты и остальное. Вот такое незамысловатое мнение.

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

      Александр, пусть семинары создают ощущение необходимости перемен и помогают определить, какие именно перемены необходимы. По Коттеру это первый шаг, по influencer – social motivation. А какие конкретные меры вы бы предложили для других шагов и других элементов системы факторов влияния?

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

      Почему вы считаете порядок построения процессов важным для завоевания умов?

      • Alexander Peshkov

        Роман, скорее всего, прямого влияния на ум нет. Но есть опосредованное, скажем, через шаг №6 (почитал Коттера и сразу стал такой умный, аж в зеркало посмотреть захотелось).

        • Alexander Peshkov

          Ха-ха. Сразу видно, воскресенье в Парке Горького 🙂

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

          Тогда самое время переходить к Питеру нашему Друкеру 🙂
          Хорошая статья в старом HBR – “They’re Not Employees, They’re People”

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

      Александр, так можно, но я не назвал бы это методикой, потому что воспроизведение этой последовательности действий возможно далеко не везде. Причины две:
      1. Это очень долгий путь – много лет. Это приемлемо не для всех.
      2. Поскольку это долгий и дорогой путь, он малоэффективен (эффективность = связь результата и ресурсов).
      Я не знаю методики завоевания сердец. Я знаю некоторые общие подходы – упомянутые Коттер и Infuencer очень интересны (но это, разумеется, не методики). Я думаю в оргпреобразованиях есть два важных этапа:
      1. начальный этап – необходимо иметь возможность давления (административного, финансового, …). Давление помогает создать нужную критическую массу, чтобы перемены могли начаться. Этот фактор более важен в крупных компаниях, менее – в небольших.
      2. чуть позже начального этапа – необходимо показать результат, чтобы в него поверили. Не обязательно все (да и результат наверно будет не для всех), но достаточно влиятельная группа. А чтобы был шанс показать результат, надо изначально понимать задачу. Это важнее, чем знать последовательность процессов.
      Семинары – скорее способ сблизить людей в терминах и базовых идеях, чтобы не не строить потом вавилонскую башню. Это очень важно, но это не “завоевание сердец”.
      ИМХО.

      • Alexander Peshkov

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

  • Alexey Lobachev

    Семинар для ТОП? %)
    Предложить людям с 16 часовым рабочим днем семинар, вместо показа изменения процесса на одной отдельно взятой службе?
    Успехов!
    Внедрите по такой методике, передавайте фотографии через Скрынника 🙂

    • Alexander Peshkov

      Предположим, согласился 🙂
      Итак, мы идем с ту самую отдельно взятую службу и говорим им “ребята, мы вас будем изменять”. И слышим в ответ “ура, наконец-то, мы так этого ждали, изменяйте же нас скорее!”. Оглядываемся вокруг и видим стены психушки. Или есть еще варианты?
      От самых небольших компаний, до любых вообще, в природе существует естественное желание людей жить и работать так, как они привыкли. Ведь все верно, для них это дополнительная ненужная нагрузка.
      Т/е в любом случае, мы должны каким-то образом убедительно попросить эту службу покориться (некоторые жестянщики даже предлагают оказывать давление, кстати, тут я полностью согласен). Но как убедить директора департамента (любого, даже поддерживающего) выделить отдел для экспериментов? Видимо, мы сможем убедить ДД только через ГД (ведь для ДД это тоже лишняя ненужная нагрузка!!). Но тогда нам нужно убедить в необходимости изменений ГД! Привет, семинар для ТОП. А как еще? Взять отдел в оборот, никого об этом не информируя? Сообщите, пожалуйста, как Вы делаете это, не обсудив с ТОП?

      • Alexey Lobachev

        Тренироваться на своем подразделении. Я ведь про плетку писал. 🙂
        Кстати, на курсе по Саппорту у Романа Журавлева один товарищ из Сименса интересовался, как заставить поддержку описывать заявки в СД. Я поинтересовался, пробовал ли он их бить?
        Он тогда смеялся… Но вот я сдал на красный значек, а он – нет 🙂

        • Alexander Peshkov

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

      • Вадим

        кстати, анекдот:
        Американец, англичанин и русский поспорили, кто
        заставит кошку съесть горчицу. Американец хватает
        кошку и запихивает горчицу ей в пасть.
        – Это насилие! – протестует русский.
        Англичанин кладет горчицу между двумя кусками
        колбасы, и кошка съедает.
        – Это обман! – протестует русский, после чего мажет
        горчицей кошке под хвостом, и кошка с воем
        вылизывает.
        – Обратите внимание, – говорит русский, – добровольно и
        с песней.

  • Вадим

    IMHO если уж Вас угораздило запустить проект, то вопрос завоевания сторонников (умов) в рамках проекта – не самое лучшее решение. ум должен сначала дозреть, ему нужно показать плюсы/минусы, запустить что-то небольшое (пилот)

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

      Хорошо, если до начала проекта можно озадачиться “работой с умами”, если на это есть время.

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

      Вот и приходится заниматься такой интересной и важной задачей уже в проекте, да и после него.

      • Вадим

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

        отсюда вывод: надо расти над собой, завоевывать авторитет и вот тогда…

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

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

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