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

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

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

В комбинированной модели количество необходимых ролей рассчитывается как 2 в степени количества статических атрибутов, а количество атрибутных правил - как 2 в степени количества динамических атрибутов. Например, в системе с 7 статическими и 3 динамическими атрибутами потребуется 2^7 = 128 ролей и 2^3 = 8 атрибутных правил, что значительно меньше 1024 ролей, необходимых в классической ролевой модели с 10 атрибутами. Это объясняется тем, что комбинированная модель разделяет ответственность: статические атрибуты управляются через роли, а динамические - через атрибутные правила.

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

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

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

Для определения этапов, где теряется время при решении инцидентов, следует применить метод Expanded incident lifecycle из ITIL Service Design. Этот метод описывает все основные этапы обработки инцидента, включая выявление, регистрацию, диагностику, решение и закрытие. Проанализировав время, затрачиваемое на каждый этап, можно выявить узкие места. Например, если значительная часть времени уходит на диагностику, возможно, требуется улучшить документирование решений или внедрить системы автоматического анализа. Если проблемы возникают на этапе передачи инцидентов между командами, стоит оптимизировать маршрутизацию и коммуникацию. Стоит помнить, что анализ должен быть целенаправленным, фокусируясь именно на поиске наиболее затратных областей для получения максимального эффекта от оптимизации.

Основные проблемы классификации включают неоднозначность определения границ между инцидентом и сервисным запросом, что приводит к дискуссиям на тему "А замена картриджа принтера? А сброс забытого пароля?". Эта неоднозначность не только создает сложности для теоретиков, но и затрудняет работу специалистов на практике. Кроме того, если эти типы обращений относятся к разным процессам управления (и, возможно, к разным менеджерам), вопрос классификации превращается в вопрос ответственности: "кто за это отвечает". Это создает организационные трения и может негативно сказаться на эффективности процесса.

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