Los registros de pedidos y existencias se transfieren entre SAP e IBM AS/400 en ambas direcciones, por lo que dos sistemas que han funcionado correctamente durante años dejan de discrepar silenciosamente sobre las mismas cifras a final de mes.
El IBM AS/400 es una plataforma, no una aplicación, por lo que no hay dos iguales. Su contenido y la información que expone son las funciones para las que fueron diseñados los programas creados para ese negocio en particular, y esos programas suelen ser fiables desde hace dos décadas. Se promocionó como un sistema difícil de conectar, pero en general no lo era. La integración de SAP con IBM AS/400 lo trata como lo que es: un sistema accesible con interfaces que llevan años funcionando, que almacena datos que SAP necesita y que requiere datos que SAP almacena, con una de las partes reconocida como fuente autorizada para cada uno.

Alumio funciona con las interfaces que ya presenta el AS/400, por lo que el punto de partida es lo que la máquina expone actualmente, en lugar de un programa de modernización planificado con antelación.
El stock, los precios y el estado de los pedidos tienen cada uno un sistema de registro designado, por lo que SAP y el AS/400 dejan de tener dos versiones de un número que solo uno de ellos debería decidir.
Cada nuevo requisito reutiliza la configuración de AS/400 ya existente en lugar de agregar otra extracción programada, por lo que la máquina atiende una integración en lugar de nueve trabajos.
La forma en que los datos salen del AS/400 se configura y se visualiza en Alumio, por lo que deja de ser algo que solo el compañero que lleva más tiempo trabajando allí puede explicar a los demás.
Un pedido creado en SAP se registra en el AS/400. Alumio se conecta a él a través de las interfaces que ya expone, como lo haría con cualquier sistema accesible, y asigna cada pedido a los campos que esos programas esperan recibir.
Los saldos de existencias que mantiene el sistema AS/400 se publican en SAP con la frecuencia que requiere la planificación, por lo que esta se basa en las existencias reales del almacén, en lugar de en una cifra que era precisa en el momento de la extracción de la semana pasada.
Un proceso de extracción que se ha ejecutado todas las noches durante años se convierte en una ruta configurada, de modo que los mismos datos llegan a SAP con un registro de lo que se movió y cuándo, y nadie necesita recordar en qué servidor se ejecutaba el trabajo anterior.
Alumio se sitúa entre los canales de venta y los sistemas de cumplimiento como una columna vertebral de integración gobernada. Los pedidos se enrutan, transforman y validan, mientras que las actualizaciones de estado regresan a cada canal.
Autentique sus sistemas utilizando los conectores preconfigurados de Alumio. Elija entre más de 200 paquetes de conectores en el marketplace, además de integraciones personalizadas ilimitadas.
Defina cómo se asignan los campos de datos entre sistemas en una interfaz visual. Ajuste formatos, enriquezca registros y aplique lógica de negocio, sin necesidad de código personalizado.
Configure los flujos para que se ejecuten en tiempo real según eventos, según un horario o ambos. Reduzca la entrada manual de datos y deje que Alumio gestione el movimiento y la transformación entre sistemas.
Una vez que su primera integración esté activa, añadir su ERP, PIM, WMS o CRM se conecta al mismo centro. Los flujos existentes siguen funcionando. Sin necesidad de reconstruir desde cero.
Un canal EDI para socios comerciales es una adición habitual, ya que una empresa que utiliza un AS/400 prácticamente siempre ha intercambiado archivos con sus clientes durante años, y esos intercambios son las integraciones menos visibles que posee. Alumio los gestiona junto con la configuración del AS/400 ya existente, de modo que la comunicación con un socio se convierte en una ruta con un registro en lugar de un script heredado.
Sí, y decidir qué sistema es el más fiable para cada cifra es más importante aquí que el cronograma. Ambos sistemas pueden gestionar el stock, los precios y el estado de los pedidos, por lo que Alumio está configurado con un sistema de registro por cifra y publica en esa dirección. Cuando algo realmente tiene que moverse en ambas direcciones, la secuencia es explícita en lugar de dejarse a criterio del último proceso ejecutado.
No, esto se configura, no se codifica. Los saldos de inventario, los números de pedido y las referencias de cuenta que ambos sistemas utilizan para el mismo cliente se asignan una sola vez en Alumio y se mantienen allí, lo que reemplaza el script de extracción que normalmente se ejecuta. Para una conversión que décadas de convenciones locales han hecho realmente peculiar, el Code Transformer requiere lógica personalizada en ese paso.
Por lo general, no es tan complejo como sugiere una propuesta de modernización. El AS/400 es una plataforma, por lo que se basa en el código diseñado para ese negocio, y parte de él funciona bien y es comprendido por quienes dependen de él. La solución ideal consiste en mantener el procesamiento donde se ejecuta y trasladar solo los datos que necesitan otros sistemas, lo cual es una decisión más sencilla y mucho más reversible.
Tras la aceptación de un registro, los dos sistemas se desvían, lo que provoca un fallo imperceptible, ya que un cambio posterior en SAP deja al AS/400 con una versión que era correcta en el momento de su llegada. Alumio monitoriza cada transferencia en tiempo real y registra con exactitud la información entregada, por lo que un registro rechazado genera una alerta inmediata con el motivo, y los reintentos se ejecutan automáticamente donde estén configurados. Las actualizaciones se vuelven a publicar al producirse un cambio, evitando así que ninguno de los sistemas se quede con la cifra del mes anterior sin darse cuenta.
Habla con un especialista en integración de Alumio. Diseñaremos la arquitectura adecuada para tus sistemas, a la escala correcta, para que tus operaciones sigan siendo fiables ante cualquier cambio.