Despite mature technology and various IT experts, the establishment of new software leads to a stress level of 11 on a scale of 1 to 10? This rarely has anything to do with the quality of the software, but as a rule with the acceptance of changes by your employees. The design of change processes should therefore definitely be a matter for the boss.
In change management, it is important to put yourself in the position of those affected and to take their concerns and reservations seriously. Your employees are your capital and know exactly what requirements software has to meet in everyday use in their respective areas of expertise. However, whether they express this and contribute their expertise to the change process depends on the communication culture in the run-up to the software introduction. Therefore tip one:
Openness instead of salami tactics
Even as you are soliciting bids, you should be thinking about which key people should already be involved. These do not have to be exclusively senior executives, but can also simply be people your employees trust and who often take on an unofficial leadership role. Identify the opinion leaders in your company and get them on board!
If future users can understand why a change will bring real benefits, then you have fulfilled your communication mission. Even if you can't get everyone in a euphoric mood: Early information instead of being caught off guard is the respectful way that makes acceptance of change possible in the first place.
By contrast, "snippets" of information give the impression that you are deliberately trying to conceal something - probably something very bad! In doing so, you provoke a toxic rumor mill in which speculation instead of facts becomes the topic. This is confirmed by the Capgemini Consulting study.
The consultancy has regularly conducted comprehensive analyses on the topic of change management since 2003 and describes an important result of these analyses in its 2017 study:
"Front Runners are shown to be more successful at managing culture change because they pay much more attention to people than to technology. This includes creating a culture of trust, allowing mistakes, emphasizing the value of knowledge, and fundamentally focusing more on the wishes and needs of employees. The constitutive element of such a "culture of trust" is early involvement of employees in the transformation and a willingness to allow freedom for personal initiative."
Source: Capgemini Consulting, Culture First! Learning from the pioneers of digital transformation -... Change Management Study 2017
There are no stupid questions
Our second tip: Always remember that not everyone finds it easy to work with software in the same way. Everyone must be allowed to ask questions. Avoiding unnecessary technical terms and abbreviations is crucial for this. If someone explains something to you and continuously uses terms that he should actually know that you don't know, do you feel that the other person treats you with respect? Probably not. And then you don't feel encouraged to ask questions, even though they would be necessary.
As a consequence, this means that problems arise afterwards! You ask yourself: "But I offered that questions could be asked. Why didn't anyone do it at that moment?" The answer is simple: because no one wanted to expose themselves. At this point, the underlying corporate culture plays a big role. Has open and honest exchange been an established way of dealing with people so far?
Practice makes perfect
Especially after long lectures or workshops in which the functionality of the new software has been explained, the participants initially feel overwhelmed by the input. It's hard to remember what was discussed at the beginning. So find a way to capture new knowledge and make it accessible to everyone. Whether it's a shared folder, an area on the intranet, or another type of online wiki, make sure that everyone can revisit the "learning material" at their leisure.
The more often facts are discussed, summarized and repeated, the faster the newly acquired knowledge is consolidated. After all, it is necessary to change work processes that have often become ingrained over years and decades!
After the migration is before the migration
Once the new software has been installed and adapted, that's no reason to put the communication work back in the mental storeroom. Even after the migration, get feedback from users. Ask about problems and find out where there are still pains that need to be alleviated.
It is possible that this will not be your only change project, and if there are real or perceived problems in the aftermath of the software introduction that no one has taken care of, then acceptance will not be greater in future projects. "After all, we saw how great it went last time" is a phrase that is often heard in these contexts. The pessimism cultivated by this is then no longer easy to combat.
In the end, one gets used to pessimism like to a too-tight jacket that can no longer be changed. - André Gide
The decisive success is interpersonal in nature
Even though we as IT consultants naturally stand behind our product technology is not the number one success factor. The goal is problem-free use of the software and satisfied users whose work has actually been simplified. The essence of success, so to speak.
Therefore, in addition to good software - made in germany - we also offer our customers Process consulting and coaching an. We accompany IT managers through the optimization of workflows and bring everyone involved to the table in joint workshops. Together we find out where the shoe pinches and where the need actually lies.
Our approach to the introduction of new software is a template approach. This means that instead of relying on lengthy target/actual concepts, which in the rarest of cases reflect real requirements, we install a template on the test system right at the start of the project and test on real data... Due to the high level of standardization of our products, modifications are often only required to a minor extent. Whereby our developer team implements individual change requests without any problems if required.
From start to go-live, we need only six weeks on average. The investment you make in our software solutions pays for itself - based on empirical values - after just one year.
