Architettura dell'automazione degli acquisti

Cosa significa realmente automatizzare il procurement?

"L'automazione degli acquisti" copre una gamma di approcci, dall'automazione dei flussi di lavoro basata su regole che instrada una richiesta attraverso una catena di approvazione fissa, alla robotic process automation (RPA) che opera sulle schermate esistenti come farebbe una persona, fino all'automazione intelligente che aggiunge capacità di comprensione dei documenti o logica di abbinamento. La ricerca sottoposta a revisione paritaria descrive l'RPA come l'uso di programmi software low-code per automatizzare processi aziendali ripetitivi e di routine, definendola la tecnologia con la crescita più rapida nella categoria del software aziendale. Nessuno di questi approcci sostituisce il processo procure-to-pay; si inseriscono al suo interno, ciascuno prendendo in carico una fase specifica e ben definita, motivo per cui la domanda utile è quali fasi di questo architettura procure-to-pay sono abbastanza routinarie da essere affidate al software e quali richiedono ancora il giudizio di una persona.

Quali fasi del flusso di lavoro vengono automatizzate per prime e perché?

Quattro passaggi ricorrono ripetutamente come primi candidati all'automazione, poiché ciascuno presenta volumi elevati, è regolato da norme e ha un chiaro esito di superamento/fallimento: instradamento e approvazione delle richieste d'acquisto, la verifica a tre vie tra ordine di acquisto, ricevuta e fattura, l'emissione dell'ordine di acquisto una volta che la richiesta supera l'approvazione e la gestione delle eccezioni delle fatture per le discrepanze segnalate dalla verifica a tre vie. Gli attuali dati di benchmarking sugli acquisti rilevano che l'automazione migliora la capacità di sfruttare gli sconti per volume, consolidare gli acquisti e ridurre i costi e gli errori derivanti dalle attività manuali, che è il caso di considerare questi passaggi come punto di partenza anziché come ambizione totale. Lo stesso lavoro di benchmarking aggiunge una condizione da prendere sul serio: la standardizzazione dei processi aiuta a garantire che la ricerca della velocità non si traduca in un aumento degli errori, quindi l'automazione di un flusso di lavoro degli ordini di acquisto ciò che non è ancora standardizzato fa solo muovere l'incoerenza più velocemente, poiché la standardizzazione deve avvenire prima o contemporaneamente alla costruzione.

Quali controlli deve preservare il percorso automatizzato?

Due principi di controllo si trasferiscono invariati dal procurement manuale, e un flusso di lavoro automatizzato deve esprimerli via software anziché dare per scontato che sopravvivano alla migrazione. Il primo è la separazione dei compiti: le linee guida federali autorevoli in materia di controllo la definiscono come suddividere i compiti e le responsabilità chiave tra persone diverse per ridurre il rischio di errori, usi impropri o frodi, separando le responsabilità di autorizzazione delle transazioni, elaborazione e registrazione delle stesse, revisione delle transazioni e gestione di eventuali asset correlati, in modo che nessun singolo individuo controlli tutti gli aspetti chiave di una transazione o di un evento. Il secondo è l'autorizzazione: le transazioni sono autorizzate ed eseguite esclusivamente da persone che agiscono entro i limiti della loro autorità. In un processo manuale, queste si presentano come persone diverse che gestiscono un ordine di acquisto su scrivanie separate. In uno automatizzato, devono comparire come un modello di ruolo, una configurazione delle soglie di approvazione e una mappa dei permessi che un bot o un motore di flussi di lavoro non può aggirare silenziosamente solo perché tecnicamente può scrivere su ogni campo che riesce a raggiungere.

Come si pianifica una sequenza di implementazione basata prima di tutto sulla governance?

Dove falliscono effettivamente le integrazioni ERP legacy e da dove provengono i silos di dati?

Il punto in cui una piattaforma di automazione degli acquisti si collega all'ERP è dove si concentra in pratica il rischio di governance, ed è anche dove si crea un silo di dati se l'automazione mantiene una propria copia separata dei dati di fornitori, budget o approvazioni anziché trattare l'ERP come l'unica fonte di verità. La guida all'integrazione di un fornitore di automazione definisce chiaramente il rischio di accesso: un connettore a cui è stato concesso un accesso più ampio di quanto richiesto dalla sua funzione può leggere dati che non dovrebbe mai vedere e scrivere su campi che non dovrebbe mai toccare. Un accesso ampio viene solitamente concesso per comodità durante la configurazione, e non perché il flusso di lavoro ne abbia realmente bisogno; vale la pena considerarlo come un elemento della checklist fornita dal vendor da testare, piuttosto che come una semplice affermazione riguardante il prodotto specifico di un determinato fornitore. La stessa guida individua una seconda modalità di errore, più silenziosa: una traccia di audit che copre le azioni umane ma lascia non registrate le decisioni automatizzate è incompleta e genererà rilievi in qualsiasi audit rigoroso. Se un bot approva una fattura, tale decisione richiede la stessa registrazione di quella di una persona: quale logica è stata applicata, quali dati ha utilizzato e qual è stato il risultato.

Perché l'automazione non verificata costa più di quanto fa risparmiare?

La tentazione è di trattare l'automazione come un problema di implementazione: configurare lo strumento, indirizzarlo al processo, rilasciarlo. La ricerca fondamentale sulla verifica dei flussi di lavoro mette in guardia contro il saltare il passaggio intermedio. Studiando i sistemi di gestione dei flussi di lavoro in generale, i ricercatori hanno scoperto che le conseguenze, tuttavia, sono che pochi flussi di lavoro vengono verificati a fondo prima di essere implementati nella pratica, il che spesso si traduce nella necessità di correggere gli errori in modo estemporaneo, spesso a costi proibitivi. Questo risultato precede le odierne piattaforme di automazione low-code di due decenni e il problema di fondo non è scomparso: la specifica di un flusso di lavoro è un frammento di logica, e la logica che non è stata verificata per le scelte, le sequenze e le eccezioni che deve effettivamente gestire fallisce allo stesso modo sia che a eseguirla sia una persona o un bot, solo che il bot fallisce più rapidamente e con volumi maggiori. I linguaggi di specifica dei flussi di lavoro devono supportare la definizione di momenti di scelta, esecuzione sequenziale, parallelismo, sincronizzazione e iterazione proprio perché i processi reali richiedono tutto ciò, e un progetto pilota che testa solo il percorso ideale non ha affatto verificato il flusso di lavoro.