ERP Implementation Series: The Chronicles of Software Upgrades
Author: Mikhail Roytman
October 2007
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.
