Regardless of where your SAP project is in its lifecycle, or what new functionality you are deploying, performance issues will bring a project to its knees and create issues that extend well beyond end user inconvenience. Ongoing performance or stability issues for any SAP system (ECC, BI, PI, etc.) can bring significant risk to the overall health and long term viability of a project and also create major schedule impacts to current projects that are in flight. Key technical team members and developers get pulled into help troubleshoot, the vendor gets involved, and project managers will spend countless hours managing the negative perceptions and potential user adoption issues or stakeholder concerns that may arise as a result of the issues.
As many projects began to invest additional time and resources in new SAP functionality such as HANA and Fiori, and of course to prepare to make the eventual jump to S/4, it’s equally important to make sure your current house is in order. On this note, we believe that SAP system maintenance is best achieved by implementing proactive maintenance measures using standard SAP functionality in order to identify and correct system issues before they impact system performance.
Most of the projects we work on are currently at Solution Manager 7.1. Some are evaluating the jump to 7.2, but will likely not make that move until the other software versions in their landscape require it. And most would like to find ways to extrapolate further value out of Solution Manager, but understand that it needs to be justified because implementing new functionality in Solution Manager often requires the most senior technical SMEs who are subsequently pulled away from customer facing work. However, when you consider the return on investment that a well-planned implementation of proactive technical monitoring functionality can provide you with, you really start to see a valuable return on investment.
We recommend Solution Manager monitoring tools to provide preventative maintenance such as Database, System Host, RFC, BI, Interface, End User and Network Monitoring, all provided by the Solution Manager Monitoring suite. Alerts should be setup with each individual system and can be tailored to any specific metrics identified as a threshold of operational sustainment. Each system will have monitoring agents installed that alert in real time. These agents can be installed on SAP and non-SAP systems alike. The alerts are emailed out to a select group based on the application support team and client’s desires. All alerts can be managed out of a system management dashboard located within Solution Manager and may be modified at any time with no impact to the systems being monitored. The monitoring alerts can be configured to setup auto reactions to include system job scheduling, SAP Service Desk ticket generation and GUI end user alerting.
The enhanced abilities of the Solution Manager tools allow the Basis team to perform adaptive maintenance activities that keeps all monitoring actions in sync as the environment evolves and new applications are added. As the monitoring solution progresses, we continue to create the custom metrics and thresholds for these alerts on the new software as needed with no interference to the already existing preventative maintenance activities already existing in the environment.
To prepare for the implementation of the technical monitoring scenario, we first make sure the Landscape Management Database (LMDB) is configured and populated accordingly. Software plug-ins and diagnostic agents (based on the version of your environment) must be installed and potentially patched on the systems to be monitored. Firewall rules may need to be setup between the systems. Once the prerequisites are in place, basis resources must execute the appropriate guided procedures in Solution Manager that pertain to technical monitoring and alerting for each system to be monitored. To finish this process, target systems may need to be restarted, so coordination with project teams and/or end users may be necessary. Once complete, the alerts should be configured and customized accordingly so as not to overwhelm recipients with unnecessary alerts. Of course, all of the above is done within the configuration management process for a client, only applying changes after the necessary approvals have been granted.
While one approach is to consider the more monitoring alerts the better, we use a more practical approach where we use what we like to call “Targeted Monitoring”. With this approach the teams target the high value/high reward targets for monitoring to ensure that the right people are getting the right alerts at the right time. Most seasoned SAP resources will tell you at some point you will reach a threshold where your alerting turns overwhelming and teams cannot react in real time to address every issue. Using a Targeted Monitoring approach, we scale back the unnecessary or redundant alerts and simply give the teams what they need to ensure the highest availability of all services currently offered by your environment.
Traditional Early Watch Reporting is also useful for a deeper dive into a particular system, and provides team members a report of system and operation metrics measured by SAP’s best practices recommendations. These reports detail every aspect of a systems condition to include job performance, I/O wait, security checks, component supportability, database connectivity, user session loss, critical error messages and the general health of system. These alerts are constantly being updated by SAP to provide the customer with the most up-to-date security hot fixes and SAP system recommendations. The Early Watch Tool is generated and reported to SAP, emailed out to the application support teams, leadership and other interested parties to give one complete version of the truth to allow for system issues to be remediated quickly and be understood by all parties responsible.
In addition to proactive alerting, keeping up with technical patches and SAP application version upgrades is critical to maintaining a high performing SAP environment. Technical patches include the ancillary architecture components that can be updated without running a full support package stack of the SAP application layer, such as the Kernel, JVM, diagnostic agents, database patches, etc. These are typically less invasive than a full SAP support package or version, and although downtime is required, it should be short. By keeping up with technical patches, you will receive the critical vendor updates relating to security, stability, and performance. SAP version upgrades or even applying support or enhancement packages typically require longer lead time, more project team coordination, and extensive regression testing. Keeping up with your technical patching in between these important projects will often make this process easier to execute (with potentially shorter downtime) because your environment will already meet many of the technical requisites to perform the upgrade.
We believe it is extremely important to follow a streamlined process for addressing corrective maintenance activities. This methodology applies not just to application issues but also to software implementations and end user recommendations for improvement. Once an issue is identified, we deliver a rapid resolution document that provides a common understanding of the issue as well as in-depth details on the impacts of the corrections. Once the decision has been made to move forward, we enter into a configuration scenario where the correction is implemented in a non-Productive environment and thoroughly tested until our requirements and impacts documentation is completely validated. At that point, all vested interested parties are coordinated with to insure complete comprehension of the changes about to be implemented. Only at that point are the corrections implemented, the changes documented and the Production environments issue is resolved.
No matter how big or small an SAP project is, everyone has resource capacity constraints. Adopting a structured, proactive process to maintaining your SAP technical landscape should help with these constraints, allowing project team members to put more emphasis on new value adding functionality in conjunction with maintaining a stable, high performing SAP environment. This ultimately should reduce the overall cost to run your SAP environment and help increase the return on investment.
Comments are closed.