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

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

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

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

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

Интегральный показатель BS (Balanced Score) рассчитывается с помощью метода взвешенного среднего, но с ключевым отличием: веса KPI являются динамическими и зависят от значений показателей. Чем ниже значение KPI (чем больше отклонение от целевого), тем выше его вес. Формула включает параметр Wmax, который определяется через выбранное руководителем значение MS (Marginal Score). Для случая с N равнозначными KPI, если 9 из них равны 100%, а один – 0%, интегральный показатель будет равен MS. Это обеспечивает более значительное снижение оценки за провал одного показателя, чем при стандартных методах.

При настройке системы оценки с использованием методики динамических весов руководитель определяет для каждого KPI параметр MS (Marginal Score), который указывает, какое значение должен получить интегральный показатель, если все KPI равны 100%, а один KPI равен 0%. Например, при N=10 и MS=50% это означает, что провал по одному важному показателю приведет к снижению общей оценки до 50%. Для менее критичных показателей MS может быть выше (например, 75%), что делает их провал менее значимым для общей оценки. Таким образом, руководителю нужно установить только один параметр для каждого показателя, что упрощает настройку системы оценки.

Тип ИТ-услуги напрямую определяет структуру процесса управления мощностями. Если услуга определена как предоставление ресурса, управление мощностями сводится к одному подпроцессу Resource Capacity Management. Если услуга ассоциирована с работоспособностью ИТ-системы, необходимы два подпроцесса: System Capacity Management и Resource Capacity Management. Если услуга ориентирована на бизнес-процессы, требуются все три подпроцесса: Business Capacity Management, System Capacity Management и Resource Capacity Management.

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

Принципиальная сложность внутренних сервисных отношений по сравнению с коммерческими заключается в том, что внутри компании часто наблюдается разделение функций заказчика и плательщика, множественность заказчиков для одной услуги и сложные пересекающиеся требования от разных подразделений. В коммерческих сценариях (например, предоставление услуг связи, IaaS, SaaS) отношения обычно более четко структурированы и основаны на рыночных механизмах, где заказчик и плательщик - это один и тот же субъект. Во внутренних корпоративных отношениях же сложность взаимодействия значительно выше, поскольку решения принимаются в рамках единой организации с разными интересами и целями у подразделений, что делает модель Value chain слишком упрощенной для адекватного описания реальных процессов.