Предельные способы агрегирования, такие как среднее арифметическое и произведение, работают неэффективно при большом количестве KPI, потому что при увеличении числа показателей в случае среднего арифметического интегральный показатель стремится к 1 (100%), а при использовании произведения – стремится к 0. Это приводит к тому, что отдельные показатели теряют значимость и не вносят существенного различия в общую оценку.

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

Существуют логичные сочетания ИТ-процессов, которые способны обеспечить 100% загрузку менеджера в крупной компании. К таким комбинациям относятся, например, управление сервис-уровневыми соглашениями (SLM) совместно с работой в рамках совета по изменениям (PRB), управление изменениями (CHG) в сочетании с управлением конфигурациями (CFG), а также управление инцидентами (INC) даже без дополнительных процессов. Эти пары процессов взаимодополняют друг друга и позволяют оптимизировать работу менеджера, обеспечивая ему комплексную ответственность за ключевые аспекты ИТ-сервисов.

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

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

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

Три основных принципа, помогающие интегрировать деятельность по развитию в повседневную работу компании: 1) Деятельность по развитию должна быть обязательной и «встроенной» в обычную ежедневную работу почти каждого сотрудника, поскольку возможности для улучшений появляются каждый день. 2) Время на развитие должно быть чётко определено и выделено явным образом, как часть работы. 3) Необходимо не позволять сотрудникам заменять выделенное время на развитие операционными задачами, поскольку рутина стремится занять всё доступное время.

Триггерами для создания новых статей являются завершение проектов, проведение обмена опытом между сотрудниками, обнаружение интересных решений или находок на обучении, а также другие значимые события, которые можно назвать «якорями». Эти события служат поводом для обязательного написания статей в Базу знаний.

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

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