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

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

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

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

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

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

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

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

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

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

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

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

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

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

Привет! Эта статья написана командой системных аналитиков из ПСБ:
 Юрием Моргуновым, Анастасией Самсонниковой, Ольгой Догадкиной, Максимом Белявским и Максимом Зуевым. Мы, как и многие компании, перешли с монолита на микросервисы. Причины тривиальны — их озвучивают, пожалуй, в каждой истории ухода от монолита: поддерживать всё это стало дорого, неудобно, монолитная архитектура замедляла процессы. 
 
 В общем, здесь начинается наша история. Если вы планируете переходить на микросервисы, эта статья для вас. Если же вы уже раздробили свой монолит, заглядывайте и дополняйте нас в комментариях.

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

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

Ссылка на исходный код

В предыдущих статьях серии было показано, как использовать функциональность FEB_FILE_HANDLING в качестве единой точки входа для импорта банковских выписок в SAP независимо от канала их получения — через прямые сервисы коммуникации с банковскими системами или файлы из систем «Банк-клиент» — и от используемого формата: XML или текстового. Также была рассмотрена классическая схема импорта промежуточных выписок в течение дня с созданием платёжных авизо для обновления данных финансовой диспозиции, или денежной позиции.

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

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

В проектах с 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.