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

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

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

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

Относительные приоритеты бизнеса учитываются при расчете общего показателя качества через использование весовых коэффициентов. Например, при объединении показателей из различных групп услуг (mission-critical, business-critical и обычные) каждой группе присваивается вес, отражающий ее степень важности для бизнеса. При расчете общего интегрального показателя эти веса учитываются в формуле, например, при вычислении взвешенного среднего арифметического. Если mission-critical услуги имеют вес 0.5, business-critical — 0.3, а обычные — 0.2, то их показатели будут пропорционально учитываться в общем результате. Это позволяет управлять акцентами в оценке и более точно отражать стратегические приоритеты бизнеса.

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

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

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

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

Согласно ITIL v3, ключевые задачи практики управления инцидентами включают в себя не только восстановление нормальной работы услуги в кратчайшие сроки и минимизацию негативного влияния на бизнес, но и поддержание удовлетворённости пользователей качеством ИТ-услуг. Это означает, что управление инцидентами направлено не только на оперативное устранение проблем, но и на обеспечение положительного опыта взаимодействия пользователя с системой поддержки. В контексте ITIL v3 среди целей процесса управления инцидентами прямо указана задача поддержания удовлетворённости пользователей, что подчёркивает важность качества обслуживания и коммуникации в процессе решения инцидентов.