Para un fabricante que opera en varios países, la decisión sobre la arquitectura del ERP empieza por definir qué necesitan hacer las plantas de forma conjunta. La información financiera del grupo, las compras y las transferencias entre plantas requieren distintos tipos de coordinación. No exigen necesariamente que los flujos de trabajo locales sean idénticos.
Por tanto, la comparación útil no es simplemente ERP global frente a ERP local. Se trata de decidir cuánta responsabilidad operativa concentrar en un sistema común, cuánta dejar en manos de las plantas y dónde aplicar las reglas compartidas.
En un webinar de SoftEngine sobre estrategia de ERP, los ponentes sostienen que el encaje estratégico importa más que el origen del proveedor. Abordan las capacidades para realizar despliegues internacionales, el conocimiento regional y los modelos que conectan ERP operativos locales con un sistema internacional. Es un punto de partida útil: elegir el reparto de responsabilidades antes de utilizar la nacionalidad del proveedor como indicador de su idoneidad.
Separa el producto, la instancia y el proceso
Una decisión sobre la arquitectura de ERP en varios países debe responder a preguntas distintas:
- Elección del producto: ¿deben las plantas utilizar el mismo software ERP o productos diferentes?
- Diseño de las instancias: ¿deben compartir un entorno de aplicación o trabajar en entornos separados?
- Estandarización de procesos: ¿qué reglas de negocio, definiciones y flujos de trabajo deben ser comunes, independientemente de dónde se ejecuten?
Mantén estas preguntas separadas al debatir la arquitectura. «El mismo ERP» no debería sustituir a una respuesta para todas ellas. Un producto compartido con configuraciones locales mantenidas de forma independiente es una propuesta distinta de un producto compartido que se rige por una plantilla común. Una investigación histórica publicada en Communications of the ACM distingue expresamente entre una configuración estandarizada para las distintas unidades de negocio y varias configuraciones diferentes, con efectos organizativos potencialmente distintos.
Una plantilla global de ERP debe expresar las reglas que la organización pretende reutilizar: definiciones de datos compartidas, estructuras contables, responsabilidades sobre las transacciones y procesos que conectan las plantas. Decide por separado si esa plantilla se desplegará en un entorno compartido o se replicará en entornos independientes. De lo contrario, una decisión de despliegue puede convertirse, sin que nadie lo apruebe expresamente, en una política organizativa.
Separa también la arquitectura de la decisión de inversión. Conservar un ERP local no demuestra que sea adecuado para su propósito, y elegir procesos comunes no demuestra que sea necesario sustituir todos los sistemas. Resuelve esa cuestión mediante una evaluación para mejorar o sustituir el ERP, en lugar de utilizar la etiqueta de la arquitectura como justificación de la inversión.
Qué exige a la empresa un enfoque de ERP global común
Un enfoque común resulta más coherente cuando las plantas necesitan coordinarse estrechamente y pueden aceptar definiciones y facultades de decisión compartidas. Su atractivo reside en la posibilidad de acordar una regla de forma centralizada y reutilizarla, en lugar de traducir repetidamente entre interpretaciones locales. La obligación correspondiente es conseguir que esa regla compartida sea adecuada para las plantas que deban seguirla.
Empieza por los datos maestros. Decide qué identificadores de producto, unidades de medida, identidades de clientes y proveedores y clasificaciones financieras corresponden al grupo. Después, distínguelos de los atributos locales. Una identidad común para un material no implica que todas las plantas deban utilizar parámetros de planificación idénticos. Del mismo modo, permitir parámetros de planificación locales no debería convertirse en un permiso para crear identidades incompatibles para el mismo material.
Las transacciones entre empresas del grupo requieren una precisión similar. Para las transferencias entre entidades jurídicas, acuerda la relación entre los registros de envío y recepción, los eventos que determinan la expedición y la recepción, y quién resuelve las discrepancias. Un entorno de aplicación común no debe aceptarse como sustituto de esas decisiones. Pregunta cómo permite el diseño elegido dar visibilidad y control a la transacción acordada.
La carga organizativa se hace más evidente cuando se solicitan cambios. ¿Quién puede modificar un campo compartido? ¿Qué plantas deben aprobar un cambio de proceso? ¿Quién decide si un requisito local debe incorporarse a la plantilla? El control central solo es útil si incluye una vía viable para resolver las diferencias reales.
Aplica la misma lógica a las actualizaciones. En un entorno compartido, establece cómo participan las plantas en la aprobación de versiones y cómo influyen sus calendarios operativos en la programación. En entornos separados que utilizan una plantilla común, decide qué cambios deben avanzar de forma coordinada y cómo se hará el seguimiento de las desviaciones. La elección de arquitectura debe contemplar esta coordinación continua, no solo el despliegue inicial.
Un núcleo corporativo con ERP locales desplaza el límite de lo compartido
En un modelo de ERP de dos niveles para fabricación, los sistemas corporativos y los de las plantas tienen responsabilidades distintas. Infor describe este reparto como un modelo en el que las plantas se centran en los sistemas operativos del negocio, mientras que la sede central se ocupa de la gestión financiera y de otros sistemas necesarios para el conjunto de la organización. Ese reparto es un punto de partida para definir el alcance, no un diseño de integración completo.
El ámbito compartido puede ser relativamente limitado. La investigación de ACM describe una autonomía operativa local combinada con una consolidación financiera común, e incluye un ejemplo de distintos productos ERP operativos conectados a un sistema financiero común. También describe un modelo más amplio en el que la sede central coordina la cadena de suministro mediante el acceso a las necesidades de compra, los inventarios y los programas de producción locales. Son arquitecturas sustancialmente diferentes: la información financiera por sí sola no responde a las necesidades de información de la coordinación de la producción entre plantas.
Define el núcleo corporativo en consecuencia. Si su propósito es la consolidación, especifica cómo se corresponden las cuentas locales con la información del grupo, cómo se concilian los datos remitidos y cómo se aprueban los ajustes. Si también coordina el suministro, especifica qué información de inventario y planificación necesita, qué significa y en qué momento pasa a ser utilizable para tomar decisiones.
La integración no elimina la necesidad de estandarizar. Cambia el lugar en el que debe hacerse cumplir lo acordado. Para los datos maestros, designa quién tiene autoridad sobre cada campo compartido y define cómo se relacionan con él las extensiones locales. Para las transacciones entre empresas del grupo, acuerda los identificadores que conectan los registros entre sistemas y la responsabilidad de resolver los desajustes. Para la consolidación, conserva una relación trazable entre las cifras remitidas al grupo y los registros locales.
Asigna responsables permanentes a ese trabajo:
- Los responsables de datos aprueban las definiciones compartidas y las correspondencias entre datos.
- Los responsables de procesos resuelven las discrepancias entre las reglas corporativas y locales de las transacciones.
- Los responsables de aplicaciones e integración gestionan los cambios en las interfaces, los intercambios rechazados y las responsabilidades de recuperación.
- Los responsables financieros aprueban las conciliaciones y los ajustes de la información presentada.
La autonomía local para publicar versiones también debe tener un límite claro. Exige una revisión de impacto cuando un cambio afecte a un campo, una transacción o una salida de información compartidos. Permite una programación local cuando las dependencias lo hagan posible, pero incluye comprobaciones de compatibilidad en la aprobación de versiones tanto corporativas como locales. De lo contrario, la «autonomía local» deja sin definir la responsabilidad de proteger los procesos compartidos.
Distingue las diferencias reales de las preferencias heredadas
Una diferencia local merece examinarse por su contenido, no aceptarse o rechazarse automáticamente. En el debate de SoftEngine, los ponentes distinguen el conocimiento del mercado regional y las particularidades normativas de las consideraciones sobre el despliegue global, y sitúan de nuevo la decisión en las prioridades estratégicas de la empresa. Lleva ese criterio al terreno de las pruebas que sustentan el propio requisito.
Ante una diferencia normativa, identifica la obligación aplicable, los registros o resultados que modifica y el responsable local financiero o jurídico. Después, evalúa si la solución común puede cumplirla mediante una localización o configuración compatible con el producto. Una exigencia legal establece qué debe conseguirse; por sí sola, no demuestra la necesidad de un ERP separado.
Ejemplo ilustrativo: una planta que fabrica equipos diseñados bajo pedido y otra que produce componentes estándar de forma repetitiva pueden necesitar flujos de planificación distintos. Examina las diferencias reales en la definición de pedidos, la programación y el cálculo de costes antes de prescribir un proceso común. Aun así, podrían compartir identidades de materiales, definiciones de clientes y reglas de información del grupo. La decisión consiste en determinar dónde sigue siendo útil trabajar de forma común, no si las plantas son idénticas.
En cambio, «siempre hemos utilizado esta secuencia de aprobación» no basta para justificar una excepción permanente. Pregunta qué obligación de negocio o restricción operativa satisface esa secuencia. Si el proceso común cubre esa necesidad, conservar la secuencia antigua añade una diferencia sin un propósito claro. Una vez entendido el requisito, utiliza un proceso de aprobación de configuraciones y personalizaciones para decidir cómo implementarlo.
Distingue también la autonomía de la planta de los límites entre los sistemas de producción. Determinar si una actividad productiva corresponde al ERP o al software de ejecución es una cuestión distinta de decidir si la planta necesita su propio ERP. El reparto de responsabilidades entre ERP y MES debe apoyar la arquitectura elegida, sin utilizarse como sinónimo de independencia local.
Elige las responsabilidades compartidas antes que el mapa de sistemas
Opta por un enfoque global común cuando unas reglas operativas compartidas y una coordinación estrecha entre plantas justifiquen un control colectivo de los cambios. Opta por un núcleo corporativo con ERP locales cuando unas diferencias operativas relevantes justifiquen la responsabilidad local y la organización esté preparada para hacerse cargo de las correspondencias de datos, las interfaces y las conciliaciones que los conectan.
Ninguna de las opciones elimina la necesidad de gobierno. El enfoque común concentra las decisiones sobre procesos y versiones compartidos. El enfoque híbrido sitúa más responsabilidad en los límites entre sistemas. El mejor diseño es aquel cuyas responsabilidades continuas la empresa puede explicar, asignar y sostener.
Si estás definiendo ese reparto entre países y plantas, los servicios de ERP de Digiventi son un siguiente paso pertinente para abordar conjuntamente la configuración de procesos y la integración de sistemas.