beteo ALM Experts Blog

Category: SAP

  • Fresh from SAP TechEd Las Vegas: Panaya 3.2

    At SAP’s TechEd conference, the new releases of Panaya Support Automation 3.2 and Panaya Upgrade Automation 3.2 have been announced.

    Panaya 3.2 Overview

    Upgrade Automation is the fast and accurate way to control the impact of SAP projects and SAP changes in general. It automatically analyzes SAP systems and changes and provides online services to answer key questions such as:

    •    What errors will occur without intervention?
    •    How can they be prevented?
    •    What exactly needs be tested?
    •    What are the most important risks?

    Support Automation analyzes functional changes to SAP system before they are released. Using analysis technology based on a unique algoritm, Panaya evaluates changes in the context of the complex interdependencies of SAP systems. For every change, it automatically creates test plans, classifies changes based on risk, and alerts managers and other stakeholders and informs about risks.

    Upgraded and new Functions in Release 3.2

    Root Cause Analysis (New Feature for Support Automation)
    If all of a sudden something is not working well in your production system, your team could spend hours finding the culprit. Or, you could simply launch Panaya’s new Root Cause Analysis for SAP, enter the transaction that is misbehaving, and you’ll immediately see the primary suspects: all the recent changes that have actually impacted this transaction.

    Real time impact analysis of code changes (New Feature for Support Automation)
    Change any ABAP program, during an upgrade project or during maintenance, and Panaya immediately tells you what is the impact and what must be tested.

    Comprehensive Project Plan for SAP Upgrades (New Feature for Upgrade Automation)
    This is one of the most powerful features: Now Panaya generates a comprehensive project plan for your upgrade, including sensible defaults for effort and people allocation to tasks. The plan can be exported into Microsoft Project

    Completely Redesigned User Interface (Enhanced Feature for Both Products)
    Since we added so many new features, they needed a new home.
    The application is now logically divided into SAP Upgrade, Impact Analysis, Root Cause Analysis, and Transport History

    Code Highlighting (New Feature for Upgrade Automation)
    When opening a program source from reports, Panaya will automatically highlight the upgrade problems in your code. For example: In the “Obsolete Functions” report – Click a program name to view its code and Panaya will highlight all the places in the code that use this function.

    Transport History (New Feature for Support Automation)
    If you need to track changes to your SAP system for compliance, analysis, or other reasons, Panaya keeps the complete transport information.

    Usage of User Exits (New Feature for Both Products)
    Now it is easy to see all the transactions that are using a user exit using a new “Drill Down” report

    Impact Overview Page (Enhanced Feature for Support Automation)
    Now the impact overview page displays the custom transactions and all the Batch or Interface transactions. This replaces the previous functionality

    Cloned Program Analysis (Enhanced Feature for Upgrade Automation)
    An improved algorithm now finds even more cloned programs that were especially difficult to track.

    Availability (Both Products)
    Since Panaya is software as a service, there’s no need to upgrade any software. The capabilities are available immediately to all customers.

    Conclusion

    Changes to SAP systems often entail substantial additional expense and undesirable effects for SAP organizations. Reference upgrade projects show that consistent, pragmatic impact analysis in a SAP Change and Transport Management process can reduce efforts by more than 30%. Risk gets massively reduced and surprises after change implementation eliminated. And beteo partner Panaya’s SaaS solutions can be implemented with little effort and with no or limited adjustments to the system.

  • How not to Disclose a Secret – HP´s ERP4IT

    Whereas ERP is a synonym for software-supported Enterprise Planning and Controlling, ERP4IT stands for software-supported IT Planning and Controlling (ITPC).

    Those who are looking for solutions will without much doubt check out the ERP4IT offerings of the leading ERP system manufacturer SAP. SAP seems to be the only ERP software vendor for managing one´s own customer IT organization and IT products through SAP Solution Manager. Theoretically In view of the special requirements of IT planning and controlling frameworks and standards, SAP scores quite well. But judging the Patchwork of SAP Solution Manager from real ERP4IT requirements´perspective, which includes comprehensive application lifecycle management, the SAP Solution Manager will at most suit to support the management of SAP customizing.

    While in general the market seems to focus on trying to define the IT processes mainly by means of frameworks and standards. Because of the missing tool support or incomplete offering several large SAP users have already started their own projects to tackle diverse ERP4IT challenges building their own solutions. Like that already more than ten years ago, the first management platforms targeting SAP change und configuration management using ABAP and workflows have been built.

    Meanwhile, in the context of digitization and automation of IT processes including testing, Mercury products had provided the logical supplement of the above mentioned basic ”ERP4IT“ platforms. HP acquired and integrated these products into their portfolio.

    HP today is capable of offering a comprehensive solution „HP Best Technology for Optimization“ (HP BTO). HP BTO is a very useful compilation of software components. In suitable combinations it can fully meet the requirements for a real solution management solution, i.e. a comprehensive Application Lifecycle Management system, as well as those of an SAP ERP4IT system, even more so if combined with some basic functionalities of SAP Solution Manager.

    However, HP seems to primarily promote its software in the form of individual products, missing the opportunity of offering the integrated solution as HP BTO ERP4IT to customers more emphatically. Should the market success of the separate software components be an obstacle to a broad positioning of the comprehensive HP BTO solution? Too bad for IT organizations which are (still) left beyond the reach of this enormous potential value.

  • E2E SAP Testing – Halfway Under Control?

    In many blogs, we have discussed the deficiencies in SAP testing. Changes to an existing system are the order of the day. Again and again, errors are corrected, customizing and programs must be adapted, new functions are rolled out. Also, technical changes as hot fixes and service packs must be installed, as well as upgrades. In view of the large number of changes, problems with testing is not want you really want. But most SAP customers have come to terms with it, solving retroactively the problems involved with rolling out badly or incompletely tested changes – amidst the applause of the business. This is quite an effort, but still considered a more sensible approach than testing the whole software system.

    Everyone will agree that this is not the approach we want. Fortunately, specialized consulting companies such as FocusFrame as well as manufacturers of testing software such as HP,  Panaya, IntelliCorp, IBIS and above all SAP have taken this to heart. However, we are still far from a real end-to-end (E2E) testing or quality process starting right from the business requirements level, but at least you can start a continuous E2E testing process covering all changes as soon as the transport of a SAP change request is due. And this is already a great benefit.

    What Does This Mean in Detail?

    SAP E2E testing process and tools

    • The first step is to analyze which SAP transactions and programs are affected by the change, on the basis of the changes due for transport and of the system or a model of it. This step is mostly referred to as Change Impact Testing. This task is supported by specialized products like HP Change Impact Testing (CIT) for SAP, SAP Test Automation and Optimization (SAP TAO) as well as IntelliCorp LiveCompare. An exciting alternative is Panaya Inc.´s pure SaaS solution. Using this service, the SAP user does not even have to install any software.
    • Once the involved transactions are known, it must be found out which testing scenarios are necessary. For this step, too, there is reasonable technical support now. As a result, the testing scenarios are identified and together with the underlying test script made available to the test management tool. This is accomplished by using SAP Test Automization and Optimization in combination with SAP Quality Center by HP.
    • In spite of above system support and test szenario reduction, the testing scenarios should – due to their large number – pass another filter. This step is widely referred to as Risk Based Testing. The point here is to reduce the number of tests to be executed to the really relevant ones. This step is supported by SAP TAO and, particularly, by SAP Quality Center by HP.
    • Then, the test management tool executes the filtered tests automatically. The results are evaluated and, if necessary, the defect management process is started and monitored. This task is assumed by SAP Quality Center by HP in combination with HP Quick Test Pro.

    From Transport Packet-to-End-Testing up to real E2E Testing
    All this sounds quite simple and logical. In practice, however, it is quite a challenge to set up and operate such an environment. As a methodologist, however, you will consider this „reactive“ approach still suboptimal as the above „E2E“ quality process, instead of starting from the beginning, meaning the requirements management, is initiated not before the changes have been executed and ready for transport. Information about the effects of changes is known to be useful on starting the projects from the project portfolio management, supporting the business analyst as well as the developers and the test team. SAP has become aware of this and is working on a solution using the new Business Process Change Analyzer (SAP BPCA) to enable real E2E quality management.

    Implementing SAP E2E testing correctly will change the poor SAP E2E quality mangement into a model for other commercial software solutions addressing quality management. The benefit of a consistent, comprehensive testing for SAP landscapes can hardly be overestimated. The reduced number of system breakdowns after the weekly roll-out of changes justifies the investment in this area – as every head of a SAP Competence Center will readily confirm. The somewhat less spectacular quality improvement along with the cost and risk reduction reached in the medium term, will provide a considerable profit by introducing a SAP E2E testing project in the context of an application lifecycle management initiative.

  • SAP Solution Manager – More Than Just SAP Marketing?

    As its name suggests, the SAP Solution Manager is designed to provide support for the management of SAP customer implementations. Does it perform this task? Or is it just one of SAP´s marketing instruments?

    Missing Functions for Complex System Landscapes
    When discussing the pros and cons of SAP Solution Manager, we must first of all give SAP credit for being one of the few vendors providing a solution management platform at all.

    But taking a closer look at the various components of SAP Solution Manager, what you see is rather some kind of patch work. It seems that many functions have been integrated just pro forma to comply with qualifications typically demanded by the market in RFPs (request for proposal)?

    Some of the  components, though existing, are only in parts or insufficiently integrated. In order to efficiently manage customer implementations, additional office solutions are needed. This, however, seems to be useful only for small-scale SAP implementations. More complex organizational structures or heterogenous SAP landscapes imply additional dependencies that prevent these solutions from answering the purpose.

    Unfortunately, in many SAP Solution Manager implementations the focus is not on what the customer actually requires, but on those functions offered by SAP Solution Manager by default.

    Expectation towards an Efficiently Working SAP Solution Management Platform
    Much of what we expect from a SAP solution management is comparable to what a comprehensive application lifecycle platform would offer. It is particularly important that the complete service lifecycle of the SAP implementation can be managed, including all documentary, organizational and technical interdependences, covering all phases from the generation of the first process implementations to extensions and error recovery, and up to process deactivation.

    Also, the complete cost and activity accounting (integrated financial management) should be made transparent all across the lifecycle of the solution. This is the only way to set up a cost-benefit equation for a customer implementation.

    The structure of the solution should provide subdivisions according to the Business Services (BS) it supports so that these services can be aligned with the overall goal of the enterprise. This results in an effective service portfolio management (SPM) and ensures the targeted value of the implementation. A working service portfolio management makes evident that in the context of a consistent service orientation, IT service management (ITSM) and project portfolio management (PPM) can no longer be regarded as isolated elements.

    In addition, advanced solution management applications should integrate consistency-ensuring measures directly into the processes in order to minimize risks. Wherever possible, automation should be favored, particularly for performing organizational tasks. This can be reached by digitization or coding.

    The following example clarifies above statement. Digitization prevents overtaker problems during transports (consistency-ensuring measures), because the transports are directly carried out (automation) upon release (organizational task).

    By the way: consistency-ensuring measures are particularly important for SAP customers using company templates when changes are transported: Applying Business Configuration Sets (BC Sets) or generally transporting SAP customizing changes can result in inconsistencies between templates and distributed implementations, because customizing of the involved systems can be changed at any time. Offering customizing synchronization and locking mechanisms, SAP Solution Manager provides a solution for this problem which unfortunately is not very well known.

    Summary
    It is crucial to success that the customer has a clear picture of all relevant IT processes involved in SAP solution management. This means that the focus must not be on the solution management tool, but on the risks that are addressed and minimized by Solution Manager. From this, we can directly derive the demands that should be placed on solution management.

  • Software Archeology – how to Successfully Change SAP Releases

    16th century. The eyes of an archeologist are scanning a field. He is asking himself where he should start digging. In his life, he still has a few years left. Which area would, from his experience, hold a chance for him to make a discovery? Then he notices a tree. For growing, it would need nutrients, so underneath there might be something. This is what he knows from experience.

    When he starts digging, he hits on a small house of a rather poor family. Disappointed, he gives up.
    200 years later, a larger excavation project is started. The settlement is found to be the most important source of information about ancient times.

    SAP
    Those who know me are acquainted with my writing style exposing my affinity to exaggerate. Let´s take a typical SAP project, a release upgrade, for example. Doesn´t differ that much from the story of the unlucky archeologist, I think. In the beginning, you often know little about a system. Everything seems to be underground. You are asking yourself how to address the release change, and on the basis of which information you might dare a prognosis. What will happen during the project? If you are lucky, the consultant experts have a fair knowledge of the system and the processes implemented on them. If not, the project will almost typically go beyond its scope on the two axes expenditure of time and budget planning. As some of the most important project phases, such as testing and training of the end user, are neglected in favour of the implementation phase, you will be faced with a quality problem. This, in turn, will have an impact on the third axis, the user acceptance.

    The way out
    Typical SAP projects, such as upgrades, are planned according to the waterfall principle. But one important step of this method is massively neglected: The requirements analysis, also known as gap analysis – in other words, the question, „How did SAP influence OUR particular standard?” If you want to comprehensively answer this simple question with reference to a SAP landscape, the only solution to the “problem” of such massive analysis is its automation.

    How can you access best quality and complete information in the shortest possible time?
    There are quite a number of vendors who offer analysis tools, from SAP Consulting via RBE up to IntelliCorp. Each of these tools focuses on a particular aspect and therefore has its individual potency.

    IntelliCorp´s Assessor Template for SAP Upgrades addresses the problem on a rather broad basis. The tool offers a variety of fully automated analysis workflows. Within a few days, three on average, it provides a wide range of material for use in the context of a detailed planning of the upgrade project. As a side-effect, the result provides a basis for the implementation team to operate on. Its high degree of flexibility makes it a tool which is suitable for all SAP applications, including commercial solutions, integration of third-party software or own namespaces in workbench.

    About the author: Fritz Mosonyi is senior consultant and division manager for SAP tools at beteo partner SPP Wien.

  • 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.

  • 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