you have just completed implementing an enterprise resource planning
(ERP) software package and you think you're set for the next five years—and
I have a bridge in Brooklyn that I want to sell you. Once a year (or more frequently
if you have really angered the software gods), the vendor issues a new release.
With the new release come promises of new functionality, better performance,
or incorporation of technological advances. Should you install the new release?
Is it worth it? What will happen if you don't? Can you defer the decision for
a year or two? What are your options?
this article looks at three options regarding implementing new releases of enterprise-wide
software. Then, assuming you elect to maintain pace with new releases, a new
class of software tools, enterprise process improvement (EPI), is described
to facilitate and help in the decision-making process through a collaborative
partnership with your software vendor.
In this article, a distinction is made between a service pack and a new release. Typically, a service pack is issued to fix software bugs and is not intended to add or modify functionality and data elements. Consequently, unless you have also modified or enhanced the code that is being altered, a service pack should be able to be installed with little effort or testing.
Alternatively, in addition to code changes, a new release can encompass new functionality, new data elements, and revised workflows and processes. While we will discuss the costs and tasks involved with implementing a new release, it should be obvious that many of the activities you completed in the original software implementation will have to be repeated, hence, the quandary as to whether to install the new release or not—that is the question.
What Are Your Upgrade Options?
Your options are whether to upgrade or not. Well, that was painless. Of course, if the decision were truly that easy, consultants would be unemployed. Bite your tongue! I have kids to put through college!
when the smoke clears, the decision is whether to upgrade or
not to upgrade. The difficult part is appreciating the short and long-term effects
of today's decision and understanding the cost components involved with an upgrade.
For a more detailed discussion, read Olin Thompson's TEC article, The
Old ERP Dilemma: How Long Should You Pay Maintenance.
1: Install New Release (The Good)
The first option is to install the current release. As stated above and depending how significant the new changes are, many of the activities completed in the original implementation will have to be performed again. Internal labor resources must be
re-committed to implementation and support tasks such as piloting the software, retraining users, converting data from external systems, modifying custom reports for data elements changes, and re-applying enhancements. Perhaps to a lesser degree than their involvement in the original software implementation, the use of vendor consultants is usually required and highly recommended.
If you can resurrect the original project team, you may be able to implement the new release at 50 percent of the original implementation budget and time. In this case, familiarity will not breed contempt but rather smooth out the learning curve. If you are unable to cajole, encourage, or outright browbeat the original project team members to support the new implementation effort, you may be near or at the original budget. And, depending on how soon after the last release you start the new release implementation, don't be surprised at hearing the refrain, "Here we go again," sung in a less than enthusiastic tone. Of course, there are the intangible costs such as business disruption and the burden on the users for having to do double data entry during the transitional period. Again, these types of inconveniences were also experienced in the original software implementation.
2: Discontinue Maintenance (The Bad)
The second option is to discontinue or go off maintenance, which implies that your company will not take this or future releases. More importantly, this decision implies that your IT department has the technical resources to support the current state of the software and that the user community is fully satisfied with the current functionality of the software. Furthermore, users do not foresee the need for additional capabilities in the near future. Additionally, technological and hardware changes must also be accommodated by the internal IT staff or by a willingness to hire or engage needed resources. When electing to use a third party, there is a greater challenge of retaining a critical mass of professionals needed to support your software. Typically, a third party will not have the depth possessed by the vendor.
The decision to go off maintenance is not irreversible but you will not save any money by stopping and then re-starting maintenance. While some software vendors are reluctant about allowing customers to go back on maintenance, most are even more reluctant to lose the potential of a recurring revenue stream. Typically, vendors will require you to make up missed maintenance payments and you must agree to come up to a supportable release level in a specified period of time. Therefore, before you go off maintenance, make sure that you understand the conditions to resume support.
3: Skip A Release (The Ugly)
third option is the middle-of-the-road alternative. Under this option you decide
to implement every other release, skipping a release and catching up on the
next one. The theory is that, if it costs x
dollars to implement a release, the cost of implementing two releases is the
two times x
dollars. Simple math says that if you skip a release, you save x dollars. Unfortunately,
simple math does not apply to the practice of implementing software releases.
Sure, you may only have to pilot the software and train users once but many
of the other implementation activities will have to be completed for even the
An example will help to illustrate this point. External data will have to go through a conversion for each release. The vendor will almost always provide routines to convert their data from one release to another. However, to use these routines the incoming data is expected to be in a certain format. Consequently, external data must be converted to the release being skipped even though it will not be used in a live production mode. Similarly, the new release code, vendor-supplied data conversion routines, custom reports, and enhancements may have to be applied to each release. Regardless, a significant amount of time will be required to investigate the impact of skipping a release.
The main problem with skipping a release, however, lies in the possibility that problems will be encountered with the go-live release. Is the problem in the skipped release or the go-live release? How do you discover the source of the problem? In many cases you have to go back to the skipped release and perform the never-completed piloting and testing. Finally, if the implementation of the selected release does not go as planned, you may fall out of warranty. Typically, vendors support the two most current releases of their software. Let's say that you are on release A, skip release B, and, as planned, choose to implement release C. Technically, the vendor does not support release A and you are out of warranty. While vendors do not normally enforce this policy, but rather use it as leverage to encourage continual migration, you must be aware of the situation.
Deciding not to pursue the standard upgrade path may not return the savings initially expected. You must accurately and objectively evaluate the true cost of your decision. However, doing this on your own without the benefit of the expertise of the vendor is like a high-wire act without a safety net. Sure, it has been done before, but why take the risk?
Enterprise Process Improvement (EPI) Software
Hopefully at this point of the article, you are inclined to continue maintenance. Great! Now, how do we convince management that the project to implement the new release of your enterprise-wide software is as important as or more important than the sales department's project to improve reporting and better anticipate customer needs; the marketing department's project to support the roll-out of a new campaign to increase sales; or the production department's project to improve line reporting to provide advance notification of declining yields? Competition for limited budget dollars is tough and any help to support the new release upgrade project will be much appreciated.
is where the new class of software, enterprise process improvement
(EPI), comes to the forefront. EPI is intended to provide CIO's with information
to demonstrate how the new release will save money, improve efficiency, and
offer value-added functionality not previously available. Essentially, EPI brings
enterprise performance management (EPM) in-house. Whereas EPM software
caters to existing clients and new customers, EPI is intended for and targeted
exclusively at a vendor's existing customer base. In effect, EPI software leverages
the existing relationship and confidence in your software vendor and the vendor's
expert knowledge of the enterprise data repositories. This expertise comes from
knowing the data format—alpha, numeric, alphanumeric, and decimal precision;
the data definition—calculated, inferred, dynamic, or static; and the data structure—table
name, indexed, primary key, and secondary key.
shown in figure 1 below, the EPI software sits as an umbrella on top of the
data repositories for the enterprise applications. Using defined query scripts
dictated by specific processes, data is extracted, analyzed, and reported.
The reports highlight savings to be realized from processes not currently being used, or processes contained in the new release of the software.
A simple example will help to illustrate how EPI software can assist in quantifying the benefits of a new release. Let's say the new release of your existing ERP software provides an e-commerce facility whereby your customers can place, update, and check the status of orders. This new process, as defined in the new processes library, would be used to execute vendor-supplied scripts to extract averages such as order size, order amount, number of changes to orders, and turn around time from the repository database. This data together with vendor-defined, but company-supplied, parameters such as minutes per order line creation and the percentage of orders that could be entered via the Internet, the EPI engine could calculate the savings in reduced labor hours and staff size by using this new process on an annual basis. Similarly other new processes could be quantified such that the total value of the new release could be approximated.
With the information supplied by the EPI software, the value of the new release could be determined and evaluated against other projects competing for common resources. With this information in hand you may stand a better chance at getting management's attention and approval.
The value of EPI software does not have to be limited to just new releases. It could also be used in post audits to validate the benefits received from the implementation of enterprise-wide software. While you are not going to pull the enterprise software out based on a poor audit, the audit results may direct your activities to investigate bottlenecks and instances where expected savings are not being realized.
The sequence in which you might go through an EPI study is not that different from any project looking to streamline operations and existing practices. After the vendor-defined, user-supplied parameters are completed, the new release processes contained in the aptly named library (see figure 1) would be executed against the enterprise-wide data repositories. Since the vendor software is working with the vendor's expected data, the tedious exercise of mapping values against business processes can be avoided. The reporting will prioritize the processes based on annualized dollar savings or cost avoidance. At this point users can target the new processes offering significant benefits. The summation of these processes will approximate the total value expected from the new release.
An EPI study should typically take 5 to 10 days to complete at a cost ranging from $10,000 to $16,000 (USD). In lean times or when vendors are trying to encourage their customer base to migrate to a new release, you can expect the pricing to be very aggressive. Some vendors may offset or discount the professional services necessary to implement a new release with the cost of the study. Ask and you may receive.
Hopefully, you are now convinced that staying on a maintenance program is in your best interest and can help maximize your investment in enterprise-wide software.
EPM software is becoming fairly commonplace and is offered by most full service vendors. However, upon realizing that new prospects are becoming increasingly skeptical of performance information being supplied by a heretofore unknown vendor, vendors will look to retrofit EPM software for the purpose of providing EPI services supported by EPI software.
EPI software may come as close as you can to a win-win situation. Your company gets needed assistance in cost-justifying the implementation of new releases of
enterprise-wide software. The vendor gains a valuable foothold in the new territory of influencing the decision process regarding new releases.
Bottom line: you may want to approach your vendors to see what they have in their bag of tricks regarding EPI services and software.
J. Strub has extensive experience as a manager and senior consultant
in planning and executing ERP projects for manufacturing and distribution systems
for large to medium-size companies in the retail, food and beverage, chemical,
and CPG process industries. Additionally, Strub was a consultant
and Information Systems Auditor with PricewaterhouseCoopers and an applications
development and support manager for Fortune 100 companies.
can be reached at JoeStrub@writecompanyplus.com.