Alcuni concetti chiave, nati in ambito Operations, sono diventati parte di alcune culture aziendali (salvo poi non essere applicati con la stessa attenzione in tutte le aree funzionali). Ci si riferisce in particolar modo ai termini di cui sotto.
Come ridurre al minimo gli errori
Poka-yoke, col significato di a prova di errore, termine giapponese utilizzato nell’ambito del disegno industriale per indicare una scelta progettuale o un'apparecchiatura che, ponendo limiti al modo in cui una operazione può essere compiuta, forza l'utilizzatore ad una corretta esecuzione della stessa. Shigeo Shingo distingue tre tipi di poka-yoke:
Il metodo del contatto (contact method): le caratteristiche fisiche di un oggetto (forma, colorazione, ...) permettono di distinguere la posizione corretta o impediscono di connettere tra loro degli oggetti evitando i malfunzionamenti causati da un errato contatto. Un esempio di questo metodo sono i connettori sagomati (e/o colorati) di una scheda madre.
Il metodo del valore fisso (fixed-value method) controlla se è stato compiuto un certo numero di operazioni (es.: una spia che si accende quando una valvola è stata ruotata un determinato numero di volte).
Il metodo delle fasi di lavoro (motion-step method) controlla se sono stati eseguiti, nel corretto ordine, tutte le fasi di un determinato processo (es.: la spunta degli elementi di una checklist).
Come identificare le attività inutili
Muda è un termine giapponese che identifica attività inutili o che non aggiungono valore o improduttive. Fa parte dei concetti lean del Toyota Production System mirante a produrre solo i beni o i servizi richiesti dal cliente e che il medesimo era disposto a pagare. Al concetto di Muda vanno legati anche quelli di MURI (Cosa illogica, impossibile, priva di ragione), e di MURA (Variazione non governata o inaspettata). In questa filosofia aziendale si possono individuare sette sprechi principali, identificati da Taiichi Ohno, ingegnere capo Toyota.
Difetti: sono errori di realizzazione e rifacimenti od anche produzione di parti e prodotti non necessari. Lo sforzo necessario a creare questi difetti è uno spreco.
Sovrapproduzione: la sovrapproduzione è la produzione o l'acquisizione di beni prima che siano effettivamente richiesti. È uno spreco molto pericoloso perché tende a nascondere problemi di produzione. La sovrapproduzione deve essere immagazzinata, gestita e protetta, generando quindi altri sprechi.
Scorte: le scorte, siano esse in forma di materie prime, di materiale in lavorazione o di prodotti finiti, rappresentano un capitale che non ha ancora prodotto un guadagno sia per il produttore che per il cliente.
Trasporti: ogni volta che un prodotto è trasferito rischia di essere danneggiato, perso, ritardato, così diventa un costo che non produce valore. I trasporti non introducono alcuna trasformazione al prodotto che il cliente sia disposto a pagare.
Movimento: simile ai trasporti, ma si riferisce, anziché ai prodotti, ai lavoratori o alle macchine. Questi possono subire danneggiamenti, usure, problemi di sicurezza.
Attese: si riferisce sia al tempo impiegato dai lavoratori nell'attesa che la risorsa sia disponibile, sia al capitale immobilizzato in beni e servizi che non sono ancora stati consegnati al cliente.
Processi: usare risorse più costose del necessario per le attività produttive o aggiungere funzioni in più, oltre a quelle che aveva originariamente richiesto il cliente, produce solo sprechi. Gli operatori che possiedono una qualifica superiore a quella necessaria per realizzare le attività richieste, generano dei costi per mantenere le proprie competenze che vanno sprecati nella realizzazione di attività meno qualificate.
Situazione piuttosto frequente nelle multinazionali è quella in cui semilavorati e finiti, progettati e/o realizzati localmente, negli stabilimenti delle varie entità legali dislocate nel mondo, sono spediti alla casamadre, per ragioni commerciali o produttive di efficienza economica, prima di raggiungere il cliente finale.
Analogie con i big data del finance
In ambito Finance l’analogia è evidente con le chiusure periodiche e la quantità di diverse informazioni che gli stabilimenti devono produrre per la Legal Entity che , a sua volta, deve produrre per l’HQ.
A questo punto, dal momento che:
In the software industry, at least in the enterprise resource planning (ERP) segment, there is an implicit understanding of what is meant by tier 1, 2, and 3 vendors (…) Indeed, the most straightforward and useful way to distinguish different software vendor tiers is by the type of company they serve:
Tier 1 vendors serve large global businesses
Tier 2 vendors serve mainly mid-market businesses
Tier 3 vendors serve smaller-than-medium businesses.
(http://www.technologyevaluation.com)
ci sono sostanzialmente due visioni. La seconda ha avuto una notevole diffusione ma non necessariamente per motivi economici se ci si sofferma sulle modalità con cui è frequentemente realizzata.
Ipotesi 1
1. ERP Tier 1 per tutte le aziende del gruppo indiscutibilmente gestito centralmente dall’HQ
2. Alti costi di progettazione del sistema, implementazione e manutenzione a cui si sommano alti costi di infrastrutture IT
3. Rigidità nelle procedure di reporting sostanzialmente non personalizzate alle esigenze locali e spesso scollegate dalle necessità legali (anche nell’accezione fiscale del termine) a cui si somma una lenta implementazione
4. Rapidità e semplicità (relativa) nelle procedure di reporting periodico, quando il progetto è terminato, soprattutto per il consolidamento dati
5. Progetto di Reporting Finanziario sostanzialmente mai terminato dati i lunghi tempi di implementazione che implica problemi di qualità / affidabilità delle cifre nel frattempo
Un Progetto di Reporting Finanziario è evidentemente un complesso progetto interfunzionale che prevede alto coinvolgimento e sensibilità specifica della Funzione IT; la scelta dell’ipotesi 1 può essere dettata in maniera inversamente proporzionale alla complicazione del settore industriale e alle dimensioni del Gruppo sia in termini di presenza in paesi diversi che di fatturato sviluppato e personale impiegato.
Ipotesi 2
1. ERP anche Tier 3 gestito localmente a livello di branch ma su interfacciato su piattaforma cosiddetto reporting tool comune
2. Inferiori costi di progettazione del sistema, implementazione e manutenzione così come inferiori costi di infrastrutture di rete
3. Flessibilità nelle procedure che sono personalizzabili (anche agli adempimenti richieste dalle normative locali) e più rapida implementazione del progetto
4. Delicate procedure di cut-off dati ed esportazione da erp locale al data warehaouse
5. Minor controllo dalla parent company per cui qualità / affidabilità dei dati affidata al locale team AFC (amministrazione, finanza, controllo)
La scelta della Ipotesi 2 è coerente con il modello sovente adottato di Entità Legale locale con relativo Responsabile Finanziario.
Questa scelta impone:
• Analisi dell’ERP locale e dell’architettura IT con focus su:
o Piano dei conti e relative riclassifiche legali / gestionali (in particolar modo identificazione degli intercompany accounts e transitory accounts)
o Tipologie documenti e causali operative per Vendite, Acquisti, Logistica, Produzione, Amministrazione
o Funzionalità di esportazione / migrazione dati (creazione file da caricare sul database di gruppo)
• Identificazione precisa delle informazioni richieste dall’HQ, scelta della piattaforma di reporting e progettazione degli strumenti (report) desiderati con focus su:
o aree funzionali interessate
o informazioni quantitative e qualitative
• Visite periodiche e audit interni con focus su:
o documentazione locale per spiegare i dati ufficialmente comunicati all’HQ (analogia del concetto di Poka-yoke)
Occorre considerare attentamente che il cuore di un Progetto di Reporting Finanziario sono le procedure automatizzate di esportazione dati, dai sistemi locali e relativo caricamento sulla piattaforma di gruppo.
L’obiettivo di un Progetto di Reporting non è il semplice caricamento, rispettando le due date, dei dati sul database ufficiale interrogato dall’HQ ma l’integrità dei dati stessi e quindi la modalità di alimentazione del database. Pertanto tale progetto si conclude con l’attuazione di procedure inerenti le funzionalità di esportazione automatica (cioè creazione di files da importare).
Questo permette, in analogia con il concetto di Muda, di:
• garantire l’integrità dei dati trasferiti ed eliminare la possibilità di errore umano (anche considerando che i dati inseriti sono sempre progressivi, quindi, ad es. il Profit & Loss Month to Date = P&L Year to Date – P&L Year to Date prior month)
• annullare i tempi morti per saturazione (buffe ring) o crash del database ricevente
• eliminare o quantomeno ridurre considerevolmente l’uso di file locali (office automation) gestiti extrasistema da addetti diversi e alternatisi nel tempo
• analizzare automaticamente gli scostamenti, sia mese su mese che periodo su periodo, tendenziali (rispetto allo stesso orizzonte temporale dell’anno precedente) e congiunturali (rispetto all’orizzonte temporale immediatamente precedente).
Spesso invece si rimane a metà del guado perché i dati sono manualmente digitati sul Reporting Tool di Gruppo che viene mantenuto, anche nel senso più ampio di aggiornato e modificato dalla Casamadre, in modo totalmente scollegato e spesso casuale rispetto alle sorgenti, cioè alle fonti dei dati, che possono essere reparti, stabilimenti o filiali con autonomia giuridica. Se è vero che sovente vengono ridotti i budget e quindi ci si deve accontentare, è altrettanto vero che non viene identificato correttamente il deliverable del progetto e viene sottovalutato l’aspetto procedurale nella qualità delle informazioni che è strettamente interconnessa con le modalità operative con cui sono costruite le cifre.
Articolo a cura di a cura di Alessandro Musso – Finance Executive & Board Member (s.m.e.) e autore degli ebook "Modelli economici e finanziari" e "Implementare un nuovo Sistema Erp.