L’opportunità di espandere il proprio mercato e fatturato, sfruttando l’abilità d’interagire in maniera capillare, efficace, efficiente, con consumatori e clienti attraverso tutti i canali possibili, sta spingendo sempre più imprese ed organizzazioni a perseguire, e realizzare, una strategia commerciale omnicanale.
Attraverso l’omnicanalità, l’acquirente riesce a vivere un’esperienza d’acquisto gratificante, accedendo a dati e contenuti sempre sincronizzati e coerenti, indipendentemente dal canale o touchpoint che sta visitando al momento (sito web, mobile app, canale social, negozio o punto vendita fisico).
Perché serve un’architettura applicativa diversa
Spesso, tuttavia, l’obiettivo di realizzare un solida strategia omnichannel si scontra con alcune limitazioni dei sistemi legacy ancora funzionanti nell’infrastruttura di back-end aziendale. Le tipologie di ostacoli sono almeno due. Il primo riguarda il potenziale limite nella capacità dei cosiddetti “Systems of Record” (SOR). Con questo termine generico si indica l’insieme dei sistemi IT – talvolta legacy -tipicamente presenti nel back-end, tra cui applicativi gestionali, ERP, CRM. Non sempre i SOR hanno la capacità di rendere disponibili in qualunque momento, per le applicazioni e servizi dei nuovi canali digitali, i dati memorizzati al proprio interno: a diversi utenti, infatti, può essere capitato, ad esempio nelle ore notturne, di accedere dallo smartphone all’app di home banking, o a quella dell’operatore telefonico, e constatare che non è possibile eseguire una transazione, rinnovare un contratto, consultare i dati di pagamento delle bollette sul proprio account. Questo accade perché i sistemi IT (SOR) che gestiscono tali informazioni possono risultare spenti, ad esempio per attività di manutenzione dei server. Questa limitazione influisce negativamente in maniera duplice su un’organizzazione che punta a implementare una strategia omnicanale: da un lato, infatti, l’utente finale percepisce tali carenze come indice di scarsa qualità del servizio; dall’altro, l’azienda stessa ed eventuali partner, che possono collaborare in strategie commerciali di co-selling di prodotti o servizi, non possono contare su un’infrastruttura IT pienamente attiva, capace di supportare appieno i nuovi canali digitali di business in modalità 24/7.
Il secondo ostacolo è relativo alle prestazioni dei suddetti sistemi legacy, perché i tempi di risposta dei SOR possono allungarsi anche di molto, in funzione del numero di richieste dati che i server ricevono in contemporanea. Si riesce facilmente ad immaginare, ad esempio, come può comportarsi un’applicazione ERP o CRM, originariamente sviluppata per sostenere il solo traffico generato dalle richieste dati provenienti dagli addetti del reparto marketing e vendite, o del servizio clienti aziendale, quando si trova a dover amministrare un traffico enormemente più grande, generato da interazioni continue degli utenti con i differenti canali commerciali che l’azienda in questione ha creato online: in questi casi, il sistema può manifestare una forte degradazione dei tempi di risposta, o addirittura andare in tilt.
‘Disaccoppiare’ i sistemi IT legacy dai canali digitali
Di fronte a tali problemi, le soluzioni che prevedono un potenziamento dei sistemi gestionali legacy in termini di disponibilità dati, scalabilità, prestazioni, possono rivelarsi molto costose. Un altro aspetto da non sottovalutare è il potenziale insorgere di problemi di security: infatti, più si praticano tradizionali interventi d’integrazione dei sistemi legacy di back-end con i moderni canali digitali, più si rischia d’introdurre ulteriori vulnerabilità nella sicurezza IT dell’infrastruttura.
Per ovviare a tali inconvenienti, la soluzione che un crescente numero di organizzazioni sta adottando è l’implementazione di un livello di software intermedio, noto come Digital Integration Hub (DIH). Quest’ultimo è progettato per rispondere all’esigenza di mediare la comunicazione tra i sistemi legacy di back-end e i vari canali e touchpoint digitali, ed è in grado di amministrare gli attuali volumi di traffico soddisfacendo i necessari requisiti in fatto di disponibilità dei dati, tempi di risposta del sistema, sicurezza di comunicazione.
Sul tema dei DIH abbiamo voluto ascoltare l’opinione di Giulio Roggero, CTO e cofondatore di Mia-Platform. Dal suo punto di vista, perché, quanto è importante oggi trasformare l’architettura applicativa? “Più che parlare di trasformazione parlerei di evoluzione. Il business, il mercato e i bisogni dei clienti finali cambiano ed evolvono nel tempo; lo stesso devono fare i sistemi digitali. Più sono capaci di evolvere, più velocemente si riesce a rafforzare il business. Quando questi sistemi non riescono più ad evolvere allora è necessario trasformarli in modo che siano evolvibili; in caso contrario si perde competitività”.
Che approccio/percorso di migrazione proponete alle imprese che vogliono far evolvere l’architettura applicativa? Quali sono le fasi chiave? “Ai nostri clienti proponiamo un percorso graduale di evoluzione: non un big bang che dura mesi, se non anni, ma un approccio graduale con ‘vittorie veloci’ e risultati tangibili dopo un mese, tre mesi, sei mesi. Durante questo percorso emergono i processi e gli strumenti migliori che guideranno l’intera trasformazione e permetteranno di costruire una cultura di continuo miglioramento ed evoluzione incentrata sul creare valore per i clienti finali grazie a servizi digitali sicuri, affidabili e semplici da utilizzare”.
Qual è la peculiarità principale della piattaforma, e della consulenza, di Mia-Platform in questo percorso? “Tutte le persone di Mia-Platform non si pongono come dei semplici fornitori ma come dei partner che aiutano a costruire il futuro business digitale del cliente. La forza di Mia-Platform è la sua capacità di essere poliedrica e di costruire la soluzione digitale che più si adatta all’esigenza dei clienti. Adottare la Suite di prodotti Mia-Platform è come comprare una scatola Lego 3×1: ci sono le istruzioni di base per costruire alcune tipologie più utilizzate di piattaforma ma con il crescere delle esigenze è possibile creare le proprie istruzioni di montaggio e combinare i propri mattoncini per realizzare la propria piattaforma. I mattoncini sono i microservizi, i connettori tra mattoncini sono le API e le istruzioni sono le linee guida che la nostra DevOps Console rende semplici da adottare, grazie agli approcci GitOps e Compliance as Code”.
