GESTIONE FATTURAZIONE ELETTRONICA 1 Analisi situazione “As-Is”

Dal 1° gennaio 2019 viene introdotto l’obbligo di fatturazione elettronica per tutti gli enti emittenti di fatture. Nel caso del Gruppo Canarbino questo fatto porta ad inevitabili cambiamenti sia a livello di processo che di architettura del software ARGON attraverso aggiornamenti obbligatori rilasciati dalla società Alpha. Tutte le fatture emesse per i clienti finali aziendali sono accompagnate dalla relativa fattura in formato elettronico (Xml) e seguono un iter di controllo formale della fattura stessa.

A livello di processi si rende necessario implementare attività tese soprattutto a far dialogare i sistemi aziendali interni con il portale SdI dell’Agenzia delle Entrate e altri soggetti interessati, e ad effettuare le opportune modifiche in caso di esito negativo della fattura elettronica.

A livello software vengono implementati, attraverso il rilascio di aggiornamenti da parte della Soc. Alpha, le nuove funzionalità e le sezioni agevolano l’operatore nella gestione di eventuali anomalie ed errori. Tuttavia, nonostante le migliorie apportate per adeguare il software alla gestione della fatturazione elettronica, il processo risulta comunque macchinoso e poco snello, con attività ripetitive senza valore aggiunto per il processo.

In figura 23 viene raffigurato la schermata di ricerca dei documenti presenti a sistema. Per la ricerca degli esiti delle fatture elettroniche l’operatore deve selezionare in una schermata molteplici opzioni per raggiungere una visione completa dello stato delle fatture. Con l’aggravante che non è possibile risalire al tipo di errore.

Il processo gestionale sul software Argon prevede i seguenti passaggi: all’emissione di una o di un gruppo di fatture sul gestionale, allo stesso tempo viene emessa una fattura elettronica, che richiede la firma digitale del responsabile della Società di Vendita emittente (o del suo intermediario). La fattura elettronica è immessa nel Sistema di Interscambio che, dopo i controlli tecnici automatici, in presenza di esito positivo, viene inviata al destinatario. In caso di esito negativo la fattura viene scartata e rinviata alla SdV.

Il processo della fatturazione elettronica nel Gruppo Canarbino viene gestito come mostrato in figura 24.

Come evidenziato dalla mappatura, il processo puo essere suddiviso in 4 sotto processi:

1. emissione, invio fatture al Sistema di Interscambio; 2. ricezione esito e verifica Errori;

3. correzione Errore;

4. riemissione fattura/e corrette.

Per definire le criticità del processo in esame, il team progetto ha considerato l’idea di usare come driver il grado di automazione delle attività che lo compongono. Pertanto, da un confronto congiunto tra i componenti del team di progetto e i responsabili di reparto, è emerso che:

- i sotto-processi di Correzione Errore e di Riemissione Fattura risultano verosimilmente poco automazzabili in quanto per completarli è necessario l’attività operativa in senso stretto di un utente per effettuare le attività di correzione e di

4.2 Mappatura dei processi e Analisi criticità

successiva riemissione direttamente su ARGON.

- il sotto-processo di Verifica Esito è attualmente gestito su ARGON dal reparto fatturazione. Quest’attività consiste nel verificare eventuali esiti negativi all’interno di Argon attraverso l’estrazione di specifici file/report aziendali. Questa attività viene ripetuta tutte le volte che viene esitata una fattura emessa nei sistemi gestionali ARGON di tutte le SdV.

- il sotto-processo di Invio fatture al sistema SdI, è attualmente gestito completamente dal reparto IT. Appena una o un gruppo di fatture vengono emesse, le informazioni tecniche di questa fatture (come per esempio data di emissione, importo, n° fatture emesse, SdV di riferimento ecc.) vengono trasmesse attraverso l’invio di mail dal reparto Fatturazione al reparto IT che effettua una serie di attività tese sia al contollo di quanto comunicato sia all’invio vero e proprio delle fatture ai sistemi esterni interessati.

Il team di progetto quindi riscontra nei primi due sotto-processi una criticità collegata direttamente alla possibilità di renderli automatizzabili. Le attività svolte sono ripetitive per ciascuna SdV del gruppo. Questo genera di conseguenza rallentamenti alle attività Core Business dei reparti interessati (IT e Fatturazione) complicando fortemente l’organizzazione delle attività.

4.2 Mappatura dei processi e Analisi criticità

4.2.3.2 Analisi situazione “To-Be”

Il team di progetto per svolgere l’analisi “To-Be” ha tenuto conto, come per il processo di Gestione Ticket, di:

- obiettivi aziendali

- caratteristiche intrinseche delle varie attività che compongono il processo - margini di miglioramento nelle tempistiche di ogni attività

- possibilità di automatizzare il processo attuale.

Il team di progetto ipotizza come soluzione ottimale “To-Be” quella per cui si prevede:

- Sviluppo di funzionalità che riducano il ricorso ad attività ripetitive e a poco valore aggiunto per le attività Core dei reparti interessati.

Terminato il tempo pianificato per il processo di analisi e mappatura dei processi, il team di progetto elabora un documento di sintesi in cui si riportano tutti i dati riscontrati nell’analisi “As-Is” e le soluzioni emerse dall’analisi del “To-Be”.

4.3 Analisi Soluzioni

In questa fase sono stati analizzati i documenti di sintesi elaborati durante la fase precedente.

l’AD pianifica meeting di secondo livello con ogni gruppo del team di progetto, tese a proporre e ad analizzare le procedure e le attività anomale riscontrate durante l’operatività in termini di situazione ordinaria seguendo la metodologia della Gap Analysis.

Ufficio IT è sempre presente alle riunioni tra i vari reparti per poter capire sia le richieste e le anomalie operative evidenziate nelle analisi “To-Be” dei processi, sia per studiarne le possibili soluzioni integrate, eventualmente usufruendo dei consigli specialistici offerti dalla società di consulenza Alpha.

L’output della riunione consiste nella definizione di un insieme di documenti in cui si rappresentano le attività critiche dei processi segnalati dal team di progetto Una volta definite le esigenze dei vari reparti reparti in termini di miglioramento gestionale, l’AD del gruppo pianifica un meeting cui sono invitati il Management aziendale e i consulenti specializzati della società Alpha, per presentare le problematiche e individuare attraverso una loro consulenza, un soluzione possibile. Vengono analizzate le criticità insieme alle esigenze aziendali emersi

durante le fasi precedenti.

I consulenti verificano tutte le richieste avanzate anche dopo un attenta valutazione dei costi.

La Società Alpha si rende conto di non poter gestire le richieste derivanti dalle esigenze del Gruppo

e documenta i motivi che stanno alla base di questa decisione:

- ARGON possiede un funzionamento completo allo stato attuale e non sono necessarie modifiche così pesanti;

- le modifiche ad “ARGON” richieste in base alle esigenze derivanti dall’analisi del team di lavoro, avrebbero comportato lo sconvolgimento dell’architettura del gestionale e pertanto impossibile da soddisfare;

- poca replicabilità della soluzione gestionale ad altri clienti: ciò richiederebbe alla società Alfa un investimento di troppe risorse per un prodotto/output, non rivendibile ad altri clienti perché troppo personalizzata sul Gruppo Canarbino. - rischio che la società Alfa possa trovare una soluzione in tempi troppo lunghi rispetto ai bisogni immediati del Gruppo Canarbino.

Di conseguenza le alternative sono due:

1. richiedere interventi esterni (outsourcing) direttamente ad altra software house per ricercare soluzioni ad hoc;

2. sviluppare internamente, grazie all’ausilio di un reparto IT molto competente, applicativi software capaci di colmare le lacune riscontrate.

Quanto emerso in questa fase viene analizzato in un meeting aziendale che vede coinvolti l’AD, i referenti aziendali, gli addetti Sviluppatori dell’ufficio IT e il Team di Progetto.

Dopo un’attenta analisi si è potuto concludere quanto segue:

1. si esclude la possibilità di rivolgersi ad altra Software-house poiché la società Alpha cura e fa manutenzione del sistema gestionale principale del Gruppo (Argon). La scelta di un altro gestionale comporterebbe ingenti oneri di implementazione della nuova piattaforma con la conseguenza di stravolgere le procedure su tutte le società del gruppo, con l’aggiunta di oneri di formazione per tutto il personale, sulla nuova piattaforma.

4.2 Mappatura dei processi e Analisi criticità

l’intero flusso di lavoro per il settore di riferimento e di gestire la complessità ed il business core aziendale.

3. si decide di valutare le risorse umane presenti in Azienda per coinvolgerle nello sviluppo del software. Nell’ufficio IT sono preenti operatori con competenze culturali, professionali e tecnici adeguati. Si fa leva anche sulle competenze del team di progetto e sulla possibilità di una collaborazione anche con le figure di riferimento delle varie aree aziendali, coinvolgendo tutti nel processo di trasformazione..

Dopo una valutazione congiunta tra il Management, i vertici aziendali del Gruppo e il team di progetto, si decide di sviluppare internamente il presente progetto in Azienda, in modo personalizzato sui bisogni emersi, con l’obiettivo di creare al contempo know-how e un prodotto finale che possa colmare le criticità individuate nelle varie aree aziendali, non sottovalutando la convenienza di mantenere segrete le innovazioni apportate

I vantaggi della scelta di sviluppare il software sono:

- minor tempo stimato per sviluppare un applicativo idoneo in base alle varie esigenze aziendali;

- minori costi sostenuti in confronto alle soluzioni presenti nel mercato - possibilità di adeguare meglio il software alle richieste dei vari reparti - nessuna dipendenza da società esterne in termini di tempi e costi - sviluppo e incremento know-how interno