Autore: InformaticaGestionale

Con questo articolo vorrei condividere alcune considerazioni, maturate dopo anni di esperienza in sistemi di gestione ERP (prendendo anche spunto dalle discussioni nate su informaticagestionale.it), su quali possono essere gli errori più comuni e quali i possibili rimedi per un progetto ERP aziendale.

In seguito una lista che, dal mio punto di vista, rappresentano gli errori più frequenti in un progetto di migrazione ERP.

1. Evitare di identificare un applicativo ERP soltanto come un software gestionale contabile qualsiasi; molte volte si pensa che il gestionale aziendale ERP riguardi soltanto la sfera contabile ed amministrativa (ciclo attivo, ciclo passivo, registrazione prime note, piano dei conti…). La gestione della contabilità è una delle funzioni di un gestionale ERP ma non è l’unica. Con questo errore si rischia di “isolare” l’applicativo per i soli scopi contabili e non si sfrutta per le reali potenzialità di integrazione e di supporto trasversale dell’operatività aziendale. Inoltre, a lungo andare, si rischia di rendere l’intero ecosistema informatico altamente improduttivo: se ERP è usato solo in un settore aziendale vuol dire che probabilmente serviranno altri software per la gestione di altri settori aziendali aumentando così i costi di manutenzione e di integrazione dell’intera infrastruttura.
2. Evitare di scegliere il software ed il partner prima di eseguire l’analisi e l’ottimizzazione dei processi. Con questo errore, quasi certamente, ci si ritrova a dover adattare i processi aziendali al software ERP. In realtà dovrebbe essere fatto esattamente il contrario. Prima di tutto si analizza il contesto, si esegue un’analisi adeguata, si standardizzano i processi e, soltanto dopo, si cerca il software più adatto a gestire il nuovo contesto aziendale. Può succedere che, dopo un’attenta analisi, adottare un sistema ERP non è poi così vantaggioso.
3. Altro errore è non adottare una metodologia di customizzazione e sviluppo in stretta collaborazione con il proprio partner già esplicitato sul contratto di collaborazione. Un progetto ERP deve essere analizzato ed adattato già dalle prime fasi di customizzazione e deve essere supportato da un contratto che assicuri una piena flessibilità di implementazione. Con questa metodologia, il cliente può valutare attraverso continui feedback (esattamente come nell’approccio AGILE) se, durante le fasi di implementazione, si stanno rispettando i requisiti richiesti.
4. Evitare di sottovalutare un progetto ERP: un progetto ERP, per ottenere i massimi vantaggi, è per sua natura complesso. Viene coninvolta una buona parte dell’organizzazione: processi operativi e decisionali, personale, ruoli, mansioni, funzioni ecc. Inoltre coinvolge anche altre tematiche come: la trasformazione digitale, il supporto del passaggio dell’informazione in maniera trasversale tra i vari reparti aziendali, riorganizzazione interna dei processi, impegno economico non indifferente ecc. Un progetto ERP ha un ciclo di vita decennale e deve quindi essere una scelta strategica.
5. Evitare di creare funzionalità (o plugin) adhoc laddove non esiste una forte necessità. Anche se ormai una buona parte dei gestionali permettono di sviluppare plugin aggiuntivi, lo sviluppo di funzionalità “esterne” deve essere una scelta ponderata su questi elementi:
   1. ogni funzionalità “esterna” deve essere ben integrata con il sistema stesso. Ad esempio, se facessi creare una funzionalità esterna che prevede la “messa a macero” delle merci in magazzino devo anche assicurarmi che tale operazione vada ad incidere sulla valorizzazione contabile del magazzino e non soltanto sulle quantità fisiche eliminate. Sembra banale dirlo ma, a livello di implementazione, non è così semplice integrare funzionalità “esterne” con un gestionale ERP. In molti casi le applicazioni ERP definiscono alcune linee guida per lo sviluppo di plugin esterni; bisogna solo assicurarsi che chi sviluppa utilizzi gli stessi criteri.
   2. Assicurarsi che non esista già un plugin pensato per fare la stessa cosa. Ogni nuovo sviluppo di applicazioni esterne deve seguire la fase di specifiche, implementazione, test e deploy. Se la funzionalità fosse già stata sviluppata allora il risparmio di tempo e costi è notevole.
   3. Più un plugin è pervasivo, cioè che si interpone in profondità negli ingranaggi dell’ERP (creazione fatture, movimentazione merci, acquisti, vendite…), più il partner al quale si affida lo sviluppo dovrà essere affidabile. In questo modo si evita che una funzionalità che è diventata parte integrante del sistema ERP (per il proprio contesto aziendale) non venga più adeguatamente supportata nel lungo periodo (uno dei maggiori motivi può essere la cessazione o cambio attività del partner). Il rischio è di vincolare la manutenzione del software generico (magari gestito a livello mondiale) alle sorti di un partner che ha sviluppato un’estensione (magari su vostra richiesta) in maniera pervasiva.