¿Software a la medida o seguir estirando el ERP?
Respuesta corta: mantén el ERP para lo que ya resuelve bien (contabilidad, inventario, compras, procesos estándar) y reserva el software a la medida para los procesos que de verdad diferencian a tu empresa. Si un módulo del ERP ya cubre la necesidad, configurarlo casi siempre cuesta menos que construir. Pero cuando el proceso es la razón por la que tus clientes te eligen, forzarlo dentro de un sistema genérico termina limitando el negocio en vez de ordenarlo.
Esta guía recorre las señales de que el ERP llegó a su límite, lo que no justifica un desarrollo, cinco criterios para decidir y la ruta híbrida que suele funcionar: el ERP como núcleo y sistemas satélite a la medida (incluida la IA) conectados a él.
¿Cómo saber si el ERP llegó a su límite?
El ERP llegó a su límite cuando la operación real ya no vive dentro del sistema, sino alrededor de él. Es una señal de arquitectura, no de capacitación: por más que el equipo se entrene o se ajuste un parámetro, el software sigue sin encajar con cómo funciona el negocio. Cinco señales concretas:
- Hojas de cálculo satélite. Cada área tiene su propio Excel paralelo para lo que el ERP no contempla.
- Personalizaciones que bloquean actualizaciones. Cada nueva versión del ERP se vuelve un proyecto de riesgo en vez de un trámite.
- El proceso se dobla al sistema, no al revés. El equipo cambia su forma de trabajar para acomodarse al software, no porque sea mejor así.
- Recaptura manual entre sistemas. La misma información se teclea dos o tres veces porque nada se conecta.
- Reportes que tardan días. La dirección decide con información vieja porque un reporte confiable exige trabajo manual.
Si reconoces varias, el problema no se resuelve con otro curso ni con otro módulo.
¿Qué no justifica un desarrollo a la medida?
No toda fricción con el ERP es un caso de negocio para construir. Antes de desarrollar conviene descartar tres causas mucho más comunes y mucho más baratas de resolver:
- Un módulo estándar ya lo resuelve. Con frecuencia el ERP tiene la función; nadie la configuró o el equipo no la conoce.
- El problema es disciplina de datos o de proceso. Catálogos desordenados, procesos que nadie documentó, excepciones que se volvieron regla. Ningún desarrollo arregla eso: lo hereda.
- Presión de moda tecnológica. Construir algo propio porque otras empresas lo hacen no es un criterio de negocio.
Construir a la medida sobre una base desordenada multiplica el desorden, ahora con mantenimiento propio. Por eso en ozeida la primera llamada sirve también para decir «esto no necesita desarrollo».
¿Con qué criterios se decide?
Cuando ya descartaste esas causas y el problema sigue siendo real, estos cinco criterios permiten decidir con evidencia en vez de con preferencia:
| Criterio | Pregunta que lo resuelve | Inclina hacia |
|---|---|---|
| Diferenciación | ¿Cualquier competidor resuelve este proceso igual con herramientas estándar? | Si sí, ERP. Si el proceso es tu ventaja, a la medida. |
| Frecuencia de cambio | ¿El proceso cambia cada pocos meses? | Procesos que cambian seguido necesitan software que tu equipo pueda ajustar rápido. |
| Integraciones | ¿Cuántos sistemas debe tocar el proceso (CRM, WhatsApp, portal de clientes, planta)? | Cuantos más, más pesa una pieza diseñada para conectarse. |
| Costo total a 3 y 5 años | Licencias, mantenimiento y personas para operar cada opción, no solo el costo inicial. | El que salga menor, con números por escrito. |
| Propiedad y dependencia | ¿El código y los datos son tuyos? ¿Puedes cambiar de proveedor? | Un desarrollo bien hecho es un activo propio; una personalización profunda del ERP puede ser una dependencia disfrazada. |
Ninguno de los cinco decide solo. El que más se olvida es el cuarto: el costo de sostener, no el de construir.
¿Cuál es la ruta híbrida: ERP como núcleo, satélites a la medida?
En la práctica la decisión casi nunca es binaria. La ruta que suele funcionar es mantener finanzas, inventario y compras dentro del ERP, porque ahí reinventar no aporta ventaja, y construir alrededor con integraciones solo donde el proceso sí es diferenciador.
Un sistema satélite típico lee y escribe en el ERP por su API (por ejemplo, el Service Layer de SAP Business One o la API externa de Odoo) y resuelve lo que el ERP no hace bien: un portal de clientes, un cotizador con reglas propias, una captura en planta, un tablero que cruza datos de varios sistemas.
La inteligencia artificial entra por el mismo lugar. Un asistente o agente de IA es otro satélite: consulta el ERP con permisos definidos, responde preguntas en lenguaje natural («¿qué pedidos de este cliente están atrasados?») o prepara acciones que una persona aprueba. No reemplaza al ERP; lo hace consultable. Así es como integramos IA en implementación de IA: conectada a lo que ya existe, con un objetivo medible y un tope de gasto de inferencia definido desde el diseño.
¿Cómo empezar sin apostar la operación?
No hace falta apostar toda la operación para probar la ruta híbrida:
- Diagnóstico con evidencia. Mapear los procesos reales, no los documentados, e identificar dónde el ERP se dobla de verdad. Eso permite priorizar el primer punto de fricción en lugar de adivinar dónde invertir.
- Una métrica y una línea base por escrito. Tiempo de un proceso, errores de recaptura, horas de reporteo. Si no se puede medir, no se promete.
- Piloto acotado sobre el proceso de mayor fricción. Alcance cerrado, fecha de corte, reversible si la evidencia no acompaña. Si el piloto cumple la métrica, pasa a producción con el mismo equipo; si no, se dice y se para.
La pregunta de fondo no es «ERP o software a la medida», sino dónde traza tu empresa la línea entre lo que es commodity y lo que es ventaja competitiva. Esa línea no se copia de otra empresa del sector: se traza con datos de tu operación y se revisa cada vez que el negocio cambia de tamaño o de estrategia.