01

Исходная ситуация

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

Ключевые проблемы были такими:
1. Система не соответствовала новым требованиям законодательства.
Компания не была готова к корректной работе с НДС. По поставкам не хватало качественных данных. Взаиморасчеты с клиентами в учетной системе не велись — только в бухгалтерии.
2. Не было готовности к маркировке и «Честному знаку».
Особенно остро проблема стояла в рознице. У компании были собственные офлайн-магазины, а значит, нужно было продавать маркированную продукцию через кассовую технику с корректным выбытием кодов. На старой системе это реализовать было нельзя.
3. Сайт жил отдельно от учетной системы.
Продажи с сайта учитывались параллельно. Данные приходилось сводить вручную. Для нового сайта и новых digital-сценариев текущая модель обмена данными не подходила.
4. Инфраструктура была слабой и устаревшей.
Оборудование давно не обновлялось, интернет-каналы не отвечали требованиям, часть процессов работала нестабильно. Для новой архитектуры этого было недостаточно.
5. Сроки поджимали.
Если полноценное внедрение маркировки в рознице обычно занимает около года, заказчик пришел практически на грани дедлайна.

Бизнес-контекст

«Наследник" — это торгово-производственная компания со сложной структурой:

• собственное производство одежды;
• оптовый контур;
• розничная сеть;
• интернет-магазин;
• маркетплейсы;

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

02

Главный вызов

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

Изменение требований по ходу проекта

По мере работы изменились внешние вводные:

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

Ограничения старой архитектуры

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

Управленческий фактор

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

Архитектурный подход

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

От распределенной базы — к единой операционной модели
Команда провела нагрузочное тестирование с учетом текущего числа пользователей и двукратного запаса на рост. Результат показал, что современная архитектура на тонком клиенте позволяет работать из центральной базы без распределенного контура.
Это дало бизнесу несколько преимуществ:

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

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

• подобрать подрядчика на аутсорс инфраструктуры;
• развернуть новые серверы;
• перейти на Linux и PostgreSQL;
• отказаться от зависимости от Microsoft SQL в условиях отсутствия поставок и поддержки.

03

Реализация по этапам

Этап 1. Форсированное внедрение в опте

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

Что было сделано:

• перенесена номенклатура;
• перенесен ключевой функционал для опта;
• подключен «Честный знак»;
• настроены УКЭП и ЭДО;
• сотрудники обучены работе с электронными документами.

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

Этап 2. Розница и маркировка

Следующим крупным блоком стала розничная сеть.

Здесь ключевыми задачами были:

• перенос номенклатуры;
• перенос остатков по магазинам;
• внедрение розничного контура;
• запуск маркировки в рознице;
• обеспечение корректной работы кассовой техники и требований 54-ФЗ.

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

Этап 3. Новый сайт и интеграция с e-commerce

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

Команда реализовала на стороне учетной системы:

• сложные выгрузки каталога;
• расписания обменов;
• признаки новинок;
• признаки акционных товаров;
• передачу остатков;
• механику сложных маркетинговых акций.

Особенно нетривиальными были составные акции. Например: при покупке определенных товаров клиент получает на выбор один из нескольких подарков. Чтобы такая акция работала на сайте, недостаточно передать только саму механику — нужно еще и в каждый момент времени учитывать реальные остатки товаров, доступных для выбора.

Этап 4. Маркетплейсы

В проект были добавлены интеграции с:

• Wildberries;
• Ozon;
• Яндекс Маркет;
• Детский мир.

Наиболее сложным оказался Ozon. Пока проект шел, маркетплейс изменил схему работы: если раньше невыкупленный товар в FBS возвращался поставщику, то затем он стал автоматически переходить на FBO.

Это означало, что заказчику пришлось поддерживать одновременно две логики:

• стандартную схему;
• комиссионную схему.

Для бизнеса это вызвало две проблемы:

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

В момент перехода до 80% остатков не совпадали. Команда поэтапно разбирала статусы заказов, движение товаров и комиссионную отчетность. В результате расхождения удалось сократить до 2–3%.

Этап 5. Маркетинговые инструменты и лояльность

Дополнительно были реализованы:

• бонусная программа;
• подарочные сертификаты в рознице;
• купоны и промокоды.

Сертификаты были поставлены на юридически корректную модель: как аванс с правильным отражением в учете.

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

04

 Подход к управлению изменениями

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

Практика показала два сценария.

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

Где руководители дистанцировались — проектной команде пришлось брать лидерство на себя

Команда со стороны интегратора фактически вела пользователей через изменения:

• товароведов;
• кассиров;
• закупщиков;
• сотрудников опта.

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

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

Основной объем работ был выполнен небольшой командой.
Ключевые роли:

• руководитель проекта;
• аналитик;
• ведущий разработчик.

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

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

Проект занял около года до полного перевода компании на новую систему.

Хронология была такой:

• около 3 месяцев — обследование, сбор информации, проектирование;
• через 5 месяцев — первый релиз и запуск базы опта;
• к Новому году — запуск крупнейшей розничной базы;
• январь-март — интенсивное сопровождение после перехода;
• далее — поддержка, стабилизация и обсуждение новых этапов.

05

Результаты для бизнеса

По итогам проекта заказчик получил не просто новую систему, а новую операционную модель.
Что изменилось

1. Компания стала соответствовать требованиям законодательства.
Запущены маркировка, «Честный знак», ЭДО, УКЭП, онлайн-кассы и корректные учетные процессы.
2. Учет стал прозрачнее.
Появились оперативные остатки, единое информационное поле и управляемые взаиморасчеты.
3. Бизнес перестал жить в параллельных контурах.
Сайт, розница, опт и маркетплейсы вошли в единый цифровой контур.
4. Появилась база для развития e-commerce.
Новый сайт, маркетинговые механики, акции, бонусы, сертификаты и интеграции с маркетплейсами вывели digital-блок на новый уровень.
5. Снижена зависимость от устаревшей инфраструктуры и legacy-решений.
Переход на Linux и PostgreSQL сделал архитектуру устойчивее в новых условиях.

Выводы и уроки

Из этого проекта можно сделать несколько практических выводов.

1. Старую систему можно терпеть долго. Но не бесконечно
Пока система «как-то работает», бизнес откладывает изменения. Но как только сходятся законодательство, розница, e-commerce и маркировка, старая архитектура начинает тормозить развитие.
2. Внедрение — это не только IT
Если не менять процессы, роли и ответственность, новая система останется дорогой оболочкой поверх старого хаоса.
3. Маркировку нельзя внедрять в последний момент
Особенно если у компании есть розница, несколько юрлиц и сложная номенклатура. В таких проектах сроки решают все.
4. Слабый подрядчик в одном контуре повышает нагрузку на всех остальных
Если сайт или инфраструктура не тянут задачу, эта сложность не исчезает — она переезжает в учетную систему и в проектную команду.
5. Маленькая сильная команда может вытянуть большой проект
Но только если у нее есть методология, техническая компетенция и готовность брать на себя роль проводника изменений.

Следующий этап

После завершения основного проекта заказчик обсуждает с командой следующие задачи:

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