В чем преимущество портфельного управления? Какие выгоды оно дает по сравнению с операционным или портфельным управлением? Как к нему перейти, какие моменты учесть, каких ошибок избежать, и как найти тех, кто будет реализовывать инициативы из портфеля?
Как связаны портфельное управление, цифровая трансформация и Product owner-ы?
Давайте разберемся, что такое портфельное управление, для чего оно нужно ?
Почему сейчас оно повсеместно внедряется везде, практически в любой крупный бизнес ? Почему это «золотой» рынок?
Эти знания полезны финансовым директорам, акционерам , CDTO, CDO, представителям топ-команды, IT - департаментов, Digital - департаментов и т.д.
Они связаны с тем, как управлять своими инициативами, продуктами, фичами (если речь идет об IT) в концепции портфельной методологии и всех схожих фреймворков, которые на базе этой методологии можно реализовывать , например, фреймворка Neuromap .
Какие это должны быть знания?
Первое - это понимание того, что мир не состоит только из Agile, SCRUM , LeSS , SAFe, «цифры», инициатив - всего этого хайпа, который дико мешает.
Есть разные типы управления.
- Проектное управление
В нем вы делаете проект, описываете проектный план, календарный план, строи те диаграмму Ганта, фиксируете scope проекта, спонсора, инвестора, бизнес - заказчика. Вы ставите проектного менеджера с навыками проектного управления и его осуществляете.
Как ни странно, нормальное проектное управление - well done, medium well - встречается крайне редко.
Как правило, это комбинированная история между проектами, бюджетами и операционным управлением.
- Операционное управление (Execution)
Операционное управление - это управление операциями, управление линейное – бизнес-процессами, OKR-ами или страт.приоритетами, если это верхний уровень операционного управления, операционной модели. Или это управление сотрудником через личную мотивацию и создание с ним функционального контракта. Все это в управлении вашими функциями в крупном бизнесе находится в разрезе execution и управляется Сhief executive officer.
Execution - это операционная деятельность.
Т.е. CEO сверху управляет всеми происходящими операциями. Кстати, операционный фреймворк уже не всегда подвластен CEO.
Но важно понимать, что управление операциями day to day, стабильными операциями, стабильными бизнес-процессами и управление новыми проектами - это разные вещи.
И если говорить о трансформационных процессах и управлении ими, то часто бывает такое, что приходит акционер и говорит: “Срочно все трансформируемся! Не трансформируетесь - всем головы с плеч. Сменю половину топ - менеджмента. Если вы EBITDA сейчас не принесете, в разы большую, то все!».
Этот Change , на самом деле, зачастую очень легко делается , без всяких Agile и «цифры » - на нормальной отладке проектного управления. Т.е. это реализация проектов, группирование проектов .
Есть замечательный пример прецедент на рынке, самый успешный кейс программного управления – компании Газпромнефть . Это огромная « махина», которая внедрила программное управление в своем холдинге.
И важно понять, что трансформация как таковая не может управляться линейно.
Потому что иначе вы получите парадокс следующего свойства. Вы ставите задачу выполнения линейных OKR и тут же навешиваете этому же руководителю задачу по трансформации - это как менять колеса на едущем поезде. Это, мягко выражаясь, очень амбициозная задача.
Руководителю, которому вы ее ставите, приходится туго, потому что в конце квартала вы спрашиваете линейные показатели, а в конце года - глобальную трансформацию.
И такая тема, связана в основном с тем, что верхушке управления хочется все и сразу - и доить корову, cash, и при этом ее трансформировать.
Есть еще третий тип управления - специфический.
Я в России практически его не встречаю.
- Это управление процессами, процессные фреймворки .
В западном телекоме – чего в России нет - покупают аналог SAP за то, что в нем уже закодифицированы необходимые индустриальные процессы, которые он хочет получить вместе с этим аналогом SAP.
В России я таких проектов не встречал, а если встречал, то они крайне неуспешны, потому что процессное управление в России так и не развилось. В том числе, кстати, потому что у нас высокая волатильность рынка и количество изменений.
И, вообще, менеджмент до процесса не всегда доходит - до процессных офисов, процессных фреймворков. Я постоянно наблюдаю огромные проекты-«франкейнштейны», условно, на 4 года, так и не достигающие глобальных побед.
Но! Процессный подход, как феникс перерождается в цифровизации. Потому что часть цифровизации напрямую связана с цифровизацией процессов. Т.е. если вы хотите перезапустить бизнес-процесс и процессный фреймворк, лучше по кусочкам режьте через цифровизацию процессов, чем просто осуществлять реинжиниринг процессов.
Процессное управление имеет непосредственно отношение к value-стримам, revenue - стримам, когда есть некоторое revenue - например, комиссионный бизнес. И без построения этого стрима, создания, например, комиссионной ценности до клиента, если мы не опустимся на шаг ниже и не простроим процессную карту всего value-стрима, особенно кросс - функциональную часть, когда процесс между разными функциями проходит, возникают стопоры, конфликты ОKR – очень сложно реализовать задуманное.
- Есть еще тип управления, который тоже все время мешает, перед тем как перейти к портфельному - это финансовое управление или управление бюджетом .
Вы наверняка знакомы с тем, что в вашей компании раз в год защищается бюджет.
Все знают, что такое бюджетная процедура и сколько сил кладется на защиту бюджета .
В какой-то момент это абсолютно теряет свой смысл, а именно, то, для чего бюджет предназначен - это реинвестиция своей EBITDA в деятельность. Редко когда бюджет «докладывается» акционером. Есть, конечно, виды бизнеса, где он «докладывается » - как правило, это реинвестиции операционного заработка.
И вот эта реинвестиция теряет свою инвестиционную суть. Она превращается в рудимент управления расходами, где преобладает риск-менеджмент минимальной ответственности с точки зрения управления рисками - закладываются наибольшие сроки, наибольшие бюджеты, наименьшие изменения, чтобы точно не «прилетело по башке» – «Я же бюджет взял!». Это может быть оценено даже, как растрата, если ты потратил нецелевой бюджет. Также может быть избыточное проектирование бюджета. Все это порочное обоснование бюджетов – «Защити бюджет!», “Мамой клянусь, точно оптимальные расходы!” - когда защита бюджета сводится к придиркам к статьям расходов.
Т.е. фокус предпринимателя тратится не на то, зачем он это делает, во имя чего и что он хочет заработать, а на оптимизацию расходов и защит у бюджетной статьи или расходной статьи.
Это в принципе другой фреймворк, другой майндсет мышления. Человек думает о расходах, экономии. Т.е. мы развиваем экономию. Да, безусловно, это полезный навык. Но это экономия. Это не предпринимательство, не инвестиции.
Мы часто видим, что в части бюджетной процедуры пытаются «впихнуть» Change, инновации, предпринимательские инициативы, какие-то продукты, новые виды бизнесов M&A – «вот все это в бюджетик запихнем. Конечно, правильно, «нам же нужно реинвестицию EBITDA в эти все статьи заложить». Значит, она должна защищаться бюджетом. А то, что у нас бюджетная процедура одна для всех – другой вопрос. Для всех одно и то же. Одни ворота. Все должны защищать бюджет одинаково.
У одного одно управление рисками, у другого - вообще, инициатива находится на стадии, когда легче сделать, чем объяснить как ты это будешь делать. «Тогда мы такие инициативы не будем брать!», - говорит бизнес, - «Мы их зарежем». Крупный бизнес это любит. «Мы сделаем акселератор. Мы рядом организуем песочницу детишек, и туда будем «пулять» все, что в бюджетную процедуру не зашло. Пусть там детишки побалуются с чем-то. А если у них что-то выгорит, пусть придут к нам. И мы еще подумаем - внедрять, не внедрять».
Это так называемое оттягивание принятия решения.
Потом все будет то же самое, только усугубится тем, что детишки создадут то, что потом вообще не интегрируемо с позиции стека, с позиции ОKR , страт.приоритетов и т.д.
Потому что очень сложно управлять стартапом в акселераторе, чтобы он еще и в вашу стратегию попал.
Коллеги, вы тогда уж определитесь – «Вам такси или шашечки?».
Если нужно в стратегию попасть, то тогда вы заводите стартап в рамках страт.приоритетов и управлени ОKR-ами, который служит, как управленческий рычаг, для выполнения стратегии и операционных показателей.
А если вам важен акселератор, то тогда взаимодействие с таким инкубационным птенцом и управление стратегией - это просто разные фреймворки.
Итак, есть разные разрезы управления бизнес - деятельностью.
Есть продуктовое управление, проектное управление, управление операционной деятельностью, финансовое управление .
- Еще есть инвестиционное управление.
Вы как раз с ним сталкиваетесь в разрезе акселераторов, в разрезе Lean startup и работы с инновациями.
В разрезе M&A, кстати - потому что зачастую интеграция молодой компании на ранней стадии сродни акселерации, инвестициям, а не merchant acquisition активов или капитала.
Этот фреймворк возвратные средства рассматривает инвестиционно , а не с точки зрения оценки активов, например, текущей операционной или EBITDA и т.д.
В и нвестиционном управлении совсем по-другому ведется работа с рисками.
Все типы управления совершенно по-разному работают с рисками, с ресурсами, стратегией.
И, безусловно, абсолютно по-разному выглядит экономика этой деятельности.
Операционная экономика сводится экономистами одним образом .
Экономика проектной деятельности обосновывается, исходя из проектного экономического фреймворка – защиты фреймворка, например, на инвестиционном комитете или проектном комитете.
Бо льшое достижение, которое мы сейчас видим - это stage gates, которые, на самом деле, не из продуктового управления взялись. Все говорят: “О, L0, L1, L6, фреймворки, стадии” - спасибо большое за это проектному управлению.
Именно проектное управление начало стадировать деятельность и собирать статусы.
Вот то, что, кстати, «продуктовикам» очень сложно дается - это статусы. Собирать статусы по портфелю или по своей инициативе - это для них сродни «ногу откусить» , чем рассказать, что у тебя происходит.
Итак, по-разному ведется работа в разрезе того , что называется управлением - управление ресурсами, управление рисками, управление финансами.
И важно понять - при чем тут портфельное управление ?
Очень часто люди не видят разницы в перечисленных типах управления.
И как тогда переходить с ним на беседу: “А давайте с вами поговорим, что такое портфель , наполним портфель , поговорим о стадийности портфеля и переходе на стадию фреймворка … ”.
А человек не знает, что такое стадийное управление в проектном управлении.
Или «Давайте обсудим диверсификацию рисков по закону Парето или по любому другому закону » .
Для чего, на самом деле, нужен портфель?
Для того, чтобы не сходить с ума из-за рисков каждой единицы портфеля.
Что такое закон Парето?
Иногда 20% инициатив портфеля обслуживают весь P L всего портфеля, все 80% фейла, которые в портфеле есть .
Эта риск-модель нужна отчасти в портфельном управлении.
А иногда бывает так, что мы говорим, что мы внедрили портфельное управление, а функция контроллинга и финансов в портфельное управление паровозиком тянет свою риск - модель из годового бюджетирования или из экономического обоснования операционной деятельности.
И тогда, что у нас остается от портфельного управления? Название одно?
«Давайте сделаем портфель, но по каждой инициативе у нас будут минимальные риски»?
Зачем тогда портфельное управление ?
Если говорить о проверке знаний, пожалуйста, проверьте у ваших управленцев отличия этих разных типов управления.
У нас в Neuromap есть модуль, который называется "6 типов управления", где мы на примерах смотрим разные способы управления.
Рассмотрим в контексте портфельного управления пример.
Есть IT - департамент.
IT - департамент делает проект «Внедрение CRM - системы». Это крупная CRM - система, вендорская .
Защитили CAPEX, бюджет, протащили через обоснование, выбрали подрядчика. Начали внедрение.
Проект двухгодичный .
Замечательно !
Но это проект.
Пока мы его внедряем, у нас есть параллельно операционная деятельность, которая не останавливается. CRM - это управление клиентами, оно, в том числе, влияет на продажи через работу с цифровыми средами. Продажи, пока мы внедряем проект, идут в рамках операционного фреймворка. Там есть свои операционные задачи, например, рост продаж - директивных или продаж по определенным сегментам.
Если это банк, то это карточные продукты, кредит и т.д.
И проект, который внедряется в продажи, невольно начинает взаимодействовать с операционной деятельностью продаж.
Вот этот стык - проектного внедрения и операционной деятельности - зачастую не прорабатывается.
А причем тут портфель? А портфель - это еще круче !
Вот IT сделало CRM или делает.
Ничто вам не мешает рядышком завести портфель. Портфель можно даже сделать функциональным - например, привязанным к продажам вашего банка или вашего крупного бизнеса.
В рамках этого портфеля не оценивать операционные показатели продавцов, а например, завести 15 позиций инициатив, связанных с продажами при использовании платформы CRM.
Зачастую мы видим обратную историю: внедряется платформа CRM, waterfall спускается инструкция по использованию этой CRM продавцов заставляют ее использовать . Не хотят - пусть идут дальше продавать в другой необанк или запускают свой стартап, который «случайным» образом украдет ту же базу, которой владел продавец « Зато мы CRM используем !».
Это яркая иллюстрация непонимания того, что такое портфельное управление.
Можно было бы разумным образом забукировать ряд средств, которые должны были быть потрачены на реализацию набора инициатив, связанных с работой с CRM - системой.
Притом эти инициативы должны иметь конкретного инициатора, т .е. представителя, желательно функционального представителя. Т.е. если мы CRM для продаж делаем, то эта инициатива должна «гнездиться» в продажах. И каждая из этих инициатив может быть уровня проекта, может быть уровня предложения, может быть уровня идеи. Здесь речь идет о зрелости инициативы.
Но все эти инициативы в пределах полугода могут так или иначе пробовать реализовывать потенциал CRM - систем в управлении продажами с конкретным эффектом на операционную деятельность, например поквартально . Можно сделать короткие инициативы, short track, например .
Управленцы крупного бизнеса часто не понимают, что инициативы не обязаны дожидаться внедрения CRM .
Более того, если мы внедряем крупный вендорский проект с CRM, это не значит, что нельзя сейчас запустить инициативы по AMO CRM c конкретным департаментом, бизнес-юнитом, чтобы научиться, например, принимать решение по индивидуализации коммерческого предложения для H2H (human to human) продаж.
Обычно бывает наоборот. Приходит какой-то инициатор , говорит: « Я пользуюсь AMO CRM. Я хочу сделать с ней такую -то прикольную штуку, завести тестовый сегмент». Ему говорят: “Нет, дружище, у нас в корпорации внедрен проект по внедрению IBM CRM, мы теперь никакими AMO не пользуемся. Мы теперь запрещаем вам пользоваться всеми другими инструментами, пока мы не внедрим CRM. Все или ничего. Будешь сидеть и полтора года ждать, пока мы внедрим CRM и заведем туда всю клиентскую базу, переведем все бизнес - процессы продаж на новый CRM». Это еще займет 4 года вместе с потерей руководителя продаж.
Это очень легко решается через то, что мы говорим: “Ребята, внедрение CRM - это проектный фреймворк. Там цикл реализации - 2 года +» .
А портфель, если взять особенно современный подход, это short track , мини-T, короткие инициативы, он может реализовываться за квартал.
Т.е. все, что нам нужно для портфеля - это список Exсel из 15 инициатив и напротив конкретной инициативы фамилия конкретного человека, который хочет эту инициативу реализовывать.
И дальше мы уже можем задаться вопросом - как обосновываются эти инициативы ? Т .е. это просто расходные инициативы, либо мы будем требовать от них экономической возвратности, т.е. экономического обоснования , н явно проходящего вне бюджетного фреймворка и даже вне проектного фреймворка ? Потому что мы замучаемся проектный комитет для каждой инициативы делать. Особенно, если мы ограничены по количеству инвестиций в эту инициативу.
А самое классное - это то, что нам придется задаться вопросом , а какую фамилию поставить напротив каждой из этих строчек ?
Потому что эта фамилия - это уже не проектный менеджер, это не сотрудник, у которого есть обязанности в соответствии с должностной инструкцией . Это фамилия человека, который что-то хочет, который проявляет себя проактивно, который готов участвовать в трансформации маленькими шагами.
Т.е. он берет на себя ответственность за эту инициативу. Он ее реализует, сталкиваясь с блокаторами в продвижении , сталкиваясь с инертностью среды, сталкиваясь иногда с непониманием своего прямого руководителя. Последний иногда может сказать: “Ты у меня в операционном фреймворке, в линейной деятельности. Какая инициатива? Ты иди мне лучше сделай 2Х продаж”.
И, если честно, руководителя можно понять, потому что ему никакой Change сейчас не нужен. Ему нужно бонусы свои получить по концу квартала, выполнить операционные показатели.
Вот, что такое на практике стык всех разных систем управления.
Важно понять, что если в ИТ-блоке есть какая-то фича, какая-то платформа, IT- решения сами по себе денег не заработают. Они дают лишь инфраструктуру, среду, сервис для тех, кто в вашей корпорации с помощью этого заработает деньги. Вы работаете в корпорации и зарабатываете для нее деньги, что в гос. корпорациях зачастую забывается. И если вы зарабатываете деньги, тогда ваша задача - весь портфель IT, включая инфраструктурные инициативы, «обложить» соответствующими Product owner-ами со стороны бизнеса, которые на базе ваших инициатив IT реализуют свои предпринимательские задумки, идеи и деятельности.
И уже дальше возникает вопрос в рамках портфельного управления : как управлять ресурсами в портфеле?
- Как в операционном фреймворке формируются ресурсы?
Это штатное расписание, защита бюджетов, найм, HR-цикл и т.д., по сути, это cost штатных расходов , FTE тех, кого мы там же сокращаем.
- Как формируются ресурсы в проектной деятельности?
Это защита проекта, защита бюджета проекта, выделение на проект, как правило, матричных ресурсов. Это как крутую тачку купить, но плохим бензином ее заправлять , а потом думать, что у нас « крутая тачка не едет быстро на 95-ом бензине, ломается все время» Мы же покупали крутую тачку, чтобы экономить потом на бензине!
Это к вопросу использования матричных ресурсов в проектном фреймворке.
- А если мы говорим про портфельное управление …
Здесь управление ресурсами - это инвестиционная деятельность.
Мы инвестируем людей в эти инициативы.
Возникает вопрос.
Если люди - это актив, ресурс, который можно инвестировать, то кого мы инвестируем, а кого нет?
И верно ли ряд человеческого ресурса держать в операционном управлении?
Является ли это максимизацией рычага на EBITDA от конкретной фамилии, или эта фамилия нам рычаг на EBITDA даст больше в конкретной инициативе или в проекте, если это более серьезная история?
И вот, когда вы начинаете смотреть на людей как на ресурс, в который можно инвестировать, то вы понимаете, какое количество потерянной прибыли есть в корпорациях, насколько они перемалывают человеческий ресурс, глупо теряют его, запутываясь в этих всех системах управления.
И самое главное - они теряют выращивание этого ресурса, который уже давно не свойственен для операционного управления.
Его надо выдергивать из операционного управления – но постепенно, потому что пока он в операционном управлении, он погружен в операционный контекст - это самое дорогое, что нужно, чтобы придумать инициативу. Потому что «продактов», продуктовых дизайнеров вы наклепаете на «раз, два, три», половина литературного института, все «креативщики» туда пойдут.
А вот как вы человека погрузите в построение, например, вашей скоринговой системы в банке или бизнес-процесса вашего кредитного конвейера, или ограничение законодательного регламента в области банковской лицензии, или технологию производства кокса в промышленной компании? Вы замучаетесь человека погружать в контекст. У вас же все это не описано!
У вас же это все в головах у технологов, а не в технологических картах. Поэтому, естественно, будущие инициаторы, будущие лидеры должны быть внутри операционного управления.
Все это важно понимать.
- Еще одна важная тема, в которой вам нужно разбираться – портфельное инвестирование.
Т.е. вы должны понимать, как принимать решения по гибкому бюджетированию, гибкой инвестиционной деятельности в конкретную инициативу в зависимости от того, на какой стадии она находится.
Стадийность (L0, L1, L6 и т.д.) нужна не только для контроля и битья по голове человека, который реализует инициативу. Она используется в принятии решений дальнейших инвестиций, это так называемый traction .
Финансовой функции зачастую из -за редукции этого бюджетирования, которая висит над ними дамокловым мечом, приходится очень тяжело…
А в трансформации бедные финансисты как меж двух огней находятся .
С одной стороны, бюджет надо сверстать и не потерять деньги акционеров, потому что финансовая функция - это последняя инстанция защиты денег, чтобы их не растрачивать.
А с другой стороны, "вынь да положь", инвестируй во все , и «что это вы у нас ограничиваете инвестиции ?! Вы, финансисты, не даете денег. Из-за этого у нас трансформация не происходит !».
Вот так бедные финансисты мучаются между двух огней.
То им по шапке прилетело, что они денег дали туда, где они «профукались» , то им по шапке прилетело, что они денег не дали, потому что из-за них стоит на бюджетировании какая-то важная инициатива.
А истина посередине - гибкое бюджетирование, smart investing .
Т.е. финансовая функция, к сожалению, в крупном бизнесе с инвестициями напрямую работает редко.
И мы зачастую видим достаточно слабую функцию контроллинга .
Теперь немного бенчмаркинга.
Одна из самых сильных функций контроллинга, которые мы, Neuromap, встретили на рынке - Северсталь.
Там работает о дин из самых современных и бизнес- ориентированных контроллеров. Контроллер принимает решение о том, как найти потенциал, а не как защитить деньги акционера. Он защищает прибыль акционера на базе его денег, а не его деньги п отому что деньги сгорают.
Итак, вам также нужно освоить современные способы контроллинга, связанные с его поэтаптностью. В этом контексте фреймворким дают финансовой функции более дидактическую, детальную, методологическую функцию контроля инвестиций с принятием решения о том, что сделать можно лучше.
Потому что финансисты зачастую останавливаются на том, что плохо. Они говорят: “Плохая экономика. Не сходится экономики, обоснования нет”.
Мы говорим: “Хорошо, подскажите. Вы же финансисты, вы экономисты. Вы макроэкономику предприятия знаете. А как нам лучше-то?”.
Они говорят: “Всё. Не подскажем. Это не входит в наши должностные инструкции. Идите, ищите новую экономику и приходите”.
Это пассив.
Это не проактивная финансовая позиция.
И, наоборот эти людям , которые предлагают инициативы, говорят: “А почему у вас нет экономического эффекта?».
А у нас же все экономисты!
У нас человек на металлургии засовывает кокс в печь.
«Что это он не получил экономического образования. В «вышке » не мог поучиться? Не может, видите ли, без экономического обоснования инициативу сделать! Ай, ай, ай!».
Come on, guys. Ну, давайте, хоть минимально компетенции простроим.
Скажите спасибо, что он видит, что мы печи недозагружаем и что мы можем загружать ее лучше в определенной технологии, в определенном способе загрузки печи, который раньше не использовался, например, динамическим использованием эффективности производственного звена. Но мы же еще с него требуем экономику.
Т.е. нужно компетенцию выращивать в сервисе, а не требовать от всех что-то, чего не хватает компетентностно .
- Также вам обязательно нужно уметь профессионально работать с рисками.
Если вы работаете с портфелями, то риск-менеджмент заимствуйте у акселераторов, венчурных фондов, инвестиционных компаний.
Потому что нельзя работать с рисками так, как работает бюджет, как работает бюджетная функция. Это, по сути, значит расписаться в своей некомпетентности, потому что, да, рисками надо управлять, а не минимизировать.
Например, иногда надо максимизировать риски, потому что именно на максимальном риске происходит, например, отрыв от конкурентов.
И есть уже готовые способы максимизации рисков с минимизацией бюджета, которые в схлопывании дают оптимальную модель. Почему так любят Lean digital, Short lag проекты (короткое плечо проекта)?
Да, потому что мы максимизацию рисков коррелируем, диверсифицируем за счет минимизации отрезка до эффекта.
И любой математик вам эту модельку соберет и объяснит , что она статистически, действительно, более сбалансирована, чем просто давать деньги влево и вправо на годичные проекты.
Т.е. вам нужна профессиональная работа с рисками.
- Важно уметь ресурсно управлять портфелями.
Часто допускаются ошибки, и ресурсы в портфеле предоставляются не инвестиционно, а деградируют из старых моделей ресурсного управления - матричный принцип ресурсного снабжения или операционный .
Или бывает такое.
В портфеле выделили ресурс, команду на инициативу, которая "не выстрелила".
И дал ее вся команда снимается, распускается, «раздается» по функциям, просто раскидывается назад по другим проектам.
Затем собирают новую команду, с новой гипотезой в этой же области и опять идут вперед.
Полгода ребята работали. Да, они завалились, но они опыт получили !
Вы что, не можете этот ресурс заново реинвестировать в следующую гипотезу с тем же Product owner?
«Нет, не можем! Они же совершили ошибку. Их надо наказать!».
Но это просто ошибка ресурсного управления – вы нематериальный актив, ресурс, который повысился в цене, реинвестируете не оптимально. Вы его раскидали туда со своей экспертизой, где она не нужна. А ту экспертизу, которую вы в ресурсе вырастили, с точки зрения компетенции, вы растратили. Это, правда, уже из talent - менеджмента, но тем не менее.
- Вы должны понимать, как делается сегментация портфеля.
Какая ошибка здесь часто допускается?
Во-первых, создается один общий портфель для всей компании.
В нем находятся все инициативы - инфраструктурные, стартаперские, короткого плеча и долгого плеча, и годовые, и инновационные, и продуктовые, и маркетплейсы, и платформы, и M&A, и collab - все .
А мы знаем, откуда ноги растут !
Из принципа, по которому бюджетируется все целиком.
А потом смотрят, как ко всем инициативам сопоставить одинаковый контроль их эффективности или экономического обоснования .
Вроде же не комильфо одних по одной схеме защищать, а других по другой, обидятся же скажут: “Вы нам всю душу вынули по расходам. А этим дали два миллиона просто под обещание , «верю - не верю» . У нас так не принято в компании. У нас же правило. Для всех одно и то же”.
Поэтому, конечно же, сегментация портфеля - это профессиональный навык.
Самое простое, что нужно делать - это обязательно разделять портфели так называемый cost reduction, это лидерство по снижению затрат. Там вы работаете с затратами. Вы не работаете с стратегией, с прибылью, с новыми возможностями, с качественными эффектами. Это killing offer.
Cost reduction портфель - это всегда портфель, на котором можно сделать эффект «не бей лежачего» . Потому что затрат в компании всегда огромное количество. Всегда накапливается cost reduction долг, потому что за счет того Change и тех изменений, которые происходят в компании, всегда будет неоптимизация затрат.
Потому что вы понимаете - вверх, вниз. Мы что-то делаем, мы затраты генерим, некогда из оптимизировать. Мы что-то сделали. Инициатива вышла на плато, мы начинаем ее потрошить и оптимизировать.
Поэтому эти волны неоптимальных затрат они всегда есть.
А если вы еще начнете смотреть с точки зрения нового потенциала , например, рассматривать те же затраты в контексте новых технологий по data driven, по математическому моделированию, по мат. оптимизации, по компьютерному зрению , то вы научитесь искать потенциал в затратах благодаря достижению новых цифровых продуктов. Это всегда будут достаточно короткие и быстрые, и легко проектируемые инициативы.
Особенно, если вы не заходите сразу в особенно опасную зону - работа с сложными структурами затрат - а в простые истории, связанные с человеческим фактором, человек всегда неоптимален расходует и сырье в компании, и ресурсы.
Итак, держите cost reduction в виде отдельного портфеля .
Вы должны выносить cost reduction инициативы в портфельное управление из операционного фреймворка и проектного фреймворка.
Рекомендация – отдельно формировать портфели с трендом на короткое плечо, шорт лег - чтобы у вас в портфеле, даже длинные инициативы (проекты), которые вы берете, например, некоторая платформа, разрезались на короткие плечевые инициативы, которые «отдирают» часть проекта в себя как первый результат.
Берите платформу, расписывайте на эпики и деливерите платформу отдельными фичами.
Таким образом, например, сейчас один из наших клиентов внедряет платформу по управлению талантами или обучению.
Сначала они делают сервис, связанный с assessment сотрудников, потому что assessment сразу же приводит людей к реализации программ обучений.
Они не всю платформу сразу делают, а один модуль сделали и сразу используют.
Это пример того, как большой, двухгодичный проект через несколько месяцев уже дал первую фичу и ее сразу в инициативку утащили в портфель.
Отдельно делайте портфели, разделенные на функции.
Допустим, вы функции ставите задачу: «Мы везде внедряем «цифру». Только нужно сразу расставить точки над i и сказать: “У вас операционная деятельность. Да, мы управляем операционной деятельностью. Мы ее никак не меняем. Мы не будем мешать вам делать вашу операционную деятельность. Но отдельно вы должны инвестировать ресурс. Или мы вам поможем - больше ресурсов дадим, дополнительный бюджета дадим, еще что-то. Вы должны инвестировать в портфель Change, например, связанный с цифровизацией , функциональными цифровыми портфелями, с внедрением конкретного инструмента». Крайне рекомендую не делать всю « цифру » сразу. Сделайте портфели по дашбордированию – это достаточно простая история.
Например, постройте еще матричную ресурсную историю, которая в разные портфели будет дистрибутировать компетенции дашборд - специалистов, например, data - scientist, какого-нибудь крутого "продакта" по data.
А сами портфели будут реализовываться middle, junior , обучившимися Python.
Это уже круче !
Это уже мы оргструктуры придумываем.
Бывает такое, что вы инвестировали в облако данных, в data lake в компании, а потом днем с огнем ищите, кто бы его использовал его для инициатив .
Ок, не надо собирать менеджмент, всех мучить, что с этим делать. Тихо, спокойно берете портфель, называете его «Технологический портфель по дашбордированию» , ставите KPI по 15 инициатив. Далее раз в неделю смотрите, где есть еще 7 инициатив, где еще 5 инициатив, где еще 4 инициативы.
Т.е. у вас появляется задача наполнения портфеля.
Вы говорите: “Коллеги, у меня целевое ожидание от портфеля 500 млн. долларов. Будьте добры, наполните портфель, потому что в текущих инициативах вы напридумывали на 170. Где еще 320 млн. ?».
Вам ответят: “У нас еще операционка”. Вы говорите: “Хорошо , не только вы. Мне в портфель нужно еще напридумывать 320 млн. Притом напридумывать так, чтобы они еще и сходились и приносили эти деньги с точки зрения проверки коммерческого обоснования» .
Итак, портфельное управление может ставить задачу наполнения портфеля инициативами, проектное - не может.
Нельзя в проектном управлении говорить: “Напридумывайте мне еще проектов на 320 млн.”. А наполнение портфеля - это вполне управляемая история в этом контексте.
Вы, по сути, ставите ресурсную задачу по портфелю, возвратности средств .
Но при этом вы еще можете инвестировать в портфель и тем самым, например, в том числе, делать мероприятия для менеджмента, collision worksop или какие-то мероприятия, направленные на придумывание инициатив, Ideation. Делайте с большим количеством сотрудников мероприятия по придумыванию инициатив
- Отдельный важный момент для IT и для Digital - ресурсное управление разделения на команды.
Сейчас во многих IT - блоках есть клиентские команды - когда IT превращается в командные пулы.
К омандный эффект - это высок ий мультипликатор эффективности инициативы. Вы его в проекте и в линейном фреймворке не увидите. В матрице не увидите, в бизнес - заказчиках, в фичах.
Да, команды - это крутой способ ускорить time to market, увеличить PnL за счет того, что команда срабатывается по циклу задач.
Например, можно делать команду, направленную на все cash back в банке. И у них может быть целый набор инициатив, связанны й сcash back. И команда нарабатывает от инициативы к инициативе командную экспертизу.
- Откуда взять «продактов»?
Это отдельный вопрос.
А "продакты" ли это?
Может быть, это бизнес - трансляторы, может это проектный менеджер, может, это вообще молодежь, а может, ряд инициатив можно поместить в студенческий акселератор ? А, может быть, вообще, возьмем готовые инициативы с рынка через хакатоны, а не будем придумывать внутри ? Т.е. можно растождествить бизнес и задачу наполнения портфеля.
Если вам легче заполнить портфель вне компании, наполняйте его вне компании. Т.е. бизнес смотрит на это и думает: “ Что-то у нас хуже получается, чем у студентов, придумывать инициативы.”
Ну, и отлично !
Вы аккуратненько создали некое давление на культуру компании, напомнив сотрудникам, что задача наполнения портфеля не ограничена ими и что они должны конкурировать с более молодыми и более креативными и, самое главное, более свободными, более амбициозными, более мотивированными людьми. Да, иногда это позитивно сказывается, иногда наоборот.
- Также важно использование управления офиса PMO.
Это дашборд портфеля, это метрики портфеля, это то, как контролировать traction портфеля слева направо от идеи до проектирования, до реализации, до первого эффекта и до масштабирования эффекта. Это все, что у нас во фреймворке есть.
Особенно здорово, когда вы портфели нарезаете по revenue - стримам – т. е. у вас есть весь портфель по комиссионному бизнесу, весь портфель по необанкам, весь портфель по скорингам (если это промышленность, то весь портфель по upstream, а в upstream весь портфель, например, направленный на ресурсные предприятия).
Т.е. это правильно с точки зрения портфельного управления.
Но это никакого отношения не имеет к орг. структуре управления линейной деятельностью. У вас в портфеле свои управленцы, владельцы портфеля , свои инициаторы.
Они не должны « биться » один в один с вашими директорами операционных подразделений и с вашей вертикалью власти. Потому что вы устанете одно к другому приводить. Это го не нужно делать.
Мы специально это растождествляем, чтобы в портфельном управлении быстрее , без всяких политических перестановок всем дать работу.
Если вы все все время будете это сопоставлять с назначениями, то успехом это предприятие не закончится .
И также я крайне рекомендую портфель накладывать на лидеров и на молодежь.
Мы всегда на связи: Telegram, сайт, info@neuromap.tech.