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

Обучение
по ITIL 4, ITSM, PRINCE2
Деловые
игры
Новые экзамены
по ITSM
Реестр ESM- и ITSM-систем в России 2024

Артём Мукосеев

Многоликий change manager

Роль менеджера изменений исторически вызывает некоторые расхождения в толковании охвата обязанностей. Довольно часто доводится задавать слушателям вопрос: “Вы сейчас кого имеете в виду, менеджера процесса в целом или координатора отдельных изменений?”. Надо сказать, что в зависимости от контекста ответ бывает разным. После очередного случая решил пробежаться по рекомендациям ITIL, чтобы выделить те, которые касаются области ответственности менеджера изменений. Что интересно, в книжке ITIL V3 2011 Service Transition (вы же ещё не забыли такую?) роль “менеджер изменений” в разделе “6.4.6 Роли управления изменениями” не описана. Там есть традиционные Владелец и Менеджер процесса, а также Инициатор, Практик, Авторизующий, Участник и Председатель комитета…

Что можно узнать на курсе ITIL 4 CDS

Как вы знаете, курс ITIL(r)4 Create, deliver and support появился прошлой осенью. Разработан он на основе одноимённой книги и отдельных публикаций, в которых описаны практики, упоминающиеся в этой книге. Практики, вообще говоря, в книге упоминаются практически все, но для успешной сдачи экзамена нужно иметь представление об основных понятиях и подходах к организации ключевых (по мнению авторов ITIL) практик – ключевых в контексте двух потоков создания ценности, упоминаемых, кстати говоря, уже на курсе ITIL(r) Foundation. В список ключевых попали следующие из них: Поток создания новой услуги Проектирование услуг (Service design) Управление релизами (Release management) Подтверждение и Тестирование Услуг (Service validation and…

Что такое “минимальная жизнеспособная практика (MVP)”?

В новой книге ITIL (r) 4 Create, deliver and support, которая, правда, пока что доступна только по подписке, описан довольно “простой” подход к определению охвата любой практики. Он называется “минимальная жизнеспособная практика” (minimum viable practice, MVP). Слово “простой” я сознательно поставил в скобки. Простым этот подход становится после того, как вы опишете потоки создания ценности своей организации. После этого можно скомпоновать практику (например, управления инцидентами или управления конфигурациями), собрав из всех шагов всех описанных потоков все случаи “вовлечения” практики. В книге есть даже шаблон такого описания, тоже весьма несложный. Единственное, надо учитывать, что в подобный “джентльменский” набор, как следствие, попадёт…

ITIL 4: подход к измерению практик

Если вы прошли какой-либо из наших курсов по библиотеке ITILV3, вы наверняка помните одну из важных концепций, которую мы разбираем и применяем – концепцию, в соответствии с которой ключевые показатели эффективности (key performance indicators, KPI) процессов формулируются на основе так называемых критических факторов успеха (critical success factors, CSF). В ITILV3 критические факторы успеха и примеры KPI приводятся для каждого из процессов, описанных в известных пяти книгах, посвящённых отдельным этапам жизненного цикла услуги. В соответствии с идеологией “трёшки” это “условия, которые должны выполняться, или что-то, что должно происходить”, чтобы можно было сказать: “этот процесс (не) достигает успеха”. В ITIL 4 данная…

Работает ли приоритизация изменений?

Одним из важнейших вопросов, которым следует задаться, решая задачу по запуску любого процесса – это по каким признакам должно стать понятно, что процесс действительно заработал. Недавно мне довелось снова принять участие в подобном обсуждении, и по итогам возникла идея поделиться на страницах портала REALITSM некоторыми выводами. Как известно, хорошей практикой при проектировании ключевых показателей эффективности, помимо оценки результативности процесса, является измерение уровня реализации ключевых видов деятельности. В данном контексте одним из ключевых признаков функционирования процесса управления изменениями является корректная работа системы приоритизации изменений. Как мы знаем (в том числе из ITIL), определение приоритета, то есть определение последовательности реализации изменений, основано…

Пару слов про управление реализовавшимися рисками

В очередной раз убеждаюсь, что это весьма и весьма полезно – ходить друг к другу на курсы. Конечно же, я про различные курсы, которые проводит Cleverics. Хотя это довольно дорого для компании – выделять двойные ресурсы под трёх-, а то и пятидневный курс, сложно переоценить объём полезной информации, которую можно получить во время курса. Всё потому, что тренер, с виду притаившийся в углу класса и что-то с упоением записывающий, имеет возможность не только подсмотреть приёмы подачи материала у коллеги и, что называется, со стороны оценить обучающие материалы, но и послушать вопросы участников. А в этих вопросах целый мир. В этот…

Сфера ответственности координатора релизов

Сразу уточним – в ITIL роль “Координатор релизов” не описана. Вопрос про сферу ответственности возник у слушателей курса ITIL RCV при обсуждении соответствующего раздела. Почему такой вопрос возник, в целом понятно. По аналогии с процессами управления изменениями или управления инцидентами при управлении релизами напрашивается необходимость фиксации так называемой “сквозной” ответственности за релиз. То есть выделения роли, отвечающей за координацию деятельности в рамках релиза на всём протяжении его жизненного цикла – от планирования до закрытия. По аналогии с “Координатором изменений” хочется назвать её “Координатор релизов”. Однако в ITIL V3 подобная роль не выделена. Справедливости ради следует отметить, что роли “Координатор изменений”,…

ITIL 4 и ожидания

Нужно ли изучать ITIL 4 только после того, как изучите ITIL V3? Вопрос возник не случайно, и мы его не придумали сами. Как показал опыт проведения учебного курса “ITIL 4 Foundation”, заметная часть слушателей полагает, что ITIL 4 представляет собой что-то вроде “следующего шага” после ITIL V3. В том смысле, что изучение ITIL V3 должно обязательно предшествовать изучению ITIL 4. Это не так. Совсем не так. Новая версия свода знаний, де-факто являющегося на сегодняшний день практически стандартом управления ИТ-услугами и названного в очередной инкарнации ITIL 4, вобрала в себя все “старые” и “новые” знания. Это становится очевидно, когда читаешь книгу…

ITFO4: шоколадки и автомобили, или “где доступ к ресурсу?”

Участвуя в курсе ITIL4 Foundation в качестве наблюдателя, обратил внимание, что многим участникам оказывается непросто понять и прочувствовать разницу между продажей товара и продажей услуги. Это особенно сильно проявлялось во время выполнения практических упражнений. Да и примеры, формулируемые слушателями во время лекционной части (когда тренер спрашивал: “Вам понятно? Тогда приведите пример!”), довольно часто содержали в себе определённую подмену понятий. Заключалась она в том, что услуга подменялась товаром. Например: “наша услуга – продажа шоколадки”. Или “продажа автомобиля”. Такое впечатление, что наличие того самого “товара” в составе сервисного предложения сбивает коллег с толку. Возникает ощущение, что достаточно только товара и – вуаля…

Как соотносятся роли Service Owner и Service Level Manager

Думаю, следует сразу уточнить, что рассматривать соотнесение ролей будем в контексте ITIL V3. В ITIL4 Foundation детального описания ролей, участвующих в практиках, нет, так что ждём. Мысль рассмотреть эти две роли, что называется, в связке, возникла не просто так. На неё навели вопросы слушателей курсов линейки ITIL Intermediate. Многих по-прежнему несколько сбивает с толку обилие вариаций названий ролей, начинающихся со слова “service”. А также до сих пор в некоторых компаниях циркулирует словосочетание “Service Manager”, которого в ITIL уже давно нет.  Апофеоза эта путаница достигает в контексте процесса управления уровнем услуг (Service Level Management). Попробую структурировать информацию из первоисточника. Итак, согласно…

Стандартные изменения в ITIL V3 и ITIL4

В каком случае изменения могут быть стандартизованы и выполняться, как запросы на обслуживание? Вопрос, безусловно, уже с бородой. Однако он по-прежнему не теряет своей актуальности. Во всяком случае, слушатели курса ITIL RCV задают его снова и снова. Одним из тезисов, вносящих некоторую путаницу в понимание, является следующий: стандартные изменения являются “заранее авторизованными”. На самом деле это вовсе не означает, что стандартные изменения не требуют никакой авторизации. Давайте вспомним, что сказано про стандартные изменения в ITIL V3 (перевод текста источника здесь и далее выполнен автором заметки): Стандартное изменение – это изменение услуги или другой конфигурационной единицы, для которого управлением изменениями заранее…

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;