• Давление регулятора. Законодательство меняется непрерывно: обновляются формы отчетности и расширяются категории обязательной маркировки. Дорабатывать эти изменения в УПП становится неоправданно дорого.
• Time to market. Устаревшая система тормозит развитие компании: не позволяет быстро масштабироваться, открывать новые направления и тиражировать учет на дочерние структуры.
• Рост стоимости поддержки и дефицит кадров. Молодые специалисты не изучают УПП и не хотят с ней работать. Оставшиеся эксперты уже доросли до уровня ведущих архитекторов и тимлидов, и стоимость их работы постоянно растет.
• Деградация данных и архитектуры. За 10–15 лет система накопила огромный багаж доработок. Данные часто расходятся.

Как переходить?

В зависимости от специфики процессов возможны разные сценарии:

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

Когда переходить?

Компании делятся на 3 группы по критичности дедлайна:

• Группа А — критичен переход с 1 января 2027 года. Есть жесткие требования с нового года (например, обязательная маркировка крупной категории товара), строгие внутрикорпоративные регламенты закрытия месяца и нет ИТ-команды для поддержки УПП.
• Группа B — переход в середине года. Бизнес допускает временную ручную сборку отчетности (включая расчеты в Excel) и готов переносить данные по ходу года.
• Группа C — могут подождать еще год. Есть сильная внутренняя ИТ-команда и стабильные процессы, что позволяет реализовать проект без спешки.

Ошибка 1. Недооценка различий систем

Суть проблемы: у ERP и УПП разная архитектура. Например, в ERP проводки вторичны по отношению к регистрам (их нет сразу «в моменте» проведения документа); себестоимость рассчитывается процедурой закрытия месяца; ручные корректировки регистров запрещены, так как ломают ядро системы.

Как предотвратить/исправить: еще до старта проекта определить топ-15 уникальных бизнес-критичных процессов и передать интегратору. Понять и принять логику ERP, где возможно — использовать типовые механизмы.

Ошибка 2. Попытка сделать из новой ERP привычную УПП

Суть проблемы: заказчик требует перенести привычные формы и интерфейсы. Интегратор соглашается и ломает ядро. Из-за этого систему будет сложнее и дороже обновлять.

Как предотвратить/исправить: формулировать задачи через бизнес-результат («нужно получить такие-то данные»), а не через интерфейс («сделайте эту кнопку здесь»).  Также можно отправить ключевых пользователей на курсы по типовой 1С:ERP, чтобы заранее познакомиться с принципами работы системы.

Ошибка 3. Неправильное распределение задач между внутренней ИТ-командой и интегратором

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

Как предотвратить/исправить: сэкономить можно, но важно объединить специалистов под началом единого архитектора, обладающего необходимой насмотренностью в ERP-проектах.

Ошибка 4. Миграция грязных исторических данных 

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

Как предотвратить/исправить: по возможности поставить табу на перенос документов прошлых периодов, переносить только справочники и остатки. Если запуск системы запланирован на середину года и перенос первички неизбежен, к миграции необходимо готовиться очень заранее (механизмы выгрузки, промежуточные сверки и пр.).

Ошибка 5. Сбор требований (обследование) по опросным листам 

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

Как предотвратить/исправить: заменить опросники на демонстрацию реальной работы ключевых сотрудников в УПП. Это сразу показывает интегратору реальные сценарии, помогает отсечь устаревшие доработки и вовлекает сотрудников заказчика в проект.

Проблема текущего применения ИИ на проектах

Сейчас специалисты используют нейросети точечно: аналитик генерирует текст ТЗ, а программист пишет куски кода в чат-боте.

1. Эффект остается на стороне исполнителя: конкретный специалист быстрее закрывает свои задачи. 
2. Остается «узкое горлышко»: проект по-прежнему вязнет в цепочке согласований и правок.

Суть подхода AI First

AI First меняет принцип внедрений — в ИИ переносится весь процесс реализации проекта. ИИ-агенты выполняют задачи, а эксперты контролируют результат и принимают ключевые решения. В чем преимущества?

• Сокращение сроков. Устранение многодневных согласований документации и рутинных задач позволяют быстрее запустить систему.
• Экономия бюджета. Стоимость проекта перестает складываться из тысяч часов работы аналитиков и разработчиков.
• Согласование результата, а не документов. Заказчик больше не тратит недели на вычитку документации — он проверяет реальные сценарии в прототипе.
• Стабильное качество. Агенты работают по заданным стандартам.
• Единый контекст. Вся история решений, специфика бизнеса и правила учета хранятся в единой проектной памяти, которая затем станет основой для ИИ-зированной поддержки и развития системы.

Этапы проекта по методологии AI First

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