Le PMI e i processi di implementazione di ERP e di soluzioni di Intelligent Automation

 Le PMI e i processi di implementazione di ERP e di soluzioni di Intelligent Automation

Uno degli argomenti attuali di discussione con imprenditori e responsabili delle funzioni Amministrazione Finanza e Controllo (AFC) delle PMI è il significato di evoluzione digitale nelle loro aziende.

Un tema ampio che impone in primis una disamina delle nuove tecnologie disponibili sul mercato, dei processi maggiormente impattati e del cambiamento – in termini di maggiore efficacia – apportato da tali tecnologie sul modello operativo aziendale.

Ma non solo: che richiede dall’altro uno sforzo preliminare di gestione di alcuni fattori di rischio “intrinseci” alla natura di tali progetti.

Nell’affrontare questo argomento, il tema che spesso emerge parlando con chi di recente ha intrapreso un percorso di innovazione, è la difficoltà affrontata nell’impostare e gestire propri i progetti. Mi riferisco in particolare ai progetti di implementazione di ERP (Enterprise Resource Planning) e/o di quelle soluzioni tecnologiche che solitamente vengono implementate a complemento del progetto stesso (esempio: Sistemi di Reporting / Business Intelligence / Data visualization / Intelligent Automation).

I contesti in cui tali difficoltà si manifestano con maggiore frequenza sono le realtà cosiddette “non native digitali” che hanno investito su nuove soluzioni disponibili sul mercato per sostituire il vecchio ERP con l’obiettivo di rendere più efficienti i processi operativi aziendali in essere oppure che sono cresciute rapidamente attraverso acquisizioni esterne e hanno investito in tecnologia per standardizzare processi operativi e omogenizzare il “modo di lavorare” all’interno del Gruppo.

In entrambi i casi, risultati non immediatamente allineati rispetto alle aspettative iniziali di benefici funzionali e operativi, incremento dei costi e dilatazione dei tempi progettuali sono tra le criticità che emergono in maniera ricorrente.

Perché ciò si verifica?

Da un punto di vista squisitamente funzionale e indipendentemente dal contesto di riferimento, dalle soluzioni tecniche adottate e dai partner tecnologici scelti, si possono individuare 6 fattori di rischio comuni e ricorrenti di tali progetti.

Il primo attiene al fatto che queste progettualità non rientrano nelle operatività “business as usual” ma rappresentano momenti di discontinuità “una tantum” in realtà dove, a differenza della grande impresa, vi è una minore abitudine da parte degli attori interni, nel gestire e organizzare progetti che presentano caratteristiche uniche poiché hanno un forte impatto tecnologico, vengono sviluppate su un arco temporale di diversi mesi e comportano l’interazione di molteplici attori – interni in quanto sono progetti “cross funzionali”, esterni in quanto richiedono l’interazione con system integrator /consulenti.

Un secondo fattore di rischio è legato al fatto che ci si focalizza solo sull’aspetto tecnologico, sottovalutando, di conseguenza, alcune implicazioni su altri elementi del modello operativo aziendale: processi, organizzazioni e competenze. Spesso tali aspetti vengono inizialmente tralasciati e presi in considerazione solo nelle fasi terminali del progetto implementativo tecnologico, con il rischio di non affrontare in maniera olistica le opportunità e quindi limitandosi a ri-adattare piuttosto che a trasformare.

Terzo rischio è la mancanza di una chiara identificazione del perimetro progettuale iniziale: cosa rientra nello “standard” e cosa invece è escluso richiedendo in tal caso minime personalizzazioni. Fattore che rappresenta la principale causa di incremento del costo complessivo del progetto a seguito di richieste di personalizzazioni (“Change Request” o semplicemente “CR”) che sorgono durante la fase di “disegno”.  Tale situazione è causata principalmente da due fattori:

  1. asimmetria informativa di base tra le parti: da un lato l’ufficio commerciale del fornitore della soluzione tecnologica e/o del system integrator che effettuerà l’implementazione tecnica, con una conoscenza profonda e dettagliata; dall’altro gli utenti che, pur partecipando alla fase di selezione del fornitore, non hanno spesso l’opportunità e il tempo di approfondire nei dettagli e di maturare una chiara visione degli impatti operativi;
  2. tendenza da parte degli utenti a “riproporre” vecchi modelli lavorativi, vanificando di fatto l’obiettivo finale di implementare un nuovo standard: semplificare, omogenizzare i modi di lavorare e i processi operativi attuali.

Quarto rischio: il system integrator ha bisogno di tempo e attenzione da parte degli utenti per raccogliere i requisiti funzionali, discuterli, impostare ed effettuare i test durante le sessioni di User Acceptance Test (“UAT”) ed erogare il training. Tempo e attenzione che sono sottratti dalla operatività giornaliera e il cui peso viene purtroppo spesso sottovalutato in sede di pianificazione del progetto a cause di inesperienza nell’affrontare tali progettualità.

Ancora.  La carenza di competenze interne di project management e/o le dimensioni limitate delle funzioni IT interne implicano che l’attività di gestione del progetto sia interamente demandata al system integrator, generando un potenziale rischio di sbilanciamento negli equilibri tra le parti in gioco. A monte, troppo spesso si sottovaluta l’importanza delle attività di project management viste quasi come un peso burocratico piuttosto che un driver di valore.

L’ultimo fattore di rischio è legato al linguaggio: gli utenti di business e il system integrator di fondo parlano lingue diverse e i rischi potenziali di incomprensione si amplificano, ovviamente, nel caso di un nuovo progetto con un nuovo team e si evidenziano proprio nelle fasi iniziali (disegno/raccolta requisiti) quando l’interazione è più frequente. Nelle realtà grandi e più strutturate esistono figure specifiche “demand manager” a cui è affidato questo ruolo di raccordo/ponte.

Nell’impostare un progetto di trasformazione digitale, quindi, imprenditori e responsabili delle funzioni AFC delle PMI devono preventivamente pianificare azioni tali da mitigare i rischi “intrinseci” valutando come eventualmente sopperire a carenze interne di competenza/esperienza/tempo i cui effetti possono manifestarsi durante il corso del progetto.

La cura e l’attenzione di tale valutazione deve essere la medesima con la quale viene effettuata la scelta della soluzione tecnologica e del system integrator.

Partecipa alla discussione

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.