| > |
Do
make sure business objectives for evaluating applications
are well-scoped and focus on the most critical
operational and strategic requirements. |
| > |
Do
centralize application purchasing as much as possible
if your MSB is geographically distributed. This
provides cost efficiency and consistent support,
and helps hinder renegade spending by business
units for similar functionality. |
| > |
Do
provide financial due diligence before looking
at any vendor's offerings. How long has the vendor
been around? How many customers does it have?
How many new customers did it add in the past
12 to 18 months? Is it profitable? Does it have
a sizable and well-established MSB client base
in
your industry? |
| > |
Do
check customer references. Application vendors
being considered should provide references of
enterprises that match your size, scope (for example,
the number of suppliers or transactions) and industry.
Only talk to clients that are using solutions
at current version levels and that have used the
solution long enough to understand the strengths
and weakness of the vendor and products used. |
| > |
Do
attempt to negotiate a way to test the application
first and then pay for it only after it has demonstrated
business value. Set milestones for vendors that
they must reach before the IT department will
advance to the next phase of a project or buy
additional software and services.
|
| > |
Do
consider in advance the possibility of vendor
mergers. Make sure the contract terms don't change
if the software vendor is acquired. Conversely,
if you are evaluating a smaller vendor that has
aggressive plans to acquire more businesses, will
you wind up being a small fish in a big pond? |
| > |
Do
determine how the vendor would react to the scenario
if you suddenly had to downsize or reduce the
use of the product. |
| > |
Do
consider how the vendor would handle the transfer
of purchased software from one operating system
or hardware platform to another. Be certain you
understand source code rights. |
| > |
Do
scrutinize the customer service record of the
vendor: who is responsible for resolving application
support issues. If it's a reseller or vendor partner,
determine the escalation process. What is the
quality and responsiveness of customer support
— for example, what is the response time
and satisfaction rate on support calls? |
| > |
Do
ensure vendor offerings under consideration align
and integrate with your IT architecture. Ensure
that there are no technical shortcomings or interoperability
issues. Determine how the product works with other
vendors' products you use and whether it can work
with partners or customers' platforms when and
if required now or in the future. |
| > |
Do
determine who owns the product and code. Find
out who can make code changes and who owns the
changes. Who does the code revert to if the vendor
ceases operations? |
| > |
Don't
be sidetracked by functionality that has nothing
to do with the defined requirements for the application
and wind up paying for unneeded features. Implementation
failures often occur because MSBs try to do too
much at once. |
| > |
Don't
equate bargain pricing with getting a better deal.
Some vendors' rock-bottom pricing campaigns don't
include such essentials as necessary training
or additional services that ensure overall success
and satisfaction. |
| > |
Don't
automatically accept the vendor's license calculations.
Understand how many end users will actually use
the application. Do you really need an enterprise-wide
license, or is it more economical to purchase
named or per-user licenses? Vendors often have
many different, confusing pricing models. Make
sure the one proposed fits your usage profile. |
| > |
Don't
pay maintenance for built-in upgrades if you plan
to upgrade on a different interval. Consider how
frequently you will need to upgrade the software
after installation and decide if your organization
is capable of handling maintenance in-house. |
| > |
Don't
consider vendors with small R&D budgets. Software
application vendors should spend between 10 percent
and 20 percent of their total revenue on developing
new and improved products to remain innovative. |
> |
Don't
forget that software applications come with a
range of additional costs through their life cycle,
including application and layered software, needed
hardware upgrades, the cost of labor and so on.
These costs can easily surpass the initial cost
of the installed system. Consider TCO and be sure
to scrutinize maintenance, training installation,
hardware and ongoing support costs. Try to identify
all potential hidden charges. |
> |
Don't
consider immature vendors or offerings unless
necessary. If the vendor or solution being offered
is new, and you are compelled to use it, be sure
you are compensated for the risks involved. |
> |
Don't
just evaluate the vendor. If the vendor's sales
or support partners will be involved, scrutinize
and do equal due diligence on them to ensure they
are up to the task. How long has the partner been
trained and certified in supporting the application
under consideration? Do they have industry competency
and are they used to dealing with enterprises
of your size? |
> |
Don't
assume that large vendors automatically equate
with ongoing stability. Understand the changing
market dynamics of the segment you are sourcing
from, and note that even larger vendors are not
immune from disruption. MSBs should consider up
front what the strategic direction and focus of
the prospective application vendor may be, as
well as what merger, acquisition, divestiture
and demise scenarios might be attached to them. |
