Unfortunately, businesses often find out far too late that they are required to customize their ERP which can be a slippery slope. Some customizations can have major productivity increases, but over-customization can force a system into a corner, making it obsolete or inflexible when it comes to future upgrades and usability. Usually, out-of-the-box functionality can deliver on the needs of an organization without the addition of over-the-top customizations, but where is the line between needing more and doing too much? Learn how to prevent the downfall of your ERP system through the application of best practices in this installment of the ERP Advisor.
ERP Customization Conundrum: Best Practices for Implementing Your ERP System
What are best practices for ERP Implementations?
Whenever the topic of ERP implementation comes up, you hear business leaders demanding best practices for their new system, but what does the term “best practices” really mean? Best practices for ERP implementations refer to utilizing as much out-of-the-box functionality as possible, without the addition of customizations for special automation or capabilities.
Too many customizations can impair the upgradability of an ERP which is why many leaders begin an ERP project demanding best practices and “out of the box” functionality. The unfortunate reality is that customizations can break when you upgrade, nullifying the effort originally put into developing the customization. Breaking customizations prevents many businesses from upgrading their ERP to the most current version. Fortunately, leaning on your vendor’s best practices can mitigate the risks associated with customization if leaders remain engaged and alert during implementation processes.
Why Do Some Businesses Choose to Customize?
ERPs are designed to meet industry-specific and operational needs out-of-the-box so it is possible a packaged application may not meet the unique needs of an individual business in its entirety. This is why businesses veer off the best practices path into ERP customization, despite warnings from their implementation specialist.
When an enterprise needs special functionality, it will often choose to customize and automate processes with the help of developers. These customizations may seem necessary to an end-user, but many times it is not in the company’s best interest. Users will demand customization because they believe it will deliver the necessary functionality they specifically need to perform their job.
Whether or not it is operationally necessary, users will still make arguments for specialized functionality. It is up to executive leadership and partners to see the real value in customization and make decisions surrounding the risks associated with going against implementation best practices.
Pitfalls of Over-Customizing a System
The over-customization of an ERP system can force it to become obsolete because businesses will skip the upgrades. Upgrades typically include necessary compliance updates, security fixes, hotfixes, etc. that the customized system will not benefit from. A major consequence of this is that the system will be vulnerable to cybersecurity attacks. Another consequence is losing access to future regulatory compliance updates. And even on a practical day-to-day level, excessive customizations can hinder the overall performance of the ERP, causing slugging response time in performing basic operations.
Unfortunately, all too many ERP customizations are implemented to meet the requirements of a single employee. This can be detrimental to a business when those individuals leave because often, no one else understands the customization or the purpose it serves within the system. When this occurs, a business's ability to grow is significantly hindered by useless functionality that will only continue to blockade future upgrades.
A major pitfall is also that customizations are extremely expensive, so when they are done unnecessarily, it wastes a significant number of resources and creates automation that will only be harmful to the system in the long run. Upfront, the customizations may appear groundbreaking, but leaders often neglect the future implications of this sort of functionality, including upgrade hindrances as mentioned above.
Users may request specific functionality to enhance their experiences and solve problems they perceive. Developers may devote time to creating solutions for the organization, only to find the user who requested wasn’t accustomed to the built-in functionality and unnecessarily built complexities to circumvent the best practices. Users who are used to a custom-built interface will particularly need oversight to ensure they do not attempt to “pave the cow path” to make the new system feel like their old one!
Gaps in a system's specialized functionality can only be accurately identified and improved upon after a system has been implemented in its entirety. It will also be painfully obvious that customization is necessary when users are unable to perform certain actions in order to do their jobs effectively. This simple practice can save an organization thousands of dollars. Most importantly, be aware of the adjustments being made to the system and be able to justify the role of those customizations in your operations to cut down on associated risks.
Conclusion
Overall, organizations should stick with best practices when implementing an ERP system to avoid creating obstacles later in the lifecycle of their product. If a product expert or executive employee within your organization is recommending customization, trust their viewpoint, but also verify the information with other potential users and experts before making the investment. In the end, the most important thing to understand about your ERP system may be that the need for too many customizations could be a major indicator that your organization has the wrong product, so it is important to be vigilant when implementing a system for warning signs that the customizations are getting out of hand. If you are in need of expert guidance, schedule a consultation with an EAG consultant, today!
Announcer 1: This is The ERP Advisor.
Announcer 2: Today's episode ERP Customization Conundrum: Best Practices for Implementing your ERP System.
Juliette: Thank you everyone for joining us for today's webinar ERP Customization Conundrum: Best Practices for Implementing your ERP System. Shawn Windle is our speaker for today. Shawn is the founder and Managing Principal of ERP Advisors Group based in Denver, CO. Shawn has over 25 years of experience in the enterprise software industry, helping hundreds of clients across many industries with selecting and implementing a wide variety of enterprise solutions. His podcast The ERP Advisor has dozens of episodes with thousands of downloads. And is featured on prominent podcast platforms such as Apple and Spotify. On today's call, Shawn will discuss how to prevent the downfall of your ERP system during an implementation through the application of best practices. Shawn, welcome.
Shawn: Hello, how are you?
Juliette: I’m good, thanks for joining me today.
Shawn: Good, you bet. It was close but I made it.
Juliette: Yes, you did. Thank goodness with like 30 seconds to spare, but here we are.
Shawn: Oh, I still had 20 to do something.
Juliette: No one would have ever known.
Shawn: I know right? But it's great, thanks everybody.
Juliette: Oh my gosh, there's a lot to consider when it comes to implementing a new ERP system and best practices, a lot of moving pieces. You always hear that businesses demand best practices from their ERP's, what do they really mean by this and where are they coming from with this mindset? What are they hoping for?
Shawn: It's a lot, but it's huge. Like when we started talking about this potential topic I was like “whoa,” and my daughter, who does the transcripts, you watch, she's going to write “whoa,” in the transcript. She's been like she's been hazing me on that.
Juliette: It’s very good; thorough.
Shawn: That's right, that's good. We've had over 400 projects at ERP Advisors, and I've been doing this for 13 years before ERP Advisors, so hundreds of clients before then, and almost every single client has worried about this.
Juliette: Right?
Shawn: It's a big deal, and I'm really glad that we're covering this.
Juliette: For sure.
Shawn: I think maybe Rebekah came up with this topic. Good job. Somebody came up with this topic. Maybe it was Erica, but this is great. Good, so spot on, very apropos for every deal we're doing today to every deal we've done, and every deal we'll do in the future. I'm going to give you the kind of normal description or the normal situation just so we can start with where everybody is at. Then we're going to go to the real deal.
Juliette: OK. Sounds good.
Shawn: Cool, so here's what's happened in ERP. Along the way with lots and lots and lots and lots of ERP implementations from SAP to old JD Edwards to old Max. The reason why I was almost late was because I was at the ECI conference here in Denver. I popped over to that, which was great. That was good and I was looking at all these apps and thinking about all these customers that have implemented over the years. And, especially in the 80s and 90s, when the software would get implemented somebody on the implementation team would say “hey, I want to set up purchasing this way or manufacturing that way or projects this way or accounting that way,” and the person who's doing the configuration says “well, but that's going to be a customization,” and the client’s like “well it's my software, so do it.”
OK, cool, they do it right or they say, “well I don't have a choice because that's how my business works.” Or they say, “I don't care, I'm going to quit in a year anyway,” whatever the reasons are that the people driving the requirements say, “this is what I want in the software.” So great. Software developers are great people. They're probably some of the biggest people-pleasers I have ever met in my entire life. From all kinds of different people like a Baker or whatever, they say “oh, I want to make all this stuff for you,” that's how software engineers have certainly been. They’re like “sure, I can build that out. That's cool. I'll build it. Boom, I just built it, that's 50,000 extra dollars.”
Juliette: Because nobody thinks to ask what the additional fee would be if they're buying a new ERP, as it is, right?
Shawn: Yeah, like back in the day, you didn't even think about the ERP. “What do you mean it costs more to customize it to my needs?” There's just a lot of misunderstanding. That then led to a lot of systems that were customized, and a couple of years later “ok, it's time to upgrade,” and then the software vendor says “oooh, yeah if we upgrade, remember those customizations, they all go away.”
Juliette: Oh gosh, so then you have to start from scratch if you need them customized again. Oh boy, for a whole another fee.
Shawn: For a whole other fee.
Juliette: Oh boy.
Shawn: See you are like an expert.
Juliette: Hardly, but.
Shawn: It's true because then what would you do if you spent say $1,000,000 in customizations if 2 years later, they're like, “hey you need to upgrade your software because there's a few more features or functions in there. Maybe there are the new 1099s, maybe there's a patch or whatever.” What would you say to that?
Juliette: I would probably go find another ERP that contained it all.
Shawn: Yeah, I mean you could, but then how much are you going to spend on that?
Juliette: All right, that’s true, that’s true.
Shawn: But you’ve got a bunch of other problems in the business that you're trying to handle, so you would probably just say “no, thanks.”
Juliette: I'm not going to upgrade.
Shawn: I'm not going to upgrade. I'm not going to go through all that pain.
Juliette: If you have that option.
Shawn: If you have the option, and in reality, a lot of businesses, and nonprofits, and other organizations do and did. Because the software for good enough, and then to do the upgrade, they look at the money and scratch their heads and say “what's the benefit here? Oh, I get off the upgrade path? Well, I don't really care. I don't need all that new stuff anyway. I'm barely using 20% of what I have. So, I'll just stay." And that makes sense, that's the thing is people in this industry make decisions because they make sense.
Juliette: Right?
Shawn: But the long-term impacts of that are they do not get the really important patches, the security issues, or the bug updates. They can't take advantage of that because they've gone off the upgrade path; they're on their own path.
Juliette: Oh boy.
Shawn: I know.
Juliette: So, if someone is already investing the amount of money that these ERP systems cost, wouldn't it be common to have best practices included?
Shawn: Well, that's what you'd think. I mean you're like every CEO, CFO, and client that looks at me and says, "what? I don't understand this.” Because it’s true; doesn't work that way. The best practices for your business are not the best practices for my business. We might be in the same vertical industry; we might be even in the same micro-vertical. Talking to the guys today we might be process manufacturers for ingredients companies; you and I might have an ingredients company and we go buy software. We try to find the best practices in the software, but my company does a lot of international business, let's say. And say your company doesn't or your company has a lot of recipes you deal with, and I don't. In those areas, best practices might not necessarily be your best practice.
Juliette: Yeah, one size doesn't fit all for sure.
Shawn: Yeah, that's it. So, the common line here with customization in ERP has been what I just went through. Folks bought ERPs, they customized the heck out of them, they couldn't upgrade, and they were landlocked in their ERP and they're watching all their competitors. Or maybe some new person comes in and says, “hey I'm the channel sales,” “oh well, you can't get that from the vendor because it's only available in the new versions.” Or “we really want to automate. We want to do AI and analytics with these new tools that Infor’s offering with Burst or whatever.” “Oh sorry, we don't have that rewritten for your older version because you went off the upgrade path.” So long story short is, again this is the traditional story, organizations took these ERPs, they built them out for what their needs were, then they couldn't upgrade. Fine cool. Now everybody knows this, everybody knows this. So, what do they do now? Oh easy, usually it's the CEO who can be pretty high level will be like, “no customizations in the new ERP.”
Juliette: Didn't you say you were going to make a T-shirt?
Shawn: That's right, that's right. I still haven't actually done that; I’ve got to do that. Maybe we'll make a little banner and fly in there, and you know who would fly it and probably jump out of an airplane?
Juliette: Will?
Shawn: Will! If he's not too busy with dates or whatever, I don't know.
Juliette: Right, right, right?
Shawn: We will have to ask him later.
Juliette: Well, he could go on a date and jump out.
Shawn: And do that exactly. That's what I'm saying. Anyway, I want to go with him. Not on the date but on the jumping out of the plane. Will, ok.
Juliette: Rebekah, have that T-shirt made.
Shawn: That's right, Shawn wants to jump out of an airplane, and no customizations. But seriously our mantra, we just had to kick off here in our office with 30 people for a big national project, no customization, no customization. It totally makes sense, right? Does that all make sense first off?
Juliette: It makes sense, but I think there are some businesses that have no choice but to have a customization. So, what do you do in that case?
Shawn: Yeah, so now we're going to talk the real deal. Ok, so you just do it. And the reality is that you do it, you're smart about it and you know you're doing it. Because, just like everything else we talk about, the risk is, is that you're responsible for a project. Let's say your project sponsor--those are the people that I hope you're hearing this right now. The people that jobs are riding on the success of the project; like mine is.
Juliette: No pressure.
Shawn: Yeah exactly, and so they start implementing, and maybe a mid-level person’s working with the consultant, and they realize there's a change in the process for purchasing they have to do. Not just the purchase approval workflow, that's always different, but maybe there's an extra step they have to do. They have a purchase request and then there's an authorized fund expenditure, like in oil and gas, that goes first, and then there's the purchase request then the purchase order. Well, the software they have doesn't have AFEs, as they're called. So, what do they do? Well, they can either do it manually, but the mid-level purchasing, budgetary, projects, AFE responsibility person says, “I got to automate this because we do a lot of these, and I’ve got to have this in the system.” OK, hopefully, that got identified in the demos. “Oh, the app doesn't support it, so we're going to add that,” “oh great how much is that going to cost?” So earlier, hopefully, you find that out.
Juliette: Right, you ask that instead of doing the customization and then having to pick that.
Shawn: Right, that's right. That's ideal. But there's a lot of times where in the selection process, maybe they're not as structured as ours are or whatever--and sometimes we honestly miss things too--so whatever. So, you get in, do the analysis, and the person says, “I have to have this built into the system.” Good, so then the developer, the consultant looks at that and says "ok, we don't do that. So let me go off and think about a couple of different ways that we could do that and come back with some options for you.” Good so you can do option A, B, or C. Option A is you just do it manually, you keep track of it in spreadsheets. Did you know Excel is the biggest ERP in the world by the way?
Juliette: Really?
Shawn: Oh yeah.
Juliette: Ok.
Shawn: Oh yeah, I don't care if it's Fortune 50 or what, everybody uses Excel.
Juliette: It's not QuickBooks.
Shawn: It’s not QuickBooks, it’s right below, exactly. I don't want to get into all the details—apparently, I do--but this is so important. So, the developer comes back and says three options. One, you do it manually. Two, I can create a custom record called an AFE, and you can enter the information there and then you can just click save and it's in the system, or as they raise their eyebrows, and start winking, what you really need is to put in the record and depending on the amount and this, we want to route it to that person, and then we want to check the actual project budgets and whatever kind of crazy things come up, because they love pleasing you. They're like, “I heard your process. I can automate that for you. I can save you 10 hours a week by building this,” and the person on the other side’s like, “you would do that for me?”
Juliette: For a fee.
Shawn: Well, yeah, for a fee exactly. That's right, ok, but does that person pay the fee?
Juliette: I don't know, do they?
Shawn: No.
Juliette: They don't?
Shawn: No, of course not. See, that's where it gets tricky. If you have a contractor in your house, they’re like, “I'm going to build you a marble bathroom and it's going to be beautiful,” and you're like, “ooo that's going to cost me a lot of money.” But if you're the AFE specialist, you're of course going to think, "ok, this is going to drive some expenditures to the company; the company is going to have to pay, but it's saving me time, so why wouldn't the company want to pay for it?”
Juliette: That's true.
Shawn: I mean it, this is going to save me--I'm just using some wild numbers here--eight hours a week of my time that I don’t have to do anymore. I can focus on adding value and adding tasks. All that basic stuff just happens now in the system. So, 8 * 50 is 400, times 50 bucks an hour and you're talking about a lot of money that could suddenly be "saved”. So, the developer comes back and says "ok, this is going to be 25-50 thousand dollars to develop.” You look at the savings and maybe there's like eight people that do this process and it's like, “well, there's the savings right there. So yeah, let's just go ahead and do it.”
Juliette: Like in the grand scheme of things, 50,000 isn't much.
Shawn: It's not much that's right. So *poof*, we build out the AFE process, test it, it works fine, go live and everything is fine, except when we want to upgrade later. The upgrade kills this AFE logic because it's not in the base product and some of the apps are written to be able to handle this kind of stuff better than others, frankly. All those customizations get wiped out, so guess what? We're right back to where we started.
Juliette: So, have any of the software companies learned from that?
Shawn: All of them.
Juliette: And they all have ok.
Shawn: They have and that is a great question. Yeah, basically—that was for Sarah, my daughter, I love you, honey; thank you—anyway, basically, all of them have, and when you look at next-generation architecture apps, those written in the last 20 years, have layers where you can put business logic specific to you. But now where it really gets interesting is with cloud apps. We had a really good conversation, I was really impressed with Oracle on a deal recently where they said to life sciences firms, they are required by the FDA to certify their software; that it works, that it tracks lot numbers for the ingredients, even for packaging and stuff that goes into food products.
Juliette: Oh right, right yes.
Shawn: And other kinds of lotions and potions and beauty products and things that are applied to the body, you have to be really careful with that. And Oracle did a really good job, very early on, saying “look, we are pure cloud. Every couple of months we roll out code in the app, and if it changes your process you have to revalidate.” It's called validation, but a lot of our clients build out a validation process and then they know exactly where the changes are, so they just have to revalidate those couple of areas.
Juliette: They don't have to create it from scratch.
Shawn: Exactly, right. And it's actually become a best practice. So, the bottom line is that yes, the newer vendors have considered this, and they've built it out. It's still dangerous though; we had a client in one of the newer products that had a bunch of code wiped out when they didn't upgrade because there was a fundamental platform change in their workflow engine, and they built a ton of workflows, and *voop* gone.
Juliette: They were gone.
Shawn: But they were able to test that and find it out in advance. Man, I'm exhausted after talking about all that. That's a lot, but that's what really happens, and that’s why I am excited to share this topic, Juliette, because it's going to happen, you're going to customize. I was talking to a vendor a couple days ago, Rebekah and I were, I'll just say this at Infor, and it was a gentleman, I think we're going to do a podcast with him later too--I'm super excited about that.
He was very focused on their tool set, and we were chatting, and I remembered even when I was back at JD Edwards in the early 2000s that these customizations are the benefits. These are the things that take the company's value for the software just through the roof because they can automate their business. They allow their people to focus on more important things. So, the right thing to do is don't say “no customizations,” and just say to all the people involved, "imagine you're going to pay for this customization. You may.” That really changes things.
Juliette: It really does, right?
Shawn: “We'll take it out of your departmental budget, at least. but imagine you're going to pay for this and just give me the case for this.” And then what happens is the accountability goes where it should, which is down to the people in the trenches. And they should be thinking with "Woah, I could see this real benefit,” and it enables them to look at this and say “this could really change our business, but there is a cost to that. What’s that cost? I want to understand that.” We might even do a drill down on this for other folks too, this specific topic, on how to do that because it's pretty simple. But you know what I mean, it puts the accountability where it should be then.
Juliette: Well, it's almost like the cost-risk benefit, in the long run, is the efficiency worth the costs of the fee that they would charge?
Shawn: Yeah, that's exactly it.
Juliette: So ok, you have to customize, can a company over-customize?
Juliette: Oh gosh, yes. Yeah, yeah they can.
Juliette: And not worth it.
Shawn: Yeah, not worth it. I feel like we should start the country music track, dum dum dum, diga dum, so what happens when you over-customize?
Juliette: What are some of the specific problems that can happen to a company when they do that?
Shawn: You're going to get fired.
Juliette: Really?
Shawn: Yeah, yep, I mean, that's like my tip to everybody in a very politically correct way of saying just be careful. You just need to be careful.
Juliette: Now fired because of the cost or just the mistake of what they’ve chosen to customize?
Shawn: Keep going. I mean the list just goes on and on. You build this whole thing out and then boom, the person who builds it out leaves. They get a better job or *laughs* the internal person who was part of all that customization, guess who then turns around and hires them? The consulting company which did all the customizations because they know the product.
Juliette: Right? Exactly.
Shawn: Oh, but you can't hire per the agreements and everything. OK, well, they'll go anyway. It's really, really dangerous unless you know you're doing it, again that's what it comes down to. This is good because in all these podcasts we've done, we've never talked about some of these things, it's incredible. When you buy packaged applications, who is that app written for? You?
Juliette: Well, I would say just generically overall, right?
Shawn: That's it, it's just generically overall. It's like buying a candy bar, it's not really made for you. You go and get a burger someplace, or food from a restaurant; they're making it for the customer who ordered it, whether that's you or not. Packaged enterprise applications by default are not made for you. They're made for a general customer that is in a specific vertical, and maybe even a micro-vertical, but it's not made specifically for you.
Juliette: Well, why, I don't even know if this is the right question, but why wouldn't they make it for someone specific, and then if someone didn't need all that they could make it more generic. They could start taking things out. Yeah, why wouldn't they do something like that?
Shawn: Well, there are some products that are--well, let me think through that a little bit.
Juliette: Does that make sense?
Shawn: It makes perfect sense, and that's how a lot of enterprise software vendors started was they took a development platform, and they wrote a solution for a specific customer say a manufacturer. That's how JD Edwards started; Ed Mcvaney and those guys back in the 70s I think it was. They were writing midrange-based solutions: the AS 400, the I series, etc. They were writing applications and accounting systems for mid-sized manufacturers throughout the Midwest. And they're like, “hmm, I wonder if we could make a system so generic that instead of having to do this for everybody.
Juliette: Just for manufacturing.
Shawn: Just for manufacturing and accounting, or even any manufacturer, there are a lot more manufacturers out there than the one we're working with,” so they did genericize the tools so it would have the key core processes in it, but then it could be configured, or customized, to meet the customer's specific needs. So that's why these platforms are written where you can extend them, you can configure them. You know I love it when somebody says, what do they say? There's a phrase and the hairs on the back of your neck should go up. “Well, I don't call it customization, I call it extension. Or I call it heavy configuration or whatever,” like “oh boy, I know what this means, you're going to customize.”
Juliette: It's code for something.
Shawn: It’s code for “look out!” and again, the problem isn't the customization, it's that it's five problems. The first one is, “we thought whatever was in there was not. So, we thought that AFE functionality was in the app, but it's not.” So now you just miss somebody's expectations and they're going to be upset. But the second thing is "ok then, how much is it going to cost?” “Oh, it's easy.” It's like my house project, it's going to take one day. So, I learned this early on where you multiply the given number times two, and then you take the increment up to the next one. So, one day project is going to take me 2 weeks, unequivocally. “Oh, it's just going to be an hour.” OK, that's two days for a house project. It's kind of the same, so that’s the second thing. When they estimate, they always estimate incorrectly, and guess which way do you think it's less or is it more?
Juliette: Of course, of course, yes.
Shawn: It's always more always going to be more.
Juliette: It’s going to take more time and cost more money.
Shawn: That's right, always. Then they start doing it and then the person who asked for it's like, “uh, I don't know,” and so then the developer starts making assumptions without talking to maybe other people they should talk to because they’ve got to build this thing, right? Then they finally build it and they put it out there, and it's not quite what the person wanted because the person didn't know enough to tell them what they wanted until they actually saw it. Then they give feedback on and say, “well, that's not what I wanted,” and the developers like “I just recorded the conversation. This is what you told me to do,” but the developer thinks, “I can't say anything because I'm trying to be nice, and I want to please you. So, what do you want?” “Oh, I want this, this, this, this, and this.” And then you hear the coins ching ching ching ching ching.
Juliette: Sure, we can make any change you want.
Shawn: We could do anything you want.
Juliette: Uh-huh?
Shawn: Then the fifth and last piece is that finally the person who gets the budget, or the boss, or somebody who's some kind of oversight or responsibility for this, because by now the project’s late because the developer was supposed to work on other things instead of this customization. It's a complete surprise to that person at the top. I mean, there are probably five other problems, but those are the first five that come to mind. So, the person at the top says, “what in the world is this?”
Juliette: And that's where that employee could lose their job.
Shawn: Right, and we don't want that, so anyway. I mean, we're going into a lot more detail than usual, we usually kind of keep it fun and light, but we are coming off cyber security month, so serious time.
Juliette: This is true.
Shawn: Anyway, there you go.
Juliette: Well, are there any key indicators when a system is on the verge of being over-customized?
Shawn: That is a good question. I mean, there's the typical thing of, “well, the software vendor just looked at our instance and said if we upgrade you, you're going to lose a whole bunch of customizations.” It's too late by then. So maybe a little bit earlier the people who were involved in the implementation quit because they knew something was wrong.
Juliette: And they don't want to hang out to dry for it.
Shawn: Yeah, they don’t want to be around for it. This stuff is hard. It's hard, oh gosh, it's so hard.
Juliette: There's another thing you say too, like choose the ERP like your job depends on it because it does.
Shawn: The implementation partner specifically, and that's the other thing, that's the real indicator, ok, when you're in an ERP implementation and the implementation partner starts to dance a little bit. “Yeah, ok, so how are we really doing?” “Good. Ok, wait like that was weird the way you just said that. What do you mean by good?” “Oh, everything is fine.” “OK, now I'm getting really worried,” it's like interrogating a child whom you come home, and your house is a wreck, and they're like “nothing happened,” you know? But you really do need to have that open, honest conversation with your implementation partner and not just the lead whose answer is to say good, and then they listen to your question.
Juliette: Yes, right?
Shawn: It's really to have a good relationship with everybody, top to bottom on both sides the client and implementation partner side. But the implementation partner is the one who has the power to make these changes. I'm thinking of a very specific project right now where the developer was like, “I'll do anything you want lady, just get off my back.”
Juliette: Oh my gosh.
Shawn: Yeah, it was bad.
Juliette: And was the customer asking too much?
Shawn: Well, she was, but her boss’s boss who was really in charge was like “no customization.” And this lady is like “no customizations, except I need it to work this way, this way, this way, this way, and you guys are behind, and you need to get this done. So, get it done!” And the developers were like “oh my gosh, uh, I guess so. I mean, it makes sense. I didn't know about all this, but I can do it.” $1,000,000 later.
Juliette: And it's ultimately not her decision to make.
Shawn: And it wasn't her decision to make. And then they fired her three months later and the companies stuck with this stuff. So, I missed some of the indicators, even on that one. I ended up going everywhere around the world. I had like 5 places to be in 4 days, in Germany and whatever, and just to see what was really going on. We'd lost track of it too, and so it was really interesting to talk to the people that were actually in the trenches, the users, to see what was really going on. And sure enough, there were a lot of changes, and especially in an entity of business where they've acquired a lot of other businesses and they're trying to come together, but they're not really, and you have one developer out here sitting with this part of the company that's saying they want this, and another developer saying they want that, and they’re not communicating.
Juliette: Right?
Shawn: They’re not talking about what's best practice, and the implementation partner is not saying “stop! Don't do this. We've got to get approval from up above before we do anything." So, you’ve got to keep your eye on who the real customer is from the implementation partner side. Who are we really going to do this for, and it's not necessarily those regional people or the lower-level people; there is somebody at the top that’s ultimately betting everything on you and your team, and you need to make sure those people are engaged. On the client side, you have to have, like I said, that relationship with the implementation partner where you can say, “what's happening?” And I mean all this stuff is sort of easy. I always think with that. So why are people still doing this right, because why the advice is still happening. The real problem comes down to--maybe we've already lost people on this call because I've been so technical--what happens. The developer says to the senior person “so you've got this new process and we saw this at this region and that region, and we looked at this and we did the process mapping,” usually by then, the executive goes *thunk*.
Juliette: Yeah, they're lost.
Shawn: They're like, "what? Sure, I, I trust you.” But the person will try to explain what's going on and then; therefore, block time to do that. Sometimes on our Monday morning calls our data migration guys will talk about what they're doing, and I watch everybody.
Juliette: Everyone starts checking their phone *laughs*.
Shawn: That’s right. I got my eyes on you guys
Juliette: Yes, that's exactly right.
Shawn: Rebekah is all over it, she gets it.
Juliette: Well, one is because we don't know it, and two, it's well over my head and the technicalities of it. But to them, they love every second of it.
Shawn: Right!
Juliette: But I would think that for a CFO or a CEO, the whole point of bringing in this implementation partner is because you don't know how to do it.
Shawn: Exactly.
Juliette: So, when they start talking all these technical terms and things that unless you know, you're like “but wait a minute, I don't know, that's why I hired you.”
Shawn: And if you tell me this is what I should do, then I trust you. I don't have any other choice; that's what happens.
Juliette: That’s right.
Shawn: And then the cycle just *blagh* goes down from there because it is always more complex than anybody thought, and it takes more time. And there are assumptions that people make, and we're all trying to do the best that we can, except for a small percentage of people that are trying to sabotage the whole thing and you wipe those people out of your project right away. Those people are gone. Now you got everybody who's like, “look, we're working our hearts out here.” Sometimes you have to get the toothpicks to keep your eyes open when the technical guy’s like “stop, tell me really what you're doing here,” “oh well, we're adding this new table and it's going to take me about 50 hours to do it.” “Ok, why are we adding a new table?” “Because this person asked for it.” “Ok, I know that person and I know they know their job really well. I'm going to go talk to that person. Stay here, developer.” You go over and talk to the person “why are you doing this, what is it for? Didn't we buy this? Didn't we get best practice blah blah blah?” “Oh, I know I thought so too, and I thought it would work like this in the demo but when I saw it, it actually works like this.” “Are you really sure?” “I really am.”
Juliette: Well, that's where you have to trust the person in that position asking for the customization.
Shawn: That's right, that's right. I mean, it's the famous phrase that everybody who's listening to this is thinking right now, trust but *said together* verify. And verify with the right people. Not just the developer who says “sure, I'm going to go develop.” They're not like that. But go back to the subject matter expert who's like “I know this process. I understand this software,” and you know you also can sort of get a gauge on them like, “you know I don't really think you do know what you're talking about. Let's go find somebody else who does.” It's worth it to spend the time to do that. It's a little extra upfront time and effort, blah blah blah blah blah we always talk about finding out what you need, then go do it.
Juliette: And then do it ok, cool. Well, one more question, I think we're almost at the end of our time, but if you are having too many customizations is that an indication maybe you've chosen the wrong product?
Shawn: Oops *laughs*, yes, yes, it is. It is. I mean, it's one major indication, and I'm thinking “hmm, which of my clients have over-customized because we chose the wrong product,” right now, let me get past that. But here's the other thing too, it’s that things change. And so there can be a different model that we have now than before. I'm trying to think of some specific examples here, but the other thing is, again, not all customizations are bad. I'm thinking of one example, in particular, that took SAP knowing that it wouldn't have all the processes that they needed, but it does have a very elegant customization and application development framework.
As do some of the other ERPs, but you can find people that know SAP customization. I mean people listening to this call right now are probably going to call us and say, “oh my gosh, are you saying I should customize SAP? That's what got us into this whole debacle in the first place.” And I'd say, “well, you know, you fueled a lot of kid’s colleges by doing that for the implementation partners.” No *laughs*. But the real reason is because there was a reason why we did it before, and we're going to do it better going forward, the platforms can handle those customizations. If you think about being able to automate your business processes for real like this particular client was a platform company where they were purchasing other professional service companies throughout the world, and there were a lot of overlapping processes.
Everybody was doing the same processes differently, so we said “this is the global way we're going to do billing, and we're going to automate this so that time comes in, it gets approved, it goes into the bill. We check some AI, different things for quality on the details against the business rules in the contracts, and then we push it forward, and it goes to a person to approve and then they approve it.” That process was basically going to end up letting 30 or 40 people around the world do something else. I don't think they're going to let him go. I don't think that's real, but now those people can go and figure out how to optimize the bills. They can handle customer issues. They can go do something better than just create a piece of paper basically, I mean it's electronic and all. It was a very custom billing process so a lot of customizations right, but it's going to change the world for them.
Juliette: Wow.
Shawn: So, it's really a conundrum. Well done on that word Rebekah very much so.
Juliette: Yes, right?
Shawn: It is a conundrum. You don't want to do so much that you get off the upgrade path, but the beauty of the cloud-based systems is you really can't, they force you to upgrade so you’ve got to face your maker.
Juliette: Right?
Shawn: A couple of times a year, that's not a bad thing.
Juliette: Yes, and you have to look at those customizations to see if they're actually working and what you need.
Shawn: Exactly, yeah, when the new code comes out. I mean 10 years from now I don't know what we're going to be doing because everybody is going to automate the heck out of their businesses. That's going to happen, it is happening. Every customer wants that digital transformation, composable apps, you know, all this stuff. Industry 4.0, Web 3.0, I think it is. All these technological trends are all leading toward more automation. So, the more you automate, the more the custom process, the more the business benefit is. Hopefully, it should be with all the right things that we talked about. I mean, you could change an industry, if you look at Uber, all they did was automated taxis. I mean, there's a lot more to it than that, but you had a platform that the driver and the passenger could all work together on.
Juliette: Yes, for sure.
Shawn: And then there is some AI in between. It's happening and has happened in many industries and will continue to. So, I think the bottom line is it's--that's a strong word but I'm going to just say it--a little bit ignorant to say, “no customizations!” But I think people, especially leaders, have to say that just so that people are like, “Woah!”
Juliette: To limit the customizations.
Shawn: Exactly because if you're like, “oh sure, it's fine.”
Juliette: It's a free for all.
Shawn: Like “oh yeah, I'm going to build this thing out exactly as I want, and then I'm out and then good luck with that.” Nobody understands it because Jane Smith just quit, and she built all that stuff with the developers, that's the worst case. I think if we're open about it and we're focused on it and there's a business case behind the customizations, I think you’re ok.
Juliette: It's worth it. Well, thank you, Shawn. As always, we could continue this, and maybe we will.
Shawn: Yeah.
Juliette: In the New Year for sure. So, thanks again.
Shawn: You're welcome.
Juliette: Thank you everyone for joining us again today. Please let us know if you have any questions. We're happy to help in any way you can. You can e-mail Shawn, myself, we're happy to help. Be sure to join us for our next webinar scheduled for Thursday, December 15th, Lessons from The Trenches: an ERP Implementation Consultant’s Year In Review. When our expert ERP consultants will take inventory of the lessons learned throughout 2022 to help prepare businesses looking to tackle and conquer an ERP implementation in the new year.
Please go to our website erpadvisorsgroup.com for more details and to register. ERP Advisors Group is one of the country's top independent enterprise software advisory firms. ERP Advisors Group advises mid to large-sized businesses on selecting and implementing business applications from enterprise resource planning, customer relationship management, human capital management, business intelligence, and other enterprise applications which equate to millions of dollars in software deals each year across many industries. This has been the ERP Advisor, thank you again for joining us.
Shawn: Thank you.