¿Se debe migrar o realizar una re-ingeniería?

Aitana Soluciones ERP y CRM ERP Leave a Comment

Microsoft Dynamics NAV 2015 ofrece funcionalidades más completas y una interfaz más amigable que permite a los usuarios ser más productivos en sus tareas diarias. La ventaja de trabajar con el nuevo modelo de licenciamiento hace que muchos de nuestros clientes (que trabajan todavía en versiones antiguas) se plateen cambiar a la nueva versión.

Ante esta tesitura, debemos formularnos con la colaboración del cliente una serie de preguntas básicas que en función de sus respuestas nos permitirán proponer la mejor solución para su actualización.

  • ¿Cuál es la versión origen?
  • ¿Disponemos de procesos de actualización de datos hasta la versión a la que queremos llegar?
  • ¿Qué tamaño tiene la base de datos actual?
  • ¿Cómo es la calidad de los datos existentes?
  • ¿Hay una necesidad de purgar o archivar datos históricos?
  • ¿Cuánto tiempo podemos tener parado el sistema para realizar una actualización del mismo?
  • ¿Necesitamos todas las personalizaciones existentes en el sistema origen?
  • ¿Existe nueva funcionalidad estándar que pueda sustituir personalizaciones antiguas?
  • ¿Existen soluciones ISV o integraciones con aplicaciones de terceros que cubran funcionalidades de la versión origen?

En función de las respuestas obtenidas, el proyecto de actualización puede encaminarse hacia un proyecto de migración, una re-ingeniería de procesos o una mezcla de ambas metodologías.

¿En qué consiste un proyecto de migración?

Durante un proyecto de migración, tras un análisis previo de la solución, se inician las tareas técnicas de migración de objetos (funcionalidad) y de datos hasta obtener una base de datos BETA.

La actualización de objetos incluye varias tareas, como la fusión de los distintos tipos de objetos y el re-diseño de cierto código para adaptarse a la funcionalidad estándar. Si la versión origen del cliente, es una versión denominada CLASSIC la actualización de los formularios y de los informes requiere un especial esfuerzo, ya que son objetos que han cambiado sustancialmente a nivel tecnológico y deben rehacerse desde cero en muchos casos.

En cuanto a la migración de datos, tomando como base los procesos de migración ofrecidos por Microsoft, se adaptan, para migrar correctamente todos los datos personalizados del cliente a la nueva versión.

Una vez tenemos los objetos y los datos migrados, el partner realiza una serie pruebas simples de funcionamiento básico de la aplicación en la nueva versión. Ahora bien, es importante destacar, que la mayoría de las pruebas funcionales deben ser realizadas por el usuario final que previamente ha recibido una formación de las novedades funcionales y de usabilidad.

En cuanto los usuarios finales han validado por completo la base de datos en la nueva versión se busca un momento del tiempo donde parar el sistema y transformarlo a la nueva versión pasando a ser esta, la versión en explotación.

¿En qué consiste un proyecto de re-ingeniería?

En el caso de una reingeniería, existe un documento básico, denominado lista de procesos y subprocesos de la empresa, este documento debe ser cumplimentado por el cliente y va a definir toda la forma de trabajar del cliente en cada una de sus áreas.

Una vez que se recogen los requisitos del cliente con el documento anterior, se lleva a cabo el análisis identificando lo que es un GAP (requerimiento que debe resolverse con una personalización) de lo que es un FIT (requerimiento que puede cubrirse por funcionalidad estándar o una solución ISV), al ser una re-ingeniería es posible que se identifiquen GAP que ya existen en la versión actual y se propondrá su re aprovechamiento para la nueva versión. Los usuarios clave del cliente tienen una participación directa en esta fase, tanto en el momento de la definición como el de la validación. Una vez el análisis ha sido validado por el cliente, el partner realiza todas las personalizaciones necesarias, así como la migración de datos (generalmente solo maestros y saldos vivos) y verificación posterior de los mismos.

El equipo de desarrollo realiza unas pruebas básicas de la nueva versión, dando paso a los usuarios clave del cliente para su validación definitiva. Cuando todo ha sido validado por los usuarios clave se imparte la formación a los usuarios finales y se decide un día para trabajar con la nueva versión, quedando la versión antigua a modo de consulta.

Después de todo lo anterior, la única conclusión que podemos obtener es que ante la decisión de un cliente a cambiar de versión, hay una larga lista de temas importantes a tratar, además de indicar que no hay una respuesta única o sencilla a la pregunta de si se debe migrar o realizar una re-ingeniería.

Además de los criterios indicados en este blog; los recursos personales tanto del cliente como del partner, así como el tiempo y presupuesto disponible para el proyecto también van a ser criterios determinantes a la hora de optar por una u otra solución. En cualquier caso no es una decisión fácil, y el proyecto debe ser cuidadosamente concebido y hábilmente ejecutado.

Por todo lo anterior a la hora de acometer un proyecto de esta índole es importante contar con especialistas con experiencia de su lado que se apoyen en herramientas para optimizar este tipo de proyectos dentro de un precio fijo y la tranquilidad de saber que su proyecto está en buenas manos.

Si tienes en mente cambiar a Microsoft Dynamics NAV 2015 pero antes de tomar una decisión quieres probar la nueva versión, te invitamos a que solicites tu prueba gratuita.

Si deseas recibir más información no dudes en contactar con nosotros ¡Estaremos encantados de ayudarte: 

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *