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

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

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

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

В условиях кризиса компании сокращают капитальные вложения в ИТ-проекты, что приводит к увеличению доли операционных затрат в общем бюджете. Например, в российских банках доля операционных затрат выросла до 76-79% по сравнению с обычными 55-60%. Это делает управление операционными расходами особенно важным для сохранения финансовой устойчивости ИТ-подразделений.

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

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

Функциональная эскалация инцидентов — это процесс передачи заявки от одного уровня поддержки к следующему по иерархии (например, с L1 на L2 или с L2 на L3) при необходимости более глубокой диагностики или решения сложной проблемы. Она отличается от временной эскалации, которая связана с нарушением сроков SLA и требует вмешательства менеджмента, и от персональной эскалации, когда заявка передается конкретному специалисту или руководителю по содержательным вопросам. Функциональная эскалация определяется сложностью проблемы и необходимостью привлечения специалистов с более высоким уровнем компетенции, тогда как другие виды эскалации могут быть связаны с организационными или временными аспектами обработки заявок.

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

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