¿Qué es la adaptación de un ERP? Ajustar el ERP a la empresa, no la empresa al ERP

El director de compras sigue recordando la frase de la reunión con el proveedor del ERP: “Nuestro sistema no lo hace así; tiene que cambiar su proceso”. Sin embargo, el esquema de aprobaciones de la empresa se apoya en una razón coherente: las solicitudes por encima de cierto importe pasan por dos responsables distintos, y en los trabajos subcontratados el albarán de envío se emite con una regla aparte. ¿Hay que adaptar el software a la regla o la regla al software? La mayoría de las empresas se hace esta pregunta meses después de empezar el proyecto, cuando los usuarios empiezan a volver a la hoja de cálculo. La respuesta no está en ninguno de los dos extremos, sino en elegir conscientemente qué se va a adaptar.

La adaptación de un ERP es el ajuste de un ERP estándar, o su ampliación con módulos adicionales, según la forma real de trabajar de la empresa en ámbitos como las reglas de negocio, la estructura de aprobaciones, los informes y el intercambio de datos con otros sistemas. Este artículo explica qué abarca la adaptación, en qué ejemplos tiene sentido y cuándo se pasa de la raya; y relaciona el enfoque con la visión de YazSis ERP.

¿Qué abarca la adaptación de un ERP?

La adaptación no es un único trabajo, sino cinco ámbitos de distinta profundidad. Los dos primeros se resuelven casi siempre con ajustes; los siguientes pueden requerir desarrollo.

• Reglas de negocio: las condiciones propias de su empresa en pasos como el precio, el descuento, la salida de existencias y el envío.
• Estructura de aprobaciones: quién aprueba, con qué importe y condiciones, y en qué orden.
• Informes e indicadores: las pantallas que mira la dirección, las definiciones de KPI, los desgloses.
• Integraciones: el flujo de datos con otros sistemas, como la contabilidad, el almacén, el trabajo de campo o el comercio electrónico.
• Módulos adicionales: una pieza desarrollada aparte para un flujo de trabajo que el producto estándar no cubre en absoluto.

Ejemplos de adaptación de un ERP

Los cuatro ejemplos siguientes proceden de una empresa manufacturera mediana ficticia; se han elegido para mostrar qué ámbito se adapta y por qué.

• Estructura de aprobaciones: una cadena que cambia según el importe. Las solicitudes de poco importe se cierran en el responsable de área; las de importe elevado van además al director financiero. Si un flujo estándar ofrece un único paso de aprobación, esta diferencia se gestiona por correo y no aparece en el registro. La adaptación lleva la regla al interior del sistema.
• Informe: la pantalla única de la dirección. Cada mañana, el director general quiere ver en la misma página los pedidos abiertos, los envíos retrasados y los materiales cuyas existencias han bajado a un nivel crítico. Los informes estándar los dan por separado; la adaptación consiste en montar una única vista con su propia definición.
• Integración: los sistemas que rodean al ERP. El resultado del recuento que llega desde el terminal portátil del almacén, el movimiento en la planta de producción o la información del banco se transfieren al ERP mediante una interfaz en lugar de introducirse a mano. Qué campo fluye en qué sentido y con qué frecuencia se define en el alcance del proyecto.
• Módulo adicional: un flujo que el ERP no contempla. La empresa quiere seguir desde una sola pantalla en qué taller, en qué fecha y en qué cantidad espera los semielaborados enviados a talleres subcontratados. El producto estándar lleva el envío y el movimiento de existencias, pero no ofrece una vista del trabajo pendiente por taller. Aquí la adaptación no basta; hacen falta un pequeño módulo adicional y datos leídos del ERP.

¿Cuándo hace falta desarrollar un módulo adicional para el ERP?

Un módulo adicional entra en juego cuando hay un flujo que no se puede resolver con ajustes y que afecta a la competitividad o al orden de la empresa. Tres preguntas facilitan la decisión: ¿es este proceso un trabajo estándar que hace todo el mundo en su sector o tiene un aspecto que diferencia a su empresa? ¿Hoy, llevado a mano, produce pérdidas, retrasos o errores? ¿Se puede cubrir adaptando el flujo estándar del producto o se necesitan una pantalla y una regla totalmente aparte? Al decidir, piense no solo en la necesidad de hoy, sino también en a cuántas personas y a qué sistemas afectará este flujo en los próximos años; un módulo adicional que parece pequeño, si no se monta de forma compatible con la estructura de datos del ERP, puede convertirse más adelante en una isla de datos aparte.

Si a la primera pregunta responde “estándar”, lo más sano suele ser ajustarse al flujo propio del producto. Si la respuesta a las dos primeras es “diferente”, un módulo adicional es una inversión razonable. En el desarrollo de software a medida, este trabajo empieza extrayendo el objetivo, los usuarios, los datos y las reglas de negocio; a continuación se diseñan el flujo de uso y la estructura técnica, se desarrolla de forma modular y se prueba con escenarios reales.

¿Invertir en un ERP estándar o en un ERP a la medida de la empresa?

La pregunta suele plantearse como una disyuntiva, pero en realidad hay cuatro opciones. La tabla resume en qué situación tiene sentido cada una.

¿Qué dejar como estándar y qué adaptar?

La defensa más sólida de una adaptación es la respuesta a la pregunta “¿esto lo hace todo el mundo así?”. En un trabajo que todos hacen igual, personalizar suele crear una carga innecesaria; en el paso que le distingue de su competidor, en cambio, el flujo estándar puede ser una limitación.

El riesgo de la adaptación: convertir cada petición en código

Si la adaptación crece sin control, el ERP se convierte en un montón de reglas difícil de entender. Pasar a la nueva versión se complica, el conocimiento queda en unas pocas personas y cada pequeña petición se convierte en un proyecto. Antes de aprobar una petición de adaptación, hágase estas preguntas.

1. ¿Qué resultado del negocio mejora esta petición y es medible?
2. ¿Se puede llegar al mismo resultado con un ajuste estándar o cambiando un poco el proceso?
3. ¿Quién ha definido la regla, quién puede cambiarla y dónde está escrita?
4. ¿Cómo se trasladará la adaptación a las futuras versiones del producto?
5. ¿Dependen de este cambio los informes y otros sistemas?
6. ¿Utiliza este cambio algún equipo además de quien lo ha pedido?

Cubrir con Excel y correo electrónico el proceso que falta

Llevar con una hoja de Excel y el correo electrónico un paso que el ERP no cubre es, al principio, una solución provisional razonable: es rápida y no espera a ningún proyecto. El problema empieza cuando lo provisional se vuelve permanente. La aprobación se pierde en el correo, la tabla vive en el ordenador de una persona y la diferencia entre el registro del ERP y la tabla se cierra a mano al final del periodo. Si hace ese paso una vez al mes, la tabla basta; si lo hacen decenas de personas cada día, ese paso está en la lista de candidatos a la adaptación. Una medida práctica: si la tabla la rellenan unas pocas personas al mes, todavía sirve; pero si en la misma tabla escriben muchas personas, otra persona traslada los datos a mano al ERP y cada mes hay una reunión de “¿por qué no cuadra?”, esa tabla se ha convertido en un proceso en sí misma.

El enfoque de adaptación en YazSis ERP

YazSis ERP se propone reunir en el mismo flujo de datos los procesos de ventas, compras, existencias y almacén, producción, finanzas y gestión según el modelo de trabajo real de la empresa; su principio se resume en la frase “adapte el ERP a su empresa, y no su empresa al ERP”. El trabajo se basa en cuatro principios: conservar el sistema actual y completar los procesos que faltan sin desmontar el ERP que funciona, ampliar con un módulo a medida el flujo de trabajo que el producto estándar no cubre, establecer un flujo de información común mediante integraciones de API y de base de datos, y medir el cuello de botella y el resultado con informes de gestión.

Qué procesos incluirá el alcance se define en un análisis previo, según las necesidades de producto y de integración; no hay un paquete preparado ni una lista fija de adaptaciones.

Si quiere identificar conjuntamente en qué procesos se queda corto su ERP actual y qué paso merece una adaptación, puede empezar por la página de desarrollo de software a medida.