Главные причины неудачной миграции данных в ERP

Согласно Википедии, «миграция данных - это процесс передачи данных между типами хранения, форматами или компьютерными системами…» довольно простое объяснение, не правда ли? Однако, хотя определение кажется столь же легким, сколь и простым. На практике сбои при миграции данных ERP могут создать каскад проблем, которые в мгновение ока могут привести к сбою всего проекта внедрения ERP.

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

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

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

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

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

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

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

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

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

Читайте анонсы наших статей:

Почитать наши архивные публикации можно и в Yandex Q