Come sta evolvendo il nostro MICROlab

Probabilmente alcuni di voi ricorderanno che poco più di un anno fa abbiamo inaugurato MICROlab, il reparto nato per riunire tre aree strategiche di MICROingranaggi – operations & IT, sistema qualità e certificazioni, e marketing – per farle ragionare sugli stessi problemi. L’obiettivo di questo progetto era ed è quello di centralizzare le strategie di ottimizzazione e innovazione, analizzando e monitorando in modo integrato i dati provenienti da ogni ambito dell’azienda.
Ebbene, proprio lavorando su MICROlab abbiamo sperimentato ancora una volta sulla nostra pelle la grande differenza che c’è tra il decidere di fare qualcosa e il metterlo in pratica.
Quello che dovevamo fare ci è stato chiaro fin dall’inizio. Ma – come è fisiologico che sia – abbiamo dovuto affinare alcuni passaggi pratici strada facendo, affrontandoli concretamente insieme ai colleghi dei vari reparti.

Mi spiego meglio.

Il metodo che abbiamo deciso di adottare per MICROlab fin dall’inizio era (ed è!) strutturato per sprint. Quindi isolare un’area operativa, capire dove c’è margine di miglioramento, concentrare lì le competenze disponibili e procedere in modo coordinato.

Inizialmente struttura, priorità e impostazione venivano definite dall’alto. Con il tempo però quel modello si è dovuto evolvere. Non mi riferisco al metodo, che è rimasto invariato, ma al fatto che oggi la direzione e le indicazioni di massima continuano a essere definite dall’alto, mentre – diversamente da prima – nel momento in cui tali indicazioni sono state recepite da chi di dovere, ciascuna figura coinvolta è in grado di dare il proprio contributo in autonomia sulla base delle proprie competenze e abilità.

Oggi MICROlab interviene dove manca una struttura. Costruisce strumenti, definisce processi, introduce indicatori. E poi lascia al reparto la possibilità di gestire autonomamente quel sistema.

Un esempio che, secondo me, rende bene l’idea, è il caso dell’ufficio acquisti. L’area era chiara e il problema anche: non esistevano indicatori, strumenti di misurazione e neppure un’interfaccia corretta che i colleghi potessero usare per leggere e monitorare ciascuna attività nel modo più giusto.
Pensate al problema del ritardo dei fornitori (problema che credo prima o poi toccato tutte le realtà manifatturiere). La valutazione dei fornitori si basava su percezioni consolidate nel tempo, ma non su raccolta e analisi dei dati. Abbiamo quindi isolato quel reparto, capito dove le informazioni si perdevano nel processo e perché, e concentrato lì le competenze disponibili per costruire gli strumenti necessari a raccoglierle.

Nel fare questo percorso ci siamo resi conto che per leggere e analizzare correttamente i problemi specifici come quello del ritardo dei fornitori, avremmo dovuto modificare parte del sistema gestionale, ma non tanto perché fosse sbagliato di per sé, quanto piuttosto perché non proponeva tutti i campi necessari ai colleghi dell’ufficio acquisti per descrivere esattamente quello che accadeva nella realtà, obbligandoli di fatto a “forzare” alcuni dati. Con la conseguenza che, se il sistema non riceve le informazioni in modo corretto e aggiornato, continua a pianificare su presupposti sbagliati, generando errori a cascata, spesso senza che nessuno se ne accorga.

Quello che abbiamo fatto è stato quindi intervenire modificando direttamente parti dell’ERP, aggiungendo campi e logiche che gli standard predefiniti non contemplavano. Ma ripeto: non perché il software fosse sbagliato, solo perché troppo generico rispetto alla realtà specifica di quel reparto. Un passaggio, questo, che molte aziende sottovalutano e tendono a ignorare, adattandosi al software senza magari comprendere fino in fondo cosa serve davvero.
In questo caso, la modifica all’ERP non è stata una scelta iniziale, è arrivata dopo, come conseguenza diretta del lavoro sui KPI e del confronto con il reparto. Senza quello, quasi sicuramente avremmo modificato il sistema sbagliato nel posto sbagliato.

Il punto inoltre non era solo risolvere il problema tecnico. Era fare in modo che, una volta concluso il lavoro, il reparto fosse in grado di gestire autonomamente quel sistema. Quindi leggere i dati, interpretare gli indicatori, agire di conseguenza. Ed è esattamente ciò che abbiamo fatto.