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

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

В управлении доступностью (AVA) основными показателями выступают: - MTRS (среднее время восстановления услуги) - MTBF (среднее время между сбоями) - MTBSI (среднее время между инцидентами) Эти показатели связаны со статистикой и тенденциями сбоев в работе ИТ-систем. В управлении непрерывностью (CONT) используются: - RTO (recovery time objective) — целевое время восстановления - RPO (recovery point objective) — целевая точка восстановления RTO показывает, за какое время после сбоя должно быть возобновлено предоставление услуги, а RPO указывает, какой период данных может быть потерян без критического ущерба для бизнеса.

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

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

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

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

Девять принципов ITIL Practitioner Guidance 2016 года трансформировались в семь принципов ITIL 4 2019 года следующим образом: два идентичных принципа остались без изменений ("Фокусируйтесь на ценности" и "Отталкивайтесь от текущей ситуации"); два принципа были объединены ("Сотрудничайте" и "Будьте прозрачны" стали одним - "Сотрудничайте и поощряйте прозрачность"); три принципа получили незначительные изменения формулировок ("Действуйте итерационно" стало "Действуйте итерационно, используя обратную связь", "Упрощайте" превратилось в "Простота и практичность", "Используйте целостный подход" получил дополнение "Think and work holistically"); один принцип ("Проектируйте, ориентируясь на потребительский опыт использования") был интегрирован в более общий принцип "Фокусируйтесь на ценности"; элементы другого принципа ("Приоритет прямого наблюдения") нашли отражение в рекомендациях по применению принципа "Отталкивайтесь от текущей ситуации"; и был добавлен новый принцип "Оптимизируйте и автоматизируйте".

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

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