Category: SAP ALM

SAP Application Lifecycle Management – change control, Solution Manager, transport, upgrade

  • Is the SAP Enhancement Package Framework the Hoped-For “Cure-All”?

    Is the SAP Enhancement Package Framework the hoped-for “cure-all”?

    The concept of Enhancement Packages (Enhancement Packages Framework, short EhPs) is simply brilliant. However, when one considers how long SAP — as the standard software supplier for business software par excellence — took to establish this software logistics discipline, one can no longer speak of brilliance. What the absence of this framework has cost customers until now, each customer should calculate for themselves.

    From a software logistics perspective, SAP has finally done its homework, but again (as in my blog on Solution Manager) only with a focus on the standard software. The EhPs unfortunately still do not address customer implementations. Impact analyses as provided by Intellicorp and Panaya for the largest investments of an SAP implementation are non-existent.

    What does this mean for SAP customers who have already made the step to EhPs (prerequisite: SAP NetWeaver 7.0)? For those not yet on SAP NW 7.0, the conventional SAP upgrade is unfortunately still a prerequisite.

    Technical basis: The corresponding EhPs can be applied in a time-neutral manner, meaning the physical effort remains, but the direct temporal dependency of the business-technical follow-up work (business-technical application of EhPs) is decoupled.

    Business-technical: In a first step (preparation), all additional requirements for new functionalities delivered by SAP in the EhP must be collected. Based on these, a concurrent analysis of the configured base (ALM – investment protection) and an evaluation of the new functionality on SAP’s demo systems must be performed. Only through this analysis can the scope of business-technical EhP application be determined.

    The activation of individual Business Switches makes the impact analysis even more challenging: now it must really be evaluated which “transaction areas” are actually used in the organization. The consequences you’ve probably already experienced: with every upgrade or now “business-technical application of EhPs,” the entire implemented application portfolio is rebuilt again, so that the new technical functions can be assured on the basis of the old technical functionality — instead of actively managing only the delta between old and new functionality.

    Conclusion: The time-consuming identification, implementation and testing of new business content remains the same, if not increased by additional complexity. Due to the newly available business functionality, concurrent impact analysis becomes ever more complex and therefore more time-consuming. The temporal decoupling of the technical application of EhPs can save time. However, this time saving should at least be reinvested in impact analysis, in order not to risk production shutdowns.

    🇩🇪 Diesen Beitrag auf Deutsch lesen

  • SAP Enhancement Packages: Options and Limits

    Customers often ask whether SAP Enhancement Packages (SAP EHP) can simply be applied. The expectation behind SAP EHP is very high: SAP Enhancement Packages are supposed to ensure the flexibility customers love in the SAP standard during upgrades while simultaneously reducing effort.

    This expectation is reflected in SAP’s marketing message, which positions Enhancement Packages as the solution for all customers who want to avoid SAP upgrades.

    But let the facts speak: What can Enhancement Packages do, and what can they not?

    SAP Enhancement Packages are functionality packages. Their advantages lie primarily in: upgrades of delivered functionalities (Business Functions) — with less effort and lower maintenance costs than classic SAP upgrades.

    However, an SAP Enhancement Package can only deliver these advantages in a limited context: when no or very few customer developments/modifications are present. By customer developments/modifications I mean ABAP changes, modifications to modules/classes, customer-specific transactions/programs, etc. — everything that must accordingly be managed in the CIM model as customer-specific software artifacts.

    What Enhancement Packages explicitly cannot do:

    • Establish clear responsibilities back to customer-specific software artifacts (“separation of concerns”)
    • Identify/version-manage customer-specific software artifacts (customizing and developments) that are in classic source SAP objects, and especially test their correct “impact”

    Conclusion: When we put existing customer implementations in relation to the SAP standard — which customer can seriously do without their customer-specific, grown SAP “customizing” or “enhancements”? In practice, this is truly not easy. It becomes clear: the technical possibilities of Enhancement Packages set clear limits in terms of flexibility and customer-specific adaptation.

    Nevertheless, SAP Enhancement Packages are a real option for SAP customers who want to move forward. But they must be understood for what they are — one upgrade option among many.

    🇩🇪 Diesen Beitrag auf Deutsch lesen

  • Is the SAP Enhancement Package Framework the Hoped-for Cure-All?

    The concept of Enhancement Packages (Enhancement Package Framework, abbreviated EhPs) is simply brilliant. However, considering how long SAP — the standard software provider for business software par excellence — took to establish this software logistics discipline, we can no longer speak of brilliance. What the absence of this framework has cost customers up to now is something every customer should calculate for themselves.

    From a software logistics perspective, SAP has finally done its homework — but again only with a focus on standard software. The EhPs unfortunately still do not apply to customer implementations. Impact analyses, such as those provided by Intellicorp and Panaya for the largest investments in an SAP implementation, are nonexistent.

    What does this mean for SAP customers who have already made the move to EhPs (prerequisite: SAP NetWeaver 7.0)? For those not yet on SAP NW 7.0, the conventional SAP upgrade remains a prerequisite.

    Technical basis: The corresponding EhPs can be deployed time-neutrally, meaning the physical effort remains, but the direct temporal dependency on business-technical follow-up work is decoupled.

    Business technical: In a first step (preparation), all additional requirements for new functionality delivered by SAP in the EhP must be collected. Based on these, a competing analysis of the configured baseline (ALM — investment protection) must be carried out, along with an evaluation of new functionality. Only through this analysis can the impact of a business-technical EhP deployment be determined. Activating individual business switches makes the impact analysis even more demanding — it is now necessary to evaluate which transaction areas are actually used in the organization.

    Conclusion: The time-consuming determination, implementation and testing of new business functionality remains the same, if not increased by additional complexity. The temporal decoupling of the technical EhP deployment may save time — but this time savings should at minimum be reinvested in impact analysis to avoid the risk of production outages.

    🇩🇪 Diesen Beitrag auf Deutsch lesen

  • How Tool-Based SAP Change Control Helps SAP Customers

    HP PPM in combination with beteo’s SAP Change Control Current Practice can help SAP customers to reduce cost and risk in the SAP change process. This article summarizes the potential benefits, challenges and approaches of implementing a SAP change control solution based on HP PPM and beteo SAP Change Control Current Practice, as well as illustrating a sample customer reference.

    Potential Benefits of a Tool-Based SAP Change Control Solution:

    Reducing cost and risk is the primary motivation for implementing a structured SAP change control process. Key benefits include: improved planning and prioritization of changes, better coordination between projects and maintenance activities, reduced risk of transport conflicts and errors, complete audit trail of all changes, and faster resolution of critical issues.

    Challenges in implementing SAP change control include: the complexity of SAP landscapes with multiple systems and clients, the need to balance speed of change with risk management, integration with existing processes and tools, and user adoption and training.

    beteo’s SAP Change Control Current Practice provides a proven framework that addresses these challenges. It combines standardized processes with HP PPM as the central tool for change request management and transport coordination. The framework has been implemented successfully at multiple SAP customers in Switzerland and provides a solid foundation for reliable SAP change management.

    A typical customer reference: A large Swiss manufacturing company was experiencing frequent transport conflicts and system instabilities due to uncoordinated changes. After implementing beteo’s SAP Change Control solution based on HP PPM, transport conflicts were reduced by 70% and system stability improved significantly.

    🇩🇪 Diesen Beitrag auf Deutsch lesen

  • SAP Consolidation: A Challenge to Further Development

    In a highly interesting and descriptive blog posting on the SAP Community Network, Tao Zhang, who works for Benteler Group, discusses the SAP consolidation process. His article focuses on the challenges and potential benefits, approaching the issue from the company’s perspective.

    As I see it, the biggest challenges facing SAP system environment consolidation projects in the medium term are: First, the planning and coordination of the decommissioning or consolidation of the current SAP landscape while ongoing business operations must be maintained. Second, the management of the complex interdependencies between SAP systems, especially when multiple clients and custom developments are involved.

    SAP consolidation is much more than just a technical merging of systems. It requires careful analysis of all business processes, master data, configurations, and custom developments. The consolidation must not disrupt ongoing business operations, which makes it one of the most challenging IT projects.

    beteo has extensive experience in SAP consolidation projects. Our approach combines detailed analysis using specialized tools with proven project management methods. We help our clients plan and execute SAP consolidations that minimize business risk while maximizing the expected benefits of the consolidated system landscape.

    The benefits of a successful SAP consolidation include: reduced operational costs, simplified system maintenance, better data quality through harmonization, and improved performance through optimized infrastructure.

    🇩🇪 Diesen Beitrag auf Deutsch lesen

  • SAP Upgrade: Analysis Procedures and Results

    SAP upgrades are regularly a major challenge for SAP customers and their IT teams. The preparation and execution of an SAP upgrade requires careful analysis of the existing system and the planned target system. beteo has extensive experience in SAP upgrade projects and has developed proven procedures for upgrade analysis.

    The most critical question in an SAP upgrade is: “Which of our custom developments and configurations will be affected by the upgrade?” This requires a comprehensive impact analysis that identifies all affected objects and assesses the effort required to adapt them.

    Key analysis steps include: technical upgrade analysis (which standard programs have changed?), custom code impact analysis (which Z-programs are affected?), configuration impact analysis (which customizing settings need to be reviewed?), and interface analysis (which interfaces to external systems need to be tested?).

    beteo has developed standardized procedures and uses specialized tools such as IntelliCorp LiveCompare for these analyses. Our experience shows that a thorough upgrade analysis significantly reduces the risk of an SAP upgrade project and enables better planning and cost estimation.

    The results of the analysis provide the basis for a realistic project plan, including resource planning, timeline, and budget. They also enable early identification and resolution of potential problems before the actual upgrade begins.

    🇩🇪 Diesen Beitrag auf Deutsch lesen

  • SAP Business Process Change Analyzer – Does It Analyze Business Processes?

    Accompanied by considerable fanfare, SAP co-CEO Leo Apotheker introduced an SAP Solution Manager module called the SAP Business Process Change Analyzer (SAP BPCA) at TechEd in Berlin. So, what’s behind it? Can the Business Process Change Analyzer fulfill the expectations that its name suggests?

    The fact that SAP has even introduced the BPCA seems to indicate the value it has assigned to impact analysis. Impact analysis is a topic that has been addressed in various articles in the beteo blog. Unfortunately SAP and its “Business Process” Change Analyzer deal exclusively with the technical analysis of transactions and programs. So, anyone who expects SAP’s analytical offering to include the overlying logical areas will be in for a long wait.

    It appears that BPCA is based on a run-time analysis, which makes it impossible to conduct impact analysis directly in the corresponding production environment. The result is that only corresponding predefined scenarios can be analyzed with BPCA.

    The question we must ask is why SAP didn’t turn to “standard” analysis tools like LiveCompare from Intellicorp, Panaya from Panaya Inc., RBE from IBIS or CIT for SAP from HP. These are based on “smarter” approaches to impact analysis and impact management, and their merits have been proven through real-world usage.

    Summary: Once again, on paper SAP’s BPCA satisfies most of the items found on typical RFP checklists pertaining to impact analysis. However, upon closer scrutiny many higher expectations that customers have regarding a bona-fide business process change analyzer have not been met.

    🇩🇪 Diesen Beitrag auf Deutsch lesen

  • SAP Solution Manager – Does It Manage SAP Solutions?

    I was fortunate to attend various presentations on the topic of SAP’s solution management at SAP TechEd 2008 Berlin. My expectations regarding SAP solution management would be that SAP could finally take on the task of solution management for specific customer implementation scenarios, and that it would do so in a comprehensive manner. Sadly, this has not yet been achieved.

    Even after visiting the solution management presentations I was disappointed to find that even though the SAP Solution Manager does fulfill the requirements to manage a standard SAP system, key functions pertaining to the solution management of specific SAP customer implementations are missing. Apparently the Solution Manager remains primarily a gateway to the customer’s infrastructure.

    SAP’s marketing, however, cleverly packages the Solution Manager as a comprehensive lifecycle management solution for specific SAP customer environments, even though basic requirements for bona-fide solution management using SolMan—such as customization version control or dependency management among individual software components—are nonexistent.

    Summary: It is somewhat disillusioning that SAP still hasn’t directed the SAP lifecycle management toward solution management for its thousands of different customer implementations. Despite the potential benefits for all SAP customers, the lifecycle management solution bearing the wonderful name of Solution Manager is still mainly a software logistics-specific bridgehead for SAP standard software.

    Note: beteo has implemented comprehensive SAP solution management for actual customer implementations based on standard processes and standard software.

    🇩🇪 Diesen Beitrag auf Deutsch lesen

  • SAP Positioning: Solution Management

    SAP Positioning: Solution Management

    Instead of positioning solution management as a product for IT, it should be understood as business functionality to manage IT.

    Business Impact Analyzer

    What does beteo understand by SAP Impact Management? beteo has written numerous blog posts on this topic. beteo has committed itself to SAP Impact-Management as its core solution goal — we live for SAP Impact Management.

    SAP’s Business Process Change Analyzer

    With great fanfare, SAP co-CEO Leo Apotheker announced the SAP “Business Process Change Analyzer” (BPCA) at that year’s TechEd in Berlin. But what lies behind it — can the Business Process Change Analyzer actually fulfill the expectations its name raises? The very fact that SAP announces the BPCA shows the importance SAP is placing on impact analysis for the future.

    In various blogs we have already written about impact analysis. SAP’s BPCA unfortunately only covers the technical analysis of transactions and programs. An analysis that goes into the logical areas is still left open by SAP. Based on available screenshots, it appears that BPCA is based on runtime analysis, which makes it impossible to perform direct impact analyses in the corresponding production system. This means that for BPCA, only predefined scenarios can be analyzed — honestly, who still works like that today?

    It is truly questionable why SAP has not adopted standard analysis tools like RBE from IBIS, Panaya and/or Intellicorp, since these are based on “smarter” impact management methods and have already been proven many times in practice.

    Conclusion: Once again, SAP gets the “checklist” points with the BPCA, but on closer inspection, the expectations for a BPCA are absolutely not met.

    The Contradiction “SAP Lifecycle Management” SAP LCM

    With great interest, I attended the various presentations on SAP Lifecycle Management (LCM) at that year’s TechEd in Berlin. My expectation that SAP would also address “customer” lifecycle management was only partially met. The TechEd unfortunately did not convince me that the SAP Solution Manager was created for the solution management of customer implementations. Rather, the Solution Manager exists so that SAP has a gateway into the customer infrastructure, in order to optimally ensure the lifecycle management of SAP standard software.

    SAP cleverly packages the SAP “Standard Software Lifecycle Management” as SAP “Customer Lifecycle Management.” Fundamental requirements for software lifecycle management — namely versioning (there is still no customizing versioning in the standard) and dependency management between individual software components — are non-existent for SAP “Customer Lifecycle Management.” For SAP “Standard Software” Lifecycle Management, this is comprehensively contained in the CIM model.

    Functionalities such as SAP ChaRM and SAP CTS+ are cleverly wrapped in marketing language, so that customers no longer notice the actual challenges of concurrent Change Request Management (SAP ChaRM) and heterogeneous deployment (SAP CTS+).

    Conclusion: It is disappointing that SAP still does not focus the topic of SAP Lifecycle Management on 75,000 different customer implementations, but rather on the software logistics of their own standard software. Each of these customer implementations is unique and requires standard procedures for managing precisely this customer-individual SAP Lifecycle Management. In various customer implementations, we have already proven that SAP “customer implementation” Lifecycle Management is an achievable challenge.

    The conventional transport management (now called CTS) could not keep pace in complex organizational and technical system environments and had to be supported by external tool support. Now that SAP NW Java development and configuration objects are added, the entire challenge becomes multi-dimensional. Thanks to SAP for leaving so much space for consulting!

    🇩🇪 Diesen Beitrag auf Deutsch lesen

  • SAP Usage Analysis with IntelliCorp LiveCompare

    Which processes run in a SAP system? What components are used most frequently? Which custom programs are used? How is usage distributed in departments or in the enterprise? Which outside systems have access to the system? These are only some of the questions asked by IT managers every day.

    They arise from different requirements. For example, there is the requirement to distribute system costs to the user departments based on usage. Another task is the preparation of lifecycle events such as SAP upgrades, SAP roll-outs, installation of SAP support packages, SAP consolidations, SAP system optimizations or the isolation of selected clients or accounting areas. In these cases, it is important to know which processes are concerned, which custom developed code is needed or no longer needed.

    A major German client in the manufacturing industry confirms the importance of such tasks: “Analysis will be the central part of our upcoming China project”. The scenarios described above are only part of the range of possible questions to which IntelliCorp LiveCompare provides answers. Usage data is handled with utmost care and is consolidated when issued in reports. This consolidation can selectively be based on enterprise affiliation or department or any other criteria.

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

    🇩🇪 Diesen Beitrag auf Deutsch lesen