It’s a general fact that insurance is far behind the times as far as technology goes. Many companies are working on updating their systems (though some aren’t) and with that comes a lot of headaches. A rather overlooked headache is that, while transitioning, there are often multiple ways of doing one operation. Employees will often take whichever route they’re most comfortable with, but that doesn’t always mean it’s the most efficient. Usually, it means the opposite.
As a team, it’s good to assess what procedures are used due to comfort or efficiency. If it turns out be both, that’s a sign that:
- The new system is not as intuitive as it should be
- There’s a general resistance to change
- The system is so intuitive that the change didn’t even matter – it was an easy switch.
Of the two companies I’ve worked at, both had been going through a major systems change during my tenure. I came in at varying stages (the first was after the system was released, so it was mostly finished up with few bugs) and the most recent where the change hasn’t happened yet, but we’re preparing for it. In the middle was a company with a serviceable Windows 95 – era program with very few promises of coming change.
The ones with impending change aren’t actually as pertinent to this article as you may think – while the change was/is happening, it will be important to get people using the system and work out the bugs. However, that stage likely isn’t going to last long, so if people continue to stick with their previous methods there’s still going to be a cutoff point at which the company says “you can’t do that anymore, period.” It’s still good to figure out why people might be reluctant to change as it could help improve the future system, but change is coming and efficiency along with it (hopefully!).
The middle ground is where it’s a problem. It creates a sort of limbo because even if the company’s programs aren’t modernized, you know that things like Adobe Acrobat, Outlook, and other tools will be. The company’s program may not be dependent on which version is used (it might even prefer the older ones) and this is a perfect swamp of stagnation.
Take a pdf editor as an example. An employee has to frequently piece documents together out of many. The old program requires you to go file>insert, then a window pops up where you hit “open” to get the document you want, then you choose whether it’s going in the front, middle, or end of the document.
The new version of the pdf editor allows you to drag and drop pages in, so all you have to do is have both documents open, highlight the pages you want inserted, and then drag them over to the new document.
The former method is familiar, but is it efficient? Heck no! It’s a lot of extra steps, more choices to make (so more brain power) and it’s far less intuitive.
However, it’s easy to imagine the walls you’ll run up against trying to get employees of 10+ years to use the new method, even install the new program, if there’s no real push to do so. The old program works, so why fix it?
This is where managers need to be very aware of the difference between efficiency and preference. It’s nice to have your employees be comfortable with what they’re doing, and yes they’re likely faster with the old method initially, but over time those lack of clicks and windows will add up.
So ask yourself this: are the methods your team uses out of convenience and comfort? Or are they truly the most efficient ways you could be processing your work? Think about why it might be, like lack of pressure from a higher power, or an unwillingness to “deal” with the difficulties that will come from implementing these practices. Depending on your answers, it might be worth getting some employees together that you know are efficient, see how they work, and implement those practices across the board. There doesn’t need to be an impending systems change to encourage growth and efficiency – you’re capable of bringing that change and improved productivity yourself.