D
ifferent studies held among CIOs shows that most SAP R/3 implementations are initiated to replace old homegrown software. Besides making all the software Y2K compliant, and getting rid of homegrown applications, a third reason has been to implement standard software like SAP R/3: Business Process Reengineering. A lot of companies used the implementation of ERP (Enterprise Resource Planning) software as a mechanism for reorganizing the company.SAP R/3 upgrades are sometimes seen as complex and difficult projects. The process is sometimes even feared. Although it can be complex and difficult, an upgrade project is like all other projects—it’s all about skills, commitment from the business, and good project planning.
The reason behind an SAP upgrade project, whether it’s R/3, BW (Business Warehouse), CRM (Customer Relationship Management), or EBPro (Enterprise Buyer Professional), can be various, but in most cases it’s initiated due to the withdrawal of release support by SAP. On a few occasions it is related to functional requirements, for example, the new R/3 functionality that is only supported in a new or higher R/3 release. But it can also be driven by other SAP products, for example, the interface between SAP APO (Advanced Planner and Optimizer) in relation with SAP R/3.
87
ERP Software Implementation Cost percentage
(36 respondents, average 750 named users);
Annual maintenance = 16%–20% of license fee source: ICT Magazine 2005
5.1 WITHDRAWN FROM MAINTENANCE
One of the major reasons to upgrade the current SAP application is the approaching of the end-of-maintenance date. SAP regularly updates and announces changes to their maintenance schedules. It’s highly recommended to check this schedule often because end-of-support dates change frequently.
SAP supports various maintenance types. New names have been introduced recently.
“old” software maintenance name “new” software maintenance name Standard Maintenance Mainstream Maintenance
The SAP software component product life cycle passes several phases, where each phase has its own different maintenance schedule for customers:
Figure 5.1: SAP product support/maintenance life cycle. ©Copyright SAP AG.
Once an SAP application leaves the development phase, it’s released to a limited number of “ramp-up” customers. This phase is also known as “FCS (First Customer Shipment).” After this phase is finished, the product becomes GA (General Available) to all other customers. At this phase the products enter the
“Mainstream Maintenance.”After Mainstream Maintenance an optional extension of maintenance is available to all customers. However, the support fee for
“Maintenance Extension” is roughly 2–5% on top of the normal maintenance fee.
After the “Regular Support” phase has ended, the “Customer-Specific Support”
phase starts. This support is rather expensive and very limited and should therefore be avoided.
Figure 5.2: SAP support maintenance fee model. ©Copyright SAP AG.
Under pressure from various SAP user groups, such as ASUG (American SAP User Group), DSAG (Deutsche SAP Anwende Gruppe), and VNSG (Vereniging van Nederlandstalige SAP Gebruikers), SAP has agreed to simplify the extended maintenance offer for their customers and to clarify the cost structure for this extended maintenance.
The rules for getting “Maintenance Extension” from SAP have been simplified.
For example, the restriction on SP stacks has been abandoned. Also, the Extended Maintenance Check from SAP has been withdrawn as a prerequisite.
5.2 MAINTENANCE STRATEGY
The SAP Release Strategy Guide is released twice a year with the latest updates on product roadmaps. This Adobe Acrobat PDF file, which can be obtained (free download) from http://service.sap.com/releasestrategy, contains an exact description of all SAP Business Solutions and their components, with respect to support, availability, and maintenance strategies. This guide will tell you, way up front, when certain products will be withdrawn from support and against what conditions the support can be extended. It also describes the best upgrade strategy to a newer release.
Figure 5.3: Long-term release and maintenance planning of SAP ERP.
©Copyright SAP AG.
Be careful with the interpretation of the maintenance strategy of SAP. Each SAP system consist of several components that all have their own end-of-maintenance dates, for example, SAP R/3 4.6C with IS-Oil running on Oracle 9.2.0.7 and IBM AIX 5.2. The end of maintenance for SAP R/3 4.6C is the first of January 2007, which includes IS-Oil 4.0B. The maintenance strategy for IS Solutions and other add-ons might differ as well. However, the standard maintenance for release
4.6C can be extended with one more year, called “Extended Maintenance.” To get extended maintenance, the customer needs to contact his SAP account or support manager and ask for a so-called “MEC Questionnaire” and “MEC Audit trail”. In order to comply with certain support restrictions, additional Support Packages need to be applied to the system; in most cases up to the latest available SP level and a special SAP Basis EXT kernel needs to be applied.
To obtain the exact maintenance strategy for your entire SAP landscape, please refer to both the support matrix and the end-of-maintenance dates for each individual component. Also, do take interface tools, add-ons, and bold-ones into account.
Both operating system and database engines are also subject for maintenance extension. Such information needs to be checked with the respective supplier, for example, IBM for AIX and Oracle for the database.
5.3 NEW FUNCTIONALITY
An important consideration for release upgrades is the new functionality offered by the target release. SAP will support two types of upgrades in the future:
Technology Upgrades and Functional Upgrades and a combination of both.
A technology upgrade covers only the technical aspects of the application. An example of this is the upgrade of the “standalone” SAP Web Application Server 6.40 to 7.00 or an upgrade from SAP R/3 4.6C to R/3 Enterprise 4.7 without using the “new” Extension Sets.
The functional upgrade will become more common now that SAP has decided to disconnect the technology layer from the functional layer. For example, BW 3.1 can be upgraded to BW 3.2 using so-called BW_CONT (Business Warehouse Content) add-on packages that are loaded using transaction SAINT. The customer gets new or more functionality without having to upgrade the entire application stack. Another example is the upgrade of SAP CRM 5.0 to 5.2. Both releases are based on the same SAP AS 7.00 technology layer. So in this case only the CRM application is changed.
New functionality is quite a broad term. New functionality can reside in all kind of places in the application. Therefore, SAP releases white papers around new developments, way before the actual release of the product. For more information on new developments, please have a look at http://services.sap.com/
developmentnews. In case the new product or version is released, SAP documents the new functionality in the so-called “Delta documentation.” These documents describe new functionality categorized per module and business process. The standard help pages of http://help.sap.com are also available for reading up on new products.
Figure 5.4: Help pages on various SAP products at help.sap.com. ©Copyright SAP AG.