ERP Journey – Key Considerations for Success – Transcript

Rob Donahue:

People embark on this journey. It’s important not just to look at it as a selection. We really want to look at it as a strategy because you’re making a decision that’s going to affect your organization for a decade. We want to make sure when we do this work we’re very thoughtful, and we strategically look at what the business wants to achieve and then how an ERP solution can help them achieve that.

Announcer:

Welcome to The Hackett Group’s “Business Excelleration Podcast.” Week after week, you’ll hear from top experts on how to avoid obstacles, manage detours and celebrate milestones on the journey to world-class performance.

Dan McCabe:

Hello and welcome to The Hackett Group’s “Business Excelleration Podcast.” Today, we’ll be discussing key considerations for organizations looking to modernize their enterprise resource planning – also known as ERP systems. I’m your host, Dan McCabe, a director in The Hackett Group’s Technology Transformation practice, and I’m joined by Associate Principal Rob Donahue. Rob, welcome to the podcast.

Rob Donahue: 

Thanks, Dan. As we get started, maybe it’s helpful if we talk about how do most organizations define an ERP?

Dan McCabe:   

Great question, Rob. This is often a term that creates semantics. When speaking with our clients, what we usually define in terms of what an ERP is is a system that supports the majority of core back-office functions. A lot of those functions are centered around account-to-report or to cash and procure-to-pay, with some systems also providing full functionality to support HR and other back-office functions. Some of these systems also have industry-specific capabilities. For example, for manufacturing, they provide supply chain and other related capabilities that help support that industry.

Rob Donahue: 

Exactly. Dan. I think you’re hitting the nail on the head that ERP is such a broad term – enterprise resource planning – and it gets pigeonholed with finance so often. But there’s so much in an organization and in the enterprise that the tool sets can deliver – whether it’s manufacturing, execution, full supply chain or quality. It’s not just finance. We want to make sure we call that out as people look at their journey to an ERP and their strategy.

Dan McCabe:   

Another question related, Rob, would be what is best in class or best in suite as we define that for ERP systems?

Rob Donahue: 

Yeah, that’s a really good point, Dan, because when we talk to organizations as you’re defining your strategy – when we’re talking, again, about ERP as an ecosystem and not just the finance world – we want to understand what strategically a company wants to achieve from its business objectives and those key processes like order-to-cash, procure-to-pay, account-to-report, maybe manufacturing, maybe supply chain depending on the industry. I really want to understand strategically they want to go best in class. That’s where we’re looking at the best breed or the best solutions for those point in different edge applications. So one vendor may be for that financial ERP, but really a CPG or a manufacturer and supply chain planning is so important to me, I want the best in breed or best in class of a supply chain tool to get that competitive advantage cause it really affects my business, or I want to maybe look at a single ecosystem. Is there a vendor that can give me all the different tool sets – the best in suite?

Some of the terminology in the industry is composable ERP – when we look at best in class or best of breed, or we use the best leading technologies across the different subfunctions. Then best in suite would be where we’re looking at a system from a single vendor that can support multiple functions across the back office or the organization – not just finance, but also potentially HR, order-to-cash, could also look at doing things like manufacturing execution or manufacturing planning and supply chain in those areas. So you could get it from one vendor like an Oracle or an SAP or a Microsoft, or again, we can go best in class where we look at tool sets that support the business. So our finance stack could be Oracle, SAP, Sage, Workday, or one of the other leading financial platform providers. Then for those key differentiators, the noncommodity processes – we sometimes call them like supply chain planning, SNOP, maybe we go to a Connaxis or a Blue Yonder. Or if transportation management is a huge differentiator for say, distribution organization, you might look at a specialized tool for that that gives you that lift in that place.

Companies have to understand that because there’s complexities, you’re best in class. You’re getting a lot of advanced functionality, but you’re paying more for the tool, and you’re also paying more to manage the integrations cause now those integrations are on you. Best in suite, you’re not getting the most advanced functionality that you might get out of the best in class, but you’re getting it from a single vendor. So you’ve got a leverage opportunity for pricing and buying, and then you’re in a single technical ecosystem for the most part. So you’re not managing many complex integrations through the upgrade path, especially as we go to cloud technologies. So, Dan, companies need to understand that and where ERP is and what their landscape is, but how should a company start really their journey as they look at their legacy platforms and what they want to go to as they transform?

Dan McCabe:   

That’s a great question, Rob, and the ERP is truly a journey that really never ends. So really, what we like to help our clients especially think about is what are the drivers? What are the business cases for helping the organization move to a new platform? So really, that’s important to align across the business – to gain organizational buy-in on the investment they’re about to make. A lot of things we see with our clients is that they have legacy systems that are really no longer supported. So maybe it’s working well today but from the support and evolution of the product itself, that’s not going to happen. Therefore, there’s a strong business need to move away from that platform and seek a new modernized solution. Also, just capability limitations where you’re finding that there’s a lot of process and efficiencies driven by the inability to utilize technology to support those processes in an optimal way.

So that’s another reason we often see our clients looking to move away or seek to go on their ERP journey to find a new modernized platform. Also, the ability to scale and grow, there’s certain solutions that just only meet the needs of an organization of a certain size of complexity and are not able to handle the move to becoming a larger organization or handling more complexities across their various functions. Those are some very common reasons that we see businesses looking to move to new modernized ERP platforms, and it’s again, good to define those upfront and have organizational buy-in that’s the driver for why we’re doing this. Some of the business cases in ROI around the move to a new ERP platform can vary.

So when you look at finance and HR, a lot of things we see as process automation, desire for that, the ability to move away from manual processes and free up people’s time and support to more value-added activities, the ability to move to more a shared service model. So where you don’t have the capabilities and a system to support an organization at scale and move to maybe limiting the amount of folks that you need to support a certain function in an organization is not there with the old system, but you have that ability with the new modernized capabilities. Then better user experience. This is something that we often find is a little bit more of an intangible, but ultimately, is something that keeps organizations competitive and keeps people’s ability to move more seamlessly through the EUI of a system as it supports the various functions of the organization. Again, business case and ROI may vary, especially for finance and HR.

Rob Donahue: 

I think you’re hitting the key points, and the manufacturing one is a great one to talk about, but people need to look at what is their drivers for the business. These are not technical solutions we’re trying to solve for the business. I think that’s just one of the key callouts I want to put out there.

Dan McCabe:

Absolutely. Absolutely. So, again, those are all important points to note and raise at the beginning of your ERP journey, and then just having the vision, so you want to align and make sure everybody understands what you’re trying to solve for. What are you trying to achieve with deploying that new system? You’d be surprised at how many organizations jump right into acquiring and looking to deploy a solution and not having a clear vision of what they’re trying to achieve.

So, again, organizational alignment around that at the onslaught really helps to chart the journey and guide the organization to where you want to be with this solution in the future, and then will really inform how you’re going to get there and what you need to accomplish throughout. Then another key point is just making sure that the business goals and objectives are aligned to your ERP journey. So where you can get lost is technology in and of itself isn’t going to meet the needs of the business unless there’s a clear vision of how it’s going to serve the business. So defining those goals and objectives and correlating them back to what and how you want to deploy your ERP solution is important when you start out on this journey.

Rob Donahue: 

Absolutely. All great points, Dan.

Dan McCabe:

Yep, and then lastly, you want to have a strategy. All of the vision, the business case, all of that will accumulate into a strategy that helps you define a road map. The road map, usually, you want to emphasize some points like what do you want to prioritize in your ERP to get the most out of your investment. Back to your original points, Rob, best in suite or best in class? What is going to serve our organization best given our current environment and where we want to move to? What are the other transformational initiatives that are required around the ERP deployment? Then lastly, what do you have to plan and prepare for overall? So having a clear road map and a sequencing of events to help really guide you through that journey is an important thing to end as you start the initial phases.

Rob Donahue:

The big thing is people embark on this journey. It’s important not just to look at it as a selection, we really want to look at it as a strategy because you’re making a decision that’s going to affect your organization for a decade. ERPs don’t get switched out or upgraded or changed very often, and it’s very impactful. So we want to make sure when we do this work, we’re very thoughtful, and we strategically look at what the business wants to achieve strategically and then how an ERP solution can help them achieve that. Less than, “Hey, I want to upgrade my technology to a new ERP,” it should be, “I’m trying to transform the business, and I’m going to make a decision on a technology enablement platform that is going to affect my company for the next decade,” and be really aware of that as you go on this journey.

Dan McCabe:

Yeah, all great points, Rob. So, Rob, how has a shift to SaaS cloud-based ERP systems impacted how organizations should approach and prepare for deploying an ERP solution?

Rob Donahue:

It’s a huge question, especially in today’s industry and landscape that we have. The shift to SaaS or cloud-based ERP systems has really challenged organizations for a new way of thinking when it comes to technology. Now, a lot of companies have started their journeys to the cloud – whether it’s moving off of legacy data centers and getting to a cloud provider like an Azure and AWS. But additionally, they may be bringing in other SaaS tools, so they’re getting some understanding of how that works. But there’s big considerations just from a business standpoint. There’s spend considerations. How does a shift from a largely OPEX standpoint where cloud, especially after that first-year deployment, is all operating cost versus where you can depreciate an on-prem world in terms of the initial software buy? Then the servers you’ve implemented for it as an allocation and an amortization going forward, that cost is much higher from an OPEX standpoint.

So what does that mean? Then additionally, cloud technology for ERP put some guardrails around us that we didn’t have before in the on-premises legacy world. When we put in a legacy ERP – like an SAP and Oracle, an EBiz, a JDE – we had a lot of flexibility. We had access to the back-end databases. We could write custom code. We could get into bad habits and do things we thought were meeting the business needs but created really complex environments to manage. You have to focus on how the out-of-the-box functionality is going to meet the business needs and then especially for those commodity processes. If they can’t, why can’t they? Are they market differentiators or are you really just trying to do it the same way you did it before because you’ve always done it that way? Additionally, understanding that cloud-based ERPs are shifting you to forcing and leveraging periodic releases and updates, so that limits the amount of customization you want to do because you’d have to manage all those customizations with your regular updates.

Most cloud-based ERPs are doing minimally two releases a year. Some of them are quarterly, and you at some point have to take in these upgrades. So no longer we’re an on-prem world where you could just wait a year to apply service packs and patches or even wait two or three years and then do some big upgrade path upgrade. To bring those in, you’re being forced to do those, so you have to be ready to take those in. You really want to focus on making sure you’re configuring and not customizing – to make sure that when you take those upgrades in, they’re not painful to do and painful to test because of all the integrations and customization you have. That’s also a discussion for that best of suite and best in class. If I’m on a cloud-based financial platform for my core ERP but I’m on a best-of-class system for say things like supply chain planning, procurement, maybe, or other edge applications or red processes, those upgrades are going to force me to test those integrations and make sure they’re still working in the upstream and downstream platforms.

So really understanding what that means from a support model and delivery really makes sense in understanding it. Also, you really need to further leverage vendors and third parties for support. You’re not going to be doing custom development. You’re not going to have basis developers or people code or all those old school type of coding developers. It’s much more configuration and turning of dials. So looking at third-party vendors to help with that support so you don’t have to have such a large technical staff manager or platform is also a big shift in the cloud organizations that we have. So what are some of the key considerations that come up once an organization determines whether it wants to go best in suite or best in class is the best fit for them? What are some of the things that have to happen for each of those as they go forward there?

Dan McCabe:   

Yeah, absolutely, great question, Rob. Really, it’s a shift in prioritization of what you need to be concerned about as you continue forward when making that decision. So when you’re looking at it from a best-in-class strategy, you got to make sure that your technology governance stays in place. It’s easy to get siloed within your organization and focus on individually deploying and utilizing technology for a function and not doing it in a standard enterprise way that meets the needs of the organization as a whole. So it’s important to make sure that you have that top-level governance in place because you can quickly, again, get siloed and then move away from a standardized mindset of how you’re approaching the procurement and deployment of technologies that not only suit the needs of the function, but also making sure that they suit the needs of the organization as a whole.

On top of that, you want to make sure, and a point you mentioned before, Rob, is the integration needs are understood, and the maintenance and support around those are understood when you’re going with the best-in-class solution. So you’re going to have still the need for data to be used at various facets of the organization for different functional purposes, and you want to make sure that stays intact. You don’t want to lose sight of that or create siloed data or confusion of sources of record when you deploy a best-in-class solution. So it’s important to understand what do the integrations need – the ebb and flow of the data. Then on the back end of it, how are you going to maintain those integrations. Once those are built, changes happen in various ways throughout the systems. You got to make sure you have a plan in place to maintain those integrations to understand who’s responsible for those.

Also, you want to make sure the systems can scale and account for unexpected changes in organization. In the best-of-suite world, you’re often able to flush through changes or higher transactional volume a little bit easier than you would be in a world where you’re going to have multiple systems in play and needing all systems to still orchestrate together to achieve what you’re trying to achieve. So it’s important to understand if the business changes in scales, that you have an understanding of how the system will ebb and flow and react to that. From a best-in-suite strategy, you really need to make sure that you have a crisp understanding of the functionality and capabilities at your disposal. So it’s easy to purchase a package that includes functionality that you might already have in the organization or that you’re using through other systems.

So it’s clear to understand upfront what and how that system will serve the organization, and what is your target state with how the technology’s going to support their function. On top of that, you want to make sure that you’re fully going to be deploying and utilizing the tool. So getting the full value out of the system and all of those integrated benefits through a best-in-suite system, you want to make sure that you have a plan in place to deploy it. It’s easy to say, “Oh, I really like a certain aspect of the tool, but not so much others,” and let that sit dormant. You’d be surprised at how much value you could realize from deploying the full suite of the solution to serve the better needs of the organization as a whole. So that needs to be top of mind, understood, embedded at the onslaught of evaluating and selecting the solution.

Also you want to understand on the back of one trap you could fall in with the best-of-suite application is just going under the assumption that the tool is fully integrated on the back end. So that is largely the case for most solutions, but there are instances where there can be a lot of pain if you don’t understand that, for example, something’s working off of the same unified database. So it’s important at the onslaught to understand where and how the solution will ebb and flow across the different modules, as well as support the different functions. Then lastly, you can’t underestimate the investment in the vendor partnership. So from a best-in-suite perspective, you’re really leaning on a vendor to support basically all of your back-office functions and do that in a long-term way that can benefit both you and that vendor. So you got to make sure you understand the partnership and understand who you’re working with on the vendors and to make sure that that partnership’s in place to help make sure you’re all moving forward, benefiting both your organization, as well as theirs at the same time.

Rob Donahue: 

Yeah. I just want to piggyback on that key point you made about understanding around the modules and ancillary solutions in their integration, especially in a best-of-suite situation, and this really goes to talking about how we select an evaluated tool. You want to make sure you’re looking at these tool sets in light of the requirements that you need to deliver your business and how they meet them – whether it’s out of the box, is it a secondary module that’s going to cost more money, is it a third-party item or do they not do it? But then additionally, when you demo and bring these vendors in, you want to make sure you’re asking for targeted information and transactions so you can understand and evaluate how transactions work across these different best-in-suite applications and understand exactly what Dan said, the underlying data model of the integration, because some tool sets will look super integrated on the front end, but on the back end, there’s a lot of things going on that you have to manage.

Others conversely might not look as integrated but are fully integrated on the back end. Understanding how that all works and really questioning to the vendor about what kind of integrations you’ll have to manage between the modules is important. To use an example of SAP, SAP is a very full-suite vendor. They have hire-to-retire, account-to-report and all this stuff in between. However, SAP’s HR platform – SuccessFactors – is architecturally completely different than the entire S/4 HANA suite. So the question is how are those integrations managed between your finance platform and that HR platform if you’re going to bring both in – is a key question to ask that vendor because they’re exceedingly architecturally different from an underlying standpoint. So if you have to manage those integrations, you need to be aware of that as you’re evaluating those vendors in those different areas.

Dan McCabe:   

Great point, Rob. Beyond the technology, what else do organizations need to focus on to successfully deploy an ERP solution?

Rob Donahue: 

Right. You’re exactly right. Selecting the technology and understanding your requirements for that technology suite and the best of class and the best of suite are all important things. But there’s a lot of things that go around an ERP that need to be ready or that you need to be prepared for, have an understanding of to really be successful as you do that deployment. You really have to have a strong data strategy and governance to really optimize the data usage across these different applications. If you’re coming from legacy ERPs or legacy disparate systems, what is customer master looking like? What is supplier vendor master looking like? Do you have it? Are they all over the place? If you’re a company that has a product, how does quote-to-cash, how does quote-to-order work? Where’s order management going to come from? Are your sales teams using a third-party application?

How’s that going to integrate? What does that mean from when a lead becomes a customer, and how that data works and is governed? Those are important things to understand ahead of time going into your ERP journey. Understanding who’s going to own these applications and what the support model is going to be post go-live is an important thing to have a consideration of visibility in there. Obviously, in addition to choosing the tool, depending on the tool you choose, you need to find a system integrator. You really want to have one that’s got the breadth and depth of the fit for your organization for what you want to do. So oftentimes, there’s a whole separate process to say, “OK, I’ve chosen tool X, now I need to find vendor Y or integrator Y to help me implement this.” You need to go through a really measured process to do that as well and understand who your partner is in deploying this massively critical system to your world. Then we can’t underestimate change management.

One of the key things when we do this work from a strategic work and a selection work with clients is that we start to talk to them now about change management. You’d think the change management comes after the system is going live or when it’s going live, but the change management really begins as you’re planning and getting ready and then implementing the system because you’re going to need a lot of people to implement the system. You’re going to have to take people out of their roles now so they can serve on an ERP implementation – whether it’s in a fractional capacity or dedicated to it. You have to look at backfill and workload, and how you keep the lights on and run the business while at the same time deploying this mission-critical application. Understanding that change – how that’s going to work and then how that’ll be mitigated, especially as you go live because the goal for any of these new systems is we no longer want to be managing by transaction. We don’t want to touch every AP or AR that comes through our system.

We want to manage by exception so that 80, 90% of our transactions flow through, and our people are really only looking at the ones that are exceptions, and then they can free up their time to look at data and look at analysis and really drive the business forward. Understanding how that’s going to impact your staffing model, how you’re going to source staffing, that’s really important as part of your change management view. That goes right into the other key point, and that’s resource planning. Having the resource plan in place to understand what new skills or resource requirements you might need, what talent acquisition you might have to do to support the ERP implementation and beyond will be really important. It ties, again, to that partner you’re choosing to help you find the right people and understanding when the tool set you choose, what is the marketplace for talent?

How hard is it to get a person to work on platform X versus platform Y that’ll be your employee is an important consideration as well. So understanding that resource plan and how you’re going to deliver and then support your new ERP solution and all its supporting edge applications and the potential integrations is a critical component that has to happen to ensure success. Choosing the technology is a huge part of the foundational work to get into a new ERP, but having that strategy upfront – knowing what we want and then have a clear understanding of how we’re going to deliver it, who’s going to deliver it and what we need to prepare for that delivery – will be important to getting great success out of there.

Dan McCabe:

Great points and great discussion, Rob. Thanks for joining us today. For more information, listeners can visit the enterprise applications implementation page of our website. We’ll also include a link in the show notes below. Thank you and have a great day.

Announcer:

Thanks for listening. You can find the audio, helpful resources and a transcript of each episode at podcasts.thehackettgroup.com. If you liked this episode, please share it. You can also subscribe at Apple Podcasts or your favorite listening app so you never miss an episode. We’d welcome your feedback by tapping the rating on this or any episode, or send us an email at podcasts@thehackettgroup.com. The Hackett Group is a global leader in defining and enabling world-class performance. Learn how we can assist with your improvement journey at www.thehackettgroup.com.