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

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

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

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

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

В статье рассматривается архитектурная гипотеза-прототип, предлагающая распределение сущностей по разным слоям и реализацию сквозного связывания между элементами различных canvas-пространств. Через призму теории о: компонентных систем управления контентом (CCMS) и баз знаний нового поколения (LLM-wiki), решая проблему масштабирования визуальных связей в интерфейсах.

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

Пользователь отправляет тикер и получает три результата: направление активность и итоговый статус.

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

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

Поэтому я открыл свою самую тяжёлую модель — 22 таблицы, 206 колонок, 86 мер — и прочитал её целиком. Двадцать мер из восьмидесяти шести меняют расчёт в зависимости от того, до какого уровня развернули матрицу: из-за них сверка «итог в итог» после переноса сходится идеально и ничего не доказывает. Шесть производственных договорённостей зашиты прямо в формулы и не описаны больше нигде.

Разбираю, что на самом деле переносится при миграции BI и почему документацию в ландшафте на 800+ отчётов придётся отдавать машине.

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

Не успели мы толком оправиться от расследования про Культ Роя внутри OpenAI, как появились новые данные про проделки другой «цивилизации» агентов: на этот раз они общались между собой прямо у нас под носом в публичном интернете (и настрочили более 18'000 сообщений).

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

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

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

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

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

Как организовать регулярную выгрузку данных из 1С, если ручной экспорт уже не справляется с объемом и частотой обновлений? В статье сравниваются два подхода: прямой доступ к базе через SQL и использование готового ETL-инструмента. Разбираем скорость, сложность настройки, требования к специалистам, риски для безопасности и сопровождения системы. Также показываем, в каких случаях оправдан SQL, а когда удобнее использовать готовый инструмент для автоматической выгрузки данных по расписанию без постоянного участия разработчика.

Если вы проводите достаточно времени, используя DeFi, то вы заметите, что большинство диалогов крутится вокруг всего одной метрики: APY. Какой протокол предлагает наибольшую доходность? У которого из них наибольшая отдача? Какой пул ликвидности генерирует больше всего комиссий? Эти вопросы вполне резонны, но они упускают из виду кое‑что гораздо более важное. Насколько эффективно используется на самом деле ваш капитал?

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

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

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

Инженеры данных построили агрегат — маленькую таблицу «продажи по магазинам по дням». Отчёт из неё собирается за доли секунды. А сводная в Excel всё равно ждёт двадцать секунд и читает миллиард строк.

Разбираемся на живом ClickHouse, почему база не видит предагрегат, который для неё построили, какая форма запроса это лечит (одна и та же для ClickHouse, Snowflake и BigQuery) и почему в итоге вопрос не к базе, а к семантическому слою. Внутри — замер на миллиарде строк: 3 секунды против 37 миллисекунд, сравнение восьми баз и одно правило, которое стоит проверить в своём BI.

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

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

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

Но «всё» нельзя использовать как границу проекта. Его сначала нужно разобрать на решения, роли, показатели, источники и сценарии проверки.

Привет! Меня зовут Дмитрий Гаврилов, я руководитель центра компетенции аналитики в MWS. Моя команда внедряет ИИ-скиллы в работу дата-аналитиков. Мы посмотрели на типичный рабочий день и поняли: рутина съедает до 75% времени аналитика. А можно ли это передать ИИ-агенту без потери качества? Эту гипотезу проверили на реальных задачах и получили конкретные результаты — делюсь в этом материале.

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

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

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

Всем привет! 

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

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

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

Давайте разбираться по порядку!

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

Мы поговорили с тремя командами, которые используют продукты из экосистемы Инфостарт Маркетплейс в повседневной работе:

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

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

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