appunti

I SISTEMI ERP 1
ERP (Enterprise Resource Planning) indica un insieme di programmi e moduli software per supportare la gestione
informativa di tutte le risorse e aree aziendali in modo integrato. Dal punto di vista tecnico, una delle caratteristiche
fondamentali di una suite 2 ERP è il fatto di basarsi su una piattaforma unica e integrata che permette una gestione
unificata dei processi aziendali e dei relativi flussi di dati.
Origini
Generalmente l’origine dei sistemi ERP viene fatta risalire allo sviluppo dei software per la gestione dei materiali in
produzione (Bracchi et al., 2010), attorno ai quali sono stati poi realizzati altri moduli che gestiscono i flussi informativi
dei processi correlati (dagli ordini alle fatturazioni alla contabilità, ecc.). Prescindendo comunque dai primi semplici
software per supportare i processi primari di produzione, per la gestione delle scorte o il calcolo del punto di riordino
(Inventory Control System), i primi veri precursori degli ERP sono considerati i sistemi MRP (Material Requirements
Planning) e soprattutto gli MRP II (Manufacturing Resource Planning). Lo sviluppo di questi sistemi ha rappresentato il
primo concept tecnologico che fu poi la base e il prerequisito per gli ERP: infatti è con gli MRP che vennero per la
prima volta definiti e testati i principi e i metodi (sia manageriali che di elaborazione) che avrebbero poi dato luogo ai
sistemi ERP. Oggi gli stessi sistemi MRP e MRP II, molto usati nelle aziende manifatturiere, spesso sono moduli di un
sistema ERP.
L’idea innovativa alla base sia di MRP che di MRPII è di centralizzare e integrare le informazioni “di business”
utilizzate per determinate procedure o per prendere determinate decisioni. Uno dei problemi centrali su cui venne
focalizzata l’attenzione fu quello del calcolo dei fabbisogni sulla base delle previsioni di produzione o della domanda,
in modo da gestire gli ordini di materiali nella tempistica nelle quantità appropriate. Come è noto, si tratta di un
problema complesso da risolvere sia dal punto di vista della modellazione matematica che degli algoritmi di risoluzione,
e quindi l’uso di applicazioni specifiche da incorporare nel sistema informativo aziendale fu ritenuta la soluzione più
adeguata. Nacquero i primi MRP che furono all’inizio creati apposta per le grandi imprese e incorporati nei loro
mainframe. Successivamente i sistemi MRPII, che rappresentano un’estensione del concetto di MRP, ebbero l’obiettivo
di integrare altri tipi di informazione altrettanto importanti per il buon funzionamento di un processo manifatturiero
(come ad es. i dati dei carichi delle macchine, la disponibilità di manodopera, eccetera) e le relative procedure
decisionali (ad es. schedulazione, lanci in produzione, ecc.). Inizialmente, per i primi sistemi di questo tipo introdotti
verso gli anni ’80, le tecnologie informatiche e i concetti dei database relazionali non erano ancora sufficientemente
efficaci per la capacità elaborativa che i calcoli richiedevano. Però fu comunque importante il fatto che venne introdotto
il concetto di un nuovo approccio ai sistemi informativi in direzione di una maggiore integrazione di tutte le
informazioni che servono al business. Il successivo sviluppo della tecnologia da un lato e dall’altro la crescente
attenzione sui processi aziendali come elemento chiave del funzionamento delle organizzazioni furono poi alla base dei
moderni sistemi ERP.
Verso gli anni ’90 le aziende produttrici di software incominciarono a realizzare pacchetti che integravano anche le
attività di amministrazione-finanza-controllo (contabilità, bilanci, documenti fiscali, ecc.) e poi vendite e distribuzione
(ad es. ciclo dell’ordine), e poi progressivamente le altre aree aziendali. L’incontro fra la domanda di ERP specialmente
da parti delle grandi multinazionali, e un’offerta sempre più matura tra cui in particolare quella di alcune società
specializzate (come JD Edwards e SAP) ha portato pian piano allo sviluppo di un vero e proprio settore dell’informatica
aziendale.
La principale direzione di sviluppo dei sistemi ERP è oggi rappresentata dalla gestione dei flussi di comunicazione con
altre aziende (dai fornitori ai clienti) attraverso la connessione o l’incorporazione di altri software (dai CRM – Customer
Relationship Management – agli SCM – Supply Chain Management, e più in generale alle applicazioni di commercio
elettronico). Ad esempio con l’acronimo ERP II (Extended ERP) si indica un sistema ERP predisposto per una gestione
integrata dei flussi di comunicazione con le catene di fornitura.
Il mercato degli ERP è oggi tuttora dominato da grandi multinazionali tra cui spicca la tedesca SAP, che detiene tuttora
circa il 40% dell’intero mercato ERP mondiale ed è in pratica l’unica grande azienda specializzata integralmente in
piattaforme ERP. Altri importanti vendor sono i colossi Microsoft e Oracle, che non essendo peraltro specializzati in
questi tipi di sistemi sono entrati nel mercato attraverso l’acquisizione di precedenti operatori.
Accanto ai grandi sistemi, che sono spesso ritagliati sulle esigenze dei grandi clienti multinazionali, esistono però molti
piccoli operatori software “locali”, specializzati in sistemi di minore dimensione e con costi più bassi, e spesso
progettati per esigenze molto specifiche di clienti di modeste dimensioni (tipicamente piccole e medie imprese). In Italia
ad esempio e in particolare nel Nordest sopravvive ancora un certo mercato di sistemi ERP “locali”, progettati per le
1
2
Questi appunti sono destinati esclusivamente alla didattica nel corso di Gestione dell’informazione e delle aziende in rete. Ogni
altro uso non è consentito. Si tratta inoltre di appunti in forma di “bozza” non certo completa né esaustiva e che riprendono
solamente i vari punti trattati a lezione.
Il termine suite indica un insieme di programmi che svolgono funzioni tra loro connesse e che generalmente condividono
un’interfaccia comune e/o database in modo da facilitare l’interscambio di dati e interconnettere le varie funzioni. Noti esempi di
suite sono i pacchetti di tipo office.
esigenze di un tessuto industriale di medio-piccola dimensione che spesso non è in grado di affrontare il costo e i
problemi di implementazione di sistemi complessi e costosi come SAP. A favore dei sistemi di piccola dimensione c’è
inoltre il fatto che le piccole e medie imprese hanno generalmente processi interni di gestione che sono da un lato meno
complessi delle grandi multinazionali dall’altro presentano particolarità e specificità che non sempre un software
progettato per una multinazionale è in grado di supportare efficacemente.
Infine vanno citati i progetti ERP Open Source; questi sistemi hanno il vantaggio di non comportare costi di licenza
(secondo la logica propria dei sistemi open source) e tuttavia le piattaforme open non sembrano ancora in grado di
competere efficacemente con i sistemi “proprietari” in termini di efficacia e di rispondenza alle esigenze della domanda.
Caratteristiche
Gli ERP (che in Italia talvolta sono chiamati talvolta anche se un po’ impropriamente sistemi gestionali) sono sistemi
che integrano in un’unica piattaforma varie applicazioni e moduli specializzati per le diverse funzioni, processi e attività
aziendali. Le diverse applicazioni e moduli condividono i dati (memorizzati in un unico database) nonché varie
funzionalità. Le caratteristiche principali delle piattaforme ERP sono di seguito riassunte (cfr. anche Bracchi et al.
2010).
Unicità dell’informazione
Si intende con questo termine il fatto che tutte le diverse operazioni ed elaborazioni dei vari moduli del sistema
condividono per ciascuna informazione uno e un solo “valore”. Significa ad es. che il “codice cliente” è lo stesso sia che
il sistema stia registrando un ordine di vendita, sia che stia emettendo una fattura, o lanciando un lotto in produzione.
L’unicità dell’informazione è ottenibile realizzando un unico database centrale, sul quale potranno operare i diversi
moduli software (cfr. figura).
Server
(elaboratore centrale)
con database
condiviso
acquisti
vendite
personale
…… …
produzione
Naturalmente il database centrale condiviso dovrà essere organizzato in modo opportuno. Ad esempio, supponendo di
memorizzare i dati dei clienti in un’apposita scheda, questa potrà contenere diversi campi con differenti informazioni,
ciascuna delle quali interessa ed è di competenza di un’area o ufficio specifici. In altri termini, l’informazione è
centralizzata ma si deve stabilire quali parti di essa è di competenza di chi (cfr. figura).
ANAGRAFICA CLIENTE
(fonte: tratto e adattato da Camussone, 1998)
L’unicità della base dati è un’acquisizione importante dei sistemi ERP e che consente vantaggi essenziali come ad es.:
- la sincronizzazione dei dati: il dato presente nel database è sempre la versione più aggiornata disponibile, e
inoltre risulta identica per tutti gli utilizzatori del sistema evitando quindi il rischio di inconsistenze,
incongruenze o errori (ad es. un codice cliente diverso stampato sui vari documenti comporta notevoli perdite
di tempo per correggere il problema)
- la fissazione dei diritti di accesso, rendendo possibile per ciascun dato stabilire chi può leggerlo, modificarlo,
crearlo, ecc.
- la tracciabilità degli aggiornamenti, ossia rendere possibile conoscere chi e quando ha aggiornato un dato
campo e facilitando quindi il controllo delle operazioni
Naturalmente, la centralizzazione dell’informazione richiede alcune attenzioni particolari quali in particolare:
- la necessità di stabilire in modo accurato i diritti d’accesso alle specifiche porzioni di dati, per evitare sia errori
sia accessi non autorizzati; questo ha non solo implicazioni tecniche ma anche di carattere organizzativo
- un sistema robusto di salvaguardia dei dati a fronte di possibili malfunzionamenti del database centrale. Infatti
dato che il database è critico per il funzionamento dell’intera azienda, si richiedono sistemi di duplicazione e di
backup che permettano di recuperare rapidamente i dati nel caso di problemi
- un sistema di connessione veloce che permetta a tutte le aree interessate di accedere ai dati che servono in
tempi rapidi.
Focalizzazione sui processi
I sistemi “dipartimentali” progettati per le specifiche aree funzionali dell’azienda hanno come riferimento il modo con
cui funziona un certo ufficio, le procedure utilizzate dai suoi membri, ecc. Questo significa ad esempio che un sistema
informativo dedicato all’amministrazione sarà progettato per fornire funzionalità relative ad esempio alla contabilità
(archiviazione documenti commerciali e pratiche fiscali, calcoli contabili e di bilancio, ecc.). Implicitamente, la visione
dell’azienda è quella di una struttura strettamente funzionale in cui l’efficienza di ciascun ufficio richiede una
separazione ben definita di compiti e attività, e quindi anche di dati e informazioni.
Nell’approccio ERP si adotta invece una visione per processi: l’ipotesi è che molte attività critiche in azienda
richiedano per il loro svolgimento che siano coinvolgano più uffici. I flussi informativi attraversano quindi
trasversalmente l’organizzazione. Il progetto di un sistema ERP è quindi basato sull’identificazione dei processi critici e
della loro informatizzazione. Ad esempio, il ciclo dell’ordine è un tipico processo critico, che prevede il coinvolgimento
di più uffici e funzioni aziendali le quali devono interagire e scambiarsi informazioni (nella forma di documenti o altri
supporti) perché il processo si possa compiere in modo efficace. In sintesi un ERP richiede di ricostruire le attività
svolte in un processo, le informazioni che sono necessarie, chi utilizza o manipola tali informazioni nelle varie funzioni
e uffici aziendali, il flusso di autorizzazioni o workflow che a cascata consentono di far avanzare il processo, ecc. Il
sistema informatico supporta questo processo in modo trasversale rispetto alla struttura aziendale.
Naturalmente una focalizzazione sui processi ha implicazioni importanti. Innanzitutto, per il progetto di un ERP si
rende necessario identificare in modo formalizzato i processi critici da informatizzare, che devono venire analizzati e
descritti formalmente e in modo dettagliato per poter poi progettare i database nonché i vari moduli software che
manipoleranno i dati. In secondo luogo, molti processi coinvolgono più funzioni aziendali che potrebbero però
utilizzare procedure diverse tra loro non del tutto compatibili: per usare un sistema ERP si rende necessaria una
convergenza nelle modalità di lavorare da parte di tutti gli uffici coinvolti in un dato processo.
Approccio transazionale “event-driven”
Nei sistemi ERP la focalizzazione sui processi che “percorrono” trasversalmente l’organizzazione è un salto importante
dal punto di vista organizzativo. Questa prospettiva è talvolta anche denominata “transazionale”: ogni “evento”
aziendale significativo (contabile o operativo) genera una “transazione” che viene istantaneamente registrata e ha effetto
contestuale su tutte le parti del database dell’ERP coinvolte. Ad es. l’immissione di un nuovo ordine da parte di un
cliente innesca un aggiornamento del database in tutte le parti che sono coinvolte da questa attività del processo. In
sostanza l’azienda viene vista come un sistema nel quale un evento (come l’inserimento di un ordine) determina un
cambiamento di stato che va registrato a livello di tutto il sistema. Per realizzare ciò, il database interno dell’ERP è
tipicamente organizzato in forma relazionale con molte (anche migliaia!) di tabelle che devono essere tra loro correlate
in modo da registrare opportunamente il cambiamento di stato generato dall’evento. La struttura “logica” dei dati è
indipendente dalla struttura “fisica” (ossia dove sono registrati e in che modo): l’importante è che ciascun evento e
ciascuna transazione innesca un aggiornamento di TUTTE le tabelle su cui essa ha effetto: ad esempio l’immissione del
nuovo ordine diventa UNIVOCAMENTE IDENTIFICATO per tutti gli utenti ERP.
Nella logica di funzionamento del sistema informativo il cambiamento rispetto ai tradizionali sistemi dipartimentali
organizzati per funzione aziendale è significativo. Si consideri ad esempio il ciclo dell’ordine come potrebbe venire
gestito in un sistema informativo organizzato per funzioni (cfr. figura seguente). La transazione ossia il cambiamento di
stato del “sistema azienda” è sempre innescata da un unico evento (l’arrivo dell’ordine) ma pur trattandosi di un unico
evento tutti i suoi effetti a cascata invece che venire registrati in modo unitario devono essere registrati in modi diversi e
in tempi diversi dato che l’organizzazione è strutturata per funzioni distinte. Questo lascia evidentemente grande
autonomia operativa alle singole funzioni aziendali ma può determinare problemi in termini di precisione, univocità dei
dati, tempo di processamento, efficace comunicazione, ecc.
Ordine
VENDITE
Registrazione
interna ordine
Registrazione
movimento
contabile
Aggiornamento
inventario
Fonte: adattato da Università di Torino, 2003
Inoltre, ciascun ufficio aziendale per poter registrare correttamente gli effetti dell’evento-transazione potrebbe dover
disporre di dati che si trovano in parti diverse dell’azienda. Ad es. per registrare l’arrivo dell’ordine l’ufficio contabilità
potrebbe dover identificare il cliente, la sua posizione fiscale, il codice prodotto, ecc. – tutti elementi che sono
tipicamente registrati nei database delle singole aree di competenza (ad es. la posizione fiscale del cliente negli archivi
della contabilità, mentre il codice prodotto sarà registrato nell’area produzione, ecc.). In un sistema informativo
organizzato per funzioni se si vuole che tutti questi dati siano corretti e trattati in modo coerente sarà quindi necessario
attingere da fonti distinte nell’azienda (produzione, vendite, finanza, ecc.) – cfr. figura seguente. Tuttavia, considerata la
strutturazione funzionale questo potrebbe non essere semplice e porre problemi di consistenza dei dati, velocità, ecc.
In figura: l’evento “nuovo ordine” verrà trattato attingendo dati da fonti diverse nell’organizzazione
Fonte: Università di Torino, 2003
In un sistema ERP si cerca di superare tutto questo gestendo l’arrivo dell’ordine come se fosse un evento unitario che
genera istantaneamente un aggiornamento dello stato del sistema in tutte le parti in cui è necessario (cfr. figura
seguente).
Fonte: Università di Torino, 2003
L’evento ha effetto contemporaneo sul database centralizzato. Allo stesso modo, per la registrazione dell’evento e il
recupero di eventuali dati preesistenti il sistema accede all’unica fonte sempre rappresentata dal database centralizzato
(cfr. figura seguente)
L’evento “arrivo dell’ordine” registrato in modo univoco attraverso un’azione contestuale nel database centralizzato
Fonte: adattato da Università di Torino, 2003
Modularità ed estendibilità
Anche se l’ERP si propone come un sistema unico e centralizzato, la sua implementazione nelle aziende sarebbe molto
ardua se non fosse organizzato a moduli. In sostanza, attorno al “cuore” centralizzato del sistema, che contiene in
sostanza gli strumenti di base per la gestione del database, sono agganciati diversi moduli ciascuno specializzato in
funzionalità o processi specifici. Nella figura seguente si riporta a titolo di esempio una tipica rappresentazione del
celebre sistema SAP R/3 (dove ad es. FI è il modulo “financial accounting”, PP “production and planning”, CO
“controlling”, SD “sales and distribution, MM “Materials management”, ecc.): ciascun modulo interagisce in modo
predefinito con il database centrale, ma realizza operazioni diverse in relazione alla specializzazione e ai processi cui è
destinato.
Fonte: materiali SAP
La modularità di progettazione degli ERP ha alcuni vantaggi. Il primo è che ciascuna azienda può scegliere i moduli che
intende usare, rendendo possibili implementazioni parziali del sistema e investimenti più mirati. Il secondo vantaggio è
l’estendibilità: l’azienda può decidere un’implementazione progressiva limitando l’impatto sull’organizzazione interna
che un passaggio alle nuove funzionalità richieste dal sistema può richiedere. Il terzo vantaggio è che talvolta diventa
possibile acquistare e agganciare allo stesso ERP moduli prodotti da società diverse, permettendo una maggiore
flessibilità nelle scelte: naturalmente, questo solleva l’importante questione dell’integrabilità e interoperabilità di
componenti sviluppate da diversi vendor.
Prescrittività
L’adozione di un sistema ERP richiede la conformazione delle pratiche aziendali a un modello di processo gestionale
preconfigurato. È ciò che Bracchi et al. (2010) definiscono prescrittività: si consideri ad esempio l’attività di
ricevimento dei materiali ordinati a un fornitore. Si supponga che il sistema ERP, per registrare il ricevimento della
merce e stampare le relative documentazioni, attinga a un database dove recupera i dati dell’ordine fatto al fornitore. In
tal caso il processo di ricevimento viene prescritto dall’ERP nel senso che ad es. non sarà possibile concludere il
ricevimento merce se l’ordine al fornitore non è stato preventivamente e correttamente registrato nel sistema.
Questa prescrittività può essere da un lato utile ma dall’altro fonte di problemi. Utile in quanto i sistemi ERP
(specialmente quelli più evoluti) sono stati progettati sulla base di esempi di flussi informativi e processi di grandi
aziende “di successo” (si usa spesso il termine “best practice” per identificare le “buone pratiche” adottate dalle
“migliori aziende” per gestire le tipiche attività aziendali). Quindi implementare un ERP può essere l’occasione per
un’azienda di uniformare le proprie pratiche alle “migliori pratiche” del proprio settore di appartenenza.
Fonte di problemi in quanto questo adattamento dell’organizzazione alle “best practice” imposte dall’ERP potrebbe non
essere facile (e in alcuni casi nemmeno opportuno: le “best practice” è un concetto sempre relativo). Ad esempio,
nell’esempio di Bracchi et al. (2010) prima riportato gli autori ricordano come un’azienda automobilistica potrebbe
avere difficoltà a gestire le emergenze di produzione imposte da un flusso just in time che richiedono talvolta arrivi
urgenti di componenti non ancora formalizzati in termini di ordini.
Per risolvere il problema i sistemi ERP moderni sono parametrizzati ossia sono progettati in modo da essere
configurabili in modo molto articolato agendo su alcuni parametri di configurazione e permettendo un migliore
adattamento del sistema alle pratiche imprescindibili della singola azienda (a titolo di esempio SAP ha migliaia di
variabili di configurazione). Tuttavia non sempre si riesce a ottenere
Architettura di un sistema ERP
Dal punto di vista infrastrutturale, tipicamente un sistema ERP ha un’architettura di tipo client-server: un computer
centrale (dove risiede il database centralizzato) ospita le applicazioni condivise e ad esso sono collegati i computer
client situati nelle diverse aree e uffici aziendali, nei quali risiedono le applicazioni software di uso specifico e locale.
Dai computer client vengono inviate “richieste” al server centrale (ad es. l’ufficio vendite invierà la richiesta di
immettere un nuovo ordin) che risponde mettendo a disposizione il servizio richiesto. L’interazione tra client e server
richiede la definizione di alcuni sistemi e protocolli informatici, che possono differire da caso a caso. Da questo punto
di vista, come accaduto ad altre applicazioni business, una tendenza generale per l’ERP è l’adozione di sistemi di tipo
“web based” o “web service” che utilizzano protocolli e linguaggi standard tipici delle applicazioni Internet e Web.
Questa modalità è giudicata sempre più interessante innanzitutto perché consente modalità di interfacciamento con gli
utenti particolarmente “user-friendly”: diventa ad esempio possibile in molti casi accedere al sistema ERP tramite un
comune browser web. Inoltre i protocolli standard facilitano l’interoperabilità tra macchine e software, cosa che nei più
vecchi sistemi ERP era più complicata e richiedeva adeguate interfacce e programmi di conversione dati.
Un’altra caratteristica importante degli ERP moderni è l’organizzazione a livelli, che consente fra l’altro una
progettazione del sistema in momenti e fasi indipendenti. Ad esempio, nel caso di SAP R/3 l’organizzazione del sistema
è a tre livelli: il più “basso” (database) riguarda i programmi base per la gestione degli accessi al database; quello
intermedio (“application”) riguarda le applicazioni per le elaborazioni di supporto ai processi di business aziendali
(gestione dei documenti per il ciclo dell’ordine, la fattura, il magazzino, …); a livello più alto (Presentation) ci sono i
programmi che gestiscono l’interazione con l’utente. Questa distinzione è importante in quanto si può (naturalmente
entro certi limiti) apportare modifiche ad un livello senza dover agire sugli altri.
Un ulteriore aspetto che riguarda lo sviluppo degli ERP è l’uso degli strumenti CASE e SOA. I CASE (Computer-aided
software engineering) sono sistemi che facilitano la progettazione software automatizzando una serie di operazioni di
codifica-decodifica e di scrittura del codice, proponendo al progettista soluzioni e configurazioni disponibili in una
libreria base, e altro ancora. In questo modo diventa possibile ad esempio la scrittura facilitata di porzioni di software da
integrare in un sistema ERP per risolvere specifici problemi. L’architettura SOA (Service-oriented architecture) è una
più recente modalità di organizzare il software specialmente nel campo business, distinguendo tra il livello
maggiormente applicativo (quello dei “processi di business”) da quello più basso riguardante il codice vero e proprio. In
pratica diventa possibile predefinire librerie di moduli di codice elementari per specifiche funzioni software. Il
progettista del sistema ERP può invece concentrarsi al livello dei processi di business (definendo ad es. quali sono i dati
che servono in un documento di ordine, come vanno inseriti, quali eventi genera il loro inserimento, ecc.) e sarà poi il
sistema a combinare e configurare i vari pezzi di codice necessari per realizzare quel processo. I sistemi SOA si basano
su linguaggi standard di nuova generazione che facilitano la connessione tra i vari pezzi di codice.
Progettazione e implementazione di un ERP; verticalizzazioni e parametrizzazioni
Come si comprenderà un sistema ERP non è mai un pacchetto standard che si compra e si installa. Infatti, i modi di
lavorare delle aziende e i processi di business sono così vari e diversi che questo sarebbe sostanzialmente impossibile.
Nelle prime implementazioni i sistemi ERP venivano realizzati “da zero” ogni volta. Oggi tuttavia ci sono due fatti da
considerare: il primo è che le aziende, pur diverse, presentano talvolta somiglianze anche marcate nell’esecuzione di
alcuni processi o attività; ciò anche in virtù del fatto che il commercio internazionale richiede una certa diffusione di
pratiche commerciali e manageriali abbastanza standardizzate. In secondo luogo, per le società informatiche che
progettano e vendono ERP diventa più facile predefinire un’architettura e un certo numero di moduli standard, e poi
configurarli e adattarli per la singola azienda utilizzatrice. A questo scopo sono fra l’altro particolarmente utili approcci
come il SOA.
Con la diffusione dei sistemi ERP (che oggi rappresentano un prodotto e un segmento di mercato ben identificati
nell’informatica gestionale) nello sviluppo di questi sistemi si sono sviluppate due pratiche. La prima è la
parametrizzazione cui prima abbiamo accennato: un pacchetto ERP è oggi configurabile con numerosi parametri che
possono essere impostati per adattare il software alle specifiche necessità e processi dell’azienda utente. La
parametrizzazione definisce i parametri del pacchetto ERP per modificarne il funzionamento secondo requisiti aziendali
specifici, e riguarda aspetti di tipo diverso come ad es.: parametri globali (valuta, unità misura, calendario), struttura
aziendale (nomi delle unità organizzative, relativi codici), la codifica del database (“master data”: quali campi, quali
formati, quali relazioni, ecc.), il reporting (modalità di presentazione dei dati agli utenti), le tabelle di autorizzazione (i
profili utente e i privilegi di accesso al sistema), e altro ancora.
La seconda è la cosiddetta verticalizzazione: poiché le pratiche e i processi di business presentano delle similitudini
quando si tratta di aziende che lavorano nello stesso settore, i produttori di ERP hanno sviluppato sistemi specializzati
per ciascun settore (le cosiddette verticalizzazioni). La combinazione tra verticalizzazione e parametrizzazione consente
di coprire un numero maggiore di possibili configurazioni per venire incontro alla domanda da parte delle aziende
utilizzatrici.
Un progetto ERP quindi viene sviluppato analizzando i fabbisogni dell’azienda utente (ossia i processi di business, le
modalità di elaborazione, ecc.), selezionando la verticalizzazione adatta, configurando i parametri e infine realizzando
modifiche o software aggiuntivi dove necessario.
A livello di dettaglio, in un progetto ERP una fase importante è l’analisi di carattere organizzativo preliminare agli
aspetti tecnici strettamente intesi. Per informatizzare un certo processo con un sistema ERP si procede infatti iniziando
con una fase di analisi che identifica e seleziona i processi che dovranno essere oggetto di informatizzazione in
relazione con gli obiettivi dell’azienda. Poi verrà analizzato l’uso delle informazioni nelle componenti organizzative in
gioco (ossia la relazione tra informazioni e funzioni aziendali o centri di costi, responsabilità aziendali, lungo i vari
processi, ecc.) e le responsabilità di ciascuna componente rispetto a una certa informazione e/o processo. Tutto ciò
viene tradotto infine in tabelle o altre rappresentazioni schematiche. Si potrà poi procedere identificando gli elementi di
controllo (ossia quali dati/documenti sono associati a quale evento, e in che modo deve avvenire la loro registrazione
nel sistema): Ad es.: quali informazioni sono necessarie per inserire un ordine, quali elaborazioni vengono innescate
dall’inserimento, ecc. Infine si formalizzeranno le relazioni tra i dati e il processo oggetto di analisi (ad es.: quali effetti
ha l’inserimento di un ordine, e su quali tabelle del database). Vantaggi e svantaggi dei sistemi ERP
I vantaggi e i problemi derivanti dall’implementazione e l’uso degli ERP dipendono dal caso specifico dell’azienda
utente. Tuttavia in linea di massima vi sono alcuni punti di carattere generale che si possono citare.
Un primo vantaggio dei sistemi ERP è legato all’efficiente gestione dell’informazione: i dati sono univoci, aggiornati in
tempo reale, con chiara identificazione di responsabilità (chi ha immesso il dato, quando, per fare cosa). Ciò rende in
generale più efficienti i processi aziendali. Ulteriore elemento importante è l’integrazione tra le diverse funzioni
aziendali che devono cooperare allo stesso processo.
In termini di problemi uno è sicuramente il costo: un sistema ERP può richiedere investimenti che vanno dalle centinaia
di migliaia di € a diversi milioni e anche più. Dati questi alti investimenti, generalmente si acquista un sistema ERP non
per usi troppo mirati ma invece per coprire in modo abbastanza vasto i processi aziendali critici. Questo comporta una
notevole complessità progettuale, e anche una notevole complessità all’atto dell’implementazione in azienda. Fra
l’altro, l’uso degli ERP richiede come detto una corrispondenza del sistema ai processi aziendali: in altri termini, il
“modello di azienda” rappresentato in un sistema ERP deve corrispondere a quello “reale” dell’azienda. In parte sono i
sistemi ERP che vengono progettati per adattarli alla realtà specifica dell’azienda, ma anche l’organizzazione deve
modificarsi per usare efficacemente il sistema. In particolare diventa spesso necessaria una strutturazione e
formalizzazione dei processi aziendali, che oltre che risultare difficile e costosa organizzativamente (richiedendo
addestramento degli addetti, superamento di resistenze interne, assimilazione di nuove procedure e modi di lavorare,
ecc.) può determinare una certa rigidità che può risultare inadeguata specialmente per aziende che fanno della
flessibilità la loro arma strategica.
Riferimenti
Bracchi G., Francalanci C., Motta G. Sistemi informativi d'impresa, Milano, McGraw-Hill, 2010
Camussone P.F., Il sistema informativo aziendale, ETASLIBRI, Milano, 1998
Università di Torino, 2003, Sistemi informativi aziendali ERP, Dipartimento di Economia Aziendale, Dispense del corso di Sistemi
Informativi, hal9000.cisi.unito.it/wf/DIPARTIMEN/Economia-A/I-corsi/Sistemi-in/Materiale-/ERP.pdf