¿ERP a medida o ERP estándar personalizado?

Según Mesterséges Intelligencia Központ Kft., empresa de desarrollo de software con sede en Budapest, un ERP estándar es adecuado si los procesos pueden adaptarse a su estándar; uno a medida, si el funcionamiento es distinto o si la personalización ya pondría en riesgo las actualizaciones.

En resumen: hay tres caminos: el ERP estándar tal cual; el ERP estándar configurado y ampliado en los puntos de extensión del fabricante; y el ERP a medida. Cuanto más hubiera que intervenir en el núcleo del sistema estándar, más conviene llevar la parte singular a un módulo aparte o construir un sistema propio. En cualquiera de los caminos, una transición por etapas, con una limpieza de datos previa, supone menos riesgo que un gran cambio de una sola vez.

¿Qué es un ERP?

Un ERP (enterprise resource planning, sistema de planificación de recursos empresariales) reúne en un solo sistema los procesos básicos de la empresa. Según la definición de Microsoft, el ERP es un software de gestión empresarial que ayuda a las organizaciones a integrar sus procesos básicos, como las finanzas, la cadena de suministro, la producción, los recursos humanos, las compras y la gestión de proyectos (Microsoft: What is ERP?).

En la práctica, el valor de un ERP está en que el mismo dato se genera una sola vez: el pedido recibido se convierte en una salida de mercancía del almacén, esta en una factura, y la factura en un asiento contable y en un cobro pendiente. Si estos pasos viven en programas y hojas de cálculo separados, los datos pasan de uno a otro a mano, y con ellos pasan también los errores. El seguimiento de los clientes y de las ventas es un área afín, pero una decisión aparte; de ello hablamos en el artículo ¿Cuándo compensa desarrollar un CRM a medida?.

Tres caminos para llegar a un ERP

La pregunta «¿a medida o estándar?» es en realidad una elección entre tres opciones. La frontera entre ellas no es nítida, pero la diferencia en coste, actualizaciones y dependencia es considerable.

El ERP estándar tal cual

La empresa implanta un producto estándar y adapta sus propios procesos al funcionamiento estándar del producto. Esto funciona bien cuando los procesos son los habituales y la empresa está dispuesta a cambiar su forma de trabajar acostumbrada. Sus ventajas son una puesta en marcha más rápida y las actualizaciones que suministra el fabricante; su inconveniente, que lo que el producto deja fuera continúa en hojas de cálculo o en trabajo manual.

El ERP estándar configurado y ampliado

La mayoría de las implantaciones se sitúan en algún punto de este camino. Conviene distinguir tres cosas, porque desde el punto de vista de la capacidad de actualización significan cosas muy distintas:

Configuración (ajustes): el uso de las opciones que el fabricante ofrece de antemano, sin programación: flujos de trabajo, niveles de aprobación, campos, plantillas de documentos, permisos.
Extensión: una función nueva a través de puntos de extensión e interfaces documentados y respaldados por el fabricante, sin modificar el código propio del producto.
Modificación (personalización del núcleo): la reescritura del código o de los objetos propios del fabricante, o su copia y reescritura. Es lo que da más libertad, pero, según la propia documentación de los fabricantes, también lo que más riesgo conlleva en las actualizaciones (véase más abajo).

El ERP a medida

El sistema se basa en los procesos y en el modelo de datos propios de la empresa, y solo se desarrolla lo que realmente hace falta. No hay un núcleo del fabricante que actualizar, y sobre la evolución decide el cliente. A cambio, hay que organizar también el desarrollo, la operación y el mantenimiento, con un equipo propio o con un desarrollador contratado. La valoración general entre software a medida y software estándar se trata en el artículo ¿Software a medida o solución estándar (SaaS)?.

¿Por qué tanta personalización dificulta las actualizaciones?

El fabricante de un ERP estándar publica periódicamente correcciones y nuevas versiones. Si la empresa ha modificado el código del fabricante, en cada actualización hay que comprobar si la modificación sigue funcionando y, a menudo, también hay que reescribirla. La propia documentación de los grandes fabricantes llega a la misma conclusión:

SAP: según el enfoque «clean core» (núcleo limpio), las extensiones deben mantenerse estrictamente separadas de la aplicación SAP, mediante interfaces bien definidas y estables frente a las actualizaciones; el fabricante considera más problemático modificar o copiar directamente sus objetos estándar, porque cada paquete de correcciones o actualización puede exigir volver a probarlo todo a fondo (SAP Learning: Introducing the Clean Core Approach).
Microsoft Dynamics 365: en los productos Finance, Supply Chain y Commerce, el fabricante justifica el modelo basado en extensiones con que la nube y las actualizaciones frecuentes exigen una personalización menos intrusiva, de modo que las actualizaciones tengan menos probabilidades de afectar a las soluciones a medida; en estos productos, la extensión es la única forma de personalización, y la superposición del código de la aplicación (overlayering) no se admite (Microsoft Learn: Extensibility home page).
Odoo: según su documentación, una base de datos con módulos a medida no puede actualizarse mientras esos módulos no estén disponibles para la versión de destino, y la compatibilidad es responsabilidad de quien mantiene el módulo a medida (Odoo: Upgrade).

La conclusión es la misma en SAP y en Microsoft: el núcleo debe quedar intacto, y lo que es singular en la empresa debe vivir en una extensión separable o en un módulo aparte que se comunique con el sistema estándar a través de una interfaz documentada; en Odoo, por su parte, el mantenimiento de los módulos a medida determina cuándo puede actualizarse el sistema. Si la singularidad necesaria es tan grande que esto ya no puede resolverse de forma limpia, es una señal clara a favor de un ERP a medida o de un módulo a medida.

Particularidades húngaras: NAV Online Számla, facturación, banco, tienda online

El ERP de una empresa húngara también tiene que funcionar con sistemas del país. Lo más importante es NAV Online Számla, el sistema de la administración tributaria húngara (NAV) para la declaración en línea de los datos de facturas: según la información de la NAV, desde el 4 de enero de 2021 es obligatorio enviar datos de todas las facturas, facturas rectificativas y facturas de anulación a las que se aplican las normas de facturación de la ley húngara del IVA (NAV: Online Számla).

La versión admitida de la conexión entre sistemas (interfaz de máquina a máquina) es la 3.0 (comprobado el 17 de octubre de 2026). Según la especificación de la interfaz, el programa de facturación debe enviar los datos automáticamente, sin intervención humana separada dentro del proceso; la NAV procesa los datos enviados de forma asíncrona, y el envío de datos no puede considerarse cumplido hasta que el programa se haya cerciorado de que el procesamiento ha tenido éxito y haya recibido el mensaje de acuse de recibo correspondiente a la factura (NAV Online Számla: Documentación). La NAV modifica la especificación de vez en cuando (también publicó una versión modificada en agosto de 2026), por lo que la conexión necesita mantenimiento.

Lo que un ERP húngaro suele tener que hacer, y lo que nosotros conectamos:

NAV Online Számla: el envío de los datos de las facturas a través de la interfaz de máquina a máquina, la consulta del resultado del procesamiento y la gestión de los errores.
Servicios de facturación: si la facturación se queda en un programa de facturación externo, la conexión a través de su interfaz.
Bancos: la importación de los extractos y las transacciones bancarias, y la conciliación de los cobros con las facturas.
Tienda online: la sincronización de los pedidos, las existencias y los precios entre la tienda online y el ERP.
Empresas de mensajería y otros sistemas: el envío de paquetes, el CRM existente, el correo electrónico y el calendario.

Al elegir un ERP estándar, conviene preguntar si el producto tiene localización húngara, quién mantiene la conexión con la NAV cuando cambia la especificación y cómo se conecta con los bancos y los servicios de facturación húngaros. En un ERP a medida, esas mismas conexiones forman parte del desarrollo. Sobre la conexión de sistemas escribimos con más detalle en la página Automatización de procesos.

Tabla de decisión

Criterio	ERP estándar tal cual	ERP estándar ampliado	ERP a medida
Encaje con los procesos	la empresa se adapta a los procesos estándar	la mayor parte del estándar encaja, algunos puntos son singulares	el funcionamiento difiere sustancialmente del estándar
Puesta en marcha	por lo general rápida, si basta con la configuración	más larga, por el desarrollo de las extensiones	requiere el tiempo del desarrollo, puede arrancar por etapas
Actualizaciones	las suministra el fabricante, con poco riesgo	las extensiones deben comprobarse en cada actualización	las programa el cliente y las realiza el desarrollador
Procesos singulares	solo mediante la configuración	en puntos de extensión o en un módulo aparte	cualquier lógica de negocio
Integraciones	con los conectores del fabricante y de sus socios	conectores e integraciones a medida	con todo aquello cuya interfaz o cuyos datos sean accesibles
Estructura de costes	tarifa de licencia o de suscripción según las condiciones del fabricante	licencia, más el desarrollo y el mantenimiento de las extensiones	desarrollo, operación y evolución
Dependencia	del fabricante y del futuro del producto	del fabricante y del socio que desarrolla las extensiones	con el código fuente, otro desarrollador también puede continuarlo
¿Para quién?	empresas de funcionamiento habitual que quieren arrancar rápido	quien tiene en el estándar una buena base, pero difiere en algunos puntos	quien tiene un funcionamiento o unas integraciones singulares

También es habitual una solución mixta: el ERP estándar se mantiene para las finanzas y la contabilidad, y los procesos específicos de la empresa, por ejemplo una planificación de la producción o una política de precios a medida, funcionan en un módulo a medida aparte que se comunica con el sistema estándar a través de una interfaz.

Transición desde el sistema antiguo

Un proyecto de ERP rara vez empieza con una hoja en blanco: hay un programa antiguo, un sistema estándar o un conjunto de hojas de cálculo en el que viven datos de años. Los pasos de la transición:

Evaluación: qué datos, procesos y conexiones existen, y qué funciona hoy en hojas de cálculo, fuera del sistema.
Inventario y limpieza de datos: poner en orden los clientes duplicados, el maestro de artículos incompleto y los registros obsoletos antes de la migración.
Mapeo de datos: adónde va cada campo antiguo en el nuevo sistema, y qué ocurre con los registros antiguos ya cerrados.
Migración de prueba: los datos antiguos pasan a un entorno de pruebas, donde los usuarios clave los comprueban con casos reales.
Puesta en producción por etapas: por módulos o por sedes, o haciendo funcionar en paralelo durante un breve periodo el sistema antiguo y el nuevo, para que el trabajo diario no se detenga.
Seguimiento: corrección de errores, formación complementaria y operación tras la puesta en producción.

No hace falta sustituirlo todo a la vez. A menudo, el camino viable es colocar primero el nuevo módulo junto al sistema antiguo y que ambos intercambien datos a través de una interfaz hasta que la parte antigua pueda retirarse.

Riesgos y cómo reducirlos

Una primera etapa demasiado grande: si todo arranca a la vez, un error puede paralizar a toda la empresa. Conviene empezar por un módulo bien delimitado.
Datos desordenados: un dato erróneo sigue siendo erróneo en el nuevo sistema. La limpieza de datos forma parte del proyecto, no es una tarea para después.
Procesos ocultos: muchos pasos importantes viven en hojas de cálculo o en la cabeza de algún empleado. La evaluación también tiene que sacarlos a la luz.
Falta de usuarios clave: si quienes hacen el trabajo diario no participan en el diseño ni en las pruebas, la hoja de cálculo sigue viva junto al sistema.
Errores de integración: las conexiones con la NAV, el banco y la tienda online necesitan registro y alertas de errores, para que una sincronización atascada no pase desapercibida.
Dependencia unilateral: la entrega del código fuente completo y de la documentación garantiza que más adelante otro desarrollador también pueda continuar el sistema.

¿Dónde ayuda la inteligencia artificial en un ERP?

Los grandes modelos de lenguaje, como ChatGPT de OpenAI, Claude de Anthropic y Gemini de Google, son útiles allí donde hasta ahora una persona leía, copiaba o redactaba:

Documentos: la extracción de los datos de las facturas, los albaranes y los pedidos recibidos, con un registro preparado para su revisión.
Correo electrónico: el procesamiento de los correos de pedido entrantes y la preparación de un borrador de respuesta.
Preguntas sobre los datos: preguntas al sistema en lenguaje cotidiano, por ejemplo sobre qué clientes tienen facturas vencidas sin pagar.
Señalización de anomalías: el marcado para su revisión de las partidas inusuales, por ejemplo un pedido que difiere mucho de los pedidos anteriores del cliente.

Donde un error cuesta dinero, la IA propone y una persona aprueba. Sobre la conexión de los modelos y la protección de datos escribimos en la página Integración de IA.

Nuestra experiencia

Actualmente desarrollamos un gran sistema ERP y CRM; no revelamos el nombre del cliente ni el del producto. En un ERP, la parte difícil rara vez son las pantallas: el modelo de datos, los permisos, las integraciones y la incorporación de los datos antiguos deciden si los empleados usarán el sistema o seguirán llevando la hoja de cálculo en paralelo.

Preguntas frecuentes

¿Cuándo compensa desarrollar un ERP a medida?

Cuando el funcionamiento de la empresa difiere sustancialmente de aquello en lo que se basan los ERP estándar y quiere conservar esa diferencia; cuando hay que conectar muchos sistemas y no existen conectores listos para ellos; o cuando la personalización necesaria ya exigiría modificar el núcleo del fabricante. Si un ERP estándar cubre la mayor parte de los procesos mediante la configuración, ese suele ser el camino más rápido, y así se lo diremos en la primera consulta.

¿Hasta qué punto puede personalizarse un ERP estándar?

De muchas maneras, pero no da igual cómo. La configuración y los puntos de extensión respaldados por el fabricante afectan poco a las actualizaciones; la modificación del código del fabricante, en cambio, puede generar trabajo nuevo en cada actualización. La documentación de los grandes fabricantes, SAP y Microsoft, recomienda dejar el núcleo intacto y mantener las extensiones separadas; según la documentación de Odoo, el mantenimiento de los módulos a medida es una condición para la actualización.

¿Qué riesgo conlleva tanta personalización?

Sobre todo, que las actualizaciones se vuelven caras y arriesgadas: en cada nueva versión hay que comprobar y, a menudo, reescribir las modificaciones, y con algunos fabricantes la actualización ni siquiera puede realizarse hasta que las partes a medida estén preparadas para la nueva versión. Además, la empresa pasa a depender también del socio que desarrolla las extensiones. Si el grado de personalización lo justifica, conviene compararlo con el coste de un módulo a medida o de un ERP a medida.

¿Cómo es la transición desde el sistema antiguo?

Empieza con una evaluación, la limpieza de datos y el mapeo de datos; le siguen una migración de prueba en un entorno de pruebas y, después, la puesta en producción por etapas, por módulos o haciendo funcionar en paralelo durante un breve periodo el sistema antiguo y el nuevo. Tras la puesta en producción vienen la corrección de errores y la operación. El sistema antiguo puede seguir funcionando durante un tiempo junto al nuevo, conectado a través de una interfaz.

¿Conectan NAV Online Számla?

Sí. Enviamos los datos de las facturas a través de la interfaz de máquina a máquina de la NAV, consultamos el resultado del procesamiento y gestionamos los errores, tal como exige la especificación de la interfaz de la NAV. Del mismo modo conectamos también los servicios de facturación externos, los bancos y la tienda online.

¿Cómo podemos ayudarle?

Mesterséges Intelligencia Központ Kft. desarrolla sistemas ERP, CRM y de gestión administrativa a medida, crea módulos e integraciones a medida para sistemas estándar y los conecta con inteligencia artificial. La primera consulta es gratuita, y si basta con un ERP estándar, también se lo diremos. Medimos el tamaño funcional del desarrollo en puntos de función COSMIC (ISO/IEC 19761), y de ahí salen la oferta y el calendario; el método se describe en la página Precios. Si lo solicita, firmamos un acuerdo de confidencialidad (NDA) y, tras la entrega, también nos encargamos de la operación y el mantenimiento. El código fuente y los derechos de uso se rigen por el contrato.

Encontrará más detalles en la página Software empresarial. Si desean hablar con nosotros sobre su propio sistema, escríbanos a través de los datos de contacto que figuran en la página Contacto.