A Visible Solution Paper
How Do You Evaluate Packaged Software?
Printable
PDF Version
Copyright © 1997, Visible
Systems Corporation
In this interview,
Visibles Alan Perkins, vice president of Consulting
Services, discusses the important issue of determining whether
off-the-shelf software will truly meet a companys business
needs. Alan, who has over thirty years of information technology
experience, has been consulting with companies on business
process reengineering and establishing corporate data
architectures for the past ten years.
Q. What are problems that companies face in
purchasing off-the-shelf software for business applications, such
as SAP , PeopleSoft, and MRP?
I have heard horror stories about companies spending
hundreds of thousands of dollars sometimes even millions
of dollars on consulting services to implement these
already over-priced, integrated business application packages. In
many cases it has taken years to get to a point where the
applications are useful. Some companies just give up after months
or years of effort because they realize the package will never
meet their needs. I believe there are two main reasons why
companies have little success with these applications:
- Many executives do not practice strategic management
and therefore are hoping an off-the-shelf business
application will magically make up for their lack of
focus. Essentially, they abdicate their management role
to the programmers who developed the application suite.
This usually results in wholesale change of their
business practices to make the best use of
"one-size-fits-all" software, rather than
modifying the software to reflect their own best
practices. Even those executives who know the
companys mission, goals, strategies, objectives and
performance measures haven't documented them to a degree
that allows them to be translated into business software
requirements.
- Most companies search for applications before they
have paid sufficient attention to improving their
internal processes and practices. Good software that
automates bad business practices is not a good system.
Q. What are common mistakes companies make in evaluating
software packages?
It's surprising what otherwise competent managers will do
when selecting software. They will select based solely on price,
or physical platform, or development language, or database
management systems, or size of the manufacturer, or
persuasiveness of the sales pitch, but rarely do they look at
anything but the most general business and data requirements. For
example, if they need accounting data, they'll make sure the
application suite includes an accounting package, but they won't
look any deeper to see if it will handle their chart of accounts
and their accounting practices.
Q. Which techniques are most effective in evaluating
software and ensuring that they meet the business and data
requirements of the organization?
There is only one effective technique for such evaluations.
It is not complicated, but it requires a thorough knowledge of
the company, its strategic and performance plans, its data and
information requirements, and its practices and processes. These
elements, which make up the company business model, must be
documented in such a way that they can be communicated and
validated internally. The business model must also be documented
so that it can be modified easily and quickly when change happens
and it will happen. In addition, the company's strategic
business model should be capable of being translated readily into
software requirements and evaluation criteria. Only when armed
with this information can a company successfully identify,
evaluate, and implement commercial software.
This assumes that the company's business practices and
processes have been evaluated and engineered to most effectively
meet company goals and objectives. A company should never attempt
to buy or build systems to support processes that need
improvement. Nor should they blindly adopt external
"best" processes and practices without ensuring that
they are truly best for the company.
Q. What technique/method would you recommend for evaluating
software packages?
After determining the business data and information
requirements that the package will need to support, companies
should identify potential packages and vendors. Then the
company's information system needs and evaluation criteria should
be communicated to all potential vendors with an invitation to
propose solutions.
The first round of evaluation will involve reviewing all
proposals and rejecting those that do not meet minimum
requirements. The vendors that survive the first round should be
invited to make a formal presentation and demonstrate their
product. If one or more of the vendors can demonstrate that their
products exactly meet the company needs, then selection can be
determined based on price and service. If no vendor meets all the
requirements, then the gap between the vendor proposals and the
company requirements must be analyzed. This may require asking
the vendor and other firms to project the cost and effort
required for closing the gap.
Q. How is data/process/object modeling used in evaluating
software packages?
Models are used to represent actual things. They can
represent things that exist or designs of things to be created
(or purchased). Data models represent the company's operational
data, strategic information, and business rules. Process models
represent what the company does, and often how things are done.
Object models represent reusable application components that are
a combination of data and the processes used to create, read,
update, and delete the data.
Q. What are the advantages of using modeling for such an
application?
Models facilitate communication within a company and with
potential vendors. A single, conceptual (logical) model can
represent the overall business model of the entire company. The
company can use this enterprise architecture model as the source
for every application and database design (physical) model. Most
CASE tools and other state-of-the-art application development
tools can create executable application components directly from
physical models.
The company can also use the logical model as the benchmark
against which to evaluate commercial applications. If a vendor
has used a structured, model-based approach to developing its
application components, then those models can be compared readily
with the company model.
Q. What are the benefits of using data modeling for
packaged software evaluation?
The most stable portion of an enterprise architecture is
its data model. How a particular data element is processed is
less important in selecting packaged software than the existence
of the data element. In fact, a company can effectively evaluate
commercial software using just functional requirements and a data
model.
Q. Do you foresee changes in the way software package
vendors work with their customers?
I think vendors will be more and more likely to make their
own models available to potential customers for comparisons and
evaluation. I hope vendors will encourage customers to take a
strategically-driven, information-centric, customer-focused,
model-based approach to application development and
implementation. I expect vendors will partner more with customers
in order to provide solutions that meet the customers exact
needs.
For more information regarding this Visible
Solution, please contact:
North
America
Visible Systems Corporation
201 Spring Street Lexington MA 02421 USA
Phone: +1-781-778-0200 · Fax +1-781-778-0208
Web Site: http://www.visible.com
Email: mcesino@visible.com
|
Asia-Pacific
Clive Finkelstein,
Managing Director
Information Engineering Services Pty Ltd
PO Box 246, Hillarys Perth WA 6923 Australia
Phone: +61-8-9402-8300 Fax: +61-8-9402-8322
Web Site: http://www.ies.aust.com/
Email: cfink@ies.aust.com
|
|