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

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

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

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

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

ITIL 4 Foundation, MPT, 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