Make vs Buy decisione finale

Meglio ‘make’? Maglio ‘Buy’? ho sentito tantissime opinioni a riguardo, ogni approccio ha i pro e i contro. C’è uno e un solo elemento fondamentale per dirimere la scelta. Prima di entrare sul ring è opportuno presentare i due contendenti, prima un excursus sui pro del ‘make’, poi un excursus sui pro del ‘buy’ e infine il match, quando vince uno, quando vince l’altro.

Il Make

I vantaggi dell’approccio ‘make’

  1. Controllo Totale sulla Qualità: Uno dei principali benefici di produrre internamente è il controllo totale sulla qualità. L’azienda ha il potere di definire gli standard di qualità desiderati e di garantire che vengano rispettati in ogni fase del processo di produzione. Questo controllo permette di evitare sorprese legate a prodotti o servizi di bassa qualità che potrebbero derivare da fornitori esterni.
  2. Protezione della Proprietà Intellettuale: La produzione interna consente di proteggere meglio la proprietà intellettuale dell’azienda. I segreti commerciali e le innovazioni possono essere tenuti al sicuro, riducendo il rischio di divulgazione non autorizzata che potrebbe verificarsi quando si condivide la produzione con fornitori esterni.
  3. Maggiore Personalizzazione: La produzione interna consente all’azienda di personalizzare i prodotti o i servizi in base alle esigenze specifiche dei clienti. Questa capacità di adattamento può portare a relazioni più solide con i clienti e a una maggiore fedeltà verso il marchio.
  4. Creazione di Competenze Interne: Il processo di produzione interna implica lo sviluppo di competenze e know-how all’interno dell’organizzazione. Queste competenze diventano un vantaggio competitivo, consentendo all’azienda di essere più autonoma e meno dipendente da fornitori esterni.
  5. Flessibilità di progettazione: Variazioni in corso d’opera di specifiche tecniche possono avvinare con una maggior flessibilità perché viene bypassata la fase di trattativa con il fornitore esterno per le variazioni di specifiche.

Tutto ciò che non è un vantag

In sintesi, l’approccio “make” offre una serie di vantaggi che possono migliorare la competitività e la resilienza di un’azienda. Tuttavia, è importante sottolineare che la decisione di produrre internamente non è sempre la scelta migliore in ogni situazione. È necessario valutare attentamente i costi, i benefici e i rischi associati a questa strategia alla luce delle circostanze specifiche dell’azienda e del mercato in cui opera. La scelta tra “make” e “buy” dovrebbe essere basata su un’analisi completa e mirata.

I falsi miti del ‘make’

  1. Flessibilità Operativa: Spesso sento dire che la produzione interna offre maggiore flessibilità operativa. Un’azienda può adattarsi rapidamente alle mutevoli esigenze del mercato, apportando modifiche ai prodotti o ai processi in tempi brevi. Nella realtà non è così, o è alido solo in alcuni contesti mirati. Se ho una determinata modalità operativa e con l’uso di alcuni strumenti, per cambiare modalità operativa dovrò sostituire gli strumenti (a volte non sempre). La flessibilità potrebbe quindi non essere sempre vera, ve distinta dalla flessibilità di progettazione.
  2. Risparmio a Lungo Termine: Sebbene l’investimento in infrastrutture e risorse per la produzione interna possa sembrare inizialmente costoso, nel lungo termine può portare a notevoli risparmi. Un’azienda può ammortizzare gradualmente questi costi e ridurre le spese associate all’acquisto esterno. Inoltre, evita costi nascosti legati alla gestione dei fornitori, come le negoziazioni contrattuali e le dispute sulla qualità. Questa è la tesi, ma come per la modalità operativa potrei trovare un fornitore maggiormente verticalizzato su prodotto e quindi con consti di produzione molto più bassi di quelli interni.
  3. Miglior Gestione del Rischio: La produzione interna può ridurre il rischio associato a interruzioni nella catena di approvvigionamento. Le situazioni di crisi, come interruzioni delle forniture o cambiamenti nei mercati globali, possono avere un impatto minore quando l’azienda è in grado di controllare direttamente il processo produttivo. Questo è un’altro falso mito, spesso la riduzione del rischio comporta una rosa più ampia di fornitori che sopperiscano ad eventuali carenze ed evitino il vendor lockin.
  4. Efficienza Logistica: Riducendo la dipendenza da fornitori esterni, un’azienda può semplificare la gestione della logistica e delle spedizioni. Questo può portare a una catena di approvvigionamento più efficiente, riducendo tempi di consegna e costi di trasporto. Questa l’ho sentita e dimenticata per poi ricordarmene mentre scrivevo. Questa posizione è valida alcune volte, errata il più delle volte. In genere per produrre un bene occorrono diversi fornitori, acquistare il bene richiede un unico fornitore.

Il Buy

I vantaggi dell’approccio ‘buy’

  1. Riduzione dei Costi Iniziali: Un vantaggio chiave dell’approccio “buy” è la possibilità di evitare costi di investimento iniziali elevati. Le aziende possono risparmiare notevoli somme di denaro non dovendo acquistare o costruire infrastrutture, attrezzature e competenze interne per produrre internamente. Questo può liberare risorse finanziarie per altri scopi, come l’espansione, la ricerca e lo sviluppo o la diversificazione.
  2. Flessibilità nell’Adattarsi alle Fluttuazioni della Domanda: Acquistando da fornitori esterni, le aziende possono adattarsi più facilmente alle variazioni nella domanda. Possono aumentare o ridurre gli ordini in base alle esigenze del momento senza dover gestire il carico di lavoro interno. Questa flessibilità è particolarmente importante in settori con domande stagionali o variabili.
  3. Accesso a Competenze Specializzate: L’acquisto esterno consente alle aziende di accedere a competenze specializzate presenti nei fornitori. Questi ultimi spesso vantano una vasta esperienza e know-how nel loro settore, consentendo all’azienda di beneficiare di migliori pratiche, innovazioni e qualità superiori senza dover sviluppare tali competenze internamente.
  4. Concentrazione sul Core Business: Acquistando beni e servizi da fornitori esterni, le aziende possono concentrarsi maggiormente sul loro core business. Questo significa che possono allocare più tempo ed energia per sviluppare prodotti, servizi e strategie di mercato che generano un vantaggio competitivo reale.
  5. Riduzione del Rischio Operativo: La produzione interna può comportare rischi operativi significativi, come problemi di capacità, costi imprevisti e obsolescenza tecnologica. L’approccio “buy” può ridurre questi rischi, in quanto l’azienda non è direttamente responsabile di tali aspetti e può spesso ottenere contratti con garanzie di servizio.
  6. Velocità di Entrata sul Mercato: L’acquisto esterno può accelerare l’ingresso sul mercato o l’aggiunta di nuovi prodotti o servizi all’offerta dell’azienda. Questa velocità può essere cruciale per sfruttare le opportunità di mercato o per rispondere rapidamente alle richieste dei clienti.
  7. Minore Gestione Operativa: L’acquisto esterno spesso comporta una minore complessità nella gestione delle operazioni quotidiane. L’azienda può concentrarsi sulla supervisione dei fornitori, piuttosto che sulle operazioni dettagliate, riducendo la necessità di gestire una vasta forza lavoro interna.

Gli svantaggi dell’approccio ‘buy’

  1. Dipendenza da Fornitori Esterni: L’acquisto da fornitori esterni può creare una dipendenza da terze parti per il rifornimento di beni o servizi critici. Se il fornitore principale riscontra problemi o non riesce a soddisfare le esigenze dell’azienda, ciò può avere un impatto significativo sulle operazioni. L’approccio ‘buy’ è ad alto rischio di vendor lockin e la gestione dei contratti con i fornitori può richiedere tempo ed energie significative. Errori nella negoziazione o nell’esecuzione dei contratti possono portare a dispute legali o a costi aggiuntivi.
  2. Perdita di Controllo: L’azienda può perdere una certa quantità di controllo sui processi operativi e sulla qualità quando si affida a fornitori esterni.Gli effetti sono :
    • Rischio di Qualità e Affidabilità del Fornitore: L’azienda non ha un controllo diretto sulla qualità e sull’affidabilità dei fornitori. Se un fornitore esterno non rispetta gli standard di qualità o non soddisfa gli accordi contrattuali, possono sorgere problemi di qualità dei prodotti o dei servizi.
    • Perdita di Know-How Interno: L’outsourcing di servizi o produzione può comportare la perdita di competenze e conoscenze interne, rendendo l’azienda più dipendente dai fornitori esterni
    • Perdita del vantaggio competitivo: Se il vantaggio competiti6ov è legato ai prodotti acquistati in ‘buy’ c’è il rischio di perdita di vantaggio competitivo e di divulgazione di informazioni riservate.

I falsi miti del ‘buy’

Riduzione dell’Impatto Ambientale: In tempi recenti, in cui l’impatto ambientale e le tematiche ESG sono rilevanti, ho sentito dire che il buy riduce l’impatto ambientale. In alcuni casi, l’acquisto da fornitori esterni può contribuire a ridurre l’impatto ambientale complessivo dell’azienda. Questo non sempre è vero ed è una specificità del fornitore, non lo citerei come vantaggio del ‘buy’

Non ho trovato altri ‘falsi’ del approccio buy.

Il match Make vs Buy

Vista così sembra una battaglia impari, il buy ha veramente tanti, ma tanti vantaggi in più, il Make è semplicemente più complesso, più costoso.

Quando vince il ‘Make’?

C’è una sola risposta valida che supera ogni altra considerazione (compresi i costi), quando il prodotto su cui si opera la scelta è strategico ed incorpora uno o più elementi differenzianti che costituiscono il vantaggio competitivo dell’azienda.

La domanda che l’azienda deve porsi prima di decidere se optare tra Make e Buy è “quanto vantaggio competitivo risiede nel prodotto’.

in ambito informatico questa scelta può sembrare semplice ma non lo è. Un sistema di CRM può essere elemento differenziante o lo sono i processi che metto in piedi. Il gestionale per le polizze è elemento differenziate per una compagnia assicurativa o lo sono le polizze che vendo. Per entrambe la risposta è la seconda, ossia l’aspetto di business.

Per entrambe vale la pena fare una considerazione che potrebbe ribaltare lo scenario. Nell’ambito del CRM voglio offrire un servizio innovativo in grado di sfruttare un nuovo come le OBU (on board unit). Se adotto una soluzione buy, l’innovazione diventerà subito disponibile anche ai miei concorrenti. In modo similare se voglio creare un nuovo prodotto assicurativo che necessità di logiche applicative e integrazioni specifiche queste logiche diventeranno facilmente disponibili ai concorrenti.

Compilare una RACI

Compilare una matrice di responsabilità RACI sembra molto semplice ed intuitivo, eppure nasconde alcuni tranelli in cui c’è il rischio di cadere. Una RACI compilata correttamente aiuta a definire le responsabili, quindi gli interlocutori corretti. Una RACI sbagliata crea entropia e fraintendimenti. Alcune regole di base aiutano a definire una RACI in modo tale che la RACI sia di aiuto e supporto alle attività progettuali. L’acronimo sta per:

(R)esponsible: Colui che è responsabile operativamente dell’esecuzione dell’attività, diversi attori possono essere Responsible

(A)ccountable: Colui che ha le leve operative per far si che i (R)esponsible possano portare a termine il lavoro e colui che prende le decisioni in merito all’attività.

(C)onsulted: E’ un soggetto che viene consultato, spesso in qualità di esperto della materia (es: SME – Subject matter expert). Non svolge attività operativa, si limita a dare suggerimenti se interpellato

(I)nformend: E’ un soggetto che DEVE essere informato sul evolversi delle attività. Non ha leve dirette sul progetto, ma la sua influenza può essere di ostacolo o beneficio per il progetto

Regola 1 – Un solo (A)ccountable per attività

Una matrice RACI ha un solo accountable, ed è colui che prende le decisioni in merito all’attività che deve essere portata a termine. Vale sempre la regola di base che la responsabilità di una decisione è personale. Chi deve prendere una decisione può appoggiarsi a un team di esperti, avvalersi di comitati o anche fare delle votazione. La responsabilità della decisione rimane personale indipendentemente dal metodo scelto. (Qui si sarebbe molto da dire in merito alla responsabilità individuale e di come molti sfruttino dei comitati per de-responsabilizzarsi.) A differenza del (A)ccountable, i (R)esponsible possono essere diversi e sono i soggetti che lavorano sull’attività, gli esecutori.

Regole 2 – La giusta granularità di attività

Una matrice RACI viene sempre scritta per uno scopo ben preciso. In funzione dello scopo la RACI può avere un diverso livello di dettaglio delle attività. Esattamente come per le WBS si può rimanere a un livello molto alto o scendere a un livello di dettaglio esasperato. La granularità molto spinta fa si che ogni responsible possa diventare l’ Accauntable del livello inferiore. Pensiamo un team che esegue dei test, avremo un accountable per tutta la parte dei test, ossia colui che prende le decisioni sui test. Avremo più esecutori (R), ossia le persone che eseguono i test. Ciascuno di essi diventa responsabile (A) per la propria attività entrando nel livello di attività che seguono. In questo modo avremo avremo un responsabile (A) per i test funzionali, per i test di integrazione quelli di performance. Il punto delicato è capire a che livello fermarsi nel dettaglio delle attività rappresentate in una RACI. In genere la scelta migliore è sempre il compromesso, una RACI da allegare un contratto tenderà a essere di alto livello. Il project manager ne predisporrà una in cui rappresenta i principali riporti e stakeholder, in queste RACI si trova spesso il nome del team di riferimento più che il nome di una persona, indicavo in questo modo che la responsabilità (A) è in capo al team leader. Ogni team del progetto può predisporre una RACI nominativa per le proprie risorse.

Regola 3 – I soggetti corretti

Come per le attività anche i soggetti presenti nelle RACI possono essere rappresentati a diversi livelli. Nel livello più alto, anche qui usato nei contratti, i soggetti sono le società che partecipano al contratto o al progetto. Ogni società andrà poi a creare una propria RACI in cui rappresenta le responsabilità di diversi team coinvolti nelle attività e ciascun team organizzerà (se occorre) delle RACI in cui i soggetti sono i nomi delle risorse. La scelta della granularità dei soggetti è legata prevalentemente allo scopo per cui viene scritta la RACI. Più si scende di livello nelle attività più i soggetto sono gruppi sempre più ristretti fino ad arrivare al nominativo di una risorsa.

Un esempio sbagliato

Mi è capitato di vedere la matrice qui di seguito riportata come allegato a un contratto:

Il pallino nero indica il fornitore, il pallino rosso indica il cliente. Si tratta quindi di una matrice di alto livello e ha come obiettivo quello di definire le responsabilità delle due società. La matrice contiene diversi errori, il primo errore evidente è che nella colonna accountable in alcuni casi sono presenti due soggetti, sia il cliente che il fornitore. Il doppio accountable è sempre da evitare perché la responsabilità delle decisioni non mai congiunta. Il secondo errore è nella colonna (R), ossia chi esegue operativamente l’attività. In una RACI che definisce le responsabilità cliente/fornitore il fornitore non ha (praticamente mai) leve per far fare al cliente delle attività funzionali al progetto. Il fornitore non può infatti pretendere di avere la disponibilità delle risorse cliente nei momenti in cui servono (es: testing della RACI). Per questo motivo il fornitore non può essere accountable per attività in cui responsible è il cliente. Se si verifica realmente una situazione di questo tipo avremo uno scarso commitment del cliente e un rischio altissimo (quasi certezza) di fallimento del attività. Attenzione, può valere l’opposto, il cliente è accountable per attività di cui è responsible il fornitore. Esempio palese è l’attività time & material. Responsabilità cliente risorse fornitore. Il terzo errore è nell’attribuzione della responsabilità (accountable) errata, ossia il fornitore si assume la responsabilità di attività per le quali non ha alcun tipo di leva operativa, come ad esempio la ‘roll out strategy’.

La RACI che abbiamo appena visto ed allegata ad un contratto porta a dire che il rapporto cliente/fornitore non è chiaro. In particolare l’aspettativa del cliente è che il fornitore si assuma la responsabilità per ogni aspetto progettuale, anche quelli su cui obiettivamente non può intervenire. La stessa RACI ci dice che il fornitore è in una posizione di debolezza ed è disposto ad accertare condizioni inaccettabili pur di aggiudicarsi la commessa. Pessimo presupposto progettuale.

Rispondere alle RFI

Arriva in azienda un richiesta di informazioni da parte di un cliente, la classica RFI. La macchina commerciale si mette in motto, account, commerciali, sales, presale, team tecnici si mettono al lavoro per rispondere al cliente e superare il primo scoglio: la qualificazione per arrivare alla gara, la famigerata RFP. Come rispondere? Che taglio dare? Mostrarsi capaci, validi e poco costosi è un must, ma proporre la luna per 4 noccioline ha senso? E’ efficace?

Come funzionano le RFI viste dal cliente? Che obiettivi ha il cliente? In genere una RFI serve al cliente per avere un’idea di massima della fattibilità tecnica, sostenibilità economica di un progetto oltre all’individuazione dei fornitori che parteciperanno a una gara. Se il cliente ha già le idee chiare procede con una gara senza perdere tempo con una RFI. Quindi in genere, sottolineo in genere, l’RFI contiene alcune idee e spunti che il cliente vuole portare avanti e chiede ai fornitori aiuto per dare concrettezza alle idee. Per il cliente un’RFI è un modo veloce per scremare i fornitori e individuare quelli che meglio capiscono le esigenze e che propongono soluzioni fuori dagli schemi. Quest’ultimo punto è secondo fondamentale. Nel ruolo “da cliente” non ho mai proposto RFI su temi già noti. Non ha senso ad esempio inviare ai fornitori un’RFI per un CMS, a meno che il CMS in questone debba avere caratteristiche innovative.

Per il fornitore l’ansia da prestazione può essere forte, soprattutto su clienti nuovi. La tentazione di rispondere in modo affermativo ed esagento a qualsiasi domanda è forte. Partendo dal presupposto che nella tecnologia e in particolare informatica si può fare qualsiasi cosa, la risposta che non sarebbe neanche tanto scorretta. Confezionando le frasi nel modo corretto con ‘si può fare’, ‘la piattaforma è predisposta’, ‘abbiamo esperienza’ si riesce a proporre qualsiasi cosa, anche la luna. Avere una quotazione di massima sensata durante un RFI è quasi impossibile. In genere le informazioni richieste dal cliente sono molto generiche e offrono spazio per diverse proposte di soluzioni. La risposta corretta dovrebbe essere da tanto a poco, con una forbice enorme legata all’assenza di requisiti di dettaglio. stesso per una eventuale pianificazione delle attività.

Ovviamente ognuno risponde a un RFI come meglio ritiene opportuno e ho visto RFI (ma anche RFP) in cui la luna veniva proposta per 4 noccioline e i costi di progetto che lievitano in modo esponenziale. La risposta a un RFI deve contenere gli spunti di innovazione che il fornitore può al cliente, evidenziare in modo chiaro gli asset presenti e idee che devono essere sviluppate insieme (a 4 mani con il cliente), un indicazione di quando può durare e ha senso che costi e duri un’iniziativa progettuale basandosi su esperienze analoghe e senza calare questa valutazione sul contesto specifico perché ovviamente non ha senso per assenza di un requisito chiaro.

Per me l’obiettivo della risposta è fornire elementi al cliente per capire se c’è un match tra le sue idee e l’impostazione del fornitore. Arrivare a partecipare alla gara deve essere la conseguenza del ‘match’ cliente/fornitore, non l’obiettivo della risposta al RFI. E’ una sottile differenza ma molto importante. Rispondere al RFI con l’obiettivo di arrivare alla gara porta il fornitore a proporre la luna per 4 noccioline. La risposta dovrebbe essere chiara e trasparente e basata su ciò che il fornitore è in grado fare e non esclusivamente sulle aspettative del cliente. Aggiungerei anche breve, la risposta deve essere breve. Va sempre ipotizzato che il cliente ha inviato all’RFI a diversi fornitori, più di quelli che partecipano a una gara, a volte anche più di 10. L’obiettivo del cliente è chiarirsi le idee velocemente per definire il contenuto di una gara. Se le risposte sono lunghe e confuse vengono archiviate velocemente.

Aspettative e requisiti

A volte con disappunto il cliente comunica che il risultato non soddisfa le aspettative, eppure tutti i requisiti tracciati nelle fasi preliminari sono stati correttamene implementati e accettati dal cliente.

Quello descritto è un rischio molto concreto dell’approccio tradizionale waterfall su progetti di carattere innovativo. Le macro fasi tipiche waterfall prevedono: analisi, disegno, implementazione e test (più altre non rilavanti per l’argomento). Nella fase di analisi dei requisiti l’interazione cliente/fornitore è molto intensa ed è il momento in cui il cliente trasmette al fornitore le proprie necessità e aspettative. Questa fase inizia con un processo più o meno formale in cui il cliente comunica “cosa” si aspetta che il sistema faccia e termina con un processo formale in cui il fornitori descrive “come” intende implementare le richieste cliente. Il documento che descrive “cosa” si aspetta il cliente, ossia le aspettative del cliente, è il documento dei requisiti. Il documento che descrive “come” viene implementato il requisito è il documento di analisi tecnico-funzionale.

Si arriva alla fine dello sviluppo e l’amara sorpresa per cliente e fornitore è che il sistema sviluppato non soddisfa le aspettative. I costi per risolvere una situazione come questa sono molto alti, occorre mettere in campo numerosi giorni uomo per smontare quanto implementato e implementare in modo diverso. La ricerca delle “responsabilità” diventa quindi una missione per cliente e fornitore.

L’origine di questa situazione è legata a queste due situazioni:

  1. Il cliente non ha espresso i requisiti con sufficiente dettaglio. Il livello di dettaglio dei requisiti è fondamentale e anche nella vita quotidiana e un approccio superficiale può mettere in difficoltà. Immaginate di voler comprare una macchina, descrivete ogni singolo dettaglio vi viene in mente, colore, optional, motorizzazione… ma non esprimete nulla sulla ruota di scorta. Date per scontato che arrivi il kit riparazione e invece arriva il ruotino.
  2. L’analisi non è sufficientemente dettagliata per consentire al cliente di capire gli impatti e le implicazione di quello che verrà implementato. Nel esempio di prima supponiamo che il cliente specifica anche che desidera il kit di riparazione, perché sa che è più pratico. Quando riceve il veicolo scopre che i tagli non possono essere riparati con il kit riparazione, si aspettava di poter risolvere qualsiasi foratura.

Al di là della responsabilità formale, ciò che vorremo è evitare che si presenti una situazione di macato soddisfacimento delle aspettative. Il problema si presenta soprattutto nei progetti waterfall e si accentua se il progetto ha carattere di innovazione per il cliente. L’innovazione infatti non consente al cliente di mettere a fuoco tutti gli aspetti del nuovo sistema, soprattutto gli impatti sui processi interni, ruoli e attività. Il requisito diventa spesso vago e molto generico con repentini cambi di idea e prospettiva. E’ qui che il fornitore dovrebbe intervenire con un approccio Agile, scomponendo il progetto in Sprint, con time frame limitati aiuta focalizzare su singole tematiche più gestibili. Inoltre al termine dello Sprint abbiamo un risultato tangibile da condividere con il cliente.

La principale critica a quest’approccio è la poca visibilità di insieme e il fatto che potrebbero essere necessari numerosi re-work con conseguente aumento dei costi. La seconda critica mossa è la difficoltà se non impossibilità ad avere una stima dei costi complessivi e del tempi necessario. In effetti entrambe le critiche sono corrette in un progetto Waterfall guida lo scope/perimetro, il tempo e i costi ne sono una conseguenza del perimetro. E’ bene ricordare sempre che un approccio Waterfall si applica bene (leggesi: rispetto tempi, costi) solo se il perimetro di progetto è ben definito, dettagliato e con poche variazioni nel tempo.

In un progetto Agile i dati certi sono la durata di uno Sprint e la composizione del team, tutto il resto è flessibile e viene determinato al proseguire delle attività. Questa flessibilità ha il vantaggio di ridurre il rischio di arrivare a fine lavoro e scoprire che la soluzione non soddisfa le aspettative, consente di effettuare cambi di direzione in corsa e rende quasi impossibile una stima del impegno complessivo a inizio lavori.

RACI: Accountable vs. Responsible

Un limite tutto italiano

Una delle digressioni più comuni sulle matrici RACI riguarda la distinzione tra Accountable e Responsible, entrambi termini vengono tradotti in italiano come “responsabile”. Questo spesso genera confusione anche perché non sempre viene fatta chiarezza e nelle discussioni ci si dimentica di usare i termini inglesi durante. L’equivoco è dietro l’angolo e rischia di infiammare gli animi. Basta la domanda o l’affermazione interpretabile: “Sei tu il responsabile dell’attività XYZ?” e la miccia difficile da spegnere è innescata.

Chi ha un minimo di basi sa che una matrice RACI ammette un solo “Accountable”,  la persona con il compito di decidere e approvare il lavoro, e molti “Responsible”, le persone che materialmente eseguono il lavoro. Nel caso di un cantiere edile il capo cantiere è la persona “Accountable”, mentre i muratori sono “Responsible”. Il primo è responsabile per l’esito del lavoro, i secondi sono responsabili nel eseguirlo. Se l’attività non è eseguita correttamente il primo ad accorgersene deve essere l’ “Accountable” ed è la persona che interviene se i “Responsible”, ovvero chi esegue il lavoro non lo fa correttamente.

Ecco, tutto questo in italiano è molto più complesso da esprimere perché mancano i termini adeguati. Il capo cantiere è responsabile, ma lo sono anche i muratori. La sottile differenza tra decisore ed esecutore viene a mancare quando si parla di responsabilità.

Può sembrare una banalità ma questo ha diverse ripercussioni pratiche. L’assenza nel linguaggi di questa distinzione porta i responsabili “Accountable” e i responsabili “Responsible” a sentirsi meno responsabili gli uni per le decisioni da prendere, gli altri nell’esecuzione dell’attività. Di fatto si creano degli alibi. Parlando con chi è accountable ricevo spesso delle risposte “ma sono loro responsabili per l’attività, perché chiedi a me” e dall’altro lato parlando con chi è “Responsible” ricevo come risposta il rovescio della medaglia “perché chiedi a noi è il responsabile dell’attività, noi siamo esecutori facciamo quello che ci viene detto di fare”.

In realtà a ben vedere il limite non è solo linguistico, è un limite mentale, per gli italiani in una RACI il“Responsible” e“Accountable” sono la medesima cosa. Noi italiani prediligiamo il “one man show”, la piccola imprenditoria in italia dilaga anche per questo.

WP to LinkedIn Auto Publish Powered By : XYZScripts.com