Найти тему
Neuromap.tech

Зрелость цифрого продукта: разрешаем конфликт между бизнесом и "цифрой"

Знаком ли вам "футбол" между бизнесом и "цифровиками", у которых он заказывает фичи? "Сначала сделайте цифровое решение" - "Сначала проверьте спрос на MVP". Частенько цифровое подразделение создает продукты и фичи, которые так и не приносят доход, P&L. Чтобы решить эту проблему, необходимо уметь работать с цифровыми продуктами и различать 3 степени их зрелости - Lean Digital, Digital, инфраструктурный продукт (большой ИТ).

Многим из вас знаком конфликт между бизнесом и «цифрой», который является блокатором вывода на рынок новых продуктов в рамках CHANGE.

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

«Цифра» и бизнес постоянно ссорятся и не могут друг друга понять.

Чтобы разобраться в конфликте, необходимо понимать, что есть три степени зрелости цифрового продукта с точки зрения сложности организации его производства и поставки ценностей клиентам: Lean Digital, Digital, инфраструктурный продукт (большой ИТ).

Разберемся с тем, что такое «цифра», Digital, что такое ИТ, и как обычно происходит работа над цифровыми продуктами.

Конфликт бизнеса и "цифры": степени зрелости цифрового решения
Конфликт бизнеса и "цифры": степени зрелости цифрового решения

Что обычно происходит в компании?

В ИТ приходит представитель бизнеса, например, руководитель «Розницы» или другого бизнес-департамента и говорит: «Давайте «запилим» цифровое крутое решение». Это решение потребует изменения, например, может понадобиться переписать мобильное приложение.

«Цифра» отвечает: «Понимаешь, всё, что ты хочешь «запилить», очень сложно, очень дорого. И вообще, давай сначала перейдём на микросервисы. Приходи через полголда. Я знаю, что мы обещали два года тому назад, но вот ещё полгодика, и всё «полетит».

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

И правы - ИТ.

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

Бизнес должен научиться считать доход от своих потенциальных задач.

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

  • Это – Lean Digital.
  • В какой-то момент на масштабировании уже нужно писать цифровое решение, Digital - некий новый фронт-энд, новый пользовательский опыт или новую фичу, которая понадобится клиентам.
Зрелость цифрового продукта: Lean Digital
Зрелость цифрового продукта: Lean Digital

Вы можете сказать о возможных проблемах с ИБ (Информационной безопасностью) в отношении Lean Digital и внешних SaaS. Да, у ИБ возникают вопросы по поводу входа в контур и его безопасности, если за периметром контура начинают гулять персональные данные, это вызывает проблемы.

Но можно просто реализовывать решение за контуром банка, в спин-офф. Да, это главный инсайт: большинство инициатив, которые запустились в Lean Digital, в Digital потом так и не приходят, больше 70%.

Если бизнес научается вместе с ИТ понимать, какая инициатива требует захода в контур, а какая не требует, часть инициатив так в контур и не попадет.

Если взять эту модель, то часть бизнес-инициатив можно делать без вовлечения цифры.

В какой-то момент цифра должна сама научиться часть бизнес-задач требовать держать в Lean Digital.

Почему? Потому что, если бы вы хоть раз сделали ревью бэклога «цифры», вы увидели бы, что 80% задач невозможно посчитать. Если выгрузить бэклог трехлетней давности, чтобы посмотреть, что из написанного в цифре вернуло ROI, вы увидите, что нет даже гипотез по этим задачам, половины продактов уже нет в компании, все уволились, так что и спросить не с кого. А по инициативам, по которым обещали деньги, их нет. Задачу взяли в работу, но продать результат, готовый продукт забыли.

Не было ответственного человека, который отвечает за то, что написанная фича приходит в P&L.

На самом деле, продуктолог начинается после написания фичи. А в большинстве бизнесов продуктолог кончается после написания фичи. То есть он существует как продакт от заказа до ее написания, а потом перекидывается на другую фичу.

И, таким образом, в бэклоге накапливается огромное количество фич, которые не вышли в доход. И причина этого – отсутствие градации по степеням зрелости цифровых продуктов. Нет единого продуктового подхода между цифрой и бизнесом.

В Lean Digital вы как бизнес должны понять, какой результат вы хотите получить.

Проверив гипотезу, вы сможете написать ТЗ для Digital.

Важно: Time To Market заканчивается доходностью на клиенте.

  • Когда вы пишете цифровое решение, фичу, первый этап – это ее создание.
  • А второй этап – когда вы начинаете использовать эту фичу для роста доходности.

При этом большинство ИТ-шников хитрят. Они используют показатель не TTM, время до рынка, а Time to solution, то есть, время до создания решения.

Важно четко определиться в понятиях.

Digital и Lean Digital - степени зрелости цифрового продукта
Digital и Lean Digital - степени зрелости цифрового продукта

Но очень важно отделять цифровое решение от инфраструктурного решения.

· Инфраструктурное решение – это решение, которое входит в Core IT, в Core Engine, то есть внутрь вашей инфраструктуры.

Для банка это, например, ABS.

Для страховой - актуарная модель, которая следит за всеми решениями по страховкам

То есть у каждого бизнеса есть своя IT-система, которая обслуживает инфраструктуру, то есть операционную модель.

Это значит, что, если она сломается, у вас сломается весь бизнес. Именно поэтому она инфраструктурная.

По сути, это то же самое, что и микросервисная архитектура, сервисная архитектура бизнеса, бизнес-архитектура. Но в «цифре» в большинстве своем этого разделения нет.

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

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

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

В CHANGE задача другая - нам нужно создать новый цифровой сервис для клиента, ему RUN может быть вообще не нужен.

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

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

Степени зрелости цифрового продукта: инфраструктурное решение
Степени зрелости цифрового продукта: инфраструктурное решение

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

Мы желаем вам успеха в решении задач вашего бизнеса и будем рады видеть вас на наших программах: заходите на сайт, оставляйте заявку. Мы всегда на связи: info@neuromap.tech