Business Continuity (BC) e Disaster Recovery (DR) sono espressioni sempre più ricorrenti nell’epoca della digital economy, dominata dall’esigenza di preservare dati da situazioni che ne possano incrinare l’inviolabilità.
La prima si riferisce alla capacità dei sistemi che gestiscono la conservazione dei dati e il loro flusso di proseguire a erogare il servizio durante e dopo un evento dannoso; il secondo fa riferimento alle iniziative tecnico-organizzative messe in atto per ripristinare dati e infrastrutture in seguito al medesimo evento sfavorevole. La tecnologia di IFM Infomaster prevede entrambi nei Conctact Center che utilizzano #phones.
Il modulo Fault Tolerance per BC e DR in #phones
Il modulo di #phones deputato a BC e DR è quello di Fault Tolerance. Si basa sul modello delle architetture distribuite in grado di garantire la continuità di servizio e il ripristino quando una minaccia esterna (malware, spyware, adware ecc.), un guasto o un errore dell’operatore mettono a rischio sia le informazioni sia il funzionamento stesso della piattaforma. La funzionalità Fault Tolerance si fonda sulla presenza congiunta di due server, uno attivo e l’altro in standby, a cui sono abbinati le applicazioni CTI (Computer Telephony integration) di IFM Infomaster. In ciascun server è installato #phones insieme al software PhonesManager. Quest’ultimo è lo strumento che permette ai due server di mantenere allineate le configurazioni del Contact Center, monitorando costantemente l’andamento di quello attivo e del server gemello. In caso di caduta di un qualunque elemento che comprometta la funzionalità del server attivo, il server secondario in standby prende il controllo. I servizi vengono attivati sul server secondario ristabilendo così la continuità e mantenendo intatte le chiamate in corso, che non vengono influenzate dal salto di Fault Tolerance.
Un paradigma per non perdere dati preziosi
Il paradigma a cui si ispira la componente Fault Tolerance di #phones è uno dei più affidabili oggi presenti in commercio. In termini di disponibilità, infatti, raggiunge una percentuale di almeno il 99,999% con periodi di downtime non pianificato, cioè di inattività, che si aggirano tra i 2,5 e i 5,25 minuti all’anno. Senza questa componente il Disaster Recovery, che solitamente viene garantito mediante la ridondanza geografica su server gemelli, non potrebbe impedire le interruzioni del sistema e le relative perdite di dati. La soluzione di IFM Infomaster, invece, integra DR con Business Continuity, tanto che l’eventuale passaggio dal server primario a quello secondario, a motivo di malfunzionamenti imprevisti, avviene senza che né l’operatore né il cliente si accorgano di nulla. Nel panorama dei software per Contact Center, questa caratteristica rappresenta un fattore di cui tenere seriamente conto. Poiché, infatti, la dinamica di relazione tra azienda e cliente oggi è sempre più focalizzata su dinamiche sofisticate di engagement e personalizzazione, una perdita dei dati ne sminuirebbe l’efficacia. Così come il venir meno dell’attività, ad esempio in presenza di un Contact Center inbound, si configurerebbe, agli occhi di chi non riesce a interloquire con alcun addetto anche per un breve lasso di tempo, quale sintomo di inaffidabilità del brand stesso.
Protezione di dati con il Disaster Recovery a prova di GDPR
Una considerazione finale va fatta in merito agli obblighi normativi introdotti dal Regolamento Ue 2016/679 o General Data Protection Regulation (GDPR) in materia di protezione e libera circolazione dei dati personali. L’articolo 32 del Regolamento dispone che sia assicurata «la capacità di ripristinare tempestivamente la disponibilità e l’accesso dei dati in caso di incidente fisico o tecnico». Qualsiasi software che gestisce schede anagrafiche e informazioni personali deve adeguarsi, compresi perciò i Contact Management System. Di conseguenza, oltre a valutazioni di ordine pratico e di efficienza, il Disaster Recovery (se non la Business Continuity) adesso è diventata una misura obbligatoria. Una ragione in più per scegliere #phones e il suo modulo Fault Tolerance visto che, prima ancora dell’entrata in vigore del GDPR, contemplava sia l’uno, ormai necessario per legge, sia l’altra.
