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

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

Управление доступностью в ITIL представляет собой процесс, задачи которого включают создание и ведение плана доступности, участие в диагностике и решении инцидентов и проблем, связанных с доступностью, оценку влияния изменений на доступность услуг и ресурсов. Однако, согласно анализу, эти задачи фактически пересекаются с другими процессами, такими как управление инцидентами, проблемами, изменениями, управление уровнями сервиса (SLM), управление непрерывностью и мощностями. Процесс управления доступностью считается уникальным изобретением ITIL, так как в других стандартах он либо не выделен отдельно, либо объединен с другими процессами.

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

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

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

Эта рекомендация вызывает сомнения, потому что она противоречит принципам модели определения приоритета, описанной в ITIL, где приоритет рассчитывается на основе уровня влияния и срочности. Если сроки разрешения инцидентов рассчитываются строго по приоритету, это сводит на нет ценность самой приоритизации, так как приоритизация работает на оперативность выполнения задач, а не на расчёт их сроков. При таком подходе теряется гибкость в управлении инцидентами и их адекватная обработка соответственно реальному влиянию на бизнес.

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

Необходимость в CI/CD может быть не столь очевидной для команды, которая разрабатывает программное обеспечение для будущего релиза, MVP или первой версии, который запланирован на значительный срок вперед (например, через полгода-год). В таких случаях основная проблема заключается не в организации процесса доставки изменений, а в самом создании работоспособного продукта. До тех пор, пока нет боевой среды с реальными живыми пользователями, внедрение сложного конвейера развёртывания может оказаться преждевременным и отвлекающим от основных задач разработки. В этой ситуации ресурсы команды лучше направить на создание качественного продукта, а вопросы автоматизации процессов доставки и развертывания можно решать уже тогда, когда будет определенность с пользовательской аудиторией и необходимостью частых обновлений.

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