KCard : Spontaneous
Change
|
About change
When talking about change there are always at least
two points of view: the ones performing the change and the ones affected by the
change. The ones performing the change are usually convinced that the change
is necessary and beneficial for all. The ones affected by the change often
don't view things from the same perspective. This leads to resistance to
change and many problems (costs, delays, frictions, pressure, stress, ...). Change is one of the biggest communication and
management issues companies come across. And it happens often and usually not
too well. Many enterprise activities require change to be handled (PLM, Six
Sigma, TQM, ERP, Lean, ...) but in reality few
actually give pertinent techniques or advice on how to do so. Here you'll
find an original technique for managing change which when applied can make
change an easy process rather than a tedious one. Spontaneous change
What we call spontaneous change is a method for
inducing change in an organisation without suffering any resistance. The
magic is in the word 'inducing', because it doesn't say who 'induces'. The
idea is to make change spontaneous, that is make the people affected by the
change be the ones who create the change. This is possible by providing the motivations and
tools to create the change. Instead of imposing change on people rather
provide them the context to want it and ask for it. But, 'providing the context' itself
requires changing something (the context). So, how can this be resolved? The fact is that a very little change in context can
generate (via this method) very big change on people. So, spontaneous change
does in fact require some initial contextual change to be performed (and
imposed) but this will be much better accepted because it will be very mild
(compared to the real wanted change, which will become spontaneous) and less
focused usually (avoiding crystallising specific aspects). In fact, the
initial contextual change can clearly be geared towards popularity, because it
isn't itself the finality, so it can dismiss all controversial elements and
keep only the consensual. Change in Information Technology
This method gives very good results for example for
deploying new Information Systems (for example an
ERP) to users. One of the biggest causes of failure with IS is simply that the users don't accept the change which is
imposed on them, thus finding all the possible reasons for not using the IS
which finally appears to be an enormous waste. Why does this happen? Our experience is that usually
large ISs (specialy ERPs) require a too bigger step for people to accept it, the new IS simply changes their ways too much in one
move. The usual method used for ERP deployment doesn't solve this as instead
of making change progressive at individual scale it makes it progressive at
organisational scale. Specifically, the usual process is to deploy the system
progressively across the organisation by starting typically by finance, then
moving to marketing, then sales and so on. Although this may look good on
paper, in fact it doesn't handle the real problem which is individual change.
A better solution is to deploy the IS progressively on an individual level
and globally at the organisation level. What this requires though is to be able to deploy
progressively at the individual level an IS which will at first basically
change as little as possible, if possible nothing (people do the same as
before, but, for example, instead of filling in a paper formulary, they fill
in a electronic one, but with the same fields, no 'clever/innovative' helpers
yet). Leave the people use this then Magical Change will happen: people will
start proposing improvements themselves, that is
they are asking for change. Usually, their requests will be pertinent because
they are the people who know their job and should be willing to improve
(motivational incentives can be used), and once into the 'change process'
they will easier accept ideas from others too (who can orient change to what
they finally want). In fact, at this point it is likely that the people who initially
wanted the change will find themselves trying to slow down and moderate
peoples' change requests. However promising this seems,
it in fact isn't too popular for now because ERP vendor's sell products which
aren't suited for this method because they include complex functionality
which imposes change on the individuals brutally, thus only leaving them the
'department by department' approach. Applying this requires a more adapted
approach to ISs which allows a more progressive
introduction on the individual level. |
Ideas to develop
|