Четыре основных типа реакции компаний: 1) Месячная премия фактически включена в зарплату, и можно только лишить ее, но не увеличить; 2) Корпоративная политика оплаты труда не позволяет легко встроить процессные метрики для поощрения, разовые премии требуют серьезного обоснования и выдаются за исключительные достижения, а не за стабильные результаты; 3) Отсутствует краткосрочное премирование, годовые премии зависят от общих успехов компании и слишком отдалены от текущих процессов; 4) Наличие системы месячного/квартального премирования, где руководитель может влиять на распределение премиального фонда и регулировать стимулирование сотрудников.

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

Геометрическое среднее решает проблему компенсации плохого показателя одной метрики высоким значением другой. Например, если оператор быстро перенаправляет все запросы (высокая своевременность K1), но не обеспечивает решения (низкая результативность K2), арифметическое среднее даст завышенную оценку эффективности. Геометрическое среднее в этом случае покажет 0%, так как K2=0%, что честно отражает отсутствие баланса. Таким образом, метод стимулирует сохранение баланса между скоростью обработки и качеством решения инцидентов.

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

Деление задач на сегменты (например, R&D, разработка, технический долг) часто приводит к формированию сило́сов — разделению команды на изолированные группы с разными целями и метриками. Это усиливает коммуникационные барьеры, способствует «перебрасыванию задач через стену» и снижает общую ответственность. Даже попытки компенсировать это через ротацию или общие награды не решают проблему полностью, так как стимулируют конкуренцию вместо сотрудничества.

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

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

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

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

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