Четвертое – мы, в принципе, не нашли ряда крайне важных функций, которые должны быть в организации, а их, в принципе, просто не было.
Юрий Левичев.
Генеральный директор
Lens Consalting.
Кейс организационной трансформации
Часть 2
Не было функции партнерств – вот этой самой ячейки, которая управляет партнерствами, альянсами и иными. Не было функции Катомер-саксесс. Кто знает, что такое функция Кастомер-саксесс? В продажах, когда вы продаете продукт, особенно, если это IT-продукт, практика и все исследования показывают, что, в среднем, ваши клиенты используют от 20 до 50% функциональности или выгод этого продукта, то есть, иными словами, клиенты не до конца доиспользуют ту пользу, которую этот продукт приносит, и глобально во всём мире уже дано это, это не мы придумали – я бы был рад, но не мы, и даже, мне кажется, где-то к моему рождению это было придумано в мире, что есть отдельные в продажах функции, которые занимаются Кастомер-саксесс, то есть они взаимодействуют с клиентами для того, чтобы дообучать их, изучать проблематику, с которой они работают и помогать тому продукту, который они приобрели, решать все задачи клиентов. Потом бренд-менеджмент отсутствовал, как ни странно, и, самое главное, отсутствовал СХ-кастом-рекс-пириенс-менеджмент. Это ключевая функция вообще не только для продуктовых компаний. Она сейчас везде бомбит, эта функция – это управление клиентским опытом. В банках вы, наверное, это встречали, в эйчаре это управление опытом сотрудников, Имплай-экспириенс-менеджмент, и так далее. Вот это ключевая штука, на которую многие компании сейчас строят вообще свои конкурентные преимущества.
Недостаточный фокус на разработки новых продуктов, потому что рост выручки, императив стратегический, который был, он предполагал не только органику, вернее, он предполагал и органику тоже, а внутри органики он предполагал и разработку и развитие, рост за счет собственных новых продуктов, а когда у вас нет контура в структуре – кто за это отвечает, это не будет выполняться, однозначно. И шестое, в районе стримы были разбиты, то есть несколько продуктов продавались в разных частях организаций. Это не очень хорошо. Ну и точно не содействовало тем принципам, которые мы создали.
Забыл сказать ликлеймер. Каждый из проектов, про которые я буду рассказывать, объемом от 60 до 250 слайдов. За оставшиеся 40 минут времени, конечно, это нереально – про это рассказать, плюс есть конфиденциальная информация, поэтому сразу говорю, что я даю выжимки, какие-то короткие выжимки, скриншоты, просто рассказываю логику, чтобы мы с вами понимали, как мы двигались.
Первое, что мы сделали, конечно, мы снизили количество прямых подчиненных. Слева у нас было 16, правее их стало девять, и тут минусами подсвечено, кто под кого зашел. Это первое, самое очевидное.
Второе. Давайте сейчас по функциям, что появилось. Мы ввели бренд лида и функцию маркетинг «Опс!», я там ее не перечислял – ее также не было. Это повышение эффективности функции маркетинга. Когда у вас бюджет в этой функции и масштаб функции переваливает за определенный масштаб, то эта функция должна появляться. Это про собственную эффективность. Мы создали, сконструировали функцию CDO (Chief Data Officer). В компании был внутренний IT-директор, который отвечает за две функции: IT и автоматизация бизнес-процессов. Мы создали еще Дата-центр и хранилище данных, и создали CDO. Мы создали как раз тот самый партнершип энеменей экзекьюшен – кубик, который отвечает за партнерство и альянсы. В CPO поворошили много, полностью переделали, предложили переделать структуру с продуктовой на кастомерную. Я сейчас еще пару слов про это дальше скажу. Кастомер-саксесс и внедрили в сейлзах и завели все продажи, международные тоже под сейлз – они были не в одном контуре. Сейлз-эффективность туда же занесли, функцию организационного дизайна и под VP-эйчаром еще создали эйчар-директора и лигал убрали под финансы. Это очень обзорно, чтобы было понятно изменение, которое мы предлагали.
Так как часть информации, всю информацию мы также для Совета директоров готовили на английском языке. Так как хотелось показать реальное движение по кеймсу, а времени с английский на русский переводить не было, то я предпочел хоть что-то показать, но на английском. CDO (Chief Data Officer) – это VP по управлению данными или ЗГД по управлению данными. СТО (Chief Tecnical Officer) – это наш директор по… как это у вас называется? Он у всех по-разному называется. Это главный по IT и разработке, давайте так назовем. CMO (Chief Marceting Officer) – главный за маркетинг. Дальше, вот это стретидже оффисер – это главный по стратегии, это главный продуктовый человек, это главный по продажам, это главный по безопасности, это HR, а это сейфо – финансовый директор. Мы стартовали в 800.
В итоге мы предложили два типа структуры. Сейчас я много чего срезаю – там много было исследований, международных практик и всего остального, и мы предложили в итоге Совету директоров две опции – это продуктово-функциональная матрица и клиентская матрица. Генеральный директор поддерживал эту опцию, мы поддерживали эту опцию. Мы долго беседовали на Совете директоров, выбрали вот эту опцию – и всё, компания пошла в эту опцию.
После того, как мы с Советом директоров утвердили вот эту структуру первого, второго уровня – то, что вы видели – мы разработали детальный план, как ее внедрять. Ну вот так мы на входе договорились, что у нас внедрение не входило в периметр наших работ. Это не значит, что мы не умеем этого делать, просто не входило. И здесь слева вы видите более-менее стандартные шаги, которые делаются всегда: план коммуникаций, дальше надо разрабатывать, дорабатывать структуры третьего уровня и ниже, всё оформление сотрудников, переводы – всё понятно, но мы компании еще подсказали, редизайн каких бизнес-процессов нужно сделать для того, чтобы эта структура зажила, потому что каждый кубик, появляющийся в пространстве – он генерит или оттягивает на себя коммуникационные потоки, он не в вакууме появился, не просто там Дата-центр создался, и вот он просто появился – и круто, сам по себе. Он куда-то встроился, в какие-то потоки, и внутри этих потоков нужно обязательно разбираться.
Ну и, конечно, за счет численности. По новым функциям его тоже нужно было делать, потому что, когда мы сказали, что нам нужна функция управления клиентским опытом или вот этот Кастомер-саксесс, например, или СХ – то, что управление клиентским опытом, вопрос, а сколько нам людей таких надо, какого уровня эти люди должны быть, а какими компетенциями должны обладать. Вот это, по крайней мере, всё по шагам, что нужно определить, чтобы это зажило – мы прописали.
Ну и, собственно говоря, были очень рады. Наступил момент радости. Всегда, когда вы заканчиваете проект, у вас наступает момент радости, и вы выглядите либо так, ну, либо плюс-минус как-то так. Но не тут-то было. Нас попросили заняться внедрением всего того, что мы нагенерили и попросили заняться внедрением вот в четырех направлениях: в продуктовом, в продажах, в управлении данными и в разработке. Но, собственно говоря, надо было до конца, до начального уровня специалистов проработать всю структуру, численность, но самое важное – нужно было проработать все связки взаимодействия, потому что, когда вы живете в плоской структуре, когда люди постоянно общаются друг с другом, это крайне важно. Вообще, компания очень открыта, компания очень слушающая, не терпящая никаких директив. Нельзя прийти и сказать: «Я считаю так! Это правильно, будем делать так!»
Мы какое-то время назад в Яндексе, когда я еще в другой компании работал, моя команда в Яндексе оптимизировала HR-процессы. Достаточно болезненный опыт. С какой точки зрения? Яндекс – прекрасная компания, очень любит своих сотрудников, а еще у них нельзя заставить ничего делать сотрудников, то есть у нас важным этапом был сбор и анализ трудозатрат по HR-функции – ну, так нужно делать в этой работе. Так вот, а они не заполняют анкеты и не заполняют. Мы приходим, просим: «Повлияйте как-то на них». Они говорят: «А мы не можем. У нас так принято, что, если человек не хочет делать – он просто не будет этого делать. Никто его не может заставить это делать: ни руководитель, никто». И здесь, конечно – хотел сказать: «Слава Богу, не так», потому что было бы сложно двигаться в трансформации, но обычно в этот момент спрашивают: «Что же вы делали?» Я вам скажу, что делали: два наших консультанта взяли игрушку «Ждун» - знаете Ждуна? Они сели на первом этаже где-то под елочкой, где-то там еще, делали фотографии и слали во все чаты, которые у них были, уговариваю людей заполнить анкеты в проекте, за который они платят деньги. Ну, такая культура. Здесь не так, конечно, гипертрофировано, но очень в этом плане классно.
Хорошо. Значит, оргструктура. Оргструктура – это понятно, с этим поработать, но не в этом был челлендж, не в этом был вызов для того, чтобы дальше туда спускаться. В общем, если вы, в принципе, умеете с этим работать, это не такая сложная задача.
У каждого из этих направлений были свои моменты, с которыми надо было поработать, которые надо было прорабатывать. Если мы говорим про продуктовую функцию, то там нужно было очень четко ее настроить под клиентский сегмент. Она вокруг продуктов была создана. Если мы говорим про маркетинг и продажи – там нас попросили на эффективность процессов, вообще, посмотреть. Если мы говорим про управление данными, то там нужно было договорить всех между собой, потому что децентрализованная аналитика.
В чем преимущества и недостатки централизации и децентрализации? Когда у вас функция децентрализована, это что значит? Это специалисты определенной функциональности находятся в разных подразделениях. В чем плюс? Плюс в том, что они решают конкретные задачи этого подразделения. Они на его потребности работают. В чем минус? Сложно очень в горизонтали между собой стыковаться, работать на одних методологиях, но это бывает крайне сложно. Вот здесь надо было договорить всех помочь принять правильное решение, как это организовать.
Ну и масштабируемость. Ну и масштабируемость с точки зрения разработки. 30 прямых подчиненных. 30 команд разработки, напрямую подчиненные руководителю. Я думаю, этим всё сказано. Компания при этом не стоит на месте, развивается. Вот тут нужно было поработать со структурой, чтобы помочь оторганизоваться.
Ну давайте, буквально по нескольку, наверное, моментов в каждой из них. Продуктовая функция. Разработали целевую структуру. Там ключевая штука – вокруг чего была. Нужно было перенастроить всю продуктовую функцию под работу с клиентским сегментов. Вот у вас есть ваша платформа поиска или вакансия поиска работы, но на эту платформу приходят разные соискатели. Это и ИПшники, это большие корпорации, это средний бизнес, и так далее. И до этого и процессы, и мышление продуктовых руководителей было заточено на продукты, а нужно было менять всё на продуктовые сегменты, на катомерные сегменты. И в этом был основной вызов. Но здесь мы также, кстати, описывали новые роли и схемы взаимодействия. Мы прорабатывали карьерные треки, нас попросили проработать карьерные треки, нас попросили даже заняться вознаграждением, и здесь мы рассказали, сколько эти специалисты должны стоить. Это всё наши компетенции, мы это хорошо знаем и умеем делать.
Так, например, выглядел пример карьерного трека, который мы описывали с требованиями. Долго не буду останавливаться – всё-таки это информация на стороне компании.
Что делали на продажах в маркетинге? А вот тут было интересно, потому что ну да, в маркетинге было «маркетинг – опс!», который мы внедряли, в продажах были свои функции, которые мы внедряли, но у нас от EP по продажам была отдельная просьба – посмотреть на эффективность ключевых процессов. Это так называемые «продажи с низким касанием» (low touch) – это то, что всё через диджитальные каналы идет, продажи через диджительные каналы, там, где не нужно персонально взаимодействовать с покупателем продукта, и есть так называемые high touch продажи, то есть с высоким касанием. Это когда продажник, условно говоря, продает, человек взаимодействует с человеком, то есть нужно было посмотреть по всем каналам, основные процессы взаимодействия с маркетингом – отсюда появились как раз карты процессов, которые нам надо было здесь для того, чтобы мы могли заняться внедрением той структуры, которую мы на первом этапе разработали, а нужно было поописывать эти процессы, поописывать взаимодействие с маркетингом, и так далее.
Мы описали процессы, нашли слабые места, прямо четко их показали, сказали: «Менять нужно здесь». Всё обсудили и со всем согласились. Разработали целевую структуру маркетинга, ну и описали новые роли, компетенции. Недостаточно нарисовать кубик. Мы же с вами понимаем, задача на этот вопрос – помимо того, сколько таких людей нужно бы, как их назвать правильно: кто это – это менеджеры, это старшие менеджеры, это начальники отделов, это руководитель команды. Потом, какими компетенциями он должен знания и навыки – потому что надо его искать на рынке. Нам надо реально разместить вакансию, и чтобы люди откликались. Вот, и как эта должность или роль новая будет взаимодействовать внутри. Вот всё это мы для них прописывали, для того, чтобы это можно было реально взять в работу и реально с этим работать. Уже на этом этапе, уже на втором проекте, который мы делали, по вот этим описаниям уже нанимались люди в компанию на те роли, которые мы им предлагали.
Что у нас в аналитике и в данных происходило? Мы смотрели на текущую функцию, вот так приблизительно, вот так приблизительно выглядели верхнеуровневые коммуникационные потоки, которые мы описывали – тут же нужно и упрощать тоже, в том числе, несложно это выглядит. У нас есть четыре, как минимум, модели, как можно организовывать функцию управления данными. Мы все эти модели рассматривали, подсвечивали, обсуждали, там тоже все эти структуры прописывали, и, к слову сказать, что самый большой расчет целевой численности – мы еще везде целевую численность рассчитывали под каждые роли – он как раз был именно в функции управления данными. И те из вас, кто внедрял или работает на управление данными знает, что там культура ищется, целый пласт идет работа с культурой. Мы также им давали рекомендации, как правильно – «правильно», это всё относительно в нашем мире, но, как нам кажется, было бы эффективно работать с точки зрения управления культурой работы с данными.
Пару слов, наверное, про численность. Мы очень любим собирать численность, так называемую, снизу-вверх, «боттом ап». Что вы для этого делаете? Вы рисуете кубик, выписываете задачи, которые он должен делать, дальше ставите среднюю продолжительность, частоту выполнения этих задач. Так, снизу-вверх, с уровня операций собирается ФТИ. ФТИ, или штатные единицы. Вот, штатные единицы, вот так вот! Так, снизу-вверх вы собираете количество. Вот оно, 108 – так мы рассчитываем количество часов, которое нужно, приводим, чуть нормируем, ну и так далее. Но тут мы пошли дальше.
И вторая штука, которую мы еще обычно делаем – мы это прогоняем через модель Монте-Карло. Кто-то из вас? Это такая штука симуляционная, вы – туда. Ей несложно, кстати, научиться, с ней работать в Экселе – совершенно спокойно с этим можно работать. Вы забиваете набор переменных, и она рассчитывает вероятность, то есть модель Монте-Карло дает вероятностную оценку. Вы забиваете переменную, что, если у меня задач будет, условно, столько, в среднем они будут длиться столько, каких-то потоков входящих будет столько, прогони мне через 10 миллионов симуляций, и покажи на нормальном распределении купол, какая будет численность. И он вам показывает потом, и, если, прямо, в центр нормального распределения ставите и говорите: «Вот, вероятность, наибольшая вероятность, что мне понадобится столько-то людей». Мы через модель прогоняем любые расчеты, в принципе, любые расчеты численности, иногда с вознаграждением когда работаем, это хорошая проверка. В данном случае, кстати, был хороший кейс, когда они, прямо, совпали. И они не всегда совпадают, не всегда математика подтверждает логику, с которой работаем.
