5 инсайтов архитектора: что происходит при миграции с 1С:УПП

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

Фирма «1С» прямо заявляет, что будет дальше: обновления УПП планируют выпускать до конца 2026 года, в I квартале 2027 они возможны только при необходимости сдачи отчетности за 2026-й. Изменения законодательства, которые вступят в силу с января 2027, поддерживаться не будут. А с 1 апреля 2027 прекратятся и консультации по УПП.

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

Миграция с УПП похожа на переезд: пока не начнешь «собирать коробки», не заметишь главного: что реально используется, а что можно выбросить, заменить или пересобрать заново.

Важно ответить на главный вопрос: зачем вам переходить с УПП. Причина «вендор снимает с поддержки» — это триггер, но не цель. На практике цели перехода бывают разные, и именно они определяют, куда и как переезжать. Глобально в основе выбора целевой системы лежат два контура учета:

• Оперативный/управленческий учет — предназначен для предоставления руководству информации, необходимой для принятия решений. Такая отчетность отличается высокой детализацией по операциям и процессам. Данные доступны в режиме реального времени или с небольшой задержкой.
• Регламентированный (бухгалтерский и налоговый учет), цель которого — предоставление информации о финансовом положении компании для внешних сторон (государство, инвесторы, кредиторы). Включает в себя обобщенные данные, которые соответствуют стандартам, установленным законодательством.

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

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

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

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

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

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

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

В-третьих, при планировании миграции нужно учитывать периоды. Здесь проблемным вопросом является переход не с начала года. Это накладывает ограничения на подготовку регламентированных деклараций и всего того, что формируется нарастающим итогом. Для таких ситуаций мы выделяем три подхода:

• Перенос остатков на начало года + детальные обороты. Честно: сложно и трудозатратно.
• Перенос остатков на дату перехода + сводные обороты за прошлый период. Агрегировать данные, которые не влияют на будущие процессы, но важны для расчета показателей нарастающим итогом с точки зрения учета.
• Перенос остатков на дату перехода + точечная перестройка пострадавших процессов. Иногда дешевле «склеить» два отчета, чем переносить в систему огромный объем исторических данных.

Отдельная сложность — управленческий контур. В нем процессы детальнее, цепочки длиннее, и независимо от даты перехода операции все равно будут «рваться» — один и тот же процесс может оказаться на стыке старой и новой системы. Например, заказ поставщику оформлен еще в УПП, а поставка произойдет уже после запуска нового решения. Или товар физически получен, но не оприходован; оприходовали, но не успели списать в производство/продажу. В итоге в новой системе не хватает первой половины цепочки, а в старой остается «хвост», который уже нельзя довести до конца. Такие переходные цепочки нужно минимизировать заранее: закрывать по максимуму до даты миграции, переносить незавершенные операции отдельным набором и заранее договориться о правилах, как учитывать все, что зависло между «двумя мирами».

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

Также планировать миграцию данных нужно по трудоемкости процесса: есть операции, которые легко ложатся на типовую систему без доработок, а есть сложные и «рваные» процессы, которые переносить гораздо сложнее.

План необходимо оценивать и по объемам данных. Остатки по банку-кассе можно просто ввести в систему операторским вводом. А вот справочник номенклатуры со множеством единиц измерений, серий, десятками тысяч SKU будет сложно загрузить в новую систему типовыми инструментами обмена, и нужно заранее продумать, как технически организовать такой перенос.

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

К миграции нужно готовиться заранее и детально ее планировать. Порой этот процесс по объему трудозатрат превышает саму разработку.

Миграция с УПП часто воспринимается как технический проект: «перенесем данные, запустим систему и продолжим жить как раньше». Но попытка повторить в новом решении все, что было в старом, почти всегда оборачивается крупными затратами.

Здесь важно понять, что действительно приносит бизнесу результат, и реализовать это в новой системе. Работает принцип Парето: 20% действий дают 80% результата. И если бухгалтер просит повторить кнопку, которая формирует отчет на пять тысяч строк, стоит задать вопрос: как эти пять тысяч строк помогут бизнесу достичь цели? Если никак — это не обязательный элемент новой системы.

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

Нужно посмотреть на процессы «сверху» — через цели и результат для бизнеса, а не с точки зрения отдельных действий пользователей в системе. После такого анализа станет понятно, какие процессы являются вспомогательными (в проекте их можно отнести на второй приоритет) или вообще не влияют на бизнес-результат (от таких можно отказаться). А есть процессы, которые напрямую поддерживают стратегические цели, и именно их нужно переносить в новую систему в первую очередь.

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

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

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

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

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

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

Тщательная подготовка к переходу почти всегда окупается. Что стоит сделать уже сейчас:

• Заморозить разработки в старой системе, чтобы не спонсировать улучшения того, что не пригодится в новой системе.
• Нормализовать НСИ (справочники, классификаторы, аналитики). Беспорядок в данных — один из главных «пожирателей» бюджета проекта. Если есть необходимость, стоит подумать про внедрение MDM-системы как способе дисциплинировать данные и облегчить переезд.
• Подготовить персонал: познакомить сотрудников с типовой логикой целевой системы, чтобы после запуска они быстрее освоились и начали работать без лишнего стресса.
• Не откладывать переход. Чем раньше приступить к проекту, тем больше шансов реализовать систему, которая приблизит бизнес к достижению целей.

Успешный переход начинается не с кнопки «выгрузить», а с анализа: зачем переезжать и что важно в новой системе для бизнеса. Когда выберете систему под цели, перенесете все необходимое, старые ненужные процессы не превратите в техзадание, а будущее смоделируете заранее — переезд будет не катастрофой, а обновлением: системы, процессов и, в каком-то смысле, культуры работы.

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

Что на самом деле происходит при миграции с 1С:УПП: запись доступна на Rutube.