1
Dipartimento dell’Energia, dei Sistemi, del Territorio e delle Costruzioni
Tesi di Laurea Magistrale in Ingegneria Gestionale
Analisi ed Implementazione di una Soluzione SAP per la Gestione
Automatica dell’Origine Preferenziale della Merce
Relatore Candidato
Prof. Ing. Riccardo Dulmin Lorenzo Iacoponi Dipartimento dell’Energia, dei Sistemi,
del Territorio e delle Costruzioni Tutor aziendale
Dott.ssa Claudia Lena
KPMG Advisory SpA
Appello di Laurea del 20 Febbraio 2019 Anno accademico 2018/2019
4 SOMMARIO
1 INTRODUZIONE 8
1.1 Presentazione del problema 8
1.2 Contenuto della relazione 10
2 ORIGINE PREFERENZIALE DELLE MERCI 11
2.1 Regole doganali generali 11
2.1.1. Origine non preferenziale (Made In) 11
2.1.2. Origine preferenziale 13
2.2 Documenti relativi alla gestione della preferenzialità 14
2.2.1. Certificato d’origine 14
2.2.2. Certificato di Circolazione EUR.1 14
2.2.3. Certificato di Circolazione EUR.2 14
2.2.4. Certificato di Circolazione A.TR. 14
2.2.5. FORM A 14
2.3 Calcolo del codice doganale e regole doganali specifiche 15
3 GESTIONE DEL PROGETTO 17
3.1 Request for proposal 18
3.2 Analisi as is 19
3.3 Analisi to be 19
3.4 Business Blueprint 20
3.5 Sviluppo i: analisi tecniche 20
3.6 Sviluppo ii: configurazione e customizing 20
3.7 Test 22 3.8 Training 22 3.9 Cutover 23 3.10 Go Live 23 3.11 Hypercare 24 3.12 Manutenzione 24
4 METODOLOGIE DI GESTIONE DI PROGETTO 25
4.1. Metodologia Waterfall 25
4.2. Metodologia Agile 27
4.3. Metodologia Scrum 28
5
5 ANALISI E DESCRIZIONE DEL PROCESSO 34
5.1 Introduzione 34
5.2 Processo AS IS 34
5.3 Processo TO BE 37
5.3.1. Gestione anagrafiche materiale 39
5.3.2. Gestione delle vendor declaration 40
5.3.3. Gestione assiemi 41
5.3.4. Processo di vendita 42
6 DISEGNO FUNZIONALE SAP 44
6.1. Customizing standard SAP 44
6.1.1. Creazione delle zone preferenziali e attribuzione dei paesi 45 6.1.2. Definizione e attribuzione delle regole di calcolo preferenziale 47
6.2. Programmi e transazioni custom per il processo 50
6.2.1. Richiesta della vendor declaration 50
6.2.2. Tabelle di supporto per campi dinamici in fase di richiesta 53 6.3. Caricamento a sistema della dichiarazione del fornitore 56
6.4. Archiviazione vendor declaration 59
6.5. Calcolo preferenziale 60
6.5.1. Tabelle per la gestione degli assiemi 66
6.5.2. Tabella per l’inserimento delle soglie aggiuntive 68
6.6. Output in fattura 69
7 REPORTISTICA DI SUPPORTO 72
7.1. Monitor status vendor declaration 72
7.2. Monitor preferenzialità codici veicolo 74
7.3. Report status BOM 75
8 IMPLEMENTAZIONE TECNICA SAP 78
8.1. Functional Design Documents 78
8.1.1. Caricamento della vendor declaration 78
8.1.2. Calcolo preferenziale 80
8.1.3. Gestione assiemi 81
8.1.4. Report preferenzialità dei veicoli 82
8.1.5. Determinazione testo stampa in fattura 83
6
8.3. Monitoraggio dell’invio automatico di e-mail 87
8.4. Smartforms 89
8.5. Query 90
8.6. Migrazione dei dati 93
9 CAMPI E TABELLE UTILIZZATI 106
9.1. Campi tecnici e descrizione 106
9.2. Tabelle utilizzate e descrizione 107
Bibliografia e riferimenti 108
8 1 INTRODUZIONE
La seguente relazione è frutto di un tirocinio della durata di sei mesi presso la sede KPMG Advisory SpA di Bologna. In questo periodo è stata analizzata ed implementata una soluzione con lo scopo di gestire automaticamente il processo di attribuzione dell’origine preferenziale ai prodotti dell’azienda cliente.
L’attribuzione dell’origine preferenziale ai prodotti coinvolge l’ambito logistico e l’ambito business: il processo di attribuzione implica la sensibilizzazione e la partecipazione dei fornitori su questo tema, la gestione integrata delle informazioni sulle distinte base, la collocazione geografica degli stabilimenti di produzione e dei clienti e la valutazione economica di diverse soluzioni.
1.1 Presentazione del problema
L’azienda cliente ha avuto la necessità di automatizzare il processo di gestione dell’origine preferenziale, avere a disposizione a sistema le informazioni relative ai materiali utilizzati in produzione ed in assemblaggio e automatizzare il processo di gestione della preferenzialità. La presenza a sistema di queste informazioni, dopo l’implementazione della soluzione, ha reso possibile effettuare automaticamente il calcolo della preferenzialità dei prodotti finiti,
classificando il prodotto come preferenziale o non preferenziale da un paese di origine verso un paese di esportazione.
L’esportazione tra paesi è regolata da accordi commerciali bilaterali o multilaterali: gli accordi commerciali fissano delle regole che, se rispettate, consentono di ottenere trattamenti preferenziali come, ad esempio, una riduzione o una totale esenzione al pagamento dei dazi doganali.
Questo processo coinvolge diversi reparti aziendali ed è stato finora gestito manualmente da più utenti interni che si sono interfacciati con l’esterno per l’ottenimento delle informazioni
necessarie e si sono occupati di attribuire, dopo aver verificato le regole vigenti ed averle
confrontate con i risultati ottenuti sui prodotti finiti, lo stato ‘preferenziale’ o ‘non preferenziale’ al prodotto finito.
Le funzioni aziendali coinvolte nel processo, in ottica di gestione dell’origine preferenziale, prima del progetto, sono:
Reparto Business: si occupa di interfacciarsi, per quanto riguarda il tema ‘Origine preferenziale’, con i fornitori e di effettuare manualmente il ‘Calcolo preferenziale’ sui prodotti finiti per attribuire lo stato ‘Preferenziale’ o ‘Non preferenziale’. Il Reparto Business ha il compito di mantenersi costantemente aggiornato sulle vigenti regole doganali e sullo sviluppo degli accordi commerciali tra i paesi
Reparto Acquisti: si occupa di fornire al Reparto Business le liste dei materiali
approvvigionati da ciascun fornitore e mantenere costantemente aggiornate le anagrafiche dei materiali sul sistema gestionale
9
Controllo di gestione: si occupa di manutenere e fornire le distinte base dei prodotti al responsabile dell’attribuzione della preferenzialità ai prodotti
Questo processo, cosi come gestito prima del progetto, ha implicato un notevole dispendio in termini di:
Risorse interne impiegate
Interfacce e comunicazioni interne ed esterne, a causa del frequente coinvolgimento di più reparti aziendali
Tempi di ottenimento delle informazioni dall’esterno, a causa dei ritardi e degli errori dei documenti ricevuti dai fornitori
Tempi di elaborazione delle informazioni interne, a causa della lunga procedura manuale e della necessità di informazioni provenienti da altri reparti
Gestione ed archiviazione delle informazioni e dei documenti
A seguito del progetto, si è aggiunto ai sopracitati il Reparto IT con i seguenti compiti: Guidare ed assistere l’implementazione del processo sul sistema gestionale
Assicurare la presenza a sistema delle informazioni rilevanti per la gestione del processo e comunicare agli utenti interessati gli eventuali errori o mancanze
Mantenere la funzionalità del sistema
Garantire la totale adozione dei passaggi effettuati sul sistema informativo Gli obiettivi che il progetto si pone sono quelli di:
Rendere più efficiente ed efficace l’intero processo Automatizzare quante più fasi possibili
Avere informazioni archiviate e disponibili a sistema Ridurre i tempi di elaborazione e liberare risorse
10 1.2 Contenuto della relazione
La presente relazione ha lo scopo principale di descrivere il lavoro svolto dal team e
individualmente durante lo stage e di illustrare le azioni intraprese per implementare la soluzione sul sistema gestionale aziendale, sia dal punto di vista di gestione progettuale che dal punto di vista funzionale e tecnico.
Durante questo periodo, ho avuto la possibilità di entrare in contatto con la realtà aziendale e di partecipare alla maggior parte delle fasi del progetto. Nello specifico, come membro più junior del team di lavoro, i compiti assegnati sono stati:
Partecipare alle riunioni con il cliente
Redigere i documenti riportanti i risultati delle riunioni
Customizzare parte del processo sul sistema gestionale aziendale Supportare le figure con più seniority nelle fasi di customizzazione
Testare le soluzioni adottate e segnalare tempestivamente eventuali errori riscontrati o punti di miglioramento
Effettuare analisi a partire dalle informazioni presenti a sistema
Redigere documenti di tipo tecnico – funzionale necessari all’implementazione del processo
Redigere documenti di preparazione alla fase di User Acceptance Test
Supportare le figure con più seniority durante la fase di cutover e go live del progetto Effettuare il training degli utenti interessati
Apprendere metodologie e procedure di lavoro
Sviluppare le soft skills necessarie in ambito lavorativo
In secondo luogo, lo scopo è far percepire l’importanza di una gestione informativa sul sistema gestionale aziendale e di mostrare un esempio di progetto di implementazione IT.
La relazione si pone quindi l’obiettivo di illustrare:
La gestione della preferenzialità: in questa parte viene effettuata un’analisi del tema della preferenzialità, delle leggi e delle relative chiavi di lettura
Il progetto e le fasi che lo compongono: in questa parte viene esposta la gestione del progetto, le fasi seguite ed il contenuto sviluppato in ognuna di esse
Il processo di gestione della preferenzialità: in questa parte vengono riportati i processi as is e to be
La soluzione funzionale implementata: in questa parte vengono illustrate le soluzioni funzionali adottate per la gestione automatica del processo
Le soluzione tecniche adottate: in questa parte vengono riportati degli sviluppi tecnici implementati per la creazione delle soluzioni funzionali
Gli strumenti utilizzati per realizzare le soluzioni: in questa parte vengono illustrati i principali strumenti che hanno consentito la realizzazione delle soluzioni funzionali
11 2 ORIGINE PREFERENZIALE DELLE MERCI
In questo capitolo sono illustrati i concetti relativi alla preferenzialità ed è fornito un quadro generale della legislazione su questo tema.
Per merce si intendono tutti i beni che vengono acquistati, prodotti e venduti dall'azienda. Possono essere quindi prodotti finiti, materiali per assemblaggio, ma anche oggetti che non vengono lavorati.
L’origine preferenziale è uno stato ottenuto dal prodotto grazie al quale può godere del diritto a trattamenti tariffari preferenziali.
Questi trattamenti preferenziali si sostanziano in una riduzione o in una totale esenzione del dazio, secondo le regole stabilite dalle autorità doganali e dagli accordi reciproci tra i paesi coinvolti nello scambio commerciale.
2.1 Regole doganali generali
Il tema dell’origine preferenziale vede coinvolti due concetti distinti. Questa distinzione è dovuta alla necessità di identificare:
L’origine in senso stretto del materiale, intesa come provenienza del prodotto
La possibile applicazione di trattamenti tariffari di favore in caso di rispetto di determinate regole imposte negli accordi commerciali tra i paesi
2.1.1. Origine non preferenziale (Made In)
Il concetto di ‘Origine non preferenziale delle merci’ serve a stabilire il paese in cui il bene è stato prodotto.
Per origine non preferenziale si intende il luogo di produzione del bene o il luogo dove lo stesso ha subito l’ultima lavorazione o sostanziale trasformazione.
A tal proposito, sono di seguito illustrati i criteri secondo i quali viene valutata l’origine di un bene e le lavorazioni che ne consentono l’ottenimento.
Criterio 1: sono sempre originari di un Paese i prodotti interamente ottenuti in tale Paese (Made In). Per interamente ottenuti si intendono:
a) I prodotti minerali estratti in tale paese o territorio b) I prodotti del regno vegetale ivi raccolti
c) Gli animali vivi, ivi nati e allevati
d) I prodotti provenienti da animali vivi ivi allevati e) I prodotti della caccia e della pesca ivi praticate
f) I prodotti della pesca marittima e altri prodotti estratti dal mare fuori delle acque territoriali di un paese da navi registrate nel paese o territorio interessato e battenti bandiera di tale paese o territorio
12
g) Le merci ottenute o prodotte a bordo di navi-officina utilizzando prodotti di cui alla lettera f), originari di tale paese o territorio, sempreché tali navi-officina siano immatricolate in detto paese e ne battano la bandiera
h) I prodotti estratti dal suolo o dal sottosuolo marino situato al di fuori delle acque
territoriali, sempreché tale paese o territorio eserciti diritti esclusivi per lo sfruttamento di tale suolo o sottosuolo
i) I cascami e gli avanzi risultanti da operazioni manifatturiere e gli articoli fuori uso, sempreché siano stati ivi raccolti e possano servire unicamente al recupero di materie prime
j) Le merci ivi ottenute esclusivamente a partire dai prodotti di cui alle lettere da a) a i)
Criterio 2: i prodotti sono originari di un Paese se in questi è avvenuta l’ultima lavorazione o trasformazione sostanziale
Il criterio è applicabile alle merci lavorate più Paesi o prodotte con l’impiego di componenti non originari nell’UE. Secondo questo criterio, un prodotto è originario di un paese quando in questo è avvenuta l’ultima lavorazione o trasformazione sostanziale, che abbia cioè modificato il prodotto. Vengono classificate come lavorazioni e trasformazioni sostanziali quelle per cui il prodotto, alla fine del processo, è soggetto ad un cambio di voce doganale (prime 4 cifre della nomenclatura doganale).
Nello specifico le regole possono essere:
Primarie: sono associate alla voce doganale (prime 4 cifre della nomenclatura) Residuali: sono riferite ad ogni capitolo (prime 2 cifre della nomenclatura) e fanno
riferimento all’origine della maggior parte dei materiali calcolata, secondo i casi, in base al peso o al valore
Vengono identificate le lavorazioni non sufficienti all’ottenimento del cambio di voce doganale: a) Le manipolazioni destinate ad assicurare la conservazione in buone condizioni dei prodotti
durante il loro trasporto e magazzinaggio (ventilazione, spanditura, essiccazione, rimozione di parti avariate e operazioni analoghe) o operazioni volte a facilitare la spedizione o il trasporto
b) Le semplici operazioni di spolveratura, vagliatura o cernita, selezione, classificazione, assortimento, lavatura, riduzione in pezzi
c) I cambiamenti d’imballaggio e le divisioni e riunioni di partite, le semplici operazioni di riempimento di bottiglie, lattine, boccette, borse, casse o scatole, o di fissaggio a supporti di cartone o tavolette e ogni altra semplice operazione di condizionamento
d) La presentazione delle merci in serie o insiemi o la loro messa in vendita
e) L’apposizione sui prodotti e sul loro imballaggio di marchi, etichette o altri segni distintivi f) La semplice riunione di parti di prodotti allo scopo di formare un prodotto completo
13
g) Lo smontaggio o il cambiamento di uso
h) Il cumulo di due o più operazioni tra quelle di cui alle lettere da a) a g)
2.1.2. Origine preferenziale
Il concetto di ‘Origine preferenziale’ serve a stabilire se un prodotto può godere di trattamenti tariffari doganali di favore. Nello specifico è necessario verificare:
La presenza di accordi commerciali tra l’Unione Europea e il Paese in cui i beni vengono venduti
La conformità del prodotto ai requisiti fissati nelle regole dello specifico accordo commerciale
Le regole doganali sono frutto di accordi commerciali bilaterali o multilaterali tra i paesi e definiscono i requisiti che un prodotto deve rispettare per ottenere la certificazione di
preferenzialità; queste sono strutturate in modo da consentire l’ottenimento della certificazione solo ai prodotti ottenuti da componenti a loro volta certificati e/o prodotti effettivamente fabbricati all’interno dei paesi aderenti all’accordo di scambio. Le regole fissate negli accordi possono essere di vari tipi:
Cambio della voce doganale
La lavorazione che viene svolta all’interno dell’UE deve causare un cambio della voce doganale del prodotto in output rispetto al prodotto in input
Incidenza dei componenti provenienti da paesi fuori dall’UE impiegati
Viene valutata l’incidenza, in termini di valore, del costo di acquisto dei componenti extra UE e sul prezzo di vendita franco fabbrica del prodotto finito esportato. Per ciascun prodotto è individuata una percentuale massima dell’incidenza del costo di acquisto delle materie prime.
Doppia condizione
In questo caso è previsto il rispetto contemporaneo delle regole precedenti cambio della nomenclatura combinata e criterio dell’incidenza delle materie prime
Regole alternative
È possibile utilizzare, ove concesso, particolari regole alternative della stessa natura delle precedenti ma con differenti percentuali e requisiti
Alla luce di quanto esposto, si può quindi affermare che:
Un prodotto, per poter essere considerato originario ed ottenere lo stato di ‘preferenziale’ da un paese di partenza verso un paese di destinazione, deve aver subito dei processi di lavorazione sufficienti nel paese di partenza o rispettare le regole fissate negli accordi.
14 2.2 Documenti relativi alla gestione della preferenzialità
In questo paragrafo vengono illustrati i principali documenti utilizzati nell’ambito della gestione della preferenzialità.
I certificati accompagnano i prodotti e consentono, se ottenuti, l’esenzione o la riduzione dei dazi all’importazione.
2.2.1. Certificato d’origine
Il certificato di origine indica l’origine non preferenziale dei beni destinati all’esportazione nei paesi terzi. Per poter emettere questo documento è necessario conoscere l’origine (o le origini) dei prodotti destinati ad essere esportati.
2.2.2. Certificato di Circolazione EUR.1
L’EUR.1 è il certificato di origine utilizzato per certificare l’origine preferenziale e consente l’eventuale abbattimento dei dazi all’importazione negli scambi con paesi legati all’Unione Europea da accordi tariffari. È rilasciato dalla Dogana su domanda dell’esportatore.
2.2.3. Certificato di Circolazione EUR.2
Il formulario EUR.2 ha lo scopo di documentare il carattere originario delle merci. È usato solo per le merci dirette a Cipro, Malta, Egitto e Siria.
2.2.4. Certificato di Circolazione A.TR.
ATR è un certificato previsto dall’accordo tra Unione Europea e Turchia per attestare che la merce descritta nel modulo è in libera circolazione.
2.2.5. FORM A
Il FORM A è un certificato di origine usato per le importazioni verso l’Unione Europea dai Paesi in via di Sviluppo tramite il quale questi paesi attestano l’origine e produzione autoctona della merce.
15
2.3 Calcolo del codice doganale e regole doganali specifiche
La nomenclatura dei prodotti e le regole doganali applicabili sono accessibili dai siti istituzionali. Ciò che viene utilizzato dai soggetti coinvolti è la TARIC (Tariffa Integrata Comunitaria) nazionale, tramite la quale è possibile ricavare informazioni sugli accordi tra i paesi, le regole applicabili, la raccolta delle disposizioni, degli obblighi e delle fiscalità a cui sono soggetti i prodotti
all'introduzione sul territorio doganale.
Si riporta di seguito un esempio di codice doganale caratterizzante un veicolo:
Sezione XVII – Materiale da trasporto
87 – Vetture automobili, trattori, velocipedi, motocicli ed altri veicoli terrestri, loro parti ed
accessori
01 – Trattori
9510 00 – potenza superiore a 130 kW
Il codice doganale del prodotto specifico risulta dunque:
8701 9510 00
Trattori agricoli e trattori forestali con potenza superiore ai 130 kW, a ruote
Nel caso dell’esempio, sono presenti specifiche regole da rispettare al fine di ottenere la
certificazione di preferenzialità del prodotto in fase di esportazione verso un determinato paese. Le regole per il codice doganale in questione sono le seguenti:
VOCE DOGANALE REGOLA GENERALE PAESE DI
DESTINAZIONE
8701
Il valore cif (Cost, Insurance and Freight) dei materiali di origine non preferenziale non supera il 60% del costo totale dei materiali utilizzati nella produzione delle merci Il valore aggiunto derivante dal
processo di produzione rappresenta almeno il 35% del costo franco fabbrica delle merci
Fabbricazione a partire da materiali classificati in una voce diversa da quella del prodotto, a condizione che il valore aggiunto sia almeno pari al 35% del
COMESA (Es. Egitto, Eritrea, Etiopia, Gibuti)
16
costo franco fabbrica del prodotto finito
8701
La fabbricazione in cui il valore di tutti i materiali utilizzati non eccede il 40% del prezzo franco fabbrica del prodotto
EU
8701
Il valore cif dei materiali di origine non preferenziale non supera il 60% del costo totale dei materiali utilizzati nella produzione delle merci
Il valore aggiunto derivante dal processo di produzione rappresenta almeno il 35% del costo franco fabbrica delle merci
EAC (Russia)
8701
La fabbricazione in cui il valore di tutti i materiali non preferenziali utilizzati non ecceda il 60% del prezzo franco fabbrica del prodotto
SADC (Es. Angola Botswana Lesotho
Madagascar)
Molto spesso queste regole possono avere anche delle regole alternative. Le regole alternative sono indicate nei documenti ufficiali (Convenzioni Regionali) che regolano gli accordi tra i paesi. Per ottenere la certificazione di ‘Prodotto preferenziale’ le regole devono essere cosi applicate:
Rispetto della regola principale, spesso a sua volta costituita da varie condizioni in AND tra loro
Rispetto, nel caso di esito negativo per la regola generale, dell’eventuale regola alternativa L'azienda esportatrice può garantire un trattamento doganale preferenziale (esenzione o riduzione dei dazi) al momento dell'importazione nel paese destinatario delle merci nei seguenti modi:
Presentando un certificato di origine preferenziale
Apponendo la dichiarazione di origine preferenziale in fattura In relazione all’importo fatturato, la dichiarazione può essere fatta:
Liberamente, per spedizioni di importo inferiore a 6.000 euro. In questo caso è possibile apporre una dichiarazione in fattura evidenziando i prodotti preferenziali
17 3 GESTIONE DEL PROGETTO
In questo capitolo vengono illustrate le fasi seguite per gestire il progetto.
L’azienda cliente, in questo caso, identifica un’area di intervento sulla quale poter investire. La decisione di svolgere il progetto di gestione automatica dell’origine preferenziale è presa dallo Sponsor interno all’azienda cliente del progetto.
Il team lavoro è così identificato:
La Sponsorship di progetto è formata da membri di elevata seniority di entrambe le organizzazioni. Rientrano in questo gruppo i responsabili di funzione (in questo caso IT e logistica) e la figura responsabile del progetto lato azienda fornitrice.
Una volta identificate le aree di intervento, vengono individuati dei soggetti che vanno successivamente a dirigere e formare il team di lavoro:
Project management IT: comprende i manager di entrambe le organizzazioni con competenze tecniche IT
Project management Business: comprende i manager di entrambe le organizzazioni con competenze in ambito legislativo ed in ambito business
Il Project Manager di ciascuna organizzazione nomina i rispettivi membri del team di lavoro: - IT: consulenti e programmatori
18
- Logistica: utente che segue il processo logistica, dall’approvvigionamento alla vendita, dal punto di vista dell’origine preferenziale. Questo aspetto coinvolge anche temi di tipo business, seguiti dallo stesso responsabile
- Servizi doganali: esperto in materia di legislazione di commercio estero
Nel caso specifico, le esigenze di business sono rilevate autonomamente dal cliente; il cliente emette una Request for Proposal in base alla quale riceve delle offerte da parte di diverse società in grado di sviluppare le soluzioni adatte alle esigenze.
3.1 Request for proposal
Il progetto inizia con la Request for Proposal da parte del cliente.
In questo documento il cliente descrive lo scopo del progetto. Nel caso specifico, il cliente richiede di implementare sul sistema informativo aziendale il processo di gestione dell’origine
preferenziale, gestito manualmente extra sistema.
In questo documento il cliente identifica i principali obiettivi che l’azienda fornitrice deve
raggiungere secondo le esigenze di business; questi obiettivi sono di tipo funzionale e riguardano ciò che il cliente si aspetta di ottenere alla conclusione del progetto, nel caso specifico:
Impostare le aree di preferenza di origine sul sistema
Sviluppare la nuova stampa per la dichiarazione del fornitore
Sviluppare una soluzione automatica per lo scambio di dati con il fornitore al fine di garantire la dichiarazione di preferenzialità a sistema di tutti i codici approvvigionati Sviluppare una soluzione semiautomatica per il caricamento massivo della dichiarazione
del fornitore
Sviluppare un calcolo specifico per "Roll - up componente"
Caricare a sistema la data di scadenza della dichiarazione del fornitore e gestire il salvataggio automatico
Nel documento, il cliente definisce anche i requisiti per la gestione del progetto stesso e delle sue fasi, tra cui:
Attività funzionali del team di progetto: stesura della Business Blueprint, preparazione ed esecuzione degli User Acceptance Test, Training
Attività tecniche del team di progetto: customizing del sistema, realizzazione delle interfacce necessarie, esecuzione degli Unit Test
Project Methodology: il cliente identifica il metodo con il quale desidera sia gestito il progetto. Nel caso specifico, il cliente ha richiesto di seguire la metodologia A.SAP, si rimanda al capitolo seguente per l’analisi delle metodologie di gestione dei progetti Project Plan e tempistiche desiderate: il cliente, nella RFP, definisce il piano di progetto e i
tempi desiderati. Questi aspetti vengono successivamente rivalutati insieme al team di progetto dell’azienda fornitrice di servizi.
19
Nel caso specifico il piano di progetto, concordato con i membri di elevata seniority del team del progetto di entrambe le parti, in cui sono state identificate le fasi ed i relativi tempi attesi è il seguente:
Figura 1 Gantt di progetto
Lingua ufficiale per la gestione del progetto: di solito, se l’azienda ha sedi dislocate in altri Paesi, viene utilizzata la lingua inglese
3.2 Analisi as is
In questa fase viene analizzato il processo as is; vengono identificate le caratteristiche fondamentali del processo, svolto manualmente, da replicare sul sistema.
In questa fase vengono identificati:
Gli utenti coinvolti nel processo: vengono individuati gli utenti e i reparti a cui appartengono per ricostruire il flusso del processo
Le procedure definite internamente
Le interfacce interne all’azienda ed esterne (fornitori e clienti) che vengono coinvolte Gli step effettuati dagli utenti: vengono individuate le mansioni degli utenti
I tempi indicativi necessari ad ogni fase: vengono individuati i tempi impiegati dagli utenti, sia interni che esterni, in ogni fase del flusso
L’analisi as is del progetto in questione definisce i punti fondamentali da replicare sul sistema e funge da punto di partenza per interventi di miglioramento.
3.3 Analisi to be
In questa fase il team di lavoro identifica le soluzioni IT e di miglioramento rispetto al processo as is. In questo caso, il processo to be è automatizzato sul sistema e richiede pochi interventi manuali dell’utente.
Analogamente all’analisi precedente, vengono identificati gli utenti, le procedure e gli step interessati nel processo.
Il processo automatizzato a sistema consente un risparmio in termini di tempo e di risorse impiegate, oltre ad una notevole riduzione della complessità informativa da gestire.
20 3.4 Business Blueprint
La Business Blueprint è una descrizione del processo aziendale rivisto in ottica del progetto. Nella BBP vengono riportati:
L’analisi di processo as is
L’analisi di processo to be, evidenziando le differenze e le similarità rispetto al punto precedente
Le funzionalità che il cliente si aspetta di ottenere Le configurazioni che saranno effettuate
La stesura della BBP spetta all’azienda fornitrice che, interfacciandosi con il cliente, identifica le esigenze funzionali dettagliate e propone la soluzione da sviluppare.
L’approvazione della BBP è una milestone di progetto e da questo momento, salvo rari casi e per lievi variazioni, non viene più modificata, decretando l’avvio operativo del progetto e degli sviluppi necessari.
La BBP è un documento utile ad entrambe le parti in quanto viene definito il raggio d’azione del progetto e l’area di intervento dell’azienda fornitrice, identificando inoltre in questo le
responsabilità e gli obiettivi da raggiungere.
3.5 Sviluppo i: analisi tecniche
In questa fase il team analizza il processo e le interfacce dal punto di vista tecnico.
In questa fase viene valutata la ‘readiness’ del sistema all’implementazione della nuova soluzione, ovvero la corretta e sufficiente gestione di informazioni rilevanti per il processo, identificando quei punti bloccanti in cui è necessario intervenire in anticipo. Possono verificarsi infatti dei casi in cui certi tipi di informazioni rilevanti ai fini del progetto non vengano gestite a sistema: si tratta, ad esempio, di campi non valorizzati o valorizzati in maniera errata che sono necessari
all’automazione del processo a sistema.
Nella fase di analisi tecnica vengono creati dei documenti in cui viene indicato lo sviluppo necessario per creare gli oggetti funzionali.
Questi documenti sono i Functional Design Documents e servono per tradurre in linguaggio tecnico la funzionalità degli oggetti.
I FDD vengono creati dai consulenti e utilizzati dai programmatori per realizzare o modificare gli oggetti a sistema.
3.6 Sviluppo ii: configurazione e customizing
In questa fase vengono apportate le modifiche al sistema e creati gli oggetti. Solitamente, insieme all’analisi, è la fase più lunga in quanto le soluzioni che vengono create, prima di giungere ad una forma definitiva, sono soggette ad aggiustamenti frequenti e sono frutto di molteplici incontri con gli utenti interessati che, in un primo momento, non hanno espresso tutti i dettagli necessari.
21
La configurazione del sistema è svolta in un apposito ambiente, in modo da non indurre problemi o errori nell’ambiente usato dagli utenti.
Il sistema è composto da 3 ambienti, assimilabili a copie, uguali tra loro per funzionamento, customizing e configurazione. Gli ambienti sono fondamentali in quanto ad ognuno di essi è associata una funzione particolare:
Ambiente di sviluppo (DEV): in questo ambiente vengono sviluppati i programmi, le modifiche e condotti primi i test volti a verificare il corretto funzionamento. Tutte le modifiche vengono salvate e successivamente trasportate in ambiente di test. In questo ambiente sono presenti anagrafiche a sistema di vecchia data, in quanto la copia
dall’ambiente di produzione avviene ad intervalli di 2- 3 anni, e, spesso, dati modificati dagli utenti per svolgere appositi test
Ambiente di quality (QAS): in questo ambiente sono presenti dati a sistema molto recenti ed è quindi possibile condurre dei test più approfonditi e affidabili. L’obiettivo dei test in questo ambiente è riuscire ad identificare e risolvere tutti gli errori in modo da poter effettuare dei fix quando si è ancora in ambienti di sviluppo e test, senza mettere a rischio il funzionamento dell’ambiente di produzione; questo sistema è chiuso all’esterno e per effettuare dei test di interfaccia con altri sistemi o con il web è necessario utilizzare appositi strumenti o simulare manualmente l’invio e la ricezione dei messaggi
Ambiente di produzione (PRD): questo ambiente contiene i dati e le anagrafiche che sono in vigore. È l’ambiente più ‘pulito’ ma anche il più delicato: non è possibile effettuare test, il trasporto deve richiedere poco tempo ed avere il minimo impatto possibile sulle attività in svolgimento. L’attività di trasporto deve essere autorizzata e coadiuvata dai membri del team di progetto interni all’azienda
Figura 2 Ambienti SAP
Le modifiche al sistema, in sviluppo, vengono effettuate tramite Customizing.
Nel customizing sono impostate le regole che consentono al sistema di svolgere tutte le funzioni, ad esempio sono in questo definite: la struttura dell’impresa (società, stabilimenti, magazzini, shipping point), le vendite (aree vendita, fatturazione, pricing). Il customizing è molto importante in quanto replica e traccia l’impresa come entità concreta in tutte le sue funzioni sul sistema. Ogni sviluppo o modifica da apportare al sistema viene salvata in una CR ‘Change Request’.
22
Le Change Request possono essere associate a:
Modifiche di customizing, in grado di consentire, ad esempio, l’utilizzo di transazioni e funzioni non ancora sfruttate o la creazione di condizioni, documenti e messaggi Nuovi programmi, associati a transazioni custom
3.7 Test
In questa fase vengono testate le modifiche apportate al sistema e le soluzioni implementate. I file di test sono redatti dal team di progetto che identifica:
Scenario di test: è descritto in maniera sufficientemente dettagliata il test che si sta svolgendo
Registrazione documenti rilevanti nel test, ad esempio ordini di acquisto o di vendita Risultato atteso: è ciò che il sistema dovrebbe restituire
Esito del test: è ciò che il sistema restituisce effettivamente Problemi riscontrati: indica gli errori riscontrati nello specifico test
Possibili cause: in base all’errore, si ipotizzano le possibili cause che vengono successivamente indagate in maniera più approfondita
Soluzioni: identificata la causa dell’errore, viene adottata una soluzione e il test viene ripetuto
I test possono essere di 4 tipi:
Unit test: viene testato il corretto funzionamento dell’oggetto preso in modo isolato; questi test sono svolti e tracciati internamente dal team di sviluppo
Integration test: viene testato il corretto funzionamento dell’oggetto che si interfaccia con altri sistemi (legacy o esterni all’azienda) o con altri moduli. Questi test sono svolti, ove possibile, internamente dal team di progetto
Regression test: vengono testati i processi toccati dal progetto, in modo da verificare che i cambiamenti apportati non abbiano indotto errori o cambiamenti non desiderati anche in questi
User acceptance: questi test vengono svolti alla fine degli sviluppi, quando il team ha implementato e fixato tutte le soluzioni in ambiente di quality. In questi test vengono coinvolti gli utenti (users) e vengono mostrate tutte le funzionalità del sistema; l’utente, con l’ausilio del team, testare le soluzioni e verificarne il corretto funzionamento, secondo quanto atteso e secondo quanto scritto in BBP. Nel caso in cui alcune funzionalità non siano coperte, si interviene con dei fix o con delle modifiche e la sessione di UAT viene ripetuta fino all’accettazione completa delle soluzioni; la sessione di UAT costituisce un’importante milestone di progetto in quanto può decidere il go/no go delle successive fasi. Solitamente, è il momento principale in cui viene deciso se autorizzare o meno il Go Live del progetto
3.8 Training
In questa fase il team eroga delle sessioni di training in cui assiste gli utenti allo svolgimento delle attività a sistema. Le sessioni di training hanno lo scopo di rendere autonomi gli utenti per la
23
gestione a sistema del processo, portando questi ad avere una sufficiente padronanza operativa degli strumenti creati e forniti.
In questa fase agli utenti viene mostrato il nuovo processo e i cambiamenti a sistema. Durante le sessioni di training vengono simulate tutte le fasi del processo ed eseguite tutte le funzionalità in ambiente di test.
3.9 Cutover
In questa fase viene preparato il passaggio dall’ambiente di test all’ambiente di produzione. Il piano di cutover identifica le attività e i tempi necessari a preparare il sistema a ricevere tutte le modifiche senza conseguenze negative od omissioni. Questo deve essere preparato per quanto riguarda:
Autorizzazione degli utenti per le nuove transazioni Preparazione della lista delle modifiche da trasportare
Autorizzazione al trasporto delle Change Request in produzione
Valorizzazione tabelle che gestiscono determinati aspetti dinamici del processo Identificazione di eventuali conflitti tra nuove regole e regole vigenti
Aggiornamento di dati coinvolti in processi collegati Migrazione, creazione o modifica dei dati nel sistema
Lo scopo del Cutover è rendere quanto più breve e meno impattante possibile, sia temporalmente che in termini di coinvolgimento anche di altri processi, il trasporto in produzione delle modifiche e delle nuove funzionalità.
3.10 Go Live
Nella fase di Go Live vengono effettuate tutte le attività che rendono effettive le modifiche al sistema in produzione e vengono implementate le soluzioni in modo che siano disponibili per l’utente ed effettive per il processo.
Le modifiche, partendo dall’ambiente di sviluppo, vengono implementate nell’ambiente di quality, nelle fasi di testing. Da questo, al momento del Go Live, vengono implementate nell’ambiente di produzione tramite una procedura detta di ‘Trasporto’.
Questa attività, solitamente, è molto delicata ed è svolta nei tempi strettamente necessari e quando il sistema non è utilizzato dagli utenti in modo da ridurre il più possibile l’impatto del cambiamento sulle attività interagenti svolte a sistema.
Le attività si sostanziano nell’esecuzione di appositi programmi che consentono di importare le modifiche nell’ambiente di produzione tramite le CR, consistono cioè nell’attivazione dei programmi e delle modifiche analizzate e create fino a quel momento negli altri ambienti e nel loro rilascio all’utente.
Il Go Live è la più importante milestone di progetto in quanto è il momento della consegna al cliente.
24 3.11 Hypercare
L’ultima fase di progetto è costituita dal supporto da parte del team. Il team di progetto rimane a disposizione degli utenti, per un periodo di tempo prefissato, principalmente per svolgere le seguenti attività:
Erogazione di ulteriori sessioni di training on the job sulle funzionalità del sistema Monitoraggio del processo e del corretto funzionamento degli oggetti rilasciati Fix di eventuali errori segnalati dagli utenti
Apporto di eventuali piccole modifiche richieste post go live
3.12 Manutenzione
Conclusosi il progetto, la manutenzione del sistema, o degli ultimi sviluppi effettuati, può essere competenza di tre entità diverse:
L’azienda stessa
L’azienda che ha implementato il progetto
Un fornitore di servizi di manutenzione terzo, che si occupa del funzionamento del sistema dopo il passaggio di consegna da parte dell’implementatore
25 4 METODOLOGIE DI GESTIONE DI PROGETTO
In questo capitolo viene effettuata un’analisi delle due metodologie più diffuse per la gestione dei progetti che coinvolgono sviluppi informatici.
4.1. Metodologia Waterfall
Figura 3 Schema delle fasi della metodologia Waterfall
La metodologia Waterfall, o modello a cascata, prevede di seguire in ordine delle fasi standard e sequenziali in grado di condurre dallo studio dei requisiti alla consegna e manutenzione
dell’oggetto. In questo modello ogni fase deve essere completata per poter iniziare la successiva ed in ognuna di queste viene creata e preservata tutta la documentazione necessaria in maniera dettagliata. La metodologia si articola nelle seguenti fasi:
Studio di fattibilità: in questa fase preliminare viene analizzata la fattibilità del progetto. L’analisi è condotta da due punti di vista:
- Tecnico: viene indagata la possibilità di realizzare tecnicamente il progetto; l’analisi comprende anche dettagli su come l'azienda fornirà i servizi, la sede di svolgimento delle attività, la tecnologia richiesta
- Economico - finanziaria: viene indagata la convenienza economica della realizzazione del progetto e viene fatta una stima dell'ammontare di finanziamento o di capitale iniziale necessario, con un errore massimo del 15%
Lo scopo di questa fase è aver analizzato un sufficiente numero di possibili scenari da poter valutare e mettere a confronto
Analisi dei requisiti: in questa fase vengono analizzati e identificati i requisiti dell'oggetto. I requisiti compongono un documento di specifiche che funge da base per tutti gli sviluppi futuri. Il sistema viene inoltre analizzato in maniera approfondita al fine di creare dei modelli e la logica aziendale che verranno utilizzati nell'applicazione, tra cui l’architettura di alto livello/processo e caratteristiche dei singoli componenti
26
Design: in questa fase vengono progettate le soluzioni secondo i requisiti identificati; sono individuabili due sottofasi:
- Progettazione logica: il processo/sistema è progettato, in un primo momento, indipendentemente da qualsiasi altri processo/sistema
- Progettazione fisica: il processo/sistema è progettato in base alle specifiche tecnologie e alle interfacce
Coding: in questa fase viene creata la soluzione/codice necessaria per la realizzazione dell’oggetto
Test: durante questa fase, gli oggetti creati vengono testati; i problemi riscontrati vengono immediatamente e sistematicamente segnalati. Questa fase si ripete con il coding in base all’esito dei test in un ciclo che porta all’eliminazione di tutti gli errori
Rilascio e manutenzione: gli oggetti creati, testati e funzionanti, vengono rilasciati ed inizia la fase di manutenzione per tenerli aggiornati e funzionali
La metodologia Waterfall prevede che ogni fase veda coinvolti membri del team di lavoro specializzati, che hanno ben definita la loro area di intervento e la documentazione da produrre; questo aspetto rende meno impattante il turnover fisiologico sul progetto.
Per la metodologia Waterfall possono essere identificati seguenti vantaggi e svantaggi:
Vantaggi Svantaggi
Presenza di documentazione di progetto definita
Inevitabile slittamento di tutte le fasi in caso di ritardo di una fase
Conoscenza dei tempi da rispettare e milestone
Testing su sviluppi completi e non sui singoli aspetti
Attribuzione precisa del lavoro da svolgere Se i tempi di analisi e sviluppo sono lunghi, rischio di avere un prodotto già vecchio Adattamento forzato della struttura al
progetto: nei progetti gestiti in questo modo sono presenti procedure dettagliate per
gestire ogni aspetto del progetto
Errori di design rivelati sono alla fine in fase di test
Possibilità di cambio dei requisiti all’inizio della fase del ciclo di vita, in quanto la maggior parte degli sviluppi concreti non è ancora
avvenuta
Se le modifiche sono richieste quando gli sviluppi sono in fase avanzata, non è possibile
apportarle Possibilità di definire tempi e costi di progetto
in modo sufficientemente affidabile Attività e team indipendenti Rischio eccessiva burocrazia dovuta alla
27
Per cercare di risolvere questi inconvenienti, si sono affermate metodologie in grado di garantire più flessibilità.
4.2. Metodologia Agile
La metodologia Agile segue un approccio allo sviluppo in base al quale i requisiti e le soluzioni vengono identificati tramite la collaborazione tra i membri di team di lavoro interfunzionali e gli utenti finali. Lo sviluppo Agile sostiene la consegna di porzioni di sviluppo durante il progetto, in modo che queste possano essere testate immediatamente. Questa tipologia di gestione consente una risposta rapida e flessibile al cambiamento.
Figura 4 Schema delle fasi della metodologia Agile
La metodologia Agile predilige:
Individui e interazioni rispetto a processi e strumenti Sviluppi funzionanti rispetto a documentazione completa
Collaborazione con il cliente rispetto a negoziazione del contratto Rispondere al cambiamento rispetto a seguire un piano
Questo significa che, oltre ad avere una base documentale e una buona gestione dei processi tipici del progetto, l’attenzione è posta all’interfaccia interna ed esterna al team di lavoro e deve quindi essere presente una forte collaborazione tra tutti i membri.
La metodologia Agile, secondo il “Manifesto per lo sviluppo di software Agile” si basa sui seguenti principi:
Soddisfazione del cliente tramite consegna anticipata e continua di sviluppi Cambio dei requisiti possibile anche in fase avanzata degli sviluppi
Stretta collaborazione tra utenti e sviluppatori Progetti costruiti attorno a persone motivate
28
Co-location, cioè condivisione della sede di progetto per frequenti incontri faccia a faccia Sviluppi come misura principale degli avanzamenti
Sviluppo sostenibile, in grado di mantenere un ritmo costante Continua attenzione all'eccellenza tecnica e al buon design Massimizzazione del lavoro non necessario non svolto Formazione e gestione tramite team autorganizzati Riflessioni regolari sui possibili miglioramenti
La metodologia Agile prevede l’utilizzo delle iterazioni; le iterazioni sono periodi di tempo variabili di breve durata in cui viene coinvolto un team interfunzionale che segue tutte le fasi del processo di sviluppo. Le fasi che il team segue sono quelle di:
Pianificazione Analisi Progettazione Codifica Unit test Acceptance test
Alla fine dell'iterazione viene consegnato lo sviluppo, cioè una porzione di prodotto/software funzionante, all’utente. In questo modo viene ridotto il rischio della consegna di un progetto non rispondente del tutto alle richieste del cliente; contemporaneamente, è possibile reiterare in modo da correggere in poco tempo gli eventuali errori.
Questo aspetto è favorito dall’utilizzo della co-location, secondo il quale i membri del team di progetto devono trovarsi nello stesso luogo per avere più coesione. In questo modo l'interazione faccia a faccia rende il processo più efficace e riduce il tempo necessario, grazie anche all’elevata numerosità degli incontri.
Nello gestione dei progetti con metodologia Agile, infatti, in una breve sessione giornaliera, i membri del team si incontrano e riepilogano il lavoro svolto a quel momento, decidono quali sono i prossimi passi e identificano i possibili ostacoli.
4.3. Metodologia Scrum
La metodologia Agile più diffusa è la Scrum. La metodologia Scrum prevede 3 ruoli che formano il team di progetto.
1) Product owner
Il Product Owner rappresenta gli stakeholder del prodotto e la voce del cliente; è
responsabile del Backlog del prodotto ed è il responsabile della massimizzazione del valore offerto dal team. Questa figura analizza il prodotto mettendo il cliente al centro dell’analisi e classifica le caratteristiche che il prodotto deve avere in base all'importanza e alle
dipendenze. Il proprietario del prodotto segue questa fase e si concentra sulla parte di gestione economica-temporale del progetto:
29
Dimostra la soluzione concordata agli stakeholders chiave Definisce le milestone
Negozia le priorità e gli aspetti economici del progetto
Assicura che gli sviluppi del prodotto compiuti siano disponibili e completi
2) Team di sviluppo
Il Team di Sviluppo è responsabile degli sviluppi e della loro consegna.
I membri svolgono le attività necessarie per sviluppare il prodotto/software costruire gli incrementi del prodotto; il team è interfunzionale ed eterogeneo, in modo da avere una visione ampia e completa del processo e degli sviluppi.
3) Scrum Master
La metodologia Scrum è facilitata dallo Scrum Master.
Lo Scrum Master rimuove i vincoli all’avanzamento del lavoro del team di sviluppo, supporta le riunioni e assicura che le fasi Scrum siano seguite. Le attività di cui è responsabile lo Scrum Master sono:
Aiutare il Product Owner a manutenere il Backlog del prodotto per garantire che il lavoro richiesto sia compreso ed attuato
Aiutare il team di sviluppo a determinare i requisiti del prodotto Promuovere l'auto-organizzazione del team
Condurre le riunioni del team per garantire l’avanzamento degli sviluppi
Workflow e fasi
In questo paragrafo vengono descritte nel dettaglio le fasi della metodologia Scrum.
Figura 5 Schema delle fasi della metodologia Scrum
La metodologia Scrum è caratterizzata dagli ‘Sprint’, cioè iterazioni, che definiscono l’unita di misura di base degli sviluppi. Lo Sprint è una porzione di lavoro tempificata, di solito di durata compresa tra sette e trenta giorni.
Lo Sprint è composto dalle seguenti fasi:
1) Sprint Planning: in questa fase il team pianifica lo sprint selezionando i requisiti del prodotto che possono essere completati in uno sprint e pianificando le attività necessarie agli sviluppi
30
2) Daily Scrum: ogni giorno viene effettuata una riunione in modo da tenere allineati tutti i membri del team sugli avanzamenti, sulle attività seguenti e vengono identificati i problemi bloccanti che possono essere risolti anche da membri esterni al team, designati dallo Scrum Master
3) Fase di review: alla fine di ogni sprint, il team di sviluppo conduce due attività:
- Recensione Sprint: con questa attività il team confronta il lavoro completato con il lavoro non completato e fornisce il primo sviluppo agli utenti
- Sprint Retrospective: con questa attività il team identifica e concorda le azioni di miglioramento continuo del processo
Figura 6 Schema delle fasi di uno Sprint Artefatti
In questo paragrafo sono descritti i documenti caratteristici prodotti e gestiti durante lo svolgimento di un progetto con questa metodologia.
I documenti fondamentali che vengono creati sono:
Product backlog: il product backlog è una lista dei requisiti del prodotto; è creata e manutenuta da team. Contiene, in modo ordinato, ciò che deve essere consegnato all’utente. L’ordinamento delle consegne può essere fatto in base a criteri tecnologici, di valore economico o temporale ed è deciso dal Product Owner. Il Product Backlog garantisce la visibilità dei requisiti, e quindi degli obiettivi, che il team deve realizzare. Il Product Backlog funge da base di partenza per la pianificazione degli sprint
Product Increment: è la lista dei requisiti del Product Backlog completati durante lo sprint. La somma totale dei Product Increment di ogni sprint, alla fine del progetto, coincide con il Product Backlog
31 Vantaggi e svantaggi
In questo paragrafo vengono elencati i vantaggi e gli svantaggi dell’adozione della metodologia Agile – Scrum per la gestione di un progetto.
Vantaggi Svantaggi
Consegne di prodotto frequenti Non ben gestibile con membri del team poco presenti
Elevata partecipazione del team ai lavori Non ben gestibile con membri del team con forte specializzazione verticale Possibilità di introdurre/modificare i requisiti
in fase di sviluppo
Non ben applicabile in casi di prodotto/software molto integrati, i Regression Test possono richiedere molto
tempo
Customer satisfaction elevata Mancanza di una figura più autorevole in grado di gestire situazioni problematiche Continua attenzione all’eccellenza tecnica e al
miglioramento Possibile mancanza di documentazione Rischio di burnout dei membri del team
4.4. Confronto tra le metodologie
In questo paragrafo vengono confrontate le metodologie Waterfall e Agile. Le due metodologie differiscono per:
Aspetto Waterfall Agile
Realizzazione degli sviluppi
Gli sviluppi sono realizzati totalmente partendo dai
requisiti
Gli sviluppi sono realizzati a pacchetti, partendo da un
sottoinsieme di requisiti (sprint)
Conduzione dei test
I test vengono svolti alla fine della fase di sviluppo, viene quindi testato l’intero
progetto
I test vengono svolti iterativamente alla fine di
ogni sviluppo Consegna degli sviluppi Completa alla fine della
relativa fase
A pacchetti, alla fine di ogni sviluppo identificato da uno
sprint Gestione del team
Team separati per locazione, competenza e
lavoro svolto
Team unito per locazione. Partecipazione richiesta molto elevata e presenza
costante Leadership Il team è gestito da un
project manager
Il team è autogestito; lo Scrum master conduce e
32
supporta le riunioni e gli sprint
Ambito d’uso
Utilizzabile in progetti in cui sono ben definiti i confini e
gli obiettivi, in cui il grado di incertezza è molto basso
Utilizzabile in progetti in cui il grado di incertezza è molto elevato in quanto
permette di cambiare i requisiti ed adattare gli sviluppi in modo flessibile e
rapido
Similarità con altre metodologie -
PDCA: la scomposizione del totale in piccoli pacchetti pianificati, realizzati, testati,
(corretti) è un tipico approccio PDCA e consente
di consegnare prodotti conformi Focus
Sul progetto e sulla documentazione, a lungo
termine
Sul prodotto e sulle funzionalità, a breve
termine
Recentemente, per cercare di risolvere gli svantaggi che affliggono le metodologie sopra esposte, si è affermata una soluzione ibrida che mira ad utilizzare i loro punti di forza.
La Waterfall – Agile Hybrid è una metodologia che utilizza in maniera sequenziale ed alternativa le due metodologie, utilizzando ciascuna nella fase più adatta.
33
Nella fase iniziale, quella di raccolta e definizione dei requisiti generali, svolta dai membri con competenze di tipo business del team, viene adottata la metodologia Waterfall, con lo scopo di produrre documentazione e definire lo scopo del progetto.
La fase di realizzazione degli sviluppi utilizza la metodologia Scrum, in modo da consentire al team di sviluppo di adattarsi alle esigenze del cliente attraverso feedback e consegne continui, con tempi predefiniti e limitati.
34 5 ANALISI E DESCRIZIONE DEL PROCESSO
5.1 Introduzione
In questo paragrafo è illustrata la gestione del processo dal punto di vista operativo.
Il processo coinvolge essenzialmente 4 aree aziendali. Le aree, nell’ambito di questo processo, svolgono le seguenti attività:
Business: è l’area incaricata di seguire il progetto dal punto di vista operativo; riceve, dal Reparto Acquisti, la lista dei materiali approvvigionati da ciascun fornitore e, dal Controllo di Gestione, le distinte base dei prodotti finiti. Si occupa di svolgere il calcolo preferenziale per ogni prodotto finito destinato alla vendita e si tiene costantemente aggiornato sugli sviluppi degli accordi commerciali tra i Paesi
Acquisti: è l’area incaricata di gestire il rapporto con i fornitori e di gestire le anagrafiche dei materiali con tutte le informazioni rilevanti per la gestione del processo sul sistema informativo aziendale
IT: è l’area incaricata di seguire il progetto dal punto di vista tecnico ed economico. Garantisce che il processo sia correttamente implementato sul sistema informativo aziendale seguendo le fasi di analisi e sviluppo delle soluzioni
Controllo di gestione: è l’area incaricata di gestire le distinte base dei prodotti finiti
5.2 Processo AS IS
L’azienda cliente, attualmente, gestisce questo processo fuori sistema secondo i seguenti step: L’utente incaricato, appartenente al Reparto Business, richiede la lista di tutti i codici
approvvigionati dai rispettivi fornitori al Reparto Acquisti
L’utente invia manualmente la richiesta di vendor declaration ad ogni fornitore singolarmente e allega un file excel in cui sono elencati i codici approvvigionati Ogni fornitore compila ed invia la vendor declaration contenente le indicazioni sulla
preferenzialità dei codici
L’utente richiede le distinte base costificate dei prodotti finiti al Controllo di Gestione L’utente inserisce manualmente l’informazione precedente nei file excel contenenti le
distinte base costificate dei prodotti finiti
Sempre manualmente, viene effettuato il calcolo per ogni singolo codice prodotto finito per stabilire se questi sono preferenziali o meno rispetto alle regole preferenziali vigenti della zona verso la quale viene effettuata la vendita
A causa della gestione manuale attuale, l’azienda gestisce un’unica zona utilizzando la regola più restrittiva, e quindi penalizzante, per limitare la complessità dei calcoli.
35
Creazione di apposite e-mail per ogni codice fornitore: considerata la numerosità dei fornitori e la loro eterogeneità per area geografica e lingua, la fase di creazione delle comunicazioni richiede un impegno ed un lasso di tempo elevati
Recupero delle informazioni dai file ricevuti e loro collocazione nelle distinte base dei prodotti finiti: per ogni distinta base, è necessario identificare la preferenzialità dei componenti in base a quanto dichiarato nei file ricevuti dal fornitore
Calcolo della preferenzialità dei prodotti finiti: per ogni codice prodotto finito è necessario svolgere manualmente il calcolo identificando i componenti preferenziali, i componenti non preferenziali ed il loro valore
36
37 5.3 Processo TO BE
L’implementazione del processo sul sistema informativo aziendale consente di automatizzare e velocizzare le fasi; nello specifico consente:
Calcolo della preferenzialità completamente automatico tramite transazione
standardizzata e validata: il sistema è in grado di estrarre automaticamente il valore e l’informazione della preferezialità immessa a sistema ed associarle alla distinta base del codice prodotto finito
Indicazione della preferenzialità salvata direttamente in anagrafica materiale, sia per codici approvvigionati, derivanti dalla vendor declaration, che per codici prodotto finito, derivanti dal calcolo
Determinazione automatica della preferenzialità a livello di ordine di vendita, in base al codice prodotto finito, al paese di destinazione e ad altre regole di seguito descritte Estrazione automatica dei codici su cui richiedere la vendor declaration per codice
fornitore
Invio automatico, previo inserimento degli indirizzi e-mail dei destinatari, della richiesta della vendor declaration
Archiviazione delle vendor declaration
L’esecuzione del processo risulta quindi più rapida, semplice ed efficace in quanto vengono quasi del tutto eliminate le attività manuali e ridotta la complessità di gestione del processo.
38
39 5.3.1. Gestione anagrafiche materiale
Le informazioni relative alla preferenzialità dei codici vengono salvate nell’anagrafica materiale e possono essere di due tipi:
Lato acquisti: l’utente incaricato indica il file compilato dal fornitore e le informazioni vengono automaticamente immesse a sistema tramite caricamento delle vendor declaration
Lato vendite: il calcolo della preferenzialità è lanciato dall’utente incaricato e il risultato del calcolo viene salvato nell’anagrafica materiale
Le informazioni vengono salvate all’interno dell’anagrafica materiale, nei dati di Commercio estero/export. Tramite una apposita funzione in cui vengono specificate le “Preferenze dogana” è possibile accedere alla tabella “Prefer. Dogana”, in cui vengono visualizzati:
Zona preferenziale: sono le zone definite secondo le indicazioni fornite dall’azienda cliente per la clusterizzazione dei paesi
Preferenza: è il risultato del calcolo secondo le regole definite per zona preferenziale Calcolo preferenziale: indica la data in cui è stato eseguito il calcolo
Dichiarazione del fornitore: riporta la preferenzialità indicata dal fornitore nella vendor declaration per lo specifico materiale in riferimento alla zona indicata
Data validità: indica la data di scadenza della vendor declaration
Per quanto riguarda i prodotti finiti, i codici che possono essere attribuiti in base all’esito del calcolo preferenziale sono:
A: è settato di default quando il calcolo non è ancora stato eseguito
B: indica che il controllo è stato eseguito e il prodotto finito risulta preferenziale rispetto al prezzo, cioè il prezzo di vendita deve essere maggiore di una certa soglia
C: indica che il controllo è stato eseguito e il prodotto risulta preferenziale D: indica che il controllo è stato eseguito e il prodotto risulta non preferenziale E: indica che è stata settata manualmente la preferenzialità di un prodotto F: indica che è stata settata manualmente la non preferenzialità di un prodotto
Per quanto riguarda i materiali approvvigionati dai fornitori, i codici che possono essere attribuiti nell’anagrafica materiale sono:
A: indica che il controllo sulla vendor declaration non è ancora stato eseguito
B: indica che il controllo è stato eseguito e il materiale è stato dichiarato preferenziale C: indica che il controllo è stato eseguito e il materiale risulta ancora preferenziale a causa
di una vendor declaration in corso di validità
D: indica che il controllo restituisce errori di compilazione nella vendor declaration I valori di preferenzialità vengono sempre sovrascritti nei seguenti casi:
40
Aggiornamento della preferenzialità a seguito della ricezione di una nuova vendor declaration e caricamento a sistema
Aggiornamento della preferenzialità del prodotto a seguito del lancio del calcolo
5.3.2. Gestione delle vendor declaration
Nel seguente paragrafo è illustrato come è articolato il processo di gestione delle vendor declaration.
Le fasi che lo costituiscono sono le seguenti: 1) Richiesta della vendor declaration al fornitore
In questa fase è disponibile un programma schedulabile in grado di: Estrarre tutte le vendor declaration attive
Estrarre i nuovi materiali creati per i quali non è ancora presente una vendor declaration Il programma genera ed invia automaticamente una e-mail al fornitore per richiedere la nuova vendor declaration. Si prevede che l’azienda invii la richiesta in un mese prestabilito e che il numero di giorni di anticipo con cui inviare la richiesta rispetto alla data di scadenza vengano definiti dal responsabile di questa attività.
La e-mail è costituita da diversi componenti:
Corpo: nel testo predefinito dell’e-mail vengono indicati l’indirizzo di posta elettronica certificata dedicato, a cui il fornitore dovrà inviare la vendor declaration, e le istruzioni necessarie al fornitore per la corretta compilazione del file allegato
Allegato 1: è il modulo contenente la vendor declaration che il fornitore dovrà firmare, ha validità legale e deve avere come riferimento il file in cui viene specificata la preferenzialità di ogni codice sottoposto a richiesta di dichiarazione
Allegato 2: è il file excel nel quale sono elencati i materiali approvvigionati dal fornitore in questione e le zone per le quali il fornitore indica la preferenzialità
Allegato 3: è il file pdf in cui vengono indicate le motivazioni della richiesta della vendor declaration al fornitore
2) Gestione delta vendor declaration
Ogni anno, con cadenza prefissata, viene aggiornata la preferenzialità dei codici nuovi o modificati per cui il fornitore invia una vendor declaration. Le vendor declaration precedenti rimangono valide fino alla scadenza. Vengono prese in considerazione anche le dichiarazioni con scadenza al 31.12 dello stesso anno
3) Caricamento delle vendor declaration a sistema
Quando il fornitore ha inviato la vendor declaration, il file contenente le indicazioni di preferenzialità deve essere caricato a sistema; quest’ultimo ha il seguente funzionamento:
41
L’utente incaricato deve indicare manualmente il file contenente i dati da caricare ed inserire la data di scadenza della dichiarazione indicata dal fornitore
È inserito un controllo sul file di dichiarazione ricevuto dal fornitore al fine di verificare che i materiali per i quali è stata richiesta la vendor declaration siano coerenti a quelli per cui il fornitore invia la dichiarazione:
- Nel caso in cui non sia presente un record inviato, questo viene registrato come “non dichiarato”
- Nel caso in cui sia presente un record aggiuntivo rispetto a quelli inviati, questo viene registrato tramite un warning
4) Archiviazione vendor declaration
Le copie originali delle vendor declaration vengono archiviate e mantenute a sistema in due modi: Nel server di posta elettronica certificata
In anagrafica fornitore
5.3.3. Gestione assiemi
In questo paragrafo è illustrato l’aspetto di gestione degli assiemi. L’azienda ha infatti la necessità di gestire questa informazione in quanto i materiali utilizzati in assemblaggio sono di acquisto o in conto lavoro.
Nel caso di assiemi derivanti da conto lavoro, la soluzione prevede l’utilizzo della preferenzialità indicata dal fornitore nella vendor declaration sul codice padre senza considerare quella dei singoli componenti, grazie alla conoscenza da parte del fornitore terzo del valore dei materiali inviati. È possibile quindi gestire gli assiemi secondo le seguenti modalità:
Tabella OPM_ASSIEMI
Viene creata una tabella custom dove vengono inseriti i codici da considerare come componenti unici (le prime 3 digit del codice materiale)
Tabella OPM_ASSIEMI_EXPL
Viene creata una tabella delle esclusioni in cui vengono inseriti i codici aventi le prime 3 digit sopracitate ma che devono essere esplosi durante il calcolo
Il codice viene considerato come componente unico se le prime 3 digit sono contenute all’interno della tabella OPM_ASSIEMI e non sono presenti all’interno della tabella delle esclusioni OPM_ASSIEMI_EXPL
Per tutti gli altri assiemi il calcolo esplode il codice in tutti i suoi componenti, considerando quindi la preferenzialità di ogni singolo componente
42 5.3.4. Processo di vendita
Nel seguente paragrafo è illustrato come è articolato il processo di vendita in ottica OPM.
5.3.4.1. Ordine di vendita
Alla creazione di un nuovo ordine di vendita, il sistema setta automaticamente la preferenzialità del prodotto, secondo le informazioni contenute in anagrafica materiale. Il veicolo può quindi risultare:
Preferenziale, in quanto dall’esito del calcolo è risultato che il prodotto è sempre preferenziale
Non preferenziale, in quanto dall’esito del calcolo è risultato che il prodotto è sempre non preferenziale
Preferenziale rispetto al prezzo, in quanto la preferenzialità del veicolo dipende dal valore soglia stabilito e dalla differenza tra prezzo di vendita e prezzo preferenziale calcolato dal sistema. In questo caso il sistema calcola un prezzo minimo in maniera statistica al di sopra del quale il prodotto risulterà preferenziale
Per una migliore e più sicura gestione dei listini e per evitare di ottenere un risultato di preferenzialità negativo, è possibile inserire un valore aggiuntivo, che va a sommarsi al valore soglia minimo esito del calcolo preferenziale, da rispettare con tutti i listini della zona.
Viene utilizzata una tabella nella quale viene inserito il codice materiale del veicolo, il listino del paese di destinazione, la divisa e l’importo soglia aggiuntivo.
Il controllo è così definito:
Viene controllata la tabella con accesso tramite codice materiale e listino del paese di destinazione
Viene fatto un confronto tra prezzo di vendita e prezzo preferenziale, calcolato dal sistema: se tale differenza è maggiore o uguale al valore soglia, il prodotto è preferenziale;
altrimenti, è non preferenziale. Lo scopo di questa soglia è quello di avere una sicurezza aggiuntiva di ottenimento della preferenzialità in termini di prezzo nei paesi in cui il prezzo di vendita si avvicina al prezzo preferenziale calcolato dal sistema.
Tutti questi controlli sono implementati già a livello di ordine di vendita, in modo da consentire una rapida visualizzazione della preferenzialità del codice materiale e dei possibili riscontri in fase di vendita e spedizione.
5.3.4.2. Delivery
A seguito del salvataggio dell’ordine di vendita, viene creata una delivery. La gestione della delivery si articola nelle seguenti fasi:
Assegnazione del VIN (numero seriale) al codice prodotto: il VIN del veicolo viene associato alla consegna
