Peritaje ERP Navision en empresa de fabricación

PERITAJE ERP NAVISION EN EMPRESA DE FABRICACIÓN

Peritaje ERP Navision en empresa de fabricación

Cuando una empresa decide contratar a un partner de Navision (Microsoft Dynamics NAV) el  primer paso es solicitar si éste ha realizado proyectos similares al que se está solicitando. En este caso una gran empresa que fabrica tornillería necesita irremediablemente, por obsolescencia del desarrollo a medida anterior, la incorporación de un nuevo sistema de software que le permita interconectar la nueva maquinaria, portal de ventas, etc. piezas que han aparecido en su nuevo negocio.

PERITAJE ERP NAVISION EN EMPRESA DE FABRICACIÓN

Las empresas que se dedican a la fabricación y en especial aquellas que parten de materia prima, que transforma mediante una serie de procesos más o menos complejos, y terminan en un producto terminado suelen tener estructuras de costes complejas. Más aun cuando el precio de coste no solo varia por variables más o menos típicas (volumen y proveedor de compra, condiciones especiales etc.) sino incluso del valor de bolsa del hierro, aluminio,…, por ejemplo.

Además tengamos en consideración que el margen de un producto terminado que fue fabricado con materia prima adquirida a un coste, por ejemplo unos meses atrás, el coste de la materia prima en el momento de la fabricación puede ser muy diferente, como es el precio de mercado de los metales. Es decir, el margen puede no ser igual para un producto fabricado con una materia prima adquirida en una fecha que a posteriori, siendo la misma pieza. Navision no tiene esta funcionalidad de base debiendo adaptar el partner el producto a este tipo de problemática.

En este peritaje se dan también otros condicionantes que desde mi punto de vista fueron clave para que la empresa final demandara al partner, en concreto:

  1. Los requisitos iniciales no fueron adecuadamente considerados, lo que denominamos siempre una infravaloración por parte del partner del proyecto.
  2. Los consultores que trabajaron en el proyecto final, pese a que en el global el partner si tenía experiencia, no atesoraban conocimientos del sector ni experiencia previa. Esta situación se suele repetir en demandas que he trabajado, es decir, aunque el partner ha trabajado en proyectos similares los consultores que finalmente llevan el proyecto no lo tienen o incluso ya no están en la empresa.
  3. Complejidad elevada para ciertos cálculos de precios de coste, márgenes, etc. Esta parte, clave en una empresa de fabricación donde los márgenes son muy reducidos y hablamos en ocasiones de piezas de varios decimales de precisión suele ser una problemática repetida en otros fracasos de proyecto.
  4. Muchos de los peritajes que me he encontrado parten de un proyecto base y el cliente, pese a su descontento de la evolución del mismo, aceptan contratar ampliaciones del mismo, lo que está enmascarando en realidad un proyecto mal ejecutado.

El material utilizado fue toda la documental que se me entrego como fueron contratos, documentos de oferta, emails, documentos técnicos, et casi como la propia instalación del ERP que se me puso a disposición en base a una copia de seguridad de Navision.

En esta pericial informática trabaje los siguientes conceptos:

  1. Estudio de funcionalidades desarrolladas en Navision que provocaban graves errores para la empresa.
  2. Análisis de todas las funcionalidades no realizadas y contratadas.
  3. Tasación económica de todos los desarrollos no realizados para poner en valor en euros las horas/consultor faltantes.
PERITAJE ERP NAVISION

En este juicio asistimos, además de los testigos, peritos de ambas partes y un tercero judicial. Recuerdo haber defendido claramente los objetivos de mi pericial, basados en mis evidencias y estudio, que se resumieron en:

  • Existen graves problemas en las unidades de medida que podrían provocar descuadres en las unidades de existencia de los productos, cuestión que llevaría a esta empresa a una situación de conocimiento de su stock incorrecta, valoración de su stock errónea y aceptación de pedidos con riesgo de no disponer del stock adecuado.
  • Existe graves problemas en la gestión de lotes y el envío a picking a almacén, pudiendo enviar pedidos parciales, pedidos sin completar, generando graves ineficiencias en el día a día de la empresa.
  • No he encontrado ninguna evidencia que exista un desarrollo que permita a la empresa la interconexión mediante EDI con terceros. Esta funcionalidad estaba incluida en el contrato firmado entre partner y cliente.
  • Existen multitud de funcionalidades clave para la productividad y rentabilidad de una empresa como la contratante, incluidos en contrato y anexo, no desarrolladas o no funcionalmente correctas.
  • El importe estimado de los desarrollos pendientes asciende a xxx.xxx + IVA teniendo en cuenta que aesta cantidad habría que sumar las oportunidades perdidas y rentabilidad de procesos derivados de los mismos.

Por lo que concluyo que la implantación de Navision adolece de funcionalidades con errores y fallos que no permiten el trabajo adecuado para la empresa así como falta de funcionalidad EDI clave para el éxito del proyecto, afectando gravemente a la rentabilidad, productividad y relación con los clientes de la empresa contratante.

En este caso quisiera comentar un problema añadido a un PERITAJE ERP NAVISION que me he encontrado en varios juicios y que complica gravemente el juicio. El tercer perito que nombraba es un perito que el juez, tras leer la pericial informática de una parte y de la contraria, decide contratar para “desempatar” o clarificar las posturas de contrarias de ambos peritos.

La importancia en los argumentos y trabajo de este perito judicial es clave pues será la que, en muchos casos, tenga en cuenta el juez. Si este tercer perito no tiene experiencia en periciales de ERP estamos ante una situación peligrosa ya que sus argumentos podrían no ser al 100% correcto, en parte por su falta de experiencia en estos proyectos.

En este caso el juez en su dictamen decidió prácticamente un juicio nulo, donde consideraba que si bien los procesos del cliente eran altamente complejos, quizás estos deberían haber estado más detallados y con más peso en los documentos de alcance del proyecto, como el contrato, por parte del cliente.

Luis Vilanova Blanco. Perito informático ERP Dynamics NAV

606954593

luis.vilanova@leyesytecnologia.com



× ¿Cómo puedo ayudarte?