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

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

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

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

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

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

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

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

        0
        0
        1. Peshkov Alexander

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

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

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

          0
          0
    1. Георгий

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

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

      0
      0
    2. Николай

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

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

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

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

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

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

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

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

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

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

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

        По пункту 1. Не догнал. А может просто не дорос.

        По пункту 2. Не имел, привёл примеры.

        По пункту 3. «Тот-то чаще всего уверен, что он самый «культурный» и сервисный» Не согласен. Практика этот тезис опровергает.

        0
        0
        1. Николай

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                      0
                      0
  4. Георгий

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

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

    0
    0
  5. Leonid

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

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

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

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

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

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

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

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

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

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

      0
      0
      1. Leonid

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

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

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

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

              0
              0
      2. Leonid

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

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

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

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

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

          0
          0
    2. Алексей

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

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

      0
      0

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

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

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

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

НОЯ
27
Учебный курс:
Основы ITIL (очно)