Four reasons maintenance software can suck

There is a scene in the movie Office Space where the three main characters take out their rage on a printer with a baseball bat. The machine is nothing but rubble by the end.

It’s an incredibly therapeutic two minutes. Probably because we’ve all been there. We’ve all dreamed of smashing our computer or phone because a piece of software has driven us crazy.

That includes maintenance and manufacturing software.

When Bryan Sapot, CEO of manufacturing software SensrTrx, asked his LinkedIn followers why the industry’s software can suck so much, it hit a nerve. It also got us wondering about the root cause of this frustration. Why does maintenance and manufacturing software suck sometimes?

We sat down with Bryan, Scott Deckers (Fiix’s Director of Customer Success), and Rob Kalwarowsky (host of the Rob’s Reliability Project podcast) to talk about it. You can watch the full video below or download it as a podcast. You can also scroll down to read the top reasons these experts think maintenance and manufacturing software can suck and how to avoid the pitfalls when searching for software.

#1. The reason for using software sucks

What it means

Software is almost certainly doomed to fail if you’re not crystal clear on the reason you want it. When you don’t know what you want to achieve or what problems you want to solve with software, it usually ends with a system that doesn’t work for your team or your organization.

What the experts are saying

“If you’re going to search for any tool, you need to know what you’re going to do with it. Too often, we see people saying, ‘Somebody told us we need to buy a CMMS, so we’re buying a CMMS’…That’s not the type of buy-in or leadership you want to see.”

– Scott Deckers

What you can do about it

Like any repair job, you need to know what’s wrong before you can fix it. That’s why the first step is to determine what problems software will solve. There are three steps for doing this:

1. Gather a team of people who will use the software and ask them what’s wrong. People won’t use the software if it doesn’t solve their problems. This post has a few tips on who to include in this consultation stage.
2. Dig deeper into the problems. Here’s where you can apply root cause analysis to your project. Keep asking why until you find the real reason for a problem.
3. Align your goals. Figure out which problems are the biggest and which ones will have the largest impact on both your organization and people.

#2. The data sucks

What it means

If there’s a problem with your data, you’re going to have a problem with your software. There are three potential problems you can have with data: It’s inaccurate, it’s the wrong kind, and there’s too much of it. Because software often relies on data, having these issues can make it look like the system itself is to blame.

What the experts are saying

“Less is more…If you have to sift through all these different metrics and all this different data to try to find something meaningful, then you don’t have any meaningful data.”

– Bryan Sapot

“If you’re not actioning work, not actioning improvement projects, not using the data to run the equipment better, then why bother? How is it going to improve your processes? What are you going to do with this information?”

– Rob Kalwarowsky

What you can do about it

Bad data is really good at blending in with good data. That’s why the secret to exposing bad data is a laser focus on one part of your operation. Look at one piece of equipment or one task and ask yourself these questions:

1. Am I collecting the right data? Does it tell me something I can act on?
2. Am I collecting too much data? Can I find what I’m looking for in a few seconds?
3. Is my data accurate? Do my records match what’s happening in real life? Am I recording data incorrectly because there’s no easy way to log it?

#3. The buy-in sucks

What it means

Your software project is going to fail if you can’t get buy-in from the people using the software. Period. When people don’t want to use the system (or don’t know how to), it ends in one of two situations: The software is used incorrectly or not used at all.

What the experts are saying

“The shop floor leadership is arguably more important to making sure software sticks, making sure it’s driving value, and making sure everyone knows the value it’s driving.”

– Scott Deckers

“You can put the most beautiful application out there on the floor that’s so easy to use and requires a minimal amount of input, but if you don’t have the leadership…and the structure in place, and people understanding why it’s there, it doesn’t matter.”

– Bryan Sapot

What you can do about it

Leading change and driving software adoption is a huge topic. In fact, we hosted a whole webinar about it. If you’re short on time, we distilled a few tips from the discussion:

• Tell people what’s in it for them. Finding out what users care about, what pains they have, and what goals they want to achieve. Then tell them how software is going to help them with these things. Back it up with numbers. Tell people that they’ll save an hour a day instead of saying that they’ll be more efficient.
• Select a software champion. This is someone who will lead and advocate for the project. The perfect champion is also a user of the software so they understand both the benefits and challenges. You can read all about the ins and outs of picking a champion here.
• Have a detailed plan. Having a software implementation plan takes a lot of uncertainty and fear out of change by making roles, timelines, and expectations clear, which makes it easier for your team to commit to change.

  Check out this full pre and post CMMS implementation checklist to create your own plan.

• Do lots of training. People forget about 75% of what they learn after just six days. Don’t rely on just one training session to turn your team into pros at using software. Make time for regular training and account for growing pains as users learn a system on the job.
• Promote your successes. While success doesn’t erase every frustration people have with software, it makes those problems seem a lot smaller. Keep track of every win you accomplish with software, no matter how small, and tell everyone you can about it. We created a video all about how to do this here.

#4. The processes around software suck

What it means

Poor processes lead to software letdowns. For example, CMMS software can be an easy way to create and execute PMs. But if you have no process to follow up on a failed PM, your whole preventive maintenance program will crumble.

What the experts are saying

“Technology is only as good as the systems in place beneath it. A hammer doesn’t swing itself.”

– Scott Deckers

“You need to worry if you’re doing the right processes the right way before you worry about measuring them with software.”

– Rob Kalwarowksy

What you can do about it

Building solid processes has a lot to do with a couple of points we’ve already covered: Defining the what and why, and starting small to find gaps.

First, identify the processes you want to facilitate, track, and improve with maintenance and manufacturing software. The word ‘improve’ is very important here—if you only monitor processes and don’t improve them, the software will most likely disappoint.

Then go to work auditing these processes. Break processes into smaller chunks to see where they might be broken. For example, in the webinar, Rob mentions that it’s important to make sure you’re doing the right PMs, in the right way, and with the right frequency.

The ultimate takeaway: Maintenance and manufacturing software is not a silver bullet

It’s not the software’s fault. That’s the big lesson we’ve learned after looking at all the reasons maintenance and manufacturing software can suck. Software is often touted as a silver bullet solution. This is a recipe for disaster. It takes a clear objective, full buy-in, solid processes, and great data for software to help your team. Building up this support system will help you use software as a tool for improvement and take your business to new heights.