Несколько еретических замечаний о структуре и сути жизненного цикла услуг сделал в очередной колонке на ITSMPortal.com Роман Журавлёв. Взяв за основу группировку процессов жизненного цикла ИТ-услуг из ITIL v3, он предложил для каждой фазы цикла формулировки целей, соответствующие реальному содержанию описанных в них процессов. Получилось совсем не так, как в ITIL.
Подробности на английском – на ITSMPortal.com
Возможность разгромить еретика в пух – прямо здесь.
На итсмпортале было высказано несколько мнений. Главным еретиком оказался Ян ван Бон, главный редактор портала:
“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 и “процессы, поддерживающие другие процессы” – все остальное 🙂
Это правда вызывает еще много вопросов сразу, ну и плюс, в самих книгах процессы делятся по книжкам совсем по другому признаку 🙂
Еретиков не громят, громят других, но не столько за их взгляды…
У вас дрова есть?