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

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

Согласно ITIL V3 в процессе управления уровнем услуг (Service Level Management) участвуют следующие ключевые роли: Владелец процесса (Service level management process owner), Менеджер процесса (Service level management process manager), Владелец услуги (Service owner) и Менеджер по взаимоотношениям с бизнесом (Business relationship manager). В указанной статье особое внимание уделяется связке ролей Service level manager и Service owner, рассматривая их зоны ответственности и необходимость тесного взаимодействия.

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

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

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

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

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

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

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