Progetto ERP in azienda, alcune considerazioni ed errori comuni

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.

Protetto: Migrazione dei sistemi informatici: come eseguire un’analisi aziendale AS-IS

Il contenuto è protetto da password. Per visualizzarlo inserisci di seguito la password:

Quando vale la pena spostarsi su cloud pubblici?

Già da diverso tempo le aziende stanno valutando soluzioni cloud per ricoprire determinate esigenze aziendali.

Il cloud (nuvola), lo ricordiamo per chi ancora non lo sapesse, non è nient’altro che una modalità di erogazione dei servizi informatici in modalità on demand attraverso internet. Un banalissimo esempio cloud è il Cloud Storage, ovvero, una sorta di disco fisso al quale si può accedere come un normalissimo disco ma che in realtà si trova fisicamente sulla “nuvola”, cioè, internet.

Inutile ripetere quali sono i vantaggi principali nell’adozione di soluzioni in cloud pubblici, ne ricordiamo giusto alcuni:

  • il passaggio da costi fissi a costi variabili delle infrastrutture informatiche in alcuni casi può essere un enorme vantaggio a livello finanziario
  • manutenzione e aggiornamenti applicativi completamente trasparenti all’utente finale
  • gestione licenze vantaggiose: in molti casi è possibile attivare e disattivare le utenze con un semplice click senza dover rimettere in discussione fastidiosi contratti commerciali con i fornitori

la domanda che ci poniamo però è: Quando vale la pena spostarsi su cloud pubblici?

Ovvero, non sempre la soluzione Cloud, può risultare vantaggiosa per un’azienda. Bisogna conoscere molto bene quali sono le esigenze aziendali tenendo in considerazione che più i processi sono standardizzati e le funzionalità richieste sono semplici e ben definite allora più è semplice introdurre soluzioni cloud.

Ad esempio, è molto facile introdurre il cloud per soluzioni di posta elettronica, team working, istant messaging, document share, storage ecc…tutte queste applicazioni hanno infatti una specifica funzionalità e rispondono a determinate esigenze ben definite.

Per queste soluzioni, l’unica preoccupazione, potrebbero essere le politiche di protezione dei dati aziendali (dal momento che i dati aziendali sono conservati generalmente da altre società private).

Per soluzioni più complesse come i gestionali ERP, CRM, BI si dovrebbe fare prima una buona analisi AS-IS e TO-BE aziendale (in modo da standardizzare il più possibile i processi), dopo di che, si può pensare al cloud come modalità di fruizione dei servizi informatici.

Queste soluzioni, essendo multi-funzionalità, generalmente hanno bisogno di applicazioni flessibili. Il cloud, in alcuni casi, non riesce ad essere così flessibile o customizzabile come si richiede; pertanto, è indispensabile fare un’analisi accurata delle esigenze aziendale e valutare se le soluzioni cloud presenti sul mercato siano realmente adatte all’azienda nonostante tutti i vantaggi sopra elencati.

Flessibilità dei mercati ed adattamento delle piattaforme informatiche

Se vi occupate dell’IT in un’azienda, molto probabilmente vi sarà capitato di avere a che fare con i continui adattamenti dei sistemi informatici alla flessibilità di mercato.

Vi sarà capitato di avviare un progetto e, dopo un anno, rendersi conto che le esigenze aziendali erano già cambiate. In questo caso sarete corsi ai ripari cercando di sistemare il progetto già in essere mettendo delle pezze o facendo sviluppare “nuove features”.

Proprio per questo motivo, in tantissime occasioni, sul blog abbiamo spiegato l’importanza di adottare software altamente flessibile.

Per flessibilità di un software si intende appunto la facilità di adattamento ai cambiamenti interni ed esterni all’azienda.

Con il tempo, molti sistemi gestionali, si sono attrezzati in modo da poter installare plugin (addon) completamente integrati con il software stesso ed in grado di rispondere a qualsiasi esigenza.

Questa soluzione permette di non intaccare il “cuore” del gestionale (si deve sapere che ogni modifica di codice al sistema originale può comportare malfunzionamenti al sistema stesso ed occorre necessariamente fare ulteriori e costosi test) e di semplificare notevolmente lo sviluppo del plugin concentrandosi soltanto sulle esigenze da risolvere.

Inoltre è probabile che, prima della vostra azienda, già un’altra realtà aziendale aveva bisogno di risolvere lo stesso tipo di esigenza. Sarà quindi facile trovare un plugin già costruito che risolva quel particolare problema.

Questa soluzione, come avrete capito, farà risparmiare tempo e soldi di sviluppo.

E’ una soluzione che vale la pena adottare soltanto se il gestionale in questione adotta una politica di espansione a plugin, presenta molte verticalizzazioni ed è utilizzato da un numero sufficientemente grande di aziende.

Nel caso in cui non si è deciso di avviare un progetto informatico con strumenti flessibili allora molto probabilmente la vostra azienda sarà invasa da software eterogeneo con conseguente aumento dei costi di manutenzione ed aumento di ridondanza di dati spesso difficili da sincronizzare.

In questi casi si ha la percezione di rispondere in tempi brevi e costi ridotti alle continue richieste di mercato. In realtà, con il tempo, se non si adottano adeguate politiche di integrazione tra i sistemi, i costi di gestione aumenteranno esponenzialmente.

Workflow di documenti: come costruire un processo di approvazione

Una delle funzionalità più importanti di Adempiere è la possibilità di creare e modificare workflow di documenti. Questo rende il sistema flessibile alle esigenze di qualsiasi utilizzatore.

 

In questo esempio mostreremo come modificare il processo di fatturazione del fornitore. In particolare vogliamo introdurre lo stato “approvato” su una fattura di un fornitore.

Il funzionamento che vogliamo ottenere è il seguente.

 

Quando un fornitore emette una fattura, viene inserita nel sistema. Se la somma della fattura è inferiore ai 100.000 euro allora deve essere approvata da un ruolo di amministrazione.

Altrimenti la fattura rimane in stato “non approvata”.

 

modifica del flusso al processo “fatturazione”:

Accedere al sistema tramite il ruolo di SystemAdmin ed aprire la maschera Amministrazione di sistema->Configurazione generale->Workflow->Workflow.

 

Selezionare il processo “Process_Invoice” ed accedere al TAB nodo.

Creare un nuovo nodo (come in figura) che chiameremo “approval step”.


Continua a leggere Workflow di documenti: come costruire un processo di approvazione