Иван Кузнецов | БизнесМатика

Самое сложное в LLM-проекте не языковая модель, а данные и проверки вокруг нее. Как мы сделали поиск ИТ-специалистов по смыслу резюме, а не по совпадению ключевых слов

2026-06-20T14:25:10.382Z

БизнесМатика - это ИТ-компания на рынке с 2012 года. Мы внедряем проекты на базе языковых моделей (LLM) для компаний среднего и крупного бизнеса.

Один из наших LLM-проектов мы сделали для собственной работы. Это платформа "Телескоп", которая подбирает ИТ-специалистов под запросы клиентов. В ее основе поиск по смыслу. Система сравнивает смысл запроса клиента и смысл резюме, а не совпадение слов в них. Сейчас в ней больше 17 тысяч резюме, и мы подбираем через нее специалистов каждый день.

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

Клиент в запросе и кандидат в резюме часто называют один и тот же опыт разными словами

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

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

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

Как поиск по смыслу находит резюме, даже если слова в нем и в запросе разные

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

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

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

После векторного отбора языковая модель оценивает, насколько кандидат подходит под запрос

Векторный поиск находит резюме, близкие по смыслу, но не оценивает, насколько кандидат подходит на деле. Поэтому несколько резюме с наибольшей близостью к запросу дополнительно разбирает языковая модель. Она сверяет каждого кандидата с требованиями из запроса по шагам. Сначала смотрит роль, затем уровень, затем конкретные требования. Модель выдает балл соответствия, разбор по пунктам (что у кандидата есть из требований, а чего нет) и короткий вывод, стоит ли рассматривать кандидата дальше. Балл соответствия и близость векторов говорят о разном, и рекрутер видит оба. Близость векторов показывает, что резюме вообще про ту же специальность, а балл модели - насколько кандидат закрывает требования запроса.

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

Как устроен семантический поиск кандидатов по описанию вакансии

Как рекрутер видит скоринг кандидата в интерфейсе Телескоп

Под капотом. Эмбеддинги в PostgreSQL и поиск по смыслу в два этапа

Эмбеддинги мы храним и ищем по ним прямо в основной базе данных (PostgreSQL с расширением pgvector), без отдельного векторного хранилища. Так все живет в одной базе. Близость между вектором запроса и векторами резюме мы считаем по косинусной мере.

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

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

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

Что нужно, чтобы поиск по смыслу работал на реальном потоке, а не только на демонстрации

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

Качество резюме и запросов на входе. Модель не умнее текста, который вы ей даете. Резюме и запросы часто приходят в разном виде, поэтому перед поиском мы приводим их к сопоставимому виду. Без этого даже хорошая модель находит не тех кандидатов.

Способ сверить оценки модели с решениями рекрутеров. Многие внедряют модель и не проверяют, совпадают ли ее оценки с тем, как на деле поступают рекрутеры, берут кандидата в работу или отклоняют. Это частая ошибка. У тех, кого берут, медианная оценка модели заметно выше, чем у отклоненных. По нашей шкале это 80 против 65. Это не «точность» в строгом смысле, а признак того, что модель оценивает кандидатов в ту же сторону, что и рекрутер. Без такой сверки вы внедряете модель, не зная, совпадает она с людьми или нет.

Свежесть резюме и запросов. Со временем запросы закрываются, а резюме устаревают. Платформа сама убирает из поиска закрытые запросы и неактуальные резюме, чтобы не показывать их в результатах.

Где еще работает поиск по смыслу, кроме подбора

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

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

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

С чего начать, если у вас похожая задача

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

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

Генеративный ИИ в корпорациях: 4,4 трлн долларов мирового эффекта и как собрать свою долю в российском ритейле и FMCG

2026-05-06T08:06:36.496Z

Несколько месяцев назад внимание к теме генеративного ИИ снова резко выросло после очередного витка обсуждения оценки McKinsey: generative AI способен приносить мировой экономике от 2,6 до 4,4 трлн долларов в год. Для ритейла и товаров повседневного спроса потенциал отдельно оценивается в 400–660 млрд долларов в год, что делает сектор одним из главных бенефициаров новой волны автоматизации знаний и контента.

Но для российского CEO, COO или CIO эта цифра сама по себе почти бесполезна. Она не отвечает на главный вопрос: где именно эти деньги лежат в конкретном P&L — у сети супермаркетов, производителя напитков, DIY-ритейлера или e-commerce-платформы. В этом и состоит разрыв между мировым хайпом вокруг LLM и реальной корпоративной повесткой в России: глобально модели уже становятся инфраструктурой, а локально часто остаются пилотом, демонстрацией или «внутренней игрушкой» для энтузиастов.

Что на самом деле означают 4,4 трлн

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

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

Как мир внедряет LLM

Мировая статистика уже показывает, что тема давно вышла за пределы экспериментов. По данным McKinsey, 71% компаний используют generative AI хотя бы в одной функции, а чаще всего внедрение начинается с маркетинга, продаж и клиентского сервиса. В более широких обзорах по enterprise AI видно, что лидируют технологические компании, финансы, медиа, e-commerce и ритейл, а затем волна уходит в промышленность и смежные отрасли.

Важно и другое: под внедрением LLM в мире уже понимают не только чат-боты. Компании подключают модели к корпоративным знаниям, документам, BI-витринам, CRM и ERP, а затем строят поверх этого ассистентов для разных ролей — операторов, аналитиков, закупщиков, юристов, разработчиков и менеджеров категорий. То есть LLM становятся не приложением, а слоем инфраструктуры для работы с текстом, знаниями и кодом.

Почему ритейл и FMCG в центре этой волны

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

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

Где именно лежит ROI

На практике деньги чаще всего лежат в пяти группах сценариев.

Клиентский сервис и продажи

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

Контент и e-commerce

Карточки товаров, баннеры, промотексты, e-mail-цепочки, описания для маркетплейсов и персонализированные коммуникации — это один из самых очевидных и масштабируемых сценариев для generative AI. Для ритейла это означает ускорение time-to-market и рост объёма экспериментов без пропорционального увеличения штата контент-команд.

Аналитика и категорийный менеджмент

Категорийные менеджеры и аналитики тратят часы на сбор данных, объяснение отклонений, подготовку презентаций и справок для руководства. LLM позволяют перевести эту работу в диалоговый формат: быстро собрать отчёт, ответить на сложный вопрос по продажам или подготовить сводку по категории. В мировых оценках экономия времени на таких задачах нередко достигает 20–40%.

Back-office

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

IT и разработка

Code assistants и внутренние технические ассистенты ускоряют создание прототипов, документацию, тестирование и разбор legacy-кода. Для компаний, которые уже строят собственные ML-решения, это особенно важно: time-to-market сокращается, а стоимость следующего эксперимента падает.

Российский контекст: почему большинство застревает в пилотах

Российский рынок нельзя назвать пустым. По данным НИУ ВШЭ, около 29% российских предприятий уже внедрили AI-решения, а интерес к теме продолжает расти. Но именно generative AI и LLM в корпоративном секторе пока чаще развиваются как «островные» инициативы, а не как единая платформа.

Причины типичны:

· Данные разорваны между POS, e-commerce, CRM, ERP, складом, маркетплейсами и внутренними документами.
· Вопросы безопасности и регуляторики делают использование внешних моделей и API чувствительным.
· На рынке не хватает команд, которые умеют связать бизнес-кейс, архитектуру, данные и внедрение в одну систему.
· Импортозамещение усложняет использование привычных глобальных решений и требует более осознанного выбора стека.

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

Что работает в российской практике

Системный подход к ИИ в ритейле и FMCG уже показывает, что деньги в этих историях вполне реальные. В проектах по прогнозированию спроса, динамическому ценообразованию, персонализации, предиктивному обслуживанию и NLP российские компании уже получают измеримый эффект: рост выручки на единицы процентов, снижение out-of-stock, экономию десятков миллионов рублей на операциях и обслуживании. Этот результат возникает не потому, что «нейросеть всё решила сама», а потому, что ИИ встроили в процесс и привязали к бизнес-метрике.

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

От игрушек к фабрике решений

Ключевой разворот для российского бизнеса — перестать воспринимать LLM как набор разрозненных экспериментов. Рабочая модель — это не десять независимых пилотов, а единый слой, через который подключаются модели, корпоративные данные, права доступа, логирование, контроль качества и повторно используемые компоненты.

Практически это означает простой, но жёсткий принцип: двигаться не от модели к применению, а от ROI к API. Сначала определяется, где именно в компании лежит эффект — в клиентском сервисе, e-commerce-контенте, аналитике, back-office или ИТ. Затем выбираются 3–5 сценариев с понятными KPI и готовностью данных. Только после этого имеет смысл проектировать архитектуру, выбирать модели, строить RAG, LLMOps и контур безопасности.

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

С чего начать российской компании

Практика показывает, что рабочая последовательность выглядит так.

1. Провести диагностику зрелости: стратегия, данные, технологии, люди, процессы, governance.
2. Выбрать 3–5 LLM-сценариев с понятным эффектом и доступными данными.
3. Сделать короткие PoC на 8–12 недель с заранее согласованными KPI.
4. Спроектировать LLM-слой: модели, RAG, интеграции, доступы, логирование, мониторинг.
5. Перевести успешные кейсы в операционный контур и изменить регламенты под новую реальность.

Без первого шага компания запускает пилоты вслепую. Без четвёртого и пятого остаётся с коллекцией интересных экспериментов, которые так и не дошли до P&L.

Зачем здесь нужен ИИ-аудит

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

Поэтому логичной отправной точкой становится ИИ-аудит. Он помогает оценить зрелость по шести измерениям, приоритизировать AI- и LLM-сценарии, оценить экономический потенциал и наметить дорожную карту на 6–12 месяцев. Такая работа не подменяет внедрение, но позволяет перестать спорить о хайпе и начать говорить о деньгах, архитектуре и сроках.

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

Больше практических кейсов и разборов по ИИ в ритейле и FMCG публикуется в Telegram-канале БизнесМатики

RAG для корпоративных данных: почему без него ваш «корпоративный ChatGPT» не принесёт денег

2026-05-05T19:33:14.972Z

Я наткнулся на материал о Retrieval-Augmented Generation, где автор честно написал: «LLM без доступа к вашим данным — дорогой собеседник, а не бизнес-инструмент».

Мне это очень откликнулось, потому что в БизнесМатике мы видим один и тот же сценарий: компания запускает «корпоративный ChatGPT», показывает красивое демо, а через месяц у проекта нет ни пользователей, ни понятного эффекта.

В этой статье я разберу, как на самом деле устроен RAG для корпоративных данных, почему без него LLM в бизнесе почти всегда остаётся игрушкой для демо и какие решения нужно принять C-level и IT, чтобы превратить GenAI в новый слой вашей архитектуры — с измеримыми цифрами по выручке и издержкам, а не только с презентациями.

Корпоративный ChatGPT, который никому не нужен

Сценарий, который я слышу от CIO и Head of Data последние полтора года, почти всегда одинаковый.

«Нас попросили сделать корпоративного ChatGPT. Мы развернули модель, прикрутили интерфейс, загрузили туда пару внутренних документов. Все порадовались на демо. Через пару недель никто не пользуется. Что мы сделали не так?».

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

Модель отлично пишет по-человечески, но не знает, как у вас реально устроены скидки, SLA по доставке, бонусы персоналу и оформление возвратов для ключевых клиентов. В лучшем случае ей скармливают несколько PDF из портала. В худшем — она отвечает «как в интернете» по общим best practices, которые мало связаны с вашей реальностью.

Сотрудники это чувствуют очень быстро:

- на общие вопросы она отвечает красиво, но «ни о чём»;

- на конкретные — начинает фантазировать или цитировать устаревшие регламенты;

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

В результате:

- в отчётах остаётся единственный KPI — количество диалогов;

- ни CFO, ни операционный директор не видят эффекта в деньгах или FTE;

- после первых громких «галлюцинаций» по юридическим или комплаенс-темам доверие к проекту падает ниже нуля.

Проблема здесь не в LLM как таковой. Проблема в том, что мы не дали ей нормального доступа к корпоративному знанию — данным из CRM, ERP, DMS, тикет-систем, базам знаний и реальной истории кейсов. И вот на этом месте в игру входит RAG.

Что такое RAG простыми словами и зачем он бизнесу?

Retrieval-Augmented Generation звучит как термин из исследовательской статьи, но идея очень приземлённая.

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

RAG делает это с LLM.

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

На уровне бизнеса это воздействует на вполне конкретные показатели:

- В поддержке — сокращается время поиска ответа и доля эскалаций, растёт FCR и доля самообслуживания.

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

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

Нужно честно проговорить ограничение: RAG не исправит мусор в исходных данных.

Если у вас три противоречивые версии процесса, устаревшие регламенты и неопределённые источники «истины», ассистент аккуратно отразит этот хаос. Это не баг, а зеркало вашей архитектуры данных и процессов.

Архитектура RAG под капотом для корпоративных данных

На слайдах RAG часто выглядит как маленький блок «поиск по документам» рядом с LLM. В реальной корпорации это отдельный слой архитектуры. Давайте разберём его по частям.

Источники: от CRM до почты

Первый вопрос не про модели, а про то, где у вас живёт знание:

- CRM и тикет-системы — обращения клиентов, макросы и шаблоны ответов, кейсы по нестандартным ситуациям.

- ERP и отраслевые системы — статусы заказов, ценовые условия, схемы поставок.

- DMS/ECM, сетевые папки — договоры, политики, регламенты, инструкции, протоколы.

- Порталы, Confluence, SharePoint — статьи базы знаний, Q&A, внутренние FAQ.

- Почта и мессенджеры (там, где это допустимо) — ответы экспертов, которые так и не попали в формализованную базу.

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

Пайплайн подготовки: ETL и нарезка на фрагменты

Дальше нужен аккуратный пайплайн:

- коннекторы к системам (вплоть до выкачки через API и лог-шины);

- парсинг документов в нормальный текст (PDF, DOCX, HTML, почтовые треды);

- очистка: удаление мусора, оглавлений, дублей;

- нарезка на фрагменты — chunks объёмом от нескольких сотен до тысячи токенов.

К каждому фрагменту добавляются метаданные:

- тип документа (договор, инструкция, тикет);

- система-источник и версия;

- дата обновления;

- права доступа (роль, подразделение, уровень).

Именно эти метаданные потом позволяют:

а) не показывать сотруднику то, что он не должен видеть;

б) отдавать приоритет свежим и утверждённым версиям документов.

Векторизация и индексы

Следующий слой — векторные представления.

Каждый фрагмент прогоняется через модель эмбеддингов (как правило, отдельную от LLM), которая переводит текст в вектор. Фрагменты с близким смыслом оказываются рядом, даже если формулировки разные.

В реальных системах редко ограничиваются одним индексом. Логично делать несколько:

- по доменам («поддержка», «юристы», «HR»);

- по типам документов;

- по уровням конфиденциальности.

Это позволяет на этапе поиска сузить пространство и не смешивать, например, юридические документы с разрозненными письмами из почты.

Retrieval и ранжирование

Когда пользователь задаёт вопрос, происходит цепочка действий:

1. Вопрос преобразуется в вектор.

2. Система ищет ближайшие фрагменты в одном или нескольких индексах (approximate nearest neighbors).

3. Отфильтровывает результаты по правам доступа и другим бизнес-правилам.

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

Хороший RAG-слой умеет:

- отличать устаревший регламент от актуального;

- учитывать важные поля метаданных (тип документа, утверждённость);

- возвращать не один, а набор фрагментов, достаточный для уверенного ответа.

Здесь же появляется то, о чём редко говорят на демо: нужны метрики качества retrieval — хотя бы простые precision@k, доля успешных ответов по ключевым сценариям, список запросов, на которые система не смогла ответить.

Оркестрация и prompt

Всё найденное складывается в prompt вместе с вопросом и инструкциями:

- как отвечать (формат, тон, язык);

- что важно учитывать (правовые риски, политика по скидкам, ограничения по обещаниям клиенту);

- что делать, если контекста недостаточно («признайся, что не нашёл ответа»).

Здесь же живут:

- логирование и трассировка;

- feedback-loop от пользователей;

- A/B-тесты разных стратегий retrieval и разных моделей.

Безопасность и эксплуатация

Два наиболее болезненных места:

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

- Governance. Кто отвечает за качество ответов в юридических сценариях? Как вы реагируете на ошибочные ответы? Кто владеет данными, на которые опирается ассистент? Без ответов на эти вопросы RAG будет жить на ответственности одного энтузиаста из IT.

Где RAG даёт деньги: живые кейсы вместо гипотез

Теперь самое важное — где это всё превращается в деньги и FTE.

Ассистент поддержки в DIY-ретейле

В одном из проектов в DIY-сети мы делали ассистента для клиентской поддержки.

51 магазин, десятки тысяч SKU, клиентские обращения 24/7 — от статуса заказа до сложных вопросов по доставке, возвратам и гарантиям.

Под капотом это был классический RAG:

- коннекторы к CRM и базе знаний;

- векторный индекс по историческим обращениям и регламентам;

- retrieval релевантных кейсов и инструкций;

- LLM, которая из этого конструировала ответ понятным языком.

Что получилось по цифрам:

- до 35% обращений уходят в самообслуживание через ассистента без участия оператора;

- дежурная смена поддержки сократилась до 4 человек на 24/7, при этом качество ответа не просело;

- клиенты начали чаще пользоваться ассистентом именно потому, что он отвечал «как по регламенту компании», а не абстрактными фразами.

Это не косвенные эффекты вроде «инновационный имидж», а вполне осязаемые снижение нагрузки и экономия на FTE.

Внутренний поиск и онбординг

Те же принципы работают для внутреннего ассистента:

- сотрудники задают вопросы по HR-политикам, IT-процессам, операционным регламентам;

- ассистент поднимает из индекса актуальные статьи базы знаний, регламенты, Q&A;

- модель формулирует ответ, а при необходимости — даёт ссылки на исходные документы.

Главный эффект — снижение количества «мелких» вопросов к линейным руководителям и экспертам:

они перестают быть «ходячей базой знаний», а фокусируются на принятии решений, а не на раздаче ссылок.

Юристы и комплаенс

Для юристов и комплаенс-офицеров RAG-слой позволяет:

- искать нужные договоры и политики по смыслу, а не по названию файла;

- быстро собирать подборки релевантных кейсов под конкретный вопрос;

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

Важный момент: здесь RAG не должен принимать решения.

Он экономит часы на поиске и первичном анализе, но финальное слово остаётся за человеком, и это нужно явно зафиксировать в регламенте использования.

Почему 9 из 10 LLM-пилотов умирают без RAG

Если обобщить провальные истории, они почти всегда про одно и то же:

компания запускает не продукт, а демо.

Типичный паттерн:

- сделали «бота на LLM», показали демо на внутренних документах;

- не разобрались с источниками правды, качеством данных, governance;

- не договорились, какие процессы и метрики он должен менять.

В итоге:

- пользователи не понимают, когда ассистенту можно доверять, а когда нет;

- бизнес не видит, что меняется в SLA, FTE или выручке;

- IT остаётся «виноватым», хотя проблема в том, что проект вообще не был про архитектуру данных.

RAG-подход вынуждает задать неприятные вопросы:

- Какие 1–2 процесса мы хотим улучшить в первую очередь?

- Где живут данные, которые описывают эти процессы, и в каком они состоянии?

- Кто отвечает за эти данные и готов участвовать в проекте?

- Как мы будем измерять качество retrieval и ответы по ключевым сценариям?

Если таких ответов нет, даже очень хорошая модель не спасёт.

Без RAG и без работы с данными LLM в бизнесе будет оставаться игрушкой — красивой, но бесполезной.

Шаги для C-level и IT: от хайпа к новой архитектуре

Для C-level разговор про RAG — это не про модели и вендоров. Это про архитектуру и управляемый риск.

Для C-level

- Сформулируйте 1–2 приоритетных сценария: поддержка клиентов, юридические запросы, внутренний поиск.

- Привяжите их к цифрам: время обработки, доля самообслуживания, экономика FTE, NPS, скорость онбординга.

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

Для CIO, Head of IT, Head of Data

- Сделайте инвентаризацию источников знаний: системы, форматы, владельцы.

- Оцените техническую готовность: есть ли API, шина данных, DWH, где можно строить поверх RAG-слой.

- Определите архитектурные решения: on-prem или облако, open source или конкретный вендор, как это стыкуется с существующей IT-стратегией.

- Назначьте владельца RAG-продукта и договоритесь, как будет выглядеть выпущенная в прод версия, а не вечный пилот.

Без этого RAG-проект обречён жить в статусе «демо у энтузиаста».

С этим — он имеет шанс стать тем самым слоем доступа к корпоративному знанию, которым ежедневно пользуются сотни сотрудников.

Нативный следующий шаг: ИИ-аудит готовности к RAG и GenAI

Перед тем как выбирать стеки, подписывать контракты с вендорами и рисовать архитектурные схемы, полезно честно измерить, где вы находитесь. Не в смысле «мы верим в ИИ», а в смысле готовности к RAG и GenAI по конкретным измерениям.

Формат, который мы хорошо обкатали, — короткий ИИ-аудит готовности:

- за неделю мы смотрим на шесть измерений: стратегию, данные, технологии, людей, процессы и governance;

- фиксируем, какие данные реально доступны для RAG и в каком они состоянии;

- оцениваем риски по безопасности и качеству;

- собираем карту потенциальных RAG-кейсов и прикидываем для них эффект (экономия FTE, ускорение процессов, влияние на выручку).

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

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

А если хочется глубже разбираться в архитектурах RAG, кейсах и ограничениях GenAI в реальном бизнесе — у нас есть Telegram-канал, где мы честно разбираем такие истории и без розовых очков, и без апокалипсиса.

ИИ съел бюджет и не подавился: почему 7 из 10 пилотов в ритейле не доходят до продакшена

2026-05-04T14:06:31.394Z

Недавно наткнулся на статью о том, как 9 из 10 ИИ‑проектов так и не доходят до промышленной эксплуатации. Это редкий случай, когда топ‑менеджер не продаёт очередной «магический ИИ», а честно говорит: проблема не в нейросетях, а в том, что у бизнеса нет инфраструктуры, порядка в корпоративных знаниях и нормального MLOps. Для ритейла это не абстрактная аналитика, а очень точное описание того, что происходит внутри большинства компаний, которые уже «занимаются ИИ».

Картина неприятная. Бюджеты на ИИ есть, пилоты есть, красивые демо для совета директоров есть. Нет только системного эффекта на P&L по ключевым контурам: учёт, планирование, управление товарными запасами, оборотный капитал. Ниже разберу, почему 7 из 10 пилотов в ритейле объективно не имеют шансов выжить, и что меняется, когда компания сначала наводит порядок в данных, инфраструктуре и MLOps, а уже потом запускает ИИ‑инициативы.

«ИИ‑пузырь» как диагноз

Колонка цепляет именно потому, что совпадает с тем, что рынок видит на практике. Она говорит об очевидном, но обычно замалчиваемом факте: 9 из 10 ИИ‑инициатив не становятся промышленными системами, а застревают на уровне пилотов или обсуждений. Параллельные оценки российского рынка подтверждают ту же логику: более 80% ИИ‑проектов не достигают целей при внедрении.

Если убрать отраслевые детали, это почти дословное описание ритейла. Сети запускают пилоты по прогнозу спроса, оптимизации запасов, динамическим ценам, персонализации, чат‑ботам и ИИ‑ассистентам, но в операционной реальности всё остаётся по‑старому. Списания по фрешу почти не меняются, out-of-stock по ключевым SKU остаётся хронической проблемой, а оборотный капитал по‑прежнему заморожен в избыточном стоке. Каждый такой пилот — это не только прямые расходы, но и год упущенного эффекта, который можно было получить в рабочем контуре запасов и планирования.

Портфель пилотов, которые не меняют бизнес

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

Типичный сценарий выглядит так. Модель по прогнозу спроса честно показывает хорошую точность на истории, но закупки продолжают делать «по прошлому году плюс X%» и ощущениям категорийщика. Алгоритм ценообразования выдаёт рекомендации, но категорийная команда правит всё руками, потому что не доверяет модели или не встроила её в процесс. Снаружи это выглядит как «инновационный ритейлер внедряет ИИ», а внутри — как набор R&D‑экспериментов без дороги в продакшен и без влияния на метрики бизнеса.

Почему пилоты умирают

Основных причин три: инфраструктура, хаос в данных и знаниях, отсутствие MLOps и ownership.

Инфраструктура

Путятинский отдельно указывает на отсутствие DLP, ИИ‑шлюза и нормальных регламентов. В ритейле это означает, что данные под пилот выгружаются разово, ИБ‑служба тормозит любую попытку промышленного использования, а интеграция с ERP, WMS или TMS превращается в отдельный незапланированный проект. В таких условиях даже хороший пилот физически не может стать промышленной системой, потому что у него нет стабильной и безопасной среды для жизни.

Данные и знания

У большинства ритейлеров ERP, WMS, TMS, касса, e‑commerce, CRM, маркетинг и Excel‑таблицы живут в разных мирах. Нет согласованных справочников, нет цельной истории по SKU, нет витрин данных, которые можно быстро использовать для ИИ‑контуров запасов, спроса и цен. Плюс значительная часть реального знания о принятии решений по заказам и акциям находится в головах людей, а не в системе. В итоге модель либо нечем обучать, либо её результат некуда встроить так, чтобы по нему реально начали работать.

MLOps и ownership

Третья причина — отсутствие промышленного контура сопровождения модели. Очень часто модель живёт в ноутбуке data scientist, а максимум — в отдельном контейнере без понятной схемы обновления, мониторинга и контроля качества. Нет CICD для ML, нет процесса отслеживания деградации, нет владельца на стороне бизнеса, для которого эта модель — рабочий инструмент, а не «чужой проект из IT». В такой конструкции пилот завершить можно, а продукт — нельзя.

Как мы в БизнесМатике делаем иначе

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

Подход выглядит так:

• Сначала считаем бизнес‑кейс: сколько компания теряет на списаниях, сколько денег заморожено в запасах, сколько стоит out-of-stock по ключевым SKU.
• Затем проводим ИИ‑аудит готовности: стратегия, данные, технологии, люди, процессы, governance.
• Только после этого запускаем PoC с целевой архитектурой, MLOps‑контуром и закреплённым владельцем со стороны бизнеса.

Этот путь менее эффектно продаётся как «быстрый эксперимент», зато именно он позволяет доводить проекты до продакшена и измеримого результата.

Кейсы, где ИИ дошёл до продакшена

Практика показывает, что ИИ в ритейле работает, если работать по‑взрослому.

DIY‑сеть: ценообразование без Excel

В федеральной DIY‑сети с 50+ магазинами и около 15 000 SKU ценообразование велось в Excel, что замедляло реакцию на рынок и перегружало команду ручной работой. После консолидации данных, запуска ML‑модели ценовых рекомендаций и встраивания её в рабочий контур сеть получила рост маржинальности в ключевых категориях и снижение доли ручных операций. Здесь сработала не только модель, но и то, что рекомендации стали частью процесса, а не отдельной «аналитической игрушкой».

FMCG‑поставщик: прогноз спроса и меньше списаний

У крупного FMCG‑поставщика с портфелем около 1500 SKU, включая фреш, основной проблемой были списания и out-of-stock. После очистки данных, внедрения ML‑прогноза спроса и встраивания модели в процесс планирования точность прогноза выросла до 85–90%, списания по фрешу сократились на 17%, а out-of-stock снизился примерно на 5 п.п. Это уже не история про «интересный пилот», а про прямой финансовый эффект и высвобождение оборотного капитала.

Fashion‑ecommerce: рекомендации, которые влияют на выручку

У fashion‑компании с 120 магазинами и онлайн‑каналом базовые рекомендации почти не влияли на чек и конверсию. После построения Customer 360 и запуска рекомендательной модели рост выручки в задействованных сегментах составил 15–30%, а средний чек вырос на 7%. Этот кейс важен как доказательство того, что промышленный подход переносится и на другие ИИ‑контуры, а не только на запасы и спрос.

Где ИИ пока не взлетит

Есть ситуации, когда следующий пилот запускать не нужно.

•Если нет нормальной истории продаж и остатков, проект по прогнозированию или запасам обречён.
•Если нет владельца бизнес‑процесса, система останется «проектом IT».
•Если ERP, WMS, касса и e‑commerce не интегрированы, модели просто некуда встраиваться.
•Если компания ждёт от LLM‑агентов того, что ей пока может дать обычный supervised ML, она рискует заплатить за моду вместо результата.

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

Что делать дальше

Если у вас уже есть 5–10 ИИ‑инициатив, которые годами висят в статусе пилотов, самый разумный следующий шаг — не запускать ещё одну. Гораздо полезнее сначала понять, какие из текущих и планируемых проектов вообще имеют шанс доехать до промышленной эксплуатации и отбиться по экономике.

Для этого мы в БизнесМатике делаем ИИ‑аудит готовности. За одну–две недели он даёт:

•профиль зрелости по шести измерениям: стратегия, данные, технологии, люди, процессы, governance;
•карту use case’ов: какие проекты по запасам, планированию, ценам и промо стоит усиливать, а какие лучше заморозить;
•матрицу приоритизации и дорожную карту на 3–6 месяцев, чтобы ИИ начал работать на P&L, а не на имидж.

Этот аудит бесплатный и ни к чему не обязывает. На рынке, где 7–9 пилотов из 10 не доживают до прома, это самая дешёвая страховка от очередного «мертвого» проекта.

Если вы узнали себя в этой картине, можно начать именно с этого шага. А если хочется больше практики, кейсов и разборов по ИИ для ритейла и FMCG — загляните в Telegram‑канал БизнесМатики.

Cifra от ВТБ для ведения бухгалтерского и налогового учёта

2026-04-03T10:00:04.192Z

«Цифровая Бухгалтерия» - дочерняя компания ВТБ, которая развивает Cifra, мобильное приложение для ИП и малого бизнеса. Через него предприниматель ведёт учёт, видит налоги, формирует платежи и общается с бухгалтером, не загружая голову нюансами налогового законодательства.

Банк ВТБ работает с сотнями тысяч клиентов малого бизнеса и развивает отдельную линейку цифровых сервисов для предпринимателей (онлайн‑бухгалтерия, онлайн‑налог для АУСН, сервисы расчётного счёта и эквайринга). В этой экосистеме Cifra отвечает за повседневную финансовую «рутинную» жизнь предпринимателя - от учёта операций до уплаты налогов и отчётности.

В 2022 году Госдума запускает эксперимент по новой системе налогообложения - АУСН. С 1 июля вновь зарегистрированные налогоплательщики должны иметь возможность подать уведомление на новый режим через банк, где у них открыт счёт. Для ВТБ это означает одно: если банк не даст удобный цифровой сценарий, предприниматель уйдёт туда, где дадут.

Как не проиграть регуляторный дедлайн

Внутри ВТБ и «Цифровой Бухгалтерии» понимали, что АУСН - это шанс закрепить за собой сегмент предпринимателей, которым важна простота налогов.

Боль состояла из нескольких частей. Во‑первых, жёсткие сроки. Закон приняли в феврале, эксперимент стартует 1 июля, а требования и протоколы по АУСН ещё уточняются. Времени на долгие архитектурные дискуссии и спокойный набор людей нет, при этом от качества реализации зависит соблюдение закона.

Во‑вторых, нагрузка на команду. Существующая команда Cifra из 50+ специалистов уже ведёт свою дорожную карту: развитие учёта, интеграций, интерфейсов, поддержку текущих клиентов. Любая попытка «выдернуть» людей на АУСН грозит срывом других обязательств перед банком и пользователями.

Цель формулировалась так: к 1 июля предприниматель должен иметь возможность полностью пройти путь по АУСН внутри Cifra - от выбора режима до уплаты налога, без визитов в офис и без отдельного захода в личный кабинет ФНС. При этом приложение обязано строго соблюдать требования регулятора и устойчиво работать под нагрузкой.

Отдельный модуль банка внутри Cifra

Команда клиента решает разработать отдельный модуль банка в рамках Cifra. Этот модуль должен связать предпринимателя в приложении, инфраструктуру ВТБ и сервисы ФНС по АУСН.

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

За простым интерфейсом скрывается сложная архитектура. На backend‑стороне Cifra появляется несколько сервисов:

подсистема для работы с уведомлениями о переходе на АУСН и смене режима,
интеграционный контур с сервисом онлайн‑налога ВТБ и далее с ФНС,
сервис расчёта и отображения начислений по АУСН в самом приложении.

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

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

Кто делал проект

«Цифровая Бухгалтерия» изначально имела сильную внутреннюю команду: продактов, разработчиков, тестировщиков, UX, юристов и налоговых экспертов.

БизнесМатика усилила этот состав командой из семи специалистов: двумя системными аналитиками и пятью Java‑разработчиками.

Системные аналитики:

переводили язык закона и разъяснений ФНС в понятные диаграммы и требования к системе,
описывали процессы «клиент - Cifra - банк - ФНС»,
работали связующим звеном между юристами, продактами и разработчиками.

Java‑разработчики:

проектировали и реализовывали backend‑сервисы модуля АУСН,
настраивали интеграции с внутренними системами ВТБ и сервисами ФНС,
отвечали за устойчивость, логирование и соответствие требованиям безопасности.

Что получилось в итоге

К моменту запуска эксперимента по АУСН модуль банка в Cifra заработал в боевом режиме. Предприниматели получили возможность подключаться к новому режиму прямо из мобильного приложения, без похода в офис и без отдельной регистрации в сервисах ФНС.

Клиент достиг целей:

функционал АУСН реализован в рамках Cifra,
модуль банка запущен в обозначенный государством срок,
команда, собранная под проект, после запуска продолжила развивать другие цифровые сервисы ВТБ и «Цифровой Бухгалтерии».

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

Как клиент оценивает проект

Ниже - цитата от представителя «Цифровой Бухгалтерии».

Запуск АУСН стал для нас стресс‑тестом. Регуляторный дедлайн не оставлял права на ошибку, а собственная команда уже работала на пределе. Мы искали партнёра, который сможет быстро усилить нас людьми, но не привнесёт бюрократику и барьеры во взаимодействии.

Команда БизнесМатики очень быстро встроилась в наш продуктовый контур. Системные аналитики помогли перевести сложные требования по АУСН в понятные для разработчиков процессы, а Java‑разработчики закрыли самые сложные интеграции с банковскими системами и ФНС.

В результате мы запустили модуль АУСН в Cifra в срок и без болезненных для клиентов сбоев. Сегодня эти наработки используются не только в самом приложении, но и в других сервисах ВТБ для предпринимателей. Для нас это пример того, как аутстаффинг может работать не как «внешний подрядчик», а как часть команды продукта.

Мобильное приложение для домовладельцев: как Proscom вернул проект в график за три месяца с помощью аутстаффинга БизнесМатики

2026-04-03T09:39:08.456Z

Речь пойдет о цифровом сервисе для жителей и управляющей компании (рынок ЖКХ и «умных домов»), который дополняет существующие ИТ-системы девелопера и УК (биллинг, CRM, домофонная платформа).

Решение внедрено в одном из крупных жилых комплексов Москвы, сначала как пилот на части домов, а затем как стандартный канал обслуживания жителей.

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

Боль и цель клиента

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

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

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

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

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

Работы, этапы и длительность

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

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

Второй этап длился примерно шесть - восемь недель и стал периодом ускорения функциональной разработки. Часть внешней команды сосредоточилась на пользовательских сценариях - видеозвонки с домофона с возможностью открыть дверь, заявки в управляющую компанию, оплата ЖКХ, оформление цифровых пропусков для гостей; другая часть закрывала серверную логику и интеграции с биллингом, CRM и системой домофонии. Команда не меняла процесс Proscom, а работала в его рамках - общие спринты, единая Jira, ежедневные созвоны и общее ревью кода.

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

Параллельно Proscom готовил публикацию в сторах и коммуникацию с заказчиком, а разработчики БизнесМатики помогали оперативно закрывать замечания после первых пилотных пользователей.

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

Команда и роли

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

Три мобильных разработчика закрывали основной пользовательский фронт. Один отвечал за iOS-версию, второй - за Android, третий взял на себя общие компоненты и сквозную бизнес-логику, чтобы минимизировать расхождения между платформами и не плодить дублирующий код. Их зона ответственности включала не только новые экраны и сценарии, но и «грязную» работу - оптимизацию сложных экранов, исправление падений, выравнивание UX с готовым дизайном Proscom.

Фронтенд-разработчик БизнесМатики усилил веб-часть - административную панель для сотрудников управляющей компании и оператора домофонной платформы. Именно через этот интерфейс менеджеры видели обращения жителей, управляли объектами, связками домофон - квартира и могли вручную разруливать нестандартные ситуации, поэтому стабильность и удобство этой панели напрямую влияли на восприятие всего продукта.

Бэкенд-разработчик взял на себя узкое горлышко проекта - интеграции и API. Он приводил в порядок сервисы, отвечающие за аутентификацию, начисления, обработку видеозвонков и обмен данными с внешними системами девелопера, настраивал мониторинг и логирование, чтобы команда не работала вслепую.

Управление командой шло в два контура. Технические решения и приоритизация задач были на стороне Proscom: технический директор и тимлиды задавали архитектурные рамки и определяли, какие фичи идти делать в первую очередь для конечного заказчика. За найм, мотивацию и стабильную отдачу специалистов отвечала БизнесМатика, опираясь на свой опыт в аутстаффинге ИТ-команд.

Использованные технологии

Технологический стек не выбивался из практик Proscom и рынка мобильных приложений для жилых комплексов.

На стороне мобильной разработки использовали нативные технологии iOS и Android - Swift или Kotlin для ключевых клиентских приложений, с учетом интеграции с push-уведомлениями, камерами и стримингом видеосигнала от домофона. Это позволило выдержать требования по производительности и работе с камерой и видео, которые обычно предъявляют к таким приложениям жильцы и девелоперы.

Бэкенд строился на распространенных для Proscom технологиях из их открытого профиля - стек на базе Node.js и современных фреймворков уровня Nest.js, с GraphQL или REST API, PostgreSQL в качестве основной базы данных. Такой подход упрощал расширение системы под новые сервисы и интеграции, которые девелопер планировал добавлять после первого релиза.

Фронтенд административной панели был реализован на React.js, с компонентным подходом и интеграцией в существующий фронтовый стек Proscom. Это позволило быстро дорабатывать интерфейс под потребности операторов управляющей компании и не зависеть от редких специалистов.

Вокруг основного кода работал стандартный для подобных проектов набор инфраструктурных инструментов: системы трекинга задач и релизов, CI/CD-пайплайны, мониторинг ошибок и логов, которые БизнесМатика настроила и передала в поддерживаемом состоянии внутренней команде Proscom.

Отзыв клиента и изменения в работе людей

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

В формате отзыва история звучит так:

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

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

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

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

Цифра Брокер: оптимизация витрин данных

2026-04-03T09:12:05.887Z

«Цифра Брокер» - одна из крупнейших российских инвестиционных компаний, работающая на рынке более 13 лет и входящая в число заметных игроков по объему операций частных инвесторов. Компания развивает мобильное приложение и онлайн‑платформу, а за ними стоит брокерская АБС, торговые системы Московской и Санкт‑Петербургской бирж, внутренние CRM‑и DWH‑контур. Хранилище и витрины данных работают в связке с учетными системами, CRM и инфраструктурой риск‑менеджмента - от них зависят управленческие отчеты, регуляторная отчетность и аналитика по клиентам.

Оптимизация шла в боевом DWH, которое обслуживает брокерское направление (отчеты по клиентской активности, оборотам, комиссиям и позициям, а также витрины для продуктовой и риск‑аналитики). Уже в первые месяцы удалось в разы сократить время формирования ряда ключевых витрин данных.

1. С чем пришел клиент

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

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

2. Откуда брались данные и почему к ним были высокие требования

Хранилище данных брокера собирает информацию сразу из нескольких классов систем. Основной поток идет из учетных и торговых систем (сделки на Московской и Санкт‑Петербургской биржах, операции клиентов, остатки и позиции по счетам, тарифы и комиссии). Дополнительно загружаются CRM‑данные о клиентах, их сегментах, реакциях на продуктовые кампании. На стороне регуляторной отчетности присутствуют свои наборы требований к качеству и полноте данных.

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

3. Какое решение выбрали

Команда хотела сохранить существующее хранилище и доработать его так, чтобы оно выдерживало нагрузку и рост бизнеса. Поэтому выбрали точечное усиление команды через аутстаффинг Senior PL/SQL‑разработчика с опытом DWH‑проектов.

Система, вокруг которой строился проект, - это корпоративное DWH брокера, разделенное на стандартные слои: загрузка (staging), интеграционный слой и витрины данных для бизнес‑направлений. DWH интегрируется с брокерской АБС, торговыми системами бирж, CRM и контуром отчетности. Именно здесь находятся витрины данных - клиентские профили, торговая активность, комиссии, остатки и позиции, отчеты под регулятора.

Решение заключалось в пересборке критичных участков внутри этого DWH. В задачи вошло перепроектирование части витрин, переписывание PL/SQL‑процедур, наведение порядка в индексах и запросах, а также внедрение минимального, но рабочего мониторинга длительности процессов.

4. Как шли работы и сколько это заняло

Первые три с половиной месяца ушли на интенсивную фазу оптимизации. Работу разбили на короткие итерации: брали одну витрину или набор взаимосвязанных процедур, формулировали гипотезы по оптимизации (индексы, переписывание запросов, декомпозиция логики), согласовывали подход с внутренним DWH‑лидом и владельцами данных, а затем проверяли изменения на тестовом контуре.

После первых результатов формат работ эволюционировал. Аутстаффинг перестал быть чисто ресурсной историей - наш PL/SQL‑разработчик стал фактическим техническим лидом по части DWH‑инициатив. Проект перешел в режим долгосрочного сопровождения и развития.

5. Кто делал проект - команда и роли

Со стороны БизнесМатики в проекте участвует опытный PL/SQL Developer с фокусом на DWH‑проектах (оптимизация запросов, проектирование витрин, работа с большими объемами данных и высоконагруженными базами). Его задача была предлагать архитектурные решения, которые вписываются в реальность брокера.

6. На чем все это работает

Технологическая основа проекта - DWH на базе промышленной СУБД. Логика хранилища реализована на PL/SQL (хранимые процедуры, пакеты, триггеры, которые обрабатывают данные из источников и формируют витрины).

Для интеграций используются стандартные механизмы выгрузки из учетных и торговых систем, а также ETL‑процессы, перенаправляющие данные в staging‑слой DWH. В хранилище выделены несколько слоев - от сырых данных до агрегированных витрин для отчетности и аналитики.

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

7. Итоги

Наш PL/SQL‑разработчик, который работает над проектом с 2023 года, описывает специфику так:

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

Автоматизация бизнес-процессов разработки цифровых сервисов для отслеживания морского транспорта в проекте Sitronics Group

2026-04-03T08:22:49.528Z

Sitronics Group - российская технологическая группа, которая занимается цифровизацией стратегических отраслей, в том числе морской индустрии и судоходства. Компания развивает решения для мониторинга судов, обеспечения навигационной безопасности и контроля экологических рисков на базе спутниковых AIS‑данных и собственной инфраструктуры.

Конкретный продукт в кейсе - сервис мониторинга морских перевозок, который собирает данные со спутников с AIS‑датчиками (планировалось более 70 аппаратов к 2025 году) и позволяет государственным заказчикам, портам и крупным грузоотправителям видеть картину движения флота и оперативно реагировать на инциденты. Сервис интегрирован в ИТ‑ландшафт Sitronics Group рядом с отраслевыми аналитическими решениями и ситуационными центрами, в том числе в рамках разработки платформ для транспорта и умной инфраструктуры.

Два бизнес‑аналитика БизнесМатики вошли в продуктовую команду в феврале 2024 года и работали на стороне Sitronics Group как часть постоянной команды. По оценкам участников, за 9 месяцев удалось снизить долю возвратов задач по причине неясных требований примерно на 30–40% и ускорить согласование ключевых изменений до 5–7 рабочих дней для типовых сценариев.

Боль клиента

К моменту старта проекта Sitronics Group уже несколько лет развивала направление цифровых решений для морской отрасли, в т.ч. спутниковый мониторинг судов и навигационную безопасность. В 2022 году компания начала тестирование данных со спутников, оснащённых AIS‑датчиками, а к 2025 году планировала группировку более 70 таких аппаратов. Это создавало мощный поток данных и давало простор для новых сервисов - от контроля захода судов в охраняемые зоны до борьбы с загрязнением акваторий.

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

Руководство Sitronics Group определило узкое место - отсутствие устойчивого контура бизнес‑анализа вокруг продукта. Нужны были люди, которые разберутся в домене, выровняют ожидания стейкхолдеров и помогут сделать продукт предсказуемым.

Данные и интеграции

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

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

Качество данных и ограничения задавали серьёзную рамку. Спутниковые AIS‑данные могли приходить с задержкой, были зоны с плохим покрытием, часть информации относилась к режиму ограниченного доступа, а часть заказчиков использовала собственные внутренние классификаторы. Аналитикам приходилось строить модель требований так, чтобы система корректно работала в условиях неполных или шумных данных, при этом не нарушала требования по безопасности и конфиденциальности.

Наши аналитики у клиента

Решение Sitronics Group состояло в том, чтобы не переписывать продукт с нуля, а усилить его за счёт зрелого бизнес‑анализа. Два бизнес‑аналитика БизнесМатики вошли в существующую продуктовую команду и стали связующим звеном между функциональными заказчиками, отраслевыми экспертами, продакт овнером и разработчиками. Их зона ответственности охватывала весь цикл - от интервью до приёмочных тестов.

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

В ИТ‑ландшафте Sitronics Group этот сервис стал одним из ключевых элементов цифровых решений для морской отрасли - он интегрировался с аналитическими панелями, ситуационными центрами и смежными системами мониторинга, которые группа развивает для транспорта и «умных» инфраструктур. Задача аналитиков была в том, чтобы каждое изменение в продукте имело понятное место во всей этой экосистеме.

Этапы работ и длительность

Проект с участием БизнесМатики стартовал в феврале 2024 года и развивался в несколько этапов. На первом этапе аналитики погрузились в домен: провели серию интервью с представителями портов, регуляторов, внутренних подразделений Sitronics Group и техническими лидерами. Целью было не просто собрать пожелания, а reconstruировать реальные сценарии - от ежедневного мониторинга до работы в инцидентных ситуациях.

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

Третий этап был уже про устойчивый режим. Аналитики участвовали в планировании и grooming‑сессиях, сопровождали задачи от формулировки до приёмки, готовили демо для функциональных заказчиков и фиксировали обратную связь. За первые 9 месяцев сотрудничества удалось пройти несколько релизных циклов и обкатать новый процесс на реальных поставках функционала.

Команда и роли

Ключевая особенность проекта заключалась в том, что аналитики не остались внешними консультантами. Sitronics Group встроила их в продуктовую команду на правах постоянных участников. Один аналитик фокусировался на внешнем контуре (заказчики, регуляторы, отраслевые эксперты), второй - на внутреннем (бэклог, документация, взаимодействие с разработкой и тестированием).

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

БизнесМатика, в свою очередь, обеспечивала методологическую поддержку. Аналитики могли опираться на внутренние практики компании, делиться опытом с коллегами, но при этом оставались частью ежедневной жизни продуктовой команды Sitronics Group. Это сочетание помогло быстро адаптировать лучшие практики к специфике конкретного продукта.

Технологический стек и подходы

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

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

С точки зрения безопасности и соответствия требованиям, решения Sitronics Group опирались на опыт компании в импортозамещении навигационных аппаратно‑программных комплексов и цифровизации стратегических отраслей. Для продукта это означало, что аналитики описывали требования не в отрыве от регуляторики, а с учётом отраслевых норм и практик.

Результаты и как их считали

Эффекты от усиления бизнес‑анализа команда почувствовала довольно быстро, хотя формальное измерение заняло несколько месяцев. В качестве базовой метрики Sitronics выбрала долю задач, возвращающихся в доработку по причинам, связанным с требованиями (например, «не учли сценарий», «неверно поняли ожидания заказчика»). Здесь за счёт стандартизации требований и глубинной работы с заказчиками долю возвратов удалось снизить примерно на 30–40% по сравнению с началом года (по внутренним оценкам команды за 9 месяцев наблюдений).

Второй важный показатель - скорость согласования ключевых изменений. До начала проекта обсуждения новой функциональности могла затягиваться на недели из‑за отсутствия единой картины требований. После внедрения практик регулярных сессий уточнения и визуализации процессов типовые изменения стали проходить цикл согласования за 5–7 рабочих дней, а сложные межведомственные сценарии - за 10–15 дней. Измеряли это по фактическим датам постановки задач и утверждения формулировок с заказчиком.

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

Риски и вызовы

Главный вызов для аналитиков заключался в доменной сложности. Морская навигация, спутниковые AIS‑данные, экологические ограничения, требования безопасности - всё это требовало большого объёма погружения, причём часть информации находилась под ограничениями доступа. Команда решила этот риск через систематичную работу с экспертами: серия интервью, совместное моделирование процессов, регулярная валидация сценариев.

Второй риск был связан с количеством стейкхолдеров. Порт, регулятор, служба безопасности, внутренние подразделения Sitronics - у каждого свои приоритеты и язык описания проблем. Здесь помогла матрица стейкхолдеров и жёсткая дисциплина требований: каждое изменение связывали с понятной бизнес‑целью и заранее обсуждали компромиссы.

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

Отзыв клиента

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

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

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

Дальнейшие планы

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

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

Hyundai Mobility — разработка первого в России онлайн-сервиса подписки на автомобиль

2026-04-03T07:54:52.175Z

1. О чем кейс

Hyundai Mobility Lab - дочерний цифровой бизнес Hyundai, который делает в России сервис подписки на автомобиль. Это живой продукт, который стоит в центре большой IT‑экосистемы (учет автомобилей в ERP, клиенты и коммуникации в CRM, биллинг, платёжные шлюзы, мобильное приложение и веб‑приложение). Сервис уже работал в Москве, Санкт‑Петербурге, Екатеринбурге, Воронеже, Волгограде и других городах, когда команда уперлась в потолок по производительности и стабильности. БизнесМатика вошли в проект именно для устранения этой проблемы.

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

2. Когда подписка на машину "тормозит"

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

Например, в пиковые моменты рекламных кампаний пользователи сталкивались с долгими загрузками (в частности, расчета стоимости подписки). Иногда бронирование подвисало.

Цели к старту проекта сформулировали следующим образом:

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

На старте проекта замеры показали нестабильное время отклика по ключевым сценариям (расчет стоимости, бронирование, оплата), рост числа инцидентов в пиковые недели, а также длинный цикл вывода изменений.

3. Данные и интеграции

Сервис подписки стоял не сам по себе, а как некий "дирижер" оркестра корпоративных систем.

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

К этому добавлялись:

платёжная инфраструктура и биллинг (первый платеж, рекуррент, статусы оплат, возвраты);
телематика части моделей (пробег, базовые данные о состоянии, геопозиция - там, где это было предусмотрено сервисной моделью);
маркетинговые системы, которые приносили трафик и сегментировали аудиторию.

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

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

4. Как устроен сервис подписки изнутри

Совместно с командой клиента мы решили двигаться в сторону микросервисной архитектуры:

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

Сервис подписки стали рассматривать как центральную платформу, которая стоит между фронтом (мобильное приложение и веб‑интерфейс) и тяжёлыми backend‑системами автопроизводителя. В идеале мобильное приложение видит простой API: «посчитай подписку», «забронируй автомобиль», «продли подписку». Вся сложность общения с ERP, CRM и биллингом скрывается в глубине бэкенда.

5. Как шла работа

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

Параллельно запустили режим быстрой стабилизации. Взяли несколько самых болезненных сценариев (расчет стоимости подписки, бронирование на выходных, платежи в пике) и сфокусировались именно на них. Часть запросов оптимизировали, часть вынесли в отдельные сервисы, часть просто перестали делать синхронно, переключив на очереди и фоновую обработку.

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

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

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

6. Команда

Со стороны БизнесМатики в проект зашла смешанная команда. Архитектор, который говорил и с разработчиками, и с владельцами продукта. Несколько backend‑разработчиков, инженер по интеграциям, DevOps‑инженеры и QA.

Со стороны Hyundai Mobility ключевыми фигурами стали product owner сервиса подписки, владелец бизнес‑процесса и IT‑архитектор.

7. Технологии: без магии, но по‑взрослому

В основе технологического стек проекта была микросервисная архитектура. Сервисы разворачивались в контейнерах, там, где нужна была синхронность - REST API, там, где важна устойчивость и асинхронность - очереди и message broker.

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

Отдельного внимания заслуживает вопрос наблюдаемости. Логи собрали в единое место, метрики - на дашборды, оповещения настроили так, чтобы команда видела проблемы как можно раньше. Настроили CI/CD, перешли к более аккуратным стратегиям выката.

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

8. Результаты в цифрах

Главный эффект проекта команда почувствовала по тому, как изменилась жизнь в пиковые недели - система стала вести себя предсказуемо.

Технически это выглядело так:

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

Бизнес‑эффекты тоже проявились. Более стабильная и быстрая работа сервиса улучшила конверсию - меньше людей бросали оформление на середине, клиенты активнее пользовались возможностями самообслуживания (продлевали подписки, меняли условия и управляли услугами внутри приложения, не перегружая колл‑центр).

9. Риски и вызовы: что могло пойти не так

Любая миграция живого сервиса на новую архитектуру - это всегда сопряжено с рисковами. В Hyundai Mobility это понимали с самого начала.

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

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

Третий риск - безопасность и регуляторика. Любая работа с персональными данными и платежами требует аккуратности. Команда безопасности подключалась с ранних этапов - архитектура и код обсуждались с учетом необходимых требований.

10. Как изменились люди - взгляд клиента

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

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

11. Подписка как платформа

Для Hyundai Mobility этот проект стал не финалом, а переходом на следующий уровень. Когда фундамент стабилизирован, к нему можно надстраивать новые уровни.

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

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

Внедрение системы интеллектуальной обработки обратной связи (NLP) для региональной розничной сети

2026-03-09T08:50:55.233Z

Региональная сеть (120 магазинов, Сибирь) столкнулась с необходимостью удержания доли рынка в конкуренции с федеральными гигантами. Сложность проекта заключалась в интеграции разрозненных систем (1C, Bitrix24, мобильное приложение) в единый аналитический контур.

Решение: автоматизация сбора и семантического анализа отзывов для Департамента маркетинга. Работала команда БизнесМатики.

Бизнес-эффект:

Время обработки негатива (SLA) снижено в 190 раз — до 15 минут.
Рост индекса лояльности (NPS) на 7 п.п. за полгода благодаря системной работе с причинами недовольства клиентов.

Точка А: Когда «Книга жалоб» трещит по швам

До старта проекта ситуация в компании-клиенте напоминала попытку вычерпать воду из лодки решетом. В день на сеть сваливалось около 800 упоминаний: отзывы в 2ГИС и Яндекс.Картах, комментарии в локальных пабликах ВК, сообщения в чат-бот Telegram и звонки на горячую линию.

Раньше два маркетолога каждое утро тратили 3 часа на «разбор полетов». Они вручную копировали тексты в Excel, тегировали их цветами (красный — плохо, зеленый — хорошо).

Проблема 1: Отчеты формировались раз в неделю. Если в понедельник в магазине №4 сломался холодильник с молоком, офис узнавал об этом в пятницу, когда партия уже была списана, а клиенты ушли к конкурентам.
Проблема 2: Человеческий фактор. Усталый менеджер мог пропустить сарказм или просто не заметить важный сигнал в потоке спама.

Цель проекта: Автоматизировать сбор и анализ обратной связи, превратив хаос из букв в стройные графики и автоматические задачи для директоров магазинов.

Топливо для системы: Данные и интеграции

Мы решили использовать то, что уже есть.

Источники: API Яндекс.Карт и 2ГИС, парсинг открытых групп города в ВК, выгрузка из AppStore/Google Play, логи чат-бота и транскрибация звонков (Speech-to-Text).
Безопасность: Данные обезличивались на входе. Мы не хранили телефоны клиентов в аналитическом контуре, только ID транзакций, если они были указаны в чеке.

Решение: Цифровой «сплетник»

Мы создали систему, которая работает как гиперактивный консьерж, который никогда не спит. В центре архитектуры — NLP-движок (Natural Language Processing). Он не просто ищет ключевые слова «плохо» или «грязно». Он понимает контекст.

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

Тональность: Позитив, Негатив, Нейтрал, Смешанная (самое сложное).
Категория (Аспект): Цены, Персонал, Чистота, Свежесть, Ассортимент.
Объект: Конкретный магазин (по геометке или упоминанию).

Если система видит маркер «опасность» (слова-триггеры: просрочка, хамит, грязь, крыса), она не ждет отчета, а сразу создает задачу в Bitrix24 на директора конкретного магазина и ставит в копию супервайзера.

Как мы это строили (этапы и хронология)

Весь проект занял 4,5 месяца. Это был спринт, а не марафон.

Разведка (3 недели): Изучили, как клиенты ругаются. Составили «словарь боли» (сленг, локальные названия продуктов).
Прототип (1 месяц): Собрали данные в кучу, обучили базовую модель. Первые тесты показали точность 60% — модель путала «лук» (овощ) и «лук» (образ). Пришлось доучивать.
Интеграция (1,5 месяца): Подружили нейросеть с 1С (для проверки наличия товаров) и Bitrix24.
Боевой запуск и тюнинг (1 месяц): Ловили ложные срабатывания и учили систему понимать сибирский сарказм.

Команда: Люди, которые учили машину читать

С нашей стороны работала компактная боевая единица:

Project Manager — переводчик с клиентского на технический.
Data Scientist — главный дрессировщик нейросети.
Backend/Data Engineer — человек-труба, соединивший источники данных.

Со стороны клиента ключевую роль сыграл директор по маркетингу. Он стал «владельцем продукта», который бил по рукам, когда мы пытались усложнить, и требовал простоты. IT-директор сначала выступал в роли «Бабы-Яги», опасаясь нагрузки на сервера, но увидев архитектуру, стал главным союзником.

Результаты: Цифры не врут

Мы сравнивали показатели за 3 месяца «до» и 3 месяца «после» полноценного запуска.

Скорость реакции: Время от публикации негативного отзыва до звонка директора магазина сократилось с 2-3 дней до 20-40 минут.
Охват: Раньше обрабатывали 20% всех упоминаний (только явные жалобы). Теперь — 100%, включая неявные сигналы в соцсетях.
Продуктовая аналитика: Выявили, что падение продаж в категории «Готовая еда» в двух районах было связано не с ценой, а с изменением рецептуры сэндвичей (люди писали «стали сухие», но маркетинг этого не видел в общих цифрах). Рецептуру вернули — продажи восстановились за 2 недели.
Экономия ФОТ: Маркетологи перестали заниматься «копипастом» и занялись стратегией. Эквивалент экономии — 0,5 ставки аналитика.

Вызовы: «Машина не понимает душу!»

Главный риск был не техническим, а лингвистическим.
Проблема: Сарказм. Фраза «Ну спасибо, удружили, молоко просто огонь (нет)» для базового алгоритма выглядит как позитив (слова «спасибо», «огонь»).
Решение: Мы вручную разметили 2000 «сложных» отзывов и дообучили модель на конкретных примерах иронии. Точность определения тональности выросла до 92%, что выше, чем у уставшего человека в пятницу вечером.

Второй вызов — сопротивление директоров магазинов («Нас теперь робот контролирует?»). Мы перевернули ситуацию: показали, что система не карает, а помогает быстро погасить конфликт, прежде чем он дойдет до гендиректора.

Голос клиента

«Сначала я думал, что это очередная модная игрушка. Но когда система в 8 утра прислала алерт, что в магазине на Ленина не открылась касса (люди написали в городском чате быстрее, чем позвонил администратор), я понял — это работает. Теперь мы не тушим пожары, а ставим датчики дыма».
— Антон В., Операционный директор по маркетингу

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

Что дальше?

В планах на следующий год:

Предиктивная аналитика: Пытаться предсказывать всплески негатива на основе погоды и календаря поставок.
Генеративные ответы: Подключить LLM (большую языковую модель), которая будет генерировать черновики эмпатичных ответов на отзывы, чтобы оператору оставалось только нажать «Отправить».
HR-аналитика: Анализировать отзывы сотрудников о работе в компании (анонимно), чтобы снижать текучку линейного персонала.