Один из наиболее актуальных кросс-функциональных конфликтов, которые возникают в процессе реализации цифровых инициатив – между продуктовым блоком и ИТ. С одной стороны - креатив и стремление как можно быстрее получить экономический эффект, PnL, с другой- регламенты и безопасность.
CFO, CEO, акционеру, по сути, неважно, договорятся ИТ и продуктовики или нет.
Им главное – чтобы инициатива через условные три месяца принесла деньги. При этом желательно, чтобы весь бизнес не упал.
То есть необходимо соблюсти глобальные требования безопасности, как в солидной авиакомпании – на борт самолета не должен попасть террорист, какой крутой PnL не сулила реализация инициативы.
ИТ может напрягать тот момент, что «продакты» находятся не внутри функции, но решения, которые они предлагают, ИТ надо поддерживать.
ИТ может воспринимать их как некоторый непонятный, плохо регулируемый в инфраструктуре «зоопарк», угрожающий безопасности.
ИТ-функция может быть заинтересована в том, чтобы уже на стадии Ideation было понимание того, как будущее решение строит инфраструктуру, чтобы его уже можно было при необходимости не пустить дальше, предложить альтернативу и т.д.
По сути логика стадии Deploy (внедрения) переносится на логику Ideation.
ИТ может сказать: «Ребята, мне вообще все равно, какие вы решения используете, я дам вам только некоторые критические контуры безопасности, так скажем критические показатели - я вас в свое общее хозяйство все равно не пущу. Делайте свои пилотики в песочнице».
"Продуктовики" в этом случае получат PnL на пилоте короткой Lean Digital инициативы - пусть 20 миллионов, пусть 50 миллионов – и когда они придут в ИТ и скажут «мы хотим это цифровое решение сделать линейным для всей компании», ничего не получится, потому что всю продуктовую инициативу придется перепроектировать.
Она отслужила в Lean Digital, принесла деньги, и по идее может быть интегрирована в технологическую инфраструктуру, то есть она должна использовать технологические решения, которые уже преимущественно выбраны в стеке.
Но здесь важно не путать зарабатывание денег, предпринимательский подход и выполнение ИТ-регламентов.
Предприниматель, продуктовик, ищет возможность заработать.
Например, есть сеть продуктовых магазинов.
Началась пандемия, люди боятся приходить в магазин.
И предприниматель, продуктовик находит решение: надо договориться о том, чтобы доставка была через сторонний эффективный сервис.
Продуктовик предлагает реализовать это решение на одном пилотном районе Москвы за 3 недели и заработать 20 миллионов прибыли.
Он не думает в этот момент ни о стратегии компании, ни о технологической архитектуре, ни об используемых логистических методах (да, у этой сети продуктовых магазинов есть своя доставка, но она плохо работает).
Но ИТ ему в этой ситуации предлагает идти во внутренние решения по логистике, внутреннее решение по интернет-магазину. Стоп.
В такой спорной ситуации важно, чтобы «продакт», который продвигает инициативу, «дружил» с цифровой стратегией, умел аргументировать, что его решение ей не противоречит. Ирония в том, что зачастую у компании нет четкой стратегии по цифровому позиционированию на рынке. Поэтому в пилотной зоне по чуть-чуть можно пробовать везде.
Классическое возражение ИТ: это все понятно, когда есть какое-то короткое решение с явным эффектом, действительно, быстрая победа PnL. Но ведь есть решения, которые имеют отложенный эффект.
Для ИТ они очень сложны в поддержке, непредсказуемы, непонятно, будет этот проект жить или не будет - потому что его сделал конкретный непонятный разработчик.
Политика безопасности не позволяет использовать решение в облаке. Т.е. его нужно оставить у себя, а для этого нужно купить лицензию, которая стоит дорого и окупится не через два-три месяца и, возможно, не через год возможно.
Возвращаемся к сути конфликта:
У предпринимателя задача через три месяца заработать деньги, у ИТ разработчика - задача сделать поддерживаемое, безопасное, унифицированное, дешевое и т.д. решение.
Урегулировать этот конфликт помогают артефакты фреймворка.
Есть ИТ-артефакты – например, заявка на инфраструктуру, заявка на технологическое решение и т.д. Это артефакты, которые от ИТ-блока нужно внести во фреймворк.
Но они не должны быть заменой продуктовым артефактам – таким, как концептуальная архитектура, заявка на покупку оборудования или на технологический проект.
На стадии проектирования идеи в кросс-функциональном фреймворке ИТ-артефакты и продуктовые артефакты находятся вместе.
И через них происходит взаимодействие этих двух систем.
Таким образом, общая цель, что две функции должны заработать деньги, предпринять что-то для этого, заставляет найти адекватное решение по выбору цифрового продукта.
Нужна помощь в цифровой трансформации, разработке и запуске фреймворка для управления цифровыми инициативами? Обращайтесь!
Мы всегда на связи: Telegram, сайт, info@neuromap.tech.
