Стратегия развития BI в компании

BI-система меняется вместе с компанией. С развитием бизнеса она обрастает процессами, ролями и механизмами контроля, становится более автоматизированной и всё больше работает на бизнес-цели.

Развитие аналитики в компании чаще всего проходит по такой модели:

Развитие аналитики в компании

Модель зрелости показывает рост аналитики от простых отчётов к прогнозам, а затем к рекомендациям и автоматическим решениям. Но у модели есть ограничение: она создаёт иллюзию, будто аналитика развивается строго линейно, на деле же разные типы аналитики не заменяют друг друга. Даже в самых зрелых компаниях не отказываются от ежедневных отчётов и анализа отклонений. Прогнозы и автоматические рекомендации дополняют эти инструменты, а не заменяют их.

Далее расскажем подробности про развитие операционной аналитики, а не аналитики компании целиком. Объясним, как именно она масштабируется, какие роли и практики появляются и как устроить систему дашбордов и доступов так, чтобы она работала в организациях разного масштаба.

Покажем, как меняется работа с дашбордами в компаниях разных размеров:

• Маленькая компания (1–15 пользователей данных). Аналитика держится на одном или двух специалистах или распределяется между сотрудниками. Фокус на быстрых ответах и базовой прозрачности: «Что произошло?» и первые разборы «Почему это произошло?».
• Развивающаяся компания (15–100 пользователей данных). Есть выделенные аналитики и роль BI-разработчика. Появляется систематизация: общие метрики, витрины и датасеты, единая структура контента и управляемые доступы.
• Большая компания (100–1000 пользователей данных). Аналитика становится продуктом для многих команд: усиливается инженерный фундамент (появляется контроль качества данных и более сложные ETL-процессы), вводятся песочницы и процессы изменений, появляются разные уровни доступа и масштабируемая навигация.
• Корпорация (более 1000 пользователей данных). Выделяются центры компетенций: BI и продуктовая аналитика, инженер данных. Дашборды публикуются при помощи подходов из разработки программного обеспечения — появляются релизные циклы, контроль версий и автоматические системы CI/CD — непрерывной интеграции и поставки.

Что меняется в процессе роста:

• Выделяются новые роли и растёт количество сотрудников, которые развивают и поддерживают операционную аналитику.
• Формируются фреймворки: стандартные подходы к разработке одного дашборда или системы дашбордов, регулярные процессы и сертификация.
• Контент становится организованным: появляются папки, навигация и версии отчётов.
• Модель доступа к данным расширяется: от простой передачи ссылок до полноценной системы прав и RLS (Row-level security, безопасность на уровне строк).

В первой главе мы отмечали, что BI-система — это продукт, который делится на составляющие: цели бизнеса, контент и процессы. Ранее мы много говорили про контент, но теперь подробнее остановимся на процессах вокруг BI-системы и проясним, какие из них стоит запускать на каждом уровне развития системы.

Категории процессов:

• работа с бизнес-пользователями;
• работа с аналитиками и разработчиками дашбордов;
• управление контентом;
• технические процессы;
• аналитика и стратегия вокруг BI-системы;
• организационная структура и роли.

Опишем каждую категорию по отдельности и приведём примеры, как меняются процессы.

Работа с бизнес-пользователямиРабота с бизнес-пользователями

Если смотреть на BI-систему глазами команды разработки, легко свести её к дашбордам, витринам, доступам и качеству данных. Но для бизнеса BI-система существует как рабочая среда, в которой нужно быстро найти информацию, правильно её интерпретировать и вовремя использовать в решениях. Поэтому зрелость бизнес-аналитики определяется не только качеством дашбордов, но и тем, насколько легко человеку войти в систему, разобраться в ней и получить помощь, если что-то пошло не так.

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

Каждый элемент пользовательской среды помогает сотрудникам быстрее разобраться в системе, начать пользоваться дашбордами и решать свои задачи без постоянного участия специалистов. Ниже разберём каждый формат отдельно.

Портал, или стартовая страница BI-системыПортал, или стартовая страница BI-системы

Портал BI-системы — это входная точка для пользователя. Она поясняет, что это за среда, какие дашборды в ней главные, как их искать, где читать определения и куда идти за помощью. Чаще всего это Wiki-страницы и пространство с ключевыми ссылками, описанием системы и материалами для входа.

Для начальных этапов подойдёт просто статичный список дашбордов с их пояснением. Но идеально, конечно, вшить такую страницу в саму BI-систему и обновлять её автоматически по каким-то правилам.

Посмотрите, как может выглядеть стартовая страница, сделанная внутри системы в DataLens. Вы можете сделать такой же портал с помощью шаблона из галереи.

Стартовая страница в DataLens

Онбординг бизнес-пользователейОнбординг бизнес-пользователей

BI-система может казаться интуитивно понятной тем, кто работает с ней каждый день. Но для нового сотрудника логика отчётов, структура данных и навигация часто оказываются неочевидными. Чтобы погрузить человека в рабочие задачи, стоит разработать онбординг и учебные материалы.

Сначала онбордингом может быть короткая инструкция или список ключевых дашбордов. Когда деталей становится больше, стоит добавить видео на 15–20 минут с основными инструкциями, как пользоваться системой: сохранять фильтры и закладки, искать дашборды и обращаться с вопросами. В крупных компаниях онбординг становится частью общего процесса адаптации: если сотруднику нужен BI-доступ, он автоматически получает стартовый пакет по работе с BI-системой.

В моей практике хорошо работали именно короткие форматы: Wiki-страницы с вводной информацией и видео, которые можно посмотреть в удобное время.

Материалы для онбординга лучше строить вокруг роли сотрудника. Маркетологам и продажникам объяснять, как работать с ключевыми для них метриками и отчётами. Операционным командам показывать данные и сценарии, которые нужны в ежедневной работе. Такой подход требует больше ресурсов: контент нужно не только создавать, но и регулярно обновлять. Упростить процесс помогает единая база знаний и данных. ИИ-инструменты помогут кастомизировать портал и автоматически подбирать полезные материалы, например, по количеству просмотров коллегами и руководителем.

В Яндекс Go мы делали такие эксперименты ещё до эпохи ИИ. На стартовой странице показывали, какие дашборды смотрят руководитель и коллеги. Так сразу становилось понятно, на что стоит обращать внимание в первую очередь.

Документация по дашбордам для бизнес-пользователейДокументация по дашбордам для бизнес-пользователей

Документация помогает пользователям понять, зачем нужен дашборд, какие вопросы он решает, как трактовать метрики, какие есть ограничения. Но разработка такой базы занимает время, а поддержка, обновление и синхронизация с дашбордом становится заметной нагрузкой на аналитиков. Результат работы часто не приносит пользы — сотрудники не заходят на страницы с документацией.

В Яндекс Go мы тоже прошли этот путь: сначала писали большие отдельные страницы с документацией, но на практике это работало плохо. Пользователи туда почти не заходили, описания быстро устаревали, а поддержка отнимала слишком много времени. В итоге стало понятно, что проблема не в самой документации, а в том, что она живёт отдельно от дашборда. Со временем мы оставили только самое важное: короткие описания прямо внутри дашборда и BI-системы.

В DataLens есть возможность делать описание на странице дашборда. Кнопка информации незаметная, лучше подсказать пользователям, где её искать.

Короткое описание дашборда

В текст можно добавить не только описание дашборда, но и формализованные определения метрик, логику расчётов, имена владельцев, источники данных и связи между объектами. Так подписи станут частью широкой системы управления данными (data governance).

На первых этапах развития BI-системы я бы рекомендовал оставить одну общую страницу с описанием всех дашбордов — она же может быть и стартовой страницей. Когда же количество пользователей системы станет больше 20–25, то стоит делать отдельные описания внутри каждого дашборда.

Сегодня написание документации можно автоматизировать. ИИ-инструменты умеют создавать описания по скриншоту или конфигурации дашборда и краткому контексту. Если подключить общую базу знаний, словари метрик и описания источников, результат получится ещё более качественным. ИИ-инструменты могут создавать документацию и обновлять текст, а за человеком стоит оставлять роль редактора и валидатора.

Словари метрик и источников данныхСловари метрик и источников данных

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

Словарь метрик появляется в дашбордах, справочных блоках и описаниях, но на деле он ближе к DWH (Data Warehouse, хранилище данных) и общей модели данных компании. Как только появляется информация о формуле расчёта, бизнес-логике, владельце метрики, источниках данных и правилах изменения определения, это выходит за пределы BI-команды. Здесь неизбежно пересекаются интересы аналитиков, BI-разработчиков, инженеров данных и иногда владельцев бизнес-процессов.

По мере развития аналитики в компании приходится определять, кто отвечает за словарь метрик и поддерживает его актуальным. В одних командах этим занимаются BI-специалисты, в других — аналитики или направление data governance, а иногда ответственность распределяется между несколькими ролями. Главное, чтобы у словаря были понятные владельцы, прозрачный процесс обновления и согласованные правила внесения изменений.

Когда компания ещё небольшая, достаточно собрать ключевые метрики и их описания внутри дашборда, рядом с ним или на отдельной странице в базе знаний. Если команда становится больше, словарь перестаёт быть частью только BI-контента и превращается в элемент общей работы с данными — появляются единые определения, владельцы метрик, связи с источниками данных и прозрачные правила расчёта.

Сейчас между BI-инструментами, системами data governance и системами хранения семантического слоя зачастую есть связи, но нет единого интерфейса, так как часто это всё равно разные продукты. Я верю, что в будущем появятся системы, связанные не только ссылками, но и общим интерфейсом. Например, если вы замените описание в словаре метрик или дата-каталоге, оно автоматически обновится и на дашборде.

В Yandex DataLens есть возможность добавлять подсказки внутрь графика или под него. Например, сделать всплывающие подсказки при наведении на знак вопроса для графика целиком или для отдельных колонок. Здесь удобно пояснить метрики и добавить описание.

Всплывающее окно с пояснением

Продвижение контента и уведомление об измененияхПродвижение контента и уведомление об изменениях

Дашборд с качественными данными бесполезен, если о нём никто не знает. BI-команды очень часто недооценивают эту проблему. Кажется,что если отчёт опубликован, пользователи сами его найдут, но в реальности это не так. Поэтому в зрелой BI-среде нужен отдельный процесс, чтобы продвигать контент и уведомлять пользователей.

Задачи продвижения контента:

• делиться новостями и полезными материалами: рассказывать про новые дашборды, улучшения, важные пересборки, новые словари, ключевые изменения в логике системы;
• управлять ожиданиями: объяснять, что изменилось, что переходит в архив, где теперь искать нужную информацию, почему поменялась метрика или интерфейс.

Если таких коммуникаций нет, пользователи либо продолжают работать с дашбордами, как привыкли, либо сталкиваются с изменениями и теряют доверие к системе.

Рассказывать об изменениях можно через регулярные дайджесты, чаты с анонсами, демодни, короткие встречи с показами новых отчётов, выступления на командных встречах, рассылки по доменам. Решение о формате остаётся за компанией, но важно, чтобы у BI-команды была зафиксирована коммуникационная политика. Должны быть понятные ответы на вопросы: что анонсирует команда, когда, кому и в каком формате и кто отвечает за процесс оповещения.

Пример коммуникаций об изменениях системы

Поддержка и обработка обращенийПоддержка и обработка обращений

Поддержка — это механизм, который помогает пользователю не остаться один на один с системой в момент, когда что-то становится непонятным. На раннем этапе она почти всегда работает неформально: сотрудник пишет в чат, аналитик отвечает, проблема решается. Когда система разрастается, пользователю нужен понятный сценарий: куда обратиться, если он не может найти дашборд, не понимает метрику, видит непривычные показатели или сталкивается с технической проблемой.

Типы обращений условно можно разделить на три категории:

• навигационные: где найти нужную метрику или дашборд;
• смысловые: как интерпретировать показатель и почему он выглядит именно так;
• технические: проблемы с доступом, обновлением данных, фильтрами или загрузкой дашборда.

Когда BI-команда начинает разделять такие запросы, поддержка становится эффективнее. Пользователь быстрее получает помощь, а аналитики замечают повторяющиеся проблемы. Например, оказывается, что дашбордом не пользуются из-за проблем с навигацией, а не из-за качества данных.

Поддержку полезно выстраивать поэтапно. На первых порах достаточно одного канала, например общего чата для вопросов. В зрелой среде стоит фиксировать владельца процессов, приоритеты обращений, шаблоны ответов и базу знаний с типовыми вопросами. Со временем поддержку можно перенести в тикет-систему.

Я рекомендую сохранять и чат, и тикеты. Создание тикета для бизнес-пользователя часто воспринимается как долгий и формальный процесс. Из-за этого появляется ощущение, что помощь придётся ждать долго. Сообщение в чате работает иначе: пользователь сразу понимает, что его услышали и проблемой уже занялись. Даже если дальше запрос всё равно превращается в тикет.

В крупных компаниях поддержка обычно строится на системе дежурств по доменам. Аналитики внутри отдельных направлений помогают пользователям сами, а более сложные проблемы передают в центральную службу.

Хорошая практика — размещать информацию о поддержке внутри дашборда: например, указывать контакт, чат или форму для обращения. Для начала контактным лицом может быть автор отчёта, но по мере развития системы обработку обращений лучше перевести из личной коммуникации с аналитиком в централизованный процесс.

Алерты и оповещения о сбоях, задержках и проблемахАлерты и оповещения о сбоях, задержках и проблемах

Даже в хорошо выстроенной BI-среде случаются задержки обновления данных, сбои источников, частичные ошибки и временные ограничения. Такие ситуации невозможно исключить полностью, но можно влиять на то, как система реагирует в момент их возникновения. Если пользователь узнаёт о проблеме случайно, это быстро подрывает доверие не только к конкретному дашборду, но и к BI-системе в целом. Если заранее настроить автоматические алерты и сообщать о сбоях или ограничениях, это сохранит доверие.

Уровни алертов:

• системные, например, сообщение о задержке в обновлении набора данных для всей компании;
• доменные, например, если проблема касается определённого направления бизнеса;
• пользовательские, например, уведомления о подписке или предупреждения для владельцев ключевых отчётов.

В начале развития компании достаточно ручного сообщения в чате или уведомлений на стартовой странице. Когда BI-среда растёт, оповещения стоит связывать с конкретными источниками данных, доменами и ответственными командами. В зрелой среде они становятся частью общей операционной модели BI.

На практике лучше встраивать оповещения в привычную пользовательскую среду. Например, показывать предупреждения на BI-портале, дублировать их в чат поддержки, отправлять владельцам затронутых доменов и отображать статус рядом с дашбордом. Тогда пользователю не нужно гадать, это локальная проблема или известный инцидент, — система сама даёт ответ.

Пример уведомления о проблеме

Как процессы меняются с ростом компанииКак процессы меняются с ростом компании

В таблице ниже собрали процессы вокруг бизнес-пользователей и показали, как они меняются с ростом компании. Посмотрите, какие практики полезно внедрять уже в небольших командах, а какие становятся актуальными на более зрелом этапе развития BI-системы.

Блок	Маленькая компания (1–15 пользователей)	Развивающаяся компания (15–100 пользователей)	Большая компания (100–1000 пользователей)	Корпорация (1000+ пользователей)
Портал, или стартовая страница BI-системы	Желательно: простая стартовая страница со списком ключевых дашбордов	Обязательно	Обязательно	Обязательно, с поиском, навигацией, владельцами и статусами
Онбординг бизнес-пользователей	Желательно: короткий созвон или инструкция	Обязательно	Обязательно	Обязательно, стандартизированный
Документация по дашбордам для бизнеса	Базовая, для ключевых дашбордов	Обязательно	Обязательно, с единым стандартом	Обязательно, с единым стандартом и связью с каталогом данных и другими системами
Словарь метрик и источников данных	Базовый список ключевых метрик	Базовый список ключевых метрик	Обязательно	Обязательно, с системой управления и владельцами
Коммуникация об изменениях в контенте	Точечно, вручную	Обязательно: чат, рассылка или анонсы	Обязательно: регулярные процессы	Обязательно: формальная коммуникационная политика
Поддержка бизнес-пользователей	Обязательно, но неформально	Обязательно	Обязательно, с понятным каналом	Обязательно, с операционной моделью, SLA или приоритетами
Алерты о сбоях, задержках, проблемах с данными	Базовые, для критичных дашбордов	Желательно	Обязательно	Обязательно, системно, с SLA на решение проблем

Работа с аналитиками и разработчиками дашбордовРабота с аналитиками и разработчиками дашбордов

Процессы для бизнес-пользователей помогают удобно работать с BI-контентом, а процессы для аналитиков и разработчиков дашбордов позволяют производить контент. Небольшим компаниям достаточно нанять сильных аналитиков и поделиться инструментом. Но когда команда растёт, оказывается, что даже сильный аналитик не может закрывать все задачи сразу: готовить данные, разбираться в бизнес-контексте, проектировать дизайн, визуализировать выводы, поддерживать единый стиль и следить за качеством данных.

Обучение и онбординг аналитиковОбучение и онбординг аналитиков

Процесс похож на работу с бизнес-пользователями, но здесь фокус не на потреблении, а на производстве BI-контента. Аналитиков стоит обучать не только работать с конкретным инструментом, но и понимать базовые принципы дизайна и собирать требования у заказчика.

В небольших компаниях обучением может быть набор вводных сессий и разборов от внешних консультантов или энтузиастов из компании. На более зрелом уровне — регулярная учебная программа с целями и расписанием.

В моём опыте наиболее устойчивый эффект давало обучение по трём блокам: инструмент, визуализация и сбор требований. В Яндекс Go было около 200 аналитиков, мы проводили учебные сессии примерно раз в квартал. Сначала это были большие учебные курсы про инструмент и дизайн — эти курсы мы записали и включили в онбординг, а вживую вели лекции только раз в год. Вместо больших курсов стали проводить короткие практические воркшопы: за 2–4 часа можно было освоить один конкретный навык и сразу применить его в своей работе.

Онбординг строится по той же логике, что и у бизнес-пользователей: новому человеку нужно объяснить, как устроена система, где лежат основные материалы, по каким правилам команда работает и к кому можно прийти с вопросом. Отличается только содержание. Аналитику важно понять стандарты публикации, структуру папок, шаблоны, правила именования, принципы сертификации, требования к качеству и доступные каналы поддержки.

Пример курса для разработчиков

Информирование об изменениях, новых функциях, политиках и правилахИнформирование об изменениях, новых функциях, политиках и правилах

Если BI-система развивается, то меняется контент и правила его использования. Появляются новые функции, шаблоны, ограничения, стандарты, процессы публикации и требования к качеству. В зрелой BI-среде нужна коммуникационная политика для авторов дашбордов, чтобы аналитики напрямую узнавали об изменениях.

На практике рассказать об изменениях можно через чат, внутренние рассылки, страницы с обновлениями, демонстрации новых возможностей, короткие разборы изменений и встречи по сложным нововведениям.

Стайлгайд и шаблоныСтайлгайд и шаблоны

Стайлгайд — это инструмент для масштабирования BI-практики, в котором указаны основные правила работы и оформления дашбордов.

Основные разделы стайлгайда:

• Презентация с рекомендациями по типографике, цвету, структуре экранов, логике визуализации и базовым правилам оформления.
• Wiki с инструкциями, видео и FAQ, которые позволяют быстрее погрузиться в работу системы.
• Шаблон дашборда с готовыми компонентами, расчётами и паттернами. Шаблон делает стайлгайд особенно полезным: переносит рекомендации из теории в практику.

Cтайлгайд снижает стоимость и время производства качественного дашборда и сокращает количество типовых ошибок. Он экономит ресурсы аналитика и помогает быстрее получать хороший результат. Внутри могут быть шаблоны элементов и их расположений, встроенные словари, готовые блоки KPI и примеры графиков. Это эффективнее, чем обычный список правил.

Пример содержания стайлгайда

Стандартизация процессов наймаСтандартизация процессов найма

Как только BI становится отдельной значимой функцией, компания упирается в вопрос найма. Поток подходящих кандидатов сужается, если ожидать, что каждый аналитик будет одинаково разбираться в SQL, исследовательской аналитике, проектировании интерфейсов, визуализации, управленческой отчётности.

В моём опыте это было одной из причин, почему появилась отдельная роль BI-аналитика — человека, который глубже специализируется на отчётности, дашбордах и работе с BI-контуром. Такой шаг не только улучшает качество контента, но и делает наём реалистичнее, потому что компания начинает искать не абстрактного сверхчеловека, а специалиста с понятным профилем.

Стандартизация найма помогает компании договориться, какие роли необходимы для системы. Так подключение новых сотрудников становится более предсказуемым: если профиль роли описан чётко, легче строить обучение, оценивать сотрудника и развивать его. На зрелом уровне обычно есть разные профили для BI-аналитиков, аналитиков данных и иногда BI-разработчиков — у них есть пересечения, но не полное совпадение навыков.

На первой сессии стоит проверить навыки BI-аналитика. Сначала оценить базовую работу с данными и инструментами — можно использовать простые прикладные задания и попросить в моменте написать SQL-запрос, посчитать метрику или собрать простой график. Важно посмотреть, как человек думает, ориентируется в данных и проверяет себя.

Затем можно перейти к оценке навыков дизайна и визуализации. Например, дать кандидату готовый дашборд и попросить разобрать его: найти ошибки, предложить улучшения и обосновать их.

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

У большинства BI-аналитиков до сих пор нет портфолио. Хотя это, по сути, одна из немногих аналитических ролей, где результат работы можно показать, ведь есть дашборды, графики и интерфейсы. Наличие портфолио — важный сигнал. Если сотрудник собрал примеры работ, это значит, что он умеет не только считать, но и доводить результат до пользователя. Особенно показательно, если портфолио содержит связку «бизнес-задача — результат».

Помимо технических сессий должна быть управленческая часть — интервью с руководителем и с ключевым бизнес-заказчиком. Это позволяет проверить, насколько человек вписывается в контекст: умеет ли коммуницировать, понимать запрос, договариваться о приоритетах и работать с людьми.

Тестовые задания лучше работают для начинающих специалистов. Для сильных кандидатов это становится лишним этапом, оно требует много времени с обеих сторон и редко даёт больше информации, чем интервью. Если есть портфолио, технические и продуктовые сессии проходят гладко, то тестовое задание может не пригодиться.

Как-то я проводил два мок-интервью на позиции BI-аналитика. Вы можете посмотреть их на YouTube, чтобы понять логику вопросов: запись с Тимуром и запись с Дмитрием.

Стандартизация матрицы компетенцийСтандартизация матрицы компетенций

Матрица компетенций формализует, что компания считает сильной работой в BI. Пока команда небольшая, нет объективной системы оценки. И когда компания растёт, сотрудники не понимают, чего от них ждут, руководители по-разному оценивают одинаковую работу, а развитие BI-роли остаётся непрозрачным.

Матрица компетенций позволяет внести ясность и разложить BI-роль на составляющие: работа с требованиями, понимание данных, визуальное мышление, владение инструментом, качество сборки, взаимодействие с пользователями, умение поддерживать стандарт и развивать среду вокруг себя. Особенно важна такая матрица для BI-аналитиков, потому что их ценность часто лежит на пересечении нескольких навыков и не подходит только под технические критерии.

Важно следить, чтобы матрица соответствовала текущим стандартам и инструментам компании. При необходимости дополняйте и обновляйте её. Составить матрицу можно в формате описания, чек-листа или формы самооценки, когда аналитик самостоятельно оценивает свои навыки.

Ниже пример матрицы компетенций, которую я составлял для нашей команды. В каждом разделе есть ссылки на теорию, которая поможет развить эти навыки. Самооценка сотрудников и моя оценка по этой матрице совпадали на 80%. Конечно, нельзя полагаться только на эту таблицу, но она может быть начальной точкой для обсуждения плана развития сотрудников. Вы можете сохранить себе копию Google Документа и использовать его при оценке своих сотрудников.

Пример матрицы компетенций

Ниже — сводная таблица навыков по сотрудникам.

Матрица навыков

Можете посмотреть матрицы компетенций других компаний, например Авито.

Система мотивации и оценка работыСистема мотивации и оценка работы

При оценке BI-аналитика стоит учитывать производительность и качество созданной среды: используются ли его дашборды, доверяют ли им, насколько они обновляются, как сотрудник влияет на стандарты внутри команды, помогает ли коллегам, улучшает ли существующий ландшафт.

Эффективность можно измерить по метрикам:

• используемость дашбордов;
• оценка качества со стороны бизнес-пользователей;
• соответствие результатов работы стандартам (например, количество сертифицированных дашбордов);
• процент просмотров, приходящихся на сертифицированную отчётность.

Не стоит оценивать BI-аналитиков только по количеству выпущенных дашбордов. BI-система приносит пользу благодаря качеству данных, а не количеству отчётов.

Если в компании уже есть система мотивации, то стоит включить в неё специфичные пункты для BI-аналитиков.

Одна из проблем, с которой я столкнулся, — это калибровка сотрудников после их ревью. Такой процесс часто существует в больших компаниях, когда раз в полгода или год на каждого сотрудника собирается обратная связь от коллег, а после этого их работа сравнивается. У меня в команде было два BI-аналитика, а их работу сравнивали с работой аналитиков данных. Когда мои коллеги говорили: «За счёт проведения этого A/B-теста мы сэкономили компании XXX млн рублей в год», я мог только сказать только: «А мы сделали пять важных дашбордов, их часто смотрят, но как посчитать выгоду — непонятно». Такие защиты проходили сложно, потому что не было критериев, чтобы оценить работу BI-аналитика. Когда мы внедрили выделенные KPI для BI-направления и стали сравнивать работу с другими командами, процесс стал проще и справедливее.

Создание комьюнити BI-аналитиковСоздание комьюнити BI-аналитиков

Если в компании растёт количество аналитиков, становится полезна не только методология, но и профессиональная среда. Без неё экспертиза быстро распадается по командам: каждый решает похожие задачи по-своему, ошибки повторяются, находками не делятся, а аналитики чувствуют себя изолированно.

В моём опыте для BI-аналитиков выстраивали горизонтальное сообщество: специалисты работали в доменных командах, но при этом оставались частью общей практики — встречались, обменивались опытом и опирались на единые подходы.

Такое комьюнити работает на создание профессиональной идентичности. BI-аналитик становится частью отдельной экспертизы внутри компании. Регулярные встречи, обсуждения спорных кейсов, внутренние конференции, разборы удачных решений и обмен шаблонами помогают этой экспертизе расти быстрее и не зависеть только от централизованной команды.

Мы проводили такие встречи раз в две недели и называли их «книжным клубом» — одной из идей было обмениваться опытом и вместе читать статьи и книги или смотреть записи конференций. Каждый раз кто-то из участников клуба готовил небольшую презентацию на 20 минут про свою работу, интересный технический приём или историю неудачи. Ещё на этой встрече мы делились новыми правилами, изменениями в системе, матрице компетенций и стайлгайде.

Комьюнити нужен лидер, который заранее продумывает форматы, повестку встреч и выступлений от коллег. Встреча может проходить даже в формате «прожарки», когда BI-аналитики получают обратную связь по своим дашбордам. Здесь важно сохранять баланс между критикой и советами.

Вот пример прожарки, где я участвовал в одной из таких встреч для Т-Банка и сразу переделывал дашборд коллег.

Конкурсы, хакатоны и демодниКонкурсы, хакатоны и демодни

Другие форматы для развития команды — внутренние конференции, конкурсы и хакатоны. Участвовать в таких интерактивах могут не только аналитики, но и бизнес-пользователи, например, как жюри при выборе лучшего дашборда для смежных подразделений. Такие мероприятия повышают видимость работы BI-аналитиков для всей компании, ведь часто их работа остаётся незамеченной.

Мы проводили конкурсы и внутренние мини-конференции, эти форматы очень нравились коллегам. Для таких мероприятий можно заручиться поддержкой HR-команды и получить мерч в качестве подарка. А вот с хакатонами стоит быть аккуратными: они дают сильный буст по идеям, но проекты редко доводят до конца — это может разочаровать участников.

Поддержка и обработка обращенийПоддержка и обработка обращений

Процесс похож на поддержку бизнес-пользователей, но здесь запросы чаще относятся к производству контента. Аналитикам нужна помощь с публикацией, шаблонами, расчётами, доступами и не только. На раннем этапе достаточно чата и помощи от коллег, на зрелом нужен выделенный контур поддержки и консультаций.

Можно попробовать формат Office Hours, когда есть выделенное время для запроса помощи. Коллеги из Яндекс Маркета даже предоставляли кабинет в офисе на целый день — там можно было попросить совета или просто поработать рядом с другими BI-аналитиками. Это сплачивает сотрудников, особенно если они работают в разных доменах и чаще видятся со своими коллегами по бизнес-направлению, а не по типу работы.

Как процессы меняются с ростом компанииКак процессы меняются с ростом компании

Блок	Маленькая компания (1–15 пользователей)	Развивающаяся компания (15–100 пользователей)	Большая компания (100–1000 пользователей)	Корпорация (1000+ пользователей)
Обучение аналитиков BI-инструменту и базовым принципам	Желательно	Обязательно	Обязательно	Обязательно
Онбординг	Базовый, одна страница с информацией	Обязательно	Обязательно	Обязательно, стандартизированный
Регулярное обучение новым навыкам	Пока не обязательно	Желательно	Обязательно	Обязательно, с программами и треками
Коммуникация об изменениях системы	Неформальная	Желательно	Обязательно	Обязательно
Стайлгайд и шаблоны	Желательно: хотя бы 1–2 шаблона	Обязательно	Обязательно, с контролем соблюдения	Обязательно, с контролем соблюдения
Стандартизация процессов найма	Пока не обязательно	Желательно	Обязательно	Обязательно
Стандартизация матрицы компетенций	Пока не обязательно	Желательно	Обязательно	Обязательно
Система мотивации и оценки BI-аналитиков	Пока не обязательно	Необязательно	Желательно	Обязательно
BI-комьюнити, встречи, внутренние конференции	Необязательно	Желательно	Желательно	Обязательно
Конкурсы, хакатоны, демодни	Необязательно	Желательно	Желательно	Обязательно, регулярно
Поддержка и обработка обращений	Обязательно, но неформально	Обязательно	Обязательно	Обязательно, с выделенным владельцем

Управление контентомУправление контентом

На ранних этапах компании сохраняют фокус на создании дашбордов: запросов много, команда активно занимается производством, а контент ещё только собирается. В более зрелых командах BI-система живёт не только за счёт создания, но и благодаря постоянному управлению ландшафтом. В какой-то момент отчётов, папок и разовых исследований становится столько, что BI начинает деградировать, если нет отдельной системы управления контентом. Так случается даже при хорошем уровне аналитиков и платформы.

Это особенно заметно в больших организациях. Контент создают разные люди, в разное время, под разные задачи и для разных уровней управления. Артефактов оказывается так много, что система становится слишком сложной и ориентироваться в ней не получается.

Управление устаревшими дашбордамиУправление устаревшими дашбордами

Почти в любой BI-системе накапливаются отчёты, когда-то полезные, но теперь неактуальные. Они занимают место не только в папках, но и в голове пользователей. BI-среда становится визуально и логически перегруженной, а найти важный дашборд становится сложнее.

Зрелая система должна уметь отслеживать неактуальный контент и снимать его с использования. Это можно делать по-разному: архивировать, помечать как deprecated, скрывать из основной навигации, переносить в отдельный слой исторического контента или удалять, если отчёт явно больше не нужен. Главное, чтобы устаревшие дашборды отсматривали системно и это стало отдельным процессом.

В Яндекс Go у нас было правило: если дашборд не открывали более 45 дней, сначала в нём останавливали обновление данных, и сообщение об этом приходило аналитику. Если в дашборд не заходили ещё 45 дней, то дашборд перемещали из папки, доступной бизнес-пользователям, в папку с архивом. Этот процесс работал автоматически, сообщения приходили на почту создателю дашборда.

Названия дашбордов, источников и компонентовНазвания дашбордов, источников и компонентов

Деталь, которая кажется незначительной, но сильно влияет на навигацию и доверие к системе, — названия. Если на сервере лежат объекты вроде sales_v2_final_new, test_kpi_copy или dashboard_temp_march, никакой поиск и никакая структура папок не помогут.

Невозможно придумать единственно верные правила наименования, но стоит сформулировать общее направление, понятное команде. Название должно быть конкретным, но не слишком подробным. Домен, дату создания и ответственного можно указать в полях метаданных для дашборда — по ним должен работать поиск и фильтрация. Если занести эти детали в название, оно станет шумным и никак не поможет восприятию.

Сертификация дашбордовСертификация дашбордов

В моём опыте сертификация была ключевым способом навести порядок в системе. Хороший дашборд должен соответствовать нескольким критериям: быстро открываться, иметь метаданные и понятного владельца, быть корректно оформленным.

Если сделать сертификацию бюрократической процедурой, аналитики начнут обходить процесс, и это станет узким местом. Можно проводить проверку, когда аналитик публикует отчёт в папке для пользователей — тогда централизованной команде BI приходит уведомление о новом отчёте, автоматически создаётся тикет в системе управления проектами со ссылкой на дашборд. В тикете есть чек-лист для проверки отчёта — важно, чтобы он был не универсальным, а зависел от типа отчёта.

Для аналитических отчётов, A/B-тестов или краткосрочных исследований использовался облегчённый набор проверок. Для overview-отчётов, страниц объектов управления и self-service-дашбордов нужен более строгий процесс проверки. Например, расширенный чек-лист с большим количеством критериев.

Чек-лист для проверки отчёта:

• Дашборд соответствует утверждённому стайлгайду и использует лучшие практики визуализации.
• Название дашборда соответствует принятым правилам наименования.
• Названия листов, вкладок и метрик консистентны и понятны пользователю.
• Все источники данных в дашборде проверены старшим аналитиком.
• Методы расчёта метрик валидированы и согласованы.
• Доступы настроены корректно через группы пользователей. Отсутствуют индивидуальные доступы без явного обоснования.
• В дашборде настроена RLS, если отчёт используется операционными или линейными менеджерами.
• Дашборд открывается менее чем за 15 секунд.
• Заполнены все обязательные метаданные: владелец, тип дашборда, департамент.
• Добавлено описание дашборда с пояснением его назначения и способа использования.

Даже при наличии чек-листа проверка не проходит полностью автоматически. Важно проверить качество дашборда через логику и смысл. Сотрудник, который проводит ревью, следит, чтобы дашборд был корректным с точки зрения бизнеса — отражал реальную картину, был понятным и помогал принимать решения. Часть задач можно автоматизировать: проверять наличие описания, заполненность метаданных, корректность настроек доступов или скорость загрузки дашборда.

Когда централизованной BI-системы ещё нет, как правило, дашборды проверяет руководитель аналитика. Когда BI-функция развивается, появляется централизованная команда и ответственность переходит к ней. Проверка становится регулярным процессом — её выполняют сотрудники BI-команды с нужной экспертизой и пониманием стандартов. Должно быть SLA на проведение проверки с обеих сторон: BI-команда вовремя делает проверку, а аналитик оперативно отвечает на замечания, если они есть.

Пересмотр состава контента по доменамПересмотр состава контента по доменам

В зрелой BI-системе управляют набором дашбордов внутри доменов. Можно иметь хорошие процессы на уровне каждого конкретного отчёта, но при этом получить перегруженную и плохо устроенную систему в целом: слишком много похожих дашбордов, дубли по метрикам, которые считаются по-разному, и так далее.

В Яндекс Go за каждым направлением закрепляли BI-аналитика, который отвечал за свою папку — домен. Каждые полгода мы проводили регулярный пересмотр папки по чек-листу, который частично повторяет чек-лист для одного дашборда, но ещё проверяет важные моменты для целой папки.

Критерии оценки отчёта по доменам:

• С бизнес-заказчиками обсудили необходимость каждого отчёта, который смотрят менее трёх пользователей в неделю.
• Если для отчёта требовалось более пяти персональных доступов, их объединили в групповые роли.
• Все названия отчётов соответствуют правилам названий.
• У каждого отчёта есть актуальное описание на русском и английском языках. Отчёт сделан на английском языке или понятно, почему он сделан на русском.
• У всех отчётов указан их тип. В папке есть баланс по типам: хотя бы один overview-отчёт, один self-service-отчёт и так далее.
• Во всех отчётах используются технические учётные записи для доступа к данным.
• Проверено, что данные обновляются с нужной частотой и обновления проходят без частых сбоев.
• Нет отчётов, которые грузятся более 15 секунд.
• Отчёт с худшим отношением просмотров и скорости загрузки передали команде визуализации данных.
• Самый популярный тип отчёта для скачивания — self-service. Если у отчёта другого типа больше скачиваний, проведено исследование, зачем пользователи выгружают данные.
• По каждому отчёту в папке пользователи получили информацию о том, для чего он нужен и как его использовать.
• Для основных отчётов подразделения проставлен тег promote.
• Есть план развития папки, заполнены основные роли, процессы и метрики подразделения.

Управление доступамиУправление доступами

Пока пользователей мало, права часто выдаются вручную и через личные договорённости. Как только BI-система начинает масштабироваться, доступы становятся частью корпоративного контроля, безопасности и доверия к данным.

Зрелая модель управления доступами должна отвечать на вопросы:

• На каком уровне выдаются права — дашборд, папка, проект, группа?
• Кто согласует доступ?
• Как пересматриваются старые права?
• Где хватает обычного разграничения по ролям, а где нужен более тонкий уровень — например, ограничение по строкам данных?
• Кто отвечает за то, чтобы лишние доступы не сохранились у уволенных сотрудников или тех, кто сменил роль?

Управление доступами должно развиваться вместе с компанией. Чем больше бизнес-процессов и пользователей, тем более развитой должна быть эта система. На ранних этапах доступы выдаются индивидуально вручную. Такой подход плохо масштабируется и часто приводит к ошибкам и отсутствию полного контроля.

Следующий этап — доступы через папки. Дашборды группируются по тематикам или функциям, например «маркетинг», «финансы» или «продукт». Пользователи получают доступ к разделам в соответствии со своей функцией. Так структура становится более понятной.

Когда бизнес-процессы становятся сложнее, возникают кросс-функциональные сценарии: например, сотруднику из маркетинга нужен доступ к отдельным финансовым отчётам, но не ко всем. Снова появляется точечная выдача доступов, что возвращает систему к прежним проблемам.

Зрелый этап — переход к ролевой модели и доступам через группы. В системе создаются группы пользователей, которые, как правило, отражают организационную структуру или роли в компании. Доступы назначаются не отдельным пользователям, а этим группам — как на уровне папок, так и на уровне конкретных дашбордов.

При дальнейшем росте важным становится сам процесс выдачи доступов. На базовом уровне он может быть реализован через систему тикетов: пользователь запрашивает доступ, и ответственный подтверждает или отклоняет его. В более зрелой системе это должно быть интегрировано в решения IdM (Identity Management, управление идентификацией), где процесс согласования автоматизирован: система сама определяет согласующих, отправляет им запросы и фиксирует решения.

Среды production и sandboxСреды production и sandbox

Важный элемент управления доступами — разделение сред production и sandbox. Production — это рабочая версия программного обеспечения или сервера, с которой взаимодействуют пользователи. Sandbox — это изолированная виртуальная среда для безопасного тестирования, разработки или запуска программ. Разделение этих сред позволяет чётко отделить незавершённый, экспериментальный контент от проверенных и сертифицированных дашбордов, предназначенных для использования бизнесом.

Полезно организовать индивидуальные sandbox-среды для аналитиков. У каждого из них будет своя выделенная область, где он сможет создавать драфты дашбордов, тестировать гипотезы и при необходимости временно делиться результатами с пользователями. Важно контролировать использование sandbox-среды, чтобы она не превращалась в альтернативную production. Если этого не делать, в sandbox начинают накапливаться отчёты, которые используются бизнесом, но не проходят полноценную проверку.

Один из рабочих подходов — регулярный пересмотр доступов. Например, в Яндекс Go мы автоматически отзывали доступы пользователей к дашбордам в sandbox каждые 10 дней. В таком случае, если отчёт действительно нужен, пользователь либо заново запрашивает доступ, либо становится очевидно, что дашборд следует перевести в production.

Альтернативный вариант — создать sandbox на уровне доменов или команд. Однако такой подход чаще приводит к потере контроля и накоплению хаотичного контента. Используйте его в относительно небольших системах, где объём дашбордов пока ограничен и управляем.

Как процессы меняются с ростом компанииКак процессы меняются с ростом компании

Блок	Маленькая компания (1–15 пользователей)	Развивающаяся компания (15–100 пользователей)	Большая компания (100–1000 пользователей)	Корпорация (1000+ пользователей)
Документация по работе с системой	Базовая	Обязательно	Обязательно	Обязательно
Управление устаревшими дашбордами	Желательно	Обязательно	Обязательно	Обязательно, с формальным управлением жизненным циклом
Правила наименования контента	Желательно	Обязательно	Обязательно	Обязательно
Сертификация дашбордов	Необязательно	Желательно для ключевых	Обязательно	Обязательно
Регулярный пересмотр состава контента по доменам	Необязательно	Желательно	Обязательно	Обязательно
Управление доступами	Базовый уровень: вручную, по ссылке или папке	Обязательно: папки, личные доступы	Обязательно: папки, группы, роли	Обязательно: матрица прав, регулярное ревью, RLS, где нужно
Построение Dashboard Map для подразделений	Желательно для ключевого направления	Обязательно для важных доменов	Обязательно	Обязательно
Разделение сред: sandbox и production	Необязательно	Необязательно	Желательно	Обязательно

Технические процессыТехнические процессы

Техническая доступность дашбордов — это фундамент BI-системы, который часто остаётся невидимым, пока что-то не выходит из строя. На определённом масштабе BI-команде приходится выстраивать технический контур с мониторингом, эксплуатационными практиками, архитектурными ревью и понятной реакцией на инциденты. Этот контур не всегда нужен в полном виде с самого начала, но по мере роста компании необходимость в нём растёт.

Отслеживание загрузки BI-системыОтслеживание загрузки BI-системы

Важно контролировать доступность платформы и уделять внимание деталям: какие дашборды загружаются медленно, какие обновления данных завершаются с ошибками, как распределяется нагрузка по дням и часам, какие домены создают наибольшую нагрузку на систему.

Пока эти показатели не измеряются, BI-команда почти всегда опирается на искажённую картину. Отсутствие явных жалоб не означает, что система работает хорошо: пользователи могут адаптироваться к медленной работе или не обращаться в поддержку, если дашборд не загрузился, а решать задачу другим способом. Проблема остаётся незаметной, но влияет на ценность всей BI-системы.

Первый шаг к стабильной работе — внедрение технического мониторинга. Если система развёрнута и поддерживается внутри компании, стоит настроить полноценное наблюдение за её состоянием. Как правило, для этого используются системы наблюдаемости — observability-платформы, например Grafana.

Если BI-система работает в облаке, это не означает, что мониторинг можно полностью делегировать провайдеру. Важно, чтобы провайдер давал инструменты для мониторинга системы. DataLens, например, позволяет создать техническое подключение, которое помогает отслеживать процент ошибок в запросах и время их исполнения. Подробности этого процесса можно изучить в документации DataLens.

Пример мониторинга в DataLens

Разработка и пересмотр архитектурыРазработка и пересмотр архитектуры

На ранних этапах развития компании используют облачную или управляемую (managed) версию BI-платформы. Это позволяет быстро начать работу без существенных инфраструктурных затрат. Позднее требования к системе усложняются, появляется необходимость в продвинутых архитектурных решениях: переносе BI-сервиса во внутренний контур, настройке сетевой изоляции, внедрении дополнительных механизмов безопасности, организации резервных копий и так далее.

Отдельный важный аспект — обеспечение отказоустойчивости. В случае on-premises или гибридных решений это может означать размещение сервисов в нескольких дата-центрах или зонах доступности, чтобы система продолжала работать даже при отказе одной из площадок. В облачной архитектуре это реализуется через подходы multi-zone или multi-region.

Такие решения требуют уже не только BI-экспертизы, но и полноценной инженерной компетенции. Как правило, за это отвечает SRE (Site Reliability Engineering, инжиниринг надёжности систем) или инфраструктурный инженер, который понимает требования к надёжности, безопасности и масштабируемости системы. Обычно эту функцию выполняет человек, который занимает несколько ролей, например, отвечает за базы данных, ETL-процессы и BI-инфраструктуру.

Нагрузочное тестированиеНагрузочное тестирование

Процесс позволяет заранее понять, как BI-система будет работать в периоды пиковой нагрузки — как правило, это начало рабочего дня и будние дни, когда одновременно заходит больше всего пользователей.

Нагрузочное тестирование помогает ответить на ключевой вопрос: выдерживает ли система реальный сценарий использования. Важно проверить, что при одновременной работе большого числа пользователей дашборды продолжают загружаться с приемлемой скоростью, обновления данных не замедляются критически, а сама платформа остаётся стабильной.

Такая необходимость обычно возникает на этапе, когда количество пользователей достигает примерно 500–600 человек. На этом уровне нагрузки интуитивные оценки уже не работают, и важно опираться на измерения.

ДежурстваДежурства

В BI-команде стоит выделять ответственного, который обрабатывает входящие запросы пользователей, отвечает на вопросы и одновременно следит за техническим состоянием системы. Как правило, это реализуется через формат дежурств: сотрудники команды поочерёдно берут на себя эту роль на определённый период — например, на неделю или несколько дней.

Во время дежурства человек отвечает за два ключевых направления:

• коммуникация с пользователями: обработка вопросов, инцидентов и обратной связи;
• реакция на технические сигналы: алерты из системы мониторинга, проблемы с доступностью, замедления работы или сбои в обновлении данных.

Такая практика позволяет быстрее реагировать на проблемы и формирует у команды чувство ответственности за систему в целом.

Технические процессы развиваются вместе с ростом компании. Посмотрите, какие из процессов стоит внедрить уже на старте бизнеса, а к чему можно прийти на этапе корпорации.

Как процессы меняются с ростом компанииКак процессы меняются с ростом компании

Блок	Маленькая компания (1–15 пользователей)	Развивающаяся компания (15–100 пользователей)	Большая компания (100–1000 пользователей)	Корпорация (1000+ пользователей)
Мониторинг загрузки BI-системы	Необязательно/базово	Желательно	Обязательно	Обязательно
Пересмотр архитектуры	По мере боли	Желательно	Обязательно	Обязательно
Нагрузочное тестирование	Необязательно	Необязательно	Желательно	Обязательно
Дежурства	Необязательно	Желательно	Обязательно	Обязательно

Аналитика и стратегия вокруг BI-системыАналитика и стратегия вокруг BI-системы

Важный критерий зрелой BI-системы — команда оценивает BI-среду как отдельный объект управления. Пока система небольшая, BI обычно развивается реактивно: пришёл запрос — сделали отчёт, возникла проблема — поправили, пользователи пожаловались — улучшили интерфейс. Но с ростом появляется отдельный слой процессов, который можно назвать аналитикой и стратегией вокруг BI-системы.

В предыдущих главах мы уже говорили, что BI-систему стоит развивать как продукт — через исследования, метрики, дерево целей, дорожные карты, бэклог и регулярные циклы переоценки.

Такой подход особенно важен потому, что BI-система почти всегда кажется понятной внутренней команде. Но когда проводишь измерения и исследования, быстро выясняется, что пользователи живут в системе совсем не так, как нам кажется.

За какими метриками следить при оценке BI-системы, мы рассказали в главе «BI-система как продукт». Там — подробно о методах измерений и том, как оценить среду качественно и количественно.

Количественная часть обычно строится на анализе использования системы: какие дашборды открываются, как часто, кем и в какие моменты. Это позволяет понять реальное поведение пользователей и выявить проблемные зоны. Качественная часть включает опросы, глубинные интервью и другие методы исследования. Особенно полезный инструмент — карта пути пользователя, она позволяет увидеть процесс взаимодействия с BI-системой целиком и выявить проблемы, которые сложно обнаружить только по метрикам или опросам.

На основе собранной информации формируется набор гипотез по улучшению системы — с точки зрения процессов, самих дашбордов и пользовательского опыта. Но фокус стоит сохранить на процессах, а не доработке отдельных дашбордов.

Далее гипотезы структурируются в единый бэклог и проходят приоритизацию. Для этого можно использовать любые подходящие методологии, например RIСE. После приоритизации команда формирует набор задач, планирует их выполнение на ближайший период и берёт в работу.

Если вам интересно, как мы развивали такие подходы в Яндекс Go, можете посмотреть пару видео с деталями этого процесса:

• Развитие BI-системы компании с помощью продуктовых подходов
• Инструменты операционного контроля Маркетплейса

Как процессы меняются с ростом компанииКак процессы меняются с ростом компании

Блок	Маленькая компания (1–15 пользователей)	Развивающаяся компания (15–100 пользователей)	Большая компания (100–1000 пользователей)	Корпорация (1000+ пользователей)
Дашборды про дашборды / usage analytics	Необязательно	Желательно	Обязательно	Обязательно
Опросы и сбор обратной связи	Желательно	Обязательно	Обязательно	Обязательно
Карты пути пользователей	Необязательно	Желательно	Желательно	Обязательно
Гипотезы и дорожная карта развития BI-системы	Желательно	Обязательно	Обязательно	Обязательно

Оргструктура и роли в BI-системеОргструктура и роли в BI-системе

Теперь вы знаете о важных процессах вокруг BI-системы, и может возникнуть закономерный вопрос: кто должен ими заниматься и как должна быть устроена организационная структура, чтобы эти процессы действительно работали.

Ответ во многом зависит от масштаба компании и количества пользователей, но можно выделить несколько типовых этапов развития.

В небольших компаниях дашборды находятся в зоне ответственности аналитиков и их руководителей. Отдельного BI-подразделения, как правило, не существует — все задачи решаются внутри аналитических команд.

По мере роста появляются два базовых сценария организации аналитики: централизованный и децентрализованный.

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

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

Наиболее сбалансированный подход — матричная модель. В таком случае создаётся центр компетенций по BI, который отвечает за платформу как технический продукт и за организацию процессов вокруг неё: стандарты, доступы, мониторинг, качество дашбордов. Аналитические команды остаются в бизнес-подразделениях и продолжают работать с задачами своих доменов. Когда таких команд становится больше пяти-семи, стоит выделять отдельную роль BI-аналитика. Этот человек отвечает за развитие дашбордов и BI-процессов внутри домена, подчиняется непосредственно руководителю команды аналитики, но при этом работает по стандартам и правилам, заданным централизованной BI-командой.

Так и достигается баланс: с одной стороны, сохраняется близость к бизнесу и скорость работы, с другой — есть единообразие, управляемость и качество BI-системы в целом.

В эволюции компании это обычно выглядит так: сначала есть просто аналитики, затем формируются аналитические команды по направлениям, после этого появляется центр компетенций по BI, и далее внутри доменов выделяются BI-аналитики. Такая модель развивается органично и позволяет масштабировать BI-систему без потери качества и управляемости.

Матричная структура команды

Отдельная роль BI-аналитикаОтдельная роль BI-аналитика

В моей практике был пример, который хорошо иллюстрирует ценность выделенной роли BI-аналитика. Мне нужно было нанять BI-аналитика в продуктовую команду. Руководитель был против: он считал, что это приведёт к перераспределению ресурсов без ощутимой пользы, ведь аналитики в команде уже умеют делать дашборды. Но мне удалось договориться, и в команду наняли сильного BI-аналитика. Уже в первые месяцы стало заметно, что фокус его работы отличается от задач продуктовых аналитиков. Он системно подошёл к построению дашбордов, пересобрал их структуру и создал набор отчётов, который закрывал значительную часть типовых вопросов пользователей без привлечения аналитиков.

Операционная нагрузка на продуктовую команду снизилась. Вопросы вроде «что происходило с конверсией в прошлом месяце» стали решать через дашборды. Продуктовые аналитики сосредоточились на более сложных и ценных задачах — проведении экспериментов, анализе результатов и формировании гипотез.

Самое показательное в этом кейсе, что руководитель поменял своё отношение. Сначала он был настроен скептически, а по итогам работы отметил, что это было правильное решение.

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

BI-аналитика — это тоже отдельная специализация, которая со временем сформировалась как самостоятельная роль. Набор компетенций отличается от других типов аналитики: помимо работы с данными, важны навыки проектирования дашбордов, понимание принципов визуализации, знание дизайна, умение выстраивать систему отчётности и поддерживать её целостность. BI-аналитик следит, чтобы данные были представлены корректно, удобно и единообразно для широкого круга пользователей.

Разделение ролей даёт преимущество с точки зрения найма: проще находить и развивать специалистов, когда требования к роли чётко определены и соответствуют реальным задачам. Люди, которым интересна работа с дашбордами, визуализацией и системами отчётности, будут эффективнее в роли BI-аналитиков, чем в универсальной позиции аналитика.

Внедрение центра компетенций и выделенных BI-ролей необязательно должно происходить сразу. Это эволюционный процесс, который зависит от масштаба компании и зрелости аналитики.

Центр компетенций необходим, когда в команде 30–50 аналитиков данных. В этот момент появляется достаточный масштаб, чтобы выделить хотя бы одного человека, который будет отвечать за BI-платформу, стандарты и процессы.

На старте в Яндекс Go было примерно 100 аналитиков, и BI-система существовала около года. За это время мы разработали много дашбордов, но качество и системный подход ещё не успели развиться. Тогда была небольшая централизованная команда: руководитель, два BI-аналитика и продуктовый менеджер. При этом BI-аналитики занимались не только процессами, они разрабатывали главные дашборды для всей компании. Это позволило команде сохранить практическую экспертизу, задать стандарты качества на собственном примере и напрямую влиять на наиболее критичные элементы BI-системы.

Спустя год, когда общее количество аналитиков выросло до 200 человек, структура изменилась: появилось около 10 BI-аналитиков, а в центральную команду вышел ещё один BI-аналитик и SRE-инженер, который отвечал за инфраструктуру и автоматизацию.

Ещё через год команда разрослась настолько, что в отдельных направлениях бизнеса (Еда, Лавка, Доставка) тоже стали появляться свои центры компетенций по BI по два-три человека, которые поддерживали стандарты уже в выделенных бизнес-юнитах.

Чтобы понять, нужен ли центр компетенций по BI, можно ориентироваться на следующие признаки:

• BI в разных частях компании заметно расходится по качеству, стилю и принципам.
• Одни и те же задачи и проблемы решаются параллельно в разных командах.
• Обучение и поддержка пользователей, развитие шаблонов происходят несистемно.
• У доменных команд не хватает времени заниматься BI-процессами.
• Отсутствует единое видение и стратегия развития BI.
• Каждая команда действует в рамках своего локального фокуса.

Если таких сигналов становится много — значит, BI-система переросла локальную модель и нужен центр компетенций. Это необязательно означает немедленную централизацию всех специалистов, но почти всегда требует появления функции или команды, которая будет смотреть на BI-среду целиком и отвечать за её системное развитие.

Оргструктура вокруг BI позволяет удерживать систему в собранном состоянии. На ранних этапах это можно делать почти неформально. Но чем масштабнее становится BI, тем важнее определить роли, зоны ответственности и связи между ними. Это позволяет BI перейти от модели, где всё держится на нескольких сильных людях, к устойчивой системе, где качество, поддержка, стандарты и развитие не зависят от случайности.

Как процессы меняются с ростом компанииКак процессы меняются с ростом компании

Блок	Маленькая компания (1–15 пользователей)	Развивающаяся компания (15–100 пользователей)	Большая компания (100–1000 пользователей)	Корпорация (1000+ пользователей)
Определение набора ролей	Обязательно	Обязательно	Обязательно	Обязательно
Выделенный центр компетенций BI	Не нужен	Желательно	Желательно, часто необходимо	Обязательно

Главное о стратегии развития BI-системы в компанииГлавное о стратегии развития BI-системы в компании

С ростом организации операционная аналитика становится полноценным инженерным объектом с необходимыми процессами. Внедрение этих процессов — всегда задача конкретной организации. Невозможно скопировать чужую систему и ожидать, что она заработает.

Этот путь нужно пройти самостоятельно. В процессе у каждой компании формируется свой набор практик, подходов и решений — и это нормально. Более того, именно такие «свои» процессы обычно оказываются наиболее устойчивыми и эффективными.

Когда я уже где-то год занимался проработкой процессов, я наткнулся на лекции и материалы. В них рассказывалось о том, что мы уже придумали сами. И сначала я расстроился, мне казалось, что если бы у меня был готовый список всех процессов заранее, то это значительно упростило бы работу, а мы избежали бы ошибок. Со временем я понял, что это не так. Это связано с природой изменений в организациях: лучше всего приживаются те процессы, которые развиваются внутри компании, адаптируются под её контекст и постепенно становятся частью повседневной работы. Поэтому важен не только сам результат, но и путь, который к нему приводит.

При этом набор практик помогает понять, какие элементы в принципе существуют, куда можно развиваться и какие проблемы предстоит решать. Но конкретные приоритеты, последовательность внедрения и финальная реализация всегда должны определяться внутри компании, с учётом её задач, культуры и уровня зрелости.

• BI-система масштабируется не только за счёт новых дашбордов, но и через процессы вокруг них: поддержку, обучение, стандарты, управление контентом и техническую среду.
• Для бизнес-пользователей важно выстраивать понятную пользовательскую среду: портал, онбординг, словари, поддержку и систему уведомлений. Без этого даже качественные дашборды теряют ценность.
• Аналитикам нужны собственные процессы: обучение, стайлгайды, шаблоны, понятные правила работы, поддержка и профессиональное сообщество. Это помогает быстрее создавать качественный контент и сохранять единый подход.
• Контент нужно контролировать: пересматривать состав дашбордов, архивировать устаревшие отчёты, поддерживать структуру, сертификацию и прозрачную систему доступов.
• По мере роста BI-системы появляется технический контур: мониторинг, архитектурные решения, нагрузочное тестирование и дежурства. Это помогает сохранять стабильность и предсказуемость системы.
• Зрелая BI-система развивается как продукт: через исследования, метрики, гипотезы, дорожную карту и регулярные циклы улучшений.
• Организационная модель тоже влияет на качество BI. На практике чаще всего работает матричный подход: доменные аналитики остаются близко к бизнесу, а центр компетенций поддерживает общие стандарты и развитие системы.

Область BI-аналитики постоянно развивается, и появление ИИ-технологий оказывает на неё влияние. В следующей главе мы расскажем, как нейросети влияют на развитие операционной аналитики: какие подходы и процессы будут трансформироваться, какие могут исчезнуть, а какие сохранятся и останутся ключевыми элементами системы.