Manager
Companies are creating custom code on a continuous basis. Once built, it remains in their systems and the previous system state is irreversible. Uncontrolled custom code growth leads to high maintenance and operations, as well as upgrade costs, and bears unforeseeable risks. Discover how to control custom developments with Custom Code Lifecycle Management. With the Custom Code Score Card (CCSC), you can make custom developments more transparent among stakeholders. The CCSC enables you to gain valuable information for your decision-making process. This way, you can account for governance and establish effective, efficient custom development.
Key Concept
Custom code assets are constantly increasing. As a result, companies struggle to find out what their major assets are and what kind of maintenance is required. The support organizations on a management level have no comprehensive method to ensure quality on a broad basis throughout the company. Outsourced and development units might have no vested interest in making their work effort and costs transparent. From the perspective of an accountant, most of the costs are overhead costs rather than direct costs that are assignable to individual developments. Maintaining custom code assets, therefore, covers a broad range of organizational functions.
Custom code is necessary for company-specific requirements and innovations required by the business. During an upgrade or Support Package implementation, custom code with a lot of references to SAP coding must be handled and needs to be adjusted. Often, custom code is created by a third party, such as an outsourcing partner. Therefore, associated IT governance is becoming more important. Most companies have created a huge amount of custom code and want to know what’s in their custom code assets. They also want to have costs under control on a global scale. Proper IT governance is a continuous improvement process, and part of this process is the control of IT custom code.
We’ll show you how to gain control by putting together the available custom code into a custom code library, the central part of the Custom Code Lifecycle Management (CCLM) application. This library allows you to plan in an appropriate way and reinforce actions from the responsible parties. We’ll also show you the Custom Code Score Card (CCSC), a concept built off the well-known Balanced Score Card (BSC) that focuses on custom code management. The CCSC aggregates the available master and transaction data contained in CCLM for management reporting. The CCLM application is a new central application available with SAP Solution Manager 7.1 that is ABAP based. Let’s start by looking at how to use the CCSC concept strategically before moving on to talk about how it works within the CCLM application on the operation level.
CCSC and Planning
Companies plan strategically, operationally, and tactically. These types of planning tasks work on different time horizons. Strategic planning is done on a three-to-five-year basis and is thus long term, while operational planning is usually done on an annual basis and contains operational tasks that are executable. The tactical dimension is even more short term and is usually done every three months. Strategic planning needs to provide data for operational planning, and operational planning feeds tactical planning. By using a CCSC concept for custom code developments, you can enforce actions within the organizational chart for the corresponding decision path.
Custom code reduction and the resulting cost reduction become strategic because it is either impossible (without significant effort) or very difficult to return to a previous system state. This is especially a challenge for bigger companies. There are certain decisions a company makes on a strategic level that enforce the operational level as well as the later tactical planning — and the corresponding subsequent individual decisions or actions. To implement the operational level, you need corresponding operational figures such as custom code total inventory, newly created inventory based on newly created objects, or even if the custom code takes part in any core business process. By using these operational figures, you can enforce tactical decisions that lead the support organization into gaining cost control on a long-term basis rather than expanding costs.
Achieving Goals with the CCSC
For the most part, the achievement of a financial objective can be expressed easily by a corresponding non-financial figure that is strongly correlated. For example, a non-financial objective of “I want to lower my number of custom developments” is strongly correlated to the financial figure of each development costing an amount such as $100 to $200 per year and per custom code object over the course of five years. Within a single CCSC, you can combine financial and non-financial figures. We are concentrating here on the non-financial figures for the CCSC because they are in most cases sufficient and easier to communicate to upper management. The CCSC is the compass that translates strategy into action regarding custom code.
Further, the CCSC is an instrument and method that is adjustable to each company’s situation and is clearly separated among the different management levels and roles to fit into any organization. The business controlling team that is in charge of the operational numbers provides guidance for any tactical decision done at the technical level. On the other hand, you need to come up with operational figures that are clearly defined for business and technical staff as well. A business analyst, as the interface between the executive and executing staff within an organization, can provide the appropriate operational figures (e.g., custom code creation per year).
CCLM Vision
Figure 1 illustrates the vision of effective, efficient custom code management. The fundamental goal of CCLM is to show how IT governance can be established with regard to custom developments. The visualization of transparency of all the depicted aspects (e.g., number of custom code objects, different versions, and the actual use in productive systems as well as quality) is the first and lowest level of the pyramid shown. That data is the basis for any calculated operational or tactical figure. On the second level, companies become active to gain control over the custom developments by maintaining data such as:
- Contract or owner
- Company-specific information such as a distribution rule for piloting of new developments
- A business criticality depending on company business

Figure 1
CCLM vision with three levels (source: SAP)
Introduction of the Custom Code Score Card
The CCSC follows the CCLM vision and the data is derived from the reporting functionality of the CCLM application. All three levels of the pyramid presented in Figure 1 are taken into account. The following overview shows the necessary figures and a derived final score on the top level:
1. Life cycle management for best-run customization
- Score (calculated from second and third level)
2. Control and ownership level
- Custom code objects with or without a contract
- Custom code objects with or without an owner
3. Transparency and awareness
- Number of development classes
- Number of custom code objects
- Severity level (enhancements and modifications)
- Quality (high, medium, or low)
- Version inconsistencies
- Usage in productive systems
The overall final score is calculated at the top and based on the lower levels of two and three, which represent governance figures and the figures of control of custom developments. Table 1 provides an example of the above mentioned figures with corresponding values and a final score calculation.

Table 1
Example for CCSC and score calculation
The CCSC takes into consideration the planning horizon by year as well as the individual figures that are part of the final score card and the calculation. Both figures are header data items. Table 1 illustrates a monthly report from September of an imaginary IT department for application management and sales and distribution (AM-SD). Each figure on all three levels of the pyramid has current values, values from last year, and future actual planned values. The planned values and the scaling factor, in combination with the provided thresholds, are used to calculate the total final score.
Finally, all scores are needed as part of the calculation to get the overall total and final score. For example, the number of custom code objects that have the attribute Contract is 558 and the planned goal is 729. That means that more than 75 percent of the objects have been maintained. Therefore, two points are multiplied by a scaling factor of two, making four. The scaling factor is necessary to prioritize the more important figures over the less important ones, and is done together with the thresholds. The result is that you can calculate a three-, two-, or one-point contribution to the score for each row.
The score at the top level represents the resulting CCSC value and indicates if objectives have been met. The difference between the initial objective and the final total provides further information about how close initial objectives have been met for the current month. You can define thresholds along with corresponding traffic lights of red, yellow, and green to make results quickly transparent. You can execute trend analysis on a permanent basis to get deeper insights about the current actions and status compared to a previous time period.
Reporting Capabilities of CCLM in Action
After laying out the overall vision of the CCSC and embedding that into commonly used business terms, we now present the actual reporting functionality available in CCLM to derive these actions. The application is important for deriving the values for the introduced CCSC in the previous section.
Figure 2 illustrates the entry screen of transaction CCLM. After finishing the customization and setup, you can trigger the data collection on the managed systems in the Settings section. The Objects section presents custom code objects, their duplicates, and related contracts and owners. This becomes relevant if there are several SAP landscapes with more than one development system configured. The maintainable objects, such as contract and owner, are assigned for controlling purposes of the custom code objects. You can maintain the assignments of personal and responsible owners, as well as different contracts for development or maintenance, here as well.

Figure 2
Overview with three sections in CCLM
There is no transaction data available in the current view of Figure 2 and thus no visible items in the Objects section. The transaction data becomes available as soon as the data collection has been executed. This can be done on a daily, weekly, or monthly basis.
Click Call Ad-Hoc Reporting under Common Tasks to produce the screen in Figure 3. The tool provides comprehensive reporting functionality for master and transaction data. The reporting capability can save variants to the database that can be automatically filled in a selection screen (Figure 3). In the General section in the upper part of the screen, it is important to fill in the library fields, such as Key, ID, and Version, to have the related results. Only one library can be active at a time.

Figure 3
Ad hoc reporting in CCLM
Furthermore, you can select the most relevant uses cases here as well:
- All Objects (All objects of the custom code library)
- New Objects (New collected objects in the library)
- Used Objects (Objects used at least once depending on system and period selection)
- Unused Objects (Objects that are unused depending on system and period selection)
The sections to select the system and period are in the middle of the screen in Figure 3. These sections offer functionality to further narrow down the result list. You can do this efficiently by selecting only parts of the managed productive systems, which might be organized for different regions or countries.
The Filter and Attributes section in the lower part of the screen is most substantial for filtering corresponding master and transaction data items (Figure 4). There are three options for master data that are enabled by default:
- Filter Attributes by
- References
- Add Columns to Report

Figure 4
The Filter and Attributes section for ad hoc reporting
The first filter allows limiting the result list by filtering of master data attributes such as Development Class, Source System, or Object (Figure 4). You can select the available attributes via an input help by pressing F4. The remaining fields labeled Value do not offer an input help. Figure 4 gives an example of how a filter selection of attributes and values could be done. Each attribute can have more than one filter value filled in at a time. In addition, there are input helps for the references, such as contract and owner. For both key values, the corresponding names are displayed with the corresponding ID.
Contract and owner information is essential for driving activities and to get control of custom developments. The reporting tool is designed to store and maintain such data so developers and managers can monitor their activities and report on the actual results.
With regard to the actual selection on database level, the ID is more important than the other fields mentioned, and, therefore, the ID is displayed in these fields by default. If no changes are made by the user, it is filtered for attribute references Owner and Contract. Each contract has two mandatory attributes: Contract Type and Organization. In some cases it is useful to search throughout all available development or maintenance contracts and to further limit the result list. The attribute would be set to Contract Type and the Value to the corresponding value or even to the asterisk, which is the wildcard. The Add Columns to Report check box is also available by default. It offers input fields with multiple selections that you can use to determine the attributes contained in the result list.
In the Transaction Data section, the following subsequent options are available:
- Usage (Usage per selected system and period)
- Version (Active version of the object in selected systems)
- Quality (Results from Code Inspector on an aggregated level)
- All Data (Usage, version, and quality data all together)
- Nothing (Only master data reporting without any transactional data)
After the execution, an output is created and returned via an SAP List Viewer (ALV) list as shown in Figure 5. You can download the results and import them into a spreadsheet to have various charts created for reporting purposes. The functionality is available just below the title bar.

Figure 5
Reporting results with usage, quality, and transport version
The example in Figure 5 shows data of 1,457 custom code objects that were returned after providing the selection criteria on the selection screen introduced in Figure 3. The first column of the reporting results (Figure 5) is the object ID of the custom code library followed by the object description, the SID, and the installation number that distinguishes which object data with regard to usage, quality, or version is collected. Not all records have usage fields assigned because only objects that are used on a daily, weekly, or monthly basis are taken into account as shown in the usage columns of Figure 5.
The quality data from the SAP Code Inspector with corresponding priorities of High, Medium, and Low is collected. It is available per the most recent run at the Quality Date. To be returned, there must be at least one message. The transport version is depicted in the last column of the ALV list. It is also only available if collectable data has been gathered and certainly is not available for local objects in the development class $TMP, as such objects cannot be transported to other systems.
CCLM is designed as an application and methodology for managing custom developments across landscapes. CCLM should be established as a single source of truth for custom code data within a company. The CCSC is an instrument and indicator for the degree of customization and enables customers to get control of own developments and establish IT governance and strategic controlling in all aspects of customization with the ultimate objective of best-run customization.
Veit Eska
Dr. Veit Eska studied physics at the University of Rostock and the Institute of Atmospheric Physics in Kühlungsborn, where he wrote a doctoral thesis on applied physics. He joined SAP in 1998, where he worked in the technical core competence team on the development of service tools for creating services such as SAP EarlyWatch alert. With regard to SAP Solution Manager 7.1, he is the product owner, architect, and developer of the custom code life cycle management (CCLM) platform.
You may contact the author at veit.eska@sap.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.

Oliver Kapaun
Oliver Kapaun graduated in economics and computer science at the University of Technology Darmstadt and has worked at SAP AG since 2002. Oliver is developing on-site services for MaxAttention customers. His areas of expertise include Java and ABAP technology, applications such as ESS, MSS, and MDM, and several other focus areas in the context of SAP technology.
You may contact the author at oliver.kapaun@sap.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.