|Best bet for buyers heading into
negotiations with software suppliers: Know the software application
and how it impacts the business process. So says Ditka Reiner, president
of Reiner Associates, San Rafael, Calif., firstname.lastname@example.org
and a speaker at this year's annual conference of Caucus the association
of high-technology acquisition professionals held recently in Washington,
As Reiner sees it, when corporate purchasing managers play a leading
role in developing specifications for software the organization is
buying, they "will be more comfortable in negotiations with suppliers.
This will be to their advantage." Reiner, who works with organizations
to help hone their negotiating skills, believes that purchasing should
work together with IT (information technology) and business unit managers
to develop the organization's requirements for software. To be successful,
"both must have the same objective."
Then, purchasing must begin its work on researching both the product
and potential suppliers, seeking answers to such questions as: Are
there alternative products or is the organization captive? (Many IT
organizations tend to believe that they are captive, says Reiner.)
What do other customers say? How good is the supplier at development?
How is their support during installation? What happens once the installation
is complete? Specifically, purchasing needs to conduct an extensive
check of the supplier's background. "If available, get an audited
copy of last year's financial statement," suggests Reiner. "Have your
financial group review the statement and rate it."
Evaluating the software itself is important to the organization and
there are two ways to do this, which is determined through the negotiation
process. The first is through an evaluation-only license; the second,
a license agreement with a test clause. "Demonstrations mean nothing,"
Reiner told the standing-room-only crowd that gathered for her presentation.
"Purchasing needs to make clear test, acceptance, and rejection criteria"
when negotiating an evaluation-only license. What's more, buyers should
specify supplier support requirements and be realistic about the time
needed to evaluate the software. However, most users prefer to negotiate
a license agreement with a test clause. It is a one-time involvement
that admittedly does take more time. For this method, buyers should
specify "a clear out."
Licensing the software
In licensing the software, Reiner stresses again
that purchasing managers need to understand the business and functionality
of the software being acquired. Purchasing should have a good grasp
on licensing terms. Does the organization need a perpetual license
or will a monthly or yearly license suffice? Purchasing needs to ensure
that the organization is protected in the event of a merger or acquisition.
Perhaps the most important term in the agreement is the word "user."
Termination criteria must be clear as well.
For a critical application, supplier support and service capability
must be spelled out, says Reiner. Also important: precisely defined
requirements for disaster recovery and testing and training.
Ask the supplier for all documentation (user manuals, system guides,
report layouts, etc.) Make sure users conduct a detailed review and
communicate their approval. Hook acceptance and performance to specifications.
It's important for purchasing to work with users and the supplier
to provide deliverables and delivery dates. Align payments to timely
delivery. Reiner suggests 50%/50% or 25%/75%.
Getting down to the nitty-gritty, Reiner says that purchasing needs
to pay particular attention to the issue of source code, something
an organization must have in case the supplier's business fails. And,
buyers need to think about additional modules. Who will pay for them?
In negotiations, purchasing should ensure that the organization receives
the modules at the same discount as the original software.
Other issues Reiner touched upon in her presentation: acceptance testing,
warranty, and maintenance.
Acceptance testing should begin upon successful implementation. The
test should be mapped to specifications. And, there needs to be a
time frame for resolution, with the user having capability to reject.
Generally, payment and refunds are tied to acceptance. Upon acceptance,
the warranty begins. In negotiations, determine the length of the
warranty. It is tied to the organization's specs. When it ends, maintenance
begins. Maintenance should cover at least two versions of the software,
says Reiner. The supplier provides support of customized modules,
and upgrades and fixes at no additional cost. There is a cap on increases.
For more information on Caucus, becoming a member,
local chapter meetings, and the annual conference, visit the group's
Web site at www.caucusnet.com
or call 407-740-0700.