As you would expect, Grey Monarch visit many SAP customers and always have an interest in SAP background processing and how the execution of batch is managed.? Whether SAP background processing is managed natively via SAP transactions (SM36/37) or externally using an enterprise scheduler/process automation tool, it never ceases to surprise us how little is actually known about the jobs that are running every single day across the SAP systems. (sometimes every single minute of every single day!)?

Talk to people in the business and tales of local printers spewing out page after page of output on a daily basis is not unusual.? The fact that no-one knows what the output is for, and once the printer has finished all of it is picked up and placed into the nearest re-cycling bin seems incredible.?

What can be deduced is that a daily job is executing somewhere yet nobody knows which job it is that?s causing this waste.? How many other similar and maybe less obvious examples are there in your organisation? It often appears that once something is set to run in background in SAP it soon becomes forgotten about and, because no-one knows what the jobs does or why it is required, just leave it to run - heaven forbid the risk of stopping it!


"Tales of local printers spewing out page after page of output on a daily basis is not usual, but no-one knows what job is creating it or why it is required. It often appears that once something is set to run in background in SAP it soon becomes forgotten about and is left to run for ever more"

Is it important to know what background jobs are running and why?

In a world where many organisations appear to adopt ITIL for the vast majority of IT processing, or at the very least it's principles, it seems that background job processing is still an area that is largely overlooked.? For instance, how many of your jobs can be traced back to the original change request??

It often appears that background job processing is also only given a passing interest in terms of Governance, Risk and Compliance, perhaps indicating a lack of knowledge of how to assess background processing in terms of risk - it is remarkable how many 'business critical' backgound jobs we find that are run from personal SAP named user accounts, some of which are often contractors who had left the business many moons ago! It is also incredible how many defined ?batch? users stil run with SAP_ALL??

It is remarkable how many 'business critical' backgound jobs we find that are run from personal SAP named user accounts, some of which are often contractors who had left the business many moons ago!

We believe that an organisation using SAP should at the very least have an understanding of the ?Business? criticality of their jobs, yet in most cases jobs are defined to run with a common classification. Progressing towards a much better classification sturcture need not be be difficult; For those with a technical understanding of SAP they will be aware that SAP natively provides three classifications that support job prioritisation . Why is this significant? Having three levels of prioritisation in SAP allows for a simple structure to be defined, e.g. Critical, Important and Normal. If an external scheduler is utilised then further levels of prioritisation may also be possible.

Using just this simple structure alone will ensure that following an SAP outage, your SAP systems will automatically take care of your most critical business processes for you first, before every other background job tries to jump into the system and take away valuable resources that will cause further delays.

Of course this argument doesn?t need to apply only to a post outage or DR scenario - patently it makes good sense during normal operations too, thus ensuring those tasks that are most important to the success of the business are always prioritised over the less important jobs.


If job review and categorisation seems such good sense you wonder why this is not typically seen in the field.? Perhaps the teams creating the jobs are not thinking/challenging what they are asked to set up in the SAP Systems??Maybe the people requesting the job(s) are not considering the relative business importance of them?? This is where setting out standards for jobs in terms of ownership, priorities, business impact information, change control references, etc. is a critical factor when reviewing your SAP batch workload.

Of course to address these things in an environment where it has never been considered previously, it is going to take some effort but it?s effort that?s going to add demonstrable value in terms of resource optimization, processing prioritization, documentation, security, audit and business continuity.

It is going to take some effort but it?s effort that?s going to add demonstrable value in terms of resource optimization, processing prioritization, documentation, security, audit and business continuity.

With SAP jobs classified and ownership correctly placed within the business the task of managing the infrastructure to support the SAP service inherently becomes more efficient. Knowing that you?re only running the jobs actually required by the business allows better decisions to be made in areas like server sizing, storage, evaluating likely growth and impact on existing infrastructure and of course the archiving that may be possible.

Background jobs that consistently fail should also be addressed. Why not go back to the process owner and highlight that a job is consuming expensive processing resource at the expense of other jobs.

 


 

Next Steps...

We believe that there is very much more to consider when running background jobs in SAP and that massive improvements in business quality and process optimization can be gained from cleansing, standardizing, classifying and applying general best practices to yo style="text-indent:20px"ur SAP background job processing.

For further information and advice on how you can benefit from our experience and ?best practice? please do contact us.

You can also share this page via the following buttons: