Why is there still so much discontent with ERP projects?

What I said on linkedin;

"There could be any reason including the above comments but the main issue is that how it's been measured up!!!
Plus, an ERP is not just to implement but to grow up together."

and Rachel asked me to collobrate here :)

As we've been implementing ERPs since 1994, I would say that there had been problems of several causes and the outcome was that no one expected.

BUT, that is an old story, at least should be! Why is that? Most of the companies were not considering the ERP as a tool but a target. Nowadays, the projects that we kick off have clear targets based on KPIs and more acceptable project charters.

So, we know where we go, how we go, why we go, when we go and most of all with whom we go.

What's the reality behind the implementation of ERP? Fitting in it or Customizing it?

Fitting in; Is it the correct tool to comply with our procedures of doing business?

Customizing it; Do we have the correct procedures? Well defined? to implement in it?

Each of it based on humanbeing!

Pretty enough ha, cause the ERPs are considered to make the business life independent of humanbeing so that people come and go.

But times change by, and that drives change management to be taken care in the procedures and in the tool (ERP) as well.

Well, what if a BPR arises in the content of the project. This is what consultants are not willing into, so do I. AS-IS and TO-BE analysis should be handled in a pre-project.

For eg, I remember that the first implementations were scheduled to any time between 2 to 4 years in the 1990s but now we can implement it just in 3 to 4 months in an airport operations company since we have a clear business map. Then comes the stand-by period, month-en support, first quarter-end for the stock exchange reporting and the year-end issues.

Woow it took another year, plus the expenses. I am not stating out the key-user circulation that it needs extra training. God, there should also be a support service either inhouse or outsourced to overcome the user-errors, and the system errors :)

So, What was the management expected at the beginning and what they've faced?

Shall I answer the question as a Salesman or as a Principal Consultant?

Ugur.

Cathy,
I conclude that the reason for this is the lack of clear mission oriented requirements. That is, the person purchasing the Enterprise Resource Planning (ERP) solution and the vendor offering the solution have different goals and never have clear requirements. The vendor wants to sell software/services and the customer wants a solution. The challenge as I saw in two ERP implementations where I work is that the customer says to the vendor, we need an ERP solution for our company. The customer does not say I need to be able to process 100 purchase orders, complete 200 shipments, and respond to 300 customer calls per week with a staff of 10 call center personnel, 5 shipping/receiving clerks, and 30 sales representative across the country; instead the customer says I need that ERP solution to help me run my business. With this start, the vendor fills in the blanks with as much product/services as the customer’s budget allows and delivers a very good paper response to the some very poor requirements.
I saw this all of the time as a presales person for enterprise management/monitoring software. The customer/prospect says to us, I need a help desk. We show up, demonstrate the help desk, tell information technology infrastructure library (ITIL) stories that reinforce the prospect’s need for a help desk and close the deal. At no point in the discussion did we focus on mission or the true business requirements. The prospect gets the software and the vendor closes the deal – requirements met, new customer signed, and sales team makes their number.
What do you think happens when the services team arrives to deliver services? 30% is a good day!

The statistics are worse than that, many projects never complete or complete so late that much of the ROI is lost. The problems happen at all levels from start to end. Often end users start by asking for what they have now, not knowing what they need, sales people sell ROI's based on changes supported in work flow and culture that is all about the people changing, not just the tools implementation. Many managers preach change but act to keep things status quo, so stake holders may be stake holders to reserve their nay vote, not to make it work. Silo's often lead to one departments gains to be at the expense of another, and the other department does not want to give up the power, or upper managements refusing to adjust budgets and expectations forcing old bad decisions. Mostly it comes down to a tool being able to amplify how good or how bad, leadership, management and work flow currently is. Leaders must set reality and expectations, managers must commit all in and workers must see the benefit and embrace it because it makes sense.

This is what exactly my research paper all about. Most of the times, the expectations set at the customer level is wrong. Engaging the customer and make them participate during the exectuion phase is very important. Before you could kick off your project and pre-award stage, ask the customer "What is the Objective?"

Once you & the team are clear about the objective, you can work towards that with the customer. Most of the times the Midrange ERP fails due to the following reasons;
1) Comparision between the legacy system & your erp
2) High level of expectations set at the time of pre-award
3) Quality of the product
4) Your delivery commitments
5) Customer engagement
6) Support - post implementation

The above are very few. However, the team should know / understand the customer's core business process and the requirements. Without which, most of the ERP's fail.

Many organizations have a fundamental misconception regarding the nature of ERP. It is easy to view ERP deployments as being primarily about installing software, although that perspective is misleading. More appropriately, one should see ERP as involving business process change; often, the term associated with this is "business transformation."

Sure, ERP deployment is intimately connected with installing software but that tends to be easiest and most straightforward part of the equation.

The real difficulty arises because ERP software cuts across different parts of the organization, meaning implementation is a complicated, and deeply collaborative, effort. For ERP to work, folks from different parts of the organization must make detailed decisions about how processes should work. That involves dissecting existing processes and figuring out how to make them more efficient.

This process focus is both ERP's strength and its weakness. It means that an ERP implementation offers great opportunity to improve processes and make the organization more efficient. However, the process orientation also means that implementations can be time-consuming and elaborate. Even in relatively small companies, the effort to automate many departments can be daunting. This complexity is what drives implementations to be difficult or to fail entirely.

A primary driver of success or failure lies with what I call the IT Devil's Triangle: the combination of software vendor, customer, and services provider. However, in the end, the customer must be responsible for the implementation project outcome. High rates of ERP failure therefore suggest that many enterprise customers implement systems that are overly complex for their organization to absorb easily.

Aside from good project management practice, I suggest aligning incentives with the service provider and software vendor. If your implementation succeeds, based on pre-determined criteria, then be prepared to pay an incentive bonus. If it does not, then the vendors should suffer financially. Alignment is the cure for many ills.