Integración ERP y Digitalización de Procesos

SAP, Dynamics, NetSuite, Odoo y muchos ERP regionales mediante conectores estándar; cualquier otro, vía API REST o intercambio de archivos.

La capa de integración mapea campos y lógica personalizados, porque la personalización es algo normal.

MSF complementa al ERP. Usted mantiene las finanzas y la parte comercial donde están, y gana una capa de fabricación de primer nivel.

De entrada, normalmente órdenes de fabricación, maestro de artículos, listas de materiales, hojas de ruta y existencias. De salida, confirmaciones de orden y de operación, cantidades producidas y rechazadas, consumo de material y resultados de calidad. La discusión nunca es sobre esa lista, sino sobre qué sistema es dueño de cada campo y qué ocurre cuando se edita en los dos. Acuerde la propiedad campo a campo antes de que nadie escriba un mapeo, porque esa decisión sale cara de revertir.

Sí, si las confirmaciones tienen que registrarse de vuelta. Todo lo que genera un movimiento de mercancías o cierra una operación es una escritura, y su equipo de ERP querrá hacerlo por interfaces liberadas, tipo BAPI, servicios OData o una tabla de staging, y no atacando la base de datos directamente. Una primera fase en solo lectura es razonable: bajar las órdenes, mostrarlas en planta y seguir notificando a mano hasta que los números cuadren.

Semanas cuando ya existen un responsable con nombre y apellidos del lado del ERP, un entorno de pruebas parecido a producción, interfaces acordadas y unos datos maestros razonablemente correctos; más cuando no. El trabajo de conector rara vez es lo que marca el plazo; lo que lo marca es esperar a las ventanas de cambio, a las aprobaciones de transporte y a que alguien conteste cuál de los cuatro códigos de artículo es el bueno. Si hoy no puede decir quién es el contacto del ERP, cuente en meses y no en semanas.

Con envíos programados de CSV o XML por SFTP, una tabla de staging del lado del ERP, o una vista de base de datos que construya y mantenga su proveedor de ERP o su propio equipo interno; leer usted mismo las tablas de la aplicación suele denegarse y puede romperse en una actualización. Lo que se pierde es la inmediatez, y el retraso es el intervalo que usted programe, habitualmente por turno o nocturno. La vuelta necesita un proceso de importación en el ERP con un responsable y una regla para los registros que rechace.

Van a descuadrar, y ninguna integración decide quién tiene razón. Las diferencias vienen de registros hechos en momentos distintos, de rechazos anotados en planta que aún no se han contabilizado y de movimientos hechos fuera de los dos sistemas. Lo que sí obtiene es una traza de eventos, de forma que una diferencia se puede seguir hasta un turno y una orden concretos, sin quedar como un descuadre global en el inventario. Designe un responsable de conciliación y una periodicidad antes del arranque.

Si el ERP no responde pero el servidor local y la red de planta siguen funcionando, las órdenes ya liberadas se mantienen en los terminales y los operarios siguen confirmando. Esas confirmaciones se escriben en la base de datos local, así que sobreviven a un reinicio y se envían en cuanto el ERP vuelve a contestar. El límite real son las órdenes que nunca llegaron a transferirse, que no se pueden arrancar. Pregunte si los registros reenviados pueden caer en un periodo que su departamento financiero ya haya cerrado.

No. El diseñador de flujos de proceso digitaliza formularios, aprobaciones y el reparto del trabajo entre personas, así que los procesos de desviación y de cambio de ingeniería en papel encajan bien ahí, pero no cambia cómo su ERP valora, planifica o contabiliza, y cualquier paso que tenga que actualizar un registro del ERP sigue necesitando una interfaz por detrás. La lógica que en realidad es cálculo, como las reglas de costes, va donde viven esos datos.