ERP a medida frente a ERP comercial: cómo decidir

La tabla no da una respuesta automática; sirve para clasificar cada área de la empresa antes de hablar con proveedores. Lo normal es que unas áreas caigan en una columna y otras en la contraria.

Al evaluar un producto comercial conviene distinguir tres niveles. La parametrización usa las opciones previstas por el fabricante: series de documentos, flujos de aprobación, campos adicionales. Las extensiones añaden lógica mediante los mecanismos oficiales del producto. Las modificaciones del núcleo cambian el comportamiento interno, y son las que más complican las actualizaciones.

• Parametrización: bajo riesgo, sobrevive a las actualizaciones, la puede revisar el propio fabricante.
• Extensiones oficiales: riesgo moderado; dependen de que el fabricante mantenga la compatibilidad de sus interfaces de extensión.
• Modificaciones profundas: alto riesgo; cada versión nueva obliga a revisar y probar lo modificado.

Un indicador útil durante la selección: si la lista de adaptaciones necesarias crece hasta parecerse a un desarrollo nuevo, probablemente estáis forzando un producto que no encaja. En el sentido contrario, si en un desarrollo a medida empezáis a reconstruir la contabilidad general o el cálculo de impuestos, estáis rehaciendo algo que el mercado ya resuelve.

Comparar solo el precio de las licencias con el presupuesto de desarrollo lleva a conclusiones equivocadas. El coste total de propiedad suma todo lo que se pagará durante la vida útil del sistema, y conviene estimarlo para un horizonte de varios años con las mismas partidas en ambas opciones.

Ningún ERP vive solo: se conecta con la tienda online, el MES, la herramienta de nóminas, los bancos, el CRM o los portales de clientes. Con un producto comercial, la integración depende de las interfaces que ofrezca el fabricante, de sus condiciones de licencia para accesos externos y de su política de versiones. Con un desarrollo propio, las interfaces se diseñan a medida, pero también hay que documentarlas, versionarlas y mantenerlas.

• Pide la documentación de las interfaces de programación antes de decidir y comprueba que cubre las entidades que necesitáis: artículos, clientes, pedidos, existencias, asientos.
• Pregunta si el acceso por interfaz tiene coste adicional o límites de llamadas.
• Comprueba cómo se notifican los cambios: si el sistema puede avisar de un evento o hay que consultarlo periódicamente.
• Define qué sistema es el maestro de cada dato para evitar dos versiones de la verdad.

Ambas opciones crean dependencia, aunque de tipo distinto. Con un ERP comercial dependéis de la hoja de ruta del fabricante: puede cambiar precios, retirar una versión o modificar el modelo de licencias. Con un desarrollo a medida dependéis de quien conoce el código, y el riesgo es que ese conocimiento esté concentrado en pocas personas o en un único proveedor.

• Propiedad del código y de la documentación técnica, por contrato y de forma explícita.
• Acceso a los datos en formatos abiertos y procedimiento de exportación completa.
• Uso de tecnologías extendidas, con las que otro equipo pueda trabajar.
• Entorno de pruebas reproducible y documentación de despliegue.
• En productos comerciales: condiciones de salida, conservación de datos al terminar la suscripción y plazos de aviso ante cambios de versión.

Una distribuidora de material eléctrico con compras, almacén y venta convencionales, y un catálogo amplio pero sin cálculos especiales, encaja bien en un producto comercial. Su esfuerzo debería ir a parametrizar bien, limpiar los datos maestros y conectar la tienda online.

Un taller que fabrica estructuras bajo pedido, con presupuestos que dependen de geometrías, materiales, tratamientos y cargas de trabajo por sección, puede necesitar un módulo propio de presupuestación y planificación. Lo razonable sería mantener contabilidad y facturación en un producto comercial y construir el módulo específico con una integración clara hacia él.

1. Clasifica cada área en estándar o diferencial. Lo estándar, preferiblemente en producto; lo diferencial, evalúalo a medida.
2. Cuenta las adaptaciones necesarias en el producto candidato. Si afectan al núcleo o no paran de crecer, revisa el encaje.
3. Calcula el coste total con las mismas partidas y el mismo horizonte en ambas opciones, incluidas horas internas y actualizaciones.
4. Verifica las interfaces disponibles y sus condiciones antes de firmar, no durante la implantación.
5. Asegura por contrato la propiedad del código, la documentación y la exportación de datos, sea cual sea la opción.
6. Pregunta quién mantendrá el sistema dentro de cinco años y con qué conocimiento.

Si después de este análisis la parte diferencial es pequeña, un producto comercial bien implantado suele ser la opción más prudente. Si es grande y estable, un desarrollo propio integrado con lo administrativo puede ofrecer más control. En ambos casos, conviene validar la decisión con un análisis del proceso real antes de comprometer presupuesto.