La promesa original del ERP y por qué no se cumple en la práctica
Cuando las empresas implementan un ERP —Epicor, SAP, Oracle, Microsoft Dynamics, Acumatica— la promesa implícita es que tendrán "un solo sistema para todo". El inventario, las compras, las ventas, la contabilidad, la producción y los recursos humanos en una única plataforma integrada. Durante los primeros años, esa promesa se cumple razonablemente bien para los procesos de alto volumen y baja variabilidad que el ERP fue diseñado para gestionar.
El problema aparece cuando la empresa crece y sus procesos se vuelven más complejos. Los equipos de ventas necesitan calcular comisiones con esquemas escalonados que el módulo de nómina del ERP no puede modelar. El área de compras quiere dar visibilidad a sus proveedores sin darles acceso al ERP. RRHH necesita que los colaboradores puedan comprobar viáticos desde el móvil. Ninguno de estos requerimientos está en el roadmap del ERP, porque el ERP no fue diseñado para resolverlos.
Los 6 procesos que casi ningún ERP resuelve nativamente
Después de trabajar con docenas de empresas medianas en México, estos son los procesos que aparecen una y otra vez como puntos de fricción que el ERP no resuelve:
- Portales de autoservicio para terceros (clientes, proveedores). El ERP está diseñado para usuarios internos. Dar acceso a externos implica licencias adicionales, riesgos de seguridad y una experiencia de usuario que no estaba pensada para no-expertos.
- Gestión de viáticos y gastos de campo. El flujo de anticipo, comprobación móvil con foto de ticket y políticas por rol no existe de forma nativa en casi ningún ERP sin customización.
- Cálculo de comisiones con esquemas complejos. Los módulos de nómina del ERP calculan salario base e impuestos bien. Las reglas de comisiones escalonadas con aceleradores y clawbacks casi siempre requieren customización o Excel.
- Conciliación bancaria automatizada. Algunos ERPs tienen módulos de conciliación básica, pero el matching automático por reglas de negocio configurables con integración bancaria en tiempo real no es estándar.
- Logística de última milla con evidencia digital. El ERP gestiona pedidos y facturación, pero el seguimiento GPS de la unidad, la firma digital del cliente y la foto de entrega requieren una aplicación móvil que el ERP no tiene.
- Gestión de mantenimiento preventivo con órdenes de trabajo móviles. Los módulos de mantenimiento de los ERPs generales están diseñados para planificación, no para la ejecución en campo con un técnico usando una tableta.
Por qué construir desarrollos a la medida sobre el ERP suele ser un error
La respuesta habitual cuando el ERP no resuelve un proceso es contratar al implementador del ERP para desarrollar una customización. El resultado típico: el desarrollo tarda el doble de lo estimado, cuesta el triple de lo presupuestado, y cuando el fabricante del ERP lanza una nueva versión, la customización no es compatible y hay que rediseñarla.
El problema estructural de las customizaciones sobre ERP es que están atadas al ciclo de actualizaciones del fabricante. Cada upgrade del ERP es un riesgo para cada customización. Las empresas que acumulan más de tres o cuatro customizaciones significativas terminan atrapadas en versiones antiguas del ERP porque el costo de migrar con todas sus customizaciones es prohibitivo. La deuda técnica no se acumula en años, se acumula en meses.
"Llevábamos cinco años sin poder actualizar el ERP porque teníamos siete customizaciones que no eran compatibles con las versiones nuevas. Finalmente decidimos sacar esos procesos del ERP y conectarlos por API. Ahora actualizamos el ERP sin miedo." — Director de TI, empresa manufacturera en Querétaro, 800 empleados
La arquitectura "ERP core + módulos satélite": qué es y por qué se está volviendo estándar
La arquitectura ERP core + módulos satélite parte de una premisa simple: el ERP hace lo que hace bien (contabilidad, inventario, compras formales, producción) y los procesos que el ERP no resuelve bien los maneja un módulo especializado que se conecta al ERP por API REST. El módulo satélite lee datos del ERP cuando los necesita y escribe de vuelta al ERP cuando genera un resultado que debe quedar en el sistema contable.
Esta arquitectura tiene tres ventajas sobre las customizaciones: primero, el módulo satélite puede actualizarse independientemente del ERP y viceversa, porque la integración es por API, no por código compartido. Segundo, el módulo satélite puede ser reemplazado por una mejor solución en el futuro sin tocar el ERP. Tercero, el tiempo de implementación es significativamente menor porque no hay que tocar el núcleo del ERP.
¿Qué procesos están resolviendo fuera de tu ERP hoy?
Conversemos sobre cuáles se pueden resolver con módulos conectados y cuáles necesitan un enfoque diferente.
Hablar con un especialista →Cómo decidir qué resolver en el ERP y qué resolver fuera
La decisión no es ideológica. Es práctica. Un proceso debe resolverse dentro del ERP cuando: el ERP ya lo resuelve bien y solo necesita configuración, cuando el proceso está tan íntimamente ligado al inventario o a la contabilidad que separarlo crearía inconsistencias difíciles de gestionar, o cuando el volumen de usuarios es pequeño y todos son usuarios internos del ERP.
Un proceso debe resolverse fuera del ERP (con un módulo satélite conectado por API) cuando: involucra usuarios externos (clientes, proveedores) que no van a usar el ERP, cuando requiere una experiencia móvil que el ERP no puede dar, cuando las reglas de negocio son suficientemente complejas o cambiantes como para que una customización en el ERP genere deuda técnica, o cuando el tiempo de implementación en el ERP es superior a las 6 semanas.
La prueba más simple: si para resolver el proceso tienes que contratar al implementador del ERP y el proyecto dura más de dos meses, probablemente hay un módulo satélite que lo resuelve en la mitad del tiempo y sin tocar tu ERP.