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

BRM (Business Relationship Management) принципиально отличается от менеджера по продажам своей основной целью и фокусом деятельности. Основная цель BRM – построение и поддержание долгосрочных партнерских отношений с заказчиком, ориентированных не на продажи и прибыль сервис-провайдера, а на ценность и удовлетворенность заказчика. BRM выступает в роли «голоса заказчика» внутри сервис-провайдера, передавая понимание бизнес-задач и ожиданий заказчика. В отличие от менеджера по продажам, BRM не фокусируется на заключении сделок и достижении краткосрочных финансовых целей. Предостережение в тексте гласит, что неаккуратное сочетание задач BRM с sales и pre-sale активностями может быстро выхолостить понятие business relationships, так как истинные business relationships не про продажи, а про партнерство с заказчиком.

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

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

Укрупнённые схемы ИТ-систем, показывающие только общие компоненты (например, «ERP-система»), недостаточны для расчёта себестоимости услуг, потому что не учитывают различия в потреблении ресурсов различными группами пользователей. Например, одни пользователи могут постоянно работать в системе, другие использовать её редко для отчётов, третьи — обрабатывать большие объёмы данных. Себестоимость услуг зависит от профиля использования, который определяется бизнес-процессами. Для точного расчёта необходима детализация до уровня подсистем, отражающая, как именно разные пользователи потребляют ресурсы.

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

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

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

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

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