Blog

Integrazioni bancarie: l’aspetto più complesso di un progetto ERP nel cloud

By Kyriba

In un periodo in cui molte aziende si preparano a una migrazione ERP nel cloud e sono interessate a digitalizzare le loro applicazioni aziendali, molte società ERP e molti integratori di sistemi sono pronti a capitalizzare la situazione e a raccogliere i frutti di anni di lavoro su progetti di migrazione.

La maggioranza di questi progetti avrà una natura globale e dovrà affrontare le complesse sfide poste dalle integrazioni bancarie a livello mondiale, considerate da molti integratori di sistema uno degli aspetti più complessi dei progetti ERP.

Snellire la connettività bancaria tramite MBC (multi-bank connectors, connettori multi-banca) può rivelarsi un’impresa non da poco in qualsiasi progetto di migrazione ERP. Molte squadre IT rincorreranno la standardizzazione con SWIFT o Alliance Lite2, ma la verità è che ciascuna banca richiede un formato differente tanto per le connessioni, quanto per inviare alle altre banche i formati dei pagamenti approvati. Per esempio, l’FTP è un protocollo che imposta la comunicazione tra un mittente e un destinatario. Come sanno tutti coloro che lo usano, il formato dei file scambiati è irrilevante. SWIFT coopera con organizzazioni che definiscono gli standard (ISO 9362, ISO 10383, ISO 13616, ISO 15022, ISO 20022-1 e ISO 20022-2); ciò nonostante, le interazioni tra banche continuano a essere afflitte dalla varietà e dalla complessità dei formati dei dati.

Per stabilire semplicemente una connessione tra una singola banca ed ERP, le squadre IT devono tipicamente passare attraverso questa sequenza di eventi:

Passo 1: Ottenere dall’azienda i requisiti bancari

Passo 2: Collocarli nella coda di attesa del progetto

Passo 3: Attendere che l’azienda e la banca preparino la documentazione richiesta e sottoscrivano i contratti

Passo 4: Organizzare una prima riunione con la banca, che potrebbe coinvolgere anche il reparto finanziario, la tesoreria, la squadra della connettività e lo SWIFT Service Bureau.

Passo 5: Ottenere le specifiche dalla banca e iniziare lo sviluppo

Passo 6: Organizzare il primo test con la banca, coordinandosi con l’azienda, la squadra della connettività e la banca

Passo 7: La maggior parte dei formati dovrà essere testata più volte. Siamo a conoscenza di formati testati anche 5 volte.

Passo 8: Il formato esce dalla fase di sviluppo

Passo 9: Preparazione

Passo 10: CQ

Passo 11: Non produzione

Passo 12: Penny test

Passo 13: Produzione

La procedura per stabilire una connessione tra anche una sola banca ed ERP è lunga e complessa e per alcune banche internazionali può richiedere anche un anno, prima di arrivare alla fase di produzione.
Una volta stabilita la connessione con la banca, poi, possono occorrere anche più di sei mesi per mettere in produzione i formati dei pagamenti. Negli USA, inviare un file NACHA per pagamenti ACH a una banca è relativamente semplice. Tuttavia, l’interazione con banche di altri paesi può far sorgere molte complicazioni. Per questo si rende necessario testare con ogni singola banca tutti gli scenari possibili concernenti i formati.

Tra i campi che vanno necessariamente verificati ci sono:

  • Banca d’origine
  • Filiale
  • Paese della banca d’origine
  • Paese della banca destinataria
  • FX
  • Valuta
  • Importo elevato o piccolo importo
  • Codice del paese
  • Codice della causale del pagamento
  • Protocollo

Una volta completata l’analisi, se si prendono in considerazione tutte le banche, le valute, i paesi, ecc., è facile capire come alcune aziende possano ritrovarsi a dover gestire centinaia di formati. Ulteriori complicazioni per le squadre IT sorgono dalla necessità di dover gestire le differenze regionali che possono presentarsi all’interno di una stessa banca. Per esempio, CITI non è una sola banca. I suoi dipendenti agiscono sotto le stesse insegne, ma CITI è composta da migliaia di banche sparse in tutto il mondo, con requisiti diversi da regione a regione e spesso anche da filiale a filiale. Senza considerare le eventuali difficoltà specifiche di ogni regione. Per i pagamenti Boleto, l’America Latina ha delle specifiche che non vengono riconosciute in nessun’altra parte del mondo; in Germania e Francia si può utilizzare l’EBICS; in Europa il SEPA, nel Regno Unito il BACS, in Giappone lo Zengin e in Cina le banconote.

Un’ultima componente che la squadra IT potrebbe non sapere o volere gestire è SWIFT. Molte aziende pensano di implementare SWIFT tramite AL2, ma la loro squadra IT potrebbe non essere pronta a farlo. A partire dal 2020, SWIFT ha istituito nuovi mandati in merito a sicurezza e certificazioni. Le aziende che intendono gestire il proprio BIC tramite AL2 dovranno sviluppare un’expertise interna in merito a SWIFT e sottoporsi a un programma di test e certificazioni annuale. Qualora la risorsa certificata abbandonasse l’azienda, il reparto IT dovrebbe provvedere alla sua sostituzione con un’altra risorsa formata e certificata.

La nostra esperienza per la tua connettività bancaria

Anziché costringere il reparto IT a occuparsi di un’area di sviluppo e manutenzione estranea alla sua area di competenza, le aziende potrebbero soddisfare le proprie esigenze di connettività cloud per ERP rivolgendosi a Kyriba. Grazie alla nostra soluzione di connettività bancaria pronta all’uso e alla nostra libreria di formati dei pagamenti condivisa comprendente più di 45.000 formati già sviluppati e testati in tutto il mondo, siamo riusciti a ridurre i tempi dei progetti di connettività bancaria globale anche dell’80%. Il nostro portfolio include oltre 1.000 aziende. Non vediamo l’ora di scoprire insieme a te come possiamo accelerare anche il tuo progetto di migrazione nel cloud.

Share