All ERP projects require risk management. No one wants to spend time, money, and energy on a project that’s doomed to fail. Yet businesses continue to begin an ERP project without having the right plan and people in place to succeed.

In part one of this series, Joshua Greenbaum, principal at Enterprise Applications Consulting, shared with us why projects fail and ways to avoid common mistakes. In this next part, we cover what you need to know and do to start your project on the right track.

Joshua Greenbaum, principal at Enterprise Applications Consulting

As the deadline to move to SAP S/4HANA is fast approaching, this is the best time for businesses to take note of how to lead a successful ERP implementation through its launch and beyond.

Sharon: What are the most critical first steps businesses should take before implementing a new ERP system?

Josh: The first thing a business needs to do is to pay attention to change management and the people component. It is critical to not treat the project as a technical endeavor, but rather one that involves people and business change. Identify the stakeholders who will have to live with the system long after it’s been implemented and bring them into the conversation from the start.

The next step is to build a business case. It is important for CIOs who have tremendous background in SAP from a technical standpoint to do a better job incorporating business requirements and ROI.

The other thing you need to do is have a good partner to work with. Unless you’re one of the relatively rare companies that has the in-house staff and expertise to do the project without a partner, this step is critical. Regardless of how much in-house expertise you have, however, at some point you may need to draw on a third-party service provider or technical consultant, or some combination of both.

Sharon: What’s the best way to find the right system integrator for your company? What are some good questions to ask as you are evaluating potential partners?

Josh: To start, get a recommendation from another company, particularly one in your industry and/or geography. Your systems integrator should understand your industry and the geography where you do business.

Ask a prospective integrator for references that match your company as closely as possible and then do your due diligence and talk to them. You should also insist on knowing who the system integrator intends to put on the project and ask what qualifications or certifications they have for the work you’re planning to do. Hold their feet to the fire about who is doing the project. Too many times they sell you the A-Team and then show up with the B-Team.

Ask how they measure progress and how they plan to keep you up to date on project progress, particularly for timelines and budget. But perhaps the most important discussion to have is how they plan to handle the change management requirements. What processes do they use? Do they have change management experts who you can talk to ahead of time? This will be the most critical component of your success. You’ll need to make sure they don’t just pay lip service to the concept but are actually dedicated to real change management.

Sharon: Whose job is it to get company buy-in for an ERP project? What about to keep the entire company informed about the implementation?

Josh: It use to be that the CIO would get approval from the board to spend money for the project and that would be it. Now, buy-in needs to be more of a matrixed process because there are more stakeholders. Everyone needs to have a sense of participation and there needs to be universal buy-in for a project to be considered successful.

All the different lines of business (LOB) that are directly affected by an ERP implementation need to be part of the buy-in and part of the justification for the project. At the end of the day, they will experience the changes first-hand. So they need to be part of your change management and user acceptance process. If the LOB users don’t like what they’re getting, they won’t use it, or they will use it improperly or insufficiently, and you won’t realize any value.

As for keeping the entire company informed, you need to have transparency and accountability for and from all parties involved—vendor, system integrator, and customer. Without that, you really run the risk of things going off track.

Sharon: What teams within an organization should be identified as key players? How should they work together?

Josh: To start, the teams need to be matched to the processes that the implementation is enabling. That’s very important. The other part is that you must select your own internal A-Team. The A-Team consists of the folks who don’t take no for an answer and do the very best job they can every time.

Often, businesses hesitate to select the A-Team because they don’t want to stretch their best workers too thin. They’re there to work on their day jobs whether it’s procurement, supply chain, HR, invoicing, reconciliation, or any other LOB group. But if you pull back your best people, the result is a B-Team that will give you B-level work.

When it comes to working together, one of the universal problems we have with designating a team is that we really don’t understand how to measure its success. We don’t even know how to teach teamwork. We measure things like whether the project is on time, or if the tasks are completed. In very few instances, the system integrator actively manages the project through a collaborative process. But for the most part, we tend to put teams together, hope for the best, and assume some magic will happen. In the absence of transparency, we find out after the fact that the team hasn’t done as well as it could have. So, you need to be able to measure your team’s success along with the project’s health.

The last thing to mention is that it takes three parties—the vendor, the system integrator, and the customer—to really screw up a project. All three have equal responsibility. Everyone needs to try to put their best foot forward. That’s how you get these projects done.

Sharon: What types of questions should an organization ask about the software? What should they ask about the internal expectations for what it will accomplish?

Josh: The obvious question you need to ask is, “Is the software going to meet my needs and are my needs and requirements going to be easily instantiated by the software?” With that answered, I still wouldn’t recommend being the very first in your industry to implement something that’s never been implemented from a vendor, even a top vendor, unless you have got some real safety valves built into a project.

Another question you should ask is, “How well does the software fit my business, my geography, and my existing infrastructure?”

A lot of times, particularly in this era of digital transformation, companies are really trying to get a step ahead. To do that, you sometimes must go out on a limb with a product, with a technology, or with a focus that may not be fully baked. Then you really need to have a good partnership with the vendor that’s jumping off this cliff with you. Ideally, those of us in the SAP community who have been long-standing SAP customers, that relationship should be there already.

The other question you need to ask is, “Do we really understand the business process that we have today? Do we really understand how we want to evolve?” A lot of times the starting point is the right technology. But beyond that, you need to know how you want to rethink your business processes. That must be nailed down as closely as possible. Sometimes it can be. Sometimes, companies are trying to invent something and they’re not even sure they know what it’s going to look like. That’s when you typically bring on a strategic consulting partner to help you think through it.

You must make sure you know the business case before you even begin to look at what the software’s going to do for you.

Sharon: What checks and balances can an organization integrate to keep a project on task and to preemptively identify challenges?

Josh: The main check and balance is communication. You must have that. You can’t wait until a problem has really festered to start solving it. That means having open lines of communication. It also means making sure there’s a stakeholder-led steering committee that’s active and proactive through all project stages.

Implementations like these are a people process. These are human beings who need to work together, and they won’t always do this just because they’re supposed to. They need direction, help, and oversight. That needs to be baked into the process.

To have a successful ERP implementation, you need transparency and accountability together. You need a people-centric process in place. And lastly, but equally important, you need to choose your partners carefully.

Are you asking some of these questions as you plan for your SAP S/4HANA implementation? Attend one of our road shows in a city near you.