Cosa fa un’organizzazione?
Ci sono due attività fondamentali in qualsiasi organizzazione: processi ripetitivi e nuove iniziative (progetti).
Dovrebbe essere chiaro ormai che le Organizzazioni sono intrinsecamente Sistemi:
“una rete di persone e risorse interdipendenti che lavorano in processi e progetti per raggiungere un obiettivo comune”.
È fondamentale essere consapevoli che processi e progetti sono collegati e, per essere in grado di gestire il Sistema, è ugualmente fondamentale essere consapevoli che è necessario capire la natura di questo collegamento.
Possiamo definire un PROCESSO come un insieme di attività ripetitive che seguono una determinata procedura.
Un PROGETTO, invece, è un tipo particolare di processo: è l’insieme delle azioni che devono essere svolte da risorse/competenze che sono necessarie per soddisfare specifiche che spesso vengono stabilite da un cliente in tempi stabiliti e all’interno di un budget concordato.
Usiamo il seguente sistema come esempio. Possiamo pensare a ciascuna casella del Sistema come a un centro di competenza che rappresenta le principali competenze necessarie per sostenere il flusso delle attività.
Per ogni riquadro potremmo disegnare un diagramma di flusso per illustrare le interdipendenze coinvolte:
La domanda quindi diventa: come possiamo creare la connessione e la transizione dai processi ripetitivi in un’organizzazione alla creazione e gestione dei progetti necessari per raggiungere l’obiettivo dell’organizzazione?
In linea di principio, potremmo scegliere un insieme di risorse dai processi, assegnarle a ciascuna attività del progetto e quindi pianificare il progetto in base alla disponibilità delle risorse. Potrebbe sembrare una soluzione semplice. Sfortunatamente, questa “soluzione” si affida a un modo di pensare che possiamo definire “pensiero lineare” (dove la reazione è proporzionale all’azione).
A volte può funzionare, il più delle volte non funziona. Siamo di fronte a un problema di complessità, in cui le interazioni non lineari svolgono un ruolo importante.
Progetti e complessità
Le organizzazioni sono sistemi complessi e le persone che lavorano al loro interno vivono e si evolvono in un ambiente complesso.
La complessità non può essere né semplificata né eliminata. In un’organizzazione, dobbiamo imparare ad abbracciare, convivere con e gestire la complessità. Abbiamo bisogno di un approccio guidato da un “pensiero non lineare” (dove una reazione non è proporzionale all’azione).
Questo pone molte sfide per le organizzazioni. In generale, c’è poca o nessuna consapevolezza della complessità e delle sue implicazioni nel business e nella gestione. Sicuramente manca nel mondo tradizionale del Project Management. Di conseguenza, abbracciare la complessità diventa un problema di conoscenza ma anche un problema di gestione dei problemi cognitivi ed emotivi connessi con l’adozione di un modo di gestire l’adattamento alla complessità. Questa è la sfida rappresentata dal passaggio dai Processi ai Progetti.
Il Dr. Eliyahu Goldratt, che ha sviluppato la Teoria dei Vincoli, ha affrontato il problema del Project Management da una prospettiva paradigmatica e ha sviluppato una soluzione sistemica rivoluzionaria che ha chiamato Critical Chain. Nel nostro lavoro, abbiamo portato la soluzione Critical Chain a livello di organizzazione invalidando l’assunto che i progetti siano programmati in base alle risorse disponibili. Nel nostro lavoro, ci focalizziamo sulle competenze disponibili.
Progetti e competenze
Al livello più elementare, la domanda che la Teoria dei Vincoli (TOC) affronta è: cosa possiamo fare con ciò che abbiamo? Come possono le nostre risorse generare il valore più sostenibile? Quando parliamo di individui, la domanda diventa: come possiamo massimizzare il valore che le persone portano al Sistema?
Noi crediamo che, insieme alla loro ingegnosità e passione, il valore più alto che le persone portano alle loro organizzazioni si trova nelle loro competenze. Queste competenze sono sia quelle che possiedono attualmente sia quelle che possono acquisire.
Le competenze non si limitano a ciò che le persone scrivono nei loro CV, ciò che hanno studiato, la loro esperienza lavorativa, ecc. Ad esempio, le persone in contabilità potrebbero facilmente svolgere compiti relativamente semplici che sono completamente estranei alle loro attività quotidiane, come supportare le vendite nell’estrazione e nell’ordine di un elenco di clienti da un database secondo un criterio definito. È importante capire che questo tipo di collaborazione sistemica sarebbe impossibile in un’organizzazione “a silo”. Sarebbe percepito come un disturbo, una “sottrazione” di risorse dalla funzione aziendale a cui “appartengono”. In un’organizzazione funzionale l’unica ottimizzazione possibile è locale, NON globale.
L’esempio di attività del database sopra riportato potrebbe facilmente rappresentare un’attività in un progetto in cui le competenze sono associate a singoli individui; questo è ciò che facilita il Coinvolgimento in quanto consente alle persone di esercitare le proprie competenze in un contesto molto più ampio rispetto ai confini artificiali di una funzione aziendale ed è il catalizzatore per l’implementazione di un‘organizzazione veramente sistemica.
Il diagramma illustra il modo in cui le competenze sono associate a ogni attività da pianificare in un progetto.
Questo è il primo passo verso il superamento dei limiti intrinseci di una gerarchia convenzionale: le competenze sono associate agli individui invece di essere pescate da una funzione aziendale a cui “appartengono”. Un’organizzazione sarà popolata con risorse che hanno varie competenze. Una volta mappate le competenze di ciascuna risorsa, possiamo anche identificare i diversi livelli di competenza che la risorsa possiede, ad esempio livello alto, livello medio o livello basso.
I livelli di competenze aprono nuove opportunità di flessibilità nel modo in cui programmiamo le attività di un progetto. Una risorsa tradizionalmente assegnata al “Centro di competenza A” avrà un alto livello di “Competenza A”, ma potrebbe anche possedere un basso livello di “Competenza B”. Se un’attività in un progetto non richiede il livello più alto di competenza B, possiamo utilizzare la risorsa con un livello inferiore di competenza B, anche se tale risorsa appartiene al centro della competenza A. Se richiediamo la competenza B, non abbiamo sempre bisogno di cercare la risorsa nel centro di competenza B. Possiamo cercare il giusto livello di competenza B disponibile ovunque nel sistema al momento richiesto.
Questo è fondamentale in un ambiente multi-progetto in quanto libera capacità che altrimenti non verrebbero utilizzate e facilita la moltiplicazione di progetti che possono essere gestiti contemporaneamente.
