Intro
In my experience as an SAP consultant, I have been so lucky to be involved, together with friend of mine sergio.ferrari2, in a lot of upgrade projects and I can say for sure that they have in common the cloned programs.
Since most of the work of the '"upgrade men" (aka ASU team) focuses so much on the adjustment of these "uncomfortable" objects, in this blog series I will focus on the feelings and the approach of the clones maintenance during the upgrade projects.
The making of a clone
First of all, we should start by giving the definition of a cloned object in SAP system.
A clone is a customer specific object copied from an SAP standard one and then modified to satisfy a business requirement.
Since SAP always advises its customers to avoid modifications to the SAP standard code, before the introduction of user-exits, the only known way for a SAP developer to satisfy the customer's requirements without making repairs, was by creating a suitably modified copy of SAP the standard code, the “clone”
The most common reasons for cloning a SAP standard program are:
- Copying SAP standard reports in customer name space it’s more easy if compared to modifying SAP standard or implementing a user-exit; copying a program is faster and doesn’t need to fill out tons of documentation to explain the reasons why you need that SSCR registration key or to implement that enhancement
- By implementing the modifications in the cloned program, the standard one remains “alive and kicking”
And in my experience I've never found a customer’s SAP system without clones; it’s as the clones are part of the “customs and traditions of that place” (system).
Kind of clones and...upgrade issues
Normally we have two kinds of cloned programs:
Full-Cloned Program:
When the developer creates the copy of the standard program, creates also all the underlying sub-objects such as the includes, the menu area, etc. in the customer name range; these types of clones are quite consistent and probably they won’t have syntax errors in the new release
Half-Cloned Program:
Here probably we had a lazy developer, so the standard program was cloned creating in the customer name range only the changed sub-objects.
After the upgrade, for these cloned programs, the risk of error or inconsistencies is very high; the original standard object changes and the cloned programs become often inconsistent.
Another situation is represented by the cloned programs that do not have syntax errors, because the upgraded version of the original program SAP has been enhanced with new features. In this case the clone works like in the old release but doesn’t include the features introduced by the new release that necessarily should be integrated (clone refresh).
Clone refreshing: The two sides of the coin
If you are approaching an upgrade project you must decide between:
- Technical upgrade: Focused on the minimization of the risk and retention of the existing functionalities (conservative approach)
- Functional upgrade: focused on total cost of ownership, by acting on the complexity of the system (e.g. reduction of modifications and custom applications)
- Upgrade with strategic business improvements: focused on the review of the processes and on the adoption of new strategic applications
Most of the customers choose the technical upgrade, a quick approach to the upgrading, mainly for cost reduction, but also to minimize the impact on the ongoing and future implementation projects.
What is the approach to be taken in case of technical upgrade and adjustment of the clones?
If you apply a conservative approach, that is, adjusting the cloned program only syntactically but without integrating the new features, you inevitably create some differences between the standard programs, which are always young and the cloned ones, which become older, because every upgrade increases the wrinkles (the Two-Face in Batman).
Therefore if you adjust the clones without integrating the new features, after one or several upgrade projects, you might have the standard one enhanced, for example, with beautiful ALV, and the cloned program that is still using the WRITE statement!!!
And your users that are complaining all the time: << I don’t like this program… Upgrades are useless… SAP never improves …>>
To be continued...
In the Episode 2 I will discuss the ways to manage the cloned objects during the upgrade projects.
- SAP Managed Tags:
7 Comments
