El pasado 2 de octubre de 2017 pudimos arrancar nuestro primer proyecto 100% cloud en Azure con la versión Microsoft Dynamics 365 Finance and Operations – Enterprise Edition (en adelante D3FO), y ante el acontecimiento de ser el primer Partner en España en poner en funcionamiento tanto la solución financiera como logística, hemos visto interesante compartir con vosotros la vivencia por la que hemos pasado tanto el equipo técnico, el equipo funcional y la dirección de proyecto en aras de que se puedan prevenir o anticipar ciertas situaciones en proyectos similares:

Precios CSP

En nuestro caso al no ser CSP directo, hicimos un estudio de mercado sobre las diferentes tarifas que ofrecían los diferentes proveedores para proporcionar la mejor a nuestro cliente. Sorprende que siendo mismo producto y condiciones, los márgenes sean tan diferentes. La recomendación es clara, si sois CSP indirectos y estáis ofertando cuenta nueva, pedir y negociar con varios proveedores. Por otro lado, si estáis realizando una migración de 2009 o 2012 a D3FO también estamos viviendo que existe un vacío de información tanto por parte de los CSP como de los fabricantes, en cuanto a la hora de aplicar descuentos. El documento oficial no deja lugar a dudas (clientes anteriores al 31/10/2016 con el BREP activo) pero cuando se solicitan precios con escenarios concretos, o bien se desconoce cómo hacerlo, o bien el fabricante deniega la operación sin saber exactamente la razón (al menos bajo nuestra humilde experiencia).

Limitación de entornos

Con la compra estándar de las 20 licencias (escenario de mínimos para D3FO) vienen incluidos 2 entornos no productivos y el propio de Producción. Hasta el momento del arranque, echamos en falta un entorno más, ya que teníamos que desarrollar y, durante un largo tiempo, convivimos funcionales y técnicos desarrollando en un mismo entorno puesto que distribuimos de esta forma:

UAT (Golden Environment) – No transacciones, parametrización final y datos maestros.
DEV: Entorno de Desarrollo, pero también entorno de pruebas al no tener otro.
PRO: Producción (intocable – responsable Microsoft)

Esta distribución solo es necesaria hasta el arranque, una vez en productivo UAT puede (y debe) ser un entorno transaccional donde probar antes de subir a PROD todos los desarrollos o cambios de parametrización, pero dado que el entorno de PROD no estará disponible hasta que en LCS se completen todas las fases del proyecto (y tengáis una call con un experto de MSFT para validar el go live – ver siguiente punto) se necesita un entorno GOLDEN donde tener la parametrización sin transacciones para que luego sea copiado a PROD.

Como os podéis imaginar la solución era sencilla, contar con un entorno puro de TEST y así lo hicimos, este entorno lo desplegamos en Azure y para optimizar costes, tuvimos que programar encendidos y apagados diarios de máquina. Una vez que tuvimos PROD fue eliminado definitivamente.

Para siguientes proyectos es probable que lo dejemos incluido de forma expresa en la propia propuesta de contrato ya que evita situaciones de riesgo en traspasos de información y backups.

Tu trabajo como Partner es auditado por Microsoft delante de tu cliente

Antes de salir a producción recibirás una convocatoria para que expliques ciertas cuestiones al fabricante, incluyendo un pequeño cuestionario de 9 preguntas en donde Microsoft quiere cerciorarse que ambas partes estáis de acuerdo en arrancar el proyecto. Hemos pedido permiso a Microsoft y si estuvierais interesados en tener una copia del «examen» antes de tiempo, os la podemos hacer llegar 😊, que nadie se alarme, este es un documento público.

Reto para el equipo técnico

El cambio a nivel técnico es muy importante y el equipo de dirección debe estar preparado para asumir que existirá, sí o sí, un tiempo invertido en la curva de aprendizaje que evidentemente no podrá ser repercutido al proyecto. Esta situación puede generar tensión ya que los resultados a nivel de desarrollo no serán tan ágiles como con versiones anteriores por pura adaptación al cambio.

Modelador de procesos

Siguiendo las best practices de Microsoft, dentro de LCS existe la posibilidad de documentar los procesos del cliente basándote en el modelo de referencia APQC. Es cierto que la posibilidad de utilizar el grabador de tareas para vincularlo al nodo de LCS pertinente del proceso ha sido una verdadera alegría, a la hora de documentar y sobre todo a la hora de controlar y simplificar las pruebas de los usuarios y CRPs, pero el desglose de información de los procesos no era tan claro y entendible a la hora de explicarlo al cliente. Desde aquí trasladar que en AXAZURE hemos desarrollado nuestra propia librería para tratar de «simplificar» en la medida de lo posible tantos procesos que en muchos casos no eran necesarios para el cliente.

ODATA – Microsoft Office Add-in

Esta funcionalidad puede ser tu mejor aliado o tu peor enemigo por los problemas que se pueden generar en la autenticación de credenciales. No vamos a entrar a valorar el tenant a utilizar, ya que utilizamos tanto onmicrosoft como cuentas propias, pero es de criticidad alta que cada vez que quieras editar o actualizar datos del ERP, que utilices el navegador en modo de incógnito o seguro, para que no te guarde credenciales anteriores.

Administración de datos

Desde nuestro punto de vista este ha sido uno de los puntos más favorables a la hora de implantar D3FO. La gestión de los paquetes de datos, o data packages, ha mejorado considerablemente el sufrimiento que hemos pasado en versiones anteriores con los Grupos de Definición primero, y los Grupos de Procesamiento después, a la hora de migrar datos. De hecho, hemos podido incluso utilizar Plantillas que ya vienen definidas por defecto por Microsoft con el conjunto de tablas que se deben completar, aunque siéndoos sinceros siempre preferimos utilizar nuestros propios conjuntos de paquetes de datos.

Una de las experiencias más reutilizables que se adquieren en el primer proyecto es entender todos los trucos de este módulo: el orden de carga de cada entidad, los errores que pueden surgir y como resolverlos, ciertas actividades que hay que realizar manualmente en el nuevo entorno antes de transferir datos, etc. Una vez que consigues este conocimiento, traspasar datos entre entornos (sin copiar la base de datos) se vuelve una tarea mucho mas sencilla que en ediciones anteriores. Como dato interesante comentaros que configurar ciertas entidades (códigos postales, artículos, etc.) con nivel transaccional grande, para permitir cargas en paralelo, se hace indispensable si no queremos esperar muchos minutos a que se carguen los datos.

También comentaros, que copiar bases de datos entre entornos, por ejemplo de UAT (SQL Azure) a DEV (SQL tradicional), no es una tarea sencilla y requiere mucho aprendizaje (prueba y error) ya que la documentación oficial no es suficientemente clara.

No queremos ser muy pesados con extensos artículos, por tanto, si te está pareciendo interesante este post, en próximos días seguiremos contando más experiencias relacionadas con este primer arranque: