shelidonJuly 7, 2021Leave a Comment

La riduzione degli sprechi è uno dei principi base nella gestione sostenibile di un progetto ed è centrale a interi sistemi, tipicamente i sistemi Lean.

I framework Agili, da bravi figli del Lean, non sono da meno e anche il DevOps, di cui sono tornata a parlare nella pillola della settimana scorsa, propone i suoi sistemi per ridurre gli sprechi. Ce ne parla sempre Gene Kim nel suo testo fondamentale sul sistema.

In particoolare gli sprechi in DevOps vengono identificati come:

1. Lavoro parzialmente svolto: questo lavoro diventa obsoleto e perde in fretta di valore, motivo per cui spesso all’interno di un flusso BIM non ha molto senso “iniziare a impostare” e, come spesso capita, c’è fare e non fare, ma non c’è provare;
2. Processi extra: ogni lavoro che viene svolto in aggiunta a ciò che dà valore al cliente (es: parametri ricompilati manualmente solo perché qualcuno non sa usare gli strumenti nel modo corretto);
3. Gold plating: aggiunta di caratteristiche (ad esempio usi, nel nostro caso) non richiesti dal cliente e non necessari all’organizzazione (questo è il tipo di sprechi cui si indirizza una buona parte della nuova norma sul Livello di Fabbisogno Informativo);
4. Task switching: quando le persone vengono messe a lavorare su troppi progetti, costringerli a passare da un progetto all’altro comporta perdite di tempo e di informazioni, specialmente in lavori tecnologicamente complessi come la programmazione o – nel nostro caso – la modellazione informativa;
5. Attese: quando i tempi si allungano a causa, ad esempio, di flussi di approvazione inefficienti, il tempo speso non lavorando sul progetto si frappone tra il cliente e il valore che deve ricevere (anche quando le attese sono determinate dal cliente stesso);
6. Movimentazione: esattamente come accade per il Lean, anche la movimentazione di informazioni (e non solo di merci) genera uno spreco e dovrebbe essere ridotta il più possibile… la cosa purtroppo non va completamente in accordo con quello che abbiamo visto qualche settimana fa in relazione all’Ambiente di Condivisione dei Dati “diffuso”;
7. Difetti: l’introduzione di difetti, specialmente all’inizio dei processi, introduce problemi che diventano sempre più grandi mano a mano che si procede con il lavoro ed è quindi importante che elementi o parti di codice malfunzionanti siano eliminati da subito (pensiamo ad esempio a quanto si paga, più tardi nel processo, l’introduzione nel modello di componenti parametrici non sviluppati in modo ottimale);
8. Lavoro manuale o non standardizzato: ogni volta che si richiede un lavoro manuale (spostare un file, ricompilare un parametro) si introduce un elemento di rischio e uno spreco.