BI-аналитик: чем занимается, какие навыки нужны и как им стать

Коротко: чем занимается BI-аналитик

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

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

Один запрос руководителя: что сделает специалист

Фраза «продажи выросли» слишком неопределённа. BI-аналитик спросит, речь об оформленных бронях, оплатах, выручке после возвратов или прибыли; за какую дату считать событие и какую неделю брать за базу. В нашем учебном кейсе доступна таблица bookings с полной суммой брони, но данных для чистой выручки нет. Значит, задача сужается до «сумма оформленных бронирований за 3–9 августа к 27 июля — 2 августа». Такое сужение — часть профессиональной работы, а не придирка к словам.

Следующий вопрос — какое действие ждёт руководитель. Если важно решить, менять ли тарифы или искать причину роста, простой итог не отвечает «почему»; нужны разрезы и дальнейшее исследование. BI-аналитик может показать, что сумма выросла на 8,39%, число броней — на 8,53%, а средняя сумма почти не изменилась. Это разумное направление для дальнейшей проверки объёма, но не причинное объяснение. Хороший специалист ставит границу доказательству прямо на странице.

Неделя работы: от интервью до сверки

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

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

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

SQL и модель данных: основа, которую видно не сразу

Для недельного итога хватит COUNT(*), SUM(total_amount) и AVG(total_amount) по bookings. Результат: 42 561 бронирование, 3 377 874 800 ₽, средняя 79 365,49 ₽. Но задача становится сложнее, когда руководитель просит разбивку по числу билетов. Прямое соединение bookings и tickets создаст несколько строк для одной брони; SUM(total_amount) увеличится без новых денег. Аналитик сначала считает COUNT(*) билетов по book_ref, затем соединяет одну строку с одной бронью.

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

SELECT COUNT(*) AS bookings,
       SUM(total_amount) AS booking_amount_rub,
       ROUND(AVG(total_amount), 2) AS avg_booking_rub
FROM bookings
WHERE book_date >= TIMESTAMP '2026-08-03'
  AND book_date < TIMESTAMP '2026-08-10';

Визуализация: не украшать, а сократить путь к решению

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

Для 3–9 августа сумма по дням — 452,16; 467,67; 479,38; 485,60; 490,80; 492,64; 509,63 млн ₽. Подпись «млн ₽, Москва, полная неделя» входит в результат не меньше, чем сами точки. Если исходная сумма названа выручкой, BI-аналитик должен исправить название, даже если число рассчитано верно. Визуальная ошибка часто превращается в ошибку решения.

Как проверить, что отчёт не врёт

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

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

Чем BI-аналитик отличается от аналитика данных

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

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

Инструменты: классы задач вместо коллекции логотипов

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

Работодатель может использовать DataLens, Power BI, Superset, Metabase или собственную платформу. Освойте один инструмент глубоко, затем переносите принципы: источник → модель → метрика → визуализация → публикация. Названия кнопок меняются, ошибки зерна и несогласованных периодов остаются. Изучать пять инструментов поверхностно до умения сверить один SUM менее полезно, чем пройти полный цикл в одном.

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

Чему учиться по порядку

Первый этап — SQL: фильтры, агрегаты, JOIN, даты, окна и проверка качества. Выполняйте запросы на реальном наборе, а не только читайте синтаксис. Второй — модель данных: факты, измерения, ключи, many-to-many, зерно и календарь. Третий — визуализация: какая форма отвечает на вопрос, как подписать масштаб и не скрыть ограничение. Четвёртый — один BI-инструмент от подключения до прав доступа. Пятый — интервью с заказчиком и защита результата.

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

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

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

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

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

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

Как разговаривать с заказчиком и защищать границы вывода

Вместо «какие графики нарисовать?» спросите «какое решение вы примете, если показатель изменится?». Уточните период, уровень детализации, источник истины, частоту обновления и кто принимает страницу. Если заказчик просит прибыль, а в базе есть только бронирования, покажите недостающие таблицы и предложите промежуточный показатель с точным названием. Не обещайте, что простая корреляция на графике объясняет причину изменения.

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

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

Ошибки начинающего BI-аналитика

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

Шестая — дать всем роль администратора, чтобы отчёт «точно открылся»: детальные данные уйдут лишним людям. Седьмая — замерить успех числом опубликованных дашбордов вместо реальных решений. Восьмая — никогда не удалять устаревшие показатели: на встрече остаются старые и новые версии одной цифры. Лекарство одно: договориться о пользователе, источнике, проверке и владельце ещё до кнопки «опубликовать».

Частые вопросы и следующий шаг

Нужен ли BI-аналитику Python? Он полезен для сложной подготовки, исследования и автоматизации, но SQL и моделирование обычно первее. Нужно ли знать все BI-инструменты? Нет: один полный проект с моделью, проверкой и доступом лучше пяти поверхностных знакомств. Можно ли войти в роль без опыта бизнеса? Да, через учебный кейс, если вы умеете объяснить вопрос и ограничение данных, а не только показать график. Чем роль отличается от «делать отчёты»? Ответственностью за определения, качество, обновление и возможность принять решение.

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