Introduction

When we are talking with customers they are oftentimes fascinated by ERP

failures.

They want to hear about the lessons from ERP failures.

We do not spend enough time finding out how can we avoid failure?

What are the things that we could do to mitigate risk in our ERP

implementations?

I am going to discuss in this article about the things that are critical to ensure

Digital Transformation initiatives

and how to avoid the ERP failure?

My name is P. K. Saxena.

I am the CTO of Sofcon Systems India Pvt. Ltd.

Sofcon Systems India is having 27+ years of experience in the field of

Automation Solutions.

And now it has started helping their clients in their migration path to Industry 4.0.

Guide of my ride is Eric Kimberling, who is CEO of Third Stage consulting

company,

an independent consulting firm

that helps clients throughout the world with their Digital Transformation

in ERP journeys.

Mitigating ERP Implementation Risk

Eric recently posted a top 10 videos of the top ERP failures of all time much like a

train wreck people just love hearing about failure.

Eric could put up a top 10 successes of all time and he tried doing something like

that in the past but no one seems to really care about the successes, they wanted

to hear about the failures.

What went wrong they wanted to hear about the details and so what I am going

to discuss about is kind of a hybrid approach.

I want to focus on your success but I also want to discuss about what are the

things that cause companies to fail.

What are the things you can do differently to avoid becoming one of the

casualties on Eric’s top ten in ERP failures list of all-time before I dive into the

Quality Assurance tool?

I wanted to share with you this Quality Assurance tool.

It is an online tool for implementation of risk assessment and it is free.

I have included a link below and I encourage you to take this assessment to see

where your project stands in terms of overall risk and what some of the

remediation recommendations it might have for you.

It is a free tool that will allow you to assess the risks of your Digital

Transformation.

Why do ERP Implementations Fail?

One thing Eric has learned in his experience as project recovery and expert

witness or in general implementation consultant is that ERP failures are not a

coincidence.

They do not just happen to organizations.

The reasons why organizations fail are not random.

There are not a bunch of different reasons why projects fail.

It is usually for the same set of reasons or at least a very similar pattern of

reasons that cause projects to fail.

I will provide answers of following 2 questions in this article.

Q1– What are the big takeaways from ERP failures?

Q2-What expert witness work Eric’s firm did for project recovery?  

I will also dwell upon 5 things to avoid risk of ERP failures in this article.

Projects that fail do not adequately manage risk.

The biggest thing that companies do wrong in their implementation, when they

fail, is that they do not adequately manage risk.

They do not identify the risk.

And they do not foresee the risk.

They do not expect those risks to happen.

As well as they do not anticipate those risks are there.

They do not realize that those risks are going to be damaging and cause

disruption to the organization.

That is the reason why most projects fail because they do not identify risk.

So this is the number one underlying theme that Eric has seen with the ERP

failures.

Before I get to the list of the 5 things which Eric suggested to avoid ERP failure,

let us try to elaborate another important thing.

What does ERP failure mean?

What exactly is ERP failure?

And what is the ERP failure mean to us?

What would ERP failure mean to you?

For lot of organizations, it means that we do not want to disrupt the organization.

If we have a situation where we cannot ship product or we cannot close the books that is going to be a failure for us

In other cases, it could be that we run over budget.

We take too long to implement.

The employees are confused.

Operations are chaotic.

Whatever the case may be we need to define what ERP failure is?

And how can we avoid those risks?

Majority of organizations that Eric has surveyed and worked with found that they

went over budget and took too much time to implement their ERP systems.

About 50% of organizations faced trouble with operational /material risk at the

time of go live.

They could not ship product.

They could not close the books etc.

So we need to find what is risk to us?

What is failure to us?

And how can we mitigate those failures will be the topic that I will now dwell

upon.

Stop Focussing on Failure!

The first thing we need to think about as we go through our ERP

implementation is to stop focusing on avoiding failure.

I know that is exactly the opposite of the title of this article

but I will explain what I mean by that.

When we look at sports and organizations having winning teams

we find that they do typically win by having a good offense along with having a

great defense too.

It is pretty rare that we have a situation where a sporting team wins solely by

having a great defence because in that case we might have a less chance to

score.

It is a very similar situation with ERP implementations.

If we are just focused on not failing then we are still going to fail because we are

not focused on the things that are going to make us successful.

Hence the first thing is to stop the mind-set of only focusing on mitigating risk,

only focusing on avoiding failure and only focusing on setting the bar so low

that we are  going to fall well short of what the possibilities of this project are.

Organizational Change Management is the #1 cause of failure.

It is important to add offense to that defensive-mix and I will discuss here about

different ways that we can add offense to the defensive-mix.

The second thing is Organizational Change Management and that is the number

one thing that Eric has seen in the ERP failures.

If I pick one thing that is commonly responsible for ERP failures then it is the

Organizational Change Management that has not been focused on.

So Organizational Change Management is the number one thing we can do to

ensure that our project is successful.

Now within Organizational Change Management there are lot of different things.

There are layers within Organizational Change Management.

We have executive alignment making sure that the executives are aligned on

what the vision for the project is as well as what the goals and objectives of the

project are.

We also have one of those high level strategic Organizational Change

Management types of things.

One such thing is understanding of the change impacts.

What are the change impacts to the organization?

How people are going to adopt to change?

How their jobs are going to change?

And how the roles need to be redefined?

How we are going to train them?

How we are going to communicate to them?

Therefore the change impacts are very important.

It is a core fundamental part of change management.

Change Management Parts

Another part is just executing a comprehensive change management plan.

Too often companies think of change management as just training.

We want a comprehensive Organizational Change Management plan

that is not just training.

It is communications.

It is change impact.

As well as it is stakeholder assessment, stakeholder analysis and alignment.

It is everything that is related to change management.

I have included a link below to video that talks about Organizational Change

Management in more detail.

I encourage you to check that out.

That unpacks the whole concept to change management and a lot more detail

but these are a few of the low-hanging fruits or the higher priority areas within

Organizational Change Management.

So make sure you have a solid change management plan.

Eric has yet to meet an executive who said that they invested too much or even

enough in their Organizational Change Management efforts.

Even for the more successful projects where Eric’s team has been involved with,

there is still an underlying feeling that they could have done more to make the

project more successful from a change management perspective.

Chances are very high that change management is going to be a lot harder than

you think and whatever amount of effort you are thinking for your change

management initiative, it is probably not enough.

Keep thinking about how we can do more to focus on this number one critical

success factor for avoiding ERP failure?

Technically- driven projects fail.

The third thing that Eric has found with ERP failures and I am going to translate that into what you should be doing the thing is that they are technology-driven initiatives.

We are going in with the technology first mentality for example S4 HANA or Oracle ERP cloud that is our platform of choice.

As well as we are going to lead with that technology and let that drive what our transformation means to us.

The most effective organizations and the most successful ones are the ones that lead with technology as their business driven initiative.

On the flip side when we look at failures we find a much higher rate of technology driven initiatives than we do business driven.

In fact Eric could not recall a recent failure that he had helped recover or that he had testified as an expert witness on where the organization took a technology-driven perspective and somehow did not fail.

Business Driven Approach

Hence it is something that we need to keep in mind is that this business driven approach is extremely important to let our operations and our organization to succeed.

What we want to be when we grow up that should drive and dictate what our technology initiative is to us.

It is going to make things a lot more clear to the organization.

And it is going to create a lot less headache later on.

It is also important to note that this type of approach requires more preparation upfront.

In theory or on paper it may seem like we are slowing down by spending more time getting alignment on what we want this project to be.

What we want our organization and our operations to look like going forward so that we can define the blueprint for the transformation but that will save a lot of time later on.

That far exceeds the amount of time we had to spend doing that upfront.

Not only that, it will save even more money because now we can dictate the tempo of when we bring in outside consultants and system integrator so that we do not have a big army of consultants charging by the hour while we are trying to figure out what we want to be when we grow up.

We have already defined that work upfront prior to starting the technical implementation so the business driven aspect is critical to avoiding ERP failure.

Leverage and Implementation of quality assurance framework.

Number four on the list is to have a QA or Quality Assurance framework.

The most difficult implementations the ones that fail are ones that did not have a good Quality Assurance framework.

They were not good at mitigating risks or even identifying risks.

It was a system integrator who had an incentive not to identify the risk because it was pointing the finger at themselves in many cases so they hid those risks or did not convey those risks to the client.

Having an independent and agnostic view of where the risks are and how we can ensure quality throughout the entire implementation is critical.

When we talk about QA framework I want to give you an example.

I have included a screen shot of it here that talks a bit about what I mean by quality assurance.

I have taken it from Eric’s video available on YouTube (https://www.youtube.com/watch?v=EdoGWMLSCN8 ).

What are the things that we should be looking at or that a typical quality assurance framework should be considering are given in this screenshot.

We see a number of things here that range from the procurement, process etc. till benefits.

Procurement & Project

The first box we see is about procurement.

Are we complying with our contracts?

Do we have the right software?

Are we negotiating the right rates for software licenses and related services?

So the compliance with procurement is very important.

The next two boxes we see are about project planning, Project governance & controls.

Do we have a solid project plan and a risk mitigation plan even before we start the technical implementation?

Have we identified those risks?

No matter who we are and where we are in our process right now, there are risks underlying our implementation even if we have not started yet.

We need to identify what those risks are and be aware of them so that we can help mitigate them.

And we have got the right project plan in place.

We have got the right controls and the right decision making process.

How our executive steering committee member is going to be involved in the process?

What decisions do we expect of them?

We need to have the stuff all defined so that we operate like a well-oiled machine during the implementation and our project team can be the most effective and efficient that it can be.

We also look at project resource.

Do we have the best resources and adequate resources internally and externally from our system integrator?

Just as importantly do we have non system integrator types of resources?

Perhaps there is independent solo consultants or independent consulting firms like Third Stage that can help augment what the system integrator does.

External Resource

The other thing that we are seeing more and more of is not relying on any one party for providing external resources but potentially relying on multiple system integrators or multiple parties for those resources.

The other part of the project resource component is making sure that we do not have too many resources on the project particularly when we are relying on those outside resources.

What we see often is that companies get lured into having too many people on the project when you could manage with a lot less.

When we have many people on project then the meter runs at a higher rate.

The consulting companies are making more money.

We are spending more money.

So we need to rationalize & validate who is on the project and when.

We need to make sure we are not over investing in the name of these outside consulting firms.

Process

Further the next thing we need to be thinking about is process alignment.

We have defined our future state processes and the technology is aligned with those processes however we are changing our processes to fit the software in certain cases.

We have changed those processes simply because we have designed the software to meet a certain process or workflow.

It does not mean that it is reality.

So we need to make sure we actually implement those process changes and those organizational changes that go along with it.

The other part of that process component is the requirements & traceability.

We have to make sure that all those requirements we defined early in the evaluation and in the planning process that we said we wanted to get out of this transformation, we go back to that and confirm and validate that the vendors, the system integrators and the consultants are all delivering on what we expected to get out of the transformation.

Configuration

Another component is configuration and development.

Have we configured and developed the software in a way that makes sense for the organization and that meets the needs of our business processes?

Next component is architecture.

Similarly with architecture, chances are we are not relying only on one ERP system and that is it.

Chances are that ERP system or systems are needed for integration with other third party systems.

Whether it be third party or legacy systems that you are choosing to remain intact or in some cases for example if you are in the pharmaceutical industry you may have some regulatory systems that have to be in place like a limb system or whatever the case may be so make sure that you have a clear architecture and a clear integration plan for the entire solution and it is really important.

However it goes outside the realm of your system integrator or consultants that are focused only on one technology.

Change Management

The other component is change management.

It itself is a big subject and I have to write another article on just about change management.

We have to make sure that we have a solid change management plan and we identify those pockets of resistance within the organization early on so that we can mitigate them and get ahead of them before they become real problems.

However Change management component is something we have to really focus on ensuring that we mitigate it throughout the implementation.

There is also Master Data Management component.

This component is something that is often an afterthought.

Something that we do right at the end of the project or we do right before our final test.

That is a big disaster waiting to happen if you are planning to do that.

You want to bring forward the data activities as much as you can because that is probably on your critical path and is probably going to determine how long this transformation is going to take.

In fact if I pick two things that are going to delay your project it is either going to be Master Data Management or even more likely Organizational Change Management.

Those two things are the most likely to delay your project and increase your cost so the sooner we can start those two things and do those two things really well the better off we are going to be testing.

Testing

Moreover we are not just talking about technology testing and software testing but also talking about user acceptance testing.

Working through different scenarios, working through your business processes and ensuring that the frontline people within your organization have signed off on how the technology works.

It not only helps us make sure we have a solid solution which we are rolling out to the organization.

But it also helps from a change management perspective.

Because now we have started to train and educate people and get them involved in the process  and help them in understanding how this whole thing is going to look once we go live so that testing process is extremely important particularly as it relates to user acceptance testing.

As per general rule of thumb, you should have at least three rounds of user acceptance testing.

Many times project team will try to get over by one or two user acceptance testing but you definitely need at least three.

Security

The next component is security.

This is another afterthought.

In many cases where we have delivered a solution however we have not set up security profiles till the day we go live, people are supposed to get locked out of certain functions and things they need to do because we have not set up the their security profiles right.

So when we are defining our business processes in the future state we should also be defining what our security roles look like.

This is also an opportunity for us to make sure that we are compliant to Government security rules defined for our company.

Security profiles are a big part of our software.

We have to ensure that we have locked down the processes and the functions that need not happen with certain individuals.

Security profile should be such that when we want to get out of the system then only we are allowed to get out of the system.

Reports & Analytics

The next component is reporting and analytics.

We have to ensure that we have access to real-time information.

It is important that it should be part of our testing process.

It should also be part of our requirements.

We should clearly define what those reporting and analytics need to be.

And then finally there is benefits, realization and performance component.

We have to ensure that we actually get the benefits which we expected out of the system.

This is probably the most important part of offense strategy that I discussed earlier in this article.

A lot of this is part of defense because we are looking for flaws and defects but the solutions we go after are meant to be offensive.

Once we have identified a risk that we have not pursued or a risk that we have not addressed which gives us an offensive strategy to get ahead of it and start to remediate and start to improve when we get to benefits realization.

This is an area where we are focusing on how can we get more value out of this implementation and not just set the bar down here which is let us not fail but let us also make sure that we get as much as we can out of this investment because we are going to spend a lot of time and money on this implementation.

Hopefully it is the last time we do it for the next 15-20 years.

Let us get it right through benefits realization.

QA framework that I just went over is the fourth thing that you can do to ensure to avoid failure and through that you are setting up yourself for success.

You are in charge of your Transformation!

Now the last thing, the fifth thing that you can do to avoid failure and this is a really important but simple one is remember that you are in charge of this project.

For those of you who do not know what I mean or you may be shrugging or uncertain why I am saying this too often so here is the clarification.

We defer our project or try to outsource our project to other parties.

We defer our project to our system integrator who has sold us a vision for what this project should look like and we let them handle this as experts.

And we let them make decisions what our operations are going to look like.

We lean on them for best practices which do not exist by the way but we lean on them by best practices to tell us how to run our business.

That is a recipe for a disaster waiting to happen.

We need to take ownership of the project and recognize that if this project fails, it is not your system integrator’s fault.

It is not your third party consultant’s fault.

And it is not your vendor’s fault.

It is your fault.

And so on the flip side of that, if we succeed it is not going to be because your system integrator is awesome.

Your independent consultant was awesome.

The vendor was awesome.

It is going to be because you managed the project well.

And you did so in a way that you not only avoided failure but you did ensure success.

So recognize that you are in charge and take everything with a grain of salt.

Take away

You are going to get a lot of advice with a lot of marketing spin.

A lot of overly optimistic views of what these projects would look like but really take a hard look at you as an organization.

What makes the most sense for you as an organization?

Set aside the best practices in the Kool-Aid and all the marketing spin that you are going to get.

And really look and reflect on what is it we want as an organization and how is it we are going to make this project more successful.

So “you are in charge” and this might be the biggest takeaway that I would have from these top 5 things.

I hope you found this information useful.

Avoiding failure is really important.

It is very doable.

If you do these 5 things which I have mentioned here in this article you are going to set yourself on a path to greater likelihood of success.

I encourage you to download some of the content I have included in links below.

I would love to get feedback from you which you have seen working or which you are experiencing now through your Digital Transformations journey.

Also I look forward to have communication from you.

By Digital Prabhat

Resources:

Eric Kimberling-How to Avoid ERP failure       

 Third Stage Consulting Group

 https:// www.thirdstage-consulting.com

 Top 10 ERP Failures of All Time:

ERP Implementation Risk Assessment Tool: