Cambio di partner ERP: il metodo di subentro, illustrato con Business Central

Che si tratti di SAP, di Sage X3 o di Business Central, il subentro di un nuovo integratore in un progetto ERP segue quasi sempre lo stesso copione. Il sistema funziona, più o meno, ma la conoscenza di ciò che è stato costruito se n'è andata con il team precedente. Bisogna recuperarla, compreso ciò che non è mai stato scritto, senza interrompere la fatturazione, gli acquisti né la chiusura del mese. I motivi del cambio variano: rapporto deteriorato, partner acquisito, consulente chiave dimissionario, oppure la scelta di riportare in azienda una parte della manutenzione.

Un progetto Business Central permette di illustrare ciascuna di queste difficoltà. Un lunedì mattina, il nuovo partner apre l'interfaccia di amministrazione. Vi trova tre ambienti sandbox di cui nessuno conosce l'uso, un'estensione sviluppata per il cliente senza codice sorgente disponibile e un accesso amministrativo delegato che scade tra dieci giorni. Il fornitore uscente ha fatturato la sua ultima giornata a consuntivo la settimana precedente.

Manifestazioni e sintomi sul campo

Su qualsiasi ERP, i primi segnali arrivano dalle elaborazioni automatiche che nessuno controlla più. In Business Central compaiono nella pagina "Movimenti coda processi": un sollecito clienti o un'esportazione contabile resta nello stato "Errore" da settimane. Il consulente precedente rilanciava il processo a mano ogni lunedì, senza averlo mai segnalato.

Poi arrivano gli sviluppi personalizzati il cui codice non è mai stato consegnato. Nel nostro progetto Business Central, un'estensione compare nella pagina "Gestione estensioni", ma la sua politica di esposizione delle risorse impedisce di scaricarne il codice dall'ambiente. Il nuovo partner può eseguirla, non correggerla. All'aggiornamento principale successivo, ad aprile o a ottobre, basta un oggetto standard rimosso da Microsoft per bloccarne l'installazione.

I team operativi, dal canto loro, hanno costruito i propri espedienti. Un file Excel ricalcola le provvigioni che l'ERP calcola male, e una contabile corregge un campo prima di ogni registrazione di fattura. Nessuno di questi gesti compare in un documento. Si scoprono il giorno in cui la persona va in ferie.

Impatto finanziario, operativo e umano

Il costo più visibile è il tempo speso a capire prima di poter agire. Un'anomalia che il team uscente risolveva in un'ora può richiedere due giorni di analisi a chi riprende il dossier, e quelle giornate vengono fatturate. Quando uno sviluppo personalizzato va riscritto per mancanza del codice sorgente, la fattura cambia scala.

Anche l'operatività subisce il colpo. Basta un'interfaccia EDI ferma, o una sincronizzazione bancaria che fallisce senza avviso, perché le operazioni del giorno non vengano integrate. La prima chiusura mensile dopo il subentro fa spesso da rivelatore: il controller rileva differenze di magazzino che nessuno sa più spiegare.

Per i collaboratori, il subentro somiglia a un ritorno al punto di partenza. Devono rispiegare processi che consideravano acquisiti, e la loro fiducia nello strumento cala proprio quando il nuovo partner ne avrebbe bisogno.

Analisi delle cause profonde ed errori di governance

Dare la colpa al partner uscente sarebbe comodo. La realtà è più condivisa. Il contratto iniziale spesso non prevedeva né una clausola di reversibilità, né la consegna del codice degli sviluppi, né una documentazione di esercizio, e l'azienda non le ha mai chieste finché tutto funzionava. Da parte sua, il partner uscente ha poco interesse a dedicare tempo non fatturato alla formazione del suo successore.

L'errore di governance più frequente consiste nel confondere la data di fine contratto con la data di presa in carico. Il nuovo partner avvia il supporto senza periodo di affiancamento e impara il sistema gestendo gli incidenti. I diritti di amministrazione passano di mano all'ultimo minuto, a volte dopo che gli accessi del vecchio partner sono già stati revocati. Su Business Central si tratta dei privilegi di amministratore delegato granulari (GDAP) e delle licenze CSP, senza i quali il nuovo partner non può nemmeno aprire l'interfaccia di amministrazione.

Resta la conoscenza tacita. Una parte della configurazione si basa su scelte fatte in workshop anni fa e mai documentate. Solo due o tre utenti chiave ne conoscono ancora la ragione, e nessuno li ha mai identificati come custodi di un sapere critico.

Piano d'azione, misure preventive e correttive

Il subentro si negozia prima della firma del nuovo contratto. Si ottiene dal partner uscente un periodo di affiancamento, da due a sei settimane secondo il perimetro, durante il quale i due team gestiscono insieme gli incidenti reali. I primi workshop censiscono le società, le sedi e le entità giuridiche gestite, con le loro particolarità: Intrastat, piano dei conti di una filiale estera, flusso di approvazione specifico di un magazzino.

La mappatura copre poi gli ambienti, gli sviluppi personalizzati e le interfacce. Per ogni sviluppo si annotano l'autore, la natura e la posizione del codice sorgente. In Business Central significa distinguere le app AppSource dalle estensioni specifiche del cliente, poi passare al setaccio il codice AL per individuare gli oggetti contrassegnati come obsoleti, che annunciano le rotture dei prossimi aggiornamenti. Le interfacce con le banche, l'EDI, il sito e-commerce o le paghe vengono registrate con la loro frequenza e il loro responsabile.

Se il sistema è già in produzione, lo storico dei ticket e le elaborazioni in errore dicono più di qualsiasi documento; su Business Central, la telemetria di Application Insights, quando è attiva, completa il quadro. Se il progetto è ancora in fase di rilascio, la diagnosi riguarda piuttosto lo stato dei collaudi nell'ambiente di test: scenari validati, scenari da ripetere, anomalie aperte. Ogni fase produce il proprio deliverable man mano, evitando il raccoglitore di ottanta pagine consegnato l'ultimo giorno e mai riletto.

Il passaggio di consegne avviene solo quando sono soddisfatte queste condizioni:

• codice sorgente di tutti gli sviluppi personalizzati consegnato in un repository di proprietà del cliente;
• diritti di amministrazione e licenze trasferiti al nuovo partner, cioè GDAP e CSP per Business Central;
• nessuna elaborazione pianificata in errore non spiegato;
• procedure di emergenza testate e contatti di escalation noti, presso il produttore dell'ERP come presso i fornitori di app di terze parti.

Il piano di passaggio assegna poi ogni azione a un responsabile, con una procedura di ripiego. Gli utenti chiave ricevono il nuovo flusso di richiesta di assistenza il giorno prima, non il giorno dopo.

Conclusione

Un subentro in un progetto ERP si vince o si perde prima del primo ticket. L'azienda che accetta l'avvio del supporto senza codice sorgente, senza accesso amministrativo e senza affiancamento compra un rischio che pagherà al prossimo aggiornamento di versione. Su Business Central, questa scadenza torna due volte l'anno. Il metodo ha valore solo se ci si rifiuta di bruciare le tappe.

La prima misura non costa nulla. La direzione rilegge il contratto di integrazione in corso, verifica che preveda la reversibilità e la proprietà del codice degli sviluppi personalizzati, poi chiede dove si trovi oggi quel codice. Se nessuno sa rispondere, il subentro è già cominciato, senza che nessuno l'abbia deciso.