A caccia di competenze
Home > News > A caccia di competenze

A caccia di competenze

14 giugno 2018

Nelle organizzazioni contemporanee l‘organizzazione funzionale lineare è diventata obsoleta e diventa sempre più urgente sostenerla con la capacità di organizzare e gestire gruppi di lavoro. Per questo l’approccio top-down nella definizione dei ruoli e delle mansioni è perdente rispetto ad un approccio bottom-up che apra a tutti i membri di un’organizzazione la possibilità di fornire alla stessa informazioni utili al loro impiego produttivo.

 

A cosa dovrebbe servire un sistema di gestione delle competenze?

Non mi riferisco ad un sistema software (che può esser la parte attuativa dello stesso), ma ad un sistema inteso in senso più largo, ovvero un insieme di elementi relazionati e organizzati in una struttura funzionale unitaria.

La maggior parte degli specialisti in risorse umane risponderà con prontezza “a chiarire chi deve sapere/saper fare cosa”. Ma siamo sicuri che questo scopo sia davvero quello più interessante? Siamo sicuri che le organizzazioni moderne abbiano davvero questa necessità di definire “a priori” quali siano le competenze richieste in ogni ruolo e, pertanto, quali siano le competenze necessarie ad ogni risorsa per ricoprirlo?

La risposta, nella maggior parte dei casi è “No”! Le aziende spesso sentono il bisogno di definire chi debba fare/sapere/saper fare cosa. Ma è un bisogno dettato più dalla smania di controllo che dall’effettiva necessità pratica. Gli stessi ruoli, nella maggior parte delle aziende, sono spesso convenzioni abbastanza formali per cui capita sempre più spesso che ad una mostrina appuntata sul bavero della giacca non corrisponda l’effettivo insieme di funzioni svolte dalla persona nell’organizzazione stessa.

Inoltre, le aziende di servizi (e anche i dipartimenti delle aziende industriali che erogano servizi agli altri enti interni) lavorano adattandosi ad un ambiente economico in continua evoluzione. Per questo hanno adottato forme di organizzazione più flessibili in cui la dipendenza gerarchico/funzionale è affiancata o, addirittura, sostituita da un’organizzazione per gruppi di progetto. Questa struttura detta spesso “a matrice”, intendendo l’aspetto che assume quando viene rappresentata in un piano cartesiano ponendo le risorse su di un asse e i progetti attivi su di un altro, presuppone che il ruolo “giocato” da ciascuna risorsa possa continuamente cambiare. Non solo nel corso del tempo, ma anche nella stessa giornata, quando la risorsa stessa è chiamata, per esempio, a interagire all’interno di un gruppo di lavoro al mattino e di un altro al pomeriggio.

Capita così che la stessa persona possa essere parte dello staff di un progetto coordinato dal suo capo funzionale e di un altro coordinato da un leader che non fa parte del suo ente tecnico e a cui partecipa come rappresentante della funzione del suo ente, possa essere a sua volta leader di un altro team di progetto sugli argomenti di cui è molto esperto e neofita aggregato ad un altro team nel quale dovrà semplicemente apprendere “on the job” competenze che ancora non possiede.

La gestione delle competenze come requisiti di una mansione, in questi contesti, è del tutto inutile poiché, di fatto, non esistono mansioni. Al contrario, può essere utile mappare i requisiti di partecipazione ai progetti, in maniera da poter definire se una risorsa può essere utile o meno all’interno di un team progetto.

 

competenze trasversali

 

Valutazione di conformità e definizione dei requisiti

Anche se i due approcci possono sembrare simili, essi hanno, in realtà, implicazioni che li rendono profondamente diversi. Mentre la valutazione di conformità ad una mansione viene promossa dai dipartimenti Risorse Umane per tenere sotto controllo la forza lavoro dell’organizzazione (sarebbe meglio dire per “dimostrare di avere sotto controllo”), una definizione dei requisiti di partecipazione ad un progetto e la relativa scelta dei componenti di un team in base al soddisfacimento degli stessi è un’attività continua che deve essere gestita dai leader dei progetti e, comunque, sotto l’egida degli enti operativi (le cosiddette “operations”), non certo del dipartimento Risorse Umane. Inoltre la valutazione delle competenze delle risorse, nel primo caso, viene fatta dai responsabili diretti (che, magari, non hanno il dominio di molte delle competenze richieste ai propri sottoposti, ma si ritiene che debbano almeno conoscerli), mentre nel secondo caso non può essere fatta dai capi-progetto, poiché essi probabilmente avranno il dominio delle competenze richieste dal progetto stesso, ma probabilmente non conoscono affatto la risorsa che deve essere valutata per decidere di una sua eventuale utilizzazione nel team di quel progetto.

Detto in altri termini, effettuare una mappatura delle competenze al fine di valutare nelle risorse la presenza dei requisiti di partecipazione ai progetti che vengono man mano attivati in un’organizzazione richiede un approccio operativo molto diverso da quello richiesto dalla valutazione periodica di conformità ad un ruolo e, precisamente:

  1. La definizione dei requisiti deve essere effettuata dal capo-progetto e non da uno specialista delle risorse umane;
  2. La valutazione delle competenze non avviene più solo da parte del responsabile funzionale, ma viene portata avanti in maniera continua da molteplici valutatori;
  3. Il mansionario viene affiancato e sostituito dal portfolio dei progetti e, di conseguenza, il catalogo delle competenze passa da un insieme finito ad un insieme potenzialmente infinito.

 

Queste tre caratteristiche assunte dal processo di mappatura delle competenze, applicato ad una organizzazione “a matrice”, trasformano completamente la finalità del processo e le sue implicazioni organizzative.

Partendo dal primo punto, quando la definizione dei requisiti richiesti ad una risorsa viene effettuata da un responsabile operativo, è evidente come questi diventino molto più specifici e tecnicamente circoscritti di quelli normalmente previsti dagli specialisti di Risorse Umane quando devono descrivere un ruolo. Ai capi-progetto di solito non interessano le competenze procedurali, ma quelle tecniche e quella parte delle competenze di base/trasversali direttamente applicabile nel gruppo di lavoro. Un’organizzazione che decida di mappare le competenze delle sue risorse con un orientamento ai progetti si troverà di sicuro ad avere una mappatura del suo know how molto più orientata al “saper fare”, piuttosto che al “sapere” e al “saper essere”.

Il fatto che, come sottolineato dal secondo punto, il “cliente interno” della mappatura sia potenzialmente ciascun capo-progetto (e non più il dipartimento Risorse Umane) porta anche alla necessità che la valutazione e la certificazione delle competenze di ciascuna risorsa sia realizzata da chi vede le stesse all’opera, ovvero dai capi-progetto dei progetti già conclusi. La mappatura diventa perciò un’attività continua, in cui ciascun capo-progetto è, allo stesso tempo, cliente e fornitore del processo di mappatura.

Questo processo circolare, che è difficile innescare (pensate alla situazione in cui si parta con questo tipo di organizzazione: nessun progetto è stato ancora svolto, quindi, per definizione, le risorse non possono essere state mappate su alcuna competenza e, pertanto, non vi sono elementi per poter definire la loro partecipazione ai team di progetto), può essere coadiuvato dall’istituzione all’interno dell’organizzazione di “gruppi professionali”, ovvero di gruppi di lavoro il cui scopo istitutivo non sia quello di raggiungere un obiettivo operativo, ma lo studio e lo sviluppo delle conoscenze su un tema di particolare interesse all’interno dell’organizzazione.

 

È, però, il terzo punto a caratterizzare maggiormente il processo di mappatura necessario ad una organizzazione “a matrice”. Dato che i progetti che l’organizzazione può essere chiamata ad affrontare non sono definiti a-priori, non si può pensare di dichiarare tutte le competenze necessarie al funzionamento ed al raggiungimento degli scopi dell’organizzazione. Il catalogo delle mansioni può essere conservato o meno, ma, anche in sua presenza, il catalogo delle competenze non potrà più essere costituito dalla somma delle competenze necessarie a far funzionare l’organizzazione. Dovrà, infatti, essere costituito potenzialmente dal totale delle competenze che potrebbero essere richieste o utili nei gruppi di progetto che potranno essere attivati. Pertanto, si tratterà di un insieme non più circoscritto e, potenzialmente infinito.

Dal punto di vista pratico, questo vuol dire che un catalogo di competenze di una qualsiasi organizzazione, in questa prospettiva, dovrebbe adesso comprendere qualsiasi competenza sia mai stata dichiarata finora in letteratura? Assolutamente no! Dovrebbe comprendere, però, tutte le competenze potenzialmente impiegabili nei progetti che potrebbero essere intrapresi in futuro. E che progetti potrà intraprendere un’organizzazione se non progetti per i quali ha le competenze necessarie?

Perciò, in maniera più pratica, un catalogo di competenze di un’organizzazione dell’era digitale dovrebbe assolutamente estendersi a coprire tutte le competenze significative in possesso delle proprie risorse, anche se queste non sono collegate ad una mansione oppure impiegabili in un progetto già noto.

Un esempio pratico

Facciamo un esempio per capire come questo assunto diventi immediatamente di buon senso (…e certo! Come avevo fatto a non pensarci?) una volta riportato su di un caso concreto.

Un’azienda che esporta prodotti verso i principali paesi europei avrà sicuramente fra le competenze delle sue risorse alcune competenze nelle principali lingue europee. Se non ha mai operato verso la Cina, non avrà previsto, invece, requisiti di conoscenza della lingua cinese. Se quest’azienda seguisse un approccio tradizionale, non rileverebbe la conoscenza del cinese mandarino in nessuno dei suoi impiegati, poiché questo requisito non è previsto in nessun ruolo (oppure non è mai stato richiesto in nessun team di progetto). Ma se arrivasse una commessa dalla Cina, le sarebbe invece molto utile coinvolgere nel team che seguirà quella commessa una sua risorsa che conosce la lingua. Anche se la lingua commerciale ufficialmente utilizzata dovesse essere l’inglese.

Come farà il capo-progetto della commessa dalla Cina a sapere che può contare su una o più risorse che parlano quella lingua se la competenza non è mai stata mappata perché il requisito non è mai stato dichiarato come tale?

Per questo è assolutamente fondamentale che, in un’organizzazione che voglia essere competitiva nell’era digitale, le competenze non vengano mappate secondo un disegno “top/down”, ma piuttosto secondo un approccio “bottom/up”, intento a rilevare le competenze che le persone a disposizione posseggono, a prescindere dal fatto che queste siano state sviluppate o vengano al momento utilizzate nei processi dell’organizzazione.

La mappatura delle competenze diventa pertanto non più la valutazione di una supposta conformità, ma un estimo, una sorta di censimento del capitale umano.

 

Alessandro Obino, CEO Exagogica

© Riproduzione riservata

Condividi





Scopri e leggi tutti i nostri articoli