Philosophy

“Culture eats strategy for breakfast”

Peter Drucker

A ChaRM introduction always means a culture shock. Probably the biggest challenge of a ChaRM implementation is therefore the necessary change in mentality among those involved.

Culture shock

At first, the old warhorses react with shock, then switch to an ignoring attitude and try to screw around with the transports as before – but this is exactly what the ChaRM tries to prevent.

There are conflicts and blame is placed on the ChaRM, which is perceived as a tight corset. Self-doubt also arises.

But after a period of getting used to it, acceptance spreads, you begin to appreciate the new – initially scary – structure of the change process, you enjoy the convenience of the powerful tools that you slowly discover for yourself, and finally you are pleased to recognize the positive leap in your own productivity. Manual maintenance of transport lists for auditing is a thing of the past. The ChaRM forgets nothing. Time-consuming communication between decision-makers, developers, testers and operators has become obsolete.

Individual change

Most ABAP developers and customizers are artists of individual changes, they juggle with the transport objects in “their” transports and spend a lot of time analyzing the correct import sequence in order to finally acrobatically plan transports in or out.

At some point, the whole thing becomes so tangled up that you are forced to make a system copy of the development system to bring it back into line with the production system.

SAP ABAP transportation, on the other hand, has followed an industrial paradigm since the introduction of R/3. Everything that is automatically recorded in the start system must be transported through to the target system in the same order. No exceptions: If you want to undo a change, you have to transport it and its deletion through. The ChaRM follows this paradigm and reinforces it.

That has to sink in first. Because thinking in terms of individual changes is very tough.

Phases

One aspect of the individual change is the particularly stubborn habit of wanting to put the “own” change into production immediately after a successful function test. It is easy to forget that every import of workbench objects stresses the production system. Initially, there is an allergic reaction to the introduction of change cycles with phases because they force a joint approach: The test phase involves joint testing, while in the go-live phase everything that has been tested is imported into the productive system at the same time.

But there is wisdom in the phases that becomes visible during testing.

Test phase

After an error has forced the re-inventory of the high-bay warehouse in Stockholm and you have lost your best Swedish customer due to the weeks of downtime (it really happened!), you start to think about whether the old joke that the real test only takes place in the production system anyway isn’t pretty stupid after all, and you start – quite a burnt child – to seriously weigh up the not inconsiderable effort of integration and regression tests with the risk of a severe drop in sales.

Integration and regression tests

However, these vital tests have their own rules, which ChaRM supports with the test phase: In this phase (and also in the go-live phase), no further transports can be released and imported into the QA system. This is because any import after the start of these tests would invalidate the results of the test scripts already executed; they would have to be repeated (in a validated environment this is enforced by law).

Incidentally, the hotfix only makes sense in these two phases. As he has his own task list, he can set an emergency correction productively despite the export-import block.

Here too, thinking in terms of individual changes casts a nasty shadow. If an error is found during the test phase, you immediately search for the change document that must have been responsible. Many new statuses are often created to facilitate this identification.

With this tunnel vision on the individual change document, one forgets that during the test phase one no longer looks in the direction of development in order to have as many errors corrected as possible, because the freedom from errors of a new or changed function has already been confirmed by the individual tester.

No: During the integration and regression tests, in which the E2E processes are tested, you turn 180° and now look in the direction of production. The aim now is to prove to the business that the next go-live will be functionally complete and error-free (did I hear Homeric laughter here?).

Test message

If errors nevertheless occur during the test phase that can only be corrected by a correction, these are side effects; it makes no sense to assign them to a change document.

In order to still be able to create an importable correction transport, there is the nice little “test message” (old: SDMT, new SMTM), which is created separately for correcting and retesting without being assigned to an ECR. Its correction transports are automatically imported during the subsequent go-live.

Go-live phase

The main advantage of a go-live phase with the mass import of tested changes is that the production system is only stressed once. If this cycle import is carried out at regular intervals (e.g. every Wednesday at 11:00), this time will be well known and the business will no longer react with panic if it is confronted with aborts due to outdated charging phases.

Goodbye

I hope that when you leave this admittedly somewhat lengthy coffee party, you will no longer have to ask the question “ChaRM, why, why, why – a brief outline of an ALM enthusiast”.