Mr. Thomas Didier with InforEAM talks about Common Misconceptions of Software Implementations

In this week's Industrial Talk Podcast we're talking to Thomas Didier, Solutions Architect at Infor and Infor EAM about “The Common Misconception of Installing Software Packages. Get the answers to your EAM implementation questions along with Tom's unique insight on the “How” on this Industrial Talk interview!

You can find out more about Tom and the wonderful team at Infor by the links below. Finally, get your exclusive free access to the Industrial Academy and a series on “Why You Need To Podcast” for Greater Success in 2020. All links designed for keeping you current in this rapidly changing Industrial Market. Learn! Grow! Enjoy!


Personal LinkedIn:

Infor LinkedIn:

Infor Facebook:

Infor Twitter

Infor Website:



Click on the InforEAM Toolkit picture above and receive the following “Must Have” EAM reports:

  1. 7 Steps for implementing reliability-based maintenance
  2. 10 steps toward a paperless operation with mobile EAM checklist
  3. Asset intensive industries, finding the straightest path to the cloud
  4. EAM vs CMMS, don't get fooled
  5. Infor EAM Brochure
  6. Infor EAM Overview
  7. 9 fleet management challenges and how to resolve



CAP Logistics:

Hitachi Vantara:

Industrial Marketing Solutions:

Industrial Academy:

Industrial Dojo:

Safety With Purpose Podcast:


LifterLMS: Get One Month Free for $1 –

Active Campaign: Active Campaign Link

Social Jukebox:

Industrial Academy (One Month Free Access and One Free Licence for Future Industrial Leader):

More InforEAM Related Podcasts Below:

Business Beatitude the Book

Do you desire a more joy-filled, deeply-enduring sense of accomplishment and success? Live your business the way you want to live with the BUSINESS BEATITUDES…The Bridge connecting sacrifice to success. YOU NEED THE BUSINESS BEATITUDES!


Reserve My Copy and My 25% Discount




Infor, InforEAM, deploy, implementation, PM, maintenance, data, Reliability, Asset Management, industry, Didier, listeners, information, podcast, code, case, industrial, work


Welcome to the industrial talk podcast with Scott MacKenzie. Scott is a passionate industry professional dedicated to transferring cutting edge industry focused innovations and trends while highlighting the men and women who keep the world moving. So put on your hard hat, grab your work boots, and let's get right Welcome to the industrial talk podcast. Let's get going and celebrating industry heroes. You know, the women and men of manufacturing the women and men of industry and all things in between your art bold, you are brave, you dare greatly and you are changing the world through your innovation, and you're changing lives. That's why this podcast platform is here. That's why we celebrate you. Yep. It doesn't get any better than that. All right, in the hot seat for this particular, you know, podcast, we got a gentleman by the name of a Thomas Didier. That's Didier, but it's spelled D, I, D, I, E, R. All right. He is InforEAM. And he is got some mad skills. So let's get going.


another great. So here's, here's the funny thing. So here I am, I was with PriceWaterhouseCoopers. We primarily in the utility space, that is my background, I was a journeyman lineman climbing towers, all that good stuff. So it was a natural fit. So I was with Price Waterhouse. And we were deploying systems, and, you know, enterprise systems, just like everything else was sometime back. And one of the topics that I always like, is talking about how to deploy systems today. And what's interesting, it's getting easier, but the same challenges always exist, it always gets down to people and culture. But the systems, the technology is far more flexible,


robust, powerful, you can pull out data analytics in a better way, you can link all of these legacy systems together, and it's not gonna, you know, I mean, you still have to map the stuff out, but it's not going to create heartache like it did when I was deploying, if you could believe this, PeopleSoft, an Indus Passport.


to get that message out to create a sense of hope and opportunity and a great vision for the future. That's what this is about. We do a lot of work in the background, we want to get your message out. is the place where you start. And you know what, we just have a conversation that no, don't twist, arms don't do anything. I just think that industry is so important. It's so important to


communities, families,


our economy, and I believe that that story needs to get out because I like helping haha. Hey, that sort of rolled off the tongue. All right. The gentleman again, let's get cracking here. The gentleman he's a solutions architect. So right off the bat.


You know, he's smarter than I am. And Thomas, but he goes by Tom Didier. He's with Infor. And we had a great conversation, but it was just like, you don't have to have a big bang and deploying these enterprise systems you don't have to you can. This technology today is wrapped around greatest flexibility and InforEAM just epitomizes that they're their leader, don't get me wrong, they're a leader when it comes to this, and the the team behind it, constantly innovating, constantly pushing the envelope, constantly trying to develop a system that meets your needs today, tomorrow, and on and on into the future so that you can be a success. Well, how can you complain about that? I you can't right. All right. Enjoy the interview with Tom Didier.


Tom, welcome to the industrial talk podcast. I'm absolutely excited about this conversation. How are you doing? I'm doing great. It's great to be here. Yeah. All right, listeners, we're going to have a conversation once again about InforEAM, we're going to talk about the flexibility of the system. And it's not it doesn't have to be an all or nothing type of implementation. Tom comes with a tremendous amount of street cred when it comes to this solution. And looking at your business. Tom, give us a little background for the listeners out there, who you are and why you're such a great professional. Well, I've been working with em dow for the last 10 years, but been with him for 13 this time, 10 years previously, and as an independent 11 years in between, I can't keep up the math. I don't know what it is. Why is that? 102? Pretty much. So I've been programming since 74 in some way.


Yeah, got a good beer, but I'm telling you what's great about it. And listeners, you gotta respect this type of commitment to what he is doing. He's seen it coming from, you know, concept way back when and then he's been a part of that conversation. And he's evolved into a really pretty robust system InforEAM, did you use did you do some other Infor products? Yeah, I did mainframe payroll systems made for a large better that time.


You know, for the younger listeners are saying mainframe, my What's that?


It's a lot more of them than people.


I know. They're out there right now. They're still out there. And somebody was telling me, Hey, does somebody have some Fortran or COBOL type of coding capabilities? What? Somebody, but they still need? Yep. Yep, they still do. All right. One of the things that that I've always been interested in is when when somebody makes the decision to get an enterprise system is an enterprise, meaning it's everywhere, right? But and then they make the decisions, like it's all or nothing, everything else. Is that the right approach? When you're starting to deploy you make that decision? You make that financial commitment?


Yes, no, it depends on where you want to get to, and how fast you want to get there is your current system going to be available for a period of time? Are you currently


when you say current system, your legacy is like, yeah, this is where we're at, we are here over here, we're trying to go over there,


right. And also, the amount of resources you can contribute to the project, you sometimes can't put enough people to the project to get you to the all in portion of it. So you know, at that point to try to get, you know, get them up and running. They want to do their work orders, they want to keep track of their inventory, they want to get all that stuff in place. So you started trying to guide them start gathering the other information for the analytics that they'll be able to use later when they are ready for those. Yeah.


But that has to come with some thought. Because there's probably when when you start to deploy the system, these are non negotiables, you need to do this, you need to do this, you need to this is sort of the bare minimum, if they want to approach it that way, right? Like there's a bare minimum, then we can start adding on?


Well, the simple thing is a problem codes when you close a work order you want to report what was the nature of the problem? What was the fix? Was there a reason or a cause for that stuff that I can analyze later to start looking for trends to see why something failed? If I don't gather that information later, I can't use it. But just getting people to set that up at the front end can sometimes be a little bit difficult one if they're not used to doing it, but to you're trying to lead them to something bigger. Right?


Yeah. And but is there a reluctance to do that? I mean, you've, you've got it, because you don't want to head down that road and you didn't capture that data. And now you're gonna try to, you know, expand or grow it or, you know, do what you need to do.


Okay, well look at a place where basically all they did was handled out of work, or they wrote down, you know, what the changes they made, turn it back in again, and that's it the end of the day. Now, you're trying to get people to do a little bit more, and not everybody's necessarily qualified to make it termination, what was the real problem? Okay, say a machine overheated? All right, I went in there. And I found that, why does it overheat? Well, you know, it dropped power because it overheated, because a filter was dirty. Okay, I can get to that point. But if I start to see that I've got several of those based on capturing this information, maybe I'll look at and say, Well, those VMs that I was doing every six weeks, maybe I need to do it every four weeks. That's the type of information that you can gather, as you're going along here, start gathering that information and use it going forward.


Is there a problem? When you have let's say, your legacy system, and then you're you're deploying a new system, you get that sort of bipolar system input type of environment? Do you have any issues with that? Because I can imagine somebody just coming in? Yeah, pencil whip, I don't care. I'm just gonna enter day, and you got crappy data going into your system?


What's the nature of every implementation? If they have a legacy system, they're used to doing what they've been doing? There's a tendency to try to recreate the current system and the new system


that that listeners is absolute Sage insight, you're absolutely correct. You take your legacy, and then you stick it in the new system. And that ain't gonna fly, fly.


No, it's not gonna fly. But I mean, there are elements of it that may be good, could be things are doing perfectly now that you want to carry that processes forward. Yeah. But you want them to take advantage of the capabilities that they are getting.


But that requires a lot of education as well, you know, you're out there. This is how I used to wander around my facility, I grab my, my pm information, I do it this way. And maybe that's not the right way to do it to you, I mean, you you, you've got a little you got a baseline implementation level, then you got to train to that, so that you're collecting the data that you need to so that you can begin to stack on additional functionality, right.


Whereas the majority of your workforce with a system, they're actually hands on to the work. They're doing the work. So they're the ones that you've basically got to get up to speed, let them enter the information they need to track their time, if you want to know how long it takes. Here's another example of something that you've got to train people to a pm is what a set unit of work that you're going to repeat over on a regular recurring frequency. something specific, right? What happens if you find something else while you're doing this PM, your fix it? Well, not as part of the PM, you write up an additional work order, right? Because you want to track that separately. If I didn't book that time, as part of the PM, I am skewing my time spent on pm you are you know, I'm overstating it, I'm increasing the costs because I may have the first one to that. And I'm losing the analytics of saying, Oh, well, I've got another problem here. Yeah, address the PM, and do a follow on work from pm type work order.


Yeah, because generally speaking, people are gonna say, Hey, I'm out here at this motor, in this pump over here is gonna, you know, squeaky sound coming from it. I'll just take care of that, too. I'm here, I'll be checking that. But I gotta just let me just take that tick, tick, tick, tick, tick, maybe close out this PM, all of a sudden, you've got some, you know, questionable debt. Well, you got a question. It's, it's bad data. not accurate period.


Well, it's not that it's bad data. But now my pm start taking two hours to three hours, right. And as a scheduler going forward, I'm looking at what they should be taking three hours here, four hours or five hours there. How do I schedule on people?


Yeah, see if it required it. You know, as I could, my thoughts are just constantly flying in. It's like, you have to really change the way people approach work. And you've got to keep at it. You can't. It's not just deploy the system, let it go. You have to deploy the system, educate, re educate, keep on doing it, make checks into making sure that things are fine. Right? Are we doing it right? adjust according was that a correct?


That's pretty much right? Yes. You definitely want to get the information you can also use going forward. So it's not just fix it, say I fixed it. And I'm done. Right? What else can I provide to the picture?


And, and culturally speaking, I know that if I'm a maintenance guy, if I'm out there in the field, if I'm doing all this stuff, yeah, I got it. I'm going to, I love riding in on that white horse. Just save the day, and you're really trying to not have them riding on that white horse.


But at the same time, you're trying to minimize keystrokes. You know, maybe a maintenance person is there to turn the wrench. They are not there to fill out paperwork. So you can't bog them down ridiculous layers of paperwork.


I'm sure they'll say that too. They don't go back to the least least. So there's a fine line between Hey, I got to collect the data and not You know, creating enemies on the other side of that whole equation, right?


Well, I have noticed a trend that it used to be, you would just close out your work orders and you'd be done. You know, that would be it. Now, if you put your work order in some sort of a status and says, Hey, I'm done with what I need to do, if somebody needs to run, you know, pass, you know, take a look at it and say, analyze what the problem was, oh, you changed this part. Therefore, this was my problem code.


He responsible for that if


I that's something that can be a supervisor or a plan, or somebody more familiar with making sure because sometimes the maintenance guy just can't decide which. And you would rather go to ask to be put in than the first one off the list.


So what you're saying, is that, okay, I have to have to do a little repair, I got to do a little maintenance on this pump, right there, boom, as a as a repair as a maintenance professional, I can do the repair, but I don't have to sit there and try to figure out, right, create a dissertation on the asset, all I have to do is say, I've completed the work, some minimum minimum type of detail, and then have somebody else sort of go back and say, Yeah, not necessarily,


I wouldn't go there the person doing the maintenance is always the one who's most knowledgeable of what's there. But I say necessarily the one to dig through a list of codes to tell you what it was this one over this one?


No. You know, what, that one?


Well, you know, if they're, if they're used to doing that type of work, and some interesting, very much so, you know, especially heavily regulated ones, where it's going into a hawk that's following that piece of equipment, its entire lifecycle. Yeah, that'd be very good at that.


What what, how does the system because it happens, where humans, it's just what happens out there? How can the system tell me that some people are, for lack of a better term pencil whipping the information? Like, I'm hitting the same code? So I got here, I'm hitting the same code, I'm not entering the data accurately, how does? How do I know that?


What you'd probably look for is, most cases, when you look at a code, there's a drop down list, they click on something, it gives them a list of options, that they pick the first one on the page. They're going through the motions. So you know, you put your harmless one up top, but they're picking the NA, you're not gonna auto stop. That's good.


That's a good strategy that that dropped down, you know, you know, that's the case, I'm gonna go, okay, drop down. Because it's so much work to go down a little bit on a drop down, but they do they pick the top one, you're right.


And it's not necessarily for tech, you pick the first one, you see, that looks reasonable, right? That may be a better one coming along. And I think in some cases, having a secondary review, that person might be more familiar with all those other options. So you know, you're not faulting the first guy going through, you're just saying somebody taking a second look at it may say, Oh, this one is a little bit more applicable to the situation from the future analytical end.


Yeah, see, and I think that that would be a great process to deploy, right? I mean, you get the maintenance professional out there, skilled, skilled, professional, but then that individual is probably saying, I got to get this done. Because I get to go over here. I got to go over here I get, maybe I've got a lineup of work that I need to get, get cracking on. And, yeah, I think that that's a really good little step to have to make sure that somebody is in there saying, Okay, well, just a justice here, get the data accurate. You need it, you need that data accuracy, so you can make some great decisions.


That's the goal.


And if you're not, I mean, you got a system, a powerful system, like like in 40. am. That's that's where the the gold is. Man. Yeah, absolutely. Okay, so here's the deal. It's all it's never all lollipops, and pink elephants and cotton candy, even though we would like it to be that way. Tell me, what are some real roadblocks when you're doing these implementations?


Wow, I'm not really sure if I should answer that one. Because, you know, sometimes you just don't have resources assigned to you. Yes, from the client end, to do everything that needs to be done. Sometimes they think that we're supposed to be doing more than what we are supposed to be doing, you know, and we're supposed to be teaching them how to maintain their own system.


It never works that way. Right? It doesn't. You need a team, you need a team of individuals dedicated for a system like this, but it correct me if I'm wrong. greater value comes when you've got the the frontline individuals providing insights into the true functionality of what they do, and have that system be able to reflect or optimize whatever they do, right?


Yes, but you also have the problem if you assign too many people. Now you've got a room full of people that have to make a decision and have repeated meetings to make the decision.


Okay. The question has to be asked, Well, how do you come on that like that sweet spot of the right amount of people with the right executive sponsorship with the right for system implementation success?


Let me know when you find out


the answer to that one don't that's why I don't


know if it's possible.


It's always we got too many people, and then you get rid of some of the people now we don't have enough people. It is just because the ebb and flow of the work.


What you also have the problem of getting the right people. You'd love to have more guys with their hands on the wrench. But yeah,


around the ranch,


yes, they've got to be doing what they need to be doing. Right? Right. So getting the right mix of people isn't really critical.


It's just like anything else, it always comes down to the people and culture with any of these systems, the tech is the tech, right? In for em is a flexible, powerful system. And it's constantly improving all of that wonderful stuff. But if you don't have the right people, people and culture, supporting the implementation, it can only be so successful.


Well, that's why we try to do things like conference from pilots, you know, when you sit there and prototype out your solution you want to implement, and you bring in the right people to review it. And yeah, you know, if you get that completely disgusted look for the maintenance people, you know, you missed it.


It's funny, because I've been in that conference room at one point or the other. And I've had that look from that kind of that maintenance person. It's, it's like, wow, right, huh. I didn't get it


was like, yeah.


So how do we adjust it? How do we modify it, please help us understand, but you guys you would go through. So you would flow out. Let's say if I'm doing a baseline implementation, for lack of a better term, I'm not going full bore, I have a strategy to get there. But right now I've got to be here. And these are non negotiable. This is where I need to be from a systems perspective, the majority of the work has to be done up front before you even begin to journey into the implementation.


Oh, you're going to set up all your assets to get a majority of information out there, you're going to have all your parts, all that defined your all your suppliers so that you can order more, all that stuff is done there at the front end, you have to have that in place before you go live. You should have all your pm schedules set up, be ready to plug in those dates, you know, at a certain date, we're now cutting over and going forward from this stuff. Yeah, with this system from this date. Yeah, that's all front end type work.



And you want to do that up front, you want to be very thorough, because you don't want to start to implement a system and then sort of go nav rats do want to go backwards, you want to want to keep on moving forward. And that that requires that planning up front big time.


Correct. That stuff should all be in place before you go live.


But it's never the case. Sometimes it's not the case, is it?


You hope it is




live? You got to have that in place.


Right? Right. Because it It's so funny, we humans, you know, we want to get it done. We never have enough time. We're always so busy. And yet you've got a system, the system that requires your attention. But then if you don't give it attention, it's going to cause some friction within the culture in the organization. And but it happens all the time all the time. It never stops. It's like, come on. It's there's a do it right. And then you won't have anybody you know, you'll have some complaining, but not everybody complaining.


But what is doing right. Yeah, you know, it depends how much you want to do with the front end. Do you want to set yourself up for the equipment surveys at the front end? Well, I may not need that to go live. I could do that after I'm live.


But you don't do it after you go online. Sometimes people get busy, don't you?


We that's why we have phases. We'll do a phase one, phase two phase, a phase one is get them up and running, doing what they need to do to be put up, keep their production going. Yeah, right. And phase two is starting to clean up what we've done, we haven't done up to the final state. Face restart adding the niceties. Our main phase if you want, now you have a Hey,


as long as everybody's committed to the phase approach, I'm all fine. Because typically it's like get it up and running. And it's okay, we've got this fire to put out over here that tie and and in the world of COVID. everybody's like, Hey, I'm trying to survive and trying to rebuild and, and everybody seems like they're just, you know, squished for time. Well, the


other thing with phases is you've always got a thing called scope creep that you got.


Ah, good, good point. Good word. So


I mean, eventually you get to a point to say on that little nicety. You can do it with the base system and this is how but if you want that little thing that's going to have to be a phase two items.


Yeah, see, that's funny because I remember hearing the term scope creep. Everybody creeps on the scope. It's this, but I, we were at this, we think this would be great. We, we know this would be great. And you know, and it just keeps going and going and going. And and it requires requires leadership to say no. Can't do it. Right. And these are the reasons why we can do it this way here. But it's going to have to be something over here phase whatever.


You sometimes have to say no one something. If your goal is to slip, if you try to do this, it is out of scope for the project, not in the contract, whatever the case may be.


Yeah. Yeah. And like I said, you got to have, first off, have the courage the leadership to say no, or to be able to say, yeah, we could do it. But we got to cut this over here. Because our, our data's this date, we got to go live, we can sort of manage that project that way.


A line I've heard many times is, is it possible to do this? And I'll respond with Yes. How much are you willing to spend?


There's a lot of you out there. I've had that conversation, too. And yeah, and that same, same statement happened. All right. Hey, Tom, we're gonna have to wrap it up. This was a great conversation. Now. I want to get a hold of you. How do I want to get a hold of you?


You've got my LinkedIn information there. That would be okay.


All right, listeners. You need to get a hold of him. You're going to go out and Didier about that. That's his last name, Tom Didier, his LinkedIn profile, says Thomas. And you will not see a picture because Thomas doesn't have a picture, which I highly encourage him to have a picture. And it's nice to be a part of this face.


Well, look at good,


you'll create a plan of attack. Correct? on how to upload that photo. Alright, reach out to him. Tom, you were absolutely a joy, man. I appreciate it. Great. It's like a walk down memory lane of when I used to implement systems, it's like, but that was years ago, and they're still having the same cup. Come on. Somebody progressed the conversation, and never happened. Do you have Do you have conversations where people say, Hey, I just want to pull it off the shelf.


You know, a lot of people think that software packages are still that way. Maybe? Oh, wait, what is configurable? Yes, it's configurable. It's not Microsoft. I don't pick one out you know what time zone I'm in? I'm done.


I just want it off the shelf. Okay, I don't know what that means. But I guarantee you, we're gonna have scope creep with that conversation. All right, thank you very much. Stop listeners. We're gonna have all the contact information for Tom out on industrial talk podcast. And I'm gonna wrap it up on the other side. So do not go away. Stay tuned. We will be right back. You're listening to the industrial talk Podcast Network.


About that Tom Didier did not disappoint. Love the conversation. Loved exactly what he was talking about. How about that for a flexible system? How about that for a great approach to your organization to be successful? You need it. I mean, if you're going down this world of digital transformation, right, this industry for Dotto need a powerful enterprise system to be able to enable that right and i think in for I am and the team at in for EA has you dot gone cover? All right. I'm here to help. I want you to go to industrial talk comm I want you to connect with me. The water's warm. I'm not gonna sit there and you know, strong army on anyway, your story needs to be told. So please ask me. I'm here to help. I'm here. No strings. That's That's why we're brave. Be bold, be brave, daring greatly. You're changing the world hang out with people those that are like that. We will be back with another great interview shortly.

About the author, Scott

I am Scott MacKenzie, husband, father, and passionate industry educator. From humble beginnings as a lathing contractor and certified journeyman/lineman to an Undergraduate and Master’s Degree in Business Administration, I have applied every aspect of my education and training to lead and influence. I believe in serving and adding value wherever I am called.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.