Con questo videotutorial mostreremo come si usano i “bottoni” della barra degli strumenti della finestra:
- ricerca e filtri
- export
- report
- stampa e anteprima
In questi tutorial faremo un’ordine di vendita di un prodotto presente in magazzino.
Selezioniamo il prodotto sulla base del suo attributo di istanza e lo spediamo al cliente.
Il primo videotutorial mostra come iniziare da subito a creare un ordine di acquisto per comprare merce e per immagazzinarla in magazzino.
La merce entrerà attraverso un attributo di istanza (lotto) in modo da poter riconoscere univocamente il prodotto.
La nostra azienda si chiama infogest e commercializza semi per piante.
Nel tutorial compreremo 1000 semi di zucca e faremo l’entrata merce specificando l’identificativo del lotto.
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.
- 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.
- 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.
- 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.
- 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.
- 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:
- 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.
- 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.
- 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.
Viste le domande che negli anni mi sono pervenute direttamente sul blog InformaticaGestionale.it provo a scrivere qui alcune considerazioni sul tema ERP in azienda.
Inizierei la discussione a partire dalle prime domande alle quali deve rispondere chi gestirà il progetto di migrazione (project owner) del gestionale: chi promuove l’ERP in azienda? quali sono i principali obiettivi che si vogliono raggiungere? quali sono i reali bisogni?
Questo perchè è necessario rendersi conto sin da subito che massimizzare i vantaggi di un progetto ERP in azienda dipende da tantissimi fattori che non riguardano semplicemente una determinata applicazione software.
BEST PRACTICE PER IL CLIENTE PRIMA DI INIZIARE IL PROGETTO
- fare una buona analisi AS-IS partendo dall’osservazione diretta dell’operatività e produrre un documento TO-BE con le soluzioni proposte: in alcuni casi, dopo una buona analisi, ci si può rendere conto che non per forza adottare un sistema ERP può essere la soluzione più adatta
- automatizzare ed ottimizzare il più possibile i processi aziendali. Un software ERP è più facilmente adattabile su processi ottimizzati e standardizzati. In generale, la reingegnerizzazione dei processi è sempre una buona pratica aziendale.
- coinvolgere tutta l’organizzazione nel progetto di migrazione: informare i vari reparti (anche quelli meno impattati) su come cambieranno i processi e quali sono i risultati che si vogliono ottenere. Creare, laddove possibile, enfasi e promuovere in maniera positiva il cambiamento. Quest’attività deve essere fatta in qualsiasi momento ed in qualsiasi situazione, anche (o sopratutto) in caso di “fallimento” del progetto: un fallimento può essere gestito nel tempo in modo da correggere gli errori e cercare di migliorare. La valutazione negativa delle persone al primo ostacolo in merito al cambiamento rende i miglioramenti più difficili da affrontare.
- partner e software selection: soltanto dopo aver affrontato la fase di analisi si può procedere con la software e la partner selection. Esistono tantissimi software ERP presenti sul mercato; ognuno ha una propria copertura funzionale che dovrà essere studiata dal responsabile del progetto per capire come integrare l’ERP in azienda e, sopratutto, da dove iniziare.
- incaricare un responsabile del progetto: affidare il progetto ad un esperto del settore ERP che lavori per conto del cliente. Può essere un interno oppure un esterno. Non deve essere una persona legata al fornitore per evitare problemi di conflitto di interessi. La persona indicata dovrà conoscere i processi aziendali (abbia almeno partecipato alla fase di analisi), dovrà saper dialogare sia livello tecnico (riesca ad intervenire in caso di soluzioni tecniche non idonee o non ottimizzate) che a livello decisionale sia con i partner che con gli stakeholder aziendali. Dovrà lavorare e collaborare in stretto contatto con i fornitori in modo da mettersi a disposizione per qualsiasi domanda, per visualizzare gli stati di avanzamento, per dare valuazioni sui MVP, per dare feedback, per trasferire le nuove esigenze dei clienti ecc…
- contrattualizzare con il fornitore un approccio “agile” che promuova una stretta collaborazione ed una flessibilità tra le parti al fine di raggiungere gli obiettivi prefissati nei tempi e nei costi stabiliti. In buona sostanza: non più “raccolta esigenze”, “sviluppo”, “test” e “deploy” ma un approccio che si basa su continui feedback di valutazione MVP ed in modo che le decisioni possano essere prese anche in tempo reale. Prevedere in questa fase anche le attività di formazione del personale e degli utenti chiave.
- contrattualizzare con il fornitore (o includere nel contratto) la manutenzione del software (manutenzione ordinaria meglio se a canone, quella straordinaria di solito definito come “costo a giornata”) specificando chiaramente i campi di applicazione: interventi di aggiornamento del software, bug fixing, prevenzione guasti, adeguamento normative ecc.
BEST PRACTICE PER IL FORNITORE
Il cliente soddisfatto di un progetto ERP è fonte di profitto di lungo periodo ed anche di tanti altri progetti satelliti di innovazione che necessariamente dovranno interagire con l’ERP. Quindi, mantenere un’alto grado di soddisfazione del cliente, si rileva molto vantaggioso in termini economici. Al contrario, avere un basso grado di soddisfazione del cliente equivale anche ad esporsi a problematiche di tipo legale (nel caso in cui il cliente si ritenga danneggiato) e di tipo economico (nel caso in cui il sistema presenta molti bug e necessita di continui interventi per funzionare correttamente. Interventi che, in buona parte, sono a carico del fornitore).
Concludo individuando 3 punti di best practice per il fornitore
- interagire continuamente con il cliente ad ogni milestone raggiunto per capire se si sta andando nella direzione corretta e se, nel frattempo, le esigenze non sono cambiate.
- eseguire adeguate sessioni di formazione rilasciando anche manuali d’uso. Un cliente che non sa usare l’applicativo, anche se fatto bene, sarà sempre insoddisfatto.
- contrattualizzare il lavoro con il cliente focalizzandosi su un approccio di stretta collaborazione e di flessibilità. Il cliente è da considerarsi un partner.