Cuando un organismo público necesita un nuevo sistema de gestión, se enfrenta invariablemente a la misma disyuntiva: ¿contratamos un ERP estándar del mercado y lo configuramos para nuestras necesidades, o encargamos desarrollo a medida? Ambas opciones tienen defensores convencidos y casos de éxito. También tienen casos de fracaso costoso. La clave está en saber cuál es la adecuada para cada situación. ## Qué es un ERP genérico y qué es software a medida **ERP genérico** (Enterprise Resource Planning): sistema estándar de gestión diseñado para funcionar en múltiples sectores y organismos con configuración y parametrización. Ejemplos: SAP, Oracle, Microsoft Dynamics, Odoo. En el sector público español, también soluciones específicas pero estándar como SIGEP, PLYCA para contratación, o las plataformas de la Junta de Castilla y León o de la AGE. **Software a medida**: sistema diseñado y desarrollado específicamente para los procesos de un organismo o sector concreto. No existe antes del proyecto: se construye según los requisitos del cliente. Entre ambos extremos hay una zona gris importante: los **ERPs configurables** o los **productos sectoriales**, que son estándar en su base pero con capacidad de personalización profunda. Muchas soluciones para sector público entran en esta categoría. ## Cuándo tiene sentido un ERP estándar Un ERP estándar es la opción adecuada cuando: **Los procesos son estándar y no requieren diferenciación.** Contabilidad pública, nóminas de funcionarios, gestión de expedientes administrativos básicos —estos procesos están normalizados por ley y son iguales en todos los organismos del mismo nivel. No hay ventaja en desarrollarlos a medida. **El organismo no tiene capacidad técnica para mantener software propio.** Un pequeño ayuntamiento de 20 empleados no tiene personal técnico para gestionar actualizaciones, parches de seguridad y adaptaciones legales de un sistema a medida. Un ERP con soporte del fabricante externaliza ese coste de mantenimiento. **El presupuesto es limitado y el tiempo de implantación corto.** Un ERP existente puede estar en producción en semanas. Un desarrollo a medida de la misma funcionalidad puede tomar entre 3 y 12 meses. **La funcionalidad cubierta por el ERP es suficiente en un 80-90%.** Si el sistema estándar cubre la mayor parte de las necesidades y solo requiere pequeñas adaptaciones, la eficiencia del ERP supera al desarrollo desde cero. ## Cuándo tiene sentido el software a medida El desarrollo a medida es la opción adecuada cuando: **Los procesos son únicos y no están contemplados en ningún ERP del mercado.** El sistema de control de trazabilidad de una cadena de distribución de agua provincial, el módulo de gestión de licitaciones de una diputación con flujos de aprobación específicos por su organigrama, o la plataforma de gestión de mediaciones laborales de SIMA —ninguno de estos sistemas existe como ERP estándar porque no hay mercado suficiente para que ningún fabricante lo desarrolle. **La integración con sistemas existentes es crítica y compleja.** Cuando el nuevo sistema debe integrarse con varios sistemas heredados (legacy) de diferentes tecnologías, y esa integración define el valor del proyecto, un ERP estándar obliga a adaptaciones costosas que frecuentemente superan el coste del desarrollo a medida. **El organismo necesita controlar completamente la propiedad intelectual del código.** En proyectos críticos financiados con fondos públicos, tener el código fuente bajo control del organismo permite auditarlo, modificarlo con otros proveedores en el futuro y garantizar la continuidad del servicio independientemente del proveedor original. **Los requisitos de seguridad son elevados y el ERP estándar no los cubre por defecto.** Para sistemas de categoría media o alta en el ENS, la seguridad debe estar diseñada desde el inicio (security by design). Adaptar un ERP genérico para cumplir los requisitos ENS de alta categoría suele ser más costoso y menos robusto que diseñar la seguridad desde cero. ## La trampa del ERP "casi perfecto": el coste real de la parametrización El argumento más frecuente a favor del ERP estándar es el económico: "ya está hecho, solo hay que configurarlo". Este argumento falla sistemáticamente cuando la parametrización es extensa. Un estudio de Gartner sobre implantaciones de ERP en sector público en Europa mostró que **el coste total de propiedad de un ERP con parametrización extensa a lo largo de 5 años es entre 1,8 y 2,4 veces mayor que el coste del contrato inicial**. Los costes ocultos incluyen: - Licencias anuales que se incrementan con el número de módulos y usuarios - Consultoría especializada del fabricante para cada parametrización (a tarifas premium) - Actualizaciones de versión que deshacen las parametrizaciones previas - Dependencia técnica del fabricante que dificulta el cambio de proveedor El software a medida tiene sus propios costes de mantenimiento, pero son más predecibles y no incluyen licencias incrementales. ## ENS: cómo afecta a la decisión ERP vs medida La certificación ENS añade una dimensión importante a esta decisión que frecuentemente se ignora. **ERPs estándar y ENS**: Los grandes fabricantes (SAP, Microsoft) tienen certificaciones ENS para sus plataformas cloud. Sin embargo, la certificación cubre la plataforma base, no las personalizaciones. Cuando un organismo añade módulos custom o integraciones, esas piezas adicionales quedan fuera del alcance de la certificación y deben certificarse por separado. Esto puede convertir la certificación ENS de un ERP parametrizado en un proceso largo y costoso. **Software a medida y ENS**: Un proveedor de software a medida certificado en ENS diseña el sistema desde el inicio con los controles de seguridad requeridos. La certificación ENS cubre el producto completo porque no hay una base estándar sobre la que se han añadido capas de personalización. El alcance de la certificación es más claro y el mantenimiento de la certificación más sencillo. Para organismos con sistemas de categoría media o alta que necesitan una certificación ENS limpia y mantenible, el software a medida con un proveedor certificado suele ser la opción más segura a largo plazo. ## Checklist para decidir: 8 preguntas clave Antes de decidir entre ERP y software a medida, responde honestamente: 1. ¿Más del 80% de los procesos que necesitas están cubiertos por el ERP estándar sin adaptaciones? 2. ¿Tu organismo tiene capacidad técnica para gestionar un sistema a medida (actualizaciones, incidencias)? 3. ¿El plazo de implantación es un factor crítico (menos de 6 meses)? 4. ¿Los procesos que necesitas son estándar del sector o únicos de tu organismo? 5. ¿Necesitas integración con muchos sistemas externos existentes? 6. ¿Quieres ser propietario del código fuente del sistema? 7. ¿La categoría ENS del sistema es media o alta? 8. ¿Prevés cambios normativos frecuentes que afectarán al sistema? Si las respuestas 4, 5, 6, 7 u 8 son mayoritariamente "sí", el software a medida es probablemente la opción más eficiente a largo plazo. ## Preguntas frecuentes sobre software a medida vs ERP en sector público **¿El software a medida puede licitarse como tal o requiere una figura contractual específica?** Puede licitarse como contrato de servicios (desarrollo) o como contrato mixto (desarrollo + mantenimiento). La LCSP permite contratos a medida sin restricciones; lo importante es que el pliego defina correctamente el objeto del contrato y los criterios de aceptación. Para proyectos complejos, es habitual usar el procedimiento negociado con publicidad o el diálogo competitivo. **¿Qué garantías tiene el organismo si el proveedor de software a medida desaparece?** El pliego debe incluir la entrega del código fuente, la documentación técnica completa y el depósito del código en un servicio de custodia de terceros (como AENOR o un notario). Con estas garantías, el organismo puede contratar a otro proveedor para mantener el sistema. Esta cláusula es especialmente importante para software crítico. **¿Es más difícil justificar un proyecto de software a medida ante la Intervención?** No necesariamente. La Intervención valora que el objeto del contrato sea claro, que el precio sea justificado por el mercado y que los entregables sean verificables. Un software a medida bien documentado y con criterios de aceptación objetivos es perfectamente justificable. La dificultad aparece cuando el pliego es ambiguo o los entregables no están definidos.