Переход с УПП на ERP. Сложности выверки регламентированного учета при «плавном переходе»

Мы занимаемся продуктовой разработкой на 1С и активно сотрудничаем с Инфостартом – наша компания входит в ТОП-10 всех партнеров Инфостарта по выручке за все время.

 

Перенос данных из УПП 1.3 в ERP 2 / УТ 11 / КА 2.

 

Расскажу про переход с УПП на ERP – обсудим сложности, которые возникают на такого рода проектах.

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

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

 

 

Вопрос перехода с УПП на ERP актуален:

• Фирма 1С несколько лет назад анонсировала снятие с поддержки УПП в 2026 году. Они наметили шаги, по которым УПП будет постепенно сниматься с поддержки. И до сих пор все эти шаги планомерно выполнялись.

• Так, с 1 мая 2022 года были сняты с поддержки все отраслевые решения. А это ни много ни мало – 28 популярных отраслевых решений на платформе УПП. Сейчас они все доступны для поддержки только на ERP.

• И мое мнение, что сделать проект перехода с УПП в 2023-2024 году будет дешевле, проще и менее больно, чем в последующих 2025-2026 годах.

 

Расчет плана проекта. Порядок действий и этапы проекта

 

 

Любой проект начинается с планирования. Вам в первую очередь нужно найти общий язык с заказчиком и понять его требования.

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

• Также нужно работать с ожиданиями, чтобы вы с заказчиком говорили на одном языке и понимали, какие будут этапы, какая у них будет длительность. Например, заказчик (ваш внутренний заказчик или внешний) может вам сказать: «Мы хотим перейти на ERP с 9 января, только остатками. До этого времени у нас есть полгода. Давайте на копии базы все отработаем, убедимся, что нам все подходит, а в новогодние праздники ваши ребята все сделают. Конечно же, также предварительно проведем обучение». Это – один сценарий. С другой стороны, вам могут сказать: «Давайте в первую очередь мы посадим в новую программу кадровиков и расчетчиков, а со старыми базами настроим двусторонний онлайн-обмен. Таким образом в течение года-двух будем планомерно подключать подсистему за подсистемой». Это – два совсем разных проекта, они будут включать в себя разные этапы, разную стоимость, разные риски. В первую очередь, с этими требованиями стоит определиться.

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

 

 

На этом слайде я собрал этапы, которые мы выделяем на проектах перехода с УПП на ERP.

Разумеется, внедрение ERP – это сложный проект, и он состоит из многих частей. Но я сегодня в докладе буду акцентировать внимание в первую очередь на такой части проекта внедрения ERP, как перенос данных. Это – очень важная часть, которая включает в себя очень большой объем работы.

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

 

Управление рисками

 

 

На этом слайде я привел список тех рисков, которые доставили нам неприятности в реальных проектах, в реальных ситуациях. Здесь таким все приведено общим списком. Давайте обсудим эти пункты по отдельности.

 

 

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

Например, приемку работ в вашей компании будет делать главный бухгалтер. И вот если она вам скажет: «Мы 10 лет назад делали переход с бухгалтерии 7.7 на Бухгалтерию 3.0 КОРП, плавали знаем», вы можете ожидать, что человек понимает также и сложности приемки работ. И это будет выполняться в итоге не в одну итерацию.

С другой стороны, может возникнуть ситуация, когда вам звонит потенциальный заказчик и говорит: «Нам нужно перейти на ERP завтра».

Что мы делаем, когда такой звонок получаем? Дальше следуют переговоры, переговоры, переговоры. То есть по приведенным здесь рискам основная стратегия реагирования, на мой взгляд, – это договариваться. И в конце концов вы либо договоритесь, либо разойдетесь. Это будет не самый плохой еще итог общения.

 

 

Следующие риски проекта – это целиком ваша ответственность как ИТ-специалиста, может быть ИТ-руководителя.

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

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

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

 

 

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

Для меня это самое-самое опасное – то, что я всегда переживаю. С этим очень сложно бороться.

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

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

Эти риски тоже нужно иметь в виду и предусмотреть.

 

Управление и организация коммуникаций на проекте

 

 

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

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

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

 

 

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

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

В переписке теряется контекст – когда ты не смотришь в глаза человеку, можно сделать другие выводы.

Что можно сделать, чтобы поработать над этим риском и как-то это дело предусмотреть?

Мы рекомендуем организовать удаленные коммуникации. Например, решить, что:

• Вопросы договора или допсоглашения к договору обязательно должны решаться на совещании в Zoom.

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

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

Рекомендую на этапе приемки работ собирать все замечания в табличку – либо в вашей внутренней системе HelpDesk, где у вас баги собираются, либо, если вы сотрудники разных компаний, это может быть простая таблица в Google Docs. Почему-то очень многие не делают этого сразу, а начинают вести такой трекер только когда уже прошел месяц-два проекта и в чате накопилось 30 задач. Если вы сразу этим вопросом не озаботитесь, вы потеряете время и, к сожалению, ресурсы людей. Лучше сразу договориться о том, что могут проверять аналитики, и что должны исправлять программисты. Вот такая простая рекомендация может быть полезна для всех и сэкономит время и силы, и нервы.

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

 

Плавный переход с УПП на ERP

 

 

• Самым комфортным и малорисковым для предприятия является именно плавный переход, когда переводят подсистему за подсистемой.

• На многих проектах мы встречаем примерно такой, как на слайде, порядок: сначала в новую систему переносят данные по зарплате и кадрам, потом – склад, потом – производство. И далее прочие подсистемы. Разумеется, в реальности на вашем предприятии это может быть по-другому.

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

 

Сложности сопоставления документов

 

 

Давайте перейдем к методическим вопросам перехода с УПП на ERP. Рассмотрим, в чем возникают сложности, если вы переносите не только остатки, но и в том числе обороты за период.

• ERP была спроектирована с нуля.

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

На самом деле, ERP получено на основе «Управления торговлей 11», но мы знаем, что «Управление торговлей 11» проектировалось с нуля. Из-за этого многие данные несовместимы или очень сложно найти такую совместимость.

Давайте про это поговорим подробнее.

 

 

На этом слайде приведен перечень очень часто встречающихся и неочевидных моментов.

Например, когда вам кажется, что для документа «Инвентаризация товаров на складе» из УПП понятным соответствием в ERP будет документ «Пересчет товаров», это, на самом деле, не так. «Инвентаризация» не создавала проводки, «Пересчет» создает.

Перечислению этих методических сложностей я посвятил целиком доклад год назад на конференции Инфостарта в Москве. Кому интересно, можете изучить.

Давайте подробнее распишу, почему это так.

 

 

Документ «Инвентаризация товаров» в УПП никаких движений не создает. А документ «Пересчет товаров» в ERP создает движения по регистру товара на складах.

Таким образом, документ «Инвентаризация товаров» вам нужно либо вообще не переносить, либо переносить непроведенным. А, соответственно, документ «Списание товаров» в УПП создавал движение и по управленческим регистрам, и по бухгалтерским. Если вы его перенесете только в документ списания товаров, то будете удивлены, он сформирует только бухгалтерские движения.

Таким образом, документ «Списание товаров» придется переносить в два документа сразу – в «Списание» и в «Пересчет». Именно тогда вы получите все необходимые движения, аналогичные тем, которые были в УПП.

За 6 лет, которые мы занимаемся такими задачами, наша компания подготовила свою методику сопоставления видов документов УПП и ERP.

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

Если что-то будет непонятно, мы с удовольствием прокомментируем, почему у нас реализовано так.

 

Сложности выверки регламентированного учета

 

 

А теперь самый сок – при переходе на регламентированный учет в ERP у вас встанет очень-очень серьезная проблема.

Дело в том, что вы не можете сделать перенос начальных остатков в новогодние праздники, потому что в конце года данные за прошлый год еще не зафиксированы. Они будут меняться. В разных компаниях это по-разному – где-то год закрывается в конце марта.

Тогда вы можете принять решение, что будете переносить данные, когда год закроется. Перенесете начальные остатки на 1 января, перенесете все документы за новый наступивший год в ERP, но тогда встанет проблема выверки движений.

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

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

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

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

 

Вариант решения «Прыжок веры»

 

 

Какие есть варианты выхода из этого?

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

Руководитель говорит: «Мы людей заранее обучили, они выйдут 9 января и будут работать в новой базе. Это – указ по предприятию, мы будем делать так».

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

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

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

Тут я бы порекомендовал заранее обсудить критерии приемки результата работ, и, в том числе, обсудить критические данные.

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

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

То есть вы обсуждаете, какие данные критичны для того, чтобы предприятие начало работу в новой информационной системе ERP, и какие данные можно будет в процессе еще довести до корректности.

 

Вариант решения «Плавный переход»

 

 

Второй вариант, альтернатива этому – это плавный переход.

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

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

• с помощью универсального обмена Enterprise Data, который уже встроен в УПП и в ERP;

• либо создать свою шину для обмена данными;

• либо использовать какое-то готовое решение – например, можно использовать наше решение с Инфостарта.

 

Настройки отражения в регламентированном учете. Используем исключения

 

 

Перейдем к следующим проблемам, которые возникают.

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

Что тут можно порекомендовать при переходе?

• У нас был случай, когда методология ERP очень здорово легла на ситуацию заказчика – предприятие производит косметику, переходили только остатками. И у них в группе компании действительно: одна организация – производитель, и там эта номенклатура на 43 счете; другая – торгует, там на 41 счете. Мы сделали стандартный перенос, а дальше обработкой проставили в настройках этой группы финансового учета исключения по счетам учета: для этой организации – такой счет, для этой организации – такой счет.

• Кроме того, в ERP можно настраивать исключения и по складам, если вам это требуется.

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

 

Закрытие месяца в ERP. Другие правила

 

 

В теме доклада про это говорилось, и думаю многие с этим уже столкнулись, кто-то еще только столкнется – процесс закрытия месяца в ERP сложнее, важнее и имеет несколько нюансов.

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

• При закрытии месяца в ERP информация, которую вы будете видеть в оборотно-сальдовой ведомости, не будет являться источником данных. Данные при закрытии будут браться из управленческих регистров. То есть бухгалтерия – это второй контур, он рисуется, генерируется на лету. Так реализовано в ERP.

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

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

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

 

Отличия в плане счетов и как с этим работать

 

 

 

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

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

Потому что, если начальные остатки переносить с помощью документа «Ввод остатков», то при правильных настройках групп финансового учета он сформирует такие движения, какие надо в ERP.

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

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

 

Перенос зарплатной и кадровой информации

 

 

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

Мы здесь рекомендуем использовать «Этап №2» стандартной обработки перехода от 1С. Считаем, что методически она переносит данные корректно и для многих успешно.

Этап №2 содержит два переключателя – либо условный «Полный перенос», либо рекомендуемый «Упрощенный перенос».

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

• Поэтому во всех случаях, когда вы можете себе это позволить, лучше делать упрощенный перенос. У вас будет создан документ «Начальная задолженность по зарплате» и «Начальная штатная расстановка». Сразу после переноса вы не будете видеть никаких первичных документов из старой базы, но сможете формировать больничные, отпуска, командировки – все данные для расчета среднего заработка будут перенесены в ERP.

 

Внедрение остальных подсистем

 

 

Далее очень часто переносят складской учет – это касается всех документов, которые участвуют в товарообороте.

Часто говорят, что именно это является настоящим внедрением ERP. Именно в этой подсистеме происходят максимально высокочастотные операции в учете.

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

 

 

Дальше можно продолжить постепенно подключать остальную функциональность ERP.

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

Даже стандартная обработка от 1С переносит для скидок только элементы справочника. Больше ничего не получается принести – нет соответствия.

И если по подсистеме производства еще можно документ «Отчет производства» перенести в «Производство без заказа» и получить точно такие же проводки, работать это все равно будет некорректно.

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

 

Полезные материалы

 

В докладе я ссылался на материалы:

• Онлайн-митап Инфостарта «Особенности перехода на 1С:ERP»: //infostart.ru/webinars/1665088/

• Доклад «Переход с УПП на ERP с сохранением документов» на конференции Infostart Event 2021 Moscow Premiere: //infostart.ru/1c/articles/1652566/

• Отчеты о внедрениях среди статей на Инфостарте (их много хороших, например: //infostart.ru/1c/articles/1540097/)

• Доклад «Плавный переход из УПП в ERP» (2019 год) с рекомендациями от фирмы «1С»: https://v8.1c.ru/upload/iblock/ac3/ac39ba3d6d9beebb1c16400dd4ee8c07.pdf – это уже классика. Этот доклад устарел только в плане интерфейсов, в плане методики он абсолютно актуален.

 

Выводы

 

 

Обсудим выводы.

• Все технические, методические сложности можно преодолеть. Главная проблема, которую нельзя преодолеть – это если проектом не управляют.

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

• Мы поговорили про сложности выверки регламентированного учета.

• И про то, насколько изменилась методика закрытия месяца.

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции  Infostart Event 2022 Saint Petersburg.