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

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

Игорь Гутник

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

В первой публикации новой версии 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 к организации работы. Но, как видно из краткого изложения этих принципов ниже, подход к формированию списка вряд ли можно признать системным. Например, если в первом…

Функция

Одна из самых интересных вещей в проведении тренингов, на мой взгляд, заключается в возможности обсудить темы, которые, казалось бы, уже много раз обсуждались, и о которых, вроде бы, все уже поспорили и договорились. Но собственный взгляд, личный практический опыт, которые могут сильно различаться у участников одной группы позволяет посмотреть на привычное через призму новых вопросов и дискуссий. На одном из последних курсов ITIL® OSA (Operational Support and Analysis) собралась довольно сильная группа с весьма разнообразным практическим опытом. Представители внутренних ИТ-служб и внешних провайдеров ИТ-услуг (системных интеграторов и ИТ-дочек крупных компаний). У каждого есть своя сложившаяся картина мира. Если говорить о…

Запросы или потребности?

Во время обсуждения взаимодействия ИТ и бизнеса на одном из последних курсов возникла дискуссия на тему бизнес-ориентированности ИТ. По мере обсуждения были выявлены две точки зрения на то, что такое готовность ИТ помогать бизнесу. ИТ-подразделение должно качественно отрабатывать запросы бизнеса ИТ-подразделение должно удовлетворять потребности бизнеса «Мы (ИТ) должны выявлять потребности бизнеса, те задачи, которые бизнес пытается решить, и попытаться помочь ему в этом» – говорили одни. «Мы (ИТ) должны чётко отрабатывать ТЗ (техническое задание). Мы не можем «фантазировать». Да и как, скажите на милость, в случае отсутствия чёткого ТЗ фиксировать целевую картину в договоре?» – возражали другие. В этой связи…

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM