VIAGGIO NEL DNA DELLE ORGANIZZAZIONI

Il Corporate DNA Modelling Language(r)

[Ontologia cenni] [La Corporate DNA Ontology] [I Patterns]

Cosa si intende per organizzazione?

Il termine può indicare l’insieme di attività che devono essere svolte in un contesto complesso per  renderlo ordinato e gestibile. Spesso con lo stesso si sottintendono le metodiche che sono necessarie a progettare modelli teorici che poi devono trovare applicazione pratica nel mondo reale. Nella accezione più ampia del termine si intende l’insieme di risorse finanziarie, umane e strumentali che, coordinate e finalizzate, si propongono di raggiungere un determinato scopo. A sua volta questo può essere profit o no profit e quindi riguardare indifferentemente Imprese, Enti o Pubbliche Amministrazioni. Tale tipo di interpretazione è quello che a noi piace di più in quanto rende evidente il concetto che ogni Entità Organizzata brucia risorse finanziarie ed ha bisogno di un modello di funzionamento (strutture processi e regole), schema o pattern, per finalizzare tutte le risorse agli obiettivi che si intendono perseguire.

In sintesi un’Entità organizzata si pone degli obiettivi e crea una sua Organizzazione per raggiungerli. L’Organizzazione è quindi la rappresentazione del suo modello di funzionamento formale. Questa è, a sua volta, la forma attraverso cui l’Entità si presenta al contesto socio-economico nonché lo schema attraverso cui opera.

Come qualsiasi liquido assume forme diverse a seconda di quella che lo contiene, così l’Organizzazione incapsula risorse di quantità e qualità diverse in uno schema. Natura e numero delle risorse devono essere scelte in funzione degli obiettivi.

E’ quindi consequenziale che uno schema o pattern organizzativo è di per sé rappresentativo di una certa realtà, nonché costituisce il disegno di una tipologia di organizzazione, ne caratterizza gli obiettivi, il modo di funzionare, i requisiti, i vincoli interni ed esterni. 

Naturalmente il pattern organizzativo costituisce l’interpretazione che ogni singola Organizzazione dà del suo modo di funzionare all’interno di un determinato contesto e delle esigenze che intende coprire.

Ciò non significa che il pattern riproduca un modello di funzionamento ottimale. Possiamo dire che se l’Organizzazione inventa e disegna sé stessa propone un modello di funzionamento soggettivo e quindi limitato sicuramente in termini di confronti all’esperienza ed all’inventiva interna ed alla sua propensione ad investire in termini di marketing e di osservatorio permanente di mercato.

Supponiamo invece che esista una biblioteca di modelli organizzativi consultabili e che questi siano interpretabili secondo formalismi comuni: un unico linguaggio semplice ed intuitivo per chi progetta organizzazioni.
 

Se ciò fosse  i progettisti potrebbero valutare vantaggi e svantaggi di singoli pattern organizzativi e scegliere il più idoneo per la dimensione della propria Organizzazione e per il contesto in cui Questa opera.

Il pattern scelto dovrebbe essere utilizzato come base per la progettazione organizzativa che dovrebbe, a sua volta, creare un nuovo pattern della specifica Organizzazione (istanziazione del  Pattern).

Naturalmente il nuovo pattern progettato dovrebbe essere messo a disposizione, anche se in modo anonimo, della biblioteca in modo che possa essere utilizzato da altre Entità Organizzative (riuso del pattern). 

Ma una biblioteca di questo genere non esiste almeno su scala industriale come non esiste un linguaggio idoneo a standardizzare la comprensione dei modelli organizzativi da parte degli addetti e non addetti ai lavori.

 Di fatto esistono le seguenti difficoltà:

 1.      ogni Organizzazione è restia a pubblicare il proprio modello organizzativo perchè:

1.1.   lo considera un vantaggio competitivo e quindi da non diffondere

1.2.   teme di poter essere confrontata e quindi che possano essere individuati e resi pubblici i fattori di debolezza

2.      le Aziende di consulenza sono restie a pubblicare i modelli organizzativi prodotti nei loro interventi perché:

2.1.   pur essendo tenute al segreto, riutilizzano gli output dei loro interventi su altri clienti

2.2.   temono di poter essere criticate in ordine alle modalità di svolgimento dell’intervento e sui risultati prodotti

2.3.   non considerano ancora un business la pubblicazione dei patterns

3.      non esiste un linguaggio unificato per la produzione ed interpretazione dei patterns

4.      non esistono sistemi considerati standard per la produzione e gestione dei patterns e soprattutto in grado di tradurre gli stessi in termini di dati ed informazioni

5.      non esiste alcun concetto equivalente all’”open source” per i patterns organizzativi

6.      non esiste un modello per la standardizzazione dei patterns organizzativi

7.      non esistono modelli di distribuzione di patterns organizzativi standardizzati.

A tali difficoltà si aggiunga il gap metodologico e culturale che ancora esiste fra il mondo dell’organizzazione, poco incline e poco dotato di standard e di sistemi, e quello dell’informatica dotato di metodologie e di tools per lo sviluppo del software.

 Proprio in tale contesto è stato sviluppato dal team universalmente riconosciuto come i “tres amigos” (Grady Booch, Ivar Jacobson, Jim Rumbaugh) l’UML (Unified Modeling Language).

 L’UML è il successore di una serie di metodologie di analisi e progettazione orientate agli oggetti apparse tra la fine degli anni 80 e i primi anni 90.

 Questo è un vero e proprio linguaggio di modellazione per progettare sistemi software ad oggetti e più precisamente la notazione grafico formale usata dalla metodologia RUP (Rational Unified Process), progettata sempre dai “tres amigos”, per esprimere le caratteristiche di un progetto; non rappresenta quindi la metodologia che costituisce invece l’insieme dei passi necessari a progettare compiutamente il sistema. Il linguaggio può essere utilizzato sempre ed in qualsiasi momento indipendentemente dalla metodologia come strumento di comunicazione e di rappresentazione degli oggetti componenti un sistema informativo-informatico ad oggetti.

 In fig. 3 sono rappresentati gli oggetti componenti l’UML.

In fig. 4 sono rappresentati i passi della metodologia RUP. Questi, a loro volta, sono raggruppati in macrofasi o sono indicati in fasi equivalenti.

 
E’ facile quindi comprendere che possono essere utilizzate le notazioni messe a disposizione dal linguaggio UML in momenti diversi della metodologia RUP in funzione di cosa si intende o si deve rappresentare nell’ambito della singola fase componente la metodologia.

Per esempio per definire i requisiti sarà necessario descrivere le classi degli oggetti, i casi d’uso e, se è determinante, la sequenza delle attività (progetto orientato al workflow) attraverso il diagramma delle attività.

I diagrammi di sequenza e di collaborazione o diagrammi di interazione saranno necessari nella fase di analisi, di progettazione e di implementazione; i diagrammi di deployment saranno necessari nella fase di implementazione per descrivere il modello fisico.

Nulla vieta che in qualsiasi momento il progettista usi una delle notazioni o per analizzare uno specifico problema o per comunicare con un utente.

 Questa è la forza del linguaggio.

 Noi utilizziamo infatti continuamente i costrutti del linguaggio, la sua sintassi, il lessico in contesti diversi per esprimere concetti diversi. Per far questo non abbiamo bisogno di schedulare le nostre attività perché ciò dipende dalle cose che dobbiamo fare (giocare, lavorare, esprimerci nel sociale o nel professionale).

 Quindi è possibile che le notazioni del linguaggio possano essere usate nell’ambito di metodologie e di ambiti diversi. Chi vuole affrontare con la stessa metodologia obiettivi diversi è probabilmente destinato all’insuccesso, mentre è possibile e costituisce un fattore di successo utilizzare un linguaggio di facile comprensione per attori eterogenei che dovranno dialogare nelle fasi di analisi, in quelle più specializzate necessarie alla realizzazione e, perché no, in quelle successive necessarie alla divulgazione del sistema.

Ritornando allo specifico tema dell’Organizzazione, oggetto della nostra ricerca, è spontaneo chiedersi se un approccio analogo possa essere utilizzato nell’ambito della progettazione, implementazione e diffusione di patterns organizzativi.

Non vi è naturalmente alcuna pretesa di creare uno standard ma non si comprende perché la strada che è stata seguita per la progettazione di modelli organizzativi non possa essere adottata, almeno come riferimento, per la progettazione di modelli organizzativi.

 Ad avvalorare questa ipotesi intervengono inoltre le seguenti considerazioni:

1.      i modelli organizzativi includono i sistemi informativi-informatici e quindi le tecnologie, che costituiscono una delle componenti di tali sistemi complessi

2.      le fasi di progettazione e realizzazione di un modello organizzativo nonché quelle di distribuzione agli utenti/addetti delle informazioni a questo inerenti sono simili a quelle di un progetto informatico

3.      se nel mondo dell’informatica si è transitati attraverso una fase pionieristica dove il software si realizzava attraverso delle analisi di massima e dove non si riteneva necessario un alto livello di specializzazione per pervenire successivamente ad una fase industriale dove pianificazione puntuale, approccio metodologico rigoroso,  ruoli e specializzazioni hanno sostituito generalismo ed approssimazione, non si comprende perché questo processo non debba essere seguito per l’organizzazione

4.      se l’operatività di Imprese, Enti e Pubbliche Amministrazioni richiede dei sistemi informativi-informatici per gestire un gran numero di dati ed informazioni con ogni probabilità è opportuno che ci si evolva verso sistemi informativi specializzati nella gestione di dati ed informazioni necessari  a rappresentare ed interpretare i modelli organizzativi.

 Proprio in considerazione di quanto fin qui esposto, è stato ritenuto possibile ipotizzare la definizione d'un linguaggio, a valenza universale, specializzato per la rappresentazione di modelli organizzativi complessi: il Corporate DNA Modelling Language.

Tale linguaggio s'inquadra nell’ambito di una disciplina definita Corporate Genetics, letteralmente Genetica d’Impresa, avente lo scopo di decodificare il DNA delle Organizzazioni (Corporate DNA) per poi clonarlo e metterlo a disposizione di altre Entità Organizzative.

Quanto sopra specificato è sicuramente necessario ma non sufficiente a risolvere il problema.

E' infatti noto come qualsiasi linguaggio si evolva in funzione dell'ambiente e delle necessità di comunicazione. Quello dell'organizzazione è soggetto alla stessa legge. Ne è dimostrazione il fatto che sia i consulenti che gli analisti d'organizzazione modificano spesso le notazioni attraverso cui rappresentano i modelli organizzativi in funzione degli obiettivi che si pongono, delle necessità progettuali e delle capacità di comprensione degli interlocutori a cui queste sono rivolte.

Per tale motivo il linguaggio deve essere flessibile, parametrico ed adattabile a qualsiasi contesto, ambito o realtà.

Come più volte sottolineato con questo trattato non si ritiene di poter esaurire l'argomento ma tracciare una strada, un percorso per raggiungere tale ambizioso obiettivo. 

C'e quindi bisogno di un livello del linguaggio diverso da quello di interfacciamento con l'utente finale. Un livello di base che consenta di creare entità elementari componibili in altre in modo tale da definire la sintassi, la semantica ed il lessico del linguaggio stesso.

Avendo già definito il Corporate DNA, i suoi elementi componenti ed il Corporate Genome, possiamo affermare che tale livello di base è perseguibile attraverso un'ontologia che li descriva, in modo formale. La stessa deve poter essere implementabile agevolmente in modo da seguire le logiche naturali dell'evoluzione dei modelli organizzativi e conseguentemente quelle delle loro rappresentazioni. 

Possiamo dire che tale risultato può essere assicurato attraverso la scomposizione in tre livelli delle entità rappresentative dei modelli organizzativi: le knowledge entity, le conceptual entity e le phisical entity.

Attraverso il primo livello è possibile definire degli oggetti astratti che poi potranno essere utilizzati come linguaggio di base per rappresentare le organizzazioni. Oggetti che potranno a loro volta usare altri oggetti per generarne altri. 

Questi troveranno poi applicazione nella rappresentazione concettuale delle organizzazioni attraverso le conceptual entity e riscontro nel mondo reale attraverso le phisical entity.

[Ontologia cenni] [La Corporate DNA Ontology] [I Patterns]