03 Sep Peritaje informático de ERP SAP, Navision, Odoo 2 conceptos usados incorrectamente
Actualmente estoy trabajando en algunos peritajes de ERP desde el lado del partner y cliente. En concreto en este post quiero hablar de dos errores que cometen muchos peritos informáticos cuando defienden la demanda de un cliente a un partner. Estos dos errores los denominadores el concepto de error bloqueante y el concepto de replanificación del mismo así como influye en un Peritaje informático de ERP.
Peritaje informático de ERP
Concepto de error bloqueante
La metodología que sirve a los partners para llevar a cabo un proyecto está basado en lo que se denomina Ingeniería del Software. La ingeniería de software es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento de software,y el estudio de estos enfoques, es decir, el estudio de las aplicaciones de la ingeniería al software integra matemáticas, ciencias de la computación y prácticas cuyos orígenes se encuentran en la ingeniería (https://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_software)
Existen diferentes formas y prácticas aceptadas en la industria para llevar a cabo un proyecto software ERP pero todas asumen que la existencia de errores de un proyecto nunca es cero, especialmente si este es grande y su número de funcionalidades o adaptaciones a la empresa final es importante. Es decir, la existencia de errores siempre será una cuestión que acompañará todo tipo de desarrollos software (web, app, ERP,…) de manera que partner y cliente trabajaran siempre en pro de minimizar su número e impacto.
¿Si esto es asi cuando podemos considerar que el partner ha realizado un mal proyecto? ¿Dónde poner la línea que separa un proyecto con errores aceptables de los que no? Desde mi punto de vista, especialmente orientado a peritaje informático y a demanda existe lo que denomino error bloqueante.
Un error bloqueante es aquel que impide de manera tangible el uso normal de un sistema software, en este caso citado el de un ERP. Por ejemplo, el fallo constante de la aplicación de descuentos en un proceso de venta afectaría a los pedidos, márgenes, costes, facturas, abonos, cobros, balance, P&G, etc Si este problema es reiterado y tangible desde el punto de vista que aparece con una frecuencia que no es posible usar el ERP sin su existencia estamos ante algo que impide de forma clara el uso del mismo.
Si un partner provoca que el ERP tenga errores bloqueantes de esta índole estaríamos, desde mi punto de vista, en una posición clara y cierta de poder obtener evidencias para la demanda judicial.
Si por el contrario los errores que tiene el ERP son mínimos, no afectan al uso habitual y normal del mismo o solo aparece en contadas ocasiones o se pueden resolver por el Partner y asi se lo hemos trasladado (no olvidemos el concepto de indefensión) no estaríamos hablando de errores bloqueantes y por tanto no creo que estuviéramos, solo por esta evidencia, en disposición de demandar al partner. Por ejemplo si tenemos un error que se da cuando el sistema no avisa de la aprobación de un pedido si este excede de una cifra concreta y esto rara vez se produce, estaríamos ante un error fácil de resolver, que ocurre pocas veces y que no interrumpe el uso normal del ERP.
Concepto de replanificación
En ocasiones los proyectos de implantación de un ERP no se desarrollan con la planificación pactada por contrato o en oferta preliminar. Esta replanificación del proyecto no tiene por qué ser, en sí misma, como negativa o evidencia de mala práctica del partner.
Desde mi punto de vista existen varias razones o situaciones por las cuales que el partner replanifique un proyecto es positivo para el mismo:
- Si el cliente y partner acuerdan realizar cambios en las prioridades del proyecto, en sus fases o alcance, de mutuo acuerdo, esta replanificación no puede ser considerada como una mala práctica del partner.
- En las metodologías modernas denominadas agiles, todos los proyectos se planifican periódicamente para realizar, de mutuo acuerdo con el cliente, aquellas partes más importantes y prioritarias cuanto antes. Es decir, se realizan fases e hitos que se replantean periódicamente, típicamente en semanas, hasta que el proyecto ha alcanzado una serie de horas dedicadas o funcionalidad base acordada en el inicio, pero siempre de mutuo acuerdo con el cliente y partner.
He encontrado, como en la pericial de este ERP que llevo a cabo en este momento, que el cliente presenta una pericial donde directamente y sin demostrar las razones, declara como una mala práctica replanificar las fases del mismo. Quizás por inexperiencia o por buscar evidencias de donde se pueda, este cliente aporto una pericial inconexa y con evidencias como esta que no se sustentan.
Conclusiones
Cuando vamos a demandar a un partner utilizar los todos los errores o las replanificaciones del proyecto pueden ser en algún caso recomendable pero no suficiente o correcto para llevar el juicio a éxito. El partner no puede asegurar un proyecto con cero errores partiendo que la propia Ingeniería del Software a si lo marca. De igual forma, la replanificación de fases o prioridades puede ser muy positiva para el proyecto si asi se demuestra, no siendo, directamente, una mala práctica del partner en sí misma.
Luis Vilanova Blanco. Perito judicial informático ERP SAP, NAvision, Odoo,… Web, App, Software a medida…
606954593
luis.vilanova@leyesytecnologia.com