Solo Broadcast: Mastering the ERP Checklist Essentials

Join the exclusive live broadcast led by AV, CEO of Avèro Advisors, as we explore the critical essentials of ERP systems. This insightful session, mainly designed for public sector professionals, will feature a thorough walkthrough of our live ERP checklist. It's a unique opportunity to deepen your understanding of Enterprise Resource Planning strategies, align with best practices in public sector consulting, and have your questions answered by an industry expert. Enhance your ERP knowledge with us and be part of this enriching journey. Join AV in this insightful solo podcast, where he delves into the critical art of navigating Enterprise Resource Planning (ERP) implementation. With an eye-opening statistic that 80% of these implementations falter, he underscores the gravity and meticulousness required in this process. Throughout the episode, AV walks listeners through a comprehensive checklist essential for any ERP implementation or digital transformation journey. This includes documenting current processes, pinpointing modernization opportunities, developing process maps for the desired future state, specifying requirements, and preparing a projected budget. The journey involves procurement, drafting a Request for Proposal (RFP), evaluating proposals, conducting product demonstrations, vendor selection, contract negotiations, and the pivotal stages of implementation and going live. AV also highlights the significance of user testing, creating training materials, and establishing a system for reporting technical issues, ensuring a well-rounded approach to ERP implementation.

Stay up to date on industry trends!

Download our free eBook:
➡ https://bit.ly/2023techguide

Learn More About Avero:
➡ https://www.averoadvisors.com

Connect With Us:
LinkedIn: https://www.linkedin.com/company/averoadvisors
Facebook: https://www.facebook.com/averoadvisors
Instagram: https://www.instagram.com/averoadvisors
TikTok: https://www.tiktok.com/@averoadvisors

Connect With AV:
LinkedIn: https://www.linkedin.com/in/verekar

(865) 415-3848 | info@averoadvisors.com

Transcript

AV (00:00):

Welcome back to the work day and happy 2024 to you. I hope everyone had a great holiday season and enjoyed time with family and friends and just generally got some time to relax and unwind and think about goals and aspirations for '24. So here we are. We're doing a solo cast today. We don't have any guests, but I thought it was really important to start this year with a reminder that mastering the ERP implementation process is not something to be taken lightly. I don't think anyone can master it really, but there are certain things you need to do that are best practices that help you sort of do it right, reduce the risk and improve your chances of success. 80% of implementations fail or so the statistic goes, but the number's up there, you've heard of so many horror stories of implementations gone wrong.
(01:07)
You've probably been part of some, and we created this checklist last year to make sure that we can hit the highlights of what you're supposed to do when you embark on an ERP implementation or a digital transformation, right? You don't necessarily do ERP implementations every year. I hope not. But if done right, this should be a once in a lifetime, once in a career sort of project that you should be proud of. It could be career defining, it could be defining for the profitability of your organization, and this checklist I think will help everyone. Before we get into it, I want to remind the viewers to comment in the chat box and tell us where you're tuning in from. We want to hear from you from all over the place, all over the world, and pop in your questions and comments and anything else you might want to discuss, want me to cover.
(02:07)
But without further ado, let's get into this checklist. And by the way, we're popping some links into the chat box here with our newsletter, with our YouTube channel, with our LinkedIn, all kinds of great content out there for you. If you're thinking about ERP implementation, modernization, getting a new system or any kind of other digital transformation, it's all out there and reach out if you need to talk to us. Oh, and if you want to download the checklist, please scan the QR code that's on your screen up here to my left, to my right, and you'll get access to the checklist. So I'm going to share my screen, see how this works and get into it.
(03:07)
So from RFP to going live the comprehensive ERP checklist. Now, why did we create this document? We ran into a lot of prospects and clients that had not thought an ERP replacement through. The perception is that you just go buy something. You contract with the software vendor, maybe a system integrator, and that should be the end of your worries and then see you at go live doesn't really work that way, right? In majority of cases, you need other partners. You need to define your strategy. You need to think about what your outcomes need to be and have all of your ducks in a row before you embark on this journey. And it's not foolproof, but this gives you better chances of success because think about where you're coming from. You have a 20, 30-year-old system that was implemented before you took this job and you inherited this.
(04:06)
You're A CFO or CIO, city manager, mayor, CEO, what have you. But the last time they did an implementation was 30 plus years ago, 20 plus years ago. It's the same thing that the system has kind of become its own thing. You have your own workarounds, you have other documents, you have a paper-based process. There's Excel sheets flying around everywhere. Where do you begin to untangle this mess and how do you choose the right vendor? Because every vendor will tell you that their system's the best. Everyone will tell you that their product will solve all of your problems. And just to sign on the dotted line, I hope no one fell for the end of year discounts because what tends to happen is they get pushed through and you sign something in haste and now you have a mess on your hands. So anyway, to cut a long story short, this is why we created this checklist, and you can find this on our website. You can find it by downloading, by clicking on this or scanning this barcode here, but let's dive into it. There's not many.
(05:19)
I think it's 12 pages and a couple of them on each page, and it's not different from what we've talked about throughout on our channel, on our lives in all of our documentation and content would be great. So what's the first thing you want to do when you're embarking on this ERP implementation, ERP modernization journey? The first thing to do is document existing processes. What do you have? What kind of systems do you have? What kind of processes are you running? Why are they in the shape that they are? Why is there so much paper? Why do you pay a million dollars a year for a system and yet you have spreadsheets galore? You're not alone if this is the situation at your organization and your functional department. This is pretty common with organizations that have had long-term implementations that have created their own ERP systems that have bought something but didn't really put in a lot of time in the implementation process.
(06:21)
It's inevitable that you'll have workarounds because the system doesn't know what you want it to do. So the first step in taking on a new implementation or looking for a new system is taking stock of what you have. Look at your processes. If you are, for example, going for an ERP system that encompasses finance, hr, payroll, asset management, what have you, the first thing to do is look at what you have, take stock of your AS is infrastructure, your AS is modules, your AS is business processes. And it's not just having meetings with functional heads, and I'm assuming you are a CIO or A CFO that's taking on this massive project for your organization. The first thing to do is take a look at what you have. And a lot of times what we do if we are brought in at this stage is we recommend doing a business process redesign, business process assessment, documentation, redesign.
(07:22)
What that essentially means is look at your processes, do an inventory right? Number one is take a stock of all of your departments, document all of the processes that each department runs and go study them. And this is a long process, right? You might ask me, why would you do this instead of just going through the implementation? We'll talk about those risks later on, and we've talked about them at length. Many of our videos on our lives, on our podcast, why you don't want to do that. It's fraught with risk because again, the systems need to be told what you want it to do. So when it comes time for the vendor to configure your systems, you have to be very clear and articulate about what it is you want it to be doing for you, and that dictates the configuration. So it all starts with the business process redesign, study processes, map them.
(08:18)
We use this tool called IBM's Blueworks Live to automate the process of business process mapping, where in the past you would do interviews, take notes, go back to your desk and map them out, map the processes out in Visio. All of that's scrunched down. Now instead of taking six months, this process actually takes a month because we're doing process mapping live with your subject matter experts, your functional leads, and people that understand your processes really well. So BPMM 2.0 framework is what we use is pretty standard in the industry. And really what we like to look at is what processes does your organization follow for things like payables, receivables, invoicing, asset management, and things like that. The next thing you want to do once you have your As is processes mapped out, and you can do this as detailed or as high level as you want, as long as you're getting to the crux of understanding where you are today, right?
(09:16)
This might be coupled with a network diagram or a systems diagram of where you are today, what modules you own, what different systems or vendors you use to take your financial processes through. All of that is documented in the first step. So once you check that off, the second thing to do is identify opportunities for modernization. Think about what that means. You've looked at where you are today. Second thing to do is dig into those processes, preferably with an outside party. I'll tell you why that is, because when you've been doing the same thing for a long time, you tend to get too close to the problem. You don't see them as problems. What might look like a broken process to me might look like what you've always done for your organization. So why would you change? A third party will give you perspective. A third party will give you distance away from the problem and help you understand how your current process fits in with industry best practices, what other organizations are doing, and what might be best for you from an efficiency standpoint and getting the most out of your resources.
(10:33)
So identifying processes or opportunities for modernization is critical. So take your processes as you've drawn them or documented them. Look for opportunities for automation for more transparency, less redundancy, less duplication, less roadblocks. And in my experience, when you do business process analysis, these inefficiencies typically show up when there are handoffs between departments. Let's say payroll is handled by finance, HR is handled by HR department, timekeeping is in hr, payroll happens in finance, so there's a handoff there. Similarly, when you're doing things like purchase orders, right? Requisitions have handoffs between departments within departments within purchasing thresholds, all of that needs to be documented. And then you need to look at opportunities for process optimization. And it's not just from a standpoint of technology. What you might find is you need to change some of your regulations, some of your codes, some of your ordinances, because it doesn't make sense anymore. The last time someone looked at these processes was, again, 20 years ago. So how do you bring your processes into your operations today, into your tech stack today is very important. And then looking at opportunities for modernization is critical.
(11:59)
Once you check that off, the next thing to do is consider what the modernized processes should look like. I mean, this is where you get to dream big. This is where you get to visualize. This is where you get to think about the vision for not just your functional area, but your organization as a whole. How do you want to deliver services to your customers? How do you want track your own resources and how do you want to make sure that your workforce has the tools and the processes to give their best? You have some really sharp people on your organization and you want to make sure that they are equipped with the right tools that allow them to excel in their function and their process. So really visualize what that looks like. Again, with the help of a third party, it's just easy because we've been there before.
(12:51)
We can help you guide through this process. We can document this for you. So as this process maps are useful, in some cases, your current state, you have an understanding of where you are. And a very detailed as is process map helps you understand where the pitfalls are. And also if you want to sell this to your leadership council board, what have you, you can pinpoint inefficiencies and you can go really deep into process mining and showing that inefficient processes lead to either money lost or opportunity costs or what have you. So cut to the future process of future state processes. You can do the same exercise. You can still do business process mapping them from a future state standpoint, and we do this with our clients where we will pull in the executives or functional heads for a certain function or departments together and on a big screen, show them the asis map and then talk about how they want to move things around or remove some boxes.
(14:01)
So we guide you through the process where we can tell you which pieces can be automated. Forget about the system you own today. Maybe the system you own today doesn't allow for automation in that specific region, but that would dictate the recommendation that leads to you replacing your ERP system or your financial system or your HR system. So you really need to think through where you are, what your vision is, what your processes should look like. And then when you check that box, the next step is to create ideal state process maps. Again, using Blueworks Live, we can really speed this up because you already have the as-is maps, because it's not always chopping off blocks of the process map. It's streamlining, combining processes. And a lot of times what happens is people in these realize that two people are doing the same job, they're doing it two different ways.
(14:56)
Sometimes three people just because they're not in the same building, they don't do it the same way, but that's an opportunity to consolidate processes, to bring in new systems that automate things. So a lot of those things need to be thought about before you even think of releasing an RFP before you even think of releasing or looking at demos. Because when you see a demo, without having thought through these things, you don't know what you're looking at. You're looking at bells and whistles, you're looking at what the vendor wants to show you, and there's a likely chance that you'll like one aspect of a product and go sign something. But 90% of it may not work for you because again, you haven't taken the time to think through what your critical business practices are processes are and how a new system is expected to change processes for you and make life better for your employees and your customers in the end. So ideal state process maps then lead to requirements, definitions. And again, this is, think of this phase as your architectural drawing phase. You're building a house, you've bought the land, you like the view, you have a thought in your head about what this should look like, which way the door should face. But you don't just go to a contractor and say how much for a house they'll tell you based on what car you drove.
(16:27)
But when you have architectural drawings, when you have an architect involved, they'll tell you what your soil is like, what the view is, what the sunlight looks like from a certain direction, what kind of doors, windows, what kind of marble blocks do you need to fulfill your real vision for your home. This is very similar. You need to think about this as a construction project, as if you're building a schoolhouse, a school building, or a police station, because that will allow you to have the clarity of mind to have some real detailed descriptions of what you're looking for. So the requirements definition is a critical stage because this is not just a step that will allow you to pick the right vendor and the right solution. It will also allow you to keep those vendors in check, keep them accountable, not just during implementation, but also post-implementation.
(17:23)
Very critical document. We've helped clients develop very detailed requirements, definitions that have saved them from losing millions of dollars because when you do a requirements definition, the vendors that are expected to respond to every requirement and tell you if they can meet them today, or is this going to be customizable or do they need to develop a whole new functionality? So this helps you not buy wafer rare, which means products that don't exist, right? A lot of times when you go to a vendor and say, I want to buy a financial module from your company, and if you don't have the detailed steps or requirements, because think of this, accounts payable or receivable might mean something to you, and it might mean something else for the vendor. And as well as I do that, depending on who you are, what kind of organization, what state you're in, purchasing requirements are different.
(18:19)
So you have to document all of this in a very detailed manner before you go pick a product. So you check that off and requirements, definitions to be useful, to be really impactful, they need to be thousands of lines. I know some people disagree with that, but in my experience, this phase has saved a lot of clients from bad implementations, bad contracts and just bad situations. It's also helped them because you have a lot of clarity on what you're looking for and everyone's on the same page or should be. So once you check that off, you move on to the next step. Excuse me, I don't have anyone to talk to today. So pauses are important, and a shout out to Nishtuan from India. Thanks for joining us, Nishtuan. Okay, what do you do next? And again, these steps might vary in order based on where you are and who's on your team and what you've done before and things like that.
(19:30)
But this is a general step flow to follow. Next, once you have your requirements, you need to create an estimated budget. Now, this might happen at this point or it can happen at a later point, or you might refine the budget as you go along and learn more about your own operation, the options out there for you and which vendors might be applicable, but have a general sense of what you want to spend at this point, because based on these requirements that you've created, you could ask a consultant, what does a product like this cost for an organization like us that is as complex, so many people doing the same kind of things? And we should be able to tell you at a high degree of certainty. But again, it depends on which vendor and how well your requirements are documented. So it's fine to come up with an estimate for your budget at this point, but keep in mind, big grain of salt, you'll have to adjust it as you go along a government agency.
(20:39)
So procurement needs to be involved. I think they need to be involved at an earlier stage from a stakeholder sort of steering committee standpoint. But if you are just starting off within your department, you're doing requirements, it's fine. You can include purchasing or procurement at this stage after you've done the requirements. Of course, if it's a financial ERP, we will talk to purchasing and they will be involved in the requirements definition phase as far as their purchasing functions are concerned. But talking with purchasing, bringing them into the fold and just laying out expectations as far as what this procurement needs to be and how we need to look at potential bidders is really important. So purchasing is going to play a huge role in this because if you are a government agency, you know how stringent the RFP process is. If you're a private sector agency, you might be able to skip this phase, but you still have purchasing, look at contracting, contacting vendors, taking bids, all of that.
(21:46)
So bring them into the fold and create an RFP. Now, remember, RFPs are, you might think that it's just we're looking for a software that does three things, send us your quotes. That's a very simplistic, risky approach to RFPs. And we've seen projects go sideways because that's what the clients put out. RFPs need to be detailed, very detailed, tell the vendor exactly what you're looking for, and then your requirements definition that we created in the previous step becomes critical. Include that in the RFP and make sure that the vendors are responding to everyone. It should be a pass fail grading on the RFP review process. If a vendor does not respond to the checklist or to the requirements definition, they can move forward. So make it mandatory.
(22:45)
It doesn't need to be absolute. This is all leading towards a negotiation phase, but vendors need to be responding to the requirements definition because that's what you want. That is your architectural drawing. That's what you want the vendors to respond to, and that's what you're going to hold vendors accountable to in the long term. So including the requirements definition with a solid, clear scope of work, maybe with some diagrams about how you have current systems integrated, it's really critical in the RFP. So once you have that ready, send the RFP out, put it on the street for maybe six weeks, eight weeks, depending on your size and the size of the RFP, and then do the pre-bid proposals. Pre-bid meetings, you can do a q and a period where you answer questions for vendors, whatever your process might be, incorporate that, but make sure that you're taking everything we've done so far, including that into the RFP, and that becomes the foundation of your ask for what you're looking for in the market.
(23:55)
So six to eight weeks later, you'll hopefully have five to 10 proposals come in, and now it's time to review proposals and conduct demos. This is a lot of work, right? So a lot of times clients will bring us into review proposals. Maybe we become part of the selection committee. Typically we don't because we want to maintain our third party stance and work on behalf of the client. And also it gives the clients a lot of ownership and initiative to do this on their own, but we're there with you every step of the way. So reviewing proposals is the first step, and these proposals are lengthy, especially if you're looking at a full-blown ERP implementation. You're looking at two to 300 page documents that are very thick with technical jargon and information about the vendor and the product. But it's important that you read every page and you compare that with your requirements definition.
(24:57)
A lot of times vendors will just send their cookie cutter RFP and proposal in without looking at what you're specifically asking for. That's a red flag. The vendor's not paying attention to your RFP, they're not going to pay attention to your implementation. So look at it from that standpoint. What are we looking at? Did the vendor pay attention to our requirements, not just the functional business technical requirements, but also requirements for the RFP? We ask for a certain format. We ask for a certain flow of what the RFP should look like. We ask for certain forms, and if they haven't paid attention to the submittal requirements, it's a red flag. And some clients choose to disqualify vendors for those red flags. Some don't. But that's up to you. So review proposals, not just from who the vendor is, what they're offering, how much money it is they're proposing, but also from a standpoint of requirements and a general feel for are they paying attention to our needs? Because the last thing you want is someone throwing a cookie cutter proposal to you and it doesn't make sense. It's generic. We've spent a lot of time so far, right, putting an RFP out a lot of time, depending on the size of your organization, you're talking about six to 12 months before the RFP hits the road. So the vendors need to match that sense of urgency and detail through their submittal as a proposal. So we have to really take time to review proposals and conduct demos. Paul from Dublin, Ireland. Thank you, Paul. Welcome.
(26:42)
The next thing to do is select the vendor. Again, this isn't, and I skipped over the demo piece, I'm sorry, but reviewing proposals and conducting demos. Once you have proposals reviewed, the next thing to do is have a short list. You may have received 10 proposals, cut 'em down to three or four based on your scoring on the number of requirements, met, general reference checks, financing budgets, cost proposals, all of those things need to be taken account. And then you take your 10 and bring 'em down to four tops. Again, depends on what you're doing, who you are, what kind of organization, and then the demos. It's really critical to not just bring in vendors to show you their bells and whistles, because if you do this in an unscripted way, if you're not leading the way and telling the vendor what you want to see, it should be obvious through your RFP process.
(27:40)
But it's usually not. And it's understandable. Vendors have a lot of demos to do. They have a certain way of doing demos, but this is not a sales demo. I mean it is, but this is really where they get the opportunity to show you how their products fit your need, specifically based on your requirements. So what do you do? You invite the top four vendors in. You schedule demos. They could be a day long demo, they could be a week long demo depending on the size. But the most critical thing to do at this point is to give the vendor a demo script. And they don't like it because they have a certain way of doing a demo and getting out of there. But the better vendors will play along. They will actually pay attention to your demo scripts. They'll pay attention to what you want to see on what day and what order, and not push back on those things.
(28:36)
Of course, it's negotiable with the vendor. If something doesn't make sense, of course it can be changed, but this is a best practice. Get them in there to do demos based on your demo scripts, because otherwise you're going to see bells and whistles, things that don't make sense to you, they don't apply to you. And after one day long demo, you'll be left wondering, what did I just watch? And it looks cool, but does it apply to me as an organization? So demos need to be tied to demo scripts that are tied to requirements, definitions that are tied to your two B processes. Very straightforward process. It's a lot of work, but this is the best way to save your organization from a lot of pain. So when you do demos, of course you're going to have your selection committee in the room or their designees, and you'll also have a pre-made demo evaluation sheet.
(29:32)
You'll also have that for proposal evaluation because at the end of the process, you'll get to tally all of these things and have a real solid for why you picked a specific product over the other, right? Because big implementations like large ERP systems, especially in the public sector, you're bound to get a protest or someone's unhappy about not being picked. So you need to have your ducks in an order in order because when that inevitable protest happens, you can showcase all of your processes, how you came up with a decision, how this was unbiased through your documentation in the absence of which you are opening yourself up to protests and problems. So the next step is of course, whoever comes through, select the vendor based on the scoring, based on reference checks, based on the demos, based on the RFP response and based on your overall comfort level with the team.
(30:30)
A lot of times vendors will bring in a sales front, but not the team that's going to work with you. So insist on meeting some of those key team members, especially the project management team, the lead consultant on a specific functional area. And of course, it depends on the timing because vendors can't including us. We can't tell you who we're going to staff on a project if your project's going to be six to eight months from now. It's difficult. So take that with a grain of salt, but you need to insist on at least meeting the leadership of the project through that process. So once you have your selected vendor, check that off. What do you do next? You negotiate and finalize your contract. Remember, there's a baffle process. If you want a best and final offer, this is the time to do it before you select the vendor, the final vendor, you can ask for best and final offer, which could be a cut in pricing, better terms on the contract, faster delivery, different team, what have you ask for a best and final offer from the vendor.
(31:34)
And then that's all part of the negotiation process, right? Legal gets involved to check off the Ts and Cs, making sure that the vendor, their contract is applicable to your state or county or city. Then you're looking at payment terms. We have a lot of content about payment terms on our channels. Do not pay anything upfront. Of course, negotiate that out of the contract. Do not pay anything that's not tied to a milestone. And everything needs to be tied to a milestone. So negotiate in good faith, bring in a third party like us. If you need help with negotiation, we do this all the time, we know a lot of the players, so it's helpful for us to be involved and just make sure that you are getting the contract that you want. You have to define what you want, which we have. And one of the biggest things that you need to define is what go live means to you.
(32:32)
What does it mean to be done? And when is that final invoice due to the vendor? And what are the milestones and triggers that will allow the vendor to invoice you? Because if you don't set those expectations in the contract, you'll get invoices every week and there won't be a way to tell what's done, what's not done. Another point is to have an independent PMO project management office officer that is overseeing all of these things. Because when you start implementations of an ERP system, you need to really keep an eye on things like vendor invoices. How do they correlate to the contract you've negotiated? Are they hitting the milestones? All of those things come into play. So negotiate, finalize your contract, and then you get into the implementation phases. But before you kick off, you have to do pre-work. Again, this is a lot of work and you can't just leave it to the vendors to figure out because they'll have project managers of their own, but they'll be only focused on their resources on making sure that their resources are doing the right things.
(33:45)
No one's going to herd the cats on your side. So you have to have a full-time project manager either in-house or someone outsourced that oversees the project. So that's step one in this phase, creating your project team and setting responsibilities. And again, lots of good content on who should be involved. We did this on the live last week, talked about project sponsorships, the PMO, who's involved at what step and how it all is critical in successful implementations, project team and setting responsibilities. Drafting a project plan is important. You need to make the software vendor give you a project plan that isn't just three lines deep. It needs to be a Gantt chart with responsibilities, with stakeholders, with intricate dependencies between different tasks that should dictate the flow of the project. That should dictate when you go live, and that should dictate who's doing what on what day.
(34:46)
So really, really, really important to do that. And then based on the vendor's plan, you create your own plan because you have your own blackout days, you have your own times off, you have your own audits, you have your own budget seasons. Tie that into the vendor's plan and make sure those two align and make sense. And then push back and make sure you get a consolidated plan that works for everybody. All hands kickoff. Meeting with the vendor, very important. This is where you bring in all the stakeholders and we've had clients bring in everybody in the organization. We've had clients bring in just the executive team. We've had clients bring in executive teams and top management. The point of this meeting is to officially kick the project off, set expectations, set timelines, and let people know that this is going to be work, but it's got the blessing of the executive team and the outcomes that you're looking for, the outcomes that everyone should be looking forward to.
(35:48)
This is a great time to talk about change management because if people are surprised, if they don't know what is going on, if they think that an ERP implementation is only something the C-suite is pushing down on them, this project's not going to be successful. So this kickoff meeting is a really good way, a really good venue, really good time to set expectations, set the tone, get people excited, and again, consultants like us specialize in doing things like that. So bring us in. We'll help you set that up. Paul Burn doesn't agree with every point, but that's good too. Yeah, Paul, just tell me what you don't agree on and we'll go from there. This is based on our deep experience in the public sector in the us and I know not everything will apply, but anyway, kickoff meeting is really important and valuable to have, so don't skip that.
(36:51)
Scale of the data conversion needs. Again, this is something you can think about at the very beginning of the project. It's actually something you should think about early on and often because if you're working off of a 30-year-old system that was homegrown and you have on-prem backups and it's clunky and can break at any time, it's important that you make sure you bubble wrap that data, right? You keep it secure. Number one. Second, do you really need to take 30 years of data, transactional data into your new system? Probably not. So you have to determine what it is that's important to you that gets translated into the new system. In our experience over the last five years, most clients have been taking perhaps one year of transactional data and two to three years of balances into the new system if you are confident in your data, because a lot of time is spent on scrubbing, cleaning in the conversion process.
(37:55)
So you can take limited amounts of data into the future system and the rest of the data doesn't get discarded. You have to find an archival solution where if you need to go back into and look at a purchase order from 1982, you can do that. But scale and size of data conversion is really critical and it will have a big impact on what your implementation looks like and then work with it. Of course, we haven't talked about it, but they're involved in the whole process. If they're not leading it, they're definitely making sure that you have all of your ducks in a row from a security connectivity and just overall ease of use standpoint, because a lot of systems are in the cloud software as a service, it is not involved in the actual configuration. They're involved in setting up the infrastructure and making sure you have the tools to access the system. So bring in it, make sure that they are connected with the vendor's crew, that they're connected with the infrastructure engineers on the other end, and that you have the right setup to get on with the system.
(39:13)
I'm going to take a question from Paul. Thanks Paul. Agree, but having a deep level project plan kickoff is difficult to achieve. We should start with a layered project plan, project plan, high level for kickoff, and then drill down into a greater detail. Yes. So there's another approach, right? Paul, where I'm coming from is, especially in the last three years of ERP implementation, we've had vendors show up with no project plan, none, zero. We've had vendors show up and when asked for a project plan, they're showing you some other client's project plan and saying, yours will probably look like this and we'll get it to you six months from now or six weeks from now, but yet you're telling me that you need to go live on a certain date. The two don't add up. So this is why we push for a project plan and as detailed as possible is great.
(40:07)
And another great point from Paul is the project plan needs to be something that everyone can buy into, can believe in. Otherwise it's only a wishlist. Well said, absolutely. Because again, this is going back to vendors pushing a go live date on our clients. They'll come in and say, you're going live in March 31st. You should be live. And when asked about how, show me the roadmap, they can't show you anything. Huge red flag. So this is why we asked for a project plan, a kickoff. It may not be the project plan. And the other thing to keep in mind too is project plans need to be dynamic and a living document, things happen, right? You should chart a happy path, see if everything goes your way, what should the project plan look like? And then there's always room for improvement. There's always room for changes, but for sure don't get bogged down and tied into a go live date just because the vendor said so.
(41:12)
So thanks Paul. Great points on that. Okay, what comes next? Complete any required infrastructure upgrades. Now this is important. This should be probably higher up in the checklist because as you're going through a requirements definition, you also have to look at your requirements for infrastructure. Do you have the right bandwidth? Do you have a failover? ISP? Do you have the right cybersecurity protocols in place? Is your firewall set up right? This can be a failure point, right? Because most of the modern organizations and systems are in the cloud, their software as a service. And we have seen organizations get ransomware or hacked. They after go live on a new system because the firewall wasn't set up right or something was left open by the vendor, by your own crew. So it's important that you tidy up on the infrastructure side. Don't let network equipment or your internal servers take the whole thing down.
(42:19)
And that's, excuse me, that's a project in itself, right? So this should be done concurrently before you start the ERP process, but definitely make sure that you're up to snuff when it comes to your infrastructure. Make sure it matches. And the other important part is if you don't have your current infrastructure buttoned up, you can't dictate standards to the vendor because one of the key requirements in the requirements definition is what are your security requirements? And the vendor needs to come up to speed and meet or beat your security requirements, not the other way around. So if you don't have your ducks in a row, your infrastructure in order, you don't have elect to stand on as far as enforcing security guidelines with the vendor.
(43:08)
And then you get on with the implementation, there's kickoff, you start configuration, you have internal subject matter experts sit in with the vendor's implementation consultants and just go through the configuration process. This is the part that takes maybe eight to 10 months in a medium-sized implementation where you're really sitting down in sessions with an implementation consultant from the vendor, and now you're converting the two B process maps and your requirements into specific workflows within the new system. So this is your chance just to have your system set up the way you envisioned it. And this is also the time where you may want to change the processes as you look at the new system. You don't have to stick to the two B process maps we made maybe a year ago. This is a time, this is a good time to do some what if analysis and see how you want the configurations done. Really critical stage
(44:15)
End user testing is really important. User community in engaging with test environments. A lot of systems come with multiple test environments, and it's important that you get in there and start playing with it before you are even officially trained. And I think the modern workforce is really good at this, right? They want to see what the system does, what does this button do? What happens if I click here? You can do all of that in a test environment. So you have to encourage your user base to go in and start clicking around. You're not going to break anything because you're not live. And secondly, you have to point them to the right testing environments, training environment, so that they get familiarity. They can point to bugs, they can have configuration changes. You can do this on day one of the implementation as long as your environment's set up creating training and documentation resources and other critical point.
(45:08)
Now, going back to business process redesign and the two B maps we created, those can be really critical tools for training because it shows you what this process should look like. Now that you know what system you're implementing, you can clearly see what process from A to Z should look like. Where do you hand off? How do you do this thing in a new system? It should be all spelled out. And then if you want, you can couple training documentation that includes the process maps, that includes the vendor's, user guides, and you can create your own if you so choose because your configuration is specific to you. Next thing is establishing a protocol for reporting system issues. Now, this is an ongoing thing. How do you know if there's an issue and how do you report it back and who do you report that to? That needs to be established and communicated.
(46:02)
Now before you go live, there's a whole testing process. How do you know this thing works? Going back to our discussion on system demos, it's the same thing. We did demo scripts there. You need to do testing scripts, but you're not just clicking around aimlessly. You have a script in front of you that says, run these three processes in this order in this specific way to make sure that this module works. So development test scripts is very important. And again, this all ties back to process maps, requirements, definition, everything that leads up to this point. User acceptance test script. This is also important because the vendor's going to ask you to accept the system. You can't just say, yeah, it works. You'll have to formally accept the system and you can't do it if you don't have it tested. You can't do it if you don't have user acceptance test.
(46:58)
So there's multiple ways of doing it. You can have a sample of your functional staff or some SMEs come in and do the testing from a user acceptance standpoint. And then you do functional and user, excuse me, acceptance testing that tells you that the system works based on your specs and you're ready to sign off. And if it doesn't, you don't sign off and send the issues and the bugs back to the vendor to resolve. But you can't do that if it's not documented. If it's not systematically handled, now go live determining which module will go live. This should be defined upfront, but this is a good chance to see readiness, right? Are you ready to go live? Even if all of the things work, you've tested it, users have accepted the product, are you ready? Is it the right time? And you absolutely get that choice right?
(47:57)
The vendor will push you to just push the button, go live so that they can move on. But this is your chance. This is your choice as a client. You could also determine if you've done this sort of analysis before, you can go live with big bang, which is everything all at once, or you can go take some modules live. Again, it depends on what your situation is, how well each module has been configured, what the interfaces are. Because not every, you don't always have the choice of going one module at a time. Sometimes you do. So all of that comes into play now. And then communicate the system, launch schedule with all vendors. I mean, you may have multiple vendors delivering multiple modules if you've gone best of breed route. So it's really important that you're communicating as a PM, as a PMO, as the organization between vendors, your staff and customers.
(48:56)
If you have them as a public organization, you may not need to update the public on everything, but things like what is the public facing functions of certain departments going to look like after this? So all of that comes into play. It should be done throughout, but this is a good checkpoint to make sure that this has been done. And backup in archive. The old system, again, going back to you may not have brought all of the data from an older system to your current system. So what is the mechanism for archived data? How do you get to it? And who's responsible? All of that needs to be discussed, configured, checked off in this last phase. And going live doesn't mean that you're done. There's a post-implementation phase where you need to keep an eye on the product. You have to keep an eye on the users.
(49:55)
You have to keep an eye on how it's working and how the new product is making things more efficient. You might have the vendor stick around for post-implementation support, buy some extra hours. You have consultants that can do that for you from a change management documentation, creating that feedback loop with the vendor standpoint. But it's really important that you keep an eye on post-implementation issues because that's your, to make sure this thing, even after go live is doing what it's supposed to do, and then that you're not paying the vendor for something that doesn't work. So in a nutshell, a really good checklist. Is this the checklist for you? Maybe not, but the audience pointed out some of these things as we consultants like to say, depend on other things. So taking a good look at your operation, what's applicable to you is really, really critical as you take on this important project. Again, if you do this right at the same organization, you shouldn't have to do it again anymore. So with that said, I thank you all for joining this Livecast today, and look out for our podcast, our newsletter, our thought leadership on our website. Lots of great stuff. And reach out with any questions or anything related to digital transformation, ERP modernization. We are here for you. Hope you have a great year, and we'll see you soon. Thank you. Bye.