В большом бизнесе есть разные модели управления, всего их шесть. Из-за этой разницы они сталкиваются между собой и соединяются в один большой конфликт вокруг портфеля инициатив – каждая из которых «простреливает» все функции. Невозможно просто заключить пакт о ненападении между ними. Нужно создавать единую, кросс-функциональную рамку работы для них – а именно фреймворк.
Единый фреймворк для управления цифровыми инициативами в корпорации помогает внедрить продуктовый подход в ней и линеаризировать продуктовый блок, особенно в ситуации, когда в компании не хватает продактоунеров - владельцев продуктов, умеющих ими управлять.
Итак, пойдем сначала.
Что часто происходит в современных корпорациях?
Акционер, вдохновившись лекциями об Индустрии 4.0, роботизацией, инновациями, приезжает к топам компании и рассказывает: «Нам нужно быть цифровыми! Нам нужны цифровая трансформация, супер-change, инновации, давайте делать как на западе».
Он хочет получить дополнительную прибыль к EBITDA компании – так называемый Green box.
EBITDA достигается с помощью RUN, т.е. операционной моделью - заводами, основным бизнесом, производственными предприятиями и т.д. и измеряется в крупном бизнесе десятками, сотнями миллиардов рублей или долларов.
Green box – это новые деньги, созданные не благодаря тому, что машинка, построенная корпорацией за 20 лет, продолжает бежать, а благодаря каким-то новым инициативам, прорывам, Change.
То есть акционер ожидает EBITDA минимум 2Х, с абсолютно новой концепцией, операционной моделью или рынком. И часто, запуская процесс цифровой трансформации и весь этот Change, топы слышат от акционеров вопрос - “И это все?”.
Потому что первые цифровые продукты или цифровые инициативы не приносят ожидаемого объема «новых денег».
Больший экономический эффект приносят проекты, связанные с cost reduction (снижением расходов) – когда вы не создаете новые продукты, а просто убираете расходы, связанные с неэффективностью какого-либо технологического процесса, потерями и т.д.
Что же касается новых продуктов, которые должны принести ожидаемый акционерами PnL, то с ними сложнее. На рынке много провальных кейсов CTO, CIO, которые защищали инфраструктурные проекты на 2-4 года, но инициативы стопорились на разных этапах. Некоторые еще на этапе проектирования, некоторые - на разработке, потому что разрабатывали что-то не то, некоторые на этапе внедрения – оказывалось, что решение никому не нужно на производстве. Некоторые инициативы внедрялись, но не приносили бизнес-эффекта. В итоге CTO, CIO увольнялись или их увольняли.
Это стандартная ошибка. С новыми продуктами нужно работать иначе, и именно фреймворк помогает это сделать, а именно:
- Повысить качество реализуемых инициатив,
- Выявить инициативы, которые не приносят ценность, на ранней стадии и не реализовывать их
- Раньше получить бизнес-эффект
Второй конфликт - между финансовой, контрольной по своей сути функцией, финансовой системой управления, и теми, кто приходит у нее просить деньги на реализацию цифровых инициатив, т.е. продуктовой системой управления.
Это могут быть люди из бизнеса, большие консультанты, руководитель юнита, акселератор.
Финансовому директору, юридически отвечающему за средства, своей головой, нужно распределить бюджет на цифровые инициативы. Как финансист он видит, что экономический эффект не проработан, непонятно, как он будет считаться – ему не хочется рисковать.
Обычно часть CFO по этой причине сразу блокирует эти инвестиции. Другая часть дает попробовать, но через полгода, не видя возвратности и экономической целесообразности, стопорит инициативу.
Таким образом стопорится цифровая трансформация – один CFO все инициативы блокирует, новый – всем раздает деньги. А на самом деле ни тот, ни другой, просто не владеют инструментами гибкого бюджетирования, необходимого в продуктовом подходе и появившегося на российском рынке вместе с его управляющими, инвестиционными комитетами где-то в 2017-ом году.
В отличие от долгого, полугодичного проектирования экономического обоснования и получения инвестиций на весь проект, как это принято в крупном бизнесе, в данном случае инвестиции даются не на весь проект, а его этап, то есть у вас есть право попробовать. В условиях неопределенности, разработки новых продуктов, то есть продуктовом подходе, сложно посчитать весь экономический эффект, PnL сразу.
Идем дальше.
Допустим финансовый директор дал деньги на инициативу, на первые 3 месяца.
Цифровая инициатива начинает реализовываться – с малого, с экономии, не с команды из 20 человек и покупки SAP, с MVP и т.д.
И в этот момент происходит столкновение продуктового подхода, продуктовой функции, и проектного мышления, свойственного ИТ-функции, CTO и CDO.
Важно понимать разницу между ними – у них разные KPI, системы менеджмента, бизнес-процессы, штатное расписание. Их даже делят на два юридических лица.
Конфликт заключается в том, что ИТ- функция, как правило, мыслит в инфраструктурной целостности, которую ей нужно сохранить, и ей руководит человек, который очень хорошо разбирается именно в инфраструктуре и безопасности. Всевозможные инициативы как раз угрожают целостности контура, инфраструктуры. Никакой креатив и инициативы не компенсируют бизнес-стоп даже на 20 минут. Если целостность системы нарушена, ей очень тяжело управлять.
И между ИТ и продуктовиками наблюдается противостояние – между стабильностью, устойчивостью, безопасностью - и цифровыми ребятами с их инициативами, которые могут принести 20 миллионов, но несут угрозу целостности и безопасности (вы наверняка видели кейсы, когда благодаря цифровой трансформации данные, хранящиеся в облаке, утекают из бизнеса).
Проектное управление – это портфель проектов, проектный план, стадии реализации, диаграмма гранта, ресурсный план, ресурсный пул специалистов, инвестиции, центр компетенций и т.д. и т.п.
Но проблема в том, что управление проектного портфеля и продуктового - это абсолютно разные системы, они в зародыше своем конфликтуют. Для того, чтобы получить ИТ-разработчиков для своей инициативы, ИТ требует от продакта сначала прописать архитектуру – а это как минимум недели три – для продуктовой инициативы это критичный срок, ее смысл в том, чтобы все происходило быстро. Сделали – быстро переизобрели. Иначе это уже не продуктовый подход.
Возможен еще один конфликт, связанный с внедряемостью и приживаемостью цифровой инициативы.
Предположим, условный продактоунер (Иванушка – дурачок) смог вписаться в повестку акционера, получить бюджетирование, договориться с ИТ-шниками.
Он прорвался, уже немного прожженный, задумывающийся, а не стоит ли ему уволиться из компании.
Каким-то образом со своей командой, собранной из коллег, он запилил цифровой продукт и его внедрил.
А дальше начинается самая смешна история - тот продукт, который он запилил, оказался никому не нужным. Потому что он забыл подумать о том, что есть какие-то инженеры, работники, линейные сотрудники, которые вроде бы говорили ему, что он собирается делать классную штуку, но в итоге, когда он ее сделал и пришел с этой штукой к ним (на производство или в банк, или в отделение продаж этого банка), они сказали, что использовать эту штуку им неудобно и они будут все делать как раньше.
То есть это конфликт на стыке линейной и продуктовой функции – когда продуктовая функция не думает о том, что такое операционная модель, штатное расписание, календарный план, рынок труда, стоимость сотрудника, стоимость штатной единицы на единицу ебиды и тд.
И фреймворк помогает кросс-фунционально эту проблему решить.
Итак, важно, понять, что рассмотренные нами конфликты - это конфликты систем, культур, а не людей.
Из-за них не нужно ругаться до потери пульса на переговорах.
Нужно просто зафиксировать, что есть, например, линейная система управления – операционными KPI, линейной деятельностью, ресурсным планом, штатным расписанием и другими линейными инструментами, такими, как мотивация, зарплата, годовые бонусы и т.д.
Есть более гибкая проектная деятельность (планирование раз в проект), которая управляется проектами и проектным портфелем, проектным планом, диаграммой Ганта, более гибким ресурсным управлением, переиспользованием ресурсов чаще 1 р в год, матричной системой.
Есть (процессное) управление через бизнес-процессы процессные фреймворки, в крупных компаниях – через целые процессные офисы.
Есть управление MBA топ-менеджмента через управление людьми, лидерством, культурами, стратегией, трендами, через современные организационные дизайны и т.д.
Есть продуктовое управление - через продуктовый портфель продуктовый вижн, спринты, статусы. Его главные метрики – PnL и TTM. В нем все переизобретается – ресурсы, процессы, штатное расписание, сама функция - лишь бы ты только быстро приносить PnL.
Современный PMO, функция управления портфелем, вынуждена гибридно смотреть на инициативы и продуктовые проекты - в крупных компаниях продуктовая функция вынужден привлекать проектные ресурсы.
Есть финансовое управление - через финансовые потоки, ресурсы.
И есть еще одна система, практически не реализованная в России - венчурное управление, через капитализацию компании. Его часто в зародышевом состоянии реализует финансовая функция – в виде акселераторов.
И все эти системы в крупном бизнесе, в отличие от среднего и мелкого ссорятся до бесконечности вместо того, чтобы понять, что не надо выбирать ни ту, ни другую систему, а надо построить фреймворк и работать через него кросс-функционально.
Нужна помощь в разработке и внедрении фреймворка? Обращайтесь!
Мы всегда на связи: Telegram, сайт, info@neuromap.tech.
