В чем проблема раздельного управления продуктами и услугами?
Представьте ситуацию: разработка выпустила обновление продукта с десятком новых функций, но отдел поддержки не был предупрежден. В результате на вопросы клиентов «Как это работает?» и «Почему сломалось то, что раньше работало?» никто не может дать внятного ответа. Знакомо?
Когда продуктом и услугой управляют по отдельности, возникают классические проблемы:
- Разрыв коммуникации. Разработчики часто не видят реальные проблемы пользователей, с которыми ежедневно сталкиваются сотрудники службы поддержки.. А сервисная команда узнает о новом функционале постфактум, когда пользователи уже начали звонить с вопросами.
- Конфликт целей. Продуктовая команда гонится за инновациями и скоростью вывода новых фич на рынок. У поддержки услуги в приоритете стабильность. Без единого центра управления эти цели становятся конфликтующими: «новые фичи» ломают «стабильность».
- Потеря качества восприятия. Пользователь не различает внутренние подразделения поставщика. Для него важна общая работоспособность услуги целиком. Если продукт технически совершенен, но его предоставление работает с перебоями, а поддержка отвечает через три дня, клиент считает, что вся услуга — плохая.
В книге ITIL Foundation (version 5) особо отмечено, что качество цифровых услуг зависит от двух факторов: качества самого продукта и системы управления поставщика услуг. Эти факторы неразрывны.
Почему продукт и услуга должны жить в едином жизненном цикле?
Цифровой продукт сам по себе — это просто код и технологии. Ценность для бизнеса и клиента он приобретает только тогда, когда становится услугой. Поэтому в новой версии ITIL вводится понятие единого жизненного цикла продукта и услуги (Digital Product & Service Management (DPSM) Diamond).
Этот цикл включает восемь этапов, и ключевая идея здесь — переключение фокуса:
- На этапах Discover (Выявление) и Design (Проектирование) мы думаем о том, какую проблему рынка решим.
- На этапах Acquire (Приобретение) и Build (Создание) мы концентрируемся на создании продукта.
- На этапе Transition (внедрение) происходит развертывание нового продукта в рабочей среде
- А на этапах Operate (Эксплуатация), Deliver (Предоставление) и Support (Поддержка) мы уже управляем услугой, работающей на базе этого продукта.
Каждый из этапов тесно связан с предыдущим и последующим, что позволяет учесть влияние каждого этапа на остальные части процесса. Таким образом, разработчики и поддержка работают над одним общим результатом, понимая общую картину взаимодействия всех компонентов.
Также такой подход интегрирует обратную связь, обеспечивая то, что инициативы по совершенствованию продукта, исходящие от поддержки, мгновенно становятся входами для нового цикла разработки (Discover/Design). Это не просто красивая картинка идеального мира, а стратегия выживания в реальных условиях быстрых изменений PESTLE-факторов.
Как разделить зоны ответственности?
В этой модели роли вендора цифрового продукта и поставщика услуг четко распределены, но они должны действовать в сообща.
Вендор цифрового продукта отвечает за создание и развитие продукта. Его зона ответственности — первые пять этапов жизненного цикла:
- Понимание потребностей рынка и выявление возможностей (Discover)
- Проектирование продукта (Design)
- Привлечение и распределение ресурсов (Acquire)
- Сборка и тестирование (Build)
- Передача продукта в эксплуатацию (Transition)
Задача вендора — создать качественный, надежный и соответствующий требованиям продукт. Но его работа не заканчивается в момент релиза. В современном мире вендор должен быть в постоянной отслеживать то, как продукт живет дальше.
Поставщик услуги отвечает за взаимодействие с клиентом и эксплуатацию услуги. Его зона ответственности — оставшиеся этапы:
- Обеспечение бесперебойной работы (Operate).
- Предоставление доступа и функционала (Deliver).
- Восстановление при сбоях и помощь пользователям (Support).
Поставщик услуг — это голос клиента внутри компании. Именно он видит, как продукт ведет себя в реальных условиях. И если он не транслирует эти знания обратно вендору (в этап Discover), то компания начинает слепо штамповать функции, которые никому не нужны.
Заключение
Граница между созданием продукта и предоставлением услуги в цифровом мире стирается. Успешные компании строят управление не по принципу «отделов», а по принципу потоков создания ценности (value streams), где активность вендора цифрового продукта и поставщика услуг переплетаются. Цифровые продукты и услуги — это не два разных явления, а две стороны одного жизненного цикла. И только управляя ими в единстве, можно добиться стратегического успеха и удовлетворенности клиентов.
Для тех, кому интересно узнать что ещё нового в ITIL (version 5) по сравнению с ITIL4 предлагаю посмотреть запись нашего вебинара от 12 марта 2026 г.
А тех читателей, кто хочет ближе познакомиться с основами управления цифровыми продуктами и услугами приглашаю на наш обновленный курс «ITSM. Основы управления ИТ-услугами (обновлено в 2026)»
