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

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

Целесообразность применения методик DevOps определяется оценкой их соответствия конечной бизнес-задаче и контексту организации. Необходимо проанализировать, является ли поддерживаемый ИТ-решением бизнес-процесс фактором дифференциации компании. Если нет, возможно, разумнее адаптировать бизнес-процесс под возможности доступных решений, включая коробочные продукты. Также важно учитывать уровень сложности инфраструктуры: в условиях высокой сложности (область 'Сложно' по Cynefin) традиционные методы могут быть неэффективны, и предпочтительнее использовать итеративный подход вместо сложного планирования.

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

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

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

Между количеством инцидентов и временем их решения существует нелинейная зависимость, усиленная за счет эффекта очереди и неравномерного распределения нагрузки в течение дня. Например, при производительности 20 минут на инцидент теоретически сотрудник может обработать 24 инцидента за день, если бы они поступали равномерно. Но при неравномерном поступлении (всплеск утром) и одновременном начале работы над всеми 24 инцидентами, среднее время их решения возрастает до 4 часов 10 минут. При уменьшении количества инцидентов вдвое (до 12), при прочих равных условиях, среднее время решения падает до 2 часов 10 минут. Это означает, что сокращение количества инцидентов через управление проблемами может дать больший эффект для снижения среднего времени решения, чем оптимизация только производительности персонала.

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

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

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