Feeds

How not to screw up an ERP implementation

Is there a magic formula?

  • alert
  • submit to reddit

High performance access to file storage

Workshop OK, so perhaps we were a bit ambitious with the title of this article. With so many variables and dependencies involved in an ERP implementation, it would be somewhat naive to claim there is a sure-fire formula for success. Nevertheless, feedback from Register readers in our current workshop and the general experience of those in Freeform Dynamics that have witnessed many ERP projects over the years suggest the existence of some things you can do that will stack the odds in your favour.

First, let's deal with the basics. As previously discussed, it's obviously necessary to define your requirements appropriately and select a package that fits. Indeed, one of the most prominent recommendations coming back from Reg readers is to minimise the amount of development work associated with customisations and extensions. You can only do this if you start out with a reasonable match between the software and your requirements. And of course when modifications to standard functionality are necessary it helps if the software you have chosen is based on an open platform that is easy to work with from a development and integration perspective.

Beyond the software and its fit with requirements, we have also looked at the importance of enlisting an appropriately skilled and experienced implementation partner to help with the project, and the dangers that arise if inadequate attention is paid to selecting a good match. Mistakes in this area can be costly, as can engaging consulting firms on unfavourable or inappropriate commercial terms.

So, it's easy then. All you need to do is define your requirements properly, select the right software, engage the right implementation partner, and you are home and dry – right? If only it were that easy.

Some of the guys in Freeform Dynamics have had the dubious honour of having to referee between parties when ERP implementation projects have gone off the rails or, worse still, figure out how best to clean up the mess when a project has seriously crashed and burned. When you have been through this enough times, you realise that in many (arguably most) cases, the behaviour of the customer is at least as responsible for the issues as software problems or consulting firm shortcomings.

At the most fundamental level, it's amazing how many organisations try to pass responsibility for success to an external party such as the consulting firm. The mentality is that they are paying the firm a significant sum of money to provide skills and expertise, so it's down to them to make the software work according to the requirements that have been written down. While troubleshooting failed projects, this is one of the first things to look for – organisations that have 'been implemented', ie had the implementation 'done to them'.

When you dig deeper, you typically find that the customer has relied too much on the implementation partner to make key decisions, rather than accepting that it's their business, not the consulting firm's. While the latter will be walking away at the end of the project, the customer will be living with the results of those decisions for a long time to come.

A similar problem arises when the customer doesn't acknowledge the criticality of making key people from the business available to provide input, guidance and deal with decision making on the project. And even if they are aware of what they should be doing, they fail to make the necessary arrangements with regard to cover so the relevant people can be freed up to contribute to the project when required.

Either way, the result is the same – decisions with far-reaching impact that you should be making yourself are delegated to an external party, and when a proportion of these are deemed to have created an undesirable outcome down the line, conflict arises, and additional cost, delay and risk is created.

We won't go into the details of what happens when the IT department is forced into the driving role, but suffice it to say that this is generally an unhealthy situation too.

The golden rule for business executives funding an ERP implementation is to accept that the project is theirs. It doesn't belong to a consulting firm or the IT department - it belongs to the business, and therefore needs to be run as a business project. In practice, this translates into accepting responsibility for success or failure internally. After all, you can write as many penalty clauses into a consulting contract as you like, but if the whole thing screws up and your organisation has been crippled, you still have a broken business.

In practical terms, this responsibility is enacted through measures that prevent the kind of issues we have highlighted above. Make sure that there is buy-in across the business to what is going on, and that corresponding commitments are made to release key people from their day jobs to work in the project. Then ensure you have a good strong business-oriented project manager overseeing the whole process from the organisation's perspective. This will preferably be a person on the payroll, but if you have to bring someone in from the outside, do it independently of the primary implementation partner (who will undoubtedly allocate their own project manager) and make sure they report into the organisation's senior management (not the consulting firm), with the right level of mandate and support to make things happen. And bang heads together when they don't.

So what do you think? Do you agree with the risks and recommendations we have discussed? Or do you have a different view? Either way, let us have your feedback in the comment area below. ®

Top three mobile application threats

More from The Register

next story
Dropbox defends fantastically badly timed Condoleezza Rice appointment
'Nothing is going to change with Dr. Rice's appointment,' file sharer promises
Audio fans, prepare yourself for the Second Coming ... of Blu-ray
High Fidelity Pure Audio – is this what your ears have been waiting for?
Record labels sue Pandora over vintage song royalties
Companies want payout on recordings made before 1972
Ex–Apple CEO John Sculley: Ousting Steve Jobs 'was a mistake'
Twenty-nine years later, post-Pepsi exec has flat-forehead moment
Zucker punched: Google gobbles Facebook-wooed Titan Aerospace
Up, up and away in my beautiful balloon flying broadband-bot
Apple DOMINATES the Valley, rakes in more profit than Google, HP, Intel, Cisco COMBINED
Cook & Co. also pay more taxes than those four worthies PLUS eBay and Oracle
Number crunching suggests Yahoo! US is worth less than nothing
China and Japan holdings worth more than entire company
prev story

Whitepapers

SANS - Survey on application security programs
In this whitepaper learn about the state of application security programs and practices of 488 surveyed respondents, and discover how mature and effective these programs are.
Combat fraud and increase customer satisfaction
Based on their experience using HP ArcSight Enterprise Security Manager for IT security operations, Finansbank moved to HP ArcSight ESM for fraud management.
The benefits of software based PBX
Why you should break free from your proprietary PBX and how to leverage your existing server hardware.
Top three mobile application threats
Learn about three of the top mobile application security threats facing businesses today and recommendations on how to mitigate the risk.
3 Big data security analytics techniques
Applying these Big Data security analytics techniques can help you make your business safer by detecting attacks early, before significant damage is done.