Narrator: This is The ERP Advisor.
Today's episode: Give Yourself the Gift of a Successful Go-Live.
Juliette Welch: Shawn Windle is our speaker for today. Shawn is the Founder and Managing Principal of ERP Advisors Group based in Denver, Colorado. On today's call, we will discuss how to ensure your ERP implementation go-live is a success.
Shawn, thanks for joining us. Good to see you.
Shawn Windle: Yep, good to see you too, and I'm glad that we both got the memo on the black shirts.
Juliette: Oh yes, there we go. If all else fails, wear something black.
Oh my gosh, well good. Well, this is kind of a continuation from our last webinar where we were talking about ERP implementations and now we're transitioning to the actual go-live.
So, not that I have any experience with it, but from what I've learned through the years, is that if you're to this point, you've spent a lot of time and money getting here and have a lot invested. Now we want to just make sure that everything goes as planned, right? Fingers crossed.
Shawn: Yeah, fingers and toes.
Juliette: Well, there may be some people that are joining us today that haven't gone through an ERP implementation or a go-live. Can you describe what a typical lot go-live involves?
Shawn: Well, it's sort of like when a woman has a baby at — no, I’m just kidding. The ERP go-live — it’s sort of like everything else in life, right? If you've prepared for it and you have everything ready, you know we can look at it like the birth of a baby. I don't know. That's probably a terrible example, but it is. It's a big event that's going to occur that you know is going to happen. So okay, if it's going to happen, then let's just make sure everything that we know about gets handled so that when the go-live occurs, the stuff we don't know about, we have time and we have our best resources available to handle it in real time so that the go-live becomes a non-event.
Go-live equals non-event — that's my goal. Ideally, that's how the go-live works.
Does it always work like that? Sometimes it does, sometimes it doesn't.
I mean, we just had a really nice go-live last month where there were definitely some issues that popped up, but they were relatively minor to the point where the client was very thankful and very appreciative and everything else. That's always a good indicator to me that the go-live went well is because our clients like us. If they don't go well, they really don't like us that much at all.
Again, sort of like a lady with her partner at delivery, but it's really one of those things where it's the result of months and months and months of work.
I mean, we'll talk about data, for instance, as we get into the call and how vital it is to do data rehearsals and go-live rehearsals earlier, so that by the time you're ready for go-live, everybody knows exactly what to do. I think overall, Juliette, that's why I love this topic of go-live is they don't have to be a huge event. Go-lives equal nonevent. That's our goal. We know what to expect, so when you know what to expect and you plan for it, then it goes as good as it can go. It goes pretty well there. That's really the secret is planning, and I think everybody on the call if you're interested in ERP or around ERP, you kind of know that innately, that the plan is important.
But really, that's the essence of the go-live is did we plan effectively or not? There are no more chances after go-live, that's the time, and so it's sort of like in high school — I used to do the musicals, I was a terrible singer, but I loved being in the musicals — mostly because there were other people that were kind of cute that did them, too. But I really had a fun time with them, and you rehearse and rehearse and you're working on this and that, and then boom, it’s showtime. But here's the thing then, is that after go-live, now you have a system that's in production that you also have to support.
So, unlike a show, a Broadway show where it's like — it's actually more like a Broadway show — you have your first night where everybody is nervous and not sure how it goes. But then you have the second night, the third night, the fourth night. So, you could think about go-lives as the opening night that you do everything that needs to happen. But listen, we're a long-term show that's going here so it's okay to make tweaks after go-live.
So, we want to make it a non-event, but if things happen, there's still time to fix things and make it go well, and I'll throw in a couple more tidbits later on how to help set the expectation with your fellow stakeholders on go-live, that'll be helpful.
Juliette: Well, it sounds like preparation is the key, and if you have done the correct preparation, hopefully it all just transitions and the go-live goes smoothly.
Shawn: And knock-on wood and everything that's around you and everything else.
Juliette: So, with your years of experience, you've been through many go-lives, many different companies through the years. Can you describe one of your successful go-lives and then what you felt contributed to its success?
Shawn: Yeah, let's see, I think it's a good example to talk through because this go-live that I'm thinking about wasn't exactly the best that we went through, but I think the client was the most prepared for how it was going to go.
So probably the secret ingredient that we did for that was massage therapists. We literally hired several massage therapists to come on site. And the week of go-live, we let people sign up for massages.
It was quite cool that several people took advantage of it. Some people didn't, but it's kind of funny. We actually did do that, and it really helped in this particular instance because there were a lot of nervous folks going into the go-live. The organization was quite complex and the software that that we were replacing was definitely mission-critical, basically billing for a professional services firm. And in most professional services firms — cash flow days sales outstanding in that — and when you look at cash, cash runs of services firms, or any business, if there's any problems with invoicing and our clients don't get the bills and then they get them late and then the clients take forever to pay the bills and then the cash — this day sales outstanding can get extended so there's no working capital for the organization to continue. Now there's lines of credits and other kinds of mechanisms that people can do for cash, but for this particular client, that was the biggest concern.
So, as we went into go-live, we did lots of testing of invoices. But probably not enough, right? I think Juliette, on our calls I try to be honest with everybody about our clients and not like spreading unicorn magic that there will be no problems and everything will be fine. It's just not true. But we knew going into this go-live that the biggest issue we had was the software was good, it was complex, it was a bigger application, a tier one ERP, it wasn't SAP, and it rhymed with “shmoracle.” And the billing requirements were very complex because this professional services firm, an engineering firm, had lots of government contracts. Government contracts with the Federal acquisition regulations FAR DCAA. When you're working for government organizations, they have some very specific requirements from costing and how much they'll pay. We had all those requirements. And we knew the requirements. We knew the app was set up. And the thing we knew was that the team, the billing team and the PM's that were reviewing the bills, were very busy as we did the whole project. Everybody was very busy.
This is several years ago, the client actually sold to — sort of was part of an oil and gas boom several years ago, growing like mad, and they knew they needed new systems. We didn't get enough testing done. And I'll never forget this moment because I was staring the CFO in the eyes saying, “I know we're late, but we're not ready.” And he looked at his controller and said, “Do you agree?” And she said, “No, we're never going to be ready. We just need to do this.” He said, “We're doing it.” Okay. But we knew it was a risk and we did have a mitigation for what happens when we go-live and we create invoices and they're not correct. I mean if anybody is on this call that has been in ERP, your heart should be thumping right now as you hear this story because you're like, “Oh my gosh like, did the people get fired and what happened with the invoices?” And there were several months where the invoicing was down, where the invoices that the system was creating weren't quite right. But we were in a position where we could take that information very quickly, do some manual modifications, and get the bills out.
So, while the implementation team is working with the people who didn't have the time to give us the feedback earlier, now they have no choice but to give us their feedback, so I'll never forget that scenario. It was the worst. It was over Christmas and — it was actually a little later —but it was wintertime and it's kind of up north in the US and it's cold. And I was like I was like this is the worst thing I've ever been through in my entire life. But we got through it. And the client was able to get to the to the back end quickly — relatively quickly — within a couple of months.
So, basically our go-live got extended. It wasn't just like “Okay, we went live today. Yay.” It was actually like a three or four month go-live process to finally say the system’s solid and now we're ready to go. Now — and that system has put them in a position where they've been able to grow and expand and do some other things, which is great.
But the most important thing about the go-live — here's a shiny nugget as I'm starting to call them — is know what your risks are and have a mitigation for them. Don't just go on hope. There's going to be risks inevitably.
Again, testing helps to minimize those risks, here's another little nugget for everybody — I gauge the likelihood of success on the implementation based on the involvement of the end users and the subject matter experts on user acceptance testing. If there's a ton of people involved in user acceptance testing — because you can set them up and you can ask him to come and you can get him ready, you can give him scripts and you can give him all the stuff to do it, but it doesn't matter — how many people were really involved? And if you have a lot of people involved, your go-live is going to be okay. It's going to be hard, but it's going to be okay. But if there aren't that many people involved in UAT, they're going to have a nightmare for go-live because basically go-live becomes UAT — user acceptance testing — and it's just dangerous when that happens, but we have another client that kind of did the same thing — as I shudder and think about it — where the folks were so busy and they just didn't give us the time on the implementation and we told the sponsor “Look, you're never going to get them to give you the time.” They're just not going to do it until it becomes their system, once it's their system, they'll be fine. These are smart people that work it out, but they're busy.
And since the late 90s, what I've seen with businesses, everybody’s so busy. I mean we work with mid-sized organizations; they’re resource constrained. They can't say, “Okay, all the people go do your normal job and then you know this team of 20 people will go over and focus on this system.” It's not real. You've got the same people that are trying to run the business and trying to do the system and you know the next thing that comes up — “Oh hey, we're going to buy a business or whatever” — so, be realistic about the expectations. Don't rely on hope. Use the user acceptance testing cycle as a gauge and then when you go-live, if you have the right resources available to handle anything in real time, too, that's another little gem is we knew — on the second example that I gave you — we knew that go-live was going to be a certain storm. I'll leave it with that on the video — excuse my expressions but well —
So, then we had the developers on-site on several of them and they basically opened all their apps are open to start editing the product in real time and fixing gaps as they became apparent.
So again, got through both scenarios. Both companies were able to get through it. They got live, thankfully, and we were able to make it okay.
Juliette: Well, it sounds like — I mean, there comes a point where you just don't really have a choice and you have to move forward and if you're able to mitigate the problems that come up or work through them, then that's what you have to do. You can't just jump off a cliff and hold your breath and hope it all works out, but you have to do it at some point, right?
Shawn: That's right, that's right. Well, I mean, actually on that point, Juliette, before you get to the next question. This is really important though, because in our industry — I mean you can tell I don't sell software — there are a lot of projects that actually don't go-live, where they actually get close to go-live and say, “Oh, we'll push it for a month.” And then they do a bunch of stuff — “Okay, it's the next month. Let's go-live.” “No, let's push it off.” It does get pushed off, sometimes indefinitely. And that to me. Is like — that's like the worst, right? I mean, I'm always an honest person. I try to be politically correct, but I'm not, but it makes me so mad when I hear about a company, an organization, nonprofit, government agency that spent all this money and they don't go live.
My second project in the 90s with a large management consulting firm — tons of people working on stuff, lots of effort, lots of activity, and then two or three years into the project they pull the plug and aren’t doing it anymore. What do you mean we're not doing anymore? It's such a moral let down. Everybody who's involved in a project, if you don't go-live, they're like, “What did I just do — I just wasted my time.” I mean, much less the money, right? And much less the drivers that you're doing this for are probably still there.
So, you're exactly right. It is sort of like you're standing at the top of the cliff. Anybody who's ever done any fun jumping off a cliff into water or even a pool or whatever, even jumping into a marriage or buying that new car, whatever it is, you know that you want to do it and you know it's the right thing to do. Sometimes you do have to trust the process that you're going to get through it okay.
And I mean again, for everybody on the call. As always, please call us, you know I'll talk to you tonight at midnight — although I have to finish up a big deliverable tonight, so I'll probably be busy, but just call Juliette, call Erica, call Shaun — or anybody in our firm — some of our consultants and just say, “Hey, I'm running into this problem.” We'd love to just give you that little bit of insight because to not go-live is like — all of us in the ERP industry die a little bit. Frankly, and I hate that. There's ways of getting around it, ways to get better.
Anyway, I'll stop being so emotional now.
Juliette: Well, I mean people put in a lot of time and emotion and it's their job.
Shawn: That’s it.
Juliette: You want it to be successful.
Okay so let’s talk about specific factors that we should keep in mind before getting ready to go-live with the new ERP system. Can you talk to us through that a little bit?
Shawn: I can, and there's four factors that I'm going to give you, and I've alluded to them all throughout the beginning, so hopefully people are still on and now you get them.
The first thing is user acceptance testing and the most important thing in that phrase is the first two words — are users accepting the system?
See, it's kind of a funny thing because when you think about UAT or testing, it's like we're making sure that the software works. No, you're not. You're making sure that the users will accept what they have. Do you see the nuanced difference there?
It's not about “okay we're going to put this this system through all these tests and blah blah blah and if it passes then we're good.” No. What we're actually doing is a very subjective process as we're making sure that the folks who are using it are actually going to use it and they're accepting of it and they're going to say, “Yeah, this is good.”
Now you have to be careful because some people say it’s great and you're like, “ow did that testing go?” “Oh, I didn't do it.”
Well, why are you telling me it's great then, that's scary, right? But in responsible organizations that doesn't happen so, that's the first thing is let's make sure that the users really accept the solution that's in front of them, because they could have said that requirements were “A”, but then throughout the whole process they changed to “B”. Now we have software that reflects B, but what they really wanted was A. B works perfect, but what they really wanted was A, so they're not accepting it. “Okay, well, we're still going to go-live with it.” Well don’t do that. Make sure the people that need the system are going to accept it. That's the first factor.
The second factor is data, data, data, data, data. I think we're going to do our next call. That's going to be called “data” and we're just going to say the word data for like 3 minutes and then it'll be the end of the call.
Juliette: I think that's been a part of almost every podcast webinar call that we've had is data is so important.
Shawn: It's the real reason why organizations implement new software. I mean, there's process automation and there's new user interfaces and there's technology legacy. You know, we built this app and the person who wrote it is like 125 years old and da da da. There's all those kinds of problems. But ultimately, the reason why we want new systems is because we want information about the organization that we can't get. When you get bigger and bigger and bigger — I mean we struggle with this and we're a fairly small organization with 18 people or whatever. And I don't know what's happening with everybody anymore because we're just smaller.
So, getting the data as best as you can during the conversion process and then at go-live is vital. And the secret to that is the dress rehearsal. One of our guys came up with that theme. But he does three or four go-live cutovers early in the project to test that we have all the data that we know what we're doing, we've pulled all the data that the users know where to go and can validate and make sure that it's right. So, the second factor is data.
I'm like on a roll today, so I’ll just kind of keep it a little shorter — but so the third factor with — the cutover with the go-live — this is a little bit — I do think folks missed this honestly, so this is another time to perk up your ears. They really don't set the expectations with all the stakeholders on what could happen at go-live.
So, it goes back to hope. We are very much people that have a lot of hope in what we do. Man, we do a lot of preparation. And you can rely on luck and you can have some and you need it. But here's the thing. Let's say you're a large privately-held organization, and you're going live, and go-live has been okay, and we're getting closer — or the implementations fine — okay, we're getting closer to the cutover and getting ready to go-live, and we feel like there's some things we're not totally sure of, so maybe a couple months in advance, especially for our CFO's and controllers out there, you might want to talk to the bank. You have covenants reporting that you have to do, and you might say “hey, we're switching systems. I think it's going to be okay. I'm going to be able to get you the covenants reports on time, but I did just want to let you know that we may be a little delayed.” Or maybe to the board. I can sense as I say that that people like I don't have that luxury to do that. Well then you better make sure that your systems tested well.
But I am telling you from doing this year after year is that you really do want to set the expectation with people a little low and then work like mad to exceed it.
But that's the third thing I would say is really set the stakeholder expectations that it might be a little bit bumpy on the go-live.
So, the last piece and I think you know we — I'm looking at my own methodology that I created for ERP Advisors Group and our change management approach, which is pretty practical change management kind of thing, it's not some high level like “make sure everybody feels good.” No, no, no. But you really need to incent people after a go-live. You have to acknowledge that they worked hard, that they put in personal time, that they've committed at a higher level than maybe some of the other employees in the organization have. Because they're still doing their day job, but then they get you to go-live. Do something for your people. I mean, maybe a little cash — doesn't have to be a lot. Maybe it's a small gift or maybe you send them on a three-week trip to Jamaica and they just hang out down there. I don't know about that, but I'm just a little something that that really incentivizes people. Maybe you don't even tell them you're going to do it, but you just do it at the end. And it's sort of — there's some recognition. I think what people love the most from what I've seen is the CEO sends out an email and says that go-live was hard, we got through it, and I really want to acknowledge these following people for committing to the business and investing so much of their personal time. And then maybe you are sending flowers to their wife, or you're sending chocolates to their husbands or — I love chocolate. If anybody ever wants to make me happy, just give me chocolate. But whatever those little things are, even to the family members, sometimes those are just nice things to do.
So, there's four factors, I'd say.
Juliette: Well, speaking of those, I don't know if maybe they would go along with this next question, but if you were asked to put together a go-live checklist, what are the musts that you would include?
Shawn: I would include Curtis Wait. Or Quentin Dewitt or our other guys. But these are guys that have been doing this forever.
So, specifically in a cutover checklist — that's a great question to ask by the way. That’s probably the most valuable question that we have asked in five or six calls, honestly, so we should point to this for everybody, because there's very little understood about go-live cutover checklist. Because the problem here — and then I'll tell you what should be in it — is the client thinks the implementation partner is going to put together a go-live cutover checklist that’s going to contain everything that needs to get done at go-live.
Well, maybe the vendor doesn't necessarily know everything that has to happen, so the vendor certainly knows that we need to move this data over and we need to open up the access for the new system and be ready for problems. Okay, fine. But from the client side it's like, wait a minute I have to make sure that the people that are going live have a job aid that's laminated — a piece of paper that's laminated, that says, here's how you log into the system or here's how you do the really simple things — and anymore in this virtual world you have a library of these things so people can get to those. You got to make sure that's available.
I tend to look at cut overs and the checklist as something that a third grader would understand. Make it extremely simple and we're talking about a third grader who's not some tech whiz kind of person.
Just as an example of a little nugget, again, is on the cutover checklist, you always have to include when you stop access to the old system, because we've had this happen before, we're live on the new system and oh my gosh, the customer service representatives just put all those orders into the old system. Well, why didn't they have access? “I don't know. I didn't know I needed to turn it off.” I wish everybody knew that. Well now they do with these videos.
But that's something that's important is to think about by day, by hour, and by order within the day what needs to get done and you really do want to think comprehensively, so even — we usually start kind of “minus-ten-day” the ten days before the cutover. Sometimes it's two weeks. Sometimes we'll set — there's another nugget of things that people might not think about being in there is send a quick communication to your customers and say, “You're now going to be paying your bills online. We've told you about it all along, but that's happening in two weeks, here's a link to the test where you can just go and see it. Or here's the link that you're going to need two weeks from now.” And then you send that to them six days beforehand and then two days and then certainly the day before.
So, you really want to think with all of the tasks not just refresh the customer list, refresh the vendor list for go-live, bring over the ending balances from the old system become the beginning balances, or all the open transactions for the old system come into the new system. I mean, there's all kinds of tips and tricks and things you can do there. Another little one to think about — some of our clients will pay all their bills out of their old system, and they'll cut all the checks, but then stick the checks in a drawer and then there's no AP that has to be brought over to the new system, and then they'll send out those checks when they want to, it's a little manual process, but it's one less thing to think about at the cutover.
But probably the only other thing I would say, Juliette, is —oh yes, oh thank God, okay — yeah, as we're preparing for this call I was like data, data, data, data, data, data and then the other thing was bank integrations, bank integrations, bank integrations, bank integrations.
A big reason why folks switch out their accounting systems is so that they can automate processes, and one of those processes that can be automated is bank communications.
So, hey, we do our AP. We want to pay these vendors — let's say there's 150 of them — and we've set these vendors up as ACH, EFT, whatever, or even some of the international standard. We click pay all ACH save yay, it's done, right? Well no. Then a file gets created and then that file has to get transmitted to the bank and then the bank will process that and then all the ACH and EFT wires go out which is amazing so we don't have to go to the bank and do each one. It saves a ton of time. Most folks love that and it's a great thing especially for controllers to do.
But man, if you got that integration you got to test that that bank integration so early, you have to start —like ten years ago you should have started. It takes a while with the banks, but at cutover you want to be in communication with all of your third party vendors that you're integrating with and telling them this is the day that we're done testing. Now we need to send this to our production system. Don't send any of the test files before then! But now we're going to do — it starts today. So that’s another thing on the cutover checklist is to make sure that you're communicating with the vendors to say it starts now.
Juliette: Instead of an “oh no” afterwards, right? Like what did I not do?
Shawn: Why didn't anybody get paid? Why didn't our employees get paid on our payroll conversion?
Juliette: So, okay along with all the nuggets that you've given us today, is there anything very particular that our listeners today should watch out for when preparing for a go-live?
Shawn: All the indicators for a bad go-live happen early. It's not like the project was going great and then we did the cutover in the go-live and it was terrible. It just doesn't work that way.
Years ago, I had put a blog entry out on a site that — again, we try to be practical — it said, “When you're selecting an implementation partner, find the partner you're willing to bet your job on. Because you are.”
So, I would love for the folks listening today to understand — trust yourself, trust your gut, trust your intuition, whatever you want to say. But early on in the process, you watch like a hawk, the implementation partner. And you make sure that their stuff is together. There that they know what they're doing and that they're organized — and we're talking about people on the project, right? Project managers specifically, and then there's usually a technical lead. Those two people — you want to watch them like a hawk. Let them do their thing for a little bit — a month, maybe two, maybe it's a couple of weeks — and when you get those early indications of like this, these people are not organized. I mean, you have to raise the flag right away and you go to the project sponsor on the implementation partner side say “look, I'm kind of worried about these guys. They don't seem like they're very organized.” “Oh, they're fine. They've done this all the time. It'll be okay.” You put a warning out there right and then as you go a little bit further and you see that the disorganization continues, you go back to that person, say, “Look, I warned you on this. This is getting a lot worse. You're going to need to talk to them now.” And they will. And you give them that third opportunity. If it's still bad, you go back to the sponsor and say, “That's it, I need a better team and you have to get me people that have done this before from my industry.” And they're usually like, “Oh yeah, I have this great person. I'll get him plugged in.” Then everything works; you'd be amazed. Look every business is growing and expanding, including these software vendors and their implementation partners. Sometimes they hire somebody who's done this a million times before they put him out, and they're terrible.
So, I mean, that's the last thing I would leave everybody with today, Juliette, is you really need to trust your own instincts on if you're seeing the disorganization — that's the biggest indicator, it's what we call a bad indicator, an indicator points to what could be a problem It's not a thing in and of itself, but if the person is disorganized — which is kind of a thing — but if they're just disorganized when it's easy, when you have all those tasks that go-live, they're going to be clueless. So, handle it early, but escalate appropriately. Don't just say, “This person is disorganized. I want him off my project.” I mean, you could do that, but just see the person, watch them, and then put out the warnings to the sponsor to say, “Hey, if this doesn't get better, they're out.” And that's when you get the best people from the implementation partner sometimes if you don't have them already. So, there's a little nugget that will hopefully help everybody a lot.
Juliette: You just want the best team to get you where you need to be, right?
Shawn: Yeah, that's right.
Juliette: I know we are over time, but we had a question come in, do you have a few minutes?
Shawn: Yeah. As long as you guys don't mind my dog snoring in the background over there, she's kind of loud.
Juliette: I love it.
Okay, so the question that came in is how do you handle that one person that always comes up with a roadblock at every turn on why the project can't go-live but all requirements and system performances have nothing wrong?
Shawn: Well, we have a guy in our name on our team, his name is Guido, and he uh — no, I'm just kidding.
It's a very good question.
As always, my accounting teachers taught me the answer is always, it depends, but it really does depend on the person's importance to the go-live. If it's somebody who's a little lower level, maybe they've been there a long time and they really don't want to change. Ignore it. As long as you know it's fine, the person is going to leave your company after go-live anyway.
Juliette: You think? Is that usually what happens?
Shawn: I know. And they probably needed to go anyway — that just happened, like it happens all the time. Now if they're higher, and they are saying things like, “Well, I don't think we've really tested my area of the application very well.” That's a different story. Okay, great test it. We're going to stop the rest of the project, we're going to give you X amount of time. Go do it.
If they’re somewhere in between there, you have to gauge how important is this person’s satisfaction to the overall goal? Because they might be at a lower role, but they have a lot of influence with others, and if they're complaining and other people hear it, then fear starts to spread. So as always, the best thing to do is to confront the individual and just say, “I really want to understand what you mean here. Show me what it is.” But, sometimes people aren't quite forthright or whatever, and like I said in the instance of them not being quite forthright, you really need to weigh the consequences of this person being dissatisfied.
I can tell you that much like life in general, if you're doing the right thing for the organization, for you as the sponsor, and for the end users and the owners — if you're doing the right thing and you have one dissenter. Okay, fine. Go with it. But if there's some things that aren't quite right, that's when the dissenter’s voice hurts, when it comes in on you a little more. When you're like “crap, we didn't do this well” that lets you know to go talk to the executive sponsor to the CEO or whoever is really overseeing this thing and just say you know what? We need to do this. This person mentioned this, and I think they're right. And then if the person stops flapping their jaws at that point, it's good. But if they're continuing to flap their jaws, just ignore and just go-live. Easy for me to say, but that's my advice.
Juliette: And just pray it's only one person.
Shawn: That’s right. Yeah, that's a great thing actually. If it's the one.
Juliette: That's right. Well, Shawn, I think we've come to our time today, but thank you as always for sharing your knowledge and expertise with all of us.
Shawn: Glad to have the opportunity. Thanks, Juliette.
Juliette: Thanks. And thank you everyone for joining us today, we appreciate you taking the time. Let us know if you have any questions. As Shawn said, you can reach out to any of us, we're happy to help in any way we can.
Narrator: ERP Advisors Group is one of the country's top independent enterprise software consulting firms. Advising mid to large sized businesses on selecting and implementing business applications including ERP, CRM, HCM, business intelligence, and other enterprise applications which equate to millions of dollars of software deals each year across many industries.
This has been The ERP Advisor.
