Несколько еретических замечаний о структуре и сути жизненного цикла услуг сделал в очередной колонке на 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 и «процессы, поддерживающие другие процессы» — все остальное 🙂
Это правда вызывает еще много вопросов сразу, ну и плюс, в самих книгах процессы делятся по книжкам совсем по другому признаку 🙂
Еретиков не громят, громят других, но не столько за их взгляды...
У вас дрова есть?