Oggi anche le organizzazioni gestionalmente più avanzate hanno molte difficoltà a fare buone scelte in termini di fornitori di soluzioni software di procurement.
Generalmente accade che, saggiamente, nel breve termine si scelgono soluzioni best-of-breed che consentono di avere ROI in tempi rapidi, piuttosto che avere la pazienza di implementare un sistema ERP completo, con tempi lunghi, per ottenere finalmente valore.
Alla fine però il rischio è di collezionare applicazioni a supporto dei processi di acquisto, ottenendo una “torre di Babele” la cui gestione diventa però molto difficoltosa. È questo il punto da cui parte Pierre Mitchell, analista di Spend Matters nell’ambito procurement, in un articolo che pone l’attenzione appunto su come oggi le organizzazioni prendono le decisioni per quanto riguarda i loro fornitori.
Per evitare queste ricadute un primo fattore chiave di successo può essere aiutare le organizzazioni a pensare come dovrebbe essere strutturata un’architettura di procurement efficace. Nello specifico, Mitchell usa a tal proposito il termine “architettura dell’informazione”, invece di “architettura della tecnologia”, perché non si tratta semplicemente di aspetti tecnici di basso livello – come decidere in base alle funzionalità che garantisce la soluzione ERP di un fornitore piuttosto che quella di un altro a supporto dei vari processi del ciclo di acquisto (sourcing, gestione dei contratti, acquisti, pagamenti, ecc).
Piuttosto, si tratta di creare un ambiente integrato dove riescano a convivere in modo coerente diversi approcci, diverse tipologie di applicazioni e fornitori, così da poterli gestire facilmente all’interno di un unico framework. Tutto questo per quanto possa sembrare abbastanza facile sulla carta, non è poi così immediato nella pratica.
Prendiamo per esempio l’area dashboard/scorecard sia per la valutazione degli acquisti che dei fornitori. Emerge che non sono solo gli analytics a influenzare il risultato, ma dipende anche dal workflow che è alla base della definizione dei KPI e dei target, e del collegamento dinamico tra questi e i master data, ecc. E anche per gli stessi analytics la scelta è molto ampia, con strumenti che possono andare al di là di data warehouse, cubi e OLAP.
Altro problema poi da affrontare sarà quello della diversa terminologia utilizzata dai fornitori e dalle organizzazioni. Ma la criticità principale è che questa della scelta dei fornitori è una competenza che poche organizzazioni hanno. Se si ha come obiettivo puntare alla progettazione di una “world-class procurement information architecture” – basata su una un’architettura software adatta a supportare l’uso di servizi Web in grado di garantire l’interoperabilità tra i diversi sistemi da una suite di procurement di ultima generazione – è fondamentale parlare una lingua comune ed essere il più precisi possibile.
Ad esempio, oltre al termine generico “portali”, pensare anche a parole come “suite” o “architettura”, “applicazioni composite” o il termine più diffuso di tutti, ovvero “piattaforma”. A supportare le organizzazioni in questo delicato passaggio – a garanzia di scelte di lungo termine in grado di supportare efficacemente i processi di acquisto – sarà fondamentale costituire un vero e proprio team di progettazione.
