Перевод всех организаций торгово‑промышленной компании на современную учетную систему с изменением бизнес‑процессов

Реинжиниринг торговых процессов, переход с нетиповой УТ10 на УТ11, маркировка, интеграция с сайтом и маркетплейсами, единая система лояльности — в одном проекте. Рассказываем, как компания за год перешла на современный учётный контур и подготовила базу для дальнейшего развития.

Введение

Задачи проекта

Задача №1. Провести реинжиниринг всех торговых процессов, связанных с закупкой, складом, различными каналами продаж (опт, розница, e‑com: собственный интернет‑магазин и маркетплейсы) для реализации максимально типовыми средствами прикладного решения.

Задача №2. Обеспечить полноту учёта, соответствие законодательству в части 54‑ФЗ, внедрить маркировку товаров легкой промышленности и обуви.

Задача №3. Интегрировать учетную систему с собственным торговым сайтом.

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

Задача №5. Интегрировать учетную систему с маркетплейсами.

С чего начался проект и как менялось решение

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

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

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

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

Реализованные решения

Решение №1. Переход с нетиповой УТ10 на УТ11 с сохранением типового функционала целевой системы, перенос данных, интеграция всего торгового оборудования с целевой учетной системой.

Решение №2. Настройка всех рабочих процессов в целевой системе, доработка функционала, обучение сотрудников.

Решение №3. Интеграция учетной системы с ГИС МТ «Честный знак», подключение и настройка ЭДО, внедрение процессов работы с маркировкой, обучение сотрудников.

Решение №4. Интеграция 1С:Управление торговлей с сайтом на Bitrix, настройка обмена товарами, остатками, ценами, передача информации из учетной системы о скидках и акциях, остатках клиентских бонусов, получение заказов и оплат с сайта. Реализация «смешанной» оплаты заказов на сайте и в рознице.

Решение №5. Интеграция 1С:Управление торговлей с OZON: FBS. Формирование каталога, остатков, цен. Работа с заказами, отгрузками, поддержка работы с маркировкой. Отражение отгрузок на маркетплейс через комиссионную схему продаж на стороне учетной системы.

Почему проект запускали поэтапно

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

Результаты проекта

Результат №1. Клиент получил актуальную, современную, обновляемую систему с максимально типовым функционалом, отвечающую всем современным требованиям законодательства (онлайн‑кассы, маркировка).

Результат №2. В системе налажен полноценный учёт товарных остатков, взаиморасчётов с контрагентами, с полной аналитикой закупок и продаж.

Результат №3. Система интегрирована с сайтом и маркетплейсами, везде действуют одинаковые условия продаж — ценами и условиями можно управлять из единой системы. Снижено количество ручных операций при сопровождении интернет‑продаж.

Результат №4. Подготовлена база для дальнейшего развития компании и клиентских сервисов.

Что из этого кейса можно взять на заметку

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

Не пытайтесь запустить всё сразу. Проект разделили на этапы: сначала оптовое направление (потому что там раньше вступали в силу требования по маркировке), потом розница, потом интеграция сайта и маркетплейсов. Это позволило не ждать, пока будет готово всё, а получать результат постепенно. Если есть возможность разделить проект на логические блоки — лучше так и сделать.

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

E‑commerce и маркетплейсы должны быть в одном контуре с учётом. Сайт и маркетплейсы — не внешние витрины, а полноценные каналы продаж. Если они живут отдельно от учётной системы, рано или поздно возникают расхождения по остаткам, ручные сверки и ошибки. В проекте их интегрировали так, что ценами, остатками и условиями продаж можно управлять из единой системы.

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

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

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

Сроки проекта

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

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

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

Команда проекта

Большая часть работы по проекту была выполнена компактной командой. Основной объем фактически закрыли три специалиста:

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

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

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

Вывод

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

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

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

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

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

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

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