While machine tools, robots, materials handling systems, whole production lines, and the computer equipment to run those things are typically purchased, the software employed is almost always licensed. A software license is a grant; the software vendor grants you the right to use the software in a specified way.
Regardless of ownership, what's important is that the software works the way you want it to work, just like any other automated system in your manufacturing plant. And just like those high-tech acquisitions, software demands high-tech legal considerations— and negotiating.
International Computer Negotiations, Inc. (ICN; Winter Park, FL) suggests a 10-step process to purchasing high-tech systems. Called "Managed Acquisition Process" (MAP), this process injects a formal methodology into the negotiations involving high-tech purchases. More important, says Marlene Bauer, area director for ICN, MAP throws a monkey wrench into those "sense-of-urgency ploys" that some suppliers use to unsettle your ability to control the purchase negotiations.
Setting Up the Negotiation Basics
Parts of MAP are obvious. For example, the first step is to form a negotiating team. Then decide what you are contracting for—resources or results—and the criteria to base your purchase decision on. Note that resource contracts cover specific products or services that you can describe by quantity, model number, and so on; results contracts cover "solutions." Next, determine what you want in the contract, what ICN calls "negotiating objectives," and prioritize them, such as:
For example, is having a "hard real-time" system more important than having an automated system based on a particular operating system? Is having a graphical user interface more important than a character-based display? Is "money no object" when balanced against a system's potential high throughput?
ICN has identified 82 negotiating objectives, but you'll never get them all, points out Bauer. She also points out that this list "kind of grows over time." Unfortunately, at any given company purchasing high-tech systems, stakeholders and technology gurus come and go. What remains is often a group of people who have to relearn effective, high-tech negotiating. Some vendors, as highly trained professionals, know this, and they try to capitalize on a buyer's weaknesses as much as possible.
Step three in ICN's MAP is to decide how you will work with your chosen supplier. Then you should gain management approval. Getting the authority to negotiate—and approval of what you plan to negotiate for—from upper management is absolutely critical before entering into a high-tech acquisition.
Dealing Better by Visiting
If you want some quick tips at negotiating high-tech projects, visitwww.dobetterdeals.com, the web site for International Computer Negotiations, Inc. (ICN). For starters, read the executive overview entitled "How to Do Better Deals," which details the company's Managed Acquisition Process. You'll also find sample tables of contents for a computer equipment master lease, software development agreement, and software license agreement.
The site's July "Tip of the Month" was entitled "Using the RFP to Maximize Supplier Commitments." There, ICN explained why you'd use an RFP in the negotiations process and two ways to stop suppliers from negotiating "downwards" from what they perceive as an idealized RFP. ICN also included a paragraph written in legalistic fury to help you "maximize supplier commitments through an RFP."
It's a good read at the very least.
Getting Promises in Writing
Writing the actual contract is next. Of course, you could just accept the standard terms and conditions of your suppliers contract. "No! Big no-no." Bauer is pretty emphatic about this point.
The fact is, you can accept or reject, in whole or in part, the supplier's contract through negotiation.
Assuming, of course, that the warranty is negotiable in the first place. Negotiating with Microsoft, for example, regarding its Office 97 software suite is an exercise in futility. The same is mostly true when negotiating with Computer Associates, IBM, and other vendors with muscle. The legal hassle to change these suppliers' terms and conditions is often enough to scare away any customer asking for a change.
(Talking about Computer Associates, keep in mind that if you're covered by a contract to a software supplier acquired by another company, then the new company has to live by the terms of the original agreement at the time of the takeover—unless you specifically renegotiate the contract or a bad—that is voidable—agreement existed with the original supplier. Because you have to live with these contracts, having a good one from the start is important. Unfortunately, you might still get bombarded by the new company with proposals to roll old agreements into a new, master agreement. Caveat emptor.)
Off-the-shelf software and shrink-wrapped licenses, however, are a special case. For the most part, custom-negotiated agreements are the norm for custom software, such as what's used to control automated production lines, or customizable software, such as all enterprise resource planning systems. In these cases, says Bauer, "pretty much all the rules of good negotiating apply. And no matter how small you are, try to get the best deal you can."
Doing that typically requires leverage. This might be difficult for a small buyer to create when negotiating with a large supplier. But it is not impossible. Bauer offers two leverage points to think about: You might be unique enough to be a referenceable account for the supplier, or your site can be a beta site for testing new features and functionality.
The point is, take the upper hand by writing your own contracts with the requirements you want. Among other things, this will save you both time and money, and, says Bauer, "increase your negotiating power." Some automotive OEMs and Tier 1 suppliers do this already. As a rule, they do not accept the standard terms and conditions in their suppliers' contracts. If the supplier doesn't like that, tough; these buyers will just go to another supplier.
More than a Technical Solicitation
Typically, your first interaction with an automation supplier begins with a Request for Proposal (RFP). The RFP translates your company's operational goals into functional requirements that a new system is expected to achieve. RFPs typically specify technical performance requirements. They should also clearly delineate areas of responsibility and detail what you expect from the vendor, including system architectures, labor, and even trash removal. Anything that could be the source of a disagreement should be in the RFP, says Roger Buiton, general manager for Ann Arbor Computer (Ann Arbor, MI), a division of the materials handling supplier Jervis B. Webb.
But don't over specify in your RFP, warns Buiton. "We don't accept a statement that a particular software event has to happen within two seconds. We do accept a statement that says that the overall throughput of the system has to be 60 units per hour." Just state the goals for the new system; let the vendor figure out the details of the system design.
ICN suggests attaching your version of a contract to your RFP, then require your potential suppliers in their RFP responses to acknowledge every term and condition in the contract—or their responses will be considered out of compliance. Suppliers can then either agree to each term or they can disagree and suggest substitutions. This approach, says Bauer, will give you a notion about which suppliers are going to be real sticklers about the contract, and which suppliers might be more amenable to your terms and conditions. "That can be a big factor in evaluating major proposals," comments Bauer.
|The Buyer's Challenge in High-Tech Procurement|
|Trained sales and negotiating staff||Typically an IT professional, untrained and inexperienced in high-tech contracts, and lacking in negotiating skills.|
|Their full-time job||Overly impressed with vendor|
|Salespeople and negotiators have financial incentives to increase $ and lower risk||Too busy to plan, execute, and negotiate a complex acquisition|
|Manipulate the process to get inside information on customer's needs, weaknesses, and "hot buttons"||Once decision to acquire is made, want it now|
|Opposing Objectives in High-Tech Procurement|
|Maximize profits||Minimize costs|
|Allocate risk to customer||Maximize protection (minimize risk)|
|Source: International computer Negotiations, Inc.|
When it comes time to issue the contract itself, attach the RFP as an addendum. The contract is the binding agreement, but the RFP is the list of promised deliverables or services that the supplier must live up to.
After issuing the RFP, hold a suppliers' conference. "Because you have yet to choose a supplier, you are in control," says Bauer. This conference gives you the opportunity to explain your system requirements and to confirm that you and your potential automation supplier have the same expectations. Later, when the warranty gets written, Buiton suggests including all of these expectations in the warranty statement "so you don't have a difference of opinion when a problem occurs."
The next MAP step is to evaluate suppliers based on information from both their responses to the RFP and throughout the MAP steps. Did they respond completely and in a timely fashion? Can they develop the system you want? Are they still being responsive to your needs?
At this point, you'll then enter ICN's "zone of consideration." This is the negotiating time between gathering RFP responses and awarding the contract. This is power-play time. The suppliers want your business and you want certain guarantees. At this point in the negotiations, fundamental issues should be clearly defined in warranting the system you're about to purchase. Negotiation points such as the duration of the warranty, acceptance testing, and when payments begin need to be ironed out.
You will need to review the supplier's terms and conditions for actions that may void the warranty. A typical exclusion is when you have modified the system in an "unauthorized" way. Make sure that any restrictions in your warranty are not for operational problems. You should not be penalized for trying to resuscitate your new automated system that is both still under warranty and dead in its tracks.
You might even want to add an escalating series of responses/compensations in your contract if the software system fails. For example, the first level might require the supplier's support people to respond within a certain amount of time. The second might be that you will call a third-party software consultant. There could be a clause for "liquidated damages," which says the supplier pays you per hour or per day if the entire software system caves in. "That'll really get their attention," comments Bauer, while also admitting that such a clause can be very difficult to get in a contract.
Buiton points out that warranties should mention what they do not include, especially if that is different than the norm. For example, automation suppliers typically warrant the parts of the systems they provide, except parts from third-party suppliers that are covered by their own warranties.
Buyer's responsibilities should also be mentioned. One "big can of worms," says Buiton, involves troubleshooting an installed system. Vendors often assume that you will recognize when something fails and that you will apply a reasonable amount of technical ability to troubleshoot the system. But if the vendor diagnoses a problem and the results point to a customer problem, who pays? This needs to be covered in the contract with your supplier.
Diligence After It's All Installed
Of course, after all the writing is approved and your supplier begins designing, then implementing, your system, you have to manage the contract. You do this, says Bauer, by monitoring key dates (for expirations, renewals, and so on), rights and obligations, your suppliers' rights and obligations, deliverables, payments, and historical data for each of your contracts.
"There's no way you can cross every `t' and dot every `i,'" says Ernest Vahala, president of the Auto Body Consortium (Ann Arbor, MI). Many times, he says, the intimate details of an automated system develop as the systems house, the software supplier,and you tie the automated system together and go forward. The contract must be written with this understanding, and with the understanding that the supplier will have the labor resources available to work with you as problems come up.
Concludes Buiton, "A warranty that's fair to both sides is by far the best warranty to have when a problem occurs. If it is unbalanced in either direction, there will be unhappiness." And there will be problems.