ERP: ¿Es la flexibilidad una ventaja? (Parte 2)

Aitana Soluciones ERP y CRMERP Leave a Comment

flexibilidad en el ERPAyer publicamos un post en el que explicaba qué es de verdad la flexibilidad en un ERP y las grandes ventajas que supone para nuestro negocio. Ahora, me gustaría hacer mención de la diferencia entre distintos niveles de flexibilidad y a los inconvenientes que puede suponer.

Para algunos fabricantes que han usado, por ejemplo, herramientas básicas de desarrollo de propósito general, la flexibilidad se entiende como proporcionar en todo o en parte el código fuente. Para mí, eso es un riesgo enorme, pues la mayoría de estos lenguajes no facilitan el trabajo uniforme y estándar al desarrollador, acabando en un alto porcentaje de casos en un caos de código que pone al usuario final en mano de los técnicos que lo han personalizado. Este riesgo no es para nada desestimable.

Es vital que la flexibilidad que se propone sea compatible con la organización del código, las herramientas para diferenciar personalizaciones de código base, etc.

 

Riesgos o inconvenientes de la flexibilidad

Empezaré por el final: un buen ERP que sea realmente flexible y cumpla los requisitos indicados anteriormente, casi solo tiene ventajas. ¿Dónde está pues el inconveniente? En el riesgo de no hacer bien las cosas, es decir, el factor humano.

Cuando un fabricante “serio” ofrece un ERP, se supone que proporciona una plataforma completamente funcional, de la que se responsabiliza al 100%. No quiere decir que un sistema no pueda aparecer en el mercado con algunos errores, pues el software es susceptible de bugs, pero lo que sí es cierto es que el fabricante (si es serio, inisito) se compromete a solucionarlos, y no solo eso, sino a hacer que el software crezca y se adapte a los cambios legales que pudieran aparecer. Normalmente eso lo hace a través de un servicio contratado de derecho de puesta al día, mantenimiento, o como lo denomine.

El verdadero riesgo, pues, está en aprovecharse de la flexibilidad, olvidando que se haga lo que se haga, es imprescindible que lo que saque el fabricante en el futuro sea fácilmente incorporable. Y para ello, es imprescindible una metodología de desarrollo muy controlada, muy documentada y, muy en especial, muy limitada al mínimo imprescindible.

Los errores más comunes, consecuencia de una flexibilidad mal entendida, son los siguientes:

  • Desarrollos innecesarios: es lo más habitual, por desgracia, y suelen ir acompañados de problemas funcionales y sobrecostes innecesarios para el usuario. La vida de un ERP implica cambios y mejoras constantes.
  1. Hay implantadores que no se reciclan para conocer las mejoras y funcionalidades que van apareciendo, y que cuando uno de sus usuarios les solicita cierta funcionalidad, por desconocimiento, la desarrollan a medida, aun cuando pueda estar en el ERP.
  2. También hay casos en que, y sigue siendo por falta de conocimiento funcional, el implantador ha tratado de resolver una necesidad de un cliente a través de un desarrollo a medida, que podría haber sido evitado completamente mediante un cambio en la parametrización.
  • Desarrollos caóticos: por desgracia, esto también es mucho más habitual de lo deseable. Se trata del típico implantador “muy técnico y poco funcional”, que ante cada solicitud de un cliente responde con un desarrollo, muy rápido, que por lo general da la sensación al usuario de que tiene a un excelente solucionador de problemas en el individuo, pero que cuando llega la instalación a manos de otro partner, se encuentra un código plagado de “if’s”, que se saltan el comportamiento estándar para hacer estas cosas especiales, y que por lo general, ni están documentados, ni explicados.
  • Desarrollos sobre desarrollos: ésta también es una práctica más habitual de lo deseable. Un implantador parte para cada instalación de la última que hizo, dando por supuesto que las mejoras que le han pedido en la instalación anterior siempre son buenas y, a lo sumo, tendrá que anular alguna de ellas. Eso produce un código caótico con líneas y líneas de código, funciones y objetos, que simplemente no se ejecutan, es decir, están solo “para estorbar” y que convierten la instalación en un sinfín de inutilidades que solo complican el sistema.

El resultado final de todos estos comportamientos heterodoxos recae en el mal del cliente final, pues al final produce:

  • Más incidencias
  • Más costes de migración
  • Más costes de mantenimiento preventivo y evolutivo

Hay que conocer el ERP para no necesitar adaptaciones más que en casos extremos en que, efectivamente, no tengan solución a través del modo de uso o la parametrización. Eso tiene el coste de la formación continua del personal, las continuas reuniones para poner en común soluciones particulares de los clientes, la documentación férrea y la comunicación interna eficiente.

Pero lo contrario, aunque puede ser más barato a corto plazo para el usuario, siempre acaba pagándose de otro modo y “con intereses”, pues todos esos comportamientos desembocan en sistemas muy limitados en su evolución, muy caros para ser actualizados, y al final, en costes altísimos de propiedad. El coste de propiedad, en este caso, suele crecer como mínimo el triple del ahorro en el coste de adquisición, a tres años vista.

Asegurarse de que el nuevo ERP es altamente flexible no es renunciable en absoluto, si se quiere que dure años y que ayude al negocio. Igual de importante es asegurarse de que el implantador es responsable, centrado en el conocimiento funcional y crítico con los desarrollos.

Deja un comentario