Tema: Innovazione amministrativa

Contesto, problema, soluzione.

Il riuso scientifico dell'esperienza nell'approccio a pattern

di Michelangelo Riccobene, Giovanni Proietto

 "Ciascun pattern descrive un problema ricorrente e la sua soluzione, in un modo tale che si potrà riusare questa soluzione un milione di volte, senza mai farlo allo stesso modo due volte". Christopher Alexander



Leggi la nota di presentazione della redazione di Pubblic@ndo

 
Premessa

Dal 1990 ad oggi, un ampio processo di riforma amministrativa è stato portato avanti, con lo scopo di modernizzare la Pubblica Amministrazione e farla operare secondo una cultura di impresa, in grado cioè di soddisfare efficacemente le domande del mercato (clienti, cittadini, imprese).

Tale processo legislativo deriva dalla parziale incapacità della Pubblica Amministrazione di soddisfare i bisogni e le aspettative per la quale è stata creata e cioè rispondere con efficacia ed efficienza alle mutate richieste dei cittadini e degli altri organismi statali, con servizi di qualità.

Le leggi da sole tuttavia non bastano. Il processo legislativo deve essere supportato da una rilevante attività di semplificazione delle procedure e delle strutture amministrative, da una incisiva e continua attività di formazione e da profondi processi di comunicazione.

Il miglioramento dell'efficienza della P.A., della sua organizzazione, è quindi lo snodo fondamentale per consentire l'attuazione della riforma.

Le organizzazioni pubbliche per potere migliorare il loro modo di operare ed interagire con il resto della società, devono tuttavia superare una serie di ostacoli e di problemi non indifferenti, legati alla complessità delle strutture, dei processi, delle attività e dei rapporti con altri ambiti organizzativi.

Oltre ai nuovi bisogni ed esigenze degli utenti/cittadini ed agli effetti delle politiche di risanamento pubblico, una spinta, non meno importante al cambiamento è stata data dall'innovazione tecnologica, dall'introduzione delle Information Communication Tecnology (ICT), che consente di rendere condivise, in tempo reale, le informazioni tra le diverse unità organizzative ed il ridisegno dei processi di servizio.

 
torna su


Le risposte alle esigenze di cambiamento

Negli ultimi anni sono state proposte e diffuse teorie, metodi e tecniche diverse per affrontare e superare le difficoltà delle amministrazioni nel definire, promuovere e realizzare progetti capaci di portare un concreto miglioramento dei servizi forniti ai cittadini.

Gli approcci più importanti sono il "Total Quality Management" (TQM), il Business Process Reengineering (BPR) e i modelli di maturità.
 

Total Quality Management

Il TQM noto anche come "Qualità Totale" è nato negli Stati Uniti negli ultimi decenni ed ha avuto una considerevole diffusione nel resto del mondo, specie in Giappone. I risultati promessi da questa metodologia si raggiungono con interventi di miglioramento continuo (incrementali), ripetendo momenti organizzati di verifica e cambiamento, che coinvolgono tutta l'organizzazione.

L'intensità del cambiamento è però minima, mentre l'evoluzione organizzativa è graduale non traumatica e poco rischiosa. Il fuoco d'intervento è costituito dal miglioramento dei processi esistenti (mantenimento degli attuali processi con miglioramento di efficienza). L'incremento del miglioramento è minore del 10%.

Ad ogni modo il TQM è utile quando è necessario "apportare piccole modifiche di adattamento alla struttura ma non è più sufficiente quando i cambiamenti richiesti sono di una tale entità che occorre intervenire sull'intera architettura del sistema organizzativo".
 
 
Business Process Reengineering

Il BPR nasce negli anni '90 per impulso di un professore di informatica del MIT, Michael Hammer, che definisce il reengineering come "la riprogettazione radicale dei processi d'impresa ("business process"), in grado di condurre a miglioramenti delle prestazioni di tipo discontinuo ("dramatic improvement") "… è tempo di smettere di pavimentare sentieri per le mucche. Invece di rivestire di silicio e software i nostri processi obsoleti, dobbiamo dimenticarli e ripartire da capo. Dobbiamo reingegnerizzare il nostro business; usare la forza delle moderne tecnologie dell'informazione per ridisegnare i nostri processi per ottenere drammatici miglioramenti dei risultati".

L'intervento, che produrrà risultati di tipo discontinuo con l'uso delle tecnologie informatiche e di telecomunicazione, ha come oggetto i processi e la loro riprogettazione radicale.

Per le sue caratteristiche il BPR è una metodologia di miglioramento (oltre il 70%) di tipo strutturale che opera in senso discontinuo: mira cioè a far fare un "salto" nei livelli di prestazione. Il "salto" si raggiunge con una ristrutturazione profonda, libera da vincoli, dei processi che sono oggetto dell'intervento e viene ottenuta grazie all'introduzione delle tecnologie informatiche innovative. L'alto grado di cambiamento atteso si raggiunge tuttavia con una elevata traumaticità conseguente all'intervento.

L'applicazione, nella formulazione originaria, del BPR, nell'ambito della P.A., incontra delle notevoli difficoltà, a volte insormontabili, che si possono così riassumere:

1. vincoli normativi (che possono non essere rimovibili allo stesso livello amministrativo in cui si colloca chi sviluppa l'intervento di reingegnerizzazione);
2. difficoltà di applicare la logica dei processi alle amministrazioni per motivi di carattere culturale (suddivisione delle competenze nella P.A.)
3. autoreferenzialità (conformità alla norma rispetto alla soddisfazione delle esigenze degli utenti).

L'applicazione del BPR, inoltre, non è scevro da rischi. Pertanto negli ultimi anni sono stati proposti correttivi e riformulazioni che mirano (H. James Harrington) ad un più contenuto e meno rischioso intervento di cambiamento organizzativo, oppure a considerare le metodologie di reingegnerizzazione come uno strumento da usare in un più ampio contesto di cambiamento organizzativo (Daniel Morris e Joel Brandon).
 
 
Modelli di maturità

Oltre a questi metodi detti di miglioramento si devono succintamente ricordare altri 2 modelli cosiddetti di "maturità": lo standard ISO e il Capability Maturity Model. L'ISO 9000 è una famiglia di standard che definiscono le caratteristiche del sistema di qualità di una azienda che produce beni o servizi.

Il Capability Maturity Model è più conosciuto nel settore dell'ingegneria informatica e si riferisce alle aziende produttrici di software. La sua implementazione è quindi rivolta a questo specifico settore.


Un approccio differente

Un approccio diverso a questi problemi potrebbe venire dai pattern, uno strumento ideato dall'architetto Christopher Alexander negli anni '70 che ha avuto, nell'ultimo decennio, un forte impatto sulla comunità dei progettisti di software. L'uso dei pattern è oggi quotidiano in questo campo ma alcuni pionieri ne stanno portando i benefici nell'ambito della "progettazione" delle organizzazioni e dei processi.

La ricerca di Alexander ha avuto un duplice obiettivo: sostituire i modelli finora in uso nella progettazione con modelli capaci di tener conto delle reali esigenze delle persone e dare alla progettazione uno strumento di trasmissione e riuso dell'esperienza che ne garantisca la selezione e quindi l'evoluzione e l'adattamento. È un tentativo di mettere insieme le possibilità della scienza moderna con la Qualità.

Alexander porta avanti questa ricerca da tre decenni (si veda [1] per la sua base teorica). I lavori sui pattern nel software sono più recenti ma più estesi e ampiamente accettati (si veda [2] per un lavoro seminale da cui si è sviluppata un'intera letteratura). Gli studi sui pattern organizzazionali sono recentissimi.

È possibile portare questi studi nella P.A. Quali vantaggi possiamo attenderci dalla loro implementazione?
 
torna su


Forze, vincoli e pattern

Il modello usato da Alexander per approcciare i problemi progettuali è fatto da un insieme di forze e vincoli da riconciliare. Forze e vincoli possono essere i più diversi, da quelli meramente tecnici a quelli umani e questo conferisce al modello la capacità di catturare aspetti non solo tecnici ma anche "fisici", normativi, umani ed anche culturali.

Cos'è un pattern? «E' una regola in tre parti, che esprime una relazione tra un certo contesto, un problema, e una soluzione» [1]

Contesto è ciò che intendiamo intuitivamente. Questa parte della regola è lasciata volutamente vaga perché possa adattarsi alle situazioni più varie. Ciò che importa è che in ogni contesto opera un insieme di forze e vincoli. Quando le forze che operano in un contesto sono in contrasto tra loro sorge la necessità di trovare una riconciliazione. Questo è il problema. La soluzione consiste nell'introduzione nel contesto di alcuni elementi nuovi che cambiano le relazioni fra le forze e le riconciliano, nel rispetto dei vincoli.

Tramite i pattern è possibile catturare l'esperienza maturata in progetti che funzionano bene e si dimostrano ben adattati alle esigenze dei loro utilizzatori, e mettere questa esperienza in una forma nella quale possa essere facilmente discussa, condivisa, modificata e riusata.

Il riuso "scientifico" dell'esperienza

Straordinariamente questo è un linguaggio molto vicino ai temi ed alle problematiche della P.A. Molti tentativi sono nati nel recente processo di ammodernamento con lo scopo di promuovere la condivisione di esperienze e di progetti meglio riusciti, come ad esempio "mappa delle abilità" (progetto nazionale URPdegliURP), con la quale si è voluto, tramite una apposita banca dati "favorire l'incontro tra uffici che vorrebbero attivare o potenziare una determinata attività e uffici che su quella specifica funzione hanno sviluppato una esperienza interessante e matura" .

L'approccio a pattern offre la possibilità di fare un passo avanti rispetto a questi tentativi verso un riuso "scientifico" dell'esperienza.

I pattern consentono di andare al di là della semplice condivisione di un progetto che ha funzionato bene. Un progetto non può essere riusato perché il contesto in cui si inserisce è unico e irripetibile. Lo scopo di un pattern invece è quello di catturare l'intento progettuale che sta dietro ad una delle soluzioni trovate nel progetto.

È questo intento che si può discutere, condividere e riusare. Molte problematiche progettuali ricorrono più e più volte in contesti diversi ma ogni volta con caratteristiche uniche. Il pattern nei diversi contesti genererà soluzione diverse.

«Il pattern è, in breve, allo stesso tempo una cosa, che accade nel mondo, e la regola che ci dice come crearla, e quando dobbiamo crearla. Esso è insieme un processo e una cosa; insieme una descrizione di una cosa che è viva, e una descrizione del processo che genererà quella cosa.» [1]

Ma c'è di più. I pattern consentono un processo di selezione dell'esperienza nel corso del tempo. I progettisti inesperti possono acquisire più facilmente l'esperienza dei progettisti esperti. Questi possono affinare i pattern di progetto provandoli e riprovandoli nei loro progetti.

Un ruolo importante spetta alla comunità. Nella progettazione del software i progettisti impegnati nello sviluppo dei pattern si incontrano in una conferenza annuale in cui le diverse proposte di pattern sono discusse e quelle accettate vengono pubblicate per divenire patrimonio di tutti.

I pattern si "scoprono" come soluzioni ricorrenti e ben adattate nei progetti che hanno avuto successo. Perché una proposta di pattern sia accettata come pattern deve avere le caratteristiche formali di un pattern (contesto, problema, soluzione) ma fondamentalmente deve essere dimostrato che il pattern ricorre più volte, che ha un valore significativo e ne devono essere chiarite le conseguenze che ha avuto nei progetti in cui è stato applicato. Per questo è necessario vedere come il pattern si è comportato nel corso del tempo. Questo processo assicura la qualità dei pattern e porta ad una progettazione consapevole.

torna su 


I fattori umani

Anche gli utilizzatori dei progetti possono fornire valide indicazioni sulla bontà delle "costruzioni" ottenute e quindi dei pattern applicati. Anzi essi stessi possono partecipare al progetto esprimendo le loro esigenze e contribuendo alla scelta dei pattern da applicare (vedi gli esperimenti di progettazione "partecipata" condotti anche in alcune nostre università).

In forza del modello che li sottende, i pattern aspirano a tener conto, nel progetto, dei fattori umani sia perché l'obiettivo della progettazione, secondo il loro autore, è quello di rendere la vita delle persone migliore sia perché le problematiche tecniche e quelle umane sono strettamente intrecciate e non si possono risolvere adeguatamente le une senza risolvere le altre.


I pattern organizzazionali e la P.A.

La genericità del metodo di Alexander, unita al suo valore, hanno consentito recentemente ad alcuni pionieri di portarne i risultati anche nel campo della strutturazione delle organizzazioni e dei processi (si vedano [3] per un articolo introduttivo, [4] e [5] per un esempio di catalogo di pattern organizzazionali specifici per un contesto e frutto di un progetto di ricerca ancora in corso).

Riteniamo che sia possibile applicare questo approccio anche alla P.A. e portare nell'attuale processo di rinnovamento vantaggi non indifferenti. Cosa fanno i "pattern organizzazionali"? Catturano le "best practice" delle organizzazioni che funzionano bene perché possano essere riusate altrove.

Anche l'organizzazione di una P.A. può essere vista in termini di pattern: le procedure e i procedimenti, gli schemi ricorrenti di interazione tra le diverse unità organizzative, gli stereotipi nel rapporto con i cittadini, e così via. Per esempio, la P.A., recentemente, con la scelta dello sportello unico e della strutturazione per processi anziché per funzioni sta cambiando due suoi macro pattern. Ovviamente questo cambierà, più o meno consapevolmente, tanti pattern di "grana più fine". Quale migliore opportunità per introdurre l'approccio a pattern che può dare un contributo significativo al cambiamento nella direzione della Qualità.


Un caso reale

Coplien descrive in [3] un esperimento fatto presso un'azienda di successo che stava incontrando dei problemi nel passaggio da piccola azienda ad azienda quotata in borsa. In alcuni incontri avuti con i dipendenti di quella azienda Coplien ripercorre gli ultimi loro accadimenti e ne discute usando come linguaggio "tecnico" un linguaggio di pattern frutto di un progetto di ricerca finalizzato allo studio delle organizzazioni di sviluppo del software in molte compagnie in tutto il mondo.

Il risultato di questa introspezione è consistito in una straordinaria presa di consapevolezza dei membri di quella azienda sul loro modo di lavorare e su quelle che invece erano le "best practice" che Coplien aveva catturato nei "suoi" pattern. E il modo di lavorare dei dipendenti è cambiato di conseguenza e in modo naturale: l'organizzazione ha corretto se stessa e imparato una nuova dinamica risolvendo le sue difficoltà.

Il linguaggio di pattern ha fatto capire a quell'organizzazione quali erano i suoi problemi e come potevano essere risolti. Coplien sostiene che la Qualità viene dalle persone e il cambiamento deve venire dall'interno dell'organizzazione. Per questo è scettico nei confronti di progetti di reengineering basati sugli standard ISO i cui metodi sono orientati alla prescrizione e non all'introspezione.


Il BPR alla luce dei pattern

Alla luce delle considerazioni fatte sin qui è possibile rivedere criticamente il BPR classico e comprenderne alcuni suoi limiti. Un aspetto dei pattern che finora non abbiamo riferito è la maggior attenzione che essi rivolgono al problema piuttosto che alla soluzione.

Quanto più la comprensione di un problema progettuale e del suo contesto sono profonde tanto migliore sarà la sua soluzione. Essa deve quasi emergere spontaneamente dalla comprensione del problema. I pattern sono prima ancora che un riuso dell'esperienza nella soluzione dei problemi un riuso dell'esperienza acquisita nella loro comprensione.

Il BPR è tanto più efficace quanto meglio è modellato il problema ma esso non offre alcun supporto alla sua modellazione. Essa è perciò lasciata all'esperienza del progettista e nessuno strumento è fornito per accrescerla. Inoltre mentre il BPR si fonda su modelli matematici i pattern si fondano su un modello capace di tener conto anche degli aspetti umani e relazionali, ed ha quindi l'ambizione di essere più completo.

È allora possibile pensare di affiancare il BPR classico con la progettazione a pattern utilizzando il primo per gli aspetti quantitativi del progetto e la seconda per gli altri aspetti.
 

Un linguaggio unificato

C'è da sottolineare ancora un altro elemento, forse il più importante, che l'uso dei pattern può offrire e che si configura come il maggiore investimento, nel medio e lungo periodo, sotto il profilo dell'innovazione e dei benefici attesi: la creazione di un linguaggio unico ovvero l'unificazione di diversi linguaggi.

I pattern che la comunità "scoprirà" nelle varie discipline diventeranno le parole di un linguaggio progettuale unificato capace di portare sullo stesso tavolo progettuale temi appartenenti a campi diversi ma fra loro intimamente connessi, perché aspetti diversi della vita delle persone, promettendo in tal modo di migliorare significatamene la progettazione in favore dell'uomo.


Una proposta

Una proposta per avviare l'approccio a pattern è quella di ripetere quanto accaduto in altri campi: accanto alle necessarie discussioni, si può iniziare un progetto di analisi di un buon numero di amministrazioni locali per individuarne i pattern, poi, come risultato del progetto compilare un catalogo ed offrirlo alla discussione della comunità e per l'uso.
 
torna su


Ultimo aggiornamento: 01/12/05