When the auditor comes twice

Nearly every major SAP customer is dreading a visit from the auditor. The regular, annual check involves randomly selecting a small, two-digit number of transport requests from the import queue of the production system for which the requirements documentation, test acceptance, and release for production implementation must be collected.

Some companies master this noble task by trying to search for documentation in e-mail inboxes. In most cases, the auditor then uncovers one or the other so-called "finding" and asks for it to be corrected by the next audit date.

In addition to the issue of traceability of changes, change management in Solution Manager naturally has many more advantages to offer: stringent and complete documentation of all changes made to the system, which is not only relevant for auditors, but can also be invaluable for your own IT department.

In addition, IT managers can gain valuable key figures from change management and massively improve the planning reliability of releases, changes and upgrades.

Incident Management

Change management is always based on incident management. Changes may be necessary because new business processes are defined, but in many cases a change is preceded by a disruption in the form of an incident.

It makes sense to record this in a company's internal service desk. Whether Solution Manager is suitable for this or not depends on the internal circumstances.

Interfaces allow integration into existing service desk tools, but the motto here is: the more intensive the form of integration, the more expensive the operation and the initial implementation project will be.

The new web interfaces have also found their way into the service desk, so that incident management can now be rolled out across the company without hesitation.

In the past, IT managers still had reservations about providing non-SAP users with a specific and old-fashioned ABAP interface and the operation of a SAPGui.

This is now no longer necessary with the new interfaces, as Incident Management hardly differs from other commercial tools in terms of ease of use.

Problem management

A new feature in Release 7.1 is problem management. In line with ITIL, an incident does not normally immediately become a change, but first becomes a problem. Only then can a change be created from a problem.

However, problem management is not only responsible for pushing incidents through, but also for identifying and adjusting structural problems before errors and reports from end users start to accumulate.

Many customers from the midmarket are already busy developing and living incident and change management in the company and will initially put problem management on the back burner.

Change Management

Change Management in Solution Manager distinguishes between normal and urgent corrections. Both types of activities are embedded in a project and linked to it.

In addition to the logical bracketing of changes, the project also fulfills another essential function. The status of the project ("In development", "Test", "Productive") controls when and into which system landscape the normal corrections are imported.

The real strength of the Solution Manager lies in the seamless integration of the transport system with the change system. A transport request can now only be created if an approved change document exists for it.

Transport requests are imported via the normal or urgent correction linked to them. E-mails from developers to SAP Basis managers telling them to import a transport are now a thing of the past.

Compared to the previous version 7.0, SAP has made a lot of enhancements here. Probably the most significant and noticeable change is the new web-enabled front end. Users can now better configure the view of a change and find their way around better than in the previous, old-fashioned CRM interface.

In addition, business add-ins have also been implemented in numerous places, enabling customers to adapt Change Management to their own needs. A classic example is the assignment of transfer order designations.

A common requirement is always that the designation cannot be changed by the user, but is specified by the system through a defined nomenclature. A new business add-in created by SAP allows this requirement to be implemented quickly and easily.

The fear of overtakers

Every person responsible for SAP Basis knows the annoying problem: import errors due to missing, dependent transports. The situation becomes explosive when more than a thousand transport requests accumulate in the import queue, waiting to go live.

In most cases, however, the entire queue is not imported with the familiar large truck for consistency reasons. Instead, individual transport orders are imported in advance as so-called overtakers.

If an older transport request is set productive one day, it can happen that working coding is reset or, even worse, table adjustments are undone.

The so-called Downgrade Protection of the Solution Manager warns IT managers of such critical situations before the import. This works by extending the classic lock management of Workbench objects. Solution Manager knows at all times which version of a transport object is currently imported in which system.

The agony of release management

Most midmarket customers often struggle to discipline their business departments toward corporate releases or at least quarterly SAP releases.

Requirements often arise spontaneously and need to be implemented all the more quickly. IT managers often regard the planning and provision of functionalities by defined deadlines as too rigid.

The normal correction is therefore only rarely used, mostly customers exclusively use the instrument of urgent correction. The urgent correction allows a transport into the productive system at any time and therefore offers the desired flexibility in contrast to the release-oriented mode of operation of the normal correction.

To create a compromise here, SAP has introduced the concept of pre-correction. Normal corrections can be made productive in advance by means of a separate approval workflow, i.e. before the actual release date.

This gives change managers and development managers the flexibility they need to deploy unplanned changes at short notice, rather than having to refer the business department to the next release window.

All in all, the use of releases is recommended in any case, if only to ensure consistent test management. If changes are continuously transported into the quality assurance system and put into production on a situational basis, then what is also imported into the production system is never tested.

Change management becomes particularly complex whenever a project landscape is to be set up in parallel to a three-system maintenance landscape. This only makes sense if additional functionalities are to be provided on certain key dates and maintenance is also to be separated systemically from project development.

A concrete example of this is the format adjustments that energy suppliers are always confronted with on April 1 and October 1. A five-system landscape, as recommended by SAP in the meantime, also requires discipline in change management.

In particular, all changes that are implemented in the maintenance landscape must also be made in the project landscape. Of course, this can be done manually, but it should not take long before one or the other transport request is lost and, in the worst case, the new release is then put into production inconsistently.

As a component of the Solution Manager, Retrofit enables all adjustments of the maintenance landscape to be imported into the project landscape in an automated way.

For customizing requests this is done by means of BC sets, for Workbench requests the coding is transferred by means of RFC connections. The whole thing only works, of course, if the relevant table entries or the Workbench artifacts have not yet been changed in the project landscape.

If a change has been made on both system landscapes, the user is presented with a splitscreen editor and the developer must decide how to handle the changes.

The retrofit process has been massively improved again in Solution Manager version 7.1 and can now be recommended without reservation. Manual reconciliation in a five-system landscape is almost impossible for larger projects. In this context, it is a pity that the retrofit functionality is only available to customers with SAP Enterprise Support.

Conclusion

Solution Manager 7.1 provides a professional tool for change and release management. Despite all this, it is important to bear in mind the classic IT saying "there is no silver bullet".

A tool can never be considered a panacea. Defining change and release processes and adapting organizational procedures is essential at first.

Q-Partners Consulting and Management assists customers in defining a roadmap, introducing processes, and implementing change and release management processes in Solution Manager, among other things.

In addition to the SAP standards, Q-Partners provides its own add-ons for change management that simplify and optimize work with urgent and normal corrections.