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

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

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

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

В Lean-подходе Lead Time — это время от момента поступления запроса до его выполнения, то есть общий период, который заказчик ожидает результата. Process Time (также называемое Touch Time или Task Time) — это время, когда непосредственно осуществляется работа над запросом, без учета времени ожидания в очередях. Основная разница в том, что Lead Time учитывает все задержки и время ожидания, тогда как Process Time фокусируется только на активной работе. Поскольку именно Lead Time определяет восприятие скорости выполнения работы заказчиком, оптимизация обычно направлена на сокращение именно этого показателя, а не Process Time. Однако отношение Process Time к Lead Time служит важным индикатором общей эффективности потока.

Термин 'менеджер услуг' (service manager) в ITIL представляет собой общий термин для обозначения любого руководителя в организации поставщика услуг. В словаре ITIL 2011 он описывается как руководитель, который может относиться к менеджерам по взаимоотношениям с бизнесом, менеджерам процессов или к высшему руководству, отвечающему за ИТ-услуги в целом. При переходе на ITILv3 этот термин формально сохранялся, но фактически не использовался из-за слишком обширного смыслового наполнения. В ITIL 4 упоминание сущности 'менеджер услуг' полностью исчезло.

В дополнение к основным компонентам чек-лист предлагает рассмотреть стандартизацию изменений с низким риском, автоматизацию процессов через конвейеры (CI/CD), порядок взаимодействия с внешними поставщиками при обработке изменений и требования к компетенциям сотрудников, участвующих в реализации изменений. Эти рекомендации необязательны для всех случаев, но могут значительно повысить эффективность управления, особенно для определённых типов изменений. Например, стандартизация ускоряет выполнение низкорисковых изменений, а автоматизация позволяет интегрировать модель изменений в существующие CI/CD конвейеры.

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

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

Уровни зрелости в COBIT называют «побочным» продуктом обследования потому, что их основное назначение — иллюстрировать текущее состояние процессов или показать разницу между текущим и целевым состоянием, а не служить основной метрикой эффективности. При проведении оценки процессов основное внимание следует уделять конкретным контролирующим мероприятиям и их результативности, тогда как уровень зрелости возникает как дополнительный результат анализа, но не как целевая характеристика. Это подчеркивает, что не следует чрезмерно фокусироваться на достижении определенного уровня зрелости, а нужно концентрироваться на улучшении конкретных аспектов процессов.