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

Все любят истории о сильных личностях. Про Туполева, Королёва, Стива Джобса, Сергея Брина, Марка Цукерберга. Про Нила Армстронга, который сделал «один маленький шаг для человека — и гигантский скачок для человечества». Про Юрия Гагарина, который первым полетел в космос.

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

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

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

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

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

В конце мая 2026 года СМИ узнали о том, что сервис «Островок», позволяющий быстро бронировать гостиницы и апартаменты, может перейти к МКПАО «Яндекс». Отечественный техногигант хочет приобрести проект за 15 млрд рублей, при этом собственники сайта планируют продать его за 20 млрд. Об истории сервиса и его патентом портфеле — подробнее в сегодняшнем материале.

Всем привет! Я Антон, системный аналитик из команды трансграничных переводов в Uzum Fintech, и от меня уже два месяца ждут текст по результатам выступления на внутреннем митапе.

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

Всем привет! Меня зовут Иван Привалов, я разработчик в команде BI Авито Финтеха и в этой статье расскажу, как мы сделали FIFO-сопоставление между N начислений и M списаний для бонусов. Заодно покажу подвох, без которого SQL быстро превращался в тыкву.

Статья будет полезна аналитикам и data-инженерам уровней мидл+, которые работают с финансовыми данными в Trino, Presto и Spark SQL.

Привет! Я Мария, и сегодня я пишу не как руководитель направления в ИТ-компании, а как создатель и администратор dating-сообщества в Telegram для спортсменов-любителей.

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

С ростом количества участников пришли классические ИТ-вопросы: где хранить данные, что считать актуальной версией анкеты, как организовать поиск, нужен ли отдельный каталог и где находится source of truth.

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

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

Самые интересные новости финансов и технологий в России и мире за неделю: дело о пропавшей Набиуллиной, ГосVPN для разрабов, разблокировка Roblox, в Европе начали повышать процентную ставку, OpenAI подали заявку на IPO, нёрд-эксортницы в Калифорнии, а также российский суд на защите нейрослопа в дипломах.

Меня зовут Денис, я бизнес-аналитик. Статья про то, как я построил себе рабочий инструмент — Custom Tool — который живёт прямо в браузере, ничего не требует устанавливать и помогает не забыть ни одного важного вопроса при разборе задачи.

Ссылка на инструмент: denissadykov.github.io/ba-cheatsheet/custom
Всё открыто, бесплатно, без регистрации.

Я работаю в компании GlowByte, а в целом в ИТ – более 20 лет. В последние годы в основном занимаюсь проектами и решениями в области AI, аналитики, больших данных, но приходилось иметь дело с большим списком разнообразных ИТ-услуг и форм взаимодействия заказчиков и подрядчиков. По роду деятельности мне приходится много заниматься подготовкой, оценкой, запуском ИТ-проектов. Очень часто нормально проведенное предпроектное обследование становится залогом успешного проекта, поэтому решил, что мои мысли про предпроект, его цели и подводные камни могут быть интересны аудитории. 

Привет! Я — Мария, руководитель направления автоматизации процессов управленческого учета, бюджетирования и контроля расходов.

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

Со стороны это выглядит странно: автоматизация есть, а полноценного бюджетного контроля нет.

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

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

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

Подключили маркетплейсы, развили e-commerce, добавили доставку день в день — и нагрузка выросла не линейно. Выручка может прибавить 30–40%, а количество складских операций — в 2–3 раза. Бизнес видит рост продаж. Склад видит больше строк, коробок, этикеток, статусов, возвратов и срочных уточнений.

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

Эта статья — о том, почему быстрый оборот ломает медленный склад, какие участки проседают первыми и что менять, чтобы склад выдерживал рост без ежедневного героизма.

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

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

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

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

Поэтому я сделал BA Toolkit — набор интерактивных инструментов для структурирования BA-встреч. Открываешь в браузере, идёшь по шагам, фиксируешь всё на месте.

Три месяца спустя — три инструмента в продакшене, открытый код на GitHub и эта статья.

Привет, Хабр! Я Анастасия Глущенко, бизнес‑аналитик направления BI в компании «ДАР» (ГК «КОРУС Консалтинг»). Люблю красивый, сочный визуал, а также яркие и емкие метафоры — короче говоря, я та еще сказочница. В этой статье я расскажу о сказочных персонажах и ситуациях, которые встречаются на пути аналитика. Ведь всем знакома фраза «пойди туда — не знаю куда, принеси то — не знаю что»?

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

Команда CRM-платформы «Модус» от ИТ-холдинга Т1 переводит руководства пользователя и администратора из Confluence в Docs as Code. Задача — связать документацию с релизами продукта, сократить ручную сборку и сделать так, чтобы аналитики могли писать в Markdown без боли.

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

Привет! Это вторая статья из цикла о 6 базовых понятиях бизнес-анализа по BABOK.

В прошлой статье мы разобрали первое базовое понятие BABOK — Заинтересованные стороны (ЗСт) Шесть основ бизнес-анализа: начинаем с вопроса «Кто в игре?» / Хабр. Мы выяснили, что каждый проект начинается с вопроса «кто в игре?». Но как только мы собрали нужных людей в рабочую группу проекта, перед нами встает следующий, не менее критичный вызов: что на самом деле нужно бизнесу?

По данным исследований PMI (Pulse of the Profession, 2023), около 37% проектов терпят неудачу именно из-за неточно сформулированных требований, в основе которых лежит непонимание истинной потребности бизнеса. Иными словами, проблема системная и дорогостоящая.

Бизнес-аналитик может идеально собрать требования, разработчик написать код, а тестировщик протестировать его, но в итоге получится решение, которое не удовлетворяет ни одну из потребностей бизнеса. Чтобы не наступить на эти грабли, разберем второе базовое понятие BABOK в этой статье — Потребность (Need).

Всем привет! На связи снова Никита Таскин и Анастасия Ильина. Продолжаем тему о контроле доступа применительно к системным интерфейсам, и на этот раз речь пойдёт об API. Напомним, что первая часть была про авторизацию UI, и ознакомиться с ней можно здесь. У нас всё так же разбор контекста ABAC-авторизации для управления задачами команд разработки в Сфера.Задачи. В этот раз мы глубже окунёмся в архитектуру и спроектируем решения для разных по сложности вариантов атрибутного контроля. Также посмотрим на другой вариант применения нашего экспериментального подхода «постанализ юзкейсов».

Привет, Хабр!

На связи команда Дирекции автоматизации девелопмента ПИК — Маргарита Золотых и Ольга Абражевич. В этой статье нам хотелось бы обсудить, какие аналитики будут востребованы в реалиях 2026 года и как найти себя в профессии тем, кто вырос до позиции Senior. С одной стороны, однотипное описание требований и фиксация чужих решений аналитикам становятся неинтересными. С другой стороны, компаниям с приходом доступных ИИ-инструментов и в тренде на оптимизацию бюджетов такой посредник становится нужен все меньше. 

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

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

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

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

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

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