Концепция проекта плавного перехода с 1С:УПП на 1С:ERP

Предпосылки проекта перехода

Сейчас как никогда назрел вопрос перехода с 1С:УПП. Альтернативы особо нет, в большинстве случаев переходить нужно на 1С:ERP.

Ключевые причины перехода:

1. УПП – устаревшая система (более 20 лет на рынке), отсутствие развития (последние годы поддерживается только изменение законодательства), устаревшая архитектура (толстый клиент).

2. Фирма 1С объявила о снятии УПП с поддержки в конце 2026 года

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

    

Выбор варианта внедрения 

1) Классический подход внедрения – каскадная модель («водопад»)

Классический подход внедрения комплексных систем, таких как 1С:ERP – каскадная модель, или «водопад» (предлагают 99% 1С:Франчайзи для подобных проектов). 

Рис. 1. Классическая каскадная модель внедрения

Подход предполагает поэтапное внедрение:

• моделирование бизнес-процессов

• функциональное моделирование – прогон процессов в типовой системе

• разработка Технического задания (ТЗ) по итогам моделирования

• выполнение необходимых доработок функционала на основании ТЗ, разработка механизмов переноса остатков

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

• опытно-промышленная эксплуатация

• передача в промышленную эксплуатацию

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

Недостатки классического подхода:

1. Заказчик видит осязаемый результат только после запуска системы в опытно-промышленную эксплуатацию, т.е. через год-полтора с начала проекта, потратив 70-80% бюджета (а это как правило десятки млн. руб!!!).

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

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

4. Большой стресс и риск для компании – всю компанию лихорадит в лучшем случае месяц, а то и квартал.

5. Сложный откат на предыдущую систему, если что-то пошло не так.

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

Альтернативный подход – плавное внедрение

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

Рис. 2. Концепция поэтапного внедрения

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

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

Общая идея плавного перехода:

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

Детальное описание этапов плавного перехода

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

На примере одного из реализованных проектов рассмотрим этапы:

🔄 Этапы плавного перехода

📦 1. Склады

В первую очередь перевод складов сырья, готовой продукции (ГП) и склада запчастей, затем остальных складов. Это связано с тем, что срочной задачей было как можно скорее запустить адресное хранение на складах сырья и ГП. Дописывать это в УПП или ставить WMS систему было нецелесообразно.

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

В итоге, мы так и сделали:

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

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

- затем запустили склад запчастей, там уже все прошло гладко.

Цель этапа в том, чтобы все документы-движения (поступления, перемещения, различные списания) по этим складам вводились в ERP. В УПП могут вводиться документы-распоряжения (заказы покупателей, заказы поставщикам и т.п.).

Т.к. для адресного хранения в ERP включен ордерный склад, то есть нюансы в документообороте. Например, в УПП списание готовой продукции происходит документом Реализация. В ERP реализация – это распоряжение для склада к отгрузке, а фактическое списание происходит расходным ордером (в УПП расходные ордера не использовались). Это все необходимо учитывать при планировании будущей работы пользователей и в обменах.

🏭 2. Производство

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

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

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

💼 3. Продажи

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

Работа с задолженностью покупателей, претензиями и т.п. А также формирование реализаций. Так же были перенесены исторические данные по продажам за 5 лет для возможности анализа.

🛒 4. Закупки

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

💰 5. Финансы

Когда все блоки оперативного учета запущены, наступил ключевой этап - перевод финансового контура

• учет ОС, НМА

• учет прочих затрат, не отражаемых в контурах выше

• перевод оставшихся складов (офисные и тп)

• настройка закрытия месяца

• перенос настроек для управленческого учета (используется подсистема Итан:Управленческий баланс)

• казначейство

• бюджетирование

• обмен с БП (бухгалтерский учет вынесен в отдельную базу)

В общем, на последнем этапе перенесли все, что еще осталось в УПП.

🔚 6. Отключение УПП

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

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

Обмен мы настраивали постепенно, под каждый этап, только теми справочниками и документами, которые необходимы.

🔄 Обмен данными между системами

Самое сложное в этом подходе - это, конечно же, обмен.

Во-первых, это высокие требования к скорости и надежности.

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

Кроме этого, при наличии обмена необходима постоянная сверка данных, что все корректно перенеслось.

В итоге мы разработали обмен через web-сервисы, который позволяет перегружать данные сразу после их создания/изменения. Кроме этого, были разработаны механизмы протоколирование обмена для выявления ошибок и автоматическая сверка данных между двумя системами. Администратор получает уведомление, если программа нашла расхождение. Это позволяет не тратить много времени на постоянный мониторинг, а реагировать только на ошибки.

Итого

Плюсы подхода:

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

2. Гибкость в требованиях – требования актуализируются перед запуском конкретного блока.

3. Блоки могут стартовать параллельно, что сокращает общий срок проекта (например, один блок в этапе Моделирование, другой в этапе Разработка, третий – в опытно-промышленной эксплуатации).

4. Сбой в работе одного подразделения менее критичен и проще устраним, чем сбой в работе всей компании.

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

Минусы плавного подхода:

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

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

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

Заключение

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

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

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

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

Такой подход применим не только для перехода с УПП на ERP, но и для других решений на базе 1С:Предприятие.