<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1409256432473273&amp;ev=PageView&amp;noscript=1">

18 Biggest Pain Points of Your SAP Monitoring

Published on 11.07.2017

Basis teams manage all SAP administration, maintenance and ongoing monitoring throughout the organization’s systems. The basis work is complex but almost invisible when all systems are working correctly.

Syslink research shows that a whopping 50% of SAP basis engineers see their most significant challenge as the time spent on unpredictable issues. Industry research shows similar results. A recent study from Veeam showed that when comparing key findings from 2014 to 2016 one can see:

  • Increase in unplanned downtime:
    • 1.4 to 1.9 hours for mission-critical applications
    • 4.0 to 5.8 hours for non-mission-critical applications
  • The average recovery time objective (RTO) for mission-critical applications is 3.0 hours vs. service level agreements (SLAs) requiring 1.6 hours. Similarly, current recovery point objective (RPO) is 4.2 hours, but should ideally be 2.9 hours.
  • Downtime cost of $5,600 per minute. $300,000 per hour - this is the cost of unplanned IT downtime costs as calculated by research powerhouse Gartner. Other studies and research in respective industries and markets put unplanned IT downtime over $7,900 per minute.

 SAP Basis work is crucial to the company, and these are just some of the most common challenges SAP Basis teams are facing daily and their potential implications. 

  1. Manually performing daily checks - SAP best-practice requires daily checks of the system’s performance and KPIs. Running these daily checks is a mundane, boring task, but not doing it will result in unnoticed failures which could spiral to a full-blown shutdown.
  2. Having to track changes manually - Tracking system configuration changes is essential for security, ompliance, audit and identifying the root-cause of failures. Many organizations track changes using a spreadsheet - resulting in missing and inaccurate information.

  3. Manual SLR report generation - Almost all managed service providers, as well as many IT departments, are committed to an SLA (Service Level Agreement). Creating a report showing the actual achieved SLA is not a simple task, takes a lot of time, and often presents inaccurate information.

  4. Too many notifications that don’t need anyone’s attention - Solution Manager, commonly used by SAP Basis teams, sends an abundance of notifications. Flooding the team with both warning and critical notifications makes it very difficult to focus on the issues that have an effect on the system performance. This often leads to frustrated team members and inevitably ignored critical notifications.

  5. Not knowing about changes that are not in compliance with the security policy - Security policies contain requirements that protect the organization. During an SAP upgrade, migration or even day-to-day operations many changes are made temporarily but left unchanged. Many of these changes are not in compliance with the company policies. Finding those risky changes is almost impossible.

  6. Not knowing the source of a failure - Finding the source an SAP issue is very complicated. You can read more about it in the Basis guide for SAP debugging
  7. Batch job times - A batch job in SAP is a scheduled background program that usually runs on a regular basis without any user intervention. These jobs are detrimental to the business if not run successfully and on-time. Not carefully monitoring batch jobs can result in a domino effect and a major business impacting issue. While these particular issues may not be technical in their nature, making sure the batch jobs ran successfully usually falls on the technical basis team. Many tools can monitor if a job canceled, but the following scenarios are often not being watched:
    1. The same job running in parallel, spawning multiple sets of results throughout the system
    2. A batch job or set of batch jobs running for a longer than usual time, pushing subsequent jobs that need to run further into the future causing delays across the business
    3. Having a batch job run successfully, but not actually process any data, therefore not providing any actual results
    4. A scheduled job not running at all, which won’t be caught by SAP or many monitoring tools as a batch job that doesn’t run can’t have an error
  8. Did OS level files arrive on time and have successful contents - Often times there are operating system level files that need to be created or updated on a periodic basis. This could vary from individual third party transfer files to critical bank processing files. Missing files are typically detrimental to the business. Unfortunately, checking these manually is an unrealistic expectation, especially when hundreds of files may be at risk.
  9. Are the correct systems & clients opened or closed for changes - Upgrade and migration project work, along with certain development changes, may require a system or client to be unlocked for changes. Leaving the system and clients open is a huge security threat and is an open invitation for malicious activity. Identifying the open systems and clients is often overlooked and always gets caught in yearly audits.

  10. Taking calls and answering tickets from employees curious on system status (batch jobs, performance, etc.) - A lot of IT and Basis teams’ time is wasted taking calls, reporting and updating other employees on the system’s status. Most systems do not provide status dashboards or clear visibility on their performance to the non-IT users, creating an additional load for IT.

  11. Manually estimating future resource consumption - Planning the amount of future resource requires extrapolation of current data and resource usage. Doing it manually is not simple, thus not being done very often. Guesstimated future needs instead of relying on real data and facts results in unplanned failures due to insufficient resources, or budget spending in the wrong places (and wrong time).

  12. Not providing proactive SAP support - Most IT and Basis teams react to issues and fix them once reported or identified - resulting in a good deal of unplanned downtime and unplanned debugging time (i.e., after hours). Unexpected failures could be reduced dramatically if support teams would be proactive and know about issues before they happen or before they spiral and become critical.

  13. Having to look through multiple tools to find data - Finding a needle in a haystack, or the source of an issue, is a tough job and even harder when the organization is using multiple tools to monitor different elements of the system (servers, databases, SAP, network, etc.)

  14. Time spent on setting up, configuring and maintaining (monitoring) tools - Many tools in the market are very hard to set up, configure and maintain. One of our customers shared with us his experience installing solution manager
    , and this is not unusual in the SAP market.

  15. Too much time spent on yearly audits - Preparing for an audit requires keeping records and collecting a lot of data. This is a time-consuming task that could take as long as several weeks. Not having a tool that properly documents all planned and unplanned changes and associates them with the relevant change policy result in manual spreadsheets that is prone to human error.

  16. Inconsistent procedures/follow up - There are thousands of possible errors within an SAP system and something always could go wrong. Every organization has different guidelines or set of procedures that need to be followed for each scenario. Many companies rely on the support engineers to understand and perform these procedures off the top of their head, which always leads to knowledge transfer issues among employees. Some companies do write proper documentation but then usually hold it in a shared folder or third-party system that is hard and time consuming to search.

  17. Inconsistent monitoring between same system types - As system monitoring is set up manually on each system, it often results in having several systems or elements of the same type monitored differently. This could result in some issues found on one system element but not on the other.

  18. Spending too much time looking for system details - Inconsistencies across an SAP landscape (for example different Kernel levels, EHP levels and support package levels) can cause various failures. Finding these system details is time-consuming and in some cases hard to extract or find. 

What are the most common challenges you and your team face? We would love to hear what is the biggest challenge your team is facing monitoring SAP system.

Post a Comment