Peritaje informático Navision, SAP, Odoo,… 7 puntos clave.

Peritaje informático Navision, SAP, Odoo

Peritaje informático Navision, SAP, Odoo,… 7 puntos clave.

Esta semana he podido compartir con dos importantes abogados de Madrid algunas cuestiones sobre Peritaje informático Navision, SAP, Odoo, tanto de los que he tenido la suerte de ser su perito, como de otros que llevo con otros abogados, llegando a una serie de conclusiones que me gustaría compartir con vosotros, de utilidad clara para abogados, partners de Navision, SAP, Aqua, etc como clientes finales que deciden implementar un sistema de este tipo. Dado que la conversación nos llevó a profundizar en múltiples aspectos quisiera en este post centrar el foco únicamente en 6 de ellos, habiendo muchos más que los guardaré para otra ocasión.

Peritaje informático Navision, SAP, Odoo,… 7 puntos clave.

Seguidamente voy a inventariar 7 cuestiones que se deben tener en cuenta en la en la preparación de la demanda de una implantación de un ERP:

  • Importancia de la consultoría inicial. Muchos de los proyectos que fracasan y que llevamos en juicios adolecen de la falta de un análisis del proyecto inicial con suficiente detalle. Este análisis, realizado en colaboración entre un partner y el cliente, antes de decidir si la solución ERP es adecuada, evitaría cuestiones tan repetidas como la minusvaloración de un proyecto de este tipo o incluso la desestimación de un ERP en concreto para el cliente. Este trabajo, tan importante y clave, es justo el más evitado. Si vemos los dos enfoques:
    • El cliente suele no conocer que esto es necesario o bien rehúsa pagar un coste por analizar con más detalle X jornadas en entender los procesos de su empresa, como se adaptan al ERP y en último caso desestimar dicho ERP.
    • Entendamos que el partner, generalmente, tiene objetivos de venta por fabricante. Es decir, si un partner comercializa SAP o Microsoft Dynamics NAV su objetivo será vender su ERP y no se planteará la posibilidad que exista otro en el mercado de otro fabricante más adecuado. Sería como si vamos a un concesionario de coches y el vendedor me dice que compre un coche de la competencia. Además es probable que el cliente probablemente no accederá a pagar jornadas de detalle de consultoría para analizar el encaje de sus procesos con un ERP concreto.
  • Como un perito debe comunicar al juez. Varios de los juicios en los cuales mi cliente ha ganado, en parte por mi pericial, la diferencia ha estado en el poder comunicador de un perito y otro. Saber explicar a un juez que, de forma general, es profano en la materia informática, donde están los puntos clave, es fundamental.
  • Contrato y documento de requisitos. La prueba es imprescindible en cada juicio. Existen pruebas empíricas, como evidenciar que el cálculo de márgenes de un ERP no funciona adecuadamente, pero también documentales. Las principales pruebas documentales, más allá del email, son contrato y documento de requisitos. Ambos deben haber sido redactados con cláusulas que protejan el proyecto a una y otra parte. Por ejemplo, supeditar un pago a la aceptación del cliente, podría ser un error ya que estamos pactando que solo se cumpla unilateralmente, estando en este caso el partner a merced de lo que el cliente decida…
  • Importe de la demanda. Entendamos como importe de la demanda todo lo que el cliente o partner puede reclamar a un tercero. En este punto tenemos varias partidas:
    • Horas de consultoría.
    • Coste de licencias.
    • Coste de hardware.
    • Otros conceptos como dolo, lucro cesante, etc
  • Propiedad del código fuente que el partner desarrolla. En este punto podríamos decir que “Lo que no esté pactado no existe” Este concepto tan básico es un concepto olvidado muchas veces en la redacción de un contrato. Si el cliente que paga un código fuente quiere protegerlo en exclusiva o bajo otro concepto debe protegerlo por contrato. Entendamos que de lo contrario se pueden dar (y se dan) situaciones donde el partner podrá vender el mismo proyecto a otros clientes competencia del cliente.
  • Modalidad del proyecto. De nuevo tenemos que referirnos al contrato como prueba documental clave. En el estará o debiera estar la modalidad de proyecto. Voy a dar algunas opciones:
    • Proyecto cerrado. El proyecto se define en su totalidad y con el máximo nivel posible al inicio. Cuidado con la duración del mismo y los cambios que el negocio puede sufrir, como afectaría al proyecto, como se prioriza cambios de dirección empresarial que afectan al ERP, etc
    • Proyecto abierto. Generalmente se pacta un número de horas en base a un análisis previo inicial y se van consumiendo. Cuidado en este punto respecto del consumo de horas en cuestiones no relevantes, como se gestionan las horas imputadas a errores de programación, etc
    • Sin entrar en teoría de desarrollo ágil y para que el lector lo entienda, el cliente plantea un objetivo a alcanzar con una serie de funcionalidades y unos hitos cortoplacistas, donde, por ejemplo mensualmente, se realizan reuniones para planificar el siguiente mes (iteración)
  • Cuestiones de gravedad. Por último y no menos importante subrayar que las evidencias que presentemos al juez tienen que tener peso e importancia. Por poner algunos ejemplos, si los margenes, costes, stocks, etc de un sistema ERP no funcionan estamos ante puntos clave e importantes. Si la pantalla no es fácil de usar, ahora el usuario tiene que dar tres clicks frente antes que daba 2, etc estaríamos ante cuestiones a evitar (de forma general) o de lo contrario el juez puede perderse y no centrar su atención en lo verdaderamente importante.

La opción de proyecto abierto mediante (o no) metodología ágil es la más recomendable pero también la que supone más dedicación para el cliente y una codirección por ambas partes, confianza, colaboración, etc Es la menos seleccionada por los clientes.

Conclusiones

En mis años como perito informático y en aquellas periciales donde el ERP ha sido el objeto principal, he podido ver como cliente y partner han fracasado durante años en su implantación. En este sentido debemos entender que ambas partes pueden tener responsabilidades y que el análisis exhaustivo de los puntos anteriores (y de otros que incluiré en otros artículos) es clave para el éxito de la demanda. Antes de demandar

Luis Vilanova Blanco. Perito informático experto en ERP Navision, SAP, Odoo,…

Luis.vilanova@leyesytecnologia.com

606954593



× ¿Cómo puedo ayudarte?