Consideriamo un team amministrativo che ricostruisce i report al di fuori dell’ERP, mentre il personale operativo reinserisce le transazioni da un sistema all’altro. La direzione vuole finanziare una sostituzione. Prima di approvarla, CFO, COO e CIO devono stabilire se questi problemi derivino da funzionalità software mancanti, processi mal progettati, integrazioni inaffidabili o responsabilità non sufficientemente definite.
La crescita e le difficoltà operative giustificano un’indagine, non una sostituzione automatica. Finanziate il miglioramento quando è dimostrabile che la piattaforma attuale può supportare i flussi richiesti. Procedete verso la sostituzione quando vincoli rilevanti non possono essere risolti a condizioni accettabili. Commissionate un’ulteriore valutazione quando restano incerte le cause, la sostenibilità economica o la capacità organizzativa.
La decisione sull’investimento deve produrre una scelta documentata tra queste alternative, non una proposta di implementazione che dia già per scontata la sostituzione.
Documentare i problemi dei flussi operativi prima di definire un nuovo sistema
Francesco Perrotta individua nei processi aziendali inefficienti o complessi e nelle difficoltà di integrazione con le applicazioni esistenti alcuni segnali che spingono a considerare un cambiamento dell’ERP. Trattate questi segnali come il punto di partenza di una diagnosi. Un’affermazione come «l’ERP non sostiene la crescita» deve diventare una descrizione verificabile di ciò che non funziona, delle condizioni in cui accade e delle conseguenze per l’azienda.
Chiedete all’amministrazione di ripercorrere un recente problema di chiusura contabile, riconciliazione o reporting. Chiedete alle operations di mostrare un ordine in ritardo, una discrepanza di magazzino o un’eccezione negli acquisti. Registrate il risultato atteso, quello effettivo, l’intervento manuale necessario e l’impatto a valle. Distinguete le conseguenze osservate dalle ipotesi: un ritardo nella fatturazione non equivale automaticamente a ricavi persi, e il tempo liberato al personale non equivale automaticamente a un risparmio monetario.
Per ogni flusso critico, raccogliete la tracciabilità delle transazioni, la configurazione pertinente, lo storico dell’assistenza e la spiegazione del responsabile di processo. Classificate quindi il vincolo ipotizzato:
- Funzionalità software: la regola aziendale o la transazione richiesta non può essere rappresentata.
- Progettazione del processo: responsabilità, approvazioni o passaggi di consegne sono poco chiari o inutilmente complessi.
- Integrazione: le informazioni non arrivano, arrivano in modo errato oppure non è possibile ripristinare il flusso in modo affidabile.
- Preparazione organizzativa: utenti, responsabili dei dati o decisori non riescono a sostenere il modo di lavorare previsto.
Sono ipotesi di lavoro, non classificazioni definitive. Se l’amministrazione sostiene che un report è impossibile da ottenere, chiedete quali informazioni servano e una dimostrazione del percorso di reporting attuale. Se le operations attribuiscono il problema all’integrazione, ricostruite il malfunzionamento attraverso le applicazioni. La successiva decisione di finanziamento deve affrontare il vincolo dimostrato, non semplicemente la richiesta del reparto che lo segnala.
Verificare se l’ERP attuale può adattarsi al cambiamento
Perrotta sostiene che il valore di una valutazione esterna risieda nell’analisi oggettiva dei processi e nella comprensione approfondita del contesto aziendale. Inserite questo principio nell’incarico di valutazione: richiedete una raccomandazione che possa prevedere il mantenimento del sistema attuale, anziché commissionare un’analisi preliminare il cui unico esito ammesso sia la sostituzione.
Scegliete un flusso essenziale per l’attività e chiedete al team di dimostrare come l’installazione attuale potrebbe supportarlo attraverso modifiche di processo, configurazione, un modulo disponibile o un’integrazione dal perimetro definito. Richiedete verifiche sulla versione installata e sulle condizioni commerciali pertinenti. «Il prodotto lo supporta» non basta se la risposta dipende da un aggiornamento non approvato, un’interfaccia non disponibile o un’estensione non testata.
Scenario ipotetico di valutazione: un’applicazione di magazzino invia le conferme di spedizione, ma l’amministrazione continua a correggere manualmente le fatture. Il trasferimento riuscito di un messaggio non dimostra che il flusso sia risolto. Chiedete al team di mostrare la registrazione dell’operazione nel gestionale, la riconciliazione, la gestione delle eccezioni e le responsabilità di ripristino. Se l’ERP riesce a completare il processo una volta corretta l’interfaccia, questo giustifica l’approfondimento di un miglioramento mirato. Se una regola aziendale obbligatoria resta impossibile da rappresentare, il business case per la sostituzione si rafforza.
Verificate la flessibilità futura oltre all’adeguatezza attuale. In un webinar sulla sovranità digitale con rappresentanti di un fornitore ERP, i relatori propongono di sottoporre le dipendenze a uno stress test rispetto a cambiamenti normativi, acquisizioni e variazioni nella strategia del fornitore. La loro preoccupazione non è la dipendenza in sé, ma quella che priva l’azienda della capacità di agire. Per questa decisione d’investimento, chiedete che cosa accadrebbe se una funzionalità necessaria uscisse dalla roadmap, cambiassero le condizioni di accesso o l’azienda dovesse rispettare un nuovo obbligo.
Documentate la risposta contrattuale, tecnica e operativa sia per il sistema attuale sia per la sostituzione proposta. A una nuova piattaforma non va attribuita per presunzione quella flessibilità che il sistema esistente deve dimostrare. Se il rimedio proposto comporta un’estensione destinata a durare, utilizzate la scheda per l’approvazione delle personalizzazioni ERP per esaminare quella dipendenza, senza trasformare la valutazione dell’investimento in un’approvazione dettagliata delle modifiche.
Confrontare miglioramento e sostituzione a parità di condizioni
Costruite gli scenari sugli stessi risultati aziendali richiesti e sullo stesso orizzonte di pianificazione. Includete il mantenimento dell’installazione attuale con miglioramenti mirati, la sua sostituzione e, quando l’incertezza resta rilevante, una valutazione dal perimetro definito prima di assumere uno dei due impegni. Se è plausibile una nuova implementazione del prodotto esistente, stimatela separatamente anziché nascondere una ricostruzione sostanziale sotto la voce «ottimizzazione».
Per definire la base di costo del sistema attuale, le categorie di costo di ERP Research includono licenze, hosting, assistenza, personale interno, manutenzione delle personalizzazioni e costi delle procedure alternative. Usatele per evitare di confrontare un programma di sostituzione con la sola fattura delle licenze attuali. Aggiungete gli interventi di miglioramento proposti e indicate quali costi esistenti scomparirebbero davvero, quali resterebbero e quali aumenterebbero.
Per la sostituzione, richiedete stime esplicite delle attività di transizione oltre che della gestione a regime. La guida decisionale ERP di Digital Advisory individua tra gli elementi del business case la copertura del personale assegnato al progetto, le prove di migrazione, le integrazioni temporanee, le trasferte dell’integratore e il margine per le modifiche, oltre al supporto di stabilizzazione successivo al periodo di hypercare previsto nella proposta. Trattateli come aspetti da quantificare per il vostro programma, non come oneri universali o benchmark.
Per ogni beneficio dichiarato, indicate il meccanismo che dovrebbe generarlo e il relativo responsabile. Se dalla sostituzione ci si aspetta una chiusura contabile più rapida, specificate quale passaggio di riconciliazione o approvazione cambierà, quali prove dimostrano quella capacità e che cosa dovrà fare diversamente l’amministrazione. Non conteggiate la stessa capacità liberata sia come riduzione del personale sia come aumento della produzione, a meno che il piano operativo non ne spieghi l’allocazione.
Formulate una raccomandazione condizionata alle evidenze. Il miglioramento è credibile quando risolve i problemi importanti con impegni continuativi accettabili. La sostituzione è credibile quando i vincoli funzionali o di dipendenza dimostrati prevalgono sui rischi della transizione. Un ulteriore approfondimento è appropriato quando una specifica questione irrisolta potrebbe cambiare la scelta. Assegnate a questa valutazione un risultato definito, un responsabile e una data di decisione, anziché un mandato esplorativo senza limiti.
Usare una scheda decisionale, non un punteggio sintetico
La scheda seguente è un ausilio editoriale alla decisione, non un modello di punteggio validato. Compilatela per ogni scenario praticabile. Mantenete visibili i disaccordi, anziché diluire un vincolo aziendale critico in un totale apparentemente accettabile.
| Area decisionale | Evidenze da registrare | Domanda per l’approvazione |
|---|---|---|
| Impatto operativo | Flussi problematici, evidenze delle transazioni, impegno attuale e conseguenze aziendali | Quali problemi risolverà questa opzione e quali resteranno? |
| Funzionalità e dipendenze | Dimostrazioni dei flussi, verifiche sulla versione installata, interfacce, condizioni di assistenza e ipotesi sulla roadmap | L’azienda può operare e adattarsi entro i vincoli proposti? |
| Confrontabilità economica | Costi operativi attuali, costi del cambiamento, impegno di transizione, assistenza continuativa e ipotesi sui benefici | Abbiamo confrontato perimetri equivalenti senza presumere che i benefici siano risparmi monetari? |
| Capacità interna | Responsabili di processo nominati, partecipazione richiesta, impegni concorrenti e decisioni sulla copertura delle attività ordinarie | L’azienda può mettere a disposizione le persone e le decisioni richieste da questa opzione? |
| Rischi della transizione | Attività interessate, soluzioni temporanee, responsabilità di ripristino e questioni aperte sulla continuità | Quali rischi aziendali accetta la direzione finanziando questa alternativa? |
| Evidenze ancora necessarie | Questioni aperte, relativi responsabili e risultati che cambierebbero la raccomandazione | Approvare ora, approvare un’indagine circoscritta o rinviare? |
Allegate alla scheda i documenti di supporto, anziché riempirla di rassicurazioni. «Gli utenti parteciperanno» deve diventare un insieme di responsabilità nominative e un’allocazione concordata del tempo. «L’integrazione è fattibile» deve identificare l’interfaccia, il risultato aziendale e le condizioni ancora da risolvere. «Costi operativi inferiori» deve essere riconciliabile con una base di costo e un modello operativo futuro esplicito.
Assegnare le responsabilità aziendali prima di approvare l’esecuzione
Perrotta descrive la sottovalutazione della formazione come un problema ricorrente nella sua esperienza, collegandola a un utilizzo inefficace del sistema e a benefici ridotti. Nella fase di approvazione dell’investimento, la conseguenza pratica è prevedere un budget per la partecipazione delle funzioni aziendali e per l’apprendimento, non condurre una verifica prematura del go-live. Una soluzione tecnicamente plausibile richiede comunque persone in grado di definire, testare e adottare i flussi previsti.
Assegnate alla funzione finance la responsabilità delle ipotesi economiche, alle operations quella dei risultati dei flussi e alla funzione IT quella delle evidenze architetturali e delle dipendenze. Nominate un responsabile aziendale per ogni beneficio rilevante e ogni decisione di processo irrisolta. Quando queste responsabilità attraversano più reparti, lo sponsor esecutivo deve chiarire i passaggi di consegne prima di finanziare l’esecuzione.
Mantenete distinte le decisioni successive. Una volta approvata la direzione dell’investimento, utilizzate la due diligence sul partner di implementazione ERP per verificare chi realizzerà il progetto. L’autorizzazione all’entrata in esercizio appartiene a una successiva verifica della preparazione al go-live ERP. Nessuna delle due deve sostituire la decisione sulla fondatezza dell’investimento stesso.
Prima di approvare l’esecuzione, affiancate gli scenari principali di miglioramento e sostituzione. Chiedete a ciascun responsabile di indicare quale esito ancora da verificare avrebbe maggiori probabilità di ribaltare la raccomandazione, quindi commissionate quel controllo prima di impegnare il budget più consistente.
Se vi serve supporto funzionale o tecnico per valutare questi scenari, confrontatevi sui vostri flussi, sui vincoli di integrazione e sulla capacità interna con gli specialisti ERP di Digiventi.
