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

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

Process Improvement Plan (PIP) - это план совершенствования процессов. При внедрении ITSM этот план претерпевает существенные изменения и расширяется, становясь планом совершенствования услуг (Service Improvement Plan, SIP). Теперь изменения процессов оцениваются именно с позиции их влияния на качество предоставляемых услуг, а не только с точки зрения оптимизации внутренних процессов.

CSI (Continual Service Improvement) - это процесс постоянного совершенствования услуг, который является универсальным и применим в любой отрасли. CSI помогает выявлять области для улучшения, планировать и внедрять изменения в процессы, измерять результаты и поддерживать постоянное развитие. Для не-ИТ организаций CSI особенно ценен при использовании вместе с ITIL Practitioner Guidance, который подробно описывает применение модели совершенствования. Это позволяет сервисным организациям любой направленности постоянно повышать качество предоставляемых услуг.

Управление проблемами существенно влияет на сокращение времени решения инцидентов, хотя часто его значение недооценивают. Если уменьшить общее количество инцидентов путем выявления и устранения их первопричин, это приведет к снижению нагрузки на персонал поддержки. Даже при одинаковой производительности сотрудников, меньшее количество инцидентов существенно снизит среднее время их решения из-за снижения очереди. Например, при 24 инцидентах в день (при условии их одновременного поступления утром) среднее время решения возрастает до 4 часов 10 минут, а при 12 инцидентах - падает до 2 часов 10 минут. Таким образом, управление проблемами влияет на процесс косвенно, сокращая поток инцидентов, что особенно важно с учетом неравномерного распределения инцидентов в течение дня (пиковой нагрузки в определенные часы).

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

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

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

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

Существуют различные алгоритмы агрегирования метрик, такие как среднее арифметическое, среднее геометрическое и другие. Выбор метода зависит от специфики бизнес-требований и характера данных. Для большого количества KPI рекомендуется разделять их на группы, рассчитывать интегральные показатели для каждой группы (возможно, разными методами), а затем объединять полученные результаты. Например, при оценке качества 30+ услуг можно выделить группы mission-critical, business-critical и обычные услуги, рассчитав интегральные показатели для каждой группы своими методами, а затем объединить их средним арифметическим или геометрическим (возможно, с разными весами). Аналогично при расчете показателя качества для одной услуги можно разделить KPI на категории (производительность, доступность, поддержка), рассчитать групповые индексы и затем объединить результаты.