Comprendere la complessità delle integrazioni bancarie dei sistemi ERP

Nel corso dei prossimi cinque anni, il settore del software aziendale subirà una forte scossa e, entro la fine del decennio, la maggior parte delle aziende eseguirà il proprio sistema ERP nel cloud. Questo genererà sicuramente un forte aumento del volume d’affari delle società ERP e dei molti integratori di sistemi pronti a sfruttare la situazione e a raccogliere i frutti di anni di lavoro su progetti di migrazione, molti dei quali di livello globale, con tutte le complicazioni derivanti dall’integrazione bancaria internazionale.

Il nostro lavoro è aiutare le aziende nei loro progetti di migrazione nel cloud e ogni volta che interveniamo in un processo di migrazione già avviato sentiamo dire sempre le stesse parole: “Non credevamo che fosse un processo tanto complesso e dispendioso in termini di tempo.” Di fatto, molti integratori di sistemi con cui collaboriamo non fanno che ripeterci che le integrazioni bancarie sono tra le componenti più rischiose dei loro progetti.

Spesso le difficoltà non derivano tanto dallo sviluppo dell’interfaccia bancaria, quanto dal fatto che ci si trova alla mercé delle tempistiche delle banche. Oggi le squadre IT delle aziende sono perfettamente in grado di creare interfacce tra sistemi di back-office diversi, ma di solito si tratta di interfacce stagnanti, che non richiedono la partecipazione di risorse aggiuntive. Dovendo però lavorare a un’interfaccia bancaria, le squadre IT devono di solito coinvolgere più risorse, da coordinare per di più con la banca: oltre al reparto IT, possono essere coinvolti la tesoreria, la contabilità fornitori, la squadra della connettività, lo SWIFT Service Bureau e la squadra tecnica della banca. Quando infine vengono sviluppate le specifiche, è raro che superino il primo test. Di conseguenza, la squadra di sviluppo dovrà rimettersi al lavoro e ripartire coi test, affrontando di nuovo il problema del coordinamento tra le risorse. Sappiamo di casi in cui, prima che la banca approvasse il formato, sono stati necessari dai due ai cinque test.

Dopo l’approvazione del formato da parte della banca, la squadra IT deve occuparsi delle sue procedure interne: sviluppo, testing, CQ, non-produzione e produzione. Nella pratica, non è raro che per sviluppare, testare e mettere in produzione un singolo formato di pagamento utilizzabile dal proprietario dell’attività possano essere necessari anche più di sei mesi.

Un errore che vediamo commettere spesso quando interveniamo nei progetti di integrazione bancaria per fornire assistenza è ritenere che SWIFT sia un tipo di messaggio standard per tutte le banche. Anche se SWIFT sta passando dal formato MT al formato XML, ciascuna banca continuerà a richiedere determinati requisiti per l’accettazione dei file in ingresso. E dato che ciascuna banca richiederà specifiche differenti e che spesso bisognerà sviluppare più formati per ciascuna banca (piccoli importi, importi elevati, assegni, bonifici, ecc.), la maggior parte delle aziende dovrà sviluppare e testare centinaia di formati per poter comunicare con tutte le banche di cui ha bisogno. È frequente che le aziende del settore IT impieghino anche più di due anni per coordinarsi con tutte le banche e testare i formati di pagamento.

Una volta messi in produzione i nuovi formati, la squadra dell’infrastruttura IT è chiamata a gestirli. In base alla nostra esperienza, per la maggior parte delle aziende la gestione continua di queste connessioni, la risoluzione dei problemi, la modifica dei formati sulla base delle richieste delle banche e l’aggiunta di nuove banche richiede l’impiego di risorse aggiuntive in un numero variabile da due a cinque persone, a seconda dell’intensità dell’attività bancaria dell’azienda.
Un nuovo problema che le aziende devono affrontare sono i nuovi requisiti imposti nel 2020 da SWIFT. Dopo il furto di 81 milioni di dollari alla Banca Centrale del Bangladesh del 2016, portato a termine con l’ausilio di un malware che aveva preso di mira il software SWIFT, SWIFT ha introdotto delle misure per incrementare la sicurezza non solo intorno alla propria infrastruttura, ma anche dei mandati richiesti dalle aziende che controllano i propri BIC. Molte aziende che desiderano gestire una propria connessione SWIFT opteranno per l’adozione di Alliance Lite2 (AL2). Ma, con i nuovi requisiti imposti per il 2020, la squadra di supporto IT interna dovrà ottenere certificazioni annuali e svolgere fino a 12 test annuali per poter continuare a gestire la connessione SWIFT. Per le squadre IT interne, questo rappresenta un rischio e costi aggiuntivi considerevoli, perché dovranno sviluppare una conoscenza del dominio SWIFT e ottenere una certificazione annuale. Molte aziende si troveranno nella situazione di avere al proprio interno non più di una o due risorse certificate, e questo rappresenta un rischio: come affrontare l’eventualità che tali risorse abbandonino l’azienda? Chi le sostituirà? Quanto potrebbe costare, in termini finanziari e di tempo, formare una nuova risorsa?

Per mitigare i rischi legati a queste risorse chiave, accelerare la migrazione ERP e semplificare la propria connettività bancaria globale, molte aziende si stanno rivolgendo a Kyriba. Grazie alla sua esperienza ventennale nella connettività bancaria, siamo certamente in grado di aiutare. I nostri adattatori bancari, forti di una rete di oltre 600 banche, forniscono una connettività pronta all’uso per la maggior parte di ERP e banche: eliminano alla radice la necessità di provvedere allo sviluppo e al testing dei formati e accelerano il time-to-value dell’ERP riducendo anche dell’80% il lavoro necessario per l’integrazione bancaria. Allo stesso tempo, non è più necessario affidare alle squadre IT interne il compito di supportare l’integrazione bancaria o acquisire le competenze necessarie per gestire SWIFT.

Per saperne di più sui nostri servizi di connettività bancaria e su come puoi accelerare il tuo progetto di migrazione ERP, contatta uno dei nostri consulenti per la connettività.