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

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

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

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

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

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

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

Переходной точкой между фазами problem control (PC) и error control (EC) является завершение диагностики проблемы - то есть момент, когда определена корневая причина проблемы и сформированы возможные варианты ее решения. В этот момент процесс управления проблемами переходит от этапа поиска и анализа проблемы к этапу реализации выбранного решения. Определение этой четкой границы между фазами позволяет разделить процесс на нормируемую часть (диагностика) и ненормируемую часть (реализация решения и проверка), что упрощает управление и контроль над процессом.

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

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