Dynamics Corner

Episode 350: In the Dynamics Corner Chair: The Three Pillars of Successful Implementations

• Nelly Jebran and Patrick Johnson • Season 3 • Episode 350

Share episode

👩‍💻We have Nelly Jebran back in the Dynamics Corner chair with us on this episode — this time in an enthusiastic discussion with Patrick Johnson on the importance of #ChangeManagement in successful implementations. 👨‍💼
 
⛵Join Kris and Brad along with our two guests as we navigate the waters of #BusinessCentral implementations from both the partner and end user perspectives.🚤
 
What you don't want to miss:
 
👥Why talking to representatives of each business function early in the implementation is critical in an integrated #ERP like Business Central.
 
🙋‍♀️Why user acceptance of the solution is just as important as user acceptance testing.
 
😱How the fear of change can stall go-live decisions and how psychology anchors implementation success.
 
👑The vital role of leadership in launching an implementation project and sustaining it throughout, and post go-live.
 
✳️The need for thorough requirements gathering in ensuring user satisfaction.
 
🧗‍♀️How a phased approach can help manage user expectations and keep your project within scope.
 
🗣🗨How two-way communication and ongoing dialogue between users and partners drives continuous improvement.
 
🌱"Don't let 'perfect' be the enemy of 'good enough'" and help your teams "grow" through implementations instead of just "going" through them.🌻
 
Join the conversation here and tell us what you think!

Send us a text

#MSDyn365BC #BusinessCentral #BC #DynamicsCorner

Follow Kris and Brad for more content:
https://matalino.io/bio
https://bprendergast.bio.link/

Speaker 1:

Welcome everyone to another episode of Dynamics Corner. You know what I would want. I want my power back, and that's a change that I'm willing to bet on that I'm going to get my power back.

Speaker 2:

I'm your co-host Chris, and this is Brad. This episode was recorded on November 21st 2024. Chris, chris, chris, sitting up there in the Pacific Northwest without power. That's a change. You have to. Northwest without power. That's a change. You have to manage that change. It's a change and adapt to that change. Speaking of change, today we had the opportunity to talk about implementations, changes within an implementation, how to implement Business Central with two podcast veterans, and I could talk with these two guests for hours about business central implementations and the human factor behind the implementations and some things to look out for implementations. Today, we have the opportunity to speak with Pat Johnson and Nellie Zmar. I hope so. If it doesn't, it's alright, alright, you ready. Actual recording quality is higher. What is my rates? Oh, dude, it's actually uploading slow for me too. I'm at 48. Am I going? Okay, though?

Speaker 1:

yeah, yeah you're, it sounds. You're very clear, actually. Good morning, hello, hello, hi, hello from the Chris. You got power, the dark side. I have no power.

Speaker 2:

The dark side.

Speaker 1:

I am running off a generator.

Speaker 4:

Yeah, the city just decided to clean our street.

Speaker 2:

Of course, course, like right as I logged on yeah, that's, um, that's usually something that happens to me, so it works. Usually, every time I start a recording, uh, somebody will knock on the door or the the individuals that take care of the lawn will come and feel that they need to take care of the lawn. It's like clockwork. It doesn't matter, I could have a different, so it's good. Good morning, miss Nellie. How are you doing?

Speaker 3:

Good morning, I'm okay, I'm alright, I'm good it's gloomy and rainy.

Speaker 1:

It's rainy. I love gloomy and rainy. You live in Washington, that's just.

Speaker 3:

You have rainy, you live in Washington, that's just you have to. You, just you, lie to yourself.

Speaker 2:

It's normal, it's normal, I don't mind the rain, but as long as it's not gloomy. And I don't mind the rain as long as it's not cold. But, like a cold, raw rain is not nice Unless you have a fire. Yeah, rain is not nice Unless you have a fire.

Speaker 1:

Yeah, unfortunately, that's what I have right now. It's like, first of all, we're recording this podcast with no power. I'm running off a generator and it's cold, rainy, gloomy and clearly it's dark. But, surprisingly though, with my kids kids with no electric electronics we had a great time, you know. I mean like we just sat in the table. We played this game called left right, I love that game uh, I don't know, it's amazing.

Speaker 1:

It's amazing, so it's like it's like needed, I guess, in a, in a connected world. But you know, you could only do that for like two days, right, and then you're like okay we need internet Dude how long have you been without power?

Speaker 1:

So what's today? So Thursday, so that means we're having a power Tuesday, so we're not expected to have power back by Saturday. So it's pretty crazy that it's not typical. So we got hit with a what they call bomb cycle, a cyclone, bomb cyclone, and if you look at the images I saw yesterday and uh, it looks like a hurricane and you just get high winds we had like 65 mile per hour wind and so it was pretty, pretty scary, because I'm out in the woods with lots of trees and so a lot of neighbors had trees uh, fall on their property and then on, you know, on their house, unfortunately. So hopefully everyone comes out okay, whoever's dealing it, if you're out here in Washington State.

Speaker 3:

Yeah, I talked to someone at Microsoft yesterday. Well, he was at the Microsoft office but had no power at home.

Speaker 1:

Yeah, Redmond, which is where Microsoft is. Redmond, a ton of people that have no power. So there's about half a million, more than half a million people don't have power in one power provider, when you don't have power.

Speaker 2:

It's a harsh realization sometimes of how dependent you are upon power for some of the smallest things. Even some stoves or other devices require power to start. So it it's, it's a catch. So you have to go back to make sure you have the traditional, you know, matches and and wood. But um yeah, which?

Speaker 2:

which this whole conversation this whole conversation may be fitting for the individuals that we're speaking with, uh, but you know this whole. How do you deal with with change management or how do you deal with process? And thank you both for joining us again. You're both veterans now and we've had great conversations with you both and I'm happy to have both of you together because we have a lot of conversations about Business Central. As far as from the technical point of view and maybe from the application point of view of you know how to use the application, how to develop the application.

Speaker 2:

I see a lot of information about that and what I'm happy to start seeing a lot of is how do you implement it right? It's not usually a lot of conversation about. These are the things that you need or should do as you undergo an implementation of Business Central or in anything I guess you could say, any ERP application. So it can kind of you know, cross many different applications that you have. But before we get into the conversation, if we could just tell everybody a little bit about yourselves and we'll go from right to left, left to right. However, I'm looking at this, patrick tell us a little bit about yourselves and we'll go from right to left, left to right. However, I'm looking at this. Uh, patrick, give us a little bit about yourself, please yeah, great having you guys.

Speaker 4:

Uh, for another amazing conversation. Um, nelly, is the first one we get to do together, so great, great, getting to see you again. Um, my name is patrick johnson, so I am the business central practice manager at lbmc technologies, um, based in atlanta. I've got power. So sorry, chris, we got the mother-in-law suite. Come hang out. Um, you know we have been in this space for 21 years, coming up on 22, but what is it we talked about last time? We're going to start saying that, no, I've been doing it for more than two decades, over two decades.

Speaker 4:

Yeah, Everything from general application implementation. I've been an end user, done support and development, a little IP, and then for the last five years I've been running a practice doing implementations, managing teams, doing cross implementations around platforms inside of the D365 suite, as well as a bunch of other tertiary products.

Speaker 2:

Great, great Nellie. How about you?

Speaker 3:

Well, thanks for having me on with Patrick, because I watched Patrick's episode and I loved your approach to implementations from a partner side, and something that I don't see often. So thanks just for that perspective. I'm excited to talk to you, but a little more, um, I'm back in the chair.

Speaker 2:

We have the sign again we do. This is a permanent fixture in my household now um, so I have been in the bc space for half a decade. That doesn't sound as impressive.

Speaker 3:

We do. This is a permanent fixture in my household now. So I have been in the BC space for half a decade. That doesn't sound as impressive For five years as a user and just due to the nature of the implementation. It was right in the beginning of COVID Our partner couldn't be on site and I had to kind of learn a lot that I may not have had to, which is, in hindsight, a really good thing. Um, and I think it's a great product, but we struggle to implement it because of the lack of change management, and so people don't think of it as much of a great product as it is because of that, and I try, you know, with our implementations and our other divisions, to keep that in mind, so that the benefits of the solution are evident to the users.

Speaker 3:

And I think that has, you know, change management is critical to that, and so here, we are.

Speaker 2:

No, it's great, Great Thank you. I look forward to the conversation with both of you and I get to see a lot of the information that you both share. But, as we talked about, I think separately and now I'm happy that we're all together but as, going through implementations, how do you? You know, one of the things that I see a lot of and work with a lot of on implementations is, you know, determining the scope of the project, right, how do we determine the scope of the project? And anytime you determine the scope of the project when you're going to do what we'll refer to as requirements gathering, as you go through the actual implementation, we have that wonderful thing called scope creep, right, and maybe does anybody know what scope creep is? Does anybody experience scope creep?

Speaker 1:

All the time.

Speaker 3:

We're the cause of that, the users.

Speaker 4:

Yeah.

Speaker 4:

Probably Well, and to be fair, sometimes it's the partner too, right, because if we're not asking the right questions at the right time, right, we might be missing something, because as users, you guys don't necessarily know what you don't know before you get into the situation. So you know, one of the things I like to say when I'm talking to clients, or even internally, is that this is the scope as we understand it today right, with an understanding that there's probably some need for agility later on. Otherwise, you know something that might take 6, 8, 12, 18 months. It used to say what the life cycle looks like. We're in a space that changes every six months. We get new features, hot fixes, there's new ISVs, right. So I always like to try to say scope as of today, right, with the expectation that there might be a change later on. Now, if we've got a one-week sprint and you change scope on Wednesday, right, there might be a little bit of a different conversation.

Speaker 3:

Let me ask you guys a question from as implementers, typically from requirements gathering to go live. What's the typical timeline, or does it depend on, oh god, company size? Ours was two months and it was crazy.

Speaker 2:

for my point of view it varies because it depends on what you're implementing and also, as you had mentioned in your comment, the size, because if you're implementing maybe the financials portion of it just general ledger accounts, receivable, accounts payable, just strictly invoicing, not really inventory management, that would be much faster than an implementation that involved distribution, manufacturing, multi, you know, transfers and such. So in my experience it varies and I don't think there's a cookie cutter approach to an implementation. I mean, I guess you could go through the process of determining what you need to implement, but I don't think that two implementations are the same. I mean you could even do two companies within the same company and the implementations could be different.

Speaker 4:

Yeah, I mean, I've implemented two competitors right, so like two people to do the exact same thing in the exact same platform and generate the same product, and their two implementations were completely different. And it's something that I like to say. It's the people there and their processes, right. The platform could be identical, but those first two portions of it have a really big implication on the implementation. And then you know also the adherence to change management, right, because the people they're particularly leading the project and also the people involved in the implementation can really define how often they stray from what you kind of defined.

Speaker 4:

And then also how fast it goes, right, it's the level of engagement, um, from the end user, because at the end of the day, like, how fast can you implement bc? I mean, the fastest one I've done was four weeks, right? Um, it don't. Yeah, that's a, that's a story for another day. But the, the uh, you know, the longest one I did was 36 months, and it was because we just constantly had this huge change curve you would see it every three or four months where, like, a new person would come into the project and have new requirements yeah, I think it.

Speaker 1:

I think it varies so much. There's so many variables, like what patrick's, you know, mentioned, I've done, uh, my finance module only for a month and then, you know, and the other side of that, I've also worked with another end user that had his only finance module as well, but it took them three months and they were exactly the same. You know, again, there's so many variables because your involvement right, the end user's involvement can also hinder that because they're too busy, and vice versa as well. So, yeah, it really varies.

Speaker 2:

Well, let's take that back. What I started talking about was scope creep, right, and I don't want to confuse. I mean, patrick, you started talking about maybe a change of scope because of the climate at a particular time. So, as you're going through implementation if it's spanning months or years, there may be a different requirement from the business point of view you had mentioned. Add a new person to the project and they change the requirement.

Speaker 2:

So let's take it back to how can we minimize the scope creep, which, to me, scope creep means we've already gone through, or an organization has already gone through, a determination of what is needed and then, as they're going through the application, they say, oh, can we add this, oh, can we do this? Something that's separate from maybe a change in process, but it's now that I'm starting to use the application. I can see the stuff that we're doing. I'd like to have new things added From the user point of view and from the partner point of view, working together, which is why I'm excited to have both of you on, because we can have maybe two different perspectives or maybe two different thoughts on it from different angles.

Speaker 2:

How can we minimize or how can someone minimize that? Because to me. I've seen that that's been costly, not only costly financially, because you often require additional time, and costly because of, again, time, it will maybe push the implementation off from your go-live date once you schedule one. And if you do have it scheduled, you're trying to squeeze some stuff and you may not get stuff thoroughly tested or thoroughly, you know, thoroughly, uh, trained, um, so how could you minimize that risk? And then I always have to go back to my famous question, which I'll ask afterwards here.

Speaker 4:

Uh, maybe I'll start from the partner's side, because we're usually driving some of the conversation, at least in the first couple weeks. Um, you know, generally it's a shared project plan with the architecture understanding of hey, you know, you communicated x, y and z and we've recommended that you implement right and glap and ar. And then hey, but you also have this inventory component that might require this, this and this. This is how we're going to do it. We'll build out a project plan and we'll try to work towards that. You, as an end user, we try to share that project plan because it's very much you have to own a part of it, right, like, at the end of the day, we're really just helping you do the thing that we know how to do really well, but at the end of the day, like you have to own your system, like we can't be there to run your business, like there's other kind of consulting to do that, right, um, but for us it's a big thing about communication, transparency and then that shared progression, right, and we do it through, like project plans and weekly check-ins and things like that. But you know, I think it all boils down to communication and then level set expectations, right, like if you want to change something, this is how we change it procedurally, internally. And like there needs to be some level of agreement around. Yeah, if we're going to make a change to the scope of this implementation, we agree. You know, we'll go through this process with you and we've established that process based upon, you know, a lot of experience seeing it either done really well or, in some cases, really poorly. And it's that expectation and communication that I think really makes those successful, because change is going to happen at some point during the course of that implementation.

Speaker 4:

Like it just is, um, and it's again because you don't know what you don't know, uh, but I think you've got to be really clear, transparent, honest, um, and that's bi-directional communication right. Like it can't just be the partner driving the whole process of the communication. Like the end users have got to communicate back to the partner driving the whole process of the communication. Like the end users have got to communicate back to the partner what their expectations are. Because it's not, you know, it's not all on the partner and it's not all on the end user. Like there's a reason they call us a partner and not an implementer, right, and it's because a partnership exists between the two groups. I mean, you really have to address it that way, rather than just treating it as a business transaction, like it really is a relationship style interaction, yeah, yeah, and I think from from a user perspective.

Speaker 3:

So a couple of things. And I'll add one ownership on the client side is critical and has to be, again, like you said, it's your, your partner, but this is our system and it's going to be our system for how many years? So that part is critical. And then what you, you don't know, what you don't know.

Speaker 3:

So from our experience, that was a huge element in scope creep, because we would get into certain functions and like, okay, we're doing this, okay, we're doing this, and then we're doing this. And then when we test it out, it's like, oh crap, no, we can't do this without this process. I'm thinking of when we were doing warehouse picks. We were testing warehouse picks and shipping, and so the standard warehouse pick in Business Central was missing a lot of information that we need, and so, okay, we had to rework that, create a custom warehouse pick. And so I think that discovery phase and, chris, I think, like you've talked about this a lot, a thorough, thorough discovery of what the client or the customer process is and like, like down to the nitty gritties so that you can incorporate that into the scope before actually doing it and then realizing, oh no, we need to do that. So, um, that's something that I would emphasize. Um, like, even the details that you don't think are going to matter, they do end up mattering when you're actually live or testing.

Speaker 3:

And then I think another critical piece is like sponsorship, a sponsor on the client side who keeps things in check. If the sponsor knows this is what we want to implement. It might be a phased approach In phase one. This is what we want to implement. It might be a phased approach in phase one. This is all we need to do, and so anything else is going to be phase two. We're going to get by with whatever we're doing in phase one, but the sponsor on the client side has to enforce that. Um, with the understanding that the business will continue to function. We're going to support, we're going to do whatever we intend to do, and all these other things are just going to be add-ons and perks after the fact. So, yeah, sponsorship, ownership on the client side, and like thorough discovery, I think are three critical elements to mitigate scope creep.

Speaker 1:

I do have a comment, nellie, you mentioned, mentioned about. We're talking about the requirements gathering. You can have the best requirements gathering, but if you don't have the, you don't have the right person yeah to be able to speak up. It's, it's, it's not, it'll be worthless. Because I've been in situations or I've been in implementations where everything was written, everything was well thought of and towards the very end someone comes up and say, actually, that's not what we do. I was like, where have you been, you know?

Speaker 3:

that's change management. It's crazy.

Speaker 3:

That is change management exactly yeah, because, uh, like you said, you can have somebody responsible for the project and the client and has no idea what's happening with each function.

Speaker 3:

Um, they may think this is what we need to get going. Um, so again back to change management. This is why, before you're even talking to a partner about an implementation internally, you need to talk to everybody that you possibly can in each function in that conversation, and then one person is like the documenter of all of that and the communicator, but everybody has to be involved in that internal discovery first, and then you communicate that to your partner and have people from multiple functions in those meetings with your partner, because I'm not going to know what a finance function requirement is, I just don't. And so somebody from finance and accounting needs to be on those calls, someone from warehouse needs to be on those calls, and in our case, it was just me trying to represent everybody. I did an okay job, but I wish I could have brought in other people. I did an okay job, but I wish I could have brought in other people, and I would do that in the future.

Speaker 1:

Absolutely. Yeah, that's. I think that's very, very important to bring in others perspective. Because I mean, Patrick, I don't know if you've got come across this and I think this came across one time in in my experience where gather requirements, we provided the estimate, everything looks good, and you go through the implementation at the very end or not very end, but closer to the to the end, as you're going through the uat, you know they all agreed to maybe use out of the box functionality because it met the requirements, right, all that stuff, uh, towards uat. They come up to you and say this is not what we had expected yeah, yeah, you wanted to look like this.

Speaker 1:

I was like wait, you were okay with the out of the box in the zero hour.

Speaker 4:

Why the change?

Speaker 1:

yes, yes, um, how do you handle that?

Speaker 4:

you know, I think I mean I think everybody is, I don't, you know. I think if you've been in the space and done more than a couple implementations, you've probably run into it because unfortunately it's common. You know, like I'd like to say that it happened one or two times in the last year, but you know it's a pretty common thing and a lot of it has to do with some of the scale of your organization can be a big impact on that. Because you know, to be transparent, not everybody can be part of the implementation, right, and you know, back in the day when I was doing a lot of implementations, my thing was warehousing and manufacturing and unfortunately those guys are usually underrepresented in the implementation groups and unfortunately those guys are usually underrepresented in the implementation groups.

Speaker 4:

And then you know you'll get out there and you're training users on handhelds and they're like, yeah, the manager thinks that that's how I do my job, but let me tell you how I actually do it. It was like, guys, we've been implementing for like four months and I'm just now hearing this while we're doing user acceptance testing, and I got to be honest, like I've got to go back to the product sponsor inside of the implementation team and be like, hey, you need to figure out what is a business need, what is a business requirement and what is our path forward, and then I'll help you figure out what that is, but I can't be the one making the decision as to what's best for your business moving forward, and there there's a. There's a second portion of this which I think is part of OCM, which is user acceptance and utilization after you've been live, and if those people that are out there doing the job all day long don't like the system because they don't feel represented in it, they're never going to adopt it. They're going to revert back to like bad practices or the way I've always done it. God, I hate that, but like the way I've always done it because I know it works right, even though that may not be the way that we need to do this.

Speaker 4:

Going forward for the best path for the business, right, or maybe like there's an effort that they don't have visibility of, but if they don't feel represented in their voice as far as like this is how I do my job isn't represented within the implementation, you'll struggle and you'll end up with OCM. You'll end up with scope creep. You'll end up with changes in the zero hour.

Speaker 2:

And those can be costly financially as well as the implementation. Because I've seen changes come in and I still struggle with when do you introduce changes and how do you determine the changes? Because you mentioned, patrick, what is the business requirement? And then also what is the requirement within the application, because you know a change or a scope creep or a change in scope. I've seen someone want to say something just because they became more comfortable with the application or going through the process, or a requirement came up and a modification was made, or somebody started a process and they said, oh, I found this button, this can do this. Oh, that would be so great if we could do this, which could throw off the entire process that you put together and and sent it back. So how can someone determine the difference between a business requirement and a business requirement within the application?

Speaker 4:

you know from from my perspective as a partner, but I've also been an end user, right like I've the application. You know from my perspective as a partner, but I've also been an end user, right Like I've been a warehouse user, been running around a forklift in a giant warehouse.

Speaker 2:

That must have been awesome, yeah you.

Speaker 4:

You say that it's fun until you're like 100 degrees and in the south you know 100 humidity and yeah so it's fun for an afternoon or a couple hours then maybe yeah, it's fun for the discovery now that I sit in air conditioning all day.

Speaker 4:

Um, the um, the the big part of that is really determining what's mission critical for the business, right, and sometimes, unfortunately, that can't be what's mission critical for the individual. You've got to have as a partner and as an end user and probably more so important as an end user have a clear vision of what do I want to do and this is like such a horrible cliche, but it's true Like what do I want to do in the next five years, right, and then help help your partner understand those goals and why you're making some of those decisions. Obviously, you can't tell them everything, but at least give them some indication so that we can help you through that process. Because, much like you were kind of describing Brad, where you might have a user say oh, I didn't know I could use that button, we may not have known to recommend it because we didn't know that that was a requirement right.

Speaker 4:

Like there's like a really unique, judicious way to say well, if you had told me in the first place, right, but you obviously can't say it that way. But it's the. You know, if we understood these requirements at day one, we might have recommended a different path. And in some cases it's like a blip right, like it's a day of work to change it, and in other times it restructures a lot of the organizational change as well as the system.

Speaker 2:

So, but to take that back, I know, nellie, you probably have a lot to add. I'll pause for a moment, but I get excited about the topic.

Speaker 3:

I do, I'm trying to jot them down. No, no, no, I will pause in a moment.

Speaker 2:

But what you're talking about is similar to my question is there's the business requirement. I may be a business manager, business owner or someone who's driving the future of the business, and then you also have the individuals that are performing the actions daily, that will have requirements based on what they know. So now, how do you in essence then filter? Okay, here is the requirement from the user. How does it align, maybe, with the direction of the business? Because, to me, if you're going to switch to a new ERP system such as Business Central, there's a reason for it. The reason may be you want to get efficiencies, you want operational gains. There's some sort of reason. So, the requirements that a user has, how do they align with the direction of the business and how do you make sure that that comes together? So then, also, when you're going through the implementation, it's not somebody saying, oh, I found this button, it would make my life so much easier and, like you said, it could shift you in a different direction. It's tough.

Speaker 3:

See, this whole implementation thing is tough.

Speaker 2:

Yeah, I'm jumping in. I'm being quiet, I'll mute myself.

Speaker 3:

No, it's fine. I think this is where a phased approach is is important because you can have, okay, this is our ultimate, perfect, ideal vision of the system, incorporating what the users need and everything. And, like you said, pat, like as the customer or the sponsor, you communicate those things to your partner what are all the requirements? But at the same time, you've got to be communicating what we're going to accomplish in a phased approach to your people. So, okay, you're not going to have this functionality for a little while, but we're going to get by with this because we need to keep the business operating, we need to keep shipping orders, whatever it is that we want to do. But this is in the next phase and we're going to do this. And then in the next phase, we're going to add this there has to be like a minimum.

Speaker 3:

I guess a minimum viable product, if you're kind of talking agile like this is going to keep us going and your, your people, need to know that like this isn't the end of it, but we have to do something and then we can talk about something else in phase two. That's frustrating. Frustrating too, because, as a user, there have been things that I've been told are going to be in phase two and I'm like, but no, like we want that now, we need that now, and it's gonna suck, but it's a give and take. But I think communication and conversation with your people from the beginning about what we're gonna do helps that. Just let them know, like, like, this is the plan, this is what we're going to try to do, this is what we want to accomplish, and it's not going to be all done overnight. Um, and I don't typically are doing phased implementations, or is it like start and then we're done?

Speaker 1:

that that depends for yeah you know that really depends because you know a partner would do their. I consider your partner as the, the organization that will, or your partner would be responsible for executing your vision right, because they know the system. But, um, it's really up to you if you want to do phases. I've've been in implementation where I don't want phases. I want everything I need to do to get my business running, so even things that they wanted to add. They don't have now, but they want to add because Business Central has that capability. They want that now.

Speaker 1:

They don't want to have to wait, you know, three months after go live to execute that. They would say, why can't we do that now? It's really a balance. It's never a question of like, why can't a partner do that? It's usually it's like do you have the capacity, you as an end user that's going to live in this application that's going to backbone of your, of your organization? Can you know, um, do you have the capacity to do that and try to change that or bring in a new process?

Speaker 3:

yeah, and another piece too is like the microsoft updates like that come all the time that we tend to like those might solve a problem that we have now that we don't know it's going to be solved. Like, if you kind of wait it out I we've seen that happen like things that we wanted that would have now that we don't know is going to be solved If you kind of wait it out we've seen that happen Things that we wanted that would have been customizations just end up being part of the system. So understanding that the system is continuously evolving and changing helps us as users to know okay, well, this is not necessarily permanent and we might have a solution coming up soon. Let's just kind of wait it out and see what's coming and if that works, then we're good, Then we don't need to customize.

Speaker 4:

To that point, Nellie, I'm going to do a shameless plug akams forward, slash BC ideas If you are not putting your stuff in there.

Speaker 4:

Microsoft is not going to hear about the thing that you want unless your partner is putting it out there for you. And they hear about the thing that you want unless your partner's putting it out there for you and they do look at it and they upvote and they talk about the development plans for it and they'll throw it on the roadmap. Um, but, kind of going back to, I think, your original question, brad, you know the how do you determine, like, how do you address that change? The big thing that I ask my people is like how is this going to impact your ability to either provide goods and services and generate revenue? And if you can still do those core things, let's address refinement at a later date, right, and you know, as long as we can still operate in the premise of can I generate revenue, can I run my business, are my people are going to be OK at the end of every day, and can we refine that at a future date?

Speaker 4:

And then you know not to jump into the phased approach again, but can I potentially push that change into a future phase? But can I get live and be able to run my business day one? And you know we're not trying to quote unquote. Like not every implementation's goal is quote unquote to just get it live as fast as you can. But if you're going to jump into an effort like implementing Business Central or any platform, the goal has got to be continue business operations as quickly as possible, because the implementation is a big interrupt. It's pulling people away from their day-to-day jobs and then get them back to being able to run the business and generating revenue and then worry about refining and making that a little better or easier. Um, assuming that you've introduced this new scope, creep right yeah, the go live.

Speaker 2:

see this, this, the go live. Right. So you go through a project, you plan. I do want to go back to the requirements. I still have this thing hung up in my brain that I can't shake. But to go back to the go live, as you're talking about, with the go live date and preparation for go live and making sure that the business can operate, you know, typically some will say if we can ship products and, you know, apply cash, you know if we can ship product, ship invoices and receive cash, you know we're OK to start and then we can, and you know, bring in some of the other changes and efficiencies. But you have an implementation, you have a go live date planned.

Speaker 2:

Now I've seen some hesitation at times of when do you go live Right, some hesitation at times of when do you go live right Is is what. How do you determine that you're ready to go live and how can you, you know, ensure that the go live is going to be proper? I mean, I'm sure any new change, any new process there's always, you know, change brings up some challenges and I'm not saying that it doesn't work properly. Some people will forget, possibly, how to do a process. But how can you push into that go-live? Because I've seen go-lives stall because someone will say we're not ready, but we're not ready because of something new. It's a matter of, okay, I'm not comfortable and ready to go live because I'm afraid versus it's not ready. It's one of those things that I see often and it's like well, we have to delay it for a week, we have to delay it for a month and I have some questions. I ask for that, but I wanted to hear everybody's thoughts on that.

Speaker 1:

I love what you're saying there, brad, because being afraid and not ready are two different things in my opinion, because you can be ready and you have everything you need to have a successful go-live, but for some reason, they just have this fear of change. Now this change is going to happen. I'm really scared, like, for example, I mean Brad you hike and Nelly you're out in the woods just like me, and Patrick you're in Atlanta. It's a jungle out there. You know, you're prepared, you have all your stuff ready to go, and then, right when you're about to leave, you still have that nervousness, feeling of like I'm not sure if I want to hike this thing.

Speaker 4:

And bear is going to get me.

Speaker 1:

That's what I think Exactly, still have that nervousness, feeling of like I'm I I'm not sure if I want to hike this thing and exactly you can be prepared. You know you can have a bear, mace and stuff like that, but you still have that fear. Um, but preparedness and fear is I like that's two different things and I see that all the time, um in implementations yeah, definitely from a user perspective.

Speaker 3:

Like it's like you're coming up with excuses not to go live because you just like, oh no, no, this has to be done first and it's that's such a critical distinction and if you think, like personally, in personal lives and personal changes, you know this is what you have to do, but you try to come up with reasons not to, because it's a change and it's scary, um, and that just translates directly into workplace changes too. We, or you'll find like people will come up with things at the last minute just because it's so close.

Speaker 1:

We're that close, yeah yeah, it could just be one person that's making that decision too, and then they may be afraid to make the decision for everybody you know, especially if you're the decision maker of go live or no. Go live, oh, I gotta decide this for all the departments. That's a scary feeling.

Speaker 3:

That's, that's fear, yeah you have to find a happy balance between sorry I don't go ahead, go ahead no, just the balance between making a decision and also considering everyone's perspectives. At some point. Someone has to make a decision, you know, otherwise we're stuck in eternal limbo and analysis, paralysis, whatever.

Speaker 4:

So somebody has to make a decision in light of everything at some point well, and to go back to something you said earlier, nelly, this is what we would classify as that organizational, like that sponsor, right? Um, somebody has got to make the decision. I hope he doesn't watch this episode, cause he's going to know who I'm talking about. But I worked with a. I worked with a COO who knew nothing about technology kind of didn't understand all of the nitty gritty of operations, but knew how to drive business initiatives forward. And I remember this is actually right in the middle of lockdown, like we were in the middle of implementation. We were two weeks from go live and then all of a sudden, the country shut down, um, and he rallied the troops, quote unquote, and said it doesn't matter, you know, hell or high water, we're going live. He was actually one of our biggest detractors at the initiation of the project and then, as he got into it and recognized the value add to the business, you know, he said, regardless of what's happening within the world, regardless of what's happened during the course of the implementation, we are going live on this date. And he championed that across the board with his users, to the extent of literally like sitting down individually with everybody when they voiced an opposition to the go live and then championed the process and just the fact that you've got to do it right.

Speaker 4:

Because, you know, we talked a little bit about the fear of, of kind of transitioning Right. I think the best kind of implementation that that fear is transitioned to like the, the heightened anticipation of like doing it right Everybody's a little excited to take that jump, even though they know it's scary, right. The best kind of implementation is when, as a partner, the best kind of implementation is when, as a partner, the best kind of implementation is when your end user is like can we go live on this date, like we're ready? Um, and I, you know, I think, hopefully, chris, you've had at least a couple of those, because those are really gratifying as a partner, where you're like I've done a good job, like I've been a very great champion for the, the system, and my customer feels ready, like because cause it's, it's like having a kid right, going out in the world. You're like okay, you're ready, yeah.

Speaker 1:

Yeah, absolutely, it was very similar. Yeah, it's, it's. It's one of those things where I had a similar situation as from a partner's perspective, we went, you know, a client wanted to go live they're manufacturing, you know, manufacturing, you know, and and it was during covid, so it was very difficult to fly anywhere and be on site went live all remote, not stepping foot, and I was scared. It's like I'm not there to like hold our hands. But we did all virtual and and you know I I worked with somebody on the other end that we were both ready and our mind, our time, it's going to be dedicated to this and it went smooth. And then, like you said, you know, it's like it's an amazing feeling to see them flourish and be able to just run the system and not be, you know, not have to wait because COVID was happening and they weren't sure if they can run this application. No, they're just like let's do it. Chris got our back, we could do this, and then it was amazing and those kind of implementations are fun.

Speaker 2:

It is important to put as part of the implementation, with the fear of it, as you're all talking about. Sometimes the fear is they're just afraid of the new system and I've even come across where requirements that surface. After they start using it and they become comfortable with it because it is new, they realize that they don't need that change any longer. Because I remember working with a, an organization. They're going through implementation, someone's going through, and they said they always would say, well, in the old system we would do this, well, in the old system we would do that, in the old system we would do this.

Speaker 2:

And I I heard that proverbial like five years later you know it's, they're still talking about it and it's just like, well, whatever. But after they started going through the process this was an organization, they went through an acquisition and they had to look at the system that the company that they were acquiring was using. And then I heard that same individual say, well, they have to do it this way, we get to do it this way. You know, it's like the mindset shifted because it all comes back to that fear of change, the fear of doing something new, and then realizing, well, it wasn't so bad looking back at it.

Speaker 2:

But how do you embrace that fear to push someone over the edge? I mean, I've asked the question sometimes where someone said, well, we need to delay a week. And I would ask okay, if we delay a week, what will change from Sunday, the day that you wanted to go live, to the next Sunday? If you're going to have some in-depth training or testing or somebody's going to do everything, then delaying a week may be advantageous because you're going to do something and have some productive results. But if you're just delaying it a week and everyone's going to do their same duty and you can pick the time frame, what do? What's the? You know what's the the rationale for going uh later, other than fear yeah and I wonder too.

Speaker 3:

How much sorry, pat, go ahead oh I was gonna say.

Speaker 4:

I don't know what your guys experience has been, but this is um, this has been my experience previously. Um, if you are willing to delay a go live one time, it is more likely to happen again and again and again. There will always be this continual understanding of oh well, we can just keep delaying, rather than creating some immediacy of no, you need to get live. Like, there needs to be a definition of done right, minimum usable product, go right. But I have seen end users and I've been guilty of it as an end user right, it's the don't let perfect be the enemy of good enough.

Speaker 4:

Right like, um, if you're going to keep delaying and yeah, if you're going to keep delaying, you you will get into the habit of understanding like oh well, I can just introduce new scope creep and as a partner, you know we're here to literally help you through the process. So we're going to say yes to a lot of things. Right, yeah, we'll help you do that. But we've got to also say yeah, but is that in the best interest of the implementation and your team and your budget and your timeline and your sanity right? Like, at some point we have to get that minimum viable product and go live and say do it, and then we'll refine later.

Speaker 3:

I think it could get pretty philosophical, talking about like perfect and what is good enough.

Speaker 3:

But I think it goes back to what you were saying earlier.

Speaker 3:

Like you had that sponsor who just said we're doing it, and I wonder how much the success of an implementation has to do with the charisma and the leadership of that sponsor. It's kind of like, I think, of school, like a teacher can make you love or hate a subject based on the way they present it to you or the way they have you interact with that subject, and I think that might be a critical element in the success of an implementation. Who's leading it on the client end and do people trust that person and what kind of relationships do they have with that leader? If I trust my leader and he tells me this has to get done, then I'm going to trust what he says or she says, because I've established that trust relationship with them. And so if somebody just comes in and it's very top-down and we're doing this, like it or not, and you don't have that rapport with your team, it's going to be hard to have them embrace it. So I think that's a critical piece.

Speaker 1:

And that you know it depends on who's there to comment on that. Like, uh, your spot, you know, the sponsorship is very important, you know, you know. But, like overcoming that can sometimes be a simple conversation of like, hey, you got me, I got your back, you got my back, say, chris, chris will get our back, that's, we could do this, you're prepared, you're UAT, all pass and everything like that.

Speaker 3:

It's just a matter of like, I'll be there for you and you'll be there for me and you just go live, just do it together and we're going to stumble and it's not going to be perfect and we're going to fail and we're going to fall flat on our face sometimes, but we're going to pick each other up and we're going to continue like understand that it's not going to be smooth sailing and with that what I like in some sense.

Speaker 2:

I mean, obviously there are issues that you can say fail and it prevents a go live. I like patrick's point. Pat's point of you'll always find something. You're training yourselves and your organization that if we find one more thing we can push it off. And we'll always push it off because I may not feel comfortable with it and the approach of pushing that product in. If you're going through UAT and you're fixing requirements along the way or you're changing scope along the way, with always one more, always one more, you're never in essence done, whereas if you go live and you find some things that you would like to change, you kind of do it once and you're done, because now it's in there and it's fixed for lack of better terms and you don't have to go back to it and individually start using that process.

Speaker 4:

One quick one before that. I do want to make a clear delineation, though Process improvement has to continually be a portion of your business, regardless of if you're a partner, a customer, whatever. Right, as a business owner and as a business manager, right, I am continually trying to improve the way that I do business so that I can do it better, faster, less expensive, attract better talent, right, all of these things. So, please, yeah. So I want to make sure that you know anybody watching understands like you need to continually try to refine your business. Just don't delay a go live for that definition of perfect White belt for life is what I would say.

Speaker 1:

But a really quick comment on that on delaying the only time as an end user where I had to delay from an end user side is when you come in. I came in from like I think they were like a month out before they were going live and I got hired in and they wanted me to run this whole thing up to go live and I was like I don't even know what's going on. I said give me, you have a date of, let's say I think it was like September 1st. Let's wait until October 1st. I just need to understand. And then I went around to the other departments like, are you good? Are you good, you can do it. And then that was it. Just that 30 days was enough. And then it went live as smoothly as you can get. But that's the only time I've had to push back from an end user side.

Speaker 2:

With something that you said, Pat and Nelly you had mentioned it too with continuous improvement and with the application changes and refinement. And then also, just to be clear, it's okay, now we went live, we're running live, the application's live. How do you continue to improve and get that operational efficiency that you talked about?

Speaker 4:

You know from, yeah, from my end. You know, a big part of that is a relationship with my customers, right? Like you know, I was talking a little bit earlier about, like, getting your kid out the door. You know you get them, you get them out there in the world and you're excited to see them succeed. But at the same time, I have that same similar relationship with my customers ongoing, right, because it's not like the second that you move out of the house that your relationship with your parents ends. Right, I continually communicate with my clients and let them know, like hey, I don't know if you guys are watching this, but this is a cool article, right, or as much as even just. Hey, subscribe to the dynamics podcast and, um, listen to what brad and chris are talking about this week, right?

Speaker 2:

like we always want to say that to everybody, just to let you know shameless plug, right, the uh, but the?

Speaker 4:

you know, hey, brad and chris have something really cool to talk about this week. You should check it out. Right, or the? Hey, have you read this article? Or hey, the wave release is about to come out in a month. Let's talk through how that might change your implementation or your business, or even maybe like what you foresee as like a projection of your business change in the next six months. Right, um, you know.

Speaker 4:

Shameless plug for community summit right, like, as partners, we all go. Right, we have to go. It's a part of our sales cycle. It's a part of our relationship building and training and new education. But, as end users, something like that for having continual exposure to the product and releases and updates and education is super important because it fosters this idea of I'm in a SaaS environment, right, like, I'm in a continually evolving ecosystem of technology, process change and people that can drive my business initiatives forward and all I have is a subscription feed to my platform. Right, you know, it's that idea of like continual change and it's part of being in this community. Right, like, it's an ecosystem. Right, it's a living, breathing organism. That really is.

Speaker 4:

You know, it's defined a different roles between partners, publishers, isvs and end users, and we're all part of this. We have to communicate and talk and we have to make sure that everybody's aware of the things that are coming out. Um, and then the relationship partner to customer. We have got to be making sure that our customers understand what's going to happen, how this might change your business scope. Um, hey, that isv that you're using there's a new product release coming out for it or hey, have you checked out subscription and recurring billing, because this is going to be really cool in october, right? Um, like, I know your business as a partner and I think this might have a value impact to you. Let's check it out. Do you want to do like an hour of training when it comes out, right? Um, or is there a cool podcast or article? Or is there marketing material from microsoft or other publishers, for that matter, that are going to give you some insights that might reshape what you might want to do as a business going forward?

Speaker 3:

I had this conversation just a couple of days ago with my CIO just on this continuous improvement, continuous learning. It's no accident that I love the product, that I love Business Central, because I've been exposed to these things. I go to these conferences and you get that hype and you get that excitement and I'm always like if I'm the only one there, I'm the only one that's going to feel that and we really need to get more people at these events, either locally it doesn't have to be like the annual things, because that's where you see what's possible. We're trying to get our like our dev team to engage with Power Platform. They haven't seen it. They're boxed in, they do their internal apps and that's just like what they do all day. They don't know what's out there, so let's get them out there so that they see what's there and then they get excited about it.

Speaker 3:

Another thing that we did for continuous improvement, and that's an initiative I led at my company. Initiative I led at my company, so Canada was one of the instances of Business Central online and then we have numerous others globally, and so I set up kind of like a center of excellence where all of us get together and we just talk about, like what challenges are we facing? What have we learned? Here's like, like you said, like I found this link, I found this video, share it with the group, and so we are responsible for each other's learning and also for continuing to be excited about the system, because it is always changing. But if you don't expose yourself to that, then you're not going to know what's possible. And that's contagious contagious like one person gets excited. You pass that excitement on and that helps to sustain post.

Speaker 2:

Go live the commitment to making the system work and enhancing the implementation with some new features or functionality or it's not even the new features of fun I'm new to the implementation, maybe not necessarily new to the product can still help drive. What the goal would be would to be able to be as efficient as possible with an implementation or with your business, right? Is that the number one goal? Like, how would you say like, the number one goal of a business is Any business with an application. Is it to become as efficient as possible? Is it to conduct business? What would you say would be the number one goal of a business with an ERP implementation?

Speaker 3:

I would say something really maybe not typical, but that your people are happy using it, that day in and day out they're spending eight to 10 hours in this space looking at this screen. I'd want my people just satisfied with it and happy with it. That would be my number one goal. That's maybe not a typical business goal but if they're happy, your business is going to see the effects of that. But yeah, I guess efficiency and cost savings and productivity might be like your typical answers.

Speaker 2:

No, I like that. I like the people are important. I mean people in an organization are important. It's they're the ones that are going to drive the business. I like the people are important. I mean people in an organization are important. It's they're the ones that are going to drive the business. I mean there are some things you can automate. There are some things you can streamline, but still, ultimately, where we are, there's usually people involved somewhere along the process to make sure that it's being done properly.

Speaker 3:

So until the sales order agent does everything and the purchase order agent does everything, and then we don't need anybody. I'm kidding, that's not what's gonna happen.

Speaker 2:

That would be the quote in the clip we use. Is nelly, you know that one minute saying until the sales order and the purchase order agent do everything you don't have to care about the people oh, yeah, we're going to replace them all with the co-pilot anyway.

Speaker 4:

Right, please edit that out. No, um, the? Uh, you know one of the things that I I heard a couple years ago. That was really an interesting thing, because the first thing I always ask people when they come to the table looking at bc is why are we having this conversation? Right, like, what is the catalyst for change? Um, yep and um, one of the most interesting things I heard and I've heard this a couple times recently was we're using this as a platform for growth.

Speaker 4:

Right, like, we've hit a threshold with our current technology stack and we need to be able to advance, innovate and develop either better processes, automate, broader outreach. Right, like, maybe this implementation is a subset of a larger technology goal. Like, hey, we're going to get into the e-commerce space. Like, we want a broader market. It doesn't always have to be a business decision, because I think a lot of the times, this is becomes more of an emotional thing for a lot of people.

Speaker 4:

Um, but, uh, you've you really got to look at the why? Right, why are we having this conversation? Like, why are you moving the product forward? And I don't think it's the same for any two companies because, again, people and processes and product are different. Um, but one of the more interesting ones I've heard recently was that, you know, this catalyst for growth and change right, we're going to leverage newer technology. You know, one of the things that I know Chris and Brad and I have talked about a lot is some people on some legacy platforms that have kind of just regardless of whatever's happening in the industry, like they've potentially hit like a glass ceiling of we can't grow anymore because the system won't let us Right. May or may not be true, but we I've heard that a lot in the last six months to a year and now we want to use this, this implementation, to grow the business Right.

Speaker 1:

Yeah, and it's interesting because people don't realize in, in human history, history, change is what drives growth and it could be, if you look at, if you look at human history in itself, that it requires change for the next, you know, for the next big thing. In a sense, you know the, the, the growth, whether that's for you individually, even for, like you know I think I shared this story before like you know, back in in the village right like, oh, perfect example, if you watch moana, you know I have kids so there's it's.

Speaker 1:

it's a great movie and it required them to change their mindset to go and explore beyond the island that they're on. If they didn't do that, they would have been still the same. So you know, for Moana to go out and explore the ocean and see what's out there, it created a change in their tribe to grow and do great things, and so that's how I look at it and why change is important. You know I had to tell them, I told my kids that why change is important. Watch Moana.

Speaker 3:

Yeah, I always, I always say you can go through change or you can grow through change. That's a choice. That's an individual choice and maybe that's a bit dismissive to say that, because sometimes there are external factors that prevent people from fully embracing but it is an individual and that's that's why I think we need to pay attention to the individual, because they have to make a choice. Am I going to try to learn something? Even if the change sucks and even if it's a terrible idea? I can learn something from it, or I just don't. And if you come at change from that perspective of learning and growth, even the worst of situations can be an opportunity growth. But even like the worst of situations can be an opportunity. Um, and that's something I think we can model as leaders and organizations. Uh, you model that behavior and hopefully, people, people are inspired I'm inspired, I'm good, I'm what change do you want to make, brad?

Speaker 2:

it changed where and to my life, to the planet, to business central I don't know something I mean, I well, that's if you want to get philosophical, I'm not going to get philosophical this is going to be a therapy session now yeah, you know it turns out to talking about implementations, change management, and you know the importance of the, the human factor of implementation, to a therapy session.

Speaker 2:

We'll go through everybody's turn of talking about the individual changes. Now implementations to me, as I had mentioned, I'm happy that we're talking about this topic. I'd like to see more of the topic of how to go through an implementation, as I had mentioned. I see so much content on this is the new feature, this is the new functionality. But to be able to see how you go through an implementation and adapt or adopt to the changes, which is important, which even brings me to the question you had mentioned that there was a requirement. I always used to tell somebody wait long enough and the requirement goes away, because they find a way to work within the application and not have to have the carrying cost of the modification. But now what about the cases where, as the application does evolve and more functionality gets added if you had a modification or an extension that was made and then the feature is now part of the application what is an approach for that? Do you keep the existing extension? Do you move it to use the base functionality? You know how, can you?

Speaker 2:

I'm so curious about this the tune-up of the tune-up of an application. I call it right, it's, it's a business central implementation tune up as you continually move forward. Just everyone's thoughts on that. That's one of the things I think about as I see all this functionality still there. All this functionality is there now and you're still using your custom one.

Speaker 4:

Yeah, yeah, this has actually happened to us recently, in the last release. I think it's for our partner, it's a time for celebration because it means that the ecosystem is evolving around customer needs, right, like the reason we build customizations and extensions in the space is to facilitate requests from end users. And when we see that added to the base application, that means, one, microsoft is innovating around the demand of the client base, innovating around the demand of the client base. And two, it means you know the base product, which is continually upgraded and supported, is going to meet the needs of my customers forever, right, versus having to maintain biannual updates and then hot fixes that might deprecate a field or change a procedure. Annual updates and then hot fixes that might deprecate a field or change a procedure. One, it minimizes our maintenance requirements and two, it means that you know the quote-unquote. The community is listening, right, and I think it's a case for celebration. But it might be a unique perspective of not doing the code, but I like it when it happens.

Speaker 3:

So I have a question for all of you because this is something I'm being a bit selfish not pertinent to us. Our biggest location, the US location, is on nav on-prem and it's been through like 10 years of customizations, like customized to no end, and we've just kind of, in anticipating for the transition, the re-implementation to Business Central Online, we kind of want to put an approval process for any modifications, any customizations to NAV right now and we're trying to figure out, like what should be considered to be a critical customization that can't wait and that we should approve, and what should we try to live without, because we don't want to kind of accumulate sunk costs and tech debt as we go on to anticipate going on to Business Central Online. Like, how do you determine what is a critical customization when you know you're going to change?

Speaker 4:

I'm having this conversation. I had this conversation this morning before this call. Um perfect. I have a client in the similar situation.

Speaker 4:

Um yeah, the first thing you got to do is look at the version of nav that you're on, um 2018 okay, and then you need to see it and try to keep this high level and not hyper technical. But you need to look if you have um extension based modifications right, because I feel like there's probably a lot of people out there that are going through the same conversation because those extension based modifications can be lifted in the cloud a little more easily. If they're not, then I think you really have to start taking a look at the thing that I mentioned earlier, which is what is limiting us from being able to generate revenue. Right, and is it a refinement or is it something that is maybe even no longer pertinent to the business? Right, because the evolution of your business you know let's assume you went live in 2019, right On 2018 or something like that Like we all kind of went through a pretty dramatic shift over the last five years.

Speaker 4:

You know either technology, commerce, just our day-to-day lives. Are those requirements still the requirements, right? So do you even still need that modification? And if you do, are the requirements of the modification the same as they were when they were generated?

Speaker 3:

I can't tell you how many support tickets or requests I've submitted that I have forgotten about because they just never got to them and I forgot that I need them, like you said it earlier, so maybe I didn't really that's that's.

Speaker 2:

I mean, I think if you're dealing with an old version and your intention is to move to the current release with the rest of the organization I go back to what Patrick's approach would be is how critical is it to the business Oftentimes doing every extension or every modification it goes back to with the training You're training individuals that you don't have to come up with using the system and becoming efficient with the system and learning how to use the system. We can just make a quick change and now I get what I want, without respect to how does it impact everybody else in the system, because on top of that, I'll go back to the question you had before. But on top of that, any modification or extension that you make does have the potential for downstream or upstream impact. So we may save five minutes for one person and I've seen this, but what it ended up doing on the downstream effect was adding hours of work for others because of that slight process change. So it's important to keep it around.

Speaker 2:

But also with if you're looking to go from an old system to a new system, well, how critical is it to allow you to become efficient and to grow, because you're ultimately going to go into a new system anyway, right?

Speaker 2:

If you're going to migrate a newer version that has different features and functionality, anything that you're incorporating and bringing you now, how is that going to change? Going forward, and anything that you're doing could. Potentially, any time that you spend enhancing and modifying, if you know you need to move, any time you spend modifying, enhancing the existing version of the application, is time that you're not spending moving to the newer version, because all this testing, all this training, all this requirements gathering is time that you could spend doing that for your migration to the new system, to keep everybody moving forward. So to me, there's a balance of start with a no and then really analyze why this person needs this request. I think you need to have a checks and balance on all of the modification requests to an implementation because of all the things that I had just mentioned, it's it benefits one, but the time spent on it, does it benefit everyone else the same, or does it cause problems for others as well?

Speaker 3:

I'm calling it the no more nav mods project. That's it, we're done. No more.

Speaker 4:

Hashtag base application. Um, oh, you know the, the other part of that too. Um, going back to what you're talking about, brad, it's not just the effort to do the migration, you're also setting yourself up. Anytime you make a modification to the base application, you are instantly citing yourself for the potential of long-term cost to maintain that modification. Anytime you make a change to what's been published by Microsoft, you are potentially looking to have to maintain that through perpetuity, right? Because you know, in theory, bc is the last ERP anybody needs. But are you going to have to pay I don't know a couple thousand dollars every six months because Microsoft changed a field? Or maybe the modification you did has, like, a really big dependency on something? You definitely got to look at the long-term implications of making those changes too. It's not just the, you know. Am I saving somebody five minutes or even an hour? It's the. What might this cost the business over the course of five to 10 years to maintain it, right?

Speaker 1:

Yeah, it's like maintenance costs. Right, it is Just like back in the nav days you pay what? 16, 18%. Back in the nav days, you pay what? 16%, 18%.

Speaker 2:

There is always a carrying cost to a modification and that technical debt that you carry you have to incorporate in the process-wise. I mean I like to see as few modifications as possible. Again, and I don't confuse personalizations with modifications I mean, fortunately, within Business Central you do have the opportunity to make personalizations. Personalizations to me are what I favor, because you can change the appearance of a lot of pages, as you can say, and even change some of the processes, all through personalization. But that personalization stays with the application, it's not an extension.

Speaker 2:

The only thing I will say that I have seen with some personalizations, as new features and functions come out. You just have to be aware that your personalizations may limit accessibility to those. But if somebody is keeping up with it and seeing how some you know at least, as as Pat's point was you know, keep be aware of what's changing and then see how you may be able to utilize some of those changes to become efficient within your implementation. I could talk about implementations for days in the philosophy behind it, but with that I have to thank you both for your time today. I always enjoy speaking with the both of you and now speaking with the both of you together we'd have to see if we can get you both back on again to talk about some other implementation challenges.

Speaker 1:

This is a continuous topic. Continuous topic it is, it is as you go through the implementations, as you go through experiences with implementations.

Speaker 2:

I think it's important to talk about implementations. Like I said, it's not all about the features and the functionality, it's about how do we implement it. How do you go through and implement it. It's not something that you can just turn on and click a button at this point. I'm hoping one day you can just say click, set it up for me this point.

Speaker 1:

I'm hoping one day you can just say click, set it up for me. Uh, yeah, because most, most of the issues that you deal with implementations you can minimize that risk or even minimize entirely, based on just preparation and talking about these, you know, on podcasts like this, um, because it just prevents it from from happening.

Speaker 2:

So so, that again, Can I?

Speaker 3:

ask you to do an episode on the best implementation and the worst implementation.

Speaker 4:

That'd be fun to see that might be contentious.

Speaker 1:

So much to choose? Yeah, just kidding.

Speaker 2:

We'll have to do a survey on that one.

Speaker 4:

I'd like to see.

Speaker 4:

I could tell you some of the things that are consistently a problem which I think we talked about a lot today.

Speaker 4:

But I'll tell you the very best thing an end user could do when they're looking at this, and it's the take an inward look at your business and figure out what you want to do Right, and then let the system help you do that. Don't always try to define like I want to be able to do this in the system. Always try to define like I want to be able to do this in the system. Say, begin the conversation with I want to be able to do this in my business or my day-to-day life, and then work with a partner to be able to define what that might look like in a system moving forward. Um, because if you start from the application, you might pigeonhole yourself in it because I'm gonna keep harping on this you know to the day I retire, but you don't know what you don't know right. The partner's job is to know the ERP and processes and have experience doing this Like communicate your business need and then let your partner help you understand what the future roadmap might be in the system.

Speaker 2:

I like that. Well, I like that. That's very well put and I appreciate that, pat, but not but. But in addition to that, you don't know what you don't know. That, pat, but not but. But in addition to that, you don't know what you don't know. But also what you know can also be a poison for you too, because you, you know, because you think you know something, or you know something, you're not sometimes as open to look at new things or looking alternative ways to gain some of that efficiency. So you don't know what you don't know. It's kind of just as an add-on to that right, because it is true, you don't know what you don't know, but if you limit yourself based on what you know, you don't know what you don't know. If you follow what I mean, you're going to limit yourself because you're not going to want to know what you don't know.

Speaker 2:

That came out poorly, but I think everyone gets the point of what I'm trying to say. Again, thank you both for your time. I hope that we can schedule to have a follow-up to this to talk about some of the key points and implementations as everyone progresses through. But as we conclude with this, pat, would you mind telling everyone how they can get in contact. Jeez, I'm all tongue-tied this morning. Pat, would you mind telling everyone how they can get in contact Jeez, I'm all tongue-tied this morning how everyone can get in contact with you to learn about all the other great things that you're doing if they have any questions about implementations or need assistance with implementations.

Speaker 4:

Yeah, I'm happy to speak to anybody around the space, either from services or just to have a conversation around the product. You can reach me at Patrick P-A-T-R-I-C-K. Dot Johnson, j-o-h-n-s-o-n. At L as in Lima, m as in Mike, b as in Bravo, c as in Charliecom, happy to have a conversation around that. I'm really active on LinkedIn. Feel free to reach out and connect to me there, happy to have any kind of conversation or just, you know, bombard you with a bunch of information around BC. Other than that, you know you can find me at any of the conferences and big, bald guy floating around.

Speaker 2:

And I appreciate all that you share as well too and bumping into you another bald guy at all the conferences. Nellie, how about yourself? How could anyone find you to learn some of the great things that you do and share about change management, as well as everything else within Business Central Implementations?

Speaker 3:

Yeah, linkedin, nellie, it's your friend, find me there. I'm there like every day, except the weekends, sometimes the weekends.

Speaker 2:

So you have LinkedIn hours Typically.

Speaker 1:

I'm sharing things you have LinkedIn office hours I'll be in the weekends open weekends 10 to 6.

Speaker 3:

Weekends are for baking, so you'll find me on LinkedIn doing pizza and stuff on the weekends, but otherwise I'm talking about change management almost every single day, because implementations are everything to do with the people, and so I try to keep that forefront in everything that I'm doing. And I'm so glad I got to talk to you, patrick, today, because I enjoy and I learn a lot from seeing how things play out from the partner perspective and from both of you, chris and Brad. So thank you so much. Thank you and thank you both again for your time.

Speaker 2:

Time is truly the currency of life. Once you spend it, you can't get it back. I'm a firm believer of that and it's how I live, and I appreciate the time that anyone spends with us, because it is time that you're not doing something else. So thank you again. I look forward to talking with both of you soon. Ciao, ciao. Thank you, chris, for your time for another episode of In the Dynamics Corner Chair, and thank you to our guests for participating.

Speaker 1:

Thank you, brad, for your time. It is a wonderful episode of Dynamics Corner Chair. I would also like to thank our guests for joining us. Thank you for all of our listeners tuning in as well. You can find Brad at developerlifecom, that is D-V-L-P-R-L-I-F-Ecom, and you can interact with them via Twitter D-V-L-P-R-L-I-F-E. You can also find me at matalinoio, m-a-t-a-l-i-n-o dot I-O, and my Twitter handle is matalino16. And you can see those links down below in the show notes. Again, thank you everyone. Thank you and take care.

People on this episode

Head Shot

Kris

Host
Contributor

Brad

Co-host