5 рисков перехода с 1С:УПП на 1С:ERP и как их избежать

Риск 1: перенос неочищенных справочников НСИ

Самый недооценённый риск — потому что выглядит как чисто техническая задача конвертации данных, а на деле определяет, насколько новая система будет годна к использованию с первого дня. 1С:ERP не очищает данные при переносе: дубли номенклатуры, контрагентов, единиц измерения и прочих справочников переносятся построчно, как есть, только теперь на них сразу наслаиваются новые документы и обороты.

На реальном прогоне ИИ-нормализации для производственного предприятия (молочный завод) было обработано 130 597 записей НСИ по 8 доменам справочников, и 46% из них получили вердикт MERGE — то есть почти половина справочника оказалась дублирующими записями, накопленными за годы работы старой базы. Ручная ревизия такого объёма заняла бы 8–9 месяцев силами команды специалистов; содержательный ИИ-анализ прошёл тот же объём за несколько дней.

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

Риск 2: несовместимость типового функционала УПП и ERP

1С:УПП и 1С:ERP — не версии одной конфигурации, а разные продукты с разной архитектурой учёта, разными механизмами расчёта себестоимости, разной логикой планирования и разным набором подсистем «из коробки». Часть автоматизаций, которые компания годами дорабатывала и встраивала в УПП под свои процессы, в типовой ERP просто отсутствует или реализована принципиально иначе.

На практике это проявляется в нескольких типичных местах:

• Расчёт себестоимости в ERP устроен иначе, чем в УПП (другие механизмы распределения затрат, другая последовательность закрытия периода) — процессы, завязанные на конкретные отчёты и настройки УПП, приходится пересобирать заново, а не переносить один в один.
• Доработки, специфичные для отрасли или для конкретного предприятия (нетиповые схемы учёта сырья, специфические регламентные операции, кастомные печатные формы с расчётами) в типовой ERP отсутствуют по определению — их нужно либо переносить программной доработкой, либо перестраивать процесс под типовой функционал ERP.
• Интеграции с внешними системами (складские WMS, оборудование, обмен с контрагентами), настроенные под API и структуру данных УПП, требуют пересборки под другую модель данных ERP — это не копирование настройки, а отдельная задача интеграции.

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

Риск 3: недооценка объёма доработок

Проекты миграции с УПП на ERP систематически недооцениваются по срокам и бюджету — и чаще всего именно из-за риска №2: пока полный список расхождений в функционале не выявлен явным аудитом, оценка проекта строится на предположении «перенесём типовыми средствами», которое на практике не подтверждается.

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

Что снижает этот риск на практике:

• Полная инвентаризация текущих доработок и нетиповых настроек УПП до начала оценки проекта, а не по ходу его выполнения.
• Резервирование в бюджете и сроках проекта отдельного буфера именно под доработки, обнаруживаемые по факту тестирования — не рассчитывать проект впритык к идеальному сценарию «перенесли и заработало».
• Приоритизация доработок по критичности для бизнеса — не всё, что было в УПП, обязательно нужно переносить в ERP один в один; часть процессов может быть перестроена под типовой функционал новой системы дешевле, чем воспроизведена доработкой.

Риск 4: риски для отчётности в переходный период

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

Источники расхождений в переходный период типичны для любого проекта такого масштаба:

• Разная методология расчёта — если механизм расчёта себестоимости или распределения затрат в ERP отличается от УПП (см. риск №2), сравнение «в лоб» одних и тех же показателей по двум системам покажет разницу даже при корректном переносе данных.
• Момент отсечки данных — если часть документов заводится параллельно в обеих системах на границе перехода, легко получить задвоение или пропуск операций, если процедура отсечки не зафиксирована явно и по датам, и по ответственным.
• Ошибки в перенесённых справочниках (риск №1) — искажают агрегаты отчётности сразу же, и в переходный период эту причину расхождений сложнее отличить от методологических различий между системами.

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

Риск 5: недостаточное обучение персонала новой системе

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

Риск проявляется в двух формах:

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

Снижение риска требует не разового ознакомительного тренинга перед запуском, а обучения, встроенного в сам проект: ролевое обучение под конкретные обязанности (не общий курс «как работает ERP» для всех подряд), тестовый контур для отработки реальных операций до go-live, и период поддержки после запуска, когда пользователи могут обращаться за разбором конкретных ситуаций, а не только по документации.

Как эти пять рисков связаны между собой

Риски не независимы друг от друга. Неполный аудит бизнес-процессов (риск №2) почти механически ведёт к недооценке объёма доработок (риск №3). Грязные справочники (риск №1) искажают отчётность именно в переходный период (риск №4), когда любое расхождение и так сложно объяснить. А персонал, не обученный новой системе (риск №5), с высокой вероятностью вносит в неё те же ошибки, которые годами накапливались в старой базе — то есть частично воссоздаёт риск №1 уже после запуска.

Практический вывод: закрывать эти риски по отдельности, в последний момент перед go-live, менее эффективно, чем встроить работу над всеми пятью в структуру проекта с самого начала — с явным аудитом на старте, буфером на доработки, методикой сверки отчётности и планом обучения, синхронизированным с этапами внедрения.

Частые вопросы