Типовые организационные структуры
Мы уже говорили в первой части, что команда по работе с данными, как и другие функциональные отделы, – это компания внутри компании. Мы помним, что относительная новизна направления работы не позволяет руководителю пойти по проторенной дорожке организационной структуры более привычных отделов. С чего же начать? Вот основные вопросы, возникающие перед руководителем в процессе формирования отдела аналитики:
• Кому должен подчиняться отдел?
• Как он будет взаимодействовать с другими подразделениями?
• Должен ли он быть централизованным или встроенным в жизнь других отделов?
• Насколько большой должна быть команда? Сколько нужно инженеров, аналитиков, специалистов по данным?
• В чем заключается основная задача отдела: обслуживать процессы, происходящие в организации, или создавать свой отдельный продукт?
Однозначных правил не существует. Есть только примеры работы разных команд. Вы можете лишь найти похожий и адаптировать его под свой бизнес.
Оценка размера команды
Давайте разберемся, насколько большой должна быть команда для работы с данными? Зависит от тех задач, которые вам предстоит решать в своей компании. Как правило, от общего объема сотрудников количество специалистов по анализу данных должно занимать 5–10 %. Конечно, есть компании, которые имеют гораздо больший аналитический отдел, например, Ozon или «Яндекс. Маркет», но в среднем картина такова.
Повторюсь, на старте отдел может состоять из двух человек: аналитика и инженера. А дальше, по мере роста потребностей, вы сможете открыть другие позиции, увеличивая штат.
Виды аналитических отделов в компании
По типу взаимодействия с остальными подразделениями компании все аналитические отделы можно условно разделить на три большие группы: централизованные команды, распределенные команды и федеративные, состоящие сразу из нескольких команд. Рассмотрим плюсы и минусы каждой.
Централизованная группа по работе с данными
Обычно ее выбирают компании на старте своего пути к управлению данными. Суть модели:
• Единый отдел по работе с информацией, он обслуживает все проекты компании.
• Есть центральная база данных, доступная всем сотрудникам этого отдела.
• Командой управляет руководитель отдела данных.
Рис. 85. Централизованная модель управления
Преимущества централизованной модели:
• Руководитель отдела видит цельную стратегию развития компании и определяет приоритет работы над проектами.
• Он же может распределять задачи между сотрудниками, исходя из понимания возможностей, навыков и талантов каждого.
• Четкие границы должностей в отделе и прозрачный карьерный рост сотрудников.
• Команда может обслуживать другие подразделения, работая над собственными проектами и адаптируясь к потребностям растущего бизнеса.
Недостатки централизованной модели:
• Существует риск, что аналитическая группа превратится в бесполезную функцию: специалисты по работе с данными делают выводы, но другие отделы никак не применяют их в своей работе.
• Так как аналитики и инженеры данных не погружены в ежедневную жизнь других команд, они могут не увидеть актуальных проблем и заниматься второстепенными.
• Из-за вовлеченности одновременно в большое число направлений и проектов отдел может не успевать заниматься собственными задачами по развитию аналитической инфраструктуры.
Пример компании с такой моделью управления данными – Micron Technology. До 2015 года вся работа с данными в корпорации была децентрализованной и нерегулярной. Но после того как ИТ-директором стал Тревор Шульце, была создана центральная группа по работе с данными. Как говорил сам Шульце в интервью Forbes, «интегрированная аналитическая информация в масштабах всей компании – это важное конкурентное преимущество. Его создание требует усилий, но оно того стоит».
Децентрализованная, или встроенная модель
В этой модели каждое подразделение нанимает своих специалистов для работы с данными.
То есть отдельные аналитики и специалисты по данным концентрируются на задачах конкретного отдела – финансового, маркетингового и прочих – и мало взаимодействуют с коллегами из других подразделений компании. Соответственно, подчиняются они тоже только руководителям своих отделов.
Преимущества децентрализованной модели:
• Команда по работе с данными сосредоточена только на своих проектах и не распыляется на другие.
• Повышается результативность команды каждого отдела, так как специалисты уделяют все внимание только своему подразделению и досконально разбираются в его работе.
• Специалисты команды развиваются и повышают квалификацию в конкретных направлениях.
Рис. 86. Децентрализованная модель управления
Недостатки децентрализованной модели:
• Нет единого источника данных, единого хранилища, из-за чего информация может дублироваться в разных отделах.
• Поскольку нет связи между аналитиками разных подразделений, они могут ходить по кругу, решая раз за разом одни и те же проблемы.
• Порой непросто найти подходящего сотрудника по работе с данными для конкретного отдела.
Разберем на конкретном примере. В стартапе «Мед+» (портал и приложение с медицинским контентом) решили внедрить децентрализованную модель. Цель стартапа – помочь врачам в их работе: автоматизировать процесс создания карточки с информацией о пациенте.
Владельцы компании шли к децентрализации постепенно. Сначала они собрали общую команду аналитиков. Затем построили продуктовую вертикаль – это люди, которые отдельными группами занимаются разными частями продукта. После в каждую команду наняли дополнительных аналитиков. И только потом компания полностью перешла к системе отдельных модулей.
Есть другой пример – компания, занимающаяся аналитикой продаж. О ней рассказал руководитель сопровождения и трудоустройства «Яндекс. Практикум» Алексей Макаров в интервью для Smart Data. Алексей поделился опытом работы в CoMagic:
«Здесь изначально аналитики нанимались под конкретные направления: маркетинговую аналитику, продуктовую аналитику и так далее. Специалиста по данным также нанимали для определенного продуктового направления. Его непосредственным руководителем был продакт-менеджер. Получается, единой аналитической команды в компании не было».
Децентрализованная модель подходит компаниям со множеством разноплановых аналитических задач из непересекающихся областей.
Она фокусирует специалистов только на своей области ответственности, поэтому отлично подходит для организации с потребностью в разнородных данных.
Федеративная модель
Эта модель объединяет плюсы двух предыдущих и нейтрализует их минусы. Однако подходит она только для больших компаний с четкой стратегией обработки данных и прогнозной аналитикой.
В федеративной модели есть централизованная группа по работе с данными и отдельные специалисты, работающие в других бизнес-подразделениях.
Что делает руководитель группы:
• определяет приоритеты в работе;
• контролирует выполнение проектов;
• обучает сотрудников.
Благодаря такой модели компания может реализовывать выгодные проекты в области данных.
Пример компании с такой организацией аналитики – «Яндекс Go». Вот что говорит об этом руководитель команды визуализации данных Роман Бунин в интервью каналу Smart Data:
«В команде визуализации данных основной “солдат” – это фулстек-аналитик. Этот специалист может самостоятельно разобраться в “болях” и потребностях бизнеса, собрать и подготовить данные, обработать их на Python, построить модель и создать дашборд. Его суперсила – статистика, аналитика и понимание того направления бизнеса, которое они курируют. Например, есть аналитики, отвечающие за данные по продукту, логистике, маркетингу и тому подобное.
С технической частью им помогают инфраструктурные команды:
• команды внутренних инструментов,
• команда платформы управления данными,
• команда по визуализации.
В свою очередь эти группы выполняют следующие обязанности:
Команда визуализации (менеджер продукта и BI-разработчики) помогает аналитикам с дашбордами, консультирует и обучает, создает шаблоны и руководства по стилю, делает большие отчеты и отвечает за управление контентом.
Группа платформы управления данными (инженеры данных, системные инженеры, партнеры по данным) создает низкоуровневые витрины данных и инструменты по работе с ними.
Команды внутренней разработки (фронтенд-разработчики, ML-инженеры и другие) создает инструменты и модели прогнозирования, библиотеки для Python, платформы для A/Б-тестирования».
Как вы видите из слов Романа, в случае федеративной модели необходимо нанимать множество специалистов, и это речь шла только об отделе бизнес-аналитики. А еще есть большая команда ML-инженеров, специалистов по данным и аналитиков эффективности, которые разрабатывают алгоритмы диспетчеризации, балансируют маркетплейс, настраивают юнит-экономику и так далее.
Для вашего удобства я собрал плюсы и минусы всех моделей организации в одной таблице (рис. 87).
Рис. 87. Сравнение моделей организационных структур
И напоследок расскажу вам об опыте моей команды LEFT JOIN. Какие же специалисты трудятся у нас?
В основном мы работаем с различными digital- и мобильными стартапами, помогаем им выстроить аналитику «под ключ» (end-to-end). Другими словами, мы решаем целый спектр задач от проектирования хранилищ и озер и налаживания процессов инжиниринга данных до автоматизации отчетности, а иногда даже до разработки моделей машинного обучения.
У нас компактный штат сотрудников и соответствующих ролей. Поскольку команда работает параллельно с несколькими проектами, большая ее часть кросс-функциональна. В каждом проекте есть конкретный сотрудник, который ведет команду к достижению цели, а другие коллеги помогают ему, решая конкретные задачи.
Среди наших сотрудников:
• проджект-менеджер – управляет и координирует проекты по работе с данными;
• архитектор данных – отвечает за архитектуру хранилища на проектах;
• три инженера данных – строят хранилища, среди инструментов: Kafka, Airflow; среди СУБД: BigQuery, Redshift, Clickhouse, Redshift, Vertica, MySQL, разумеется, SQL и Python;
• инженер-аналитик – работает с инструментом dbt, строит модели данных в Looker, использует Python и SQL для обработки данных;
• ведущий аналитик данных – помогает заказчику определиться с аналитическими задачами и выстраивает работу аналитиков;
• три аналитика – владеют рядом инструментов в зависимости от потребностей и возможностей заказчика: Tableau, Looker, Redash, PowerBI и Metabase, также используют SQL. Ряд задач – например, построение классификационных моделей – в компании мы выполняем с использованием Python, Jupyter и в некоторых случаях Collab;
• два Junior Data Analyst – помогают старшим аналитикам и решают часть задач с тем же стеком технологий.
Теперь вы имеете представление о сегодняшних ролях в области работы с данными. И эта область стремительно расширяется, буквально на наших глазах появляются новые задачи, требующие новых специалистов с новыми навыками. Поэтому сегодня нельзя просто опубликовать вакансию с описанием «Требуется аналитик-универсал». Такой специалист вряд ли существует: найти компетентного во всех сферах работы с данными практически нереально. А на каждом этапе развития бизнеса вам будут нужны разные специалисты. И если ваша компания не слишком большая для целого аналитического отдела, то всегда есть выход в виде партнерских отношений с приглашенной командой-консультантом – например, LEFT JOIN.
У нашей консалтинговой компании большой штат аналитиков самых разных направлений. Мы сможем полностью погрузиться в вашу задачу и выбрать людей, которые выполнят ее с максимальной эффективностью. Поэтому, если прямо сейчас вам не нужен свой штат, обратитесь к грамотному консультанту.