beteo ALM Experts Blog

Category: Change Management

  • SAP Change Impact Management – PHW Business School and beteo study

    In collaboration with the PHW Business School, Zurich, Switzerland we are conducting  a study in the IT Change Impact Management area.

    We are analyzing a specific challenges of international corporations using SAP as their corporate software globally and specifically the challenges of their IT development organization because of impacts given by system consolidaton centralization efforts.

    Fundamentally we will focus on the following issues:
    – what benefits were and are to expect from these consolidation projects?
    – What are the (intermediate)  results?
    – What new challenges are there for further developments in the centralized SAP system and development world?

    The goal of the research is to analyze trends, identify possible sources of trouble and generate possible solutions for the new challenges.

    In order to accomplish this, we will conduct expert interviews with selected contacts in person and/or on the phone. The results will be available to all interview partners. We want to actively increase the interaction between client, partners and experts in this study.

    Interested? Leave a comment in the blog or get in touch with us, studie@beteo.ch.

  • Configuration Management for SAP Customizing?

    A comprehensive configuration management is the most important basis of SAP Change and Transport Management. For ABAP code, this is accepted as general practice and supported by suitable tools. But how about configuration management for SAP customizing?

    From our experience, the major part of changes transported across a SAP system landscape are customizing changes. Not surprisingly, the persons responsible for change and transport management often keep struggling with problems after roll-outs for lack of consistently applied configuration management for_these objects. A consistent change and distribution of customizing requires stringent configuration management.
    Crucial to a cross-enterprise use and protection of SAP templates is that central and local objects are well documented, comprising all versions of their lifecycle up to the newest version.

    Comprehensive SAP configuration management all across the SAP landscape is meant to ensure overall integrity of the objects involved in SAP development, including ABAP as well as non-ABAP objects:

    • The use of well-defined standardized naming conventions clearly reveals to which organizations, areas and projects the objects belong.
    • All changes to objects, including individual customizing settings, are documented. At any time, it is obvious who is – and at which times – the owner of settings, who is entitled to make and has made changes and for which reason. This allows the changes to be tracked afterwards, which is an equivalent to versioning.
    • The documentation also includes the information as to who and what and who depends from a defined customizing setting. This is an integral factor of reasonable impact management.

    In the context of each change to the SAP landscape systems, it must be made sure that the rules listed above for practicing a comprehensive SAP configuration management are observed. This, again, requires a strict organization of the change und transport management. Naming conventions for transport objects and transports must be established, transport packages must be grouped according to their content, organizational and technical processes must be clearly defined and adhered to.

    Some projects are highly dependent on a consistent comprehensive SAP configuration management. Without this, very often the challenges to enterprise SAP organizations can hardly be mastered, especially in the context of mergers and acquisitions, strategic outsourcing projects, insourcing, and regional or global consolidations of systems. This is also true for customizing changes. However, a solid foundation as outlined above allows such projects to planned and implemented with reasonable effort and fair success. Also customizing changes of several systems can be consolidated without a negative impact.

    In addition, a comprehensive SAP configuration management allows you to permanently record the data related to transports, to the transported objects and to the result of the transport, and to evaluate them. This is comparable to using suitable analyzing tools, such as the one offered by Prospero, which have been designed to disclose the causes of problems in SAP logistic processes, or even to give a prognosis concerning their results. The same is achieved by using SAP change management data for the transport of SAP changes. In any case, SAP change and transport management has still plenty of room for improvement in complex SAP landscapes.

    Summary
    Applying a wide-ranging SAP configuration management has turned out to be the most effective method to ensure a consistent and efficient SAP change and transport management and a consistent customizing across the SAP system landscape.

    Unfortunately, the opportunity for global enterprises using large SAP systems to improve the quality and to save costs by investing in SAP change and transport management is very often not seized, because it is thought to be technically complex. But if the challenge is taken up it soon shows that the problems are more political or company-related than of a technical nature.

  • Proof of Concept – Less Risk for System Implementations

    Scoping for defined requirements and harmonized expectations
    The scoping approach allows you to define requirements, expectations and project scopes when systems, methods and processes are implemented. This results in aligned expectations, a well-designed system architecture, defined requirements as well as a structured implementation roadmap. If the roadmap is implemented in several iterations, quick wins are achieved in addition to a direct benefit to the project client and the users.

    Technically complex problems as a challenge
    If system implementations are planned in technically complex environments, in addition to the purely technical requirements that have to be met, the following questions should be addressed:

    • Is a clean system installation possible?
    • Can the solution be integrated into the existing system landscape?
    • Which is the best way to coordinate the installation and integration with the IT organization
    • Are all used technologies compatible?
    • Which interfaces are affected, and in which way?
    • Can the described functions really be implemented?
    • How does the system behave with regard to usability?
    • Will the system be accepted by the users?
    • Which are the actual costs to be faced?
    • Which technical capabilities and roles are required for the implementation?
    • Can the planned benefit really be achieved?
    • How about the capabilities of partners, manufacturers and providers, and what characterizes collaboration with them?

    The above questions are only part of the criteria which are relevant to success. To answer them, further activities are necessary. Very often, there is a great deal of uncertainty about the technical and organizational feasability of the project as well as about the time and costs involved.

    Proof of concept: minimization of risk in decision-making process
    In the context of system implementations, proof of concept (POC) equals a technical feasability study. POC can be used as a part of scoping to check for technical and organizational feasability of projects. Prior to execution, the criteria relevant to success and the subsequent steps must be clearly defined in order to ensure maximum benefit. For working out a POC, it is recommendable to implement a mock-up or a prototype comprising the core functionality. This allows to test the functions, define them accurately and involve the users in the planned project at an early stage. Proof of concept reveals which requirements can be met in which way and which functionality demand workarounds or additional solutions. Thus, time and cost expenditure for installation and integration into the existing system landscape can later be well estimated and planned in agreement with the responsible IT organization.

    Pilot pojects as a performance indicator
    Experience has shown that working with pilot projects significantly adds to success. The prototype is used in productive systems on a limited scale. There are various alternatives to proceed:

    • limited user group
    • limited functionality
    • limited process scope
    • limited and/or isolated system environment

    Working with a pilot project allows you to rather accurately pre-estimate if the system in action meets all requirements, covers the planned functionality and proves to provide the expected benefit.

    Summary

    Proof of concept allows you to find out if the implementation of a system can be technically realized, and to evaluate the capabilities of manufacturers, partners and providers as well as the quality of collaboration with them. In addition, the expected time and cost expenditure for installation and integration into the existing system landscape are made calculable and can be planned in accordance with the responsible IT organization. Prior to execution, the criteria relevant to success and the subsequent steps must be defined.

    It is recommended to create a prototype which includes the core functionality, i.e. those functions from which the greatest benefit is derived. This allows the users to be involved at an early stage of the project; as a positive result, user-friendliness and acceptance by users can be evaluated and taken into account. If the prototype is tested in the context of a pilot project with either a limited user group, limited functionality, limited process scope, or on a separate system, this will result in a realistic view of the potential of benefit. Proof of concept is used to work out facts and foundations in order to minimize the risk of making inappropriate decisions in the process of system deployment.

  • Proactive Impact Management – the basis for BTO

    Business Technology Optimization as a Challenge
    Business Technology Optimization (BTO) targets at a closer collaboration of IT and business – nothing really new, just a daily challenge to the CIO. To support SAP IT organizations in reaching this target, beteo has designed the beteo Impact Hourglass.

    beteo Impact-Sanduhr

    With the beteo Impact Hourglass, principally all objects of the business domain (in the following BD) and the technical domain (in the following TD) which are involved in changes are seen integrally, comprising system and development, as well as in relation to each other. Thus, business and IT aspects of a system can be comprehensively understood, viewed and analyzed.  Relations between objects of both areas can selectively be established, according to the object type. Due to interdependencies, effects of changes can be mapped and understood across all levels.
    Persons from business and IT who are planning a change and are in charge of apecifying the change requirements can use the beteo Impact Hourglass to have all dependent objects from BD and TD displayed. This means that all objects which might have to be changed can be identified. This view including the technical objects as well as the descriptions of the business processes and all other describing objects of the development ensures that all objects affected by the change can be managed.

    The beteo Impact Hourglass is a suitable instrument to allow all persons involved in SAP system analysis processes – from planning to implementation of changes – to proactively carry out system impact analyses and simulations. Before there are any changes to the system, all possibly affected objects are identified. Special filters can be used to have particular object types and their relations displayed. So it is easy for users of the beteo Impact Hourglass to keep track of things. What is new about the beteo Impact Hourglass is that it not only allows viewing objects related to technical implementations (results from development and testing), but also organizational processes (business processes, activities, depending organizations) and describing objects (concepts, specifications, training, testing scenarios). Changes and their effects can be exactly planned, analyzed and controlled, and potential for optimization is revealed right away.

    beteo Impact analysis
    Basically, beteo Impact Hourglass enables three types of impact analysis.

    • Concurrent Impact Analysis
      The Concurrent Impact Analysis shows how many parallel changes are potentially made per object. This facilitates identifying risks on the one hand, and the grouping changes on objects on the other hand to address them at once. In most cases it is quite helpful to know in advance that there are upcoming concurrent changes to particular objects.
    • Dependency Impact Analysis
      The Dependency Impact Analysis shows which objects of the selected object type across the whole system and the development documentation might be directly affected by a particular change.
    • Interference Impact Analysis
      Starting from an object, which for example has been identified through Dependency Impact Analysis, the Interference Impact Analysis finds out which superordinate objects not directly connected to the same change are additionally affected. This might reveal processes using an object which has been indirectly affected by a change to another business process and therefore has to be tested after the change, because technically the same functions and settings are used in the system.

    Versioned documentation of Business Domain (BD), Technical Domain (TD) and related objects of system development

    The BD mainly includes organizational objects and objects resulting from describing system development measures. With the beteo Impact Hourglass, these objects and their relations can be documented and to each of them a lifecycle can be assigned. This ensures that the describing, organizational objects for each change request are identified and kept updated. Change requests not only refer to technical objects, but also to business objects and to all supporting objects which are created and customized in the context of the development process.

    The versioned documentation of the objects of business process management makes it easier to understand the evolution of all objects. Dependencies on real and describing business domain and technical objects and interdependencies between these objects are identified. Changes to programs and customizing activities can be presented and understood comprehensively and in relation to each other.

    Summary
     From the early stage of planning a change, before it is actually executed, the beteo Impact Hourglass provides a clear and complete conception of its effects and the possibility of evaluating them. This allows all types Impact Analyses to be proactively carried out and subsequently be tracked in the project phase.  Decisions in the context of practicability, planning of implementation – particularly of parallel upcoming changes – and project management and controlling can largely be improved and simplified.
    There are a number of useful tools available for the reactive Impact Analysis applied to objects of the technical domain (TD), such as IntelliCorp´s LiveCompare, Panaya Inc.´s Panaya, IBIS´ RBE Plus and Hewlett Packard´s Universal CMDB. However, they basically support the programmer and not as much the business analyst. The beteo Impact Hourglass integrates business processes into impact analysis and allows enterprises to benefit from Business Technology Optimization (BTO).

  • Lifecycle Management – no Pain, no Gain!

    Successful IT Planning & Control must include not only IT Service Management and Project & Portfolio Management, but also Application Lifecycle Management in order to be of lasting benefit. The following illustration by Gartner clearly demonstrates this.

    IT Planning- & Controlling

    Considering the support of the various areas and, above all, of the interfaces between them, it is obvious that helpful methods and high-quality tools for Service Development (Project & Portfolio Management, Design, Development and Testing) and Service Delivery (IT Service Management) are available and in use.

    On the other hand, tools and methods supporting the interfaces between the different areas and to Application Lifecycle Management in general seem to be rather scarce.

    At the same time, Application Lifecycle Management promises attractive benefits like:

    • a noticeable increase in developer productivity
    • “best practice” in development and service roll-out
    • a clear focus of developers on business instead of technical requirements
    • largely improved collaboration between development and business area
    • improved time-to-market by repeatable and partly automated processes and generally improved resource planning

    The software manufacturers priding oneself on their solutions that are supposed to reduce either project or operating costs are getting a bore. To them, the direct interdependencies between business and development are rarely of central concern. Statements as to the benefit of the solutions usually refer to either of the two aspects, and very often, improvement on one side is combined with a dramatic rise of costs on the other. This is why this topic is often referred to as the general “IT dilemma”.

    A relevant issue of “good” software engineering is a comprehensive requirements management, covering diverse influencing parameters. However, there are few cases where with each requirement all depending lifecycle objects are taken into account right from the start. But without this, recognizing competing requirements as what they are is impossible. What is more, hardly ever consideration is given to changes that are being implemented. Thorough IT Planning and Control across all fields of activities including their interfaces also comprises referencing and versioning of the describing, organizational and technical objects and their relation to one another. IT Service, and IT as a whole, is regarded and referred to as a complete system.

    The same is often true for business: IT Service Management (ITSM) includes Trouble Tickets without a clear reference to the concerned objects in Application Lifecycle. Information about the newest changes is not passed on to either the present development or the planned projects. This results in duplication, inconsistencies and considerable effort put in subsequent coordination. Any kind of re-use following the change or the newest project release is moving beyond reach.

    “Comprehensive” process frameworks and methods such as ITIL, PRINCE2, PMI and COBIT or SOX audit and compliance standards are just as unsuitable to overcome the “IT dilemma”, because they all disregard the interdependencies between the Service Lifecycle objects, meaning between processes, services and all technical objects. Although it is the intent and purpose of all these standards to diminish risks, I doubt if they can half-way reach this target without taking these dependencies into account.

    To me, the only solution in sight is introducing a professional method- and tool-supported Application Lifecycle Management.

  • Lifecycle Management – a Nightmare?

    Andrea User and Daniel Eveloper both work in the same enterprise. When they meet in the cafeteria, the say hello. That has been all, so far. Today, they will both attend the same meeting. They still don´t know that this will have an impact on their lives.

    Andrea and Daniel are sitting in conference room 3.22
    Andrea works in the human resources department and is in charge of employee training courses. Since long she has been familiar with this topic before she started to work for the company 6 months ago. She has a pretty clear conception of how the staff-related processes are to be mapped in the ERP system (Enterprise Resource Planning Systems). And she knows, which extensions and changes remain to be added. This is why she had invited Daniel. He has been recommended to her by the CIO.

    Daniel is very experienced in IT and has worked for the company for a long time, principally engaged in the development of different ERP systems. He has been involved in a variety of release changes, system roll-outs and consolidations and – thanks to his good constitution – has survived, more or less free of damage.

    And here is Andrea, another quite euphoric program manager who needs to be brought back to earth. What the heck is going on in the heads of these people? The “small” extension unfortunately requires a new service pack which is planned to be installed next summer, not before two thorough testing cycles will have been carried out on the development and pre-production systems. Experience has shown that deploying, configuring and testing this extension will take another two or three months – provided everything will pass off smoothly.

    Andrea’s “small” change involves customizing activities for one of the applications. This makes it worse. The developer of this application has quit for a better job – the company´s advanced training offerings were rather sparse. Today, nobody knows how this application really works and – making it even worse – who has access to its various interfaces. A charming smile on his face, trying to strike a friendly note, he said something like “never touch a running system”. In a way, he felt sorry for having to thoroughly disillusion this nice woman.

    Andrea, feeling her sweaty hands, is looking at her alarm-clock on her night table, showing 06.55 hrs. It takes her a couple of moments to realize, relieved, that she was just awaking from a heavy nightmare. A completely realistic dream. Very slowly, she is calming down.

    Two hours later, Andrea and Daniel are – really – sitting in conference room 3.22
    Andrea put forward her wish as to the “small” change concerning the ERP extension, and Daniel immediately knows what to do.

    He takes a seat next to Andrea and starts his notebook. The tool he opens seems to display the system landscape. Right away, Andrea recognizes where her system is mapped. But there is another thing she does not see at first sight: the information about the systems that has been collected and related to one another by this tool. But this is not really a problem. Daniel knows which data can be recalled.

    After recognizing that the change implies installing a new service pack, he starts an impact analysis for it. This involves listing all objects affected by the change and makes the related processes visible. Since there are quite a lot of processes that have to be changed repeatedly, test scripts have been produced for them long ago. Now, there are only two new processes listed which require a new test script, and it will be no problem to have them available by the time the system will be upgraded in a week. The request for the script he has just issued. When he is doing the same for the desired extension, he realizes that three new processes are implemented. Andrea is quite surprised about Daniel being so well acquainted with her HR topics.

    The effect of the necessary change on the customized application is visible right away. The interface which must be extended is only used by one evaluation tool. Testing this interface and if necessary changing it will not take longer than 10 minutes. Without delay, he issues the order directly to the developer, which not only includes the development activities, but also testing as well es completing the documentation correspondingly.

    The meeting did not take the full time Andrea had planned for it. So there is some time left for her and Daniel to have a cup of coffee together. Andrea has decided to thank the CIO for his recommendation.

  • The Cycle Above the Development Cycle

    Nowadays, software is used in virtually all enterprises. Software is continuously extended, changed or deactivated – as a result of changing business requirements, enhanced functionality of commercial software releases, or subsequent to bug-fixing. Over the years, typical phases, methods and techniques of the development cycle have established: project portfolio management techniques, software development methods and techniques, models for carrying out projects, IT service management and quality requirements.

    Software Development Cycle

    Software is code and all its descriptive objects
    In order to handle software applications, the user needs instructions, i.e. a user manual. Developers need a technical documentation, division managers need a process description, and the business or the outsourcing partner needs a business manual. For gach phase of a software development cycle, there are documents which are essential to particular user groups. Project plan and project documentation which influence the development of the software most directly, provide valuable information about the software. Some software components are dependent on system environments. Particular server and client components must be installed along with the software.

    As a result, even the most simple tool becomes part of a highly complex network of software and descriptive objects which are linked to many other objects.

    Managing the Software’s Lifecycle

    To the user, software is just a means to an end, a tool which temporarily facilitates the carrying out of particular tasks within the business process. In its lifecycle, the software passes through multiple development cycles (fig. 1) until it is replaced by a completely different tool (fig. 2). Every single software or software change is designed in line with defined requirements, or compared with other software, and then, if found suitable, developed and implemented.

    Software Development Cycle

    While being used, software is maintained, improved, and eventually deactivated. Some vendors offer tools to record all circumstances which determine the lifecycle of a software component as a complex system. The suitable instrument to this end is the Software Lifecycle Management. It offers a series of methods, techniques and supported by tools like advanced CMDB solutions and workflow engines.

    Multiple views in a holistic approach
    Software changes permanently. Its functionality is extended, the entry of data is facilitated, tasks are diversified. Existing software must be migrated, changes must be activated. Finally, a new version emerges from the amended former software version, or from part of it. For this new version, new instructions, new testing, and a new configuration are needed. Parts of the old software component continue to exist in the form of functions or modules which have been integrated in the new version.

    Software Development Cycle

    To reduce the complexity analyzing software systems during the change process tools allowing to take different perspectives have become a necessity. Depending on diverse requirements and tasks, for software environments we must be able to look at all software or descriptive objects and their relationships from a business, a development or a supplier view.

    Summary
    Development for sustainable systems requires a multidimensional look beyond the single development cycle. The overall software lifecycle, the cycle above the development cycle must be managed. Unidimensional, snapshot-like views as offered by many software techniques, do not allow an integrated Software Lifecycle Management. The tools for building up lifecycle management environments allowing to all interdependencies across the entire cycle are available, but still rarely used.

    Once in place lifecycle management systems keep even complex software systems manageable, customizable and flexibly adaptable.

  • SAP Change and Transport Management – Efficient and Safe

    In order to handle the various problems resulting from changes to a SAP landscape, it is common use to spend of lot of money on experts rushing to fix them. But there is a better alternative: Focussing on a tool-supported, automated SAP change and transport management environment, including measures to ensure consistency, can eliminate the cause of the failures once and for all. There is a couple of measures to be taken: organizational measures, technical transport validation, and consistency-ensuring measures with horizontal and vertical effects.

    Basic Organizational Measures

    • Definition, digitalization of the end-to-end transport process or of the whole change process
      • ensuring that no transport request (technical change) is issued without change request (organizational change)
      • diversification of the transport types so that for projects and releases the suitable transport can be selected
    • Replacing manual execution by automatic technical implementations
      • no inconsistencies due to missing and/or incorrect interactions
      • release processes are validated, executed and documented
      • tedious routine tasks are automated
    • Also operational customizing must be subject to a controlled change management process.
    • Creating development guidelines and naming conventions to support change and transport management
      • changes can be checked for consistency with respect to form and – in parts – content
    • Definition of a company template – particularly useful if there are more than one development client

    Validation of Transports

    • Early detection and exclusion of risky objects from transport, e.g. NRIV objects (SAP number ranges)
    • Formal validation of the transport objects with regard to project/support release and organizational unit they belong to
      • ensuring that a transport request contains only related changes or changes for specific areas so that parallel project activities are not compromised
      • code inspection based on system engineering, validation of the transport object´s affiliation
      • ensuring that the development guidelines are followed and verifying – on the basis of naming conventions – that the code is related to one single business area
    • Verifying, for example by running test imports, if all referenced objects which are not yet on the target system are transported
    • Object-related customizing documentation such as owner, change, changed keys, including customizing versioning
      • complete documentation, complete history (comprehensive life cycle of the customizing settings), traceability and audit trail

    General Consistency Measures

    • Content-related division of transport requests of multiple projects or maintenance requests
      • consistent, project-oriented deployment; interdependencies of objects are understood, taken into account and controlled
      • autonomy of projects in terms of change transport
    • Opening and closing of the systems and clients should – whenever possible – be subject to an automated change process
      • system-based monitoring of the change; it can be tracked at any time, when system changes were possible.

    Horizontal Consistency-Ensuring Measures

    • Ensuring the correct sequence when transporting customizing changes, workbench transport objects (programs and data structures), considering dependencies between workbench and customizing objects with regard to overtaking issues.
      • No inconsistencies on target systems resulting from early arrival of objects (overtaker issues)
    • Rollback functionalities and automated updating of systems and clients based on transport history (system or client copy) when systems are re-initialized, added or when changes need to be reset.
      • Full transparency as to which transport orders apply to which system or client level. Executed transport orders can be undone at any time when unexpected problem show up or lests are not successful.

    Vertical Consistency-Ensuring Measures

    • Ensuring the correct installation order of all changes (transport requests from all SAP component systems such as SAP CRM, ERP, BW for ABAP and customizing, Java packages, portal configurations) before they are further processed on the target system. This includes all changes that have to be installed together, not by themselves via different SAP Transport Systems (SAP TMS).
      • all changes belonging to a group are completely installed before the next organizational step is released
    • Synchronizing and locking of company template customizing
      • no inconsistent company templates in target system landscapes
      • vertical distribution of these settings to all SAP component systems

      • Horizontale und vertikale Konsistenzsicherung


    Summary
    Many big SAP organizations still practice a reactive method of solving the problems resulting from change transport. The enormous costs seem to be accepted as inherent to the process. But we have seen that applying a clean automated process including consistency-ensuring measures can save a lot of money and puts aside large parts of the work involved.

    Interestingly, not the unnecessary and incalculable costs and effort motivate more and more enterprises to improve their SAP change and transport management, but the requirements which result from compliance rules and which, SAP IT, too, is faced with. Thanks to the transparency and traceability of the processes and to comprehensive documentation, SAP change and transport management, if stringently applied and supported by suitable tools, will supply these needs on the fly.

  • SAP Change Control Reduces Risk and Costs

    Nothing is more constant than change – this is also true for SAP systems. At least once a week, numerous changes of support or project organizations are moved into system landscapes and more or less automatically transported to production servers. And the more complex the solution landscape is, the higher the risk that something goes wrong.

    Consistent, tool-supported SAP Change Control helps to implement, control and largely automate the SAP change process. To every SAP customer, a secure way of executing auto-deployment of SAP transports, for ABAP as well as non-ABAP changes, across the SAP landscape is available, but hardly ever it is consistently made use of. Instead, thousands of system components break down every week, and the resulting problems must ex post be analyzed and solved by system specialists.

    It is true that compared to other commercial software systems, SAP systems offer quite convenient possibilities to implement changes across system landscapes. Unless there are parallel changes implemented from support and projects and the system landscape is very complex, SAP tools supporting change transport will do a good job. They allow transport routes to be defined across the system, transport requests to be released and change packages to be distributed and installed across the system, including defined steps of validation. So far, so good.

    But this rather sophisticated system has its limits. First, the process of rolling out changes is quite error-prone. Second, the compliance rules are not completely met. And third, the system is susceptible to inconsistencies.

    • Changes are more or less simultaneously distributed across the solution landscape via transport processes. Differences in runtime speed in the various phases of distribution and verification can cause time-dependent changes to be implemented in the wrong order.
    • There might be conflicting changes from different projects.
    • Manual changes might be executed at the wrong time.
    • Customizing changes are not versioned and have no lock mechanism. It happens easily that they are unintentionally overwritten.
    • Once changes and change sequences have been executed, they cannot easily be executed for a second time.

    There are ways to proactively handle these problems with a reasonable effort. Using SAP Change Control with suitable tools and techniques implies the following:

    • For all changes to the solution landscape, there is a change request and an approval. There is no transport request (technical change) without change request (organizational change). All changes are documented.
    • Changes are grouped in packages according to projects and areas of use so that the transport is unlikely to cause conflicts with the system environment. The projects have more autonomy concerning transport.
    • Transport and routine tasks are automatically executed in the correct order, including comprehensive measures to ensure consistency.
    • Potential errors caused by changes that are transported faster than others or by unintentional overwriting are recognized in time and remedied proactively. This also applies to packages transporting different changes from all kinds of SAP or non-SAP systems, such as changes SAP CRM, ERP, or BW objects, customizing, Java packages, portal configurations – and to many interdependent components that must be changed.
    • Entries into the Change Control documentation are made automatically.
    • Change processes are strictly followed.
    • All changes are executed in a secure way, rollback functions are available wherever possible. Changes can be run repeatedly.
    • There is a complete audit trail for all changes.

    Summary
    SAP Change Management cannot automatically be scaled when the system landscape changes. But applying SAP Change Control techniques and tools most stringently will help SAP customers to massively reduce the risks and to largely avoid extra work and stress when distributing changes in complex system landscapes.

  • beteo SAP Change Control Miniguide

    The new SAP Change Control Miniguide below has just been posted on our beteo website. Additions and feedback are welcome!

    SAP Change and Transport Management Tools

    Product Vendor Modules
    Conigma Suite Galileo Group Change and Transport Management
    Newmerix Automate! newmerix Change and Transport Management
    PPM HP Change and Transport Management
    Rev-Trac Revelation Change and Transport Management
    SAP Solution Manager SAP Change and Transport Management
    TransportManager REALTECH Change and Transport Management

    Additional ALM information

Powered by