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

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

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

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

Конфликт интересов не является нормальным событием, так как он создает противоречивые обязательства, которые могут нарушить объективность и качество выполнения задач. Если такой конфликт присутствует на долговременной основе, процессы работать не будут, поскольку люди, исполняющие их, стремятся избегать ситуаций, вредящих их профессиональной деятельности или репутации. Это противоречит естественному поведению специалистов, которые не хотят вредить себе или своей работе.

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

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

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

Value Streams в IT4IT и процессы ITIL v3 имеют прямое соответствие, хотя и структурированы по-разному. В IT4IT определены четыре основных Value Stream'a: Strategy to Portfolio (S2P), Requirement to Deployment (R2D), Request to Fulfill (R2F) и Detect to Correct (D2C). Каждый Value Stream состоит из нескольких функциональных компонентов. Например, Value Stream 'Request to Fulfill' включает в себя функциональные компоненты, которые непосредственно соответствуют множеству процессов из ITIL v3, таких как управление запросами, управление инцидентами, управление проблемами и управление уровнями услуг. Аналогично, Value Stream 'Detect to Correct' соотносится с процессами управления непрерывностью и доступностью. Таким образом, хотя IT4IT объединяет процессы в более крупные потоки создания ценности, практические функции и действия, описанные в этих потоках, совпадают с процессами ITIL v3.

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