AJC ERP Implementation Overview

Hi, I'm Andrea Jones and today we are going to start our conversation on ERP implementation. There is a lot to do when implementing a major system like an erp. A lot of people call this a digital transformation and so you would like to be prepared. In this next series we're going to go into detail about each of these steps, about roles, responsibilities, timeline, change management, various things. But here in the overview, let me give you a high level picture of what we see typically and drive as project and change managers with an ERP implementation. To catch you up, we have already gone through a great selection process. Please feel free to watch the videos on that. It includes the role's responsibilities and how long it typically takes to select a good ERP system for your organization. We talked about negotiation considerations you want to bear in mind as you're working through the contract with your vendor, who will be your partner for a long time. So it definitely has to be a win win contract negotiation process and kicking off the communications and the change management as you finish that selection and head into implementation to make sure your whole team, all of your end users, are up to speed on what they need to know at the appropriate time. So no one, you know, to use a technical term, freaks out, right? So now you're in the implementation and the first thing that you really need to consider is pulling together your team, your implementation team and setting expectations. So these are the people that are going to be doing the implementation on your side. They may not be the high level people who made the decision on the steering committee for the selection. Maybe a level down and that's totally acceptable and they have some time to do this. We'll talk about that a little later. As well as the vendors team, they'll typically switch from their technical sales team to their implementation team, which includes a project manager for them and some analysts on their end. Their project manager is not intimate with your team. They'll be checking in with you, but they are really driving the work on their side. So that's something to keep in mind. You might also have a customization or two where there's a development team, typically through the vendor, or maybe a third party and maybe you're integrating different additional solutions like a build.com and Avalara or some sort of warehousing or CRM software, things like that. So they might provide some team members. If people come later, you determine some of this is needed later, I would bring the team back together and reset everyone on the goals, objectives, roles, responsibilities, milestone schedule and what your working norms are As a team, you know, for example, you're going to meet weekly and you're going to send updates on your action items the day before a meeting or something like that. Right? Like not acceptable to let things slide in your world, most likely. Okay, so you pull the team together, the plan together, and then you're going to drive a technical process. The project manager will be driving this. So there's a lot to do. You know, there's data migration that needs to happen. All of your customer data, your supplier data, your inventory data, your parts data, your production data, you know, whatever you're making or shipping, all of that data. And then you need to worry about configuring the system, getting it set up the way you want to. If there's any new things to be built, a customization that needs to happen. Everything needs to be tested. Not only tested for its happy path, you know, how it's supposed to go, but also exception tested so that you can't break it. If you try to put something in that's not the right thing, it will fail or won't let you, that type of thing. And then you do a full conference room pilot. This is where you're doing that order to cash entire flow of data through the system and testing every step and making sure that it goes between departments. Well, for all the different kinds of things that you have happening in that order to cash, same with procure to pay, same with record to report, you're sort of seeing what you need to see. There will always be a round of issues or problems that come up that need to be driven down to an acceptable state before you move on. So, so that could be iterative. And then you want to think about the end users and how you're going to train them, how they're going to do any kind of testing. Because testing often is a great way to get up to speed in the system, even if it's not every end user, maybe some champions or supervisors, the people who will deploy the testing. And again, that's where a change manager will help you sort of develop your strategy and your plan for the end users and getting them on board. They're not the same as the project manager who's just saying, hey, you gotta get this done and let's drive it to resolution. Then you have your final cutover plan. So, you know, if you migrated all that data before and you've been testing it and working with it, you also have been adding new products or new customers or different, you know, scenarios and situations in the data that needs to be pulled in at the last second right before go live. So you have a completely accurate set of data when you go live and need to plan for that. You go live. And then there's what we call the hypercare period. That's the four to six weeks after you've gone live, where you are in the system and using that for the actual transactions for your organization. And there might be some additional small things that crop up, hopefully nothing earth shattering, but if there is something big, you need to make sure that that gets resolved immediately, something critical, then there'll be high, medium, low issues that pop up, or features or functionalities that you want to fix or you want to configure differently, or you want to see or add or a new report or a new form or whatever it might be. You really want to track that when you first go live. And you'll see that the volume of those types of things dip down over time. But four to six weeks is about what we expect to see, especially since now all the users are actually in this thing and using it at the end of the day. And no matter how prepared they were or how much they trained, it's still a little different when it's live and real. Those are the big steps. We want to talk a little bit more about different roles, responsibilities of your project manager, of your steering committee team, of your core team, of the vendor, of their project manager of their team that's doing configuration and supporting you. Any developers that you might have, any third party integrated software team members that you want to have participate. How long is this whole thing going to take? Of course, that really depends on your complexity, how much time you allocate to this. We can talk a little bit about rules of thumb there and then the change management overall, how to make sure everyone's ready to go, you know, and I like to say this is a very unifying project. I mean, it's not easy, but going through a shared, challenging experience as a company can be very unifying and bringing people together. And that's a great way to get everyone on board feeling like they're supporting the team and supporting each other and that they're really productive and adding value to the organization. I think it's a great opportunity. So look forward to talking about all of those steps with you in the next series of videos. Thanks for watching.