Featured Author - P. Hennigan
- December
6, 2000
Introduction
About every eighteen to twenty-four months the technology industry identifies
the latest in a long line of silver bullets that will simplify the delivery
of technology's benefits to the business world. The ASP model has recently
enjoyed that distinction and the accompanying hype. Unfortunately, wading
through the hype to determine if this particular silver bullet can bring
value to your business is an arduous task. This article provides some
simple guidelines for determining if you should consider the ASP model
along with thoughts on selecting an ASP.
Why
an ASP?
If you believe the marketing hype, the ASP model will solve all the software
development, delivery and maintenance problems that businesses have consistently
struggled with. While that can't be the case, the ASP model does present
an attractive option given the right situation.
The
existence of the right situation depends on how well you have defined
your business functionality need, the IT resource constraints you face,
and the cost issues you must address. A few questions can help determine
when that situation exists.
What
is the nature of the business functionality you need to deliver?
- Will
it require significant customization to use an existing ASP offering?
- Does the
functionality need to be integrated with existing systems?
If you answer
yes to these two questions, then the ASP option may not offer the best
option. Although it is evolving, the ASP model is based on the economics
of delivering similar functionality to multiple customers with minimal
integration. As soon as you start discussing significant customization
and integration you step out of the ASP model into the systems integrator
model.
This is not
to say that any customization or integration needs should prevent you
from examining ASP options. Most ASPs can handle some customization, and
their offerings may routinely support basic integration with enterprise
systems. However, significant customization or integration usually means
you are faced with a full-blown systems development and integration project.
If you are
considering the ASP route for mission critical functionality, proceed
with caution. This may be unavoidable with start-ups, but established
companies should experiment with the model on less critical functionality
until the market shakes out.
Does an
ASP deliver functionality that you need but can't deliver alone due to
resource constraints?
An ASP can
help you address many of the issues those resource constraints present.
Whether the issue is time to market pressure or skill constraints, an
ASP may offer a feasible solution. That solution carries forward for ongoing
maintenance. The ASP model minimizes the resource you will need to devote
to the ongoing maintenance of the functionality.
The ASP option
doesn't eliminate your need to manage the delivery of the functionality.
Managing the delivery of the ASP service is a critical function that you
can't skimp on.
Do you
lack the capital to purchase and install the software required to deliver
the functionality?
The ASP model
is a rental model. It has lower entry costs than a purchase or build-your-own
option. If you need the functionality, but can't afford the capital to
purchase it, the ASP option will provide you access.
This does
not mean that the ASP model guarantees the lowest total cost of ownership.
Much of the ASP hype focuses on the cost savings picture, but that picture
does not clearly show whether the ASP option will generate less cost over
the life of the application.
Selecting
an ASP
Selecting an ASP is no different from selecting any other type of service
provider. Your selection criteria should be aimed at answering the following
three questions:
- Does
the ASP's offering meet your business requirements?
- Will
the ASP be around as long as you expect to need it?
- Can the
ASP deliver the functionality at your required service levels?
The first
question reflects the simplest and most important principle: clearly define
your requirements before selecting a solution to meet them. If you don't,
you can't adequately answer any of the questions. Also, when you are defining
your requirements, think beyond your current needs. How might your business
strategy impact your needs several years out? What's the minimum duration
for which you need this relationship to last? If you can answer that question,
then you only want to consider ASPs that will be around at least that
long.
That brings
us to question number two. However, given the maturity of the industry
how do you evaluate the viability of the providers you consider?
Although
the industry is immature, you still follow basic due diligence procedure.
You deal with the immaturity factor by setting your risk tolerance requirements
at a level that doesn't eliminate all the players. The due diligence questions
aimed at answering question two should include the following:
- How long
has the vendor been in business?
- How long
has it been delivering the specific functionality that you are interested
in?
- How strong
is its financials-income statement & balance sheet?
- What
are its funding sources?
- What
is its market?
- What
are its growth plans?
- How many
customers does it have and how big are they?
- How many
customers has it lost in the last year and why?
- What
does it see as its competitive advantage?
- What
portion of its infrastructure is internally provided and managed?
- What
portion of its application portfolio is internally developed and managed?
- Describe
its alliances/partners? How are they funded?
Question
three addresses the key issue.
Can
The ASP Deliver?
Can the ASP
deliver the functionality at your required service levels? In order to
answer that question you need to examine the operations of the ASP. Your
examination should include the following major areas.
Infrastructure
- What
components of the delivery infrastructure do you directly provide? Indirectly?
- For components
provided indirectly:
- Who
provides them?
- What
is their customer base and how do you compare with other customers?
- What
is your SLA with that provider?
- For all
infrastructure components regardless of who is delivering them:
- Examine
the procedures, methodologies, and tools addressing:
-
Systems Management
-
Change Management
-
Performance Measurement
-
Security
- Disaster
Recovery
- Describe
the current infrastructure capacity and any growth plans.
Administration
- Human
resources
- What
is the staffing by function within the ASP?
- What
are its staffing growth plans?
- Change
Management
-
What is the process for handling changes to service?
- Customer
service model
- Who
will own servicing your account?
- What
staff will be working on your account?
- What
is the problem notification process?
- How
are issues escalated?
The examination
of the ASP's operations will help determine if it can meet your service
levels. The formal Service Level Agreement (SLA) will then establish the
framework for managing the service levels and the relationship with the
ASP.
The
Service Level Agreement
As you construct
the SLA, you need to think about three major aspects: scope, mechanics,
and remedies.
- Scope.
Your SLA scope must be broad enough to address all the critical components
of the ASP delivery model. A useful guideline is to include system,
network, and application performance within the scope. This ensures
coverage of the critical components, and provides a framework for end-to-end
service levels regardless of whether the ASP directly provides all the
delivery components.
- Mechanics.
The SLA mechanics are crucial to the effective management of the service
levels and the relationship. You must define specific and measurable
performance metrics. The SLA should include both the metric definitions
and measurement process. Any debate regarding the metrics and their
measurement should end before you sign the contract. The SLA should
also detail the change process and issue escalation mechanics. Define
now the process for making any changes to your service in the future.
Likewise, define and document the process for handling issues. If the
first level of operational managers can't satisfactorily resolve an
issue, how quickly does it escalate and to whom?
- Remedies.
The final aspect of the SLA is the remedy. Unsatisfactory or untimely
performance should trigger performance remedies. The purpose of discussing
remedies is to first eliminate from consideration those ASPs that won't
be able to deliver your required service levels and second to focus
the selected ASP on meeting its guaranteed service levels.
The ASP model
is not a silver bullet after all. It is another selection in the expanding
menu of ways for businesses to access technology. The model brings with
it the strengths and weaknesses inherent in any third party sourcing model.
Organizations should look past the glitter, and seek to evaluate this
model in a systematic fashion to minimize business risk.
About
the Author
Peter E. Hennigan
Mr.
Hennigan's experience includes more than twenty years in analytical, sales,
financial and IT roles. As a Principal with Technology Contract Solutions
(TCS) Mr. Hennigan focuses on helping clients minimize the risk and cost
associated with their technology acquisitions. His recent experiences
have included the financial analysis of a data center relocation for a
major brokerage house, an analysis of the data center hardware and software
contract portfolio for a large Midwest healthcare, the negotiation of
a multi-year hardware break/fix contract for a large Northeast insurance
company, and the development of an application development services agreement
for a Northeast financial services company.
Previously,
Mr. Hennigan spent over ten years in senior management positions in the
Information Technology Department of the Liberty Mutual Group, a Fortune
100 financial services company. Mr. Hennigan holds a BS in Civil Engineering
- Magna Cum Laude and an MBA from Syracuse University.
Mr.
Hennigan can be reached at:
phennigan@technologycontracts.com