ITSM – лекарство?

Эта тема уже была затронута мной в одном из постов. Однако развития она не получила, а мне кажется важной (не хотел бы, чтобы она потерялась в глубине комментариев). Контекст обсуждения был таков: прежде, чем внедрять какие-то процессы (медицинская аналогия – принимать лечение), сначала надо выполнить всестороннее обследование (медицинская аналогия – поставить диагноз). И мысль безусловно правильная, но, как мне кажется, есть и другая сторона вопроса. Итак:

Операционные процессы управления ИТ (inc, reactive prb, chg+rel) – это не «лечение», которое должно быть индивидуально показано пациенту, а «физкультура», которая может применяться всеми «без рецепта» (при должной адаптации, разумеется). Это базовые процессы, которые могут применяться как для поддержки сервисного подхода, так и независимо от него. Эти процессы структурируют операционную деятельность, которая существует независимо от веры организации в ITSM. Обследование в данном случае скорее должно отвечать не на вопрос «Нужны ли эти процессы?», а на вопрос «Как их правильно организовать, на чём сделать акцент?».

Как раз сервисный подход, напротив, «показан» далеко не всем, есть пререквизиты.

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

Вот здесь обследование действительно должно дать ответ на вопрос «Надо ли? И если надо, то кому и зачем?».

Спорно? Давайте поспорим.

ITIL ITIL Practitioner — новый учебный курс 2016

Правильный следующий шаг после ITIL Foundation.
 

Узнайте больше!

Комментарии и мнения

  1. Алексей Попов

    По-моему всё разумно, поэтому и развития мысль не получила.

    Те же inc и chg всегда есть, они минимум на 1 уровне зрелости, и они всегда более понятны, и могут более-менее успешно работать в организациях с разными подходами к процессному управлению (www.cleverics.ru/images/p...s_management.png, верхний левый квадрант).

    В тоже время, сервисный подход, как таковой, зачастую бывает даже вреден. Если уровень зрелости, уровень «клиентоориентированности» ИТ-структуры в организации значительно превышает уровень зрелости самой организации, то проблем здесь не меньше, просто они другие.

  2. Олег Скрынник

    Мысль про операционные процессы ни разу не очевидная, а потому — ценная. Правильно, что вместо глубин комментариев к другому посту она теперь имеет своё отдельное место.

    Чтобы посмотреть на тот же вопрос немного с другой стороны достаточно послушать Романа нашего Журавлёва с его давнишним выступлением про хорошие и лучшие практики: www.youtube.com/cleverics#p/u/45/YZOwhQho6BA

  3. Константин Нарыжный

    Дмитрий, я бы назвал операционные процессы не «физкультурой», а обязательными прививками, что ли, как прививки в детстве. Если их не сделать — последствия будут катастрофичны.

    То есть, «да, надо» и известно, «зачем».

    1. Дмитрий Исайченко Автор

      Не согласен. Прививки сделал — и забыл. Иммунитет есть, требуемое состояние достигнуто. Более в этой связи ничего делать не надо.

      С процессами так не бывает. Уж если и продолжать использовать эту медицинскую аналогию, то это именно физкультура — постепенно, постоянно, правильно. Перестали делать — через год-два всё насмарку, надо начинать практически сначала.

      1. Константин Нарыжный

        Дмитрий, это оффтопик, конечно, но тут с какой точки зрения мы смотрим. Если бизнес-организация — организм пациента, а консультант — это доктор, то лучше тот доктор, который смог единожды так усовершенствовать имунную систему так, что она всю жизнь работает как надо, результативно и рационально реагируя на угрозы.

        Я согласен в главном: отвечать на вопрос «А оно мне надо?» обязан каждый заказчик проекта: и decision maker и 'influencer'. Вялый или «инстинктивный» ответ на этот вопрос часто ведёт к разочарованиям.

        1. Peshkov Alexander

          Система, находящаяся вне управляющих воздействий, стремится к энтропии. Термондинамика.

          Безусловно, физкультура, но если речь о inc, problem, chg — то наверное, это общеукрепляющая гимнастика.

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

    1. Георгий

      Сорри, не сразу увидел призыв 🙂 Дим, не знаю насчет ложки, но у тебя снова аналогия (я уже отписал по этому поводу) — она опять, как любая аналогия, порочна 🙂

      аналогия красива, спору нет, плюс особенно порадовал спор про то, как это называть, прививкой или физкультурой 😀 🙂

    2. Николай

      И снова здравствуйте!

      По выраженной в данном посте симптоматике Вам, пациент, прописано несколько ложек 🙂

      Симптом №1. «Прежде, чем внедрять ... сначала надо выполнить всестороннее обследование ... И мысль безусловно правильная».

      Если использовать любимые тобой аналогии, то это похоже на утверждение «я не сумасшедший» 🙂 Когда в следующей фразе после утверждения мы его объявляем безусловным — это диагноз... так что тут пейте фенхель 🙂

      Но на этот симптом есть и вторая ложка — утвержденьице-то спорное. «Всестороннее обследование» — чего??? Всей организации? Здоровья ИТ-директора? Конкретного процесса?.. Готов привести пример, когда необходимость внедрения конкретного процесса очевидна после ответов на несколько простых вопросов. Так что ложка №2 — поконкретнее плиз...

      Симптом №2. «Операционные процессы... и сервисный подход».

      Я наверное тупой... неужто Дмитрий имел ввиду, что ВСЕ процессы, кроме «inc, reactive prb, chg+rel» нужны ТОЛЬКО при сервисном подходе к управлению ИТ? Это настолько странно, что не буду прописывать ложку, пока не получу подтверждения...

      Симптом №3. "сервисный подход... «показан» далеко не всем... здесь обследование должно дать ответ на вопрос «Надо ли? И если надо, то кому и зачем?».

      Мысль понятна и по-своему верна. Вот только заказчики за это платить не захотят (если конечно разберутся, что им впаривают). Проблема в том, что вопрос этот — в голове консультанта, а не заказчика. Тот-то чаще всего уверен, что он самый «культурный» и сервисный и «раз я Вас позвал, значит мне надо все как у людей».

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

        1. Николай

          По первому пункту просто хотелось понять, отчего утверждение «прежде, чем внедрять ... сначала надо выполнить всестороннее обследование» такое уж «безусловно правильное», ну и по возможности уточнить обследование чего именно является обязательным.

          Пункт второй — очень хорошо, спасибо, снимается.

          По третьему — интересно, а что, был такой заказчик который так прямо попросил обследовать его на предмет ответа на вопросы:

          «Нужен ли моей организации сервисный подход?»

          "Если надо, то кому и зачем?»

          За это правда деньги платят???

          1. Дмитрий Исайченко Автор

            «По первому пункту просто хотелось понять...»

            См., например, комментарий от Leonid'а www.realitsm.ru/2011/09/i...ne/#comment-6187. Собственно, он и автор слов про всестороннее обследование. И я по-прежнему согласен с ним в том, что в этой мысли есть своя доля правды.

            «а что, был такой заказчик который так прямо попросил обследовать его ... За это правда деньги платят???»

            Во-первых, было и такое. Во-вторых «деньги платят» — это сомнительный критерий пользы. Как мы знаем, деньги часто платят за полную фигню (извините мой французский), а иногда — напротив — за то, что полезно, заплатить не могут.

        1. Дмитрий Исайченко Автор

          Допустим. Но как из этого утверждения следует, что «Я бы только исключил из списка прививок изменения и релизы. Они не настолько уж и обязательны, по сравнению с инц. и проблемами.»?

          Или «не нужно ничего менять вот сейчас прямо» — это устойчивое состояние (год и более)? Но тогда зачем этой компании управление проблемами?

            1. Дмитрий Исайченко Автор

              Любопытный пример. В голове рисуется организация, которая проводит изменения крайне редко (раз в год, а то и реже), но при этом так «метко», что проблем от этих изменений хватает вплоть до появления следующих 🙂

              Вряд ли такое состояние можно назвать типичным для большинства организаций.

                    1. Дмитрий Исайченко Автор

                      Верно. Поэтому я думаю далеко не только про аутсорсеров. Всё-таки случаев внутренних ИТ-подразделений, обеспечивающих развитие и применение ИТ — существенно больше. Для них, например, chg — очень важная часть вполне себе повседневной работы. Вы же — напротив — утверждаете, что он не так уж необходим, приводя в пример а) аутсорсеров, б) небольших аутсорсеров и в) не владеющих ИТ-инфраструктурой для предоставления ИТ-услуг. Не слишком много ограничений для обобщения?

  4. Георгий

    Ну вот рядом появился пост про ненужность CMDB для 95%. Здесь прямо обсуждается, что некоторые процессы нужны всем, а некоторые даже и не всем («некоторые женятся, а некоторые так»)

    Давайте, может, на основании «реального итсм» и нашего опыта/мнения сделаем список процессов, которые с нашей точки зрения имеют право на жизнь (процессы берем из книг ITIL), а какие мы оставляем за бортом прогрессивного пути человечества? 🙂

  5. Leonid

    Мне кажется, совершенно бессмысленно отвлеченно рассуждать о большей или меньшей степени полезности или применимости определенных процессов. Продолжим медицинскую аналогию: Все рекомендации ITIL в чем-то полезны, но и как любые полезные лекарства имеет определенные негативные последствия — противопоказания. На одной чаше весов ожидаемый положительный эффект, а на другой затраты ресурсов и ломка привычного порядка работы. Тут надо уточнить, что мы говорим, как я понимаю, не о процессах вообще, ведь в том или ином виде (1-2 уровни зрелости) они есть в любой организации, а о проектах по повышению уровня зрелости процесса до 3-го уровня, чем мы с вами в основном и занимаемся. А вот польза от подобных проектов уже далеко не очевидна и для правильного лечения нужна точная диагностика. И выяснять в первую очередь следует не «Нужны ли эти процессы?» и не «Как их правильно организовать, на чём сделать акцент?», а в чем причина проблем. Иначе получается интересное кино, например: Слишком много (по мнению бизнеса) инцидентов с важными системами. Энное количество времени за энные деньги внедряются процессы управления инцидентами и управления проблемами. Инцидентов становиться еще больше. Почему? Да потому, что основная причина была в недостатке квалификации специалистов, поддерживающих системы, а отвлечение этих специалистов на процессостроительство еще более ухудшило их работу по основному направлению. Сами получившиеся процессы могут быть сколь угодно «прекрасными» ©, но проблему заказчика они не только не решили, а только еще больше усложнили ему жизнь.

    1. Дмитрий Исайченко Автор

      Я думаю, всё очень зависит от постановки задачи. Далеко не всегда заказчик готов формулировать её в виде конкретных проблем. Моя мысль в том, что организация, скажем, управления инцидентами (на нормальном 4-м уровне, чем мы с вами и занимаемся), будет полезна по крайней мере в большинстве случаев. Я готов отдельно по пунктам обосновать, почему именно 4.

      И я немного запутался, о чём Вы говорите:

      1. В вашей организации обследование было.

      2. Проблема у Вас была отнюдь не только в нехватке специалистов.

      3. Тем не менее, мы помогли обосновать в том числе и нехватку кадров, и люди были набраны в разгар кризиса 2008 года.

      4. Строго говоря, мне пока неизвестны факты «процессостроительство еще более ухудшило их работу по основному направлению».

      5. Напротив — насколько мне известно, исходная управленческая задача в целом решается. Вот SLM — действительно отдельная история. Но тут пока рано хоронить 🙂

      Так вот я запутался, Вы это в целом или конкретно про Ваш случай?

      1. Leonid

        «Так вот я запутался, Вы это в целом или конкретно про Ваш случай?»

        А с чего Вы взяли, что я говорю про то, о чем Вы подумали;). Я далеко не в одном ITSM-проекте участвовал, но конкретные «адреса и явки» без большой необходимости предпочитаю не светить. Так что предлагаю на форуме обсуждать не «Ваш случай», а только то, что я написал в комментах.

            1. Дмитрий Исайченко Автор

              Пост Михаила был точно не про вас 🙂 Как Вы участвовали не в одном ITSM-проекте, так и мы сотрудничаем больше, чем с одной компанией 🙂 Ладно, правда, какая разница, на каком этапе мы запутались. Важно, что распутались.

      2. Leonid

        «Моя мысль в том, что организация, скажем, управления инцидентами (на нормальном 4-м уровне, чем мы с вами и занимаемся), будет полезна по крайней мере в большинстве случаев.»

        Умеючи и в процессе управления инцидентами можно накасячить так, что никому житья не будет, а идеальных процессов вообще не бывает, уже 3 года процесс управления инцидентами юзаем, а в каждом аудите все равно вылезают шероховатости еще с проектирования тянущиеся, да еще и новые процессы свое добавляют. Опять же, действительно ли уж так общеполезно прорываться на 4-й уровень с 3-го или даже 2-го?;)

        1. Дмитрий Исайченко Автор

          «уже 3 года процесс управления инцидентами юзаем, а в каждом аудите все равно вылезают шероховатости»

          Вот именно поэтому и важна 4, чтобы эти шероховатости выявлять и устранять, постепенно развивая деятельность. Потому что 3 на практике спустя пару лет превращается «нам как-то написали, мы как-то работаем», причём чем дальше, тем больше отличается одно от другого. 4 — это уровень, начиная с которого включаются внутренние механизмы контроля, оценки и совершенствования. Это принципиально повышает жизнеспособность системы управления.

    2. Алексей

      Сомневаюсь что правильно построенный процесс может навредить описанным образом.

      Это все равно что плохому рыбаку дать вместо обычной удочки, дорогую профессиональную. Толку может и не будет, но хуже — тоже врядли.

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

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

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

ИЮН
5
Учебный курс:
Основы ITIL (очно)