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

Между покупателем и продавцом в карточном платеже стоят четверо: банк-эмитент, платёжная система, банк-эквайер и процессор с агрегатором. Обмануть покупателя может только продавец. Но подключить продавца к инфраструктуре может только посредник — и вопрос, отвечает ли он за это подключение, до сентября этого года внятного ответа не имел нигде.

4 сентября 2026 года Федеральная торговая комиссия США объявила о мировом соглашении с Nuvei, одним из крупнейших мировых платёжных процессоров. Компания выплатит 4,85 млн долларов и перестроит процедуры проверки подключаемых магазинов.

Сумма для компании такого размера символическая. Интересно другое: впервые внятно сформулировано, за что отвечает посредник, который сам ничего покупателю не продавал.

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

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

И это не исключение – это норма для большинства предприятий, где выбор поставщика до сих пор делается вручную, на глазок, без формализованной процедуры. Хуже того: даже если менеджер учитывает партионность, он всё равно не учитывает историю взаимодействия – сколько раз поставщик привозил вовремя, сколько раз приходилось оформлять рекламацию. Эта информация хранится в ERP-системе, но почти никогда не используется для принятия решений.

В этой статье мы разберём математическую модель, которая закрывает оба пробела. Три критерия – приведённая стоимость закупки с учётом минимальной партии, срок поставки и интегральный уровень доверия к поставщику, вычисленный из данных ERP. Один алгоритм, реализованный в Engee на языке Julia. И числовой пример, где поставщик с самой низкой каталожной ценой закономерно оказывается наихудшим выбором – а модель это выявляет автоматически.

Много лет я занимался бизнес‑анализом и внедрением продуктов 1С. Зная хорошо специфику работы я сделал расширение конфигурации 1С для рисования бизнес процессов сразу внутри 1С.

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

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

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

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

В статье разберём, почему timeout не позволяет однозначно определить результат бизнес‑операции и как безопасно обрабатывать такие ситуации.

Представим ситуацию: наша система отправляет внешней системе запрос «Создать платёж на 50 000 ₽» POST /payments→ внешняя система получает запрос и создаёт платёж → внешняя система отправляет ответ о созданном платеже → при отправке ответа происходит ошибка и он не доходит до нашей системы → наша система не получает ответ в установленное время и фиксирует timeout.

Можно ли повторить запрос на создание платежа?

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

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

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

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

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

Это вторая статья из цикла про прототип 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, а когда удобнее использовать готовый инструмент для автоматической выгрузки данных по расписанию без постоянного участия разработчика.