CAPITOLO 2
Il Sistema Legacy Aziendale
2.1 I sistemi Legacy
Nella letteratura specialistica si incontrano diverse definizioni di Legacy System.
Per prima cosa vediamo cosa si intende per legacy. Webster propone come definizione del termine legacy “something of value received from an ancestor or predecessor or from the past” (“qualcosa di valore ricevuto da un antenato o predecessore o dal passato”).
Vediamo alcune tra le definizioni più diffuse per i Legacy System:
o “grandi sistemi software con cui non si vorrebbe avere a che fare ma che sono vitali per l’organizzazione” (Bennet);
o “ogni applicazione in produzione” (Schick);
o “ogni sistema informativo che resiste alle modifiche ed evoluzioni necessarie per tener dietro ai nuovi e mutevoli requisisti di business dell’organizzazione” (Brodie).
o “un sistema informativo (applicazione) di valore ereditato dal passato” (Massari, Mecella).
Come si può notare dalle varie interpretazioni del termine Legacy System, con particolare riferimento all’ultima citata, si fa sempre riferimento ad un sistema informativo aziendale che esiste da anni, è fondamentale per il business aziendale ed è ereditato dall’ambiente elaborativo attuale.
Scorrendo le varie definizioni si può cogliere come generalmente ci si riferisca a tali sistemi considerandoli sì un’eredità del passato, ma un’eredita scomoda, qualcosa di obsoleto, di strettamente appartenente al passato e lontano dagli sviluppi moderni delle tecnologie informatiche; qualche autore utilizza il paragone, particolarmente azzeccato, con i dinosauri. Questo primo punto è quello che si può evincere dai riferimenti temporali che si possono rintracciare nelle varie espressioni utilizzate.
Un secondo punto, non meno importante del primo, è quello legato al valore di tali sistemi, concetto ben espresso dal riferimento al termine “eredità”. Anche se in alcuni casi si preferirebbe fare a meno di dover trattare tali sistemi, i sistemi Legacy hanno un valore innegabile per il business aziendale e non possono, come vedremo in seguito, essere semplicemente abbandonati come un oggetto privo di importanza. Al contrario, i
seguito l’evoluzione delle prassi aziendali e rappresentano abbastanza fedelmente uno specchio dei processi dell’impresa.
Vediamo adesso brevemente le caratteristiche che identificano i sistemi Legacy:
o È un sistema fondamentale per l’azienda, strettamente legato al business e mission critical, per cui spesso deve essere operativo al 100% per 24 ore al giorno sette giorni su sette.
o È un sistema complesso, il cui stato attuale rappresenta l’evoluzione negli anni del sistema informativo attraverso continui miglioramenti, aggiornamenti ed ampliamenti; su di esso l’azienda ha quindi investito pesantemente e non può essere semplicemente abbandonato.
o È di grosse dimensioni, centinaia di migliaia di linee di codice, distribuite su migliaia di programmi.
o È scritto in linguaggi di programmazione di vecchia generazione (ad esempio COBOL, PL1 ed assembler).
o Il Database Management System è obsoleto o addirittura assente e si fa ricorso al file system.
o L’interfaccia è a caratteri (ad es. terminali 3270).
o Il funzionamento del sistema non è di facile comprensione, come già detto spesso il sistema ha subito varie evoluzioni nel corso del tempo ma tali modifiche e variazioni, nella maggior parte dei casi, non sono state documentate, per cui la manualistica non è aggiornata.
o Il sistema è un archivio dei cambiamenti subiti dalle prassi e dalle funzionalità aziendali; tali cambiamenti sono registrati nel sistema come cambiamenti delle funzioni e si trovano quindi immersi nel codice.
Si può intuire da quanto esposto che la definizione di Legacy System è soggetta a varie interpretazioni. Molti degli applicativi scritti negli anni ’70 e ’80 rientrano sicuramente in questa categoria, ma qualche addetto ai lavori propone addirittura una definizione più estrema, sintetizzata dalle frasi “tutto ciò che non è Java è Legacy”, oppure “qualsiasi cosa che non sia realizzata con metodologie Object Oriented o non usa il Web è Legacy”.
Quello che preme qui sottolineare è come i Legacy System, anche se presentano quelle caratteristiche negative di obsolescenza sopra riportate, sono spesso fondamentali per l’azienda e supportano in modo completo tutti i processi mission critical; approcci definitivi quali la sostituzione netta sono di difficile praticabilità.
2.2 Classificazione dei sistemi Legacy
Vediamo adesso come classificare i sistemi Legacy in un’ottica orientata al loro trattamento (figura 11):
1) Sistemi altamente decomponibili, sono ben strutturati e presentano delle caratteristiche peculiari:
o I componenti applicativi sono separabili in logica di presentazione, logica applicativa e logica d’accesso ai dati, cioè il software è composto di tre livelli logici;
o I moduli applicativi sono interdipendenti tra loro;
o I moduli applicativi hanno interfacce ben definite con i servizi di database, quelli di presentazione e le altre applicazioni;
2) Sistemi data decomponibili, sono sistemi che possono essere definiti come semistrutturati e presentano le seguenti caratteristiche:
o I componenti applicativi sono separabili in due livelli: i servizi d’accesso ai dati quelli di presentazione e logica applicativa fusi in un solo blocco;
o I moduli applicativi hanno interfacce ben definite verso le altre applicazioni; Sono sistemi in cui è possibile accedere ai dati ma non alla logica applicativa.
3) Sistemi program decomponibili, sono anche questi sistemi che possono essere definiti come semistrutturati e presentano le seguenti caratteristiche:
o I componenti sono separabili in due livelli: i servizi di presentazione e quelli di accesso ai dati e logica applicativa fusi in un unico blocco;
o I moduli applicativi hanno interfacce ben definite verso le altre applicazioni; Per questi sistemi, nella cui categoria rientrano la maggior parte dei sistemi Legacy esistenti, non è possibile l’accesso diretto ai dati; tale accesso è tipicamente possibile solo se si invocano delle transazioni predefinite (tipicamente una transazione).
4) Sistemi monolitici (non strutturati), sono sistemi in cui tutti i componenti appaiono come un unico blocco in cui tutti i tre livelli logici sono fusi insieme. Generalmente a questi sistemi si può accedere solo attraverso l’invocazione da terminale.
Da un punto di vista del trattamento tali sistemi possono essere definiti secondo la seguente classificazione:
o Ostili: non permettono l’interfacciamento con l’esterno;
o Trattabili: l’interfacciamento con l’esterno è possibile, serve uno sforzo a livello di programmazione e tecnologie apposite;
o Amichevoli: l’interfacciamento con l’esterno è facilmente ottenibile.
Con riferimento alla prima classificazione è facilmente intuibile come i sistemi altamente decomponibili siano amichevoli, quelli semistrutturati (data o program decomponibili) siano trattabili mentre quelli non strutturati restino ostili.
2.3Il trattamento dei sistemi Legacy
Come abbiamo visto nel paragrafo introduttivo i sistemi Legacy rappresentano uno strumento spesso indispensabile e difficilmente sostituibile per il business aziendale. Nonostante si basino su tecnologie ed architetture ritenute obsolete supportano i processi aziendali praticamente al 100% e, in alcuni casi, con prestazioni ed affidabilità elevate.
È chiaro quindi che il management aziendale deve affrontare la gestione di tali sistemi cercando di combinare le esigenze del business con la necessità, fondamentale per mantenere competitiva l’azienda, di ammodernare ed aggiornare il sistema aziendale. Una nuova corrente di pensiero nell’ambito del settore delle Information Technology raggruppa i possibili approcci ai Legacy Systems sotto il nome di Legacy Application Reengineering , o, più in generale, di trattamento dei sistemi Legacy.
Vediamo di fare una prima panoramica tra i possibili trattamenti di un sistema Legacy: 1) Manutenzione;
2) Ignorare il sistema;
3) Sostituzione (netta o parziale) del sistema;
4) Integrazione tra sistema Legacy e nuovi sistemi aziendali.
Vedremo nei prossimi paragrafi di spiegare dettagliatamente ciascuno di questi approcci.
2.3.1 La manutenzione
Con il termine manutenzione si intende “il complesso delle operazioni necessarie a conservare la conveniente funzionalità, efficienza e modificabilità del sistema”.
Nonostante l’utilizzo di tutte le più avanzate tecniche di progettazione e realizzazione dei software, la percentuale con cui i costi di manutenzione incidono sul totale delle spese effettuate per i sistemi informatici raggiunge, e in alcuni casi supera, il 70%. È facile intuire quindi come questa tipologia di trattamento sia non solo universalmente applicata ma anche di fondamentale importanza: se è vero che la manutenzione dei sistemi Legacy, per una serie di motivi facilmente intuibili e che andremo in seguito ad elencare, è più difficile rispetto ai sistemi per così dire “moderni”, è altresì vero che una manutenzione non adeguata accelera il processo degradatorio con il quale un sistema diviene Legacy.
Poiché a volte è difficile distinguere tra i vari tipi di interventi che si eseguono su di un software o su di un sistema diremo che parliamo di manutenzione quando, nonostante le modifiche apportate, il sistema rimane strutturalmente invariato e continua a svolgere lo stesso ruolo nel contesto utilizzativo.
Vediamo di distinguere tra i vari tipi di manutenzione possibile:
o Migliorativa: come dice il termine stesso serve a migliorare gli elementi che servono a soddisfare i requisiti non funzionali del sistema, ovvero quei requisiti Figura 12 – Trattamento dei sistemi Legacy.
generali non strettamente legati alla funzione svolta dal sistema (prestazioni, uso di risorse, manutenibilità, ecc.);
o Adeguativa: ha come scopo principale quello di adeguare il sistema ai mutamenti tecnici avvenuti a livello infrastrutturale oppure tecnologico (ad esempio il caso di Database Management System, di versione del sistema operativo, ecc.);
o Correttiva: serve per correggere i difetti del sistema. Con difetto si intende un comportamento non adeguato del sistema perché non rispondente alle specifiche stabilite sia a causa della inadeguatezza delle specifiche individuate. Tale manutenzione è importante perché qualsiasi software o sistema, nonostante si usino le tecniche di progettazione e realizzazione più precise, presenta sempre degli errori;
o Evolutiva: a differenza del primo tipo di manutenzione qui il fine è sul miglioramento dei requisiti funzionali secondari del sistema; restano inalterati sia la funzione principale del sistema che le caratteristiche infrastrutturali e tecnologiche. Che cosa rende particolarmente difficile e costosa gli interventi manutentivi, di tutte le categorie sopraesposte, di un sistema in generale ed in particolare di un sistema Legacy? Un primo punto da evidenziare è il fatto che gli autori del sistema spesso non sono disponibili per aiutare chi deve effettuare la manutenzione: dato che sono passati molti anni – a volte anche 15 o più – dalla creazione del sistema è difficile reperire gli autori originali.
Un secondo fattore è legato alla continua evoluzione del Legacy per adattarsi al mutare dei requisiti e dei processi aziendali; abbiamo già detto come nel sistema siano immerse anni di prassi aziendali. A questo si aggiunge la difficoltà derivante dal fatto che tali modifiche siano spesso non documentate, e questo comporta l’obsolescenza della documentazione di sistema disponibile.
Un altro criterio è legato all’approccio utilizzato nella progettazione del sistema originale e delle sue modifiche: mentre sarebbe auspicabile perseguire l’obiettivo di modificabilità del sistema, non sempre gli sforzi vanno in tale direzione. Si dovrebbe cioè progettare il sistema pensando che esso dovrebbe essere comprensibile anche a chi non ha partecipato alla sua realizzazione, mentre spesso i criteri di progettazione sono estemporanei e spontanei.
Possiamo elencare tra i fattori che aumentano il costo degli interventi manutentivi le dimensioni di un sistema, la sua età, la complessità del sistema, la mancanza di documentazione o comunque la presenza di documentazione non aggiornata.
Viceversa vi sono dei fattori che diminuiscono i costi di tali interventi, tra i quali possiamo citare l’uso di tecniche strutturali o formali, la disponibilità di test cases, l’utilizzo di strumenti (tool) automatici, la presenza di una metodologia di sviluppo, la presenza di documentazione aggiornata, l’esperienza dei manutentori.
Facciamo notare come l’incremento dei costi di manutenzione comporta un fattore negativo non solo per il sistema Legacy, ma più in generale per tutta gli investimenti IT di un’azienda. Basti pensare che il tempo e le risorse, sempre crescenti, utilizzate per la manutenzione vengono sottratte ad altri progetti IT: a volte il peso della manutenzione è tale da comportare l’abbandono degli altri approcci al trattamento dei sistemi Legacy.
2.3.2 Ignorare il Sistema
Con questo tipo di approccio si intende la decisione di escludere il sistema da ogni successivo sviluppo informatico dell’azienda.
Da quanto esposto in precedenza sulle caratteristiche dei sistemi Legacy, con particolare riferimento al fatto che essi spesso svolgono un ruolo di supporto a processi mission critical, si può capire come tale approccio sia nella maggior parte dei casi impraticabile; si può infatti pensare di ignorare il sistema solo nel caso in cui esso sia di supporto a processi che non sono fondamentali per il business aziendale.
Una delle modalità che rispondono alla categoria di approcci che “ignorano” il sistema consiste nel darlo in outsourcing a software house specializzate nella gestione dei sistemi Legacy.
In questo modo in pratica si smette di preoccuparsi delle problematiche relative al sistema senza rinunciare alle sue funzionalità, e si concentrano le risorse per strategie di sviluppo informatiche diverse (ad esempio la creazione di un nuovo sistema).
2.3.3 La sostituzione netta
Con questo approccio si intende la riscrittura completa del sistema Legacy, con una sostituzione a taglio netto: metaforicamente possiamo dire che fino al venerdì sera si usa il vecchio sistema aziendale e al rientro dal fine settimana troviamo già operativo il nuovo sistema, mentre del vecchio non rimane più traccia.
Anche se questa soluzione è diametralmente opposta alla precedente ha in comune con essa, nella maggior parte dei casi, l’impossibilità di essere messa in pratica, e questo per una serie di motivi:
o Abbiamo già detto che il Legacy è un sistema complesso, che supporta molti processi mission – critical e di grandi dimensioni. La riscrittura partendo da zero di un nuovo sistema che, implementando le nuove tecnologie, sostituisca completamente il Legacy è un progetto enorme e, come tutti i progetti di queste dimensioni, richiede notevoli sforzi in termini di risorse (finanziare, umane) e di tempo. Se a questo si aggiunge l’elevata dinamicità dei mercati che costringono le aziende a cambiare continuamente si capisce come solo la definizione degli obiettivi e delle specifiche di sviluppo del sistema possano richiedere anni, e nel frattempo il contesto in cui il nuovo sistema deve operare può già essere mutato. Inoltre progetti di così grandi dimensioni hanno, statisticamente, un’elevata probabilità di fallire.
o Sempre per quanto riguarda lo sviluppo non è possibile partire dalle specifiche del Legacy per creare quelle del nuovo sistema. Come già detto la documentazione non è aggiornata, le specifiche originali non sono più valide e i continui interventi sul sistema hanno creato nuove interdipendenze logiche non documentate; per avere una comprensione del sistema sovente si deve partire dal codice.
o Il Legacy, per la sua natura, deve avere accesso ai dati 24 ore al giorno 7 giorni su 7, e questo rappresenta un problema per il trasferimento dei dati dal vecchio al nuovo sistema. Inoltre i dati, prima di essere trasferiti nel nuovo sistema, devono essere controllati, e convertiti e tale processo richiede settimane; questo rappresenta un ulteriore ostacolo a questo approccio.
Per tutti i motivi sopraelencati si può capire come tale soluzione sia di elevata complessità e venga intrapresa solo nei casi in cui questo approccio venga ritenuto dal management assolutamente indispensabile.
2.3.4 La sostituzione incrementale (migrazione)
Questo approccio viene ben definito dal termine migrazione: si decide di sostituire il sistema in modo completo o solo in parte con una serie di passi successivi, realizzando così una migrazione tra il sistema Legacy (detto anche source, cioè sorgente) ed il sistema informativo, basato sulle nuove tecnologie, che si sta sviluppando (detto anche target, cioè destinazione).
Tale strategia può apparire sicuramente più semplice da condurre rispetto ad una sostituzione completa e quindi sempre preferibile, bisogna tuttavia tenere conto delle statistiche che riguardano la percentuale di successo dei progetti di migrazione: da uno studio condotto negli USA negli anni ’90 risultò che l’80% delle migrazioni erano
fallite, cioè erano state posticipate (rispetto ai tempi previsti), ridimensionate o addirittura annullate. Per questo, nell’intraprendere questa strada, il management aziendale deve porre particolare attenzione alla gestione del progetto.
Le alternative possibili per un progetto di migrazione sono due:
1) Migrazione parziale: si trasferisce solo una parte del sistema Legacy, solitamente quella più problematica. Ad esempio si può trasferire la parte del sistema che più abbisogna di un aggiornamento, oppure quella parte la cui manutenzione è estremamente difficile e costosa. È una strategia con rischi contenuti soprattutto per quei sistemi che abbiamo precedentemente definito come amichevoli o trattabili; si lavora soprattutto a livello di interfacce utenti o di dati.
2) Migrazione completa: tutto il sistema viene migrato dal Legacy al nuovo. In questo caso i rischi che abbiamo già menzionato vengono ridotti da una gestione incrementale del cambiamento: il progetto viene diviso in passi, ciascuno corrispondente alla migrazione di parte del sistema. Come si può facilmente intuire il vantaggio è rappresentato dal fatto che in caso di fallimento di una parte del processo si deve ripetere solo il passo che non è riuscito, con tutti i vantaggi che ne derivano. Nel caso di migrazione parziale, come detto, si può principalmente agire a livello di interfacce utenti o a livello di dati.
Se abbiamo un sistema Legacy di cui vogliamo migliorare la modalità di presentazione agli utenti finali, passando ad esempio da un’interfaccia a caratteri ad una GUI (Graphic User Interface) o ad una interfaccia Web accessibile da browser, sceglieremo ovviamente di migrare le interfacce utenti. Possiamo muoverci in due direzioni: l’utilizzo di tecniche di screen scraping per tradurre l’interfaccia in una interfaccia grafica, oppure la riscrittura completa delle interfacce. Con lo screen scraping si usano emulatori di terminali che simulano la pressione dei tasti e la lettura/scrittura di posizioni specifiche; il vantaggio è che non si deve intervenire sul Legacy, lo svantaggio è in termini di prestazioni. La riscrittura completa sarebbe auspicabile, tuttavia è fattibile solo per sistemi trattabili o program decomponibili. Solitamente si usa un approccio misto, si fornisce da subito la nuova interfaccia con lo screen scraping mentre si procede alla riscrittura della nuova interfaccia.
La migrazione dei dati comporta invece il trasferimento dei dati da una piattaforma ad un’altra. Questa operazione comprende le attività di conversione, trasformazione, spostamento ed allocazione dei dati dal sistema source a quello target. Fortunatamente esistono varie tecnologie di supporto a queste attività, quali Database Unload/Reload
Utilities, Tools di conversione automatica, Data Propagators, Application Servers e Gateways.
2.3.5 L’integrazione
L’integrazione è un approccio innovativo al trattamento dei sistemi Legacy e deriva dallo sviluppo del nuovo paradigma DOC (Distributed Object Computing): questo paradigma permette di vedere i vari sistemi informativi aziendali non più come tante “isole” informatiche da collegare tra loro, bensì come un unico grande Sistema Informativo Distribuito (utilizzato, localizzato ed anche gestito in modo non centralizzato), ovvero, se vogliamo usare una metafora, un unico grande organismo di cui gli equivalenti, vecchi o nuovi, dei Legacy System costituiscono i vari organi. Non si tende più alla completa sostituzione o alla modifica sostanziale del Legacy, si cerca invece di utilizzare un approccio di tipo black box (a scatola nera): con l’uso di tecnologie ad hoc si punta a realizzare un object wrapping del sistema in modo che il Legacy presenti verso l’esterno un’interfaccia ad oggetti.
Non scenderemo qui nel dettaglio delle varie tecniche che permettono di raggiungere tale obiettivo, vale la pena sottolineare come tale soluzione permetta di ridurre rischi, costi e tempi di sviluppo rispetto agli altri approcci finora esaminati.
Un breve cenno merita lo strumento principale utilizzato in questo approccio, cioè il wrapper: si tratta di un livello software che nasconde l'implementazione effettiva delle funzionalità (che sono realizzate da uno o più moduli di un'applicazione legacy in ambiente mainframe o server) e le presenta attraverso un'interfaccia ben definita, tipicamente ad oggetti.
2.4 Il sistema Legacy della Power-One Italy
Il sistema Legacy aziendale viene indicato, in modo non corretto, con il nome di COPICS, il cui acronimo sta per Communications Oriented Production Information and Control System. Il COPICS è in realtà solo una parte del sistema informatico, infatti è un sistema gestionale di tipo MRP II realizzato dalla IBM negli anni ’80, il cui scopo è principalmente quello di fornire al management una guida per lo sviluppo di un sistema di controllo dinamico ed online dalla produzione.
In realtà il sistema Legacy attualmente operante non è limitato al solo COPICS, inoltre esso è qualcosa di diverso rispetto a quello nato nel lontano 1986 perché ha subito
un’evoluzione costante; per meglio capire la configurazione attuale dobbiamo ripercorrere la cronologia degli investimenti in informatica per lo stabilimento di Terranuova Bracciolini.
2.4.1 Storia dell’informatica dello stabilimento di Terranuova Bracciolini
I primi passi mossi dall’informatica nello stabilimento di Terranuova Bracciolini risalgono ai primi anni ’80, ancora prima che l’impianto venisse acquistato dalla MagneTek e faceva ancora parte del gruppo Plessey (di casa madre inglese).
In quel periodo l’informatica era stata data in outsourcing ad una società di servizi esterna, la quale utilizzava un sistema di tipo 36 (antenato dell’AS/400). Tale scelta fu ripensata a causa dei costi elevati che l’azienda doveva sostenere, venne commissionato uno studio congiunto tra funzionari della Plessey e personale IBM che portò alla decisione di assumere direttamente la gestione dell’informatica.
Il primo nucleo del sistema informatico aziendale era rappresentato da un elaboratore IBM 4361 modello 4, da un Database gerarchico DL1 e da una serie di pacchetti applicativi: COPICS (MRP), Inventory (magazzino), Distinta Base e IFS (contabilità generale, clienti e fornitori).
Negli anni successivi vi fu un rapido sviluppo in termini applicativi: miglioramenti e completamenti delle applicazioni iniziale nell’area della produzione, della contabilità, del controllo di gestione, informatizzazione di nuove aree applicative, come il disegno elettrico e meccanico e il controllo qualità.
Ovviamente l’evoluzione non si era limitata al solo campo delle applicazioni, ma erano state fatti anche evoluzioni a livello architetturale. Il sistema mantenne sostanzialmente la configurazione con elaborazione centrale con terminali non intelligenti, passando però al concetto delle “isole informatiche”: lo sviluppo dell’informatica avvenne in ciascuna di queste isole (gestionale, personale, disegno elettrico, disegno meccanico, controllo di qualità) dotandole di potenza elaborativa autonoma e collegandole tra loro per il necessario interscambio di dati.
Citiamo qui le principali tappe evolutive negli anni 1986-1992:
o 1988 Sostituzione dell’elaboratore IBM 4362 modello 4 con un modello 5;
o 1990 Installazione dell’elaboratore IBM 4381 modello P13, creazione dell’isola del CAD elettrico sull’elaboratore IBM 4361 modello 5;
o 1991 Installazione della rete di PC con topologia Token Ring per l’isola informatica del controllo qualità;
o 1992 Installazione della Workstation IBM RISC/6000 in rete Ethernet dell’isola del CAD meccanico e dell’elaboratore AS/400 modello E10 per l’isola del personale.
In questa prima parte dell’evoluzione ci fu una costante presenza del personale IBM sia per la manutenzione del sistema che per le proposte di investimenti e sviluppi futuri. In particolar modo si manifestarono alcuni aspetti negativi dell’approccio fino ad allora seguito, con il quale la IBM rivestiva un ruolo a dir poco fondamentale:
o elevati costi del personale della IBM, sia per la manutenzione del sistema che per l’addestramento del personale aziendale;
o l’azienda aveva solo licenze da utente del software e non poteva quindi disporne liberamente;
o molti degli adattamenti e personalizzazioni del pacchetto software sulle particolari esigenze aziendali (“customizzazioni”) richiesti alla IBM venivano regolarmente respinti.
Questo tipo di atteggiamento ha portato l’azienda a cercare soluzioni alternative. Era naturalmente impensabile poter tornare ad un outsourcing completo dell’informatica aziendale come alle origini, tuttavia si è cercato di allentare la dipendenza dalla IBM cercando delle software house che offrissero dei pacchetti software adatti alle esigenze dell’azienda ed avessero un tipo di collaborazione più flessibile. Tra queste aziende possiamo sicuramente ricordare la SGM, il cui pacchetto relativo al Purchasing (area acquisti) ha sostituito quello originale della IBM.
Un vantaggio di questo tipo di approccio consisteva nel fatto che di tali software l’azienda non era più licenziataria, bensì proprietaria, per cui, possedendo il codice sorgente delle applicazioni, le modifiche e le customizzazioni erano adesso possibili. Da un punto di vista del Database l’evoluzione proseguì con il passaggio, nel 1995, dal Database DL1, divenuto ormai obsoleto, ad un Database relazionale, il modello DB2 sempre della IBM; in questo caso ci fu nuovamente l’impiego di un consulente IBM ma affiancato questa volta da personale della SGM.
Nel 2002 ci fu l’ulteriore passaggio a livello di Database con l’utilizzo del DB Oracle, mantenendo comunque sempre il solito pacchetto di applicazioni.
Per quanto riguarda l’architettura del sistema una volta scadute le licenze IBM del mainframe (4361, 4381, ecc.) ci fu il passaggio al sistema UNIX con emulazione CICS. Il CICS (Customer Information Control System) merita un cenno a parte. Questo sistema di gestione degli utenti a video ha permesso all’azienda di ammortizzare i cambiamenti
avvenuti a livello di numero di utenze negli anni; bisogna qui ricordare infatti che la situazione passata è stata l’esatto negativo di quella attuale, ovvero il sistema informativo aziendale è stato esportato nelle altre sedi del gruppo.
Gli stabilimenti di Chatsworth (USA), di Salgotarjan (Ungheria) e di Baoan (Cina) sono stati tutti oggetto di implementazione del COPICS, e questo è stato ottenuto a livello di utenti grazie al CICS. Praticamente con il CICS è stata creata una duplicazione dell’ambiente operativo, quindi sono stati creati quattro ambienti ciascuno modificato per le esigenze particolari del singolo impianto con le varie customizzazioni richieste. Teniamo ben presente questi punti (esportazione del sistema italiano ad altre realtà e customizzazioni) perché li riprenderemo quando parleremo del progetto di implementazione di Oracle oggetto di questo lavoro.
2.4.2 Il COPICS
Esula dallo scopo di questo lavoro un’analisi tecnica del COPICS, e questo si vedrà anche nel capitolo dedicato all’implementazione di Oracle a Terranuova Bracciolini in cui si pone l’accento non tanto sulle tecnologie, ormai in gran parte obsolete, che stanno alla base del sistema, bensì sul grado e tipo di supporto che esso è in grado di dare a tutti processi del business aziendale.
Come abbiamo illustrato nella storia dell’informatica aziendale quello che viene chiamato COPICS è in realtà il sistema Legacy che è nato come nucleo originario con il solo COPICS (MRP II) e altri pacchetti quali gestione del magazzino, della distinta base e della contabilità, ma si è poi evoluto e modificato fino a coprire tutte le esigenze aziendali; comunque continueremo in questo lavoro a chiamare il sistema Legacy con il suo nome tradizionale, COPICS.
I cambiamenti intervenuti a livello di pacchetti applicativi, architettura informatica e database hanno mirato ad aggiornare il sistema alle mutate esigenze e strategie aziendali, seguendo anche l’espansione internazionale del gruppo.
Alcuni delle tappe evolutive sono state dettate da ragioni puramente strategiche, quali ad esempio il limitare la dipendenza dall’IBM e avere pacchetti di cui l’azienda fosse proprietaria per poter realizzare gli adattamenti del caso, altri sono dovute all’apparire sul mercato di nuove tecnologie che hanno reso obsolete quelle utilizzato, come per i tipi di database utilizzati, altre ancora riguardavano la necessità di avere uno strumento adeguato di supporto a tutti i processi aziendali.
A quest’ultimo tipo di tappe evolutive si può ad esempio ricondurre l’introduzione del Cyberplan, un programma di una software house italiana che ha lo scopo principale di poter eseguire, in modo flessibile ed in tempi rapidi, delle simulazioni sul piano produttivo che erano altrimenti impensabili sul COPICS originale: la struttura del pacchetto era tale che qualsiasi piano di produzione che veniva fatto girare sul sistema modificava in modo definitivo le quantità di materiale in giacenza ed i fabbisogni, rendendo impossibile la simulazione di piani di produzione alternativi tra loro.
Il COPICS può tranquillamente essere classificato come sistema Legacy perché risponde alla definizione precedentemente data, in quanto:
o È un sistema fondamentale per l’azienda, come si può anche evincere dalla figura 14 di pagina 28 copre praticamente tutti i processi aziendali e deve essere attivo per il 100% del tempo.
o È di vecchia concezione, il suo nucleo originario infatti è stato creato negli anni ’80.
o Rappresenta l’evoluzione dei processi e delle prassi aziendali, negli oltre 20 anni di vita ha subito modifiche tali da renderlo irriconoscibile agli occhi di chi ha nozioni soltanto del COPICS originario.
o È di grosse dimensioni.
o È scritto in un linguaggio di programmazione di vecchia generazione (COBOL).
o L’interfaccia è a caratteri. Quella di mantenere l’interfaccia a caratteri è stata una precisa scelta dell’azienda, che ha sacrificato l’usabilità di interfacce grafiche per ottenere elevate prestazioni; per un esempio di come il sistema si presenta agli utenti si può vedere figura 13.
Sul COPICS originario è basata l’intera rete di applicazioni che aiutano a gestire tutti i processi aziendali, per cui è facile capire la difficoltà di rimpiazzarlo con un nuovo strumento; di questo ed altre problematiche sorte con l’implementazione di Oracle parleremo nei capitoli successivi.
Naturalmente anche prima dell’acquisizione del ramo PEG di MagneTek da parte di Power-One era chiara al vertice aziendale l’esistenza di soluzioni innovative alternative al COPICS, basti pensare che nel 2006 era stata richiesta una collaborazione alla Facoltà di Ingegneria dell’Università di Pisa che ha prodotto un lavoro dal titolo “Problematiche di Valutazione e Introduzione di un nuovo Sistema Informativo Aziendale presso MagneTek S.p.A.”.
- 2 8 -F ig u ra 1 4 – I p ro ce ss i s u p p o rta ti d al C O P IC S .
Il vertice aziendale stava quindi valutando alcune dei possibili approcci per introdurre un nuovo strumento che sostituisse il COPICS, magari con la scelta di una migrazione parziale il cui impatto venisse ammortizzato negli anni, mantenendo nel frattempo in piedi un sistema ibrido composto da source e da target.
A rompere gli indugi e rendere pressoché inutili gli studi fatti in questa direzione è arrivata nell’ottobre 2006 l’acquisizione da parte di Power-One. Il gruppo Power-One aveva implementato in tutti i suoi stabilimenti l’ERP Oracle, volendo quindi integrare il gruppo di stabilimenti appena acquisiti nel network aziendale non si poteva prescindere da un’integrazione del sistema informativo.
Come realizzare questa integrazione?
Si poteva sicuramente procedere con la realizzazione di interfacce tra i sistemi che rendessero possibile ai due sistemi dialogare tra di loro, ma questo avrebbe richiesto notevoli risorse.
Inoltre il COPICS, per quanto funzionale allo scopo, resta pur sempre un sistema di vecchia generazione, mancante di alcune funzionalità ormai diventate necessarie per gestire realtà aziendali complesse come quella del gruppo Power-One. Come esempio basti pensare alla reportistica, presente solo a livello embrionale e comunque poco flessibile, oppure alla possibilità di estrazione di dati dal sistema, che richiedono procedure lunghe e complesse.
Per tutti i motivi sopraelencati la scelta del vertice aziendale è stata quella della sostituzione del COPICS tramite implementazione di Oracle negli stabilimenti italiano e cinese del ramo PEG, escludendo gli altri due stabilimenti in quanto non rientravano nella strategia di sviluppo del gruppo.
