Cuando una empresa mediana evalúa un ERP, uno de los argumentos de venta más frecuentes es "nuestro sistema es totalmente personalizable". Esa frase suena bien, pero esconde una pregunta que rara vez se hace con la profundidad necesaria: ¿personalizable significa configurable sin costo adicional, o significa que cada ajuste requiere un proyecto de desarrollo que la empresa pagará aparte?
La diferencia entre esas dos interpretaciones puede representar cientos de millones de pesos en el TCO (Total Cost of Ownership) a 3-5 años. Y es una diferencia que muchas empresas descubren después de firmar el contrato — no antes.
Esta guía explica los tres niveles reales de personalización en un ERP, cuándo conviene aplicar cada uno, cuáles son los riesgos de sobre-personalizar y cómo evaluar la flexibilidad real de un sistema antes de elegir.
Los tres niveles de personalización que hay que distinguir
La mayoría de los artículos sobre "personalización de ERP" hablan del concepto como si fuera una sola cosa. No lo es. Son tres niveles distintos con implicaciones de costo, mantenimiento y riesgo completamente diferentes.
| Nivel | Qué implica | Ejemplos concretos | Costo | Riesgo |
|---|---|---|---|---|
| 1. Configuración | Ajustar parámetros dentro de las opciones que el sistema ya ofrece, sin modificar código | Definir centros de costos, configurar reglas de aprobación por monto, establecer listas de precios por canal, parametrizar retenciones | Incluido en la implementación | Bajo — no afecta actualizaciones futuras |
| 2. Adaptación | Crear elementos nuevos dentro del marco del sistema usando herramientas nativas del ERP | Crear campos personalizados, agregar opciones a formularios, modificar reportes para el usuario final, importar/exportar datos con formatos específicos | Bajo a medio | Bajo — opera dentro del marco del sistema |
| 3. Desarrollo a medida | Escribir código nuevo para cubrir procesos que el sistema estándar no contempla | Un módulo de logística especial, integración con un sistema propietario del cliente, un flujo de aprobación con reglas no estándar | Alto | Medio-alto — puede complicar actualizaciones y requiere mantenimiento especializado |
La clave operativa: cada nivel adicional de personalización aumenta el costo, el tiempo de implementación y la complejidad de mantenimiento. Un ERP donde todo requiere desarrollo a medida es, en la práctica, un software hecho a la medida disfrazado de ERP — con los costos y riesgos que eso implica.
El modelo 90/10: lo que un ERP bien diseñado debería cubrir
Un ERP maduro, con décadas de evolución y una base de clientes diversa, debería cubrir con su configuración estándar el 90% de las necesidades de una empresa mediana. El 10% restante — los procesos verdaderamente únicos del negocio — es el espacio legítimo para desarrollos a medida.
Ese equilibrio no es arbitrario. Es el resultado de años de implementaciones donde el proveedor identifica qué necesidades son comunes a todas las empresas de cierto tamaño y sector (y las incorpora al producto estándar) y qué necesidades son genuinamente particulares de cada empresa (y las deja como espacio configurable o desarrollable).
El 90% estándar debería incluir: contabilidad NIIF, facturación electrónica DIAN, nómina con todas las variables laborales colombianas, inventarios multi-bodega, compras con flujo de aprobación, cartera por edades, reportes financieros estándar, conciliación bancaria.
El 10% a medida puede incluir: un flujo de despacho específico del sector, una integración con el sistema de un cliente o proveedor particular, un reporte regulatorio que solo aplica a empresas de un nicho, un proceso de aprobación con reglas muy específicas de la empresa.
Cuando el "10%" se convierte en el "40%", hay dos posibilidades: el ERP es demasiado rígido para el perfil de la empresa (y fue una mala elección), o la empresa está intentando replicar sus procesos manuales en el sistema en lugar de aprovechar las mejores prácticas que el ERP propone. Ambas son señales de que algo falló en la evaluación.
Los 4 beneficios reales de un ERP configurable
1. La empresa no cambia su operación para adaptarse al software
Cuando un ERP es suficientemente configurable, los procesos del negocio se reflejan en el sistema — no al revés. Las reglas de aprobación, las listas de precios, los centros de costos, los flujos de facturación y las políticas de descuento se parametrizan según cómo opera realmente la empresa, sin que nadie tenga que cambiar su forma de trabajar para encajar en la lógica del software.
2. La implementación es más rápida y menos costosa
Un ERP donde el 90% se resuelve con configuración y el 10% con desarrollo se implementa en meses, no en años. Los desarrollos a medida del 10% se ejecutan en paralelo con la configuración del 90% estándar, sin bloquear el arranque del sistema.
3. Las actualizaciones no rompen lo que ya funciona
Cuando la personalización se hizo por configuración o por adaptación (dentro del marco del sistema), las actualizaciones del proveedor — nuevas funcionalidades, cambios normativos, mejoras de rendimiento — se aplican sin afectar lo configurado. Cuando la personalización se hizo con código a medida, cada actualización es un riesgo de que el desarrollo rompa o deje de funcionar, lo que obliga a pruebas adicionales y potencial reescritura.
4. El sistema evoluciona con la empresa sin depender de un desarrollador
Una empresa mediana que crece, abre una nueva sede o incorpora un canal de ventas necesita que el ERP se adapte rápidamente. Si esa adaptación se resuelve con configuración (crear un nuevo centro de costos, agregar una bodega, configurar una nueva lista de precios), el equipo interno lo puede hacer. Si cada cambio requiere desarrollo a medida, la empresa depende del proveedor o de un desarrollador externo para cada ajuste — lo que genera cuellos de botella y costos recurrentes.
Los riesgos de sobre-personalizar que nadie menciona
La personalización tiene un punto de rendimiento decreciente que es importante reconocer. Más allá de cierto nivel, cada customización adicional genera más problemas de los que resuelve.
Fragilidad ante actualizaciones
Cada línea de código a medida es una línea que puede romperse con la próxima actualización del ERP. Las empresas que sobre-personalizan terminan "congeladas" en una versión vieja del sistema porque actualizar implica reescribir todos los desarrollos.
Dependencia del desarrollador
Si el código a medida lo escribió una persona (interna o externa), la empresa depende de esa persona para mantenerlo, corregirlo y documentarlo. Si esa persona se va, el conocimiento se va con ella.
Costo de mantenimiento creciente
Los desarrollos a medida no solo cuestan al implementarse — cuestan cada vez que hay que mantenerlos, cada vez que hay que probarlos contra una actualización, cada vez que un usuario encuentra un error. Ese costo acumulado es lo que convierte una implementación "económica" en una cara a 5 años.
Complejidad para el equipo interno
Un sistema con demasiadas customizaciones se vuelve difícil de entender para usuarios nuevos. El onboarding de un empleado que llega al área contable toma semanas en lugar de días porque el sistema tiene reglas que no son estándar y no están documentadas.
Cómo evaluar la flexibilidad real de un ERP antes de elegir
Estas son las preguntas que el comité de evaluación debe hacer a cada proveedor para medir la flexibilidad real del sistema — no la que dice el brochure.
¿Qué porcentaje de la implementación promedio es configuración estándar vs. desarrollo a medida?
Un proveedor honesto debería poder responder con números reales de sus últimas implementaciones. Si la respuesta es "depende" sin datos, es señal de que no tiene estandarizado el proceso.
¿Quién puede hacer cambios de configuración: solo el proveedor o también el equipo del cliente?
Si cada ajuste de parámetro requiere un ticket al proveedor, la flexibilidad es teórica — no operativa.
¿Qué herramientas nativas tiene el sistema para adaptación sin código?
Crear campos, crear opciones, modificar reportes, configurar flujos de aprobación, importar/exportar datos — esas son capacidades de adaptación que reducen la necesidad de desarrollo a medida.
¿Las actualizaciones del sistema respetan las configuraciones y adaptaciones del cliente?
Esta es la prueba de fuego. Si cada actualización rompe los ajustes, el sistema no es configurable — es hackeable. No es lo mismo.
¿Los desarrollos a medida se documentan y quién los mantiene después del go-live?
Si la respuesta es "el equipo de implementación" y ese equipo se va al terminar el proyecto, la empresa queda con código sin documentar que nadie puede mantener.
El enfoque de Ofima: 90% estándar, 10% a la medida
Ofima ERP opera con el modelo 90/10 verificado en su base de clientes de más de 40 años: el sistema estándar cubre el 90% de las necesidades de la empresa mediana colombiana — contabilidad NIIF, facturación electrónica DIAN, nómina con toda la normativa laboral vigente (incluyendo Ley 2466), inventarios, compras, cartera, manufactura y BI con DataBot.
El 10% restante se resuelve con herramientas nativas de adaptación (crear campos, crear opciones, modificar reportes, capturas web, enlaces con otros sistemas, importación/exportación de datos) y, cuando es necesario, con desarrollos a la medida que quedan documentados y mantenidos por el equipo de Ofima.
Las actualizaciones normativas (DIAN, reforma laboral, cambios de UVT, nuevos formatos) se aplican centralmente sin afectar las configuraciones ni las adaptaciones del cliente. Y el Asesor Experto Certificado acompaña cada ajuste para asegurar que la configuración se mantenga alineada con la operación real de la empresa.
Si quieres evaluar qué porcentaje de tu operación cubre el estándar y qué necesitaría desarrollo a medida, ese diagnóstico es parte del proceso de evaluación. Conversemos.
Preguntas Frecuentes
¿Qué diferencia hay entre configurar y personalizar un ERP?
Configurar es ajustar los parámetros que el sistema ya ofrece (centros de costos, reglas de aprobación, listas de precios) sin tocar código. Personalizar puede significar adaptar dentro del marco del sistema (crear campos, modificar reportes) o desarrollar funcionalidades nuevas con código. La configuración es estándar y no genera riesgos. El desarrollo a medida es más costoso y requiere mantenimiento.
¿Cuánto del ERP debería cubrirse con el estándar vs. desarrollo a medida?
En un ERP maduro para empresa mediana, el estándar debería cubrir el 90% de las necesidades y el desarrollo a medida solo el 10%. Si el porcentaje de desarrollo a medida supera el 20-25%, es señal de que el ERP no es el adecuado para el perfil de la empresa o de que se está replicando procesos manuales en lugar de aprovechar las mejores prácticas del sistema.
¿Los desarrollos a medida se pierden cuando el ERP se actualiza?
Depende de cómo se hicieron. Si se realizaron dentro del marco de extensibilidad del sistema (herramientas nativas de adaptación), las actualizaciones los respetan. Si se hicieron modificando el código fuente del ERP, cada actualización puede romperlos. Por eso es fundamental que los desarrollos se documenten y se prueben contra cada actualización mayor.
¿Puedo cambiar la configuración yo mismo o dependo del proveedor?
En Ofima ERP, muchos ajustes de configuración los puede hacer el equipo interno capacitado: agregar centros de costos, modificar listas de precios, ajustar reglas de aprobación. Para cambios más complejos (nuevos flujos, integraciones, desarrollos), el Asesor Experto Certificado acompaña el proceso.
¿Qué pasa si mis procesos son muy diferentes al estándar del ERP?
Primero hay que distinguir si la diferencia es real o es simplemente la forma en que la empresa siempre lo ha hecho. Muchas veces, el proceso "único" de la empresa es en realidad un proceso estándar ejecutado de forma no óptima. El diagnóstico de implementación identifica qué procesos son genuinamente únicos (y merecen desarrollo a medida) y cuáles pueden beneficiarse de las mejores prácticas que el ERP propone.
¿La sobre-personalización es un riesgo real?
Sí, y es uno de los principales motivos de fracaso en implementaciones de ERP. Una empresa que customiza todo termina con un sistema frágil, difícil de actualizar, dependiente de desarrolladores específicos y caro de mantener. La personalización debe ser la excepción justificada, no la regla.