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

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

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

Японские свечи на бирже отображают диапазон изменений цены (от минимума до максимума) за период, что напрямую сравнимо с анализом диапазона показателей качества ИТ-услуг (от минимального до среднего значения). В биржевой аналитике такие графики используются для оценки волатильности и стабильности актива. Аналогично, в ITSM диапазон между минимальным и средним показателем показывает, насколько стабильно выполняются SLA: узкий диапазон сигнализирует об однородно высоком качестве, а широкий — о наличии провалов в отдельных услугах. Это делает отчёт интуитивно понятным для руководителей, привыкших к финансовым метрикам.

Методическое обеспечение ИТ-бюджетирования может быть 100-процентным, поскольку ITIL предоставляет четкие, структурированные процессы и руководства для каждого этапа бюджетирования. Это включает в себя последовательные шаги от получения бизнес-планов через BRM/SLM до расчета стоимости услуг и формирования бюджета, где каждый этап имеет специфические методики, алгоритмы и формулы. Это делает процесс предсказуемым и документируемым, позволяя достичь полной методической проработки без пробелов.

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

Важно, что предложенная метрика изменяется в диапазоне [0;1], потому что нормированность метрики позволяет легко интерпретировать её значения, сравнивать производительность в разные периоды времени и между различными группами или подразделениями. Нормированные метрики упрощают установление целевых значений, так как менеджеры заранее знают, к каким показателям стремиться (например, достичь 80-90%), а также позволяют выявить, когда значение метрики становится критически низким и требуется вмешательство для улучшения процесса.

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

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

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