Роли менеджера изменений в ITIL часто вызывают неоднозначность, потому что в ITIL V3 эта роль не была описана как отдельная, а вместо нее упоминались другие роли, такие как владелец процесса и практик. В зависимости от контекста и организации роль 'менеджера изменений' могла включать в себя различные функции, иногда совмещая обязанности менеджера процесса, администратора изменений и председателя CAB. Даже в ITIL4, где роль менеджера изменений стала официальной, остается гибкость в распределении обязанностей: менеджер изменений может выступать как универсальный ролевой игрок, объединяющий несколько функций, или его обязанности могут быть распределены между менеджером изменений и координаторами, в зависимости от масштаба организации и сложности изменений.

Классификация процессов на управленческие, основные и обеспечивающие помогает в управлении организацией, обеспечивая структурированный подход к анализу и оптимизации деятельности. Эта система позволяет выделить ключевые области ответственности, определить взаимосвязи между различными частями организации, распределить ресурсы более эффективно и выявить узкие места в бизнес-процессах. Структурирование процессов по категориям помогает руководителям понять, какие процессы напрямую создают ценность для клиентов, какие обеспечивают управление, и какие поддерживают операционную деятельность, что в свою очередь способствует более целенаправленному управлению и стратегическому планированию.

Основные ограничения гибких методологий в контексте эксплуатации ИТ связаны с их фокусом на разработке и временных целях, а не на долгосрочной поддержке. Гибкие методологии, такие как Agile, не обеспечивают четкой структуры для постоянного обслуживания систем после завершения проекта. Отсутствует механизм управления повторяющимися стандартными задачами, которые не требуют итеративного развития. Кроме того, гибкие подходы часто не учитывают потребности в документировании и стандартизированных процессах, необходимых для эффективной эксплуатации.

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

Приемлемыми причинами для перевода в статус 'Ожидание' являются объективные внешние факторы, не зависящие от исполнителя: ожидание поставки оборудования, комплектующих или материалов; необходимость получения информации или решения от сторонних подразделений, компаний или лиц; ожидание возвращения ответственного сотрудника из отпуска или командировки; необходимость согласования с клиентом этапов работ; ожидание завершения смежных задач, критичных для продолжения процесса. Не являются приемлемыми причины, связанные с внутренними проблемами отдела: нехватка времени у сотрудника, отсутствие четкого плана работы, отсутствие навыков или знаний для выполнения задачи без запроса помощи, откладывание работы на потом без явной внешней причины.

Руководитель должен ответить на следующие вопросы: какие именно параметры нужно измерять и почему; как именно будут проводиться измерения; какие решения будут приниматься на основе полученных данных; кто будет отвечать за использование результатов измерений; какие изменения в деятельности ожидать после внедрения системы измерений; как оценивать эффективность самой системы измерений.

Мастер-класс 'Проектируем канбан для ИТ' представляет собой практическое занятие, в ходе которого участники работают над созданием и оптимизацией канбан-доски. Занятие включает выполнение заданий разной сложности: первое задание направлено на понимание базовой концепции визуализации процессов, а второе задание является более сложным и помогает осознать, что канбан — это не только про визуализацию, но и про поток задач, ограничение количества задач в работе, вытягивающую систему и выявление узких мест в процессе. Мастер-класс также включает обсуждение эволюционного подхода к внедрению канбана и возможность практической работы в группах для лучшего усвоения материала.

Ключевые элементы, отличные от обычного таск-трекера, включают: визуализацию потока работ с чёткими правилами перемещения задач между этапами, установку ограничений WIP (Work in Progress) для предотвращения перегрузки сотрудников, организацию вытягивающей системы, где задачи берутся в работу только при наличии свободных ресурсов, и акцент на анализе и оптимизации процесса через выявление узких мест. В большинстве таск-трекеров отсутствует встроенная поддержка этих функций, что приводит к их неполному использованию.

Ограничение WIP (Work in Progress) положительно влияет на эффективность команды, так как предотвращает перегрузку сотрудников множеством одновременных задач. Это позволяет сосредоточиться на завершении текущих задач, снижает время ожидания и повышает скорость выполнения работ. Кроме того, ограничение WIP помогает выявить узкие места в процессе, так как при достижении лимита становится ясно, на каком этапе возникает задержка, что позволяет своевременно вносить корректировки в процесс.

Основная проблема заключается в отсутствии достоверных данных о том, какие инциденты связаны с конкретными изменениями. Даже если формально привязать инциденты к изменениям, трудно гарантировать точность этих связей, так как нет надежного процесса подтверждения причинно-следственной связи. Сотрудники не мотивированы тратить время на дополнительное указание связи между инцидентом и изменением, особенно когда их основная задача - быстрое восстановление сервиса. Это делает статистику по влиянию изменений на количество инцидентов недостоверной.