If you missed the lead in to this article, it featured technicians deliberately breaking $50, 000 machines. Check it out.
Several factors weigh in to what causes poor user adoption. Don Brules does a good job outlining them here. To paraphrase:
- No benefit to end users demonstrated
- Lack of effective training
- System isn’t designed for how users actually work
- Lack of a business case for deployment
So how do we avoid this? It boils down to two things:
1) Choosing appropriate software
This depends on your staff almost as much as your facility. Carefully consider what kind of computer skills your maintenance crew possesses when you’re selecting software. Can they handle something that’s feature rich and requires lots of training? Is an old school, spread-sheet layout tolerable or do you need something more modern? The point of a CMMS is to save time, right? It’s supposed to be faster than a paper-and-pencil system, right? If your maintenance crew, the people who will be using it the most, can’t use it faster than they can write down and file something then the software isn’t effective.
Traditionally, software is selected based on a required feature set, and then money is dumped into training and onboarding to make the software actually usable. CMMS vendors have a nasty habit of bloating their products with features in order to hit checkmarks on a CIO’s feature list – doing so at the expense of usability. End users, who are penalized by this, aren’t the ones making purchasing decisions, so the vendor gets away with it.
It’s important that a CMMS can perform the critical functions you need, but not as a tradeoff for a quality user experience. Without it, your software purchase won’t be used properly anyways.
2) Training & Achieving buy-in from stakeholders
I’ll say one thing about training. Get users to do it themselves. No one learns anything substantial from watching someone else do it, and this is doubly true of learning software.
Getting users committed to the project is harder. Employees’ goals and motivations can vary greatly from the company’s goals and motivations. The key to achieving buy-in is to align what’s good for the employee with what’s good for the company.
You need to demonstrate that the software will:
- Improve workflow and save the company time, money, etc
- Be of some personal benefit to the user. Such as: learning a new skill, saving them time, make some process easier…
- Be a good overall choice for the company with demonstrable benefits. If you have a track record of running poor or ineffective initiatives, user adoption of your projects will plummet.
- Provide a measurable benefit, preferably in the short run (<3 months) to demonstrate the value of the project.
Specifically for a CMMS implementation, it might resemble this:
- This will give us a better PM schedule, so things won’t break down as often
- Although it might take slightly longer than writing down work orders, we’ll save time in the long run by having them more accessible and searchable
- Parts will be better managed, so we won’t have to wait or rush-order a part
- CMMS knowledge is a marketable skill, learning it will make you harder to replace
- If the maintenance department saves money on parts/repairs, it’s less like they will need to commence layoff’s
The key to user adoption is: What’s in it for THEM?