Dynamics Corner
About Dynamics Corner Podcast "Unraveling the World of Microsoft Dynamics 365 and Beyond" Welcome to the Dynamics Corner Podcast, where we explore the fascinating world of Microsoft Dynamics 365 Business Central and related technologies. Co-hosted by industry veterans Kris Ruyeras and Brad Prendergast, this engaging podcast keeps you updated on the latest trends, innovations, and best practices in the Microsoft Dynamics 365 ecosystem. We dive deep into various topics in each episode, including Microsoft Dynamics 365 Business Central, Power Platform, Azure, and more. Our conversations aim to provide valuable insights, practical tips, and expert advice to help users of businesses of all sizes unlock their full potential through the power of technology. The podcast features in-depth discussions, interviews with thought leaders, real-world case studies, and helpful tips and tricks, providing a unique blend of perspectives and experiences. Join us on this exciting journey as we uncover the secrets to digital transformation, operational efficiency, and seamless system integration with Microsoft Dynamics 365 and beyond. Whether you're a business owner, IT professional, consultant, or just curious about the Microsoft Dynamics 365 world, the Dynamics Corner Podcast is the perfect platform to stay informed and inspired.
Dynamics Corner
Episode 339: In the Dynamics Corner Chair: The Importance of Understanding the Why Behind the Implementation
What does it take to scope an ERP implementation? How long does it take to implement an ERP solution? In this episode, Patrick Johnson shares valuable insights and tips for successful Microsoft Dynamics 365 Business Central implementations in this conversation. The conversation revolves around implementing Microsoft Dynamics 365 Business Central and the factors to consider when scoping out an implementation project. The main themes include:
- The importance of planning and communication.
- The challenges of user adoption.
- The need to prioritize critical business operations.
The conversation also touches on the impact of technology shifts, the role of data cleanliness, and the complexity factors that affect the cost and duration of an implementation.
Connect with Patrick on LinkedIn (https://www.linkedin.com/in/patrick-johnson-3091b852/)
#MSDyn365BC #BusinessCentral #BC #DynamicsCorner
Follow Kris and Brad for more content:
https://matalino.io/bio
https://bprendergast.bio.link/
Welcome everyone to another episode of Dynamics Corner, the podcast where we dive deep into all things Microsoft Dynamics. Whether you're a seasoned expert or just starting your journey into the world of Dynamics 365. This is your place to get insights, learn new tricks and why preparation is crucial before starting Business Central Implementation. I'm your co-host, chris.
Speaker 2:And this is Brad. This episode was recorded on September 5th 2024. Chris, chris, chris, you know, preparation it's important. Oftentimes we have a conversation about a lot of technical aspects of Business Central from the architecture, from development, from reporting, various different areas. Today, we had the opportunity to talk about something that's also important and that's implementing Business Central. With us today, we had the opportunity to speak with Patrick Johnson of LMBC. We don't have a fancy clicker, so we just clap hands and say take two, there you go. Do you know what I forgot about too, chris? I forgot that we had a soundboard.
Speaker 1:Yeah, maybe we start using that in the future. Maybe I'll bring it back.
Speaker 2:Maybe I'll bring it back and see, but it's less distracting without it because I don't play with it as much. Patrick, how are you doing this evening?
Speaker 3:Doing. All right, how are you guys doing?
Speaker 2:Doing well, doing well, coming up towards the end of the week, uh conference season conference season's coming in days of knowledge next week. Yeah, yes, yes, days of knowledge in atlanta. Then we'll be heading to community summit in san antonio. I don't know why they call it conference season, because I think there's only two of them doing it.
Speaker 1:I'm not going to, yeah there's some conferences in between, usually around towards the end of summer, fall, and then you got spring for next year.
Speaker 2:Yes, spring with directions, Doug, bc, tech Days, the whole Dynamic Minds, the whole slew of them. I think the spring is conference season because either that or I just don't pay them. I think the spring is conference season because either that.
Speaker 3:I just don't pay attention. I think we just have two every year. I think summer is just the get stuff done part of the year, and then spring and fall are, you know, travel and speak and meet with everybody and see everybody, and then you know you have essentially five months to get stuff done, with no conferences.
Speaker 2:Ah, five months, is that what it is?
Speaker 3:Something like that.
Speaker 1:We just work for five months a year. No, it's just when that 60-hour commitment doesn't have speaking commitments associated with it.
Speaker 3:right? Yeah, for sure, I'm just teasing.
Speaker 1:Well, there's webinars there's everything.
Speaker 2:But I have a lot of things I wanted to talk to you about this evening. I've been looking forward to the conversation, to get your take on a number of points for the topic that we've chosen. Before we jump into it, though, would you tell everyone a little bit about yourself?
Speaker 3:Yeah, so my name is Patrick Johnson. I am the Business Central Practice Manager at LBMC Technologies in Nashville, tennessee. I'm based out of Atlanta, georgia, been in the space for about 21 years, been an end user developer, project manager, obviously, consultant and now running a practice at LBMC, specialized mostly in manufacturing and distribution myself. But I have a pretty heavy background in finance as well, so I don't know if that qualifies as me to be expert in anything, but I can at least talk about everything a little bit.
Speaker 2:Well, you've been in the space for 21 years. If you've been in the space for 21 years. You come from the days where you had to do everything. I didn't know that you were a developer. Oh yeah, chris was a developer too. You come from the days where you had to do everything. I didn't know that you were a developer.
Speaker 1:Oh yeah, Chris was a developer too, you know? Oh gosh, yeah, I gave that up. Yeah, same right, I gave that up, man, there's too much things to do, you know. But you know, Patrick, it sounds better when you say you've been doing it for over two decades, Right?
Speaker 2:Early 2000s early 2000s, big old nav 3.0 days back in the day, wow, wow, nav 3.0. I remember the day well. Um and practice manager of lbm, lbmc say I have a tough time. It's the age, chris, I'm telling you I'm having a tough time getting together.
Speaker 2:I read an article and you know how, when you read things, I'm starting to get my aarp stuff in the mail and then and then I was online the other day and this was complete, because I don't look any of this information up, nor have I read or talked with anybody about anything of this topic recently. But I started seeing ads for like the top five words that people mispronounce when they have dementia. You know when? What are the early signs of dementia, and it's it. It just got me thinking. I said, wow, am I really, you know, getting to the age? I know it can happen at any age, but is this? Is my computer trying?
Speaker 1:to tell me something. You said mispronunciation of certain words. I mean you're Northeastern, so that's every word, every other word at least right.
Speaker 2:It depends on who you're talking with.
Speaker 2:Other Northeasterners will argue that we say things properly and the rest of the country doesn't, but Patrick, working over there in the space for over two decades, as Chris had mentioned to us one of the things, and you're working with them as a practice manager over there.
Speaker 2:One of the things working with the BC implementations is, you know, the BC product is taking off. I think a couple months ago or a month or so ago, microsoft published that there were over 40,000 implementations or users, I forget exactly the verbiage of it A lot, a lot of implementations at Business Central and it's still growing. We often have a lot of conversations about the technical aspect of an implementation, the features, the functionality, development, extensions, performance, a lot of things like that. Another topic that I think is important, that I'd like to start seeing some more attention paid to or topics on, is this whole implementation plan or implementation projects. It's somebody may sign up for the application, they have a partner and they start working through this process and from both sides, what can someone expect as they go through this journey of implementing Business Central and how do they ensure that they do it properly?
Speaker 3:Yeah, you know that's kind of a loaded question because there are a lot of factors to it. Um, you know a lot of it kind of has to do with their maturity in the erp space. Um, you know some of that speaks to what erp are you coming to business central from? Um you know we see a lot of people, um, particularly recently, coming from great plains and solomon. Um see a lot of QBO migrations to BC and each one of them kind of has its own little unique thing about it. But I think you know the thing that I see that's common across all of these implementations is process and people.
Speaker 3:Right Like you can have some huge changes in your organization when you look at some of the feature sets that BC kind of just has out of the box. A lot of these people are coming from either like, very constrained ERP spaces or very module-based ERPs where BC is more of a hey, you get a full-scale ERP around your business and it's more about shaping your business around what you can do in BC. One of the things we find a lot is people only use a portion of the ERP and it's because there's such a huge change curve and it's just because you have all of these features and assets at your fingertips. Not to mention you have your biannual upgrades and updates from Microsoft, with Wave 1 and Wave 2 falling in the spring and the fall fingertips. Not to mention you have your biannual upgrades and updates from Microsoft, with wave one and wave two falling in the spring and the fall, and I think it's that change curve of moving to the SaaS that is a common thing that a lot of these people are seeing is.
Speaker 3:It's just a huge shift. One of the other things I think is maybe no longer having direct access to SQL databases is kind of a big thing. That we talk about a lot Doesn't mean that you know they necessarily can't get to their data anymore. It's just a little different, right. Not a lot of people doing select all from table where statements. Right, we're talking like APIs, web services, you know, xml ports to be able to push data in and out of the system, and I mean this all kind of speaks to the modernization of ERP in the SaaS environment in the BC space.
Speaker 2:So it is. I mean you mentioned it's sometimes a change adoption to moving to a new ERP application. In the case of Business Central in particular, you're referencing Business Central Online. With Business Central on-premises we can have another discussion. But as they're going through an implementation, I'm more looking to maybe talk about project scoping, whether it's from the partner point of view, from the customer point of view, to kind of to get an understanding of the journey that they're going to go through during the implementation.
Speaker 2:It completely understood that not one size fits all when it comes to ERP implementation. I think you mentioned it and it's a valid point that the business center application encompasses an entire business support with all the different areas and modules, and so it can support many different types of businesses as well, and not every business will use every single feature, nor will they use each feature in the same manner. But in essence, if someone's going through the journey from the partner's point of view, a partner will have to work with the customer to come up with an implementation plan to scope out the project, and then the customer will have to go through that exercise with a partner. And how should one approach that? What should one expect and how does one come up with a project scope or an implementation plan?
Speaker 3:Yeah, you know, from our perspective on the partner side, we're honestly really concerned about what your pain points are today and being able to resolve those, or at least look forward to how we could resolve those in the ERP. So, coming to the table with the discussion before you ever even like make the decision around an ERP with the hey, we would really like to do this better. Make the decision around an ERP with the hey, we would really like to do this better. One of the other things that we see a lot are people who say something like we really want to do this kind of a big leap within our technology stack, right. Like we want to go completely paperless, right. So coming to the table with those kind of understandings and communicating effectively with the partner is really helpful so that we can help scope that around the platform, right.
Speaker 3:Because I don't think going into the implementation just saying like, oh yeah, we're gonna do sales and we're gonna do purchasing and procurement and oh yeah, you need mrp coming to the table and saying things more like hey, we want to streamline our sales process so that it either has less steps or that our sales team has better visibility across the organization, um, or maybe, like your closed process is really complicated and you have issues maybe getting your books closed at the end of each month.
Speaker 3:Okay, well, explain the things that are painful for you today and maybe how you would like to do it moving forward. Maybe don't have it all vetted out and figured out, but at least be able to communicate those things so that the partner has things that they could help you do within the application or even maybe in some of the tertiary things, like the ISV network, custom development, and build out that scope before you ever hit the ground running, because that investment and understanding what you want to do moving forward will pay dividends so that you're not constantly having change requests and, like you, just have a moving target as you implement. But that initial planning to help build the scope is really helpful.
Speaker 1:Yeah, I think you hit a very good key point there. A lot of planning needs to happen, you know, before you even you know break ground in Business Central. A lot of people don't. I feel like a lot of users that starts their journey in Business Central, they tend to forget some of that planning and it typically hits them right in the middle of implementation or right even closer when you start doing user acceptance testing. From your perspective, patrick, being in the space for about two decades or over two decades, I guess you mentioned about user adoption. I wanted to hear your experience Maybe you may have some statistics behind it where a client that you have taken to Business Central they came from a different ERP system, not necessarily Nav.
Speaker 1:I find people coming from Nav to Business Central and it's a little different ERP system, not necessarily NAV. I find people coming from NAV to Business Central and it's a little bit easier in terms of adoption. But what about the other ones that did not come from NAV or GP? How was that experience for you? Is it easier for them to adopt because they're coming to something new, so they don't have bad habits, or is it more difficult?
Speaker 3:Again, every scenario is going to be different, right, because every client environment and all the people are going to be different. But I would say I've definitely seen people struggle a little bit with the amount of technology and automation and tool sets that you get when you move from something that maybe is more of a bookkeeping tool, like quickbooks online, to business central, and they've struggled a little bit with that technology shift of all of a sudden oh well, I need to put a purchase, like a formalized purchase order, in right, or if I want to do a drop ship, right like now. The system has a process and tools built around that that maybe previously they did, maybe via email or on paper, or maybe it was like a knowledge silo where it's the you know, I don't know brad knows how to do it. Just go ask him right. And now all of a sudden, that's very systematic and the platform actually enforces rules around it.
Speaker 3:Um, you know, I I would say to your point yeah, a lot, of, a lot of our microsoft-centric erps you know, some of the legacy ones on prem are going to have an easier time because you have, like, common nomenclature, right, sales order is a sales order, purchase order is a purchase order. Some of your processes are almost going to be a one-to-one right, because BC is the culmination of Microsoft's experience over the last, you know, 30-something years in the ERP space, so most of the things are going to feel familiar. The interface, though, seems to be a little bit of a conversation every time we move somebody off of an on-prem or maybe an older ERP. The interface is very modern in comparison to, maybe, nav 3.0, where we were dealing with essentially a structured Excel format, or maybe some even older systems, like we see some people coming off AS400, right, they've been on the ERP for 25 years, 30 years, and they're looking at SAS and they're like, oh, we're just going to jump into Business Central. That interface can be a big shift for people.
Speaker 2:Just to jump back to a point that Chris had made, that you had mentioned that you found it easier for individuals to move from nav to business central. What I find often is it's sometimes more difficult because they have they have preconceived expectations that the system or the ERP software would be the same In essence. It may be different because of all the new features and functionality, or they've had modifications.
Speaker 1:I could go on a tangent on all this stuff right here.
Speaker 2:That habit's carried over, but I found in my experience, and I know the biggest one was the jump from the vision to the roll-tailed client. Everyone got frustrated because you went from the classic client again so talking from the decades to the roll-tailored client. Everyone got frustrated because you went from the classic client again so talking from the decades old here over to the roll-tailored client and there was a different look and feel and they always expected it to be the same and then move over to Business Central and introduce the full web client. If anybody hadn't used it in the later versions of Dynamics Nav, they had a little difficulty in adopting the use of it because they wanted it to be the same. And I think in Patrick's point of the maturity of the business operations, operational maturity sometimes can help guide that as well too. But that's what I see often, is that well, we used to do it this and dynamics.
Speaker 1:Now. We used to do it. That is so funny. That is so funny, brad, when you mentioned from classic to rtc, how you went from forced forms to pages right, so you can have like separate pages or windows. And in the early versions of business central you were just stuck in the browser. You couldn't even pop it out at that time. So a lot of people complained about that too, and so that was.
Speaker 2:It's funny to come in full circle. So to go back to again, to go through an implementation, I'll take it back. You know we can pick one. I mean there's two.
Speaker 2:There's new implementations, where you're going to do an implementation from somebody coming from another application, or you can also talk about a re-implementation or, depending upon the version, a migration to Business Central implementation because somebody that has been using it.
Speaker 2:If they're in the typical upgrade flow, then their migration should be relatively straightforward at a point. But somebody's migration from an earlier version should be, should be, should be, should be. Again, I say that with the should be just knowing that many new features and additional functionality is added to the software each release and someone may have an extension or may have another modification, or may not even you know they may be able to capitalize on that new feature by reducing technical debt from an existing extension or increasing their operational efficiency. So that's a whole other topic on how to stay current with the software and the changes. But how do you scope out an implementation? How do you determine what it will take to get it done and what needs to get it done and with that how much it should cost, right? So, if you're going to scope out an implementation, I want to implement a business central software, see this is Famous question.
Speaker 1:Yeah, how much is it going to cost? Famous question.
Speaker 2:So pretend I'm a customer, right, and I'll say the two questions how much will it cost and how long will it take, yeah, and just get it done.
Speaker 3:Yeah, sure, you know a lot of that kind of boils down to the what do you want to do, right? I'm a big proponent of the crawl, walk run premise when it comes to new implementation or migration to ERP. Business Central can be a lot for newer users and I don't think you necessarily have to jump in first. And you know, I was kind of mentioning that pain point list or those feature sets that you're looking for. You don't have to do all of those day one. So I think you know, from my perspective, having done this quite a few times, would be the what is what is key to your business operations? Right, because I want to make sure that I don't interrupt your way of doing business or at least your ability to generate revenue as a customer, right, your way of doing business, or at least your ability to generate revenue as a customer, right? Um, so first it's to it's to kind of get that minimum threshold list of what do you need to do to be able to run your business well, right? Um, sometimes that's just doing a one-to-one feature set, right? Like I need to be able to enter sales orders, okay, great. Like check, right, but you might also communicate something like I don't have an ap department, so I need automated ap. Um, so that that kind of conversation really has to happen first, which is, you know what are the key portions of your business. That need to happen day one so that I can help you kind of figure out, at least from a scope perspective. You know, okay, well, there are some dependencies here. Right, to be able to do automated ap we got to core AP right, need to be able to put in purchase orders. I need to be able to process vendor balances. And if you, if you don't have all of those things, I've got to go into place and say, okay, great, now we have a premise of what you want to do. Let's deep dive into how do we get you there.
Speaker 3:And I always try to break it into three different phases, which is communicate where you are today, right, because I need to know what you're doing today effectively to be able to say what do you want to do going forward. Then, if you have a good idea of what you wanted to go in forward, I can help you work on the how do I get you there. And so, as I'm doing that, I'm taking a couple things into account. Right, it's your data right? How clean is your data? How much data do you have right now today, how much of it needs to come over to the ERP? And then, how mature is your process and the people within that process? All of those are kind of key factors to what I call complexity factors, to coming up with a number Right.
Speaker 3:And we work in an industry where time is money right. So as I come up with those hours, I'm trying to figure out how much do I have to guide you through the process, how much is more of just data migration or training, and how much is oh gosh. Now I've really got to get into the weeds and teach your users how to do this. Or maybe you have a premise right. Maybe you already know how to do planning.
Speaker 3:All I have to do is teach you how to use the system, more so than having to teach you how to do the whole platform and the process Right, because when you communicate something like I want to be able to do automated AP, but you were essentially doing it via email last year that's a bigger ask on my part, so I've got to start adding hours to that to be able to think through configuration. You know the custom development that needs to happen data migration, data cleansing during migration if we need to be a party to that and then training right, we call it user acceptance testing and then ongoing training, and each one of those is kind of a factor when it comes to coming up with that number, I don't know. 12 months and half a million dollars, chris, that's how much every project costs, and then you know and then sometimes I'm going to blow it out of the water and come in way under budget.
Speaker 2:No, no, I know it's not easy.
Speaker 2:And I know it's not easy from a partner point of view, coming up with a proper estimate of effort to complete an implementation because there are some complexities, as you determined, and it's also difficult from the customer point of view. But I think you hit on a couple of key points of you. Know I go back to, you know I don't know, chris operational organization maturity, how you can phrase it, how much, how much they know of what they need to become more efficient and how that fits within Business Central, and also how many processes or practices that they want to get to they fully understand and that they may be doing now you mentioned, yeah, so just to touch base a little bit on that, it is very difficult.
Speaker 1:I mean. I think we've all been in that shoes. We're asked like how long, how long is it going to take and what is it going to cost? You know there are ways you can kind of narrow that implementation cost. I guess the effort that's going to take A lot of that.
Speaker 1:People forget, like we mentioned earlier about the planning components how much can a client take on some of those tasks? It actually it's better for them to take on those tasks not only from a financial aspect but also during the adoption process, because now they're involved, right, they're invested not only from the monetary perspective but also the process and taking that ownership. I find in my experience the user adoption increases when they're involved at the very beginning, even before they are shown. Business Central, as simple as you know clean up your data, right. That's something that they can do. Not necessarily you know they know the data more than I know their data. I can tell you where I can put it based on your definition of those of the data, but that right there alone, small stuff like that can save a ton of hours of having to clean it up and then going a lot of back and forth and stuff, hundreds of hours in data cleansing.
Speaker 3:Yeah, because if I do it wrong twice, right, you know if your data was wrong, it's not like I'm just going to eat that hour. Right, you know the other part of that too. There's got to be some onus on the partner to put some on this on the client too, right, I mean, there's a reason they call us a partner and not an implementer, right? Yes, we might be implementation specialists, but we're not here to just kind of cookie cutter, plug and play these ERPs into every instance. Right, we've got to work with the clients so that they understand how the system works, how it's configured, why we made a specific choice around the configuration, or an ISV, or maybe, like, we configured something a very specific way so that they're a party to those decisions, so that you know, should their company mature or even grow in the future, they understand, like, why did we make this decision at this point in time?
Speaker 3:What could have been a different decision? Or where do we maybe look at? You know, six months a year, five years from now? And if they understand how the ERP was at least configured or why, I mean, they don't have to know all of the intricacies of, like the back end of BC, but at least the why of did we pick this and what would have been the other route. You know, as they scale, you know, and that's on the partner too, to kind of keep up with that and communicate as the company grows like, hey, maybe we should do a phase two and do another sprint on like warehousing right, it's one of the big ones we see. Right, don't jump in feet first to warehousing automation. Maybe, like just be able to get bins out there, right?
Speaker 2:um, it is true, I like the way you phrase it, partner.
Speaker 2:Uh, oftentimes I I think it's important to realize the relationship has responsibilities and ownership From the customer point of view.
Speaker 2:At the end, they're the ones that own the implementation in a sense, because it's their business.
Speaker 2:Again, an ERP application it doesn't matter which one that you're using is, in essence, the heart or the lifeblood of an organization and it's important, from my opinion, that anyone who's implementing that has a good matter.
Speaker 2:Which one that you're using is, in essence, the heart or the lifeblood of an organization. And it's important, from my opinion, that anyone who's implementing that has a good understanding and ownership of it and they understand, like you said, they don't necessarily have to understand technically everything about it, but at least understand what it's doing for them. And the decision was made to go there and to just throw it over to someone and say here you may have implementation specialists on staff which are there to, but it's still not your responsibility to you know, make everything perfect, because you know part of the scoping or part of the cost or the part of the duration. It can be mitigated by how much the customer or the user of the application will do versus what the responsibilities of the partner. So it is ensuring to have that shared partnership where, at the end, the customer that's using it owns it and has some responsibility for it, along with the partner, to make sure that they have a successful implementation partner to make sure that they have a successful implementation.
Speaker 3:You know, and to that point you know, we find particularly our clients that are very hands-on with their implementation have fewer support requests on average, right, they have three less per every hundred or, I'm sorry, three less for every 10 support requests every month than somebody who was essentially a I don't know, just help me get it done right so they actually have a cost reduction for that capital investment in the engagement in their implementation and that actually we found over time that as they have more exposure and experience within the ERP, those support requests actually decrease longer and longer over time because in a lot of ways those people become subject matter experts themselves in the ERP as they've been ingrained in it. I mean, they touch it every day, right, but if they weren't involved from day one and essentially they were sat down at a desk and said like, hey, click the header and start entering customer information day one, then they're not going to necessarily understand how all that works and over time they're going to accumulate a bunch of support requests and ultimately cost.
Speaker 2:Yeah, it's with anything. You get the most out of it if you are close to it. In a sense and it's not everybody you could have a few internal, as you mentioned, subject matter experts or people who have that talent on staff that can help manage the use of it once it is implemented. Because with the changes of technology, with the changes of business in the world, you know, having the flexibility to adopt new features, functionality and change business processes is important. So having individuals on staff that can I call it on staff, but having those individuals, individual, talented professionals, working within an organization to help guide and drive, that is beneficial and they can also oversee the various aspects of the implementation as well. But let's jump back to the scoping and the implementation process. So you talked about sort of a discovery process to determine their pain points as well as what their needs are as far as business processes are concerned. And with that, what is your take on a good way to go through that exercise or what someone could expect to go through that exercise?
Speaker 3:Yeah, oh man, I'm going to take it like full, full circle Before I actually begin a discovery with a client, we can go a rectangle, if you want, sure, right parallelogram, tetrahedron um, I'm running out of oh, we can go with octagon, hexagon, I'm running out of shapes that I know the name of um.
Speaker 3:I know triangle um, but you know we have. We actually require our clients to establish those SMEs day one before you even begin discovery If they are going throughout their organization and figuring out who are the people who understand their job right and how are they keeping the business alive. So they might be managers. We actually find, of all things, managers are not the best SMEs because they don't always know how to do the job right.
Speaker 1:I agree with you there a hundred percent.
Speaker 3:Yeah, so we actually make them take the scope of their ERP and break it into sections and provide an SME for the discovery before we ever start Right. And you know, generally we try to establish somebody at the end user that that's going to manage it from a high level, so that we have a single point of contact. But I need to know who I need to talk to, so that when I get in there and I need to know exactly how you do your job, that I'm talking to somebody that knows how it is and not somebody who's just going to be like I don't know, let me go ask my people or I don't know. Like we'll figure it out as we go. Like at that point I literally kind of stopped the discovery and like, no, we need to establish this day one.
Speaker 3:We can't figure that out as we implement. I mean, there are instances where you can quote, unquote, figure it out while you implement, but you really have to define those things up front. And then they help define the scope too, because they're the ones that are actually communicating what needs to be done day to day. And as we do that, we actually do a very targeted discovery. We actually won't implement without doing a very engaged discovery with clients and it's just because, at the end of the day, clients are going to pay for it regardless and sometimes you can fret over cost of discovery, but it's an equity investment in the long-term success of the implementation.
Speaker 2:So no, I do agree, because sometimes, again, not all business is equal, not all setups are equal. Sometimes managers or business leaders think things are being done a certain way. Managers or business leaders think things are being done a certain way and then, when you had mentioned, just like Chris had mentioned, sometimes those doing the task can tell you a little bit more of what they're doing. But now, as you're going through this process and I'm going to take it to throw some questions at you here, just taking it, so you go through the process, chris, this is also for you as well, because this is one of those things you had mentioned early on development, right? So development to me is sort of an extension or a change in the existing process and how you come up with that development is going through someone's requirements, correct?
Speaker 3:Oh yeah, I never start with what are we going to design?
Speaker 3:It's the what's the pain point.
Speaker 3:And then we kind of design around that, right, you have to scope the the business need first, right.
Speaker 3:Um, and we actually generally try not to put a technical person in that discussion. We actually try to get a business expert, like an accountant or a kaizen engineer or um, you know, in some cases just somebody who's been a warehousing employee to communicate with the end user so that they can speak that language and discuss like, hey, what do you want functionally? Right. And then, by proxy, that person generally has a more technical background and then can work with our development team to kind of build that scope, right, it's the hey, in some cases this is just a page customization, right? Or maybe we need to build a form and then in other ways, you know, you kind of have to revise how BC is configured altogether by building extensions with procedures or you know. So, as you're doing that, I think it starts with the discussion of the business need, right, and it starts with the users being able to speak in a language that they're used to and not trying to describe it in a hyper-technical term.
Speaker 2:Okay, so with that, my mind is blazing on this topic. And well, it's because when you're going through an implementation we understand in the business requirements, someone will explain to you a business requirement. How can you validate that it's an actual business requirement? These are questions that I have and I've been having these. I go through phases and this is one of my latest phases.
Speaker 2:Everyone knows I do a lot of development and I honestly push back on more development. I don't want to say push back on more development than I do, but I push back on a lot of development and I honestly push back on more development. I don't want to say push back on more development than I do, but I push back on a lot of development because I'll say, business central can do this, Does this adequate for them? So why do we have to do a change for this? So now let's go back to the other side. So I already told you the end, so now I'm going to go to the beginning. A user gives a requirement. How can you validate that the requirement's a true requirement?
Speaker 3:Yeah, we generally try to run all this stuff through a steering committee from the executive level within the organization, right? Because another portion of this too is an end user, particularly an SME, may not have the full visibility of the organization, so we talk about it as a committee before we actually make any kind of effort around solutioning. It. Might be a hey, I'm just going to pick on warehousing because it's my shtick, but like the scanners suck. Well, that's not necessarily what is wrong. Right, it might be indicative of a bigger problem, but we have to discuss it as a group to kind of solution what the problem might be. It might be hey, you have a network issue, right, you need more access points in your warehouse. They suck because they can't access it. Or maybe they're just outdated and it's a hardware problem. Maybe it's a software problem and it does require development.
Speaker 3:But until you kind of talk it out like that and there might also be a hey, you're just doing it wrong. Right, Like the process is not really meant to be done this way, you're doing something that violates, like, a general business process that we would think would be accurate, right, maybe we should talk about what's a best practice that doesn't require any development, right? Maybe about what's a best practice that doesn't require any development, right? Maybe it's just a process change. Um, I, you know, we, we never start with a development first mindset because even though, yeah, in theory right, we can do whatever we want in al um, should we is maybe the better question.
Speaker 2:It's not the can we, it's the should we that's the music to my ears, because any modification or extension that you bring is additional technical debt to implementation. The architecture is amazing with business-centric. You can easily extend it, but you still need to make sure those extensions work with future versions as well as with maybe other ISV add-ons, other pieces you put in there.
Speaker 2:So, if I hear what you're saying is you go through and validate to ensure that the requirement is a true requirement and it's not a limitation of their existing system. So see, this is all music to my ears and this is what I like to hear, because I hear requirements and they come in and you find out well, we do it this way. Well, why do you do it this way? Because we do it this way? My favorite answer is because we always have.
Speaker 2:But then, one step above that is you find out that somebody was doing something a certain way because of a systemic limitation that was in a previous system and it became the process because of the limitation. I went through one one time and, to be honest with you, they started a process because they didn't have enough room originally. Like, if you dug deeper, they found that they didn't have enough room in a building to do something that even when they expanded, they still did the same way because they thought they had to do it the same way. And if you dug deeper and deeper and deeper, that requirement wasn't a requirement, it was something that was in place in process because of a limitation that they've had that they adopted as a new process.
Speaker 1:For an example, yeah, it is very important to have that conversation because there are many times that I've come across.
Speaker 1:My experience is that they've been doing it for so long they really don't know if there's any other way to do it or if it wasn't out of the box. Like you said, they kind of have to adjust due to the limitation and sometimes you don't see that. Sometimes it doesn't get surfaced until the very end, which is another common thing that occurs. But the conversation is very important to start and a manager can sometimes not be the subject matter expert because they're not on their day-to-day. But you also have to encourage everybody in that space to speak up, because as you go through your business process, when you're going through a discovery, they just tell you high level, this is what we do and all that. But in reality the people that are actually working on those things can have a lot more insight of ways to improve your business process. And on top of that, sometimes it's not even any close to a modification. It could just be an adjustment to your process due to the limitation that they currently have on their ERP system.
Speaker 3:Yeah, I think one of the other parts of this too, which we've seen a lot when we do discovery and scope. You kind of need to define that this is not a griping session for the end user, right? Like, please, don't just come in here and complain about how things are. Or like, hey, this really sucks. Come into it with a mindset of like, hey, let's improve, not just, oh gosh, like I can't do what I need to do, okay, well, what do you want to be able to do? Don't just tell me like you can't do your job because the system won't let you. Like, tell me what you want to do. I mean, that's what we're here for is to help find a solution set to provide you tools and resources to be able to do your job better, right? Um, so don't just come in there and be like, well, you know? Um, the the month end sucks. Well, what sucks about it? Right? Like, do you have problems depreciating fixed assets, right? Or like, are you? Like, are you on the wrong accounting basis? Right? Are you running cash? Should you be doing an accrual? Um, like?
Speaker 3:These are all kind of conversations that need to be had more around the like the systemic problem, more than it is just the oh, this, this hurts, right, it's the hey, this hurts, but we really feel like maybe we could be doing this better or hey, in some cases. You know, we are not technology advisors, sometimes we're business advisors because we in this industry kind of see, oh gosh, the gambit of what can be done and we can take our experience and kind of communicate that. Obviously we're kind of really careful around what we communicate from our experience right, non-disclosures and whatnot. But in a lot of cases you'll find that consultants have maybe worked in that industry or have had an experience, maybe even as an end user, in that space and the have you thought about?
Speaker 3:Statement. I really like that rather than saying no, right? I try not to say no, it's a have you thought about right? Have you thought about doing this, maybe a little different from a process standpoint? Or have you thought about maybe integrating an ISV, rather than just being like, no, we're not going to do that?
Speaker 2:So as you go through that is good to have your thought about it, because it does promote thought, I believe, where they can start thinking about different ways to become efficient. One thing I always say when I go through the implementations if you're just going to replicate everything that you're doing now in the new software that you choose, in the new software that you're going to use, really why are you moving? I mean, you're switching to a new application. There has to be a reason why. There's a reason that there's pain, there's a reason because of technical limitations, there's whatever reason. There is a reason. And if you just try to replicate the same process, you may not be getting any efficiencies.
Speaker 2:But as you go through this and now you have the requirements and, as we mentioned, business Central does a number of different things. Take personalization out, because the latest versions of Business Central have so much personalization that there's often confusion between customization and personalization. I wouldn't even call it customization, I'd call it extended at this point. But personalization is more data design, screen-type interfaces. That's not a modification, it's setup or configuration within the application. I'm talking now to the extension points points. How do you determine what needs to be an extension versus? Can someone change their business process to fit within the application, because Business Central may do something slightly different or do it in a different way and the requirement may be to do something and they may think they need a modification, which I'm going to throw this other question on. I hope you remember all these because I just fire them out, because this is all big on me. When do you determine you need a modification in the process or where in the process as well?
Speaker 2:um that's a loaded question because I have a follow-up question. That that's the. That's the last question. I'm doing everything backwards tonight because that's a loaded question, because I have a follow-up question. That that's the. That's the last question. I'm doing everything backwards tonight because that's the last question. I have a former question that I'll ask after we talk about this.
Speaker 3:I think you have to begin the conversation with the why right, like, why are we wanting to do this? Um, and sometimes it's you know, I don't have enough staff to be able to do this without having an automated solution. Right, I hear that one a lot, right, like, we don't have enough people to be able to do this. There's too much volume, so we need it to be more automated. We actually have kind of a matrix of things that we kind of run down before we ever even jump into the scope around development and it's. Does it start with people? Right? Do you have the right people at the right seat? Because a lot of times that can also be a contributing factor to the problem, right? So sometimes it might be. Hey, let me ask more than one person is this a common problem? I can't tell you the number of times I have heard like, hey, this sucks, we need to fix it. And then you go ask somebody else and they say, oh, no, no, no, no, like that that person doesn't know what they're talking about. Like this is how we do it. Or this is a better way to do it, and and you can fix that problem without ever having to run down the scope um, then you might also have a situation where, yes, we can validate that this is an issue, um, and we ask the question is the process broken, right? Do we need to come in, as put our process engineer hat on and say like, hey, are you doing this out of order? Are you missing a data set? Is there a process breakdown? Is there a communication breakdown, right, and can we fix it that way? Okay, yes, no, if you say no, we actually go out and look in the ISV network first. We are lucky as partners that the ISVs are responsible for keeping their systems up to date, um, where um, their, their extensions, kind of have to be compliant with the most recent releases from Microsoft. Um and I you know I don't use every ISV out there I think a lot of this comes down to, like, the, the good partnerships within that space to make sure that they have solutions that might be able to fit those Um, and if they do great, the good partnerships within that space to make sure that they have solutions that might be able to fit those.
Speaker 3:And if they do, great, and then your, your solution is more of a relationship and a discussion around the cost of that solution, and then we might get into the development effort of okay, now we have exhausted all other aspects of of what I can offer you, and then I'm not going to, I'm not going to do a deep dive into it. But then there's also the question of like the power platform and power apps, because maybe it's not an extension in BC, maybe it's a power app leveraging the power platform and the data verse, or maybe another D three 65 product, right, that that can also be a which I don't want to go down that rabbit hole. But it might be like the sales process in BC sucks and I'm like why aren't you using customer engagement, right?
Speaker 2:So it's a matter of using the right tool for the job. I think every application, no matter what it is, was developed for a certain purpose, and just because it doesn't meet somebody's need doesn't mean that it's deficient. It just means that it wasn't. It's not the best solution for their need. You know, it may fit someone else. Run and sneak is a great for some people and dress shoes are nice for others, you know, but they still uh, you know, uh, chris. Chris tells me the way. It's just dress shoes, his feet hurt. I can't talk. See, it's that whole thing that we started talking about. Chris tells me that his feet hurts when he wears dress shoes and they suck, and that's why he wants to wear tennis sneakers. I say no, chris, they don't suck, they just don't work for your feet yeah, well, I mean in some ways.
Speaker 3:In some ways maybe you just need a different shoe, right like correct um correct but you know that that also might mean like maybe chris is not in the right environment where like right, because maybe chris and this is another portion of this too right person in the right seat right is chris in an environment where he can succeed because he has to wear dress shoes, like? If yes, then like no work from home, and then I told him not to wear dress shoes oh, that would have been an experience.
Speaker 3:Yeah, he didn't hiking with dress shoes, but I mean like you know, this kind of speaks to the whole premise of round. Like, I don't want to say like development should be your last resource, because that's not true, um, but to a lot of extent, anytime a client communicates a request and we do development around it, there's going to be continued cost at some point. It may not be this wave release, it may not be three wave releases from now, but the other part of that too is because we are in a very dynamic space. Who's to say that I didn't just put a request on the Yammer board? The second I wrote that extension for you where it was like, hey, I really wish the Dataverse would allow you to do virtual tables Not that I did that, you know, four years ago, um, and then all of a sudden, you have the ability to extents because microsoft listens to us, and now all of a sudden, I wrote this customization for you that's debunked by base application features that that's part of staying current, I think.
Speaker 2:Think with it, because it is an application that is constantly evolving to use that word in this context. It's changing, so something that required a modification when you started the implementation may get added to the application. The contract billing is out with 2024 Wave 2. I know a lot of modifications were made for contract billing. I'm not saying contract billing's going to satisfy every one of those cases, but even the whole printing to PDF. How many modifications were made back in the early days for printing to PDF? Speaking of the modifications and I'll throw this out, chris, I don't know if I've asked you this or if you've heard me ask others this it's for an implement.
Speaker 2:This is kind of a little side by tangent, as much as I try not to go off on these tangents, but when you're going through this process of implementations and then determining, you know, change requests or how somebody would need to change or what modifications they may need, when does that happen? And what I mean by when does that happen is does anyone ever just sit down and say here's Business Central, let's walk through your business end to end, see what it does? And what I mean by that is okay, let's throw in a chart of accounts. Let's throw in a couple items, let's throw in a couple customers, your basic cases. I'm simplifying it. Let's purchase raw materials, let's take customer orders, let's ship an order, right? My question is I see that because I see sometimes I see change requests or extensions Again, forget personalization, to hide fields and move stuff around because that's personalization, okay, so take that off the board because you don't need an extension for that.
Speaker 2:I see so many times that before someone even touches it, they've already come up with modifications that are needed, where I feel like saying did you even put an order through, to go through the scenario to see where is it lacking in functionality that you may need? If it's additional fields, could it be captured a certain way in Business Central without having those fields that you had before? Or do you really need to add those two new fields to the sales header, for example? What is both of you, chris? I'll ask that to you. It's like. What are your thoughts on that type of approach for an implementation?
Speaker 1:That's a good one. So I will share my piece where it's worked for me in the past and one of those things I'd mention you know you got to do a discovery or analysis of their current process, their current ERP. In many cases when you are doing a discovery it's always in my opinion again, my opinion, my experience it worked well for me. It's always a good idea to have Business Central already open. Have Business Central already open, not only you help introduce the people of what to expect and what Business Central looks like, you're kind of getting a little ahead of there.
Speaker 1:Before putting up Business Central and going through the whole process, you can at least speak to while you're doing a discovery and understanding the process. You can kind of sort of follow that with Business Central and in some occasion I would show that like this is how you would do it in Business Central. And then it's easier for me to surface certain things that you know Business Central might not see. For example, it also helps you translate some fields where they say one thing in the current system, if I have Business Central up and running, I could say, well, you reference this field, it's called this, but you can actually do this in Business Central. It allows them to think. It allows them to get excited about it. Are these going to be customizations or are these just needs to be redefined? I'm trying to find the right word but restructure their thinking of what this field means in Business Central.
Speaker 2:I wish I had the soundboard. I'm sorry, patrick, because I would clap on that, because you hit so many key points that by having business central set up in the base level, they can look at it with you. You can get a visualization of what they are referring to as well as they can have one with you. I see that it's a successful exercise, because terminology is killer. It is absolutely killer because everybody calls things something and I only speak Business Central. So I need a way to associate what you're calling it to where it fits within Business Central. And going through that exercise together I think is helpful because again, it goes back to receiving and seeing modifications and just shaking my head sometimes. So and uh, yeah, I won't even tell you sometimes where it was functionality that was already in business central. But yeah, you know where there's maybe another alternative.
Speaker 1:But patrick, how many times do you do a data migration? Even going through a simple configuration packages where you get an excel file, you know and and got to go back to the client and said what does this field means or what is this data? You can actually identify a lot of that information during the discovery, before you even start data migration.
Speaker 3:Oh yeah, you know, and I mean maybe to your point too one of the things that I found really helpful just from a consultative perspective is maybe run through the process and be like have a client just describe what they're doing day to day to you and then try to run through it in bc, and then the second it doesn't meet their requirements stop and say like, okay, now describe to me what you would have expected it to have to do. Okay, great, um, like, have you heard of item attributes? Right? Right, it's like the. How do you define color? Right, it was like well, is it a variant? Right, is it a stock keeping unit? Right, so you know. Then you stop and you have a just yeah. And then you have a discussion and you're like great, that's an item attribute. Right, it's an arbitrary field that I'm going to throw out there that I can report on later, but it has no feature that I have to build. Right, it's the. Hey, you called it color and you built a custom field in your previous ERP. I'm going to make it an attribute and then add a value to it.
Speaker 3:And then you kind of ask the question of does that? The way that I kind of phrase it is does that meet your need, right? Like, does that work for you? Like, do you think that we could do this? Going forward, you'd be surprised how often they would just be like, yeah, that seems like it would work, and then we move on right, and then it's the next thing.
Speaker 3:It's like the, and then you keep going through that process in bc as they describe what they do today for you. Now, this requires a little bit of like process engineering mindset to to really hear what they're saying and translate that to a simple process in bc. But I can't tell you the number of times we've mitigated customization by doing that right, and it's just been like, hey, talk me through how you do this, let me walk through it like I would do it in bc, like if I were going to do a vanilla demo. And then we find nine times out of ten it was like, hey, the previous erp had to be customized or the previous system had to be customized, so they assumed it had to be customized to BC.
Speaker 1:Yep and a hundred percent, because you, you, you hit it right there. Sometimes, when you're having those side by side, people don't realize, especially people that joined the organization at a later time. They don't know that some fields are modified Right and then you can actually identify as like oh yeah, that's not, that's, that's not a out of box business central. It's easier for you to note and say OK, I think this is a modification, without getting into the codes.
Speaker 3:Yeah, you know part of that too. I think there is some onus to try to push clients to use out of the box fields more than create custom ones, Cause then you're just creating table extensions and page extensions until the cows come home and you kind of have to have a conversation of hey, there's something in business central that kind of fits that requirement, Can we use that rather than go in? You know, is it easy to create a table extension and then add that to a page? Yeah, Um, but do I have to, and is it more sustainable to do it?
Speaker 1:this other way maybe right, but you got to let them. Yeah, that's, that is always funny. Can you just add that field? For what purpose? Why are you reporting against it? Like what is? It's going to be a big decision making uh, field that's going to affect everything else. Yeah, that's a have you heard of it.
Speaker 2:Yes, Sometimes it sounds so easy, like you said, it's easy to create, and I'm not saying they're not needed. Sometimes it's so easy to say just create a table extension because you can't. It goes back to what you I like your approach of. Just because you can doesn't mean you should and just say is that really the best solution? It's almost like and again, depending upon who's doing the ask, their level of understanding of the application, level of understanding of the business process, whatever level of understanding, it's sometimes like me going to the doctor saying my arm is sore, put a cast on it, it's broken, right, it's. It's where the doctor should be able to take a moment to understand what's really wrong and they may find out that my arm isn't broken. I didn't need a cast. That wasn't the best solution. The best solution may be.
Speaker 3:You know something else give me some aspir, yeah, a splint or something I don't know.
Speaker 2:But that's my point. It's always important to make sure that the right you know, define the right. You can go down that rabbit hole. You want to talk about rabbit holes forever. Who's the right person to make the decision? But I think anything even as simple as that should be reviewed. And sometimes I think human nature is to take the easy way and sometimes the easy way isn't always the best way and you know it's just throw the field on there. We just got to get it done, you know, just keep them happy, and it may not be the best approach in the long run.
Speaker 3:I'm talking in the long run, you're not consulting and you're not partnering, right, like, if you're just going to do everything in a binary, like yeah, because I try to. Like, clients will ask the question of you know, it's not just the, how long is it going to take and how much does it cost, it's the can you right, can't you? Just I'm like, yeah, of course I can't, it's technology, right, like there's very few limitations as to what I can and cannot do, right, um, should I? Is the question that we ask. Like it's probably annoying my parents, like my parents probably probably drove them insane. I was the why kid, right? It's like, why are we doing that?
Speaker 3:Like in, the customer doesn't know what they don't know. Like they don't know. When they ask you just to add a field with the long term implications might be, you have to, as a like, and this doesn't even have to be in the partner network just as a general user in the space, like you need to understand that that could have some long-term implications. Um, I mean, heck, we had one the other day, um, where microsoft used the same name for a field that we had extensed. We in, in one of the hot fixes we had, extents the table and used what we thought was a logical name for a field, and then Microsoft added it added to the base application and it caused a slew of failures across extensions yeah that that happens and thankfully that's where the affixes come into play to help prevent some of that.
Speaker 2:Yeah that so we geez. There's so much. I have a few more points that I want to get to with this. So we talked about going through the implementation. We talked about the discovery uh, we talked about requirements gathering ensuring you have the requirements gathering and consulting and partnering to come up with the right solution, the why guy. I've always been that as well and I always tell it when I ask why a thousand times. Not because I'm saying what you're doing is inappropriate. You'll break it down to the smallest point to either validate what you're doing is the best way, or you may find that you're doing something, like I had mentioned earlier, for another reason than you think, or it even gets you thinking that yeah why are we doing this If you can validate what you're doing when you go through those?
Speaker 2:why? Why? Why? Why? Which you can actually explain? And the answer is not just because, but a factual reason. It helps validate a process for somebody too, so they can feel good that what they're doing is efficient.
Speaker 1:Yeah, absolutely. I think you really have to always, always, have your consulting hat on, you know, because if you just want to implement it, like you said, patrick, you just set it up, configure it every single time the same way, but it takes away that value, right? I think that's where the value comes in, for a consultant is to be able to identify. You know what's the long-term effect if you were to do it this way?
Speaker 2:So I think that's important and with that we touched on too, is have some considerations. Discussion about data what do you need to do with the data that you're, uh, bringing into the system? You know how much data do you need to bring in and that we talk about? We can go down the whole side. I'm just wanting to put that as a point, as a point of consideration is how much data do you need to bring in, as far as historical data even is? I think, chris and Patrick, you had mentioned data. Some people call it data massage and data cleansing.
Speaker 2:But again, if your customer list has 20,000 customers but you only do business with a thousand of them, do you really need to bring all 20,000 in, or can you get away with bringing in, you know, the customers that have been active with a certain amount of time, uh, for example, yes, with a certain amount of time, for example, yes, yeah, listen, I've seen I can tell you some. We can talk about that after. Well, no, I'll get into it now, just so I don't forget. I'm taking notes for some reason, but I see so many implementations, or it's more so, on the migrations or upgrades, I don't even like to use word upgrade anymore because, again, I think it's a matter of which version you're coming from, but they feel that they've spent so much on the system before that they need to take all of the stuff with them. They need to take all of the changes. They need to take 20 years worth of history because they're attached to what they've already spent, thinking that if they don't bring it they're losing the value. But in some cases it actually hurts them because they're bringing.
Speaker 2:To go back to what I said before, do you bring I call it one pile of poop from you. Take a, you shovel one pile of poop from one side of the garage to the other. It's it one pile of poop from you. Take a, you shovel one pile of poop from one side of the garage to the other. It's still a pile of poop, right? So why are you moving it from one side of the garage to the other? You know, throw it out instead of taking up space.
Speaker 3:Yeah, you know, when somebody comes to me, God it's. I'm glad that I'm not the only person struggling with this. We'll put it that way it God it's. I'm glad that I'm not the only person struggling with this. We'll put it that way. It's funny that you said 20 years. So it goes back to the why, right. Like, why are we doing it? Like, don't data, don't move data for data's sake? Right, Like, why do I need that? Do you really report 20 years back? No, no business compares. You know. 20, 2013 to 2023 to 2024, right.
Speaker 3:Most businesses are operating, like, within a space where, like, maybe on a compliance requirement, they need seven years of history. Okay, For what? Right, not even in the Microsoft space. Just in general, within technology, where maybe I don't need to move over the transaction history, or maybe, like your legacy system was on prem, Okay, well, there's a lot of solutions to maintaining that data should. Should you really need it? Right, when I'm not just being derisive and saying like, no, like. We work in a technology space where, like, if that is a true requirement, do I have to put it into the ERP? No, Like, if it doesn't functionally add value to the ERP itself, right, Like there's not a master data, there's not a historical requirement. There's things like Azure Databricks or just Azure Storage right, Like spin up an Azure SQL instance and then deprecate your on-prem server and be done with it, and then I'm just going to bring over that data and you want to go report on that? Great. Let me show you how power BI can connect to Azure SQL right.
Speaker 1:So many options.
Speaker 2:Yeah, so many months.
Speaker 3:I didn't mean to send you on a spiral, but it's just. I mean it's a hotbed topic because we're talking about implementations, and these are just.
Speaker 2:We should almost, chris, just have one discussion with a group of people about just the implementation do's and don'ts, even data migrations, is entire. Data migrations we can talk about for a month.
Speaker 3:Yeah, but I mean, like, to get back to your point. It's the why. Right, like. Why would I want to do that? Like, why do you need to bring 20,000 records over? Well, I have the data. Well, that's not a why, that's a. That's a like I want, right, A. Why would be something like I need to be able to report year over year within the ERP because there's a compliance requirement, right or God.
Speaker 3:Maybe I have an open transaction from 20 years ago, great, well, don't migrate the other 19,000 records from 20 years ago. Migrate that one. And then let's worry about the last two years, right? And that's where you kind of have to start guiding these clients through the understanding of when does it actually add value to the business and when are you just going through the motions of moving data. Yeah, it's just such a. It's such a big thing too, because everybody spends all this time building out this database they spent. They're like oh god, I have 20 years of manufacturing history that I've got to have. But do you have to have it? It's the. Why do you need it? Right, like it's the why do I need to do this? Why does it add value to you? Because it takes time for us to migrate that, even if you can do it via config packs, which, which is not even a viable option. Sometimes, right, there's record set limitations. It takes forever if you're validating every field, right.
Speaker 2:It's good that you're saying the why, but the important part, to phrase it a little bit differently just because you don't bring it to the ERP software or to bring it into Business Central no one's a bigger fan of Business Central than me, I think, and it's been my life and I enjoy the application it doesn't mean that you don't have access to it. See, there's a difference. Why do you need to bring it into your ERP system versus putting it in a data warehouse, wherever that may be? I'll just use the word data warehouse, whether it's in Azure, azure, like I said to Chris, azure Azure, no, it's. See, that's what I'm saying is why do you need it?
Speaker 2:Because, if you need to do it, for reporting, because there may be cases where some industries or businesses medical and some food they need to keep history because of I worked with medical devices they needed to keep history for a long time just because of the nature of their product. But that doesn't mean that you need to keep it in the system that you're moving to. It just means that you need to have access to report on it. I worked with one implementation and they said oh, can we keep the old system, you know the old database running on the computer and you're like, yeah, it's a sql database, just leave it you can and they're like okay, that's fine, you know again, it's the why do you need it is the important part, and if you do need it or want it, you don't have to lose it.
Speaker 2:You just don't bring it in the form of putting it within your erP application today.
Speaker 3:Yeah, I mean those 80 gigs can get soaked up pretty fast, right? We partition a tenant, you get 80 gigs.
Speaker 2:And then what? Three per user.
Speaker 3:Five per user.
Speaker 2:Yeah, I did a joke to Chris one day. I gave him an input and we just inputted tons of pictures.
Speaker 3:I mean that all goes to actual database storage, right. Then there are solutions around not doing that, right? Yeah, so data is, it's just a mean joke. Yeah, Data is cheap until it's not, though, right, so that's.
Speaker 3:Another factor to this that I don't think a lot of people talk to their clients about is the. You know, let's say that you have a pretty robust environment with a lot of users, that you have a pretty robust environment with a lot of users, and maybe you have like three or 400 gigs worth of data storage in your tenant. There becomes a cost conversation at some point of how much value is that adding to your business versus how much cost if I have to buy additional space for you at some point? Right, and you know well, I think we're very lucky to be in a space with an ERP that is so cost. Well, I think we're very lucky to be in a space with an ERP that is so cost effective for every market. Until you start running out of data and you start looking at how much it costs to partition more Azure space inside of your tenant. It can get pretty expensive really fast and you start talking like 20 years of data, or maybe you process like 300 sales orders a day that you know you could.
Speaker 1:You. You can even break that down a little further in terms of the way you would ask the client about data one how much data do you need that would allow the business to move forward to a point when you need to do a decision making? How much, how far do you need to go back to make your business move forward? That's one part. That's usually. You can usually get an answer fairly quickly. The second part is you know if you do need to move it. You know it could be as simple as leave it to your existing ERP system and just report manually and just have one license. It's sometimes that's easier or cheaper, if you're looking at costs, than trying to build this data warehouse where maybe one time someone needs to run it at the end of month.
Speaker 3:Yeah, there's a I hear a lot of people say that like what if? Statements too. Like what if I get audited Right. Like don't migrate 20 years of data with the what if I get audited Right. Like figure out what the requirements are in your industry and then meet those minimum requirements and then move on right.
Speaker 2:So we kind of been walking through an implementation, determining scope, and going through a project. I would love to have drafted a project plan or something for this, but now it comes time to go live, as we call it, that infamous go live. We're going live on January 1st.
Speaker 3:No.
Speaker 1:I've done too many of those man Listen.
Speaker 3:February 1st is a great day to go live. No listen.
Speaker 2:January 1st I understand the year end and stuff like that, but let's be real. You have Thanksgiving here in the United States, thanksgiving at the end of November. Then you have many holidays in December, whether it's Christmas holiday, there's several other religious holidays, hanukkah all these holidays for celebration. Then there's New Year's. The reality is, a lot of individuals are checked out and they're really not ready to go through an implementation on January 1st, in my opinion. You know 4th of July weekends. I can tell you how many implementations are done on 4th of July weekends, but it's one thing to consider that's important is the timing of when you're doing it, because people need to do it and it's oftentimes people on the business side as well, too, and they have their what I call, you know, a job to do, along with the implementation well, you're going to come in and do a full physical on new year's eve so that we can go live right like no yeah it's.
Speaker 1:it's wild to choose right at the beginning of the new year's you know I I stopped stopped counting how many birthdays I've missed of go-lives in January where I would go. My birthday is sometime in January, but there's been many times where I spend my time at the restaurants eating alone. I know it sounds sad Celebrating my birthday because I'm at a go-live. There's many other dates that you can accomplish the same thing.
Speaker 3:You know to that point it doesn't even have to be the first. You know a lot of people are saying you know, we've actually made some pretty good use cases to end users and clients that it doesn't even need to coincide with the first. Like this is some arbitrary month end premise. That's, oh, we need to coincide with a first. Like this is some arbitrary month-end premise. That's, oh, we need to go live at a month-end. I mean, why, like, what is the use case for going live at a month-end? Your open AR is going to be the same as it would have been at the middle of the month anyway. Your accounting staff isn't going to be tied up trying to do a month-end right. They're going to have been able to close the books on the previous period. We're going to have all of the open transactions.
Speaker 3:Why don't we cut over mid-month, do a little bit of parallel testing for the last two weeks of the month and then we'll do a hard cut over when you're ready to go live, um, and it's kind of a mid-month go live. It's kind of like a soft mid-month go live. Maybe think about it that way, um, where you you don't need to go live on the first. Like, god forbid, you go live on january 1st like for the rest of my career. I kind of don't ever want to do that again, because it's just this, this arbitrary made-up reason that people are like, oh, we got to go live on january 1 because that's our year, that's the beginning of our year. Well, the reason you're saying that is from a reporting perspective. That's just data. Right, there's no functional reason to do it, unless there really is, in which case you know, have that conversation and discuss it, but you know.
Speaker 1:I think you lose a lot of that when you do go live in January 1st. Again, there's a lot of clients that go live in January 1st but you lose a lot of that subject matters that you typically would be helping with the go live. You know their mindset there. They're just with the go live. You know their mind's not there, they're just coming from the holidays. You know they're just celebrating all this stuff, they're just on vacation and then for them to come back and then switch to a go live is. It's a recipe for disaster when you do, when you do that now there's been successful ones, obviously.
Speaker 3:I think a lot of people have successful implementations in in the beginning of the year, but it's certainly not fun, I would say and unless there's, like, a true business, need I just again, I don't know why right, february is a great year, a great day to go like february 1st. Right, it's an arbitrary, random extra day. Right, like it's a short month. So then, if you're really concerned with how much data it's going to take in the speed like, do it in February, um, or you know even better, do it at the beginning of Q2, right, um, so that you have a smoother transition, um, and, and you know, the prep for that go live is really, you know, the entire implementation is prepped for that go live, obviously, but we actually spend a very intentional portion of time preparing for the go live, like, there are a lot.
Speaker 3:I mean, I think everybody who's done an implementation knows their steps for that cutover right, everybody has designated duties and responsibilities and you've got a process that you've got to go through, and a lot of that depends on what you've configured or the data that needs to move. But I just don't think it has to be on the first either. I think it could be like the second Monday of a month if it had to be. We've done several of those and they've been very successful and they're less stressful for the end user, because they're not trying to do a month end while they're cutting systems over.
Speaker 2:It's a challenge. It's a challenge. So now we go live. We chose our date. We're not doing a January 1st unless there's a real reason. I understand sometimes it's scheduling as well, with shutdowns. I mean there's a number of factors. But, as you had mentioned, have a good, real, clear discussion or answer as to why you're doing it on the day that you're doing it, because also sometimes doing it, you have individuals who are going to help you with that you also want to think about them and their energy to help drive you through that process as well.
Speaker 3:Consultants are people too.
Speaker 2:It's not only the consultants, it's the individuals that are in your employee that are also going to be giving up time as well to do the project for the business. I guess you could call it so. We talked about a couple of things on here, and what can someone expect after they go live again? This is for everyone.
Speaker 3:Um, I I don't think it's consistent across any implementation. I think some will go really well. It's generally those people that did their testing and have been engaged in their implementation. Um, the best kind of go live for me is when the client is literally trying to drag me to that finish line. It's the now we're ready, let's go. Now we're ready, let's go Like we've got this. And they're like showing me throughout the course of their implementation, like no, I can do, I can blow out sales orders like no big deal. And then there are others where we're having to like push towards a deadline and I and a go live when maybe the client isn't as ready as we would like, I don't.
Speaker 3:I generally don't believe that like necessarily, unless there's a business need you know you need a target, go live like there is no thing of it takes what it takes. But I think we all kind of know like projects sometimes run long because something happens right, um, but you've got to establish that date and you've got to plan backwards from it. Um, that, once you've gone live, it's it's really a question of like having a really strong support network so that the client feels supported, um, and it doesn't always mean that that's the partner. Um, I'm going to keep leaning on these SMEs. Um, we try to create an escalation path with our clients so that they understand, like hey, you should maybe go ask Brad. Right, brad is your SME, he knows how to fix this. We've taught him how to do it. Don't necessarily put a ticket in every time you get an error because you didn't release a sales order. Right, like, hey, maybe escalate it internally and create that path.
Speaker 3:We, we actually find also when we do that I, we actually find also when we do that I want my clients to be superstars and the people who are involved in the implementation. They become superstars at the end user because they are the subject matter experts. They become these guys that are like they're not the single source of truth, but they're essentially the subject matter experts in their field Because I want them to escalate internally and own their system. So we generally try to establish those SMAs. We call it train the trainer, right, we train an SME to be that trainer, to teach other people within the organization and then be that first line of defense, right? Essentially, before you reach out and submit 30 tickets, your first week.
Speaker 2:It is good to have that escalation or to have an internal liaison working with the partner, because if someone thinks they need a ticket, for they can see the patterns, they can see if something really is an issue. Is it not an issue, is it a training issue, or is it something's not working properly. It's a number of different things, whereas if they go to the partner, it goes back to what we were saying before is, if they're making a support request like, oh, it should be doing this, it should be doing that. If they really don't know what it should be doing or understanding, you could create further harm to the issue because someone will fix it.
Speaker 2:And they fixed it incorrectly, not because of incompetence or they're not capable, it's because they were misdirected.
Speaker 1:I love this topic what to do after go live at Business Central because it is a matter of maintenance.
Speaker 1:At this point, it is considered the last upgrade to many to Business Central, so it's a matter of maintaining Business Central. One of the things that if you don't establish and I actually have a speaking session about this, so I'm looking forward to having this conversation with many others that if you don't establish a plan for after go live and maintaining business central, you will create what I call rogue processes, will create what I call rogue processes. What that means is that if they don't have a path of communication of things to improve and maintain business central, what they will do, what your users will do, is Google stuff and they would take what they learn and then, oh, I'm going to set it up this way and then it becomes a part of their business and then you wonder why things are not working or there's some inefficiencies and that can create rogue processes. And then guess what? Now it becomes a technical debt or a process debt that you'd have to carry throughout your business.
Speaker 3:Nothing better than that.
Speaker 2:I found it on Mabuso right Like that, no, that that is a great point that you had mentioned there and that's why it's important to have some visibility to the implementation, because post go live. You do want to keep an eye on things and to ensure, as you mentioned I like that rogue processes so we we actually don't consider the go live the cutover for our project team.
Speaker 3:We actually continue the engagement for several more weeks after that and continually check in. Usually it's usually it's every day for 30 minutes throughout the course of at least one month end. And you know, a client might look at that and like, well, we just spent all this money. Why do I need to pay you 30 minutes a day for the rest of this? Because you don't want this stuff to pile up until Friday and then send me six tickets. Right, it's the. Hey, we're starting to notice a trend real quick. Well, great, let's jump into a session real quick and get that squared away for you. So we call it continued support.
Speaker 3:Where the project team is still engaged um, I mean, they're the subject matter experts, right? The? The project team that did the implementation is probably going to know more about that business than some of the people at that business at the end of it, right? Um, they stay engaged on a continual touch base throughout the course of that implementation. Um, the the term, like the amount of time, can be variable, right it base throughout the course of that implementation. Um, the, the term like the amount of time, can be variable, right, it depends on the scale of the complexity, um, but it it makes sure that that client feels supported as well, um, so they don't think it's just a hard cut over, it's the you know we're not throwing them into the deep end when we know that they can swim and aren't going to drown, right.
Speaker 3:I don't like to drown we made t-shirts one year as a sink or swim in 2018. But yeah, I mean, it's that transition right and it very much is that it needs to be an ease into it. It can't be a hard cut over, because that's just a recipe for disaster. Um, this is not one of those instances where I think ripping the band-aid off is the best solution. I think it's a nice easy transition, as much as you can internally or as a partner, where the client feels like it was the organic transition from system to system or process to process, rather than just a hard cut over, because that could just be very disruptive.
Speaker 2:No, it is good and we've talked about a lot of points. A business central implementation is an experience for many. It doesn't have to be something that's difficult, nor is it always difficult. I've worked on several implementations that went quite well, or rather well, and I've worked on some that didn't go as well as they could have, and it wasn't an issue due to the software or the application, it was an issue due to, you know, sometimes what I call preparation right. So with that, so we kind of talked through a full cycle of implementation to discovery, scope, some points. I could talk about all these, each thing we talked about. I could have had a separate discussion for hours on each point, and I think we all could. Chris, we'll have to make a note that we have to try to get some of these implementation do's and don'ts we should.
Speaker 1:We should break it down further, because I want to yeah no can you take notes for me today?
Speaker 2:I'm tired, it's late, well, just ask co-pilot to take notes I don't have co-pilot up on here. You know we could we could take this.
Speaker 1:We could take this and have co-pilot.
Speaker 2:Summarize it okay, we can't, we should do that, we should do that and then have I. I would like to have the implementation do's and don'ts and and maybe I have some ideas maybe one of these upcoming conferences we can just get a bunch of recordings together it is put that on the schedule.
Speaker 1:We'll put it on schedule, uh, but you know it is very important, right, like once you're live, once you're live, um, it never really ends, uh, because, uh, there's a saying that, uh, my uncle used to say is that every day is an opportunity to be better than yesterday.
Speaker 2:So you just have to continue to improve so so with, as we've been talking about this quite a bit and we'll have a continued discussion on this in the future, but to sort of close this discussion with a nice quick ending, I'll ask this for you too, Chris, because I know you do a lot of implementation, so this is to both of you what tips would you give? Come up with a number, any number, it's not the quantity, it's the quality, as they say. In this case, what tips would you give to someone who is about to undergo a business central implementation? Business central implementation, and what I mean by tips is preparation tips. You know what they can do to prepare or expect, which is still part of preparation to make their business central implementation successful.
Speaker 2:Oh, I'll jump in here first, chris has more time to think then.
Speaker 3:There you go. He's smart, I how he did that. I saw the gear spinning. I start with you've got to get those SMEs right. You've got to establish who in your business knows how to run the business and knows how to do the business right. You've got to start with that. You need to know who the key players in the right seats in your organization aren't and unfortunately, sometimes the people making decisions around ERP and implementation of migration don't have enough visibility throughout the organization to know who those are. So it can take time to get those right people in an organization and come up with a way to communicate.
Speaker 3:Well. Right, Because sometimes you're multinational and you need to have that conversation across the ocean in time zones. Then you need to come up with the the why. Right, why are we doing this? Right? Like you need to come to the table with why am I doing this? If it's just because business central is the new shiny thing for microsoft, I don't know. Maybe you should take a look at the why again.
Speaker 3:Um, there needs to be a business need or or a value add statement that you can put around the migration implementation upgrade, whatever you want to call it. Like there should be a business case to do this right. And that needs to be the mission statement of your implementation moving forward. That mission statement might transition and change over time, but it needs to be the reason that you're having the conversation around the implementation. And then, honestly, you really need to start mapping your processes and have a good understanding of how you want to do business going forward. Those three steps are kind of key before you ever put the first letter in a word document yeah, well, some good tips well put pat.
Speaker 1:I think a lot of that kind of falls into my tips regarding, you know, before starting Business Central implementation, what's interesting to me is, in implementing Business Central, it seems to be a common theme where a lot of clients don't really have an internal change management process. It's almost like it got lost. It got lost somewhere. I don't know where that got lost. You know, when I started my career implementing Dynamics, it seems like it never gets thought about, especially when you have a smaller implementation. Even big ones, man, they don't exist, which is wild, so it kind of breaks down.
Speaker 1:If I can break down change management and you touch a lot of these, patrick is, you know, understanding why you're doing it, understanding the change right? What's the biggest impact? You know why is the organization investing a lot of time and money to put in a brand new system that's going to be the backbone of the business, identify stakeholders? There's been so many times where you run a project and you maybe see the C-level, c-suite leadership come into play and then they're just not in it. So that could be a difficult conversation when things go haywire and you're not getting the support that you need to have a proper implementation and, of course, taking the time to review your process. So if you already have an existing documented processes, that helps and save a lot of time. And, last but not least, is the data cleanup. As you noted earlier, patrick, hundreds of hours you could save. Imagine that. Translate that to dollars. Take the time to do that. It's going to save a lot of time. So those are my big tips before starting.
Speaker 2:Thank you. Those are very important tips. And I laugh, chris, about the data cleanup and the data cleanup and the data, because I can tell you, I remember some implementations where their data migration was more expensive than the implementation because they thought they needed everything and it was. It was yes. If they would have taken the data migration out, their implementation probably would have been what chris a third of the price, if that right, maybe even a quarter of the price.
Speaker 3:I mean, just use a round number and say, if you saved 500 hours, throw a round number at it, which is not realistic in our industry. But let's say it's a hundred dollars an hour, right, it's fifty thousand dollars. Like, what could you do with fifty thousand?
Speaker 2:dollars in your business, right? Yeah, this was much more than that yeah right, yeah, right.
Speaker 1:So take the time, man, it's wild, it's a wild concept, but it works. It works. It's not perfect, it works.
Speaker 2:Take the time to be prepared for the implementation, because if you don't think you have time to do it properly, you sure as heck don't have the time to do redo it several times. In the end it's it's something I see all the time. It's I don't have time to do this task, but I have time to do it three times in the future. Sometimes it would take a temp to be prepared with, and you guys both offered some great tips. Patrick, thank you very much for the conversation today. I could talk about this topic for hours, chris. You and I will probably talk about this for hours for the rest of the night, but thank you again for taking the time to speak with us. If you would, would you please let everyone know how they could get in contact with you if they had any additional questions about business central implementations, migrations, upgrades or any of the other great things that you would do?
Speaker 3:Yeah, first off, appreciate you guys. It's always great hanging out with you, but also just really enjoy talking about this space and trying to make it better. If anybody wants to talk about it more, 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, um. Or I'm a very active on LinkedIn, um. Or go find me out at one of our you know many conferences. Coming up, um. Be the big bald guy floating around with an LBMC shirt on, happy to talk to you and you know, if nothing else, just commensurate around data.
Speaker 2:That's good. That's good, that's good. Thank you again. I look forward to seeing you at days of knowledge as well as community summit to maybe talk a little bit more about this topic. Thank you again for your time.
Speaker 3:We greatly appreciate it appreciate you guys. All right, thank you bye.
Speaker 2: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.
