Imola Informatica

~ Project Partners

Imola Informatica

Archivi della categoria: IT Transformation

Warm Wallet: architettura di wallet digitale per servizi IT basati su Blockchain

31 venerdì Ago 2018

Posted by Michele Cappelletti in IT Transformation

≈ Lascia un commento

Tag

architettura, bitcoin, blockchain, wallet

Le blockchain stanno rapidamente prendendo piede come architetture rivoluzionarie, aprendo la strada a nuove opportunità di business basate su interazioni sicure e decentralizzate.

I wallet sono lo strumento con cui l’utente si interfaccia con la blockchain, forniscono le funzionalità per gestire il saldo e custodiscono le chiavi necessarie alla firma digitale delle transazioni.

Per i wallet esistono differenti tipologie di architetture e diversi componenti hardware/software disponibili sul mercato, con diversi livelli di accessibilità e affidabilità.

In questo articolo sono analizzati i diversi tipi di wallet e viene proposta un’architettura di wallet che unisce l’accessibilità e i benefici di un wallet online con la sicurezza dei cold storage basati su sistemi disconnessi dalla rete.

Schema di interazione tra utenti e blockchain


 

Wallet

Un wallet è il software che consente di interagire con una o più blockchain. Consente inoltre di eseguire e ricevere transazioni, visualizzarne lo stato e tenere traccia del proprio saldo. Continua a leggere →

Blockchain: come sapere se “lei” è quella giusta

25 venerdì Mag 2018

Posted by Michele Cappelletti in IT Transformation

≈ Lascia un commento

Tag

blockchain, dlt

Il numero di blockchain disponibili sul mercato è in costante aumento, ogni giorno riceviamo mail di partecipazione a ICO o un invito a provare l’ultima blockchain… Ma quali sono le caratteristiche di una blockchain? Come scegliere quella più adatta al proprio scopo?

Una volta determinato il caso d’uso e compresi i motivi per cui la blockchain apporti un reale vantaggio al proprio sistema, arriva il momento di scegliere quale blockchain utilizzare.

Mentre alcune blockchain hanno caratteristiche simili, altre differiscono molto: la scelta quindi non è scontata e una non vale l’altra. Come per l’adozione di qualsiasi software è necessaria una valutazione.

In questo articolo ragioniamo su quali siano alcuni dei principali requisiti da tenere in considerazione per la selezione della blockchain più opportuna al proprio contesto di applicazione, quali ad esempio utilizzi finanziari (scambio di criptovaluta) o per il tracciamento di eventi (supply-chain, notarizzazione di documenti).

L’analisi riguarda le macro aree:

  • Requisiti sulla criticità del servizio
  • Requisiti sui dati
  • Requisiti su prestazioni e integrazioni
  • Costi

Requisiti sulla criticità del servizio

È necessario tenere ben presente il contesto business in cui si opera domandandosi quale sia il livello di criticità del servizio erogato, ad esempio situazioni potenzialmente pericolose per l’uomo o per la natura, i ricavi economici legati al servizio, o ancora implicazioni legali. Continua a leggere →

DevOps, non solo strumenti ma soprattutto persone

26 lunedì Feb 2018

Posted by Renzo Racioppi in IT Transformation

≈ Lascia un commento

Tag

automazione, collaborazione, DevOps, silos

La trasformazione digitale è un processo che le aziende devono attraversare per poter mantenere un vantaggio competitivo in un contesto in cui il mercato è sempre più mutevole. Gli approcci di gestione dei sistemi IT tradizionali, basati su silos aziendali, risultano oramai inadeguati di fronte alle esigenze di cambiamenti frequenti in tempi molto stretti.
Queste sfide, in aggiunta al fatto che i sistemi informativi diverranno sempre più complessi, spingono le organizzazioni a una presa di coscienza per poter affrontare una situazione che rischia di diventare ingestibile.

Proprio per questo, sempre di più le organizzazioni italiane stanno cercando di accogliere i principi DevOps all’interno del proprio ecosistema IT. DevOps è una metodologia riconosciuta a livello internazionale ed è la combinazione di due termini: Development (le attività di sviluppo) e Operations (la messa in produzione di quanto realizzato dagli sviluppatori). Il nome incarna un’esigenza di maggior collaborazione e coinvolgimento tra gli uffici, entrando quindi in forte contrapposizione al modello a silos, dove ogni reparto tende a procedere “per conto proprio” o addirittura a discapito degli altri.

Secondo la nostra esperienza, DevOps presenta molteplici definizioni, a seconda del punto di vista che si vuole enfatizzare: Continua a leggere →

Video

Dal prodotto ai servizi: l’innovazione secondo CucinaBarilla

19 lunedì Feb 2018

Posted by Maria Seralessandri in IT Transformation, Open Innovation Lab

≈ Lascia un commento

Tag

CucinaBarilla, Lean, Matteo Gori, Prototipazione

“Un buon prodotto non basta più. Per stare in tavola, la ricetta giusta è innovare”: Matteo Gori, managing director di CucinaBarilla ha raccontato la sua esperienza in Barilla all’Open Innovation Lab. L’evento si è svolto il 2 febbraio presso la sala espositiva di Cooperativa Ceramica d’Imola ed è stato organizzato da Imola Informatica, Innovami e dall’Università di Bologna.

Il cambiamento nel modello di business

Il progetto CucinaBarilla, lanciato nel 2015 dopo diverse sperimentazioni, prevede l’utilizzo di un forno particolare, disegnato in partnership con Whirpool, per cucinare una serie di piatti pronti sviluppati da Barilla. Il forno è in grado di leggere quantità d’acqua, tempo, modalità di cottura e temperatura da una etichetta RFID (Radio Frequency Identification) presente sulle confezioni dei prodotti. Per questo il forno Cucina Barilla “cucina al posto tuo e lo fa sempre bene”.

Nel suo racconto Matteo Gori ha evidenziato come, partendo da un modello di business che non funzionava, l’azienda ha avuto il coraggio di ammettere l’errore e rivedere completamente il progetto.

All’inizio infatti occorreva acquistare separatamente forno e piatti pronti sui canali di vendita tradizionali della grande distribuzione. Il costo del forno, anche se può essere usato come un normale microonde, è abbastanza elevato (699 €) e difficilmente le persone sono incentivate a sperimentare.
Continua a leggere →

Smart Factory e Smart People

22 mercoledì Nov 2017

Posted by Maria Seralessandri in Digital Society, Imola, Industry 4.0, IT Transformation, Management

≈ Lascia un commento

Tag

Industria 4.0, Innovazione, lean production, Open Innovation Lab, Toyota Production System, Università di Bologna

Industria 4.0? Non solo robot, ma persone!

Lo scorso venerdì 3 novembre si è svolto all’interno delle iniziative promosse dall’Open Innovation Lab (OiLab) l’incontro “Industria 4.0? Persone, non robot!” in cui è intervenuto Maurizio Mazzieri, Senior Advisor di Toyota Material Handling Italia. L’evento è nato dalla collaborazione tra Imola Informatica s.p.a, Innovami e l’Università di Bologna. In fondo trovate tutti i riferimenti e i video delle interviste.

Il tema Industria 4.0 è affascinante ed è una delle sfide più importanti che il settore manifatturiero non solo italiano dovrà affrontare nei prossimi anni. Prende il nome dall’iniziativa europea Industry 4.0, a sua volta ispirata dal progetto tedesco Industrie 4.0 e prevede forti investimenti in ambito produttivo per integrare le nuove tecnologie digitali con i sistemi fisici. L’obiettivo è innovare le imprese per essere competitive sul mercato, favorire la crescita e lo sviluppo di nuovi prodotti e servizi. In Italia è stato avviato un piano nazionale che prevede diversi benefici, in termini di incentivi economici e agevolazioni fiscali.

Il dibattito è stato senza slide davanti ad un pubblico misto di aziende, ricercatori, studenti, startup. È schietto e diretto Mazzieri, mi dicono che sia così anche quando tiene lezioni alla Business School di Bologna.

Continua a leggere →

Open Living Imo…Lab

20 martedì Giu 2017

Posted by Maria Seralessandri in Imola, IT Transformation

≈ Lascia un commento

Tag

Cloud, Docker, Laboratori, Rancher, Unibo, Workshop

Il prossimo 23 giugno a Imola, presso la sala corsi Innovami (via Selice, 84/a) l’Università di Bologna, Imola Informatica e Innovami organizzeranno un evento dal titolo: “Applicazioni in cloud – Strumenti e modelli per far crescere l’innovazione in azienda”.

Interverranno Antonio Corradi (Università di Bologna), Claudio Bergamini (Imola Informatica), Gabriele Brusa (Innovami). L’evento è rivolto a ricercatori, studenti, imprese, startup e rappresenta un’anteprima di un ciclo di incontri ispirati al modello della rete degli European Network of Living Labs (ENoLL)

Ma cos’è un open living lab e perché Imola Informatica ha deciso di partecipare? La European Network of Living Labs è una federazione internazionale no-profit di laboratori in Europa e nel mondo. Fondata a novembre 2006 sotto il patrocinio della Presidenza europea, la rete è cresciuta molto in questi anni e attualmente ne fanno parte circa 320 laboratori accreditati.

Lo spirito su cui si basa la rete degli ENoLL è che l’innovazione non sia prerogativa di pochi soggetti o il risultato di sporadiche e geniali intuizioni dei singoli, ma che più spesso emerga dalla connessione di più individui, dall’esplorazione e dal contributo di conoscenze provenienti da campi diversi. Gli ambienti collaborativi ed eterogenei facilitano lo scambio di informazioni e le interazioni tra le persone. Gli strumenti tecnologici oggi a disposizione aumentano rispetto al passato la probabilità che nuove idee possano trasformarsi in progetti, prodotti e servizi.

Imola Informatica, l’Università di Bologna e Innovami vogliono contribuire a creare una rete che coinvolga ricercatori, studenti, università, enti pubblici, aziende e startup. L’obiettivo è avvicinare il mondo della ricerca a quello dell’imprenditoria fornendo uno spazio collaborativo e aperto con gli strumenti necessari a sviluppare e sperimentare liberamente in ambito digitale.

Il tema centrale del primo incontro sarà il cloud e come nel concreto possa portare vantaggi alle aziende, semplificare la gestione delle risorse hardware e software, velocizzare il tempo di avvio di nuove iniziative e ridurre i costi.
Nel corso del workshop verranno mostrati, a titolo di esempio, alcuni strumenti per cloud computing, tra cui Docker e Rancher.

Perché organizzare Imola Programma?

09 giovedì Mar 2017

Posted by cbergamini in Complexity, Imola, IT Transformation, Open Data, Web2.0

≈ Lascia un commento

 

High tech, agenda digitale, smart cities, industria 4.0, internet delle cose, agricoltura smart, intelligenza artificiale, big data, app, social media, web marketing, robotica, stampa 3D, crittografia. Società digitale, pensiero computazionale, startup, privacy informatica, cybersecurity, cyberbullismo, identità digitale, oblio digitale…

Quando Imola Informatica è nata, nel 1983, tutti dicevano: l’informatica è il domani. Dopo più di 30 anni si continua a dirlo, e nel linguaggio di tutti i giorni c’è la sensazione che sia effettivamente così.

Ma davvero le persone comuni se ne rendono conto, al di là dello smartphone perennemente in mano? E chi usa computer e tablet per ragioni professionali ha un’idea della relazione che collega il computer-telefono che guarda continuamente e gli strumenti che usa al lavoro? Nel sovraccarico informativo che riguarda la tecnologia fanno molta fatica a districarsi gli addetti ai lavori, figuriamoci come si possono orientare le persone comuni.

Poi c’è l’immaginario collettivo. La Silicon Valley, i miliardari ventenni, gli hacker, il cyberspionaggio russo, le spie cinesi, gli attacchi informatici, i virus, le auto che si guidano da sole, le fabbriche che producono da sole, metà delle professioni intellettuali che spariranno nei prossimi x anni, i robot che operano meglio dei primari e le macchine che vincono a scacchi e ai quiz.

L’informatica viene percepita come una cosa lontana nello spazio, fatta da persone strane, un misto tra geni e pazzi, che a quel livello non ci riguarda. L’informatica che ci riguarda è comprare su Amazon ed eBay, usare Facebook, WhatsApp, Instagram, TripAdvisor, AirBnb, guardare YouTube, cercare su Google.

Imola Programma, il 10 e 11 marzo 2017 all’Autodromo Enzo e Dino Ferrari a Imola, nasce per cercare di migliorare la comprensione della tecnologia da parte di chi la utilizza.

Ha come obiettivo affrontare temi di cui tanto si sente parlare ma che coinvolgono poco le persone normali.
Da vicino.
Potendo interrompere per fare domande.
Potendo affrontare un tema di cui ci importa, con qualcuno che ci può spiegare.
Con l’occasione di vedere che l’informatica non è lontana come si potrebbe pensare, c’è chi se ne occupa anche qui, e che alcuni addirittura vendono le loro conoscenze o le cose che hanno costruito nella Silicon Valley o in India o in Germania.
Imola Programma si rivolge particolarmente ai giovani, per aiutarli a capire, a scegliere, a smitizzare.
A capire che Imola offre tanto a chi studia informatica, a mostrare loro che si raccolgono sotto questo nome aziende che fanno mestieri diversissimi, appassionanti, importanti, spesso anche divertenti o affascinanti.
A vedere che se ne occupano persone normali, che hanno studiato le cose giuste e oggi fanno una serie di mestieri molto richiesti, e che saranno ancora più richiesti in futuro.

E si rivolge alle aziende di ogni tipo e dimensione, per avvicinarle in modo “amichevole” a un mondo che intimidisce spesso chi non ha una cultura in materia.

Per Imola Informatica e Local Focus l’organizzazione di questo evento è stato un grosso impegno da tutti i punti di vista, ma quello che ci sembra di vedere, forse condizionati dall’ottimismo, è di avere creato una bella opportunità.

Per Imola e le persone che ci vivono, prima di tutto.

Per i curiosi non imolesi: potrete saperne di più su localfocus.it/imola-programma e con #ImolaProgramma sui social.

Complicato e Complesso. Cosa fare di diverso?

02 lunedì Dic 2013

Posted by cbergamini 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 venerdì Ago 2013

Posted by cbergamini 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 mercoledì Ago 2013

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

≈ 1 Comment

Tag

Complexity, IT Management

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.
Alessandro Cravera 
Alberto De Toni e, particolarmente didattiche le slide 
Alberto Gandolfi su Google Scholar
Valerio Eletti  con un sacco di belle presentazioni 
Dario Simoncini
Marinella De Simone
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.
← Vecchi Post

Meta

  • Accedi
  • RSS degli articoli
  • RSS dei commenti
  • WordPress.org

Category Cloud

Blogroll Complexity Digital Society English Enterprise2.0 Enterprise Architecture Enterprise Information Management Imola Industry 4.0 Infografica IT Management IT Transformation Linked Open Data Management Open Data Open Innovation Lab SemWeb Senza categoria Sicurezza SOA Strategy Università Web2.0

Post Recenti

  • Sicurezza e password degli utenti: anatomia di un data breach
  • La minaccia dei malware bancari
  • Warm Wallet: architettura di wallet digitale per servizi IT basati su Blockchain
  • Le nuove sfide della sicurezza informatica
  • Auto-organizzazione: un equilibrio tra caos e ordine eccessivo

Categorie

  • Blogroll
  • Complexity
  • Digital Society
  • English
  • Enterprise Architecture
  • Enterprise Information Management
  • Enterprise2.0
  • Imola
  • Industry 4.0
  • Infografica
  • IT Management
  • IT Transformation
  • Linked Open Data
  • Management
  • Open Data
  • Open Innovation Lab
  • SemWeb
  • Senza categoria
  • Sicurezza
  • SOA
  • Strategy
  • Università
  • Web2.0

Archivi

  • dicembre 2018
  • settembre 2018
  • agosto 2018
  • luglio 2018
  • giugno 2018
  • maggio 2018
  • febbraio 2018
  • dicembre 2017
  • novembre 2017
  • settembre 2017
  • agosto 2017
  • luglio 2017
  • giugno 2017
  • marzo 2017
  • febbraio 2017
  • gennaio 2017
  • novembre 2016
  • ottobre 2016
  • agosto 2016
  • febbraio 2016
  • dicembre 2013
  • agosto 2013
  • febbraio 2013
  • gennaio 2013
  • dicembre 2012
  • novembre 2012
  • febbraio 2012
  • gennaio 2009
  • marzo 2008
  • gennaio 2008
  • dicembre 2007
  • agosto 2007
  • maggio 2007
  • aprile 2007
  • marzo 2007
  • febbraio 2007
  • gennaio 2007
  • dicembre 2006

Proudly powered by WordPress Tema: Chateau di Ignacio Ricci.