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

Процесс руководства в COBIT 5 рассматривается как деятельность, осуществляемая извне относительно управляемого объекта, потому что руководство взаимодействует с объектом как с «черным ящиком»: на вход подаются требования, правила и политики, а на выходе формируются отчеты о результатах. Руководство не вмешивается в детали реализации процессов, не управляет ресурсами напрямую, а фокусируется на достижении стратегических целей и соблюдении интересов заинтересованных сторон. Таким образом, руководство определяет направление и контролирует результат на высоком уровне, оставляя детали реализации функции управления.

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

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

Поле «Срочность» с градацией (низкая, средняя, высокая) часто используется бизнесом для завышения приоритета запросов, так как максимальная отметка «высокая» кажется единственно правильным выбором при любом запросе. Это приводит к перекосу в управлении изменениями: важные emergency-изменения теряются среди множества ненужно приоритизированных изменений, а процесс принятия решений замедляется из-за необходимости перепроверки каждого случая. Кроме того, сама градация не учитывает контекст — например, «высокая срочность» может означать как реальную угрозу для бизнеса, так и личную заинтересованность сотрудника.

Традиционные KPI фокусируются только на соблюдении Tmax, игнорируя тот факт, что даже кратковременные простои вблизи лимита могут нанести бизнесу значительный ущерб. Например, при Tmax = 4 часа инцидент, устраненный за 3,9 часа, формально считается успешным, хотя за это время бизнес мог потерять клиентов или прибыль. Новый подход учитывает реальное влияние на операции через Tmin, что позволяет выстроить более справедливую систему оценки, ориентированную на реальные результаты, а не формальное соблюдение сроков.

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

В тексте приведены два примера имитации активности: массовое закрытие проблем с кодом 'Решение нецелесообразно', при котором KPI остается близким к единице, несмотря на отсутствие реальной пользы, и регистрация дублей проблем, которые сразу закрываются как дубликаты. Эти действия создают видимость высокой активности, но не добавляют ценности процессу управления проблемами.

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

Вероятностный характер поступления инцидентов, описанный как стохастические отклонения, существенно влияет на среднее время их решения. Инциденты обычно распределяются неравномерно в течение дня с пиками нагрузки (распределение в форме 'верблюда'), что создает эффект очереди. Даже при постоянной производительности персонала, если инциденты приходят неравномерно, среднее время их решения может быть значительно выше, чем при равномерном распределении. Например, 24 инцидента, решаемые с производительностью 20 минут каждый, теоретически должны обрабатываться за 20 минут на инцидент при равномерном поступлении, но при массовом поступлении утром среднее время возрастает до 4 часов 10 минут. Это связано с тем, что последующие инциденты вынуждены ждать, пока предыдущие будут обработаны, что приводит к экспоненциальному росту среднего времени при увеличении количества одновременно поступающих инцидентов.