Системный и бизнес-анализ

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

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

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

Классическая корпоративная воронка часто выглядит примерно так: Хотите посмотреть продукт? Оставьте заявку → менеджер позвонит → договоримся о времени → проведем демонстрацию.

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

Привет! Меня зовут Алиса, и сейчас я руковожу командой разработки продукта «Штурвал». У нас работает около пятидесяти человек:  инженеры,  безопасники,  девопсы, фронтендеры, бэкендеры на Go и тестировщики, которые ломают всё, что мы строим. Но сегодня я хочу рассказать не о них. Сегодня балом правят аналитики. И под катом объясню, почему. 

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

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

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

Меня зовут Вадим Скляров, я бизнес-аналитик проектного офиса МТС Медиа. В этом материале расскажу, почему для этой задачи я выбрал ORM2 в качестве инструмента концептуального моделирования, какие приложения есть на рынке, почему в итоге понадобилось собственное SPA-приложение и чем оно оказалось полезным.

В этой статье рассказываем о реальном опыте переноса решения Retail Analytics (платформа аналитики для ритейла от Lasmart) с Microsoft SQL Server Analysis Services (SSAS Multidimensional) на Alpha OLAP, входящий в состав российской аналитической платформы Alpha BI.

Привет, Хабр! Меня зовут Лилиана Муллаярова, я маркетолог продукта Alpha BI. Статью готовили с командой продукта Alpha BI и командой нашего партнёра Lasmart, который и проводил миграцию Retail Analytics. Мы сравним, как система работала на MS SSAS, а как на Alpha OLAP, где получили прирост производительности, а где пришлось менять подходы. И главное: стоит ли игра свеч, если вы сегодня выбираете между «остаться на SSAS» или «мигрировать на российский OLAP».

Автоматизация в n8n может собраться за полчаса, а через несколько месяцев превратиться в процесс, который страшно менять.

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

«Паша! Я конечно не МГИМО финишед, но можешь хотя бы по‑русски, а?» — попросил Азиз когда я выпалил ему питч, заготовленый для грядущего ивента в 71 блоке на one North. Тогда я понял, что…
Потенциальный клиент для внедренца not!= специалист.
И я сделал то, что планирую сделать в этой серии статей — рассказал про интеграцию автоматизированного учёта в малом бизнесе простыми словами.

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

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

Сообщение в личку в 18:40: «Слушай, а почему у тебя в выгрузке 11 903 заказа, а на дашборде 12 480? Завтра в 11 показываем отчет».

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

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

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

Материал будет полезен дата-сайентистам и тимлидам, которые работают с монетизацией на маркетплейсах и в сервисах для объявлений.

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

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

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

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

12–14 ноября 2026 года в Санкт-Петербурге пройдет INFOSTART A&PM EVENT 2026 - конференция для аналитиков, руководителей проектов, владельцев продуктов и специалистов, работающих с проектами и продуктами на платформе 1С.

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

Приветики, меня зовут Пётр и я продуктовый аналитик с коммерческим опытом в ПА около 12 лет. В моей работе глобально задачи делятся на 3 типа — разметка событий, аб‑тесты и продуктовые рисерчи.

Про разметку я уже писал тут https://habr.com/ru/articles/785320/

Под аб‑тесты мы с корешами собрали коммерческий воркспейс. Было тут: https://habr.com/ru/articles/1064034/

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

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

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

И поэтому общий показатель - это скорее начало анализа, а не его итог.

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

Одна из главных ошибок в разговоре о карьерном росте — сравнивать должности только по размеру зоны ответственности.

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

Найм, one-to-one, конфликты, отчёты, согласования и внезапные проблемы очень быстро «съедают» календарь. В какой-то момент инженерные задачи превращаются в вечернее хобби после восьми часов созвонов.

В последнее время традиционная бизнес-аналитика все сильнее пересекается с плоскостью аналитики данных (как в индустрии финтеха и банкинга, так и во многих других сферах). Некоторые профильные специалисты уже не первый год рассматривают Business Intelligence как супермножество Data Science, и все громче звучит мнение, что компаниям необходимо объединять оба направления.

Поэтому сегодня мы в МКБ подготовили подборку материалов для желающих погрузиться в тему BI/Data Science. Под катом — открытые книги, которые помогут разобраться в современном аналитическом стеке, а также профильные учебники. А еще блоги, авторы которых простыми словами разбирают вопросы и проблемы по теме: от борьбы с «фактором автобуса» до принципов работы в индустрии BI.

👾 ИИ Агент для скоринга торговых рекомендаций

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

В итоге оценивается не красивая лента и не заявленный win rate, а статистически проверяемое качество решений автора.

Как восстановить архитектуру распределенной системы по Git-репозиториям, конфигурации и исходному коду

Системному аналитику далеко не всегда достается система с актуальной документацией и готовыми архитектурными схемами. Иногда единственным достоверным источником информации остается то, что реально работает в production: развернутые сервисы, их конфигурация и исходный код.

В этой статье на практическом примере я покажу, как восстанавливал AS-IS архитектуру существующей подсистемы: от определения фактически работающих компонентов и поиска соответствующей версии исходного кода до анализа Java Spring-приложения, его Kafka-потоков, REST-интеграций, работы с MongoDB, retry и обработки ошибок. Результатом стала архитектурная модель и диаграмма последовательности, построенные на основании фактической реализации.

Статья в первую очередь рассчитана на системных аналитиков. Ее цель не в том, чтобы научить читать Java-код как разработчик, а показать практическую методику: куда смотреть в незнакомом репозитории, как выбирать значимые участки кода и как превращать найденные технические детали в понятное описание поведения и архитектуры системы.

Я — аналитик данных в команде BIGDATAHOUSE, и на всех проектах трансформацию данных реализую через dbt — де‑факто стандарт, в качестве BI в основном использую Superset.

Бизнес‑логика в таком стеке оказывается разбита по двум местам: одна её часть оседает в dbt, другая описывается в BI. Со временем эти две части неизбежно расходятся, и отследить такие расхождения становится всё сложнее.

Из профессионального интереса изучая альтернативные BI‑платформы, я наткнулся на Lightdash. Он обещает закрыть эту и ряд других проблем.

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

Привет, Хабр! Меня зовут Никита, я основатель и генеральный директор VSL-BI.

Недавно мы сделали проект для рекламного агентства, где вся аналитика была построена в BI Конструкторе Битрикс24. На его примере покажу, какие задачи инструмент действительно закрывает, где начинаются ограничения и кому его возможностей будет достаточно.