Концепция проекта плавного перехода с 1С:УПП на 1С:ERP
Предпосылки проекта перехода
Сейчас как никогда назрел вопрос перехода с 1С:УПП. Альтернативы особо нет, в большинстве случаев переходить нужно на 1С:ERP.
Ключевые причины перехода:
- УПП – устаревшая система (более 20 лет на рынке), отсутствие развития (последние годы поддерживается только изменение законодательства), устаревшая архитектура (толстый клиент).
- Фирма 1С объявила о снятии УПП с поддержки в конце 2026 года
- Отсутствие большого количества функций, которые есть в современных решениях (адресное хранение, более развитый функционал закупок, продаж и т.п.).
Выбор варианта внедрения
1) Классический подход внедрения – каскадная модель («водопад»)
Классический подход внедрения комплексных систем, таких как 1С:ERP – каскадная модель, или «водопад» (предлагают 99% 1С:Франчайзи для подобных проектов).
Рис. 1. Классическая каскадная модель внедрения
Подход предполагает поэтапное внедрение:
- моделирование бизнес-процессов
- функциональное моделирование – прогон процессов в типовой системе
- разработка Технического задания (ТЗ) по итогам моделирования
- выполнение необходимых доработок функционала на основании ТЗ, разработка механизмов переноса остатков
- подготовка к запуску (развертывание базы, обучение пользователей, разработка инструкций, перенос остатков и т.п.)
- опытно-промышленная эксплуатация
- передача в промышленную эксплуатацию
Все эти этапы выполняются для компании целиком. В результате, в назначенную дату производится одновременный запуск новой системы с отключением предыдущей системы.
Параметры классического проекта для среднего производственного предприятия:
Весь проект занимает в среднем 1,5-2 года, средний бюджет проекта 50-70 млн. руб.
Недостатки классического подхода:
- Заказчик видит осязаемый результат только после запуска системы в опытно-промышленную эксплуатацию, т.е. через год-полтора с начала проекта, потратив 70-80% бюджета (а это 35+ млн. руб!!!).
- Отсутствие гибкости. За такой долгий срок требования меняются всегда. На поздних этапах тяжело менять требования, это сложнее и дороже.
- Длительный срок внедрения. Каждый этап должен быть завершен до перехода к следующему.
- Ошибки выявляются на поздних этапах проекта, абсолютно всегда вылезают вещи, которые не предусмотрели.
- Большой стресс и риск для компании – всю компанию лихорадит в лучшем случае месяц, а то и квартал.
- Сложный откат на предыдущую систему, если что-то пошло не так.
В связи с этим, многие заказчики не готовы к проекту перехода на таких условиях, но необходимость перехода никуда не делась. В переговорах с одним из заказчиков мы решили реализовать другой подход.
Альтернативный подход – плавное внедрение
Плавный переход — это метод внедрения 1С:ERP, при котором компания постепенно переводит бизнес-процессы из устаревшей 1С:УПП в новую систему. Старый контур учета (УПП) сохраняется до завершения полного перехода, что позволяет снизить риски, распределить нагрузку на сотрудников и начать получать результат уже на ранних этапах.
Рис. 2. Концепция поэтапного внедрения
Вместо одного масштабного запуска «по водопаду» проект дробится на блоки — каждый блок переводится и запускается отдельно, с минимизацией стресса для бизнеса.
Такой подход похож на внедрение вспомогательных систем, например WMS (системы управления складом), когда в WMS системе работают складские работники, а в основную учетную систему передаются документы, отражающие движение по складу, агрегированные до необходимого уровня.
Общая идея плавного перехода:
Мы постепенно переводим пользователей в новую систему, а созданные ими учетные документы выгружаются в старую систему в необходимом виде (для старой системы выгруженные документы ничем не отличаются от документов, которые вводятся непосредственно в систему).
Детальное описание этапов плавного перехода
В ходе проекта постепенно переводятся сначала все оперативные подразделения (порядок может меняться в зависимости от требований в конкретном проекте).
В данном проекте план был такой:
🔄 Этапы плавного перехода
📦 1. Склады
В первую очередь перевод складов сырья, готовой продукции (ГП) и склада запчастей, затем остальных складов. Это связано с тем, что было расширение складов и как можно скорее было нужно запустить адресное хранение на складах сырья и ГП. Дописывать это в УПП или ставить WMS систему было нецелесообразно.
Но через какое-то время мы пошли еще дальше. Если мы можем запустить отдельно блок Склад, то почему бы не запускать каждый склад по отдельности? Это логичное развитие идеи плавного перехода.
В итоге, мы так и сделали:
- сначала запустили склад сырья, поработали 2 недели, устранили все возникшие проблемы (о них расскажу ниже)
- затем запустили склад ГП, проблем уже было существенно меньше
- затем запустили склад запчастей, там уже все прошло гладко.
Цель этапа в том, чтобы все документы-движения (поступления, перемещения, различные списания) по этим складам вводились в ERP. В УПП могут вводиться документы-распоряжения (заказы покупателей, заказы поставщикам и т.п.).
Т.к. для адресного хранения в ERP включен ордерный склад, то есть нюансы в документообороте. Например, в УПП списание готовой продукции происходит документом Реализация. В ERP реализация – это распоряжение для склада к отгрузке, а фактическое списание происходит расходным ордером (в УПП расходные ордера не использовались). Это все необходимо учитывать при планировании будущей работы пользователей и в обменах.
🏭 2. Производство
В рамках этапа переносится ввод всех данных, связанных с производством. С точки зрения финансового учета, это только документы выпуска продукции и списания материалов на выпущенную продукцию.
Основная цель этапа – запустить удобное планирование, которое в дальнейшем будет давать информацию не только производству, но и закупкам и продажам. Опять же, в УПП этого не было и дорабатывать ее так же не имело смысла.
Планирование в ERP - это тема отдельной статьи. Если коротко - то там много и методологических особенностей, и удобство работы оставляет желать лучшего. Поэтому мы реализовали блок планирования, который результат работы записывает в типовые объекты (этапы производства, графики производства и т.п.), но планирует независимо, более гибко, оперативно и, самое главное, с точки зрения юзабилити намного удобнее.
На данный момент запущено два этих блока, дальше проект поставлен на паузу в связи с не связанными с автоматизацией обстоятельствами. Но в этом тоже большой плюс нашего подхода - клиент получил существенные выгоды от запуска двух блоков, потратив не так уж много денег. И может спокойно приступить к следующему этапу спустя какое-то время.
Поэтому дальше опишу укрупненный план, который был заложен в проекте.
💼 3. Продажи
Перевод работы с заказами покупателей – формирование, резервирование, анализ доступности сырья для выполнения заказа, получение сроков изготовления заказа из подсистемы планирования производства и т.п.
Работа с задолженностью покупателей, претензиями и т.п. А также формирование реализаций.
🛒 4. Закупки
Перевод работы с заказами поставщикам, планирования закупок, работа с задолженностью поставщикам, и т.п.
💰 5. Финансы
Когда все блоки оперативного учета запущены, наступает ключевой этап - перевод финансового контура
- учет ОС, НМА
- учет прочих затрат, не отражаемых в контурах выше
- перевод оставшихся складов (офисные и тп)
- настройка закрытия месяца
- перенос настроек для управленческого учета (используется подсистема Итан:Управленческий баланс)
- казначейство
- бюджетирование
- обмен с БП
В общем, цель - перенести все, что еще осталось в УПП. Это большой объем, поэтому данный этап будет явно разбит на подэтапы в процессе дальнейшей работы.
При необходимости также переносятся исторические данные (история продаж, агрегированная финансовая отчетность за прошлые периоды и т.п.).
🔚 6. Отключение УПП
Когда все перенесено, получена отчетность в двух системах, обмены настроены и проверены, то старая система выводится из эксплуатации.
Важно! При реализации всех этих этапов, в УПП сохраняется учетный контур (расчет себестоимости, формирование финансовой отчетности, выгрузка данных в бухгалтерские базы и тп).
Обмен настраивается постепенно, под каждый блок, только теми справочниками и документами, которые необходимы.
🔄 Обмен данными между системами
Самое сложное в этом подходе - это, конечно же, обмен.
Во-первых, это высокие требования к скорости и надежности.
Во-вторых, различие в архитектуре и методологии между системами. ERP по функционалу сильно больше, чем УПП. Соответственно, и реквизитов больше. И нужно тщательно продумать как эти реквизиты заполнять.
И основные проблемы, с которыми мы столкнулись - это проблемы с обменом.
Сначала мы решили все делать на КД2. Купили правила, здесь же, на Инфостарте. Немного допилили их под наши требования. На тестах все было прекрасно, данные перегружали в обе стороны.
В рабочем режиме все пошло не так в первый же день. Обмен шел долго, а пользователи ожидали увидеть данные "сразу". Часть объектов не загружалась, непонятно почему. Вылезли ошибки, которые в тесте мы не отловили.
В силу особенностей КД2, отладка сильно затруднена. Часто бывало так, что выгружаешь повторно не загруженный объект - все хорошо. Почему в рабочем режиме он не загрузился сказать сложно.
Тут мы поняли, что влипли. Но спасло то, что это всего лишь один склад. Мы посадили одного консультанта, который сверял и перегружал данные. В это время программисты писали свой обмен. На основе старых наработок был сделан обмен через XML, в котором каждый элемент (справочник или документ) выгружался в отдельный файл.
Заняло это неделю, еще неделю заняла отладка в рабочей базе.
Кроме этого, был разработан отчет, который сверял данные между базами - какие документы перегрузились, какие нет.
Чуть позже добавили протокол загрузки, чтобы прямо из базы можно было посмотреть что загрузилось, что нет и по какой причине.
В итоге, второй склад мы запустили спустя 3 недели без каких-то особых проблем.
Итого
Плюсы плавного подхода:
- Заказчик получает первый результат через несколько месяцев после старта проекта, потратив небольшую часть бюджета.
- Гибкость в требованиях – требования уточняются перед запуском конкретного блока.
- Блоки могут стартовать параллельно, что сокращает общий срок проекта (например, один блок в этапе Моделирование, другой в этапе Разработка, третий – в ОПЭ).
- Сбой в работе одного подразделения менее критичен и проще устраним, чем сбой в работе всей компании.
- Существенно ниже бюджет и сроки проекта за счет меньшего количества переделок, более компактной команды, более простого запуска. Год-полтора вместо полутора-двух, 30-40 млн. руб. вместо 50-70 млн. руб. Т.к. проект не закончен, то расчет сделан исходя из планового бюджета и фактического бюджета по завершенным первым двум этапам.
Минусы плавного подхода:
- Высокие требования к механизму обмена между базами (как методологическая проработка, так и техническая реализация).
- Необходимость регулярной сверки данных между базами до полного перехода в новую систему.
Важно: Минусы нивелируются опытом и готовыми инструментами. Нами разработаны собственный механизм обмена, включающий протоколирование, и удобные отчеты для сверки данных между базами.
Заключение
Подход полностью себя оправдал. Несмотря на проблемы, результат был получен в запланированный срок и бюджет.
Данная методология позволяет значительно снизить риски проекта, сократить затраты и сроки внедрения, при этом обеспечивая непрерывность бизнес-процессов.
Ключевым преимуществом подхода является возможность получения промежуточных результатов на ранних этапах проекта, что позволяет заказчику видеть реальную отдачу от инвестиций и при необходимости корректировать требования для последующих блоков.
Успешная реализация плавного перехода требует высокой экспертизы в области интеграции систем и готовых технологических решений для обеспечения надежного обмена данными между системами. При правильной организации проекта данный подход становится оптимальным решением для многих средних и крупных предприятий, планирующих переход на современную ERP-систему.
