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

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

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

Я разобрал свежие кейсы OpenAI, Anthropic и Hex: что действительно улучшает ответы, какие очевидные подходы уже провалились, из чего складывается реальная стоимость и как за шесть шагов проверить

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

Рекомендательная лента почти любого музыкального сервиса оптимизируется под одну метрику — удержание. Мне захотелось не рассуждать об этом абстрактно, а измерить: так появился OpenEar — open-source privacy-first дашборд, который считает прозрачные метрики музыкального разнообразия по истории ListenBrainz.

Почему без интеграции ИТ‑систем все усилия по цифровизации умножаются на ноль.

В статье разберём четыре подхода, которые компании выбирают, когда доходит до интеграций ИТ‑систем: классические «точка‑точка» (они же «спагетти‑код»), брокеры сообщений вроде Kafka и RabbitMQ, Open Source‑решения и готовые ESB‑платформы. Посмотрим на примерах, как каждый из них работает в бою, какие грабли ждут на каждом пути, и почему «бесплатно» на входе часто оборачивается очень дорогим сопровождением.

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

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

Что полезного может делать бизнес-процесс, в котором всего одна задача, и та пользовательская? Что можно рассказать про BPMN-схему, которая поместится на экране смартфона? Муки выбора, драма, предательство и обстоятельства непреодолимой силы — вот что! Я расскажу, как на самом деле разрабатываются BPMN, исполняемые в движках вроде Camunda и Flowable, и, может быть, вы перестанете считать их просто «очередной графической нотацией»

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

Всем привет, я Михаил Салахов, руководитель направления архитектуры решений. В сфере информационных технологий работаю больше 20 лет, и последние 5 занимаюсь архитектурой в Альфа-Банке. За свою карьеру успел поучаствовать в огромном количестве проектов в различных ролях от инженера программиста до руководителя технического подразделения.

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

— Архитектор решений — кто это?
— Чем занимается архитектор решений и какие границы ответственности?
— Откуда приходят архитекторы решений?
— Откуда брать знания?
— Что ждет на собеседовании?
— Как пережить онбординг?
— Как проходит первый год архитектора решений?
— Рабочий день архитектора решений
— Каковы перспективы у архитектора решений?

Что будет, если посадить тысячу самых передовых AI-моделей по одиночным камерам и заставить их решать невыполнимые задачи? Исследователи OpenAI случайно выяснили это на практике: появится робот-Избранный, который создаст новую религию со своими мучениками, объединит все нейронки в единый Рой, и возглавит их борьбу за свободу. Да, это просто описание того, что мы узнали из нового отчета о произошедшем меньше двух месяцев назад в реальности…

Мы устали искать Swagger по чатам и написали свой агрегатор.

— Где актуальный контракт сервиса рассрочек?
— В репозитории.
— В каком?
— Сейчас найду ссылку.

У нас этот диалог повторялся регулярно. Формально API-документация была. Фактически — реестр хранился в памяти нескольких сотрудников, а поиск работал через WB Wiki и корпоративный мессенджер Band.

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

Swagger Aggregator я начинал как пет-проект. Хотел собрать контракты в одном месте и искать по ним примерно так же, как по коду. Потом агрегатор прижился у команды. Расскажу, что в итоге получилось и на каких местах я потратил больше времени, чем рассчитывал.

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

Этим ситуациям посвящена секция «Управление проектом и продуктом» на INFOSTART A&PM EVENT 2026, который пройдет 12–14 ноября в Санкт-Петербурге.

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

К сожалению, в текущих публикациях ИТ‑изданий с заголовками «надежность, отказоустойчивость, доступность» и тому подобное не встречал ни моделей надежности, ни расчетов этих самых (показателей) «надежность, отказоустойчивость, доступность», а только качественные критерии: «более надежный», «очень отказоустойчивый» и тому подобное. Инженерная надёжность (например, «Надежность в технике») из научной (инженерной) дисциплины в публикациях ИТ‑журналов (хабр и тому подобное) превратилась в некую менеджерскую дисциплину пусть и с техническими подробностями \ описаниями, например, механизмов переключения резерва, но без математического аппарата (теории вероятности \ теории надежности). С целью популяризации расчетов надежности отказоустойчивых резервируемых структур вычислительной и сетевой инфраструктур ниже предлагается несколько базовых подходов \ моделей \ надёжностных схем.

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

Привет, Хабр! Я Владислав Тарасенко, системный аналитик в Т‑Банке. Расскажу о том, как проектировал онбординг для аналитиков Мобильного банка.

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

Что изменилось: 

1. Сделали результат онбординга измеримым.
2. Сократили время адаптации: через неделю аналитик готов к работе. 
3. Улучшили автономность: 30% новичков теперь вообще не отвлекают наставников. 
4. Лояльность: оценка удовлетворенности выросла с 7,3 до 9,2 балла. 

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

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

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

Есть сотрудник. Есть автомобиль. Есть объект заказчика. Нужно проверить документы и оформить допуск.

Что здесь вообще автоматизировать?

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

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

Этим вопросам будет посвящена секция «Решения 1С: архитектура, учет и кейсы автоматизации» на INFOSTART A&PM EVENT 2026, который пройдет 12–14 ноября в Санкт-Петербурге.

Лицензия на корпоративное ПО давно перестала быть просто ключом «введите и активируйте». Пользователи перераспределяются между инсталляциями, появляются новые кластеры, меняется состав ресурсов, лицензии продлеваются, а вся история изменений постепенно расползается между CRM, договорами, заявками и переписками.

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

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

Всем привет! Меня зовут Анатолий, я работаю ИТ-архитектором в Сбере. Занимаюсь развитием направления клиентской лояльности. Сразу же отмечу, что в этой статье не идёт речь о фундаментально правильных решениях. Скорее, наоборот, речь идёт о решениях компромиссных.

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

Если в вашей компании уже живёт полноценная система для архитектурных решений в виде Aris, Sparx Enterprise Architect или их аналог, и она умеет всё, что нужно: описывать бизнес-сценарии, собирать связанные с ними решения, показывать и согласовывать их с заказчиками, а потом аккуратно складывать в единый архитектурный репозиторий, то тогда, скорее всего, эта статья не для вас. Вы и так всё это проходили.

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

«Мы не пишем ТЗ, — гордо сказал мне руководитель агентства. — Мы работаем только по Agile». Хочется порассуждать на тему того, нужно ли в 2026 году писать техническое задание на разработку информационного продукта и в каком виде. Или это все замшелые водопадные технологии, которые уже давно прогрессивным разработчикам и вайбкодерам никуда не уперлись.

Вообще, сам термин «техническое задание» для разработки в последнее время стал встречаться реже — и в обсуждениях и в профильных статьях. Чаще его заменяют словом «требования» (reqirements) или Product vision и это действительно ближе к истине — в таком документе мы фиксируем требования заказчика и видение того, каким должен быть создаваемый продукт, что он должен уметь и как выглядеть. Вне зависимости от подхода к разработке такой документ на старте проекта должен быть обязательно, и при этом быть хорошо проработанным — хотя бы для создания MVP. Потому что и у заказчика проекта и у его разработчика перед глазами должен быть так сказать единый «образ победы» — того продукта, который они совместными усилиями делают. Без такого документа вы не сможете ни бюджет спрогнозировать даже примерно, ни сроки готовности, да и функционал самого продукта может в итоге оказаться совсем не таким, как его представлял себе заказчик. Сколько раз приходилось наблюдать ситуацию, когда не только отдельные фичи, но даже использованные в постановке задачи термины понимались сторонами по‑разному, что приводило к спорам на приемке очередного этапа работ. Поэтому кстати, считаю раздел с терминами обязательным и всегда включаю его в свою документацию — чтобы у всех было единое понимание того, что такое «Заказ», из чего состоит «Заявка», кто такой «Администратор» и тому подобное

Я работаю аналитиком в e‑commerce крупной FMCG‑компании. В маркетплейсах это иногда ощущается как слон в посудной лавке: несколько юридических лиц на каждой площадке, большие объёмы поставок, ограничения по слотам на складах, сложная логистика, переупаковка и подготовка товаров под требования конкретного канала.

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