Integraciones con los bancos: el aspecto más complejo de un proyecto de ERP en la nube

A medida que muchas compañías se preparan para una migración de ERP a la nube y para la digitalización de sus aplicaciones empresariales, las compañías ERP y los integradores de sistemas están listos para sacar provecho de esta situación y cosechar los frutos de años de trabajo en proyectos de migración.

La mayoría de estos proyectos serán de naturaleza global y deberán abordar la complejidad de las integraciones bancarias globales. Además, muchos integradores de sistemas coinciden en que las integraciones bancarias para las ERP son uno de los aspectos más complejos del proyecto.

La optimización de la conectividad con los bancos con conectores de múltiples bancos puede ser un desafío en cualquier proyecto de migración de ERP. Aunque muchos equipos de TI optarán por la estandarización con SWIFT o Alliance Lite2, la verdad es que cada banco sigue necesitando sus propios formatos para conexiones y para implementar los formatos de pago aprobados en los bancos. Por ejemplo, FTP es un protocolo que establece la comunicación entre el emisor y el receptor. Como sabe cualquiera que haya usado FTP, este protocolo es independiente del archivo en sí. SWIFT coopera con entidades normalizadoras, como ISO 9362, ISO 10383, ISO 13616, ISO 15022, ISO 20022-1 e ISO 20022-2; sin embargo, los complicados y variados formatos de datos siguen plagando las interacciones bancarias.

Veamos el proceso y la secuencia de eventos que TI debe atravesar para conectar a un solo banco a un sistema ERP, un caso de uso simple de conectividad con bancos:

Paso 1: Recopilar los requisitos bancarios de la empresa

Paso 2: Colocarlos en la cola del proyecto

Paso 3: Esperar a que la empresa complete los contratos/trámites necesarios con el banco

Paso 4: Programar la primera llamada con el banco, que también puede incluir las áreas de finanzas, tesorería, el equipo de conectividad, oficina y banco

Paso 5: Recopilar las especificaciones del banco e iniciar el desarrollo

Paso 6: Programar la primera llamada de prueba con el banco, coordinar con la empresa, el equipo de conectividad y el banco

Paso 7: La mayoría de los formatos deberán probarse varias veces. En algunos casos, se han necesitado 5 pruebas para un formato

Paso 8: El formato sale de la etapa de desarrollo

Paso 9: Prueba

Paso 10: Control de calidad

Paso 11: No producción

Paso 12: Prueba con un centavo

Paso 13: Producción

Los pasos necesarios para conectar tan solo un banco a un sistema ERP son exhaustivas, y algunos bancos internacionales pueden tardar más de un año en entrar a la etapa de producción.

Después de establecer la conexión del banco, hemos vistos formatos de pago que han tardado más de seis meses en llegar a la etapa de producción. Enviar un archivo ACH NACHA nacional estadounidense a un banco es un proceso bastante simple. Sin embargo, pueden surgir otras complicaciones cuando se administra un negocio bancario global. Por este motivo, es necesario probar cada uno de los escenarios de los formatos con cada banco.

Estos son algunos de los ejemplos de los campos obligatorios:

• Banco de origen
• Sucursal
• País de origen
• País de destino
• Cambio de divisas
• Divisa
• Valor elevado o valor reducido
• Campo específico del país
• Código de motivo del pago
• Protocolo

Una vez realizado el análisis, si se tienen en cuenta todos los bancos, las divisas, los países, etc., resulta fácil ver cómo algunas empresas pueden tener cientos de formatos obligatorios. Para incrementar las complejidades, los equipos de TI tienen que resolver las diferencias regionales en los bancos. Por ejemplo, CITI no es un solo banco. El nombre puede ser el mismo, pero CITI está compuesto por miles de bancos en todo el mundo, cuyas regiones, o incluso sucursales, tienen sus propios requisitos. Además, cada región geográfica puede tener sus dificultades inherentes. En América Latina, se aplican especificaciones en torno a los pagos Boleto que no se reconocen en ninguna otra parte del mundo. Alemania y Francia pueden utilizar EBICS, SEPA en Europa, BACS en el Reino Unido, Zengin en Japón o las notas bancarias en China.

Un componente final para el que TI podría no estar listo o dispuesto a adoptar es la administración de SWIFT. Muchas corporaciones están analizando la implementación de SWIFT a través de AL2, pero es posible que TI no esté preparado para los requisitos. En 2020, SWIFT incorporará nuevos mandatos en torno a la seguridad y las certificaciones. Las compañías que opten por administrar su propio BIC a través de AL2 tendrán que contar con expertos internos en el dominio de SWIFT y llevar a cabo un programa anual de certificación y prueba. Si el recurso que obtuvo la certificación abandona la empresa, TI tendrá que capacitar y certificar a un nuevo recurso.

Una solución experimentada para la conectividad con los bancos

En lugar de que el departamento de TI deba hacerse cargo de otra área de desarrollo y mantenimiento que esté fuera de su dominio, incentivamos a los departamentos corporativos de TI a recurrir a Kyriba para el requisito de conectividad de ERP en la nube. Hemos logrado acelerar los proyectos de conectividad global con los bancos en más del 80 por ciento con nuestra solución de conectividad bancaria adicional lista para usar y nuestra biblioteca compartida de formatos de pago con más de 45 000 formatos de pago globales previamente desarrollados y probados. Con más de 1000 clientes que utilizan nuestra conectividad, esperamos poder mantener una conversación para acelerar su proyecto de la nube y sus tareas de migración..