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

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

В PIR применяются количественные и качественные критерии: соблюдение бюджета и сроков, достижение целевых метрик (например, рост производительности на 15%), уровень удовлетворенности пользователей, соответствие требованиям и анализ рисков. Также оцениваются непредвиденные последствия и влияние на другие процессы. Для каждого критерия устанавливаются пороговые значения, и на основе их сравнения с фактическими результатами определяется успешность внедрения.

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

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

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

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

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

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

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