Inicio
 > Informes e investigaciones > Blog de TEC > Seis errores de migración de datos

Seis errores de migración de datos

Escrito por: Norma L. Davis
Publicado: enero 30 2008

Para cualquier organización que implanta algún sistema, una de las actividades más importantes y arriesgadas es la migración de datos, es decir, llevar los datos del sistema heredado al sistema nuevo.

Sin duda, la selección, la implantación y la operación de una aplicación empresarial para un sistema, por ejemplo, planificación de recursos empresariales (ERP), gestión de activos empresariales (EAM) o cualquier otro, tiene elementos técnicos, pero para implantar estos sistemas se necesita mucho más que habilidades técnicas. Sin embargo, también es necesario tener habilidades de gestión para poder llevar a cabo todas las actividades de implantación y operación de la aplicación. Quienes tienen esas habilidades deben vigilar de cerca y comunicarse con el personal técnico que se encarga de configurar e implantar la aplicación. En muchos casos, esto significa que los altos directivos tienen una participación activa en todo el proceso de implantación, hasta que se hace la migración de datos de un sistema heredado a la aplicación nueva.

Pero ¿por qué es necesario que la dirección se involucre en la migración de datos? ¿No se trata simplemente de transferir datos tabulares de un sistema a otro?

Un buen ejemplo

Hace no mucho, participé en la implantación de IFS Applications en una empresa de fabricación que pertenece al mercado medio. Cuando finalmente el equipo de implantación había terminado la migración de los datos, estábamos todos eufóricos porque habíamos logrado un índice de éxito del 85 por ciento; más de lo que esperábamos. De hecho, habíamos logrado migrar el 98 por ciento de los datos del sistema heredado a IFS Applications.

Sin embargo, nuestra excitación se convirtió en preocupación cuando nos reunimos para hacer la auditoría de calidad de los datos, porque nos dimos cuenta de que el técnico que había hecho las migraciones había cambiado las definiciones de los mismos. Lo que pasó fue que, por tener más cuidado con el aspecto tecnológico de la migración, se hicieron cambios al formato de los mismos. En algunos casos, los datos se colocaron en campos diferentes a los que pertenecían originalmente, con el fin de que fluyeran mejor en la aplicación nueva. Por un lado, estos cambios facilitaron la migración, pero el nuevo formato entraba en conflicto con la lógica de la empresa y los flujos de trabajo que habíamos diseñado en IFS Applications.

En realidad no fue culpa del técnico, quien naturalmente había hecho lo posible por que la transferencia de datos tuviera éxito. Sin embargo, una migración exitosa no depende nada más del aspecto técnico; hay que tomar en cuenta el aspecto empresarial, por lo tanto, no pueden ser nada más los expertos en tecnología de la información quienes se encarguen de esas tareas.

Durante la segunda migración pudimos recuperarnos, pero esta falta de supervisión se tradujo en varias semanas de retraso. A partir de entonces, decidimos que sería un representante del equipo administrativo, no un técnico, el que se encargaría de los cambios.

Después de esta experiencia me detuve un momento a pensar y me llegó la inspiración para elaborar esta lista de seis errores que suelen ser comunes en la migración de datos.

Primero: La migración de datos es una función de TI

Aunque sin duda, el personal de TI sabe cómo extraer los datos antiguos e importarlos en la base de datos nueva, hay otras funciones del proceso de migración de los cuales debe encargarse el equipo compuesto por los representantes de cada área funcional que se verá afectada por la aplicación nueva. Ellos saben realmente cómo se usaban los datos en el sistema antiguo y cómo se usarán en el nuevo.

El ejemplo anterior ilustra por qué sucede esto. Es muy probable que los expertos técnicos no sepan reconocer cuándo hay que tener información sobre las operaciones y la administración para llevar a cabo el proceso de migración. O puede ser que el empleado nuevo de TI, que quiere demostrar sus habilidades durante el proceso de migración, cambie el formato de los datos para agilizar el proceso.

Moraleja: Asigne propietarios a cada tipo de dato o función para que tomen las decisiones y trabajen con el personal de TI durante el proceso de migración.

Segundo: El departamento de TI interno está preparado para extraer e importar los datos

En muchas pequeñas y medianas empresas (PYME), el departamento de TI está compuesto solamente por uno o dos empleados, y aún un departamento más grande probablemente no tendría las habilidades necesarias para ocuparse de los aspectos tecnológicos de un proceso de migración. Dependiendo del sistema heredado, la extracción de los datos puede implicar codificación del software y el uso de otros paquetes de software que ayuden a llevar a cabo el proceso. No todos los empleados de TI están capacitados para extraer los datos del sistema heredado usando estos métodos.

Hace poco participé en un proyecto en el que el sistema heredado del cliente exigía que se desarrollara código de software en Cobol para poder cargar algunos de los datos a las tablas de migración en el formato correcto. Sólo uno de los empleados de TI conocía Cobol, y trabajando solo no habría podido desarrollar todo el código a tiempo para cumplir con el programa de implantación. En situaciones como ésta, es necesario capacitar a otros empleados internos o externalizar el proceso, y cada una de estas opciones tiene sus costos y sus ventajas.

Cuando la dirección de una empresa se enfrenta a una situación como ésta, tiene que tratar de no opinar sobre si el personal existente puede manejar la migración, porque pocos expertos en tecnología quieren admitir públicamente que no tienen las habilidades necesarias. Lo más probable es que decidan aceptar el reto del proceso nuevo.

Moraleja: No suponga que su personal de TI tiene todas las habilidades técnicas o la capacidad para manejar la migración de datos. Si toma en cuenta las habilidades y la carga de trabajo que tienen sus empleados de TI –sin olvidar que seguramente tendrá que dar soporte al sistema heredado durante la implantación-, podrá evitar cuellos de botella que ocasionen retrasos en el proyecto.

Tercero: La migración de datos es uno de los últimos pasos antes de iniciar la operación del sistema nuevo

Muchas veces se cree que porque una empresa necesita contar con la información más actualizada en su sistema nuevo, hay que llevar a cabo la migración de datos justo antes de iniciar la operación del mismo. Nada más falso. Por el contrario, la migración de datos se hace al principio y con frecuencia. Hay que hacer una primera migración justo después de capacitar al equipo de implantación. Esta migración temprana le permitirá entender de dónde provienen sus datos, cuál es su calidad y su condición y a qué tablas y campos del sistema nuevo hay que migrarlos. Los resultados de estas migraciones tempranas también ayudarán al equipo de implantación a entender cómo funciona el software nuevo, y así podrán tomar mejores decisiones. Es posible que haya que hacer varias migraciones antes de que la empresa pueda hacerles pruebas a sus procesos en el sistema nuevo.

Moraleja: La migración es un proceso, no un evento que ocurre una sola vez. Por lo tanto, hay que tomarla como un elemento central de la implantación. Si planea cuántas migraciones hará, podrá determinar cuánto durará la implantación.

Cuarto: Es necesario y recomendable hacer cambios a los datos

Cuando hay problemas con los datos durante la migración, la solución no siempre es hacerles cambios. Es normal que se hagan cambios durante las dos primeras migraciones, pero se hacen varias migraciones de datos precisamente para poder cambiar y mejorar constantemente los datos, las tablas y el código, hasta que los datos heredados se acomodan correctamente en el sistema nuevo. Sin embargo, conforme avanza el proceso, hay que controlar el número de variables, y eso significa hacer menos cambios. El problema con los cambios es que muchos datos tienen relaciones de interdependencia con otros datos.

Hay que evitar lo más que se pueda hacer cambios a los datos y a sus definiciones, porque cualquier cambio puede afectar otros datos a un grado exponencial. Un cambio, por muy pequeño que sea, a un elemento de un dato, un campo, un código o una tabla, puede afectar muchos datos y muchos procesos. Por ejemplo, cambiar una unidad de medida de “unidad” a “kilos”, puede afectar la cantidad en existencia, el costo unitario, el costo de ventas y el valor total del inventario.

Moraleja: Hay que vigilar de cerca los cambios que se hagan a los datos, las tablas o el código, sobre todo a medida que la empresa se acerca a la fecha de lanzamiento del sistema. El gerente de proyecto tiene que estar al tanto de los cambios que se soliciten y de las ventajas y, sobre todo, los riesgos que implica cada uno. Un simple cambio a los datos puede tener consecuencias importantes, así que es necesario formalizar un proceso de revisión y aprobación de los mismos.

Quinto: Tuvimos mucho éxito en la migración. Ahora tenemos que hacer pruebas con nuestros procesos

Si cree que la migración de sus datos fue satisfactoria y que ya puede empezar a hacer pruebas con sus procesos empresariales, se está engañando. Una migración de datos nunca tiene el resultado que se espera; siempre hay sorpresas, aún en la última migración. Hay que verificar los datos en el sistema nuevo, en cada pantalla y en cada campo, para asegurarse de que están bien organizados y en el formato correcto. Aún los datos más simples pueden ocasionar problemas que pueden tener consecuencias graves si no se detectan a tiempo.

Para ilustrar, les doy el ejemplo de una empresa que tenía un sistema heredado en el que las direcciones de los clientes y los proveedores se encontraban juntas. Toda la dirección - calle, ciudad, estado y código postal- residía en un solo campo. El sistema nuevo tenía un campo distinto para cada uno de estos elementos. Al migrar los datos al sistema nuevo, toda la dirección se incluyó en el campo calle, y los campos ciudad, estado y código postal quedaron vacíos. Fue necesario trabajar mucho en el formato para corregir el problema.

Moraleja: Hay un viejo proverbio que dice que no hay que hacer suposiciones cuando se trata de datos. Después de migrar al sistema nuevo, hay que revisar y verificar los datos de todos y cada uno de los campos del sistema. Sólo entonces es conveniente hacer pruebas con los procesos.

Sexto: Siempre podemos hacer cambios después de iniciar la operación del sistema

Muchas veces, las empresas están tan concentradas en la fecha de lanzamiento de su aplicación nueva, que quieren ahorrar, y para hacerlo deciden esperar para hacerles cambios a los datos. Esto puede ser un error, simplemente porque el equipo de implantación estará tan ocupado antes y después del lanzamiento del sistema, que es muy probable que haya que retrasar más los cambios. Después del lanzamiento, el equipo deberá enfocarse más en las tareas que llevaba a cabo antes de la implantación, por lo tanto estará demasiado ocupado para tratar todos estos cambios. Asimismo, después de iniciar la operación del sistema ya no contará con los recursos externos especializados que forman parte del equipo de un consultor o un proveedor. Una de las mejores formas para reducir el costo total de propiedad de su aplicación empresarial es limitar el tiempo de consultoría después del lanzamiento del sistema.

Moraleja: Haga bien las cosas antes de iniciar la operación del sistema. Después del lanzamiento le será mucho más difícil –y más costoso- hacer cambios.

Los retos de la implantación de un sistema pueden parecer enormes, pero si trata el proceso de migración de datos con las mejores prácticas, podrá evitar los problemas que pueden retrasar el reemplazo satisfactorio del sistema. Será necesario que cuente con un enfoque sólido a la migración de datos que le permita contar con los recursos y el tiempo adecuados. Sólo así podrá confiar en que el sistema nuevo soportará el proceso empresarial y que todos gozarán de los beneficios.

Acerca de la autora

Norma L. Davis es fundadora y presidenta de Connective Edge Resources, una firma independiente de consultoría en gestión que se especializa en selección e implantación de sistemas ERP. Tiene un doctorado en administración ejecutiva del Peter F. Drucker and Masatoshi Ito School of Management de Claremont, California. Asimismo, es profesora adjunta de Californa State University, en Fullerton, y de la University of Redlands, en California. Imparte los cursos de gestión, gestión de operaciones, planeación y control de operaciones, gestión de operaciones y calidad, y gestión de estrategias. Se puede contactar con ella en norma@connectiveresource.com.

Si desea obtener más información o iniciar su propia comparación de soluciones, visite el

Centro de evaluación de ERP de TEC

 
comments powered by Disqus