La integración de OEE con Epicor tiene éxito cuando se cumplen tres condiciones: el patrón de integración coincide con la versión de Epicor (Kinetic vs ERP 10 vs versiones anteriores), el flujo de datos es impulsado por eventos y no por sondeo, y el ciclo de vida de la orden de trabajo es la columna vertebral de la integración (no el programa de producción ni la lista de materiales). El modo de fallo más común es tratar a Epicor como una fuente de datos pasiva y a la plataforma OEE como la consumidora activa; las plataformas que tienen éxito tratan la orden de trabajo como un objeto compartido de propiedad conjunta. Esta guía recorre los puntos finales compatibles, tres patrones de flujo de datos operativos, los errores comunes que vemos en despliegues en campo y un plan de implementación de 6 semanas ejecutable con su equipo de TI existente más el consultor de integración del proveedor de OEE.
Esta guía forma parte de una serie que cubre el diagnóstico de la meseta de OEE, cómo convertir el mantenimiento en un centro de beneficios, y reseñas de competidores de TrakSYS, FORCAM FORCE, y AVEVA.
Convierta el tiempo de inactividad en un dato accionable para su equipo.
Reservar una demoCuatro sesiones de trabajo: (1) el administrador de Epicor guía al consultor del proveedor de OEE a través de las superficies de integración activas y sus limitaciones; (2) el patrocinador de operaciones de planta confirma el ciclo de vida de las órdenes de trabajo y el modelo de datos de operaciones; (3) Seguridad de TI aprueba el enfoque de autenticación y las rutas de red; (4) el equipo conjunto selecciona uno de los tres patrones de flujo de datos según la versión de Epicor y las restricciones de TI. Entregable al final de la semana: un documento de arquitectura de 2 páginas firmado por el administrador de Epicor, el responsable del proveedor de OEE y Seguridad de TI.
Levantar un código de empresa de Epicor no productivo o un entorno de pruebas. Configurar la cuenta de servicio con permisos de lectura sobre las tablas dentro del alcance.
Confirmar que el proveedor de OEE puede alcanzar los endpoints REST de Epicor desde el host de integración. Ejecutar una prueba "Evento de creación de trabajo → reconocimiento por OEE" de ida y vuelta con datos simulados.
Al final de la semana 2, la canalización de integración está conectada aunque todavía no fluyan datos reales de producción.
Para el Patrón 1: el administrador de Epicor escribe las Functions o Method Directives que se disparan en las transiciones de estado del trabajo. Para el Patrón 2: el proveedor de OEE escribe el código de sondeo con limitación de tasa y lógica de interruptor de circuito.
Para el Patrón 3: el proveedor de OEE crea la exportación diaria en CSV con formato compatible con DMT. La semana 3 es la mayor parte del esfuerzo de ingeniería por parte del proveedor independientemente del patrón.
Elegir una única línea de producción, idealmente la que tenga el flujo de órdenes de trabajo más limpio. Habilitar la integración solo para el centro de trabajo de esa línea.
Operar en vivo durante 1 semana junto al método de medición de OEE existente (Excel o lo que estuviera en uso). Comparar resultados diariamente. Al final de la semana 4, la integración estará produciendo datos de OEE atribuidos a órdenes de trabajo de Epicor en una línea que coinciden con los resultados esperados dentro de la tolerancia.
Ampliar el alcance de la integración de una línea a todas las líneas de producción incluidas en el alcance. La mayoría de los problemas en esta etapa no son de lógica de integración, son de higiene de datos (órdenes de trabajo sin rutas de operación, centros de trabajo no mapeados de forma coherente entre plantas, operarios que no han iniciado sesión en Epicor). Dedicar la mayor parte de la semana 5 a la higiene de datos, no al código.
La lógica de integración que funcionó en la línea 1 funcionará para el resto, siempre que los datos estén limpios.
Cambiar del método de medición antiguo a la plataforma integrada de OEE. Configurar la monitorización de la integración: alertar sobre eventos rotos, eventos descartados, enlaces ambiguos y fallos de autenticación.
Entregar la integración al equipo de TI interno para su mantenimiento continuo. Documentar el runbook para escenarios operativos comunes (ventanas de mantenimiento de Epicor, indisponibilidad del SaaS del proveedor de OEE, cambios de red). Aprobar la aceptación de la integración tanto por el administrador de Epicor como por el patrocinador de operaciones de planta.
Las semanas 7-12 son el período normal de medición de OEE durante el cual emerge el valor de la integración. Para la semana 12, la planta debería disponer de 4-6 semanas de datos de OEE atribuidos a órdenes de trabajo que el planificador de producción usa para programar, el responsable de mantenimiento usa para planificar ventanas de mantenimiento preventivo, y el director de planta usa para informar al equipo corporativo.
Este es el valor que la integración fue diseñada para aportar, y escala de forma lineal con la limpieza de la canalización de integración establecida en las semanas 1-6.
Tres modos de fallo. Primero, las plantas que intentan definir el alcance de la integración sin presupuestar un recurso por parte de Epicor producen documentos de arquitectura de la semana 1 que son aspiracionales en lugar de ejecutables.
Segundo, las plantas que intentan el Patrón 1 sin experiencia con Functions (Kinetic en concreto) acaban volviendo al Patrón 2 en la semana 3, lo que cuesta 2 semanas de retrabajo. Tercero, las plantas que omiten el trabajo de higiene de datos en la semana 5 descubren que la integración "funciona en la línea 1 pero falla en la línea 4", un problema de datos, no de código, pero caro de descubrir en el momento equivocado.
Respuesta rápida: Integrar el software OEE con Epicor Kinetic requiere tres puntos de conexión: (1) extracción de la orden de producción desde Epicor hacia la plataforma OEE, (2) envío de paradas, desperdicio y conteo de piezas buenas de vuelta al reporte de mano de obra y materiales de la orden de trabajo en Epicor, (3) sincronización del diccionario de códigos de motivo para que los diagramas de Pareto en la herramienta OEE coincidan con los informes de variaciones de Epicor. El conector nativo de Fabrico para Epicor cubre los tres con una sincronización cada 30 segundos; el middleware basado en Zapier introduce retrasos de varios minutos que comprometen los flujos de trabajo en tiempo real de los supervisores.
Análisis relacionados: Integración OEE + Infor · Proceso de selección de software OEE · Cerrando el bucle OEE-CMMS · Lista de verificación de costos ocultos del software OEE.
Las dos líneas de producto de Epicor relevantes para producción tienen superficies de integración significativamente diferentes. Epicor Kinetic (introducido en la renovación de 2021, dominante en nuevas implementaciones) expone una interfaz REST moderna además de Epicor Functions para flujos de trabajo basados en eventos.
Epicor ERP 10 (la línea heredada, aún en servicio en miles de plantas) expone Business Objects mediante la API de estilo SOAP más antigua, además de exportaciones BAQ e importaciones de estilo DMT. Cada línea requiere un enfoque de integración distinto; asumir que "soporte de Epicor" significa lo mismo para ambas es el error de definición de alcance más común.
Para Kinetic: el endpoint JobEntry REST (creación/actualización de orden de trabajo), el endpoint LaborDtl (registro de tiempo del operario), el endpoint PartTran (reportes de producción), y el framework Epicor Function para controladores de eventos personalizados. Para ERP 10: JobEntry.JobEntryBO, LaborEntry.LaborEntryBO y PartTran.PartTranBO como Business Objects accesibles vía SOAP.
Para ambas: un feed de solo lectura desde JobOper para las operaciones actuales de la orden de producción.
El objeto más útil en cualquiera de las versiones de Epicor es el registro Job Head + Job Operations. Es a esto a lo que la plataforma OEE adjunta las mediciones OEE.
Cuando la plataforma OEE mide una parada no planificada de 15 minutos en la Línea 3, la plataforma atribuye esa parada al JobOper activo que se estaba ejecutando en la Línea 3 en ese momento. Sin esta atribución, los datos de OEE son solo números; con ella, los datos de OEE impulsan los análisis de órdenes de trabajo que ya le importan al planificador de producción.
Intentar integrar a nivel de pedido de cliente o pedido de venta. El pedido de venta es demasiado abstracto para OEE; OEE vive a nivel de orden de trabajo y operación. Los intentos de conectar a un nivel superior producen análisis confusos en los que nadie confía.
Intentar replicar la lista de materiales (BOM) en la plataforma OEE. Algunos consultores de integración sugieren replicar la lista de materiales de Epicor en el lado OEE para tener "contexto completo". Esto es un sobrealcance.
La plataforma OEE necesita la BOM a nivel de línea de producto (que puede obtener bajo demanda), no como un almacén de datos replicado.
Intentar escribir de vuelta el tiempo de mano de obra a Epicor desde la plataforma OEE. Esto suena atractivo (registrar automáticamente el tiempo del operario a partir de los datos de funcionamiento de la máquina en OEE) y es un campo minado regulatorio en plantas sujetas a requisitos de reporte laboral.
Mantenga el reporte de mano de obra en Epicor; permita que OEE reporte el tiempo de máquina por separado.
Las llamadas a la API REST de Epicor requieren autenticación mediante clave de API; Kinetic también soporta OAuth 2.0 con el IdP de Epicor. La plataforma OEE debería ejecutarse bajo una cuenta de servicio dedicada con acceso de lectura a las tablas Job, Operations y Part, y acceso de escritura solo a las tablas específicas a las que el diseño de integración escribe (normalmente ninguna, en una arquitectura limpia). Las plantas que entregan credenciales de nivel administrador de Epicor a la plataforma OEE están creando una superficie de ataque y un dolor de cabeza regulatorio; resista la tentación de la conveniencia.
Antes de dimensionar el proyecto de integración, responda por escrito cuatro preguntas: (1) ¿qué versión de Epicor (Kinetic, ERP 10 o anterior) está en producción? (2) ¿cuántos códigos de compañía/sitios de Epicor necesitan integración? (3) ¿la plataforma OEE es una instancia SaaS (que requiere que Epicor sea accesible desde internet a través de un gateway API) o está local (on-premise)? (4) ¿qué patrón de integración (Functions basadas en eventos, sondeo REST como alternativa, DMT basado en archivos) es aceptable para el administrador de Epicor? Estas cuatro respuestas determinan si la integración es un proyecto de 6 semanas o de 14 semanas.
El flujo de eventos impulsado por la orden de trabajo es el patrón más sólido para la integración de OEE con Epicor. El patrón: Epicor emite un evento cuando una orden de trabajo se inicia, se pausa o se completa; la plataforma OEE recibe el evento y vincula los datos de producción entrantes (estado de la máquina, unidades producidas, micro-paradas) con la operación activa.
Cuando la orden de trabajo se cierra, la plataforma OEE envía de vuelta un registro resumen final con: total de unidades producidas, desglose de OEE por componente (disponibilidad, rendimiento, calidad) y las categorías de pérdida dominantes durante esa operación.
En Kinetic, esto se implementa mediante Funciones de Epicor que se disparan en las transiciones de estado del trabajo. En ERP 10, requiere Directivas de método personalizadas en JobEntry.Update y JobEntry.MasterUpdate.
Ambos son patrones de Epicor bien conocidos; cualquier administrador de Epicor con experiencia puede configurarlo en 2-3 días.
Para plantas que no pueden habilitar Funciones de Epicor o Directivas de método (a menudo debido a restricciones de TI corporativo), la alternativa es una extracción basada en el programa de producción. La plataforma OEE lee los registros JobOper activos cada 5 minutos vía REST API, identifica qué operación está ejecutándose en qué centro de trabajo, y vincula las mediciones de OEE en consecuencia.
El patrón funciona pero produce una resolución de 5 minutos en lugar de tiempo real, y genera carga en la base de datos de Epicor.
Mitigue la carga limitando la extracción a operaciones con estado "In Process" o "Setup", no a todas las operaciones. La mayoría de las plantas tienen entre 10 y 30 operaciones activas en cualquier momento; extraer las 5.000 órdenes de trabajo cada 5 minutos es una señal de estrés en la base de datos que el DBA de Epicor marcará.
Para plantas que no pueden o no quieren habilitar integración del lado de Epicor en absoluto, la plataforma OEE puede funcionar como un sistema de medición puramente del lado de máquina con reconciliación periódica basada en archivos. La plataforma OEE lee datos PLC y CV, calcula OEE por máquina y exporta un CSV diario que se importa a Epicor mediante DMT.
El contexto de la orden de trabajo se establece en la conciliación de fin de mes, no en tiempo real.
Este patrón produce mediciones de OEE pero no desbloquea análisis de órdenes de trabajo impulsados por OEE. Es aceptable como una implementación de fase 1 en plantas con políticas estrictas de gestión de cambios en Epicor, con la hoja de ruta explícita para actualizar al Patrón 1 o 2 en la fase 2.
Campos mínimos viables: número de Job, sufijo de Job (para trabajos divididos), número de operación, número de pieza, cantidad solicitada, cantidad completada, estado de la operación, centro de trabajo / recurso, fecha y hora de inicio, fecha y hora de fin, ID del operador (si la entrada de mano de obra está conectada). La mayoría de las plataformas OEE leen estos campos mediante una única vista JobOper en 5-15 segundos; la sobrecarga de integración es pequeña si el alcance está bien definido.
Si su arquitectura escribe de vuelta: total de piezas producidas (PartTran), minutos de mano de obra (LaborDtl) y métricas resumen de OEE (en un campo UD personalizado en JobOper). Si su arquitectura no escribe de vuelta: las métricas resumen de OEE se publican en Power BI o en una vista analítica en una ubicación separada, y los usuarios de Epicor las leen a través del portal analítico en lugar de la interfaz de Epicor.
Antes del go-live, ejecute seis pruebas: (1) el evento de creación de Job dispara el acuse de recibo en el lado OEE; (2) la transición de estado del Job (Started → Paused → Started) preserva la continuidad de la medición OEE; (3) el cierre del Job envía de vuelta un registro resumen que coincide con el alcance esperado; (4) escenarios de datos erróneos (no se encuentra JobOper, vinculación ambigua del centro de trabajo, caída de red) fallan de forma controlada con errores registrados; (5) escenarios multi-planta enrutan al alcance correcto de la planta OEE; (6) fallos de permisos retroceden limpiamente sin bloquear Epicor.
La mayoría de las plataformas OEE empresariales consolidadas tienen al menos la capacidad de integración del Patrón 2 (sondeo) para Epicor. TrakSYS de Parsec, FORCAM FORCE y Fabrico CMMS + CV OEE admiten la integración con Epicor mediante patrones documentados. La profundidad y la limpieza de la integración varían; solicite a cada proveedor un cliente de referencia que haya estado ejecutando su integración en producción durante al menos 12 meses.
Kinetic Cloud es el objetivo recomendado para nuevas integraciones con Epicor en 2026. La superficie de la API REST es la misma que la de Kinetic local pero se accede a través del endpoint de la nube pública de Epicor. La autenticación utiliza OAuth 2.0 con el IdP de Epicor.
El host de integración de la plataforma OEE necesita salida a Internet; si su plataforma OEE también es SaaS, la integración es de nube a nube y más fácil de desplegar que las arquitecturas mixtas nube-local.
SAP PM utiliza patrones OData e IDoc; Microsoft Dynamics 365 utiliza Business Events y Common Data Service. Los principios arquitectónicos de esta guía (flujo de eventos impulsado por órdenes de trabajo, cuenta de servicio dedicada, orientado a eventos en lugar de sondeo) se aplican a los tres.
Los endpoints específicos y los patrones de autenticación difieren, pero un proveedor que se haya integrado de forma limpia con Epicor normalmente tiene la capacidad técnica para integrarse igualmente de forma limpia con SAP PM y Dynamics 365.
Epicor MES (el módulo heredado de planta) se solapa con lo que hace una plataforma OEE, lo que genera una decisión estratégica: reemplazar Epicor MES por la nueva plataforma OEE, o ejecutar ambos en paralelo con límites de alcance claros. Las plantas que ejecutan ambos encuentran la superposición confusa para los operadores y cara de mantener; las plantas que reemplazan Epicor MES típicamente migran dentro de los 6 meses posteriores a la puesta en producción de la plataforma OEE.
La migración es un proyecto separado de la integración inicial.
Ejecute una instancia de integración separada por código de empresa, o utilice la capa de informes intercompañía de Epicor (si está licenciada). El primer enfoque es más simple y rápido; el segundo es preferible si la ingeniería corporativa quiere informes centralizados. En cualquier caso, no intente "consolidar" múltiples códigos de empresa en un único tenant de la plataforma OEE sin un alcance por planta explícito, la carga de higiene de datos se vuelve inmanejable.
Para el Patrón 1 (orientado a eventos) en un entorno Kinetic de una sola empresa, espere €30k-€80k en honorarios de integración al proveedor más 80-150 horas del tiempo interno del administrador de Epicor. El Patrón 2 (sondeo) es algo más barato, €20k-€60k al proveedor más 50-100 horas internas.
El Patrón 3 (basado en archivos) es el más barato con €15k-€40k al proveedor más 30-60 horas internas, pero produce el análisis más débil. Para multiempresa o ERP 10, espere 1,5-2x estos rangos.
La integración OEE con Epicor tiene éxito con el patrón de flujo de eventos impulsado por órdenes de trabajo, la participación del administrador de Epicor desde la semana 1 y una arquitectura limpia que trate la orden de trabajo como un objeto compartido. La implementación es un proyecto de 6 semanas con un recurso dedicado del lado de Epicor, 10-14 semanas sin él.
Evalúe honestamente el alcance según su versión de Epicor, ejecute un piloto de una línea en la semana 4, dedique la semana 5 a la higiene de datos y entregue a TI interno en la semana 6. El valor aparece en las semanas 7-12 cuando los análisis de órdenes de trabajo atribuidos por OEE comienzan a impulsar decisiones reales de planificación de producción y mantenimiento.
Vea cómo Fabrico unifica OEE y mantenimiento en una sola plataforma.
Solicitar una demo
Iniciar sesión
Blog
