Wisdom is Gathered from User Behavior

As a Customer Success Manager, I always recommend that customers leverage the usage data to optimize their ERP project plan while communicating with clients. This is the essential wisdom of end-user behavior that represents the actual situation of how the user acts on the business application. It is reliable, powerful, easy to access, and there is no extra cost to set it up. But why should we rely on usage data that much? Let’s have a deeper dive into SAP to understand.

What are the Different Usage Data of SAP?

ST03N is the classic usage collector for workload statistics, managed by Basis. It is configurable mainly for time periods etc., and only for the static object calls that can tell who has executed what.  

Usage Procedure Log (UPL) is a newer usage collector for all ABAP-based systems. Compared to ST03N, the UPL result will be more accurate because it can detect both submitted programs or dynamic calls and the usage of any ABAP-based unit down to subroutines. The capability will collect usage information daily and have no performance impact on your system. The UPL is NOT turned on by default. You could switch it on within Solution Manager (>7.1)

ABAP Call Monitor (SCMON) is available with AS ABAP 7.50, and for the lower releases (>=7.00) per ST-PI Add-on, it is a successor of UPL. The advantage of the SCMON compared to the UPL is that by using this tool, you collect the usage data (how often a specific ABAP object was called) and the information about the calling business process. As a result of the monitoring, you get a list of business transactions (callers) along with all ABAP objects that have been called within these business transactions, including the number of calls.

SCMON saves the usage data on the system for a maximum of 7 days. To store the usage data for a more extended period, you should use transaction SUSG. SCMON does not impact system performance and needs to be activated too.

Why is Usage Data Useful?

Customer SAP systems usually contain not only the standard program but a large number of custom codes developed for business adaptation and requirement changes year after year. Some customized objects may not be used so often; some may be used frequently for a while, then replaced or retired, later becoming redundancies (on average, 40-60% of your custom code). Therefore, those not in use code will still need extra effort to be maintained during the version upgrade, request change, or covered by regression test. So, tracking and analyzing the usage level of custom code on your production system directly or through remote connections is always recommended.   

Using data from the methods mentioned above period (we suggest 12 months to 18 months, if possible, that can cover most of the yearly activities) will significantly optimize your SAP projects in many aspects:

Preparation phase – Try to clean your unused custom code/object/report before the evaluation, which will help accurize the project effort evaluation and have a more precise budget for storage database cost, etc.

Realization phase –Prioritize the code remediation & the following test tasks based on the object usage level. Assign the tasks of often used items at a higher priority, and scope out unused items to reduce the project’s total effort/cost. 

  • For Continuous development & Ongoing changes

From the SAP change request, the impacted entry points usage level could also be detected. This can lead to more reasonable prioritization of tasks with limited resources.

Ideally, a single platform that includes all project activities and usage data would be greatly helpful, that with the comprehensive information can ease the collaborations and provide the crucial visibilities to empower the team.

How Does Panaya Utilize Usage Data

After the system code is uploaded to PANAYA, the analyzer will determine if an object has been frequently, normally, or rarely used by comparing each entry-level object relative to the other used objects within a given module in SAP. As a result of the analysis, suggestions can be made, such as:

  • Giving higher priorities to Frequently Used items.
  • Considering scoping out the Unused.
  • Reviewing the Unknown part before the decision (expert experience is needed here).
  • Increasing the priority of critical business processes no matter the usage level.

New ETL (including usage) uploads will be calculated in aggregated results to provide better coverage of new code versions. The dynamic changes of user usage can bring more valuable insights.

Given that more utilizations of the usage data and SAP are developing it to include further associated elements, user behavior is becoming increasingly important. It is like an auto-generated positive feedback mechanism – every user clicks votes for meaningful features; crowds choose the wise. End users provide their favorite via user behavior which makes a virtuous cycle if the usage data can be used for enhancement.

Skip to content