Hace aproximadamente un año compartíamos las funcionalidades que nos brindaba el módulo de Administración de cambios de ingeniería en Dynamics 365 Supply Chain Management, y hoy queremos aportar a la comunidad lo que hemos aprendido una vez implantado: lo que está bien, lo que está mal, lo que hemos mejorado y lo que está por venir, puesto que ya tenemos experiencia suficiente como para atrevernos a dar nuestra opinión sobre el módulo.
A modo de resumen, la Administración de cambios de ingeniería en Dyn365 SCM es un módulo poco utilizado en las implantaciones pero que aporta una serie de características interesantes relativas a la gestión del producto, como son la dimensión versión específica de este módulo, los atributos de ingeniería, las directivas de preparación y las directivas de liberación.
En este caso práctico, partimos de una petición de migrar de AX 2012 a Dynamics 365 F&O, donde la gestión de la versión del producto acabado se hacía mediante la dimensión Estilo y utilizando dos dígitos para enumerarlo. Estos dos dígitos, dependiendo del producto, podían tener significados distintos. Nosotros, al analizar la migración, planteamos la posibilidad de utilizar el módulo de cambios de ingeniería, puesto que resolvía de forma estándar la mayoría de las inquietudes que nos expresaba el cliente y, además, nos permitía abordar la gestión de la vida del producto, que hasta el momento se llevaba por fuera.
Una vez se crea un producto bajo una categoría de ingeniería, esta no se puede cambiar. Hereda los atributos propios de la categoría, así como las directivas de liberación y preparación.
Realizamos la segmentación de las categorías de ingeniería en varias fases, desde un modelo con mucho detalle (alrededor de 200 categorías) hasta uno más sencillo de 8 categorías. Al final, solo para el producto acabado, hemos creado alrededor de 40. Lo que nos ha hecho definir los límites entre una y otra han sido los atributos y la nomenclatura automática, es decir, los atributos de ingeniería permiten construir en base a su valor el número, el nombre y hasta la descripción del producto. Esto es muy práctico, pero obliga a pensar qué atributos son propios de un producto y cuales no.
Por el camino, tuvimos que desarrollar varias personalizaciones para dar soporte a la petición del cliente de tener atributos de ingeniería anidados, traducciones automáticas y una serie de restricciones orientadas a mitigar errores en la creación de producto, vía desde productos emitidos o vía pedido de cambio de ingeniería, ¡son formularios distintos!
Mejoras en backlog. Las traducciones de los atributos están disponibles de forma estándar, pero la nomenclatura de productos no está vinculada al idioma, por lo que por ejemplo, la descripción del producto montada en castellano sería la misma a utilizar en inglés, dando lugar a expresiones sin sentido.
Un problema que hemos resuelto es el hecho de tener varios equipos gestionando la creación del producto y el garantizar que hasta que cada uno no haya terminado sus obligaciones, el producto no esté disponible.
Con las directivas de preparación, cada equipo (financiero, comercial, planificadores, etc) es capaz de ver de forma automática qué trabajos tienen pendientes así como aceptarlos una vez realizados. Hemos prescindido de la opción de aprobación en dos pasos por no aportarnos valor.
Mejoras en backlog. Automatizar todavía más las liberaciones de preparación, de forma que el sistema valide de manera desatendida si se cumplen los trabajos y quitar de la carga de comprobar al usuario.
Las directivas de liberación nos determinan qué elementos debemos traspasar cuando liberamos un producto desde una empresa de ingeniería a otra empresa. Viene a sustituir y a potenciar lo que antes recogíamos vía emisión de producto.
La configuración de directivas nos ha permitido tener una entidad jurídica como repositorio de creación y gestión de producto. A la hora de liberarlo, hemos podido diferenciar lo que iba hacia empresas comerciales (traspasando solo el producto), de lo que iba a empresas de fabricación (traspasando producto y LMat).
El hecho de poder elegir una plantilla de producto en la empresa destino, y que esta funcione como las plantillas antiguas pero vitaminadas (por ejemplo se copian las configuraciones predeterminadas de pedido) permite tener una automatización muy grande. Tengamos en cuenta que la directiva es función de la categoría de ingeniería y de la empresa destino.
En los pedidos de cambio de ingeniería hemos tenido un poco de todo, pero por el camino hemos descubierto dos bugs que ya a día de hoy han quedado solucionados con el Update 38.
El primero hacía que el business impact de los productos de un pedido de cambio de ingeniería solo funcionasen cuando el idioma del usuario estaba en inglés (en-us).
El otro provocaba que cuando se utilizaba una secuencia numérica en la nomenclatura del producto, si este nacía vía pedido de cambio de ingeniería y posteriormente se modificaba algún atributo antes de procesar el pedido de cambio de ingeniería, este consumía un número nuevo de la secuencia, dando lugar a incoherencias.
Por lo demás, la herramienta funciona muy bien, da trazas de cualquier cambio, permite justificarlo e incluso la gestión de la liberación desde el propio ECO (Engineering Change Order) facilita mucho las cosas. Da la opción de modificar cualquier característica del producto y guardar traza de quién y qué se modificó, aunque parece que hay ciertos campos que todavía no se prestan a un funcionamiento, digamos, coherente (por ejemplo, ver nombre de búsqueda de producto en producto sin emitir…).
Por cierto, si creáis un producto vía ECO, aunque no tenga transacciones posteriores, NO lo podréis eliminar ☹. Esto es así por diseño, aunque tengo abierta una idea en Microsoft para que lo reconsideren. Os animo a votarla si también consideráis que es interesante.
Mejoras en backlog. Aunque tenemos trazabilidad de ECO en la empresa de ingeniería donde se realiza, desde las empresas que reciben el producto no se tiene esta visibilidad, obligando a viajar a la original para ver los cambios. Creemos que sería bueno que esta consulta fuese cross-company. Otro de los puntos que queremos desarrollar es la integración con Inventor, para que tanto el producto como su LMat se creen de forma automática desde Inventor.
Aunque en un principio las descartamos para hacer una aproximación más sencilla al módulo, finalmente hemos decidido utilizarlas para canalizar las peticiones de creación de nuevo producto por parte del área comercial, integrándolas en un futuro con Dynamics 365 Sales.
La acogida ha sido muy buena, aunque ciertamente hemos tenido que adaptar una serie de campos para poder recoger mejor (y estructurar y estandarizar), las necesidades de información para poder crear el producto sin depender de otra herramienta.
Sin lugar a duda, mirando hacia atrás cuando se planteó por primera vez utilizar este módulo, para el cliente ha sido una satisfacción el poder poner una herramienta nativa en Dynamics 365 FO al servicio del equipo de ingeniería de producto.
El futuro pasa por ahondar más en el módulo, creando Power Apps para la gestión de características muy específicas del sector fabricación/automoción (AMFEs, PPAPs, etc) y sobre todo, animando a los distintos usuarios que intervienen en su día a día con la herramienta a identificar posibles mejoras.
