Kris:
Welcome everyone to another episode of Dynamics Corner. How do you build an ERP? It's just like building a deck. I'm your co-host, Kris.
Brad:
And this is Brad. This episode was recorded on March 20th, 2025. Kris, Kris, Kris, how do you build a house? How do you build a deck? How do you prepare for an ERP implementation? And you have to listen to the entire episode because they were four quotes that I now put down on my list of quotes as we recorded this episode. With us today, we had the opportunity to speak with Ryan Pollyniak. Good morning, sir. How are you doing?
Kris:
Yo, yo.
Ryan Pollyniak:
Good morning guys. How are you?
Brad:
Excellent.
Kris:
Good.
Brad:
Haven't had the chance to talk with you in a while, but I see you're doing some great things.
Ryan Pollyniak:
I don't know about that. I don't know who told you that, Brad, but-
Brad:
Listen-
Ryan Pollyniak:
... I do stay busy. I know you guys are doing great things. The podcast has taken off.
Brad:
Great. Thank you. Well, it's all because of individuals such as yourself who take the time to speak with us.
Ryan Pollyniak:
My pleasure.
Brad:
We're the boring guys. It's the individuals that we speak with that have a vast wealth of information to share and experiences, which makes it nice.
Kris:
Yeah, well.
Ryan Pollyniak:
Pleasure to be here guys,
Brad:
And we appreciate that. I've always looked forward to speaking with you. I get closer and closer to you every time. We still have to get a hike in.
Ryan Pollyniak:
Yeah, I know. And you have to turn words into action at some point, right? And for me, free time is such a premium with three little girls. They're all in gymnastics. We do that every day but Wednesday during the week, and right now every weekend is a meet. That's it. Busy job in the ERP business and between that and the gymnastics, that is what I do. And I am not complaining, by the way. I do love it. I love hiking too, and you got to make some time for that kind of thing, and I will get up there and go for a hike up there in the White Mountains with you at some point.
Brad:
Absolutely. I like the turning words into actions quote. I'm going to steal that.
Kris:
That's important.
Brad:
I think that on time, everybody says that they don't have time, they don't have time, which is true and everyone has busy schedules. It's a matter of what you do with your time, and I'm happy to see that you're doing it with your little girls in gymnastics because I'll tell everyone, when your children get older, all that complaining that you're doing about the meets on the weekends or the soccer tournament, lacrosse tournament, so whatever you have, you miss it.
Ryan Pollyniak:
That's right.
Brad:
You go through it and you're like, "Ah." It's just a struggle, but you actually miss seeing it. And now I appreciate being able to see others in those tournaments and those meets and I miss it and I appreciate seeing the kids having fun and doing things. I hope your girls are doing well with it.
Ryan Pollyniak:
Yeah, absolutely. And don't interpret it as a complaint. I do love it. I've got the vanity plate coming, which is a surprise. I checked availability. Gym dad is available in Georgia right now in my county.
Kris:
Nice.
Ryan Pollyniak:
I've got like two months until my tag renewal comes, so I check it every couple days. It's still there. I love it, Brad. I mean, no question about it.
Brad:
Absolutely.
Ryan Pollyniak:
You only get to do this for a while, right?
Kris:
Yeah. Short time
Ryan Pollyniak:
Hiking is passion of mine, I love it, love hanging out with you. We're going to make that happen. And I do believe big time in you are what you do, not what you say.
Brad:
Correct.
Ryan Pollyniak:
That was a quote that a guy from my past that I used to know in the business world gave to me and said, "Look, say whatever you want. I am going to, I was going to, I meant to, I plan on. None of that really matters. You are what you do at the end of the day, not what you say."
Brad:
That's two quotes I'm stealing from you.
Ryan Pollyniak:
There you go.
Brad:
No, that is so true. You are what you do. Words means just that, they're words. It's your actions and what you do to stand out. This is all philosophical. Do you get on the balance beam yourself with the girls? Do you get out there [inaudible 00:04:45]?
Ryan Pollyniak:
You see the balance beam? Oh, wait a minute. We do have one down here. So I thought maybe it was in the background. No, not really, anyway. I mean, I've walked across the thing a few times, which I consider a win at this stage and they're doing cartwheels on it and turns and this.
Kris:
That's impressive.
Brad:
I do not know how individuals that participate in gymnastics do some of the stuff they do. I'm with you, Ryan. I think I would just take a win as just being able to get up on a balance beam and stand for a few minutes, never mind walking or doing some of the flips and the bounces. When you see one on TV, it looks like it's maybe three feet wide and you could put a party up there, but when you see them in real life, they're only a few inches wide, right?
Ryan Pollyniak:
Four, regulation is four inches. Right?
Brad:
My foot's not even four inches. I mean, my foot's larger than four inches.
Ryan Pollyniak:
So imagine doing a back handspring, where you're literally launching yourself backwards and landing on your hands on a four-inch wide balance beam. I mean, it's incredible.
Kris:
That's impressive.
Brad:
I cannot do it. I'm very happy that you get to do that with your girls, it must be amazing to watch and hopefully they can do it injury free too. Because I know if I was on that balance beam or hanging on something like that, I'd be in the ER every day.
Ryan Pollyniak:
My eleven-year-old went to middle school on crutches today. She just sprained her ankle, so not too bad. We've been relatively injury free between the three of them, but yeah, it's a concern. But look, you got to take the bubble wrap off and let them live, right?
Brad:
Absolutely.
Kris:
Yep.
Brad:
Absolutely. And they get a lot out of it too. A lot of lessons learned with doing athletics when you're young. But enough of the philosophy. I have two quotes I'm going to steal from you. I'll have to cite you I think on there. Maybe I won't, but at least now we know where we got them from. Before we jump into the conversation, can you tell us a little about yourself?
Ryan Pollyniak:
Yeah, sure thing. Obviously, we covered, I'm a father of three and a husband, first and foremost, family first always. But right behind that is professional life. I've been doing Microsoft Dynamics. I've been in the industry now, it's hard to believe, 17 years, I think I've been saying 15 for the last couple of years. I keep forgetting that the years are progressing. And I've been working with Western Computer implementation and support partner for Microsoft Dynamics almost 10 years. It'll be 10 years in May, believe it or not.
Brad:
Wow.
Ryan Pollyniak:
So it's been quite a while working with companies to understand their needs and to evaluate fit and to navigate the complex world of Microsoft Dynamics, which you guys know is ever-changing, especially in the SaaS world these days. And so I've described myself sometimes as a Sherpa, you've got an executive or you've got a business leader or even somebody who's been assigned in their organization, "Hey, go get quotes and demos for the ERP." That's a tall order for somebody who's not living and eating and sleeping and breathing this stuff. So I take these people under my wing and I say, let me be your Sherpa, let me be your guide. Here's what to look out for, here's what's a fit, here's what's not a fit. Maybe Dynamics isn't a fit, or maybe Western Computer isn't a fit.
And then send them on their way to go work with somebody who may be more tailored to their particular needs. And that's important. Nobody wants to get into things that they're not well suited to help with. And so guiding people through their ERP journey, CRM journey and helping them understand the Microsoft Dynamics stack, that's what I do every day and I do love it. I'm passionate about it, and so consider myself lucky.
Brad:
No, it is, you do a great job. And I appreciate what you say, is you talk with customers, prospects, individuals looking to undertake the ERP journey, and you are absolutely correct, it is changing, ever-changing. I think by the time we're done with this recording, things will have changed from where we started.
Ryan Pollyniak:
Yeah, I'm sure.
Brad:
But I do appreciate, as you had mentioned, is finding the right fit, implementing ERP system, it can be many different things to which it's not so generic. It's what's involved. And finding the right partner or finding the right application to help you or assist you or guide you on that journey is extremely important. And finding someone such as yourself that can take the time to tell you, we may not be the fit for you, or maybe this isn't the product for you, but also this is a product for you and this is how you can determine it's extremely important and it makes for a better relationship. And that's one of the most important things I'm starting to stress and emphasize, because I see more how important it is in this world of where everybody's thinking, I hate to... I don't even want to say it, but where everything's becoming more automated, that relationship and that guide, that relationship and the trust that you have with someone, it becomes more and more important. And it's great that you're doing this stuff 10 years, that's-
Ryan Pollyniak:
A decade.
Brad:
... that's a long time. And then 17 years, I'm trying to think. Man, so I've known you for a while.
Ryan Pollyniak:
It's been a while. Yeah-
Brad:
I'm trying to think.
Ryan Pollyniak:
I didn't have as many grays as I did back then, and that ties back to the three daughters thing. But time flies, it moves pretty quickly. And that part you were just talking about ever-changing, I mean now more than ever, and I try to convey this to anybody looking at ERP. Long-term relationships with an implementation partner, consultant, whomever is going to be your guide here, it's more important than ever because the days of having a product NAV 2005 and you wait 10 years and then you upgrade, it's over. And I mean, this stuff is changing twice a year on a major level and more times than that on a minor level, if you don't have somebody guiding you through the update process, taking advantage of new features and what's your long-term strategy to help me evolve as a company, that is now more important than ever. Because the application changes constantly. So you've got to take that into account, I think as you go, evaluate relationships with technology partners.
Brad:
With ERP software implementations and the changing of implementations, when you're working with customers or even maybe not someone you're working with, what is some advice or some views that someone can take when they're going to, this is such a big question that I'm going to say in a very small, very few words, a small amount of words I hope, sometimes I can ramble. When someone's undertaking their journey to look either for a new ERP software application, or when they're looking to maybe upgrade their new ERP application, I know there's some challenges or some things that someone needs to look out for that they come along the way. What are some words of wisdom or some advice that somebody should go through to undertake that journey?
Ryan Pollyniak:
Yeah, man, we could talk about this one for a while, so let me try to go as basic as I can to start. You have to have a long-term plan and vision. And so what I've heard sometimes is, "Well, we just want to take what we have, and we want to move it into the cloud, and then we'll optimize processes after that." "Let me just look at the next step in the journey and then we'll figure out the rest of the way that we're going to go." I mean, that's a very dangerous thing to do because you're very likely to box yourselves in and prevent yourselves from actually achieving the things that you want to achieve down the road. So it's fine to take a phased approach and to walk and crawl and run and to evolve with how far you're going to take your technology, but you better have a plan that starts at the beginning and has concrete steps that you can then follow.
So let's say for instance, taking NAV to Business Central. Yeah, we have upgrade tools. We can migrate the data, we can migrate the configurations, we can take your custom code into BC, but then you're locked into quite a number of core decisions, locations and inventory costing and dimensions, and all of this data that's in there now somewhat limits what you can do going forward. Maybe you've acquired additional companies and you need a stronger multi-entity solution. Or maybe you have divested companies and you don't need half the mods you used to have. Well, it's okay to walk and crawl and run, but if you're building a ten-story building and you're only building the first two stories now, when you build the foundation, it better be for 10 stories.
Because otherwise, you're going to build two, and then you're going to have to tear the whole thing down and build the ten-story building. So on a high level, that's the number one piece of advice that I would give executives decision makers. As you plan this out, you don't have to do it all at once, don't let anybody make you pile too much into the initial project. That can be daunting, and that can be a pitfall as well, right? Change management is critical. If you change everything at once, you have a lot of internal bandwidth required to do that, you have a lot of change management challenges with people changing everything at once. So you don't have to do that either, but you do have to have a plan and you better make sure that that first step has the long-term vision in mind or you end up boxing yourself in.
Kris:
Does the conversation have to start internally before they even start looking for partners and such?
Ryan Pollyniak:
Yeah, 100%. So how can you make a plan for how we're going to get somewhere until you know where you want to go? And that has to happen internally. Now, it may be valuable to ask for the advice of some technology partners. Don't let them get you into a high pressure sign by the end of the month, signed by the end of the year, get a big discount type scenario because it's not in your best interest. But you can glean some advice from the right people and certainly that needs to start internally. And one part of that is informing the organization very early, and this has to start earlier than most people think that the change is coming. And you can tell people change is coming and "Hey, we are changing our ERP. We are changing our CRM." Anyone who has kids, you tell them to do something, "Go do this." It's the first question they're going to ask for your internal people. What's the first question your kids are going to ask?
Brad:
"Why?"
Ryan Pollyniak:
Why. Every time. So you better be ready to answer that for your people in a meaningful way. We are changing because we're on ancient technology. We can't aggregate data and drive business decisions with our data. We are at security risk because we're at an old on-prem system that is ripe for cyber attack. We're falling behind our competitors, they're upgrading, they're getting their data in order and preparing for taking advantage of all the great competitive advantages that AI is going to present that maybe we don't even know what those are going to be yet, but you better be ready. You can't be on disparate on-prem systems with half your data in Excel and expect to go take advantage of the AI that's coming down the track because we won't be ready to do that.
So explaining the why to everybody in the organization, "We are changing. We're going to go evaluate solutions. Here's why we're doing it." It's important because your people will sometimes have some apprehension, "Hey, we've been using our AS/400, we've been using GP for 20 years. It works just fine. Why are you trying to ruin my life?" I mean, you've got to explain that internally if you're going to have buy-in. So it goes beyond that, it goes beyond just why are we doing it as an organization, but how does it impact me?
"I'm the AP clerk and you're telling me we're going to implement AP automation, that concerns me." "I've been writing paper pick tickets in the warehouse for 15 years and you want me to use a scanner? Why am I doing this?" "I'm a salesperson who has this great notebook with all my notes on it and I don't need a CRM." You have to explain, "Well, here's what's in it for you. You have all these notes in your notebook. If you can get that into a system and allow it to prioritize your tasks for you and track your notes and update you when it's time to contact somebody and prioritize which opportunities might be most viable, it's going to, it's going to help you close more business. It's going to help put money in your pocket."
Just as an example on the CRM side, right? People need that. "What's in it for me?" WIIFM, if you guys have heard that acronym, like "What's in it for me?" And you have to always put yourself in someone else's shoes and think of it from their perspective. "Why are we changing as an organization? It works fine." "Well here's why." "Well, how's it going to impact me?" "Here's how it's going to impact you. It's going to be positive." So I think those are some definitely, to answer your question, you've got to start that conversation internally very early.
Brad:
That is so important and often overlooked, because some of the most successful implementations I have seen have been those implementations that included the individuals that are going to actually go through the journey with them because they have some, what do the people say? User adoption or user acceptance, in a sense. Because if they understand and they feel if they're part of it, they're going to work better to help make it successful and understand instead of being apprehensive and maybe potentially having, as you had mentioned, maybe some fear of the new system because they have been using that AS/400 system for 15 years and now you want me to use a new system, I'll be uncomfortable like the fish out of water as they kind of say. So now what's going to happen? I'm not going to be able to do my job.
Kris:
A question on that, when you're talking about change management, what is it for them. Who should deliver that message? So especially when there's a big change coming and you're going to have to talk to individuals or individuals that is going to be affected by this change, who should deliver that message?
Ryan Pollyniak:
In my opinion, the first message should come from the top. It should be, maybe it's an email, maybe you have a monthly or quarterly company meeting with everybody on board and you're updating, "Here's the status of the organization and here's where we're at." And we do that internally and our CEO Kristen leads that. She talks about the big things first, right? "Here's where we're going." She's the captain of the ship. So where are we going first of all, in general and why I think that message best comes from senior leadership, maybe even all the way at the top. If we were going to make that change internally, I could tell you right now, Kristen would be the one to announce it. "Here's where we're going guys." But then some of the more granular stuff, "How does it affect me personally?" That probably needs to come from someone who more directly manages your role, your direct report maybe or somebody, maybe a sales VP or a marketing VP or COO or somebody one level down to, "Hey, let's disseminate this on a more granular level."
But the why is also probably important to come from the top. It can't be, "Hey guys, we're moving off of our AS 400. We need to get on a cloud-based system, so thanks for coming." It can't be that, it has to be all the things that we talked about. "Here's why. Our competitors are getting ahead of us. We're not able to take advantage of our data. We have security risks. We're all in the same boat literally together as an organization. So here's why we need to steer it in a new direction from a technological technology stack foundation, from a technology stack perspective I should say." And that should come from the top. But then as you get more granular, "Well, how is it going to impact me personally?" "Also, how are you going to empower me to use this new stuff?" And that's a big part of it as well.
"Am I just going to be expected to watch a few YouTube videos? Are you going to give me hands-on training? Are we going to have consultants on site when we go live?" Those things are going to be going through your people's head. So after you get through the here's what we're doing and here's why we're doing it and here's how it's going to impact you, well then it's here's how we're going to help you succeed in doing it. That part of it comes next. I mean, how are you going to empower me to do it? So that's probably not the CEO actually telling the AP clerk, here's how we're going to help you do it, or here's how it's going to impact your particular job. That's a few levels down, I would say.
Kris:
I love the clarification in that because you are right. The first message should come from the top executive, either the CEO or somebody at the C suite or VP level that can relay the message of why the big change is happening as an organization and where the company is going. And you clarified that from the individual standpoint of what is it for me, it needs to come from their direct, who they directly report to because then they interact with them more than they interact with the CEO. So I appreciate the clarification. There's always been kind of confusion of who should be delivering that message for people that uses the application all the time, how is that going to affect my job?
The director or the supervisor should be working with them and they have to be on the same page. They have to believe this change is important for the organization, so when it trickles down to that individual person, they don't feel like they're alone, they're hearing it from their direct supervisor, this change is amazing. So someone has to champion that change as well. It has to go all the way down your supervisor so that your people that are using it, they don't feel like, "Oh crap, I should be looking for a new job." Or something like that.
Ryan Pollyniak:
Yeah, absolutely Kristopher. And there's one more level there where the CEO has to be aligned with the next layer of management. Because you can't have each manager making their own decisions either. We're still pointing this ship in the right direction, we're going to The Bahamas one way or another, and if one department wants to go to Bermuda and one department wants to go to the Key Largo, that's not where we're going. So that CEO has to empower their managers to say, "Here's where we're going guys and here's why and here's how it's going to affect you." And that is critical. I remember a project recently where there was one individual who was very used to doing things a certain way for quite a long time, and when the project started unfolding and we started explaining, "Well, this is how we're going to do it in Business Central." There's an immediate roadblock. "No, we're not going to do it that way." Is what the comment was.
And I was having this conversation with the project manager the other day, that's very dangerous. And she said, "No matter what, we're doing it, we've got to do it this way." Now this is someone who is one or two pegs down in the organization throwing up a roadblock. That's a red flag in a project. So as a technology partner, we owe it to senior leadership to align with them and say, "Hey, your person's asking for this. There's a perfectly reasonable way to do it with out of the box software. They want us to do a modification that's going to cost quite a lot and really kind of cause long-term care and feeding as these updates come out."
And philosophically, we're totally against customizing the system in order to meet everybody's unique needs, there needs to be some adoption of best practice. So it's our job as a technology partner to raise that concern with the C-level executives and say, "Hey, here's what your person's asking for and here's what we're telling them and here's why writing a bunch of custom code to do it exactly the way this one person wants to do is a bad idea." So that goes along with the change management. If you want to control timeline and budget in a project, it's the only way to do it.
Brad:
Yeah, the individuals, and I thank you for pointing that out because it's important to have awareness of what's going on also at the levels of the implementation as you had stated. That's one of the questions I actually wanted to speak with you about is, how can you handle or prevent that? And you had mentioned from the technology partner point of view, bring that information to the leadership team or the stakeholders for the project. What about internally? Is there something that you could suggest within the change management process to help minimize the roadblocks that may sometimes derail an entire project? Because you can't have one or two people that create such a challenging roadblock either through modifications or saying that they're incapable of doing their job now because of this and it can cause some problems for an implementation and for an organization.
Ryan Pollyniak:
Yeah, absolutely. So all of these change management aspects kind of build on doing that, but when it comes down to it's about communication and explaining to an individual. This should come from that individual's boss probably or direct report depending on your organizational structure. Here's why what you're asking for is not in line with our vision that our CEO laid out on the company meeting two months ago. It's going to be costly, it's a software as a service, it's a cloud-based solution that's updated two times a year. So they may not know that, right? They may not know the why behind it and they may not understand why it's a pitfall. So you have to be prepared to have the conversation and communicate effectively. So I'm going to give you another quote here, Brad, and this one I love, it's my favorite in all walks of life, but especially in business, the main problem in communication is the illusion that it's already happened. So if these people don't know-
Brad:
Look at, there's three.
Ryan Pollyniak:
... why it's a bad idea... There you go, it's three. So if they don't know why it's a bad idea, they're going to push back harder. But again, getting down to the why and not assuming that they know customization's an ERP pitfall and we want to leverage best practices and it's going to cause problem with updates and all of these other reasons that the three of us, and probably a lot of the people listening to this podcast already know that these are pitfalls, well, this person who's asking for this modification to make the system do exactly what their old system did for 15 years, they don't understand that. They just say, "Hey, this is how I operate. I need the system to do it." And they cross their arms and stomp their feet. Explaining the reasoning to them and communicating what you already know and you live, eat, sleep, and breathe this stuff every day as an ERP pro, they don't know that stuff. They're not an ERP pro. This is the first time they've been through an ERP project ever, maybe, or maybe they did one 15 years ago.
So I think that that's where it comes in. If you want to break down those barriers to change this method of announcing it, here's why and then here's how it's going to affect you. And no, we're not going to rebuild the old system and here's why we're not going to rebuild the old system. That's the only way to break those barriers down. And hey man, I've seen it, we've gotten projects that have gone back to Microsoft and they say Business Central's terrible product or the partner blew it. Maybe it could be one reason or another. And then Microsoft, sometimes they'll bring those projects to us, we've been doing this for so long, and we'll get a hold of it and we'll say, "Where are you in the process right now?"
Before we can help you, we need to understand where in the process your company is and what broke down? And sometimes the users haven't been in the system until it's time for UAT. That is a big problem because all of these things that we've been talking about are going to rush to the surface as you're trying to go live, as you're trying to prepare to go live. So it needs to happen, to go back to what Kristopher asked earlier, way before the project even begins, internally that alignment needs to happen, and you got to get the users in the system early and let them air their grievances and then explain the why and here's why we're approaching it a certain way and how they're going to still achieve their same business processes maybe through a new method following the best practices that the system allows them to do.
Brad:
Yeah, that's so many things that are going through my mind, and I was speaking of UAT and user acceptance testings. One of the challenges of the questions that I hear or see when someone's switching to a new system, and I use the word switching loosely there, it could be moving from another ERP software system to something in the Microsoft dynamic stack or even upgrading from a previous version, is the users have a full-time position now working with their application or in the business to get orders shipped, to get vendors paid, whatever their function may be within an organization. What is a good approach to giving them the opportunity to get into the application and be able to work with the application while still functioning within the business? And how much time should someone expect to be able to or should they allocate for someone to be able to work with and be comfortable with the system and its infancy and then back when you're in the UAT phase, just about to go live?
Ryan Pollyniak:
Yeah, I mean these are great questions. So you nailed the number one thing that you need to do to allow users to get into the system, and that's provide them the time to do that. I wouldn't recommend starting an ERP project or finishing one during your busy season. If you have seasonality in your business, you need to talk to your technology partner about where are the subject matter expert's going to be needed. Is it on the front end? Is it on the back end? Is it in the middle? And typically I find that that's on the front end and the back end more so than in the middle where we're building the system. If we're doing custom development or integrations or configurations, those decisions are made through analysis sessions and design sessions on the front end and then they're solidified on the back end in deploying the system and prepping for go live, testing and training.
And that's where your heavy usage is going to be. So I find that if your people are already maxed out, you can't put an ERP project on top of them to add to what they're already unable to keep up with. And that may mean bringing some temporary help on, that may mean prioritizing projects and doing things one at a time. So along those lines, I've found hiring temporary help or even semi-permanent to permanent help is better done to backfill the day-to-day jobs of your people and let them, the people who are going to use the system long term focus on the project. If you're going to staff up for a project, right? Don't staff up and have temporary people working on the project, this is what you're going to be living with for a long time. So if you're going to have to increase staff to do a project, I would say backfill the mundane stuff, the day-to-day and then free up your people's time to focus on a very important investment in your [inaudible 00:34:08] man.
It is an important investment. It's costly, it's risky, it's time-consuming, it can make or break some businesses. I mean, you've got to invest the appropriate amount of time to do that. Now, that does vary by job role. You're going to have your subject matter experts in each area that are going to really own the processes and under normal methodology they will be disseminating that information later on to some of the other end users. So it's not as if everybody in your organization needs to dedicate percentage of their day, your subject matter experts though, you should probably plan on the front end of a project and analysis and design 25% of your day, if you're a subject matter expert doing an ERP project. Maybe a little bit conservative, but I mean that is at your own peril. Now, if you're the internal project manager for a client, which is a critical role, and sometimes this comes as a surprise to clients who are perspective clients who are saying, "What do you need from my people?"
"Well, we need someone to be an internal project manager." "Okay, I thought you guys were going to manage a project." "Well, yeah, we are. We're going to manage the budget and we're going to manage the resources and we're going to manage risks and team morale and track the timeline and track issues, absolutely. But we need somebody internally to manage your people and make sure that your people are available to take part in analysis sessions, to take part in design sessions." Somebody at that PM level should be empowered, whether it's directly or through direct access to the decision makers to make those design decisions and not stick a project in neutral as we're making these decisions, I've seen it happen. I had a project, they were very passionate about the end go live date. There were some critical reasons they wanted to go live. The project got stuck in design for eight weeks on one decision where the whole solution pivoted on it, right?
If you don't have somebody empowered to quickly move this stuff, there's no partner in the world that can control your timeline. I mean, we were waiting for them for two months. And that goes both ways. But I would say that empowering that PM internally, and that PM better have 50% minimum of their time devoted to the project for the duration. And if it's a big company with a big project, it should be dedicated. I mean, this is business critical stuff. So SMEs maybe 25% on the front end of the project, 25% and on the back end. As you approach go live, that might ramp up a little bit. You're going through UAT and you're really getting ready. PMs, this should be their main focus. The internal client-side PM who's going to herd the cats on the client side, so to speak, and make sure everybody's doing what they need to do, that should be their sole focus really during a project.
Kris:
You made a point there about giving them time to work on this implementation of bringing a brand new ERP. And I did a session on this early this year, beginning this year or even late last year in some of the conferences. And one of the statistics I've found, I think through oak.com that focuses on change management and in the effects of change management, if you don't do it, it's stated that 75% of employees that are going through ERP implementation or even changes in the organization suffers from moderate to high level stress. So think about that when you don't give them time to work on this ERP implementation, 75% of your team members or employees that are part of that project are stressing out. And interestingly enough, that 18% of that, also the same statistics here, same source, 18% of that leave work or quit during an ERP implementation.
So nearly 20%. So if you have 10 team members, two of them is going to more likely going to quit if you don't have proper change management. That's very important to consider. And if they do leave even one person leave that's critical to that group, that will take you back. That's going to push your project a little further. Now you got to find a new subject matter expert or even the person that is supposed to help decide of how you're supposed to architect your business process leaves, that is a significant loss to a project.
Ryan Pollyniak:
Yeah, no question. And think about everything you've invested in freeing that person up and paying consultants to work with them and they've built up all this knowledge and they've provided all this insight and then they get burnt out and walk out the door. Yeah, Kristopher, great point. I mean, that's a massive business impact. Think about the cost for something like that. It's hard to quantify, but it's huge.
Brad:
The stress is important, which goes back is, you're going through the process, what type of feedback system or support system do you see helpful in an implementation during post and pre and then also during the UAT phase of an implementation?
Ryan Pollyniak:
So are you talking about an internal feedback system for the client or maybe between the client and the partner?
Brad:
I think both. Because we're talking about the changes that an organization's going to undertake and change will occur at all levels of it. It'll be the individuals that are at the executive level, the individuals that are doing the task in the various departments. And we talked about how someone could be a roadblock. Kris had mentioned about stress levels within there, and then also if someone's going through it, then we're looking for user adoption. How can we enhance or what can we put in place for a feedback loop and a support loop to help minimize the challenges that we're going to have through an ERP implementation?
Ryan Pollyniak:
Yeah, sure. So between the partner and the customer, I'll start there, you've got to have a cadence of status, right? Status meetings, stand-ups, could be a SteerCo meeting. Not every organization is big enough to have a SteerCo. A SteerCo, essentially what it is, you have the key decision makers, the key executive sponsors the project managers on a meeting, and you're providing, the whole point of it is candid feedback. Now, in a status meeting, it might be a bit more granular, and so for instance, ours, it's how we color code it. How are we doing on timeline? Is it red? Is it yellow? Is it green? How are we doing on budget? What are our risks? And then how are we doing on team morale? Which is what we're talking about here. What is the pulse of your people right now? And that's a subjective conversation typically and very commonly, that conversation starts with our team providing feedback to leadership the client on, "Here's what I'm getting from your people, and I'm sensing some pushback on a certain process."
Like the example I gave earlier, wanting to modify to meet a particular use case that could be better handled out of the box. That's a red flag that has to be raised, and it goes back to communication in a status meeting, and those should be common every two weeks at a minimum, let's get together, let's talk about the risks and let's talk about the timeline and the morale. Let us tell you what we're seeing and hearing and you tell us what you're seeing and hearing from your people. Now, the SteerCo's a bit different, it's somewhat higher level, maybe once a month, maybe once every two months, and that is okay on the executive level, here's where the project's going. We're generally pointing our boat in the right direction, and maybe at that point, "Hey, we need some more executive level change management to help us through this process if we're going to help you." That's a conversation that I've had many times coming from analysis into design. "Hey, we need to control the budget here."
"Okay, well, if we're going to control the budget, we need your help to help your people understand why we're doing this the way we're doing it, why we're not rebuilding the custom Salesforce application that's been in place for 15 years." And it's just right in line with everything we've been talking about. Now, internally, obviously your people have to have some type of forum to talk to your internal decision makers, project leads. That could be the project PM as kind of an initial stage like, "Hey, here's my concern, here's what I'm feeling." And I would say, not only empowering people to do that, maybe you have internal meetings every other week. How's the project going? Maybe it's a survey. Send a survey monkey out and say, "Well, what are your feelings on the project right now? What are your concerns?" And get that feedback internally.
You have to not only empower people to do it, but you have to encourage people to do it. You have to maybe incentivize them some way, "Fill out the survey, get a $10 Starbucks gift card." Whatever it might be, or again, goes back to explaining why. "Hey, we need to hear what you're feeling on this project because we don't want to continue to go down a path that's causing angst. We need to know though." And so you've got to provide a forum internally, you've got to provide incentivization or at least encouragement, "Hey, give us your feedback on the project." And then once you get that as a PM, you can in turn communicate that to your project team through the status meeting or through the steerco and provide that, "Hey, here's what we're hearing."
And then you match that up with the partners who typically consultants can be pretty opinionated, and that's for good reason. These people are professionals, they've done sometimes a hundred projects or more in their life and they've seen this kind of stuff happen and they need to say, "Look, here's what we're seeing. I'm seeing a red flag here, I'm seeing a red flag there." And it goes back to communicating with each other. You can't assume that one party knows what the other knows because usually it's not the case.
Brad:
That's some good... I'm listening to what you're saying and so many things are going through my mind and so many experiences that I've had that go along with what you're saying and where some challenges and some roadblocks that come in implementations. As we've been talking, and I started to think about this because you talked about budget, you talked about go live dates, you talked about changes to an organization. How can one or what's the advice to be able to properly plan the timing of an ERP implementation and the budget of an ERP implementation? Because there's some variables in there, in my opinion, going through some projects, and I'm just looking for maybe some insights from you. You have individuals that need to train, you have individuals that need to test, you have designs, you have testing itself. You may have some remediation because something may not work as they originally intended, or they may find that the process could be slightly varied for bigger benefit.
What's the best approach to take to be able to, one, plan the budget, two, plan the duration to be able to determine when to go live? Because it sounds to me, "Ryan, build me a house, it's two stories, two bedrooms, I want to move in next week." And some people think that, "Oh wow, okay, you can just do it. It's ERP software, just install it." What are some realistic expectations or processes that someone to go to get a good sense of what it takes so that they don't go over budget, they don't have a late implementation. I know challenges arise, but I look for the realism.
Ryan Pollyniak:
Yeah. The house analogy, I can't help but bring up something that our relatively new VP of sales, Ben Bolte brought up the other day when we were in our internal sales marketing retreat. And he said, :If somebody asks you for a budget..." He brought up the house analogy that you just did. He said, "Well, I can build you a two-story house brick with three bedrooms and two and a half bathrooms. Here's roughly what it's going to cost. What I can't control is when your wife comes and says, 'Well, here are the faucets I want and here's the tile I want and here's the flooring that I want.' And that's what your job is as a leader to control those type of nice-to-haves and peripheral type stuff." So the tendency when there's a big change is to say, "Okay, we're changing guys. We're on GP, it's end of life, we're going to Dynamics 365." And then everybody from every department says, "Well, here's what I want. Here's what I want. Here's what I want. Here's what I want."
Because they think that's their only chance, and that can absolutely impact time. I mean, not can, it dramatically impacts time and budget. And so focusing on why you're making that change from a leadership perspective and reining in the, I want this, I want that from each department, is really important in the first stage, assuming that there is a target timeline and there always is a target budget. You've got to say, "Well, hey, listen, we're using GP for counts receivable or, accounts payable and GL. And yeah, maybe we want to use it Dynamics 365 for more." Maybe we want to expand it into the operational side of the house and maybe we want to have a vendor portal and connect our e-commerce website. Well, if timeline and budget are constraints, you say, "Let's focus on what we need to do first. Let's get GL and AP and AR into Dynamics 365." Could be Business Central, could be F&O. I've seen GP clients move to both.
Now, I'll caveat that and say you do, like we talked about earlier, if you're only going to replace one for one what you have now, need to have the long-term goal in mind and make sure that you're setting that proper foundation with a roadmap. And that might mean a heavier analysis and design phase where you plan everything out and then you deploy your core business reason. Why did we make this change? Yes, your marketing person's asking for automation and your sales VP wants CRM integration, but you don't have any of these things now. Maybe your... I've seen people, I mean I know you've seen it guys like, "Hey, how are you managing your production schedule?" Whiteboard Excel. Okay, well we have to have it in phase one. Why? You're doing it this way now.
So focus, why are you making this change and let's do that and let's absolutely plan for the rest and execute it in chunks and phases if need be. Here's what it looks like if we do it all at once timeline and budget-wise and here's what it looks like if we kind of chunk it out. And maybe there's a business-critical event coming. That's what I always try to get down to. So here's what I hear. I want to go live January 1st. And I ask this question every time I hear that, and I typically already know the answer. What do you typically hear around that? Do you ever hear that? Need [inaudible 00:50:28]?
Kris:
Oh, yeah.
Brad:
Oh, January 1st? Oh, I hear that all the time.
Ryan Pollyniak:
And the reason is typically, "That's when my fiscal year ends."
Brad:
Yes.
Kris:
Yep.
Ryan Pollyniak:
Which to a consultant implementing this stuff does not matter. We have done over a thousand projects at Western Computer. Very, very few of them have gone live January 1st. First of all, I know everyone's fiscal calendar is not January 1st, but going live on the fiscal year is not important in an ERP project. We can absolutely, we have tools to do GL, true ups and net measure, net change. We can navigate that and do navigate that on every project. And so that is not really a valid reason to constrain your organization around an arbitrary timeline. People think it is, but it's not.
Kris:
It affects your people. By the way, January 1st is around the holidays. It's screws that everyone up that don't want to go to work.
Brad:
It's the worst time because it's-
Ryan Pollyniak:
The worst time to go live really.
Kris:
It is, yeah.
Brad:
You have vacations, you have holidays-
Ryan Pollyniak:
Yeah, you're right Kristopher. Absolutely.
Brad:
... people being stressed out about gifts and stuff. So you saying January 1st, Kris and I had this conversation recently about that. It is, you just have to pick a realistic date and think of the other constraints that are also occurring. And if January 1st is the date, there has to be a reason other than, "Oh, it's the best time of year to do it." Or "It's our year end." As you had mentioned.
Ryan Pollyniak:
Yeah. So if you put those arbitrary constraints around your project, you're not going to make the most efficient decisions for your organization. Now, maybe on the other hand, you've got a more real reason, maybe my renewal for my ERP application is coming up and if I go past August 31st, I'm going to be automatically signed up for three more years and I need a system to run my business. That's a situation where you really need to boil it down to requirements. We call it the MVP deployment, minimum viable product. And what do I need to make happen and how do we work together? Because it cannot be all partner, guys. I mean, this is a two-way street. What do we collaboratively need to do to make that date happen? Because that's a real date. Or I've seen, if you've ever heard of a TSA, which is essentially an agreement when you're divested from a company and they say, "We are going to give you a TSA." I forget the acronym technology services agreement or something like that.
But basically what it does is it says, okay, we're spinning your company off and you could stay on our systems until X date. That's a real reason to have a hard and fast go live date, you're not going to have a system to run. Or maybe there's some exorbitant fee or penalty you're going to have to pay if you go past that date. Fiscal year is not one. So don't constrain yourself based on that. But some of these other reasons, if you have those dates, you have to be willing to boil it down to business critical, what do we need to go live? Don't shortcut yourself and box yourself in by forgoing the long-term vision. That still needs to happen, but then the nice-to-haves and the peripheral stuff and everyone raising their hand and saying what they want, that's going to have to wait in those types of scenarios if you want to control the timeline and budget.
Kris:
I love the, sorry, Brad, I love the analogy of building a home. Brad and I use that quite a bit. But a quick short story of using the deck analogy as well. It's not just analogy, that's what I'm going through right now. Setting up a timeline. When I bought this house has a pretty huge deck, I think Brad's seen it. It's almost 1600 square feet deck. It's massive. And its house is built in early '90s, and so we have to replace it. Does it still work? Absolutely. It's like an ERP system, like current ERP. Can it still work? Yeah, it could still stand on it. You still hosts, things like that. But eventually you're going to have to replace it, and because of safety reasons and things like that. So when you're budgeting stuff like this and ERP implementation similar to I'm budgeting a deck, we have a range and then, but you also don't understand, you don't know the underlying issues as well.
So let's say they start taking it apart and they realize, ah, you may have to change some of these beams and so forth. So you have to consider those got yous and maybe a little bit of leeway, maybe 10%, 15, 20% of budget overrun, which is, by the way, it's common in ERP implementation, there's always going to be an ERP budget overrun. But I had a timeline in mind. It is like I want to be able to enjoy it in the summer. So I'm asking these guys now I'm becoming some clients, I'm becoming like that. "I need to get this done in two months because summer's around the corner, I need to be able to enjoy this thing."
And they're like, "No, that's not realistic because you may have some permitting and all that stuff." So I have to remember, it's like maybe a good time is to get it done after summer where it's not much quieter and I can actually make some changes along the way. Like you said, my wife wants to have better railings and stuff like that. So those things to consider as well. But budgeting is really, really tough, but you have to give a little bit of range and plus minus depending on changes.
Brad:
Budgeting and scheduling is a challenge for the points you make. And I do, I always say ERP implementations is a house build or house remodel, and you know what you want and you have to figure... And Ryan, you hit on some other key points. The partner works with you through the implementation, but you live with it after the implementation. And a lot of implementations I see have struggles. They put a lot of it more onto the partner. Now the partner can guide you, the partner can do the work to help you get it running, but they're not there using the system day to day, nor should they be because they're there to help you implement. So your comment about the partner working with them, but it's their system that they have to accept and to use to going forward is important. And I had a million other things I wanted to say, and as usual, it goes right outside of my brain.
Ryan Pollyniak:
Well, I love the deck analogy. I mean, house analogy, take your pick. But I'm thinking, Kristopher while you're explaining the deck, I'm thinking what is the risk if you don't do that? And that is very much akin to somebody on an old on-premise SQL server. I've seen it happen, on-premise servers are ripe for cyber attack guys, and I've seen it several times in the middle of deciding how are we going to do ERP, how are we going to get to the cloud? Hacked, can't ship, can't invoice, can't pay vendors. I mean, business ground to a halt. And the cost of that is tremendous. So don't wait until the deck falls off the house.
Kris:
Someone could get hurt.
Ryan Pollyniak:
It's too late. It's too late, right?
Brad:
It's absolutely true. I've seen that an implementation with somebody, they did, they had ransomware on their system during an implementation because of whatever reason, and they had to spend a lot of money getting their system intact before they could even do the implementation. The other key point that you made too, was again, with the house analogy and what I liked, what you had is do what you need to get the business operational. All the stuff that you may not be doing now, have a roadmap to get there because they could delay you. You're already going through enough changes as it is through a new system that if you can keep some of those workflows in place with the understanding that you're going to gain some efficiencies, obviously there's a reason why someone's switching, like you had mentioned.
It could be because, like you had mentioned, if you are not going to have system, if you had grown, if you're looking for operational efficiencies, a number of different reasons why people switch, but having that roadmap is extremely important because these, "Oh, I can do this. Oh, I can do that," as you're going through an implementation, it throws the entire implementation off, and I have seen it because they see all this cool stuff that the new system has that they don't even do today. Not to say that they can't grow, or their business can't change their processes to utilize those new features, but the more complexity and changes that you add to it, it can also slow down the implementation. So you're-
Kris:
They get hung up with the appliances, Brad, that's what takes forever.
Brad:
Exactly, and they forget that the roof still hasn't been put on and it's leaking. And they're tied up about the appliances which can go in after the house is built.
Kris:
Exactly.
Brad:
Even after you move in. See, I use the house model and remodel with everyone I speak with for these reasons. Because you can move into a house and have shiny appliances afterwards, but you still can have a little portable refrigerator to keep things cool as you're moving into the house and you're filling it out.
Kris:
But that's what we deal with, right? With the ERP somehow, everyone's already want to know what kind of couches and appliances they want to put in there and all that and how it's structured.
Brad:
Well, they get excited. So you can put a picture on the wall of the couch and all this other stuff and say you'll get there, but let's not lose sight of, we need to move in and get there. Speaking of all of this, we think about user adoption, we think about ERP implementations. How can you measure user adoption? And also, what is and how do you measure a successful ERP implementation?
Ryan Pollyniak:
Those metrics have to be identified ahead of time. And they're different. ERP is different than CRM. I know you guys are ERP guys, I kind of span both, and just to touch on that briefly, I will say ERP user adoption is easier to drive. Because it's required. You've got to ship, you've got to invoice, you've got to pay your vendors, you've got to receive your inventory, or you can't run your business. CRM, you better have a plan to have adoption or it will sit and collect dust and you'll have an expensive Rolodex in a digital format. So establishing metrics ahead of time. What do we hope to get out of this implementation? Do we hope to decrease our day sales outstanding or optimize our inventory so that we don't have inventory that's sitting unused, which has a cost? Or we don't have sales that can maybe not be fulfilled because we don't have enough inventory. Or maybe we want to be able, if we're a manufacturer, I hear this all the time, we want to be able to measure our availability to promise.
So somebody calls and says, our sales team and says, "Hey, I need a widget by July 1st, six weeks from now. Can you do it?" "I don't know. Let me go consult the whiteboard." Right? Well, all of those parameters are able to be set up in the ERP, and if your goal is to achieve availability to promise the tools are there in any modern ERP, not any but Dynamics certainly. And if the inputs aren't put in, vendor lead time and capacity on the shop floor and planned production orders and all of this data needs to still be input. I was sitting in a conference room a couple of months ago, I'm not going to say where because that might give my customer away here, but we were going through all of the ways to calculate availability to promise for them, and they said, "Oh, yeah, yeah, we have that in our system now."
"Okay. Then why aren't you available to promise?" "Well, we don't input any of the data. You don't use it." Okay, a system's not going to fix that. Guys, you've got to mandate this internally in some way. We can't make your people do it. We could teach them how to do it, but defining some kind of metrics and goals, KPIs, whatever you want to call them, like, "Hey, our goal coming out of this is to be able, when our salesperson asks us for an availability to promise a widget delivery, that we can actually give them a concrete number." That's more of a vague KPI, metrics like we want to reduce our inventory on hand by 25% and still be able to fulfill our sales goals.
That's more of a hard metric, but those should be established ahead of the project and then measured after the project. Maybe there's some kind of incentive tied to it, bonus structure, some kind of performance measurement, maybe not, maybe it's just more of a team effort. "Hey, here's why we're doing it. We want to be able to have a higher level of customer satisfaction, and we can't do that if we're just guessing at availability to promise and hoping that it works out." Hope is not a strategy. There's number four, okay?
Brad:
Hope is not a strategy.
Kris:
That's your fourth quote right there.
Ryan Pollyniak:
Hope is not a strategy.
Brad:
I have to write all these down. When I watch this afterwards, I'm going to write all these down. I've been trying to get to them, but you're going too quickly. The planning is so important and you hit that even for the measurement of the success because that way you can say it's successful. So if you look back, if someone says, "Oh, we're late." Or "We're doing this." Or they feel it's worse than it was, I've gone through implementations like that where they lost sight of that it actually is successful because they may have had some challenges along the way. Not saying it was a bad experience, but that planning is worthwhile. And just like building a house or cutting wood, all that planning upfront saves you in the end. Sometimes people want to cut corners to speed things along or to save a dollar or two, but as I always tell Kris, they don't have the time to do it the first time, but you have the time to do it three times after you go live or even spend months fixing the data afterwards.
And to your point about you can't get something, systems are a tool that you use, systems aren't going to do things for you. Because I hear these requests, "Well, I want to report that tells me this." "Well, you need to enter the day, you have the data." "I don't have time to enter the data, I just need the system to tell me this." I can't tell you how many times I hear similar scenarios, and the reality is it's a tool for you to use to become more efficient or to get an output, not do the output for you. Well, maybe in the future it'll do everything for us and we don't need to do anything.
Kris:
Yeah. I love the house analogy all the time. It's like putting copper pipes rather than PEX. PEX is better, but hey, we got to do copper because that's what we've always been using.
Ryan Pollyniak:
Yeah. Why not just build all the house though and then switch out the pipes, Kristopher, right? So you do have people who do it.
Kris:
Yeah, I know, right? That's what people do.
Brad:
It's true. They're in the drywall already or in the brick already, so we've got to take the whole wall down as well, because you want to do that.
Kris:
You put the wrong pipes in.
Brad:
Well, Mr. Ryan, sir, and also don't cut yourself short on that. You do CRM and ERP, but you do so much more. You deal with Business Central, F&O, F&SCM, FX, whatever they call it today, CRM, a little of the Azure stuff too, so you do quite a bit and you quite knowledgeable and I appreciate all the information that you share with us. And I appreciate you taking the time to speak with us today. Time is truly the currency of life and any moment that someone spends with us is a moment that they're not doing something else. We appreciate it and we value that. If someone would like to get in contact with you to learn more about change management, ERP implementations or how they can become, have some more enhancements or features through their ERP implementation project or how to even come up with an ERP system to use, how can someone contact you?
Ryan Pollyniak:
Yeah, sure. So LinkedIn is tried and true. There are not many Ryan Pollyniaks out there on LinkedIn, so you can find me pretty easily there. You can email me at first name dot last name, ryan.pollyniak@westercomputer.com or come through our website. We do have a chat that admittedly the very first chat is about, "Hey, Brad, thanks for coming by. Can we help you?" The second that you put something in the chat, you're going to get one of our sales team who are all season pros and they'll be able to answer your questions and guide you and be your Sherpa along this journey.
Brad:
Absolutely. You do have a great sales team over there and a knowledgeable staff that can... A team, I guess you could say, that I can help someone guide them through the journey. Again, thank you for your time. We appreciate it and I look forward to getting hiking with you after your girls get older and they're done with a gymnastics career.
Ryan Pollyniak:
We'll try to squeeze it in before. [inaudible 01:06:56].
Brad:
Absolutely. Thank you again.
Ryan Pollyniak:
Thanks, guys. I really appreciate it.
Brad:
I look forward to seeing you soon. Thank you. Ciao. Ciao.
Brad:
Thank you, Kris, for your time for another episode of In The Dynamics Corner Chair, and thank you to our guests for participating.
Kris:
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 dvlprlife.com. That is D-V-L-P-R-L-I-F-E.com, and you can interact with them via Twitter, D-V-L-P-R-L-I-F-E. You can also find me at matalino.io, M-A-T-A-L-I-N-O.I-O, and my Twitter handle is matalino16. You can see those links down below in their show notes. Again, thank you everyone. Thank you and take care.
