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

Обучение
по ITIL 4, ITSM, PRINCE2
Деловые
игры
Консалтинг
по управлению ИТ

Игорь Гутник

А цикл где?

Многие из тех, кто знаком с ITIL® v3, воспаряя/погружаясь в дивный новый мир ITIL 4, почти сразу задают вопрос: «А где же здесь жизненный цикл услуги?» И, действительно, где? Куда дели? Коротко напомню, жизненный цикл [ЖЦ] услуги – модель, которая описывает весь путь услуги от начала обсуждения идеи до вывода из эксплуатации, через бизнес-обоснование (business case) и согласование концепции услуги (service charter), формирование проектной документации (service design package, SDP), построение, внедрение и тестирование, передачу в эксплуатацию и, собственно, эксплуатацию услуги. И всё это в среде и при поддержке постоянного совершенствования (continual service improvement). Кроме того, модель полезна тем, что формирует...

«А вместо процессов у них там практики…»

Такую фразу довольно часто можно услышать или прочитать в обсуждении новой версии ITIL® 4. Корректно ли это утверждение? Насколько «вместо»? Есть ли разница между процессами и практиками? Действительно, существенную часть объёма книги составляет раздел, в котором для тех, кто знаком с предыдущими версиями ITIL, очень много знакомых названий: «Управление инцидентами», «Управление проблемами», «Управление доступностью», «Управление уровнем услуг», «Управление поставщиками» и т.д.Только теперь это названия не процессов (process), а практик (practices).Понятие «процесс» в ITIL 4, конечно же, есть. Определение его стандартное (в том смысле, что оно совпадает с аналогичным определением в ISO/ГОСТ): «Набор взаимосвязанных или взаимодействующих видов деятельности, который преобразует входы...

Неизменно верные своим принципам (или нет)

В первой публикации новой версии ITIL® («ITIL Foundation: ITIL 4 Edition»), вышедшей 18 февраля 2019 года, описан набор руководящих принципов. Как известно, это не первая попытка сформулировать систему принципов. Впервые в библиотеке ITIL принципы были сформулированы в книге «ITIL Practitioner Guidance», выпущенной компанией AXELOS в 2016 году. Хороший обзор этих принципов в своё время сделал Павел Дёмин. В 2016 году принципов было девять, а в 2019 – семь. Разумеется, любой любознательный читатель новой книги ITIL, знакомый с предыдущей публикацией, задастся вопросом: «Что изменилось? Почему/зачем?» Если в качестве принципов мы рассматриваем тезисы, которые помогают принимать управленческие решения, т.е. утверждения, опираясь на...

Люди для CMDB или CMDB для людей

«Кто на ком стоял? — крикнул Филипп Филиппович, — потрудитесь излагать ваши мысли яснее» Михаил Булгаков, «Собачье сердце» По-моему, Игорь Фадеев в конце прошлого года написал отличную заметку . Как мне кажется, проблема, решение которой он предлагает, встречается в компаниях, пытающихся построить практику управления конфигурациями, не так уж редко. Я же при обсуждении этой заметки в очередной раз вспомнил, как при первом прочтении ITIL мне показалось, что в части описания управления конфигурациями в книге содержится парадокс, терминологический казус. Как выяснилось, парадокса нет. Но в реальной жизни некотоые попытки организовать практику управления конфигурациями иногда напоминают попытку воспроизвести этот парадокс (может быть тоже невнимательно...

Заказчик – кто это?

При обсуждении взаимодействия ИТ-службы (будь то внутреннее ИТ-подразделение в организации или сторонняя ИТ-организация) с контрагентами, довольно часто происходит блуждание в, казалось бы, трёх соснах. Как обозначить одну сторону этих взаимоотношений, обычно вопросов не возникает — «ИТ» или «поставщик ИТ-услуг» (вслед за ITIL’овским «IT service provider»). А вот для обозначения второй могут использоваться разные слова: «заказчик», «бизнес», «потребитель», «клиент», «пользователь» (реже «покупатель» и т.д.). Причём, когда в обсуждении участвуют несколько коллег, да ещё с опытом работы в разных компаниях, ситуация напоминает знаменитое столпотворение. С «пользователями» разбираемся довольно быстро – это те, кто пользуется ИТ-услугами; user-ы в привычном для ИТ-специалистов смысле слова. А...

Оттого, что в кузнице не было гвоздя

На днях в сети в очередной раз проскочило описание примечательной истории, случившейся десять лет назад, в марте 2008 года при открытии в лондонском аэропорту Хитроу знаменитого Терминала 5. Текст, который мне попался, по-моему, прекрасен. Поэтому, несмотря на его большой размер, рекомендую к прочтению. Если коротко, то проект по строительству огромного терминала, уникального по своей конструкции, размеру, системе сортировки багажа и многим прочим параметрам, был мощно разрекламирован, имел серьёзный бюджет (порядка 8 млрд долларов), огромные сроки. Его открытие являлось важным шагом на пути повышения конкурентоспособности одного из крупнейших авиаперевозчиков компании British Airways [BA] и аэропорта Хитроу. Терминал в дальнейшем неоднократно получал...

SLA или...

В нелегком (без шуток) но интересном деле по построению сервисных отношений можно выделить две важные стороны: формальную и неформальную. Отсутствие формализации в отношениях между поставщиком услуг и заказчиком может приводить к разному понимаю одних и тех же вопросов, отсутствию чёткого понимания того, кто и за что отвечает, отсутствию одинакового понимания условий предоставления услуги и критериев её оценки. Более того, это приводит к отсутствию основы для адекватного планирования ресурсов поставщика, а, значит, к повышению рисков нарушения уровней услуг. В случае с внутренним поставщиком (например, ИТ-подразделение в составе организации) это, скорее всего, будет ещё и нерациональным для организации в целом. Степень формализации...

Чем канбан отличается от списка задач?

В последнее время в разговорах довольно часто воспроизводится в сущности один и тот же шаблон: … — У нас Agile. — А в чём заключается? — Ну, мы используем в работе канбан. — Каким образом? — Все задачи на стене висят (в колонках «Надо сделать», «Делаем», «Сделано»). … Т.е. некоторые ставят знак равенства в следующих парах «Agile = Канбан» (что не так) и «Канбан = таск-трекер» (что не совсем так). Вот, и получается, висит на стене табличка с задачами – стало быть, Agile. И если с первым уравнением/неравенством обычно разбираемся довольно быстро, то второе требует больше времени. В принципе «всё...

Граница между постоянным совершенствованием и управлением проблемами

Вопрос о том, имеет ли смысл включать проактивное управление проблемами как отдельную процедуру в процесс управления проблемами (problem management, PRB), или это отдельный процесс, отличающийся по своей природе от реактивной составляющей управления проблемами обсуждался уже неоднократно. Также затрагивался и вопрос взаимоотношения процесса управления проблемами с практикой постоянного совершенствования (continual service improvement, CSI). Интересные заметки по данной теме (и ещё более интересные обсуждения в комментариях к ним) можно посмотреть, например, здесь и здесь, а также в комментариях к этой заметке В результате размышлений на эту тему, обсуждений на курсах и споров с коллегами у меня сформировалась картина, которой хочу поделиться. (Спойлер —...

Вот купил себе значок...

На портале уже публиковалась заметка о том, что AXELOS (правообладатель ITIL, PRINCE2 и других управленческих практик) в целях популяризации программы «ITIL Membership» (направлена на создание сообщества вокруг ITIL) предлагает всем, сдавшим с начала 2018 года экзамен «Основы ITIL» («ITIL Foundation»), бесплатную годовую подписку на эту программу. Аналогичная программа, кстати, создана и по PRINCE2 (методология управления проектами). Правда, для бесплатного получения этой годовой подписки «PRINCE2 Membership» необходимо сдать экзамен более высокого уровня («PRINCE2 Practitioner»), а не «Основы PRINCE2» («PRINCE2 Foundation»). С момента начала этого аттракциона невиданной щедрости прошло более трёх месяцев. Но пока я не встречал людей, которые бы воспользовались предложением. Нужно...

Принципы DevOps от DASA

На сайте сообщества по развитию компетенций DevOps и Agile, ассоциации DASA (DevOps Agile Skills Association), опубликован список принципов DevOps. Авторы предваряют этот список формулировкой задачи, решение которой было бы крайне полезно. Существует множество определений DevOps. И многие из них адекватно объясняют один или более аспектов важных для предоставления ИТ-услуг. Вместо попыток сформулировать наше собственное исчерпывающее определение, мы предпочитаем подчеркнуть шесть принципов DevOps, которые мы считаем важными для тех, кто применяет или переходит на подходы DevOps к организации работы. Но, как видно из краткого изложения этих принципов ниже, подход к формированию списка вряд ли можно признать системным. Например, если в первом...

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM