All’interno di un’azienda è normale trovare molti software differenti.
Un CRM per la parte commerciale, un gestionale per l’amministrazione, un sistema ticket per l’assistenza, una piattaforma cloud per i documenti, strumenti per il marketing, il sito web, magari un e-commerce e una serie di applicazioni verticali dedicate a funzioni specifiche.
A prima vista può sembrare che il problema sia avere troppi strumenti.
In realtà non è necessariamente così.
Un’azienda può utilizzare dieci sistemi differenti e avere un’infrastruttura molto efficiente, oppure utilizzarne tre e costringere le persone a passare continuamente dati da uno all’altro.
Il vero problema quindi non è quanti software vengono utilizzati.
È capire come comunicano.
OGNI SOFTWARE PUÒ FUNZIONARE BENE DA SOLO
Quando un’azienda sceglie un software, normalmente lo fa per risolvere un problema specifico.
Il CRM viene scelto perché gestisce bene clienti e opportunità commerciali.
Il gestionale amministrativo viene scelto perché gestisce fatture, contabilità e ordini.
Il ticketing viene scelto perché permette di organizzare le richieste di assistenza.
Il cloud viene utilizzato perché rende disponibili documenti e file.
Ognuno di questi sistemi può essere perfettamente adatto al proprio compito.
Il problema nasce quando un processo aziendale attraversa più di uno di questi strumenti.
Un nuovo cliente viene acquisito dal commerciale nel CRM.
Successivamente deve essere creato nel gestionale.
Deve essere predisposta una cartella documentale.
Può essere necessario aprire un progetto.
L’assistenza deve sapere che quel cliente esiste.
L’amministrazione deve conoscere condizioni economiche e riferimenti.
A quel punto la qualità del singolo software conta ancora, ma conta soprattutto il modo in cui le informazioni passano da un sistema all’altro.
QUANDO LE PERSONE DIVENTANO IL SISTEMA DI INTEGRAZIONE
Uno dei segnali più chiari di una infrastruttura frammentata è la presenza di persone che copiano continuamente informazioni.
Un dato viene esportato da un sistema e importato in un altro.
Un codice cliente viene riportato manualmente.
Un ordine viene copiato.
Una email viene inoltrata perché il destinatario non ha accesso allo strumento che contiene l’informazione.
Un foglio Excel viene utilizzato come punto di raccordo tra due reparti.
In questi casi le persone stanno svolgendo una funzione che dovrebbe essere affidata all’infrastruttura.
Questo non significa che ogni sistema debba essere collegato a tutti gli altri.
Significa che i passaggi ricorrenti, prevedibili e importanti dovrebbero essere progettati in modo da non dipendere dal copia e incolla.
Infatti ogni trasferimento manuale introduce tempo, possibilità di errore e soprattutto una dipendenza.
Se la persona che conosce quel passaggio non è disponibile, il processo può fermarsi.
IL PROBLEMA DEI DATI DUPLICATI
Quando i sistemi non comunicano, la stessa informazione finisce spesso per esistere in più punti.
Il nome del cliente è nel CRM.
È anche nel gestionale.
Può essere presente nel sistema ticket.
Compare in una cartella condivisa.
Magari esiste anche in un foglio Excel utilizzato da un reparto.
Finché l’informazione rimane identica, il problema non si vede.
Quando cambia, invece, bisogna capire quale versione sia quella corretta.
Un indirizzo viene aggiornato nel CRM ma non nel gestionale.
Una ragione sociale cambia.
Un referente lascia l’azienda.
Una condizione commerciale viene modificata.
Se ogni sistema contiene la propria copia, la qualità del dato dipende dalla capacità delle persone di ricordarsi dove effettuare tutti gli aggiornamenti.
Questo è uno dei motivi per cui, quando si progettano integrazioni, è importante stabilire quale sistema sia responsabile di una determinata informazione.
Non tutti devono essere la fonte principale di tutto.
UNA FONTE PRINCIPALE PER OGNI INFORMAZIONE
Un principio utile consiste nel definire una fonte principale per le informazioni più importanti.
Il CRM può essere il sistema di riferimento per contatti e opportunità.
L’ERP può esserlo per fatturazione e dati amministrativi.
Un sistema documentale può essere il riferimento per i file.
Il ticketing può esserlo per lo stato delle richieste di assistenza.
Questo non significa che un dato debba esistere solamente in un posto.
Può essere necessario renderlo disponibile anche altrove.
La differenza è che deve essere chiaro dove nasce e dove viene aggiornato.
Gli altri sistemi dovrebbero ricevere quella informazione attraverso un meccanismo controllato.
In questo modo, quando un dato cambia, non è necessario ricordarsi di modificarlo manualmente ovunque.
API, WEBHOOK E INTEGRAZIONI
Oggi moltissimi software mettono a disposizione strumenti che permettono di comunicare con altre applicazioni.
Le API consentono a un sistema di leggere o scrivere informazioni in un altro.
I webhook permettono di comunicare che è avvenuto un determinato evento.
Un nuovo ordine può generare automaticamente una notifica.
La creazione di un cliente può avviare un’altra procedura.
La chiusura di un ticket può aggiornare un dato altrove.
Non è necessario che l’utente conosca tutti questi meccanismi tecnici.
Dal punto di vista aziendale il concetto è più semplice: quando succede qualcosa in un sistema, gli altri strumenti che devono saperlo dovrebbero ricevere l’informazione senza richiedere un passaggio manuale.
La tecnologia utilizzata per farlo può cambiare.
Il principio rimane lo stesso.
NON SERVE UN UNICO SOFTWARE PER FARE TUTTO
Quando un’azienda percepisce troppa frammentazione, una delle reazioni più comuni è cercare una piattaforma unica che faccia qualsiasi cosa.
L’idea è comprensibile.
Un solo sistema, un solo accesso, un unico database e tutto centralizzato.
In alcuni casi può essere una buona soluzione.
In altri rischia di creare un problema diverso.
Un software molto ampio può essere ottimo per alcune funzioni e mediocre per altre.
Può richiedere forti personalizzazioni.
Può aumentare la dipendenza da un unico fornitore.
Può costringere alcuni reparti ad adattarsi a strumenti meno adatti solamente per mantenere l’uniformità.
L’alternativa non è accettare il caos.
È costruire una architettura dove strumenti specializzati possano comunicare in modo ordinato.
In questo modo l’azienda può scegliere il software più adatto a ogni funzione senza trasformare ogni passaggio tra strumenti in un lavoro manuale.
UN PROCESSO NON DOVREBBE CONOSCERE I CONFINI DEI SOFTWARE
Dal punto di vista dell’utente, un processo aziendale dovrebbe essere il più continuo possibile.
La persona non dovrebbe necessariamente preoccuparsi del fatto che una parte dell’informazione si trovi nel CRM e un’altra nell’ERP.
Per fare un esempio, immaginiamo la trasformazione di una opportunità commerciale in un cliente operativo.
Il commerciale chiude l’opportunità.
Da quel momento possono essere necessarie diverse attività:
- creare il cliente nel gestionale;
- trasferire dati fiscali e amministrativi;
- creare la struttura documentale;
- notificare il reparto operativo;
- generare attività iniziali;
- predisporre eventuali accessi;
- rendere il cliente disponibile al sistema di assistenza.
Se ogni attività richiede un intervento separato, la chiusura commerciale è solamente l’inizio di una lunga sequenza manuale.
Se invece i sistemi sono integrati, quell’evento può diventare il punto di partenza di un processo coordinato.
Il commerciale continua a lavorare sul CRM.
L’amministrazione continua a usare il proprio gestionale.
L’assistenza continua a lavorare sul ticketing.
Ma l’infrastruttura si occupa di far circolare le informazioni necessarie.
INTEGRARE NON SIGNIFICA COLLEGARE TUTTO CON TUTTO
Anche le integrazioni possono diventare un problema se vengono costruite senza una logica.
Collegare ogni sistema direttamente a tutti gli altri crea rapidamente una rete difficile da comprendere e mantenere.
Se cambiamo un software, possiamo dover modificare numerosi collegamenti.
Se un dato viene aggiornato da più punti, possono nascere conflitti.
Per questo è importante progettare i flussi.
Quale sistema produce l’informazione?
Quale la utilizza?
Quando deve essere aggiornata?
Serve un aggiornamento immediato oppure è sufficiente una sincronizzazione periodica?
Che cosa succede se uno dei sistemi non risponde?
Come vengono registrati gli errori?
Queste domande trasformano una semplice connessione tecnica in una vera integrazione aziendale.
IDENTITÀ, ACCESSI E PERMESSI
Quando i sistemi comunicano tra loro, non bisogna considerare solamente i dati ma anche chi può utilizzarli.
Un’integrazione non dovrebbe diventare un modo per aggirare i permessi già esistenti.
Se un sistema può accedere a informazioni sensibili, è necessario capire quali dati può leggere, quali può modificare e per quale motivo.
Lo stesso principio diventa ancora più importante quando all’interno dell’infrastruttura vengono introdotti sistemi AI o agenti capaci di utilizzare strumenti.
La capacità tecnica di accedere a un dato non significa automaticamente che quel dato debba essere disponibile a qualsiasi processo.
Una buona architettura quindi collega i sistemi ma mantiene chiari i confini.
LE INTEGRAZIONI DEVONO ESSERE OSSERVABILI
Una integrazione che funziona non dovrebbe essere invisibile fino al giorno in cui smette di funzionare.
È necessario sapere se i flussi stanno lavorando correttamente.
Quante operazioni sono state eseguite?
Quante sono fallite?
Esistono dati rimasti in attesa?
Un sistema esterno non risponde?
Una informazione è stata rifiutata perché incompleta?
Questi elementi sono importanti perché un processo automatico può creare una falsa sensazione di sicurezza.
Se prima una persona copiava un ordine, almeno vedeva immediatamente il problema quando non riusciva a farlo.
Con una integrazione automatica, un errore non rilevato può rimanere nascosto.
Per questo log, controlli e notifiche fanno parte dell’integrazione tanto quanto il collegamento stesso.
QUANDO ARRIVA L’INTELLIGENZA ARTIFICIALE
Un’azienda con sistemi ben collegati è anche in una posizione molto migliore per utilizzare l’intelligenza artificiale.
Infatti un sistema AI isolato può elaborare solamente le informazioni che gli vengono fornite manualmente.
Un sistema AI inserito in una infrastruttura integrata può invece ricevere dati dai sistemi autorizzati, elaborarli e restituire il risultato al processo.
Può leggere una richiesta, trovare il cliente nel CRM, recuperare informazioni da un sistema documentale e preparare un’azione che verrà successivamente approvata.
Ma tutto questo funziona bene solamente se le integrazioni sottostanti sono affidabili.
L’AI non elimina il bisogno di architettura.
Lo rende ancora più evidente.
IL VALORE È NEL FLUSSO, NON NEL NUMERO DEGLI STRUMENTI
Avere molti software non significa necessariamente avere una infrastruttura complicata.
La complessità nasce quando ogni confine tra un sistema e l’altro diventa un passaggio manuale, ambiguo o fragile.
Un’azienda può continuare a utilizzare strumenti differenti, purché sia chiaro:
- quale sistema è responsabile di quale informazione;
- come i dati vengono trasferiti;
- quali processi devono essere sincronizzati;
- quali permessi devono essere rispettati;
- come vengono gestiti errori ed eccezioni.
Quando questi elementi sono progettati correttamente, i software smettono di essere isole e diventano componenti di un unico sistema aziendale.
Ed è a quel punto che la tecnologia comincia realmente a lavorare per l’organizzazione, invece di costringere l’organizzazione a lavorare per la tecnologia.