Expand +



SAP Change Intelligence

by Rick Porter

November 30, 2011

We hear a lot about Business Intelligence (BI) these days where Business Intelligence systems are used to improve an enterprise's decision making by combining tools for gathering, storing, accessing and analyzing business data. Change Intelligence tools do the same but for change related data. Change Intelligence tools permit analysis of change related data to monitor, summarize and alert on change activity and improve change related decisions.

To best understand the potential value of SAP Change Intelligence, it's necessary to understand the sources of SAP system change, the lurking dangers of unidentified or lost change and the limitations of current native tool sets.

Sources of SAP system change

In a busy SAP environment, system changes happen all the time. New developments are introduced daily such as fixes, support packs, minor enhancements, releases and major project developments. System restores, refreshes and client copies occur regularly. Development personnel move on and off and in and out of projects frequently. This means that the likelihood of an SAP IT team fully understanding the state of change both within and between SAP systems and clients at any point in time is highly unlikely. Understanding elements of change such as work in progress, stale change and object version inconsistencies across systems is difficult.

Lurking dangers

In busy IT operational environments the cleanliness of systems reduces over time. The correct version of every object is not exactly where is should be - in that all change that has begun in development has not been propagated (or in a plan to be propagated) to all systems. There is development forgotten and lying dormant in DEV or QAS and not all objects versions are as expected in each system.

The lurking danger manifests when, for example, som e dormant forgotten code in DEV is inadvertently moved to PRD or a later version of a critical object is overwritten in PRD when an earlier, out of sync, version is moved in. The errors and problems that result from such situations are generally very difficult to identify and thus resolve and may be very costly to the business and a source of embarrassment to the IT team.

Limitation of native tools

Underlying SAP SE tools can help. For example if a problem shows up in PRD and the offending object is known, SE80 (Object Navigator) is a great tool to drill into the object to see what versions are in a system. It is also a useful tool to compare versions across two systems. The same goes for data dictionary objects through use of SE11 (ABAP Dictionary Maintenance).

The native mechanisms for change related data result in often large, very dynamic and dispersed data over several systems, and so meaningful and timely intelligence can be quite illusive.

Where the limitations begin to show up is in the area of preventative analysis. For example, identifying changes in QAS but not yet in PRD or finding differences between objects across three or more systems.

The value of 'Change Intelligence'

Having fast access to an array of change data that contains facts and detail about every change in every system including before-and-after version information, presents a wealth of opportunities for developers, basis team members and managers. For instance, with this type of information readily available it is a straightforward task to quantify the difference between objects that may be for example in QAS and PRD. When it is simple to compare custom objects across multiple SAP systems by analyzing every object in every system, team members can quickly see exactly which objects are different in QAS and PRD and make timely information based decisions.

An email has been sent to:

More from SAPinsider


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!