ERP Project Failures

December 16th, 2015 by Leave a reply »

Reports have appeared of two more high profile SAP project failures, one at Deutsche Post DHL, the other at Dow Chemical.

Deutsche Post DHL Group is struggling with a software upgrade in its DHL Global Forwarding division. The upgrade gone wrong has already led to a write-off of €345 million. Dubbed the New Forwarding Environment (NFE), the upgraded software for DHL’s Global Forwarding division was to enable a variety of new capabilities, including better shipment visibility through improved capture, management and display of operational milestones, and a reduction of paperwork through greater use of a document management system. It was originally used by SAP as a global reference for SAP TM 9.0 when it was released in February 2015, so this failure is particularly embarrassing for SAP.

Dow Chemical Co. spent eight years and $1 billion implementing a new enterprise resource planning system that didn’t deliver value as quickly as hoped and said that another eight year project was ‘unimaginable’.

It is easy to point fingers. There will no doubt be many lessons to learn about the challenges of large scale project management, scope creep, budget, training, partner selection and channel capacity, etc. Another factor that is often overlooked is what can reasonably be expected to work in the real world. Long projects risk more staff changes, more consultant changes, more business changes, more technology changes and the urgency of day to day issues tend to take higher priority.

We don’t live in a perfect world, its easy to dream up automatic processes, detailed field by field segmentation of duties, directed workflows for every step of every process, with hundreds of reports, kpis , dashboards etc
The result is often over engineered and over complex solutions. It takes a long time to build, even longer to test, and by then the user has changed, or the business requirement has changed, a new code version, new database version, new operating system are released, the government changes taxes, etc, etc.

Users resent being micro managed, the project adds more work to their daily load etc.

Does a global solution provide efficiency and standardization, ease of support, and global rollout or or does it stifle local autonomy and agility, and result in inflexible systems that need external workarounds to meet local requirements?

Rethink the rfp – ‘what can I live without for now? “rather than ‘what else can I conceivably demand?’.

be realistic about the team size and effort needed internally – its at least as big as the consulting effort. Who really has the experience to make the policy decisions? – how much time can they sped away from day to day business tasks?.

One of our most successful clients has grown from 100 to 2500 +staff in the last 5 years. What is important is done excellently, but they don’t automate for the sake of it, they understand that complex data structures, and processes and workflows and security provide ongoing maintenance challenges, they don’t reinvent the wheel, They also take ownership of their system.

The difference between success and failure is not always that great. When you firs town a car, ease of use, reliability, proper driving instruction are more important then whether its BMW or a Mercedes. Before worrying about the stereo, and the colour work decide whether it is right for your needs or do you need something else like a Van or a HGV.

Consider why management want the system then consider why the users will use this system – are the reasons aligned?

Advertisement

Comments are closed.