Un’azienda dell’arredo ha acquistato il gestionale insieme a un pacchetto di sviluppi su misura. Quattro anni più tardi, nel passaggio alla release successiva della stessa famiglia di prodotto, ha pagato quegli sviluppi una seconda volta per intero. La responsabile amministrativa lo riassume in una riga: si compra il programma, si commissionano tutte le personalizzazioni, e qualche anno dopo si ripagano. È il momento in cui le personalizzazioni del gestionale smettono di apparire un dettaglio contrattuale e diventano una voce di costo ricorrente.
La stessa azienda ha appreso solo dopo sei anni che esisteva una release molto più aggiornata di quella in uso. Non l’avevano adottata per un motivo preciso: con diverse personalizzazioni in essere, nessuno garantiva che sarebbero state reintegrate. Le personalizzazioni del gestionale hanno finito per legare l’azienda a una versione superata, mentre volumi, sedi e persone continuavano ad aumentare. La valutazione di un cambio di piattaforma è arrivata con sei anni di ritardo, e in quei sei anni le procedure che il software non copriva si sono spostate su fogli di calcolo e caselle di posta.
Nelle analisi di sostituzione di un ERP modulare per PMI la domanda sulle personalizzazioni precede quella sul prezzo. Chi ha costruito vent’anni di procedure dentro un software teme di perderle; chi le ha già ricostruite una volta teme di doverlo rifare al rilascio successivo. La risposta dipende da due variabili concrete: che cosa è stato personalizzato, e con quale tecnica.
Configurazione e sviluppo su misura producono conseguenze diverse
Nella maggior parte dei progetti la richiesta del cliente si risolve senza scrivere una riga di codice. Maschere ripulite, colonne riordinate, pannelli riorganizzati, campi resi obbligatori, layout di stampa ridisegnati, filtri e totalizzatori salvati per utente: sono impostazioni, e vivono nel livello di configurazione. Un aggiornamento non le tocca.
Lo sviluppo ad hoc appartiene a un piano diverso. Interviene sul comportamento del programma, aggiunge logiche che lo standard non prevede, e va riallineato quando il fornitore rilascia una versione nuova. Le personalizzazioni del gestionale che nascono così vanno riallineate a ogni versione. In trattativa la distinzione salta quasi sempre: il cliente descrive un bisogno, il fornitore risponde con un preventivo, e nessuno dichiara su quale dei due piani si sta lavorando.
Nei progetti ERP che seguiamo in Aesir Srl la separazione è il primo elemento che formalizziamo: quanta parte della richiesta si copre configurando lo standard, quanta richiede un’estensione e quanta una modifica vera e propria. Le tre voci hanno costi diversi, tempi diversi e soprattutto un diverso destino agli aggiornamenti.
La differenza si vede meglio con tre esempi presi dallo stesso progetto. Aggiungere in una griglia di magazzino la colonna con il codice articolo usato dal fornitore è configurazione: si imposta una volta e resta. Creare una nuova causale contabile accanto a quelle standard, per distinguere le fatture di conto lavoro, è estensione: si affianca al prodotto e sopravvive al rilascio. Cambiare l’algoritmo con cui il programma calcola la disponibilità di magazzino è una modifica vera e propria: tocca il nucleo, e a ogni nuova versione qualcuno deve verificare che continui a comportarsi come previsto.
Come si confrontano i costi delle tre categorie
Il costo si valuta sulla stessa scala. La configurazione ha un costo di analisi e nessun costo ricorrente. L’estensione ha un costo di realizzazione e una verifica contenuta a ogni rilascio. La modifica del nucleo ha un costo di realizzazione, un costo di riallineamento a ogni release e un costo di regressione, cioè il tempo speso a controllare che l’aggiornamento non abbia alterato il comportamento atteso. Nel confronto fra due preventivi conviene chiedere le tre voci separate: è l’unico modo per capire quale delle due offerte costa meno al terzo anno.
Quali personalizzazioni del gestionale sopravvivono a un aggiornamento?
Sopravvivono le personalizzazioni ottenute configurando lo standard o affiancandogli nuovi oggetti. Vanno invece rifatte quelle che modificano oggetti di sistema, destinati a essere sovrascritti dal rilascio.
In fase di analisi si applica alle personalizzazioni del gestionale una regola che quasi nessun cliente accetta al primo colloquio: gli oggetti di sistema non si modificano, si duplicano. Causali contabili e codici IVA standard restano intatti; se serve un comportamento diverso se ne creano di nuovi, prendendo spunto da quelli esistenti. Sul piano dei conti la scelta è tra nascondere una voce e cancellarla: conviene nasconderla, perché una voce eliminata oggi può servire a un controllo fiscale fra tre anni.
Un’azienda familiare di venti persone, tre divisioni, lavoro per commessa, è arrivata alla migrazione con un’indicazione netta del proprio commercialista: adottare il piano dei conti standard del nuovo gestionale invece di ricostruire quello vecchio, «perché così nel momento in cui c’è un aggiornamento lo aggiorna e siamo allineati, sennò diventa veramente un pasticcio». Nella migrazione precedente avevano seguito la strada opposta, e il giudizio sul risultato si riassume in una riga: il sistema perde gli automatismi.
| Tipo di intervento | Dove risiede | Comportamento al rilascio |
|---|---|---|
| Configurazione di maschere, colonne, filtri e layout di stampa | Profili e parametri utente | Conservata |
| Nuovi oggetti creati per duplicazione: causali, codici, tabelle | Anagrafiche di sistema estese | Conservata |
| Modifica di oggetti standard rilasciati dal produttore | Nucleo del prodotto | Sovrascritta, va riallineata |
| Layer di integrazione verso applicativi esterni | Componente separato | Da verificare a ogni cambio di API |
Vent’anni di procedure dentro un software che non si aggiorna più
Il caso dell’azienda dell’arredo si chiude con un dettaglio che pesa più del costo ripetuto. Le personalizzazioni ripagate riguardavano kit e produzione interna, e l’azienda le ha saldate poco prima di esternalizzare la produzione: perderle, a quel punto, non cambiava nulla. La modifica che incide sul lavoro quotidiano è un’altra, l’interfaccia tra il software di magazzino con i terminali portatili e il gestionale, e nessuno l’ha mai realizzata. Fra tutte le personalizzazioni del gestionale discusse in quegli anni, è rimasta l’unica che rallenta il magazzino, ed è l’unica per cui nessuno aveva firmato un preventivo.
Un distributore B2B con rete vendita utilizza da venticinque anni un gestionale sviluppato su misura. Il responsabile di prodotto descrive la situazione senza attenuanti: «iniziamo ad essere un po’ stretti all’interno della chioccia che ci siamo costruiti». La domanda che pone al fornitore è quella di tutti: si parte da un prodotto standard oppure da un prodotto sempre costruito su misura. La proprietà ha poi sospeso il progetto per l’anno in corso, e la ragione dichiarata non riguarda la piattaforma valutata, ma il peso di venticinque anni di stratificazioni. Ogni funzione aggiunta nel tempo ha reso quel software più aderente al lavoro dell’azienda e più difficile da sostituire: il secondo effetto arriva sempre dopo il primo, e nessuno lo mette a bilancio quando firma la prima personalizzazione.
I tempi di un progetto ERP si misurano sulle persone, non sui moduli
Le personalizzazioni del gestionale incidono sul calendario più di qualsiasi altra voce, perché ogni modifica va analizzata, realizzata, provata e spiegata a chi la userà. La stima dei tempi si costruisce insieme alla decisione su che cosa personalizzare, non dopo averla presa.
La sequenza è consolidata: demo d’insieme, analisi di dettaglio con stima puntuale, richiesta della copia del database al fornitore uscente, allineamento su piano dei conti, causali contabili e codici IVA, importazione delle anagrafiche, configurazione, formazione, avvio. Il calendario però dipende da una variabile che il fornitore non controlla.
È la disponibilità di chi in azienda conosce i processi. In un progetto con avvio fissato al primo gennaio, le due parti hanno concordato per la referente amministrativa un impegno di mezza giornata a settimana, in sedute pianificate, per non sottrarla al lavoro in modo imprevisto. Su quella base il fornitore ha chiesto di anticipare l’inizio dei lavori di circa un mese rispetto alla data proposta dal cliente. Il piano ha escluso la formazione dal periodo immediatamente precedente alla pausa estiva, per la ragione più concreta di tutte: a settembre non ne resta nulla.
Le prime settimane dopo l’avvio hanno un assorbimento diverso da quello di regime. Nei progetti entrati in esercizio a gennaio il contatto con l’assistenza è quasi quotidiano nel primo trimestre, poi decresce rapidamente. Una configurazione circoscritta, come la riconciliazione bancaria con due istituti collegati, richiede circa una giornata, con il consenso bancario da rinnovare ogni tre o sei mesi a seconda della banca.
Il ticket funziona a regime, l’avvio chiede un canale diretto
La resistenza al sistema di ticket ha sempre la stessa formulazione: «va bene aprire i ticket, ma non troppa burocrazia, vorremmo trovare un’azienda che parla la nostra stessa lingua». È una richiesta legittima, e si risolve separando le fasi.
In onboarding lo scambio è diretto e non passa dal ticket, perché il progetto ha un referente e un ritmo suo. A regime il ticket diventa lo strumento corretto: traccia l’attività, la assegna al primo tecnico disponibile e porta con sé l’elenco dei software attivi presso quel cliente, così chi prende in carico la richiesta sa già su che cosa sta intervenendo. I canali restano più di uno, dal portale alla mail che genera automaticamente il ticket alla telefonata. L’escalation scatta quando la risoluzione non arriva nei tempi concordati.
Ogni area applicativa ha il proprio referente tecnico: figure diverse presidiano gestionale, CRM e documentale, ciascuna specializzata sul proprio prodotto. Aesir opera come MSP e MSSP nello stesso perimetro contrattuale, con progetti seguiti in tutta Italia.
Integrare i verticali senza sostituirli
La seconda domanda ricorrente riguarda i software che l’azienda non intende toccare. Un portale B2B proprietario, un applicativo di pianificazione delle visite, un verticale HR: sistemi che funzionano e su cui esiste competenza interna.
La risposta tecnica passa dalle API. Nel caso del distributore citato l’indicazione era esplicita, portale e pianificazione visite restavano fuori dal perimetro, e il progetto si è costruito attorno a quel vincolo con un layer di integrazione dedicato. Con un verticale HR il flusso è bidirezionale: le presenze salgono verso l’ERP, le commesse scendono verso il verticale, e l’evento che innesca la sincronizzazione è la creazione o la cancellazione di una commessa. L’accesso si apre generando un token, operazione di pochi minuti.
Resta da stabilire quale sistema è titolare dell’anagrafica. Quando ERP e CRM per aziende di servizi convivono, il gestionale mantiene il dato di riferimento: nel momento in cui l’offerta diventa ordine l’anagrafica si consolida sul gestionale, con eccezioni ammesse a livello di singolo documento. Aesir è Gold Partner di NTS Informatica per Business Experience, e con gli altri gestionali si utilizzano i connettori disponibili oppure si costruiscono.
Checklist: le personalizzazioni del gestionale da approvare e quelle da rimandare
Prima di firmare un preventivo di sviluppo conviene verificare sei punti.
- La richiesta si copre configurando lo standard? La verifica va richiesta per iscritto, non a voce.
- L’intervento modifica un oggetto rilasciato dal produttore oppure ne crea uno nuovo per duplicazione?
- Che cosa accade a quella funzione al prossimo cambio di release, e chi ne sostiene l’onere?
- La modifica serve a un processo destinato a restare, o a un’attività che l’azienda sta valutando di esternalizzare?
- Esiste una documentazione leggibile da un fornitore diverso da chi ha scritto il codice?
- La finestra di manutenzione per gli aggiornamenti è concordata, o il rilascio arriva senza preavviso in orario di lavoro?
L’ultimo punto genera più attrito di tutti nel quotidiano. Sugli adeguamenti normativi il rilascio può essere automatico e pianificato in fascia non lavorativa, oppure manuale per chi preferisce un approccio conservativo, con finestre concordate. Le scadenze fiscali e i requisiti di fatturazione elettronica pubblicati dall’Agenzia delle Entrate arrivano comunque, e l’unica variabile che l’azienda controlla è l’orario in cui il sistema si ferma per riceverli.
Domande poste prima di firmare lo sviluppo
Le personalizzazioni del gestionale attuale si possono portare sul nuovo?
Le personalizzazioni del gestionale non si trasferiscono come oggetti. Si trasferisce il requisito che le ha generate, e su quel requisito si verifica quanto è già coperto dallo standard della nuova piattaforma. In molti progetti la parte residua da sviluppare risulta nettamente inferiore all’originale, perché il prodotto nel frattempo ha assorbito a standard funzioni che anni prima erano su misura.
Aggiornare uno sviluppo esistente impegna quanto rifarlo?
Su un prodotto evolutivo, che mantiene continuità fra le release, il riallineamento di uno sviluppo esistente ha un impegno inferiore alla riscrittura. La condizione è che la modifica sia documentata e costruita sopra lo standard. Senza documentazione l’impegno tende a coincidere con quello di una nuova realizzazione.
Che cosa accade ai dati se il rapporto con il fornitore si interrompe?
Il fornitore restituisce al cliente la copia del database. È una clausola da verificare prima della firma, insieme al formato in cui consegna i dati: un backup proprietario, illeggibile senza il software che lo ha generato, soddisfa la clausola e non serve a chi deve portare i dati altrove.
Parliamone
Le personalizzazioni del gestionale non sono un errore da evitare. Sono una risposta legittima a un processo che l’azienda ha costruito e che la distingue dai concorrenti. Il criterio di decisione riguarda l’orizzonte: ogni sviluppo su misura va valutato sul suo costo di manutenzione lungo tutta la vita del sistema, che in un gestionale si misura in anni. Chi sceglie la strada dello standard configurato paga meno il primo giorno e molto meno al primo aggiornamento.
Se desidera approfondire il tema o valutare la situazione della sua azienda, può compilare la form in fondo alla pagina oppure scrivere a support@aesir-tech.it: prenotiamo una consulenza gratuita e partiamo dai suoi numeri.