Per la versione 2 del suo Erp Freeway® Skyline, Eurosystem ha deciso di cambiare totalmente approccio rispetto al passato, strutturando il sistema in funzione dei processi aziendali. Per definire la nuova metodologia di progettazione, la società si è fatta aiutare dal Dipartimento di Matematica Pura e Applicata dell’Università di Padova, di cui abbiamo intervistato il professor Alessandro Sperduti per approfondire i vari aspetti di questa collaborazione.
ZeroUno: Qual è stato il punto di partenza del lavoro con Eurosystem?
Alessandro Sperduti: Siamo partiti dal fatto che l’obiettivo di un’organizzazione dev’essere la soddisfazione del cliente, e per ottenerlo occorre ottimizzare il processo completo, non singole attività dipartimentali od operative.
Il primo passo, quindi, è individuare i principali processi di un’azienda, core o di supporto. Questi ultimi, per esempio l’amministrazione, possono essere molto simili per aziende diversissime, per cui l’importante è ottimizzare i processi core business, anche per mezzo del sistema informativo. Si passa da una visione funzionale, a silos, a una visione trasversale, sull’intero processo, in cui la singola funzione o reparto può non lavorare in modo ottimale, ma è ottimizzato il risultato finale del processo.
ZeroUno: Quali sono le difficoltà di orientare un sistema Erp per processi?
Sperduti: Non è un lavoro semplice: un’unità produttiva supporta di solito più processi, quindi occorre capire quali attività appartengono a quali processi, e quali processi interagiscono tra loro, dove e come. Il sistema informativo deve supportare questa visione. Prima il lavoro della software house era più semplice, ben delimitato: ci si faceva raccontare i requisiti dal capo funzione, si rimaneva nel singolo dipartimento individuandone le attività da supportare. Quando si ragiona per processi tutto diventa molto più complicato, il processo va studiato dall’inizio alla fine. Inoltre nella visione per processi non esiste workflow ottimo in se stesso: occorre partire dalla strategia di business dell’azienda, e orientare il processo per supportarla. E poi il software da solo non è sufficiente: esistono policy, regole, aspetti chiamati abilitatori, che hanno anche effetto sul software e sul modo in cui si conduce l’analisi dei processi.
ZeroUno: Come è cambiato il processo di Eurosystem di sviluppo del software con questa nuova metodologia?
Sperduti: L’aspetto più critico, che crea le maggiori resistenze organizzative, è la fase di analisi e definizione dei processi. Occorre fare molte interviste, ci vuole tempo, anche perché spesso l’azienda, soprattutto se è piccola o media, ha difficoltà ad esplicitare con chiarezza la propria strategia di business. Inoltre si vogliono risultati subito, spendendo il meno possibile. Quindi abbiamo cercato di snellire il più possibile la metodologia. Eurosystem ora ha gli strumenti per ridurre al minimo i rischi di un progetto di questo tipo ed evitare situazioni in cui il cliente pensa di non ricevere valore dal lavoro della software house.
ZeroUno: Quanto si può preconfigurare il software e quanto va customizzato sul singolo cliente?
Sperduti: Questo dipende da quanto il cliente è disposto a mettere in discussione i propri processi, con la complicazione che spesso c’è scollamento tra la visione che i dirigenti hanno del processo, e il suo workflow reale e quotidiano. Dipende quindi da quanto l’azienda si affida alla software house, alla sua esperienza, ai framework che ha definito nel tempo, alla sua capacità di capire le peculiarità del caso specifico in funzione di molte variabili: la complessità dei processi, gli obiettivi strategici, il budget disponibile. Il rischio è che l’azienda voglia solo automatizzare quel che fa già, anche nelle minuzie, nelle inefficienze: il software in questo caso deve essere molto più personalizzato, ma il problema è che le inefficienze che un processo non informatizzato può mascherare emergono tutte quando si automatizza.
ZeroUno: Quanto può durare questo lavoro di analisi e definizione dei processi?
Sperduti: Dipende da molti fattori, dimensioni, cultura, maturità IT, obiettivi. La metodologia prevede una fase iniziale, che si chiama framing, in cui si cerca di capire lo stato dei processi, come interferiscono tra loro, quali avrebbero bisogno di un intervento più urgente: l’output è una lista di priorità degli interventi necessari sui processi. Questa va discussa con l’azienda, ma anche per interventi molto piccoli non si può pensare di chiudere tutto in una settimana: la fase di analisi richiede tempo, ma anche i ritorni, se il lavoro è fatto bene, sono maggiori.
ZeroUno: Oltre al ‘framing’ iniziale, quali sono le altre fasi della metodologia?
Sperduti: Dopo che si è deciso su quale processo intervenire, c’è una analisi ‘as is’ con cui si fotografa il processo in quel momento. Ci sono molti fattori da considerare l’importante è catturare le informazioni principali senza perdersi nei dettagli. Alla fine c’è un nuovo confronto con l’azienda, in cui si decide come intervenire. Si può concludere anche che il processo ha problemi, ma toccarlo sarebbe rischioso per i possibili impatti su processi molto più critici. Altre volte piccoli interventi portano notevoli benefici nel breve termine, ma certe volte il processo va completamente ridisegnato. Qui ovviamente, oltre agli aspetti tecnologici dello sviluppo software, contano quelli organizzativi: come cambia il lavoro delle persone, le attrezzature necessarie, le nuove responsabilità e procedure, insomma tutti quegli aspetti che possono far fallire il progetto anche se il software è fatto bene.
Poi si passa al ‘to be’, si progetta il nuovo processo: fase che può essere più o meno lunga in funzione di ciò che si è deciso, ma è importante capire le peculiarità di questo progetto rispetto a tutti gli altri. Per esempio può essere necessario un processo particolarmente vicino al cliente, con visualizzazione su un portale di tutte le fasi di lavorazione. Alla fine del ‘to be’ c’è la raccolta dei requisiti tecnici per lo sviluppo e configurazione del software, sempre con l’ottica dell’intero processo e non di singole funzionalità.
ZeroUno: Quali sono le principali differenze rispetto alla metodologia tradizionale di sviluppo?
Sperduti: È fondamentale la partecipazione dell’azienda a tutte le fasi di discussione, la disponibilità di tutti gli attori fondamentali: un problema tipico è l’affidabilità delle informazioni, per cui esistono delle procedure di verifica indiretta. Nel metodo tradizionale invece l’interlocutore è spesso una sola persona, ma questo porta quasi sempre a ricadere nelle solite ottimizzazioni locali. E poi è importante che anche il programmatore abbia competenze di processi, organizzazione e flussi di lavoro, per mostrare al cliente come un certo cambiamento del processo può tradursi in modifiche del software più o meno complesse e lunghe.
Il cuore di questo approccio è l’analisi a monte che mostra in che modo agire e giustifica perché. La soluzione software che si adatta ai cambiamenti aziendali senza richiedere sviluppi è molto importante, ma per averla occorre lasciare alle aziende software il tempo di studiare i processi.
