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

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

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

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

Наиболее частые ошибки при внедрении систем управления конфигурациями включают: чрезмерный фокус на самом процессе и инструменте, а не на создании ценности для конечных пользователей; попытки собрать слишком много информации без чёткого понимания, кто и как будет её использовать; недостаточное внимание к поддержанию актуальности данных; отсутствие коммуникации и обучения для пользователей о том, как и зачем использовать систему; игнорирование обратной связи от пользователей. Эти ошибки приводят к тому, что CMDB превращается в «базу только для записи», которую никто не использует, и инвестиции в систему не окупаются.

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

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

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

Перед внедрением системы измерений необходимо ответить на следующие ключевые вопросы: что, как и зачем мы измеряем; когда начали измерять и когда планируем завершить; на кого ориентированы результаты измерений и как они будут использоваться. Без ответов на эти вопросы работа по составлению раздела KPI будет бессмысленной и поверхностной.

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