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

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

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

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

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

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

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

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

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

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