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.

Progetto ERP in azienda, best practice per massimizzarne i vantaggi

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

  1. 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
  2. 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.
  3. 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.
  4. 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.
  5. 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…
  6. 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.
  7. 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

  1. 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.
  2. 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.
  3. contrattualizzare il lavoro con il cliente focalizzandosi su un approccio di stretta collaborazione e di flessibilità. Il cliente è da considerarsi un partner.

Come capire se il cliente sarà un cattivo pagatore con l’intelligenza artificiale, un pratico esempio

medium economic 1 day

Oggi scopriremo, grazie ad un algoritmo che implementa il classificatore di Naive-Bayes (un classificatore che si basa sul teorema delle probabilità di Bayes), come individuare preventivamente se i clienti (o potenziali clienti) saranno buoni o cattivi “pagatori” per un particolare prodotto o servizio.

Buona parte dei sistemi gestionali permettono di esportare l’elenco dei clienti e la rispettiva situazione delle fatture saldate o insolute.

Queste informazioni sono fondamentali per il riconoscimento predittivo e rappresentano il training set dell’algoritmo.

Più l’esportazione è dettagliata e migliore sarà l’accuratezza della predizione.

Continua a leggere Come capire se il cliente sarà un cattivo pagatore con l’intelligenza artificiale, un pratico esempio

Predizione di un evento attraverso Naive Bayes OnLine

InformaticaGestionale.it propone ai suoi lettori il nuovo servizio online che sfrutta il teorema di Bayes per fare predizioni di qualsiasi tipo grazie ad un set di dati storici eseguiti su specifici attributi. L’obiettivo è predire un determinato target o valore a partire da un nuovo set di attributi.

Questo può essere utile in moltissimi campi di applicazione: dal sociale alla medicina, dalla manutenzione alla produzione industriale.

Ecco una carrellata di esempi:

  1. lotti di produzione PC difettosi sulla base di attributi come temperatura (alta, media, bassa), velocità di produzione, tipo PC (standard, custom), qualità materiali (ottimo, scarso, buono). Riusciamo quindi ad identificare se un lotto sarà difettoso oppure no.
  2. l’acquisto di un prodotto da parte di un potenziale cliente in base ad attributi quali dimensioni azienda (piccola, media o grossa), tipologia azienda (servizi o manifatturiera), prezzo del prodotto.
  3. capire se una persona ha una determinata malattia sulla base di attributi quali sintomi, sesso, esami che determinano se l’individuo è malato oppure no.
  4. capire se un macchinario industriale ha bisogno di manutenzione (in modo da prevenire eventuali guasti) sulla base del tempo di funzionamento, velocità di produzione, complessità del prodotto (semplice, medio, complesso).

Il modello matematico utilizzato è basato su record storici che sono stati preventivamente inseriti (training_set). In base a questi record è possibile predire una determinata condizione preventivamente inserita nel testing_set.

Il calcolo della probabilità condizionata per ognuna delle casistiche determina la probabilità che si verifichi l’evento 1 oppure l’evento 2.

La predizione verrà orientata sull’evento con più alta probabilità.


 

ad esempio:

Data la seguente traingin table, vogliamo predire il valore della riga segnata in giallo (testing table)

 

TIPO AUTO TIPO GUIDA TIPO STRADA KM PERCORSI PREZZO AUTO TARGET
SUV SPORTIVA MISTO 4000 65000 NO MANUTENZIONE
UTILITARIA PASSEGGIO CITTA 80000 30000 MANUTENZIONE
SUV PASSEGGIO MISTO 15000 80000 NO MANUTENZIONE
UTILITARIA SPORTIVA CITTA 8000 20000 MANUTENZIONE
MONOVOLUME SPORTIVA MISTO 4000 65000 NO MANUTENZIONE
MONOVOLUME LAVORO CITTA 80000 40000 NO MANUTENZIONE
SUV LAVORO MISTO 250000 120000 MANUTENZIONE
UTILITARIA LAVORO AUTOSTRADA 70000 10000 MANUTENZIONE
UTILITARIA SPORTIVA MISTO 200000 12000 TO PREDICT

 

Secondo Naive Bayes il valore predetto è MANUTENZIONE : 3.6747338165603E-13

Se, invece di mettere 200.000 km percorsi mettiamo solo 20.000km allora la macchina risulta in NO MANUTENZIONE

qui l’esempio, potete provare a cambiare il testing set e visualizzare il valore predetto: ESEMPIO1

Clicca qui per la DEMO

IdempiereIOT: gestione delle risorse fisiche aziendali

Per risorse fisiche intendiamo tutti i beni “tangibili” in un’azienda, siano essi di supporto oppure di core-business:

  • documentazione cartacea (es. cartelle cliniche, cartelle giuridiche, fatture, ordini…)
  • dispositivi elettronici aziendali (server, PC, notebook, tablet, smartphone, allarmi…)
  • parco auto aziendale
  • macchine industriali
  • sensori e attuatori

IdempiereIot prevede la gestione “intelligente” di questi dispositivi:

  • Virtualizzazione dei beni aziendali: ogni bene aziendale può essere associato su Idempiere: è possibile categorizzarlo, inserire informazioni aggiuntive (es. data prossimo controllo), link ad allegati…
  • Gestione dello stato del bene: (es. occupato, disponibile, guasto…)
  • Interazione con altri beni aziendali: (es. se un server lavora per diversi giorni con temperature ambiente troppo elevate allora si presume, in base ai dati storici, che si danneggi nel giro di poco tempo. A questo punto il “motore centrale” invia un alert all’operatore ed invia un segnale al termostato per abbassare automaticamente la temperatura).
  • Interazione con il sistema ERP: es. associazione di un bene ad un dipendente (es. assegnazione di un notebook aziendale), condivisione di un bene con più dipendenti (es. macchina industriale), tempo di utilizzo di un bene da parte di un dipendente, scannerizzazione tag cespite direttamente sul “bene”…
  • Storicizzazione di tutti gli eventi avvenuti su qualsiasi bene virtualizzato.
  • Acquisizione informazioni di un “bene” attraverso il proprio smartphone fotografando il qrCode o avvicinando l’NFCTag associato tramite l’applicazione FlowItems.
  • Dashboard con analisi in tempo reale

NodeRed è il motore che gestisce i beni aziendali tramite protocolli standard e li mette in comunicazione con Idempiere attraverso i webservices.

RealTime analysis

Nel caso di gestione di macchine industriali questa soluzione rientra nelle specifiche dell’industria 4.0.

L’architettura del sistema è studiata per essere facilmente adattabile alle necessità di ogni cliente.