Capitolo 2
L’avanzamento del progetto ETL
2.1 SAL di Area
2.1.1 Gestione Commesse d’Investimento e Codice di Rete
Essendo il primo SAL si è provveduto a fare un piccolo sommario delle attività svolte ad oggi (08/11/2005) dopo un mese di lavoro. Fino ad oggi sono state svolte riunioni, coinvolgendo risorse interne (operativi Toscana Gas) e esterne (consulenti BIP, fornitori sistemi legacy) al fine di presentare gli oggetti tecnici: per ogni oggetto si sono visti quali sono gli attributi al fine di condividere la fase di Mapping, ovvero verificare la presenza o meno dei dati sui sistemi legacy. All’interno dei tavoli di condivisione delle informazioni sono sorte alcune problematiche che hanno scaturito talune soluzioni e riprogrammazione di talune attività, vediamo un esempio: STR (fornitore legacy di Linea 32 e Planet: applicativi di progettazione per le commesse d’investimento) non ha dati da fornire indi i dati per questa area saranno costruiti ex-novo sui sistemi SAP.
In più uno dei key-user di quest’area provvederà a caricare gli indicatori statistici a livello di WBS sui singoli comuni di pertinenza (attività manuale). Per quanto riguarda le WBS specifiche (maggiori di 300 metri a livello d’estensione) e il preventivo tecnico (inteso nell’accezione SAP: ovvero i costi sostenuti dalla Distribuzione per effettuare i lavori di manutenzione o di allacciamento) anch’esse saranno caricate manualmente.
E’ pianificato un incontro con il fornitore STR per vedere com’è possibile integrare i suoi applicativi con SAP. Una volta che il fornitore SAP avrà le necessarie informazioni su tempi, metodi e costi deciderà se implementare o meno le interfacce necessarie.
Scadenze: fino ad oggi l’area AFCO –Amministrazione Finanza e Controllo- non è stata
interessata e coinvolta in nessuna riunione a causa di alcuni documenti mancanti che sono stati forniti dal partner Italgas.
Sarà necessaria la presenza dei soggetti AFCO al fine di costruire in modo completo le Work Breakdown Structure e i relativi codici di identificazione (!!punto di attenzione!!).
Relativamente all’area Codice di Rete (CodRe) e quindi l’applicativo Lodestar sono state svolte delle attività:
un incontro con una risorsa BIP al fine di riprendere aspetti relativi ai progetti e effettuare una lista degli oggetti tecnici in merito alla funzione CodRe,
disanima dei singoli oggetti tecnici con due risorse BIP, di cui una tarata bene anche sull’applicativo Agenda per chiarire i dubbi in merito al rispetto delle delibere dell’A.E.E.G.
Area d’attenzione: CodRe è un area più lenta rispetto alle altre poiché vi sono talune
problematiche, ovvero:
complessità degli oggetti tecnici,
condivisione oggetti tecnici con alcune aree (AFCO ad esempio, che essendo ferma è
bloccante per gli altri soggetti in gioco).
Lodestar è un applicativo ibrido che ha una vista commerciale del PDR e alcune informazioni di tipo tecniche condivise con altri moduli di SAP (PM per esempio).
E’ importante evitare di chiedere due volte i dati ai fornitori di sistemi legacy, poiché in fatto di tempi e costi risulta essere un dispendio di risorse. Quindi l’oggetto è visto come oggetto logico con più viste: ovvero informazioni sia tecniche che commerciali. Ad oggi questa attività è svolta in merito a Lodestar e i suoi oggetti saranno integrati con quelli PM (Plant Manteinance) per gli aspetti condivisi. Una volta completata la definizione s’interrogheranno i consulenti dei sistemi legacy al
Work Breakdown Structure –WBS– (letteralmemente struttura di progetto dettagliata):
rappresenta una disaggregazione del progetto in elementi (Work Breakdown Element o WBE). E’ normalmente rappresentata mediante una struttura gerarchica a più livelli. Temporalmente il progetto (di rete) ha una data effettiva d’inizio e di fine e può essere pluriennale.
WBE: Work Breakdown Element anche detto elemento WBS. E’ il singolo elemento della struttura; è un oggetto di contabilizzazione ed uno strumento di pianificazione e consuntivazione di tempi e costi dell’attività.
Dubbi: Il consulente dell’applicativo Mosaico -per la realtà ex-Publienergia- ha buone conoscenze
sul sistema ma non sulla semantica del dato, indi si userà una risorsa dedicata che possa sopperire a queste mancanze. La risorsa in oggetto è pratica sugli applicativi poiché li utilizza a livello giornaliero.
A livello di sviluppi attuali e futuri vediamo che le attività da fare sono:
Mapping: ovvero il dato esiste sui sistemi sorgente?
Rischi e criticità: comprendere al meglio il significato dei campi in gioco ed in più
essere sicuri che il dato è stato prelevato da tutti i sistemi (applicativi) che lo utilizzano.
Fase attuale: consolidamento di quello che c’è disponibile a livello di dati.
Fase futura: definire le specifiche d’estrazione (dai sistemi legacy verso DBT) e di censimento (reperire su campo o da altre fonti –documenti cartacei–, ad esempio, le informazioni necessarie).
Work in Progress: vi sono alcune questioni delicate in corso di risoluzione o in attesa. Vediamone alcune:
Per l’area AFCO le risorse di consulenza BIP sono in attesa che la shell service SOFID di Italgas definisca in modo chiaro ed univoco il codice d’identificazione delle WBS. Questa codifica sarà ripetuta in egual modo nei sistemi TG.
Per l’area PS (SAP) è necessario gestire i ricavi e i costi di TG al fine di ribaltarli sulle WBS.
Per l’area CodRe sarà necessario chiarire la differenza tra i fattori K e M, correttori per i volumi, poiché il gas aumentando l’altezza aumenta di pressione. Di conseguenza a seconda della conformazione geografica coloro che vivono in case sopra il livello del mare hanno una maggiore pressione di gas e quindi portata e per questo motivo devono pagare un importo maggiore rispetto agli altri clienti.
o Prossima attività: si farà una riunione di confronto tra più soggetti, poiché i sistemi
legacy di TG gestiscono la cosa in molti modi differenti, sarà necessario trovare un indirizzo comune e che sia rispondente alle esigenze di SAP.
Condividere costi-benefici in merito al recupero dati da sistemi legacy. Per condivisione si intende un attività a metà tra Toscana Gas e società di consulenza BIP. Da questo punto di partenza scaturiscono tutta una serie di considerazioni:
o a livello di business, per l’autority, lo storico serve o meno?
o se vi sono alcuni dati importanti per la funzione CodRe ma non gestiti da SAP: sarà possibile mantenerli? quanto costerà? Esempio: attualmente si riesce a sapere il costo orario della singola risorsa, domani sarà possibile continuare a farlo (criticità relativa al fatto di non aver acquistato il modulo HR -Human Resource- di SAP).
Problema: non tutte le aree potevano partire allo stesso livello, alcune aree di lavoro sono state più
veloci, altre più lente.
Scadenze: il go-live dei sistemi SAP alla data 1 Giugno 2006 è confermato.
Si ritiene giusto che ogni singola area sia informata dell’attività delle altre aree. A questo scopo si impostano dei SAL di area e poi di progetto per mostrare l’avanzamento del progetto all’amministratore delegato (AD). Quando si andranno a definire le specifiche i SAL di area e di progetto coincideranno per avere una condivisione il più alta possibile a livello di informazioni fra i membri dei singoli gruppi. Il sistema a quel punto non sarà più visto in termini di moduli SAP ma come un blocco unico. Nella fase di definizione delle specifiche tecniche ci sarà bisogno di più di un tavolo d’integrazione tra le varie aree di lavoro. Questa è una scelta non di tipo tecnico ma bensì funzionale in quanto taluni dati saranno condivisi da più funzioni.
Necessità degli attori TG: avere una chiara visione di quello che fanno le altre aree (risorse
interne TG) e di quello che fanno i consulenti esterni (BIP).
Soluzione proposta: a livello settimanale vi saranno una sorta di newsletters di progetto.
Toscana Gas gestisce la delibera 47/00 completa al fine di produrre la documentazione all’autority in merito agli interventi presso la clientela, Italgas invece utilizza quella temporanea, che dura dodici mesi. Questa tematica riguarda i rapporti Toscana Gas – Italgas: è un aspetto strategico. La società di consulenza farà approfondimenti sulla situazione Italgas, comunque questa tematica non impatta sull’applicativo Lodestar bensì su Agenda.
Problema: la società di consulenza ha una visibilità completa di Toscana Gas e parziale di Italgas.
Fiorentina Gas non è un esempio utile su cui lavorare in quanto anche loro seguono la linea proposta da Italgas.
Delibera 47/00: è una direttiva concernente la disciplina dei livelli specifici e generali di qualità commerciale dei servizi di distribuzione e di vendita del gas. Si individuano indicatori di qualità commerciale del servizio a due livelli: generale e specifico.
Nella definizione dei livelli specifici di qualità del servizio relativi ai fattori commerciali, si fa riferimento ai seguenti indicatori:
tempo di preventivazione per l’esecuzione di lavori semplici; tempo di esecuzione di lavori semplici;
tempo di attivazione della fornitura;
tempo di disattivazione della fornitura su richiesta del cliente;
tempo di riattivazione della fornitura in seguito a sospensione per morosità; fascia di puntualità per gli appuntamenti con i clienti.
Nella definizione dei livelli generali di qualità del servizio relativi ai fattori commerciali, si fa riferimento ai seguenti indicatori:
tempo di preventivazione per l’esecuzione di lavori complessi; tempo di esecuzione di lavori complessi;
tempo di risposta a richieste di rettifica di fatturazione;
tempo per l’effettuazione della verifica del gruppo di misura su richiesta del cliente;
tempo per l’effettuazione della verifica della pressione di fornitura su richiesta del cliente;
tempo di risposta motivata dell’esercente a reclami scritti o a richieste di informazione scritte;
tempo di arrivo sul luogo di chiamata per pronto intervento; grado di rispetto degli appuntamenti con i clienti;
2.1.2 Manutenzione
Dopo un mese d’attività si relaziona lo stato del lavoro anche per questa area. A fine Settembre c’è stata la presentazione degli oggetti tecnici di competenza dei moduli PM (Gestione Impianti) e CS (Servizio alla Clientela). In merito agli oggetti si sono definiti gli attributi che sono la base per l’attività di mappatura. Sono stati distribuiti i tracciati record al SIT (Sistema Informativo territoriale) e ai fornitori di sistemi legacy: Neta per l’applicativo iCis, Publiservizi per Mosaico.
Decsisione: si è scelto di fare un unico documento per PDR e contatori, che contenga la
spiegazione di tutti i campi. La società di consulenza ha ricevuto di ritorno dai fornitori dei sistemi legacy dei documenti completi con piccoli dubbi da risolvere.
Obiettivo: attualmente la direzione del progetto è di dire se il dato è disponibile o meno. Se esso
non è disponibile si utilizzano le idee degli operativi Toscana Gas al fine di reperire il dato da altre fonti, o al limite fare un censimento –a campione– su campo.
Priorità: avere tutte le informazioni in merito a PDR e contatori, in quando questi due oggetti sono
core per il business e per il sistema SAP.
L’attività attuale in merito alla società di consulenza è quella di fare azione di consolidamento sull’esistente.
Punti d’attenzione: un'altra banca dati denominata Codice di Rete oltre a quelle menzionate
gestisce l’oggetto PDR, in merito all’attività di switch: ovvero passaggio da Toscana Gas Clienti ad un'altra società di vendita. Il problema è che uno dei sistemi in gioco, ovvero iCis vede il contatore attivo se e solo se è allocato presso Toscana Gas Clienti, in realtà non è così. Il contatore è attivo anche se allocato presso un'altra RelCo.
Rischi: esistono vari rischi in merito al fatto d’essere sicuri di possedere tutte le informazioni
necessarie sul contatore. Esempio: relativamente al campo stato del contatore, 45.000 unità su 150.000 in campo (realtà ex-Ages), presso il SIT, risultano essere chiusi invece ciò non è vero poiché sono contatori rimossi.
Un punto di forza nei sistemi esistenti Toscana Gas è il fatto di possedere l’applicativo iCis che è quello più trasversale fra tutti: i dati utilizzati da CodRe, per esempio, sono una parzialità di quelli dell’applicativo sopra menzionato, difatti sono state fatte delle estrazioni a livello locale dal sistema di cui sopra. Il dato, comunque, necessita oltre ad essere mappato di essere bonificato al fine di avere un dato pulito all’origine.
Tematica ricorrente: in questo ambito spesso l’argomento finisce sui contatori rimossi che vanno a
costituire lo storico. Di solito questo tipo di contatori è distrutto tranne che in particolari casi. Vi sarà in futuro una scelta su cosa decidere di portare e cosa invece no.
Come abbiamo visto i PDR sono corredati di informazioni che derivano da molte fonti, in più esso si lega ad altri oggetti che hanno una vita più dinamica. Le definizioni d’indirizzo e utenza possono essere differenti, quindi si coinvolgeranno i fornitori di Mosaico e iCis per risolvere il problema. Esempio: Mosaico nel campo indirizzo scrive via e nome della stessa, SAP non ragiona secondo questa logica e richiede solo il nome della via.
Problemi su PM:
1- non si ha una chiara e precisa identificazione della lunghezza dei metri di rete. Vi sono tre casi
possibili che si possono presentare per la realtà Toscana Gas:
Comuni gestiti totalmente (su questi comuni TG fa veri e propri investimenti) e quindi soci
Comuni non soci ma con cui vi sono delle convenzioni (quì TG fa solo manutenzione)
Frazioni inserite in Comuni non gestiti e non convenzionati
Soluzione: la società di consulenza ha proposto di inserire i metri di rete della frazione nel comune
limitrofo. A questo punto sorge un problema a livello pratico degli operativi TG, che perdono traccia della reale situazione metrica sulla frazione in esame. A livello di reportistica vi è una richiesta da parte di TG di riuscire ad evidenziare nel report l’informazione relativa ai metri in campo sulla frazione, e quindi di avere un livello di dettaglio il più fine possibile.
2- risulta essere mancante il dato relativo al diametro delle tubazioni in campo.
Soluzione: il key-user propone di completare l’attività relativa al censimento su campo delle
tubazioni esistenti sulla rete TG. L’impressione e che questa attività era già in corso d’opera quindi non occorrerà tanto tempo il portarla a compimento.
3- definizione del codice PDR: si pone la scelta di introdurre già nel sistema AS-IS il concetto di
codice PDR, ma pare essere troppo pesante. Il codice PDR è formato da 4 caratteri e poi 11 numerici.
Soluzione: dare un codice ex-novo a tutti i PDR. L’allocazione PDR su ex-Publienergia o ex-Ages
si capirà dai comuni. Sui PDR la cosa più difficile non sarà trovare e definire le logiche per battezzare i PDR, ma sarà importante, quando ci sarà il Go-Live, il collegamento con gli altri oggetti tecnici. Esempio: se su un PDR cambio il misuratore ne devo tenere traccia. E’ necessario avere una dimensione media di quanti cambiamenti dovrò tenere traccia, un key-user ipotizza che in 4 mesi cambieranno circa 1000 contatori. Quindi è necessario che al 31/12/2005 i sistemi iCis e Mosaico, i quali fino a Giugno saranno ancora in vita, “battezzino” i PDR.
Sarà necessario avere delle riunioni fra risorse BIP e TG per creare la connessione PDR-contatore.
4- avere informazioni precise sulle strutture: IPRM, GRF, Sistema di Protezione Catodica. In più
un key-user di manutenzione richiede di avere una precisa definizione di IRI. L’operativo in questione ipotizza che siano cabine di secondo salto: in realtà ce ne sarebbero due: una a Pistoia e una a Tirrenia (provincia di Pisa).
2.1.3 Attività presso la clientela
La società di consulenza BIP ha fornito i tracciati record ai fornitori di sistemi legacy (Publiservizi per Mosaico, Futura per Allacci). Per le tabelle non completate si è fatto un secondo invio e si è richiesto di completare gli aspetti mancanti. La parte Mosaico è completa, quella di Allacci è in via di completamento.
Per la compilazione dei cicli di lavoro si andrà a vedere ciò che ha implementato Fiorentina Gas. Cabina di secondo salto: è un riduttore di pressione. A questa classe appartengono tutte quelle cabine che alimentano reti più o meno estese di bassa pressione a servizio diretto dell’utenza. In queste l’impianto di condizionamento non è presente in quanto il salto di pressione, quindi di temperatura, è contenuto.
La normalizzazione (esempio: Via Galilei diventa Galilei) di Allacci e Mosaico è affidata a Stradario che gira sulla tecnologia Navteq. I sistemi Toscana Gas AS-IS hanno un maggior livello di dettaglio rispetto ai sistemi di destinazione per taluni aspetti. Attualmente in Toscana Gas si riesce a definire in modo preciso il prezzo di un operativo, domani questo sarà ancora possibile sui sistemi ASI ? (!!punto di attenzione!!)
I cicli di lavoro possono essere utilizzati sia direttamente negli Ordini di Lavoro che all’interno di Programmi di Manutenzione. Nel primo caso rappresentano le operazioni standardizzate da inserire nell’Ordine di Lavoro per facilitare la compilazione dello stesso, nel secondo caso rappresentano le fasi lavorative da eseguire a determinate scadenze su una certa classe impianto/sede tecnica/equipment.
Un ciclo di lavoro standard contiene tutte le operazioni (fasi lavorative) da eseguire in una manutenzione, l’elenco degli eventuali materiali/prestazioni da utilizzare per tipologia di lavoro.
Utilizzando i cicli di lavoro si riduce il tempo richiesto per completare la preventivazione degli Ordini di Lavoro e si stabiliscono gli standard per interventi come le ispezioni o analisi.
I Cicli di lavoro possono essere legati a sede tecnica/equipment o generici. In quest’ultimo caso sono detti Istruzioni.
In ciascun ciclo saranno inserite operazioni classificabili in una delle seguenti tipologie:
o operazioni interne: eseguite da manodopera interna differenziata per centro di lavoro, con eventualmente associati i codici materiali e le quantità da utilizzare;
o operazioni esterne: eseguite da imprese esterne. Ad ogni operazione saranno associati:
i codici e le quantità delle prestazione di servizio erogate dall’impresa
i codici materiali e le quantità da utilizzare nel caso in cui questi siano forniti da Toscana Gas
Considerazioni:
TG: Necessita di sapere, mediante i SAL, dove siamo e dove stiamo andando, avere quindi una
maggior visibilità dell’attività progettuale.
BIP: Chiede a Toscana Gas di avere una chiara visibilità del business TG. Esempio: BIP vede
un’attività di TG come a sé stante, in realtà, vista dall’interno TG l’attività in questione è collegata con altre.
Toscana Gas è stata poco coinvolta nell’attività di mapping, poiché essa è molto tecnica. Nella fase successiva, ovvero quella di definizione delle specifiche tecniche, si avrà un “lavoro a più mani”: CS sarà strettamente legata a CodRe. Le varie aree di progetto avranno parti specifiche di funzione e altre condivise tra più aree funzionali.
2.1.4 Approvigionamenti e Logistica
A fine Settembre c’è stata la presentazione degli oggetti tecnici relativi alle seguenti aree: approvvigionamenti, logistica, vendite. Per ogni oggetto sono stati illustrati i relativi attributi e c’è stata la condivisione dei tracciati record, i quali sono stati distribuiti ai key-users di Toscana Gas. Le risorse TG hanno riconsegnato i seguenti tracciati ed adesso si vedrà come procedere. Allo stato attuale la società di consulenza sta facendo attività di consolidamento per fissare eventuali incontri con i fornitori dei sistemi legacy. D’ora in poi sarà necessario che le varie aree di progetto si muovano in modo omogeneo. L’area vendite è ancora un po’ indietro e quindi non sono ancora stati inviati i tracciati record ai fornitori dei sistemi legacy.
Punto di attenzione fondamentale: è basilare definire la struttura organizzativa aziendale in
merito alla logistica. Sarà necessario definire quanti e quali sono i magazzini. Definire la struttura organizzativa è alla base dell’implementazione di un ERP.
Soluzione possibile: si potrebbe decidere di esternalizzare il processo di logistica. La questione,
relativamente a SAP, è di capire se i materiali rimarrano di proprietà TG o meno. Se rimangono proprietari per SAP il problema non si pone. Alcuni codici strategici (i contatori ad esempio) rimangono in gestione all’azienda. Quando si esternalizza, comunque, è basilare avere una piena conoscenza del processo in esame.
Aree di attenzione:
Altro punto delicato è quello relativo alle anagrafiche dei materiali, ovvero si dovrà decidere se prendere queste informazioni da distribuzione (che lavora su cartaceo) o da logistica (database applicativi legacy: Sigla++ e Mosaico), in quanto vi sono due gruppi di lavoro che forse svolgono in parallelo la medesima attività ovvero unficare i codici presenti a magazzino agli standard di Italgas (!!spreco di risorse!!). Si prevede che l’attività della distribuzione sarà conclusa per fine dicembre.
Soluzione possibile: fare il punto della situazione con key-user di CodRe per poter validare i codici
materiali prodotti dal key-user di Logistica.
In merito alla suddetta questione il key-user di Approvvigionamenti pone il problema che, indipendentemente dall’unificazione, vi saranno alcuni materiali che vanno caricati comunque a sistema SAP. Per fare ciò saranno utilizzati dei particolari criteri.
Il fornitore dell’applicativo Mosaico non ha inviato, allo stato attuale, giacenze, anagrafiche materiali e layer per fare LIFO o costo medio ponderato. Il fornitore STR non invierà dati, in quanto le prestazioni d’acquisto ovvero il listino (elenco) prezzi è creato dal key-user di CodRe/INV. Questo elenco è presente nel contratto generale e in quelli specifici che sono utilizzati dal key-user di APP.
Una struttura che è importante per i sistemi SAP di destinazione sono i layers LIFO. Ad oggi nei sistemi TG si utilizzano due valorizzazioni: LIFO (per la realtà ex-Publienergia), costo medio ponderato (per la realtà ex-Ages).
Decisione: vedere se a dicembre 2005 si deciderà di chiudere a LIFO o con un altra modalità
contabile.
Priorità: SAP ha bisogno degli strati (layer) LIFO mese per mese. Fornitori sistemi legacy:
- Mosaico: utilizza allo stato attuale la chiusura annuale a LIFO.
- Sigla ++: l’opzione LIFO è presente a sistema ma non è mai stata utilizzata. In realtà mancano le formule per calcolare il LIFO, che quindi andrebbero implementate sul sistema legacy in esame.
Vedere dov’è gestita la pubblica illuminazione e la corrispondenza ai sistemi ASI di destinazione.
I materiali di consumo sono gestiti in modo diverso da sistemi ASI e ESI. Il primo codfica i materiali e li gestisce a quantità, il secondo gestisce solo le quantità. ESI gestisce tutto mediante e-procurement.
E’ fondamentale definire le strategie di rilascio per i documenti degli Approvvigionamenti. Proposta della consulenza: l’area approvvigionamenti di Italgas ha già definito delle procedure
possibili per il rilascio dei documenti. TG dovrà decidere se questi modelli sono adattabili alla sua realtà oppure se vi sono soluzioni più semplici. Le strategie in TG comprendono le procure e altri oggetti di business.
Prossime attività: l’area SD è un po’ indietro e coinvolge attori diversi da quelli di APP/LOG.
Questi soggetti saranno coinvolti in una riunione in cui verranno presentati i tracciati degli oggetti da migrare per il modulo SAP di destinazione SD: anagrafiche clienti, prestazioni e contratti di vendita.
2.1.5 Avanzamento attività di bonifica e censimento
Questa riunione è stata l’ultima di un primo ciclo di SAL. L’obiettivo della stessa è stato quello di:
– contestualizzare le attività del progetto “Conversione dati di ToscanaGas” in un quadro più ampio che comprende anche le attività di final preparation e Roll-out tecnico;
– condividere le principali evidenze emerse dalla fase di mapping del modello dati di Toscana Gas con il modello dati di Italgas;
– condividere le prime risultanze della fase di definizione della strategia di conversione del modello dati di Toscana Gas al fine di renderlo compatibile con il modello dati Italgas.
In particolare saranno presentati:
l’elenco, non esaustivo, delle attività di bonifica e censimento, necessarie a completare la fase di popolamento del Data Base Transitorio; attività propedeutica alla fase di “final preparation”;
il macro piano delle attività di censimento e bonifica; date entro le quali queste attività dovranno essere completate.
E’ bene riproporre a livello grafico il macro piano di progetto:
Settembre Ottobre Novembre Dicembre Gennaio Febbraio Marzo Aprile Maggio Giugno
Fase di Conversione Mapping di dettaglio Logiche di Conversione Realizzazione e test Roll-out tecnico Realizzazione estrattori Simulazione Cut-over
Di seguito vi sarà un analisi delle fasi svolte allo stato attuale:
Mapping di dettaglio
Obiettivi della fase Azioni intraprese • Determinare gli oggetti di business da
definire nel Data Base transitorio, necessari alla fase di roll-out tecnico; • Per ogni oggetto di business individuato
dettagliare:
– gli oggetti tecnici della mappa ASI che lo descrivono (caricatori, tabelle, attributi di dettaglio);
– i sistemi Toscana Gas alimentanti con il dettaglio delle tabelle e dei relativi campi; – eventuali divergenze di processo
nella gestione dell’oggetto di business/tecnico
• E’ stata collezionata e approfondita la documentazione relativa al modello dati ASI
• E’ stata avviata una serie di incontri per l’approfondimento di temi specifici inerenti le Aree di progetto costituite in Toscana Gas
• Sono stati individuati i sistemi sorgenti e i relativi fornitori. Per ognuno di questi sono stati analizzati preventivamente i possibili dati estraibili dal sistema
• Sono stati inviati ai fornitori i tracciati di dettaglio degli oggetti tecnici da migrare Logiche di conversione
Mapping di dettaglio
Realizzazione e test
In merito all’attività di mapping si sono ottenuti i seguenti risultati, relativamente alle varie aree di progetto.
Progetti di investimento (Area PS di SAP)
Non sono stati individuati sistemi legacy per la gestione delle WBS (oggetto di imputazione contabile delle attività di Toscana Gas utilizzato per la pianificazione e la consuntivazione dei costi e degli obiettivi fisici dei lavori).
Attività presso la clientela (Area CS di SAP)
Gli Ordini di Servizio e le Offerte Commerciali sono gestite attraverso i sistemi Allacci (Pisa) e Mosaico (Empoli/Pistoia). L’attività di mapping ha evidenziato la necessità di:
convertire i dati dai sistemi legacy sorgenti per mapparli correttamente sul modello a tendere (es. PdR, listini prezzi, ecc.);
inserire manualmente nel DBT dati mancanti o presenti in forma cartacea (preventivi non ancora accettati, listini prezzi, ecc.).
E’ assente, nei sistemi legacy sorgenti, l’oggetto “Ciclo di lavoro” (pacchetto di operazioni precostituite per la gestione di attività standard utilizzato per facilitare la valorizzazione dei preventivi tecnici).
Manutenzione impianti (Area PM di SAP)
L’attività di mapping ha evidenziato la presenza di più sistemi alimentanti Allacci/iCis (Pisa), Mosaico (Empoli/Pistoia), Vettoriamento, SIT (Sistema Informativo Territoriale) e alcuni fogli excel dislocati presso le UOT.
E’ assente il concetto di PdR ed è necessario ricostruire la struttura delle principali sedi tecniche gerarchiche e logiche alle quali il PdR è connesso. Alcune entità, oggetto di conversione, dovranno essere ricavate a posteriori una volta determinate le relazioni tra sedi tecniche e PdR.
E’ emersa la necessità di effettuare censimenti sul campo (es. rilevazione del diametro delle tubature).
Non sono stati individuati sistemi alimentanti o documentazione elettronica per le anagrafiche dei fabbricati e dei convertitori.
Codice di Rete (Area Lodestar)
Sono stati individuati quattro sistemi legacy sorgenti per l’estrazione degli oggetti definiti nell’area Codice di Rete: Allacci/iCis (Pisa), Mosaico (Empoli/Pistoia) e Vettoriamento.
Tutti i principali oggetti da definire nel DB Transitorio sono presenti sui sistemi sorgente o ricavabili mediante opportune logiche, in particolare:
è assente il concetto di PdR;
le letture saranno estratte dai sistemi legacy in accordo alla copertura d’ambito geografico/funzionale;
gli oggetti Impianti, Comuni, Shipper e Tariffe sono presenti sul sistema Vettoriamento. E’ in corso di approfondimento la completezza di alcune anagrafiche sulla base del censimento comuni-impianti in corso di lavorazione da parte di Toscana Gas.
Approvvigionamenti (Area MM di SAP)
L’attività di mapping ha evidenziato la presenza del sistema alimentante GINA da cui estrarre il legame tra il fornitore e il gruppo merci per l’attività di qualifica fornitore.
Non ci sono sistemi alimentanti da cui estrarre i contratti di acquisto, ad eccezione dei contratti di prestazioni di rete per i quali è stato individuato il sistema STR-PLANET nel quale sono presenti i listini di acquisto definiti per ogni contratto.
E’stato individuato il sistema alimentante STR-PLANET per la codifica delle attività di rete e l’alimentazione dei listini, resta da determinare se mantenere la codifica o recepire i codici di Fiorentina Gas.
Logistica (Area MM di SAP)
L’attività di mapping ha evidenziato la presenza di due sistemi alimentanti, MOSAICO e SIGLA++, da cui è possibile estrarre le giacenze (quantità e valore) dei materiali a magazzino. La ricostruzione dei layer lifo è possibile solo sul sistema MOSAICO relativo ai materiali di Empoli e Pistoia.
L’attività di codifica dei materiali, curata dalla logistica e dalla distribuzione, sarà utilizzata come tabella di transcodifica per i valori di giacenza.
La giacenza dei materiali consegnati alle squadre e alle imprese è presente sui sistemi ma è poco significativa (in particolare per l’area di Empoli e Pistoia).
Vendite (Area SD di SAP)
L’attività di mapping non ha evidenziato la presenza di sistemi legacy alimentanti da cui estrarre i dati.
Logiche di conversione
Obiettivi della fase Azioni intraprese • Definire le logiche di caricamento degli
oggetti, individuati nella fase di mapping, al fine di popolare il DB Transitorio;
• Individuare le eventuali attività di censimento / bonifica dei dati;
• Scrivere le specifiche tecniche degli estrattori dei sistemi legacy Toscana Gas;
• Analisi dei dati raccolti durante la fase di mapping;
• Incontri congiunti fornitori – process owner Toscana Gas per la determinazione delle principali logiche di estrazione dati dai sistemi legacy Toscana Gas;
L’attività di definizione delle logiche di conversione è attualmente in corso (fine Dicembre). E’ stata conclusa una prima fase di incontri con i fornitori dei sistemi legacy che ha permesso di identificare, per i principali oggetti di conversione, la strategia di estrazione e caricamento dei dati sul DB transitorio.
Mapping di dettaglio
Logiche di conversione
Realizzazione e test
In particolare:
o E’ stata definita la strategia di definizione dell’anagrafica PdR/misuratori sui sistemi legacy: • In iCis sono disponibili i PdR allacciati attivi sull’Area Pisa e San Giovanni Valdarno • Su Allacci vi sono i PdR non ancora allacciati sull’Area Pisa e San Giovanni Valdarno • Mosaico gestisce la totalità dei PdR dell’area Empoli/Pistoia
• Vettoriamento contiene la totalità dei PdR gestiti nativamente da società terze (switch) • Sono state censite le attività di eventuale bonifica e censimento manuale necessarie a
completare il modello dati ASI, di cui si da evidenza in seguito.
• E’ stato realizzato un primo piano di caricamento delle tabelle del DB Transitorio. Attività di bonifica e censimento
L’attività di bonifica e censimento dei dati è fortemente legata alla qualità dei dati presenti nei sistemi legacy di Toscana Gas, pertanto:
– le attività nel seguito riportate rappresentano le prime evidenze emerse dalla fase di definizione delle strategie di conversione, ricavate senza analizzare i dati presenti nei sistemi legacy;
– è necessario un approfondimento di analisi a valle di verifiche della qualità dei dati presenti, ad oggi, nei sistemi legacy
– nuove attività di bonifica e censimento dati potranno essere necessarie a valle della prima estrazione dai sistemi legacy Toscana Gas.
Queste premesse portano ad avere delle priorità e fare delle decisioni importanti, quali:
• individuare un coordinatore unico per le attività di censimento e bonifica dei dati;
• individuare, all’interno delle singole aree funzionali, figure responsabili dell’attività di censimento e bonifica dei dati;
• attivare meccanismi di monitoraggio dello stato di avanzamento delle attività di bonifica e censimento.
Si vede adesso (alla pagina seguente), per ogni area di progetto, quali sono gli oggetti tecnici che devono essere censiti o bonificati.
Bonifica e censimento area PS
Oggetto di
conversione Tipo Attività Attività Date limite WBS: oggetti di
imputazione contabile D Definire 23 gennaio
Indicatori statistici
(dati di contabilità) D
Definire e continuare ad aggiornare
fino al momento del roll-out 17 marzo
Tipo di gas B Confermare a partire dal modello Fiorentina Gas
31 gennaio (Conclusa) Devoluzione della rete B Confermare a partire dal modello
Fiorentina Gas
31 gennaio (Conclusa) Tabella per
inserimento automatico dei dati amministrativi nelle
WBS di rete
B
Attività preliminare di definizione dei Centri di costo e di profitto ed
eventuale successiva bonifica.
28 febbraio
Elenco delle aree B
Attività preliminare di definizione della struttura organizzativa e
successiva bonifica
Bonifica e censimento area CS
Oggetto di conversione
Tipo
Attività Attività Date limite
Ordini di servizio B
Attività di bonifica da effettuarsi sui sistemi legacy prima della fase di estrazione. OdS Testata: bonifica indicazione impianti di
distribuzione per comuni forniti da più impianti
Attività, Permessi, PdR, Ods Esteso: bonifica del legame con la testata Materiali: bonifica del legame con la testata e
identificazione del codice materiale (solo Allacci)
28 aprile
Offerte commerciali B
Attività di bonifica da effettuarsi sui sistemi legacy prima della fase di estrazione. Ods: bonifica indicazione impianti di distribuzione per comuni forniti da più
impianti
OC, Permessi, PdR: bonifica del legame con la testata 28 aprile Cicli (testata, operazioni, componenti): pacchetti di operazioni/componenti standard precostituiti B
Attività preliminari di definizione strutture organizzative, tariffe, magazzini e contratti
quadro. Da definire a partire dai cicli Fiorentina Gas.
31 gennaio
Giorni di tolleranza dell'Offerta Commerciale
B Confermare a partire dal modello Fiorentina Gas. 31 gennaio (Conclusa) Tabella di associazione UOT-Magazzino.
Giorni di scadenza offerta per tipo di
lavoro
B Confermare a partire dal modello Fiorentina Gas. 31 gennaio (Conclusa) Elenco comuni in franchigia D Definire 31 gennaio (*Conclusa in quanto non vi sono
comuni di questo tipo presso Toscana
Gas) Elenco delle
prestazioni in franchigia
D Attività preliminare di definizione delle
prestazioni e successiva definizione. 31 gennaio (*)
Elenco dei materiali in
franchigia D Definire 31 gennaio (*)
Elenco degli operai che eseguono gli
interventi D Definire 31 gennaio (*) Tabella per il caricamento delle WBS negli OdS e negli OdM.
D Attività preliminare di definizione delle WBS
e successiva definizione 28 febbraio
Anagrafica squadre D Definire 31 gennaio (*)
Tabella di associazione
Squadra-Magazzino
D
Attività preliminare di definizione dei magazzini e successiva associazione squadra–
magazzino
31 gennaio (*)
Listini prezzi per redazione offerte
commerciali
Bonifica e censimento area PM
Oggetto di conversione
Tipo
Attività Attività Date limite
Punto di
riconsegna B
Da valutare, per la copertura dei parametri non
obbligatori
31 gennaio (*)
Contatori B
Bonifica per calibro maggiore di G4 (calibro, portata di bollo, tipologia tecnica e codice materiale)
31 gennaio (*)
Comune, Classificazione
Comune
B Completamento attributi 31 gennaio (*)
IRI, classificazione
IRI D Definire (2 impianti) 31 gennaio (*)
Gruppo di
riduzione utente BC Bonificare / censire Post-go live Diametro,
Classificazione Diametro
C Censire sul campo (Pistoia) 28 febbraio
Unità immobiliare, Classificazione Unità immobiliare C In corso di valutazione Classificazione IPRM, GRF, GRI, GRU BC
Da valutare fogli excel UOT (informazioni non
obbligatorie).
31 gennaio (*)
Caratteristiche e
Classi B
Valutare il modello
Fiorentina Gas. 31 gennaio (*)
Piani di
manutenzione D
Eventuale definizione (non
obbligatorio). 15 febbraio
Task list B Definizione a partire da
Bonifica e censimento area Codice di Rete
Oggetto di conversione
Tipo
Attività Attività Date limite
Clienti B
Identificare i vari codici ricavo da associare a ciascuna tipologia di cliente (TG Clienti, Cliente
finale, RelCo terze, ecc) e inserirli nell'attributo "codice ricavo". 7 febbraio Informazioni identificative del misuratore B
Su iCis in fase di estrazione andranno tracciati a parte i misuratori con stato "Emesso contratto con
subentro". Andranno bonificati a sistemi avviati, tenendo traccia su file extra sistema di tali situazioni. Le volture post go-live elimineranno le
"posizioni aperte" dei misuratori in "attesa di voltura" che risultano da file.
post go-live
Informazioni relative all’ubicazione del
contatore
C Necessaria attività di censimento Post go-live
Informazioni tecniche relative al singolo
impianto
B Bonifica, per ciascun impianto il valore del PCS
assente nei sistemi legacy. Post go-live
Anagrafica dei punti
REMI D
Definizione manuale dell'associazione Comune, Località, City-Gate, impianti REMI. Da utilizzare
a supporto della fase di estrazione dati.
31 gennaio (*)
Oggetto che lega ciascun REMI Fisico
al REMI Virtuale di afferenza
D
Definizione manuale dell'associazione Comune, Località, City-Gate, impianti REMI. Da utilizzare
a supporto della fase di estrazione dati.
31 gennaio (*)
Anagrafica shipper D Definire su foglio excel. 7 febbraio
Associazione
impianto – shipper D Definire su foglio excel. 7 febbraio
Associazione Relco-Impianto e relativa %
di prelievo da parte della RelCo.
D Definire su foglio excel. 7 febbraio
Comune B Bonificare su foglio excel. Attività già in corso. 31 gennaio (*)
Misuratori C Vettoriamento non gestisce il numero di cifre
(circa 3000 PdR) del segnante. 28 febbraio
Correttori C
Nessuno dei sistemi sorgenti gestisce il codice del correttore (non obbligatorio eventuale
censimento).
Post go-live
LEGENDA:
D- definizione: dato non reperibile né attraverso estrazione (anche parziale) dai sistemi legacy di Toscana Gas, né attraverso censimento sul campo. Il dato deve essere costruito attingendo alle conoscenze specifiche di Toscana Gas, eventualmente sfruttando le definizioni già utilizzate da Fiorentina Gas;
B- bonifica: dato reperibile dai sistemi legacy Toscana Gas o da altri strumenti, informatici o cartacei, la cui consistenza non è corretta al cento per cento. Anche in questo caso l’attività di bonifica, talvolta, può essere fatta partendo dalle definizioni utilizzate da Fiorentina Gas;
C- censimento: dato non reperibile attraverso estrazione dai sistemi legacy Toscana Gas, ma solo da attività di censimento sul campo.
2.1.5.1 Costituzione gruppo Bonifica e Censimento
L’incontro, che è il secondo per l’area Bonifica e Censimento dati, ha come obiettivi:
presentare le varie risorse del gruppo di lavoro di censimento e bonifica dati; definire le attività di Bonifica e Censimento e il loro piano di realizzazione; definire i ruoli e le responsabilità all’interno del gruppo suddetto;
comunicare le modalità di monitoraggio delle attività in carico al gruppo di lavoro.
Nei mesi precedenti (Settembre – Ottobre – Novembre – Dicembre) sono state fatte interviste ai fornitori di sistemi legacy e alle risorse operative di Toscana Gas per avere informazioni sui dati, ovvero quale fosse la fonte da dove prelevarli e più nello specifico il campo sorgente (fase di mapping di dettaglio). In seguito vi è stata la prima milestone, in cui le logiche di conversione sono state comunicate ai fornitori dei sistemi legacy al fine di estrarre i dati dai sistemi legacy Toscana Gas e poter caricare il DBT (Data Base Transitorio, ovvero la struttura informatica che farà da ponte tra sistemi sorgenti –legacy– e sistemi destinazione –ASI–).
Le attività di bonifica e censimento sono svolte in quanto non vi sono sistemi legacy di caricamento per parecchi dati in esame. Ad oggi Toscana Gas è nella fase di Realizzazione e Test.
Questa macroattività, si prevede che sarà conclusa il 20/02/2006, data in cui il Data Base Transitorio sarà caricato con la maggior parte dei dati. I dati subiranno dei refresh (aggiornamenti) periodici. Ad Aprile i dati saranno fermi e consolidati per essere caricati in fase di cut-over finale.
Mapping di dettaglio
Logiche di conversione
Realizzazione e test
Per le attività di bonifica e Censimento vi saranno logiche semplici o meno, ad esempio: il PdR non è un concetto nativo per TG, alcuni dati relativi ad essi non sono presenti a sistema e quindi vi saranno due opzioni possibili:
censimento manuale nel caso di dato presente in campo;
conoscenza (know-how) delle risorse TG o utilizzando semplici regole.
Un oggetto su cui si dovrà decidere di utilizzarli o meno sono i piani di manutenzione. Nel caso in cui si decida di utilizzarli andranno costruiti a partire da zero, e sulla base della istruzione operativa che già prevede vari tipi di controlli: ispezione periodica a livello mensile o annuale, in merito agli Impianti di Riduzione, valvole, impianti elettrici, eccetera.
La prima definizione di ruoli riguarda il responsabile del gruppo di lavoro che sarà il key-user di PM ovvero Manutenzione (interna all’area Servizi alla Clientela e Gestione di Rete –Sc & Gr-), in quanto ha una buona conoscenza degli oggetti in campo sulla rete dal punto di vista cartografico. Altro ruolo assai importante è quello del Program Manager, relativamente a questa macro-attività di progetto, il cui compito sarà di: pianificare i tempi, i costi, le criticità che si svilupperanno in corso d’opera e la risoluzione delle stesse. Si è poi proceduto ad allocare le singole risorse nelle tabelle di attività precedenti (pagina 47 e seguenti), si vedono di seguito alcuni esempi significativi:
Le WBS, oggetti utili al fine dell’allocazione dei costi, saranno definite avendo come caso reale quelle di Fiorentina Gas, e le risorse impegnate saranno due key-user dell’area AFCO (Amministrazione Finanza e Controllo). Come già visto in precedenza le WBS di Toscana Gas saranno di due tipi:
o forfetarie: che hanno al loro interno investimenti economici in merito a servizi presso la clientela (area CS di SAP), uso interno, manutenzione programmata. Questa è un’ allocazione di costi annuali svolta in sede di budget il cui valore è fisso. A fine anno, con il consuntivo, su SAP, se vi è un esubero di risorse, queste potranno essere ri-allocate su altri investimenti, in caso di mancanza di risorse avremo una situazione negativa.
o specifiche: ovvero investimenti che si pianificano in corso d’opera e a cui il budget gli viene costruito in corso d’opera.
Su SAP si caricheranno le WBS e i consuntivi, in base alle stampe in formato PDF fornite dall’applicativo Planet, sistema legacy attualmente utilizzato da un key-user di Sc & Gr. Le due
risorse di AFCO avranno un accesso al programma al fine di effettuare il mapping delle WBS, in primo luogo, in secondo luogo si prenderanno le attività attualmente svolte da TG e si devono far rientrare in quelle implementate sul sistema SAP. Inoltre se vi saranno attività non implementate a sistema TG, ma presenti su SAP queste saranno aggiunte nelle WBS al fine di tutelarsi per il futuro. Per entrare maggiormente nello specifico, esempi di attività di SAP sono:
Costruzione
Modifica o Sostituzione Posa Contatore
Manutenzione non programmata Manutenzione programmata Sostituzione contatore
E’ possibile che due o più attività di quelle elencate nel Data Base dei sistemi legacy siano contenute in una di quelle SAP.
Tipo di Gas \ Devoluzione a rete \ Tabelle di inserimento automatico dei dati amministrativi nelle WBS di rete: la rilevazione di questi dati è affidata alle due risorse di AFCO, già coinvolte per la definizione delle WBS.
La definizione dei Centri di Costo (CdC) è in mano a SOFID, società d’intermediazione finanziaria nell’orbita del gruppo ENI –Ente Nazionale Idrocarburi–, che ha il 28/02/2006 come data limite per l’attuazione della suddetta attività.
Una problematica ricorrente è la presenza di un periodo di buio, teoricamente di durata pari a due o tre settimane nel mese di giugno, in cui sarà tutto “spento”: ovvero non si potrà lavorare né su ASI né sui sistemi legacy. In questo periodo vi sono due ipotesi:
gestione a mano delle pratiche (utilizzando come supporto strumenti Office); gestire le pratiche sui sistemi legacy.
Questa seconda ipotesi pone dei problemi in quanto sarebbe necessario caricare anche le pratiche del periodo di buio, ciò porterebbe ad un allungamento dei tempi e un incremento dei costi sostenuti da TG.
Altro problema è quello degli impianti che in futuro potrebbero essere interconnessi. Esempio pratico: Quarrata e Pistoia sono due comuni distinti ma un piccolo ramo di tubazione di Quarrata sfocia e serve il territorio pistoiese. Gli impianti sono due, in futuro potrebbero essere uno solo che serve entrambi i comuni, ma ciò a livello di SAP è un problema. In SAP per ogni comune si ha una PCM, quindi se si decide di implementare due PCM e in futuro ve ne sarà una sola bisognerà attuare delle modifiche a sistema SAP (operazione che richiede tempo e dispendio di risorse). Allo stato attuale non si può nemmeno generare una sola PCM in quanto l’Autorithy richiede informazioni precise sulla situazione metrica di un comune a livello di tubi in campo.
Ultima problematica rilevata è quella relativa alla presenza di molte pratiche in formato cartaceo, presso l’area Codice di Rete, relative a chiusura per morosità, chiusura normale, viaggio a vuoto dell’addetto per qualunque motivo (esempio: il cliente non è in casa). Sarà quindi necessario da gennaio a giugno 2006 prevedere degli inserimenti manuali (esempio: su foglio excel, al fine di caricare il DBT) per la gestione delle pratiche di morosità e di mancato intervento.
Gestione del programma
• L’attività di Gestione del Programma prevede un incontro settimanale di SAL al quale dovrà partecipare tutto il gruppo di lavoro (GdL) ed eventuali altri soggetti indirettamente coinvolti dalle attività di bonifica e censimento dei dati. Scopo dell’incontro è quello di monitorare lo stato di avanzamento delle attività al fine di anticipare eventuali criticità. • Le scadenze per talune attività di bonifica e censimento sono molto vicine (31/01/2006),
quindi, eventuali criticità che dovessero emergere durante le attività di censimento e bonifica, dovranno essere comunicate tempestivamente al responsabile del gruppo di lavoro e della gestione del programma, anticipando i tempi previsti dal SAL.
2.2 Definizione della struttura organizzativa Toscana Gas
La struttura organizzativa definita sarà utilizzata dalle aree Progetti di investimento (Area PS di SAP), Attività presso la clientela (Area CS di SAP) e per l’area Manutenzione (Area PM di SAP).
Divisione di pianificazione della manutenzione
È stata definita un’unica Divisione di Pianificazione (TDEP) e rappresenta le attività di tutta Toscana Gas.
Area
Divisione di ubicazione e Centri di Lavoro
È stata definita un’unica Divisione di Ubicazione (TG01) al di sotto del quale sono stati definiti quattro Centri di Lavoro Responsabili che raggruppano le diverse competenze territoriali:
o Unità Operative Territoriali Est (TG0101) che si occupa della gestione delle attività presso la clientela e la manutenzione;
o Unità Operative Territoriali Ovest (TG0102) che si occupa della gestione delle attività presso la clientela e la manutenzione;
o Unità Operative Territoriali Nord (TG0103) che si occupa della gestione delle attività presso la clientela e la manutenzione;
o Verifiche che si occupa delle attività di verifica e ricerca dispersioni su tutto il territorio Toscana Gas.
I Centri di Lavoro Responsabili sono utilizzati per attribuire la responsabilità dei lavori (gestiti con gli Ordini di Servizio e con gli Ordini di Manutenzione) alle unità competenti ma non erogano ore. È stato definito un secondo livello di Centri di Lavoro, sottostante le tre Unità Operative Territoriali e l’Unità Verifiche:
o Impiegati o Operai o Responsabili
Tali Centri di Lavoro sono utilizzati per l’imputazione delle ore degli operai, degli impiegati e dei responsabili sugli Ordini di Servizio e di Manutenzione.
È stato definito un Centro di Lavoro Responsabile per le attività di Ingegneria di Rete con un solo Centro di Lavoro di Impiegati sottostante che opera su tutto il territorio di Toscana Gas.
È stato ipotizzato un Centro di Lavoro di staff (IMM) di impiegati per la gestione delle attività di manutenzione degli immobili civili che opera su tutto il territorio di Toscana Gas.
Tariffe dei Centri di Lavoro
Ogni Centro di Lavoro è collegato ad un Centro di Costo ed è utilizzato per scaricare i costi del personale dal centro di costo agli Ordini di Servizio e di Manutenzione mediante le tariffe.
È stato deciso di valorizzare le tariffe secondo il criterio del costo standard. Saranno quindi definite tre tariffe, una per gli impiegati, una per gli operai ed una per i responsabili, non differenziate in base al criterio territoriale.
2.3 Generazione WBS
L’attività è stata utile al fine di illustrare:
o la struttura e la codifica delle WBS utilizzate per la contabilizzazione dei lavori di rete (WBS strutturate forfetarie e specifiche);
o il modello di contabilizzazione dei lavori di Toscana Gas (come avviene in SAP l’imputazione delle WBS negli ordini di servizio e negli ordini di manutenzione);
o il flusso per l’approvazione in budget delle WBS;
o la struttura e la codifica delle WBS piatte per la contabilizzazione delle attività non di rete.
E’ stato condiviso che sarà necessario creare le seguenti tipologie di WBS:
o ITG_ITF - Progetti d’investimento forfetari. Si tratta di progetti d’investimento forfetari e non richiesti dalla clientela che coinvolgono più di un comune e che scaricheranno i costi a cespite ovvero a stato patrimoniale.
Ordine di Servizio: è un oggetto tecnico utilizzato in SAP al fine di pianificare e consuntivare: • Costi (materiali, prestazioni, risorse interne).
• Obiettivi.
• Altri dati tecnici (tipo mensola, potenzialità, stato, eccetera). • È legato ad un’imputazione contabile (è l’elemento di una WBS).
o ITG_FCG - Progetti presso la clientela di gestione. Si tratta di progetti forfetari (cioè che coinvolgono più di un comune) per le attività presso la clientela. Tali WBS saranno utilizzate per contabilizzare quei lavori presso la clientela che scaricheranno i costi a conto economico (es. letture, verifiche, morosità…).
o ITG_FCI - Progetti presso la clientela di investimento. Si tratta di progetti forfetari (cioè che coinvolgono più di un comune) di costruzione reti e di impianti di derivazione utenza che scaricheranno i costi a cespite.
o ITG_MT - Manutenzione ordinaria. Si tratta di progetti utilizzati per la contabilizzazione delle attività di manutenzione.
È emerso, durante l’incontro, che non esiste un applicativo da cui estrarre automaticamente i codici identificativi delle WBS, pertanto sarà necessario procedere alla creazione di tali codici in maniera manuale.
Le prossime attività consisteranno nell’:
o illustrazione dei tracciati di caricamento delle WBS sul DBT;
o analisi del modello di funzionamento e delle modalità di generazione dei codici identificativi delle WBS piatte con il coinvolgimento del fornitore SOFID, responsabile della parte amministrativa.
2.4 SAL del Gruppo di Lavoro EtL
2.4.1 Logiche di Conversione (1° Step)
L’attività in esame ha avuto molteplici obiettivi:
– Formalizzazione della chiusura per la fase di definizione delle logiche di conversione per tutti gli oggetti “Area Core” necessari al primo caricamento dei sistemi ESI –Estensione Sistemi Informativi– di Toscana Gas;
– Stato avanzamento delle attività di sviluppo dei programmi di estrazione dai sistemi legacy e di caricamento del Data Base Transitorio;
– Punti aperti e Criticità
– Definizione dei prossimi passi;
Come da programma è stata conclusa la fase di definizione delle logiche di conversione per tutti gli oggetti che necessitano di essere caricati sui sistemi ASI –Attuazione Sistemi Informativi– a partire dai sistemi legacy. Inoltre sono state avviate sia le attività di realizzazione dei programmi di estrazione e caricamento dati che le attività di bonfica manuale dei dati stessi.
Si riprende ora il Diagramma con tempi e scadenze già visto nei paragrafi precedenti:
La fase di caricamento del Data Base Transitorio deve essere completata entro il 20 Febbraio 2006. L’attività di definizione delle logiche di conversione è stata suddivisa in due sotto attività al fine di anticipare l’implementazione degli estrattori e dei caricatori e le bonifiche dei dati ad essa strettamente legate.
Settembre Ottobre Novembre Dicembre Gennaio Febbraio
Mapping di dettaglio Logiche di conversione Realizzazione e test Fase di Conversione Load DBT 20/02 31/01 DBT stabile 16/01
Logiche di conversione
Oggetti estraibili dai
sistemi legacy Toscana
Gas
Oggetti non estraibili
dai sistemi legacy
Toscana Gas
Supporto alle attività di censimento e bonifica dei dati
• Avviate attività di scrittura degli applicativi di estrazione dati dai sistemi legacy
• Avviate attività di scrittura degli applicativi di caricamento dati nel Data Base Transitorio
• Avviate le attività di censimento e bonifica manuale
Presentazione documentazione tecnica
•
WBS•
Cicli•
Listino prezzi per la preventivazione lavori su richiesta del cliente•
Equipment•
Convertitori•
Cicli di lavoro•
Classi e Caratteristiche•
Piani di manutenzione•
Punti di misura•
Ordini di manutenzione (OdM)•
Blocco materiali•
Caratteristiche misuratori•
Rottami (probabilmente non saranno censiti e caricati su SAP)•
Anagrafica fornitori•
Inforecord•
Contratti di acquisto•
Listino e Attività PS CS SD PM MM•
Attività soggetta a definizione manuale in carico a due risorse AFCO•
Attività soggetta a definizione manuale in carico al personale delle UOT•
L’attività di definizione degli equipment può essere fatta in modo automatico (necessario per stabilire quali equipment definire)•
Cicli di lavoro, classi, caratteristiche e piani di manutenzione vanno definiti manualmente e sono già stati assegnati al gruppo di censimento e bonifica•
Gli OdM non saranno caricati a sistema•
Tutti gli oggetti in elenco sono oggetto di attività di censimento e bonifica già assegnate al gruppo di lavoro.Legenda:
Moduli di SAP:
PS: Project Systems CS: Customer Service SD: Sales and Distribution PM: Plant Manteinance MM: Material Management
WBS: Work Breakdown Structure
AFCO: Amministrazione Finanza e Controllo CodRe/INV: Codici di Rete e Investimenti UOT: Unità Operative Territoriali
Avanzamento attività di censimento e bonifica dati
• E’ stato definito il gruppo di lavoro composto interamente da personale Toscana Gas che prevede:
– Key-user di PM svolge la funzione di Responsabile del Gruppo di Lavoro
– Una risorsa di PERORG –Organizzazione del Personale– sarà il Program Manager per il gruppo di lavoro in esame
– Nove dipendenti suddivisi sulle varie aree di progetto
• E’ stato fatto un primo incontro conoscitivo nel quale sono state assegnate le attività in ambito a singoli partecipanti
• Alcune attività di bonifica non sono ancora state avviate poichè legate:
alle attività di SOFID, programmate a partire dalla settimana del 23 gennaio; alla definizione della struttura organizzativa dei magazzini;
• E’ stato decisa un’attività di monitoraggio delle attività con cadenza settimanale direttamente con le singole persone responsabili delle attività al fine di restringere i tempi. Inizialmente si era ipotizzato di fare riunioni settimanali con tutte i membri del GdL, ma appariva un eccessivo dispendio di tempo per le singole risorse, che venivano coinvolte solo per una parte delle tematiche affrontate nella riunione.
Prime evidenze da attività di estrazione dati
• Dalla prime attività di estrazione dati dai sistemi legacy sono emerse le prime attività di bonifica manuale:
– nel sistema Allacci, per i PdR costruiti ma non ancora attivi e i PdR per i quali è stata fatta un’offerta commerciale non ancora eseguita, non sono riportati:
l’impianto ai quali sono collegati (ricavabili per la maggior parte dei Comuni; solo per 2 Comuni di Pisa è necessaria attività di bonifica manuale poichè serviti da più di un impianto)
la località nei quali sono costruiti o è stato effettuato il sopralluogo (circa 5000 PdR). L’indicazione della località è utile al fine dell’applicativo Lodestar che fa fatturazione alle RelCo, una diversa località corrisponde a una diversa tariffa.
Attività di scrittura dei programmi di estrazione legacy e caricamento DBT
– Tutti i fornitori hanno dichiarato di essere in linea sul piano che prevede la chiusura delle attività di scrittura dei programmi entro la fine di gennaio;
– E’ stato rinforzato il gruppo VerticalTech per la creazione dei programmi di caricamento sul DB transitorio.
– Sono state messe in primo piano le attività di Futura (applicativo Allacci) per renderle compatibili con il piano di caricamento del DB transitorio.
Avanzamento attività di sviluppo al 13 gennaio 2006
• VerticalTech:
- Dichiarati completati gli script di creazione del DB Transitorio
- E’ stato creato un team di 4 risorse per la scrittura dei programmi di caricamento
• Futura:
- Dichiarato completato il programma di estrazione dei PdR • Sister (SIT):
- Dichiarati ultimati tutti i programmi di estrazione dati dal sistema legacy SIA - In corso le tarature dei programmi da feedback su estrazione dati
- In corso l’attività di redazione delle specifiche tecniche
• BookInformatica:
- Dichiarati completati i programmi di estrazione dati dal sistema Vettoriamento - In corso le tarature dei programmi da feedback su estrazione dati
• Neta:
- Dichiarata completata la scrittura di quasi tutti i programmi di estrazione - In corso le tarature dei programmi da feedback su estrazione dati
• Publiservizi:
- Dichiarati completati i programmi di estrazione dati - Non sono state fornite estrazioni anche parziali dei dati
Punti aperti e Criticità
PUNTI APERTI:
Definizione WBS piatte (con coinvolgimento di SOFID)
• Per le pratiche dei costruttori, si distingue il caso in cui il costruttore richiede il lavoro nell’ambito della sua attività oppure per esigenze personali (queste informazioni sono utili in merito alla Delibera 47/00 che distingue fra richiedente e cliente finale);
• Rilevata necessità di agevolare l’operativa dell’utente in fase di creazione dell’offerta commerciale (preventivo) relativamente ai contributi su vie e località interessate;
CRITICITÀ:
• Non è ancora stata definita la struttura dei magazzini
Prossimi passi
• Completamento definizione della struttura del Data Base Transitorio
• Definizione delle query di quadratura, utili al fine di vedere se il dato è corretto. Verrà fatta una verifica di congruenza tra lo stato tecnico e commerciale, ovvero si fa un controllo sulla semantica del dato soggetto a estrazione.
• Supporto ai fornitori:
– aspetti funzionali legati alle logiche di estrazione dei dati dai sistemi legacy e caricamento sul Data Base Transitorio
– aspetti tecnici legati alle prime estrazioni dei dati dai sistemi legacy
• Supporto alla fase di bonifica censimento e definizione dei dati non presenti o parzialmente presenti nei sistemi legacy di Toscana Gas
• Definizione della modalità di gestione delle pratiche aperte, ovvero quei lavori (presso la clientela o per esigenze interne Toscana Gas) che iniziano prima dell’introduzione di ASI e continuano la loro vita sul nuovo sistema.
• Definizione della modalità di migrazione del sistema di accertamento documentale in merito a:
– Pratiche aperte – Storico
Pianificazione delle attività:
Area PS
Deve essere avviata con SOFID l’attività di definizione delle “WBS piatte” (WBS con un unico livello).
Devono essere avviate con SOFID le attività di definizione dei Centri di costo e dei Centri di profitto preliminari per le attività di bonifica con data limite il 28 febbraio.
Area CS
Sono state riassegnate al personale delle UOT le attività di definizione dei Cicli di Lavoro (in precedenza le risorse allocate per questa attività erano miste: CodRe\INV e UOT);
Alcune attività di bonifica, con data limite 31 gennaio, sono preliminari alla definizione della struttura organizzativa dei magazzini;
Area PM
E’ necessario decidere se definire Piani di Manutenzione e se censire le unità immobiliari; Devono ancora iniziare le attività di bonifica manuale relative alla definizione delle Classi,
Caratteristiche e Cicli di lavoro relativi ai piani di manutenzione.
Dalle prime estrazioni dati sono emerse due nuove attività di bonifica assegnate all’area Manutenzione Impianti
Codice di Rete
Necessario reindirizzare l’attività di identificazione dei Gestori calore
Approvvigionamenti e Logistica
Ci sono quattro attività con data limite metà febbraio in attesa della definizione della struttura dei magazzini, altre quattro attività in attesa delle estrazioni dati dai sistemi Mosaico e Sigla++
Area Vendite
