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

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

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

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

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

Оценка эффективности потока обычно предполагает экспертное приближение: команды интуитивно или на основе наблюдений определяют, сколько времени задачи проводят в активной работе и сколько времени в ожидании. Точный расчет же требует сбора и анализа конкретных данных по времени каждой задачи. В реальности большинство попыток «точного» расчета Flow Efficiency оказываются упрощенными оценками из-за сложности точного измерения Touch Time и Time in Process. Как правило, результаты оценки дают более реалистичные и полезные для команды показатели (в районе 10-25%), тогда как «точные» расчеты могут приводить к абсурдно высоким значениям (90% и более), не отражающим действительное положение дел.

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

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

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

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