Strategy and execution of ERP upgrades.
Faced with the decision to buy or build their computer systems, public-sector organizations have increasingly turned to the growing list of software vendors providing prepackaged solutions robust in the functions specifically required in the public sector. This trend has been especially notable in the Enterprise Resource Planning (ERP) class of software packages, which handle accounting, payroll, procurement, and other central-office functions. Leading ERP vendors provide solutions which integrate cross-industry "best practices" with government-specific features such as encumbrance accounting and position control.
Part of an organization's investment in an ERP System includes the opportunity to take advantage of technical enhancements and business process improvements in future releases of the software. In fact, most ERP vendors will include several years' worth of upgrades at significant discounts when purchased initially with their software. Organizations should upgrade their ERP software to current releases as they are made available to reap the benefits of the new features, software bug fixes, and new emerging technologies.
Many organizations question the value of performing an ERP upgrade project. When they do decide to undertake an upgrade, a lack of experience may cause the costs and length of the upgrade project to approach or even exceed those of the original software implementation effort. This article reviews the tips and traps in the planning and execution of a successful public-sector upgrade effort.
The Business Case for an Upgrade
Successful software upgrade initiatives, like the original implementations that preceded them, should make solid business sense and serve an organization's mission. Therefore, before beginning an upgrade effort, it is important to analyze the benefits the upgrade project can provide in order to accurately weigh against the time and resources that the upgrade will cost. In essence, it is important to establish a business case for the upgrade project. Here are some simple steps to take in order to formulate a business case for the upgrade effort. While each of these factors may weigh differently from organization to organization, they all generally contribute in some way to the upgrade decision.
What Direct, Tangible Benefits Can the Organization Derive from the Upgrade Effort? This is the first question to ask when contemplating a decision to upgrade ERP systems. Generally, every organization stands to benefit from an upgrade project in the following ways.
* Eligibility for Help Desk Support. Virtually all of the major ERP software vendors provide service after the sale. In fact, most vendors seek to influence purchasing decisions based largely upon the quality and timeliness of their response to questions about functionality, implementation problems, and potential software bugs. However, a software vendor can only provide quality help desk support if they are experts on the version of the software application the customer on the other end of the line is calling about. Most software vendors cut off support on a given version of their software 12 to 18 months after the next version becomes available.
* Solutions for Outstanding "Bugs" or Design Weaknesses. Although most software vendors invest heavily in software testing before releasing new code to customers, it is unrealistic to expect that any software package will be error-free. The majority of software bugs are resolved and delivered either fix-by-fix, or all-at-once as part of the next release version of the ERP package. Either way, the organization must be on a supported version of the software to take advantage of these fixes.
* New, Expanded, or Improved Features. Perhaps the most obvious benefit derived from an upgrade project is the opportunity to take advantage of system functions that were added to the software after the original implementation was completed. When an organization purchases an ERP package, it is purchasing not only the knowledge and strength of the software vendor and the software code as it exists the day they sign up but also the future enhancements to the product. Software vendors are constantly improving their packages. If a customer neglects to upgrade, they are robbing themselves of a significant benefit on their original investment. The vendors invest time and resources to researching, developing, and testing new features. The new functionality is probably going to expand or improve upon automated business processes. New releases also may address changes in tax or accounting requirements.
How Often Are Upgrades Necessary? Is it Possible to Skip Releases? The primary factors driving the need for and frequency of upgrades are the support window and upgrade path availability. As mentioned earlier, a typical support window for a given ERP software version is 12 to 18 months after the next release is introduced. Therefore, it is important to keep the cut-off dates for support of the currently installed version marked prominently on the calendar. Within the support window, it is possible to delay upgrade activities and even to skip releases, as long as the organization considers the software vendor's available upgrade paths. An upgrade path is the technically feasible sequence of version upgrades - if a vendor has released software versions 1.0, 2.0, and 3.0 in the recent two years, they may provide tools and advice for upgrading from version 1.0 to version 2.0, and also from version 2.0 to version 3.0. Each of these would be an acceptable upgrade path. Due to technical or procedural complications, it may not be possible to move from version 1.0 to version 3.0 without first moving to version 2.0. The vendor would not support the 1.0 to 3.0 upgrade path in this case. Exhibit 1 shows an example upgrade path, showing release dates and end-of-support dates for three different versions of an application.
It is somewhat of an art to understand when new releases are coming out, when support will be discontinued for an old version, and what the upgrade paths will be. However, a baseline understanding of the interplay of these factors, combined with frequent communication with the vendors, help organizations plan the timing of upgrades.
A few other questions are pertinent when considering the timing of an ERP upgrade.
* Availability of Desired Functionality. Does the upgraded release include new or improved functionality that is important to your organization? If so, the upgrade may make sense for the short-term. If not, it may be more cost effective to skip a release.
* Project Team Personnel. Are the functional and technical individuals needed for the upgrade team available to participate in the effort? Hopefully, the answer will be yes, indicating that the upgrade has been part of the organization's plan since the end of the original implementation or the most recent upgrade.
* Stability of New Release. How stable will the new release be (i.e., how many "bugs" might the new version have)? An organization must consider whether it wants to be one of the first to upgrade or wait until others have tested the waters.
How Much Will It Cost? Perhaps the primary factor weighing against the benefits offered by an ERP upgrade is the cost of performing the upgrade. The cost of an ERP upgrade can be as variable as the cost of the original implementation. There are many factors weighing into the upgrade cost, but it is usually enough to warrant a line item in the budget. It will most likely cost less than the original implementation did - hopefully much less - but it will be a project cost that should be planned and expected. It is possible to minimize the cost of each software upgrade with a comprehensive methodology and through smart planning during the original implementation.
Any Reasons for NOT Upgrading?
By analyzing the potential functional and technical benefits of ERP upgrades, it seems that any organization would prefer to establish and maintain an upgrade schedule if at all possible. The only reason to avoid the upgrade effort would be prohibitive cost. Some of the decisions made before and during the original system implementation can result in shockingly high time and resource costs. At some point the costs outweigh the benefits, and the organization has an issue to address concerning the long-term viability of the ERP package it implemented. While it is unfortunate when these conditions arise, it is important to identify them early. Although these cost factors certainly suggest delays in the upgrade schedule, they should seldom suggest abandoning the upgrade concept entirely.
Upgrade Strategy. The ERP vendors seem to be driven to get each next release into the hands of their current and new customers as quickly as possible. This is partly an effort of each vendor to keep their name on the lips of the industry analysts because they have the "latest version" of software in a very competitive market. It also assures that new and exciting functions will be made available to the customers as quickly as possible. Sometimes this occurs so quickly that by the time an ERP implementation is well underway, the next software version hits the street and the project has an upgrade to do before they ever go live.
It is important that the implementation team remain aware of upcoming release dates so that they may plan the project around those dates. For instance, it may be a good idea to wait to begin the project until an upcoming release is made available, leaving the largest period of time until the next release is ready. If an updated software version is made available in the midst of an implementation, the team must decide whether to perform the upgrade before the go-live date, or wait until after the software has been released into production in the organization before attempting the upgrade. It is reasonable to do the upgrade during the project if it can be completed before the system test and end-user training tasks occur.
Define "Guiding Principles" Related to Modifications. Software modifications are the primary variable complicating upgrades and increasing the cost of upgrade projects. When an organization modifies delivered code and the vendor changes the same code in the next version, the upgrade team must identify and reconcile the changes. Sometimes the team must even choose between their own modifications and those of the vendor, potentially affecting availability of help desk support from the vendor.
There can be conflicting goals surrounding modifications in every ERP implementation. Some may desire a "vanilla" implementation, in which modifications are strictly avoided. Others may seek to deliver the maximum efficiency for ERP system users, and will consider system modifications in order to achieve that goal. There are even some who insist that no functionality will be lost from the legacy system (even if it includes 20 years' worth of customizations), and will prescribe heavy modifications in order to add that functionality to the ERP system. These decisions will absolutely impact the upgrade - very modification the team chooses to perform will result in a cost, both during the implementation and every upgrade project. This is not intended to imply that system modifications can never be cost justified, but it is necessary to understand the impact of modifications and to always weigh the anticipated costs - current and future - against the benefits the modification would provide.
Exhibit 2 SAMPLE UPGRADE PROJECT TEAM Team Member Responsibilities Project Manager Project planning, tracking, maintaining scope. Project Technical Manager Supporting the technical environments. Database Administrator Maintaining database, sizing, and administering database security. Database Server, Network, Issuing login IDs and passwords, Administrator granting read/write and System system security, and handling connectivity and security issues. Application Administrator Maintaining the application table structures, ensuring processes run correctly, and making any necessary changes to the application configuration to resolve any issues. Upgrade Expert Running the compare reports, performing migrations, formulating a strategy for the upgrade, and maintaining tracking logs. Project Module Team Lead Knowledge of business processes, system modifications, batch interfaces and custom reports. Project Module Analysts Analyzing, designing, and reapplying modifications, trouble shooting, and testing. Technical Analysts Coding and testing.
Indeed, even when an organization adopts a "vanilla" implementation approach, a few modifications are normally unavoidable. In the public-sector environment, it is common to encounter a statutory requirement during the implementation that can only be fulfilled by modifying the ERP system code. While all modifications will affect upgrade cost and risk, "smart" modifications can minimize an organization's exposure while still allowing the system to fulfill the inflexible requirement. To develop "smart" modifications, organizations can follow these guidelines.
* Maintain Development Standards. Ensure that all system code changes are recognizable by using in-code comments. Also, establish and follow stringent standards in modification design and documentation. These standards will facilitate quicker analysis and identification of the modifications when it is time to upgrade the system.
* Create New System Objects. Where possible, avoid modifying existing objects (i.e., tables, data field definitions) in the ERP system. Instead, create new objects to achieve the same result. One of the primary upgrade risks arising from modifications is that the customer and the vendor will both make changes to the same object. Utilizing new objects as opposed to modifying existing ones minimizes this risk.
* Document Thoroughly. Document all modifications, from the business reason behind the modifications to the exact code changes comprising the modification. Documentation is tedious and time-consuming, but it will be absolutely invaluable during the upgrade process.
Planning the Upgrade
If you have already completed your implementation and made some decisions that may complicate the upgrade, do not give up. While it may be more difficult, an organization can successfully execute an upgrade regardless of the level to which their original implementation was upgrade-friendly or how much they thought about the upgrade when making decisions on modifications. If a defined and comprehensive methodology is followed, then the chances of a successful upgrade are substantially improved. A comprehensive methodology should consider all aspects of the upgrade process well in advance of addressing them during the process itself, supporting the early identification of issues and a clear definition of the steps to be followed.
There are four steps that should be followed in planning an upgrade. The planning should come before any commitment to conversion dates, estimate of cost, or estimate of effort. It is only by developing an accurate plan that the true scope of work can be understood. The first two steps focus on gathering documentation on the current application and environment.
First, ensure that a complete set of documentation exists for all modifications and processes that were implemented during the original installation. If the original implementation was equally well-planned, electronic and paper documentation is easily accessible, making the effort smaller. The effort also will be reduced if the persons who worked on the original implementation are still available and can be relied upon to support the documentation process. Of critical importance is establishing a link between a modification and the business reason for the modification. There may have been many objects built to support a business-critical modification. Knowing the link between the objects and the business case is very helpful when it comes time to evaluate the new release of the software - if the reason for a modification is not known, it will be difficult to determine if it is still required. At the end of step one, a listing of all modifications, their original documentation and their business justification should be available for use and evaluation.
Second, spend the time to document the current technical environment. This means taking inventory of all databases, their size, their use, the versions of the database, the version of the operating system, and how much space is available on the servers. Document any information on your technical environment that will support an evaluation of the requirements of the new release of the software against what is currently being used.
After completing the review of the current application and environment, steps three and four move on to building an understanding of the options and requirements found in the new release and in the processes necessary to upgrade. These steps are less dependent on the original implementation than steps one and two were.
The third step establishes a functional and technical understanding of the new release. Do this by reviewing any manuals or notes that the vendor has released in support of the application, by attending training classes (vendor-led or otherwise), or by installing a version of the new release and spending time using it and testing it out first hand.
Lastly, focus on the upgrade process itself. Most ERP vendors will deliver a set of instructions that, if followed, will help lead you towards a successful upgrade. But the instructions are not all encompassing and will require some interpretation and understanding of the potential implications of the steps involved. In short, make sure that what the vendor is recommending makes sense for the combination of platform, functions, and environment in which the organization functions.
The workplan should include tasks, resources, and target dates for the upgrade. While this workplan can offer a picture of what the upgrade will cost and require, it is still best to view this as a working document. Many variables will still exist. These include freezing development for the current release for an extended period of time, the length of production downtime necessary to perform the actual production upgrade, the scope of modification re-development, the time necessary to acquire and install any new hardware and software, and the potential inclusion of new features into the application. All of these could impact either the timeline or the scope of work necessary to complete the upgrade.
The initial workplan should define the project team as much as possible. During an upgrade, both functional and technical expertise will be required. In fact, the functional component of the upgrade is as significant or greater than the technical execution and must be accounted for in the project team. Functional resources will contribute most heavily in understanding new functionality, the changes to existing processes, functional software testing, and helping to develop updated training for end users. The technical upgrade roles tend to parallel the roles that technical members perform in the ongoing maintenance and support of the application. Exhibit 2 shows a list of roles that are commonly found on an upgrade project team. Keep in mind that the upgrade is an effort that is separate from, and in addition to, the maintenance of the current production application. So, while the roles may sound similar, the effort involved in both activities might require additional resources.
It is extremely important that the upgrade have a strong executive sponsor. An executive has to be supportive of the project and communicate the benefits of and need for the upgrade. The support will be critical in driving out decisions on such things as the timeline, the necessity of a modification, or the impacts of a business process change.
Executing the Plan
Once the plan is in place, an organization can move on to the execution. There are four distinct phases to a successful upgrade of an ERP application - impact analysis and initial upgrade, solution development, performance/acceptance testing, and production conversion.
Phase 1 - Impact Analysis and Initial Upgrade. First, perform an impact analysis on all custom or modified reports, interfaces, batch processes, and on-line modifications that make up the application. Determine how they will be impacted by the new release by comparing their processing to the configuration and processing of the new release and documenting any discrepancies. New fields on records and entirely new records are two things that may impact either modified or custom objects.
While the impact analysis is being conducted, the first upgrade also can be executed. Most packages deliver a method to compare your customized application against the new application and to identify the differences. Once the evaluation is complete, there is typically an automated process that will merge the two versions and create a customized application on the new release. However, it is likely that changes made by the vendor in the new release will overwrite many customizations.
Phase 2 - Solution Development. During this phase, all modifications that were overwritten are redeveloped and retested. Also, all business processes will be tested to ensure that the merge of the current and new versions was correctly and completely performed. This is the core activity of the upgrade, where all modifications are verified and tested.
Phase 3 - Acceptance/Performance Testing. The process moves into final testing, where a mock conversion is run and the application is tested for both accuracy and performance data. This is very different from Phase 2 where the system was tested only to verify that the functionality was accurate, but conversion of data to the new release was not tested. Once this phase starts, it is important to cease all development in the current production environment. It is almost impossible to upgrade a moving target.
It is not unusual for an organization to question the need for an extensive production-line test for an upgrade. As has been discussed, an upgrade is a major effort and should be respected as such - do not wait to find out that data has been corrupted or lost after the production system has been upgraded.
Phase 4 - Production Conversion. This phase is where the current application is upgraded to the new release and users will begin accessing the upgraded application. It is necessary to coordinate any necessary downtime with users to ensure that no critical business functions are compromised. It is necessary to verify that the data was converted correctly, that all security is accurate, and it is generally a good practice to schedule time for a small group of users to perform some basic transactions to verify that all is well. Depending on the requirements of the application, it also may be necessary to recover any interfaces or processes that were put on hold pending the completion of the production upgrade.
At the end of this phase, a fully functional production application will exist on the most recent release of the software. The successful completion of this phase is, of course, dependent on the completion of the first three phases.
Considering the benefits available from an ERP upgrade and the magnitude of resources required to execute one, these are significant projects for most organizations. There are several key success factors in every upgrade: first, if possible, begin planning for the first upgrade early in the ORIGINAL implementation. Doing so will help to minimize the impact of each upgrade on the organization. As with any major project, a detailed plan should be established in advance of any effort starting on the upgrade. This will help prevent any surprises from occurring along the way. Also, follow a structured approach and methodology for the entirety of the upgrade to keep users' informed of the upcoming changes and involve them in the testing process. While following all these recommendations is not a guarantee for a successful upgrade, not following them is almost certain to increase the costs and risk of failure.
KURT COLLINS is the co-founder and Division Leader of Empower Solutions. Empower Solutions is a Division of Intelligroup, Inc. (http://www.intelligroup.com/) and can be found on the World Wide Web at http://www.empowersolutions.com/. WILL GREER, Financial Practice Leader, and ROB KUNGENSMITH, Upgrade Practice Leader, also contributed to this article.
|Printer friendly Cite/link Email Feedback|
|Title Annotation:||enterprise resource planning|
|Publication:||Government Finance Review|
|Date:||Aug 1, 1999|
|Previous Article:||Phased ERP implementation: the City of Des Moines experience.|
|Next Article:||The future of ERP in the public sector.|