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

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

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

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

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

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

Статья будет полезна аналитикам и DS, которые работают с несколькими ML-моделями в проде и хоть раз озадачились вопросом, как сравнивать их между собой.

Открываешь вакансию аналитика в 2026 и видишь ML, LLM, дата-инженерию, облака и пятнадцать инструментов, а SQL с Excel где-то внизу, будто это само собой. Кажется, что профессия ушла далеко вперёд и, если ты только вкатываешься, ты опоздал на пять лет.
Я в аналитике с 2020 года и вижу оба конца отрезка: и с чего начинала сама, и с чем приходит новый поток. Так вот, если смотреть не на список требований, а на то, чем аналитик реально занят в течение дня, окажется, что поменялось куда меньше, чем обещано.
Делюсь мнением, что изменилось, а что раздулось только в описаниях вакансий, а что не сдвинулось с 2020 года вообще и по-прежнему отличает сильного аналитика от среднего.

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

В сегодняшнем дайджесте мы собрали популярные решения в Базе знаний Инфостарт за последние 14 дней. Сообщество 1C активно скачивает обработки, ставит лайки и комментирует эти публикации. 

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

Помесячный прогноз выручки стабильно недобирает, не скачет, а именно недобирает: факт всегда выше прогноза, из месяца в месяц, примерно в одну и ту же сторону.
Стабильное смещение — это уже не шум, это баг, поэтому я полезла в модель.
Модель прогноза выручки занижала цифры вдвое.
Ошибка была в одной строке – np.exp() вместо честного возврата из логарифмов.
Разбираю этот кейс и всё остальное, что аналитику нужно знать про логарифм: декомпозиция роста, эластичность, A/B-тесты и поправка Дуана.
С кодом и цифрами.

Привет, Хабр! Меня зовут Михаил Рязанский, я руководитель группы технической аналитики в Дзене. Группа включает в себя команды DWH, антифрода, аналитики модерации и ML‑аналитики. Вместе с Марком Хабаровым, лидом команды ML‑аналитики, мы расскажем про наш инструмент для анализа результатов А/Б‑тестов и про интеграцию в него LLM. Получилось интересно, местами — больно. Но обо всём по порядку. 

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

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

Что ценнее: купить готовый программный продукт, технологическое ядро или сразу получить собственный «завод» по выпуску ПО? Разбираемся, чем отличаются White Label и OEM, почему сегодня необязательно разрабатывать сложные технологии полностью с нуля и какие инженерные задачи скрываются за зрелой корпоративной платформой.

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

Привет! Меня зовут Михаил Измайлов, я лид по аналитике данных в команде лояльности MAGNIT OMNI — бизнес-группе ритейлера «Магнит», которая отвечает за развитие омниканального опыта для клиентов.

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

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

Оплатить ChatGPT, купить подписку на Figma, пополнить рекламный кабинет Google Ads, оплатить AWS или GitHub. Кажется, что в 2026 веке это должно занимать несколько минут. Но стоит столкнуться с задачей в реальности и выясняется, что универсального решения, как это обычно бывает в наши дни, нет. Одни советуют открывать компанию за рубежом, другие — искать иностранный банк, третьи уверяют, что все давно решается через финтех.

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

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

Оба продукта — CDP (Customer Data Platform) для маркетинга. По сути это база данных, которая собирает информацию о клиенте отовсюду и нарезает её в сегменты, — а сверху на эту базу наслаиваются рассылки, бонусы и акции, ласково выманивающие клиента с дивана. Задача-дубль — конструктор сценариев: визуальный редактор, где кампания собирается цепочкой блоков. Классика жанра — сценарий на день рождения:

Первое профессиональное программное решение по спортивной аналитике, усиленное ИИ, мы с командой построили для экзотичного у нас крикета. Было это еще в 2017 году, и тогда решение выглядело каким-то космолетом.

Сейчас в 2026-м наш ИИ-аналитик на базе AI4BI "универсализировался", оброс возможностями по добавлению доменной экспертизы через RAG-базы знаний и сильным AI\ML плечом, развился до того, чтобы масштабироваться в сторону как классических видов спорта - футбола, хоккея, волейбола, баскетбола, бенди - под самые разные роли: тренер, скаут, спортивный аналитик, спортивный директор, владелец клуба, так и в сторону «гражданской» фитнес-аналитики. При этом уже не выглядит чем-то космическим - сейчас это доступный инструмент для спортивных организаций от профессиональных команд до фитнес-клубов.

Сегодня разберём 3 кейса, покрывающих 3 разных вида спорта и 3 роли, - и на каждом покажем, как это выглядит внутри AI4BI.

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

Мой путь от скептика к как меня в шутку называют коллеги «документатору‑злодею» и мысли о том, зачем же нам все таки нужно уметь и делать проектную документацию.

Привет, Хабр!

Как перепроверить отчёт, который прислали специалисты? Как перестать постоянно обращаться к аналитикам с ad hoc-запросами и часами ждать очередную таблицу? Может быть, стоит просто спросить нейросеть о показателях своей компании?

У этой концепции есть название — GenBI. Сама идея не нова: сегодня производители встраивают копилотов практически во все аналитические сервисы и обещают доступ к корпоративным данным через запросы на естественном языке.

Но на практике всё оказывается сложнее.

Когда говорят о GenBI, архитектуру часто описывают так: пользователь задаёт вопрос на естественном языке, большая языковая модель пишет SQL, база данных выполняет запрос, а модель объясняет результат.

Для демонстрации этого достаточно.

Для корпоративной аналитики — обычно нет.

Мы с командой занимаемся проектированием и разработкой корпоративных BI-систем на базе SQL Server, SSIS, SSAS Tabular и Power BI. В основном это on-premise-решения, где данные из учётных систем проходят через DWH и семантическую модель, прежде чем становятся доступны пользователям. В последнее время также занимаемся интеграцией таких моделей с LLM-интерфейсами.

Главная проблема здесь не в том, умеет ли LLM написать синтаксически корректный запрос. Современные модели умеют генерировать и SQL, и DAX. Проблема в другом: откуда модель должна узнать, что именно компания называет выручкой, продажей, активным клиентом, себестоимостью или остатком?

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

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

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

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

Когда я начал активно использовать OpenAI Codex для длительных задач, я быстро заметил странный парадокс. Агент способен работать самостоятельно десятки минут, но именно человек продолжает каждые несколько минут проверять терминал: не закончил ли он работу. Я решил поменять эту модель взаимодействия. Вместо того чтобы следить за агентом, агент стал сам сообщать, когда моё участие действительно необходимо.

В предыдущей статье мы разобрали третье базовое понятие BABOK — Изменение (Change). Мы выяснили, что изменение — это не событие, а процесс, и что 70% инициатив проваливаются не потому что техника плохая, а потому что человеческая сторона проигнорирована. Но предположим, вы всё сделали правильно: нашли нужных заинтересованных сторон, сформулировали истинную потребность, спроектировали переход. Следующий вопрос — самый дорогостоящий в буквальном смысле слова:

Что именно мы будем строить или менять?

Именно здесь в игру вступает четвёртое базовое понятие BABOK — Решение (Solution). И именно здесь совершается ошибка, за которую бизнес платит дороже всего: команда влюбляется в первое пришедшее в голову техническое решение и перестаёт искать альтернативы.