Personalizar o no personalizar, esa es la cuestión.

Esto lo escribí en Marzo de 2012 y 10 años después, decidí volver a postearlo haciendo algunos ajustes pequeños debido al cambio de paradigma sufrido por NAV a BC mismos que marcare en azul.

Cuando se ve un proceso de negocio demasiado complejo y alejado de un ERP estándar, la primera reacción es personalizarlo.

Muchos teóricos de los ERP´s dicen que un ERP es tan bueno como pueda ajustarse exactamente a los procesos. Y en su mayoría están bien. Pero la mayoría de los ERP´s son bastante genéricos y para ajustarse exactamente a los procesos requieren personalización. Cuando algo no se ajusta a la funcionalidad natural, se personaliza, ¿así de simple no?

No lo es, lo siento.

Por cada línea de código personalizado que el cliente quiere que se agregue al sistema, este se aleja cada vez más de lo que realmente es, un producto que se adquirió en primer lugar. Puede que no le interese este punto en este momento ya que, después de todo, lo que desea es resolver sus problemas del negocio. Pero el resolver sus problemas actuales con este método de aproximación de entrada, puede introducir en la ecuación nuevos problemas que no son del negocio los cuales causarán mucho dolor tan pronto se vuelvan relevantes.

A continuación veremos una lista de las razones por las cuales se debe pensar mucho antes de pedir una personalización del ERP:

• Regresión: Es un termino muy bonito en la teoría de desarrollo de software y es un eufemismo para “la regamos”. Esto pasa cuando se hace un pequeño cambio en la funcionalidad A y de pronto la funcionalidad B comienza a comportarse raro. Cuando se introduce una característica nueva, se deben hacer pruebas de regresión para asegurarse que el nuevo cambio no descompone algo que ya estaba ahí. Con los ERP´s, no importa lo que se haga, siempre hay mucho de ya estaba ahí para revisar. Entre mas personalizaciones, mas pruebas y lo que los consultores no encuentren en dichas pruebas, será encontrado por los usuarios finales, pero después del arranque. Cazar todos esos bugs puede llevar meses. Personalmente he visto proyectos que se convierten en una carrera de pruebas de regresión.
• Arranque: Las personalizaciones prolongarán el arranque. Entre mas haya, mas tiempo llevará el arranque. Aunque el presupuesto inicial “cubra” los costos de personalización, los tiempos que generan puede hacer que el proyecto no sea exitoso. Con los sistemas ERP, las fechas de arranque importan mucho, es mas sencillo cambiar a la solución al termino de ejercicio fiscal, y menos costoso. Si se falla en la fecha determinada, se deberá posponer todo un mes completo.
• Soporte Oficial: Cuando hay un problema, dependiendo del plan de soporte que se tenga, se puede solicitar soporte al fabricante del sistema (Microsoft en el caso de NAV). Cuando lo hace, lo primero que ellos preguntan es si el problema puede ser replicado en una versión estándar del producto. Si no es así, estamos fritos porque Microsoft no da soporte a versiones personalizadas. Para problemas pequeños, esto no es necesariamente importante pero imaginar que un bug puede detener completamente una empresa es algo impactante fuerte.
• Actualizaciones: El ciclo de vida de una versión de un ERP es de 6 meses dos a tres años mientras que el ciclo de vida de una implementación de un ERP es de cinco a diez años. Esto significa que en la vida de una implementación, puede haber entre 10 a 20 dos a cinco versiones de la misma aplicación lanzadas por el fabricante. Actualizar a la nueva versión puede requerir revisar la extensión volver a desarrollar nuevamente todas las personalizaciones haciendo que tenga que pagar por la misma personalización varias veces cuando no esté en modo de suscripción a la extensión si no como desarrollo pagado especial. Por supuesto que puede optar por no actualizar pero esto significa amarrar toda su infraestructura a versiones anteriores de software (y hardware).
• Know-how: Las personas vienen y van, pero el conocimiento también va  y viene con ellos. Si utiliza un ERP para administrar su negocio, tiene el gran beneficio de poder contratar power users con experiencia en el ERP. Pero esto tiene su lado malo si creo un Frankenstein, cualquiera que venga con conocimientos del ERP no será de mucha ayuda. Y cuando esas personas que conocen al Frankenstein se van, tendremos un problema. Lo mismo es para su partner, los consultores y programadores pueden cambiar, pueden tener experiencia de clase mundial, pero no será fácil darle mantenimiento a Frankie.
• Bloqueos por el proveedor: Uno de los beneficios de comprar un ERP estándar es evitar el bloqueo de proveedores. Si llega el momento en el cual ya no esta a gusto con su partner, simplemente se cambia por otro. Si su primer partner desarrolla un Frankenstein para usted, ya no será tan fácil cambiar de partner. Los partners son muy cauteloso antes de aceptar dar soporte a aplicaciones que ellos no desarrollaron, puede ser muy costoso también. Si se tiene que cambiar de partner, algunas veces, esto significa re implementación.

Cuando se ven las personalizaciones desde esta perspectiva, se vuelve obvio que dichas personalizaciones pueden convertir un ERP en un generador de costos a largo plazo.

Por supuesto que no todo es blanco o negro. En ocasiones las personalizaciones pueden ser totalmente necesarias. Todo lo anterior no significa que no se deba personalizar, realmente implica que antes de hacerlo, se deben considerar todas las alternativas, y si finalmente las personalizaciones son el método a seguir, tome en cuenta todos los temas tratados y elija al mejor partner disponible en base a su experiencia, metodologías y  estabilidad de programación.

No se olvide que un ERP es un sistema para administrar un negocio, esto no implica necesariamente que deban cumplirse los caprichos de los usuarios, lo importante es que el negocio funcione.