CAPITOLO 4
INTEGRAZIONE DI OTM IN MODALITA’
TRADIZIONALE
In questo capitolo verrà presentata la modalità di proposizione di Oracle
Transportation Management tradizionale, delineando quelli che sono i cost driver
principali che concorrono a determinare i costi di implementazione e gestione
della soluzione proposta.
Questi dati saranno, nei prossimi capitoli, comparati con quelli derivanti
dall’analisi dei driver di OTM proposto in ottica SaaS, verificando quindi se in
quest’ultima modalità si possono ottenere vantaggi in termini di riduzioni di costo.
4.1 Copertura funzionale della soluzione
Per proporre una soluzione ad un cliente che manifesta determinate esigenze
sono necessari una serie di passi che, a lavoro ultimato, porteranno alla
delineazione di un prodotto che soddisfa tutte le esigenze espresse.
Nel caso di un software verticale come OTM, ovvero un prodotto di mercato, adattarlo alle necessità di un committente può voler dire effettuare
un’approfondita analisi dei requisiti richiesti, verificare quali di questi siano già
soddisfatti dalle funzionalità del prodotto stesso, quali requisiti invece necessitino
di una personalizzazione del prodotto ed infine quelli per cui la soluzione non
supporta nessuna funzionalità adatta a soddisfarli e quindi necessitano di uno
4.1 Copertura funzionale della soluzione
Un esempio chiarificatore potrebbe essere la proposizione di OTM per
un’azienda che svolge un servizio di trasporto auto in cui si presentano tutte le
situazioni appena descritte. La fase di pre-analisi del progetto ha portato ad
effettuare la GAP-Analisys della soluzione rispetto alle esigenze espresse dal
cliente. Il risultato dell’analisi è sintetizzato dalla Tabella 4.1 seguente che riporta:
• funzionalità: requisito espresso dal cliente;
• STD nel prodotto: indica che la funzionalità richiesta è già presente nel
prodotto offerto ed è necessaria solo un’attività di configurazione del
prodotto per adattarla alle esigenze del committente;
• personaliz. prodotto: indica che la funzionalità viene implementata
attraverso una personalizzazione del prodotto, intesa come estensione della
soluzione implementata unicamente con gli strumenti messi a disposizione
del prodotto stesso senza specifici sviluppi di codice;
• sviluppo a progetto: indica che la funzionalità è realizzata tramite
specifici sviluppi previsti nella fase di realizzazione del progetto, integrati
4.1 Copertura funzionale della soluzione
Tabella 4.1 Esempio GAP analisys requisito cliente/funzionalità prodotto.
Funzionalità STD nel prodotto Personaliz. prodotto Sviluppo a progetto Acquisizione/Inserimento di OdT/ LdC
Acquisizione automatica degli ordini di trasporto e/o delle liste di carico dai sistemi informativi
legacy
Inserimento manualmente gli OdT che il cliente
invia alla cliente extra sistema
Schedulazione e ottimizzazione dei viaggi
Generazione piano trasporti ottimizzato, in funzione delle risorse disponibili e dei vincoli di trasporto predefiniti dall’utente, rispetto al criterio scelto dall’utente (costo minimo, miglior
livello di servizio, …).
Esecuzione automatica della schedulazione fronte di variazioni delle risorse disponibili e/o dei vincoli, sia in modo manuale su esplicita
richiesta dell’utente
Esecuzione automatica della schedulazione a fronte di variazioni delle risorse disponibili e/o
dei vincoli
Esecuzione manuale della schedulazione su
esplicita richiesta dell’utente
Esecuzione della schedulazione che consideri le
4.1 Copertura funzionale della soluzione
Conferma e/o modifica da parte dell’utente del Piano Trasporti generato, prima di renderlo
operativo
Tracking
Registrazione della posizione e del carico di ciascuna bisarca, durante il viaggio (stato della
consegna).
Acquisizione delle informazioni relative all’avvenuto carico/scarico inviate dall’autista tramite hardware general purpose o specifico (sms, cellulare con scheda per il riconoscimento
vocale, palmare, …).
Trasmissione delle POD al sistema legacy del
cliente
Accesso ai clienti dell’ azienda di trasporti per l’acquisizione/verifica dei dati relativi ad uno
specifico telaio
Gestione clienti
Interfaccia per la ricezione dal sistema SAP dei
dati anagrafici dei clienti
Interfaccia per l’invio a SAP dei dati necessari all’emissione fatture o alla verifica fatture nel caso di fatturazione in nome e per conto (es.
trasporto primario per cliente Fiat Auto)
Gestione fornitori
Interfaccia per la ricezione dal sistema SAP dei
dati anagrafici dei fornitori
4.1 Copertura funzionale della soluzione
alla verifica delle fatture passive
Gestione autisti
Anagrafica autisti
Programmazione rinnovo patente
Gestione tessere identificative
Registrazione dei dati consuntivi presenti sul disco orario, consegnato dal vettore al suo rientro, e visualizzazione dello scostamento di
tali dati dai dati previsti
Gestione mezzi
Anagrafica mezzi
Programmazione revisione annuale in funzione dei dati presenti in anagrafica e delle regole di revisione definite sul sistema (programmazione a
calendario)
Programmazione interventi di manutenzione ordinaria in funzione dei dati presenti in anagrafica e delle regole di manutenzione
definite sul sistema
Gestione interventi di manutenzione straordinaria
Gestione danni
Registrazione sul sistema della scheda danni fornita in formato cartaceo dal vettore al suo
rientro (adattamento a scheda fornita da Fiat)
Gestione tariffari
4.1 Copertura funzionale della soluzione
Gestione contratti assicurativi
Gestione contratti assicurativi per i mezzi di
trasporto
Gestione contratti assicurativi per i danni da
trasporto
Reportistica
Reportistica standard del package Export dei report in formato excel
La presenza di requisiti che necessitano di personalizzazione del prodotto e
soprattutto di sviluppo a progetto possono portare ad un incremento dei costi di
sviluppo, che uniti ai costi di licenza e hardware già alti per un software verticale
come OTM lo rendono appannaggio sono delle grandi aziende che dispongono di
budget di spesa per i software elevati.
4.2 Elementi che compongono il costo della soluzione
Analizzeremo adesso le voci di costo principali nell’ambito di un progetto di
integrazione di una soluzione software applicativa basata su prodotto, elementi
chiave nella definizione dell’investimento richiesto al cliente.
I cost driver più importanti possono essere raggruppati in due macrocategorie:
• prodotti;
• servizi.
I fattori che vanno a sommarsi nel prodotti sono principalmente i costi di
4.2 Elementi che compongono il costo della soluzione
I servizi, invece, sono le voci di costo legate ai servizi professionali necessari
al progetto di integrazione e alle successive attività di manutenzione.
Di seguito approfondiremo i costi legati a questo secondo driver facendo
riferimento alla proposizione tradizionale di Oracle Transportation System,
esponendo prima quelli legati alla fase di sviluppo e poi quelli di gestione,
evidenziando per entrambi la metodologia di lavoro applicata.
I costi che contribuiscono alla determinazione del driver “servizi” sono stati
individuati nella quantificazione, ad esempio in giorni uomo, del lavoro
necessario per la proposizione della soluzione. La metodologia applicata per
l’integrazione in questione può essere riassunta nelle quattro fasi di cui si
compone lo sviluppo di OTM per l’azienda di trasporti presa in esame e nelle due
fasi che compongono la gestione dell’applicazione.
4.2.1 Servizi per lo sviluppo: definizione della strategia
Questa rappresenta la fase iniziale del processo di sviluppo e prevede la
pianificazione del progetto di implementazione e la creazione dell’infrastruttura
per supportarne le attività.
Il team di progetto stabilisce inizialmente le linee guida generali che si
seguiranno per sviluppare e gestire il progetto nel suo complesso, dalla
pianificazione iniziale fino alla completa implementazione e messa in produzione
del sistema.
I primi passi vengono mossi per rivedere ed analizzare gli attuali processi
operativi e di supporto per giungere a definire macro-requisiti completi e
condivisi. Per raggiungere una chiara comprensione del business di riferimento,
4.2 Elementi che compongono il costo della soluzione
modello di business e realizza macro-modelli dei nuovi processi avvalendosi, se
opportuno, di modelli di processi pre-definiti (“best practices”).
4.2.2 Servizi per lo sviluppo: analisi e disegno della soluzione
La seconda fase vede impegnato il gruppo di lavoro nella definizione dei
modelli architetturali, sia funzionali che tecnologici, e dei processi passando
prima attraverso la chiara definizione dei requisiti di business e di sistema. Lo
scopo è quindi quello di creare la soluzione ottimale ai processi di business attuali
ed anche futuri dell’azienda.
Le attività principali che si svolgono in questa fase possono essere
schematicamente riassunte nel seguente elenco:
• disegno del nuovo modello dei processi: partendo dall’analisi dei
processi attuali ed in funzione dei macro-requisiti identificati verrà
definito il modello dei processi;
• definizione dei requisiti di business: definizione e formalizzazione dei
requisiti del cliente. Per ogni area funzionale, business unit, divisione, etc.
vengono analizzate le richieste avendo come prospettiva il modello di
business futuro.
• mappatura dei requisiti di business: viene effettuata la mappatura tra i
requisiti raccolti nella fase precedente e il modo in cui questi possono
essere coperti dal nuovo sistema informativo, al fine di fornire in maniera
puntuale la risposta al requisito, la/le soluzioni possibili e là dove non
esiste una copertura completa verrà proposta una soluzione alternativa
chiamata in genere “workarounds”. Un “workaround” rappresenta una
4.2 Elementi che compongono il costo della soluzione
della quale agli utenti potrebbe essere richiesto un adattamento delle
procedure operative. Inoltre saranno evidenziati tutti i requisiti per i quali
non esiste una copertura funzionale standard e non è possibile studiare un
“workaround”. Questi requisiti sono denominati gap;
• architetture tecniche ed applicative: attraverso quest’attività quale sarà
possibile definire l’architettura applicativa e tecnologica. L’architettura
tecnica viene definita in modo che possa pienamente supportare la
configurazione standard dell’applicazione e che tenga in considerazione le
necessità architetturali future del committente. L’architettura applicativa
consiste nella stesura di documenti in cui vengono riportate le
parametrizzazione di base dell’intero sistema; utenti, funzioni, menu,
permessi di accesso, risorse del sistema, ecc.
• Pilot Technology Setup (desktop, network, ecc.): consiste
nell’allestimento e verifica delle componenti infrastrutturali (ad esempio
desktop, LAN e WAN) che concorrono al funzionamento del nuovo
sistema informativo dell’impresa di trasporto auto fin qui trattata.
4.2.3 Servizi per lo sviluppo: implementazione
Durante questa terza fase vengono implementate e configurate le soluzioni
identificate durante le attività precedentemente descritte di Modelling & Design,
eseguendo la parametrizzazione finale del sistema, sviluppando le estensioni
funzionali necessarie ed i programmi di conversione ed interfacciamento richiesti
4.2 Elementi che compongono il costo della soluzione
Per far ciò vengono predisposti gli ambienti necessari a sostenere lo sviluppo
del progetto, primo tra tutti l’ambiente di sviluppo, e di seguito quelli di
certificazione, di produzione e di test.
Le attività principali che si svolgono in questa fase possono essere
schematicamente riassunte nel seguente elenco:
• prototyping: se previsto dalle piano di progetto si procederà con lo
sviluppo del prototipo, ovvero nella costruzione di una componente
parziale del sistema idonea alla dimostrazione di una parte delle
funzionalità del sistema;
• application setup: esecuzione del setup del sistema all’interno
dell’ambiente di test al fine di preparare il modello del nuovo sistema per
l’esecuzione delle procedure di conversione dei dati e del system test;
• realizzazione delle interfacce: insieme di attività finalizzate alla
realizzazione delle interfacce per lo scambio dei dati tra il sistema oggetto
del progetto ed altri sistemi del committente che resteranno operativi
anche dopo l’entrata in esercizio del nuovo sistema. Le attività
comprendono l’analisi, il disegno, lo sviluppo e il test;
• realizzazione personalizzazioni: insieme di attività finalizzate alla
realizzazione delle funzioni personalizzate derivanti dalla necessità di
coprire esigenze di business non supportate dalle funzionalità del prodotto
standard. Le attività comprendono l’analisi, il disegno, lo sviluppo e il test;
• data conversion: attività attraverso la quale sarà possibile definire le
4.2 Elementi che compongono il costo della soluzione
complessità di caricamento, dell’ampiezza temporale dell’archivio storico,
dei tempi di conversione, del caricamento in produzione;
• documentazione: attività attraverso la quale sarà possibile seguire,
produrre, aggiornare e archiviare tutta la documentazione del progetto. La
documentazione del progetto consiste nei “deliverables” prodotti durante
l’esecuzione delle diversi fasi del progetto. Di particolare rilevanza è la
preparazione della Documentazione utente che comprende la descrizione
delle funzionalità dei moduli parametrizzati più quelle realizzate tramite
personalizzazioni;
• test di sistema e di performance: questa attività comprende la definizione
dei requisiti del testing, della strategia di test che sarà adottata, della
modalità di gestione di eventuali errori;
• change management: scopo di questa attività è di effettuare una
valutazione degli impatti e dei rischi associati alla realizzazione del
progetto di implementazione della soluzione in termini di resistenza al
cambiamento indotto, per poter correttamente formulare le necessarie
azioni in termini di comunicazione, coinvolgimento, formazione ed
addestramento;
• coinvolgimento degli utenti: questa attività si propone di massimizzare il
coinvolgimento degli utenti nella realizzazione del progetto;
• gestione della comunicazione: questa attività è finalizzata alla gestione
4.2 Elementi che compongono il costo della soluzione
• gestione della formazione: quest’attività riguarda la formazione sulle
caratteristiche del modello specifico di sistema realizzato per il cliente
indirizzato ai key user.
4.2.4 Servizi per lo sviluppo: transizione al (nuovo) sistema
Questa è la fase finale del processo di sviluppo che prevede il trasferimento,
all’interno dell’organizzazione del cliente, del sistema completamente
configurato, completo di dati, interfacce, personalizzazioni, documentazione e
materiale per uso e addestramento e comprendente le sessioni end to end di
business simulation e di installazione degli ambienti di pre-produzione e
produzione.
Il passo successivo consiste nella valutazione e verifica definitiva delle reali
funzionalità in base agli obiettivi del progetto e delle prestazioni del sistema in
base alla prestazione prevista. Il perfezionamento del sistema viene effettuato
mediante un approccio controllato, onde minimizzare l’impatto sugli utenti finali.
Inclusa in questa fase finale è una serie di attività di perfezionamento per
stabilizzare il sistema e per avviare una regolare manutenzione.
La transizione termina con l’avvio del sistema in produzione e la certificazione
finale di conformità agli scopi ed obiettivi di business del progetto, segnando
come detto l’ultimo passo della fase dell’implementazione ed anche l’inizio del
ciclo di supporto del sistema.
4.2.5 Servizi per la gestione: gestione del progetto
Con quest’attività si apre la descrizione dei fattori di costo che incidono,
4.2 Elementi che compongono il costo della soluzione
La gestione del progetto rappresenta l’insieme delle attività tramite le quali il
responsabile (Project Manager) definisce le strategie ed il piano di progetto
esploso fin nelle attività più elementari, determina le milestone, assegna i tempi e
le risorse, controlla lo stato di avanzamento lavori, interagisce con il management
aziendale e coordina i rapporti tra il cliente e i/il team di progetto.
I principali strumenti utilizzati in quest’attività sono:
• kick-off della commessa: il kick-off meeting (incontro tra committente e
produttore) costituisce lo start-up ufficiale dell’attività ed ha come
risultato la realizzazione di documenti che esplicitano i requisiti del
sistema, l’attribuzione dei ruoli e delle responsabilità e la definizione dei
milestone e del piano iniziale di rilascio dei deliverable;
• piano di progetto: il piano di progetto è realizzato nella fase di
modellazione concettuale del sistema (fase di sviluppo definizione della
strategia) e viene revisionato in caso di significative modifiche ai requisiti
iniziali. E’ costituito dalla sequenza logica delle attività, indicando per
ognuna di esse i ruoli e le responsabilità in termini di verifica, ispezione,
revisione ed approvazione, dai punti di verifica per ogni fase di sviluppo e
progettazione ed infine dalle date di completamento.
4.2.6 Servizi per la gestione: gestione della qualità
La gestione della qualità comprende le attività per assicurare la qualità del
prodotto finale. A tal fine ve sono alcune che sono considerate di particolare
rilevanza:
• stato avanzamento lavori: quest’attività viene pianificata prima
4.2 Elementi che compongono il costo della soluzione
settimane, intervallo di tempo che varia in funzione della complessità e
delle criticità della fase. Ha lo scopo di verificare che tutte le attività siano
state concluse ed i delivery prodotti, evidenziando eventuali carenze
progettuali e/o problemi sorti ed individuare adeguate azioni correttive;
• verifiche della progettazione: le verifiche consentono di valutare gli
output di ogni fase della progettazione e sviluppo, al fine di accertare il
soddisfacimento dei requisiti in ingresso. Attraverso esse la tracciabilità
dei requisiti del cliente viene garantita in tutti i documenti prodotti nel
corso della progettazione e dello sviluppo. Inoltre, se ogni output della
fase è riconducibile ad un input, si garantisce l'assenza di attività superflue
al raggiungimento degli obiettivi definiti;
• review con il cliente: viene sottoposto a quest’attività ogni documento di
progetto rilasciato. Lo scopo è quello di permettere al cliente di valutare se
l’evoluzione del progetto è in linea con i requisiti di base e la tempistica
prevista, e di ottenere da esso un riscontro (approvazione), che permetta di
procedere con le fasi successive del progetto;
• validazione del sistema: le attività di validazione permettono di accertare
il corretto funzionamento del sistema realizzato attraverso il processo di
progettazione e sviluppo, in relazione con i requisiti contrattuali. La
sequenza dei test che viene effettuato a tal scopo prevede inizialmente il
test plan, la definizione degli obiettivi che si vuole perseguire con il
testing, la definizione degli input, dei risultati attesi, la determinazione
della sequenza di operazioni necessarie all'esecuzione di un test ed infine
4.2 Elementi che compongono il costo della soluzione
4.2.7 Servizi per la gestione: gestione del rischio
Ultima fase dei servizi per la gestione del software è la gestione del rischio.
Questo rappresenta un aspetto molto importante da tenere sotto controllo in un
progetto di sviluppo software, in quanto può prevenire eventuali situazioni
dannose che, se verificate, potrebbero mettere a rischio il completamento del
progetto nei termini fissati, con un inevitabile incremento dei costi.
Il rischio, componente non eliminabile, può essere gestito innanzitutto
identificandone le tipologie, documentandolo, assegnandone probabilità ed
estensione dell’impatto che avrebbe se dovesse verificarsi. Tale approccio
consente sia di intervenire a priori per ridurne la probabilità di manifestarsi, se
possibile, o di mitigarne gli effetti negativi sul progetto.
Quest’attività è articolata in sottoprocessi che possono essere così
schematizzati:
• segnalazione del rischio: ogni membro del gruppo di lavoro ha la
possibilità di segnalare un rischio che ha identificato per quanto attinente
al proprio ruolo e area di competenza nel progetto;
• registrazione del rischio: questo processo consente al Project Manager di
passare in esame tutti i rischi segnalati dai suoi collaboratori e determinare
se essi sono effettivamente applicabili al progetto. Tale decisione viene
presa in base al fatto che il rischio abbia o meno impatti sui deliverable
previsti dal progetto o specificati dal piano della qualità o impatti sulle
tempistiche programmate nel piano di progetto.
• azioni per mitigare il rischio: viene effettuata la revisione formale di tutti
4.2 Elementi che compongono il costo della soluzione
il rischio se non ci sono più azioni da intraprendere ed il rischio non può
più avere impatto sul progetto, emettere una richiesta di revisione se, allo
scopo di mitigare il rischio, deve essere implementata una modifica al
progetto ed infine di identificare le azioni di mitigazione del rischio.
• esecuzione delle azioni per mitigare il rischio: tramite questo processo
vengono assegnate le azioni di mitigazione del rischio e viene verificato il
successo dell’azione stessa a fine completamento dell’esecuzione.
Si possono quindi riassumere le attività fino a qui descritte per l’integrazione di
OTM in modalità tradizionale all’interno della tabella seguente, utile per poterle
comparare successivamente con le attività da compiere per l’integrazione di OTM
in ottica SaaS, evidenziando così le differenze tra le due logiche.
Tabella 4.2 Attività necessarie per l’integrazione di OTM tradizionale.
Attività Descrizione
Definizione della strategia
Definizione delle linee guida generali per sviluppo e gestione del progetto,dalla pianificazione iniziale fino alla completa implementazione e messa in produzione del sistema.
Analisi e disegno della soluzione
Definizione dei modelli architetturali, sia funzionali che tecnologici e dei processi.
Fase di implementazione
Implementazione e configurazione delle soluzioni identificate.
Transizione al (nuovo) sistema
Trasferimento, all’interno dell’organizzazione del cliente, del sistema completamente configurato, completo di dati, interfacce, personalizzazioni, documentazione, materiale per uso.
Gestione del progetto
Insieme delle attività che definiscono le strategie ed il piano di progetto esploso fin nelle attività più
elementari, determinano le milestone, assegnano i tempi e le risorse, controllano lo stato avanzamento lavori.
