La forma en que la conectividad con los bancos puede poner trabas en la migración de ERP a la nube

By Remy Dubois mayo 12, 2020

En la tecnología de la información, a menudo se desarrollan nuevos términos sin tener en cuenta la importancia de las palabras que componen el término.

Esto se aplica directamente al término “conectividad con múltiples bancos”, en forma específica a la palabra “múltiples”.

Poder administrar con eficacia múltiples, o más precisamente muchos, bancos es esencial. Es importante considerar los siguientes cuatro elementos de los bancos:

  • Un banco es una organización externa y no una entidad interna con integración típica de TI.
  • Un banco es una organización orientada a los procesos debido a sus requisitos de cumplimiento y seguridad.
  • Los bancos internacionales que operan en diferentes zonas horarias podrían tener hasta 12 horas de diferencia con el lugar en el que usted se encuentra.

Es posible que sus contactos en algunos bancos tengan dificultades con el inglés o con su idioma nativo, por lo que el trabajo técnico será un desafío.

¿Cuántos bancos suelen incluirse en la conectividad con múltiples bancos?

Cuando hablamos de “múltiples bancos”, no nos referimos solo a dos o tres bancos. En algunos casos, las compañías tienen que administrar 10 o 20, si no 50 a 100 bancos.

Las implicaciones de la conectividad con múltiples bancos en los departamentos de TI

Cuando se inicia un proyecto local de conectividad con los bancos dirigido por TI, la dificultad de agregar otros bancos al software de ERP suele ser una de las áreas más subestimadas del proyecto. Debido a la complejidad y al enorme alcance de las diferentes tareas por realizar, la conectividad con los bancos es un dominio malinterpretado y a menudo subestimado.

El trabajo que implica la integración con los bancos

Tradicionalmente, los clientes que deseaban implementar una central global de pagos debían pedirles a recursos internos de TI que crearan y probaran formatos de pagos y flujos a sus bancos.

Debido a la cantidad de variables que hay en un formato de pago, se deben modificar y probar cientos de personalizaciones de formatos en cada entorno antes de iniciar las pruebas con el banco, que rara vez funcionan la primera vez.

Estas personalizaciones de formatos incluyen lo siguiente:

  • el banco,
  • la sucursal de origen,
  • la sucursal de destino,
  • el tipo de pago,
  • si hay una conversión de divisas,
  • pago urgente o no urgente,
  • la divisa,
  • otros campos regionales o específicos del banco.

La magnitud de los formatos y escenarios que deben crearse y probarse puede ser enorme y abrumadora. Esto se relaciona particularmente con el hecho de que la mayor parte de la integración de aplicaciones que realizan los departamentos de TI implica conectar una aplicación con otra aplicación. Cuando las compañías inician un proyecto importante, los recursos de TI ya son escasos y tienen poco tiempo para crear y probar todos los formatos de pago requeridos.

Escenarios de pago y variaciones de escenarios de pago

Las variaciones entre los bancos en términos de protocolos, formatos de archivo y seguridad, entre otros factores, suelen convertirse en una integración única para un escenario de pago específico, para cada banco.

Un escenario de pago podría ser Banco A – Sucursal de origen Frankfurt – Sucursal de destino Madrid – Pago SEPA no urgente – No divisa – Euro.

Los escenarios de pago deben probarse con el banco porque los errores causarán fallas en los pagos. Esto se debe a que para que un pago atraviese un proceso completo debe cumplir con los requisitos específicos establecidos para cada banco. Sin embargo, el departamento de TI luego debe llevar un registro de las variaciones entre los bancos.

Para la implementación de la conectividad con un banco, en general, se requieren entre tres, cinco o diez formatos. No obstante, hay aproximadamente quinientas variantes para los proyectos de conectividad con bancos internacionales.
En función de nuestra experiencia en la asistencia que brindamos a los clientes con la conectividad con los bancos, la secuencia de pasos para habilitar dicha conectividad suele ser la siguiente:

  1. Desarrollo de especificaciones: con un sistema ERP, es necesario desarrollar todas las especificaciones de datos después de haber recibido la información del banco.
  2. Extracción y transformación: el siguiente paso es crear el código de extracción y transformación que extraerá los datos correctos de la base de datos de ERP. Como alternativa, si se usa una aplicación de conectividad con múltiples bancos como el área de trabajo de integración para configurar los archivos de pago, en general, se los debe mover uno por uno entre el software de ERP y cada banco. Cualquiera sea el caso, el departamento de TI debe encarar una gran cantidad de trabajo. De acuerdo con nuestro análisis, la conectividad con múltiples bancos incrementa la carga de trabajo con respecto al uso de lenguajes de desarrollo estándares para crear la conectividad.
  3. Prueba: luego, se utiliza un valor de centavo para probar la interfaz con el banco participante. La primera vez que se ejecuta la conexión, casi en todos los casos, no funcionará.
  4. Resolución de errores o fallas en la interfaz: el banco participante explicará el motivo por el que la integración no tuvo éxito. Sin embargo, a menudo, el equipo de TI del cliente no entenderá la explicación que proporcionó el banco, ya que los bancos usan su propia terminología y expertos en el dominio con los que los departamentos de TI no están familiarizados. En general, cada escenario modificará la información que deba enviarse. Como ejemplo, un escenario que envía información de pago de Alemania a Polonia cambia cuando el pago se envía de Alemania a Dubái. Esto vuelve a cambiar cuando se modifican los tipos de pago. Si el pago es urgente o no modifica nuevamente los datos necesarios. Cada escenario cambia los datos que deben enviarse, y un solo campo faltante o un formato incorrecto significa el fracaso de la prueba.

Como resultado de esta complejidad, para agregar un nuevo banco, se suelen requerir de seis a 12 meses, y un rango de 5 o 10, si no 80 bancos, podría poner en riesgo el éxito de su migración a la nube.

Para conocer cómo puede simplificar y acelerar la integración con los bancos durante la migración de ERP a la nube, descargue nuestro último libro electrónico.

img
Active la liquidez.

Transforme el uso de la liquidez como vehículo dinámico para el crecimiento y la revalorización

Descubra cómo