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

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

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

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

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

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

Обычно задаются два основных вопроса: 1) Не работает только у вас или другие коллеги также сталкиваются с этой проблемой? 2) Совершенно не работает ИТ-услуга или недоступна только часть функционала? На основании ответов определяется один из четырех уровней влияния. Однако эта схема часто усложняется дополнительными критериями, так как базовые вопросы имеют недостатки: пользователи могут не знать о проблемах коллег, а граница между 'совсем не работает' и 'частично не работает' может быть неочевидной в конкретных ситуациях.

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

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

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