Plataformas y flujos
ERP a medida: arquitectura modular y desarrollo
Sistemas de gestión construidos por módulos sobre un núcleo común de datos, para cubrir la parte de la operación que un ERP estándar no recoge sin forzarlo.
Beneficio operativo
La parte de la gestión que os distingue funciona sobre un núcleo de datos propio, y lo estándar sigue en productos conectados sin duplicar información.
Foto: Carl Lender from Sunrise, USA · CC BY 2.0
Contexto · ERP a medida
Un ERP a medida no tiene por qué ser un sistema gigante escrito desde cero. Lo sensato suele ser un núcleo pequeño y estable (terceros, artículos, documentos comerciales, permisos y auditoría) y módulos que se añaden por fases: la parte operativa que os distingue primero y la que es igual en todas las empresas, como la contabilidad, conectada a un producto existente si conviene. Esa arquitectura modular permite empezar por un área, migrar datos por bloques y cambiar un módulo sin rehacer los demás. También obliga a tomar en serio lo que un ERP comercial ya trae resuelto: facturación conforme a la normativa, trazabilidad de cambios, roles y cierres. Diseñamos el núcleo, los módulos y la migración, y explicamos qué conviene no construir.
Arquitectura
Cómo circula la información
Esquema conceptual: cada proyecto concreta las piezas con los sistemas reales de la empresa.
01 · Entrada
- Datos maestros depurados
- Documentos comerciales y operativos
02 · Validación
- Reglas de negocio por módulo
- Requisitos del sistema de facturación
03 · Procesamiento
- Núcleo común de datos
- Módulos operativos propios
04 · Control humano
- Validación por responsable de módulo
- Cierres y aprobaciones
05 · Trazas
- Auditoría de cambios por usuario
- Registros de facturación encadenados
06 · Salida
- Documentos y facturas
- Exportaciones a contabilidad y otros sistemas
Escenarios operativos
ERP a medida en la práctica
Ejemplos de lo que se podría diseñar. No describen proyectos realizados.
01
Núcleo y primer módulo operativo
- Entrada
- Hojas de cálculo con clientes, artículos y presupuestos técnicos, y un programa de contabilidad que funciona bien.
- Procesamiento
- Se construye el núcleo de terceros, artículos y documentos con su auditoría, y un módulo de presupuestos y pedidos que exporta a la contabilidad existente los documentos cerrados.
- Salida
- Un único registro de clientes y pedidos, contabilidad sin cambios y una base sobre la que añadir los siguientes módulos.
02
Facturación con requisitos técnicos
- Entrada
- Pedidos servidos que deben facturarse desde el propio sistema, con la normativa española de sistemas de facturación como referencia.
- Procesamiento
- El módulo de facturación genera registros encadenados e inalterables, corrige mediante registros nuevos y no sobrescribiendo, incluye el código QR en la factura y guarda el registro de eventos.
- Salida
- Facturas y registros con la trazabilidad exigida, listos para la revisión del asesor fiscal y para el envío a la AEAT si se opta por esa modalidad.
03
Migración por fases desde un ERP antiguo
- Entrada
- ERP heredado con datos maestros duplicados, documentos históricos y procesos que nadie se atreve a apagar.
- Procesamiento
- Se migran primero los maestros depurados, se ejecutan ambos sistemas en paralelo en un área y se comparan resultados antes de apagar esa parte del antiguo.
- Salida
- Área migrada con conciliación documentada, plan de vuelta atrás probado y el siguiente bloque listo para empezar.
04
Varias empresas en un mismo sistema
- Entrada
- Un grupo con varias sociedades que comparten clientes y artículos pero facturan y contabilizan por separado.
- Procesamiento
- El núcleo comparte los maestros que deben ser comunes y separa por sociedad documentos, series, permisos y exportaciones contables.
- Salida
- Cada sociedad ve y factura lo suyo, el grupo consulta datos consolidados y los permisos impiden cruces no autorizados.
Alcance
Qué resuelve ERP a medida y qué no
Qué puede resolver
- Modelar procesos operativos propios (presupuestos técnicos, fabricación por encargo, servicios recurrentes, alquileres) que un ERP estándar obliga a forzar.
- Separar el sistema en módulos con un núcleo común de datos maestros, de modo que cada área evolucione sin romper las demás.
- Aplicar roles y permisos por módulo, empresa y acción, con registro de quién cambia qué y cuándo.
- Migrar por fases desde hojas de cálculo o un ERP antiguo, conviviendo con él mientras dure la transición.
- Conectar con contabilidad, banca, facturación electrónica y comercio electrónico existentes en lugar de reconstruirlos.
Qué no resuelve
- No es la mejor opción para procesos que son iguales en casi todas las empresas, como la contabilidad general o las nóminas; ahí suele ser más razonable integrar un producto.
- No elimina las obligaciones normativas de un sistema de facturación: si el módulo factura, debe cumplir los requisitos técnicos que le apliquen y eso tiene un coste de diseño y mantenimiento.
- No se termina nunca del todo: un ERP propio necesita un equipo o un proveedor que lo mantenga, y eso debe estar previsto desde el principio.
Integración
Cómo se integra ERP a medida con lo que ya existe
Un ERP modular vive rodeado de otros sistemas y conviene asumirlo desde el diseño. Contabilidad, nóminas, banca y facturación electrónica pueden seguir en productos especializados, conectados por API o ficheros con conciliación. Los módulos propios publican eventos (pedido confirmado, albarán servido, factura emitida) que consumen el almacén, el transporte o el portal de clientes, y cada intercambio queda registrado para reintentar sin duplicar.
- Asientos o documentos hacia el programa de contabilidad
- Facturas y registros de facturación según la modalidad elegida
- Pedidos y existencias con comercio electrónico y portales
- Almacén, transporte o producción mediante eventos
- Identidad corporativa para el acceso con roles
Modalidades de despliegue que suelen plantearse
Se elige en cada proyecto tras evaluar requisitos y sistemas existentes.
Controles desde el diseño
Datos, validaciones y permisos
Antes de desarrollar
- Mapa de procesos con lo que es propio de la empresa y lo que es estándar, para decidir qué se construye y qué se integra.
- Inventario de datos maestros y de su calidad actual antes de planificar la migración.
- Responsable de negocio por módulo que valide reglas, permisos y criterios de aceptación.
- Revisión del asesor fiscal sobre los requisitos del sistema de facturación que aplican a la empresa.
- Plan de mantenimiento y de evolución con equipo o proveedor asignado y propiedad del código definida.
Riesgos, límites y mantenimiento
- El alcance tiende a crecer: si no se fija qué módulo va primero y qué queda fuera, el proyecto se convierte en una reescritura interminable.
- Los requisitos de los sistemas de facturación tienen calendario propio y cambian: el texto consolidado del RD 1007/2023 fija el 1 de enero de 2027 para sociedades y el 1 de julio de 2027 para el resto, pero el Ministerio de Hacienda anunció el 5 de octubre de 2026 su intención de aplazar las obligaciones pendientes hasta octubre de 2028, a falta de la norma que lo apruebe. Conviene diseñar el módulo con los requisitos técnicos actuales y revisar el calendario antes de cada fase.
- Una migración sin ejecución en paralelo ni conciliación deja diferencias que aparecen en el primer cierre.
- Depender de una sola persona que conoce el sistema es un riesgo serio; documentación, pruebas y propiedad del código deben quedar resueltas.
Antes de desarrollar
Alternativas a desarrollar ERP a medida
| Opción | Cuándo encaja | Límites |
|---|---|---|
| ERP comercial estándar parametrizado | Procesos parecidos a los de la mayoría de empresas del sector y disposición a adaptar la forma de trabajar. | Los procesos propios se fuerzan con campos libres o hojas auxiliares, y las personalizaciones encarecen cada actualización. |
| ERP comercial ampliado con extensiones en su propia plataforma | La mayor parte encaja y faltan pocas piezas bien delimitadas. | Dependencia del lenguaje y del ciclo de versiones del fabricante, y coste de licencias que crece con usuarios y módulos. |
| ERP vertical en la nube para el sector | Existe un producto pensado para vuestra actividad y su modelo de datos coincide con el vuestro. | Cobertura parcial de lo particular, menos control sobre la evolución y condiciones de exportación de datos que conviene revisar. |
| Productos especializados por área conectados entre sí | Cada área tiene un buen producto de mercado y el problema es que no comparten datos. | Integraciones que mantener, maestros que tienden a duplicarse y ningún sitio único donde ver el ciclo completo. |
Sectores, servicios y lecturas relacionadas
Última revisión:
Sectores donde se aplicaría
Preguntas frecuentes
¿En qué se diferencia esta página de la guía sobre ERP a medida frente a comercial?
La guía ayuda a decidir si os conviene un ERP propio o un producto. Esta página parte de que una parte del sistema se va a construir y explica cómo: núcleo, módulos, permisos, facturación, migración e integración con lo que se queda.
¿Un ERP a medida tiene que cumplir VERI*FACTU?
Si el sistema emite facturas, entra en el ámbito del Real Decreto 1007/2023 sobre sistemas informáticos de facturación, con requisitos de integridad, trazabilidad, inalterabilidad, registro de eventos y código QR. La modalidad VERI*FACTU, que envía los registros a la AEAT, es una de las opciones. Qué aplica en cada caso debe confirmarlo vuestro asesor fiscal.
¿Se puede empezar por un solo módulo?
Sí, y suele ser lo más prudente. Se construye el núcleo mínimo y el módulo que más valor aporta, conectado al resto de sistemas actuales, y se decide el siguiente paso con el primero ya en uso.
Siguiente paso
Cuéntanos qué parte de tu gestión no encaja en un ERP estándar
Cuéntanos qué datos y sistemas intervienen en tu proceso. Estudiaremos qué puede automatizarse, cómo se integraría y qué convendría validar antes de desarrollar. Ver todas las capacidades.
Sin compromiso de aceptación: estudiamos cada caso antes de proponer nada. Cómo tratamos la información que compartes.