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

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

CSI (Continual Service Improvement) может улучшить процесс управления проблемами несколькими способами: 1) Предоставление структурированного подхода к анализу - CSI предлагает методологию измерения, сбора данных и анализа, которая может быть применена к процессу управления проблемами для выявления его слабых мест и возможностей для улучшения. 2) Интеграция с другими процессами - CSI помогает устанавливать связи между управлением проблемами и другими процессами, такими как управление инцидентами, управление изменениями, позволяя создать более целостную систему управления. 3) Формирование культуры постоянного улучшения - CSI способствует созданию среды, в которой постоянный поиск способов улучшения работы становится частью повседневной практики. 4) Применение моделей улучшения - таки как PDCA (Plan-Do-Check-Act) или метод «Семи этапов» из ITIL CSI, которые помогают систематически подходить к улучшению процесса управления проблемами. 5) Измерение эффективности - CSI предоставляет инструменты для установления метрик и KPI, которые позволяют количественно оценить эффективность процесса управления проблемами. 6) Стимулирование проактивного подхода - CSI поддерживает сдвиг от чисто реактивного к проактивному и предиктивному управлению проблемами через анализ данных и выявление трендов.

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

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

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

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

В ITIL V3 2011 роль менеджера изменений не была отдельно описана - вместо нее существовали роли владельца процесса, менеджера процесса, инициатора, практика, авторизующего и участника CAB. В ITIL4 роль менеджера изменений (Change manager) стала официальной в рамках практики 'Поддержка изменений' (Change enablement) как специфическая роль, включающая управление жизненным циклом отдельных изменений и развитие самой практики. В ITIL4 также появилась дополнительная роль координатора изменений (Change coordinator) для работы в ограниченном контексте, в то время как владелец практики отвечает за общее управление практикой.

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

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