Big Risk for small Fry

Contratual tips for new entrants in the ERP game.

BY Wayne D. Bennet

ENTERPRISE RESOURCE PLANNING implementations are once again in the news with stories of both success and dispute. And we can probably expect more of these stories now that Y2K configuration freezes are thawing in the heat of pent-up demand. Two factors make these stories relevant to all CIOs. First, the ERP vendors are headed down-market in search of new opportunities; and, second, the same contract and management principles that help determine the outcome of big ERP projects apply with at least equal force to smaller ones.
    Sure, we see the big guys wielding considerable leverage at the bargaining table and ending up with a decent claim if the implementation fails, but midsize companies have fewer resources to help in case of disaster. A big mistake in a big company is hard to hide and hard to recover from; in a smaller company it's impossible to hide and even harder to recover.
    A complete tutorial on ERP could take a full semester and several guest lecturers to cover properly. But if we start with the typical definition of what we want to avoid (over-budget, late, inadequate function or performance or some combination of these), here are a few matters to consider.


Timing
Having a vendor start work before a contract is signed seems so facially stupid that it is hardly worth mentioning except that it happens all the time. Without a contract you have few intellectual property rights, no appropriate confidentiality provisions and you are paying by the hour. Worst of all, you lose leverage in the contract process and you set yourself up for a mess if no deal can be reached.
    As you are negotiating, everyone thinks you are saving time by starting early, all the while ignoring that as the clock ticks and your ERP deadline looms, you have either wasted all the work to date (because you now have no rights in the software and therefore no leverage, so you cannot come to an acceptable contract) or you will have to eat whatever the vendor puts in front of you at the end of the process. Given the frequency with which the simplicity of this concept is not recognized, it is hardly surprising that Halloween Superman costumes come with the warning, "Do not attempt to fly wearing this costume."


Price and Payment
Price is not the most important factor in the success of an ERP project, but you don't really need a money pit. Seek a fixed price and a well-defined change order process. Don't try to chisel every last nickel off the price. You will do better to get a realistic price up front than to deprive the vendor of an honest profit. Otherwise, expect to be pestered with change orders until the vendor puts some vitality back into its margins.
    Check references to find out how the change order process went for other customers of your vendor. Did the price increase 10 percent or 100 percent? Did every last pixel change cause a change order or did only the big changes cause a repricing?
    As for the actual paying, many vendors are sensitive to the cost of money issue. Holdbacks are great (and should be sought) but if the vendor is a big company, holdbacks have less real effect than desired. Holdbacks can range from 10 percent to 50 percent and are typically limited by the vendor's margins. They are intended to keep the vendor's skin in the game. If payments are made upon key milestone achievements (and achieving a milestone involves accepting the deliverable, not just the delivery!) a fair amount of money can accumulate in the holdback by the end of a large project. But seeking your money back versus not paying the holdback yields the same result when up against a large vendor—it's a lawsuit either way.


Contract Leverage
Having a tight contract that permits you to declare a breach and then terminate it is a swell thing. But in the end, do you want an ERP system or a contract claim? You may need your termination sledgehammer, but using it will hurt you at least as much as your vendor. Most often, you need a contract that invites conformity to terms that are well tailored to success. Your vendor will say that you don't need a contract that causes everyone to keep running back to check its terms. That's only partly right. You want to keep people from only delivering to the letter of the contract, but you also need a contract that would, if read, invite the parties to work together.
    Get actual, specified monetary damages for material failures (materially late, materially nonconforming) and consider an upside or bonus for beating selected metrics that imply success for both sides. Add clear escalation procedures so that disputes of every stripe can be resolved efficiently. Require each side to maintain continuity of personnel and give each side the right (and the right avenue) to suggest to the other side that a key person is standing in the way of success.

Acceptance and Testing
Interim deliverables need to be accepted conditionally, not absolutely. And the condition is that the whole system works in the end. Why accept pretty screens that have no properly functioning software under them? Acceptance and rejection and redelivery processes must be clearly defined in the contract.
    Furthermore, you need the right to test what your vendor does; your vendor needs the right to test what you do; and you both need the right to seek third party help to determine whether objective standards have been met. No one should be the final arbiter of his own work. When considering third parties, be sure they are truly independent—not a vendor that would have preferred to have gotten the job in the first place.

Backlash
At the risk of contravening some of the other principles, take them with a grain of salt. It may be easy for the CIO to declare that the cleanest implementation involves the fewest legacy interfaces and the least customization—everyone must either conform to the out-of-the-box ERP solution or reveal that she is not committed to ERP. But despite the grief of legacy systems, sometimes you will need to bend. In some cases, the in-place business process is not only unique, it lends a competitive advantage or is simply too expensive to change to conform to the new ERP system. Seek advice from others as to this trade-off. It has operational, cost and political consequences.
    Throughout all this, don't forget that ERP cuts across the long-established and hard-earned fiefdoms tucked away in every nook and cranny of your company. Before you even begin, be sure department leaders understand what ERP is and not only what the benefits are but what the sacrifices are: Some current processes must change to simplify the system and to conform it to the rest of the organization.
    There are surely other issues—each success and disaster brings its own lessons. But you can get a good start by thinking about how these ideas apply to your organization.