Why knowing what background jobs are running on your SAP systems matters more than ever before!
As you would expect, we’ve visited many SAP customers over the years and always have an interest in the SAP background processing and how the execution of batch is managed. As SAP systems continue to move from on-prem to cloud and the charging models from SAP and supporting software solutions transition to flavours of consumption/activity based the impact of not knowing what your running, why it’s running and increasingly how it’s running will be an increase in operational costs going forward. This is happening already!
Whether SAP background processing is managed natively via SAP transactions or externally using an enterprise scheduler/process automation tool it never ceases to surprise how little is actually known about the jobs defined and running across the SAP systems. There is certainly almost no consideration of how a job is setup which can be very important with today’s consumption based licensing models. For sure, those administering the systems will be able to tell you how often a job runs, what Abap/Variant are being used and most likely if it’s a job that they see failing time and time again but often very little more. The fact that resources/credits/cpu are being consumed is not even a consideration.
Talk of folks in the business seeing local printers spewing out page after page of output on a daily basis from a long forgotten SAP job may be fairy-tale, but it highlights an important point. The fact that no-one knows what the output is for, and once the printing is complete all of the output is picked up and placed into the nearest re-cycling bin would seem incredible. What can be deduced is that a daily job is scheduled somewhere yet nobody knows which job it is that’s causing this waste. No doubt there are other examples, the most obvious being the constant execution of jobs that fail the majority of times because the condition to enable execution, e.g. file arrival, happens at variable times per day. How many other similar and maybe less obvious examples are there in your organisation? It is often the case that once something is set to run in background in SAP it soon becomes forgotten about and over time, through staff or outsourcing partner churn, no-one knows why the job is running. Neither is anyone particularly interested in what it does or verifying if it’s still required. The easy solution is to simply let sleeping dogs lie and progressively pay more over time.
Is it important to know what batch is running and why? Cards on the table, we definitely think so, however the majority view appears to be that there are more important things to prioritise – like assessing additional storage or which VM SKU or S/4Hana model is going to be best to support our SAP systems and the processing required – for the ever-increasing batch!
The approaches taken to implement new batch is often also a surprise. In a world where many organisations adopt ITIL, or at the very least its principles across many parts of the IT landscape it seems that background scheduling is often overlooked. How many of your jobs can be easily traced back to the original change request?
At the same time in SAP there are often initiatives around Governance, Risk and Compliance affecting different process areas yet this also seems to completely overlook batch too. Audit teams only appear to have a passing interest (perhaps because they are not aware of the risks?) and often do not appreciate what both the SAP or an external scheduler may provide scope to do. Do your defined ‘batch’ users still run with SAP_ALL or as a user with a role containing SAP_ALL? Does your external scheduler (or indeed other connecting SAP/non-SAP applications) use a SAP user account with SAP_ALL authorisations?
So what information does Adaptiv think it’s important to understand when looking at the batch landscape? First of all we believe an organisation using SAP should at the very least have an understanding of the “Business” criticality of their jobs. For those with a technical understanding of SAP they will be aware that SAP natively provides three classifications that support job prioritisation yet in most cases jobs are defined to run with a common classification. 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 such that you can ensure your business critical jobs always get the front of queue before less critical batch. If an external scheduler is utilised then further levels of prioritisation will also be possible.
If an SAP system owner doesn’t know which jobs are critical to the business when things go wrong, perhaps due to an unplanned outage or even worse a DR scenario, it’s not going to reflect well when the focus is to get critical systems and processes running again and it then becomes necessary to reach out to the business to ask which are the most critical jobs that need running. Chances are they won’t know the job names either! How much extra time, cost and reputational damage would that create? Alternatively, if those that are responsible for providing the SAP service know that once something like normal operations are resumed SAP will automatically focus on the business critical jobs i.e. those that are going to allow goods to be manufactured, parts to be ordered, payments to suppliers, goods to be delivered, raw materials to be received and receipt of payments from customers, then that clearly will be much better received.
With an approach in place to categorise the jobs, it then also follows that as the critical jobs repeat they will again be given priority and when systems start catching up on any backlog, or as resources allow, so the Important and Normal jobs will be allowed to execute. If all jobs are categorised the same then this will never be possible. 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 categorisation seems such good sense I wonder why this is not typically seen in the field. Is it because our perceived good sense is not good sense at all? Is it that the teams creating the jobs are not thinking about/challenging what they are asked to setup in the SAP Systems? Is it the job requestors not considering the relative business importance of the job(s) they are requesting alongside the many others that exist? Is it just a lack of understanding, experience and knowledge of ‘best practice’?
If one accepts it’s good practice to identify and prioritise the most important jobs then of course one needs to recognise that most businesses are continually evolving whether that’s introducing new products, smarter ways of working or a myriad of other initiatives that can introduce change into the SAP job scheduling landscape. In terms of background jobs running in SAP it shouldn’t take a great leap of faith to recognise that jobs that were required in the past may not be required now, especially if your moving or have moved to S/4Hana. A move to S/4Hana would be a good time to review existing jobs and put in place process for the future but this can represent significant effort depending on your starting point.
If a company recognises the value of identifying the business criticality of their jobs then surely the information in place must be periodically re-evaluated, to confirm the on-going requirement, criticality and frequency of execution, etc. In order to confirm these points it is likely that a Business, Functional and/or Technical ownership of some sort must also have been or be established. This extra job information of course needs to be stored so that it can become a reference for the jobs being run. For those having the benefit of an external scheduler or our insight tools then there will be opportunity to both store and automate the validation process too.
Of course to address aspects of criticality and ownership, in an environment where this has never been considered previously is going to take some effort to put information in place but it’s effort that’s going to add demonstrable value. From a SAP system ownership perspective, rather than blindly providing an infrastructure to support SAP processing and jobs you know nothing about, immediately this is changes to one where you know very much more about the service you’re being asked to provide and more importantly you know that resource is required based on an auditable, current and confirmed business requirement. Perhaps then you can consider a re-charge model to the business for the services they require?
Where a company is expanding, diversifying, migrating to new infrastructure or a new service delivery partner knowing what processes run to support different business functions clearly has enormous benefit if one is able to easily identify the jobs in the first place. Here naming standards should be employed. If for existing and new jobs you are going to determine the business criticality and the ownership information then why not complement that too with business process area, region and/or market? For all new jobs, include a change reference linking the job to a recorded change in the change management system? All of this information will be invaluable if considering an outage/change that might affect a particular market or business process area and trying to determine which jobs might be impacted or indeed which new jobs have created a problem.
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 SAP consumption forecasting, server SKU sizing, storage, evaluating likely growth, the impact on existing infrastructure and of course the archiving that may be possible. This is not just the jobs that are running successfully of course, it also should allow those jobs that run and consistently fail to begin to be addressed. Information captured allows recourse to the process owner to highlight that a job is consuming processing resource, at the expense of other jobs, only to fail more times than not. Even if a job doesn’t fail very often, when it does, without the ownership information this becomes a much more difficult and time consuming task to identify who can determine root cause and do something about it. When failing jobs become just ‘noise’ how does that effect your monitoring and ability to spot and address that job that doesn’t normally fail?
As will be clear from the above we believe there is very much more to consider when running background jobs in SAP than is done typically. We also believe with today’s software and infrastructure charging models it would be remiss of an organisation that doesn’t just have money to burn to not consider this carefully. Maybe the examples mentioned have provided food for thought?
Next Steps…
Hopefully this article has provided some insight into how examples of ‘best practice’ in SAP Job scheduling, whether using native tools or external scheduling applications, is not something that is simply there ‘out of box’. For further information on how you can benefit from our experience and ‘best practice’ please do contact us.