Search

Smart Digital Controller

Machine Learning Reply aiuta le società nell'automatizzare il Controllo di Gestione

Il Problema

È noto che il controllo di gestione di una azienda cresce esponenzialmente in difficoltà all’aumentare delle dimensioni dell’azienda stessa. Con l’incremento del numero di commesse attive è sempre più difficile individuare i punti di criticità in maniera tempestiva, prima che diventino problematiche di impatto irreversibile. Ancora più difficile è, una volta individuato il punto di criticità, sviscerarne le cause e intraprendere le corrette azioni per ripristinare l’andamento normale di un progetto.

Se alziamo ancora di una tacca l’asticella degli obiettivi in ambito di Business Management di maggior impatto sarebbe l’utilizzo di uno strumento in grado di anticipare l’insorgere di queste anomalie in modo da minimizzare e in alcuni casi azzerare gli eventuali effetti negativi.

La Soluzione

Machine Learning Reply ha risposto a queste esigenze sviluppando il Digital Controller Reporting, uno strumento in grado di tenere traccia di tutte le commesse intraprese dalla azienda e di ciascuna di esse, attraverso il calcolo di specifici KPI differenziati per aree tematiche di interesse, è in grado di portare a galla le criticità presenti. In questo modo dalla massa totale dei progetti in atto è possibile filtrare quelle poche posizioni che richiedono attenzione. Di queste viene poi specificato e mostrato all'utente l’ambito per il quale è stato sollevato un warning in modo tale che l’utente possa intraprendere l’azione correttiva migliore per ripristinarne l’andamento o notificare al sistema, tramite inserimento di note, casi per il quale il warning non deve essere sollevato.

Tramite note inserite in linguaggio naturale è possibile infatti dare un feedback sui warnings sollevati specificano quali posizioni siano da considerare non a rischio nonostante KPI anomali o viceversa, quali commesse debbano essere monitorate nel dettaglio anche se apparentemente non presentano punti critici.

Modelli predittivi di Intelligenza artificiale permettono inoltre di prevedere quali posizioni hanno la maggiore probabilità di sollevare determinati warning nel prossimo futuro a partire dall’andamento registrato fino al momento corrente. In questo modo si ha la possibilità di agire in anticipo prima dell'insorgere di problematiche più critiche.

Ambiti di Monitoraggio

Il DCR è stato realizzato per monitorare contemporaneamente moltissimi aspetti di una commessa che si possono raggruppare in due macrofamigle.

Financial
Nel report Financial del DCR viene condensata tutta l’informazione di una commessa legata al ciclo attivo. Ordini, fatturazioni, incassi e scadenze. Per ciascuno di questi aspetti si calcolano specifici KPI e warning. Particolare attenzione viene data ai ritardi nelle fatturazioni e nei pagamenti. Una dashboard permette di monitorare in maniera aggregata tra le varie commesse l’andamento suddiviso per cliente o per business unit, anche rispetto ai valori nei mesi precedenti.

Delivery
Nel report Delivery vengono monitorate le commesse dal punto di vista del rapporto costi ricavi e dell’effort richiesto. Queste metriche vengono scomposte in costi e ricavi interni, esterni e di subappalto. Per quanto riguarda l’analisi dell’effort, un report apposito, confronta i giorni consuntivati dalle risorse in un determinato lasso di tempo (ad esempio mensile) con ciò che era stato pianificato per lo stesso, notificando qualora questi si discostino troppo tra di loro. Infine di tutte queste metriche si tiene traccia nel tempo permettendo così di valutare l’andamento del progetto durante tutto il suo arco vitale.

Key Performance Indicator

A seconda dell’ambito preso in esame differenti insiemi di KPI sono stati definiti.

Financial

  • Aging: In caso di mancanza di ordini o di fatturazione per una commessa è necessario definire un’indicazione dell’entità di questa scopertura (separatamente per ciascuno di questi aspetti). A valle di una analisi di utilizzo che coinvolgeva esperti di dominio nel project management abbiamo definito l’AGING di SCOPERTURA, un KPI equivalente al numero di mesi in cui la commessa è stata lavorata (ovvero in cui effettivamente sono state spese delle risorse) senza però avere un corrispondente ordine/fatturazione di entità tale da rispecchiare l’effort impiegato.
  • Defer Il KPI Defer è strettamente legato alle annotazioni prese nella sezione note di ogni commessa. Queste annotazioni vengono interpretate da un modello di Natural Language Processing che determina se nella nota è presente o meno un concetto di procrastinazione dell’arrivo di ordini/fatturazioni (es: la nota riporta la frase “Ordine in arrivo a dicembre”). Se questo tipo di note si sussegue spesso, con riferimenti temporali sempre più in là nel tempo senza che effettivamente arrivino gli ordini o le fatturazioni promesse, il flag Defer si solleva evidenziando la presenza di previsioni di copertura poco affidabili.
Delivery
  • C/R: Rapporto costi fratto ricavi della commessa. Questo KPI viene calcolato sia globalmente sul progetto, sia tenendo conto solo dei costi esterni, sia tenendo conto solo dei subappalti. Inoltre in caso di subappalti viene calcolato separatamente per ogni fornitore a cui la sottocommessa è stata subappaltata anche parzialmente. Questo KPI non viene valutato unicamente come dato isolato ma si valuta anche il suo andamento nel corso dei mesi, evidenziando variazioni troppo repentine sia in crescita che in diminuzione, spesso sintomo di una cattiva gestione. Il C/R viene inoltre calcolato sia tenendo conto di tutto l’arco di vita del progetto, sia considerando solo costi e ricavi maturati nell’anno in corso.
  • Growth: Da questo KPI viene valutato se al crescere dell’impiego di risorse su una commessa corrisponde un aumento dei ricavi. È calcolato come la differenza tra la crescita relativa di ricavi e la crescita relativa di giorni consuntivati rispetto al mese precedente. Anche di questo KPI si tiene traccia nell’arco dei mesi per valutarne l’andamento.
  • Valore Mese Uomo: Rapporto tra i ricavi della commessa maturati fino alla data corrente e il numero di giorni consuntivati fino alla data corrente, moltiplicato per i giorni lavorativi nel mese. Questo indicatore misura l’efficacia di una singola risorsa nel produrre ricavi nell’arco di un mese lavorativo. Anche di questo KPI si tiene traccia nell’arco dei mesi per valutarne l’andamento
  • Planned Effort Percentage: Data una pianificazione di distribuzione delle risorse, questo KPI permette di valutare quanto questa venga rispettata. Questo KPI si basa solamente sul numero di giorni consuntivati rapportandolo al numero di giorni previsti dall’inizio del mese fino al giorno corrente. Se il rapporto è maggiore di 1 significa che si stanno impiegando più risorse del previsto, viceversa se minore di 1 potrebbe essere sintomo di una mancanza di risorse da allocare sul progetto.

Machine Learning

Calcolo dei threshold
Punto focale del Digital Controller Reporting, dopo aver definito i KPI descritti sopra è determinare per quali valori di tali KPI si rende necessari accendere una spia d’allarme che consenta all’utente di focalizzare l’attenzione dove realmente esiste un problema da gestire. Attraverso un modello di Anomaly Detection vengono quindi identificati, per ciascuno KPI dei valori di soglia per i quali, se superati, è possibile identificare la commessa specifica come anomala e degna di attenzione.

Elaborazione delle note
Come accennato prima a ciascuna posizione è possibile associare una nota che descriva o spieghi la situazione attuale e le eventuali anomalie. Un modello di Natural Language Processing elabora questa nota ed è in grado di identificare l’intento in essa contenuto, nonché entità a cui si fa riferimento nella nota. In questo modo, attraverso le note, è possibile ad esempio dire allo strumento:

  • Quali posizioni non devono essere evidenziate nonostante la presenza di KPI anomali.
  • Quali posizioni devono essere monitorate con attenzione anche se presentano KPI nella norma.
  • Periodi temporali durante i quali è possibile ignorare alcuni warning.
  • Riferimenti ad altre commesse.
  • Importi e valori da modificare nei dati estratti dal tool.

Benefici e Risultati

Il DCR si è spesso rivelato di enorme utilità sotto vari aspetti. Prima di tutto è uno strumento in grado di fare risparmiare tempo durante le attività di controllo di gestione in quanto i problemi presenti o che si potrebbero presentare all’interno di un progetto vengono immediatamente e automaticamente evidenziati, senza la necessità di interpellare project manager o controller intermediari al fine di isolare quelle commesse problematiche. Anche la scelta delle operazioni da effettuare una volta individuato il problema è facilitata dalla numerosa quantità di indicatori che permettono una analisi a 360 gradi del progetto. La componente di machine learning rende lo strumento estremamente adattivo alla singola applicazione su cui viene installato e la gestione degli warning tramite l’interpretazione del linguaggio naturale delle note consente un utilizzo facile e che non richiede alcun tipo di conoscenza tecnica particolare da parte dell’utente. Infine, il vantaggio di uno strumento come il DCR è che avendo sempre a disposizione l’analisi delle commesse attive nel loro insieme è possibile effettuare anche elaborazioni aggregate per monitorare sugli stessi parametri l’andamento della business unit o anche dell’intera company nell’arco del tempo.


Discussione con il business
La prima fase per la messa in piedi del DCR è sempre un incontro con il business, ovvero coloro che saranno gli utilizzatori finali dello strumento. In questa sede vengono discussi più nel dettaglio e eventualmente modificati o aggiunti i KPI che andranno comporre i report, nonché tutte le informazioni utili di contorno per descrivere le posizioni che potrebbero essere evidenziate dal DCR.
Definizione pipeline di ingestion
La seconda fase, che coinvolgerà degli aspetti più tecnici della situazione as-is del cliente, riguarda l’individuazione e l’analisi delle fonti dato preesistenti a disposizione. Si procederà quindi alla definizione di un flusso dati e alle procedure di ETL per accentrare, normalizzare e pulire tutte le informazioni che dovranno poi essere elaborate e esposte nel DCR.
Sviluppo backend e frontend
Una volta realizzato un flusso dati near real time, vengono implementate sia le procedure per il calcolo dei KPI concordati, sia la componente relativa ai modelli di machine learning e alla loro gestione (training aggiornamento automatico, deploy, etc..). Parallelamente si implementa anche una prima versione di dashboard interattiva dove sarà possibile visualizzare i KPI e le informazioni sopra citati, nonché introdurre le note date dall’utente.
Tuning dei modelli e finitura della dashboard
La fase finale dell’industrializzazione contempla un ciclo di user acceptance tests atti a validare il corretto funzionamento dei modelli e la fruibilità della dashboard, fino al raggiungimento di una versione adatta e personalizzata sul singolo cliente.