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

Ограничение работ в процессе (WIP) в системе Kanban — это установленный верхний предел количества задач, которые могут одновременно находиться на определённом этапе процесса. Это ограничение необходимо для предотвращения перегрузки рабочих этапов, снижения времени ожидания и повышения скорости прохождения задач через весь процесс. В DevOps-практиках WIP также позволяет зарезервировать ресурсы для неплановых задач, таких как решение инцидентов. В канбане можно устанавливать как общие ограничения для всего процесса, так и отдельные ограничения для разных категорий задач, что делает систему более гибкой и устойчивой к возникающим проблемам.

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

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

Операционный Уровневый Договор (OLA) предполагается как документ, который определяет обязательства внутреннего подрядчика по отношению к поставщику услуг, который тот предоставляет своим заказчикам (при этом между поставщиком и заказчиком заключены SLA). Однако, если внимательнее рассмотреть суть OLA, то оказывается, что с точки зрения подрядчика OLA на самом деле является SLA. То, что для одного субъекта выглядит как OLA, для другого может быть SLA, потому что предоставляется услуга, поддерживающая выполнение операций и обеспечение услуг внешним клиентам. Это значит, что OLA как отдельный документ не существует, а является SLA с точки зрения другого участника сервисных отношений.

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

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

Назначение процесса определяет его базовую функцию и место в общей процессной модели без привязки ко времени, тогда как цели процесса – это конкретные измеримые результаты, которых нужно достичь в определённый период. Ключевые отличия: - Назначение формулируется как описание общей задачи (например, "обеспечение качества услуг через устранение инцидентов"). - Цели формулируются в формате SMART: с глаголами совершенного вида ("увеличить долю решённых инцидентов до 95%"), измеримы и привязаны к срокам (квартал, год). Цели регулярно пересматриваются, в отличие от назначения, которое стабильно. Ответственность за назначение несёт дизайнер процессов, за цели – владелец процесса.

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

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