Регламент управления изменениями и релизами в контексте разработки и внедрения прикладного программного обеспечения состоит из двух основных компонентов: 1) Документ, определяющий основные стадии создания новой автоматизированной системы или выполнения доработок («Положение о разработке прикладного ПО»), который описывает состав работ, ответственных лиц, входные и выходные документы для каждой стадии. 2) Документ, определяющий порядок приёмки новых систем в эксплуатацию («Положение о внедрении информационных систем»), который включает порядок и охват тестирования, подготовку тестовых сред, опытную эксплуатацию и другие аспекты внедрения. Этот регламент может дополняться политиками релизов по информационным системам, что позволяет согласовать с бизнесом календарь релизов и определить необходимость и порядок выделения ресурсов на проведение пользовательского тестирования (UAT). В совокупности эти документы обеспечивают структурированный процесс управления изменениями и релизами при разработке и внедрении программного обеспечения.

Расширенный жизненный цикл инцидента подчеркивает разграничение между управлением инцидентами и управлением проблемами. Управление инцидентами сосредоточено на оперативном восстановлении предоставления услуги, в то время как управление проблемами направлено на поиск и устранение корневых причин сбоев, предотвращающих их повторение. В процессе расширенного жизненного цикла диагностика разделяется: базовая диагностика нужна для быстрого восстановления работы, а более глубокая диагностика переходит в зону ответственности управления проблемами.

Процесс управления проблемами в ИТ включает не только устранение технических ошибок в инфраструктуре, но и работу с организационными вопросами, такими как исполнение, взаимодействие, принятие решений и контроль. Это позволяет выявлять и устранять корневые причины инцидентов еще до того, как они приведут к сбоям в работе систем. Такой подход обеспечивает комплексное решение проблем и способствует системной работе по развитию управления.

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

Ролевая модель управления доступом (RBAC) не является панацеей, потому что она не может охватить все возможные сценарии доступа, особенно уникальные или редкие. Регулирование каждого возможного случая через создание специализированных ролей привело бы к чрезмерной сложности и непрактичности системы. Также модель не учитывает динамические изменения в должностях или обязанностях сотрудников, поэтому её эффективность повышается при комбинировании со стратегиями, такими как управление доступом через запросы и регулярный аудит прав, что обеспечивает гибкость и адаптивность системы управления доступом.

В ITIL v3 определение инцидента включало два предложения: «Незапланированное прерывание или снижение качества ИТ-услуги. Сбой конфигурационной единицы, который еще не повлиял на услугу, также является инцидентом, как, например, сбой одного диска из массива зеркалирования». В ITIL 4 второе предложение отсутствует, и определение стало короче: «Незапланированное прерывание или снижение качества услуги». Однако в руководстве по управлению инцидентами ITIL 4 указано, что практика все равно включает в себя восстановление нормальной работы ресурсов даже если их сбой не виден пользователям. Таким образом, ключевые смыслы остались прежними, различие скорее терминологическое.

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

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

При внедрении системы измерения эффективности в ИТ-процессах часто совершаются следующие ошибки: 1. Механическое копирование KPI из рекомендательных материалов (таких как ITIL) без понимания, что это лишь примеры, а не готовые решения, подходящие для конкретной организации. 2. Стремление измерить все возможные параметры процесса, что приводит к чрезмерной сложности и малой полезности системы измерений. 3. Игнорирование здравого смысла: попытка полного управления через измерения и безоговорочное доверие только технически "объективным" данным при отвержении субъективной, но важной информации (опросы удовлетворенности пользователей). 4. Отсутствие целостного подхода: KPI для отдельных процессов разрабатываются изолированно, без учета их роли в общей системе управления ИТ и взаимосвязей с другими процессами. 5. Сбор непригодных данных: иногда возникают сложности со сбором данных, они недоступны или вызывают сомнения в своей объективности, что делает KPI бесполезным для принятия управленческих решений. 6. Формирование KPI без четкого понимания целей измерения: что именно нужно измерять и зачем это нужно, что приводит к использованию показателей, не помогающих в принятии решений.

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