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

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

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

Эксплуатационные подразделения обеспечивают стабильность с помощью проверенных ИТ-процессов, таких как ITIL, COBIT и стандартов ISO. Они поддерживают баланс между надёжностью системы и способностью вносить изменения, минимизируя риски сбоев в контролируемых средах. Основная задача таких подразделений — оперативная обработка запросов пользователей, реагирование на инциденты, сбор обратной связи и поддержание бесперебойной работы инфраструктуры, что требует чёткого распределения ответственности и соблюдения регламентов.

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

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

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

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

При расчете Flow Efficiency возникает вопрос, какое рабочее время учитывать. Если команда состоит из сотрудников с разными графиками работы (например, аналитики в Новосибирске, разработчики в Москве, тестировщик на неполную ставку), возникает сложность выбора календаря. Можно было бы использовать календарь отдельного сотрудника, но в случае совместной работы над задачей это не отражает реальную ситуацию. В результате многие команды прибегают к упрощенным оценкам или договоренностям, которые дают неточные результаты, а не строгий расчет. Это приводит к ситуации, когда формально рассчитанная Flow Efficiency может отличаться от реальной эффективности в несколько раз.

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