5 правил переноса данных при внедрении новых ИТ-систем

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

Чем раньше входе ИТ-проекта поднимется вопрос о переносе остатков данных - тем лучше. В конце внедрения информационной системы сложнее выделить бюджет на новые задачи, а команде аналитиков и разработчиков - найти время. Как вести работу с остатками данных на проекте, чтобы не потерять ничего важного, рассказал ведущий консультант ГК «КОРУС Консалтинг» Дмитрий Кучма.

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

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

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

1. В новой системе может не быть инструментов для ввода данных. В этом случае обращаются к аналитикам и разработчикам, чтобы они создали инструменты переноса. Иногда заводят даже отдельную промежуточную базу, куда помещают остатки, чтобы потом забрать их в новую систему. Так можно проверить объем и целостность данных, чтобы потом уже из этой подготовленной базы целиком перенести данные в рабочую базу при запуске новой системы.
2. Новому решению нужны данные, которых нет в старой системе. Например, компания не вела адресный учет на складах, а в новой системе этот учет будет. Здесь нужно предусмотреть создание множества ячеек, правил размещения, областей хранения, а также продумать, как вы будете вводить эти элементы в новую систему.
3. Многие данные надо вводить в систему быстро. Номенклатура в организациях может постоянно пополняться и состоять из десятков тысяч позиций, которые не так просто оперативно перенести. Например, многие крупные компании работают круглый год, в режиме «24/7»,. Для переноса данных такие организации могут остановить бизнес-процессы максимум на 1-2 суток: за это время надо полностью заполнить новую базу остатками и запустить работу на новой программе. Тут может понадобится разработка инструмента, который поможет быстро получить и записать большой объем данных.

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

Компании часто совершают 5 ошибок при переносе остатков данных в новую систему:

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

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

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

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

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

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

Чтобы не потерять данные из разных процессов, воспользуйтесь документами ввода начальных остатков и рекомендациями от 1С. Команде внедрения нужно продумать - как эти документы будут создаваться и чем заполняться. Это может быть очень трудоемко, потому что документы могут содержать табличные части с тысячами строк. По методике довольно хорошо подходит бухгалтерский учет - можно сверять по каждому счету, какие данные перенесены в части ввода начальных остатков. В технической же части нужно выделить достаточные ресурсы на серверах. Запись данных при переносе использует очень много памяти, это следует учитывать.

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

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

НСИ (нормативно-справочная информация) - справочные данные и настройки системы. Если неверно перенести их в новую систему, работа в ней будет затруднена из-за ошибок, либо вообще невозможна. Например, если будут регистрироваться неверные данные из-за настройки НДС сверх цены - в документах НДС будет добавляться сверху, а не включаться в сумму.

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

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

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

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

Не имея инструментов проверки соответствия данных, отвтетить не этот вопрос нельзя. Поэтому во время проекта нужно проработать отчеты, по которым можно оценить объем и правильность перенесения остатков, а также создать методику проверки целостности НСИ,. которая проверяет, например, содержат ли элементы справочников все необходимые реквизиты. Для части данных будет достаточно сравнить, например, оборотно-сальдовые ведомости. 

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

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