Mixing
Software training for skeptical operators [closed]
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
6
down vote
favorite
I have the responsibility for training around 200 operators of a production plant for a new software. This software will be an essential tool for those operators since they will have to confirm there basically every production step they do. Also, it functions fundamentally different than the software they have been using so far for this purpose (SAP) and it cannot be translated entirely from English to German, which means that operators will have to learn some few English vocabularies to understand what some buttons in that new software are doing.
During my first training sessions, many operators have been strictly against the new software. Many of them said, they cannot understand English and also said that they do not have capacities to learn that new software and want to stick with the old (unfortunately, the company cannot do that).
How can I "sell" them that software in a way they are more willing to adapt to it and learn those few vocabularies? How can I present them that software in a way that they do not leave meeting room unhappy and are willing to learn the new software?
training
edited Aug 7 '15 at 10:28
Angelo
6,15621631
asked Aug 7 '15 at 9:07
Acroneos
1,0422814
closed as off-topic by Jim G., scaaahu, Alec, gnat, mcknz Aug 12 '15 at 21:47
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions asking for advice on what to do are not practical answerable questions (e.g. "what job should I take?", or "what skills should I learn?"). Questions should get answers explaining why and how to make a decision, not advice on what to do. For more information, click here." – Jim G., scaaahu, Alec, gnat, mcknz
 |Â
show 4 more comments
up vote
6
down vote
favorite
I have the responsibility for training around 200 operators of a production plant for a new software. This software will be an essential tool for those operators since they will have to confirm there basically every production step they do. Also, it functions fundamentally different than the software they have been using so far for this purpose (SAP) and it cannot be translated entirely from English to German, which means that operators will have to learn some few English vocabularies to understand what some buttons in that new software are doing.
During my first training sessions, many operators have been strictly against the new software. Many of them said, they cannot understand English and also said that they do not have capacities to learn that new software and want to stick with the old (unfortunately, the company cannot do that).
How can I "sell" them that software in a way they are more willing to adapt to it and learn those few vocabularies? How can I present them that software in a way that they do not leave meeting room unhappy and are willing to learn the new software?
training
edited Aug 7 '15 at 10:28
Angelo
6,15621631
asked Aug 7 '15 at 9:07
Acroneos
1,0422814
closed as off-topic by Jim G., scaaahu, Alec, gnat, mcknz Aug 12 '15 at 21:47
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions asking for advice on what to do are not practical answerable questions (e.g. "what job should I take?", or "what skills should I learn?"). Questions should get answers explaining why and how to make a decision, not advice on what to do. For more information, click here." – Jim G., scaaahu, Alec, gnat, mcknz
4
You haven't "sold" it here -- is this software actually better for them? It does seem counterproductive to train workers to learn a new language to use the software rather than translate the software - software is supposed to be the more flexible one. I'd be unhappy too if my employer told me I needed to learn a foreign language to use software that's essential to my job and I had to use it to confirm every step I did. It sounds like you're trying to find a "nice" way to tell operators that the software has already been chosen and they have no choice but to adapt to it or lose their job.
– Johnny
Aug 7 '15 at 9:53
2
Obviously the decision is already done and they can not do anything against it. They will not be happy, regardless what you tell them. But you can make it as easy as possible for them. I would recommend designing a cheat sheet where the most important commands and vocabularys can be found. They should pin that near their terminals.
– jwsc
Aug 7 '15 at 10:12
1
@Johnny, these problems can occur even if there was no language barrier in the system. There are many good reasons for switching over software and sadly it is never going to seem like a "good deal" for the operators unless it actually makes their worker easier or better in some tangible way they can observe.
– Angelo
Aug 7 '15 at 10:31
1
True, but adding a language barrier on top of the new software seems like the company doesn't really value the operators who have to use the software daily, which makes it even harder to "sell" the software and makes it seem like the company is putting their interests above the employees and makes adoption if the software much harder than it needs to be. It seems that "language" should be at the top of the list of requirements for new software.
– Johnny
Aug 7 '15 at 10:49
2
I don't know about Germany, but there could be further legal aspects to the language problem. Where I am from (France), it is mandatory to translate everything. Some of our internal softwares aren't fully translated, but the users didn't complain about it. If they did however, my company would legally be forced to translate all of them.
– Aserre
Aug 7 '15 at 12:02
 |Â
show 4 more comments
up vote
6
down vote
favorite
up vote
6
down vote
favorite
I have the responsibility for training around 200 operators of a production plant for a new software. This software will be an essential tool for those operators since they will have to confirm there basically every production step they do. Also, it functions fundamentally different than the software they have been using so far for this purpose (SAP) and it cannot be translated entirely from English to German, which means that operators will have to learn some few English vocabularies to understand what some buttons in that new software are doing.
During my first training sessions, many operators have been strictly against the new software. Many of them said, they cannot understand English and also said that they do not have capacities to learn that new software and want to stick with the old (unfortunately, the company cannot do that).
How can I "sell" them that software in a way they are more willing to adapt to it and learn those few vocabularies? How can I present them that software in a way that they do not leave meeting room unhappy and are willing to learn the new software?
training
edited Aug 7 '15 at 10:28
Angelo
6,15621631
asked Aug 7 '15 at 9:07
Acroneos
1,0422814
I have the responsibility for training around 200 operators of a production plant for a new software. This software will be an essential tool for those operators since they will have to confirm there basically every production step they do. Also, it functions fundamentally different than the software they have been using so far for this purpose (SAP) and it cannot be translated entirely from English to German, which means that operators will have to learn some few English vocabularies to understand what some buttons in that new software are doing.
During my first training sessions, many operators have been strictly against the new software. Many of them said, they cannot understand English and also said that they do not have capacities to learn that new software and want to stick with the old (unfortunately, the company cannot do that).
How can I "sell" them that software in a way they are more willing to adapt to it and learn those few vocabularies? How can I present them that software in a way that they do not leave meeting room unhappy and are willing to learn the new software?
training
edited Aug 7 '15 at 10:28
Angelo
6,15621631
asked Aug 7 '15 at 9:07
Acroneos
1,0422814
edited Aug 7 '15 at 10:28
Angelo
6,15621631
edited Aug 7 '15 at 10:28
Angelo
6,15621631
edited Aug 7 '15 at 10:28
Angelo
6,15621631
6,15621631
asked Aug 7 '15 at 9:07
Acroneos
1,0422814
asked Aug 7 '15 at 9:07
Acroneos
1,0422814
asked Aug 7 '15 at 9:07
Acroneos
1,0422814
1,0422814
closed as off-topic by Jim G., scaaahu, Alec, gnat, mcknz Aug 12 '15 at 21:47
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions asking for advice on what to do are not practical answerable questions (e.g. "what job should I take?", or "what skills should I learn?"). Questions should get answers explaining why and how to make a decision, not advice on what to do. For more information, click here." – Jim G., scaaahu, Alec, gnat, mcknz
closed as off-topic by Jim G., scaaahu, Alec, gnat, mcknz Aug 12 '15 at 21:47
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions asking for advice on what to do are not practical answerable questions (e.g. "what job should I take?", or "what skills should I learn?"). Questions should get answers explaining why and how to make a decision, not advice on what to do. For more information, click here." – Jim G., scaaahu, Alec, gnat, mcknz
4
You haven't "sold" it here -- is this software actually better for them? It does seem counterproductive to train workers to learn a new language to use the software rather than translate the software - software is supposed to be the more flexible one. I'd be unhappy too if my employer told me I needed to learn a foreign language to use software that's essential to my job and I had to use it to confirm every step I did. It sounds like you're trying to find a "nice" way to tell operators that the software has already been chosen and they have no choice but to adapt to it or lose their job.
– Johnny
Aug 7 '15 at 9:53
2
Obviously the decision is already done and they can not do anything against it. They will not be happy, regardless what you tell them. But you can make it as easy as possible for them. I would recommend designing a cheat sheet where the most important commands and vocabularys can be found. They should pin that near their terminals.
– jwsc
Aug 7 '15 at 10:12
1
@Johnny, these problems can occur even if there was no language barrier in the system. There are many good reasons for switching over software and sadly it is never going to seem like a "good deal" for the operators unless it actually makes their worker easier or better in some tangible way they can observe.
– Angelo
Aug 7 '15 at 10:31
1
True, but adding a language barrier on top of the new software seems like the company doesn't really value the operators who have to use the software daily, which makes it even harder to "sell" the software and makes it seem like the company is putting their interests above the employees and makes adoption if the software much harder than it needs to be. It seems that "language" should be at the top of the list of requirements for new software.
– Johnny
Aug 7 '15 at 10:49
2
I don't know about Germany, but there could be further legal aspects to the language problem. Where I am from (France), it is mandatory to translate everything. Some of our internal softwares aren't fully translated, but the users didn't complain about it. If they did however, my company would legally be forced to translate all of them.
– Aserre
Aug 7 '15 at 12:02
 |Â
show 4 more comments
4
You haven't "sold" it here -- is this software actually better for them? It does seem counterproductive to train workers to learn a new language to use the software rather than translate the software - software is supposed to be the more flexible one. I'd be unhappy too if my employer told me I needed to learn a foreign language to use software that's essential to my job and I had to use it to confirm every step I did. It sounds like you're trying to find a "nice" way to tell operators that the software has already been chosen and they have no choice but to adapt to it or lose their job.
– Johnny
Aug 7 '15 at 9:53
2
Obviously the decision is already done and they can not do anything against it. They will not be happy, regardless what you tell them. But you can make it as easy as possible for them. I would recommend designing a cheat sheet where the most important commands and vocabularys can be found. They should pin that near their terminals.
– jwsc
Aug 7 '15 at 10:12
1
@Johnny, these problems can occur even if there was no language barrier in the system. There are many good reasons for switching over software and sadly it is never going to seem like a "good deal" for the operators unless it actually makes their worker easier or better in some tangible way they can observe.
– Angelo
Aug 7 '15 at 10:31
1
True, but adding a language barrier on top of the new software seems like the company doesn't really value the operators who have to use the software daily, which makes it even harder to "sell" the software and makes it seem like the company is putting their interests above the employees and makes adoption if the software much harder than it needs to be. It seems that "language" should be at the top of the list of requirements for new software.
– Johnny
Aug 7 '15 at 10:49
2
I don't know about Germany, but there could be further legal aspects to the language problem. Where I am from (France), it is mandatory to translate everything. Some of our internal softwares aren't fully translated, but the users didn't complain about it. If they did however, my company would legally be forced to translate all of them.
– Aserre
Aug 7 '15 at 12:02
4
4
You haven't "sold" it here -- is this software actually better for them? It does seem counterproductive to train workers to learn a new language to use the software rather than translate the software - software is supposed to be the more flexible one. I'd be unhappy too if my employer told me I needed to learn a foreign language to use software that's essential to my job and I had to use it to confirm every step I did. It sounds like you're trying to find a "nice" way to tell operators that the software has already been chosen and they have no choice but to adapt to it or lose their job.
– Johnny
Aug 7 '15 at 9:53
You haven't "sold" it here -- is this software actually better for them? It does seem counterproductive to train workers to learn a new language to use the software rather than translate the software - software is supposed to be the more flexible one. I'd be unhappy too if my employer told me I needed to learn a foreign language to use software that's essential to my job and I had to use it to confirm every step I did. It sounds like you're trying to find a "nice" way to tell operators that the software has already been chosen and they have no choice but to adapt to it or lose their job.
– Johnny
Aug 7 '15 at 9:53
2
2
Obviously the decision is already done and they can not do anything against it. They will not be happy, regardless what you tell them. But you can make it as easy as possible for them. I would recommend designing a cheat sheet where the most important commands and vocabularys can be found. They should pin that near their terminals.
– jwsc
Aug 7 '15 at 10:12
Obviously the decision is already done and they can not do anything against it. They will not be happy, regardless what you tell them. But you can make it as easy as possible for them. I would recommend designing a cheat sheet where the most important commands and vocabularys can be found. They should pin that near their terminals.
– jwsc
Aug 7 '15 at 10:12
1
1
@Johnny, these problems can occur even if there was no language barrier in the system. There are many good reasons for switching over software and sadly it is never going to seem like a "good deal" for the operators unless it actually makes their worker easier or better in some tangible way they can observe.
– Angelo
Aug 7 '15 at 10:31
@Johnny, these problems can occur even if there was no language barrier in the system. There are many good reasons for switching over software and sadly it is never going to seem like a "good deal" for the operators unless it actually makes their worker easier or better in some tangible way they can observe.
– Angelo
Aug 7 '15 at 10:31
1
1
True, but adding a language barrier on top of the new software seems like the company doesn't really value the operators who have to use the software daily, which makes it even harder to "sell" the software and makes it seem like the company is putting their interests above the employees and makes adoption if the software much harder than it needs to be. It seems that "language" should be at the top of the list of requirements for new software.
– Johnny
Aug 7 '15 at 10:49
True, but adding a language barrier on top of the new software seems like the company doesn't really value the operators who have to use the software daily, which makes it even harder to "sell" the software and makes it seem like the company is putting their interests above the employees and makes adoption if the software much harder than it needs to be. It seems that "language" should be at the top of the list of requirements for new software.
– Johnny
Aug 7 '15 at 10:49
2
2
I don't know about Germany, but there could be further legal aspects to the language problem. Where I am from (France), it is mandatory to translate everything. Some of our internal softwares aren't fully translated, but the users didn't complain about it. If they did however, my company would legally be forced to translate all of them.
– Aserre
Aug 7 '15 at 12:02
I don't know about Germany, but there could be further legal aspects to the language problem. Where I am from (France), it is mandatory to translate everything. Some of our internal softwares aren't fully translated, but the users didn't complain about it. If they did however, my company would legally be forced to translate all of them.
– Aserre
Aug 7 '15 at 12:02
 |Â
show 4 more comments
2 Answers
2
active
oldest
votes
up vote
10
down vote
Change is a difficult thing for organizations to go through and it is really hard for everyone in the org to change at the same time. The good news is that scenarios like yours have been studied extensively.
You'll want to read about the "technology adoption lifecycle" (and related concepts) and how to apply those ideas in a practical setting. This was originally applied to the diffusion of technology for farms, but it applies very well to organizations which are releasing new tools to their workforce.
To boil it down into a nutshell, there are three phases to such a roll out:
Cultivate "innovators" in your user-group. Find a small number users who are willing to embrace the new system and who are well-regarded by others in the organization. These "alpha-users" are willing to try new things and are eager to provide feedback to you as well as evangelize the new system to "early adopters". You can refine your training materials by first using them with the innovators and early adopters. This group of people will typically have been mentors for others in the organization and thus will know the limitations of the others. These people will tell you if you need to make changes (for example, if the language issue is a serious problem or just a straw-man argument).
After that, you can begin large-scale training for "majority" users. Perhaps even directly enlisting the help of those who became power-users, provide pragmatic training that addresses the concerns you learned about during your interaction with innovators and early adopters. The majority users will have seen that the early adopters can handle the system and will gain confidence that they can make it work too.
Finally, you'll always have what is known in the literature as "laggards". These are folks that are profoundly resistant to change. The common advice for these people ranges from providing individualized attention to using pressure from management. The good news is that if you've been careful with your roll-out, there won't be too many laggards.
Of course, all this takes time and planning. But if your users are counted in the hundreds, it is worthwhile.
If you don't believe in the technology adoption cycle theory, the concept of trying out your training on a small group of people FIRST is valuable.
I should add that "innovator, early-adopter, majority, laggard" are just convenient names for roles that various people take in this process. They're not labels that apply to the workers personally. Its important to make that subtle distinction if you ever communicate this to the organization.
answered Aug 7 '15 at 10:23
Angelo
6,15621631
1
Nice answer. :)
– Jane S♦
Aug 7 '15 at 11:48
suggest improvements |Â
up vote
1
down vote
I'd say that first you have to solve the translation problem. Expecting people to learn a new language to use software is really unacceptable. I realize your company has foolishly made the decision to go ahead, so you need to provide training materials and materials to be used on the shop floor tho help people translate. For instance could you do screenshots of the screens with the English and then make a version of the screenshot with the German translation that shows just under it on a page? This could then be posted near the place where the software is used, so people can look at it when they get tired or are new to using the software.
Next you are going to have to be blunt with them, there is no possibility of retaining the current system, Let them understand what is driving the change and how that change will be good for the company. If there are things the software will do that the old system would not and those are things the people on the floor are interested in, make sure to highlight those areas in the training. Sadly I suspect the real advantages of this software are only at the management level and that indeed it will make doing their jobs harder. (I say that because I have almost never seen a software change that made things easier for the users of the software.)
Remind them frequently that once they get used to the new interface, it will get significantly easier. Then give them lots of hands on exercises. Give them real world problems and encourage them to talk about the edge cases they run across when performing their work and show them what do do with the system when those less frequent things happen. Again a cheat sheet here is helpful.
As far as the training, you need to stop the complaints when they start. Say something along the lines of "I'm sorry you feel that way, but the decision is not going to change and you have to learn how to use this software. So lets get back to what you are here to learn." If someone persists in being disruptive about it after you have repeatedly asked them to get back to the topic at hand, then take a break, go get his supervisor and ask him to straighten the guy out. You can't afford to let the ones most resistant to the change prevent the others from learning what they need to know.
It seems you have given the training already to a some people. Get a few of the more cooperative ones together for a meeting if possible and ask them to honestly tell you what they found confusing about the training and what other things they wish had been covered. Part of the problem with a lot of these training classes are that they are not designed to meet the users' needs. Depending on what they say, you may need to restructure the training to make it more effective. If so, do that, then present the restructured information to the people you originally trained.
answered Aug 10 '15 at 17:35
HLGEM
133k25226489
suggest improvements |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
10
down vote
Change is a difficult thing for organizations to go through and it is really hard for everyone in the org to change at the same time. The good news is that scenarios like yours have been studied extensively.
You'll want to read about the "technology adoption lifecycle" (and related concepts) and how to apply those ideas in a practical setting. This was originally applied to the diffusion of technology for farms, but it applies very well to organizations which are releasing new tools to their workforce.
To boil it down into a nutshell, there are three phases to such a roll out:
Cultivate "innovators" in your user-group. Find a small number users who are willing to embrace the new system and who are well-regarded by others in the organization. These "alpha-users" are willing to try new things and are eager to provide feedback to you as well as evangelize the new system to "early adopters". You can refine your training materials by first using them with the innovators and early adopters. This group of people will typically have been mentors for others in the organization and thus will know the limitations of the others. These people will tell you if you need to make changes (for example, if the language issue is a serious problem or just a straw-man argument).
After that, you can begin large-scale training for "majority" users. Perhaps even directly enlisting the help of those who became power-users, provide pragmatic training that addresses the concerns you learned about during your interaction with innovators and early adopters. The majority users will have seen that the early adopters can handle the system and will gain confidence that they can make it work too.
Finally, you'll always have what is known in the literature as "laggards". These are folks that are profoundly resistant to change. The common advice for these people ranges from providing individualized attention to using pressure from management. The good news is that if you've been careful with your roll-out, there won't be too many laggards.
Of course, all this takes time and planning. But if your users are counted in the hundreds, it is worthwhile.
If you don't believe in the technology adoption cycle theory, the concept of trying out your training on a small group of people FIRST is valuable.
I should add that "innovator, early-adopter, majority, laggard" are just convenient names for roles that various people take in this process. They're not labels that apply to the workers personally. Its important to make that subtle distinction if you ever communicate this to the organization.
answered Aug 7 '15 at 10:23
Angelo
6,15621631
1
Nice answer. :)
– Jane S♦
Aug 7 '15 at 11:48
suggest improvements |Â
up vote
10
down vote
Change is a difficult thing for organizations to go through and it is really hard for everyone in the org to change at the same time. The good news is that scenarios like yours have been studied extensively.
You'll want to read about the "technology adoption lifecycle" (and related concepts) and how to apply those ideas in a practical setting. This was originally applied to the diffusion of technology for farms, but it applies very well to organizations which are releasing new tools to their workforce.
To boil it down into a nutshell, there are three phases to such a roll out:
Cultivate "innovators" in your user-group. Find a small number users who are willing to embrace the new system and who are well-regarded by others in the organization. These "alpha-users" are willing to try new things and are eager to provide feedback to you as well as evangelize the new system to "early adopters". You can refine your training materials by first using them with the innovators and early adopters. This group of people will typically have been mentors for others in the organization and thus will know the limitations of the others. These people will tell you if you need to make changes (for example, if the language issue is a serious problem or just a straw-man argument).
After that, you can begin large-scale training for "majority" users. Perhaps even directly enlisting the help of those who became power-users, provide pragmatic training that addresses the concerns you learned about during your interaction with innovators and early adopters. The majority users will have seen that the early adopters can handle the system and will gain confidence that they can make it work too.
Finally, you'll always have what is known in the literature as "laggards". These are folks that are profoundly resistant to change. The common advice for these people ranges from providing individualized attention to using pressure from management. The good news is that if you've been careful with your roll-out, there won't be too many laggards.
Of course, all this takes time and planning. But if your users are counted in the hundreds, it is worthwhile.
If you don't believe in the technology adoption cycle theory, the concept of trying out your training on a small group of people FIRST is valuable.
I should add that "innovator, early-adopter, majority, laggard" are just convenient names for roles that various people take in this process. They're not labels that apply to the workers personally. Its important to make that subtle distinction if you ever communicate this to the organization.
answered Aug 7 '15 at 10:23
Angelo
6,15621631
1
Nice answer. :)
– Jane S♦
Aug 7 '15 at 11:48
suggest improvements |Â
up vote
10
down vote
up vote
10
down vote
Change is a difficult thing for organizations to go through and it is really hard for everyone in the org to change at the same time. The good news is that scenarios like yours have been studied extensively.
You'll want to read about the "technology adoption lifecycle" (and related concepts) and how to apply those ideas in a practical setting. This was originally applied to the diffusion of technology for farms, but it applies very well to organizations which are releasing new tools to their workforce.
To boil it down into a nutshell, there are three phases to such a roll out:
Cultivate "innovators" in your user-group. Find a small number users who are willing to embrace the new system and who are well-regarded by others in the organization. These "alpha-users" are willing to try new things and are eager to provide feedback to you as well as evangelize the new system to "early adopters". You can refine your training materials by first using them with the innovators and early adopters. This group of people will typically have been mentors for others in the organization and thus will know the limitations of the others. These people will tell you if you need to make changes (for example, if the language issue is a serious problem or just a straw-man argument).
After that, you can begin large-scale training for "majority" users. Perhaps even directly enlisting the help of those who became power-users, provide pragmatic training that addresses the concerns you learned about during your interaction with innovators and early adopters. The majority users will have seen that the early adopters can handle the system and will gain confidence that they can make it work too.
Finally, you'll always have what is known in the literature as "laggards". These are folks that are profoundly resistant to change. The common advice for these people ranges from providing individualized attention to using pressure from management. The good news is that if you've been careful with your roll-out, there won't be too many laggards.
Of course, all this takes time and planning. But if your users are counted in the hundreds, it is worthwhile.
If you don't believe in the technology adoption cycle theory, the concept of trying out your training on a small group of people FIRST is valuable.
I should add that "innovator, early-adopter, majority, laggard" are just convenient names for roles that various people take in this process. They're not labels that apply to the workers personally. Its important to make that subtle distinction if you ever communicate this to the organization.
answered Aug 7 '15 at 10:23
Angelo
6,15621631
Change is a difficult thing for organizations to go through and it is really hard for everyone in the org to change at the same time. The good news is that scenarios like yours have been studied extensively.
You'll want to read about the "technology adoption lifecycle" (and related concepts) and how to apply those ideas in a practical setting. This was originally applied to the diffusion of technology for farms, but it applies very well to organizations which are releasing new tools to their workforce.
To boil it down into a nutshell, there are three phases to such a roll out:
Cultivate "innovators" in your user-group. Find a small number users who are willing to embrace the new system and who are well-regarded by others in the organization. These "alpha-users" are willing to try new things and are eager to provide feedback to you as well as evangelize the new system to "early adopters". You can refine your training materials by first using them with the innovators and early adopters. This group of people will typically have been mentors for others in the organization and thus will know the limitations of the others. These people will tell you if you need to make changes (for example, if the language issue is a serious problem or just a straw-man argument).
After that, you can begin large-scale training for "majority" users. Perhaps even directly enlisting the help of those who became power-users, provide pragmatic training that addresses the concerns you learned about during your interaction with innovators and early adopters. The majority users will have seen that the early adopters can handle the system and will gain confidence that they can make it work too.
Finally, you'll always have what is known in the literature as "laggards". These are folks that are profoundly resistant to change. The common advice for these people ranges from providing individualized attention to using pressure from management. The good news is that if you've been careful with your roll-out, there won't be too many laggards.
Of course, all this takes time and planning. But if your users are counted in the hundreds, it is worthwhile.
If you don't believe in the technology adoption cycle theory, the concept of trying out your training on a small group of people FIRST is valuable.
I should add that "innovator, early-adopter, majority, laggard" are just convenient names for roles that various people take in this process. They're not labels that apply to the workers personally. Its important to make that subtle distinction if you ever communicate this to the organization.
answered Aug 7 '15 at 10:23
Angelo
6,15621631
edited Aug 7 '15 at 10:48
answered Aug 7 '15 at 10:23
Angelo
6,15621631
answered Aug 7 '15 at 10:23
Angelo
6,15621631
answered Aug 7 '15 at 10:23
Angelo
6,15621631
6,15621631
1
Nice answer. :)
– Jane S♦
Aug 7 '15 at 11:48
suggest improvements |Â
1
Nice answer. :)
– Jane S♦
Aug 7 '15 at 11:48
1
1
Nice answer. :)
– Jane S♦
Aug 7 '15 at 11:48
Nice answer. :)
– Jane S♦
Aug 7 '15 at 11:48
suggest improvements |Â
up vote
1
down vote
I'd say that first you have to solve the translation problem. Expecting people to learn a new language to use software is really unacceptable. I realize your company has foolishly made the decision to go ahead, so you need to provide training materials and materials to be used on the shop floor tho help people translate. For instance could you do screenshots of the screens with the English and then make a version of the screenshot with the German translation that shows just under it on a page? This could then be posted near the place where the software is used, so people can look at it when they get tired or are new to using the software.
Next you are going to have to be blunt with them, there is no possibility of retaining the current system, Let them understand what is driving the change and how that change will be good for the company. If there are things the software will do that the old system would not and those are things the people on the floor are interested in, make sure to highlight those areas in the training. Sadly I suspect the real advantages of this software are only at the management level and that indeed it will make doing their jobs harder. (I say that because I have almost never seen a software change that made things easier for the users of the software.)
Remind them frequently that once they get used to the new interface, it will get significantly easier. Then give them lots of hands on exercises. Give them real world problems and encourage them to talk about the edge cases they run across when performing their work and show them what do do with the system when those less frequent things happen. Again a cheat sheet here is helpful.
As far as the training, you need to stop the complaints when they start. Say something along the lines of "I'm sorry you feel that way, but the decision is not going to change and you have to learn how to use this software. So lets get back to what you are here to learn." If someone persists in being disruptive about it after you have repeatedly asked them to get back to the topic at hand, then take a break, go get his supervisor and ask him to straighten the guy out. You can't afford to let the ones most resistant to the change prevent the others from learning what they need to know.
It seems you have given the training already to a some people. Get a few of the more cooperative ones together for a meeting if possible and ask them to honestly tell you what they found confusing about the training and what other things they wish had been covered. Part of the problem with a lot of these training classes are that they are not designed to meet the users' needs. Depending on what they say, you may need to restructure the training to make it more effective. If so, do that, then present the restructured information to the people you originally trained.
answered Aug 10 '15 at 17:35
HLGEM
133k25226489
suggest improvements |Â
up vote
1
down vote
I'd say that first you have to solve the translation problem. Expecting people to learn a new language to use software is really unacceptable. I realize your company has foolishly made the decision to go ahead, so you need to provide training materials and materials to be used on the shop floor tho help people translate. For instance could you do screenshots of the screens with the English and then make a version of the screenshot with the German translation that shows just under it on a page? This could then be posted near the place where the software is used, so people can look at it when they get tired or are new to using the software.
Next you are going to have to be blunt with them, there is no possibility of retaining the current system, Let them understand what is driving the change and how that change will be good for the company. If there are things the software will do that the old system would not and those are things the people on the floor are interested in, make sure to highlight those areas in the training. Sadly I suspect the real advantages of this software are only at the management level and that indeed it will make doing their jobs harder. (I say that because I have almost never seen a software change that made things easier for the users of the software.)
Remind them frequently that once they get used to the new interface, it will get significantly easier. Then give them lots of hands on exercises. Give them real world problems and encourage them to talk about the edge cases they run across when performing their work and show them what do do with the system when those less frequent things happen. Again a cheat sheet here is helpful.
As far as the training, you need to stop the complaints when they start. Say something along the lines of "I'm sorry you feel that way, but the decision is not going to change and you have to learn how to use this software. So lets get back to what you are here to learn." If someone persists in being disruptive about it after you have repeatedly asked them to get back to the topic at hand, then take a break, go get his supervisor and ask him to straighten the guy out. You can't afford to let the ones most resistant to the change prevent the others from learning what they need to know.
It seems you have given the training already to a some people. Get a few of the more cooperative ones together for a meeting if possible and ask them to honestly tell you what they found confusing about the training and what other things they wish had been covered. Part of the problem with a lot of these training classes are that they are not designed to meet the users' needs. Depending on what they say, you may need to restructure the training to make it more effective. If so, do that, then present the restructured information to the people you originally trained.
answered Aug 10 '15 at 17:35
HLGEM
133k25226489
suggest improvements |Â
up vote
1
down vote
up vote
1
down vote
I'd say that first you have to solve the translation problem. Expecting people to learn a new language to use software is really unacceptable. I realize your company has foolishly made the decision to go ahead, so you need to provide training materials and materials to be used on the shop floor tho help people translate. For instance could you do screenshots of the screens with the English and then make a version of the screenshot with the German translation that shows just under it on a page? This could then be posted near the place where the software is used, so people can look at it when they get tired or are new to using the software.
Next you are going to have to be blunt with them, there is no possibility of retaining the current system, Let them understand what is driving the change and how that change will be good for the company. If there are things the software will do that the old system would not and those are things the people on the floor are interested in, make sure to highlight those areas in the training. Sadly I suspect the real advantages of this software are only at the management level and that indeed it will make doing their jobs harder. (I say that because I have almost never seen a software change that made things easier for the users of the software.)
Remind them frequently that once they get used to the new interface, it will get significantly easier. Then give them lots of hands on exercises. Give them real world problems and encourage them to talk about the edge cases they run across when performing their work and show them what do do with the system when those less frequent things happen. Again a cheat sheet here is helpful.
As far as the training, you need to stop the complaints when they start. Say something along the lines of "I'm sorry you feel that way, but the decision is not going to change and you have to learn how to use this software. So lets get back to what you are here to learn." If someone persists in being disruptive about it after you have repeatedly asked them to get back to the topic at hand, then take a break, go get his supervisor and ask him to straighten the guy out. You can't afford to let the ones most resistant to the change prevent the others from learning what they need to know.
It seems you have given the training already to a some people. Get a few of the more cooperative ones together for a meeting if possible and ask them to honestly tell you what they found confusing about the training and what other things they wish had been covered. Part of the problem with a lot of these training classes are that they are not designed to meet the users' needs. Depending on what they say, you may need to restructure the training to make it more effective. If so, do that, then present the restructured information to the people you originally trained.
answered Aug 10 '15 at 17:35
HLGEM
133k25226489
I'd say that first you have to solve the translation problem. Expecting people to learn a new language to use software is really unacceptable. I realize your company has foolishly made the decision to go ahead, so you need to provide training materials and materials to be used on the shop floor tho help people translate. For instance could you do screenshots of the screens with the English and then make a version of the screenshot with the German translation that shows just under it on a page? This could then be posted near the place where the software is used, so people can look at it when they get tired or are new to using the software.
Next you are going to have to be blunt with them, there is no possibility of retaining the current system, Let them understand what is driving the change and how that change will be good for the company. If there are things the software will do that the old system would not and those are things the people on the floor are interested in, make sure to highlight those areas in the training. Sadly I suspect the real advantages of this software are only at the management level and that indeed it will make doing their jobs harder. (I say that because I have almost never seen a software change that made things easier for the users of the software.)
Remind them frequently that once they get used to the new interface, it will get significantly easier. Then give them lots of hands on exercises. Give them real world problems and encourage them to talk about the edge cases they run across when performing their work and show them what do do with the system when those less frequent things happen. Again a cheat sheet here is helpful.
As far as the training, you need to stop the complaints when they start. Say something along the lines of "I'm sorry you feel that way, but the decision is not going to change and you have to learn how to use this software. So lets get back to what you are here to learn." If someone persists in being disruptive about it after you have repeatedly asked them to get back to the topic at hand, then take a break, go get his supervisor and ask him to straighten the guy out. You can't afford to let the ones most resistant to the change prevent the others from learning what they need to know.
It seems you have given the training already to a some people. Get a few of the more cooperative ones together for a meeting if possible and ask them to honestly tell you what they found confusing about the training and what other things they wish had been covered. Part of the problem with a lot of these training classes are that they are not designed to meet the users' needs. Depending on what they say, you may need to restructure the training to make it more effective. If so, do that, then present the restructured information to the people you originally trained.
answered Aug 10 '15 at 17:35
HLGEM
133k25226489
answered Aug 10 '15 at 17:35
HLGEM
133k25226489
answered Aug 10 '15 at 17:35
HLGEM
133k25226489
answered Aug 10 '15 at 17:35
HLGEM
133k25226489
133k25226489
suggest improvements |Â
suggest improvements |Â
4
You haven't "sold" it here -- is this software actually better for them? It does seem counterproductive to train workers to learn a new language to use the software rather than translate the software - software is supposed to be the more flexible one. I'd be unhappy too if my employer told me I needed to learn a foreign language to use software that's essential to my job and I had to use it to confirm every step I did. It sounds like you're trying to find a "nice" way to tell operators that the software has already been chosen and they have no choice but to adapt to it or lose their job.
– Johnny
Aug 7 '15 at 9:53
2
Obviously the decision is already done and they can not do anything against it. They will not be happy, regardless what you tell them. But you can make it as easy as possible for them. I would recommend designing a cheat sheet where the most important commands and vocabularys can be found. They should pin that near their terminals.
– jwsc
Aug 7 '15 at 10:12
1
@Johnny, these problems can occur even if there was no language barrier in the system. There are many good reasons for switching over software and sadly it is never going to seem like a "good deal" for the operators unless it actually makes their worker easier or better in some tangible way they can observe.
– Angelo
Aug 7 '15 at 10:31
1
True, but adding a language barrier on top of the new software seems like the company doesn't really value the operators who have to use the software daily, which makes it even harder to "sell" the software and makes it seem like the company is putting their interests above the employees and makes adoption if the software much harder than it needs to be. It seems that "language" should be at the top of the list of requirements for new software.
– Johnny
Aug 7 '15 at 10:49
2
I don't know about Germany, but there could be further legal aspects to the language problem. Where I am from (France), it is mandatory to translate everything. Some of our internal softwares aren't fully translated, but the users didn't complain about it. If they did however, my company would legally be forced to translate all of them.
– Aserre
Aug 7 '15 at 12:02