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

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

Обсуждения на учебных курсах

Кто отвечает за конвейер развёртывания?

Нужно очень сильно отстать от жизни (примерно лет на 5-7, что по нынешним временам приравнивается к вечности), либо иметь крайне веские аргументы, чтобы не использовать для доставки готового кода до среды эксплуатации конвейер развёртывания (в народе часто именуемый конвейером CI/CD, что в данном случае непринципиально). Техническая сторона вопроса – как построить конвейер – в большинстве случаев понятна, если не очевидна. Инструментов море, идеология ясна, собрать конвейер можно в простых случаях за час, в сложных – за пару недель. Организационная же сторона вопроса не так проста, как кажется. Кто должен/может его создать? Кто обеспечит функционирование? Кто починит, когда сломается? Кто будет…

ITIL 4 и ожидания

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

Существует ли эффект Даннинга-Крюгера?

Многие слышали об этом эффекте. По легенде, менее компетентные люди склонны завышать собственную самооценку, в то время как более компетентные люди скорее будут её занижать. Соответственно, принимаемые решения могут быть неадекватны обстоятельствам по причине когнитивного искажения. Данное наблюдение сопровождается дополнительными свойствами. К примеру, декларируется, что эффекту подвержены практически все люди, вопрос только в степени искажения. Люди низкой квалификации неспособны осознавать свои ошибки, в силу той самой низкой квалификации. Людям с большим количеством знаний в определённой предметной области бывает непонятно, почему для остальных всё так сложно, ведь “на самом деле” всё довольно просто. Наверное, какая-то часть описания данного эффекта соответствует действительности….

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

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

А цикл где?

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

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

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

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

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

Зачем нужен Change Management?

Вопрос без подвоха. Ну почти. Его контекст довольно-таки прост. Если конкретизировать, то он звучит так: “как сформулировать для руководства бизнеса и ИТ, а также для персонала ИТ-департамента преимущества от инвестиций в постановку и автоматизацию процесса управления изменениями?”. То есть нужно максимально просто и понятно объяснить указанным заинтересованным сторонам, зачем нужно упорядочить и формализовать деятельность по управлению изменениями. Для начала попробуем наморщить лоб, с умным видом пошелестеть страницами умных книг (вы знаете, каких) и выдать “научную” формулировку. Во всем известной библиотеке ITIL, в книге Service Transition написано довольно много слов про “назначение и задачи”, “ценность для бизнеса”, “организационные преобразования”, “формирование культуры”…

Руководители проектов в эпоху Agile (когда всё гибко, бережливо и продуктово)

Необходимое примечание (disclaimer): я не имею ничего против управления проектами вообще и руководителей проектов в частности. Мне известна область применения проектного менеджмента, равно как и его ограничения. Я знаю менеджеров проектов, способных получить качественный результат в совершенно не располагающих к тому условиях; я также видел РП, польза от которых ограничивалась созданием протоколов встреч. Во многих проектах я сам был на роли менеджера, и хорошо знаю, в чём заключается эта работа. Ну и формальное обучение проходил, разумеется. Данная заметка не имеет цели поставить под вопрос пользу от дисциплины управления проектами в общем случае. Лишь в частном. Теперь перейдём к теме. В…

От MVP к продукту, а затем к продукту 2.0: как мы развиваем один из наших учебных курсов

Обсуждения и дискуссии на учебных курсах – самые главные составляющие учебного процесса. Действительно, ключевая разница между лекцией на 50+ человек и интенсивным тренингом заключается в вовлечении каждого участника. Дискуссии важны по следующим причинам: во-первых, это возможность для тренера понять успевает ли группа за рассказом; во-вторых, это возможность для слушателя прояснить непонятный для него момент; в-третьих, это потрясающая по своей силе возможность примерить то, о чём говорит тренер, на реальную ситуацию конкретного участника. Только так можно получить пользу от обучения, только путём сравнения, примерки, приближения к действительности. В учебном курсе “Основы DevOps” предусмотрено примерно двадцать точек, где тренеру необходимо организовать обсуждение….

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

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

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;