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

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

Для определения владельца сквозного процесса необходимо проанализировать обязательные обязанности этой роли по каждому пункту из выбранного источника (например, ITIL), затем оценить степень критичности каждой обязанности для конкретной организации и процесса, используя, например, десятибалльную шкалу. Где 10 баллов означает, что процесс без выполнения этой обязанности 'не выживет' или уже вызывает проблемы. Полученный приоритизированный список требований покажет, какие полномочия и возможности должны быть у владельца процесса в данной организации. Важно учитывать, что для разных процессов и организаций эти требования могут существенно отличаться в зависимости от критичности процесса, уровня сложности, организационной структуры и культурных особенностей. Например, в организациях, только начинающих внедрять процессный подход, владельец часто должен обладать широкими полномочиями, охватывающими все задействованные подразделения.

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

Для корректного расчёта Incident Rate необходимо собрать данные за год с разбивкой по месяцам, чтобы исключить сезонные колебания. В числитель включаются только пользовательские обращения, классифицированные как инциденты, за исключением инфраструктурных инцидентов. В знаменатель следует брать количество активных пользователей ИТ-системы, исключая уволенных сотрудников и технические учетные записи. Для этого рекомендуется использовать данные из справочника сотрудников, реплицированного из Active Directory в ITSM-систему.

Causal Loop Diagram (CLD) помогает в верификации набора метрик, позволяя визуализировать взаимосвязи между ключевыми элементами системы управления. Анализируя CLD, можно убедиться, что все элементы управления охвачены метриками. Например, при рассмотрении DevOps-процессов, CLD отражает такие факторы, как время выхода на рынок, среднее время обработки, размер очереди изменений, уровень стандартизации, успешность внедрений и другие. Соотнося элементы CLD с предлагаемыми метриками, можно определить, достаточно ли текущих показателей для оценки состояния системы и где есть пробелы.

Учет траектории развития при найме агента изменений важен, потому что различные типы траекторий требуют различных подходов к управлению и развитию сотрудника. Компания должна понимать, готова ли она идти медленно, но с большой надежностью изменений (и тогда подойдет "подмастерье с высоким потенциалом"), или хочет двигаться быстро (требуя большей адаптивности, настойчивости и логического мышления от специалиста). Также важно учитывать, будет ли компания готова к управлению высокопотенциальными сотрудниками, которые могут быстро перерасти свои позиции, иначе нанятый человек может стать "бомбой замедленного действия".

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

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

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