En este nuevo post de nuestra serie de posts sobre software ERP de gestión empresarial hablamos del coste que asumimos al actualizar a Microsoft Dynamics NAV, y cómo reducir su impacto económico para nuestra organización.
Claves para recudir costes al actualizar Dynamics NAV
Cuando se piensa en la posibilidad de actualizar un software crítico para el negocio, la presión arterial comienza a subirnos ante la idea de soportar interrupciones de la producción, el tener que lidiar con datos complicados, la personalización de la herramienta, las migraciones que suponen la integración y la posibilidad de, incluso, perder algo en el camino. Y lo que es peor... el coste que debemos asumir.
Nada del otro mundo, de eso no se libra nadie. Los que tenemos experiencia en este tipo de operaciones sabemos que con la actualización de software sofisticado y personalizable se presentan esos riesgos y costes. Y a los clientes les lleva muchas veces a abandonar o posponer la actualización, lo que impide que se beneficien de las ventajas que esa implementación supondría.
Pero las actualizaciones no tienen que ser un sumidero de gasto. Después de años de gestión al actualizar a Microsoft Dynamics NAV, la verdad es que la empresa de las ventanas multicolores ha perfeccionado los procesos y procedimientos. El resultado: un ciclo de actualizaciones que no suponen, de una a la siguiente, cambios radicales en la estructura de la herramienta, sino mejoras que pueden ser adoptadas de forma gradual y sin un gran coste de personalización.
Factores que afectan al coste al actualizar a Microsoft Dynamics NAV
Hay que tener en cuenta una serie de factores al realizar la actualización, y con cada uno de ellos hay estrategias que podemos llevar a cabo para disminuir considerablemente el impacto económico:
Modificaciones personalizadas
Todas las empresas tienen algunas modificaciones personalizadas. Aunque ha habido todo un cambio de filosofía en las implantaciones de sistemas de gestión (los consultores pelean cada vez más con los clientes para que sean estos últimos los que se adapten al estándar), actualmente el grado de personalización de los ERPs es elevado. Cuando se trata de mejoras, hay una gran diferencia entre tener algunos informes modificados y tener un complejo sistema de integración específica del negocio, como por ejemplo un sistema de reservas integrado en la aplicación de ventas.
Cuando se han realizado amplias personalizaciones de la base de datos, al coste se añade el hecho de que éstos tienen que ser fusionados en la nueva versión del código NAV. Lo habitual es que ese código tenga que ser transformado, como ocurre con las dimensiones en una versión pre-NAV 2013.
¿Qué podemos hacer en estas situaciones? Lo primero: comprobar si la versión NAV que vamos a actualizar cuenta con funcionalidades estándar que sustituyen/complementan esa modificación. Si la personalización no ha adquirido todavía la categoría de estándar en NAV, debemos comprobar que no existe en NAV un complemento ya desarrollado que se adapte a nuestras necesidades.
Efectivamente, este software tendrá que ser fusionado en el nuevo código de NAV, pero los complementos tienen un impacto mucho menor en el código NAV estándar en comparación con el código personalizado programado. Un buen NAV Add-On tendrá la mayor parte de sus objetos fuera del rango objetivo NAV estándar y en un rango de ID de objeto independiente. Los objetos que integran el producto de software con NAV se pueden combinar y, por lo general, encajan como piezas de un rompecabezas, ya que vendrán de la misma versión.
Dynamics NAV nos aporta una nueva y útil funcionalidad denominada “Eventos y Suscripciones”. Con esta nueva funcionalidad, podemos mover el código personalizado en “Unidades de código” que están fuera del rango de objeto estándar, y establecer las suscripciones dentro de los objetos estándar. Aunque esto acarrea más trabajo al actualizar a Microsoft Dynamics NAV (sobre una base de una sola vez), las futuras actualizaciones serán menos costosas debido a esta nueva funcionalidad.
Informes propietarios e informes personalizados
Los “Informes propietarios” son aquellos que han sido desarrollados específicamente para la empresa de un determinado cliente, partiendo normalmente de cero. Por exigencias del entorno de desarrollo (y para diferenciar claramente los elementos que forman parte del estándar y los que no) estos pertenecen, por lo general, a la gama de objetos numerados en el rango 50.000-59.999. Por otro lado, un “informe personalizado” es aquel que ha sido modificado de la versión NAV estándar para satisfacer las necesidades de una empresa concreta.
El número de informes propietarios e informes personalizados que se incorporan a la base de datos puede tener un gran efecto sobre el coste de actualización. Antes de la introducción del cliente RTC, los informes eran desarrollados utilizando el - ya antiguo - Report Designer. Pero a partir de la edición Dynamics NAV 2013 esa herramienta ha dejado de utilizarse y los informes se desarrollan en código RDLC utilizando el entorno de desarrollo Microsoft Visual Studio.
Cada informe actualizado desde una versión pre-RDLC debe ser previamente modificado para insertar el Report Code en la base de datos. A continuación, el diseño debe ser realizado en Visual Studio. Este proceso, aunque tedioso y lleno de desafíos, es algo fundamental para posteriores modificaciones y simplificará el total de horas necesarias. En la mayoría de los casos, los nuevos informes son de una calidad netamente superior a los antiguos debido a la versatilidad de la herramienta. Permite corregir errores de forma rápida y eficaz en los informes (columnas demasiado estrechas, totales mal calculados, exiguas separaciones de documentos, etc..) que permiten una experiencia de usuario mucho más agradable y eficiente.
La mejor manera de reducir los costes en los desarrollos de los informes de ambas clases es prestar atención, examinar y recopilar aquellos que los usuarios están usando realmente. No podemos pasar por alto que, con el tiempo, los usuarios de nuestras bases de datos van y vienen, y con ello los informes necesarios para unos y otros también cambian. Por ejemplo, un controller puede aglutinar su supervisión contable en un informe específico, mientras que otro se maneja mucho mejor con un esquema de cuentas. Actualmente podemos implementar en la base de datos un desarrollo que recogerá los datos relativos a los informes que se están utilizando, proporcionando una imagen clara de lo que hay que actualizar.
CONCLUSIÓN
En el próximo post, seguiremos profundizando sobre cómo reducir el coste al actualizar a Microsoft Dynamics NAV. ¡Permaneced atentos!
