Intekey WMS 2.0 · стратегический переход

Зачем мы перешли на новый стек

От платформенной зависимости lsFusion — к открытому стеку Spring Boot + React + PostgreSQL. Это решение про бизнес-устойчивость, скорость развития и предсказуемую поддержку — не «переписать ради переписать».

Аудитория: руководство · продукт · разработка
Фокус: бизнес · масштабируемость · поддержка · развитие

Исходная точка

Система работала. Стратегически — зависела от платформы.

Было

lsFusion + приватный Nexus

DSL и рантайм нишевой платформы
Сборка только через закрытый репозиторий
UI-формы генерирует платформа
Автотестов почти не было
Кастомизация клиентов расползалась по общему коду

Стало

Intekey WMS 2.0

Spring Boot 4.1 / Java 25 — массовый стек
Maven Central + npm — без спецдоступа
React 19 + TypeScript: ТСД (PWA и APK) и АРМ
329 тестовых классов бэкенда, 207 из них — на настоящем PostgreSQL
Один билд + feature-флаги и extension points

Пять стратегических причин

Почему оставаться на старом стеке стало дороже

Vendor lock-in Нельзя собрать и развернуть без доступа к приватной платформе и Nexus.
Рынок кадров lsFusion — узкий DSL. Spring + React — большой рынок инженеров, быстрее найм и замещение.
Стоимость ошибки Класс регрессий вроде Task 35273 (молчаливый NULL → двойной резерв) — конструктивно закрыт в новой модели остатков.
Стоимость кастомизации Правки «под клиента» в общем коде тормозили всех. Теперь — флаги и точки расширения, без форков.
Невозможность уверенно менять Без автотестов каждый релиз — ручной риск. Сейчас изменения проверяются машиной.

Технический фундамент

Открытый, портируемый, понятный стек

Backend Spring Boot 4.1 Язык Java 25 БД PostgreSQL 18 + Flyway UI React 19 · TypeScript · Vite · PWA Архитектура гексагональный монолит

Один контур учёта

Остаток и резерв — один ресурс с блокировкой. Конкурентные задачи не «перехватывают» один и тот же товар.

Модули без сцепки

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

Явные статусы

FSM документа: разрешённые переходы заданы таблицей, а не разбросанными апдейтами.

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

Что это даёт бизнесу прямо сейчас

Снижение риска

Независимость от вендора платформы

Продукт собирается и развивается стандартными инструментами. Смена подрядчика, CI или облака больше не упирается в закрытый Nexus.

Скорость ценности

Быстрее выводить изменения клиентам

Автотесты + понятный стек = короче цикл «запрос → релиз». Меньше сюрпризов на складе после обновления.

Экономика команды

Дешевле нанимать и растить людей

Инженеры приходят со знанием Spring/React. Онбординг короче, чем обучение нишевому DSL.

Доверие к учёту

Меньше класса «тихих» складских багов

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

Масштабируемость

Растём по клиентам и нагрузке — без размножения кодовых баз

1

сборка на всех тенантов. Различия — флаги и extension points, не форки.

~20

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

VM

легче старого рантайма: старт с 4 vCPU / 8 ГБ на пилот; рост — app и БД раздельно.

Горизонтальный рост процессов Новый процесс (перемещение, контроль, отчёт) добавляется модулем, а не «ещё одним REQUIRE в общем монолите DSL».
Операционный кат-овер Архив тенанта вместо удаления — откат возможен. Волны по runbook, а не «big bang».

Поддержка и сопровождение

Предсказуемая поддержка вместо «экспертизы платформы»

Раньше

Узкое бутылочное горлышко

Мало специалистов по lsFusion
Сложно воспроизвести баг без живого контура
Регресс ловили на складе
Кастом клиента мог сломать соседнего

→

Теперь

Инженерная дисциплина

Стандартный стек — шире пул поддержки
Unit + IT на PostgreSQL в CI
Регресс Task 35273 закреплён тестом
Клиентские правила изолированы в extensions

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

Развитие продукта

Как новый стек ускоряет развитие приложения

Spec-Driven Development

Спека → инварианты → история с критериями приёмки → код → тесты → статус. Изменения управляемы, а не «починили в обход».

Schema-renderer для CRUD

Справочники не пишутся по экрану на React. Backend отдаёт дескриптор — единый рендерер строит форму. Меньше UI-долга.

Ручной UX только там, где нужно

ТСД, 3D-топология, АРМ диспетчера — осознанно кастомные. Остальное — типовой и дешёвый в сопровождении CRUD.

Печать и интеграции

Jasper PDF из проверенных шаблонов, ERP/MobileSMARTS как явные порты. Внешние системы подключаются без переписывания ядра учёта.

Где мы сейчас

Доменный контур WMS уже на новом стеке

22

эпика реализованы (на 2026-11-09): приёмка → отгрузка, остатки, печать, аналитика, ТСД и АРМ, изоляция заказчиков, горячий путь ТСД, APK и работа без связи

9

эпиков в работе: паритет по заказчикам и процессам, перевод контуров, ТСД поверх легаси, внедрение ядра у заказчика, обмен с 1С

781

сквозной тест Playwright (94 набора) плюс 329 тестовых классов бэкенда; схема БД — миграции Flyway до V122

Честно: это ещё не «все заказчики легаси в продуктиве». Это готовый фундамент продукта, на котором перевод идёт волнами — с измеримым паритетом, а не с сюрпризом в день X.

Вывод

Новый стек — инвестиция в управляемый рост

Бизнес: меньше зависимости от вендора, быстрее ценность, дешевле команда
Масштаб: один билд на всех клиентов, изоляция кастома, предсказуемые волны онбординга
Поддержка: мейнстрим-стек, автотесты, диагностируемые инциденты
Развитие: SDD, модули, schema-renderer — фичи добавляются без разрушения ядра учёта

Следующий шаг — волны клиентского паритета и продовый кат-овер по runbook, опираясь на уже работающую Intekey WMS 2.0.