Clustering with ChaRM
Some IT managers have been busy in the past introducing change request management. The credo I always preach here is: A requirement from a specialist department is approved via a change request and then leads to one or more changes.
This statement already contains the first question:
Why actually multiple changes?
It is now the case that Solution Manager also masters several transaction types in Change Request Management. A transaction type is essentially a construct consisting of a workflow, a definition of the change form, i.e. the user interface and, in particular for changes in the SAP environment, of course also with the connection to the transport system.
No other change management tool represents this linking of the workflow with the import mechanics via the STMS so well and has the same functions as Solution Manager.
The transaction types "Normal change" and "Urgent change" were created for this purpose. Now, it is of course the case that complex requirements in particular require changes not only in an SAP environment, but also in other system environments.
Solution Manager also makes it possible to define a workflow and use it for this purpose. Of course, the connection to the transport system is not available here and is not even necessary.
This design can also be used, for example, to map changes that require adjustments in an SAP interface and on a web interface. The adjustments on the web interface would be classically represented as a "non-SAP" change.
This concept works very well because the change request always forms the bracket between the individual changes. This ensures that the coordination of the different changes can be completed.
Without a change request, exactly this bracketing and required reconciliation in the change process can only be done very laboriously via additional fields on the form.
The issue that a customer wants to supply several system lines via a change with transport connection was already provided by SAP in version 7.1 with SP10. Exactly this component is called cluster.
In this way, a so-called cluster can be formed from a BW and an ERP landscape. This cluster can then be used to manage changes that are made in both landscapes. This ensures that changes do not have to be managed and coordinated manually across multiple transport landscapes.
In Solution Manager 7.1, this technique was still somewhat in its infancy. The clusters always had to be identical. So if you had an ERP landscape with three systems, you also needed three business warehouse systems to complete this logic. With Solution Manager 7.2, this has changed and "uneven" clusters are also possible.
The whole thing always sounded so good on the slides that I always represented this mode of operation to customers. I was always surprised that there were only a few discussions on this topic on the Internet, especially in SDN.
Since the last implementation, it is also clear to me why: What SAP is hiding here is that the "Urgent Change", which most customers have exclusively in use, cannot use this function at all.
SAP has implemented this cluster functionality only for "Normal Correction", leaving out in particular those users who do not perform release-oriented development. Even customers with release-oriented development are penalized: All changes within the release dominate the cluster.
All other changes of the "urgent change" type do not. So massive rethinking is required here.
Unfortunately, this was so poorly documented that I also fell into the trap here. The way out of this impasse has meant that by means of enhancement spots and a few minor modifications we have also activated the cluster collection for "Urgent changes".
I hope SAP will see sense and act promptly. If we, as a consulting firm, manage to turn on this feature via customizations, SAP should succeed even more.
