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

Неортодоксальный взгляд на жизненный цикл услуг

Несколько еретических замечаний о структуре и сути жизненного цикла услуг сделал в очередной колонке на ITSMPortal.com Роман Журавлёв. Взяв за основу группировку процессов жизненного цикла ИТ-услуг из ITIL v3, он предложил для каждой фазы цикла формулировки целей, соответствующие реальному содержанию описанных в них процессов. Получилось совсем не так, как в ITIL

Подробности на английском – на ITSMPortal.com

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

ITIL 4 Foundation, DSV, DPI, CDS, HVIT, DITS
и другие интересные аббревиатуры от соавторов ITIL 4

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

  • Еретиков не громят, громят других, но не столько за их взгляды…
    У вас дрова есть?

  • На итсмпортале было высказано несколько мнений. Главным еретиком оказался Ян ван Бон, главный редактор портала:

    “ITIL, несомненно, никакой не жизненный цикл. Достаточно взять словарь, чтобы в этом убедиться…
    ITIL НЕ описывает процессы – это просто свод хороших практик, и там это написано.
    ITIL использует общепринятое определение процесса. Но покажите мне процессы в главах, описывающих Security Management, или Capacity Management…. Хватит искать процессы в ITIL!

    О как.

    • Ян ван Бон – та ещё зажигалка.
      Он в этой теме очень давно, и сейчас не стесняется в выражениях. Сколько раз уже замечал его колонки и его же комментарии к другим колонкам…

  • Роман, а могли бы подробнее пояснить свою позийцию по поводу “event management не процесс…”
    Возможно по причине моего не укселент инглишь, а может банального тугодумия, мне этот вопрос остался как-то не совсем ясен.

    • Могу рассказать свои соображения, т.к. совсем недавно, на прошлой неделе, с одним из клиентов подробно разбирали этот вопрос.

      У каждого процесса, согласно ITIL, должна быть чётко определена цель. У управления событиями её нет. С практической точки зрения это означает, что к такому “процессу” не придумать разумных KPI – только такие, которые ориентированы на производительность, а не на достижение цели (ибо её нет).

      Далее, управление событиями – скорее всего не централизованная штука, а распределённая. Различные отделы внутри ИТ управляют различными событиями. Это скорее их работа, задача, часть ответственности – но не единый процесс всего ИТ-подразделения.

      • Т.е. проблема только в том, что забыли цель определить?
        То что IM – централизованный, это вроде бы тоже не догма, не так ли?

  • Я считаю, что это функция. Так же точно, как и Service Desk. То есть комплекс ресурсов, специализированный для выполнения определенной деятельности. Выполняться эта деятельность может в интересах и в рамках различных процессов. У которых, к слову, есть цели. В то время как у event mgt’а и SD – только назначение.

    “Он играет на похоронах и танцах”. Потому что умеет играть. И это умение используется с разными целями – в процессах и, кстати, проектах.

    К слову: Ян ван Бон и многие другие отказывают, например, управлению мощностями в праве называться процессом по немного другому основанию: отсутствию ясного потока работ, трансформирующего входы в выходы.

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

      • Манипулировать, конечно же можно. Главное, чтобы был смысл и польза. В адекватном реагировании на все события в инфраструктуре польза не очень видна.

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

        • Как-это не видна. Польза в том, чтобы система была управляема и находилась в желаемом (нам) состянии. Если рассматривать инфраструктуру, как объект управления, то события это обратная связь, которые сигнализируют о состоянии системы. Реагирование на события это фактически система управления с обратной связью.

  • Очень интересные комменты ЯВБ. Прекрасная дискуссия.

    Но я не искал бы универсального ответа на вопрос о разнице между функциями и процессами. В реальной жизни они могут трансформироваться одно в другое. Есть примеры. Что считаю важным это то, что _в_каждой_конкретной_ организации или ситуации ответ на этот вопрос должен быть четко сформулирован и утвержден. Поскольку полностью согласен с ЯВБ: If you do not know your processes, then how would you ever be able to manage your activities in an effective and efficient way?

    Однако думаю, что _в_большнистве_случаев_ cap – это функция. evt – аналогично. Иначе в связках inc vs evt, cap vs evt, cap vs slm будет столько пересечений с нечеткой ответственностью, что это принесет больше вреда, чем пользы. А это и есть мерило.

    • Тот же ITIL v3 (в подтверждении этих слов) говорит следующее:

      “Functions are often mistaken for processes. For example, there are misconceptions about Capacity Management being a service management process. First, Capacity Management is an organizational capability with specialized processes and work methods. Whether or not it is a function or a process depends entirely on organization design. It is a mistake to assume that Capacity Management can only be a process. It is possible to measure and control capacity and to determine whether it is adequate for a given purpose. Assuming that it is always a process with discrete countable outcomes can be an error.”

  • Еще пара слов к вопросу о манипуляции. Я пытаюсь манипулировать прочтением ITIL в границах, заданных базовой терминологией ITIL, а не собственной фантазией. И, как сказал тот же ЯВБ, ITIL использует общепринятое определение процесса, и многие процессы в ITIL этому определению не соответствуют. Или, как сказал Скептик в известной книжке, “в отличие от ITIL, где понятие “процесс” используется с великолепным пренебрежением ко всем общепринятым значениям этого слова, в RealITSM мы говорим об “активностях”.

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

    • “Так вот, бизнес-ценность от того, что ИТ управляют событиями, очень косвенная, как и от того, что ИТ управляют конфигурациями или теми же мощностями. А от того, что ИТ устраняют сбои быстро или изменения внедряют, или требования новые реализуют — очень даже прямая.”

      Ром, а что из этого следует? Мысль не уловил.

  • Мысль примерно в следующем:

    Есть в ИТ деятельность, результаты которой вносят непосредственный вклад в реализацию бизнес-целей. И есть деятельность, результаты которой формируют внутри ИТ необходимые функциональные возможности.
    Первую можно договориться считать процессами, вторую можно договориться считать функциями.
    Тогда INC, CHG+REL, SLM будут, наверное, процессами.
    А [все] остальные – источниками функциональности для этих процессов.

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

    • Георгий

      Да, мысль очень близка моему понимаю 🙂 только с моей точки зрения, есть не деление на функции и процессы (это вообще можно отдавать на откуп конкретной организации, согласен с Димой 100%), а деление на “процессы ближе к бизнесу” – INC, CHG+REL, SLM и “процессы, поддерживающие другие процессы” – все остальное 🙂
      Это правда вызывает еще много вопросов сразу, ну и плюс, в самих книгах процессы делятся по книжкам совсем по другому признаку 🙂


Добавить комментарий для Олег СкрынникОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM