Introduction
A slew of recent announcements and vendor analyst briefings might be showing an interesting trend. Namely, enterprise software vendors are becoming more amenable to pledging support for older (even quite antiquated) product releases, much to the delight of anxious users who still rely on those releases. Until very recently, these users were faced with vendors' more or less subtle ultimatums and deadlines by which they should migrate to current product releases, or else.
In
the recent past however, Made2Manage (with continued support
for the Visual FoxPro database-based product release), Adonix
(with continued support for the recently acquired CIMPRO Classic
and CIMPRO V products), Epicor (with continued
support and certain enhancements for venerable Avante, DataFlo,
InfoFlo and for the recently acquired MANAGE 2000
product), and MAPICS (with continued support for recently "stabilized"
Point.Man, albeit with the option to migrate to the recently
acquired and more promising SyteLine product) would be some
examples of the vendors that have announced that they will support the respective
aged versions of their products. These vendors are encouraging their customers
to consider migration at the customers' convenience some time in the future.
Also
notable was the recent PeopleSoft pledge to continue to enhance
and support the former J.D. Edwards IBM AS/400-based World
Software (now renamed as PeopleSoft World), while at its recent worldwide
partner conference, Microsoft Business Solutions promised ten
years support (till 2013) for all its current product lines on diverse proprietary
technologies, even after the so-called Project Green (i.e., new single code
platform based on the Microsoft Business Framework including .NET)
becomes available some time in 2006. Most recently, Geac Computer Corporation
announced a set of programs, called Value for Maintenance, designed to help
customers better integrate Geac and third-party software and simplify the Web
enablement of the company's applications, whereby the programs will be rolled
out first to Geac's legacy mainframe-based E Series and M
Series products.
The
list of similar announcements could go on, ending with the very recent announcement
by SSA Global to offer ongoing support for its recently acquired
Baan solutions and also a product roadmap into the future.
Incorporating feedback from existing customers, the initiative includes enhancements,
extensions, a new thin client user interface (UI) for existing Baan
IV and Baan ERP 5 product lines, and a commitment
to the delivery of the next generation ERP platform SSA Baan ERP 6,
previously codenamed Gemini. This is the reversal of the decision
made by Baan when it was part of Invensys. At this stage, SSA
Global raises the bar with its claims that "no product will be sunset," whereas
most other vendors pledge the support for older products only for some unspecified
extended period of time.
In any case, this is good news for user organizations that want to stay on the older release, but is it necessarily a good business model for the vendor?
Why Do the Users Want to Stay on an Older Release?
These announcements are indisputably a sigh of relief for customers who want to remain on an older release. But why do they want to resist the upgrade? As with many things in business, the cost of upgrade often outweighs the value of upgrade.
Factors on the cost side of the evaluation are reapplying modifications, redoing integrations, the need to retrain users (users become attached to the old product that "has been working"), and the general cost of business disruption. The vendor can mitigate some of these costs by supplying conversion tools, training, etc. but much of the cost is unavoidable.
Factors
on the value side of the evaluation are new features and support for newer technology,
such as Web enablement, collaboration with trading partners, and self-service
applications for mobile users to name some. However, users tell us that frequently
the features offering the most value are the ones that the users have addressed
through modifications, which reduces the value of new features. The situation
becomes particularly complicated for the product releases that have been heavily
modified/enhanced by a value added reseller (VAR), particularly in cases where
the VAR has gone out of business. For more about the upgrade rationale and dilemmas,
see The
Old ERP Dilemma - Should We Install The New Release?.
Vendor Considerations—It is About the Money
The decision to support older releases is like any other business decision, it is all about the money and profitability. As with any business, if the vendor can make money by providing support for older releases, it is good business for the vendor. The decision may be sugar-coated with pronouncements about doing what is good for the customer, but both the vendor and the customers know that the first consideration must be the money.
In the past, vendors could minimize the cost of support by forcing all customers to stay current, using the most recent release. This led to a common policy of not supporting older releases because that maximized profits. But times have changed. Many customers do not see the value in staying current with releases. These customers then see less value in support since their release is not supported anyway, and are therefore in jeopardy of stopping support payments. Since the vendor needs these customers to maximize revenue and profits, it is now in the best interest of the vendor to support these older releases.
How the costs work and where is the break-even point? The cost has two elements. First, bug fixing and keeping the software compatible with changes in the operating environment (operating system, database, hardware discontinuation, etc.) is a fixed cost that does not vary with the number of customers supported. On the other hand, the majority of hot line support, distributing bug fixes and other similar cost varies with the number of customers supported. (A portion of these costs are fixed, you need a minimum number of people regardless of how many customers are supported.)
Revenue is derived directly from customers taking support. Indirectly, vendors also typically feel that a customer on support is more likely to purchase more software and services, however few vendors consider this (and they should not) when making the decision whether to support an older release. If comparing the projected cost to the projected revenue, does the vendor see an adequate return on investment (ROI)? If so, then it looks upon supporting the older release as more favorable (other issues are part of the decision like the alternative use of the resources, the value of keeping everyone on one release, etc.) If the analysis does not show an adequate return, the vendor has the following three practical solutions: 1) do not offer support, 2) get more customers to buy support, or 3) charge more for the support. While gaining more customers for support sounds obvious, it is often much more difficult (and thus costly) a feat than expected.
Another
possible extreme example is the approach taken by Relevant Business
Systems, which until recently, did not have a formal major product
release schedule per se for its flagship INFIMACS II product,
but would rather deliver only several periodical continuous enhancements that
all the existing users get automatically (like patches). Still, this is only
possible due to the vendor's sharp focus on complex manufacturers and MRO (maintenance,
repair, and overhaul) contractors in the defense sector, and with a relatively
small install base of customers keenly interested in these individual enhancements.
The picture gets quite a bit more complex for a vendor serving dozens of unrelated
industries, where not all users would necessarily want to take new enhancements,
which would then result with a number of customers remaining on "unsupported"
product versions. The proof of a challenge to support all the versions would
be Relevant's decision to institute a formal six month schedule, as to mitigate
the releases support conundrum.
While
particular vendors are making the decision, each may still look for a longer-term
commitment from the customer base as an added incentive to offering support.
Even behind SSA's vocal pledge for supporting all its products, each individual
product release likely has its own profit and loss (P&L) calculation, so that
each business case must stand on its own. Consequently, some releases may still
be dropped in the future, while some may have the support price increased. Also,
with SSA's impending products convergence strategy in the future (i.e., into
future devised SSA iSeries, SSA UNIX, and
SSA Financials product lines), the vendor may be thinking longer
term and want to hereby keep the customers in the fold.
Recommendations
Users—If
support for your older release is something that has value, communicate the
need to your vendor. Be prepared to talk about what you are willing to commit
to, how much, and for how long. If you are off maintenance contract, is this
of value to you (for more info, see The
Old ERP Dilemma: How Long Should You Pay Maintenance?)? If so, communicate
with your vendor.
Vendors—We
still see many vendors who steadfastly hold on to their past policies on support.
However, times have changed; the industry has changed, should you reconsider
your policy? We understand you are running a business and need to make a profit.
For most vendors, this is something that your customers want and you should
not be afraid of open conversations on the subject. Explain to the customers
that this is a business decision that requires you to make a profit and that
the cost of support may increase as the number of customers for that support
decreases. It can be good business and good for your customers.
About
the Authors
Olin
Thompson is a principal of Process ERP Partners. He has over 25 years
experience as an executive in the software industry. Olin has
been called "the Father of Process ERP." He is a frequent author and an award-winning
speaker on topics of gaining value from ERP, SCP, e-commerce and the impact
of technology on industry.
He
can be reached at Olin@ProcessERP.com.
Predrag
Jakovljevic is a research director with Technology Evaluation Centers,
Inc. (TEC), with a focus on the enterprise applications market. He has over
fifteen years of manufacturing industry experience, including several years
as a power user of IT/ERP, as well as being a consultant/implementer and market
analyst. He holds a bachelor's degree in mechanical engineering from the University
of Belgrade, Yugoslavia, and he has also been certified in production and inventory
management (CPIM) and in integrated resources management (CIRM) by APICS.