Archivi della categoria: IT Management

Microservizi: perché dovrebbero interessare anche il business e non solo i tecnici IT

26 Lug 2019

Posted by in IT Management

≈ Lascia un commento

Tag

Con il termine “microservizi” si identifica un nuova tipologia architetturale con la quale progettare applicativi software. È da un po’ di tempo che tanti articoli di informatica e blog dedicano spazio a questa tematica: digitando la parola microservizi su un qualsiasi motore di ricerca si possono trovare moltissimi contributi tecnici. Tipicamente viene analizzato un aspetto tecnico identificandone i vantaggi e gli svantaggi. Meno frequenti invece sono gli interventi che cercano di fornire una visione di prospettiva su come questo nuovo approccio innovativo alla creazione di software possa impattare sensibilmente il mondo del business, in senso generale.

Vediamo assieme perché i microservizi sono un elemento importante per le future opportunità di business.

Continua a leggere →

Complicato e Complesso. Cosa fare di diverso?

02 Dic 2013

Posted by in Complexity, IT Management, IT Transformation

≈ Lascia un commento

Ho dedicato il post precedente a chiarire -spero- la differenza tra situazioni Complicate e Complesse, vista l’ambiguità della lingua parlata italiana in proposito.

Nella realtà quotidiana non è facile distinguere nettamente le due situazioni, che spesso compaiono insieme creando terreno fertile per valutazioni errate.
E’ infatti molto frequente che si estragga una parte del problema, la si definisca -correttamente- Complicata, e da lì si ottenga la conferma che lo stile giusto di gestione è quello di sempre.
Parto innanzitutto a definire lo stile di gestione “ di sempre” che ha portato organizzazioni e società a risultati sensazionali, frutto di miglioramenti iniziati a inizio secolo scorso e tuttora in corso. 
E’ uno stile adatto ai Sistemi Complicati, che posso riassumere nel modo seguente:
  • Prendere decisioni – trovare la scelta migliore
  • Definire i ruoli e responsabilità – per le attività che vanno svolte
  • Definire il piano – utilizzando le priorità e la catena di comando
  • Governare – decidere e dire agli altri cosa devono fare
  • Controllare – allineare e mantenere il focus sull’obbiettivo

Building

Con questo approccio siamo andati sulla luna, abbiamo costruito edifici e città, abbiamo trapiantato cuori, faremo ancora milioni di cose nuove. Farlo è familiare, dà un senso di sicurezza, ha portato a grandi risultati. Perché confutarlo?

Ecco la mia risposta.

Perché oggi frequentemente non basta, e non mi sembra opportuno accontentarsi.
Mi sembra abbastanza evidente che a fronte di situazioni in cui semplice, complicato e complesso si mischiano occorra pensare meglio ad approcci migliori, che facciano distinzioni e gestiscano in modo appropriato le diverse parti.
Ci sono molte situazioni in cui è possibile attribuire una Responsabilità: per andare sulla luna Houston ha la responsabilità,  il chirurgo ha la responsabilità del trapianto,  l’ingegnere ha la responsabilità dell’edificio o del piano regolatore.
La Responsabilità dà il potere di gestire con lo stile descritto sopra.
Ma ci sono casi in cui la eventuale Responsabilità non dà questo potere: quando il risultato emerge da una creazione non possibile con la coercizione, dalla collaborazione, dall’interazione delle varie parti.
Basta pensare ad un bambino recalcitrante o ai dipendenti di una azienda o agli abitanti di una città, per rendersi conto che le relazioni non permettono di prevedere un controllo efficace, qualsiasi buon piano io abbia fatto.

Se i risultati che vogliamo ottenere dipendono dalla collaborazione e co-creazione e non possediamo espliciti e definitivi strumenti di controllo, allora probabilmente lo stile che abbiamo usato finora non è il migliore.
Quale stile funziona meglio nei Sistemi Complessi?

  • Costruire le relazioni – pattern utili di interazione
  • Sense making – interpretazione allargata della situazione
  • Loose coupling – supporto alle Comunità di Pratica e aggiunta di autonomia
  • Apprendimento – agire/imparare/pianificare nello stesso tempo
  • Osservare cosa emerge – costruire sulle evidenze di buon risultato

child

By Tom Jacobs

Quando non possiamo specificare -in senso ingegneristico- né determinare cosa vogliamo ottenere, dobbiamo adeguare il nostro stile e abilitare i risultati intervenendo sul sistema.
Quando non è possibile pensare che con una correzione si aggiusti tutto, allora devo cercare i punti di leva che devo cambiare per migliorare il sistema.
Ad esempio posso cambiare quello che le persone fanno, e dovrò quindi cambiare le regole attuali, che faranno cambiare le relazioni, le reti e i comportamenti, e sarò costretto a cambiare gli strumenti.
Parlando di organizzazioni cambieranno le regole, le norme tacite di comportamento, come vengono gestiti i conflitti, gli errori, il potere, le linee guida e le checklist.

Il bello è che probabilmente se mi comporto nello stesso modo in due comunità diverse -aziende, quartieri, città, mercati-, otterrò due risultati diversi: magari buoni risultati, ma diversi. 
I risultati dipendono dal contesto, dal momento, dalla cultura e dai valori della comunità e lo stile diverso, in ultima analisi, consiste nel tenerne conto.

Complicato o complesso ?

30 Ago 2013

Posted by in Complexity, IT Management, IT Transformation

≈ 9 commenti

Mi è servito un sondaggio tra colleghi e clienti per decidere di scrivere con l’obiettivo di chiarire la differenza tra complicato e complesso, che nel linguaggio comune vengono utilizzati in modo pressoché intercambiabile.

Ho scoperto con sorpresa che il linguaggio che utilizzo normalmente non è affatto chiaro agli altri, ma immediatamente mi sono sorpreso di essermi sorpreso.
Quindi cerco di chiarire i termini, per poi parlare delle implicazioni.
Con COMPLICATO definiamo un problema o una situazione che siamo in grado di descrivere compiutamente, di cui siamo in grado di definire una strategia e un piano per affrontarlo, dei tempi e delle milestones per arrivare a un risultato che siamo in grado di descrivere.
Con COMPLESSO definiamo invece una situazione in cui non siamo in grado di definire una serie di milestones precise, dei tempi precisi e un risultato preciso da raggiungere.
Sono definizioni un po’ grossolane rispetto a quanto si trova in letteratura, ma secondo me rendono bene l’idea.
Uso alcuni esempi tipici per tradurre in pratica:
COMPLICATO: assemblare un mobile dell’IKEA, mandare un razzo sulla luna, smontare e rimontare un orologio, costruire una barca.
La complicazione può venire dalla vastità del compito e dagli skill molteplici che sono necessari, ma se della situazione conosco cosa so fare e cosa non so fare,sono comunque in grado di descrivere i passi certi per arrivare ad una risoluzione.
COMPLESSO: crescere bene un figlio, impostare un piano strategico – che funzioni -, gestire un gruppo di persone, realizzare un progetto software grosso che non ho mai fatto prima, gestire un’azienda, o l’IT di una azienda.
Complexity Cloud
In altre parole, se esiste una ricetta, pur con molti ingredienti e con molti step, se anche non ho alcuni degli ingredienti e non so fare alcuni step, posso comunque procurarmi ciò che manca ed essere pressoché sicuro del risultato. E si tratta di situazioni complicate.
E’ abbastanza chiaro che tutte le volte in cui sono coinvolte persone non come “ingranaggi di un orologio”, cioè esecutori di procedure, ma come elementi portanti di un’attività che ha interconnessioni ed evoluzioni nel tempo, siamo di fronte a problemi complessi.
I sistemi complicati sono predicibili. Li possiamo prendere, separare nelle parti, capire le interazioni, e riprodurre. A meno di errori di esecuzione, sono in grado di ripetere l’evento.
Per i sistemi complessi non è così. Per quanti figli io possa avere non ne usciranno mai due uguali, per quante aziende abbia gestito non potrò mai garantire che fare le cose che ho fatto in una farà funzionare la prossima. I sistemi complessi sono in larga parte impredicibili, e quando li sollecito con un’azione non so con certezza cosa aspettarmi (a meno che non sia un peccatore cronico di “overconfidence”).
L’incertezza è sovrana, averlo fatto bene una volta non dà garanzie per la prossima, non ho garanzie di successo. Molte volte non riesco nemmeno a definire esattamente cosa sia il successo.
Per riassumere:
Sistemi complicati (come costruire una barca)
  1. Le formule sono critiche e necessarie
  2. Riuscire una volta garantisce che anche la prossima riuscirà
  3. Servono livelli di esperienza adeguati nei diversi campi coinvolti
  4. Ci sono molte similitudini (se non uguaglianza) tra le ripetizioni
  5. Ci sono alti livelli di certezza sul risultato
Sistemi complessi (come crescere un figlio o gestire un gruppo di persone)
  1. Le formule hanno un’applicazione limitata
  2. Riuscire una volta dà esperienza, ma non garantisce il risultato ripetibile
  3. L’esperienza è necessaria, ma non sufficiente
  4. Ogni persona o gruppo è unico (e cambia nel tempo) nelle caratteristiche, e le relazioni sono fondamentali
  5. Ci sono bassi livelli di certezza sui risultati
Una prima conclusione che si può trarre è che lo stile con cui si affrontano situazioni complicate e complesse non può essere lo stesso.
Mentre per le prime ho una relazione diretta tra causa ed effetto, cosa che mi permette uno stile di monitoraggio e gestione consolidato e abbastanza ripetitivo, per le seconde le indicazioni devono servire a capire i trend e i modelli di comportamento del “sistema” per giurarlo nella direzione giusta tenendo conto che un’azione provocherà sicuramente reazioni che non sono in grado di predire con certezza.
Prossimamente cercherò di illustrare gli stili più appropriati per affrontare situazioni complicate e complesse, sempre cercando di essere molto pratico.

Al ritorno dalla Complexity Management Summer School

28 Ago 2013

Posted by in Complexity, Enterprise Architecture, IT Management, IT Transformation

≈ 1 Comment

Tag

,

Vi risparmio la faccia tra il compatimento e il sarcastico di mio figlio quando gli ho detto un paio di mesi fa: “A cavallo di luglio e agosto vado per dieci giorni a seguire un corso”.

“Spero che ne valga la pena” gli ho risposto, e adesso posso dire che ne valeva proprio la pena. Quindi vorrei condividere l’esperienza della partecipazione alla Complexity Management Summer School.

 Image
Innanzi tutto è stata una fatica fantastica.
Dieci giorni e parecchie notti di una intensità pazzesca, con una batteria di “docenti” e ospiti da favola e una ventina di alunni estremamente “intriganti” per varietà di estrazione: dal fotografo professionista, al direttore d’ospedale, al responsabile della innovazione, all’imprenditore belga, al responsabile dell’Enterprise Architecture di una banca, all’HR, alla Social Responsability, e così via.
I docenti restavano a disposizione per 4-5 giorni di cui 1 e mezzo a fare lezioni, giochi, laboratori e “community” o consulenze personali (anche in team) per il resto del tempo.
Diciamo che ci si poteva “ubriacare” facilmente con le diverse sfaccettature della complessità: l’aspetto filosofico, sociologico, tecnologico, organizzativo sono stati quelli più nettamente emersi durante il “corso”.
Per farla molto breve quello che ho imparato è che c’è un tipo di complessità oggettivamente evidente ma spesso non considerata: la complessità sociale.
Il fatto cioè che in qualsiasi aggregato di persone ognuna è un individuo con una sua visione di sé, degli altri (come genere) e del mondo ai vari livelli che si intersecano (la famiglia, le comunità in cui vive -città, azienda, etc.-) e che porta questo suo “essere e credere” nelle interazioni che ha con gli altri, influenzando con la sola sua presenza il comportamento di ognuna di queste.
Alla faccia del disegnare le organizzazioni con rettangoli e frecce!!
Tenere conto della complessità sociale significa tenere conto di questo aspetto, e quindi essere consapevoli della realtà che il comportamento degli aggregati di persone è largamente impredicibile, quindi occorre guidarlo dolcemente piuttosto che prescrivere. La prescrizione influenza i comportamenti pressoché sempre in modo negativo, e sono veramente pochi i casi -almeno nel knowledge work- in cui una prescrizione viene vista come una indicazione chiara da supportare.
La mia conclusione è che tutte le organizzazioni sono socialmente complesse per definizione e gli stili correnti di gestione (command and control) vengono sopportati ma non supportati, con la conseguenza diretta che le persone si difendono anziché partecipare.
Un po’ di riferimenti sui docenti, per chi avesse interesse a leggere.
Alberto De Toni e, particolarmente didattiche le slide 
Alberto Gandolfi su Google Scholar
Valerio Eletti  con un sacco di belle presentazioni 
e l’ospite “off the records” che ci ha mostrato che è possibile cambiare le organizzazioni:
Beppe Carrella e il suo BClab e il suo eBook scaricabile “Provocazioni Manageriali” 
Chi è interessato a qualche approfondimento, non deve fare altro che chiedere.

Disagreement rather than consensus

10 Dic 2012

Posted by in Enterprise Architecture, IT Management, IT Transformation

≈ Lascia un commento

Tag

, , ,

To make more effective decisions, develop disagreement rather than consensus.

Peter F. Drucker

Introduzione

Pochi giorni fa ho iniziato una discussione su Linkedin (Vedi gruppo Strategie competitive e modelli di business) che partiva da questa citazione.

L’idea l’avevo in testa da qualche mese, perché sulla lavagna del mio capo compare una scritta simile:
“Non stai facendo al meglio il tuo lavoro se non sei in disaccordo con me almeno una volta al giorno”.

Ci riflettevo anche perché avevo la necessità di spiegare l’azienda ad alcuni colleghi più giovani,
e perché abbiamo un’organizzazione orizzontale: a mio parere, più difficile spiegare di quelle classiche.

Non volevo però fare un “auto citazione”, ma volevo piuttosto qualcosa che venisse dalla letteratura, ma senza dover spiegare Viable System Model [VSM], System Thinking [ST] o la Cibernetica [KYB].

Nella discussione facevo notare come la critica fosse alla base di una buona decisione,
mentre spesso siamo di fronte a dei modelli organizzativi a “pensiero unico”.
Ovvero modelli in cui il capo ha ragione per definizione e nessuno osa contraddirlo,
pena l’esclusione dai ruoli che contano e derisione da parte dei colleghi.

Costruire invece di distruggere

Nella discussione ho sottolineato una differenza fra critica e critica costruttiva,
però mi hanno fatto notare che tale differenza non esiste, in quanto o si trova una soluzione che mette insieme i pezzi, oppure si aprono due strade differenti.

Io, invece, ritengo che esistano delle critiche fatte per distruggere e altre fatte per costruire.
In particolare mi lascia perplesso l’idea che alla fine della discussione, se non si trova un accordo, allora si aprono delle strade alternative.

Trovo questa situazione estrema e in generale da scongiurare, perché la tensione in azienda sarebbe forte e sarebbero a rischio anche i rapporti umani presenti, oltre alla qualità percepita dal cliente e il fatturato.

Inoltre ritengo che la critica non debba proprio essere fatta con l’obiettivo di intraprendere una strada a scapito di quella originalmente proposta, ma deve essere fatta prima di scegliere una strada, e per ponderare la decisione in maniera più profonda.

Credo cioè che la critica serva per far affiorare i punti di vista e le informazioni meno evidenti o addirittura sconosciute, e non certo per mettere in discussione la decisione per un particolare interesse.

Come si sviluppa il dissenso

Sviluppare il dissenso è tutt’altro che facile.

Da noi lo si fa introducendo persone con caratteri e obiettivi personali molto diversi fra loro.

Non esiste una gerarchia, ma un responsabile del progetto che ha l’obbligo di coniugare
l’interesse del progetto con quello dell’azienda … e non solo quello del progetto come se fosse un’entità isolata rispetto all’azienda stessa.

Inoltre i responsabili di progetto cambiano spesso e quindi tutti si ritrovano con diversi ruoli
su diverse iniziative su diversi clienti in tempi abbastanza ravvicinati.

In un contesto del genere il dissenso è abbastanza fisiologico come l’abitudine al cambiamento.

Dico fisiologico, ma certamente non indolore 🙂

A volte si rischia molta confusione e in qualche caso si sente addirittura parlare di disorganizzazione.

E’ per questo che è importante la presenza di un responsabile.
Dando l’effettiva connotazione al termine, esso non è il capo ma colui che si fa carico
di trovare un equilibrio tra le tante posizioni presenti e di spiegare le sue decisioni.

Non può ignorare l’opinione di qualcuno o addirittura soffocare le opinioni, o quanto meno non è nel suo interesse, perché a breve potrebbe cedere il suo ruolo e vedersi smontate le sue teorie (e i suoi giochetti).

Voi cercate il dissenso ? e come ?

Carriera

In questo tipo di organizzazioni è anche difficile parlare di carriera, almeno nella sua percezione classica.

Non ci sono poltrone su cui sedersi in eterno, non sei giudicato in base al numero dei tuoi subalterni, i numeri dei tuoi progetti sono irrilevanti rispetto a quelli dell’azienda.

Non ho nemmeno una risposta inattaccabile su cosa vuol dire carriera in un’organizzazione orizzontale.

Ti piace quello che fai ?
La tua parola viene riconosciuta come importante ?
Ci sono sempre cose nuove da imparare ?
Condividi le responsabilità e non ti senti solo ?
Non sei mai il colpevole ma uno di quelli che devono trovare la soluzione ?
Non sei escluso dai temi importanti ?

Non so se hai fatto carriera e non so se è merito dell’organizzazione, ma andare al lavoro potrebbe non essere così brutto 🙂

E voi come vi trovate al lavoro ?
E a cosa date il merito o la colpa ?

Referenze

[VSM]
http://en.wikipedia.org/wiki/Viable_system_model

[ST]
http://en.wikipedia.org/wiki/Systems_thinking

[KYB]
http://it.wikipedia.org/wiki/Cibernetica

[Gruppo Imola]
http://www.linkedin.com/company/imola-informatica

[Mirco Casoni]
it.linkedin.com/in/mcasoni

Per tentare un salto di qualità

03 Dic 2012

Posted by in Blogroll, Enterprise Architecture, Enterprise2.0, IT Management

≈ 1 Comment

Esco da un paio di settimane di incontri e tavoli di brainstorming con manager IT di vari livelli riguardanti i loro obiettivi e desideri per il prossimo anno, i piani che li vedono coinvolti, le difficoltà che vivono e che rendono problematica la realizzazione dei piani.

Vorrei condividere alcune riflessioni sintetiche sull’aria che si respira in molte delle aziende che frequento, e tentare alcune domande.

Lo scenario che spesso (troppo) mi viene raccontato è un mix di vari archetipi assai noti nelle organizzazioni tecniche e non, che vado di seguito ad elencare.

Fantasy world

Di fronte ad un problema, una persona si muove a intuito. Spesso i manager non hanno una idea diretta del problema e sulla base di informazioni di seconda mano, parziali e ritenute poco affidabili, devono comunque decidere. Per cui si costruiscono un modello della realtà che secondo loro ha un senso e giustifica le azioni che vogliono intraprendere.

Baronies

Le Baronie sono un pessimo punto di partenza per creare sinergie, essendo straordinariamente resistenti ad ogni cambiamento che non sia legato ad un interesse individuale. Cercano di accaparrarsi risorse di ogni tipo, praticano la competizione fratricida e rifuggono volontariamente la condivisione di informazioni e conoscenza.

Here be Dragons

Strategie e/o attività vengono ostacolate da disturbi dell’ambiente che non erano per nulla inattesi e imprevedibili, ma che non erano state volontariamente evidenziate e preannunciate.

Bean Counters

Il sintomo più frequente consiste in una fissazione ossessiva all’efficienza e al taglio dei costi. Lo stile manageriale dei Bean Counter vede il futuro come semplice estensione (prolungamento) del passato ed il cambiamento come “fare più o meno quello che abbiamo sempre fatto”. Per cui si può migliorare, ma solo facendo meglio quello che si è sempre fatto, nel modo in cui lo si è sempre fatto. Frequentemente gli obiettivi sono espressi da miglioramenti nei grandi numeri, senza preoccuparsi delle azioni reali che vanno fatte e delle loro conseguenze.

Silo Decision

E’ dovuto a processi decisionali altamente politicizzati dovuti a fazioni contrapposte. Ne risultano decisioni che una parte del management non condivide o perché non sono stati coinvolti o perché le considerano impraticabili. Queste due cause sono interdipendenti: vengono escussi se sembra che non condividano e non condividono perché sono stati esclusi. Questo modo di procedere produce strategie che falliscono e non sono attuabili perché vengono ignorati i problemi chiave.

Rooster fight

La presenza più o meno spinta di questi archetipi organizzativi ha conseguenze evidenti: organizzazioni rissose, politiche, poco efficienti, sprecone e inconcludenti, con la maggior parte delle persone frustrate e superoccupate, che producono risultati veramente modesti rispetto alle potenzialità, ma a prezzo di grande fatica soprattutto psicologica.

A questo punto le mie domande:

Può l’Enterprise Architecture fare qualcosa di buono per queste situazioni?

Se no, chi se ne deve occupare?

C’è qualcuno che lo ha posto (o se lo è posto) come obiettivo?

C’è qualcuno che ci è riuscito, con che “cappello” e come?

C’è qualcuno a cui interessa discuterne?

C’è qualcuno a cui interessa migliorare (pur nei limiti e nei perimetri di influenza) o no?