Пять столбов успешного перехода на новую 1С

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

Попробуем рассмотреть задачу перехода на новую 1С с пяти разных сторон и привнести в ее понимание новые идеи, чтобы вы смогли взглянуть на эту проблему по-новому.

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

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

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

Результат работ

Первый столб, о котором я хочу рассказать – это результат работ.

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

• По сути, это проблема коммуникации: в задаче не сформулировано, какие подсистемы в какой срок должны быть внедрены, какие бизнес-процессы должны быть автоматизированы, какой должен быть учет, какие настройки параметров учета в новой базе 1С, в которой будут работать сотрудники. И это, конечно, приводит к проблемам.

• Возникает ситуация, с которой вы, возможно, сталкивались – заказчик говорит: «Да, вы сделали то, о чем мы договаривались. Но это не то, что нам нужно. Мы с этим работать не можем».

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

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

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

Наверное, вы знаете, что в УПП учет по сериям для номенклатуры чаще всего включали для учета импортных товаров, потому что никак по-другому там нельзя было хранить номера ГТД. А при переходе на УТ 11, Комплексную автоматизацию или 1С:ERP, учет по сериям чаще всего можно было безболезненно отключить – в этих продуктах учет по сериям для импортных товаров в разрезе ГТД не требуется, он в основном предназначен для номеров партий и хранения сроков годности.

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

Как можно и нужно было поступить в такой ситуации?

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

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

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

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

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

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

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

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

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

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

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

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

Управление

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

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

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

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

Договор как конструктор

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

Мы предлагаем использовать термин «договор как конструктор». Идея в том, чтобы прямо в текст договора включать пункты из коммерческого предложения – фиксировать в договоре работы, которые вы предлагаете заказчику в данном проекте.

В чем плюсы такого подхода?

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

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

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

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

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

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

Способы и сценарии первичного переноса данных

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

На представленном здесь скриншоте показан каталог шаблона конфигурации 1С:ERP, где собраны все существующие стандартные обработки для перехода на 1С:ERP, которые разработала фирма «1С». Они находятся либо прямо в каталоге, либо в его вложенных папках.

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

Кроме стандартных обработок от фирмы «1С», есть авторские инструменты для переносов данных – например, их можно найти на Инфостарте в разделе Маркетплейс. Они, как правило, позволяют переносить не только остатки, но и документы.

Большинство стандартных обработок для переноса работают на правилах конвертации данных – на механизме XML-обмена «Конвертации данных 2».

Но почему именно на КД 2? Вроде считается, что эта технология уже устарела и почти 10 лет существует КД 3 с форматом обмена EnterpriseData?

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

• Несмотря на то, что у КД 2 хуже производительность (данные выгружаются и загружаются медленно), там выше гибкость – добавить свои нетиповые объекты и поля достаточно просто. В то время как КД3 опирается на XDTO-схему, которую для добавления объектов нужно дорабатывать – про это я расскажу далее. В КД2 такой необходимости нет.

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

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

Допустим, в компании принято решение: с нового года учет будет вестись в 1С:ERP – что нужно сделать для перехода на новую систему?

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

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

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

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

Второй сценарий похож на первый, но с небольшим отличием.

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

Во всем остальном тут ситуация совпадает.

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

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

Все три перечисленные сценария позволяют быстро перейти и сэкономить время разработчиков.

• Но, во-первых, они применимы в ситуации, когда в основном в 1С ведется только регламентированный учет, потому что технологическое окно зависит от срока сдачи отчетности.

• А во-вторых, такой подход связан с рисками – при резком переходе, когда мы «рубим с плеча», может произойти ситуация, когда один из ключевых бизнес-процессов, автоматизированных в 1С, какое-то время не будет работать.

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

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

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

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

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

В этой ситуации я бы рекомендовал больше ориентироваться на формат 1С КД3 или EnterpriseData.

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

• В отдельных случаях стандартные обмены еще работают на формате XML – например, для Розницы 2.3 и УТ11.

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

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

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

Обратите внимание на возможности обмена через универсальный формат EnterpriseData.

На слайде показано, как выглядит узел плана обмена в универсальном формате на стороне УПП.

• Вы выбираете дату начала переноса документов.

• Вы можете фильтровать данные по организациям и по складам.

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

Популярные задачи по обменам XDTO (КД 3 / EnterpriseData)

При необходимости обмен в универсальном формате EnterpriseData можно дорабатывать.

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

• Добавление поля примитивного типа. Бывают ситуации, когда к обмену в универсальном формате нужно добавить свой документ – например, если у вас отраслевая конфигурация 1С. В первой инструкции описано, как для этой цели можно использовать перенос через поле AdditionalInfo. Кроме этого, можно использовать табличную часть ДополнительныеРеквизиты – она также есть в формате Enterprise Data.

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

  • Либо все-таки отказаться от стандартного менеджера обмена в универсальном формате, а написать в КД 3 свой, загрузить его в отдельный общий модуль в расширении и определенным образом подключить.

  • Либо редактировать в стандартном модуле менеджера обмена только отдельные ПКО или ПКС и перетаскивать их к себе в расширение.

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

• Объединение исправлений при обновлении релиза 1С. Четвертая инструкция – о том, как все поддерживать, если вы обновляете вашу конфигурацию на новый релиз. Там тоже в зависимости от количества правок возможны разные ситуации.

• Добавление своих типов объектов в формат (расширение формата обмена). И последняя инструкция, наверное, самая сложная – это расширение формата обмена. Есть стандартная инструкция от фирмы «1С», но она написана достаточно тяжелым языком, и в ней отсутствует важная настройка – как именно перетягивать к себе в расширение типы объектов базовых XDTO-пакетов. В нашей инструкции этот пробел исправлен – про это написано подробно.

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

Дополнительно. Перенос отраслевых

Хочу еще немного добавить про перенос из отраслевых конфигураций. В 2019 году фирма «1С» выпустила инфописьмо о том, что в 2026 году УПП будет снята с поддержки.

По этому плану с 1 мая 2022 года планировалось снять с поддержки все отраслевые на УПП. И это было сделано – пока фирма 1С идет по своему графику, который был анонсирован в 2019 году, никакого переноса сроков здесь нет.

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

Таблицу соответствия отраслевых на УПП и их аналогов на ERP также можно скачать из вложения к публикации.

Вопросы и ответы

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

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

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

Кроме этого, вы должны сказать заказчику, что если у него в базе отрицательные остатки, они не будут перенесены. И если принятие к учету основных средств в УПП оформлено через документ «ОперацияБух», оно тоже не будет перенесено.

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

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

Сталкивались ли вы при переносе в новые системы с ситуацией, когда для реализации требований заказчика типовой функциональности переноса не хватает? Например, при переходе с УПП на ЗУП 3 заказчику важно видеть все документы, а адекватного решения по их переносу нет. Как вы решаете подобные задачи и как подходите к их оценке?

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

Я бы в данном случае долго-долго дискутировал с заказчиком по поводу того, что так делать не стоит. И не брал бы на себя ответственность по поводу разработки переноса всех кадровых документов в ЗУП 3 «один в один». Конечно, можно разработать такие правила конвертации. Но добиться того, чтобы расчетный лист в двух системах потом совпадал, мне кажется, будет весьма затруднительно. Зарплата просто не начислится так же, как она начислялась ранее.

Проводите ли вы полноценное тестирование системы после переноса? Как добиться от заказчика, чтобы он все-таки полноценно протестировал функционал перед внедрением?

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

Они вводят свои данные, которые еще вчера вбивали в старую 1С, и могут работать где-то по аналогии. А если они совсем не обучены, это, опять-таки, повод отправить людей на курсы или провести обучение своими силами.

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

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

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

Конечно, бывают случаи, когда договориться не получается. Например, несколько лет назад у нас был проект по переходу с «Комплексной 1.1» на «Комплексную 2». У заказчика было огромное количество ручных операций, но в «Комплексной 2» это все перестает учитываться при закрытии месяца.

Главный бухгалтер потенциального заказчика предложила превратить эти ручные операции в корректные документы «Комплексной» – анализировать проводки и превращать в правильный вид документа. Но даже для одной их базы это был бы колоссальный объем работ. Написать универсальный алгоритм для такого преобразования было бы крайне сложно. Мы просто не взялись за проект, потому что понимали, что выполнить такие ожидания невозможно.

Главное – договориться еще «на берегу» о том, как заказчик видит конечный результат. Это сложно, но надо копать до последнего, чтобы раздвинуть этот «туман» у заказчика в голове и найти общий язык. Иначе ничего не получится. Это справедливо для любых сфер жизни: если вы понимаете друг друга, все получится.

Как выходить из ситуации, когда стало уже понятно, что вы с заказчиком не договорились? Через суд, или есть еще какие-то варианты?

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

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

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

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

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.