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

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

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

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

Склад может работать «в плюс» по всем видимым статьям — и при этом системно терять рентабельность. Не из-за ошибок персонала и не из-за дорогой аренды, а из-за структуры ассортимента.

Возьмём типичный пример: неликвидные позиции на складе оценены в 5 млн рублей. При обычной для рынка стоимости хранения запаса 20–30% в год, только за то, что эти позиции занимают место и держат замороженный капитал, склад теряет от 1 до 1,5 млн рублей ежегодно. Через 3–4 года такого хранения суммарные затраты превышают закупочную цену товара. Дальше держать — терять деньги наверняка, продать — терять деньги один раз.

Эта статья — о том, как увидеть эту математику в данных WMS и принять решение раньше, чем она окончательно съест маржу.

Всем привет! Меня зовут Егор Гурин и я разработчик в компании MTC Web Services. Работаю в стриме, который занимается разработкой контактного центра МТС. Практически любые обращения клиентов в компанию, будь то неработающий интернет или вопрос по заказу в интернет-магазине, проходят через нас. 

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

В этом материале я поделюсь инструментами, которые помогли наладить процессы в нашей команде в рамках методологии Document Driven Development, — возможно, вам она знакома под такими терминами как design-first или API-first. Покажу, как в удобной форме описывать контракты с помощью TypeSpec, использовать мокирующие сервера не дожидаясь реализации серверной, а еще — расскажу про инструмент кодогенерации на Go и автотесты с помощью Schemathesis.

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

Несмотря на самостоятельность этой публикации, она раскрывает некоторые вопросы, поднятые ранее в статье "Как пройти… к третьей нормальной форме?"

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

В 2026 году тот же путь можно пройти быстрее: передать ИИ требования и за несколько итераций получить кликабельный прототип на HTML, CSS и JavaScript — с формами, модальными окнами, валидацией и тестовыми сценариями.

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

Что если задать BI-системе вопрос, который выходит за рамки рутинной аналитики? Будет ли она также эффективна? Эта идея родилась из корпоративного шуточного спора: шутили над качествами сотрудника «Рака», а в статистику попали также и другие «носители» знака зодиака. 

Мы в Modus решили проверить закономерности на данных, так как это наш профессиональный рабочий инструмент и сфера интереса. Взяли статистику всех игроков Российской Премьер-Лиги, добавили знаки зодиака — и посмотрели, что получится. 

Спойлер: вышел настоящий дашборд и серьезный вывод о том, на что способен гибкий BI.

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

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

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

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

Цифровые сервисы уже несколько лет пытаются добавлять нейросети везде, куда только могут дотянуться, и это уже стало новой реальностью. При этом, чаще всего, когда говорят про ИИ в цифровых сервисах подразумевают сервисы для пользователей – поиск, чат-боты и тд. Но бизнес-сервисы тоже активно используют языковые модели. Я в этой статье хочу поделиться наблюдениями, как в бизнес-банкинге сегодня работает ИИ. Мы с коллегами нашли несколько примеров и оценили их в рамках исследования Markswebb Business Mobile Banking Rank 2026.

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

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

Пользуюсь не каждый день, но там где надо выбрать из нескольких вариантов, перелопатить гору инфы и выбрать что-то одно путнее, у NotebookLM пока нет равных.

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

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

Сплиттер работает корректно, метрика посчитана, а p‑value уверенно опустился ниже 0,05 — результат кажется готовым к раскатке. Однако ошибка в оценке дисперсии способна превратить случайное различие в статистически значимое.

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

В какой-то момент у нас, как и у многих команд, появился соблазн проверить: а можно ли уже не просто просить AI «написать user story», а действительно встроить его в рабочий процесс аналитика? Например, дать агенту вводные по задаче, макеты в Figma, примеры документации и требования к оформлению, и получить на выходе нормальный Use Case, API-спецификацию, PlantUML-диаграмму и аккуратную страницу в Confluence.

Звучит красиво. 

Особенно если вы когда-нибудь вручную переносили сценарии из заметок в Confluence, сверяли шаги с макетами, оформляли вкладки с HTTP-запросами, проверяли коды ошибок и пытались не забыть все вопросы, которые «надо потом уточнить».

В статье расскажу, насколько мы близки к этой утопии — как протестировали работу ИИ в реальном аналитическом процессе в нескольких кейсах: для подготовки Use Case, аналитических артефактов, публикации в Confluence и в работе с Figma.

Как с помощью бесплатных инструментов Google создать систему анализа данных: от сбора ответов в форме до визуализации на сайте. В качестве примера разберем исследование туристических предпочтений и настроим автоматическую отправку письма при достижении цели.

Недавно мне понадобилась старая заметка. Я точно помнил, что записывал её: там былы креды от сервиса (да, знаю надо хранить все в пароехарилках, но я записал как записал).

Не помнил я только, где именно это записал(

В Notepad++? В Obsidian? В сообщении самому себе? В папке проекта? Минут двадцать я перебирал места, и к концу уже не столько искал заметку, сколько пытался воскресить в памяти тот день что бы понять ход собственных мыслей

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

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

Первая статья из цикла «Аналитик в чужом процессе»

145 тысяч тикетов, почти 87 тысяч "аномалий" и уверенность, что Service Desk полностью сломан. Но один разговор с опытным специалистом первой линии заставил меня выбросить половину критериев, переписать анализатор и полностью изменить выводы. Эта статья — о том, почему большие данные сами по себе ничего не объясняют, если сначала не понять сам процесс.

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

Это 2 часть материала про переход, 1 часть про самые распространенные заблуждения и ошибочные представления о системе 1С:ERP в статье https://habr.com/ru/companies/infostart/articles/1051952/

В апреле 2026 года глава Google Сундар Пичаи сказал, что 75% нового кода Google сгенерировано AI. Динамика: 25% в начале 2024 года, 50% к концу 2025 года, 75% к апрелю 2026 года.

Согласно Sonar 2026 State of Code Developer Survey, 96% разработчиков не доверяют функциональной корректности AI-кода полностью. 95% тратят время на его проверку, тестирование и исправление, а 38% считают такое ревью более трудоемким, чем проверку кода, написанного человеком. Генерация кода подешевела, контроль за ним - нет.

Thoughtworks в Technology Radar vol. 34 (апрель 2026) ввел термин codebase cognitive debt - разрыв в понимании между человеком и кодовой базой, который растет по мере того, как AI генерирует все больший объем кода.

Узкое место производственного процесса сместилось с написания спецификаций и кода на постановку задачи AI (intent) и контроль генерации (review): что именно должна делать система, в каких границах и кто проверяет, что AI-агент сделал именно это. Код производится быстрее, чем кто-либо успевает подтвердить его соответствие требованиям. Качество, стабильность и сопровождаемость держатся на том, кто и как организует постановку и проверку. Это зона ответственности архитектуры.

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

В этой статье я, Алексей Соболеков, архитектор решений, разберу изменение роли архитектора в агентной разработке. Я прошел три модели архитектурного процесса.

Настоящая статья написана под влиянием двух статей М.Ю. Коренюгина, являющегося управляющим директором компании BMGI, автор-разработчиком методологии ADAPT, мастером черного пояса по Lean – Six Sigma (General Electric): «Тензорное управление: критический взгляд на парадигмы менеджмента. Часть 1», опубликованной в журнале «Методы менеджмента качества», № 5, 2026 г., и «Тензорное управление: критический взгляд на парадигмы менеджмента. Часть 2», опубликованной в журнале «Методы менеджмента качества», № 7, 2026 г. Обе статьи поражают глубиной проработки, логичностью построений и выводов, а также высокопрофессиональными знаниями автором темы, которой они касаются.

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

Что такое тензор?

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

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

Одна из особенностей, выделяющих роль системного аналитика среди всего многообразия позиций в ИТ, —  его зона ответственности, а точнее — границы этой зоны. Поскольку он находится на стыке разработки и бизнеса (не говоря о том, что часто выступает в роли интегратора, Delivery manager, Product manager, Scrum master, архитектора и так далее), лучше всего эту работу можно описать картинкой ниже.

Время от времени в руки SA попадают «непрофильные» задачи, которые могут стать настоящим вызовом, выковать характер или причинить ментальные муки. Но чаще все вместе.

И снова привет, Хабр! На связи Александр Малышев, лид SA в МТС Cashback. Это продолжение истории про «рыцаря системной аналитики без страха и упрека» в которой я рассмотрел дилемму изменчивости требований. Вторая часть посвящена зоне ответственности SА. Так как вопрос довольно непростой, то я решил подать его в нетипичной для Хабра и юмористической форме — стихотворной истории в духе народных сказок.Тем, кто хочет немного отвлечься от рутины — желаю приятного чтения!