All ERP projects require risk man­age­ment. No one wants to spend time, mon­ey, and ener­gy on a project that’s doomed to fail. Yet busi­ness­es con­tin­ue to begin an ERP project with­out hav­ing the right plan and peo­ple in place to succeed.

In part one of this series, Joshua Green­baum, prin­ci­pal at Enter­prise Appli­ca­tions Con­sult­ing, shared with us why projects fail and ways to avoid com­mon mis­takes. In this next part, we cov­er what you need to know and do to start your project on the right track.

As the dead­line to move to SAP S/4HANA is fast approach­ing, this is the best time for busi­ness­es to take note of how to lead a suc­cess­ful ERP imple­men­ta­tion through its launch and beyond.

Sharon: What are the most crit­i­cal first steps busi­ness­es should take before imple­ment­ing a new ERP system?

Josh: The first thing a busi­ness needs to do is to pay atten­tion to change man­age­ment and the peo­ple com­po­nent. It is crit­i­cal to not treat the project as a tech­ni­cal endeav­or, but rather one that involves peo­ple and busi­ness change. Iden­ti­fy the stake­hold­ers who will have to live with the sys­tem long after it’s been imple­ment­ed and bring them into the con­ver­sa­tion from the start.

The next step is to build a busi­ness case. It is impor­tant for CIOs who have tremen­dous back­ground in SAP from a tech­ni­cal stand­point to do a bet­ter job incor­po­rat­ing busi­ness require­ments and ROI.

The oth­er thing you need to do is have a good part­ner to work with. Unless you’re one of the rel­a­tive­ly rare com­pa­nies that has the in-house staff and exper­tise to do the project with­out a part­ner, this step is crit­i­cal. Regard­less of how much in-house exper­tise you have, how­ev­er, at some point you may need to draw on a third-par­ty ser­vice provider or tech­ni­cal con­sul­tant, or some com­bi­na­tion of both.

Sharon: What’s the best way to find the right sys­tem inte­gra­tor for your com­pa­ny? What are some good ques­tions to ask as you are eval­u­at­ing poten­tial partners?

Josh: To start, get a rec­om­men­da­tion from anoth­er com­pa­ny, par­tic­u­lar­ly one in your indus­try and/​or geog­ra­phy. Your sys­tems inte­gra­tor should under­stand your indus­try and the geog­ra­phy where you do business.

Ask a prospec­tive inte­gra­tor for ref­er­ences that match your com­pa­ny as close­ly as pos­si­ble and then do your due dili­gence and talk to them. You should also insist on know­ing who the sys­tem inte­gra­tor intends to put on the project and ask what qual­i­fi­ca­tions or cer­ti­fi­ca­tions they have for the work you’re plan­ning 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 mea­sure progress and how they plan to keep you up to date on project progress, par­tic­u­lar­ly for time­lines and bud­get. But per­haps the most impor­tant dis­cus­sion to have is how they plan to han­dle the change man­age­ment require­ments. What process­es do they use? Do they have change man­age­ment experts who you can talk to ahead of time? This will be the most crit­i­cal com­po­nent of your suc­cess. You’ll need to make sure they don’t just pay lip ser­vice to the con­cept but are actu­al­ly ded­i­cat­ed to real change management.

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

Josh: It use to be that the CIO would get approval from the board to spend mon­ey for the project and that would be it. Now, buy-in needs to be more of a matrixed process because there are more stake­hold­ers. Every­one needs to have a sense of par­tic­i­pa­tion and there needs to be uni­ver­sal buy-in for a project to be con­sid­ered successful.

All the dif­fer­ent lines of busi­ness (LOB) that are direct­ly affect­ed by an ERP imple­men­ta­tion need to be part of the buy-in and part of the jus­ti­fi­ca­tion for the project. At the end of the day, they will expe­ri­ence the changes first-hand. So they need to be part of your change man­age­ment and user accep­tance process. If the LOB users don’t like what they’re get­ting, they won’t use it, or they will use it improp­er­ly or insuf­fi­cient­ly, and you won’t real­ize any value.

As for keep­ing the entire com­pa­ny informed, you need to have trans­paren­cy and account­abil­i­ty for and from all par­ties involved — ven­dor, sys­tem inte­gra­tor, and cus­tomer. With­out that, you real­ly run the risk of things going off track.

Sharon: What teams with­in an orga­ni­za­tion should be iden­ti­fied as key play­ers? How should they work together?

Josh: To start, the teams need to be matched to the process­es that the imple­men­ta­tion is enabling. That’s very impor­tant. The oth­er part is that you must select your own inter­nal A‑Team. The A‑Team con­sists of the folks who don’t take no for an answer and do the very best job they can every time.

Often, busi­ness­es hes­i­tate to select the A‑Team because they don’t want to stretch their best work­ers too thin. They’re there to work on their day jobs whether it’s pro­cure­ment, sup­ply chain, HR, invoic­ing, rec­on­cil­i­a­tion, or any oth­er LOB group. But if you pull back your best peo­ple, the result is a B‑Team that will give you B‑level work.

When it comes to work­ing togeth­er, one of the uni­ver­sal prob­lems we have with des­ig­nat­ing a team is that we real­ly don’t under­stand how to mea­sure its suc­cess. We don’t even know how to teach team­work. We mea­sure things like whether the project is on time, or if the tasks are com­plet­ed. In very few instances, the sys­tem inte­gra­tor active­ly man­ages the project through a col­lab­o­ra­tive process. But for the most part, we tend to put teams togeth­er, hope for the best, and assume some mag­ic will hap­pen. In the absence of trans­paren­cy, 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 mea­sure your team’s suc­cess along with the project’s health.

The last thing to men­tion is that it takes three par­ties — the ven­dor, the sys­tem inte­gra­tor, and the cus­tomer — to real­ly screw up a project. All three have equal respon­si­bil­i­ty. Every­one needs to try to put their best foot for­ward. That’s how you get these projects done.

Sharon: What types of ques­tions should an orga­ni­za­tion ask about the soft­ware? What should they ask about the inter­nal expec­ta­tions for what it will accomplish?

Josh: The obvi­ous ques­tion you need to ask is, ​“Is the soft­ware going to meet my needs and are my needs and require­ments going to be eas­i­ly instan­ti­at­ed by the soft­ware?” With that answered, I still wouldn’t rec­om­mend being the very first in your indus­try to imple­ment some­thing that’s nev­er been imple­ment­ed from a ven­dor, even a top ven­dor, unless you have got some real safe­ty valves built into a project.

Anoth­er ques­tion you should ask is, ​“How well does the soft­ware fit my busi­ness, my geog­ra­phy, and my exist­ing infrastructure?”

A lot of times, par­tic­u­lar­ly in this era of dig­i­tal trans­for­ma­tion, com­pa­nies are real­ly try­ing to get a step ahead. To do that, you some­times must go out on a limb with a prod­uct, with a tech­nol­o­gy, or with a focus that may not be ful­ly baked. Then you real­ly need to have a good part­ner­ship with the ven­dor that’s jump­ing off this cliff with you. Ide­al­ly, those of us in the SAP com­mu­ni­ty who have been long-stand­ing SAP cus­tomers, that rela­tion­ship should be there already.

The oth­er ques­tion you need to ask is, ​“Do we real­ly under­stand the busi­ness process that we have today? Do we real­ly under­stand how we want to evolve?” A lot of times the start­ing point is the right tech­nol­o­gy. But beyond that, you need to know how you want to rethink your busi­ness process­es. That must be nailed down as close­ly as pos­si­ble. Some­times it can be. Some­times, com­pa­nies are try­ing to invent some­thing and they’re not even sure they know what it’s going to look like. That’s when you typ­i­cal­ly bring on a strate­gic con­sult­ing part­ner to help you think through it.

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

Sharon: What checks and bal­ances can an orga­ni­za­tion inte­grate to keep a project on task and to pre­emp­tive­ly iden­ti­fy challenges?

Josh: The main check and bal­ance is com­mu­ni­ca­tion. You must have that. You can’t wait until a prob­lem has real­ly fes­tered to start solv­ing it. That means hav­ing open lines of com­mu­ni­ca­tion. It also means mak­ing sure there’s a stake­hold­er-led steer­ing com­mit­tee that’s active and proac­tive through all project stages.

Imple­men­ta­tions like these are a peo­ple process. These are human beings who need to work togeth­er, and they won’t always do this just because they’re sup­posed to. They need direc­tion, help, and over­sight. That needs to be baked into the process.

To have a suc­cess­ful ERP imple­men­ta­tion, you need trans­paren­cy and account­abil­i­ty togeth­er. You need a peo­ple-cen­tric process in place. And last­ly, but equal­ly impor­tant, you need to choose your part­ners carefully.

Are you ask­ing some of these ques­tions as you plan for your SAP S/4HANA imple­men­ta­tion? Attend one of our road shows in a city near you.