Category Archives: Metodologie

L’Ordine di lavoro nella gestione informatizzata della Manutenzione – parte 2

Published by:

La Richiesta/Ordine di Lavoro

Dopo aver realizzato il sistema di riferimento che ci permetterà di emettere ed elaborare la richiesta in questione, entriamo nel vivo della medesima. Segnaliamo innanzitutto che alcuni SW usano l’espressione RdL altri l’espressione OdL, altri entrambe, con significati sequenziali. Vediamo le definizioni UNI, che tengono conto ovviamente di tutti i possibili scenari.

UNI 10147.12.8 – 2003 Richiesta di Lavoro (RdL) : istruzione* con la quale si richiede l’intervento di manutenzione che deve essere fatto.

UNI 10147.12.5 – 2003 Ordine di Lavoro (OdL): istruzione* che attiva l’intervento di manutenzione a seguito di una richiesta di lavoro.

Istruzione*: può essere un documento cartaceo, una richiesta fatta attraverso supporti elettronici oppure richiesta verbale.

Di seguito gli scenari di emissione più diffusi:

  • RdL seguita da OdL. Si utilizza preferenzialmente questa modalità quando la richiesta di lavoro deve essere autorizzata per diventare esecutiva. Tipico ad esempio della manutenzione in regime di Global Service (completamente terziarizzata) o di Service più o meno spinto. Vi sono comunque SW che tracciano d’ufficio coi due passaggi la presa in carico della RdL. La chiusura dell’attività a lavoro eseguito richiede poi i due passaggi a ritroso.
  • Emissione della sola RdL. La tracciatura della presa in carico avviene definendo degli “stati di avanzamento” corrispondenti alle varie fasi di esecuzione del lavoro. E’ il sistema più utilizzato anche perché esiste comunque la possibiltà di inserire la fase di autorizzazione, ma gestione e chiusura sono più snelli.
  • Emissione del solo OdL, che coincide con la RdL di cui sopra. E’ solo una questione di terminologia. Noi sconsigliamo questo scambio di acronimi, in quanto UNI dà due definizioni distinte dei medesimi, che non dovrebbero quindi essere usati l’uno per l’altro. Tuttavia UNI non è cogente.

Chi scrive raccomanda di far riferimento al secondo scenario; questo sia per semplicità sia perché in ogni caso il primo passo per qualificare il “fabbisogno di manutenzione” resta sempre la RdL. Sottolineiamo “primo passo”, perché tutta la filiera del fabbisogno (quantificazione economica e temporale, problematiche e consuntivazione finale) è correlata univocamente alla RdL.

Come emettere la RdL

E’ quanto mai consigliato procedere per gradi o, meglio, per affinamenti successivi. Si raccomanda allo scopo di sviluppare l’Equipment Tree su Aree-Pilota prima di eseguire la mappatura di tutte le Unità Produttive. Le Aree Pilota devono essere rappresentative delle fasi del Processo, in modo da poter “clonare” il più possibile le esperienze fatte sulle medesime. Analoga fase sperimentale è raccomandabile anche per la messa a punto della “maschera” di emissione della RdL, che sarà testata ovviamente sulle Aree-Pilota di cui sopra. Per esperienza di chi scrive, il metodo più semplice consiste nell’utilizzare allo scopo un foglio Excel opportunamente organizzato, nonchè strutturato in modo da poter essere importato con facilità dai SW commerciali “definitivi” più diffusi. Aggiungiamo che la fase sperimentale su Excel di Equipment Tree e maschera di emissione RdL è particolarmente utile per una scelta più consapevole del SW definitivo stesso.

La Figura 2 riporta un’impostazione elaborata dallo scrivente sulla base di esperienze dirette e generalmente utilizzabile in qualsiasi settore merceologico. Se i dati immessi sono completi e veritieri, l’uso dei “filtri” di Excel permette di effettuare queries già notevolmente significative, specie per l’analisi dei dati di fermo e guasto in seguito a interventi di Manutenzione Correttiva.

Precisiamo inoltre che alla configurazione step by step dell’RdL partecipano sia il richiedente che l’esecutore, immettendo ciascuno i dati di propria competenza. Le informazioni dovranno essere congruenti. Pertanto la supervisione “educativa” e formativa da parte dell’Ingegneria di Manutenzione (IdM) non dovrà mai mancare e non solo nella fase sperimentale. Se la supervisione non è costante e collaborativa il processo di “data collection” si deteriora rapidamente, con buona pace del “completo e veritiero” sopra auspicato.

f2Figura 2

Contenuti delle colonne

N°RdL: è il numero progressivo della Richiesta di Lavoro. Il SW definitivo effettuerà la numerazione in automatico.

Codice posizione: è il codice di posizione riportato sull’Equipment Tree. Chi emette la RdL deve avere sempre a portata di mano l’Equipment Tree stesso. L’ideale sarà confezionare un documento Excel a più fogli, in modo da poter “chiamare” l’Equipment Tree in tempo reale, copiare il codice di posizione e incollarlo nella colonna in oggetto. E’ importante che il codice sia quello del livello di dettaglio più “spinto” disponibile sull’Equipment Tree. Se non lo fosse, la supervisione da parte di IdM se ne accorgerà e si cercherà di approfondire e correggere col Richiedente. Ciò contribuirà alla sua formazione, dandogli la percezione sia di non essere abbandonato sia del fatto che deve pensare con attenzione all’oggetto di manutenzione per cui chiede l’intervento.

Data evento: se la politica di manutenzione relativa alla riga che si sta compilando è la Correttiva (a guasto), la data coincide con la data di emissione della RdL. Se invece la RdL riguarda un’attività programmata, la data può essere diversa. Deciderà il Gruppo di Lavoro operante sull’Area-Pilota. A regime la data sarà immessa in automatico per i lavori non programmati, mentre per i PMP (Piani di Manutenzione Programmata) sarà l’Ingegneria di Manutenzione a definire ed immettere gli scadenziari. Ne tratteremo sul prossimo numero.

Richiedente: è il nominativo o il riferimento univoco (es. matricola) di chi richiede il lavoro. Può essere un appartenente a qualsiasi Funzione aziendale, purchè abilitato. Salvo emergenze palesi, non è pensabile fermare un manutentore “che passava di lì” e chiedergli di intervenire. Anche il pronto intervento deve essere richiesto tramite RdL, proprio perchè lo scopo ultimo del “Progetto Manutenzione” è segnatamente quello di spostare risorse dalle attività non programmate verso attività programmate. Ogni informazione sui fabbisogni non programmati è quindi preziosa per analizzarla e ridurli al minimo, sempre ovviamente in ottica di economicità.

Descrizione Intervento: è l’unico campo libero per tutte le politiche di manutenzione. Chi effettua li lavoro immette le informazioni che ritiene più utili, comprese le cause del guasto (se si tratta di manutenzione Correttiva) e se ritiene di immetterle. Si noterà che manca una colonna specifica, con le causali codificate e il relativo campo obbligato. La mancanza è voluta, in quanto l’esperienza di chi scrive dà per preferibile analizzare le cause di guasto in sede opportuna e, in fase di RdL, concentrarsi su altre informazioni che è bene cogliere “a caldo”. In questa fase, sempre per esperienza in campo, è molto più importante e ricco di contenuto informativo cogliere il componente elementare da cui il guasto ha avuto origine, come vedremo commentando i contenuti delle colonne “Codice Componente” e “Descrizione Componente”.

Esecutore: è il nominativo o il riferimento univoco (es. matricola, codice Fornitore etc.) di chi esegue il lavoro. E’ importante poter selezionare le attività svolte da personale interno, sia di manutenzione che di produzione (in sede di manutenzione autonoma o Automanutenzione) e le attività invece terziarizzate. Chiaramente il foglio Excel permetterà un dettaglio limitato, mentre il SW definitivo consentirà di avere una visione completa delle risorse necessarie per l’esecuzione del lavoro richiesto. Un buon SW permetterà anche di verificare eventuali scostamenti tra quanto preventivato e quanto consuntivato, di fare confronti tra fornitori, ricerche etc.

Politica di Manutenzione: Si raccomanda di creare una tendina con voci precostituite, in modo da agevolare sia il richiedente sia chi elaborerà le informazioni. Le voci raccomandate, almeno in questa fase, sono:

Manutenzione Correttiva; Manutenzione Preventiva Ciclica; Manutenzione Predittiva; Manutenzione Migliorativa, Assistenza all’Esercizio.

Per le definizioni, si rimanda alle Norme UNI. L’Assistenza all’Esercizio, a rigor di termini, non è una Politica di Manutenzione. Tuttavia talvolta è necessario, opportuno, conveniente etc. che la Manutenzione affianchi l’Esercizio per i più disparati motivi. A titolo esemplificativo e non esaustivo: attrezzaggi, pulizie tecniche, fermate/riavviamenti, start-up di nuovi impianti etc. Un caso interessante è la supplenza in manuale di perdita di automazione. Vedasi a tal proposito più avanti, quando si trattano gli “Effetti sul Processo”. L’impiego di risorse manutentive per necessità produttive deve essere comunque mappato, sia perché spesso segnale di una situazione anomala sia in quanto non sarebbe corretto scaricarne i costi sul già risicato budget della manutenzione.

Codice Componente e Descrizione Componente: come anticipato in Figura 1 (riquadro in rosso sopra l’ultima colonna di destra), invece di appesantire l’ET spingendolo a gradi di dettaglio onerosi e di difficile lettura da parte degli operatori, si raccomanda l’utilizzo di  “Flags” con liste codificate di “componenti elementari”, da utilizzarsi per selezionare ed immettere i componenti elementari (codice e descrizione) a corredo delle RdL relative alla Manutenzione Correttiva e non solo. Questo comporta numerosi vantaggi:

  • Si arriva a un dettaglio molto spinto senza appesantire l’Equipment Tree
  • Ogni “Flag” è valido per tutta l’Azienda: il medesimo componente elementare, ad esempio un fusibile, può essere operativo dovunque. ATTENZIONE: inserire o rimuovere un elemento dovrà essere di esclusiva competenza del System Administrator, supportato dall’ingegneria di Manutenzione, in modo da garantire la costante congruenza dei codici. I componenti saranno sempre descritti in ordine alfabetico, i codici non saranno necessariamente in progressione, se non alla prima stesura.
  • Si fornisce lo spunto di partenza per un’analisi del guasto rigorosa (vedere la voce “Descrizione Intervento” sopra commentata)
  • Si può creare un link con la Gestione Ricambi ( ovviamente a regime, col SW definitivo)
  • Si possono selezionare facilmente i componenti più critici

Ora inizio, Ora fine e Durata intervento: si tratta di informazioni quanto mai delicate, difficili da inquadrare e molto spesso anche da ottenere. Specialmente nel dominio della Manutenzione Correttiva (a guasto), quantificare i tempi effettivi di indisponibilità è per lo meno laborioso. Per contro, il pay back del costo delle possibili contromisure al guasto stesso è mediamente di gran lunga più coperto dal valore delle perdite di produzione (in quantità e/o qualità) che dal costo dell’intervento manutentivo vero e proprio. L’Ingegneria di Manutenzione ha necessità di conoscere quanto tempo trascorre dalla percezione dell’anomalia al ritorno alle condizioni produttive standard. Tale tempo complessivo misura la effettiva reattività del sistema ed è costituito dalla sommatoria di una serie di tempi, la cui analisi dettagliata è altrettanto importante ma sarà effettuata in sede opportuna.

Ore uomo impiegate: è un’informazione utile qualunque sia la Politica di Manutenzione attivata dalla RdL; permette di quantificare le risorse umane necessarie all’esecuzione del lavoro. Ovviamente il dato coincide col tempo di intervento solo se questo sarà eseguito da una sola persona. Se ho un fermo macchina di un’ora e sono intervenute più persone i due dati saranno diversi.

Effetto sul Processo: è uno dei dati più importanti per l’Ingegneria di Manutenzione, specie se la RdL è una richiesta di Manutenzione Correttiva. Anche qui, come nel caso della “Politica di Manutenzione”, si raccomanda di creare una tendina con voci precostituite, in modo da agevolare sia il richiedente sia chi elaborerà le informazioni. Le voci raccomandate, almeno in questa fase sono: Nessun effetto; perdita di velocità; perdita di qualità; fermo macchina/impianto; perdita di automazione; ambiente; sicurezza.

Osservazioni sulle due voci meno ovvie.

  • Nessun effetto. Se il fabbisogno di manutenzione non ha avuto effetti sul processo (ad esempio la fermata di una pompa con pompa di riserva, l’avaria di una scheda elettronica con back-up caldo etc), l’evento può comunque essere un sintomo di “disagio” e deve essere tracciato in quanto si è comunque trattato di un guasto.
  • Perdita di Automazione: è a volte possibile sopperire “in manuale” ad avarie, più frequentemente elettro-strumentali, che comportano perdita di automazione. Ad esempio: loop strumentali per trasferimento liquidi e robot “pick & place nel packaging. Con un po’ di buona volontà e per brevi periodi, in determinati casi è possibile sopperire. Come accennato quando si è trattato delle “Politiche di Manutenzione” si può ricorrere temporaneamente al contributo operativo anche da parte dei manutentori per evitare il fermo impianto. Sarebbe perciò una perdita di informazione pesante attribuire al guasto il “nessun effetto”.

L’Ordine di lavoro nella gestione informatizzata della Manutenzione – parte 1

Published by:

Lo strumento informatico a supporto del “Progetto Manutenzione” è imprescindibile e costituisce condizione necessaria di successo. Necessaria, non anche sufficiente, in quanto si tratta come appena detto di uno strumento. Esso deve pertanto essere calato in un ambiente dotato di sufficiente cultura di Manutenzione e maturità aziendale. L’emissione della Richiesta di Lavoro è il momento chiave per cogliere e capitalizzare il prezioso contenuto informativo che scaturisce dall’insorgere alla consuntivazione di un evento manutentivo, programmato o non programmato.

Prima di affrontare l’argomento riteniamo utile cercar di chiarire in cosa consiste la gestione informatizzata della Manutenzione. Riferiamoci come sempre (quando è possibile), alla normativa UNI. La Norma è la 10584 – 1997 e la definizione è la UNI 10584.3.1 Essa recita:

Sistema Informativo di Manutenzione (SIM): complesso di norme, procedure e strumenti atti ad accogliere ed elaborare le informazioni necessarie per la gestione delle attività di manutenzione e per il monitoraggio dell’attività degli impianti.

La definizione è sintetica ma, come tutte le definizioni tecnico/scientifiche (perché di questo si tratta), ogni parola va pesata in valore assoluto. E’ vero che dal 1997 a oggi l’informatica ha compiuto tali passi che le prestazioni ottenibili da parte di un SW di normale caratura sono decisamente ordini di grandezza superiori a quelle ottenibili alla data della stesura della Norma stessa, ma i principi concettuali e di buona applicazione sono invariati. A dimostrazione, solo apparentemente paradossale, di quanto appena detto, è interessante notare che la Norma, nel definire il SIM, NON pone come un “must” la gestione informatizzata del medesimo. A pag. IV della Norma, punto 1 – SCOPO E CAMPO DI APPLICAZIONE – si legge infatti: la presente norma individua e descrive le peculiarità del sistema informativo di manutenzione (SIM) sotto il profilo logico, procedurale e organizzativo, prescindendo dal sistema di supporto, che può essere realizzato anche in forma cartacea [ ..omissis…].

In pratica, è fondamentale che ci sia una consolidata organizzazione della manutenzione, nel cui ambito le informazioni descrittive della “storia” dei beni manutenuti siano sistematicamente raccolte e organizzate in forma codificata, ripetitiva e agevolmente consultabile; ciò al fine di poter prendere decisioni, progettare contromisure, stabilire priorità etc etc su basi analitiche-oggettive.

Ciò chiarito, il “può” concesso da UNI al cartaceo indica una possibilità ormai solo teorica o al massimo propedeutica/sperimentale. UNI lo ha doverosamente puntualizzato per coprire tutti i possibili scenari, purchè ci siano comunque dati “intelligenti” da elaborare e interpretare.

Il SIM presuppone quindi scelte / decisioni organizzative, tecniche e gestionali che vengono, anzi, devono venire ben prima del sistema di supporto, ovvero prima dello strumento e indipendentemente dalle sue prestazioni. Pertanto, al di là dell’atteggiamento giustificatamente “asettico” da parte di UNI, lo strumento per rendere efficacemente operativo il SIM non può che essere informatico. Il mondo anglosassone usa l’acronimo CMMS, che sta per Computerized  Maintenance Management System. Ancora una volta gli acronimi anglosassoni sono più incisivi: nello specifico il contenuto “vero” sta nei termini Management System

Così come la Cultura di Manutenzione è un di cui della padronanza del sistema produttivo definita “Maturità Aziendale”, analogamente il CMMS è collocabile come sottoassieme (strategico !) di un sistema gestionale più ampio, classificato come EAM (Enterprise Asset Management), che quasi sempre si avvale della sinergia di più SW ed ha come missione la gestione del Life Cycle o Ciclo di vita dei beni.

E’ interessante arrivare alla conclusioni su cos’è il CMMS proponendo anche una riflessione sull’acronimo francese, GMAO, ovvero Gestion de la Maintenance Avec l’ Ordinateur, dove (ovviamente) Ordinateur sta per Computer. L’espressione francese ha il grande pregio di sottolineare la natura “strumentale” dell’apparecchio, finalizzata ad ordinare i dati in modo idoneo all’uso che se ne vuole fare. Effettivamente, per quanto supportato in maniera anche formidabile dallo strumento, il momento della trasformazione delle informazioni in conoscenze e da conoscenze in decisioni, è esclusiva prerogativa dei professionisti della manutenzione.

Il fabbisogno di manutenzione: dove intervenire e come procedere.

Come anticipato in apertura del presente articolo, l’insorgere di un fabbisogno di manutenzione è già di per sé un’informazione preziosa, informazione a cui fanno seguito tutte le successive, quelle relative alle attività messe in atto per soddisfare detto fabbisogno. Il “fabbisogno” può essere sia di manutenzione Programmata che Correttiva (non programmata; a guasto). La Richiesta-Ordine di Lavoro a cui ci riferiremo nel presente articolo viene emessa nel dominio della Manutenzione Ordinaria (Budget “a spese”), in quanto le attività di Manutenzione Straordinaria (salvo casi molto specifici) sono di norma progetti su investimento e in ogni caso gestiti con Software specifici per i progetti.

Una corretta mappatura del percorso genera un corredo informativo che, se ben organizzato, permette di gestire analiticamente (su basi numeriche) tutta la filiera, nonchè di ricavare informazioni oggettive per supportare decisioni tecniche ed organizzative e verificarne i risultati.

La corretta gestione informatizzata della manutenzione si fonda dunque su due poli strategici: l’Equipment Tree, che deve permettere di individuare univocamente dove scaturisce il fabbisogno e la Richiesta / Ordine di Lavoro che, emessa all’insorgere di un fabbisogno di manutenzione e  riferita univocamente all’oggetto di manutenzione, permette di qualificare e quantificare tutte le informazioni che descrivono l’intervento manutentivo. Il tutto in forma codificata, “interrogabile” da ogni angolazione e con modalità tali che i dati possano essere confrontabili nel tempo tra loro e con altri dello stesso settore merceologico (possibilità di benchmarking).

L’Equipment Tree 

Prima di progettare la “maschera” di emissione della RdL/OdL è dunque indispensabile “insegnare” al CMMS come rispondere al primo quesito, il più istintivo, di chi emetterà e di chi processerà il segnale di fabbisogno. Il quesito è “DOVE” ovvero dove è necessario intervenire.

Definire “DOVE” in modo semplice, univoco, tracciabile e tracciato, correlabile ad altre famiglie tecniche in funzione di parametri specifici è la parte più delicata dell’implementazione del CMMS: non si può sbagliare, pena il trascinamento pressoché irreversibile di “peccati originali” pesantemente invalidanti dell’uso e delle prestazioni del CMMS e di difficile se non addirittura impossibile rimozione una volta strutturato il tutto in un certo modo.

Di solito questa fase è supportata da consulenza specialistica, ma NON in informatica (quasi sempre già ampiamente presente): serve consulenza specialistica in Ingegneria di Manutenzione. E’ pessima consuetudine infatti che i CMMS vengano implementati nella loro struttura generale ed a scopi prettamente amministrativi, rimandando a tempi successivi l’implementazione dei cosiddetti “Moduli Tecnici”.

L’implementazione del CMMS va fatta invece con priorità alle esigenze dei moduli tecnici. Se funziona la parte gestionale, al massimo si prende atto di una situazione (effetti delle disfunzioni). Se funziona anche la parte tecnica, oltre a prendere atto della situazione si ricavano le conoscenze per migliorarla (cause delle disfunzioni). Nessuno potrà mai ridurre i costi (senza fare danni anche maggiori), a meno che non ne conosca le origini effettive ed agisca – o meglio, sappia agire – solo su quelle.

Senza entrare nel dettaglio delle tecniche di realizzazione dell’Equipment Tree, precisiamo soltanto che l’Ingegneria di Manutenzione seguirà comunque una logica gerarchica del tipo Padre-Figli-Nipoti  e fermerà la scomposizione ad albero (da cui il nome) al livello di dettaglio minimo indispensabile. Trattando della maschera di emissione RdL/OdL vedremo poi come mappare anche i componenti elementari senza appesantire l’anagrafica degli impianti.

Per chiarire meglio quanto sopra, riportiamo in Figura 1 l’Equipment Tree di un ipotetico carroponte da parco rottami (acciaieria) con benna-ragno  ad azionamento oleodinamico (a spicchi). Il principio da seguire è la “riproduzione del processo che la macchina deve compiere, chiedendosi cosa deve funzionare correttamente e contemporaneamente affinchè il processo abbia luogo.

Relativamente al Carroponte, vediamo che il suo “processo” consiste nell’afferrare del rottame e spostarlo in uno spazio tridimensionale. Occorre quindi che funzionino i 4 sottoassiemi fondamentali posti al secondo livello, ciascuno preposto ad un tipo di spostamento.  A propria volta, ogni sottoassieme può funzionare se funzionano le apparecchiature che lo compongono, poste al terzo livello rispetto al livello individuato come primo. Logicamente, se a livello aziendale si decide che il codice di primo livello sia quello dello Stabilimento, al secondo livello ci sarà l’Impianto, poi la linea ed infine la macchina. La codifica sarà sequenziale, in logica gerarchica, sicuramente recuperando i codici esistenti ma non perdendo la descrizine sintetica del processo.

La scomposizione può proseguire all’infinito o quasi, ma si sconsiglia vivamente di appesantire l’ET oltre il minimo indispensabile.

f1Figura 1. Esempio didattico di Equipment Tree

 

Ishikawa or 5-Why – Which do you prefer for Root Cause Analysis?

Published by:

Discussione sulla RCA, proposta e pubblicata su LinkedIn da  Daniel Uebbing

Il diagramma di Ishikawa è il metodo più popolare per l’analisi delle cause, perché causa principale ed effetto sono presentate in modo conciso. Quali sono i vantaggi?

  • Ottimo metodo per la raccolta dettagliata delle cause principali
  • Presentatione delle inter relazioni
  • Chiara presentazione grafica
  • Elaboratione visuale delle cause alla radice
  • Secondo l’analisi delle cause è possibile avviare misure sostenibili
  • Strutturazione generale dei processi
  • Apprendibilità

Ma non bisogna ignorare il metodo dei 5-Perché per l’analisi delle cause. Il metodo 5-Perché viene utilizzato in qualità in tutto il mondo e soprattutto è aggiuntivo al metodo Ishikawa. L’uso di 5-perché è semplice e conveniente soluzione per economizzare le risorse interne.

Quali sono i vantaggi per riprodurre tutte le procedure amministrative necessarie all’interno di un software?

  • E’ possibile avviare misure sostenibili fuori dalla analisi delle cause
  • Per avere un processo standard all’interno della società per la documentazione del CIP Workshop e misure sostenibili.
  • Si garantisce la totale trasparenza di tutte le azioni nell’ambito del processo di miglioramento continuo
  • Si effettua una panoramica a disposizione di tutte le attività presenti
  • Siete sostenuti da un sistema di promemoria che assume la e-mailing automatica di promemoria, e vi sostiene per garantire il completamento contemporaneo di misure
  • Si dispone di una panoramica di tutte le attività che rimangono ancora da completare

D.Uebbing

Il cambiamento

Published by:

Francesco Starace, amministratore delegato dell’Enel, ha messo nero su bianco quello che la classe dirigente deve fare per realizzare e consolidare un processo di miglioramento (da “il Fatto Quotidiano” del 30/05/2016).

“Per cambiare un’organizzazione ci vuole un gruppo sufficiente di persone convinte di questo cambiamento, non è necessario sia la maggioranza, basta un manipolo di cambiatori. Poi vanno individuati i gangli di controllo dell’organizzazione che si vuole cambiare e bisogna distruggere fisicamente questi centri di potere. Per farlo, ci vogliono i cambiatori che vanno infilati lì dentro, dando ad essi una visibilità sproporzionata rispetto al loro status aziendale, creando quindi malessere all’interno dell’organizzazione dei gangli da distruggere. Appena questo malessere diventa sufficientemente manifesto, si colpiscono le persone che si oppongono al cambiamento, e la cosa va fatta nella maniera più plateale e manifesta possibile, sicché da ispirare paura o esempi positivi nel resto dell’organizzazione. Questa cosa va fatta in fretta, con decisione e senza nessuna requie, e dopo pochi mesi l’organizzazione capisce, perché alla gente non piace soffrire. Quando capiscono che la strada è un’altra, tutto sommato si convincono miracolosamente e vanno tutti lì. È facile.”