Sul blog Lean Edge la domanda del momento è quella posta da Godefroy Beauvallet:
Lean crea la mentalità delle prestazioni, consapevolezza dei problemi, e risoluzione locale dei problemi come modalità di sviluppo delle persone attraverso le tecniche del problem solving, aumentando continuamente lo “spirito di kaizen”.
Se uno inquadra lean in questo modo, sembra difficilmente possibile praticarlo in qualsiasi azienda moderna senza incontrare le questioni riguardanti le tecnologie informatiche (IT): gran parte del lavoro oggigiorno gira usando sistemi informatici (dalle email alla compilazione di vari moduli); usiamo IT per i nostri report, per calcolare gli indici e analizzare le prestazioni; gli allarmi sono spesso generati da sensori inviati poi attraverso le reti e elaborati da computer; grandi quantità di dati che possono essere usate per analizzare i problemi e conservate nei server.
Tuttavia, la “pegno della produttività dell’IT” è di standardizzare tutte le attività attraverso un interfaccia e le regole globali; la distribuzione globale e istantanea di miglioramenti; la circolazione delle informazioni a velocità della luce; la disponibilità di decine di dati… E tutto questo è molto diverso dal “pegno di produttività Lean”.
Quindi, e i dati empirici lo confermano, sembra che IT e Lean spesso ignorano l’un l’altro – i sensei Lean trattano IT come una scatola nera; i guru di IT invece guardano Lean come una tecnica di soft management di cui non devono preoccuparsi più di tanto. Alcune volte, IT e Lean collidono e le cose diventano bruttissime… Raramente invece, le persone che lavorano con Lean e nell’IT tentano e parlano, come succede sempre più spesso negli ambienti di sviluppo Agile. Ma questi tentativi sono molto rari.
Come può cambiare questa situazione? Esiste un “Lean Way” per guardare il sistema IT di una azienda, ed eventualmente per cambiarlo? Quali potrebbero essere i primi passi di questo percorso?
Una domanda molto interessante.
I sistemi informatici odierni sono fatti in modo tale da raccogliere miriadi di informazioni di qualsiasi cosa che rientra nella gestione delle aziende. E sono fatti tutti con lo stampino, uno uguale (o simile) a tutti gli altri, o a quelli della loro concorrenza.
Io per nessun motivo sono contrario all’utilizzo di questi sistemi, ma bisogna andare piano nell’utilizzo. Prima di costruire un sistema IT, un’azienda dovrebbe chiedersi: Cosa vogliamo ottenere da questo sistema? Quali dati vogliamo avere? Come può aiutare questo sistema informatico i nostri processi, le nostre persone? Come può offrire un valore aggiunto e non solo ulteriori complicazioni alla nostra azienda?
Bisogna quindi, come al solito, partire dal processo… Esaminarlo, farlo prima manualmente, capire i problemi, capire ciò che si può misurare come, ad esempio, le prestazioni dello stesso.
Io non partirei mai dall’applicazione di un gestionale rigido e completo. Io partirei dall’utilizzo di strumenti semplicissimi e gratuiti per la raccolta dei dati, vedrei cosa mi forniscono, che valore posso avere nel lavoro quotidiano. Come migliorano il mio processo. Poi, una volta capito a fondo il mio processo, svilupperei le applicazioni che rispecchiano i miei bisogni, non applicazioni standard che si trovano in tutti i gestionali e che tutti utilizzano. Quelle non mi servono. Magari inizialmente potrei avere un costo più elevato per personalizzare il sistema, ma a lungo termine, se ho impostato il sistema in maniera corretta, che segua il flusso delle operazioni nel mio processo, otterrei dei risparmi di tempo e denaro enormi. E inoltre avrei la possibilità di agire sul sistema per migliorarlo ulteriormente in funzione dei miglioramenti successivi. E avrei i dati significativi. Per me…
Sistemi chiusi che si comprano a scatola chiusa non servono a niente. Perché se li prendete, dovete essere voi ad adattare i vostri processi interni alla scatola chiusa e non il viceversa come sarebbe giusto nel caso di lean thinking.
I sensei lean solitamente vanno in conflitto con IT proprio per il motivo che vi ho spiegato sopra. Loro vanno prima a vedere il processo e a sistemarlo. Poi pretendono da IT di impostare il sistema informatico di conseguenza. Ma perché litigano? Perché c’è la resistenza del IT a cambiare in quanto sono state consumate moltissime risorse per mantenere il sistema a scatola chiusa così come è, e adesso gli viene chiesto di buttarlo via e ripartire da capo… Posso capire questo ragionamento, ma la strada comunque è di lasciar perdere il passato e vedere il sistema come lo vogliamo domani, come vogliamo che funzioni in futuro. Un sistema che aiuti a tutti di realizzare gli obiettivi e migliori le condizioni nell’azienda. Ci vuole però il coinvolgimento della proprietà in questa discussione, in quanto il personale dell’IT generalmente ha eseguito gli ordini dei loro superiori, che gli avevano dato l’approvazione di implementare i “monumenti”. Adesso questi monumenti sono da abbattere ed è da costruire qualcosa di migliore e più semplice (più process oriented…), e tutti devono essere d’accordo su questa decisione…
Voi avete qualche altro suggerimento da proporre?
