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

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

Опубликовано 23 сентября 2011
Рубрики: ITSM, Процессы
Комментарии

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

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

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

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

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

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

ОБУЧЕНИЕ
IT Service Management
Учебные курсы от соавторов ITIL 4

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

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

  • Алексей Попов

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

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

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

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

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

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

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

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

      …И я бы SLM всем прививал сразу;)

      • Вадим

        это не прививка, это как “зашиться раз и навсегда”

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

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

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

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

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

        • Peshkov Alexander

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

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

    Подождём Гошу и Николая, они принесут свои ложки, которые у них всегда полны 🙂 Думаю, этого очень не хватает для дискуссии.

    • Георгий

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

    • Николай

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

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

      Симптом №1. “Прежде, чем внедрять … сначала надо выполнить всестороннее обследование … И мысль безусловно правильная”.
      Если использовать любимые тобой аналогии, то это похоже на утверждение “я не сумасшедший” 🙂 Когда в следующей фразе после утверждения мы его объявляем безусловным – это диагноз… так что тут пейте фенхель 🙂

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

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

      Симптом №3. “сервисный подход… «показан» далеко не всем… здесь обследование должно дать ответ на вопрос «Надо ли? И если надо, то кому и зачем?».
      Мысль понятна и по-своему верна. Вот только заказчики за это платить не захотят (если конечно разберутся, что им впаривают). Проблема в том, что вопрос этот – в голове консультанта, а не заказчика. Тот-то чаще всего уверен, что он самый “культурный” и сервисный и “раз я Вас позвал, значит мне надо все как у людей”.
      А вот для консультанта действительно важно выявить скрытые “подводные камни ABC”, которые могут помешать запуститься не самым “механистическим” процессам. И здесь “ложки” не пропишу – разве что выявлять эти моменты неформально, на этапе пресейла, и конечно бесплатно для заказчика.

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

        По пункту 1. Не догнал. А может просто не дорос.
        По пункту 2. Не имел, привёл примеры.
        По пункту 3. “Тот-то чаще всего уверен, что он самый «культурный» и сервисный” Не согласен. Практика этот тезис опровергает.

        • Николай

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

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

          По третьему – интересно, а что, был такой заказчик который так прямо попросил обследовать его на предмет ответа на вопросы:
          “Нужен ли моей организации сервисный подход?”
          “Если надо, то кому и зачем?»
          За это правда деньги платят???

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

            “По первому пункту просто хотелось понять…”
            См., например, комментарий от Leonid’а http://www.realitsm.ru/2011/09/itsm-as-a-medicine/#comment-6187. Собственно, он и автор слов про всестороннее обследование. И я по-прежнему согласен с ним в том, что в этой мысли есть своя доля правды.

            “а что, был такой заказчик который так прямо попросил обследовать его … За это правда деньги платят???”
            Во-первых, было и такое. Во-вторых “деньги платят” – это сомнительный критерий пользы. Как мы знаем, деньги часто платят за полную фигню (извините мой французский), а иногда – напротив – за то, что полезно, заплатить не могут.

  • Алексей

    Я бы только исключил из списка прививок изменения и релизы.
    Они не настолько уж и обязательны, по сравнению с инц. и проблемами.

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

      Алексей, почему? Вы знаете компании, которым не надо ничего менять в ИТ-инфраструктуре и бизнес-приложениях?

      • Алексей

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

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

          Допустим. Но как из этого утверждения следует, что “Я бы только исключил из списка прививок изменения и релизы. Они не настолько уж и обязательны, по сравнению с инц. и проблемами.”?
          Или “не нужно ничего менять вот сейчас прямо” – это устойчивое состояние (год и более)? Но тогда зачем этой компании управление проблемами?

          • Алексей

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

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

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

              • Алексей

                Разве изменения являются единственным источником проблем?

                Для IT аутсорсеров вполне типичный пример.

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

                  Для крупных – едва ли. Для небольших – возможно.
                  Всё же получается, что область применимости Вашего “Они не настолько уж и обязательны” весьма ограничена, как мне кажется.

                  • Алексей

                    Для крупных аутсорсеров тогда уж и не только операционные процессы обязательны…

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

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

  • Георгий

    Wow!
    Дима поднял аналогии на высокий уровень – целой статьи (привет Больцману) )))

  • Георгий

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

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

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

      Внимательный читатель заметит, что CFG в перечисленных мной “физкультурных” процессах не значится. Сознательно. Впрочем, и согласиться c тезисом про 95% я тоже как-то не готов. По-моему цифра с потолка.

  • Leonid

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

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

      Я думаю, всё очень зависит от постановки задачи. Далеко не всегда заказчик готов формулировать её в виде конкретных проблем. Моя мысль в том, что организация, скажем, управления инцидентами (на нормальном 4-м уровне, чем мы с вами и занимаемся), будет полезна по крайней мере в большинстве случаев. Я готов отдельно по пунктам обосновать, почему именно 4.
      И я немного запутался, о чём Вы говорите:
      1. В вашей организации обследование было.
      2. Проблема у Вас была отнюдь не только в нехватке специалистов.
      3. Тем не менее, мы помогли обосновать в том числе и нехватку кадров, и люди были набраны в разгар кризиса 2008 года.
      4. Строго говоря, мне пока неизвестны факты “процессостроительство еще более ухудшило их работу по основному направлению”.
      5. Напротив – насколько мне известно, исходная управленческая задача в целом решается. Вот SLM – действительно отдельная история. Но тут пока рано хоронить 🙂
      Так вот я запутался, Вы это в целом или конкретно про Ваш случай?

      • Leonid

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

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

          Наверно потому что изначально Ваш камент был про пост нашего консультанта про наш проект. Ну, это не важно. Важно, что разобрались. Отлегло 🙂

          • Leonid

            Пост Михаила?! Вот никогда бы не подумал что это про нас, забавно получилось, ладно, проехали;).

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

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

      • Leonid

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

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

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

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

    • Алексей

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

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

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

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