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

Для определения принадлежности элемента к категории ИТ-актива или конфигурационной единицы необходимо ответить на ключевой вопрос: «Что конкретного мы будем делать с этим элементом как с ИТ-активом?». Если для элемента предусмотрены специфические процедуры учета, управления жизненным циклом, оценки стоимости, которые отличаются от процедур управления конфигурационными единицами, то его следует отнести к ИТ-активам. Если же отличий в процедурах работы нет, и элемент используется просто для отслеживания конфигурации, то он является конфигурационной единицей. Пределы понятий определяются практическими потребностями системы управления.

В процессе управления проблемами координатором проблемы должен стать ведущий специалист из той области, где изначально проявляется проблема. Например, если тормозит приложение, координатором будет специалист app-саппорта. Однако, если диагностика выявляет проблему в смежной области (например, на СХД), в условиях слабой матрицы рекомендуется создать новую связанную проблему и назначить для неё отдельного координатора, сохранив исходную проблему под ответственностью первого координатора. Это позволяет вести параллельное решение обеих проблем и избежать потери мотивации у «страдающей стороны».

Критерий «R» (relevant – релевантный) чаще всего вызывает трудности в практическом применении. Основная проблема заключается в том, что люди склонны включать в систему измерения показатели, которые легко или привычно измерять, но не обязательно соответствуют реальным управленческим задачам. Нередко встречаются случаи «отчётности ради отчётности», когда собираются данные, но на их основе не принимаются решения. Ещё хуже, когда метрики мотивируют действия, противоположные изначальным целям, как это происходит в так называемой «палочной системе». Это происходит из-за того, что систему формируют под имеющиеся измерения, а не под реальные потребности.

Для управления сложностью микросервисной архитектуры рекомендуется применять два ключевых процесса ITIL: управление проблемами и управление конфигурациями. Управление конфигурациями позволяет сохранять информацию о всех компонентах системы, их параметрах и зависимостях, что помогает поддерживать обзор всей архитектуры. Управление проблемами помогает анализировать и устранять корневые причины инцидентов, что особенно важно при диагностике сложных взаимодействий между микросервисами. Эти процессы позволяют сохранить систему в более детерминированном состоянии и избегать перехода в сложный (Complex) домен, где управление становится значительно труднее.

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

Для обеспечения баланса между объемом данных в CMDB и возможностями их поддержания необходимо: четко определить критерии включения данных в CMDB (удобство использования, необходимость поиска, требования к отчетности); интегрировать CMDB с внешними источниками данных вместо физического копирования всех данных; ограничить объем хранимых данных только теми атрибутами, которые непосредственно участвуют в процессе управления конфигурациями; использовать гибридный подход, сочетая локальное хранение ключевых данных с доступом к дополнительной информации во внешних системах; регулярно проводить аудит содержимого CMDB для удаления неактуальной или избыточной информации.

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

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

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