ERP advice
that looks plausible
Abstract
So, you read the earlier Avancier papers on application portfolio management, and still want to implement an ERP package?
This paper is a
reprint of advice I have stumbled across and found plausible.
Lessons
learned by James Gaskin
Get Your Executive Ducks in a Row Early
Constantly Search for Bad News
Data Conversion Is Neither Easy Nor Quick
Using
templates rather than Configuration or Customization
James Gaskin writes books, articles, and jokes about technology, and consults for those who don't read his books and articles.
Email him at james@gaskin.com.
Before your start an ERP (Enterprise Resource Planning) project, take a look at these three lessons learned by those who fought ERP battles before you.
With the Obamacare disaster on everyone's mind, you want to have as clean an implementation as possible.
Since ERP touches every part of a company, every executive must be on board.
And not just on board as in, "Fine, I'll go along with the project," but fine as in, "I will do everything possible to make this work."
The top levels, of course, are the most important to get the ball rolling, since the CEO, CFO, and CIO must approve the purchase.
Make sure they understand they can't just sign and disappear but must champion the project the entire time.
Lower-level managers don't have authority to start an ERP project, but they can go a long way toward killing it if they really balk and fight.
The only way to get middle managers to play nice is to have upper level management watching them during each project phase.
Another part of CXO engagement in the project is their tolerance for bad news.
If your company executives have reputations of overreacting to bad news, your ERP project will roll along smoothly for 90 percent of your estimated timeframe, then crash and burn in spectacular fashion.
Why? Because little things going wrong will be hidden from upper management, not get fixed properly, and finally derail the project.
Avoid this by making sure bad news gets pushed up the ladder before good news.
Repackage the "bad news" into "issues to solve before going forward" so they don't sound like bad news that should be hidden by lower level managers and project teams.
When laying a railroad, it's much easier to adjust a few inches early on than a mile at the end.
Think of your ERP project the same way.
Let constant minor course adjustments keep your project moving in the rights direction.
Many ERP projects derail when they start converting data from the old to new system.
Sure, 95 percent of the data conversion can be handled by automated scripts.
That last five percent, however, can take forever to transfer, and it will (of course) include many of your most critical data files.
Clean your old data fanatically before attempting the conversion.
Make sure you have twice as much disk space as you think you will need to handle issues during the conversion.
Make sure you backup all your old data, no matter how safe the conversion process managers claim it will be.
Then backup again, and take another look at the last data-cleaning pass and see if it can be improved.
Learn the hard lessons provided by those going before you down the ERP path, and you may soon reach the finish line somewhere close to your original time and expense estimates.
You surely didn’t buy your ERP with the idea you would turn it into an expensive development environment.
So what to do if it doesn’t do what you want? Or does it in a clunky generalised kind of way?
Toolbox for IT / Topics / ERP / Blogs / Jul 29 / By Rick Cook
ERP systems have to be flexible to meet the needs of companies installing them.
It is a truism that no two companies are run exactly alike and hence their ERP systems aren't going to be alike either.
Which is fine, but is your proposed ERP system flexible enough?
Can it handle everything you want it to do in the way you want to do it?
That's a tall order and sometimes the answer is “no”.
That leaves a basic choice between configuring the system as closely as you can to what you need, or jumping in an writing custom code to try to make things work exactly the way you want it.
Configuration is the equivalent of throwing switches and picking values from pre-set lists.
It is the basic method of installing a system. It is well-defined, but limited in what it will let you do.
Customization involves writing code to integrate with the ERP system.
You can do just about anything – given enough time, money and development talent.
However implementations with a lot of custom code have a well-founded reputation for going over budget, being late and not delivering all the functionality promised.
[And then, you’ll find it difficult to accept upgrades from the vendor.)
Templates - a middle ground.
Templates are pre-written files that perform various jobs in implementing an ERP system.
They are a fast way to accomplish tasks from RFPs to invoicing.
Because the work has been done for you and (ideally) checked, they are plug in modules offering many of the benefits of customization without the development time or risk.
Templates offer a lot more choice for implementation than configuration usually does.
Not everything, mind you, but a lot more.
Understand too, the chances you will be able to completely implement an ERP system without at least some custom code are slight.
However the less code you have to write, the smoother your implementation is likely to be.
Templates for various ERP systems are available from a number of sources at a variety of prices.
Like spreadsheet template, some of them are available free.
Others cost anything from a few dollars to thousands of dollars depending on the source and complexity of the template.
Almost all of the major ERP systems have libraries of templates available, sometimes from the ERP vendor and sometimes independently.
On a popular system like SAP, or SugarCRM, you are likely to find templates that will do almost every job in setting up an ERP system.
In most cases there is no guarantee that the templates will play well with each other, but they should all work with the ERP system they were designed for.
The quality of ERP templates varies, depending on the quality control practiced by the developer.
Some of them are quick-and-dirty kluges thrown together for a specific project and released as a product as an afterthought.
Others are carefully developed to the highest standard of software.
Also be aware that some of these things are not simple to install.
You'll probably need help from your consulting team to get at least some of them set up right.
Keep in mind, too, that the ERP vendor isn't likely to be much help if there is a problem with a third-party template.
Most vendors will provide assistance with templates they supplied, but even that is likely not to be at the level of support for their product.
In general you should thoroughly check out a template before using it.
Pay special attention to the limits of the template.
For example some of them are limited in how many users they will support simultaneously.
Others may significantly slow down your system.
If you are purchasing the template you should get a trial period to find out if it will work for you.
Templates aren't an ideal solution to the customization vs configuration dilemma, but they do give you a third option that is worth looking into.