Fases de un proyecto de implantación de SAP: implantación (4 de 4 – migraciones)

Bienvenidos al último post sobre la fase de implantación de SAP: el estudio y la puesta en marcha de la migración de datos. De modo que, vamos a explicar todos los puntos relacionados al tema y mencionamos algunos conceptos que son de importancia.

¿Qué es la migración en la implantación de SAP?

Cuando decimos migración de datos en la implantación de SAP, nos referimos a la transferencia masiva de todos los datos maestros y de todas las posiciones abiertas el día del cambio del sistema antiguo al nuevo sistema SAP. Y precisamente ese es el procedimiento al que se recurre una vez que pasemos todas las fases consideradas en esta serie de post sobre la implantación.

“Posiciones abiertas” son, por ejemplo, lo que verás en la siguiente lista:

• Los pedidos de venta abiertos (aún no enviados).
•  Las entregas en curso.
•  Los pedidos de compra aún no están cerrados.
• Los asientos contables abiertos (créditos de clientes y créditos de proveedores) aún no equilibrados, etc.

¿Qué herramientas se nos proporciona en la implantación de SAP para migrar estos datos?

Hay varios, comencemos con el último en orden cronológico es el Legacy Transfer Migration Cockpit (LTMC), que en italiano suena como “Cockpit para migrar los datos del sistema informático que va a ser retirado”.

Para utilizar el Cockpit de Migración, no es necesario escribir ningún código de programación. Se maneja desde una pantalla lanzada en SAP con el código “LTMC”. Esta herramienta funciona cargando archivos XML creados con una plantilla (una “estructura modelo”) que puede descargarse directamente de la LTMC.

El consultor debe compilar el archivo de la plantilla (idealmente descargándolo del antiguo sistema con el mismo formato requerido) y cargarlo a través de la funcionalidad proporcionada en el LTMC.

 LSMW – Legacy System Migration Workbench para la migración de datos

Esta es una herramienta más antigua que la anterior, pero sigue siendo muy eficaz (la he utilizado varias veces). Ofrece varias herramientas de migración y permite al usuario crear automáticamente (incluso sin conocimientos de programación) un programa de carga simplemente “grabando” todas las operaciones que el programa tendrá que realizar.

Supongamos, por ejemplo, que es necesario cargar materiales en el registro, el LSMW ofrece en un solo paso la posibilidad de crear los datos maestros en prueba, especificando qué campos son fijos (no varían en los registros que se van a cargar.

¿Cómo facilita SAP el proceso de migración?

 Pensemos tal vez, en el canal de distribución es siempre 10), qué campos deben variar según una lógica (por ejemplo, para un determinado tipo de material el sector de la mercancía es 10, para otro tipo de material el sector de la mercancía es 20), y qué campos son variables y estarán sujetos a la carga masiva (por ejemplo, la descripción del material será específica para cada material).

SAP creará automáticamente un programa basado en el registro que especifica el modelo de archivo (es decir, qué campos, formato, posiciones, etc.) que espera en el momento de la carga masiva.

¿Qué debemos tener en cuenta en la fase de migración de datos?

Como sabemos, en esta fase hay que ser muy cuidadosos para que toda la información que se someterá a la migración, pueda seguir el curso que le corresponde sin problemas, por eso, veamos algunos consejos sobre la fase de implementación de la migración:

En primer lugar, me reafirmo en lo que he dicho en posts anteriores sobre la necesidad de preparar siempre análisis funcionales. En este caso, el documento se llama estrategia de migración.

La estrategia de migración en la implantación de SAP define muchos factores, entre estos los siguientes: 

• Qué objetos se migrarán (datos maestros de clientes, datos maestros de proveedores, existencias, partidas abiertas, etc.)
• Cómo se migrarán los datos (a través de LTMC, LSMW, programas ad-hoc, introducción manual por parte del usuario, etc.)
• Cuáles son las distintas estrategias de migración, por ejemplo, se realizará una primera migración de prueba para esta fecha en el sistema de prueba SAP, y luego una segunda migración de prueba para otra fecha en el sistema de prueba.
• Cuando se realizará la migración al sistema real         .
• El modo de aprobación (validación de los datos) por parte del usuario.
• Cómo se conseguirá (quizás sólo con datos de muestra cuando haya miles de registros que migrar).
• En qué momento debe producirse dicha aprobación.

¿Qué hacer si necesita crear un desarrollo Ad-Hoc?

Cuando surge la necesidad de crear un desarrollo Ad-Hoc, es una buena práctica crear un análisis técnico para evitar los problemas descritos en los posts anteriores: es necesario definir el alcance del desarrollo y compartirlo con la persona que se encargará de la actividad.

Y por supuesto, explicando el documento, recogiendo sus aportaciones y rectificando. Haciendo que esté siempre actualizado en caso de que el desarrollador realice cambios sobre lo acordado previamente.

¿Por qué es necesario rectificar los datos antes de la migración?

También, para esta actividad es necesario comprobar que los campos a migrar y los nuevos campos han sido “acoplados” correctamente según la lógica de los nuevos procesos. Y no con un mapeo que mantenga la antigua visión de los procesos de negocio (para entender mejor la importancia de este concepto puedes leer el post sobre interfaces).

Otro consejo que quiero darte para la implantación de SAP, que puede parecer trivial, pero es muy importante, es limitar al máximo los objetos a migrar. Cuanto menos datos haya que migrar, mejor será la gestión de esta fase.

¿Cómo evitar sobrecargar el sistema con los datos para la migración?

En primer lugar, es una buena práctica “cerrar” tantas posiciones abiertas como sea posible. Muy a menudo, esto se hace compartiendo la decisión con los clientes y proveedores u otros socios comerciales que giran en torno al cliente.

Por ejemplo, si tenemos entregas que se están procesando, sería una buena idea disponer de todas las entregas que ya se han creado pero que aún no se han procesado definitivamente para el último día de uso del sistema antiguo. De esta forma eliminaremos un objeto a migrar (las entregas).

Otro ejemplo podría ser el de las facturas pasivas a registrar. Especialmente si el inicio del sistema (“Go Live”) se fija para el primer día de un mes, sería muy útil pedir a los proveedores que envíen las facturas correspondientes a todos los pedidos abiertos.

Migración de datos manual, ¿por qué hacerla?

Además, algunos objetos se pueden migrar mediante la creación manual. Esta solución es especialmente posible para los objetos que tienen pocos registros que cargar.

Esta solución también tiene la ventaja de incentivar al usuario para que aprenda a utilizar SAP rápidamente antes de la puesta en marcha.