Банк ВТБ работает с сотнями тысяч клиентов малого бизнеса и развивает отдельную линейку цифровых сервисов для предпринимателей (онлайн‑бухгалтерия, онлайн‑налог для АУСН, сервисы расчётного счёта и эквайринга). В этой экосистеме 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 вернул проект в исходный календарный план и вышел в релиз без срыва сроков, а заказчик получил рабочее приложение с несколькими тысячами активных пользователей в первые месяцы.

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

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 этот кейс стал иллюстрацией того, что аутстаффинг - это не про «отдать работу на сторону», а про инструмент управления ресурсами и рисками в момент, когда собственная команда упирается в потолок. А для нас - подтверждением того, что внешняя команда может аккуратно встраиваться в культуру и процессы клиента и приносить результат, не перетягивая одеяло на себя.

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

Конкретный продукт в кейсе - сервис мониторинга морских перевозок, который собирает данные со спутников с 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 этот проект стал не только способом «починить» отдельный продукт, но и полигоном для отработки практик бизнес‑анализа в стратегически важной отрасли. Уже в ходе работы часть подходов - шаблоны требований, принципы работы со стейкхолдерами, критерии готовности задач - начали переносить на соседние направления, связанные с транспортом и умной инфраструктурой.

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

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.

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

Региональная сеть (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). Он не просто ищет ключевые слова «плохо» или «грязно». Он понимает контекст.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что дальше?

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

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

Клиент: Сеть магазинов товаров для дома и ремонта (DIY-ритейл).
Масштаб: 51 точка по ЦФО, интернет-магазин, 2000+ сотрудников.
ИТ-ландшафт: 1С:ERP, самописная CRM и IP-телефония.
Что сделали: Внедрили голосового и текстового ИИ-агента в первую линию поддержки.
Главный эффект: Операторы перестали быть «справочным бюро», а среднее время ожидания ответа на линии упало с 4 минут до 40 секунд.

Проблема

Представьте себе утро понедельника или вечер пятницы в строительном магазине. Телефоны разрываются. Клиенты хотят знать всё: от «есть ли у вас грунтовка глубокого проникновения» до «где мой заказ №12345». В пиковые часы 35% звонков просто сбрасывались, менеджеры в залах, которые должны продавать и консультировать живых покупателей, вынуждены были отвечать на одни и те же вопросы: «До скольки вы работаете?» и «А доставка в субботу есть?».

Базовая метрика выглядела удручающе:

• Lost Call Rate (потерянные звонки): 35%.
• FCR (решение вопроса с первого обращения): 60%.
• Нагрузка на оператора: 120 звонков в смену (выгорание через 3 месяца).

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

Данные

Любой ИИ умен ровно настолько, насколько качественны данные, которые ему скармливают. Мы столкнулись с классикой российского ритейла: данные были везде, и они были «грязными».

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

1. База знаний: Скрипты, условия возврата, гарантия.
2. 1С:Управление Торговлей: Актуальные остатки и цены.
3. CRM: Статусы заказов и профили клиентов.

Решение: Цифровой консьерж, который реализовала наша команда (БизнесМатика).

Наше решение строилось на базе LLM с архитектурой RAG (Retrieval-Augmented Generation). Представьте, что мы наняли стажера с эйдетической памятью. Он помнит наизусть все инструкции, имеет мгновенный доступ к складской программе и никогда не спит. Ассистент был внедрен в два канала:

1. Голос (Телефония): Распознавание речи, поиск ответа, синтез голоса.
2. Текст (WhatsApp/Telegram/Сайт): Мгновенные ответы в чатах.

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

Как это строилось: От галлюцинаций до мастерства

Процесс занял 4,5 месяца и напоминал обучение ребенка речи, только очень быстрое.

1. Проектирование (3 недели): Мы слушали звонки. Тысячи звонков. Выделили 50 топовых интентов (намерений), которые покрывают 80% трафика.
2. Чистка данных (4 недели): Самый трудоемкий этап. Пришлось написать промежуточный слой (API), который нормализует данные из 1С перед тем, как отдать их нейросети.
3. Прототип и «Песочница» (3 недели): Запустили бота на внутренней линии для сотрудников. Они пытались его сломать, задавая каверзные вопросы.
4. Боевой запуск (6 недель): Раскатывали постепенно. Сначала на 5 магазинов, потом на регион, потом на всю сеть.

Команда: Люди за кулисами

Со стороны интегратора работала «штурмовая группа»:

• Архитектор решений: проектировал связку телефонии и нейросетей.
• Data Scientist: «дрессировал» модель, чтобы она не путала ламинат с паркетом.
• Backend-разработчик: строил мосты к 1С.

Со стороны клиента ключевую роль сыграл не столько IT-директор, сколько Руководитель клиентского сервиса. Именно она валидировала ответы бота: «Нет, так мы с клиентами не разговариваем, слишком официально, добавьте эмпатии».

Вызовы

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

Мы решили это через метафору «Экзоскелета». Мы объяснили и показали на демо, что ИИ не заменяет оператора, а забирает на себя «мусорную» работу.
Риск галлюцинаций: На старте бот один раз придумал акцию «Скидка 50% на все перфораторы».
Решение: Вдрили жесткие ограничители. Теперь, если бот не находит точной информации в базе знаний, он запрограммирован отвечать: «Я уточню этот момент у коллеги» и переводить на человека, вместо того чтобы выдумывать.

Результаты: Цифры, которые говорят сами за себя

Спустя 3 месяца после полного запуска (сравнение квартал к кварталу):

Экономика: Стоимость обработки одного обращения снизилась в 3 раза. Но важнее то, что в нерабочее время (с 21:00 до 09:00) бот стал собирать и квалифицировать лиды, которые раньше просто терялись. Это дало прирост выручки интернет-магазина на 1,5%.

Слово клиенту

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

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

Следующие шаги

Проект перешел из стадии «инновация» в стадию «стандарт работы». В планах на следующий год:

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

Проект: Внедрение AI-рекомендаций для Fashion E-commerce.

Дано: Ритейлер с объемом ~120 заказов/день на базе экосистемы 1С. Основная проблема — низкая утилизация трафика («витринный шоппинг»).

Реализация: Развертывание системы персонализированной выдачи товаров без остановки операционной деятельности и перестройки IT-ландшафта.

Ключевой показатель: Рост выручки на 30% за 3 месяца за счет повышения релевантности предложения пользователю.

Боль клиента: Синдром cлепого продавца

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

• Конверсия в покупку: 1.2% (грусть маркетолога).
• Средний чек: 4 500 руб.
• Проблема: Ручное управление рекомендациями. Контент-менеджер Лена тратила 4 часа в неделю, чтобы вручную привязывать «ремни» к «брюкам». Это работало медленно и часто нелогично.

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

Археология данных: Что мы раскопали

Любой ИИ — это гурман. Ему нужны свежие ингредиенты (данные). Мы полезли в закрома клиента и нашли там типичный для российского ритейла «зоопарк»:

• Источники: История заказов за 2 года из 1С (ERP), логи поведения с сайта (Google Analytics / Яндекс.Метрика raw data) и каталог товаров.
• Качество: Здесь нас ждал сюрприз. В базе 1С размер «L» был записан в пяти вариациях: «L», «l», «48-50», «Большой» и, внезапно, «Л».
• Безопасность: Чтобы не нарушать 152-ФЗ, мы настроили процесс обезличивания. ИИ не знал, что покупатель — «Иван Иванов», он видел «User_ID_4829», который любит синий цвет и тратит деньги по пятницам.

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

Решение: Цифровой стилист

Мы не стали ломать существующий «Битрикс», а построили рядом с ним «мозг» — отдельный микросервис рекомендаций.

Представьте, что это опытный шахматист, который просчитывает ходы.

1. Коллаборативная фильтрация: «Люди, похожие на тебя, купили это». Если 100 брутальных мужчин купили эти брюки и этот ремень, 101-му мы предложим то же самое.
2. Content-based подход: Анализ атрибутов. Если вы смотрите красное платье, система ищет похожие по фасону, материалу и цене, а не просто «что-то красное».
3. Бизнес-правила (Hard Logic): ИИ может ошибаться, поэтому мы поставили «предохранители». Например, не рекомендовать зимние куртки летом и не предлагать товары, которых осталось меньше 2 штук на складе.

Этапы большого пути (3.5 месяца)

Проект двигался не как спринт, а как марафон с препятствиями:

1. Анализ и проектирование (2 недели): Поняли, что данные грязные, поплакали, заложили время на чистку.
2. Сборка Data Pipeline (4 недели): Настроили перекачку данных из 1С и сайта в наше хранилище.
3. Обучение моделей (3 недели): Самый творческий этап. Первая версия модели упорно рекомендовала всем дешевые аксессуары. Пришлось учить алгоритм не гнаться только за вероятностью клика, а смотреть на маржинальность.
4. Интеграция и А/Б тесты (5 недель): Выкатили на живых людей. 50% видели старые «Хиты продаж», 50% — наш умный блок.

Команда: Люди и машины

С нашей стороны работало «спецназ-трио»:

• Data Scientist: Тренер нейросети, шаман математики.
• Backend-разработчик: Строитель труб, по которым текут данные.
• Менеджер проекта: Переводчик с «айтишного» на «бизнесовый».

Со стороны клиента героем стал Маркетинг-директор. Сначала он был главным скептиком («Да что ваша машина понимает в моде?»), но когда увидел первые цифры, превратился в локомотив изменений, выбивая доступы у безопасников.

Под капотом (Технологии)

Для любителей «железа» и кода:

• Язык: Python (стандарт индустрии).
• ML-библиотеки: PyTorch для векторизации товаров (превращаем фото платья в набор цифр) и LightFM для матричных разложений.
• БД: ClickHouse для хранения логов (очень быстрый) и Redis для мгновенной отдачи рекомендаций на сайт.
• Оркестрация: Apache Airflow — дирижер, который каждое ночи запускал переобучение модели.

Результаты: Магия цифр

Спустя месяц чистого А/Б теста мы подвели итоги. Разница между группой с ИИ и группой без него была статистически значимой, как разница между велосипедом и электросамокатом.

Что мы получили (по метрикам):

• Выручка: +30% (за счет роста конверсии и глубины чека).
• Конверсия карточки товара: Выросла на 15%. Люди перестали уходить со страницы, если товар не подошел — они кликали на «Похожие».
• Средний чек: Увеличился на 7%. Блок «С этим покупают» начал реально работать, подкидывая к кроссовкам правильные средства для ухода, а не случайные шапки.

Риски и грабли: «Холодный старт»

Главным вызовом стала проблема «Холодного старта». Что показывать новому пользователю, о котором мы ничего не знаем?
Сначала система впадала в ступор.
Решение: Мы внедрили гибридную логику. Пока пользователь «аноним», мы показываем ему тренды региона (в Москве — одно, в Новосибирске — другое) и новинки. Как только он делает 3-4 клика, включается персонализация. Это похоже на то, как официант сначала предлагает меню дня, а потом замечает, что вы смотрите только на стейки.

Жизнь после внедрения

Изменились не только цифры, но и работа людей.

Отзыв владельца «NordLook»:
«Честно? Я думал, это очередная игрушка для айтишников. Но когда я увидел, что система сама продала залежавшуюся партию зеленых брюк, просто начав рекомендовать их к новой коллекции свитшотов, я понял — это работает».

Что изменилось в офисе:
Контент-менеджер Лена перестала заниматься «ручным вязанием» товаров. Вместо механической работы она занялась созданием красивых лукбуков для Instagram. Рутина ушла к роботу, творчество осталось людям.

Что дальше?

Аппетит приходит во время еды. Теперь клиент хочет:

1. Умные рассылки: Чтобы в email-письме приходили не общие баннеры, а именно те товары, которые пользователь забыл в корзине или смотрел вчера.
2. Офлайн-интеграция: Продавцы в шоуруме с планшетами. Клиент называет номер телефона, а продавец видит: «Ага, он любит зауженные джинсы, предложите ему новую коллекцию».

Клиент: Федеральный FMCG-ритейлер (Топ-10 РФ), управляющий сетью из более чем 1500 магазинов формата «у дома».

Проблематика: Необходимость оптимизации запасов в категориях с коротким сроком годности (Fresh/Ultra-Fresh) в условиях гетерогенного ИТ-ландшафта (централизованная ERP на базе 1С и децентрализованные WMS-системы).

Решение: Разработка и внедрение системы прогнозирования спроса на основе алгоритмов машинного обучения (ML). Проект включал пилотное внедрение на 50 торговых точках и распределительном центре (РЦ) с последующим тиражированием на всю сеть.

Результаты за 6 месяцев: Точность прогнозирования продаж достигла 85%,  объем списаний скоропортящейся продукции снижен на 17%.

Боль клиента: гадание на кофейной гуще

До прихода алгоритмов процесс заказа товаров напоминал игру в рулетку. Директора магазинов каждое утро садились за Excel и, полагаясь на интуицию, решали, что заказывать. Точность таких прогнозов колебалась в районе 55–60%. Это приводило к классическим «качелям»:

1. Overstock (перетарка) - магазин завален помидорами, которые гниют. Списания съедают маржу.
2. Out-of-stock (дефицит) - покупатель приходит за молоком, видит пустую полку и уходит к конкуренту через дорогу.

Клиент поставил амбициозную цель - исключить человеческий фактор из рутинных заказов и снизить потери, не уронив при этом доступность товара на полке (OSA, On Shelf Availability).

Данные - укрощение хаоса

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

Источники, которые мы завели в Data Lake:

• История чеков за 3 года: кто, что, когда и в комбинации с чем покупал.
• Справочники товаров: самая большая боль. Один и тот же сорт яблок в разных регионах мог называться по-разному. Пришлось проводить нормализацию справочников (Master Data Management).
• Промо-календарь: акции ломают стандартные паттерны спроса, поэтому данные о скидках стали критически важными.
• Внешние факторы: погода (через API метеосервисов), производственный календарь (праздники/выходные) и даже график выплат пенсий в конкретных локациях.

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

Решение: Цифровой оракул от команды БизнесМатики

Мы не могли ломать существующую ERP, поэтому построили рядом интеллектуальную надстройку. Это микросервисная архитектура, которая работает как «второе мнение», а со временем - как основное. Система забирает данные из хранилища, прогоняет их через набор ML-моделей и выдает рекомендацию: «Закажи 15 пакетов кефира и 40 кг картофеля на завтра». Этот прогноз автоматически падает в систему автозаказа (автопополнения), и если он не превышает критические лимиты, заказ формируется без участия человека. Директор магазина вмешивается только в случае форс-мажора.

Работы и этапы: Марафон длиною в 9 месяцев

Проект шел не как спринт, а как планомерная осада крепости.

• Аудит и чистка данных (2 месяца): Самый скучный, но важный этап. Если на входе мусор - на выходе мусор, даже с самым умным ИИ.
• Разработка MVP (3 месяца): Выбрали одну категорию («Молочная продукция») и 10 тестовых магазинов. Обучили первые модели.
• Опытно-промышленная эксплуатация (2 месяца): Запустили «битву алгоритмов». Сравнивали заказы директоров и прогнозы ML на живых данных, но заказы пока делали люди.
• Тиражирование (2 месяца): Постепенное подключение всех категорий Fresh и всех регионов.

Команда: математики и товароведы

С нашей стороны работала команда из 7 человек: Project Manager, Tech Lead, два Data Scientist, Data Engineer, DevOps и бизнес-аналитик.

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

Что под капотом

Мы использовали классический, проверенный в бою стек, избегая экзотики ради стабильности:

• ML-движок: Python. Для прогнозирования временных рядов мы отказались от тяжелых нейросетей в пользу градиентного бустинга. На табличных данных ритейла они работают быстрее и точнее, лучше интерпретируются.
• База данных: ClickHouse для быстрой аналитики больших массивов данных и PostgreSQL для хранения метаданных.
• Оркестрация: Apache Airflow управлял потоками данных (ETL).
• Инфраструктура: Все упаковано в Docker-контейнеры и управляется Kubernetes (K8s) на серверах клиента.

Результаты: Цифры, которые убедили всех

Мы считали эффект методом A/B-тестирования: сравнивали показатели «пилотной» группы магазинов с контрольной группой (где работали по старинке) в течение 3 месяцев.

• Точность прогноза выросла с 60% до 85% на горизонте 7 дней.
• Списания снизились на 17% в категории Fresh и на 20% в категории Ultra-Fresh.
• Упущенные продажи сократились на 5%. Товар стал всегда в наличии, даже в пятницу вечером.
• Директора магазинов освободили по 1,5–2 часа в день, которые раньше тратили на формирование заказов.

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

Операционный директор сети:

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

Следующие шаги

Теперь, когда фундамент заложен, аппетит клиента вырос. В планах на следующий год (Roadmap):

1. Прогноз эластичности спроса по цене: чтобы ML подсказывал не только сколько заказать, но и какую скидку поставить, чтобы продать всё под ноль к концу срока годности.
2. Внедрение компьютерного зрения: камеры в зале будут сами видеть пустую полку и давать сигнал на склад или сразу в систему заказа, минуя этап пересчета остатков.

Крупный мясоперерабатывающий завод в Санкт-Петербурге, работающий в режиме 24/7, столкнулся с проблемой внезапных остановок холодильного оборудования. Для минимизации рисков порчи продукции и финансовых потерь была внедрена система предиктивной аналитики в основном цехе хранения и охлаждения. Система интегрирована с существующей 1С:ERP и MES-системой собственной разработки. В результате за первые 6 месяцев эксплуатации удалось сократить незапланированные простои оборудования на 20% и снизить затраты на аварийные ремонты на 15%.

Проблема

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

Цель проекта была перейти от реактивного и планового обслуживания к обслуживанию "по состоянию", прогнозируя отказы ключевых узлов за 2-3 недели до их возникновения.

В течение 6 месяцев до старта проекта велся учет всех инцидентов. В среднем, незапланированные простои холодильного оборудования составляли 48 часов в месяц, а прямые затраты на аварийные ремонты (запчасти + сверхурочная работа) достигали 1.2 млн. рублей в квартал.

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

Источники данных - это данные с новых IoT-датчиков, установленных на компрессоры (виброактивность, температура подшипников, давление на входе и выходе, потребляемая мощность), исторические данные из SCADA-системы (температурные режимы в камерах), а также журналы ремонтов и обслуживания из MES-системы (текстовые описания поломок, замененные детали).

Исторические данные о ремонтах были неструктурированы и содержали неполные описания. Данные с датчиков на начальном этапе были шумными из-за особенностей работы оборудования.

Функционал системы

• Система в реальном времени собирает показания с 200+ датчиков.
• Разработана ML-модель на базе градиентного бустинга, которая анализирует временные ряды и выявляет аномалии, указывающие на деградацию оборудования (износ подшипников, утечки, падение производительности).
• Создан дашборд, который визуализирует "здоровье" каждого агрегата в виде понятных шкал. При прогнозировании поломки система автоматически отправляет уведомление начальнику ремцеха и инженерам с указанием проблемного узла и предполагаемого окна для ремонта.

Решение представляет собой отдельный программно-аппаратный комплекс. Он получает данные из MES и SCADA по API, но не вмешивается в их работу. Это система поддержки принятия решений для службы главного инженера.

Работы и этапы

Проект был реализован за 6 месяцев.

Результаты

• Сокращение времени простоя на 20%: За 6 месяцев после внедрения общее время незапланированных простоев составило в среднем 38.4 часа в месяц (вместо 48 часов).
• Снижение затрат на аварийные ремонты на 15%: За счет своевременной закупки запчастей по плановым ценам и выполнения работ в рабочее время.
• Предотвращение 4 крупных отказов: Система спрогнозировала критический износ подшипников на двух компрессорах и нарушение герметичности на двух других, что позволило провести ремонт до отказа. По оценке, это сохранило продукцию на сумму около 10 млн. рублей.
• Методика расчета: Сравнивались показатели "среднее время простоя в месяц" и "стоимость аварийных ремонтов за квартал" за 6 месяцев до и 6 месяцев после внедрения системы.

Риски и вызовы, как их решали

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

Во-вторых, на начальном этапе были ложные срабатывания модели. Однако был введен период пилотной эксплуатации, во время которого все алерты перепроверялись вручную. Это позволило дообучить и откалибровать модель, снизив количество ложных срабатываний до приемлемого уровня (<5%).

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

Главный инженер:

Мы перешли от режима пожарной команды к проактивному управлению. Раньше мы узнавали о проблеме, когда в цеху становилось тепло. Теперь система предупреждает нас за 2-3 недели, давая время спокойно заказать детали и спланировать ремонт на удобное время. Это полностью изменило наш подход к надежности.

Что изменилось для людей

Вместо экстренных вызовов по ночам, механик теперь получает на почту уведомление: "Агрегат №12: прогнозируемый износ муфты через 15-20 дней". Он вносит замену в план работ на следующей неделе. Начальник ремцеха теперь начинает планерку с обзора дашборда оборудования, а не с отчета о ночных происшествиях. Приоритеты по обслуживанию расставляются на основе данных, а не интуиции.

Дальнейшие планы клиента по сотрудничеству с нашей компанией

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