Comprensión sobre la complejidad de las integraciones de ERP con bancos

En los próximos cinco años, ocurrirá un movimiento radical en el ámbito del software empresarial. Al final de la década, la mayoría de las compañías ejecutarán su sistema ERP en la nube. Sin dudas, esto creará un aumento de ingresos para las empresas de ERP y muchos de los integradores de sistemas listos para sacar provecho de esta tarea masiva y cosechar los frutos de años de trabajo en proyectos de migración, muchos de los cuales serán de naturaleza global y deberán abordar la complejidad de las integraciones con bancos globales.

Mientras ayudamos a las compañías en sus proyectos de migración a la nube, seguimos escuchando lo mismo de aquellas que ya iniciaron el proceso de migración: “No teníamos idea de que sería tan complejo o requeriría tanto tiempo”. De hecho, muchos integradores de sistemas con los que trabajamos nos dicen que las integraciones con bancos son uno de los componentes de sus proyectos que implican mayor riesgo.

La complejidad no proviene necesariamente del desarrollo de la interfaz del banco, sino que se debe al hecho de que se está a merced de los plazos del banco. Los equipos de TI corporativos de hoy tienen experiencia en la creación de interfaces entre sistemas de “back-office”, pero suelen ser interfaces estancadas y no requieren recursos adicionales. Cuando se trabaja en una interfaz bancaria, el equipo de TI suele necesitar varios recursos para coordinar con el banco. Estos pueden incluir TI, Tesorería, Cuentas por Pagar, el equipo de conectividad, SWIFT Service Bureau y el equipo de tecnología del banco. Una vez que se desarrollan las especificaciones, casi nunca pasan la primera prueba y el equipo de desarrollo tiene que volver a crearlas y probarlas, y volver a ocuparse de la coordinación. Hemos visto casos en los que la aprobación del formato de prueba por parte del banco ha requerido repetir el trabajo de dos a cinco veces.

Una vez que el banco aprobó el formato, TI debe trabajar sobre sus procedimientos internos para el lanzamiento a producción, que incluyen desarrollo > prueba > control de calidad > no producción > producción. De hecho, es común que para que el dueño del negocio utilice un solo formato de pago, se requieran más de 6 meses para desarrollarlo, probarlo y lanzarlo.

Un error común que solemos ver cuando brindamos asistencia en proyectos de integración con bancos es la suposición de que SWIFT es el tipo de mensaje estándar que utiliza cada banco. Aunque SWIFT está pasando de MT a XML, esto no invalida el hecho de que cada banco tendrá sus propias variaciones en la forma en que acepta los archivos entrantes. Dado que cada banco requiere su propio formato y la mayoría de los clientes necesitan varios formatos por banco, como valor reducido, valor elevado, cheque, transferencia, etc., muchas compañías necesitarán que se desarrollen y prueben cientos de formatos en sus bancos. Habitualmente, vemos que a las empresas de TI les lleva más de dos años llevar a cabo todas las conexiones con los bancos y las pruebas de los formatos de pago.

Una vez que los formatos estén en producción, el equipo de infraestructura de TI tendrá que administrarlos a partir de allí. Vemos que la mayoría de las corporaciones requieren recursos adicionales para administrar estas conexiones y resolver los problemas bancarios, editar los formatos según lo estipulado por el banco e implementar nuevos bancos cuando sea necesario. Según el negocio bancario de la compañía, se puede requerir un promedio de dos a cinco personas.

Un problema nuevo que las compañías están enfrentando tiene que ver con los nuevos requisitos de SWIFT estipulados para 2020. Debido al ataque fraudulento que sufrió un banco de Bangladesh por USD 81 millones en el que piratas informáticos utilizaron malware dirigido al software de SWIFT en 2016, SWIFT no solo ha incrementado la seguridad en torno a su infraestructura, sino también para los mandatos que exigen las corporaciones que controlan su propio BIC. Muchas compañías que desean administrar su propia conexión SWIFT analizarán la adopción de Alliance Lite2 (AL2). Pero según los nuevos requisitos para 2020, el equipo interno de soporte de TI deberá obtener certificaciones y pasar hasta 12 pruebas cada año para conservar su validación para SWIFT. Esto implica un enorme riesgo y costos adicionales para muchos equipos internos de TI que ahora deben contar con expertos internos en el dominio de SWIFT y realizar certificaciones anuales. Uno de los riesgos es que muchas compañías no tendrán más de uno o dos recursos con certificación. ¿Qué ocurre en caso de que este nuevo recurso abandone la compañía? ¿Quién es el apoyo? ¿Cuál es el costo y el tiempo para capacitar a un nuevo recurso?

Para mitigar estos riesgos en torno a personas claves, acelerar las migraciones de ERP y simplificar la conectividad global con los bancos, muchas organizaciones están recurriendo a la conectividad de Kyriba. Con 20 años de experiencia y raíces en la conectividad, podemos ayudar. Nuestros adaptadores de bancos para nuestra red de más de 600 bancos conectados brindan conectividad adicional a la mayoría de los sistemas ERP y bancos, eliminan la abrumadora tarea de desarrollo y prueba, y aceleran el tiempo de obtención de valor para el ERP al reducir en más del 80 por ciento el trabajo de integración con los bancos. Este servicio meticuloso también elimina la necesidad de que el departamento interno de TI brinde soporte a las integraciones con los bancos o de que haya expertos en el dominio de SWIFT.

Para obtener más información sobre nuestros servicios de conectividad con los bancos y cómo puede acelerar su proyecto de migración de ERP, hable con uno de nuestros asesores de conectividad.