What are companies doing wrong when implementing ERP systems?

I suggest three things to consider when implementing ERP:

1. As Steve says, don't write custom code. There is no doubt that modify the packaged ERP system with custom code leads to a variety of ills. Aside from introducing complexity and cost, upgrading a customized system is also expensive and difficult. When you upgrade, all those customizations need to be migrated to the new system.

2. Plan for change. ERP is all about business transformation and doing things better. Lack of change management and training is a key reason many projects run into trouble. Since training occurs toward the end of a project, many organizations assume it won't be a problem, or will simply take care of itself. Big mistake.

3. At the start of your project, don't assume things everything will be great. The fact is, most implementations have difficulties somewhere along the way. Be realistic and assume you will hit trouble spots along the way. Budget in extra time and money and look closely for trouble as you go forward. Seek out early warning signs of difficulty.

ERP can be great, but since your business is complex, the implementation project will also be complicated. That's fine if you know it going in and make suitable and realistic plans.

Very good advice from both Steve and Michael. A while ago i wrote a blog post called "13 Things a Customer Can Do to Avoid an ERP Implementation Failure" - there are also some interesting comments from the readers http://blog.technologyevaluation.com/blog/2009/06/09/13-things-a-customer-can...

But frankly, i don't think the high rate of failure applies to ERP only - maybe people talk more about ERP failures because the value of these contracts can be very high, but i think that the main reason why IT projects fail is the disconnection between the IT department, the financial decision maker and other executives.

In my experience, I have found that many organizations do not have a solid understanding of where value is created and enhanced in their organization. The benefits of a properly implemented ERP system should enhance those processes where value is created or enhanced, while maximizing efficiency and minimizing costs with those process that are not in the value chain. It's hard to assess a perceived value gap if you do not understand where value is created, enhanced, diluted, or in some cases damaged.
ERP is a technology enabler for people and processes. It's a three legged stool with people, process, and technology. Unfortunately, people and process will trump technology every time if the appropriate steps are not taken to assess proper technology "fit", and investments are not made in process re-engineering and user training very early in the process.

Mike,
There are several points that need to be addressed in your question. The first point is the cost/time overruns. I would venture that the source of the majority (not all but a significant portion) of the overruns are actually dictated by the company during the sales process. A company will ask for quotes from each vendor, will then respond that the cost id too high, so the supplier will "reconfigure" their quote (and attach caveats to the deliverable), and then a significant portion of the decision as to which vendor to partner with will be made on "low price". You are building in false expectations from the start, so don't be surprised if you follow this process and have overruns. The second point has to do with not achieving all the benefits. When a company generates their ROI document they start the list with their "low hanging fruit". That is the pain areas that is driving them to look for a new ERP solution. After this then then start to add other items of potential payback (less urgent items) to enhance the ROI & shorten the payback period in the presentation to the decision maker(s). Then comes the implementation and the 80/20 rule. The main areas are addressed with 20% of the work, the large pain points that drove the project are resolved and the project implementation team feels successful. The remaining items in the ROI calculation are numerous small issues (no single item being "critical" to the business) the total of which requires the balance of the effort (the remaining 80%). Without an internal champion to clean up the "little issues" this work may never be done. If it is addressed it is often after the "implementation" in follow on "optimization" projects. So the answer is: set realistic goals, establish budgets & plans that reflect reality, hold people accountable for the areas of improvement that they bring forward, continue to monitor/support/fund the ERP project after the initial "go live", and remember that the software nor the implementation partner can deliver the results - you have to take the ownership of the project & deliver the results. The software and the implementation partner are only "tools" to support your efforts.

Hope this helps.
Bill

I do not believe that there is a simple answer to that question, because each project is individual. However, in my experience some problems seem to reoccur:

1. The management team is not fully supportive.
2. The project or programme is not seen as a business change. Instead it is treated as an IT activity with resulting misaligned objectives.
3. Budgets are notoriously optimistic.
4. If outsourcing the implementation to a service provider, the client often neglects acting as a professional buyer.
5. The scope of the project is not clearly defined.
6. The project is not split into achieveable phases, which would allow quick "victories" along the journey.

I work essentially with SMBs and my observation is very much in line with the report’s findings.

No need to repeat what’s in the first reply, Steve’s fist sentence says it all.

When and ERP is implemented, it costs a lot and hurts a lot in the first phase. It continues and will continue to cost and hurt albeit less with time. This is not because the system has started to produce its originally intended benefits but because users have found ways and workarounds to do their work with less pain and nonsense. They subsequently continue to spend time and effort devising ways to bridge the gap between the system and the company’s evolving business processes by using multiple spreadsheets, databases, 3rd party addons, electronic files, etc…. They do it because they need to and the system is not following. This process goes unnoticed because it takes place slowly, everyday and bit by bit. SAP’s payroll is no longer adequate? No problem, new spreadsheets are built and maintained by the payroll person or a 3rd party addon is purchased. The sales process has changed or gotten more complex and MS Dynamics or Sage is too complicated or heavy to reconfigure? No problem, another series of spreadsheets is created by the sales department. Revisit the company two years later and you are guaranteed to find an ERP that’s patched up and stitched from nearly every side.

But in the end who cares? The system provider made their money, the system reseller and consultants made their money, the company got bruised and left limping for years to come,… and life goes on.

For last aprox 10 years, I have done quite a few (over 30) ERP projects. I often reflected on this subject, #1 cause of shortcomings, and developed the (personal) term "project spirit". There are projects with "good spirit" people are happy to work together, problems are good=just opportunities to learn new exciting things, people hear each other with respect and consideration, trying to understand and help the other project member, people do their job and some extra also just to make sure they connect with the team, people do not try to show off and impress others with irelevant things, people are pro enough to be relaxed when their knowledge limit is reached and it's time to learn, people are not obsessed with current organisational power and policy positioning, etc.
As for the project "bad spirit", well, think you got the idea...
Regards,
Eugen