Integrazione gestionale e-commerce: cosa si rompe davvero quando i due sistemi iniziano a parlarsi

Hai venduto tre pezzi che non hai. Il negozio online li mostrava disponibili, il magazzino li aveva finiti alle undici del mattino, e la telefonata al cliente la fai tu. Se ti è successo anche una sola volta, il problema non è il gestionale e non è l'e-commerce: è quello che c'è, o che non c'è, in mezzo.

In questo articolo trovi il conto vero di un'integrazione fra gestionale ed e-commerce. I quattro flussi che devono funzionare e cosa si rompe in ognuno. Le tre strade possibili con i prezzi che si pagano davvero in Italia, compresa la voce che non entra mai nei preventivi. Le otto domande da mettere per iscritto prima di chiedere un'offerta, perché un fornitore che ti fa un prezzo senza avertele fatte sta tirando a indovinare. E i quattro numeri con cui capisci, senza discussioni, se l'integrazione che hai sta reggendo o no.

Faccio software da ventisei anni e una buona metà di quel tempo l'ho passata sul confine fra due sistemi che dovevano parlarsi: gestionali e magazzini, impianti e sistemi di fabbrica, piattaforme che scambiavano dati con banche e clienti. Il posto dove i progetti falliscono quasi sempre non è dentro un sistema, è nello spazio fra due.

Una cosa la metto subito, perché è la premessa da cui discende tutto il resto: un'integrazione non è un travaso di dati, è un accordo permanente fra due sistemi che sono stati progettati senza sapere l'uno dell'altro. Un travaso si fa una volta e finisce. Un accordo va scritto, va fatto rispettare e va sorvegliato tutti i giorni, per anni. Chi lo tratta come un travaso paga la differenza in ordini persi, e la paga a rate.

Perché il gestionale e l'e-commerce non riescono a parlarsi da soli

Sembrano due sistemi che si occupano delle stesse cose: prodotti, prezzi, clienti, ordini. In realtà guardano gli stessi oggetti da due mondi diversi, e le parole che usano coincidono solo in apparenza.

Il gestionale ragiona per codici articolo, unità di misura, lotti, aliquote, magazzini fisici, listini legati al singolo cliente e condizioni di pagamento. È un sistema costruito per chiudere un bilancio: la sua ossessione è la coerenza contabile, e per quella è disposto a essere lento e rigido.

L'e-commerce ragiona per schede prodotto, varianti, fotografie, testi, categorie, carrelli, coupon e sessioni di navigazione. È un sistema costruito per far comprare: la sua ossessione è la velocità di risposta e la libertà di cambiare una vetrina in cinque minuti, e per quella è disposto a essere approssimativo sui dati.

Queste due ossessioni sono legittime tutte e due, e sono opposte. L'integrazione è il posto dove qualcuno deve decidere quale delle due vince, campo per campo. Se quella decisione non la prendi tu, la prendono i due software al posto tuo, e la prendono male.

Il problema dell'identità: che cos'è "lo stesso prodotto"

È la prima domanda e quella che costa di più se la si sbaglia, perché la si scopre due anni dopo quando ormai ci sono ottantamila righe di storico appese alla scelta sbagliata.

Prendi una camicia in tre taglie e quattro colori. Nel negozio online sono quasi sempre dodici cose vendibili distinte, ognuna con la sua giacenza e il suo codice a barre, raccolte sotto un'unica scheda con una fotografia e un testo. Nel gestionale possono essere dodici codici articolo separati, oppure un articolo solo con due dimensioni di variante, oppure, e succede più spesso di quanto pensi, un articolo unico dove taglia e colore stanno appiccicati dentro la descrizione perché quindici anni fa a nessuno serviva distinguerli.

Quel terzo caso è la trappola. Finché vendevi solo al banco, la commessa leggeva la descrizione e capiva. Un negozio online non legge le descrizioni: ha bisogno di un identificativo stabile per sapere se il pezzo che sta vendendo c'è o non c'è. E se quell'identificativo nel gestionale non esiste, l'integrazione non lo può inventare: qualcuno deve mettere mano all'anagrafica prima che si scriva una riga di codice.

La regola che uso: l'identificativo che tiene insieme i due mondi deve esistere nel gestionale, essere unico, non cambiare mai e non contenere niente che possa cambiare. Niente codici che incorporano il fornitore, l'anno o il reparto, perché il fornitore cambia e il codice no. Se un identificativo così non c'è, crearlo è il primo lavoro del progetto, e va fatto prima di tutto il resto.

Le tre differenze che sembrano dettagli e non lo sono

L'IVA. Il gestionale quasi sempre lavora a prezzi netti e applica l'aliquota in fattura. Il negozio online, se vende a privati in Italia, deve esporre il prezzo comprensivo di IVA. Fra i due c'è un arrotondamento, e l'arrotondamento non è commutativo: arrotondare il netto e poi applicare l'aliquota dà un risultato diverso dall'applicare l'aliquota e poi arrotondare. Su un ordine solo è un centesimo. Su diecimila ordini è una riga di quadratura che il commercialista non chiude, e qualcuno passerà tre giorni a capire perché.

Le unità di misura. Il gestionale vende cavo al metro e imballi da venticinque. Il negozio online vende pezzi. Se il fattore di conversione non è scritto da qualche parte in modo esplicito, viene messo nel codice dell'integrazione come numero fisso, e il giorno che l'imballo diventa da trenta nessuno se lo ricorda.

I decimali. Il gestionale tiene i prezzi con quattro cifre decimali, il negozio con due. È un dettaglio innocuo finché non moltiplichi per una quantità: quattro pezzi a 3,3325 fanno 13,33, ma quattro pezzi a 3,33 fanno 13,32. Un centesimo, di nuovo, e di nuovo su ogni riga.

La decisione che vale metà del progetto: chi è il padrone di ogni campo

Prima di scegliere una tecnologia, prima di chiedere un preventivo, prendi un foglio e fai una tabella con tre colonne: il campo, il sistema che comanda, cosa succede se l'altro lo cambia.

Il codice prodotto comanda il gestionale. La giacenza comanda il gestionale. Il prezzo di listino comanda il gestionale. La fotografia, il testo di vendita, la categoria di navigazione e le parole chiave comandano il negozio, perché sono cose che il gestionale non sa nemmeno rappresentare. L'anagrafica del cliente è quella interessante: nasce nel negozio, perché è lì che il cliente si registra, ma dal momento in cui ha una partita IVA e una fattura addosso comanda il gestionale, e ogni modifica successiva deve tornare indietro.

La colonna che quasi nessuno compila è la terza, e senza quella la tabella non serve. Se un operatore corregge un prezzo direttamente nel negozio online, cosa succede? Le risposte accettabili sono due: la modifica viene sovrascritta al prossimo allineamento e chi l'ha fatta lo sa, oppure la modifica non è tecnicamente possibile perché il campo è bloccato. La risposta inaccettabile, che è quella che si trova nella maggior parte delle installazioni, è "dipende", perché "dipende" significa che ogni tanto vince uno e ogni tanto l'altro, e nessuno riesce più a capire quale prezzo è quello giusto.

Questa tabella è anche il documento che ti fa risparmiare di più in fase di offerta: un fornitore che la riceve compilata ti fa un preventivo serio, e uno che la riceve compilata e ti fa lo stesso un preventivo generico si è appena qualificato da solo.

I quattro flussi che devono funzionare: giacenze, anagrafiche, ordini, documenti

Ogni integrazione fra gestionale ed e-commerce, indipendentemente dai marchi in gioco, è fatta di quattro flussi. Hanno direzioni diverse, frequenze diverse e modi diversi di rompersi, e trattarli come una cosa sola è il primo errore di progetto.

1. Le giacenze: dal gestionale al negozio, il più delicato di tutti

Va in una direzione sola e riguarda un numero solo per articolo, quindi sembra il più semplice. È il contrario: è quello che genera le telefonate arrabbiate, perché è l'unico che si manifesta direttamente davanti al cliente.

La quantità che mandi al negozio non è quasi mai la quantità che il gestionale ha in magazzino. È la disponibilità vendibile, e per calcolarla devi togliere quello che è già impegnato da ordini non ancora evasi, escludere i magazzini che non servono il canale online, decidere se contare la merce in arrivo dal fornitore, e sottrarre l'eventuale scorta di sicurezza. Ognuna di queste quattro sottrazioni è una decisione di business, non una scelta tecnica, e va presa da chi risponde del fatturato.

La domanda che chiude il flusso è cosa succede quando la disponibilità arriva a zero. Il prodotto sparisce dal catalogo, resta visibile come esaurito, o accetta l'ordine come prevendita? Sono tre comportamenti diversi con tre conseguenze diverse sul posizionamento della pagina, e vanno decisi per famiglia di prodotto, non per l'intero catalogo.

2. Le anagrafiche e i prezzi: dal gestionale al negozio, ma non tutto

Qui l'errore tipico è l'eccesso di zelo: si porta al negozio tutto quello che il gestionale ha, e ci si ritrova una vetrina piena di articoli tecnici, ricambi, imballi e voci di servizio che non dovrebbero essere in vendita.

Serve un interruttore esplicito nel gestionale, un campo che dice "questo articolo si vende online", e serve che quel campo sia l'unico criterio. Le alternative che vedo di solito, filtrare per categoria merceologica o per presenza della fotografia, funzionano finché qualcuno non crea una categoria nuova, e poi smettono senza avvisare.

Sui prezzi la complicazione italiana è quella dei listini. Un'azienda che vende sia ai negozi sia ai privati ha listini diversi, sconti per cliente e condizioni particolari, e il negozio online ne rappresenta uno solo. Se domani vuoi anche un'area riservata per i rivenditori con i loro prezzi, il modo in cui hai scritto questo flusso decide se è una settimana di lavoro o due mesi. Vale la pena tenerne conto adesso anche se non lo fai adesso.

3. Gli ordini: dal negozio al gestionale, dove nessuna riga può andare persa

È il flusso in cui un errore non si può recuperare rileggendo il dato più tardi, perché il dato è un fatto che è successo una volta sola: qualcuno ha pagato.

Il momento in cui l'ordine passa al gestionale va scelto e non subito. Passarlo appena il carrello viene confermato riempie il gestionale di ordini che non saranno mai pagati. Passarlo solo a pagamento incassato è più pulito ma ritarda la logistica sui pagamenti lenti, e con il bonifico anticipato può voler dire due giorni. La scelta ragionevole nella maggior parte dei casi è passarlo alla conferma con lo stato di pagamento esplicito, e lasciare che sia il gestionale a decidere quando si può spedire.

Poi c'è la parte fiscale, che in Italia è la fonte di metà degli ordini bloccati. Un cliente privato ha bisogno del codice fiscale se chiede la fattura, un cliente con partita IVA ha bisogno del codice destinatario o della PEC per la fattura elettronica, un cliente estero ha bisogno di regole ancora diverse. Se il negozio online non raccoglie questi dati nel momento giusto, l'ordine arriva nel gestionale e si ferma lì, e qualcuno dovrà telefonare. Il posto giusto dove risolvere questo problema è la pagina del carrello, non l'integrazione.

4. I documenti e gli stati: dal gestionale al negozio, il flusso che riduce le telefonate

Quando il magazzino prepara il pacco, quando il corriere lo prende in carico, quando la fattura viene emessa, il cliente deve vederlo nella sua area senza chiamare nessuno.

È il flusso che di solito viene rimandato alla seconda fase, e ha una sua logica perché non blocca le vendite. Ha però l'effetto economico più immediato e più facile da misurare di tutti: ogni stato che il cliente vede da solo è una telefonata che non arriva al centralino. Su un negozio che fa cinquanta ordini al giorno sono diverse ore di lavoro alla settimana, tutte le settimane.

Perché vendi quello che non hai: la finestra di scoperto

Il caso in apertura, i tre pezzi venduti e non disponibili, non è sfortuna. È aritmetica, ed è prevedibile con un conto che si fa in due minuti.

Se le giacenze si allineano ogni quindici minuti, esiste una finestra di quindici minuti in cui il negozio mostra un numero vecchio. Se in quella finestra qualcuno svuota lo scaffale, vendi merce che non c'è. Quanto spesso succede dipende solo da quanto velocemente si muove quell'articolo.

Un articolo che vende dieci pezzi al giorno non ti darà mai problemi: la probabilità che due ordini cadano nella stessa finestra sull'ultimo pezzo rimasto è trascurabile. Lo stesso identico meccanismo, su un articolo in promozione che vende quaranta pezzi all'ora, produce dieci ordini per finestra, e quando la disponibilità reale scende sotto dieci lo scoperto è certo. Il rischio non è distribuito sul catalogo: è concentrato su pochi articoli, quelli veloci, e cresce proprio nei giorni in cui hai più traffico.

Questa osservazione ha una conseguenza pratica che fa risparmiare parecchi soldi: non serve rendere istantaneo l'allineamento di tutto il catalogo. Serve renderlo istantaneo per la coda veloce, che nella maggior parte dei cataloghi è fra il due e il cinque per cento degli articoli.

Le tre difese, in ordine di quanto costano

La spinta al posto dell'interrogazione. Invece di chiedere al gestionale ogni quindici minuti come stanno le cose, si fa in modo che sia il gestionale ad annunciare ogni movimento di magazzino nel momento in cui avviene. La finestra passa da quindici minuti a qualche secondo. Tecnicamente è la soluzione migliore e costa poco, a una condizione: che il gestionale sia in grado di annunciare qualcosa. I gestionali moderni hanno un modo per farlo, quelli più vecchi spesso no, e allora si ripiega su una lettura frequente della tabella dei movimenti, che è meno elegante e funziona comunque.

La scorta di sicurezza. Si dichiara al negozio due pezzi in meno di quelli reali. Costa zero da implementare e ti fa perdere vendite quando i pezzi rimasti sono pochi, quindi va applicata per classe di rotazione e non su tutto: buffer sugli articoli veloci, dove protegge davvero, nessun buffer sulla coda lenta, dove ti farebbe solo perdere l'ultimo pezzo di ogni taglia.

L'impegno al carrello. Il pezzo viene messo da parte nel momento in cui entra nel carrello e liberato se l'ordine non si conclude entro un tempo stabilito. È la difesa più efficace ed è anche la più costosa, perché richiede uno stato condiviso fra i due sistemi e una gestione delle scadenze che va sorvegliata. Ha senso quando il valore unitario è alto o i pezzi sono unici, come nell'usato o nel collezionismo, dove vendere due volte lo stesso oggetto non è un disguido ma un rimborso.

Nella maggior parte dei progetti la combinazione giusta è la prima più la seconda applicata bene. La terza si aggiunge dopo, e solo se i numeri dicono che serve.

Le tre strade per collegarli, con i prezzi che si pagano davvero

Le possibilità sono tre. Non c'è una migliore in assoluto: c'è quella giusta per quante eccezioni ha la tua azienda, e le eccezioni si contano prima di scegliere.

Il connettore pronto

Esiste già, lo installi, lo configuri, funziona. Vale per gli accoppiamenti diffusi: i gestionali più venduti in Italia hanno moduli per le piattaforme di negozio più diffuse, e sul mercato ci sono estensioni che coprono le combinazioni più frequenti.

Il costo tipico è fra zero e tremila euro di attivazione, più un canone che va dai trenta ai centocinquanta euro al mese. I tempi sono di giorni, non di settimane.

La condizione è una sola e non è negoziabile: devi accettare il modello di dati che il connettore ha deciso. Se il tuo modo di gestire le varianti coincide, sei a posto e hai speso il minimo possibile. Se hai una regola tua, per esempio uno sconto che dipende dalla quantità a scaglioni o una disponibilità che deve considerare due magazzini con priorità diverse, il connettore non la sa fare e non la imparerà. A quel punto la scelta è cambiare il processo aziendale per adattarlo al connettore, che qualche volta è la risposta giusta, oppure cambiare strada.

Il middleware

Uno strumento intermedio dove i flussi si disegnano invece di programmarli: si collegano i due sistemi, si mappano i campi, si impostano le trasformazioni.

Il costo tipico è fra quattromila e diecimila euro di impostazione iniziale, più un canone fra i duecento e gli ottocento euro al mese che quasi sempre cresce con il numero di operazioni. I tempi sono di qualche settimana.

È la scelta giusta quando i sistemi da collegare sono più di due, e succede più spesso di quanto sembri: gestionale, negozio, un marketplace, il corriere, la piattaforma delle email. Il vantaggio vero è che una modifica alla mappatura la può fare una persona che non programma. Lo svantaggio, che si sente al terzo anno, è che la logica di funzionamento della tua azienda finisce dentro uno strumento che non è tuo, in un formato che non puoi portare via, e il canone cresce esattamente quando cresci tu.

L'integrazione su misura

Codice scritto per te, che gira dove decidi, che fa esattamente quello che serve.

Il costo tipico di una prima versione seria è fra i dodicimila e i trentacinquemila euro, in quattro-dieci settimane, più un costo di esercizio che sta fra i centocinquanta e i quattrocento euro al mese fra infrastruttura e sorveglianza. La forbice è larga perché dipende quasi tutta da una cosa sola: quanto è civile il modo in cui il gestionale espone i suoi dati. Un gestionale con un'interfaccia documentata sta nella parte bassa. Un gestionale che si legge solo andando a leggere le sue tabelle sta nella parte alta, e ci sono casi in cui la parte più costosa del progetto è capire cosa significano quelle tabelle.

Ha senso quando le regole sono tue e sono il tuo margine. Se il modo in cui calcoli la disponibilità o applichi gli sconti è una parte di come guadagni, quella logica non può stare in uno strumento generico, perché uno strumento generico ti costringe a diventare generico. Su questo tema ho scritto il conto completo in gestionale aziendale, quando il pacchetto basta e quando ti serve su misura, e il ragionamento è lo stesso: sotto una certa soglia di eccezioni il pacchetto vince sempre, sopra quella soglia perde sempre.

La regola per scegliere, in tre righe

Conta le eccezioni: le regole che la tua azienda applica e che un negozio qualunque non applicherebbe.

Da zero a due eccezioni, connettore pronto, e resisti alla tentazione di fare di più. Da tre a otto eccezioni, o se i sistemi da collegare sono più di due, middleware. Più di otto, oppure meno ma di quelle che riguardano direttamente il margine, integrazione su misura.

C'è un caso in cui questa regola non vale ed è quello del gestionale che non è collegabile in nessun modo ragionevole, perché è vecchio e chiuso. Lì la domanda non è più quale integrazione fare: è se ha ancora senso tenere in piedi quel gestionale, e la risposta la trovi in modernizzazione del software legacy.

Quanto costa davvero, con la voce che nessuno mette nel preventivo

Il prezzo che vedi in offerta è il costo per arrivare al primo giorno di funzionamento. Il costo del progetto è un'altra cosa, e si vede sui tre anni.

Su tre anni, un connettore pronto sta fra i tremila e gli ottomila euro tutto compreso. Un middleware sta fra i quindicimila e i trentacinquemila, e la variabilità è quasi tutta nel canone che cresce con i volumi. Un'integrazione su misura sta fra i venticinquemila e i cinquantamila, con la parte grande concentrata all'inizio e un esercizio che poi resta piatto.

Detto in un altro modo: al primo giorno il su misura costa da quattro a dieci volte il connettore, sui tre anni ne costa da tre a sei, e su cinque anni la distanza continua a chiudersi perché il canone di un connettore non smette mai mentre lo sviluppo finisce. Non è un argomento per scegliere il su misura: è un argomento per non decidere guardando solo la prima cifra.

La voce che manca in tutti i preventivi che ho visto

Un'integrazione va tenuta viva, e tenerla viva costa fra il quindici e il venticinque per cento all'anno di quello che è costato costruirla. Se hai speso ventimila euro, la manutenzione ordinaria è fra i tremila e i cinquemila euro l'anno. Non sono guasti: sono i lavori che l'ambiente ti impone senza chiedertelo.

Le piattaforme di negozio cambiano le loro interfacce di continuo e mandano in pensione le versioni vecchie con un preavviso di mesi. Il gestionale si aggiorna e qualcosa si sposta. Cambia un corriere. Arriva una regola fiscale nuova. Si aggiunge un marketplace. Il catalogo raddoppia e quello che andava bene con cinquemila articoli non va più bene con dodicimila.

La conseguenza pratica è che un'integrazione senza un budget annuale dichiarato e senza una persona che ne risponde è un progetto già fallito, solo che non lo sa ancora. Il momento in cui lo scopre è sempre lo stesso: la settimana di massimo traffico dell'anno.

Le due voci che non sono nel preventivo perché non le paghi al fornitore

La prima è la pulizia dell'anagrafica. Nella maggior parte dei progetti reali è la parte più lunga e la paghi in ore dei tuoi, non in fattura: codici doppi, articoli senza codice a barre, descrizioni che contengono informazioni che dovrebbero essere campi, prezzi mai aggiornati. Un fornitore serio te lo dice all'inizio, uno che vuole solo chiudere ti dice che si sistema strada facendo. Non si sistema strada facendo.

La seconda è il tempo delle persone durante il passaggio. Per qualche settimana chi fa magazzino e chi fa amministrazione lavorerà con due sistemi da controllare invece di uno, e questo tempo va messo in conto quando si sceglie il periodo dell'anno in cui fare il lavoro. Non si fa a novembre.

La sincronizzazione non è un travaso: le cinque regole che decidono se regge

Questa parte è tecnica e la trovi qui perché è quella che distingue un'integrazione che dura da una che va rifatta dopo diciotto mesi. Se il lavoro lo fa qualcun altro, sono le cinque cose da chiedere in fase di offerta: le risposte ti dicono con chi hai a che fare meglio di qualunque presentazione.

1. Lo stesso messaggio due volte non deve fare danni

Le reti perdono le risposte. Un sistema riceve un ordine, lo salva, e mentre risponde "fatto" la connessione cade: chi ha mandato il messaggio non sa se è arrivato e riprova. Se il ricevente non è attrezzato, in magazzino compaiono due ordini identici e qualcuno spedisce due pacchi.

La difesa è banale e va messa fin dal primo giorno: ogni messaggio porta un identificativo stabile deciso da chi lo manda, e chi riceve tiene un vincolo di unicità su quell'identificativo. Il secondo arrivo non viene lavorato, viene riconosciuto.

public sealed record OrdineInArrivo(
    string IdEsterno, string Cliente, decimal Totale, DateTime QuandoUtc);

public enum Esito { Registrato, GiaVisto }

public static async Task<Esito> RegistraAsync(
    DbConnection db, OrdineInArrivo ordine, CancellationToken ct)
{
    // Il vincolo di unicità su IdEsterno è nel database: è il database
    // a garantire che due arrivi contemporanei non creino due ordini.
    const string sql = """
        INSERT INTO OrdiniRicevuti (IdEsterno, Cliente, Totale, QuandoUtc)
        VALUES (@IdEsterno, @Cliente, @Totale, @QuandoUtc)
        """;

    try
    {
        await using var cmd = db.CreateCommand();
        cmd.CommandText = sql;
        Aggiungi(cmd, "@IdEsterno", ordine.IdEsterno);
        Aggiungi(cmd, "@Cliente", ordine.Cliente);
        Aggiungi(cmd, "@Totale", ordine.Totale);
        Aggiungi(cmd, "@QuandoUtc", ordine.QuandoUtc);
        await cmd.ExecuteNonQueryAsync(ct);
        return Esito.Registrato;
    }
    catch (DbException e) when (ViolaUnicita(e))
    {
        // Non è un errore: è la rete che ha riprovato. Si risponde ok.
        return Esito.GiaVisto;
    }
}

La riga che conta è l'ultima. Un doppio arrivo non è un errore da segnalare, è il funzionamento normale di una rete, e va risposto con un ok. Le integrazioni che riempiono la casella di posta di allarmi per questo motivo finiscono con nessuno che legge più gli allarmi, ed è così che passano inosservati quelli veri.

2. Non si chiama l'altro sistema mentre il cliente sta pagando

La tentazione, quando l'ordine viene confermato, è di mandarlo subito al gestionale e aspettare la conferma. È l'errore che fa cadere il negozio ogni volta che il gestionale è lento, ed è il caso peggiore possibile: il cliente ha pagato e vede una pagina di errore.

Quello che va fatto è scrivere l'ordine in una coda nella stessa transazione in cui lo si salva, e rispondere subito al cliente. Un processo separato prende dalla coda e consegna al gestionale, con ritentativi a distanza crescente, e quello che non passa dopo un certo numero di tentativi finisce in un raccoglitore di scarti che una persona guarda tutti i giorni.

La proprietà che ti compri con questa struttura è quella che conta davvero: il gestionale può stare fermo tre ore, per un aggiornamento o per un guasto, e il negozio continua a vendere. Quando torna, la coda si svuota da sola nell'ordine giusto. Senza questa struttura, ogni fermo del gestionale è un fermo delle vendite.

3. L'ordine dei messaggi conta, ma solo dentro lo stesso oggetto

Se per lo stesso articolo arrivano due aggiornamenti di giacenza, prima dodici e poi otto, e vengono lavorati al contrario, il negozio resta a dodici e vende quello che non c'è.

Garantire l'ordine globale di tutti i messaggi costerebbe la possibilità di lavorare in parallelo, che è quello che ti serve nei giorni di punta. La soluzione è garantire l'ordine solo dove serve, cioè dentro il singolo articolo: si usa il codice articolo come chiave di ripartizione, e articoli diversi procedono in parallelo mentre lo stesso articolo procede sempre in fila. In alternativa, ogni messaggio porta un numero di versione crescente e chi riceve scarta quelli più vecchi di ciò che ha già.

4. La riconciliazione notturna: la rete di sicurezza che quasi nessuno mette

Per quanto bene sia fatto, un sistema che scambia messaggi in continuazione prima o poi va fuori allineamento su qualcosa. Un messaggio scartato per un formato imprevisto, una modifica fatta a mano da qualcuno, un aggiornamento andato male.

Serve un lavoro notturno che confronta i due sistemi articolo per articolo e produce l'elenco delle differenze. La regola importante è che quel lavoro non deve correggere in silenzio: deve dire cosa non torna. Un'integrazione che si aggiusta da sola senza dirlo nasconde il problema di fondo, e la differenza cresce sotto il tappeto finché non diventa una discussione con il commercialista.

Nella pratica: il rapporto notturno arriva per posta, se le differenze sono zero è una riga sola, e chi lo riceve impara a preoccuparsi quando ne vede due.

5. Il registro: trenta secondi per rispondere al cliente arrabbiato

Ogni scambio va registrato con un identificativo che lo lega a tutti gli altri passaggi dello stesso ordine, con l'ora, il contenuto e l'esito. Occupa spazio e sembra sovrabbondante finché non arriva la telefonata sull'ordine numero 4821 che il cliente dice di aver fatto e voi dite di non aver ricevuto.

Con il registro, la risposta si dà in trenta secondi e con una data precisa. Senza, si passa mezza giornata a incrociare i due sistemi, e comunque non si saprà mai cosa è successo davvero.

Le otto domande da mettere per iscritto prima di chiedere un preventivo

Questo è il capitolato in una pagina. Non serve un documento da quaranta pagine e non serve un consulente per scriverlo: servono otto risposte, e chi le ha scritte compra molto meglio di chi non le ha.

Uno. Chi comanda su ogni campo. La tabella della prima sezione: campo, sistema padrone, cosa succede se l'altro lo modifica. È la domanda numero uno perché tutte le altre ne dipendono.

Due. Che cos'è un prodotto vendibile. Come si chiama nel gestionale, come si chiama nel negozio, chi lo crea per primo, e cosa succede quando ne nasce uno nuovo: appare da solo o serve un'approvazione.

Tre. Come si calcola la disponibilità. Quali magazzini contano, se si sottrae l'impegnato, se si conta la merce in arrivo, quanta scorta di sicurezza e su quali articoli, e cosa fa il negozio quando la disponibilità è zero.

Quattro. Quale prezzo vede il cliente. Quale listino, IVA inclusa o esclusa e con quale arrotondamento, come si comportano le promozioni del negozio rispetto agli sconti del gestionale, e chi vince se i due non sono d'accordo.

Cinque. Il ciclo di vita dell'ordine. In che momento passa al gestionale, con quali stati, cosa succede a un pagamento non riuscito, a un annullamento, a un reso, a una spedizione parziale. I resi sono la parte che viene dimenticata nel novanta per cento dei casi ed è quella che genera le note di credito.

Sei. I dati fiscali. Cosa raccoglie il negozio per un privato, per un'azienda, per un cliente estero, e cosa succede quando manca qualcosa: l'ordine si blocca, passa lo stesso e qualcuno chiama, o non si può nemmeno concludere.

Sette. I numeri veri. Quanti articoli, quanti ordini nel giorno peggiore dell'anno e non nel giorno medio, quanti movimenti di magazzino all'ora nei momenti di punta. Un'integrazione che regge cinquanta ordini al giorno e una che ne regge cinquecento nell'ora di picco del Black Friday non sono lo stesso lavoro, e il prezzo lo dicono questi numeri.

Otto. Cosa succede quando l'altro non risponde. Per quanto tempo si accumula, chi viene avvisato e come, dopo quanto si smette di riprovare, e chi guarda gli scarti. È la domanda che separa i fornitori che hanno già fatto questo lavoro da quelli che lo stanno per fare per la prima volta a tue spese.

Se mandi queste otto risposte a tre fornitori e ricevi tre preventivi con una forbice del venti per cento, hai comprato bene. Se la forbice è del duecento per cento, i tre stanno leggendo tre lavori diversi, e la prima cosa da fare è capire perché prima di guardare i prezzi.

I quattro errori che ho visto costare di più

Sincronizzare tutto tutte le notti

È la prima cosa che viene in mente e funziona benissimo con tremila articoli. A ottantamila articoli il lavoro notturno inizia a mezzanotte e finisce alle sei, occupa il gestionale per tutta la notte, e il giorno che va storto qualcosa a metà lascia i due sistemi in uno stato che nessuno sa descrivere.

La cosa giusta è mandare solo quello che è cambiato, appoggiandosi a un segno del tempo di ultima modifica o alla tabella dei movimenti, e tenere il confronto completo come verifica notturna in sola lettura. Il risultato è che il lavoro notturno dura minuti, e le differenze vengono segnalate invece che riscritte.

Lasciare due padroni sullo stesso campo

Il prezzo si può cambiare nel gestionale e anche nel negozio. Nessuno ha deciso chi vince. Per qualche mese non succede niente, poi qualcuno fa una promozione modificando il negozio, l'allineamento della notte la sovrascrive, il giorno dopo la rifà, e nel frattempo trenta clienti hanno comprato a un prezzo che nessuno voleva.

Non esiste una soluzione tecnica a questo problema, perché non è un problema tecnico. Si decide chi comanda, si blocca il campo dove non comanda, e si dà a chi fa le promozioni uno strumento nel sistema giusto. Il campo bloccato è la parte che dà fastidio ed è la parte che risolve.

Nessuno guarda quando si rompe

L'integrazione ha smesso di funzionare l'undici del mese. Se ne sono accorti il ventidue, perché un cliente ha chiamato. Undici giorni di giacenze ferme e ordini che si accumulavano da qualche parte.

Il difetto qui non è nel codice: è che il monitoraggio, se c'è, dice che il servizio è acceso. Un servizio acceso che non sta lavorando niente sembra sano. Il controllo giusto guarda il lavoro, non il processo: quanti messaggi ho consegnato nell'ultima ora, e se sono zero in un orario in cui non dovrebbero esserlo, qualcuno viene avvisato. È la differenza fra chiedere "il motore è acceso" e chiedere "ci siamo mossi".

Trattarla come un progetto che finisce

Si va in produzione, si fa il collaudo, si chiude il progetto, il fornitore saluta. Non c'è un responsabile, non c'è un budget annuale, non c'è nessuno che legga i rapporti. Dopo otto mesi la piattaforma del negozio dismette la versione dell'interfaccia che stavate usando, e la scoperta avviene nel modo peggiore.

Un'integrazione è un pezzo di infrastruttura, come la connettività o il backup. Serve un nome, un numero di ore al mese e un rapporto che qualcuno legge. Il modo di ragionare è lo stesso che ho descritto in software come asset: una cosa che produce valore ogni giorno va mantenuta, non consumata.

Come capisci se funziona: quattro numeri, non una sensazione

"Va bene" e "ogni tanto dà problemi" non sono misure e non permettono di decidere niente. Questi quattro numeri sì, si ricavano tutti dai dati che hai già, e stanno in un rapporto settimanale di mezza pagina.

Il ritardo mediano di allineamento delle giacenze. Quanto tempo passa fra il movimento in magazzino e il numero aggiornato nel negozio. Sotto i cinque minuti sugli articoli veloci è un buon obiettivo. Guarda la mediana e non la media, perché la media la sporca un caso isolato e ti fa guardare dalla parte sbagliata.

La percentuale di ordini rimasti indietro. Quanti ordini hanno impiegato più di quindici minuti ad arrivare nel gestionale. Sopra lo zero virgola cinque per cento c'è qualcosa da guardare: di solito è la coda che si accumula in una fascia oraria precisa, e questo dato ti dice quale.

Lo scarto della riconciliazione notturna. Quanti articoli hanno una giacenza diversa fra i due sistemi. L'obiettivo è zero e va preteso: uno solo, ripetuto per tre notti, è sempre l'inizio di qualcosa.

Gli scoperti ogni mille ordini. Quante volte hai venduto merce che non c'era. È il numero che vede il cliente, quindi è quello che conta di più, e sotto i due su mille l'integrazione sta facendo il suo lavoro.

Se nessuno di questi quattro numeri esiste nella tua azienda, non è che l'integrazione va male: è che nessuno lo sa, e la prima cosa da fare non è cambiarla ma iniziare a misurarla. Misurare costa qualche giorno di lavoro e cambia il tono di tutte le conversazioni successive, comprese quelle con il fornitore.

Da dove partire senza fermare il negozio

Se stai leggendo con in mente un negozio che vende già e un gestionale che gira già, l'ordine dei lavori conta quanto i lavori stessi. Questo è quello che seguo io.

Prima il rapporto in sola lettura. Due o tre giorni di lavoro per un programma che legge i due sistemi e produce l'elenco delle differenze: articoli presenti in uno e non nell'altro, giacenze diverse, prezzi diversi, codici doppi. Non scrive niente, quindi non può rompere niente. Serve a due cose: sapere quanto è grave la situazione, e avere un numero di partenza da confrontare con quello di dopo. Nella metà dei casi questo rapporto cambia anche il progetto, perché mostra che il problema non era dove si pensava.

Poi le giacenze, in una direzione sola. È il flusso con il ritorno più immediato e il rischio più basso, perché va dal gestionale al negozio e non tocca niente di contabile. Quando funziona, gli scoperti crollano e si è comprato credito per il resto del lavoro.

Poi gli ordini, prima in prova. Per una settimana l'integrazione riceve gli ordini veri e li registra senza consegnarli al gestionale, mentre le persone continuano a lavorare come prima. Alla fine della settimana si confronta quello che avrebbe fatto con quello che è stato fatto a mano. Le differenze sono la lista dei casi che nessuno aveva raccontato, e c'è sempre.

Poi il resto, e solo se serve. Documenti, stati di spedizione, resi. Sono le cose che riducono le telefonate e migliorano l'esperienza, ma nessuna di loro fa perdere una vendita se manca ancora per un mese.

Quello che non va fatto per primo è la fattura, che è la parte più delicata dal punto di vista fiscale e la meno urgente da automatizzare, e qualunque cosa che tocchi contemporaneamente i due sistemi in scrittura. Si parte sempre dal flusso che è già rotto e che si vede da fuori, non dal flusso che è più elegante da costruire.

Sul dimensionamento di chi fa questo lavoro, se internamente o fuori, il conto l'ho fatto in quanto costa un team di sviluppo .NET. E se l'integrazione ti sta portando anche a spostare qualcosa in cloud, in Azure per le PMI italiane ci sono i numeri per non trovarti una bolletta a sorpresa: una coda e un processo che consuma non costano quasi niente se sono dimensionati bene, e costano parecchio se sono lasciati accesi a caso.

Il punto, in breve

Collegare un gestionale e un e-commerce non è un problema di tecnologia: le tecnologie per farlo ci sono tutte e sono mature. È un problema di decisioni prese o non prese, e le decisioni sono sempre le stesse quattro: chi comanda su ogni campo, che cosa è un prodotto, come si calcola la disponibilità, cosa succede quando l'altro sistema non risponde.

Chi prende quelle quattro decisioni prima di scegliere lo strumento compra bene qualunque strumento scelga. Chi le rimanda si ritrova a farle prendere dal software, che le prenderà nel modo più comodo per sé e non per l'azienda.

La scelta fra connettore pronto, middleware e su misura si fa contando le eccezioni, non guardando i prezzi: se le tue regole sono quelle di tutti, paga il meno possibile e passa ad altro; se le tue regole sono il tuo margine, non metterle dentro uno strumento che non è tuo.

E l'ultima cosa, che è quella che vedo saltare più spesso: un'integrazione non finisce il giorno che va in produzione. Costa il venti per cento all'anno per restare viva, ha bisogno di un nome che ne risponde e di quattro numeri guardati una volta alla settimana. Se non li hai, non hai un'integrazione: hai una cosa che sta funzionando finché dura.