Lessons Learned from the ERP Frontline

Of all the rules, this is the most important one. In many cases, it's not intuitive.

ERP project success has several obstacles to overcome, including competing corporate initiatives and quarterly P&L goals. It's a rare CEO that gives business leaders a pass on ongoing profitability and growth goals because of an ERP implementation.

Some senior business leaders might call this an I.T. "cop out". After all, as an I.T. leader, isn't this YOUR job? The answer is yes and no.

Here's why.

Business leaders have credibility with their employees (that the I.T. department doesn't have.)

One of the biggest challenges is selling the importance of the ERP project. Employees need to understand why the project is important, how processes will change, what the expected benefits will be and specifically how their individual jobs will be affected. They will be afraid of the unknown and will resist change. They need to be "on board".

No one is better positioned to help sell the initiative and cope with change management issues than local business management. While I.T. can help craft the message, business leaders need to help deliver it.

Business leaders control the resources needed to gather requirements, determine functionality gaps, cleanse legacy system data, approve the system design, test the system and (possibly) deliver the training.

ERP projects will require significant personnel resources from across and throughout your company and it's the business leaders who manage those people.

Business leaders set the priorities.

It's critical that Business leaders be fully conversant with the ERP project in order to make good decisions with respect to managing priorities as the project progresses.

LOB (Line of business) leaders allocate their people among competing priorities. They control their peoples' compensation and career progression. They have the credibility it takes to help sell the reasons for doing the ERP project. They play a significant part in setting expectations relating to the project's expected process improvements, sales increases or cost reductions. LOB leaders set the agenda.

Business leaders who will help with the change management efforts, trainers (and trainees) who will spend significant time getting ready for go-live and other administrative tasks like helping to cleanse data, identify functional requirements and gaps; communicate project status to their sites or departments etc.

CIOs can install systems. Business leaders help implement systems.

The answer is that ERP implementations are business initiatives.

If your company identifies "up front", exactly who is responsible for obtaining the ERP benefits, it will be a tremendous help in getting and keeping senior leadership committed to the project.

It's like the old joke about the hen and the pig. When it comes to a bacon and egg breakfast, the hen is involved, the pig is committed. To be successful you must have the commitment of senior leadership.

For example, if purchasing savings are expected, your V.P. of Purchasing should understand how (s)he will be improving purchasing performance with the new tools - whether through vendor rationalization, corporate contracts, better credit terms, reducing the transaction cost of each PO or refining the purchasing process. (S)he should be at the front of the room whenever your purchasing teams are together, helping to evangelize, motivate, and teach.

In a perfect world, your Purchasing team should have been responsible for determining the potential purchasing benefits in the first place. If your functional experts weren't involved in identifying (or at least "signing off") the expected benefits, it is unlikely they'll be committed to achieving the results.

Take away the opportunity for business leaders to "opt out" after the fact. "I never believed we could get those savings!" is of little help once you've already spent millions on ERP.

In the 80's and 90's I.T. teams used to talk about the "invisible upgrades" - meaning that the projects were to be run so smoothly, that no one would notice that an upgrade had occurred.

This begs the question: "If no one noticed, why do it?"

Implementing a new ERP system is all about change. The idea is to improve efficiencies, clean data, to facilitate faster decisions with better data - by and large to make all the business processes more standard, predictable and transparent.

It involves a LOT of change. And change is hard. So, it is with this in mind that I suggest that since your employees will have to deal with the pain of change, you might as well make it BIG!

My mother always used to say that it was far less painful to rip the Band-aid off quickly than to remove it by slowly tugging at it. In my experience, the same applies to implementing ERP.

Resist the temptation to "leave well enough alone". Look to improve everything. Take full advantage of the technology and capabilities of the new system.

There won't be any more pain involved and you'll have the opportunity for level-step improvement.

After completing my second ERP implementation, I discovered a very useful HBR article, entitled "The Hard Side of Change Management". The authors interviewed 225 companies and determined that there were 4 significant factors which determine ERP success. They have developed a "DICE framework" that allows you to score where your project will fall along a success curve.

The four major factors are:

Duration of project (and time between project reviews)
Integrity of team performance (capability of your project team)
Commitment of senior executives to the project
Extra effort required by employees (workload) to accomplish the project.*

*See Appendix B for a better understanding of how ERP increases employee workload.

You can download a copy of the HBR article at:
http://harvardbusinessonline.hbsp.harvard.edu/b01/en/common/item_detail.jhtml?id=R0510G

This will be the best $6 you ever spent.

Read this article BEFORE you begin your project and score yourselves using the DICE methodology to make sure that you fall within the predicted success range. If necessary, spend extra time up front to improve executive support, to break your project into smaller chunks or to upgrade your implementation team to improve your chances for success.

Six members of my team took the DICE test independently and we all scored within one point of each other. It works. It's accurate. Believe it.

While it is far preferable to have Sarbanes-Oxley processes in place before beginning an ERP project, if your current processes are lacking, now is the time to put them in place.

Properly configuring security roles will help enforce operational segregation of duties issues.

Solid SDLC processes will improve design, documentation, testing, training and quality of the code that is promoted to production.

I would highly recommend that you look for some SDLC automated solution to help manage the process. You need to avoid paper at all costs and implementing electronic workflow for approvals is far superior to snail mail approvals. I would refer you to Lesson #9. Go Fast!

You also need to think about how you will support the system once you go live. Your support team will ask for unlimited security in order to more effectively diagnose issues, but SOX rules will not allow this in your production environment.

You'll need to setup a development environment strategy on the test system that is refreshed on a frequent basis, to allow for troubleshooting outside the production environment. We found that a weekly refresh worked best for us.

In the ERP projects I've managed, the functional team is made up of "pairs" - (i.e. a Purchasing guru from the business, sitting with his/her functional configuration consultant*). The business person provides all the functional (process and task) knowledge and the consultant provides the system configuration skill set.

Over the course of the project your functional person becomes comfortable with system configuration to the point that once the project is complete, the consultants can go on their merry way.

At the beginning of each project, I ask the business leaders to make a list of their "franchise players" - people so valuable to their respective business units, they can't do without them.

Then I ask for those people for the project.

Selfish? Maybe.

But ask yourself this: "Do you want people you can afford to do without, designing and building your future processes?" Probably not.

And remember too, that your functional team will need the street credibility with the rest of their functional peers to provide them with confidence in the new system. If they are leaders within their relative functions, it will go a long way towards end user buy-in of your new system.

Plan up front, to re-integrate these people back into the business, once the project is up and running (and stable). Your team members will have a vested interest in making sure the system works as planned and they'll be far more effective if they're doing that back within the business. Replace these people on your support team, with other functional experts - as a developmental assignment. If you can manage to rotate business people through functional support assignments, you'll help solidify system understanding throughout your organization.

*Major consulting firms used to have dedicated fulltime staffs and a proprietary methodology with which to help implement ERP. Consultants used to have significant business/process experience as well as configuration experience. Now, it is not unusual for consulting companies to subcontract ERP configuration expertise to independent consultants who offer varying degrees of process expertise. This means it increasingly important that your internal business process people know their function.

Your functional experts will come from across the organization. If your company is national or international, it will be necessary to co-locate the team.

ERP implementations are so complex and move so quickly, that you will not be able to overcome the barriers of time zones and distance if your team is dispersed across the country.

In my experience, putting everyone together in a common environment, allows for fluid communication, on-the-spot meetings, decisions and open debate. It makes it as easy as possible to keep everyone on the same page, to correct misunderstandings and/or misperceptions.

ERP modules are integrated, so what one processes does "upstream" affects functions downstream. These people have to be talking together to make sure that processes work across all functions.

You simply can't do that very easily or effectively if people aren't in the same room.

Typically travel and related expenses (for your team and your consultants) will account for about 15% of your total project cost. This expense is well worth it.

When you ask for the best and brightest people, the business leaders may counter with an offer of part time help. Resist this temptation with every fiber of your being.

While it is very tempting to accept part time help from a terrific resource, you will need this help on a continuous basis. The entire project team cannot be held up because your part time member is off "doing their regular job". It's simply too expensive to operate this way.

This situation also puts undue pressure on your part time candidate. (S)he will feel the need to perform 100% of their regular job as well as 100% of the project work. While this is a noble thought, you will burn these people out very quickly.

And no one wins if that happens.

During a very early project meeting with senior executives, I communicated the daily project expense run rate.

Jaws dropped.

While everyone knew how much the total project cost was, they hadn't internalized the labor component into a daily rate.

We were planning on spending $60K a day. And at that rate, you had BETTER go fast!

Here are some strategies to help move things along quickly.

1. Pave the way to fast decisions with a Decision Matrix. A Decision matrix is a one page document which spells out who is involved in the project decision making process. By agreeing in advance, who will make, approve, consult and be informed on each type of decision, you'll vastly improve your ability to get things done. Appendix A contains an example.

2. Identify executive teams up front. For example, if you're implementing a Financial system which will result in process or reporting changes across several lines of business, it may be in your best interest to create an advocate group of Finance VPs from each line of business with whom to meet to consult, inform and build buy-in with their respective groups.

3. Do NOT revisit decisions. Remember that you're spending $60K a day! Do you really want to go back and revisit decisions? This is a guaranteed way to slow down a project, bloat a project budget and miss a deadline.

4. It's tougher to hit a moving target. No matter how well you've sold the benefits of your ERP project there will be those who are not on board. These "snipers" may sit quietly and try to sabotage the work you're doing. The faster to go, the more difficult for dissenters to be effective.

5. Keep your eye on the prize. You will make literally thousands of decisions during the course of your project. Keep asking the question: Will the outcome of this decision have a material affect on our ability to achieve our project goals? Will it adversely affect our customers? If not, don't sweat it too much. Move on.

6. Manage using Roles NOT Rank. Command and control decision organizations are deadly impediments to moving quickly. If you've been successful in recruiting great people for your project, regardless of their job titles, let them do their jobs! Assign them responsibility and let them use it. Your decision matrix will define the scope of their decision making ability. Everyone needs to be able to speak candidly and casually with everyone else on the project, whether they came on board as a clerk, manager, director or VP. Throw those old job titles out. You're all on the same team.

A "vanilla" implementation refers to one where you implement the standard features of the ERP system without modification. You install it "out of the box".

If you're working at a company of any size, you've likely spent several millions of dollars on your ERP software. And you'll be immediately tempted to change it to match what you're doing today.

Stop.

Understand up front, that if you make significant changes to packaged software, the consequences may not be immediately visible. Here's what you'll find out afterwards.

1. Your ERP vendor will not support modules that you've customized. The burden of proof will always rest with you, to prove that the vendor's portion of the code isn't working properly, once you modify it.

2. Unless carefully implemented, your customizations can be a barrier to seamless future upgrades. Remember that every time you change code, you must re-integrate the changes into subsequent upgrades, before you can implement them. This applies to (vendor provided) code patches as well.

3. ERP systems always bump up against support windows. Your current system may be supported for several years into the future, but these windows end at some point. There will be vendor pressure to stay relatively current on your releases, or risk having vendor support lapse. The more customizations, the more difficult the task. I have heard of some companies who actually re-implemented ERP rather than face the task of trying to upgrade!

4. You've just provided lifelong job security to your ERP developers.

That said, there will always be some changes that need to be made. In my experience, our team needed to rewrite a standard delivered Purchase Order to provide our vendors with all the information they required. We took a copy of the standard code and identified it as a customization (so we could easily identify it for future patches or upgrade integration), then rewrote the code.

Keep these changes to an absolute minimum (at least until you've had some significant experience operating your new system) and you'll be glad you did.

There will always be some examples of where legacy systems will outperform standard ERP functionality.

What really matters is to stay focused on the greater good. In every project I've been involved in, when a variety of legacy systems are being replaced by a common ERP system, more sites tend to gain functionality, than the number who lose functionality.

It's most important that the company overall, improves its processes and performance.

The expectation that every function at every site will improve needs to be addressed up front. It just won't happen - especially if your company runs heavily customized legacy systems.

The burden of proof for maintaining functionality outside the scope of standard ERP must reside with the site. They may be entitled to make a case for a customization, but in the end the decision needs to rest with the Project Manager. Refer to Lesson #9 Go Fast!

In all likelihood, unless the customization provides significant benefits for everyone, it won't happen right away, if ever.

I hate to be the one to break it to you, but the shiny new ERP system you're installing will be your legacy system a year from now.

It doesn't make sense to make everything absolutely perfect before launching. Sure - the functionality should work as designed - all the big promises kept.

But if writing those last three custom reports means you're about to miss a go live date, write them later.

You will be tempted to make everything perfect. After all, there are people out there waiting in the weeds - waiting for any opportunity to say "I told you so!"
And there will always be something that doesn't work, regardless of all your testing. Someone, somewhere will find a way to break (or hang) a process. There is no such thing as a perfect system.

You're always better off launching, getting some experience, finding some flaws and getting them fixed -fast.

The ONLY exception to this rule is Payroll. If you are putting in a new payroll system, test until you can guarantee the new system works as expected.

My team once parallel tested seven consecutive weekly and bi-weekly payrolls before certifying that our payroll system was 100% ready to go. Our go-live criteria was 100% accuracy.

You can't mess with people's pay, ever.

ERP projects really expose how bad your legacy system data is. If your company is typical, your data will contain vast amounts of duplications, miscoded items, missing, erroneous and inconsistent data.

I was shocked to learn that fixing this data can cost as much as 10% of your entire project.

During ERP projects, you need to determine how the data will be cleansed and secondly, figure out how you'll maintain data integrity going forward.

Here's an example. In one ERP implementation, our legacy system contained 44,000 vendors. That's as many vendors as Wal-Mart! After doing some analysis, we found:

a) 25,000 of these vendors hadn't been used in over two years.

b) Many were duplicate vendors, with minor differences in the way their names were entered in the system.

c) Many were branch offices of the same vendor (we were missing the opportunity to negotiate pricing at a corporate level).

d) Some vendors had as many as 32 different credit terms with us!

e) The data structure of our new system enabled us to load one vendor, with multiple branch addresses, causing us to have to massage legacy data significantly.

And this was just one of many master data files.

By the time we were done cleansing this data, we were down to 11,000 vendor records. And some of this work had to be delegated to our lines of business to cleanse. No one person in your organization will be able to do this on their own without significant business support.

This takes time, research and also requires that you to build a process to circumvent the same outcome with your new system! One of the decisions you must make, is who owns the data (the business does) and who will keep it clean, going forward (again, someone in the business).

In many instances, your company will decide to assign this task to a new Master Data Coordinator, who will either monitor and cleanse data as your employees enter it (after the fact) or who will be the sole person to add new data to the system (up front) to ensure data integrity. Either way, this will be a change from what you do today.

Don't underestimate the challenges of poor legacy data. Remember too, that cleaning this data in a time effective manner is also critical to keeping your project on track.

Entire books have been written on Change Management. Getting your employees to understand why the project is going on and getting their buy-in is the most difficult part of the entire effort.

By nature, everyone hates change. And installing a new ERP system is BIG change.

If you enjoy strong management support of your project and you've assigned responsibility for the project benefits to business leaders, it's far more likely that you will succeed in winning over the hearts and minds of your employees.

Because you won't have tried to do it alone.

Change Management is where your consulting partner can add a lot of value. They can help you through a process to identify key manager project advocates and detractors, identify objections and concerns and help you put together a plan to support your advocates and help address the non-believers.

They can also help craft a communication plan that segregates your company employees by managers, functional experts and general users, so that your project communications can be targeted to each target group.

These "soft skills" are actually the most difficult part of any large project. In my estimation getting the Change Management right is the single largest factor of project success.

No matter how much testing and training you do, once you go live with your new ERP system your company will go through what is known as a "performance dip", as your employees learn to use the system effectively.

How long this "dip" lasts will depend entirely on how well you've run your project. If things have been run well, the performance dip should only last for a few weeks - perhaps a month or so.

If your management buy-in is lacking, or your employees weren't given adequate training or time to play with the new system, if they don't understand the new processes, your performance dip could last for many months.

And no one wants that.

But understand that a "performance dip" will happen. You (and your business counterparts) will need to manage through it.

Now that you've gone live, congratulations! Phase two starts immediately.

To help shorten the "Performance Dip" and speed up system adoption, build some reporting metrics that help managers better understand how their teams are using the system.

For example, if you're implementing a payables system with an automatic 3-way match, what percentage of the POs are auto-matching? Why? Why not?

How much manual exception processing is happening? By whom? Why?

Old habits die hard. If your company used to emphasize "just get the job done and the next guy will fix it!", then you're in for a difficult time. Integrated ERP systems work best when each stage of the process is managed properly.

ERP Short cuts are never short cuts. If someone pushes a PO through the system with missing or inadequate information, it'll cause delays when Accounting tries to pay the invoice. In the old days, it didn't really matter. It was someone else's problem.

Now that you're managing processes, end to end, each step is visible. Everyone is accountable.

And you should do anything in your power to help the business manage the processes efficiently.

a. Measure the process and performance vs. planned benefits

b. Modify your processes as required. Retrain your employees if necessary. Start user groups so functional teams can collaborate and learn from each other. Start a dialog.

c. Manage for results. Measure again.

There's an expression I'm quite fond of. Solve every problem twice.

What this means, is solve the problem (get the transaction through the system) THEN, address the source of the problem (the reason the problem occurred in the first place).

One issue that often gets overlooked is whether the goals of your new ERP project align with the way your company currently compensates its employees.

In many instances, annual compensation plans and performance bonus plans are already in place and are difficult to change mid-year.

But if you're rewarding an obsolete set of performance metrics (like local site profitability) and your desire is for different objectives (overall company profitability) you could be in for a rough ride.

Your employees' behaviors will always "follow the money".

For example, a local site likes to use a local vendor but Corporate purchasing wants to secure a new national supplier, whose pricing will benefit the overall corporation, possibly to the short term detriment of the local site. (Say for example, Site A might have to spend $1000 more with the new vendor, but the corporation might save $50,000 across all other sites).

If the site's management are compensated based upon the site's P&L, and in this singular case, the new supplier adversely affects these results, what behaviour might you expect?

At the earliest possible point in your project, you should begin the discussion about which results are most important to your company as a whole. If you can't convince senior leadership that a significant portion of bonus should be based upon ERP benefits realization, you're going to have a tough time getting buy-in where it most counts - from the people who will use (or NOT!) the new processes and system.

To quote a former colleague, "What gets measured gets done. What gets rewarded, gets done faster!"

Don't make your employees choose between the size of their paycheck and supporting your ERP project.

If the scope of your ERP project includes implementation in countries outside the United States, you will be faced with an additional set of challenges.

The first challenges are overcoming the barriers of language, culture, foreign regulations, distance and time zones.

International projects contain all the challenges listed in this lens PLUS, the international anxiety of having a project managed from a country outside your own.

Special effort must be made to understand and adapt to cultural differences. For example, in many EU countries, vacation policies are significantly more generous than in the U.S. France, for example, usually offers 5 week vacations and also other paid leave benefits we just don't have here.

In France, never, never, never try to go live in August. The entire country is on vacation.

Secondly, work weeks tend to be shorter than ours. In France a 35 hour work week is standard (although this may be changing).

And culturally, I've found that while European sites contain dedicated and hardworking employees, they simply have a different approach to work than we do in the U.S.

The statement that Europeans work to live and here in the U.S. we live to work is very true in my experience.

Expect a natural resistance to working late evenings and occasional weekends. It's not you, your project or their dedication. It's their culture.

Accordingly, it's always smart to add some time to the project plan for European implementations.

Additional effort must be made to understand and implement your project to support local regulatory requirements (especially HR requirements), adhere to privacy laws (which require European employees to sign a release, if their personal information is to reside on a computer outside Europe).

In international projects distance is your enemy. If you're working with European sites, early mornings offer you your only commuication window.

It is absolutely essential to make sure that your European partners particpate in all weekly status meetings. You need to make them feel like one of the team - because they are.

Access to Instant messaging really helps fscilitate those international communications. It's also adviseable to have your international team travel to the US to bolster teamwork and foster face to face relationships.

During implementation, if you can afford to have local team members be onsite in Europe, I'd highly recommend it. It demonstrates a physical committment to remote sucessful imlementations and adds strength to the voices of your international business partners in addressing and resolving issues quickly.

Here's an example of how your ERP project will add additional workload (and stress) to a typical employee.

For the sake of this example, your employee is a Purchasing clerk who will eventually need to use the new ERP system to do their job.

You employee could be involved in:

1. One of more meetings to perform Requirements Gathering and Gap identification. (if required purchasing functionality isn't provided by the core system)

2. Data cleansing operations (like a review of all the site vendors to determine thresholds for which vendors to keep and which to discard or elimination of duplicates or the addition of required data (like Tax ID numbers or minority owned businesses) if missing.

3. Meetings or verification of purchasing classifications (so that purchases can be analyzed)

4. May have to provide existing Purchasing reports to project team.

5. May have to help identify site resources involved in the purchasing process (like; Who does requisitioning? Who does the purchasing? What Purchasing approvals/limits are currently in place? How are these approvals monitored?

6. Site issuance of new Procurement Cards, if appropriate.

7. Design review - attend a meeting where the project team will demonstrate the (new) purchasing high level process flow and demonstrate basic system functionality.

8. 1 or more days of system transaction training.

9. 1 or more days of system transaction practice, prior to go live.

10. 1 or more days of practice report generation and analysis.

11. Potentially some site specific testing to make sure that POs (if printed, faxed, emailed) work locally.

12. Possibly assume local training duties (if Train the Trainer approach is used).

All of this and keep doing their "real" job!

These types of activities need to be considered when determining the DICE score (the extra employee workload component) for your project.