Skip to Content
Author's profile photo Rick Porter

SAP Change Intelligence

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, some 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.

Assigned Tags

      1 Comment
      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      Is this a new tool?  What does it do that we can't do with the tools we have now?

      Just curious, I may have read your blog wrong.  You are correct, it is very hard to keep track of changes that have made it to Q and not PRD.   So if there is a change out there, I build on top of the change, D, my change goes to PRD along with the other change.

      Or worse, I do a compare, start for the PRD data, and overlay a change on Q.  I can see that being a larger problem, the more our development team grows.

      Great information and hoping that there is a new tool to track that instead of the manual way of comparing each client.  And the project may be across systems as well!

      If nothing else this should bring some good debate!