Questo sito utilizza cookie per raccogliere informazioni sull'utilizzo. Cliccando su questo banner o navigando il sito, acconsenti all'uso dei cookie. Leggi la nostra cookie policy.OK

Erp alla velocità della luce: accelerare o no?

pittogramma Zerouno

Erp alla velocità della luce: accelerare o no?

29 Nov 2007

di Stefania Chines

Realizzare una rapida implementazione di un Erp può essere di grande utilità per un’azienda, quando accompagnata dalla giusta strategia e da strumenti corretti.  Ma esistono anche degli svantaggi, che toccano molto da vicino la piccola e media impresa italiana, che si trova in un contesto di mercato molto particolare

Secondo una ricerca sviluppata da Performance Monitor, i clienti che implementano l’Erp per la prima volta sono intimiditi dai tempi e dai costi dell’implementazione stessa e cercano di accelerare il “go-live”.
Questa accelerazione, quando accompagnata dalla giusta strategia e da strumenti corretti, può portare benefici, inclusa una riduzione dei costi e, nello stesso tempo, un ridotto time-to-benefit. Tuttavia, senza la giusta strategia e gli strumenti adeguati, un’accelerazione dell’implementazione comporta il rischio di abbreviare il training dell’utente finale e il cosiddetto change-management, la mancanza di una pianificazione a posteriori, il problema di un’over-engineering e altri inconvenienti che di fatto conducono a una maggiorazione dei costi (ed erosione dei benefit). In alcuni casi, quindi, il dilemma è: accelerare o non accelerare? Senza accelerazione, l’implementazione costerebbe di più, ma altri rischi sarebbero mitigati. Quindi la domanda potrebbe diventare: costi o rischi? Sembra essere proprio questa l’inevitabile scelta da compiere.
Prima del 1997, la metodologia di un’implementazione si svolgeva in due fasi: l’As-Is, che descriveva lo status quo dei processi di business, e il To-Be, che descriveva il passaggio dallo status quo (as-is) al processo (to-be), che eliminava i punti deboli fino al raggiungimento degli obiettivi e dei benefit che ci si era prefissati. Ma tutto ciò spesso comportava una lievitazione dei costi e lo sforamento dei tempi. Dal 1997 in avanti, sono nate nuove metodologie. L’approccio informatico è diventato più diretto. Si è, per esempio, iniziato ad usare sale conferenze, template, best practises che però hanno saturato in breve tempo il mercato, divenuto teatro di innumerevoli di casi di successo, frutto di sei mesi, quattro mesi e persino di due settimane di implementazione.

Se da un lato è vero che le nuove metodologie hanno aiutato a ridurre il tempo necessario all’implementazione, tuttavia si sono venuti a creare nuovi problemi come, per esempio, un’inadeguata conoscenza delle tecnologie, un change-management troppo rapido e una carente pianificazione post implementazione. Nei ultimi dieci anni, la maggior parte delle metodologie sono state ridefinite per risolvere tali problematiche, ma nonostante ciò, nel caso di un’implementazione accelerata, alcuni rischi permangono a tutt’oggi, sia per il mercato italiano sia per quello americano.

Il modello italiano
Secondo Stefano Mainetti (nella foto), docente di Tecnologie dei Sistemi Informativi al Politecnico di Milano e responsabile scientifico dell’Osservatorio Ict e Pmi della School of Management del Politecnico con Andrea Rangone e Raffaello Balocco, “rendere veloce l’implementazione di un sistema di gestione comunemente denominato Erp, Enterprise Resource Planning, che in italiano si traduce letteralmente con “pianificazione delle risorse d’impresa”, per le Pmi italiane in particolare potrebbe essere il coronamento di un sogno: riduzione dei costi e dei tempi”. Ma non sempre è così. “Oggi i sistemi Erp permettono di realizzare sistemi informativi – continua Mainetti, –  in grado di integrare tutti gli aspetti del business e i suoi cicli. Vale a dire, per esempio per il settore del manufacturing, supportano la pianificazione, la realizzazione del prodotto, le vendite, gli approvvigionamenti, gli acquisti, la logistica di magazzino, il marketing, ecc. Di fronte a queste considerevoli potenzialità, l’azienda che intende adottarli si trova a dover decidere quanto cambiare il proprio modo di operare, a partire dalla situazione attuale (“as-is”), per giungere a una situazione obiettivo (“to-be”). Soprattutto nel primo periodo storico di adozione (anni ’90), la scelta di miglioramenti considerevoli da raggiungere, sia di tipo organizzativo sia tecnologico, ha comportato in molti progetti notevoli sforamenti nei tempi di progetto e nei costi pianificati in prima istanza, associati anche a risultati complessivi inferiori alle attese”.
Spesso si correva il rischio di promettere un sogno. E questo accadeva soprattutto quando l’Erp veniva proposto a una piccola e media impresa, che non possiede le risorse di una multinazionale. L’uscita dal tunnel appariva lontana, e solo in corso d’opera ci si accorgeva come fosse difficile raggiungerla.
“La modalità più comune di procedere nel progetto era quella di verificare in corso d’opera come proseguire nell’implementazione, modulando tempi e costi di conseguenza – spiega Mainetti. – I contratti con i system integrator non potevano che essere del tipo “time&material”. Questo modo di procedere, se associato a una buona capacità di investimento e a una determinazione tipica delle aziende di grandi dimensioni o delle multinazionali, ha garantito il successo di molte iniziative, ma ha contribuito anche a creare un certo timore da parte delle medie aziende italiane. In qualche modo, gli indubbi vantaggi derivanti dall’adozione di un sistema Erp, venivano posti in secondo piano di fronte ai rischi derivanti dai costi e dalla complessità dell’iniziativa”.
Si è passati quindi, in particolare per le Pmi, a una seconda fase, quella che viene seguita a tutt’oggi: “Per contenere i rischi – prosegue Mainetti – si è passati a implementare il processo basandosi su di un modello precostituito, che prevedeva per le Pmi un contratto “chiuso”, vale a dire con maggiori garanzie in termini di tempi e costi di adozione. Cambia anche il modo di proporre l’Erp, non più in una forma generica, ma in una forma più adatta alle esigenze specifiche di una Pmi (forma da alcuni chiamata light, leggera), opportunamente specializzata per le esigenze del settore merceologico di appartenenza (verticalizzazione). L’implementatore porta in dote alla Pmi le esperienze fatte sui precedenti clienti dello stesso settore, concedendo così la possibilità di importare delle vere e proprie “best practice”, cioè il modo migliore di fare qualcosa che vince sul mercato, di organizzare un’attività. E così, ecco che anche la piccola azienda della Val Brembana ha la possibilità di organizzarsi come General Motors”.

I benefit di un’implementazione accelerata
Secondo quanto emerge dallo studio Performance Monitor, l’elemento cruciale di un’accelerazione (light) è il riutilizzo degli asset esistenti.  In effetti, i processi preconfigurati possono essere facilmente implementati. Il riutilizzo dipende dalla capacità di un cliente di adattarsi ai nuovi processi di business piuttosto che accada il contrario, e cioè che occorra adattare il software al cliente. Più il cliente si avvicina a questo principio, più veloce sarà l’implementazione (anche per la grande azienda).
Cinque benefit chiave possono derivare infatti da un’implementazione accelerata: riduzione dei tempi e dei costi; minore distruzione delle operazioni preesistenti; probabilità ridotta di ave installato un sistema superiore alle necessità dell’azienda (over-engineering); tempi accelerati nel raggiungimento dei benefit.
Si comincia con i tempi e con i costi, che costituiscono gli indicatori tradizionali di un successo. Un’implementazione accelerata viene richiesta dal cliente innanzi tutto proprio per ridurre i tempi di implementazione e, di conseguenza, il time-to-benefit. In entrambi i casi, si avrà una riduzione dei costi.
Il livello concernente la riduzione dei costi non riguarda semplicemente il totale delle ore spese per l’implementazione, ma riguarda anche la relazione che si instaura col system integrator. Il cliente può scegliere se collaborare attivamente con il system integrator o se ridurre al minimo il proprio intervento.
Un altro vantaggio di un’implementazione accelerata è la ridotta probabilità di un’”over-engineering”. Seguendo maggiormente metodi standard di implementazione, il business process design e le attività di configurazione del software tendono a condurre alla ricerca di un processo “ideale”.
Una caratteristica di un’implementazione accelerata è la riduzione della fase di business process design (anche detto blueprint), nel momento in cui i clienti accettano processi di business già sperimentati. Questo tipo di processi non sono “over-engineered e spesso sono preconfigurati, cosa che contribuisce a una riduzione di un processo di configurazione.
In ogni implementazione, man mano che i clienti imparano a conoscere l’Erp, scoprono che possono fare di più di quanto fosse incluso nel progetto iniziale. La tentazione è di espandere l’obiettivo per includere nuovi benefit, che allungherebbero però i tempi di go-live. Con il termine “scope creep” si suole identificare quelle funzionalità aggiuntive che non erano state specificate nei requisiti originali, ma che sono state individuate quando l’ambito dell’applicazione è stato chiarificato e le sue funzioni sono state definite. Ma ciò non va bene per l’Erp, che comprende una suite di applicazioni, ma solo per applicazioni individuali. Eventuali benefit ulteriori, non facenti parte del progetto iniziale, possono essere perseguiti dopo il go-live. In ogni caso, i clienti devono adottare una strategia di continuous business improvement dopo il go-live, in cui i processi di business (e, di conseguenza, la configurazione) proseguono.
Accanto alla riduzione dei costi, il vantaggio maggiore di un’implementazione accelerata è la riduzione del time-to-benefit. A seconda degli obiettivi di business, questa riduzione può essere marginale o drammatica. Per esempio, se un cliente sta affrontando un nuovo mercato che richiede questo tipo di software, la differenza fra un’implementazione di sei mesi o di dieci potrebbe essere drammatica.

Il ruolo chiave del system integrator
“In questa seconda fase di implementazione di un Erp, in Italia in particolare ci sono stati dei cambiamenti nel ruolo degli attori – dichiara Mainetti. – A partire dal produttore dell’Erp, che ha dovuto organizzare una rete di partner maggiormente specializzati per dimensioni di aziende e settori industriali, ai singoli system integrator che, a partire da forme contrattuali nuove, hanno dovuto proporre progetti con rischi contenuti e tempi e costi molto più affidabili. Per quanto riguarda i contratti, in alcuni casi oggi si arriva a definire delle vere e proprie partnership con le aziende clienti, magari anche con il riconoscimento di royalties nel caso di rivendita da parte del partner di un modulo sviluppato sulla base dell’esperienza dell’azienda cliente. Per ciò che concerne il contenimento dei rischi, si cerca oggi di organizzare l’implementazione del sistema in piccoli passi molto concreti, cercando di fare percepire da subito, al management e all’imprenditore, il reale valore della scelta fatta”.

I rischi di un’implementazione accelerata
A fronte di una standardizzazione dei processi aziendali, stabilire un senso di urgenza è essenziale per il successo di un’implementazione accelerata. Talvolta però il senso di urgenza finisce per destare allarme perché le scadenze stanno allontanandosi e i budget sono ristretti.
I rischi principali per un cliente che opta per un’implementazione accelerata sono: di abbreviare il training dell’utente finale; di ridurre o di rendere inadeguato il change management; un carente transfer della conoscenza; una carente pianificazione post-implementazione.
L’utente finale compie i processi di business che sono supportati da un software Erp e la loro competenza, o la mancanza di questa, ha un effetto diretto sull’efficacia di questi processi. Sfortunatamente, il training dell’utente-finale è uno degli aspetti più trascurati dell’Erp ed è ancora più trascurato nel caso di un’accelerazione. Il training costituisce l’ultimo step prima del go-live e se il progetto è in ritardo o sta sforando il budget, la tendenza è di abbreviarlo in modo da risparmiare tempo.
Inoltre, un cambiamento nell’organizzazione del management, in un’implementazione accelerata può scaturire in un tempo insufficiente per orientare il proprio staff verso i nuovi processi di business.
Correre verso il go-live senza avere una visione a lungo termine è un altro dei rischi di un’implementazione accelerata. In sostanza, i clienti dovrebbero vedere la fase di implementazione come uno “sposalizio” e la consegna del software come “il matrimonio”. Mentre la cerimonia può durare sei mesi o più, il matrimonio può durare vent’anni.
Un fallimento della fase post-implementazione in cui il cliente dovrebbe essere in grado di operare e migliorare l’Erp condurrà a erodere i benefit.

Declassamento dell’obiettivo
Alla base dell’implementazione di un Erp, c’era (e c’è tuttora) l’obiettivo di un cambiamento ambizioso, il cosiddetto “to-be”, che potrebbe quindi, con un’implementazione accelerata finire per essere declassato.
“Non necessariamente – sostiene Mainetti. – Partendo da una base di esperienza concreta, quale quella del sistema verticalizzato e di un partner con più esperienze maturate nello stesso settore, è possibile costruire dei primi passi progettuali molto concreti e sicuri. In questo primo momento, l’azienda cliente ha il tempo di “crescere” assieme al nuovo sistema e di porsi nelle condizioni ideali per perseguire obiettivi susseguenti più ambiziosi. In pratica, agendo in questo modo, si va a contenere il rischio dell’”over-engineering” dei processi, preferendo una tecnica chiamata di “continuos improvement””.
“Infine – tiene a far presente Mainetti, –  anche dal punto di vista tecnologico, le tecnologie oggi allo stato dell’arte quali Soa (Service Oriented Architecture) e Bpm (Business Process Management) tendono ad avvalorare questo nuovo modo di procedere in quanto rendono il sistema maggiormente flessibile ai cambiamenti. Cambiamenti che possono quindi essere apportati in modo continuo, senza richiedere livelli di costi simili a quelli sostenuti per la prima implementazione del sistema, ma che richiedono al contempo un’azienda “capace” di fare evolvere il proprio sistema informativo in modo coerente alle proprie esigenze di business”.

Stefania Chines

Articolo 1 di 5