November 26, 2019 | 13 min read Making the transition to CMMS software with Steve Ricard (PODCAST) By: Marc Cousineau Back to blog How to implement a CMMS, with Fiix and the Rooted in Reliability podcast Everything about change is hard, from knowing when to make a switch to making sure everyone is comfortable with a new way of working. Adopting a CMMS, and shifting how you do maintenance, is no different. This transition can be challenging, even if it’s ultimately worth it. Fiix’s Implementation Team Manager Steve Ricard visited the Rooted in Reliability podcast to talk about the challenges, benefits, and best practices for implementing CMMS software. Steve, and host James Kovacevic, discuss: The right time to look for a CMMS How to plan for a good implementation Tips for dealing with data How to manage change so your team is engaged, informed, and successful Listen to the podcast episode here (also available on Accendio Reliability’s website) or read the transcript below. Nail your CMMS set-up with this free CMMS implementation checklist Episode transcript View the episode transcript James Kovacevic: It is my pleasure to welcome Steve Ricard. Welcome, Steve. Steve Ricard: Hey James, how’s it going? JK: I’m doing well, thank you. Now Steve, for those who aren’t familiar with you, you are an implementation team manager with Fiix Software. We’ve had many people on from Fiix before, so it’s a CMMS that many people use, that many people are familiar with. You are also a CRL and you also have your CFM. Now, a very brief introduction, what can you do to fill in the blanks for us? SR: Sure. I started my maintenance career back in 1986. I performed my first implementation of a CMMS while I was working at a property management company. Back then, it was data streams and a brand-new, just-introduced MP2 product, which, to kind of give you an indication of how old I am, that is obsolete, so sometimes I feel like I may be getting towards the obsolete stage myself. I maintained my career and really fell in love with computers at that point and maintained the maintenance career into a networking administration certification. Then, as you’ve mentioned, I achieved my certification in facilities management from Northeastern University. I decided that I liked computers so much that I wanted to do more than just implement for the property management company I was working for. So I shifted over to work for another CMMS provider back in 2000 and I’ve pretty much worked in that arena ever since. JK: So it’s fairly easy to say that you’ve been involved with CMMSs for quite a period of time if MP2 was new when you were getting into it. I still know some organizations that run it. That being said, you’ve been involved with CMMS for a long period of time across a wide range of industries. Now, what is a CMMS in your words? SR: So, I’ll start it with the acronym. I’m sure just about all of your listeners are aware that it stands for computerized maintenance management system. Some people will replace that ‘system’ with software. Basically what it is is a two-part system. The first part is a database where all the information from a company’s maintenance organization gets stored. If you’ve ever worked with multiple Excel worksheets, workbooks, or a database you know that it’s not always user-friendly to retrieve the data that you want to see. So, the CMMS has a second part and that’s what the end-user sees and we call that the front end. The front end’s role is to organize the data in a way that allows users to view all that information that otherwise might be jumbled up. In addition, the front end will contain some computer code where some complex computations on the data will be made and it does that to help maintenance teams better schedule their maintenance work and keep track of parts and materials. A CMMS should also have a good strong reporting tool so you can get that data in a report that’s going to make sense to everyone within the organization. JK: Excellent. So, a very good definition of what a CMMS is. And they’ve been around for quite a while as you’ve mentioned previously. But how do organizations know if their current CMMS is becoming out of date, obsolete, or when it’s time to start looking for something new? SR: Believe it or not, the first CMMS came out in about 1965 and it was a punch card system. So the principles of how a CMMS should work have been around for over 50 years. When I’m evaluating, some of the things I would look for are, is the user interface modern looking? With the advancement in programming development tools, software companies have really been able to simplify the user experience while still being able to keep the complex computations that I mentioned earlier. If a system isn’t user-friendly, then companies might be losing some productivity, and user adoption might be difficult. That’s one area that you may want to look at replacing. Does the system we’re currently using have a robust mobile solution? Do we want to try to move away from the pen and paper and go paperless? Well, then you’re going to want to have a robust mobile solution to do that. How about some advanced features? In the older CMMSs, pretty much all of the scheduled maintenance was going to be based on a time period. Does your system allow for meter-based and/or condition-based monitoring? Then, the last thing I would look at is, what are the hardware requirements of the system? Is the customer running on outdated servers and old operating systems because the software itself won’t run on anything newer? I guess one more thing. If there’s anyone out there still using a punch card CMMS, well then, they should certainly consider upgrading. JK: Yes absolutely. And, you know, those old servers that you mentioned, that’s an issue for a variety of different reasons. It’s not just the fact that, you know, they’re old, it’s that there are security patches that are no longer being applied to them that present a cybersecurity risk. They are unreliable and we can’t support anymore from an IT perspective. There are many different things to consider. SR: Absolutely. And you also have to consider that the older servers may not have had the storage capacity. The newer CMMSs really promote attaching electronic files, whether they be pictures or videos, or perhaps Autocad drawings, which all take up quite a bit of space. The older servers just don’t have that capacity. They also may not have had the RAM or processor capacity to function in a fast-paced environment. So, ya, in addition to the security issues, there’s just a whole bunch of things to look at when you’re looking at your hardware. JK: The other big thing to keep in mind is with all the information that’s out there and all the other systems out there, we want a CMMS that can integrate with other systems, whether that’s a GIS or condition-monitoring, or whatever type of solution we have. We want these to be able to talk to each other so you’re not having to manage 18 different systems in 18 different windows in your computer all the time. SR: You know, that’s a great point and one of the things that I should have brought up earlier when I told you some things to look at is, can your system integrate and does your system have a closed app, meaning it isn’t allowed to connect to the outside, or, are you deploying some of the new technologies, like APIs? For instance, at Fiix, we use an open API platform. We can connect to just about anything that also allows API connections. We can now keep the accounting people and the purchasing people within their purchasing software, the maintenance folks within the maintenance software, and use this API, or this bridge if you will, to communicate between the two. You can take the information from programmable logic controllers and automatically feeding that into your CMMS. This is another example of some packages that may be outdated because they don’t allow for those hooks JK: Yes, absolutely. Now, we’ve covered quite a few reasons why organizations—how organizations would know their system is out of date. But when should they actually take that plunge and move from that outdated system to a new system? What drives them to do that? SR: Well, that’s an interesting one. When I first started in the industry, there was no such thing as cloud-based software. So, we talked about the hardware that they have to consider, so should they consider moving over to software as a service, or SaaS? Also, they need to take a hard look, maybe take a forensic approach, to their existing system. What worked with their original system, and what didn’t, and how can they improve? I really want to tell people to subscribe to the Five P philosophy, which is, proper planning prevents poor performance. When you want to look at a system or consider replacing one, you really need to do a good job at truly evaluating and plan appropriately so you can be stood up when you do move over. JK: Alright, excellent. Now with that, what do organizations need to consider when preparing to transition from that outdated CMMS to a new one? What are the things they really need to consider? Is it that cloud vs. hosted? What else do they need to consider? SR: In the old days, we also had to look at our printer technologies. You know, if you’re running an old system, you may be restricted by the printers you are using. Typically, that’s not an issue today. If you go to a web-based solution, the customer doesn’t really have work station or server concerns. If they have a way of getting out to the internet, they can pretty much access the software from anywhere. With the advancements in smartphones and tablets, how are they going to arm their technicians? Are they going to arm them with mobile solutions? Or a work station? Or are they going to go at it the old-fashioned way and process paper? Now, we’d obviously recommend that you move away from paper and pen. It’s hard to store, it’s hard to translate, and you really see some efficiencies by moving to a fully electronic system. JK: Alright, excellent. Now with that, what about the training portion? Is that a consideration when we’re looking at from an older system to a newer system? What are people used to, are they going to adopt a newer system? That sort of thing? SR: Absolutely. In so many instances, I’ve gone out and the decision to replace a software solution or to install a software solution if they’re not replacing something old, has come from the top without end-user involvement. The end-users are really the ones that make or break a system. There can be a directive from above, but if the end-users don’t understand one, what the goals are of the organization, and two how to use the software, then their user adoption is going to be very low. If their user adoption is low, it’s going to make it very difficult for the system to catch on. You’re probably going to have people entering data in inconsistent methods and what that leads to is harder data to retrieve. Harder data to retrieve means harder reports to run, which pretty much means a failed system. What we really want to do is get the end-user buy-in from the beginning and the best way to accomplish that is to make sure they are trained and are as comfortable as possible utilizing the software. JK: Alright, excellent. So we need to consider all of those people things in addition to the technology considerations, the software considerations, all those things. Now, one of the questions I get often is, how do organizations decide whether or not to import that old history from the old CMMS, the outdated CMMS, to the new one? How do we decide that and is it worth the effort? SR: It can be. It’s a great question because so often we get customers that do have data in their legacy system and their immediate reaction is, hey, let’s bring everything into the new system. Well, we need to ask, first of all, why? Why are you making a switch to the new system? Is it that the old system is antiquated? Or are there new features or functions that you want to deploy? Or are you unhappy with the configuration on top of the other factors that I just brought up? Is all the data in your old system good? Is it clean? Where do you want to make improvements and adjustments? We need to take that into consideration on what we’re going to bring in. A big one is, we need to find out if they own the data when they move off their old system. Will they lose access to it? Was the data on a propriety database platform? Well, if they’re going to lose access to it, we certainly would want to bring that data in. However, if they can access the data, generally what I recommend is that they bring in their asset records, their parts, any of their PM schedules, as well as any open work orders. Then, generally, we recommend that they keep their historic records in their historic system. Again, if there’s a case where a customer won’t have access to their old system once they migrate over, then we really want to take a review of the historical data that needs to be brought in. JK: Alright. I’ve seen some organizations that, you know, aren’t going to have access to that old system, so they export it to Excel, all the records, and they keep it in Excel if they ever have to look back at it. I’ve seen some move it all into some sort of accessible database, and I’ve seen others that actually move it over to the CMMS. They all have their pros and cons, but the summary of it is, we want to make sure we have access to the data. Correct? SR: Absolutely. As long as you have access to it. And don’t forget, a lot of that old data, you probably have folks entering it that are no longer with the company, so do we want to bring in that type of information into the new system? So, as you said in summary, we just need to make sure that you can always have access to it. JK: Alright, excellent. So, we’ve made the decision on what to do with our data and we’ve made the decision on what platform we’re going to go with. What do we need to do around the people to make sure it’s adopted? Is it initial training and that’s it? Is it a full awareness campaign and some training? Is it some hands-on stuff. What do we need to do to make sure our staff are prepared for the transition? Because it’s going to be a big transition going from an old, outdated system to a new, user-friendly system. SR: Of course. Change is difficult. People struggle with change. We like to be comfortable. So, whenever you introduce change, it can be difficult for people. The most important thing, first and foremost, is we have to communicate. We need to inform the end-user that changes are being made and ideally we want to get the staff involved in the selection process. I’ve worked with a bunch of companies and have said, you know what, bring in the person who is going to be your biggest naysayer, bring them in really early, and let’s address that person’s concerns. If we can make them happy then everyone else in the organization knows they are the naysayer, so if they are brought on board, it’s going to make that adoption easier. Then we do want to do end-user training to make sure everybody is trained up, but we don’t want to walk away at that point. We want to stay involved. We want to have regularly scheduled calls and webinars with the customers to make sure everybody is comfortable. As soon as somebody gets uncomfortable, even slighty, we want to manage that situation right away. We want to get involved with them before it grows too big and they move from uncomfortable to disgruntled. JK: Alright, excellent. And you know, sometimes those biggest naysayers are the informal leaders within the organization, so you want to make sure you grab them because if they make that change with you, others will follow, typically. SR: Absolutely. Like I said, if you can get the naysayers onboard, most other people will jump in. JK: Now, let’s say we get those naysayers onboard. What other preparations do organizations need to make to be ready for this transition? SR: One thing I can’t recommend enough is creating a standard operating procedure manual. An SOP. It always amazes me when I show up and people are pulling out SOPs for absolutely every bit of maintenance that they perform, but they don’t have one for their maintenance activity software, their CMMS. Develop an SOP. It should clearly define how the system should be used and it should also be a living, breathing document. You can’t create it once and then walk away. You need to perform constant reviews of the system and if you make changes, make sure you update that SOP. The folks that do that are the ones I always see be most successful. JK: I think having those SOPs ensures everyone is entering the data in the right way, the right format, using the right reports. It’s all those things that really drive consistency in the data quality within that CMMS. One of the things that I often see too is organizations will develop the SOP, train people on it when the CMMS is being prepared to roll out, and there’s usually a delay, so there are people who haven’t seen or touched the system for a period of time, and it’s rolled out without any further follow-up training or ongoing training. So, it starts to degrade and go backward because no one is using that SOP, no one is using those standards that were developed for the CMMS. SR: Right, and when you talk to them, they’ve got their original SOP to perform their maintenance task and then in the back of that SOP, they’ve got some technical service bulletins attached. So, the manufacturer says, hey, we’ve got to make some changes to some maintenance tasks, here’s an update, and they are very quick to add those updates to their maintenance task SOP. Well, we need to do the same thing to your CMMS SOP. JK: Absolutely. In addition to SOPs, if you had a magic wand, what is the one thing you’d do differently with organizations looking to update their CMMS? SR: I guess I’d actually want to wave that wand over the people instead of over the technology or process. As I mentioned earlier, change can be difficult and change can be challenging. I’d really want to ease the folks’ concerns and help them understand that sometimes, change can be a good thing. We often run into people that are so uncomfortable that their discomfort level really slows the project down. As a good consultant, we really need to be there to hold their hand and make them as comfortable as possible, which will make the process go so much easier. JK: Alright, excellent. Now, what is the one thing you want our listeners to take away from this conversation on updating CMMSs, transitioning to updated ones? What’s one thing you want them to take away and do differently tomorrow or next week? SR: If I can, I’d like to give you two takeaways. JK: Alright, I’ll take two. SR: Alright. Number one, look. Take a hard look at your system. Is it doing everything you need it to do? Look at it as if it was your first day on the job. Is it easy to use, is it user-friendly? Are you getting out of it what you need to get out of it? Number two, listen. This goes back to the communication I talked about earlier. Really listen to your end-users. Don’t just hear them, but listen. They are the ones that are going to make or break it. Do they have legitimate complaints? What can you do to make their jobs easier? If you can make their jobs easier, you’re going to go a long way to improving their morale, which can, of course, improve overall productivity and performance. JK: Alright, excellent. Two great takeaways there. I want to thank you, Steve, for taking the time to talk to us today about making that transition away from outdated CMMSs. SR: No problem at all James, it was my pleasure. (opens in new tab) (opens in new tab)