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

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 causaran 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 un bug puede detener un negocio es algo fuerte.
• Actualizaciones: El ciclo de vida de una versión de un ERP es de 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 dos a cinco versiones de la misma aplicación lanzadas por el fabricante. Actualizar a la nueva versión puede requerir volver a desarrollar nuevamente todas las personalizaciones haciendo que tenga que pagar por la misma personalización varias veces. 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 Frank.
• 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 sera tan facil 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.

Sure Step: Grado de ajuste de un ERP

Un factor muy importante para tener éxito en una implementación de Microsoft Dynamics es determinar y entender el Grado de Ajuste. Este es un indicador numérico el cual explica que tan cerca o lejos estamos de los requerimientos del cliente en un NAV estándar.

Determinando el Grado de Ajuste

El Grado de Ajuste es determinado durante la Fase de Diagnostico de Sure Step en la parte de Fit Gap. El fin de estos trabajos es determinarlos procesos de alto nivel, los requerimientos funcionales y no funcionales además de definir la forma de la solución.

Generalmente hay 4 posibles resultados que requieren identificación:

• Característica estándar: Este es el resultado preferible. Significa que el requerimiento puede ser cubierto con el software tal cual, sin configuraciones o instalaciones especiales. La mayor parte de las veces hay muchos de estos resultados porque la mayoría de las tareas y procesos son comunes a todas la compañías y de ahí que son cubiertas por la solución estándar. Ejemplos de esto es el uso de múltiples almacenes, establecimiento y observancia de limites de crédito para los clientes o el manejo de reservas de productos a través el sistema.
• Configuración: Cuando la funcionalidad existe en el sistema pero el sistema debe ser configurado para su utilización; de hecho, son características estándar que requieren trabajo de consultoría para poder ser utilizados. Ejemplos de estos requerimientos son aquellos como los procesos de venta para clientes nacionales y extranjeros, el manejo de las ventas, los procesos de aprobación o configurar el sistema de planeación de la demanda.
• Personalización: Los resultados menos deseables. Cuando hay un requerimiento que no es cubierto por la funcionalidad natural del sistema, debe ser programado. Cosas como facturación automática no son soportadas por Dynamics NAV estándar y requieren algo (o mucho) de programación.
• Flujos de Trabajo: Si no hay un ajuste completo entre un requerimiento y la funcionalidad estándar, y la personalización es requerida, aun así existe la posibilidad de que la compañía decida realizar un cambio en sus procesos que se adapte a la funcionalidad estándar el lugar de programar. Hay muchas razones por las cuales esta es de lejos una mejor solución que la programación y siempre debe ser considerada antes de tomar la decisión de programar.

Las características estándar y los requerimientos de configuración se dicen que ajustan mientras que la programación se denomina gaps.

Dicho de una manera más sencilla, el grado de ajuste es el porcentaje de requerimientos que se ajustan sobre la suma total de requerimientos. Digamos que si durante el análisis se detectan 87 requerimientos de los cuales 63 ajustan, el grado de ajuste es del 72.4%, ¿puede ser mas sencillo?

Los Add-ons o soluciones ISV de terceros también cuentan como un ajuste así que es critico identificar esos posibles add-ons los cuales pueden ser utilizados como parte de un ajuste natural de NAV.

Entendiendo el Grado de Ajuste

Las características estándar y los requerimientos de configuración cuentan hacia el grado de ajuste mientras que las personalizaciones no. Aunque las soluciones de Dynamics vienen con capacidades de personalización, cada característica que requiera programación aleja la solución de un producto estándar.

Desde la perspectiva del grado de ajuste, todos los requerimientos son iguales. Esto significa que no hay un peso dado a un requerimiento y dos personalizaciones y ambos casos afectaran de la misma manera el grado de ajuste sin importar su grado de complejidad.

¿Esto es confuso no? ¿Cómo es posible que todos los requerimientos pesen lo mismo?

Bueno, naturalmente, no es así, pero durante el análisis deberemos de poner todos los requerimientos al mismo nivel, ajustes y gaps. Si un cliente dice que necesita fabricar en el método configurar por orden de producción, se puede decir que tenemos un gap, o podemos disolver este gran requerimiento en varios más pequeños hasta encontrar lo que el cliente realmente necesita. Uno se sorprende a veces de que un gap muy grande, al ser separado en varios más pequeños, puede ajustarse más a la solución. También puede ocurrir al revés.

Solo analizando los requerimientos a fondo y poniéndolos en un mismo nivel con una métrica correcta, se puede definir correctamente el grado de ajuste de un sistema, de otra forma, se estarán comparando peras con manzanas.