Бизнес-линии, сервис-линии и платформы @ T-Bank

Достаточно давно я не писал про менеджмент и решил исправиться, написав про структуру Т-Банк:) Наша компания устроена федеративно: разные подразделения работают достаточно независимо для достижения общих целей компании. Большая часть подразделений относится к одному из трех типов: бизнес-линии, сервис-линии, платформы, которые сильно отличаются друг от друга. А для руководителя важно понимать в каком типе подразделения он работает.

Бизнес-линии

Характерной особенностью такого подразделения является продукт, который предоставляется внешним клиентам (продукт может быть разных типов: b2c, b2b, b2g, b2b2c, …). У продукта обычно есть план развития и продуктовые метрики, а также PnL (profit and losses). Такое подразделение похоже на мини-компанию внутри большой компании. Примерами бизнес-линий могут быть: банк физлиц и отдельные продукты внутри (дебетовые, кредитные, …), банк для юрлиц и отдельные продукты внутри (РКО, бухгалтерия, …), инвестиции, страховая и так далее. В нашей схеме у таких бизнес-линий есть собственные бизнесовые руководители (CPO) и их ребята в виде продакт менеджеров и бизнес-аналитиков, а также собственные технические руководители (CTO) и вся структура IT команд под ними. В идеальном случае бизнес и IT выровнены по целям и используют какой-то фреймворк для каскадирования целеполагания по всем уровням.

Сервис-линии

Эти подразделения оказывают некоторый сервис, который необходим бизнес-линиям для эффективной работы. Такой сервис часто проще строить централизованно и получать эффект экономии на масштабе. Также очень важно, что в сервис-линиях часто концентрируется некоторый важный ресурс, который надо уметь использовать совместно и не допускать эффекта трагедии общих ресурсов (tragedy of the commons). Поэтому снаружи сервис-линия для бизнес-линий выглядит как некоторый интерфейс, куда они приходят за сервисом, который предоставляется с определенным уровнем качества. Внутри же сервис-линия часто состоит из какого-то набора специалистов, которые в рамках операционной деятельности оказывают сервис. Деятельность этих специалистов автоматизируется командой разработки этой сервис-линии и на выходе получается большое количество инструментария, который позволяет оказывать сервис эффективнее. Для сервис линии важно уметь считать косты, которые аллоцируются на бизнес-линии, которым оказывается этот сервис. А вот profit часть здесь считается сложнее, но обычно есть матмодельки, которые показывают как его можно оценить:) Например, для онлайн-привлечения затратами являются затраты на ФОТ сотрудников, рекламу, а прибыль считают из моделей NPV продукта, куда привлекают пользователей или LTV привлеченного клиента (этот подход посложнее NPV).

Платформы

Эти подразделения создают продукты для внутренних пользователей. Характерной особенностью таких продуктов является возможность использования их в формате self-service. Самым ярким представителем таких платформ является IDP (internal developer platform), которая направлена на инженеров внутри компании, которые создают цифровые продукты. На тему IDP можно почитать whitepaper от CNCF и мой разбор в трех частях: 1, 2 и 3. Платформа бывает представлена в виде коллекции возможностей, что определены и представлены в соответствии с потребностями пользователей платформы. Здесь важно, что все эти возможности интегрированы вместе и предоставляют возможность выполнять типичные сценарии пользователей платформы. Помимо IDP бывают и более высокоуровневые платформы, которые предоставляют возможность использовать платформу в формате as a Service или развернуть для себя какую-то часть сервисов платформы, если коммунальная версия почему-то не подходит.

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

Дальше я приведу пару примеров

Привлечение (сервис-линия)

Продолжу рассказом того, как у нас устроено привлечение, с которого я и начинал тогда еще в Тинькофф почти 8 лет назад. Привлечение — это каноническая сервис-линия, у этой сервис-линии заказчиками являются бизнес-линии. Задача от них упрощенно звучит примерно так

• С учетом наших бизнес-планов нам надо привлечь X% новых клиентов
• У нас есть на это бюджет Y млн рублей
• У нас есть модели для оценки вклада привлеченных пользователей в PnL продукта (последние годы мы переходим к LTV моделям)

Кроме таких целей по продуктам есть еще общие рекламные активности: телевизор, спонсорские контракты (как с КХЛ). Эти траты не всегда легко аллоцировать на конкретный продукт, но их надо уметь учитывать.

Дальше у нас есть каналы для привлечения, которых до 2022 года было в разы больше, но и сейчас остались инструменты от Yandex, VK и так далее, работу с которыми надо автоматизировать, чтобы маркетологам, таргетологам, performance менеджмерам и остальным ребятам из сервис линии было удобно работать, а их руководителям сыпались актуальные отчеты

• У нас есть внутренние инструменты аля рекламный кабинет, который интегрирован с внешними системами. Он помогает из единого места управлять рекламой, туда встроены контроли и подсказки, а также подтягивается аналитика из внешних рекламных инструментов.
• Дальше эта аналитика объединяется с внутренней информацией из data platform для того, чтобы построить сквозную аналитику с учетом оффлайн событий: встреч с клиентами, выдачи продуктов, утилизаций продуктов и так далее. В итоге, по каждому продукту и каналу можно получить отчет о том, как он себя чувствует и принять решение о запуске/остановке привлечения на определенный продукт или через определенный канал
• Внутри у нас есть сервис аудиторий, который позволяет объединять данные по пользователям (например, какие продукты есть у клиентов) и показанной рекламой. В итоге, мы можем делать таргетирование на look a like пользователей в рекламе или наоборот исключать часть сегментов из таргетинга, чтобы не показывать рекламу продуктов, что есть у клиентов
• Другой важный момент — это модели атрибуции. Суть в том, что для продажи продукта часто нужно несколько точек касаний через разные каналы иначе продажа не состоится. Но в простых инструментах обычно продажа засчитывается тому касанию, что было последним — это может приводить к локальным оптимизациям, когда мы выкидываем другие касания, считая их неэффективными и это приводит к падению показателей. Интереснее построить более сложную модель атрибуции, которая учитывает эти особенности. Например, многие пользователи читают ТЖ (Тинькофф Журнал), но напрямую продукты оттуда оформляет не так много людей, но это не значит, что информация из ТЖ не помогла людям в будущем стать нашими клиентами.

В общем, эта схема работает достаточно хорошо и большую часть указанных выше инструментов делали мои ребята последние 8 лет:) У этой системы несколько сотен пользователей со стороны заказчика, где маркетинговые команды внутри сервис-линии собраны по продуктовому признаку: маркетинг депозитных и расчетных продуктов, инвестиций, платежей и переводов, нефинансовых сервисов и так далее. А со стороны IT это несколько десятков человек, которые постепенно построили эту систему.

Get Alexander Polomodov’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Перечислю некоторых ключевых людей со стороны бизнеса и IT:

• Когда-то эту махину мы начинали строить с Кириллом Бобровым, который тогда был VP of Acquisition
• Потом на смену ему пришел Саша Лебединский, который является директором по развитию бизнеса и VP of Growth
• За онлайн-маркетинг у Саши отвечает Игорь Посталенко, который и был основным заказчиком этих систем
• На стороне IT за маркетинг и рекламу отвечает Кирилл Крайнев, технический директор этого управления
• Рекламные кабинеты делал Саша Гайдуков, руководитель отдела, которого еще я лет 6 назад брал на работу
• Ну и внутри есть еще сотни ребят, без которых мы бы не сделали все это. Спасибо ребятам за работу.

Мобильный банк (платформа)

Здесь из квази-продуктовой команды надо было делать платформу. Я рассказывал много раз и раньше, но самый сочный рассказ был на Highload ++ Spb 2022. Но для этого поста я сокращу его до кратких тезисов:

• До конца 2019 года Мобильный Банк Тинькофф рассматривался как самостоятельный продукт, который развивался и побеждал во всех рейтингах вида MarksWebb
• Команда была монолитной и со своими приоритетами, где фокус был на кредитных и дебетовых продуктах, а также лайфстайл сервисах
• Но в 2019 году компания решила, что Мобильный Банк должен стать супераппом, в котором представлены все бизнес-вертикали (из терминологии первого поста)
• В этой концепции мобильный банк должен был стать платформой, а точнее позволить продуктовым командам бизнес-вертикалей автономно разрабатывать свои фичи внутри приложения
• Для того, чтобы это работало надо было выделить платформенные команды, которые позволяли бы обеспечивать такие вещи как: согласованная архитектура приложения, общие инструменты для тестирования, сборки, производительности, надежности, дизайн решений

В момент перехода мы, фактически провернули обратный маневр Конвея, а точнее

• Уловили цели и задачи бизнеса
• Выяснили какая архитектура потребуется под их решение
• Выработали правильный оргдизайн команд, границы ответственности, процессы работы

Дальше мы несколько лет шли в сторону платформизации и сейчас все продуктовые команды мобильного банка и API уехали в свои бизнес-вертикали, а у меня в юните осталось управление разработки клиентских интерфейсов (УРКИ), в котором остались платформенные команды:) Я считаю, что это преобразование прошло успешно и мы достигли тех целей, которые ставили перед собой, когда запускали эти изменения. Подробнее почитать про этот кейс можно в моей статье или посмотреть видео-записи выступления.

P.S.

В общем про подходы формирования структуры команд под запросы бизнеса я рассказывал раньше в постах про

• Структуру команд
• Проектный подход
• Продуктовую разработку

А также рассказывал про это на конференции Yandex под конец 2023 года