|
This article was featured in the October, 2007 issue
of the Technology First Magazine.
Dayton, OH
October 26, 2007
By Mikhail Roytman, Partner, Ellipse
Solutions LLC
 It
took years of long discussions and negotiations. This organization
was not known for quick decisions. The user community was
begging for change. All of the important indicators were increasing
on a monthly basis - sales, production, profits as well as,
unfortunately, inventory levels, late shipments, and quality
issues. While sales and manufacturing were putting up record
numbers, the enterprise system was unable to keep pace. New
solutions were needed to improve planning, scheduling, procurement,
warehouse management, and other areas. The management was
ready for the next step: improve the current combination of
a 15-year old homegrown solution and assorted third-party
systems. Business processes are always somewhat unique for
all companies, but the procedural flow in this Ohio automotive
supplier was standard enough for many common ERP applications
to handle. And not just handle, but also dramatically improve
most areas of the business, thereby gain a competitive advantage.
Were the executives trying to match the business requirements
with software capabilities of various applications? Not this
time around – one of the most important reasons this
corporation seriously considered no packaged ERP solution
is what I call an “upgrade anxiety”. The experience
of some of the company’s higher-ups with the costs and
technical difficulties of upgrading an ERP system drifted
this organization towards a route of custom written software.
Although many at the top believed that a packaged system could
be found to better satisfy their budget, schedule, functional
and technical expectations, it was seen as a temporary solution.
The upcoming modifications and future upgrades seemed so terrifying
that all of the ERP vendors were ignored despite their arguments.
This brings us to Part 3 of the ERP Implementation Series.
As you might have guessed, today’s feature is dedicated
to the essentials of the ERP Upgrades.
“Honey, we need to upgrade our kitchen …”
This story was not designated to start a package vs. custom
software debate. It is a valid topic … for another day
– today we will consider the basics of upgrading a solution
once it has been purchased, implemented and put in use.
The term “upgrade” is interpreted in many ways.
While to most professionals the “upgrade” means
new innovative technologies, advanced functional abilities,
expanded architectural compatibility, or improved data management,
many ERP suppliers also hide various corrections and fixes
under the same terminology. It sounds much better to call
a customer and say: “A new version improves …”
vs. “It’s a patch to fix the problem we were unable
to correct before.” In the end, both cases are important.
Most of the time, companies are interested in both repairing
the glitches as well as exploring new technologies. That’s
why properly planned ERP implementation also triggers the
preparation for future upgrades before the first kilobyte
of your new application is ever installed.
Why Upgrade?
When an ERP provider announces a new version (release, revision,
patch, fix or whatever other cliché name is in use),
the first question is characteristically: “Should we
bother?” Most companies pay their software maintenance
fees and virtually all upgrades are either free or comparably
inexpensive, so the initial response is often: “We already
paid for it – let’s use it.” When dealing
with reputable solutions possessing a proven quality control
process, it is a relatively straightforward task to install
technical patches and fixes. However, if it is truly a new
release with additional and/or modified functionality, the
upgrade process is not much different than the initial implementation,
including all of the important steps such as data conversion,
functional user acceptance, testing, training, conference
room pilot, etc. Of course, having been through the process
once or twice before, the resource investment on the part
of management, user community and IT should be significantly
less than the original implementation. Many factors play important
roles in the upgrade budget, however I have seen studies where
a typical upgrade takes on average approximately 30 to 75
percent of the initial ERP project budget.
Some companies religiously follow latest releases while the
majority can’t afford to jump on board every time a
new version of the package hits the market. Many local companies
delay implementing non-urgent upgrades and then attempt to
leap through several releases at once. Our experience show
that this practice does not always result in cost savings.
Many software vendors stop supporting previous releases once
new versions are introduced. Additionally, all of the intermediate
revisions must usually be loaded anyway just to enable a smooth
path to the latest version. Finally, the level of the upgrade
complexity rises considerably when companies start hoping
through releases.
Many innovative technologies compel management to do the
upgrades. Such advancements help to reduce costs and improve
processes long-term and cannot be ignored. At one time, every
solution provider added bar-coding capabilities, then object-oriented
programming came to play, etc. Imagine a warehouse today without
a bar-code reader. More recent modifications include addition
of web interfaces, RFID, Service Oriented Architecture, XML,
new data security and quality programs among many other now-mandatory
functions.
Customizations galore
By far, the toughest issue standing in the way of software
upgrades is related to customizations of the original application.
Outside of the smallest organizations, most companies require
enhancements to the packaged software. This is one of the
major architectural qualifications an ERP solution can bring
to the table. Is it built to manage change? There are many
ways of implementing customizations to minimize the affects
of upgrades on your future software solutions. Some of the
better ERP applications construct the architectural foundation
to ease the process of creating modifications.
One of our clients skipped numerous releases over the span
of approximately 10 years and finally migrated from Mapics
DB to Mapics XA Release 6 several years ago. The software
was highly customized and the older versions of Mapics provided
very limited resources of properly incorporating modifications
with the main solution. Even though, the initiative was a
success, it required a huge enterprise-wide effort and took
over 2 years to accomplish.
Another one of our current clients is moving their Microsoft
Dynamics AX solution from version 3.0 to 4.0 (after initially
starting with AX 2.5). Their solution was heavily enhanced
for many years including major new modules to cover very specialized
in-house procedures. However, both the company and MS Dynamics
AX have been prepared for this from the get-go, and the successful
upgrade is expected to go live in November. Yet the size of
this company and the magnitude of their operations and modifications
still took about one year to achieve although it was done
with comparatively limited resources never interrupting the
development process of new internally created enhancements.
On the other hand, a couple of smaller local manufacturers
made an effort to sacrifice some of the benefits of their
solutions and purposely are not making any modifications (other
than reporting). Their upgrades are less involved, but in
most cases such strategy brings limited return on their ERP
investment.
A Word of Advise
These stories are very typical. Many other factors (user training,
new hardware requirements) can affect significantly the schedule
and the cost of future upgrades, however some strategic decisions
can facilitate the process:
- Proficient management practices of internal software development
can ease some of the upgrade challenges. Rarely is it justifiable
to update the actual package source code. Most seasoned solutions
allow methodologies to properly manage modifications such
as user exits or custom layers.
- Selecting an ERP solution built to handle change can heal
a lot of future pains. And always, always consider the cost
of future upgrades when selecting new ERP software for your
organization.
- Many experts recommend hiring a permanent ERP Manager, because
the so-called “implementation” is never fully
complete in our continuously evolving business environment.
And even though it is a great idea, unfortunately, it comes
with a pricey tag and most companies can’t afford a
permanent ERP Department.
- Document, document, document … Keeping tight records
of all modifications (functional and technical) will immensely
ease the hardship of future upgrades.
- Any properly structured major upgrade provides an opportunity
to review the infrastructure and combine a software upgrade
with other initiatives (for example, hardware re-assessment,
business processes re-evaluation, etc.) and typically save
money in comparison to carrying out those projects independently.
- With any other product, be it a microchip or a microwave,
the rule of thumb is to wait until the new release gets time
tested. Unless there is a tremendous financial incentive from
your ERP vendor or a “can’t wait” new functionality,
the goal is to give a chance to the provider to resolve the
initial problems before committing your organization to such
an undertaking.
Until next time, your friendly ERP correspondent …
Mikhail Roytman is a Partner with Ellipse Solutions LLC,
a global Microsoft Business Partner headquartered in Dayton,
Ohio. Ellipse Solutions is a division of Roytman Information
Services, Inc., a provider of Career Placement and Consulting
solutions in Information Technology, Management and Engineering.
For additional information please visit http://www.EllipseSolutions.com
and http://www.roytmanIS.com
|
