Affrontare il Cambiamento Organizzativo: dal Problem Solving al Process Development

Quale manager non desidera che i propri collaboratori abbiano capacità di problem solving? E allo stesso tempo: quali collaboratori non desiderano che i propri manager abbiano capacità di problem solving? Questa locuzione inglese è entrata velocemente nel dizionario manageriale e pochi sono gli annunci e i colloqui di lavoro che non cercano di sondarne la presenza e, non meno di rado, di valutarla nel corso della carriera in azienda. E’ una di quelle competenze così dette trasversali che l’Unione Europea considera tra le basi della cittadinanza attiva e consapevole e, quindi, fondamentale già durante la scuola dell’obbligo.

Meno le aziende sono burocratizzate (con procedure e regole rigide) più questa capacità viene stimolata ed apprezzata a tutti i livelli organizzativi. Ci sono delle situazioni, però, in cui le realtà organizzate fanno i conti con il “lato oscuro” del problem solving: la sua incapacità di dare risposte efficaci quando gli elementi del problema sono molto numerosi, altamente variabili e hanno a che fare con il comportamento umano.

Proviamo a fare un esempio: i prodotti vengono costantemente consegnati in ritardo al cliente. Le diverse funzioni aziendali si “rimpallano” il problema: l’amministrazione lamenta l’arrivo di ordini poco chiari da parte dei commerciali, la produzione lamenta un sovraccarico, la logistica rimprovera la cattiva gestione degli ordini a monte. Ogni funzione organizzativa, ogni manager e ogni collaboratore, in base al ruolo che ricopre, dà una spiegazione e una visione del problema. Ognuno individua una o più cause e, spesso, non si concorda neanche su quale sia la principale. Oltre ad avere una visione della criticità molti hanno anche una soluzione: “ma basterebbe …”; “se solo….”. La logica del problem solving, davanti ad un caso del genere, ci porterebbe con passi lineari a definire meglio il problema per poi indagarne pedissequamente le cause (fino ad arrivare alla causa radice) e definire una soluzione da applicare e monitorare. A rigor di logica tutto funziona.

Peccato che ciascuno di noi ha fatto esperienza di come ci siano delle situazioni critiche a cui sono state applicate diverse e numerose soluzioni senza che il problema si risolvesse in modo totale e definitivo. Quando ad essere in gioco non sono solo elementi tecnici (il cui funzionamento non solo è analizzabile scientificamente ma anche chiaramente definibile nei mutamenti) ma anche le percezioni e i comportamenti umani l’approccio “definisci il problema – chiarisci le cause – trova una soluzione” spesso fallisce.

Non si tratta di un limite insito nel problem solving in sé come tecnica, quanto, piuttosto, nelle modalità in cui viene utilizzato nei contesti aziendali nonché in una sorta di deriva culturale: il “fast problem solving”.

Non solo cercare soluzioni ma anche trovarle rapidamente, in modo che siano immediatamente operative. La capacità di risolvere problemi l’abbiamo definita come una competenza base, le domande da porsi ora sono: quale competenza più avanzata ci occorre per affrontare situazioni la cui complessità non è neanche chiaramente definibile? Quando il comportamento umano è uno degli aspetti fondamentali per risolvere la criticità è efficace concentrarsi sulle diverse percezioni delle cause? Se non è facile definire tutte le variabili in gioco ha senso cercare soluzioni immediatamente applicabili?

Ciò di cui le aziende hanno sempre più bisogno ma sono poco abituate a cercare e incentivare è il process development per affrontare le sfide di cambiamento organizzativo. Le scienze organizzative e manageriali certo non mancano di testi e definizioni. Il process development, però, è qui inteso prima di tutto come un modo di pensare e di muoversi all’interno dei problemi più che come una tecnica.

Pur senza ignorare i diversi approcci che esistono al problem solving nonché i diversi modi in cui esso nella pratica viene utilizzato proviamo a definire alcuni aspetti fondamentali del process development ragionando per differenze.

MODIFICHE IN UN CONTESTO DEFINITIVO VS MODIFICHE DEL CONTESTO

Ci sono tanti tipi di problemi diversi e in base alla loro portata i cambiamento che si rendono necessari sono più o meno complessi. In linea di principio si può dire che più un problema è delimitato (per dimensione, per criticità che provoca, per numero e tipologie di persone coinvolte) più è adatto ad essere affrontato con una logica di solo problem solving. Il contesto, in queste situazioni costituisce una cornice data e fissa e per affrontare la criticità non è necessario agire su tante variabili. Ci sono casi, invece, dove non solo la criticità ha un impatto importante sul business (in genere quando è collegata al processo del cliente) ma è anche frutto di più concause che, tutte assieme, rendono visibile la necessità di apportare modifiche ampie che coinvolgono non solo uno spazio organizzativo delimitato ma un contesto più ampio. Si tratta spesso di criticità connesse a più funzioni organizzative e, non di rado, alla cattiva connessione tra le diverse funzioni. Questi tipi di situazioni necessitano di un approccio process development perché ciò che si deve ottenere non è solo l’eliminazione di una causa ma la modifica più profonda di un sistema sociale, tecnico, economico.

I problemi da orientare al process development piuttosto che al solving sono quelli che da tempo sono presenti nella vita aziendale ma che, nonostante tutti i tentativi, sembrano essere diventati “cronici”. Continuando ad adottare una logica di causa-effetto lineare queste situazioni continueranno a rimanere “croniche”.

Il punto di partenza è, invece, allargare l’orizzonte per capire se è la cornice e non solo il quadro a dover essere ripensata.

RISULTATI PREDEFINITI VS RISULTATI PRE-FIGURATI

Quale obiettivo vuoi raggiungere? Cosa esattamente vuoi ottenere? Definisci questo prima di intraprendere qualsiasi azione: questo è un assioma del problem solving. Certo, senza obiettivi chiari è difficile scegliere quale strada intraprendere ma tra il risultato predefinito e il risultato non definito c’è una via di mezzo: il risultato pre-figurato. Ossia un risultato desiderato che, a differenza di un obiettivo, ha una certa flessibilità: man mano che si intraprendono delle azioni esplorative il risultato modifica la sua natura. La definizione di obiettivi chiari, non a torto, è un dictact indispensabile per l’efficacia e l’efficienza organizzativa ma può diventare una gabbia dorata quando il tema è un cambiamento complesso. Dunque in un processo di process development non si rinuncia ad avere degli obiettivi solo si è consapevoli che il contesto può riservare delle soprese e diventa necessario essere disponibili a rivedere ciò che prima si dava per certo. Così facendo si evita uno dei aspetti principali del problem solving mal gestito: trovare soluzioni ai problemi sbagliati. In un approccio di process development più che definire il problema, l’orientamento è definire una domanda aperta. Spesso si dice che un problema ben definito ha già in sé la soluzione. D’altro canto se è mal definito ha già in sé il fallimento. Il process development richiede la capacità di vivere l’incertezza senza farsi trascinare da essa ma senza fingere che possa essere arginata. Richiede l’abilità di ri-considerare il problema e il risultato in modo ciclico dopo ciascuna nuova azione: solo così anche una situazione male impostata all’inizio ha la possibilità di essere rivista e di trasformarsi in qualcosa di utile ed efficace.

FOCUS SULLE CAUSE VS FOCUS SULLE CONSEGUENZE E SUL “COME”

Quello che solitamente definiamo con sole due parole ha alle spalle diversi step. Prima di arrivare al problem solving, infatti, c’è un momento di problem finding (accorgersi del malessere); uno di problem setting (definire il problema e chiarire termini, limiti, conseguenze); uno di problem analysis (studiare approfonditamente le cause disaggregando in problemi secondari). L’azione di problem solving è quindi spesso indirizzata a eliminare la causa del problema. Ci sono situazioni difficili dove una attenta analisi può portare ad una incontrovertibile definizione delle cause. Elementi oggettivi su cui tutti possono concordare. Ciò, ovviamente, è tanto più facile quando gli elementi analizzati sono inanimati. Se le cause, invece, risiedono in una ragnatela di comportamenti, relazioni, strumenti, regole, ruoli, cercare di definire la causa diventa spesso controproducente per due motivi:

1. le cause sono numerose e ciò che crea l’effetto indesiderato non è un evento in sé ma è la relazione inaspettata ma concreta che si genera tra aspetti differenti. Il punto non è eliminare una causa ma modificare le relazioni tra più accadimenti, comportamenti, condizioni;
2. ciascuno vede la realtà dal proprio punto di vista. Uno stesso problema può essere analizzato in modo completamente diverso da persone con ruoli, attitudini, propensioni differenti. Alle volte, semplicemente, non può esserci un accordo univoco sulle cause.

Ciò che tutti possono vedere e condividere, invece, sono gli effetti perché sono tangibili, chiari, dimostrabili. Partendo dalle conseguenze il process development non rinuncia totalmente ad analizzare le cause ma, semplice, è maggiormente focalizzato su “come risolvere gli effetti” piuttosto che sul “perché si creano degli effetti”. E’ un processo del tutto contro-intuitivo. Siamo abituati a ragionare per causaeffetto con un approccio lineare. Cercare di capire il perché delle cose ci sembra naturale oltre che necessario per arrivare ad una conclusione. Affrontare in un’ottica di process development una situazione significa partire dal presupposto che le “cause”, anche quelle meno evidenti, riveleranno la loro natura man mano che si attuano delle azioni a condizione che esse non cerchino immediatamente una soluzione ma siano, prima di tutto, azioni esplorative.

AZIONI IMMEDIATAMENTE RISOLUTIVE (FAST PROBLEM SOLVING) VS AZIONI ESPLORATIVE (SLOW QUESTIONS)

Nei processi di problem solving la fase di analisi del problema è un momento preliminare, temporalmente antecedente all’identificazione e all’adozione di una soluzione. Nei processi di sviluppo, invece, la definizione del problema è contestuale ad alcune azioni che permettono di vedere la situazione da diversi punti di vista. Non si tratta, quindi, di azioni mirate all’immediata risoluzione ma azioni che esplorano, investigano il problema in modo interattivo con le persone coinvolte.

Nel problem solving il primo step è l’analisi, nel process development il primo step è la condivisione per definire di una domanda. L’analisi è quindi parallela all’azione e non è cristallizzata in un solo momento. Azione e riflessione si fondono in un ritmo alternato in cui ogni step svela un nuovo aspetto del problema. Più che un obiettivo ben fatto, diventa fondamentale definire una domanda di sviluppo trasparente e priva di pregiudizi da condividere, lavorare, modificare. Una domanda che inizi con “Come possiamo…” invece che con “perché non siamo riusciti a….”

TEAM PREDEFINITI VS RETI SOCIALI INEDITE

Affrontare la criticità con domande aperte invece che con processi di analisi solo successivamente seguiti da aspetti creativi di risoluzione conduce anche a chiedersi chi debba occuparsi di un dato problema. Solitamente in azienda vengono formati team specifici per affrontare i problemi. Nel migliore dei casi si tratta di team interdisciplinari (composti da persone con competenze tecniche differenti), nel peggiore dei casi sono formati dalle persone che si ritengono più esperte su quella questione. In entrambi i casi, però, è definito in modo aprioristico chi è più adatto ad attuare un problem solving. La logica sottointesa è che c’è chi si dedica a pianificare una soluzione e chi, tutti gli altri, dovrà applicare la soluzione. In questa netta distinzione si insidia il germe del fallimento. Chi deve applicare la soluzione sono spesso le persone che sono più direttamente a contatto con il problema. Sono le stesse persone che, non di rado, fanno i conti con gli aspetti incontrollati che la soluzione proposta non ha preso in considerazione. A questa netta distinzione il process development contrappone all’idea del team dedicato l’idea di rete sociale. E’ fondamentale definire chi è il responsabile di un processo (process owner), ossia la persona che si prende carico della criticità dal momento del suo rilevamento fino alla messa regime di soluzioni innovative. Chi partecipa al processo, invece, è definito in modo graduale e aperto. I primi passi esplorativi servono anche a far diventare evidente chi può dare un contributo al processo a prescindere dalle sue competenze tecniche, dal livello gerarchico che ricopre, dalla funzione in cui lavora. Il process owner ha la responsabilità di definire gradualmente il team in base a ciò che la realtà organizzativa porta gradualmente ad evidenza uscendo totalmente dall’idea di gerarchica, divisione funzionale, profilo professionale e tecnico. Si tratta di un processo creativo a tutto tondo in cui l’atto generativo risiede anche nella costruzione di relazioni lavorative che non erano mai stati sperimentate.

COMPETENZE TECNICHE VS COMPETENZE SOCIALI

Le persone più adatte a portare avanti un processo di sviluppo non sono necessariamente quelle che hanno maggiori competenze tecniche su una data questione. La priorità delle competenze sociali su quelle tecniche è data da due elementi:

1. i processi di sviluppo, come abbiamo detto, richiedono la capacità di essere resilienti all’incertezza. Questo ha a che vedere più con le abilità di muoversi in contesti altamente flessibili che con la conoscenza minuziosa del contesto;
2. le competenze tecniche sono fondamentali per affrontare le mansioni lavorative. Sono anche un assett importante per l’analisi dei problemi. Allo stesso tempo, però, costituiscono spesso una gabbia mentale soprattutto se si cercano in elementi tecnici le condizioni per risolvere problemi che sono anche di natura sociale e comportamentale.

Ciò che diventa fondamentale nei processi di sviluppo sono abilità e attitudini come: creare i propri percorsi senza la necessità di strade prestabilite, l’energia e la voglia di attuare un cambiamento, la capacità di vedere nei problemi delle opportunità, saper avere interazioni creative e positive con capi, colleghi, clienti, fornitori, l’abilità di avere una comunicazione orientata all’azione.

Ciascuna di queste attitudini meriterebbe un approfondimento ma quello che si vuole sottolineare è che i processi di sviluppo organizzativo richiedono non solo la creatività e la capacità di analisi (due elementi spesso richiamati nelle tecniche di problem solving) ma competenze sociali più avanzate e che non è detto risiedano necessariamente nei livelli gerarchici più alti o nei profili professionali più qualificati.

Sia la capacità di problem solving e che quella di process development sono fondamentali nei contesti aziendali. Ciò che bisogna però domandarsi è quando l’abitudine ad agire la prima rende impossibile sviluppare la seconda per affrontare situazioni più complesse. L’attività manageriale, quella lavorativa e, semplicemente, la vita di tutti i giorni richiede continuamente l’attitudine a risolvere problemi. Quando questa abitudine, però, ci rende incapaci di dare spazi temporali e relazionali alle circostanze più ostiche diventa un “tallone di Achille”.

Alzando gli occhi dalla scrivania, allora, può valere la pena cominciare a guardarsi attorno per chiedersi: è desiderabile essere attorniati da persone in grado di attuare non solo problem solving creativi ma processi di sviluppo creativi?

A cura di Erika Nemmo, CNR-IRCrES – Istituto di ricerca sulla crescita economica sostenibile del Consiglio Nazionale delle Ricerche