Quando conviene collegare il gestionale con un'API

Se il tuo gestionale fa bene il lavoro principale ma non comunica con uno strumento che ti serve, non devi per forza sostituirlo. Un'integrazione gestionale API può togliere un passaggio di copia e incolla e lasciare il sistema attuale al centro del lavoro. Prima di collegare due software, però, devi decidere quale contiene il dato corretto, quali informazioni devono passare e cosa succede quando il collegamento si interrompe.

Un'API è un passaggio con regole chiare

Un'API è il modo con cui un software chiede o consegna informazioni a un altro seguendo regole già definite. Puoi immaginarla come uno sportello: un programma presenta una richiesta in un formato concordato e l'altro risponde dicendo se può eseguirla e con quale risultato.

Questo collegamento non trasferisce automaticamente tutto quello che vedi sullo schermo. Qualcuno deve stabilire quali dati scambiare, quali operazioni sono permesse e come riconoscere una pratica già esistente. L'API è il mezzo; l'integrazione è il lavoro di decidere come usarlo dentro un processo reale.

Per capire se può bastare, segui una pratica dall'inizio alla fine. Se il gestionale segue bene quasi tutti i passaggi e ne manca uno soltanto, collegarlo può essere più semplice che cambiare sistema. Se invece ogni fase richiede un programma diverso, l'integrazione rischia di nascondere un problema più grande.

Quale sistema conserva il dato principale?

Il primo accordo riguarda il dato corretto. Non è necessario che esista un unico sistema principale per ogni cosa, ma ogni tipo di informazione deve avere un posto riconoscibile da cui partire.

Il gestionale può essere la fonte per clienti, ordini e contratti. Il sito può raccogliere una nuova richiesta, ma non dovrebbe diventare un secondo archivio del cliente. In un'attività ricettiva, invece, il calendario del booking engine o del gestionale può essere il riferimento per la disponibilità, mentre sito e portali ricevono l'aggiornamento. Nel booking engine per agriturismo ho descritto perché decidere quale calendario comanda viene prima di parlare di sincronizzazione.

Per ogni dato chiarisci quindi:

• quale sistema può crearlo;
• quale sistema può modificarlo;
• dove si controlla la versione corretta;
• cosa deve succedere quando viene archiviato o annullato.

Se due software possono cambiare liberamente lo stesso numero di telefono, lo stato di un ordine o la disponibilità di una camera, l'API non può stabilire da sola quale modifica tenere. Serve una regola prima del collegamento. Altrimenti avrai due schermi aggiornati, ma nessuna certezza su quale guardare.

Dati, direzione e momento del passaggio

La parola «sincronizzazione» è troppo generica per descrivere un progetto. Per ogni passaggio conviene seguire una pratica concreta e annotare cosa accade:

1. L'evento che fa partire il passaggio. Può essere un nuovo contatto, una prenotazione, un ordine o una modifica fatta da una persona.
2. I dati necessari. Passa soltanto ciò che serve al sistema che riceve l'informazione. Un secondo software non deve diventare una copia incompleta del gestionale.
3. La direzione. Chiarisci se il dato va dal gestionale verso l'altro strumento, se torna indietro o se le due cose succedono in momenti diversi.
4. Il risultato atteso. Decidi come capire che l'operazione è riuscita e dove vedere il suo stato.
5. L'identificativo della pratica. I due sistemi devono riconoscere lo stesso cliente, ordine o prenotazione anche dopo un aggiornamento.

Prendiamo un caso semplice: un modulo del sito raccoglie una richiesta e la invia al CRM. Il CRM dovrebbe creare un contatto o aggiornare quello già presente, e il team dovrebbe poter vedere se il passaggio è riuscito. Se dopo l'invio qualcuno deve controllare una casella email, copiare il testo e verificare a mano se il contatto esiste già, hai spostato il lavoro invece di ridurlo.

Lo stesso vale per un ordine. Se il gestionale deve restare la fonte principale, il sistema esterno può inviare il nuovo ordine e ricevere lo stato; non dovrebbe inventare un secondo stato che poi qualcuno deve confrontare ogni mattina.

Se l'API non risponde

Ogni collegamento può incontrare un problema: il servizio non risponde, i dati inviati non sono completi oppure la richiesta è arrivata ma la risposta si è persa. Il progetto deve dire cosa vede la persona che lavora e quale passo può fare dopo.

Un'integrazione gestibile dovrebbe almeno:

• mostrare se il passaggio è riuscito, è in attesa o richiede un controllo;
• riprovare soltanto le operazioni che si possono ripetere senza creare un duplicato;
• conservare il riferimento della singola operazione, così una nuova prova non sembra un ordine nuovo;
• avvisare una persona quando il problema non si risolve da solo;
• indicare come continuare il lavoro e come riallineare i dati in seguito.

«Riprova» non è una strategia sufficiente. Se il gestionale ha salvato un ordine ma il sistema che lo ha inviato non ha ricevuto la risposta, ripetere alla cieca può crearne un secondo. Se invece la disponibilità di una camera non viene aggiornata, qualcuno deve sapere quale calendario controllare prima di confermare un'altra prenotazione.

Per le attività con conseguenze concrete, può essere corretto fermare la conferma finché il sistema principale non ha registrato l'operazione. Per altre, come un aggiornamento non urgente, può bastare metterla in coda e avvisare il responsabile. Va deciso in base al lavoro che si bloccherebbe o proseguirebbe con un dato sbagliato.

Duplicati e aggiornamenti in conflitto

Un collegamento utile non crea un nuovo cliente ogni volta che riceve una richiesta. Deve riconoscere la scheda già esistente usando un identificativo stabile e sapere quando aggiornare un record invece di crearne uno.

Questo controllo diventa più delicato quando i dati esistono già in entrambi i sistemi. Lo stesso cliente può avere un nome scritto in modo diverso, un indirizzo vecchio o due schede create da persone diverse. Il software può segnalare che le informazioni si somigliano, ma nei casi dubbi dovrebbe lasciare la decisione a una persona invece di unire tutto automaticamente.

Stabilisci anche cosa succede quando i due sistemi contengono modifiche diverse. Puoi scegliere una fonte prioritaria, mettere il conflitto in una lista da controllare oppure impedire l'aggiornamento finché qualcuno non decide. L'importante è non sovrascrivere in silenzio un dato che potrebbe servire.

Prima di un nuovo gestionale questi controlli fanno parte della migrazione: nell'articolo su come migrare i dati senza fermare l'azienda trovi perché bisogna decidere chi risolve i conflitti e quali informazioni vale la pena portare. Anche quando mantieni il sistema attuale, la stessa responsabilità serve per il primo allineamento.

Quando collegare il gestionale e quando cambiarlo

Tieni il gestionale attuale e valuta un'integrazione quando il flusso principale è chiaro, il sistema contiene già i dati che ti servono e manca un collegamento circoscritto. Devono essere disponibili le informazioni e le operazioni necessarie, deve esserci una fonte principale e il team deve poter gestire le eccezioni senza aprire ogni volta una richiesta di assistenza.

Valuta la sostituzione quando il software non riesce a rappresentare il lavoro principale, non permette di leggere o aggiornare i dati indispensabili oppure costringe a mantenere più archivi per quasi ogni attività. In quel caso aggiungere collegamenti può rendere più difficile capire dove nasce un errore. Nell'articolo su quando cambiare gestionale aziendale trovi i controlli da fare prima di prendere quella strada.

La scelta può stare anche nel mezzo. Se usi un CRM standard e il processo funziona tranne che per un passaggio, puoi tenere il CRM e collegare un piccolo strumento dedicato. In quel caso parti dall'analisi descritta in CRM standard o su misura, prima di costruire un software nuovo.

Se vuoi capire se il tuo caso si risolve con un collegamento, il servizio di sviluppo di software, CRM e gestionali comincia dalla ricostruzione del flusso e dalla scelta dei dati da scambiare. Per iniziare bisogna stabilire quale sistema deve sapere cosa e chi interviene quando i sistemi non sono d'accordo.