La resistenza al Cambiamento - Resistance to Change
[For English readers, a translation of this article can be found at the end of the page]
In un precedente articolo https://blogs.technet.microsoft.com/marco_moioli/2018/06/25/moving-from-project-to-process/ ho parlato di come i software "as a Service" pongano la tematica di innovazione continua.
Questo è vero per Windows 10, per Office 365, per Salesforce, per Dropbox…
Qualsiasi software che viene fornito da un cloud provider si evolve e questo introduce due macro problematiche:
- Le aziende non sono strutturate per abbracciare cambiamenti tecnologici continui
- Una volta che la nuova funzionalità viene recepita a livello tecnico, è necessario che l'utente la utilizzi
Si dice sempre che la più grande forza nell'universo sia "l'amore" ma io sospetto sia nei primi posti anche "l'abitudine" infatti modificare il modo di lavorare di una persona in modo che, tramite nuovi strumenti, possa migliorare la sua produttività è un'impresa alquanto ardua.
Sono necessari una serie di passi strutturati
- Il volere dell'IT di fornire un nuovo strumento/procedura (qual è il business need?)
- L'implementazione tecnologica del nuovo strumento nell'ambiente esistente
- La comunicazione all'utente finale dell'esistenza del nuovo strumento/procedura
- L'efficacia del cambiamento basata sul fatto che gli utenti utilizzino il nuovo strumento/procedura e che il cambiamento abbia raggiunto effettivamente lo scopo prefissato (più produttività oppure più sicurezza…)
Tutto questo sulla carta sembra semplice ma in realtà è molto più complesso…
Vanno individuati attori, momenti, dipendenze tecnologiche e organizzative.
Va pianificato quando, come e da chi verrà effettuato il change a livello tecnologico.
Va pianificato inoltre quando, come e da chi verrà effettuata la comunicazione all'utente finale sotto forma di email, workshop, video, documenti, ecc...
E' un argomento complesso ma come punto di partenza si può seguire una metodologia come la seguente:
https://www.prosci.com/adkar/adkar-model 
In a previous article https://blogs.technet.microsoft.com/marco_moioli/2018/06/25/moving-from-project-to-process/ I talked about how the software "as a Service" brings "Continuous innovation".
This is true for Windows 10, Office 365, Salesforce, Dropbox...
Any software coming from a cloud provider evolves and this introduces two macro issues:
- Companies are not ready to embrace continuous technological changes
- Once the new functionality is implemented at a technical level, it is necessary for the user to work with it
It's common to say that the greatest force in the universe is "love" but I suspect in the first positions you can find also " habits" in fact it's not easy to change the way users get productive introducing new tools and procedures.
A series of structured steps are required:
- The will of IT department to provide a new tool/procedure (what is the business need that I can address with this tool/procedure?)
- The technological implementation of the new tool in an existing environment
- Communication to the end user about the existence of the new tool/procedure
- The effectiveness of the change based on the fact users are using the new instrument/procedure and the change goal is achieved (more productivity for example or more security…)
This is not simple…
Actors, timeline, technological and organizational dependencies must be identified.
It must be planned when, how and by who the technological change will be carried out.
It should also be planned the final user communications using emails, workshops, videos, documents, etc …
It's a complex topic but as a starting point you can follow this method: