Wednesday, February 3, 2016 Consulting - Basis documentation you should have for your SAP systems

When I start with each client, I like to collect as much 'meta' information as possible. To make my job easier and to leave each client with a solid deliverable, I collect each of the following items:

I. General – Client Background

1. Where is the client located?
2. What is the clients business?
3. Are there access requirements for the site and building?
4. What are the operating hours?
5. Who are the key contacts?
6. What are the up time requirements?
7. Who are the client's other key vendors?
8. Who handles the operating system environments?

II. Infrastructure

1. How to connect with the client (is a VPN used)?
2. What operating system(s) and database(s) are utilized?
3. Which third party applications connect to the SAP systems?
4. Are there any special security requirements?
5. Which flavor of virtualization is used?
6. Are there any DR requirements?

III. Diagrams

1. Landscape
This should include all the SAP systems and any relevant connected systems
2. Transports/Updates
Shows the flow changes between systems
3. Network
How are the systems connected?
4. Server/Virtualized Instances and Systems
Where to the systems reside?
What processors and memory is on each system?
Do any of the systems share database instances?
5. Data Flows
How does data move between each of the systems?

IV. Processes

1. Change management
How are changes approved and moved through the systems?
Is there a ticketing system such as Jira utilized?
2. Communication
Who should be alerted when issues come up?
Is there an incident call tree?
3. Incident Management
How are issues and problems managed?
Are incident tickets created and are RCA's expected after problems resolved?
4. Security
Who and how are security requests handled?
5. Project Management
Is there an internal team that manages each project?

V. Strategies and Standards – Infrastructure

1. Backups
How and where are backups saved?
How are backups and restores requested?
2. Business Continuity
3. Downtime
When and how long are the scheduled maintenance periods?

VI. Strategy and Standards – SAP Specific

1. Client Strategy
Are there separate configuration and development clients?
2. Security Standards
Are there gateway or message server security requirements?
3. Authorization Standards
Are there firefighter roles available for production systems?
Is there a policy for who can run debug mode or SE16 in production?
4. Transports
Who imports transports?
Is there a scheduled date/time for production imports?
5. SLD
What infrastructure has been setup for the SLD systems?
Is there a code review process in place?
7. System/Data Refreshes
Is there a scheduled process for refreshing data back to other systems?
8. Updates/Upgrades
How often are updates scheduled for the systems?
Is there a review process for SAP upgrades?
9. Monitoring
Is there a monitoring matrix that shows when alert messages should be generated and who should receive those alerts?
10. System Settings
Who approves the opening of systems?
Who should be notified what systems are opened and closed? Consulting - Scheduling Standard SAP Basis Housekeeping Tasks

When I first come to a client site, one of the first things I check is to see if they are running standard tasks to maintain their systems. Below is a template I created for the first SAP system I managed (way back in 4.7 on a MAX DB system nonetheless).

1. Housekeeping jobs for ABAP Systems

Job NameReportRepeatClient SpecificPRD - Scheduled?















This is something that I've compiled over the years to better track scheduled housekeeping tasks. These I've compiled from Notes 16083, 1411877, and 1440439.

Most of these jobs can be scheduled from within SM36 (standard jobs). I like to manually check these against the list above to make sure the jobs are running with the correct reports and in the correct clients. If a job isn't scheduled, I'll create a new job and assign the task to a dedicated SAP Basis background account (something like 'BATCH_BC' should work). Please don't assign your account to these jobs! Almost every site I've worked at has had jobs fail because the Basis admin used their own account and these all failed when their account was deleted or locked.

Even more amazing is the number of sites that don't run all of these. I run some of these jobs at older sites and found one that deleted over 6 years of stale temporary variants! Needless to say, it took less time to create new variants after this cleanup.

You should also remove the jobs below. These are defunct and only generate errors in the system.

2. Defunct Jobs

Job NameReportReason
SLCA_LCK_SYNCHOWNERSSLCA_LCK_SYNCHOWNERSOnly schedule on livecache systems
SAP_WP_CACHE_RELOAD_FULLOnly schedule on workplace servers

As a standard process, I'll add a check to standard system checks to ensure that these jobs are still scheduled (I'll check every month or so).

It is important to run these jobs so tables that hold transient data don't grow out of proportion to the rest of the data. Over time, you'll find the system starts to slow down as it reaches performance thresholds. As a Basis admin, you can return value to your client by ensuring that standard tasks are running and cleaning out those transient tables. Making sure these stay small, will make upgrades and migrations a bit easier.

Joseph P. Haynes
SAP Basis Consultant