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

Всем привет, меня зовут Катя, я развиваю Gramax. Уже несколько месяцев мы делаем ИИ-агента для работы с текстом и документацией, поэтому много смотрим на реальные кейсы в разных компаниях. Один из самых сильных принесли друзья из SellOut+. Они делают аналитические системы для фармы и FMCG, быстро пробуют новые подходы и в какой-то момент взяли первую версию функции агентов в Gramax.

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

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

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

Как отличить инжениринг AI-систем от применения ИИ в разработке и почему coding agents в 2026 году требуют больше контроля, тестов и архитектурных границ

Как на собеседовании отличить системного аналитика, который учил REST по учебнику, от того, кто реально проектировал API?

В статье — три живых кейса из практики в FinTech и e‑commerce. Вы сможете проверить себя, увидите разбор популярных ошибок и узнаете, почему даже опытные инженеры спорят про PATCH и 409.

Самые интересные новости финансов и технологий в России и мире за неделю: MAX выпилили из AppStore, Трамп придумал новые тарифы, миллионы Гугл-комаров выпустят в США, Google и Цукерберг хотят продать много новых акций для строительства датацентров, а фондовый рынок и крипта падают дружно упали, как только Майкл Сейлор начал продавать биткоины.

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

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

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

В 2026 году уже не нужно гадать, человек писал GitHub-репозиторий или AI. Я сделал Chrome-расширение, которое оценивает репозиторий по прозрачным эвристикам: README, коммиты, структуру файлов и метаданные. Без нейросети, без чёрного ящика — только понятные правила и объяснимый вердикт.

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

Любой аналитик знает, что самым надёжным способом проверки гипотез являются рандомизированные контролируемые эксперименты (RCT), или, как их называют в народе — A/B-тесты. На практике часто возникают ситуации, когда провести A/B-тест невозможно — в основном это происходит по этическим или техническим причинам. Однако бывают кейсы, когда рандомизация невозможна потому, что treatment-ом является определённое действие пользователя. Например, treatment-ом может быть оформление платной подписки или отмена бронирования на сервисе. Давайте назовём такой вид воздействия добровольным.

В русскоязычном пространстве, и в частности на Хабре, достаточно много статей, посвящённых таким методам Causal Inference, как DiD, PSM и Causal Impact. Тем не менее, к моему удивлению, практически нет статей, посвящённых методам на основе ортогонализации и regression adjustment, хотя, на мой взгляд, именно эти методы являются самыми удобными для оценки эффекта от добровольного treatment-а. Пришло время исправить это недоразумение и разобрать метод Double/Debiased Machine Learning (DML) и Partial Linear Regression для задач Causal Inference!

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

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

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

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

Об этом и поговорим.

На одной из ИТ конференций по бизнес-анализу я проводил мастер-класс «Моделируем IT архитектуру предприятия». Участники были разбиты на группы, и было дано одно из заданий из нашего Курса аналитика 1С:

Функциональный архитектор 1С — это не «аналитик посильнее» и не человек, который просто рисует красивые схемы. Это специалист, который держит в голове бизнес, ограничения платформы, логику процессов, риски внедрения и границы проекта.

Разбираемся, чем на самом деле занимается архитектор 1С, кому стоит идти в эту роль и почему на крупных проектах без него быстро начинается хаос.

Что стоит за вопросом «это писал человек или нейросеть» — и почему разговор об авторстве уже упирается в SIP, DR и MAP.

Добрый день, уважаемые читатели Хабра.

В этой статье я хочу рассказать о продукте APItizer, почему появилась потребность в его создании и какой путь привёл от небольшого Python-скрипта к полноценному инструменту для проектирования REST API-контрактов.

Если вам интересно сразу посмотреть на продукт, добро пожаловать в APItizer (прямая ссылка, вдруг домен не работает).

Сбор первичных документов из 1С, SAP и ERP из разных юридических лиц традиционно является серьезной головной болью бухгалтерии. В этой статье мы поговорим о том, как с помощью low-code платформ можно автоматизировать данный процесс и сформируем гайд по построению такого пайплайна.

Привет, Хабр! Пишет команда Business Intelligence GlowByte. Каждый год мы проводим Fine Day Online – конференцию про бизнес-аналитику, где практики из разных компаний делятся честным опытом. 22 апреля собрались спикеры из сети “Галамарт”, банков Уралсиб и ОТП, а также FanRuan, и все пять докладов оказались про одно и то же: данные есть, деньги в инструменты вложены, а бизнес по-прежнему принимает решения на ощущениях.

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

Трансфер знаний: как за 5 шагов мы превратили кризис в рутину

Реальный кейс из практики бизнес-аналитика

Хотите знать, какие ошибки можно совершить и, что самое главное, как их избежать при передаче задач, знаний и проектов от аналитика к аналитику? Тогда вам сюда!

Замечаете, что безопасность становится важнейшим атрибутом качества современных систем. А знакомы ли вы с концепцией Zero Trust? Не упустили ли вы момент перехода к непрерывной проверке безопасности?

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

Давайте на примере таск-трекера посмотрим как разные уровни ABAC влияют на логику фронтэнда и бэкэнда. Разберём как системному аналитику с помощью экспериментальной методики — постанализа юзкейсов — быстро оценить ситуацию и понять, когда принять решение простое, а когда сложное.

Меня зовут Андрей Рыжик, я Product Owner BI-направления в компании «Белый код». Эта статья – обзор платформы rapeed: in-memory OLAP-движка с собственным форматом хранения, нестандартной алгеброй связей между источниками и несколькими клиентами поверх единого ядра.