Phases of the ERP Implementation Process

Today we're going to talk about phases in the E RP implementation process. So now that you've selected the vendor, have negotiated a great contract, you've signed the deal, what do you do next? There will be a phase here or a time frame where the vendor says, okay, we need to hand this off from the sales team to the project management team and hang tight will send you all the details. So this is a great time for your team internally at the city or county or your agency to organize yourself, pick the right vendor for project management, assign the right project sponsors, and get your team excited about this really difficult process that you're about to take on. That'll last anywhere between 12 months to 24 months, depending your size and what kind of modules you're implementing. So first thing to do is get organized, and what I mean by that is get your team in place.

Kick off and Project Management

Make sure you have a project manager. We've covered that in a previous video in this series, but it's critical that you have a project management on staff or someone you have hired from the outside that's experienced E R P implementations to take you through the end of this very, very difficult process. So once you have your project team lined up, the vendor's ready to go, what you really want to do is set up a kickoff meeting. The vendor will probably ask you for a kickoff meeting that is global in nature, where they'll bring their team, they'll have your team in place these days, they'll do a zoom call, which is not ideal. So in order to get ready for all of those things, you need to do an internal project kickoff first. What we recommend is sitting down with your project management team and just talking through what your expectations are, who's responsible for doing what the generic timelines are and how do you want to play this project going forward?

Remember, communication's going to be key during the whole process, so you really need to be on the same page before the vendor comes on site to kick this process off. When you have the real kickoff meeting with the vendor, what you should expect from the vendor is to show up with a project plan in hand. What we've seen recently is vendors will come on site or during the kickoff meeting, say, Hey, we're going to do a project plan in the next six months. That's not ideal, that's not how this works. You need a project plan before you kick the project off so your team can go through the dates, go through the sequence of events, and make sure that the vendors team has taken your blackout dates, your holidays, your critical deadlines around audits and other outside deadlines that you may have into account as they create this project plan.

So in the kickoff meeting, what we would expect is for the vendors team to come in, introduce themselves for your team, to introduce yourselves to the vendor, get to know each other intimately because you're going to be spending a lot of time together. The next thing you do is set expectations. Talk about the deadlines, talk about the go-live date. And again, don't Don't just get tied into what the vendor says. Really think through the schedule and the project and see what deadline and go-live date, date makes sense to you and your organization. And at times it's really important to note that this goli date, while it may seem like a hard date that can't be missed, keep in mind that things happen. Keep in mind that your day jobs and the organization's mission continues as you go through this implementation process. So the goal live date might change and that's okay.

However, we need to set off on this project or this journey by setting a tentative date to go live so you can plan and work backwards from it as you kick off the project. Who do you need to have in the room? All of your stakeholders. Ideally, you should have your project sponsorship project management team, the city manager, county executive mayor, whoever's in charge of this city or organization needs to be present in this meeting because if things fail, all of this is going to go all the way to the top. So we need to make sure we have the support for everybody involved all the way from the top to the users that will be actually doing work in the system as far as possible. Bring everyone to the kickoff meeting so everyone can know all the parties involved, what's expected of them, and how this project's going to roll out.

The vendor will be presenting to you what their methodology is, what kind of homework to expect, what timelines to expect, and who's doing what. Even on the vendor side, they'll have a project manager, they'll have several subject matter experts. They'll have either implementation consultants or just other consultants that show up from time to time depending on what modules being worked on, what functional areas we need expertise on. Kickoff meetings are really critical in getting no getting to know the team in getting to know the timelines and asking questions. Please don't hold questions back if you have a worry about something, if you have a doubt about something, if you're not clear about a certain aspect of the project, this is a great time to ask that question because then the vendors' team and your project management team can go back and redo schedules, reset expectations do better with communications and just talking to this team during the kickoff meeting is really, really important.

Configuration and Business Process Sessions

Soon after the kickoff meeting, you'll have your marching orders, right? The vendor will say, we're going to be on site or have Zoom calls starting two weeks from now and we expect you to come ready with these things. One of the critical things especially today when you're looking at software as a service cloud-based e r P systems, is that your IT team is involved not from a configurations or setting up the system perspective, but really from a connectivity perspective, how do you access the system in the cloud? It's going to be really important for your IT team to be involved early on so that they can set up their VPNs. So you can access the system from anywhere. You can set up your security controls. So no unauthorized person can access modules. They're not supposed to access IT department, IT people will be really important in this phase.

So they can really set up the connection between your building, your systems, your devices, to the vendor systems in the cloud, or in any other building. So bring your IT team to this meeting, to the kickoff meeting. Bring them up to speed on what the project expectations are. If they haven't been involved in the selection process, which also is increasingly common and normal it's a great time to bring them up to speed on what's going on and what we expect from them going forward. It's role in a modern E r P system is really setting up the security policies, making sure people have access to the systems, and making sure that the connections don't break. Because remember, you're relying on a proper bandwidth, a proper internet connection so that you can access the clients or the vendor systems from anywhere. So it is critical as you set up on this journey, as you set up your systems to be able to access the vendor's solution.

Once you have access to the systems, remember there's a few things to do before you can actually start configuring. Making sure that you have the right licenses, that the vendor has provisioned your systems correctly, that you have the right modules, that you have the right environments. The vendors typically will set up three or four environments as the configure system, and your job is to make sure that you can get in and play around with the system as they're being configured. Your production environment is one that you go live with at the end of the process, and that's where the actual work happens. But while the implementation is in process, while the vendor's setting up the system, you will have the opportunity to play around to get familiar with the system, to make mistakes and try and break it but you don't do it in the production environment.

You'll do that in what's called training, testing, or just configuration environments. Different vendors call it different things, but typically these are your sandboxes that you can go in and play around, get familiar, get to know the system, and really start thinking about how your processes need to change based on your business process redesign or newer functionalities offered by the new system that you just bought. Many times you have an older system, God forbid you have an AS 400 or a green screen system that was built in the 1970s that no one knows how to keep up with and it's about to break. It can fall apart at any time. So there's a crucial period as you're going live or configuring or implementing your new system that you wanna make sure that the older system doesn't break and fall apart. In my experience, we've called it bubble wrapping, the old system, putting it on ice, what have you, but that old system still exists.

It's still your system of production is still your system of record and you need to make sure it doesn't break as you're starting to build and configure your newer system. So your IT team any team, your consultants that have been instrumental in keeping this older system alive needs to be engaged so that as you're paying more attention to the implementation of a newer system, the old system doesn't break apart. It's also important that you keep the data within the older system alive well so that when it comes time to transferring data, converting it from the older system to the new system, you have everything ready to go. It's all backed up, and that again, you don't break it inadvertently while you are in the process of converting the data from the old system. Trust me, we've seen all of this happen and it's really critical that you keep the older workhorse running as you're getting this new brand new system up and running for your organization.

So now that you've had all of the housekeeping things done, you're set up, your teams are ready to go, it has set up your environment, what happens next? The vendor project manager will communicate with your project manager or whoever's leading the charge and set up meetings for you. What do these meetings look like? What'll happen is the vendor will send let's say it's a financial RP implementation. The first thing they'll do is send a chart of accounts expert or you'll have a meeting with a chart of accounts expert that will ask you if you're happy, if you're satisfied with how your current chart of accounts is structured. A lot of times the state that you operate in or the county that you operate in will dictate what the charter of account should look like, or they'll recommend a certain way the chart should be set up and the vendors charter of accounts expert will come in and help you configure their system using this chart of account.

This is a great time to redo your chart of accounts if your chart of accounts hasn't been updated in a long time. And remember, I am an accountant, I understand this intimately, and all of your E R P practices and reporting and automations going forward will depend on how well your chart of accounts is in tune with your business practices, with your reporting needs, with what the state wants. So pay really good attention to the chart of accounts either when you start implementation or we've had some clients that have taken the time between contract signing and kickoff to really take a look internally about how they want the chart modified, how they want their accounts set up, how they want their accounts to be named. All of this makes life real easy as you go through and implement your new system. So after you've had your chart of account sessions, depending on again, what modules you've bought, what modules you're contracted for, typically the vendor will schedule meetings with their, let's say accounts payables specialists, receivable specialist, general ledger specialist to walk you through what's capable in the system, how your setup is envisioned, and how do you get those things to me merge together.

Remember we did, we went through a lot of hard work and homework as we got ready for putting our R F P out. We did a lot of business process redesign, we did requirements definitions, and we did all of that without thinking about what system we're going to buy. So a lot of aspirational things, a lot of idealistic things may not be possible in the system that you just bought, but that doesn't mean you have to fold and accept what the system can offer. There should be compromise and you should find the happy medium between sometimes spying the sky functionalities and what the system can offer for you. And these are the sessions that go on for days at a time. For example, if you're just talking about, let's say the procurement process, you're going to start from how our acquisition is made to how it's configured for workflows and approvals.

How does it check for budgets being available? How does it check for the right budgets being hit? All of that process we've envisioned and mapped out on our business process redesign, and in these sessions with the vendor subject matter experts, you are going to walk them through how you want their system to work for you. So you'll take these process maps and if the vendor's any good, they would've done the homework because remember, we've included all of these documents in your RFP in the past. So what the vendor does is they do their homework, they come prepared. Again, this is ideal. Not always does it happen but we need to make sure that the vendors are being held accountable for these things, right, doing their own homework. They can't just show up to your configuration meetings and say, Hey, we know nothing about your process.

Tell us more. That's when you get into a waste of time. So push your vendors to do their homework, push your vendors to look at the documentation we've given them and come prepared to these sessions cuz when they come prepared, it's a really, really good and smooth process where you can then say, okay, my procurement process needs to work this way. Show me how your system does it and let's work on configuring the new system based on these processes. So something like a procurement process will probably take a whole week. The vendors subject matter expert implementation consultant will come to your site ideally or do it over zoom or teams and really talk you through how your process fits into their system and how it can be configured. That is a very minute process. What you need to do is send your best procurement people, your subject matter experts internally to sit through these processes and give them the charge to make those tiny decisions that need to be made in terms of who approves what workflows, how do you want the process to flow and empower them to make those decisions in those meetings.

Because if you don't, and if you say, Hey, I can't make that decision, I need to ask my boss or their boss's boss, then you get into delays because the implementation consultants are there for a specific timeframe. They might be there for a week. So you may be able to come back and say, Hey, I'll get you that answer tomorrow. But smaller de details, smaller decisions need to be empowered and made by the line workers that will actually be doing work in the system. So each module, each functionality, each part of the process might take to a three days, sometimes four days, depending on how complicated it is. And you'll sit through these processes again, which can be really boring or they can be really exciting depending on what's going on. But it's critical that your subject matter experts are in these meetings, they're the right people and that they're empowered to make decisions in the process.

But it's really important that you pay attention during these sessions because what happens then is after every week session, the vendor will send you an invoice for it. They'll send you session notes or site visit notes and they'll ask you to sign off on these notes. And if you don't have someone in these meetings that have been paying attention and you sign off on things that either didn't happen, didn't happen to your liking and satisfaction happened wrong you're signing off on something that's not right and now you owe money, and more importantly, the vendors off the hook for getting that process done. So it's really important during these configurations slash discovery sessions that you really have engaged folks attending and that are excited about making these changes in your organization. So once the vendor's team has had their configuration sessions with your team, remember this is the bulk of the implementation process.

You will be doing this for 2, 3, 4 months at a time. Weeks on end, not just communication, but as the project sponsor. As the project management team, it's really important that you keep people's morale up, show them the end result, keep your eye on the end goals and make sure that you're bringing the team with you cuz it's really, really easy to lose sight and lose focus of the end result and just get bored with the whole process. There's too much at stake, you don't want to do that or for that to happen. So make sure as a project sponsor, as a project manager, as a functional lead, you're keeping your teams on task you're keeping your team attending these sessions and paying attention throughout the process. So what happens later, the vendors team, the subject matter experts, the consultants will gather all of this data if they haven't been making changes to the system or configuring it on the fly.

As you sit through these processes they'll take notes and they'll take your requirements, your processes, your setup configurations and take 'em to their technical folks who will then in the backend make these changes and configurations to your system. You don't have to do a thing when this happens. So there may be a break between sessions where you don't have to sit through eight, 10 hour sessions with the vendors teaching them or telling them how you want the system to work for you. Once you have these sessions, the vendor's going to have a few sets of documentation. They have your requirements, they have your business processes, they have your session notes, and now it's on them to configure the system as you've told them to through these sessions. So there's a lull in the implementation process when this happens, but if you have other modules going at the same time, you'll have more sessions and some people, some functional leads and some functional staff may be involved in multiple sessions.

Typically it's the purchasing and accounts payables people that are sort of overlapping. But anyway, once you have this configuration sessions, the vendor's job is now to configure your system based on the sessions and the notes. So they go away, they tell their techies what to do, their people configure and program the system and the workflows the way you want 'em to be. And in a couple of weeks they'll have some more homework for you. They'll come back and say, Hey, we've set this up. We need you Mr. Or miss functional lead in purchasing to go into the system and in the test system, take a look at how we've done this, run a few processes, tell us if it works well and if not, give us changes. Once again, a really important milestone and a checkpoint to make sure that the vendors team is doing exactly as you've asked them to do to their RFP process and through the configuration sessions.

Training and Testing

So once the team has set up all of your processes, all of your modules, and they say, the vendors team says, Hey, we're done. We've done what you've asked us to do. Now it's on you to do the testing. And remember, this is probably six to eight months after you started the whole process that you get a chance to really get into the test system and use the system. How do you test it? Do you just go in and do random processes and see if it works? You can, but that's not the most optimal way of testing the configuration of new system. Remember, again, everything goes back to the homework that you did before. You put an RFP out, you did your process redesign, you did the requirements you have all this documentation, and at the end of the day, you want the system to work for you as you envisioned it, as you dreamed about it.

And you've had to make some compromises because the system you chose may not be able to do all the things that you wanted to do. But in the testing process, you really need to have test scripts that help you to test out all of the processes in a systematic manner so that when something fails or doesn't work the way you wanted it to, you can specifically tell the vendor that, Hey, on this test script, on this line, in this process, here's what failed. Or here's the result that came up that I didn't like. Can you please modify this? And creating a test script is not an easy task, but if you have a dedicated project team, if you have analysts on staff that are experienced in doing this, by the time time it comes time to test out your new system, you should have these test scripts ready for you to go.

So if you're a purchasing director or a purchasing subject matter expert, you can then get these test scripts from your team and run them through the system to see how well the system is taking care of your process or if it's falling apart, it needs to be documented. And this is where your implementation come. Team comes in play you have a project manager, you have business analysts, you have project management assistance. Their job through the process of implementation is to make sure they're documenting things that don't work, that they're communicating them to the vendor and they're keeping track of how well the vendor's taking care of fixing those errors or making those modifications based on your test. In terms of testing, there's two different levels. You'll do your functional testing where like I said, the purchasing director or SME will go in and check out a few functions based on a test script and if the system passes through those checks and those gates, the next big thing and the biggest thing perhaps in the whole implementation is what we call user acceptance testing.

So what happens once you've had your subject matter experts functionally test some of the processes within the system once you've had them do that and the system has passed, the vendors made the changes, you now get into perhaps the most important phase of the implementation. Getting your user community, those people that will be using the system day in and day out, your AP clerks, your purchasing specialists, whoever else that's going to use the system on a daily basis to cut pos, to make acquisitions, to cut checks, to pay vendors, all these folks will need to now come into the system to test it on in very stringent manner. So you have your functional test scripts, now you, you're going to give your end users the user acceptance test scripts, which tend to be a little more involved, a little more detailed. And what you're doing in this process is, you know, can do this virtually or you can do this in a system implementation war room where everyone sits in the room that's involved with a certain process and runs through these detailed scripts that allows you to make sure that your process is going to work in the new system and it gives them an opportunity to tell you what's not working, what needs to change.

Remember, before you accept the system, you have all the opportunity in the world to have the vendor make it edits and changes for you. They might make a noise about it, but really you're entitled to it. So as you're doing this testing, make sure that you're documenting things that don't work that you can communicate through your project management team, through the vendor so that they can make changes that you need. User acceptance testing is, I mean, think about the term acceptance testing. This is the critical phase where you are saying to the vendor that you're either going to accept the system as it's being configured or you're going to not accept it because things don't work. Very critical that you run through test scripts, that you document that you have a formal process of accepting the system. If everything works, make sure you sign off on it.

The vendor might have a form for you, they might throw it at you a couple weeks in advance. You have to be really careful on what you sign. This is again, a place where a project management team that's dedicated will come handy because they can then say, Hey, don't sign this. We haven't done the u A T for this. The system hasn't worked for this process yet. Hold off. But if everything goes well, all the modules work, all the functions work, the users are happy, this is the time when you say, okay, I accept. We accept at least this module, this works. Sign off on the user acceptance test and move on to the next module. Once you've done user acceptance testing on all modules, you are now at a point where you can say that we are ready to take the system live. And if everything has fallen in place what I like to call the happy path where everything just lines up and things go well, you're now ready for the next phase of this project, which is actually going live.

And again, when the vendor first showed up on site and you had the kickoff meeting, they might have said, Hey, let's kick off on February one with your payroll process, or let's cut the first check on Jan one. Those are aspirational dates. You need to have gone through the whole process of user acceptance testing, configuration of the system and get everybody on the same page before you can say, okay, we're going to go live on a certain date. So what does going live mean? Going live means that you're going to stop using your old system. Now, previously the practice was that you would go live with the new system while the old system was still working and you would do what was called a parallel go live where you're making sure that the new system has the same results as the old system because you're switching your system of record.

You don't want there to be any discrepancies, but the best practice today is to pick a date, kill the old system or put it on eyes, archive it and then make the new system your new system of record. That's what we are going to use starting on a certain day. So it's really important that you pick this date and the rollout really carefully that everyone is communicated with, that you're not taking on too many things. We don't recommend going live with the full e r P system. That includes financials, hr, payroll community development, work orders, asset management. At the same time are the best practice that we've seen that is most successful is that you chunk it out, pick a date for financials, pick a date for hr, and then roll out the rest of the systems incrementally. Because if you pick one day for all of these processes to go on a new system, you're looking at some real troublesome times because what if it doesn't work?

What if people haven't been paying attention in configuration sessions or training sessions and now you're asking them to use a new system while shutting off the old one? You wanna really make sure that you're ready for this, that you're doing this right, that everyone has been communicated with. And on the day that you go live, things are as smooth as can be. I've never seen a system implementation where go live is smooth, there's always some hiccups, which is also where you, you'll find it really valuable to have a dedicated team that doesn't have any other thing to do, but project manage and make sure that this project is going well. That GoLive goes on time and it goes as expected. And on GoLive day you'll come in and typically the important milestones for saying that you're live on a new system are things like, did you run payroll on a new system?

Did you cut checks to vendors on a new system? Are your employees are their data and their information being managed in a new system? These are key markers that really tell you what goli means. Cuz if it's left fuzzy, you can really, the vendor community especially can say, Hey, we handed you the system. That means to us is no, we need to define what go-live means for us and hold the vendors accountable for that definition on the day that the clients say we're going to go live. So with that your new E r P system should be the one that you use. That should be your system of record, that should be automated. It should give you the reports and the dashboards that you need when you need them. So once you're live on the new system, things should work pretty well. But e R P implementations, now at this point, you have been at this for about two or three years.

Go-Live

There's fatigue, there's frustration, but there's also relief that you're finally live on a new system. So if there are 10% of functionalities that don't work that need to be ironed out, you need to tweak your processes. This is a great time to do this, right? What we call the post-implementation, the post coli phase where you might still have the vendor engaged before they hand you off to support where you still might have your third party implementation experts and project managers involved. Post coli is important because you can't just take your foot off the pedal, you have to make sure you're monitoring the system. You have to make sure that it's still working a week, two weeks, a month into the post coli process that things are working for you as you envisioned. And maybe a month or two after go live, you can really say we're done.

So post-implementation is critical. As you try to clean up processes, as you try to reconfigure things, you tweak your project reports, you tweak your dashboards and your outputs from the system. You have to keep an eye on the trailing ends of the E R P implementation and really tie up any loose ends that you might have at this point. Congratulations. You are live after a three to four year process on a new E R P system which should really make things easier for you and your organization. So now that your vendor has configured your system and set up the workflows and the securities, how do you train your end users? Remember the end users are the ones that are going to use the system day in and day out. They'll be the ones putting requisitions in, cutting checks, doing approvals, or asking for time off.

How do you train these people to use the new system and let go of any training or knowledge they have of the old system? Training in an E R P implementation sort of happens incrementally and throughout the process. Remember when you're sitting through your configuration sessions where the vendors on site trying to set up your system, you have the opportunity to follow along and on your own screen on a laptop, just click around and play around and things. Also, remember that your user community will have access to the training and testing environments from day one if the vendor is doing the right thing and have set up the system right before kickoff or right after, you will have access to the training environment and you can distribute that to the whole crew and say, Hey, here's a new system. Go in and play with it.

It's not going to break anything. Just do whatever you want and get yourself familiar with the new interface. So that's one level of training. Modern systems also have self-directed training. In the training modules there have like Tyler Munis has Tyler University and if they've set it up for you, you should be able to go in and play around with the system. It will show you to a very detailed degree what boxes to click on. Where do you go next as you're running through a process, let's say you choose to go through a accounts payable process for approving invoices, right? You'll pick it up from a dropdown menu and say, I wanna learn this process. The system will show you where to click next and how to go about the process. That's one. I'm sure other systems have the same kind of technology that you can do some self self-paced and self-motivated learning as you get to know the new system.

Post Implementation

So that's another level of training. You may or may not have formal training sessions, but most implementations for E R P systems involved at least a week of training where after the configuration's done and right before or soon after functional testing where you bring in your end users and put them through the paces in terms of how to use a new system. Remember, you can't just put those people your end users in front of a computer and say, Hey, this is your new system, use it. Different people learn in different ways. So you definitely need to have documentation manuals and processes in front of you users that they can emulate and learn from. And a lot of times the vendor for the system may not have detail enough notes or manuals, so you have to create them internally or have someone from the outside come in and use what the vendor has. Make it a little more interactive, a little more detail a little more graphical at times, and present that to your end user so they can learn the system either at your organization or online or on their own time. But training is critical because when you go live, you don't want people to say, Hey, we were never trained on this thing. I don't know how to use it. And have your processes break.