ChaRMante extensions

When we talk to customers about Change Request Management (ChaRM), we always emphasize that there are two main types of so-called process types that are already included in delivery customizing: the "normal correction" and the "urgent correction".

Both workflows map the management of software changes and are perfectly integrated into the transportation system.

The main difference between the two types: Normal changes can only be made productive as a release. Urgent corrections, actually intended by SAP for time-critical, immediate adjustments, can be made productive at any time without release assignment.

In an initial delivery, these two "workflows" are available in the system and can still be customized, but the form of production implementation (as a release or individually) is predefined by the system.

Many customers can't live with the relay-oriented view. One reason for this is that IT managers do not want to mess with the business department and only want to put functions into production at certain times. On the other hand, the excuse "We are agile and therefore cannot commit to a release" is used.

The majority of ChaRM users therefore only use the urgent correction. In implementation projects, however, there is more than one workflow, so that this process type is mapped in different variants in the system - e.g. as a Preapproved Change and as a Major Change.

The context behind this always remains the urgent correction and the associated opportunity to productively implement the changes individually.

If IT managers are introduced to normal correction and its software process, there is usually a significant advantage over urgent correction: It works with transports of copies.

As developers usually do not have the test data on the development system that is relevant for a more extensive test, the changes must be brought into the quality assurance system and tested there.

In the classic context, this means that the transport must be released and imported. This is not a problem in itself; most companies have mapped the authorization system in such a way that transports can be released by developers and an automatic import is defined for the import queue of the quality assurance system.

In practice, however, it often leads to development, testing, development and then testing again. I have already seen such cycles for requirements in which more than a hundred transports were created.

In the classic use of an urgent correction, this can be mapped via the workflow and the overtaking protection does the rest, but productive implementations of such changes are still extensive.

With transports of copies, the import queue remains lean, as the objects are placed in the downstream system using the "Transport of copies" request type, but these "attempts" never end up in the import queue of the production system. In such a context, more than a hundred attempts are not a problem.

There is one important feature to note here: The original transport remains open until the development activities have been completed and the objects are then permanently locked for this change. This has the advantage that overtakers can no longer occur.

With a few clever moves and some coding, this procedure can be transferred to the urgent correction. We also usually set up the workflow so that the original transport is not released until the key user has completed the tests.

In this workflow, overtakers are a thing of the past. Particularly in environments where only urgent corrections are used, the key user wants to see the changes in the production system as soon as the tests have been completed.

As the time delta between the release of the objects on the development system and import into the production system is small (usually less than a day), there are no more problems with overtaking.