La software per i costi di trasporto ha bisogno di un'integrazione ERP o TMS?

Quando si introduce un nuovo software logistico, nasce rapidamente l'assunzione: prima di iniziare dobbiamo integrare il nostro ERP o TMS.

In questo modo un progetto sui costi di trasporto, di natura funzionale, diventa rapidamente un progetto IT. Bisogna definire interfacce, mappare campi dati e pianificare risorse interne. La domanda vera – analizzare i costi di trasporto, controllare le fatture o valutare una gara d'appalto – passa in secondo piano.

Per la software di gestione dei costi di trasporto, tuttavia, un'integrazione diretta ERP o TMS non è automaticamente un prerequisito per iniziare.

Ciò che conta anzitutto è: a quale domanda vogliamo rispondere? E poi: di quali dati abbiamo bisogno per farlo?

ShipCheck può elaborare dati di fatturazione e spedizione anche da PDF, Excel e CSV. In questo modo le aziende possono già lavorare con i dati di trasporto esistenti, senza dover necessariamente costruire prima un'integrazione di sistema completa.

La differenza centrale è: accesso ai dati e integrazione di sistema non sono la stessa cosa.

Il punto di partenza migliore: il caso d'uso invece dell'interfaccia

Invece di partire dall'architettura tecnica, un progetto sui costi di trasporto dovrebbe rispondere a quattro domande: caso d'uso → dati necessari → fonte dati → modalità di trasferimento.

1. Caso d'uso

Cosa deve fare concretamente il software? Per esempio:

• Analizzare i costi di trasporto
• Costruire un reporting KPI
• Controllare le fatture di trasporto
• Confrontare le offerte di gara

Come può presentarsi concretamente un reporting di questo tipo lo mostra l'articolo su software di reporting dei costi di trasporto.

2. Dati necessari

Quali informazioni sono necessarie per questo caso d'uso?

3. Fonte dati

Dove si trovano oggi queste informazioni? Per esempio:

• ERP
• TMS
• Fattura dello spedizioniere
• File del vettore
• Accordo tariffario
• Export Excel

4. Modalità di trasferimento

Come arrivano i dati nella software per i costi di trasporto? Per esempio:

• PDF
• Excel
• CSV
• export periodico
• integrazione tecnica

Questo ordine è importante. Un'API risponde solo a: come arrivano i dati da A a B? Non risponde a: sono i dati giusti per il nostro caso d'uso?

Quali dati servono alla software per i costi di trasporto?

Dipende da cosa si vuole fare con il software.

Analisi dei costi di trasporto

Per un'analisi dei costi di trasporto è necessario poter ricostruire i trasporti e i costi rilevanti. A seconda dell'analisi desiderata, possono essere importanti ad esempio:

• Spedizione
• Data
• Spedizioniere
• Relazione
• Modalità di trasporto
• Peso
• Costi

Con questi dati si possono analizzare tra l'altro i costi per spedizioniere, relazione o modalità di trasporto, nonché i costi per spedizione e l'andamento nel tempo. Quanto granulare possa diventare questa analisi lo descrive l'articolo sull'analisi dei costi di trasporto a livello di spedizione.

Il requisito funzionale è quindi: i dati di trasporto e di costo rilevanti devono essere disponibili e analizzabili. Non: devono necessariamente arrivare tramite un'interfaccia ERP diretta.

Per il controllo fatture si aggiungono i dati tariffari

Nel controllo delle fatture di trasporto la sola storia dei costi non basta. Qui servono due lati:

• Effettivo: cosa è stato fatturato?
• Dovuto: cosa avrebbe dovuto essere addebitato secondo le condizioni concordate?

Per questo il software necessita di:

• Dati di fatturazione
• informazioni di spedizione rilevanti
• tariffe e condizioni concordate

La logica tariffaria viene applicata alla spedizione concreta e successivamente confrontata con la fatturazione. Come le tariffe possano essere rese utilizzabili in modo automatico lo mostra l'articolo digitalizzare le tariffe di trasporto.

La domanda decisiva non è quindi: «Il nostro ERP è integrato?» Ma: «Sono disponibili i dati per calcolare i costi dovuti contrattualmente per la spedizione?»

Per il tendering servono dati storici di spedizione

Anche nelle gare d'appalto per il trasporto non è l'integrazione il fulcro. ShipCheck utilizza i dati di trasporto storici per applicare le nuove offerte degli spedizionieri al profilo di spedizione effettivo.

Per farlo serve uno storico solido dei trasporti rilevanti. Le nuove tariffe possono quindi essere calcolate su queste spedizioni e confrontate tra loro – vedi valutare una gara d'appalto per il trasporto.

Se i volumi futuri si discostano dallo storico, nel calcolo possono confluire anche dati di forecast.

Proprio in una gara d'appalto, quindi, un set di dati storici strutturato può essere più importante di un'interfaccia live permanente.

I dati devono essere disponibili – non necessariamente integrati in tempo reale

Un'azienda spesso possiede già i dati di trasporto rilevanti. Per esempio come:

• export Excel dal TMS
• file CSV dall'ERP
• fattura PDF dello spedizioniere
• file di fatturazione strutturato
• elenco storico delle spedizioni
• PDF o Excel delle tariffe

Questi dati possono già costituire una base sufficiente per un caso d'uso concreto. Come ricavare analisi da tali export lo descrive l'articolo analizzare fatture di trasporto e dati di spedizione.

La domanda dovrebbe quindi essere prima: «Possiamo fornire in modo affidabile i dati necessari?» e solo dopo: «Dobbiamo costruire per questo un'interfaccia diretta?»

Quando si può iniziare senza un'integrazione ERP o TMS diretta?

Un avvio senza interfaccia diretta è realistico soprattutto quando i dati necessari possono già essere esportati o forniti regolarmente.

Esempio: reporting dei costi di trasporto

Un export mensile contiene:

• Spedizione
• Data
• Spedizioniere
• Relazione
• Modalità di trasporto
• Peso
• Costi

Con questi dati si possono già rispondere a domande come: come evolvono i nostri costi di trasporto? Quanto costa ogni spedizione? Quali spedizionieri generano quale quota di costo? Quali relazioni stanno cambiando?

Quali indicatori siano utili a questo scopo lo mostra l'articolo sui KPI dei costi di trasporto. Per questo non è necessario costruire prima un'interfaccia individuale.

Esempio: controllo delle fatture di trasporto

Sono disponibili i dati di fatturazione, le informazioni di spedizione rilevanti e le tariffe concordate. A questo punto si può verificare: cosa è stato fatturato? rispetto a: cosa avrebbe dovuto essere addebitato secondo tariffa?

Anche qui il requisito funzionale è la disponibilità dei dati, non l'integrazione. Le deviazioni tipiche sono descritte in errori sistematici nelle fatture di trasporto.

Esempio: gara d'appalto per il trasporto

I dati storici di spedizione sono disponibili come export strutturato. I nuovi prezzi dei fornitori possono essere applicati a questa struttura di trasporto reale. Un'integrazione permanente non è necessariamente il primo passo.

Quando diventa opportuna un'integrazione ERP o TMS?

Il fatto che un'integrazione non sia sempre necessaria per iniziare non significa che non abbia valore. Diventa particolarmente interessante quando un processo di gestione dei costi di trasporto viene gestito in modo continuativo e regolare.

Quando si aggiungono continuamente nuovi dati

Per un'analisi di gara una tantum può bastare un export storico. Nel controllo continuativo dei costi di trasporto, invece, si aggiungono costantemente nuove spedizioni, fatture e voci di costo.

In questo caso un approvvigionamento dati maggiormente automatizzato può ridurre l'onere manuale ricorrente.

Quando confluiscono più fonti dati

Le aziende con più società, sedi, sistemi ERP, sistemi TMS o spedizionieri hanno spesso un panorama dati frammentato. Più spesso devono essere elaborati gli stessi flussi di dati, più conviene una modalità di trasferimento standardizzata.

Quando servono informazioni operative aggiuntive

Le fatture forniscono soprattutto informazioni di costo. Per alcune analisi possono essere rilevanti dati di spedizione o aziendali aggiuntivi provenienti da ERP e TMS. Quali campi siano effettivamente necessari dipende però dal caso d'uso.

Quando si vogliono ridurre i trasferimenti manuali

Un'importazione periodica di file può essere del tutto sufficiente per alcune aziende. Altre vogliono automatizzare maggiormente questo passaggio. In tal caso l'integrazione è un'ottimizzazione di processo, non necessariamente il prerequisito per poter iniziare a fare gestione dei costi di trasporto.

L'integrazione non sostituisce la qualità dei dati

Un'interfaccia tecnica non risolve automaticamente un problema di dati a livello funzionale. Se ad esempio:

• i vettori sono denominati in modo incoerente,
• mancano le relazioni,
• le voci di costo non possono essere attribuite correttamente,
• mancano caratteristiche di spedizione rilevanti,

un trasferimento automatico non rende automaticamente queste informazioni analiticamente utilizzabili.

Un'interfaccia risolve la domanda: come trasferiamo i dati? La qualità dei dati risolve la domanda: possiamo analizzare questi dati in modo significativo?

Per l'analisi dei costi di trasporto, quindi, spesso non è decisivo il trasferimento tecnicamente più elegante, bensì la completezza e l'utilizzabilità del set di dati.

Dati di fatturazione, dati tariffari e dati ERP/TMS svolgono compiti diversi

Una distinzione utile è la seguente:

Da qui derivano diverse combinazioni:

• Fattura + tariffa + dati di spedizione = controllo delle fatture di trasporto
• Dati di spedizione + costi = analisi dei costi di trasporto
• Dati storici di spedizione + nuove tariffe = tendering

L'integrazione tecnica è solo una possibile modalità di trasferimento per questi dati.

La software per i costi di trasporto deve sostituire un TMS?

No. Un TMS e una software specializzata nei costi di trasporto non svolgono necessariamente lo stesso compito. Un TMS può gestire i processi operativi di trasporto e i relativi dati di spedizione.

ShipCheck si concentra sull'utilizzo economico dei dati di trasporto, delle fatture e delle informazioni tariffarie per l'analisi dei costi di trasporto, il reporting, il controllo contrattuale delle fatture e il tendering.

Il TMS esistente può così rimanere una fonte dati importante. L'introduzione di una software per i costi di trasporto non significa quindi automaticamente che il sistema di gestione dei trasporti esistente debba essere sostituito.

E quale ruolo gioca l'ERP?

Anche un ERP può fornire informazioni importanti. Ma i dati rilevanti per la gestione dei costi di trasporto spesso non si trovano solo lì. A seconda dell'azienda, le informazioni si trovano ad esempio distribuite in:

• ERP: dati di ordine e dati aziendali
• TMS: dati operativi di trasporto
• Fattura dello spedizioniere: costi fatturati
• Accordo tariffario: logica dei prezzi concordata

La sfida consiste quindi spesso nel rendere utilizzabili congiuntamente le informazioni rilevanti provenienti da più fonti per un caso d'uso concreto sui costi di trasporto.

Come dovrebbe partire un progetto sui costi di trasporto

Passo 1: definire il caso d'uso

A quale domanda deve trovare risposta il progetto? Per esempio: dove aumentano i nostri costi di trasporto? Le nostre fatture vengono addebitate correttamente secondo tariffa? Quale offerta di spedizioniere si adatta economicamente al nostro profilo di spedizione?

Passo 2: determinare i dati necessari

Quali informazioni richiede esattamente questo caso d'uso?

Passo 3: identificare le fonti dati

Dove si trovano oggi queste informazioni?

Passo 4: scegliere la modalità di trasferimento più semplice e opportuna

È possibile iniziare con PDF, Excel, CSV o un export già esistente?

Passo 5: ottimizzare l'approvvigionamento dati ricorrente

Se il processo viene gestito in modo continuativo, si può successivamente valutare quale trasferimento convenga automatizzare.

L'architettura risultante è quindi: caso d'uso → dati → fonte dati → modalità di trasferimento. E non: integrazione → dati → prima o poi un caso d'uso.

Come lavora ShipCheck con fonti dati diverse

ShipCheck può elaborare dati di fatturazione e spedizione anche da PDF, Excel e CSV e renderli analizzabili in modo strutturato. Questa base dati può quindi essere utilizzata per più processi di gestione dei costi di trasporto.

• Analisi dei costi di trasporto: analizzare i costi di trasporto secondo diverse dimensioni e rendere visibili gli andamenti.
• Controllo fatture: verificare le voci fatturate rispetto alle tariffe e condizioni registrate.
• Tendering: calcolare i trasporti storici con nuovi prezzi dei fornitori e scenari.

Il principio centrale è quindi: la gestione dei costi di trasporto richiede i dati giusti. Non richiede necessariamente, fin dal primo giorno, un'integrazione ERP o TMS completa.

Conclusione: prima risolvere il caso d'uso, poi ottimizzare l'approvvigionamento dati

Un'integrazione ERP o TMS può essere molto utile per la software di gestione dei costi di trasporto. Ma non dovrebbe essere considerata automaticamente un prerequisito per l'avvio del progetto.

Se i dati di fatturazione, spedizione e tariffa sono già disponibili tramite PDF, Excel, CSV o altri export utilizzabili, l'analisi, l'audit o il tendering possono già basarsi su di essi a seconda del caso d'uso.

L'ordine più sensato è: definire il caso d'uso → determinare i dati → identificare la fonte dati → scegliere la modalità di trasferimento adatta → automatizzare ulteriormente l'approvvigionamento dati se necessario.

In questo modo un problema funzionale sui costi di trasporto non diventa inutilmente, in primo luogo, un ampio progetto IT. La domanda centrale non è: «Il nostro ERP è già integrato?» Ma: «Abbiamo i dati giusti per rispondere alla nostra domanda sui costi di trasporto?»

Uno sguardo ai modelli di abbonamento mostra come possa apparire un avvio senza progetto IT.