Перенос истории в 1С. А может не надо?

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

После запуска (и выверки истории) 100% клиентов, которые наставали на переносе говорят:

• Если бы я знал, что нам предстоит, я бы ни за что в это не ввязался
• Кто вообще придумал переносить историю? (я? Нет, я не мог)
• Почему вы меня не отговорили, вы же профессионалы, знали, что будет плохо? Ах вы меня отговаривали… вы были недостаточно убедительны.

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

Итак, у нас в анамнезе сотни завершенных проектов. И среди них было несколько десятков таких, где мы не смогли отговорить клиента от переноса истории. Мы переходили на 1С с таких систем как:

• SWS (не знаете такую? А мы теперь знаем)

• SAP

• Мой склад, Мое дело, и другие онлайн сервисы

• 1С 7.7 (ПУБ, ТиС, и прочие конфигурации, даже полностью самописные)

• Устаревшие конфигурации 1С8 (УТ10, КА1 и так далее)

• И даже полностью самодельные (написанные талантливыми программистами, и тут нет сарказма) MS Access и другие базы данных 

Простыми словами о том, что такое «загрузка данных в 1С»

Загрузка начальных остатков

• Справочники (клиенты, товары, статьи затрат, банковские счета и так далее) выгружаются, а затем загружаются в новую систему.
  
  Скорее всего структура и состав справочников поменяется при переходе. Почти всегда вместе с внедрением новой системы, хочется «навести порядок».
  
  Отдельный маленький этап проекта – это проработка НСИ (нормативно справочной информации), выработка регламента работы с НСИ и правил мэппинга – соответствия старых справочников, новым.
• Делается срез остатков на момент перехода (рассчитываются остатки товаров на складах, остатки партий и их себестоимость, взаиморасчеты, остатки денег). Все это на «дату Ч».
  
  Данные по остаткам переносятся в новую систему входящими остатками (в зависимости от типа остатков, выбирается правильный вид документа для ввода).
  
  При этом учитывается новая структура справочников (новые, объединенные или наоборот разобранные позиции, новые папки, свойства, характеристики)

1. Естественный (видимый заказчику) процесс – это перенос всех документов выбранных типов из старой базы в новую. Может показаться что это просто большая работа.

   Один раз надо запрограммировать выгрузку и загрузку (за это, так и быть, клиент готов заплатить). А потом просто запустить нужные обработки, чтобы они «сами» все сделали, и за 5 лет документы перенесли.

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

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

   Скорее всего никто про них не знает и не думает, в выгрузку они не попадут, и будут обнаружены после расследования «почему же у нас не совпадают отгрузки в штуках за 5 лет».

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

2. Настоящая «бомба замедленного действия» в другом.

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

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

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

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

   Когда вы найдете эту ошибку (кстати, после того как вы ее найдете, что вы с ней будете делать? Не менять же механизм округления всей 1С, чтобы было «как раньше»?), и проведете документы заново, вы увидите, что она исправилась… Но что-то еще не совпадает. Успехов в поисках…

   Таким образом, после того как весь массив документов за 3-5-10 лет будет проведен в новой системе… Вы действительно надеетесь увидеть ту же себестоимость продукции, тот же финрез, те же отчеты о продажах и взаиморасчетах?

14 причин ненависти к переносу истории

Что помешает перенести весь массив данных из старой системы в новую 1С, и жить счастливо.

Был ли я достаточно убедительным?

Мне все еще не удалось отговорить вас переносить историю? ОК, вы клиент, и ваше желание – закон. Особенно, если оно подкреплено бюджетом.

Приготовьте деньги

Конечно же, перенос истории за период, это не только «сделать пару (десятков) обработок», которые выгрузят и загрузят данные. 
Это так же работа того, кто будет сверять каждый год, каждый месяц, каждый день. В разрезе всех видов данных. Искать расхождения и ошибки. Анализировать их причины, и вносить новые и новые требования в ТЗ на перенос данных. Эта работа несомненно стоит денег, и она тем дороже, чем больший массив нужно проверить. Чем больший объем данных должен «совпасть».

Приготовьте время

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

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

Забудьте про сжатые сроки

Какие бы мощные у вас не были сервера, историю придется переносить не раз, не два, и не десять раз. Десятки, а то и сотни итераций:

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

Ну и что вы предлагаете?

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