Il sistema informativo Agrati

Il sistema informativo della Agrati si appoggia attualmente su tre IBM AS/400, tre server NT e più di 130 tra PC e workstation collegati in rete tra loro.

 Il sistema è l’unione di quattro sottosistemi principali:

·         il sistema gestionale: si occupa di gestire tutto ciò che riguarda l’amministrazione dell’azienda, come paghe e stipendi;

·         il sistema tecnico-produttivo: fornisce gli strumenti di progettazione e di produzione dell’area CAD+ (CAD, CAM, CAE, ecc.);

·         il sistema di controllo della qualità: raccoglie tutti i dati inerenti i controlli di qualità, sia a campione che su intere serie di pezzi provenienti dalle macchine automatiche collegate in rete;

·         il sistema logistico: governa tutta la movimentazione del materiale a partire dalla merce in arrivo fino alle consegne ai clienti, passando per la gestione del magazzino automatizzato e dei collegamenti E.D.I. Garantisce inoltre la completa rintracciabilità di tutti i prodotti, memorizzando la provenienza della materia prima e tutte le operazioni subite da un pezzo.

Il sistema gestionale e quello della logistica integrata sono governati da due server IBM AS/400, mentre il sistema tecnico-produttivo e quello del controllo qualità utilizzano due reti LAN. Un sistema M.R.P.II mantiene in stretto collega­mento il controllo della qualità col sistema tecnico, per poter fornire ai progettisti dati aggiornati in tempo reale sull’andamento della qualità dei pezzi in produ­zione. Tutti e quattro i sistemi sono collegati tra loro, in modo da configurare un’unica struttura client-server.

Accanto a questi sistemi si sta installando ora l’E.R.P. System 21 di JBA di cui saranno utilizzate l’area finanziaria, parte di quella logistica e di quella produttiva.

Tutti i principali moduli di contabilità interna ed esterna di System 21 verranno impiegati. Al momento questa parte è stata completamente configurata e sta per sostituire il precedente sistema. Sono, infatti, in corso le fasi di training del personale e della migrazione dei dati dal vecchio database.

Per quanto riguarda la produzione, invece, il vecchio sistema continuerà ad esistere e l’E.R.P. di JBA lo affiancherà, permettendone l’integrazione con altri settori, in particolar modo con quello finanziario. Sono attualmente in prova i pro­grammi di interfacciamento tra i due sistemi informativi.

La gestione dei magazzini rimarrà di totale competenza del sistema pro­prietario Agrati, anche se verrà parzialmente integrato con i moduli dell’area logistica. La movimentazione delle merci diverrà di totale competenza di System 21, così come la gestione dei fornitori e dei clienti.

Questo modello è replicato anche nelle altre aziende produttive del Gruppo, che sono collegate tra loro tramite una rete Intranet.

Il nuovo modello di controllo

Il modello del sistema di controllo, che, in questo momento, è in fase di completamento, è stato elaborato dalla Arthur Andersen MBA alla fine dello scorso anno. Si basa in parte sui report che erano già in uso ed in parte su nuovi tipi, in modo da incrementare il numero e la qualità delle informazioni da analiz­zare; parte dei dati sono estratti dai sistemi informativi già esistenti e parte dal nuovo System 21. Il modello di controllo è suddiviso in quattro diversi gruppi (Area Acquisti, Area Produzione, Area Supporto ed Area Vendite) ognuno dei quali è diviso in sezioni; per esempio l’area Acquisti è composta dai report sulle “Statistiche di Acquisto” e da quelli sui “Costi di Struttura”.

Ogni report si suddivide a sua volta in più dimensioni che contengono le informazioni fondamentali del controllo. Ovviamente ognuno è destinato ad ambiti aziendali diversi che devono avere accesso solo ed esclusivamente alle informazioni a loro destinate.

L’Area Acquisti

I report dell’Area Acquisti sono due: “Statistiche di Acquisto” e “Costi di Struttura”. Il report “Statistiche di Acquisto” contiene tutte le informazioni di sintesi sull’andamento degli acquisti per tipologia di risorsa ed in particolare:

·         analisi dei volumi di acquisto e di consumo;

·         analisi del prezzo di acquisto;

·         analisi comparativa rispetto agli obiettivi stabiliti e ai periodi precedenti;

·         dati statistici relativi all’andamento macroeconomico.

Questo report è destinato alla Direzione Generale, all’ufficio Acquisti ed alle singole Direzioni Vendite, Produzione e Amministrativa, limitatamente però ai soli dati relativi agli acquisti di loro competenza.

Il report “Costi di Struttura” contiene l’analisi delle spese delle strutture amministrative ed operative con particolare riferimento all’aggregazione delle voci di spesa secondo criteri prestabiliti che evidenzino il costo delle strutture per attività ed al confronto con gli obiettivi di budget e coi periodi precedenti. Esso è destinato, oltre che alla Direzione Generale ed all’Ufficio Acquisti, al Controller, alla Direzione Vendite ed a quella Produzione.

Entrambi i report si basano su un modello multidimensionale composto dalle dimensioni Società, Acquisti, Fornitori e Tempo, suddivise in diversi livelli, e dalle misure Quantità e Valore. La Dimensione Società si divide nei livelli Gruppo, Consociata, Consociata Sede/Filiale, Unità. Il Gruppo è l’aggregato di tutte le aziende che compongono il Gruppo Agrati; nel livello Consociata sono comprese le singole aziende produttive, mentre il livello Consociata Sede/Filiale raggruppa le aziende commerciali, sia come sedi principali che come filiali. Solo le filiali si suddividono poi in unità locali, che rappresentano i vari magazzini di spedizione. I magazzini non sempre contengono merce relativa ad una sola filiale, ma possono anche servire più filiali contemporaneamente.

La Dimensione Acquisti possiede quattro livelli di raggruppamento: Referenza, Classe, Famiglia e Totale di Acquisto. La Referenza di Acquisto è il singolo articolo acquistato, la Classe e la Famiglia (materie prime, rondelle, pallets, attrezzi, ecc.) raggruppano gli item in due livelli intermedi prima del Totale Acquisto, che naturalmente è la spesa aggregata sostenuta per l’approvvigionamento di tutte le merci.

Per ogni società fornitrice esiste una anagrafica, tramite la quale è possibile raggruppare le aziende a livello intermedio nel Gruppo Fornitori, che rappresenta il settore merceologico di appartenenza (acciaierie o aziende che fanno trattamenti superficiali). Eventualmente è prevista una distinzione ulteriore tra fornitori esterni ed interni (Terzi/Intercompany), che, se implementata, prenderà le infor­mazioni dal libro mastro di riferimento in System 21. La valutazione della qualità dei fornitori sarà effettuata in base alla tempestività nelle consegne, alla frequenza dei ritardi, ai ritardi massimi, agli scarti in accettazione, ecc. Attualmente non è stato ancora definito se utilizzare nei report dati reali, estratti dal database qualità, o un punteggio basato su dati storici (vendor rating).

La dimensione tempo prevede aggregazioni che vanno dal singolo giorno a più anni.

Infine nelle ultime due “minidimensioni” si trovano la gestione delle diverse valute utilizzate negli acquisti e l’attribuzione delle operazioni ai diversi centri di costo (per esempio i costi delle vergelle alla produzione o i pallet ai magazzini).

La Arthur Andersen MBA ha previsto, nel suo modello, la distinzione tra dati actual, cioè effettivi, e dati di budget.

Gli altri modelli

Oltre al modello dell’Area Acquisti verranno creati anche quelli dell’Area Produzione, dell’Area Vendite e dell’Area di Supporto.

Il modello della produzione prevede cinque dimensioni principali: Società, Fornitore, Acquisti, Prodotto e Area produzione. Società, Acquisti e Fornitore sono le medesime del modello Acquisti, mentre la dimensione Prodotto com­prende tutti i prodotti finiti e i semilavorati (W.I.P.), raggruppati nei livelli Prodotto, Famiglia (stesso tipo di prodotto di diversi diametri), Tipo (viti o dadi) e Totale. Una ulteriore suddivisione è tra prodotto unificato e prodotto speciale. La dimensione Area Produzione invece raggruppa le macchine in base al loro tipo e all’appartenenza ad uno specifico reparto e sottoreparto; sono incluse anche le informazioni relative ai lotti, ai depositi, agli ordini di prelievo, alle relazioni di intervento (manutenzione) ed ai rapporti di non conformità.

Il modello dell’Area Vendite si compone delle dimensioni Società, Prodotto (uguali ai precedenti modelli), Struttura di vendita, Canale di vendita, Settore merceologico del cliente e Area Geografica. La Struttura aggrega i clienti per agenti, area di vendita (con il relativo capo area) ed in totale; la dimensione Settore merceologico invece li suddivide in base al sottosettore, al settore ed alla loro appartenenza o meno al Gruppo Agrati (Intercompany/Terzi).

Il modello dell’Area di Supporto riguarda le operazioni finanziarie e conta­bili ed analizza le informazioni inerenti i dipendenti, i mastri, le causali di spesa, le valute, ecc.

L’implementazione del modello Acquisti

Per implementare in Cognos il modello dell’Area Acquisti è necessario utilizzare i dati presenti nel database di System 21, integrati da fonti esterne come tabelle Excel e altri sistemi aziendali.

Considerato che il refresh dei report sarà effettuato prima mensilmente e poi, una volta a regime il nuovo sistema, giornalmente, abbiamo deciso di creare in Impromptu quattro query separate, una per ognuna delle tre dimensioni princi­pali ed una per le misure. In questo modo, sarà possibile riutilizzare le estrazioni di dati effettuate per questo report anche per alimentare le dimensioni comuni dei report delle altre Aree (per esempio Società). Inoltre, utilizzando query separate per ogni dimensione, non è necessario creare l’hotfile del catalogo Financial nel Manufacturing per inserire i dati dei fornitori nel modello OLAP di PowerPlay, poiché questi provengono da una Query Definition apposita.

I cataloghi che permettono l’accesso diretto ai dati di System 21 sono già presenti nel pacchetto di installazione di COGNOSuite, in virtù di una collabora­zione tra JBA e la stessa Cognos. In questo modo non abbiamo dovuto accedere direttamente alle tabelle di System 21 per creare tutti i singoli join, ma semplice­mente selezionare dai cataloghi le voci di nostro interesse, già rinominate più chiaramente con l'utilizzo di nomi logici (folder). In ogni catalogo sono infatti presenti diverse librerie, suddivise per argomento, che raggruppano gli accessi ai file del database ed ai loro campi in una visione manageriale ed intuitiva. Ovviamente a noi interessavano solo alcuni dati, presenti nei cataloghi Manufacturing e Financial, per cui abbiamo selezionato i campi necessari ad alimentare il report, (elencati in Tabella 1). Si può notare come, già in fase di creazione, il catalogo Manufacturing, come in generale tutti i cataloghi per System 21, sia stato concepito per comprendere non solo i dati strettamente inerenti la produzione ma anche quelli più comunemente utilizzati, in modo da ridurre al minimo la necessità di ricorrere agli Hotfile.

A commento della Tabella 15 si può dire che nella dimensione Società la distinzione tra sede e filiale avviene semplicemente analizzando il campo STRC20 (Stockroom Code); se il codice magazzino è 00 si tratta di una sede, altrimenti di una filiale. Per quanto riguarda la dimensione Acquisti il livello Classe di Acquisto è generato unendo i codici presenti in PGMJ35 (Item Group Major) e PGMN35 (Item Group Minor) mentre la Famiglia si ricava dai primi sei caratteri del conto DGLA35 (Default G/L A/C). Per i fornitori il Gruppo è definito da SGP105 (Supplier Group 1), un campo appositamente dedicato in System 21. In futuro probabilmente verranno definiti anche gli indirizzi di partenza e di arrivo della merce che saranno scritti nel campo DSEQ05 della tabella PLP05. La dimensione tempo si basa sulla data dell’ordine (OSLD1F3.PMP02.ORDT02), anziché la data di movimento poiché il campo INP95.REFD95 (Date of Movement) non è ancora stato attivato in System 21.

Per completare il modello della Arthur Andersen alla tabella vanno aggiunti altri dati presi dagli altri database aziendali; le informazioni mancanti riguardano i centri di costo e la valutazione della qualità dei fornitori. Queste verranno aggiunte in un secondo momento quando sarà realizzato il collegamento tra Cognos e il resto del sistema informativo.

Una volta configurato il catalogo abbiamo estratto un report per ogni dimen­sione. Poiché il database di System 21 non era ancora totalmente popolato abbiamo dovuto includere anche delle altre misure provvisorie (per esempio la data dell’ordine o il tipo di pagamento) per permettere a PowerPlay di collegare tra loro correttamente le diverse query; queste misure, una volta disponibili tutti i dati, potranno essere rimosse dal report. Poiché alcuni campi contenevano un numero notevole di record, molti dei quali fittizi, per velocizzare le prime estrazioni abbiamo posto un filtro alla dimensione temporale, filtro che andrà tolto quando si vorrà utilizzare il modello in maniera definitiva. Abbiamo salvato ogni report sia in formato .imr, per poter essere riletto da Impromptu, che in formato Query Definition (*.iqd), per passare all’analisi OLAP di PowerPlay.

Query Misure:

COGNOS QUERY
STRUCTURE,1,1
DATABASE,SYSTEM21
DATASOURCENAME,C:\Program Files\Cognos\Prototipo Acquisti\Misure Acquisti.imr
TITLE,Misure Acquisti.imr
BEGIN SQL
select T1."CONO02" as c1,
                  T1."VNDR02" as c2,
                  T1."SSEQ02" as c3,
                  T1."CURC02" as c4,
                  T1."ORDT02" as c5,
                  ((cdate(T1."ORDT02" + 19000000))) as c6,
                  T2."ITEM03" as c7,
                  T2."OQTY03" as c8,
                  T2."PRIC03" as c9,
                  T2."OQTY03" * T2."PRIC03" as c10
from "OSLD1F3"."PMP02" T1,
               "OSLD1F3"."PMP03" T2
where ((T1."CONO02" = T2."CONO03") and (T1."ORDN02" = T2."ORDN03"))
and (T1."CONO02" = 'X1')

END SQL
COLUMN,0,Company Code
COLUMN,1,Supplier
COLUMN,2,Supplier Address Seq
COLUMN,3,Currency Code
COLUMN,4,Order Date
COLUMN,5,Order Date DD/MM/YYYY
COLUMN,6,Item Number
COLUMN,7,Order Qty
COLUMN,8,Unit Price
COLUMN,9,totale ordine

Query Anagrafica Società:

COGNOS QUERY
STRUCTURE,1,1
DATABASE,SYSTEM21
DATASOURCENAME,C:\Program Files\Cognos\Prototipo Acquisti\Anagrafica_Società.imr
TITLE,Anagrafica_Società.imr
BEGIN SQL
select T1."CONO10" as c1,
         T1."CNAM10" as c2,
         T2."STRC20" as c3,
         T2."STRN20" as c4
from "OSLD1F3"."INP10" T1,
      "OSLD1F3"."INP20" T2
where (T1."CONO10" = T2."CONO20")
and (T1."CONO10" = 'X1')
order by c1 asc,c2 asc,c3 asc

END SQL
COLUMN,0,Company Number
COLUMN,1,Company Name
COLUMN,2,Stockroom code
COLUMN,3,Stock Room Name

Query Anagrafica Articoli:

STRUCTURE,1,1
DATABASE,SYSTEM21
DATASOURCENAME,C:\Program Files\Cognos\Prototipo Acquisti\Anagrafica_Articoli.imr
TITLE,Anagrafica_Articoli.imr
BEGIN SQL
select T1."CONO35" as c1,
         T1."DGLA35" as c2,
         T1."PNUM35" as c3,
         T1."PDES35" as c4,
         T1."PGMJ35" as c5,
         T1."PGMN35" as c6,
         (substring(T1."DGLA35" from 1 for 6)) as c7,
         ((cdate(T1."ESDT35" + 19000000))) as c8,
         T2."STRC60" as c9,
         T1."PGMJ35" || T1."PGMN35" as c10,
         T1."ACSU35" as c11
from "OSLD1F3"."INP60" T2,
      "OSLD1F3"."INP35" T1
where ((T2."CONO60" = T1."CONO35") and (T2."PNUM60" = T1."PNUM35"))
and ((T1."CONO35" = 'X1') and (T1."PNUM35" LIKE 'A0%'))
order by c1 asc,c7 asc,c10 asc,c3 asc

END SQL
COLUMN,0,Company Number
COLUMN,1,Default G/L A/C
COLUMN,2,Item
COLUMN,3,Item Description
COLUMN,4,Item Group Major
COLUMN,5,Item Group Minor
COLUMN,6,Famiglia di acquisto
COLUMN,7,Effectivity Start Date DD/MM/YYYY
COLUMN,8,Stockroom code
COLUMN,9,Classe Acquisto
COLUMN,10,Average Cost/ stock unit

Query Anagrafica Fornitori:

COGNOS QUERY
STRUCTURE,1,1
DATABASE,SYSTEM21
DATASOURCENAME,C:\Program Files\Cognos\Prototipo Acquisti\Anagrafica_Fornitori.imr
TITLE,Anagrafica_Fornitori.imr
BEGIN SQL
select T1."CONO05" as c1,
         T1."SUPN05" as c2,
         T1."SNAM05" as c3,
         T1."SGP105" as c4,
         T2."PYTP45" as c5
from "OSLPLF3"."PLP05" T1,
      "OSLPLF3"."PLP45" T2
where ((T1."CONO05" = T2."CONO45") and (T1."SUPN05" = T2."SUPN45"))
and (T1."CONO05" = 'X1')
order by c1 asc,c4 asc,c2 asc

END SQL
COLUMN,0,Company Number
COLUMN,1,Supplier Code
COLUMN,2,Supplier Name
COLUMN,3,Supplier Group 1
COLUMN,4,Payment Type

In Transformer abbiamo caricato le query, collegandole tra loro; poiché il programma crea automaticamente i collegamenti tra di query è stato necessario rinominare alcuni campi aventi lo stesso nome. Inoltre abbiamo aggiunto una tabella di Excel (Sedi.xls) per associare ai codici dei magazzini i loro nomi, dato non registrato da System 21. Con un sem­plice drag-and-drop, abbiamo creato il modello spostando i campi voluti sotto le relative dimensioni nella finestra Dimension Map, creando così il PowerCube. Lanciando da Transformer PowerPlay si apre automati­camente l’analisi OLAP del modello creato.

Conclusioni

Le analisi che abbiamo condotto hanno confermato la corrispondenza tra il modello teorico e quello realizzato in PowerPlay, ma non sono risultate partico­larmente significative dal punto di vista gestionale a causa della presenza di dati fittizi e di campi ancora vuoti nel database di System 21. Quando sarà conclusa l’operazione di interfacciamento tra il vecchio sistema e l’E.R.P. e quando sarà definitivamente popolato il database si potrà utilizzare il modello realizzato, secondo la tempistica prevista dalla Arthur Andersen MBA, come sistema di controllo gestionale.

La realizzazione pratica del modello di controllo della Arthur Andersen è stata relativamente semplice grazie all’intuitiva interfaccia delle applicazioni Cognos. La Suite, in effetti, si è rivelata uno strumento piuttosto versatile nell’uso quotidiano poiché può accedere a dati provenienti da un ampio numero di database, cosa utile in Agrati, dove sono utilizzati svariati tipi di database nelle differenti aree aziendali. COGNOSuite infatti verrà impiegata in futuro non solo per estrarre dati da System 21, ma anche per realizzare altri report direzionali e manageriali, basati su database locali. A questo proposito, però, potrebbe essere migliorata la gestione degli hotfile in Impromptu per quanto riguarda gli accessi contemporanei a database diversi; l’impossibilità teorica di accedere a due o più database nello stesso catalogo infatti è un limite, a nostro avviso, non sempre aggirabile tramite lo spostamento in locale dei dati dai database stessi.

Un altro limite di Impromptu è dato dal fatto che la creazione dei cataloghi deve essere necessariamente fatta da personale dell’area E.D.P., perché i collega­menti di rete con i database non sono molto intuitivi e richiedono una buona conoscenza della struttura del sistema informativo aziendale. Nel nostro caso, la possibilità di utilizzare dei cataloghi già parzialmente predisposti per System 21 ci ha aiutato nella scelta dei dati utili e ad orientarci nella gran quantità di file e librerie create dall’E.R.P..

I tempi di prelievo dei dati, inoltre, si sono rivelati più lunghi del previsto, tanto per la creazione dei report di Impromptu che per quella dei cubi di PowerPlay; durante la fase di training abbiamo potuto stabilire che l’estrazione di un report di poco superiore a centomila record da un AS/400 durava quasi un’ora. Ciò determina, per i nuovi modelli di controllo, la necessità di fare i prelievi dei dati in notturna, utilizzando lo Scheduler di COGNOSuite; l’uso di dati “recuperati” il giorno precedente è comunque accettabile per le finalità dei modelli poiché l’analisi è effettuata sui dati appartenenti ad un lasso di tempo superiore ad un anno e dunque le informazioni raccolte in poche ore non sono generalmente determinanti.

Un modo per fronteggiare questo problema di lentezza potrebbe essere quello di utilizzare PowerCube incrementali, ma alcune prove che abbiamo effet­tuato (su dati estratti dal vecchio database Agrati) non hanno fornito esito positivo; alcuni dati, infatti, venivano duplicati quando si eseguiva il secondo incremento. Probabilmente un più accurato settaggio dei parametri di estrazione in fase di installazione potrà risolvere questo problema.

Un altro problema emerso durante la fase di training è dato dalla relativa “rigidità” dei cubi estratti. Una volta estratto un cubo, infatti, non è più possibile modificarne la struttura, così gli utenti che hanno la necessità di variare i raggrup­pamenti delle categorie debbono necessariamente riestrarre tutti i dati. Per questo inconveniente abbiamo poi trovato una soluzione, che consiste nel modificare la visualizzazione del cubo in PowerPlay (in modalità Reporter), mostrando tutte le categorie di drill-down interessate e rimuovendo quelle non necessarie, fino ad ottenere il raggruppamento voluto.

PowerPlay si è rivelato comunque uno strumento di analisi multidimensio­nale decisamente buono, non mostrando particolari pecche né nella fase di creazione del modello OLAP (in Transformer), né nella fase di analisi, ma, anzi, lasciando aperta agli utenti la possibilità di configurare i propri lavori in modo molto personale, in base alle singole esigenze.

Scenario, l’utility di data mining di COGNOSuite, presenta una buona varietà di soluzioni adatte ad indagare in profondità i dati, anche se si sente la mancanza di uno strumento di analisi predittive come 4Thought, che non è com­preso nella licenza della Suite e deve essere comprato a parte. Scenario infatti è ottimo per scoprire l’andamento dei dati storici, visualizzando i risultati in grafici chiari e significativi, e i rapporti di causa-effetto, grazie all’uso degli alberi di decisione, ma lascia all’utente tutto il compito di estrapolare l’andamento futuro dell’oggetto dell’analisi.

Pregi e difetti riscontati nell’interazione tra System 21 e Cognos

Pregi:

·         Cataloghi già parzialmente realizzati;

·         Possibilità d’accesso a diversi tipi di database;

·         Versatilità d’uso;

·         Interfaccia grafica intuitiva;

·         Personalizzazione dei report e delle analisi OLAP;

Difetti:

·         Necessità di personale specializzato per ottimizzare le prestazioni delle estrazioni e delle analisi;

·         Lentezza nell’estrazione dei dati.

Torna in alto