Dopo aver affrontato problematiche propedeutiche relative ai prodotti, come l’approvvigionamento delle schede tecniche o l’acquisizione del catalogo fornitore, un livello ulteriore di lavoro ed analisi è quello della scelta del fornitore “migliore” per un articolo sufficientemente identificato. Precondizione di tutto il processo che illustrerò è che il sistema non consenta prodotti duplicati o perlomeno lo faccia non di default ma per giustificate esigenze di marketing o per errore dovuto ad una errata identificazione del prodotto.

Qualità della base dati di partenza

Un fattore determinante è nella qualità delle informazioni ottenute dai cataloghi prodotti da fornitori in quanto alla base di questa funzionalità c’è l’identificazione corretta del prodotto che andremo a far competere. Purtroppo poiché errare è umano in informatica l’errore, quando c’è, può andare oltre l’umano devastando 🙂 Si pensi ad un baco in un processo automatico che tratta una mole di dati significativi e al fatto che la scoperta possa avvenire non tempestivamente. L’errore potrebbe nascondersi dietro una evenienza imprevedibile in fase di analisi.

Per mia esperienza, purtroppo, avendo a che fare con informazioni provenienti da fornitori diversi non solo per articoli trattati ma per qualità del servizio prestato non si finirà mai di trovare eccezioni o problemi al trattamento di tali dati, e gli errori li fanno anche fornitori che operano a livello internazionale.

Identificazione del prodotto

L’identificazione di un prodotto (unique product identifiers, Global Trade Item Numbers (GTINs)) non è una cosa banale. In base alla mia esperienza un prodotto può esser identificato o mediante il Brand (marca) + ProducerCode (codice del produttore\fabbricante ovvero il Manufacturer Part Number (MPN)) o mediante l’EAN.

Mentre l’EAN resta un numero a 13 cifre univoco, quello che io ho chiamato ProducerCode, purtroppo, essendo alfanumerico e includendo caratteri extra lettere/numeri, capita che i fornitori spesso apportino modifiche rimuovendo o aggiungendo caratteri producendo l’effetto di far perdere traccia del prodotto fornitoci e quindi far fallire la competizione per il prodotto migliore. Altre volte queste informazioni identificative, che ci forniscono, sono errate perché si riferiscono ad altri prodotti o semplicemente rendono irrintracciabile il prodotto, altro caso è che uno dei due tra EAN e ProducerCode siano corretti mentre l’altro si riferisca ad altro prodotto quindi nel  momento in cui si deve far concorrere a seconda di cosa si sceglierà come codice si avrà un risultato diverso.
Un altro errore tipico è quello per cui un fornitore associa un nome Brand errato, qualcuno toglie gli spazi vuoti altri eliminano caratteri speciali altri usano un nome di Brand non aggiornato, etc. Ci sono fornitori di rilevanza internazionale come Ingram Micro che abusano del Brand associato ad un prodotto per eseguire un ulteriore livello di classificazione.

A causa di questi errori gli effetti risultanti potranno esser dirompenti, immaginiamo che l’EAN corretto per un televisore sia associato ad un aspirapolvere il risultato sarà che il prodotto vincerà la competizione in base al prezzo e ci si ritroverà a commerciare on-line, televisori molto ma molto sottocosto.

Inoltre se un fornitore corregge un identificativo di prodotto il nostro processo, che effettuerà l’acquisizione del catalogo, dovrà essere predisposto per tale correzione consentendo così la successiva giusta competizione.

Nel caso specifico trattato da me, nella identificazione del prodotto, oltre a considerare

si è aggiunto anche il tipo di garanzia associata che potrà essere: garanzia Italia o garanzia Europa. Probabilmente questo parametro lascia il tempo che trova ma oggi che scrivo l’articolo è importante visto che i prodotti a garanzia Europa costano meno avendo un servizio inferiore. Quindi l’identificazione s’è eseguita con:

Il caso di Amazon

Questa è la strada intrapresa nel caso oggetto del mio lavoro ma occorre dire che ci sono aziende come Amazon che per l’identificazione dei prodotti riforniti dai vari venditori fanno riferimento praticamente ad un sol codice che può essere l’EAN (l’ISBN per i libri e l’MPN solo per i prodotti artigianali). L’EAN è comunque obbligatorio. Il rivenditore che si avvale del marketplace di Amazon per vendere il propri prodotti non deve inviare le schede dei propri prodotti ma bensì ad esempio l’EAN e i restanti parametri di vendita per ciascun articolo, sarà Amazon ad identificare il prodotto e pubblicare in automatico le sue caratteristiche. Ma anche l’EAN può essere errato correndo il rischio di vendere un prodotto che da noi in realtà è un altro quindi si perderà l’account e la possibilità di usufruire di tale marketplace ricevendone di ritorno una prestazione \feedback negativo. [Amazon usa anche l’ASIN (Amazon Standard Identification Number) per riferirsi ai prodotti questo è un codice interno ma che è esposto anche nella scheda prodotto col nome di “codice identificativo”].

Parametri del gioco

Far concorrere più fornitori per stesse categorie di prodotti ha come scopo primario quello di soddisfare la clientela al dettaglio per poter aumentare le vendite quindi un primo parametro da considerare non può che essere il prezzo unitario, ma non è l’unico per cui schematizzando potremmo considerare:

• il prezzo unitario;
• la disponibilità numerica del prodotto fornito, potremmo ignorare il fatto che esistano delle quantità in arrivo;
• i tempi di consegna della merce che il fornitore ci garantisce. Questo potrebbe essere un parametro non variabile ma fisso visto che molti fornitori non forniscono una indicazione puntuali, in alcuni casi potremmo disporre di fornitori B2B in questi casi è meglio “tenersi larghi”;
• l’affidabilità complessiva del fornitore.

Tutti questi parametri potranno esser mandati in input ad una funzione che per ciascuno di essi assegnerà un “peso” così che tra tutti si possa dare maggiore rilievo al prezzo piuttosto che alla disponibilità etc. In questa funzione che assegnerà un punteggio al prodotto fornito da un fornitore possiamo pensare che il prezzo concorra nella misura del 35%, la disponibilità del 25%, tempi di consegna del 30% e l’attendibilità del fornitore del 10%, e che a punteggio maggiore corrisponda ad un fornitore peggiore. Tale punteggio potremmo chiamarlo “punteggio di handicap”.

Implementazione della scelta del fornitore migliore

In questo scenario avremo da una parte tutti gli articoli di ogni fornitore sincronizzato e dell’altra tutti gli articoli pubblicati, per ciascun articolo pubblicato dovremmo scegliere il fornitore migliore ovvero che avrà totalizzato un punteggio di handicap minore.
La scelta del fornitore di un articolo on-line comporterà la pubblicazione di informazioni quali: prezzo a cui aggiungere il mark-up, disponibilità del prodotto e giorni di consegna.
Questo algoritmo influenzerà certamente le scelte di pubblicazione degli articoli in quanto il passaggio dal fornitore alla pubblicazione in vetrina non è diretto ma ci sarà una prima verifica sulla presenza dell’articolo on-line per evitare duplicati indesiderati.

Per la soluzione che ho concretamente implementato, l’algoritmo produce i risultati su una tabella che in realtà già esisteva in cui per ogni articolo on-line ci sono tanti record quanti sono i fornitori attivi che lo riforniscono, uno solo però risulterà eletto. Questa tabella è quella su cui lavorano altri processi che producendo su un suo campo il prezzo finale ovvero quello a cui s’è poi aggiunto il mark-up. L’uso di questa tabella risponde anche all’esigenza di avere aggiornati i prezzi ad ogni richiesta della vetrina on-line a seguito di un utente che interroga la base dati. Avere queste informazioni su tutti i fornitori sarà utile perché così saranno presentabili sulla scheda prodotto del back office (nel mio caso ho implementato una vista separata in modo che si potessero vedere anche gli articoli che provengono dal catalogo fornitori senza alcun vincolo di garanzia).
Questa tabella però dovrà esser “scremata” ovvero ripulita delle informazioni obsolete ovvero che non si aggiornano più dopo un intervallo prefissato. Infatti poniamo il caso che un fornitore non ci fornisca più un determinato prodotto (discontinuato) che invece un’altro continua ad rivendere, se non interverrà un processo di pulizia questo continuerà ad esistere in tabella anche se non disponibile.

Sul versante che è a monte ovvero degli articoli resi disponibili dai fornitori, la loro selezione in input al processo oggetto di questo articolo,  è stata fatta tenendo conto:

• l’articolo deve avere un rappresentante on-line del quale cioè son disponibili tutte le informazioni richieste e che quindi già in passato è stato pubblicato. Se si è trovato un articolo che ha una origine diversa (perché di diverso fornitore originario) di quello pubblicato e rappresentativo, questo dovrà esser marcato (flag sulla tabella di interfaccia tra i cataloghi sincronizzati e quanto assimilato già dal nostro sistema) per evitare che venga preso in considerazione dal processo che si occupa della messa on-line\pubblicazione dei nuovi articoli;
• l’articolo può anche non esser disponibile. Attenzione però che questo non sia in realtà dismesso dal fornitore infatti alcuni fornitori semplicemente non passano più l’articolo altri invece lo passano ma con un flag indicante che non è più trattato;
• devono essere anche articoli di cui abbiamo i requisiti minimi ovvero almeno, ad esempio, l’EAN o ProducerCode + Brand e che abbiano anche la tipologia di garanzia;
• non deve avere duplicati all’interno dello stesso catalogo fornitore. Ebbene sì capita anche questo e con fornitori insospettabili per attendibilità e cioè che sullo stesso file catalogo da sincronizzare ci siano 2 o più articoli duplicati o che abbiano diverso ProducerCode ma stesso EAN. In questo caso il buon senso vuole che si scelga l’articolo più disponibile, con il prezzo migliore e più recente.

Sul versante a valle invece occorrerà fare attenzione a non pubblicare mai prodotti di fornitori che hanno disponibilità zero, questo è superabile semplicemente fornendo il massimo punteggio di handicap mentre qualora l’articolo non sia disponibile nell’intero gruppo di fornitori concorrenti questo non dovrà essere visualizzabile on-line quindi la circostanza dovrà esser gestita altrove.

Alcune strane varianti del gioco

Sempre nella implementazione c’è stata anche una variante che potrei chiamare la “scelta dell’arena dei competitori”… Mi è stato chiesto infatti di creare dei gruppi in cui si possano scegliere i fornitori da mettere in concorrenza per cui uno stesso articolo\prodotto può esser duplicato ma solo perché fa parte di un gruppo diverso. L’esistenza di almeno un gruppo era già sottintesa nel paragrafo in cui ho parlato dell’identificazione del prodotto in cui aggiungevo anche la garanzia tra le chiavi e ciò per ottenere il gruppo degli articoli a garanzia europea e quelli a garanzia italia.

Precauzioni

Come già evidenziato spesso accade che la fonte di informazioni su cui si basa l’algoritmo del migliore fornitore prodotto sia inquinata da errori. Oltre già citato errare di identificazione prodotto, c’è quello dell’assegnazione di un prezzo errato. Un possibile rimedio è quello di verificare il prezzo all’interno del gruppo di fornitori dello stesso articolo facendo scattare un errore qualora il prezzo del prodotto considerato sia inferiore ad una certa percentuale che è un parametro gestibile dal back office.

Licenza con diritto di citazione (art. 70, Legge 22 aprile 1941 n. 633)
Prego chiunque usufruirà di questo articolo di citarmi o inserire un link al sito.
Grazie.