Да, связи влияния в CMDB являются достаточными для расчёта TCO с некоторыми оговорками. Поскольку главная задача CMDB — определение влияния одних элементов на другие, эти связи отражают использование ресурсов, что непосредственно связано с распределением стоимости. Например, если сервер зависит от системы хранения данных и использует её ресурсы, то доля стоимости системы хранения может быть включена в TCO приложения, установленного на этом сервере. Это позволяет создать достаточно точную модель распределения затрат без необходимости введения специальных «экономических» связей в CMDB.

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

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

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

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

Автоматизация позволяет интегрировать процессы управления конфигурациями и изменениями, обеспечивая автоматическое обновление данных CMDB при каждом зарегистрированном изменении. Например, при использовании инструментов DevOps или платформ управления конфигурацией (Ansible, Puppet, Chef) изменения в коде или инфраструктуре фиксируются и сразу же отражаются в конфигурационной базе. Это повышает скорость и точность данных, снижает человеческий фактор и делает процессы более прозрачными для всех участников.

Команда на уровне «Зрелость» представляет собой агента изменений на уровне всей компании. Она полностью контролирует свой рабочий процесс и несет ответственность за продукт на уровне P&L (прибыль и убытки), что означает управление финансовой стороной продукта. Инициативы направляются не только внутрь команды, но и наружу, команда стремится расширять зону влияния и инициирует изменения, затрагивающие множество служб и подразделений компании. Для такой команды лидер-слуга уже не нужен, как и лидер-наставник. Здесь требуется лидер-партнер с достаточными полномочиями для поддержки командных инициатив на высшем уровне, обладающий широкой осведомленностью о направлении развития компании и достаточным авторитетом для интеграции целей команды с целями компании. Это высшая ступень развития, где команда становится драйвером изменений в организации.

В ITIL отсутствует градация уровня экстренности, потому что emergency-изменения по определению требуют немедленного выполнения без промедления. Если ситуация допускает вариации вроде «немного срочно» или «очень срочно», это уже не emergency — такие случаи обрабатываются в рамках стандартных или срочных изменений. Градация запутала бы процесс, ведь экстренное изменение подразумевает, что все ресурсы должны быть переключены на его реализацию в ущерб другим задачам. Например, если сайт компании падает, команда не анализирует «степень срочности» — она сразу приступает к восстановлению.

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

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