PCOE Setup Guide 2014 04

Partner Center of Expertise

Setup Guide For internal SAP and partner use only

2

Copyright

© 2014 by SAP AG. All rights reserved.

Neither this document nor any part of it may be copied or reproduced in any form or by any means, or translated into another language, without the prior consent of SAP Active Global Support.

SAP Active Global Support makes no warranties or representations with respect to the content hereof and specifically disclaim any implied warranties of merchantability or fitness for any particular purpose. SAP Active Global Support assumes no responsibility for any errors that may appear in this document. The information contained in this document is subject to change without notice. SAP Active Global Support reserves the right to make any such changes without obligation to notify any person of such revision or changes. SAP Active Global Support makes no commitment to keep the information contained herein up to date.

These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

TRADEMARKS

All rights reserved. SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries.

Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Business Objects S.A. in the United States and in other countries. Business Objects is an SAP company.

All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.

Please see http://www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices.

DOCUMENTATION VERSION

Date: 19 March 2014

Release: 5.1

http://www.sap.com/corporate-en/legal/copyright/index.epx%23trademark

© SAP AG 2014 Partner Center of Expertise Setup Guide 3

Table of Contents

Copyright 2

Table of Contents 3

Introduction 6

Chapter 1. Partner Center of Expertise 7

1.1 Definition 7

1.2 Components 7

1.3 Setup Timeline 7

Set Up 8

Deliver 9

Certify 9

Chapter 2. Support Infrastructure 10

2.1 Dedicated Support Hotline 11

Alternative Modes of Communication 11

2.2 Remote Connection 12

2.2 Test Systems 14

2.4 Incident Management System 15

2.5 SAP EarlyWatch® Alert 17

2.6 Support Staff 21

Support Roles 21

First Level Tasks 23

Second Level Tasks 24

Third Level Tasks (usually SAP Support) 24

Development and Training 25

People Certification 26

Outsourcing or Subcontracting 27

2.7 SAP HANA Test System* 27

Chapter 3. Support Processes 28

3.1 Customer On-boarding 28

3.2 Incident Management 28

Preparing an Incident 29

Reporting an Incident 30

Receiving an Incident 31


Acknowledging an Incident 32

Assigning an Incident 33

Processing an incident 33

Forwarding an incident 34

Closing an incident 35

3.3 After Office Hours Support 35

SAP Solution Manager 36

7x24 Support Operations 36

On-Call Support 36

3.4 Handling Complaints and Escalations 37

Complaints 37

Escalations 37

Chapter 4. Marketing & Communications 38

4.1 Support Presentation 38

SAP Enterprise Support 40

Structuring Your Potential Support Offer 40

4.2 SAP Communication 41

SAP Partner Account Manager 41

SAP Partner Service Advisor 41

4.3 Maintenance Agreement 42

Chapter 5. Continuous Improvement 44

5.1 Support Reporting 44

Service Level Reporting 44

Customer Incident Reporting 45

Team/Processor Reporting 46

Management Reporting 47

5.2 Feedback Gathering 47

Internal Feedback 47

External Feedback 48

5.3 Service Improvement 48

5.4 Support Readiness Activity 49

Chapter 6. SAP Solution Manager 50

6.1 Customer Landscape Validation 51

6.1 Project Administration 51

6.2 Solution Documentation 53

Technical Landscape Documentation 54

Business Process Documentation 55

Custom Code Documentation 55

6.3 Incident Management 56


6.4 Maintenance Optimizer 61

6.5 Maintenance Certificate 63

6.6 Technical Monitoring 64

6.7 Business Process Monitoring 66

6.8 Root Cause Analysis 68

Root Cause Analysis for SAP HANA 70

Chapter 7. Partner COE Audit Process 71

7.1 Relevant Roles for the Audit Process 71

7.2 Audit Types 72

Readiness Audit 72

Validation Check 73

Re-Certification 73

7.3 Audit Process 73

Registering for an Audit 73

Conducting the Audit 76

Judging the Audit Result 79

7.4 Combined Certification 80

7.5 Global VARs 81

Appendix A: Quick Links 82


Introduction These guidelines are intended for Value Added Resellers (VARs) as participants of the SAP PartnerEdge channel program, who are about to set up and operate a Partner Center of Expertise (Partner COE). A Partner COE is that unit within a VAR which is responsible for provision of various support services for the indirect customer base.

SAP PartnerEdge VARs are entitled to sell specific software products (e.g. SAP Business All-In-One, SAP Analytics) including maintenance. They engage with SAP and their customers via a shared support delivery model, called VAR-delivered support. Within this shared support delivery model, Value Added Resellers take care of their customers while providing first and second level support and their related maintenance services. They are the first and single point of contact for their customers concerning the SAP-based solution.

Information to set up a VAR-specific support infrastructure can be found via the special home page http://service.sap.com/var-partner and the SAP PartnerEdge Portal, http://sappartneredge.com/pcoe. Further links to relevant items are provided in this document. These guidelines should be used as a basis for building and operating support structures in a Value Added Reseller support organization.

http://service.sap.com/var-partner


Chapter 1. Partner Center of Expertise

1.1 Definition To ensure that all indirect customers receive the same high

quality support, VARs are expected to set up a Partner Center of

Expertise (Partner COE) whose primary responsibility is to

deliver defined support processes and services for indirect

customers. A Partner COE should be established with the

recommended infrastructure, people, and processes to ensure

a streamlined and effective delivery of maintenance services by

both the VAR Partner and SAP.

1.2 Components To enable a successful support operation, a Partner COE

requires several components to work seamlessly and efficiently.

These components are grouped into the following areas:

Support staffing considering relevant product and

process certifications

Service desk infrastructure including, among others,

service desk applications, test systems, remote

connectivity tools and strategies

Support processes such as those required for

incident or problem management, escalation and

complaint handling, services delivery

Marketing and Communications which provides the

means and visibility through which the support

operations can be introduced and presented competitively.

Quality assurances strategies including support process monitoring and reporting, feedback

gathering, process documentation

Continuous improvement strategies through regular process reviews and customer feedback.

Detailed information with respect to the expected set up of these various components are discussed

through several chapters in this document.

1.3 Setup Timeline It is expected that from the signing of the PartnerEdge agreement and opting for the VAR-Delivered

Support model, VAR Partners have to start setting up plans and strategies to establish their Partner COE.

Therefore, VARs should carefully go through the maintenance instructions under Exhibit 4 of their

PartnerEdge agreement to determine the requirements and standards for the support organization

tasked to deliver maintenance services to indirect customers.

A Partner Center of Expertise (Partner

COE) delivers maintenance service to

indirect customers through SAP

recommended infrastructure, processes,

and offerings.


The setup of a Partner COE is dependent on factors such as the size, supported products, experience,

and maturity of the organization. The timelines shown from Figure 2-1 shows the phases of setting up a

Partner COE.

SET UP

During the Set Up stage, VAR Partners should clearly determine the

requirements and standards for the Partner COE. These could be

accomplished by going through the maintenance instructions from the

PartnerEdge contract, attending focus sessions on PCOE enablement, or

utilizing the assistance of both the Partner Account Manager (PAM) and

the Partner Services Advisor (PSA) to ascertain the requirements and get

the best advice with respect to the set up strategies based on the VAR

Partner’s situation.

Some of the pertinent activities expected during the set up stage are as

follows:

Determine requirements for the Partner COE according to

business goals and strategies.

Plan, design, and set up physical infrastructure components

such as people, hardware, software, networks, communications.

Set up required connectivity infrastructure between SAP,

customer, and VAR Partner.

Activate functionalities or applications required for regular

monitoring of customer systems and to engage proactive

maintenance services.

Ensure availability of product knowledge through continued

development, training, and certification achievements.

Training and documentation of support processes and

procedures.

Definition of support performance targets and measurement

activities.

Figure 1-1. Timelines towards Partner Center of Expertise Certification


DELIVER

Once all physical elements are established and support processes are

clearly understood by support staff, the VAR should consider a go live

activity by which the Partner COE commences the delivery of

maintenance services with existing customers. Amongst the activities

that are expected to be performed are the following:

Delivery of support awareness sessions either as an on-boarding

activity or as a support readiness service.

Go live of incident (and/or problem) management processes.

Delivery of pro-active support services

Support process monitoring

Generation of regular support reports to review and measure

support performance and execution.

Regular review of customer systems based on proactive

monitors and reports.

Gathering of customer feedback

Ongoing review of support elements and documentation of potential

improvement points.

CERTIFY

After maintenance services have been delivered to customers and where

Partner COE elements have been tried, tested, and evaluated, the VAR

Partner should be ready for an audit exercise. The Partner COE

questionnaire should be completely filled providing documents where

necessary to better describe and showcase the VAR Partner’s Partner

COE operations.

The Partner COE audit process is a necessary step to achieve support

authorization required to allow a VAR Partner to deliver support to

indirect customers. A more comprehensive discussion of the audit

process is described in Chapter 7 of this document.


Chapter 2. Support Infrastructure

A successful support operation could not be possible without the physical infrastructure, applications

and tools, support staffing, and processes that comprise the essential components of a support

infrastructure. SAP has clearly defined such infrastructure requirements in the SAP PartnerEdge Channel

Agreement and VAR Partners are enjoined to establish these essential elements as a mandatory

requirement.

Figure 2-1. Support Infrastructure Components

For VAR Partners with an existing support business, compliance with SAP requirements necessitates a

review of existing tools and systems to ensure that compliance is not compromised and is met as closely

as possible to guarantee that support services are not jeopardized for both SAP and the VAR Partner’s

mutual customers. Any deviations from SAP’s standard requirements have to be clearly explained to an

Auditor for clarification and recommendations, when necessary.

From the maintenance instructions as provided in Exhibit 4 of the SAP PartnerEdge Channel Agreement,

the following infrastructure requirements are as follows:

7x24 Dedicated Support Hotline

Remote Connection between SAP, VAR Partner, and Indirect Customers

Test Systems for all products productively used by customers

Incident Management System for incident and problem handling and documentation

SAP EarlyWatch® Alert data transfers between VAR Partner and Customers

Certified Support Staff

SAP Solution Manager (mandatory for VARs supporting SAP Business All-In-One and/or SAP

HANA®)

The compliance weight and level for each physical requirement are defined in the succeeding pages.


2.1 Dedicated Support Hotline

As clearly stated, a support hotline should be a

dedicated number that can be reached by customer end

users without need for routing, extensions, or

intermediary communication.

It is preferred that the support hotline meets the

following criteria:

Is a dedicated landline number that directly connects to the support organization

Should have automatic call routing with several lines directly linked to the main support hotline.

Rarely returns a busy signal. For such instances, it is expected that the hotline has a voice mail

facility for support staff to return calls as soon as a line becomes available.

Have automated voice recording for out-of-office announcements. For example, when a customer

calls after business hours, recorded instructions or guidelines are available from the support hotline

providing instructions that a customer can clearly follow to secure support out of regular business

hours.

The call is answered by support staff that clearly identifies themselves as a member of the partner’s

support organization. For example, when the hotline is reached, a support staff member responds

with “Good morning Sir! You’ve reached <<company name>> support. How may we help you?”

ALTERNATIVE MODES OF COMMUNICATION

Apart from a support hotline, VAR Partners can offer alternative means for accessibility of their support

organization to the customer end users. The following means could also be considered to supplement an

existing support hotline:

Online Support

It is not uncommon for well-established support

businesses to offer online accessibility of their

incident management system or other support-

related facilities such as knowledge bases, forums,

or product information and documentation. Online

availability of the incident management system

allows interactive and efficient means of

communicating incident progress and resolution

with the customer base and offers visibility of issues

logged with the VAR.

Dedicated Support Email Address

As an alternative to a direct call, VARs can also offer a dedicated email address which routes to their

support organization. This, however, is not the most efficient process for incident reporting as an e-

mail typically contains unstructured content and there is no guarantee that the email has been

received by the VAR support organization or, depending on network traffic or unforeseen technical

issues may delay receipt at the partner end. This mode could be best used for incidents not requiring

immediate resolution.


Fax

Although outmoded in current times, a fax machine still provides a valuable backup alternative to

electronic means of communication. Thus, having a dedicated fax number for such emergency

situations is recommended.

After Office Hours

The support hotline should be available at all times

and should be properly set up and/or configured to

respond appropriately for calls received outside of

regular business hours. In such instances, a

support hotline should never return a busy signal

but should offer helpful instructions for guiding

customers through after-office hours support

procedures.

It is expected that a dedicated support hotline

should provide any of the following instructions

outside business hours:

Issue automated voice instructions offering alternative means for reporting incidents

Routes to a dedicated mobile number or communications service fully monitored and available for

emergency calls

It is not recommended to offer alternative numbers to customer end users such as the following:

Issuing mobile numbers of specific consultants or other company personnel

Whenever the individual leaves the company or changes numbers, the customer has to receive

new sets of numbers and names. This does not offer a permanent and standardized solution but

will most often confuse customers regarding appropriate contacts for specific situations.

Providing a different phone number for after-office calls

Offering different support numbers can create confusion regarding call hours and expectations.

Urgent calls after office hours are usually made by customers who are in distress and usually in a

pressure-specific situation. It cannot be expected that at such situations, customers could

remember out-of-ordinary processes (and numbers) which probably occurs infrequently and

thus would not be usually accorded due attention.

A dedicated support hotline must be a local land line available for use 7x24. It is

recommended to have phone routing capabilities or voice mail as well to handle busy

lines and/or after-office calls.

2.2 Remote Connection Current communications and networking options offer various means of accessing customer systems in

a remote environment. This becomes the most cost-effective means to view, diagnose, analyze, and

resolve incidents without necessitating the physical presence of an individual at the customer site. This

is, by far, the most feasible alternative for assisting customers quickly and with minimum amount of

delay.

For SAP customers, remote connectivity with SAP’s support backbone is a mandatory requirement for all

productive instances. This is a necessary first step for allowing SAP to provide mission critical services

when it is sorely needed. Without this infrastructure, a customer should clearly understand that SAP or

the VAR Partner is not expected to fulfill service level commitments, where any are made. This could also


allow SAP or the VAR Partner to downgrade priority calls as the expected resolution for incidents without

immediate access would be lowered.

Figure 2-2. Remote Connection Setup

Remote connectivity has to be setup with customer systems for the following purposes:

View, analyze, and resolve incidents from SAP or VAR side from any location at any time.

Execute SAP and/or VAR services for either proactive monitoring (such as SAP EarlyWatch®

Alert, Root Cause Analysis, or Solution Monitoring.)

Security Issues

Customers do have valid concerns about remote connectivity and its potential risk for uncontrolled or

undetected access to their critical systems. Thus, it may be necessary to educate customers on the

following aspects:

Customer has full control of their connection and has sole

capability to open the connection manually from their end at their

own time, at their own means.

Remote connection need only be set up once and can be

opened by a customer only at their preference.

Customers can use various encryption methods for data

protection and security.

Some tools such as Team Viewer or NetViewer, allow

SAP or the VAR Partner to only view customer screens that are

made shown by customers without having an actual physical

connection to customer systems.

VAR Partners should ensure that their customers are fully aware of these security issues and how they

are addressed with current methods. As SAP mandates this requirement with its customers, VAR

Partners have to request their customers to provide this means as a necessary first step for efficient

support especially in critical situations.

SAP offers extensive information on remote connectivity types through the SAP Service Marketplace

pages under http://service.sap.com/access-support. By far, the SAP software program SAProuter is

the most popular means for controlling and monitoring communication between SAP servers and

frontend computers, as well as enabling RFC access between different servers. SAProuter information

can also be taken from http://service.sap.com/saprouter.

http://service.sap.com/access-support

http://service.sap.com/saprouter


For non-ABAP platforms, customers can use other options available as listed from the SAP Service

Marketplace pages. One of the more popular and easiest methods is Netviewer. This allows SAP to either

view the customer’s screen via a Show Only permission or execute transactions via the Full Access

privilege (requires SAProuter). For information on the usage and application of various remote

connection strategies and tools, please visit http://service.sap.com/access-support.

As a key ingredient for certification, remote connectivity is expected to be available for the following:

between SAP and customer production systems

between VAR Partner and customer production systems

between SAP and VAR Partner test systems

between SAP and VAR Partner/Customer SAP Solution Manager systems

between VAR Partner and Customer SAP Solution Manager systems

Remote Connection Exception

It is acknowledged that some customers may have strict policies regarding connectivity outside their

network. These can be mandated by company or even local policies. For such cases, the VAR Partner

should request its customer for documentation of such policies and to present this to the Auditor for

every audit session. The VAR Partner should initially peruse the document and explicitly indicate or

pinpoint the page/chapter/paragraph where such restriction is stated.

Being a mandatory requirement, the VAR Partner should ensure that compliance for

remote connectivity is generally high within its customer base and its own support

infrastructure. An 85% compliance target is required.

2.2 Test Systems

Customers reporting incidents may not necessarily welcome the idea of their systems being used as a

test environment for resolving their own issues. Thus, VAR Partners have to set up a necessary back-up

environment to allow simulation of customer issues on a standard SAP system with a similar product

type, release, and version.

Figure 2-3. Remote Connection Page in the SAP Service

Marketplace

http://service.sap.com/access-support


A test system, therefore, should fulfil the

following factors:

Available onsite at VAR Partner

office for immediate use by

support staff

Test systems should be available

at the VAR Partner’s office and is

not meant to be the customer’s

own test system. Test systems

should generally not be used

productively nor should be part

of a transport route.

Based on standard SAP product

version and release

Delivered objects, features, and

functionalities could generally

differ between products and release. Thus, it is essential (and to avoid conflicting results) to

have the same product version and release while performing simulation activities.

Has remote connection to SAP

In the event that a VAR Partner should be able to simulate an incident in their own test systems,

this could be used as an alternative system by SAP support in the event that a connection to the

customer is not possible. Thus, a remote connection to SAP is also necessary.

Should use the partner’s own demo/productive installation numbers

Test systems should use the partner’s own licensed installation. Thus, it is not expected that a

partner uses the installation number of their customers to be used for their test environment.

Test systems should be available for all products with versions and/or releases used by

the customer base. These should have remote connection established with SAP.

2.4 Incident Management System

It is preferred that VARs should use the SAP Solution Manager Service Desk as the primary incident

management system. For VARs supporting SAP Business All-In-One and/or SAP HANA®, this is a

required infrastructure component.

The SAP Solution Manager Service Desk is able to fulfill both first level and second level processing

activities as recommended from the agreement and should be able to cover the following processes:

Receipt and classification

Incidents should be received immediately upon posting by a customer end user. There should be

minimal delay in receipt of the responding support unit so as not to brook any cause for

complaint or frustration on the part of the customer end user.

Test systems can be used to simulate incidents

that could otherwise not be performed in a

customer’s productive environment.


Incidents should have various

classification areas to enable proper

determination of expertise requirement

and urgency status. The most popular of

these from an SAP perspective is the

specific SAP component and priority level.

These should be made available during

incident receipt to allow the support unit to

identify the customer’s needs. It is also

possible that some support operations

also have further classifications such as

for incident type, customer classification,

or service levels.

Ownership and/or assignment

An incident management system should

either have the capability to assign an

incident automatically based on

classification factors or allow manual

assignment to appropriate parties.

Progress documentation

An essential component of an incident

management system is its capability to store

information on the following activities:

o Communication between support

processors and customer end user

o Internal documentation on findings, test

simulation data and results, and call

contents, and discussions

o Date and Time stamps on all activities

o Attachments such as screen shots, error

messages, incident details, logs, and

communication copies

Documentation should not be modifiable to

preserve the integrity of documented

processes.

Different text types or memos should be

available to easily distinguish the documentation type. Examples are ‘Internal Note’ for

discussions exclusively within the support unit and ‘Reply’ solely for responses to customer

end users.

Communication across involved parties

There should be interactive exchange of information between the VAR support unit and

customer end users. Thus, online accessibility of incident management systems play a crucial

functionality for this purpose where end users can monitor progress of their reporting incidents

online and be able to correspond with the support processor as close to real time as possible.

Incident Management systems that can be set up to send automatic emails or phone messages

to either the support team members or customer end users are ideal as they offer alternative

and supportive communication channels.


Tracking, monitoring, and reporting

To enable the support organization to immediately identify incidents that require processing, it is

strongly required to have an incident management system with flexible monitoring and reporting

capabilities. It is highly required to provide for tracking of pending incidents. This should include

information on the unique incident number, priority, short text, processor name and incident

status. It is also beneficial to have information on last changed date, service level adherence, and

escalation flags (if available).

Monitoring should be conducted several times daily while

reporting can be run periodically depending on business

requirements as well as for performance monitoring.

Online accessibility of an incident management system is

a must and should be fully integrated with SAP’s support

network. Partners should ensure that their incident

management systems online address is available for

access through the SAP Service Marketplace. Please see

SAP Note 1285423 for instructions to accomplish this

integration.

Use SAP Solution Manager Service Desk for incident handling and/or integrate 3rd party

systems, if applicable. Online availability should be possible and is integrated with the

SAP Service Marketplace.

2.5 SAP EarlyWatch® Alert The SAP EarlyWatch® Alert is a tool that monitors the essential administrative areas of SAP components

and provides information on their performance and stability. This is a facility that executes automatically

so that customers can react proactively before an issue becomes critical.

VAR Partners are required to activate this functionality for all productive installations of its customer

base. The collected data can then be transferred to the VAR Partner’s SAP Solution Manager (Scenario A

of Figure 2-5). It is always preferred that customers run their own SAP Solution Manager system

(Scenario B of Figure 2-5) and transfers this data therein but a close alternative is for customers to

transfer data into the VAR’s SAP Solution Manager system if they have none of their own. VARs should

review the SAP EarlyWatch® Alert reports of their customers at least four times a year. Any SAP

EarlyWatch® Alert report that receives a critical (red) rating overall should be referred to SAP for further

action.

To activate the SAP EarlyWatch® Alert, simply follow the instructions given in the Best Practice:

Activating SAP EarlyWatch® Alert in End Customer's System. You can access the Best Practice at

http://service.sap.com/var-partner → Solution Manager Setup. You can also use the SAP Online Help

on SAP Solution Manager (http://help.sap.com/solutionmanager71 → Application Help → Application

Operations → Technical Reporting → SAP EarlyWatch® Alert).

Figure 2-4. SAP Solution Manager

Service Desk Reporting

https://service.sap.com/sap/support/notes/1285423


http://help.sap.com/solutionmanager71


Figure 2-5 SAP EarlyWatch® Alert Data Transfer Setup

The report can be generated and read from the SAP Solution Manager in HTML or Microsoft Word

format. Alternatively, it is possible to automate sending HTML reports per email to assigned recipients.

If SAP EarlyWatch® Alert data cannot be processed in a local SAP Solution Manager system, data from

productive systems can be sent to SAP for processing (Scenario C of Figure 2-5). To learn about the

restrictions and to activate SAP EarlyWatch® Alert data to be processed at SAP, please follow the

instructions from SAP Note 1172939 .

SAP EarlyWatch® Alert is most effective when activated for the production system of each SAP

component in your customer’s solutions. This gives you a complete overview of all components and their

effect on performance and stability. For non-productive systems such as quality assurance,

development, training, or test systems the service can be activated as well. As the check thresholds and

rating rules are set for production system, some results in the SAP EarlyWatch® Alert report do not apply

to non-productive systems. E.g. the backup frequency may be of little importance for a training system,

and so the rating for backups in the SAP EarlyWatch® Alert report can be ignored.

To create the report, SAP EarlyWatch® Alert reads system data and analyzes it against set threshold

values. Depending on the analysis, SAP EarlyWatch® Alert issues a red, yellow, or green traffic light to

indicate to what degree the threshold values are exceeded. The symbols are visible both in the report and

as a graphic alert in the system monitoring area of the SAP Solution Manager.



Figure 2-6. SAP EarlyWatch® Alert Workflow

Depending on the criticality of the SAP EarlyWatch® Alert report, necessary action is to be taken

by the VAR Partner. If the overall rating of the SAP EarlyWatch® Alert report is red, SAP strongly

recommends contacting the SAP Partner Support Advisory Center and subsequently open a message to

SAP with an attached SAP EarlyWatch® Alert report within 24 hours. The SAP Partner Support Advisory

Center will analyze the situation based on the report and decide if a Technical Quality Check (TQC) is

required. The SAP Partner Support Advisory Center will inform VAR Partners on the analysis result and, if

required, schedule service delivery of the relevant Technical Quality Check service jointly with the VAR

Partner and its end customer. For details, see SAP Note 1162164.

Figure 2-7 shows further details on the workflow for SAP EarlyWatch® Alert data and activities that could

be performed depending on the result ratings.

In evaluating SAP components, SAP EarlyWatch® Alert monitors the following:

General component status

System configuration

Hardware

Performance development

Average response times

Current workload

Critical error messages and process interruptions

Database administration

http://service.sap.com/support/notes/1162164


Figure 2-7. SAP EarlyWatch® Alert Report Analysis

SAP Note 1257308 provides information with respect to SAP products and components for which SAP

EarlyWatch® Alert is available.

SAP EarlyWatch® Alert for Solutions

The SAP EarlyWatch® Alert for Solutions enables users to gain an overview of the current status of the

entire solution landscape within one consolidated system report. This overview includes historical

developments, aggregated solution KPIs and detailed statistics about dedicated systems of the solution.

The solution-based report consolidates alerts generated by the regular SAP EarlyWatch® Alert (EWA)

monitoring services and classifies them in order to identify potential areas for improvement, such as

performance or stability.

The report tool accesses the Solution Manager Solution Repository and hence provides a link between

standard SAP EarlyWatch® Alert and individual core business processes with regard to performance

evaluations.

Features

SAP EarlyWatch® Alert for solutions...

… is an automated and periodic off-line monitoring service provided by the SAP Solution

Manager

… is solution oriented and comprises all systems relevant to the business processes of

production

… consolidates SAP EarlyWatch® Alert reports, focusing on system key performance indicators

and SAP EarlyWatch® Alert alerts

… reports on “Solution KPIs”

… establishes a relationship between business processes and SAP EarlyWatch® Alert alerts


… facilitates a comparison between system KPIs in order to enable fast detection of main

bottlenecks

… reports on the solution performance as well as the solution stability

… provides statistics about workload and performance, exceptions and changes each retrieved

from the BI of the Solution Manager Diagnostics (SMD)

… reports the current software and hardware components and tracks changes in the solution

landscape

Figure 2-8 SAP EarlyWatch® Alert for solutions in the SAP Solution Manager

The SAP EarlyWatch® Alert topic is also covered in section 2.5 of this guide.

For SAP Analytics, SAP EarlyWatch® Alert is also made available for specific products/releases and in

conjunction with the Remote Support Component. For more information, please visit

http://service.sap.com/rsc.

Knowledge Base and Services Information

To find setup and usage information on SAP EarlyWatch® Alert, do visit the SAP Service Marketplace at

http://service.sap.com/ewa.

All productive systems should have SAP EarlyWatch® Alert data transfers sent to the

VAR Partner on a weekly basis. A compliance rate of 85% for all customer productive

installations is required.

2.6 Support Staff A successful support operation relies heavily on the competencies and expertise of the people

responsible for incident resolution. At an early stage, a VAR has to identify critical areas that need to be

supported, determine the support structure and roles, formulate basic workflow processes, and identify

the infrastructure components required to support operations.

SUPPORT ROLES

Within a support organization, there are some roles that are key for seamless operations. Depending on the size of the organization, the roles could either be shared with other roles or could be owned and performed by a single individual. For instance, for a small support operation, the Help Desk staff could perform both the Help Desk role, Dispatcher, and Coordinator roles. There are times that the Support Manager also performs the Coordinator role. The following are examples of roles that could be identified from any support organization: Help Desk, Dispatcher, Coordinator, and Processor.

http://service.sap.com/rsc

http://service.sap.com/ewa


Help Desk

Support hotline frontline personnel

Receives calls from customers and either (a) creates a new call into the incident management system, (b) for existing incidents, document customer call for processor, (c) for existing incidents with processor, can forward calls to respective processor upon request

May not necessarily have product knowledge but understands key components of incident posting.

Dispatcher

Processes incidents for resolution

Utilizes different tools, knowledge base, own and/or peer expertise to resolve incidents

Simulates or reproduces incident steps in a test environment or customer systems (if allowed)

Communicates with customer on progress, additional information, or provided solutions.

Documents progress and findings in the incident management system

Forwards incidents to relevant parties (higher support levels and/or SAP) if current expertise is insufficient in finding a resolution.

Coordinator

Performs support process monitoring/reporting and ensures processing complies with policies and adherence to targeted service levels

Ensures appropriate resources are available for incident processing on a daily basis (duty roster, substitution).

Manager

Defines strategies and outlays procedures, processes, targets for support operations

Central role during de-escalation operations; either as contact or coordinator for de-escalation procedures and activities

Evaluation and appraisal of support staff

Key decision maker for process improvements

Depending on the size of the support staff and/or the customer base, some of the key support roles can

be performed by one individual.

For some support organizations, the Processor role can be divided into several levels depending on

product expertise. Within the SAP PartnerEdge Channel Agreement, support levels are sub-divided into

two: First Level and Second Level. Following are the duties attributed to each support level:


FIRST LEVEL TASKS

Duties

Accepts the incident

Performs translation (if necessary) for incidents to be sent to SAP

Complete the problem description

- meaningful incident header

- technical information on incident context such as log files

- technical information on the incident system (system id, system type, system name,

installation number, product version and patch levels, database version, OS, GUI version,

localization or language settings)

- comprehensive problem description; including steps leading to the incident and full syntax

of the error message

- surrounding factors ( ex. recent upgrades/transports)

- incorporate attachments when necessary

Checking incident priority

Assigning the proper component

Ensuring availability of remote connection

Searching for previous customer incidents with identical symptoms from various knowledge

bases

Splitting up incidents that describe more than one incident

Summarizing status of incident before forwarding to the next level

First Level Employee Profile

Excellent ability to communicate directly with the customer

Good knowledge of local, country-specific circumstances that may need to be communicated to

other support organizations

Ability to adapt to different situations (for example, escalations). This enables a relationship to be

built with the customer so that his specific requirements can be understood and communicated to

the upstream support organizations.

Basic understanding of the products supported by the Support Desk so that qualified questions

can be asked when entering and completing the message. This includes

- Basic desktop know-how

- General SAP know-how

IT experience and, depending on the Level, detailed knowledge of the supported product or

product area. If necessary, project experience

Familiarity with the terminology used in the company

Readiness to participate in ongoing training measures to further consolidate and update existing

know-how

Fluency in a foreign language (especially English)

Knowledge of the internal communication means (for example, mail program)


SECOND LEVEL TASKS

Duties

Subsequent to First Level and includes the following tasks:

Searches for errors using the data from end user

Checks customizing settings

Looking for fault through …

o system and core dumps

o debugging

o trace analysis

Analyzes technical data and document incident progress

Reproduce and isolate the incident

Decide if incident is due to a defective or non-defective cause

o Propose appropriate system configuration or work-around if the cause is non-defective

o Forward incident to Third Level (SAP) if the cause of the incident is a software defect / fault

and no SAP note is available to correct it

Document the solution approach

Check and test the solution in a test system

Second Level Employee Profile

Finding the solution using their own expertise, solution database, or product documentation

Completing the message by requesting the missing information from the previous Level or

directly from the reporter

Performing a detailed problem analysis (Customizing, dump, trace, debugging)

Provide direct support to the reporter in complex cases (for example, for importing patches, and

so on)

Training new employees by means of internal courses

Collaborating with the SAP Support Organization

Detailed SAP know-how

Technical know-how

THIRD LEVEL TASKS (USUALLY SAP SUPPORT)

Duties

Detailed analysis of recorded traces and error messages

Creating or modifying SAP Notes regarding …

o Identified cause of defect

o Incident resolution process including all material/information (e.g. bug fixes, patches, work-

around description) to update SAP’s support system

Specify expected duration to fix defects by patches, bug fixes, or support packages

Recommend workarounds and alternative solutions

Access customer end user systems through the SAP Support network

o to analyze end user’s system regarding the incident

o assist end user in order to perform the required and applicable incident remedy by using

workarounds or fixes

o change coding, provide fixes, and create patches

A VAR should also clearly determine which product areas will be supported depending on the

products/components installed at their customer base. Foremost amongst these core components for

SAP Business All-In-One are Basis, Financials & Controlling, Sales & Distribution, and Materials

Management. However, VARs should always look into products and/or components installed at

customers to appropriately determine the correct support staffing expertise needed.


DEVELOPMENT AND TRAINING

Support staff should not lack in training opportunities and should continue to acquire skills and

competencies not only through delta training but also onsite experience and knowledge-sharing from

other colleagues. Appropriate knowledge should already be present from support staff with at least two

(2) years’ experience either as an SAP consultant or has been providing support for their respective SAP

components within a similar duration.

The VAR has to ensure that the support staff has similar expertise as its SAP Global Support Center

counterparts in SAP. Thus, it is important that support staff is well-versed with their specific industry

Figure 2-9 SAP Education Certification page

or component areas and has had experience with actual implementation of their product. It is

recommended to supplement existing expertise with SAP classroom training and to evaluate their

knowledge through SAP product certification with the achievement of an SAP Education Associate

certificate at a minimum. For more information on product certification, please visit

http://www.sap.com/education under the Education tab.

Support staff with the relevant role equivalents should take the various e-learning materials as provided

in the SAP PartnerEdge Portal. To view these training curriculums, visit the PartnerEdge Portal page with

the links provided for each specific product area.

The following should be considered:

System Administrator

o Plan and perform the implementation of SAP Solution Manager across all related IT-components by

setting clear objectives for the system infrastructure, implementation process and integration

o Optimize technical team infrastructure

Message Processor

o Provide first and second level support by processing customer messages on different components

o Root cause analysis: analyze root cause of an issue via remote connection and resolve known errors

by means of SAP notes, solved customer messages, documentation or verifying customizing entries

or hardware parameters

o Evaluate problem category and forward to next level of expertise

o If message processor does not find a solution, message is forwarded to SAP Support

Support Coordinator

o Plan and coordinate the support center

o Interact with the Partner Account Manager regarding specific support topics

o Define new services within your SAP Enterprise Support offering

http://www.sap.com/education


PEOPLE CERTIFICATION

The Partner COE program requires the fulfillment of two people certification variants:

Support-specific qualification and

Product-specific certification

Support-Specific Qualification

Every VAR support unit should have at least two (2) support staff who have completed a support-specific

web-assessment qualification, Q_SUPP_1, as a mandatory requirement. A minimum of two achievements

should be fulfilled regardless of the number of products supported.

C_PXSUP_90 or C_BOSUP_90 certification will continue to be accepted in lieu of Q_SUPP_1, until further

notice.

Product-Specific Certification

In addition to support-specific certification, VAR Partners having support staff providing incident

handling services should have at least two product-specific certificates for each supported product area.

These are equivalent to SAP Associate Certification at a minimum. Examples of these product or

application-related certification are as follows:

SAP Product

Family

Exam ID Exam Description

Analytics C_BOBIP_40 SAP Certified Application Associate – SAP BusinessObjects

Business Intelligence Platform 4.0

C_EPMBPC_* SAP Certified Application Associate – SAP BusinessObjects

Planning and Consolidation

C_EPMFC_* SAP Certified Application Associate – SAP BusinessObjects

Financial Consolidation

C_GRCAC_10 SAP Certified Associate – Access Control with SBO GRC 10.0

Applications C_A1LOG_* SAP Certified Application Associate – Logistics with Business All-In-

One Solution

C_A1FIN_* SAP Certified Application Associate – Financials with Business All-

In-One Solution

C_SRM_7* SAP Certified Application Associate – Supplier Relationship

Management 7.0

C_TCRM20_7* SAP Certified Application Associate – CRM Fundamentals with SAP

CRM 7.0

C_TERP10_6* SAP Certified Business Associate with SAP ERP 6.0

C_THR12_6* SAP Certified Application Associate – Human Capital Management

with SAP ERP 6.0

Mobile C_AFARIA_01 SAP Certified Application Associate – SAP Afaria 7.0 Administrator


C_SUPADM_01 SAP Certified Application Associate – Sybase Unwired Platform

Administrator

SAP HANA C_HANASUP_1 SAP Certified Support Associate – SAP HANA

OUTSOURCING OR SUBCONTRACTING

It is also not uncommon for some VAR Partners to outsource some components to other parties outside

of their general area of expertise. For instance, some VARs would outsource either the Basis component

or specialized components such as HR, CRM, or some industry solutions. Such situations are considered

as sub-contracting. It is important to note that the PartnerEdge Channel Partner agreement does not

allow sub-contracting of any maintenance service without explicit approval by SAP. Thus, an audit may

not include services provided by third party and could lead to critical gaps in your maintenance provision.

This could ultimately lead to an audit failure. Thus, do contact your Partner Account Manager for current

SAP policies on this arrangement prior to PCOE registration.

Should an explicit approval be available, do expect that the Auditor may request documentation and

participation from the third-party unit to verify support arrangements and integration of support

operations between both parties. The PCOE auditor may also request that a third-party representative be

present during the audit interview should this be deemed necessary.

Support staff available on a full time basis.

People certification (both support-specific and product-specific) requirements should be achieved by VAR Partner support units.

Each VAR Partner with support staff performing incident management processing should have at least two (2) support consultant certificates PER support unit.

2.7 SAP HANA Test System This section is only applicable for VAR Partners providing support for SAP HANA.

It is a mandatory requirement for VAR Partners supporting SAP HANA to have a functioning test system

for this product. This must be in place, even if they have no customers with SAP HANA systems yet.

Partners must demonstrate that they have the knowledge and ability to set up Root Cause Analysis and

perform SAP EarlyWatch® Alert data transfers via SAP Solution Manager for their SAP HANA test system.

During the PCOE readiness audit (or recertification audit), the following will be checked:

The partner’s SAP HANA test system is connected to an SAP Solution Manager system through

which the functionalities for root cause analysis and SAP EarlyWatch® Alert should be

operational.

Remote connection types SSH and SAP-DB are established and connected to SAP.

For VAR Partners supporting SAP HANA, an SAP HANA test system must be available

which fulfils the following requirements:

Has remote connection to SAP including both SAP-DB and SSH connection types.

Is connected to an SAP Solution Manager system.

Root cause analysis via SAP Solution Manager has been set up and is operational.

SAP EarlyWatch® Alert reports are available to demonstrate that data transfers have been executed through SAP Solution Manager.


Chapter 3. Support Processes

Within a support operation, there are processes that should be present to ensure that maintenance

services are delivered based on defined strategies and methods. These should include standardized and

streamlined procedures from the introduction of new customers to activities performed for both

corrective and preventive maintenance offerings. Procedures should also be in place for critical situations

which could occur outside of normal scenarios.

The audit process considers the following basic processes that are expected to be available for VAR

support operations:

Customer On-boarding

Incident Management

After-Office Hours Support

Complaint and Escalation Handling

Support Readiness Checks

Every support organization should clearly document their support processes as a general guideline for

new hires, for mentoring purposes, and as reference both for improvement and extraordinary

circumstances. It is a good practice to review existing processes from experience by internal staff and

explicit feedback from the customer base. This helps support organizations focus on areas which need

further development, improvement, or modifications.

3.1 Customer On-boarding Within a support operation, there are processes

that should be present to ensure that

maintenance services are delivered based on

defined strategies and methods. These should

include standardized and streamlined

procedures from the introduction of new

customers to activities performed for both

corrective and preventive maintenance offerings.

Procedures should also be in place for critical

situations which could occur outside of normal

scenarios.

3.2 Incident Management Incident and Problem Management could be extremely simple or complex usually depending on several

factors such as:

size of the support organization

incident management system capabilities

organization targets and goals

However, this generally has a basic workflow. Differences occur in the execution but should usually follow

the same seamless process. An incident management support process from the VAR support unit has

the following basic workflow actions:

Incident Receipt

Incident Acknowledgement

Incident Dispatch

Customers have to be familiar with maintenance

procedures and deliverables. VARs should ensure

that an activity exists where support-specific

topics are clearly discussed.


Incident Processing

Incident Forwarding

Incident Closure

Feedback

The Feedback process would be explained further in Chapter 5, Continuous Improvement.

PREPARING AN INCIDENT

Even for the most mature organizations, incidents are not an unlikely event. Thus, it is expected that

customers are dutifully prepared to respond to such situations by appropriately compiling information

necessary to report the occurrence and justify expected outcomes.

Self-Service

Before an incident can be created for the VAR support organization, it is highly recommended that the

customer end user tries to resolve the

incident within their means. This could be

through the use of an available solution

database, help documentation, or training

materials. An end user could also refer the

incident to their own key users, business

process owners, or competence teams.

These individuals or units could perform

initial review of the incident and could

offer potential solutions.

Reporting incidents to a central

competence group within the customer

organization is also a good practice as this

helps to prevent end users from posting the

same incidents to the VAR especially in

cases when the incident occurs with

multiple users within the same period. This

also helps to ensure that expected

outcomes for an incident are correct.

Once the customer has decided that it could not resolve the incident, then it can refer to the VAR support

organization for handling.

Preparing an Incident

It is important for the support organization to have provided clear directions which methods are available

for logging of incidents. Equally important are the details required by a support organization to

immediately process an incident. Following should be

mandatory information for an incident to be processed.

Following are some of these relevant details (see also SAP

Note 16018).

System identification

This would include the system id, system type and

client number as basic information. For incidents

of a technical nature, information on lower-level

components such as the database and/or the

operating system information should be provided.

Customer end users can refer their incidents with

internal key users or business process owners as the

initial resolution step before incidents are raised to

the VAR.




Priority

Customers should be able to appropriate relay the urgency of the incident. The VAR should also

be clear about their priority definitions and properly educate customers which priority levels to

use.

Reporter Details

The customer should supply contact information of the person who can best discuss and

respond to the VAR support processors. For incidents reported with top priority, contact

information and personnel from the customer side should be available at all times.

Product Area / Component

For incidents to be dispatched or routed to the right support team or processor, the reporter

should properly identify the specific product/component where the incident occurs. This would

help to lessen potential delays with incident handling amongst the support unit.

Short Description

Most incident management systems provide a facility for describing the context of an incident in

a brief one-liner statement. This statement should be as descriptive as possible to indicate

transaction codes, error codes, report/program names or other reference terms where readers

could immediately discern or perceive the content of an incident.

Incident Details

Understandably that most reporters want to send an incident off as soon as possible, the speed

by which an incident was created and sent to the support organization would be fruitless if the

support organization only sends it back with request for additional information that should’ve

been included in the first place. Reports of an incident should meticulously prepare their incident

providing the relevant details to avoid further ping-pong situations between the customer and

the support team for incidents that have unclear or incomplete information. Following

information should be included in the incident description:

o Steps performed prior to the incident. This should include field values in case such values

are significant.

o Expected result of the transaction and actual result. This helps the processor to understand

what the customer is attempting to perform and to immediately discern if the customer has

executed the appropriate steps to arrive at their expected outcome.

o Error details including logs, dumps and screen shots

o Situation with the system prior to the incident (Has there been a modification? Was there

a recent upgrade? Are there any identified changes/improvements on the system? Was

this the first time to execute the transaction?)

o Can the incident be reproduced?

o Is the incident happening with just one user or multiple users?

Impact

For issues that have serious business or financial impact, it is important for customers to inform

the support unit of the consequence(s) to the business so the incident can be appropriate

processed with urgency and attention.

REPORTING AN INCIDENT

Depending on the setup arranged with the VAR, an incident could be reported by any of the following

individuals:

End User: any end user from the customer could report an incident directly to the VAR

support organization.


Key User: individuals within the customer organization who have in depth knowledge of the

transaction for which an incident is to be reported on.

Business Process Owner: an individual who has detailed knowledge of the business process

for which the incident is related to. This individual could also have been involved in the

implementation process and is aware of the activities, decisions, and execution of the

company’s business process.

Competence Team: a group of individuals set up by the customer organization to function as

a support unit for its end users. The team is comprised with individuals experienced in the

implementation and execution of the company’s business processes.

Either an individual or unit is responsible for posting an incident, the VAR Support organization should

generally be communicating with an individual which will be herein designated as a Reporter.

A customer would be provided methods and tools by which an incident can be reported to the VAR

support organization. The most popular communication media are either online, phone or email.

Depending on methods used, a customer should be dutifully prepared to provide all relevant details to the

VAR support organization.

RECEIVING AN INCIDENT

There are different methods by which a support organization could receive an

incident from its customer base. This depends greatly on the provided

communications infrastructure as well as the features available from the

incident management system. Information gathered from this process is

significant as it would direct the efficiency by which an incident can be

processed by the support organization.

Execution plans vary depending on the method by which an incident is logged

as discussed in the following topics.

Incident received online

Preferred method

Near real time receipt by the VAR support organization depending on network traffic

Provision of forms for detailing relevant incident information

Depending on incident management system features, can immediately dispatch an incident based on priority and/or component area to a specific support unit or processor

Incident received via phone

Received real time

Requires manual work from the VAR to collect information from the Reporter and post this subsequently to the incident management system

Details can be requested from the Reporter by following a pre-defined form from the incident management system


Possible confusion or misunderstanding of Reporter’s statements which could lead to improper dispatch or delays in processing

Incident received via email

Received near real time depending on network traffic

No guarantee that email is received by VAR support organization pending


their acknowledgement.

Typically contains information in an unstructured format, often leading to the support personnel having to get back to the incident reporter

Requires manual work from the VAR to post the emailed incident into the incident management system


Less possibility for confusion if incident reported can be summarily copied into the incident management system

Incident received via fax

Received near real time depending on network traffic.

No guarantee that fax is received by VAR support organization pending their acknowledgement.

Fax may not be regularly monitored by the VAR support team.

Requires manual work from the VAR to post the faxed incident into the incident management system

Less possibility for confusion as reported incident can be entered verbatim into the incident management system

When a VAR has received the incident and has this subsequently posted in

their incident management system, this can then be reviewed by a support

staff. The support staff could check the following from an incident:

Complete and comprehensive incident details (includes error information, logs, screen shots, steps leading to the incident, expected and actual result)

Verify priority setting. If this is set incorrectly, the customer should be informed of any changes

Confirm component or product area. Utilize various means to match the incident with its proper product/component. For example, if the transaction code is mentioned, an SAP note search can be performed to verify if most notes received use the same component.

Ensure that only one incident has been reported. Otherwise, create additional tickets for other incidents posted.

Support staff can also have a checklist of areas to be reviewed before an

incident can be qualified for processing. Once this has been completed, an

incident can then be assigned to the appropriate support consultant.

ACKNOWLEDGING AN INCIDENT

Once an incident has been received by the support organization, it is

important to immediately provide a reply to the Reporter to state that the

incident has been received. Whether an incident has been logged online, via

phone, fax, or email, a unique identifier should be available. This identifier

usually comes in the form of a number series. This incident number should be

communicated to the Reporter to help identify their specific incident amongst

others.

It is also during the incident acknowledgement process that the initial

reaction time is set.


ASSIGNING AN INCIDENT

Upon receipt and subsequent review, the support staff with the Dispatcher

role can then assign an incident to the relevant consultant. An incident is

dispatched based on the following criteria:

Component/product

Priority

Availability of consultant

Most incident management systems allow for the input of assigned

processors. This could also trigger an automated response through email

upon assignment. Thus, the processor is informed when an incident has been

assigned to him.

There are cases, however, that the Dispatcher role no longer exists. This

could apply to large support organizations where support consultants are

primarily responsible for ensuring that their queues (assigned areas of

responsibility) are properly monitored. Thus, support consultants are

responsible for assigning incidents in their name, ensuring that incidents are

prioritized based on defined criteria, and that incidents that have been

returned for their review and continued processing has been returned to their

specific queues.

PROCESSING AN INCIDENT

Once an incident has been assigned for processing, the Processor

subsequently reviews the contents of the incident. At this time, it could also

be possible that the support employee may perform the following activities:

Determine whether the component / product have been properly assigned. Otherwise, the processor can change the component and subsequently send it back to the Dispatcher for re-assignment.

Verify priority setting and adjust as necessary with proper communication to the Reporter.

Determine whether the inquiry is related to an error or requires consulting work. For the latter case, then it may be necessary to discuss options with the customer.

During processing, a support employee may need to use several sources for responding or verifying their responses to the Reporter. These could be any of the following sources:

Training Materials

Help Documentation

SAP Service Marketplace

SAP Notes Database

Own Solution Database

Peer Networks

Product Forums

In some circumstances, it may also be necessary for a support employee to

simulate the incident through a test system with the standard SAP product

installed. Simulation is needed in the following cases:

Verify if the steps performed by the end user is correct and conforms to proper procedures

If errors are not received in the standard test system, it can be assumed


that the incident is local to the customer’s solution landscape

Confirm that proposed solutions achieve the desired effect on a test system before recommending to the customer.

Support employees should properly document their findings, simulation

efforts, and communication in the incident. This could either be visible or not

visible to customers. Information provided therein could be used by

succeeding support employees to whom the incident could be forwarded to

later on. This information would also be vital to SAP Support in cases when

the incident would be forwarded to SAP Support as this would help to lessen

the effort in root cause determination and would help SAP Support to focus

on other untested areas.

FORWARDING AN INCIDENT

After an incident has been reviewed and processed by a Processor, there may

be instances that the expertise level of the current processor may not be

sufficient and, thus, the incident may need to be referred to someone of

additional expertise or experience. The incident can then be forwarded to the

next support level in some cases. For some situations, this could be forwarded

to SAP.

Incidents forwarded to another level should provide for a comprehensive

summary on activities performed so that the next Processor will not have to

redo the same tasks which would delay the incident resolution process.

Before an incident is forwarded to SAP …

Incident should be written (or translated) into English, if needed

Verify that the incident refers to SAP products and/or third party applications supported at SAP otherwise refer the incident to the proper vendor.

Remote connection has to be checked and should be available upon request.

Contact information completely provided

Complete summary of the incident and inclusion of attachments, if necessary, has been provided including detailed information on tasks performed, SAP notes used, and customer situation at current.

Appropriate approvals (within the VAR support process) has been received to allow forwarding of the incident to SAP

When an incident is forwarded to another Level, it is most prudent to inform

the customer that the incident has ‘changed hands’. Thus, a reply to the

customer should be made to provide information that the incident has been

forwarded to the next level of support or to another component as the case

may be.

For incidents forwarded to SAP, the VAR should decide whether they will act

as interface to the customer or if the customer themselves would be

responding directly to SAP. It is recommended that the former is used and to

use the latter for incidents that are forwarded to SAP after the VAR’s

business hours.


CLOSING AN INCIDENT

An incident can be closed if the customer confirms that the solution proposed

by the VAR has resolved their incident. The VAR can consider the following

strategies for closure:

Allow the customer to close the incident on their own. This could lead to situations when an incident could be left unclosed for a long time unless the customer is constantly reminded to do so.

Conduct follow-up sessions regularly to remind customers of incidents that could be closed. This approach would require a resource and corresponding effort to follow-up with customers. This may not be an acceptable task for VARs with a huge customer base.

Allow for automatic closure after a reasonable period depending on priority level. This should be clearly known by the customer to avoid complaints. This helps eliminate any further manual follow-ups from the support unit.

It is important to ensure that customers have provided either a reply to

confirm that their incident has been resolved or that they explicitly close the

incident.

For incidents that have also been referred to SAP for resolution, the VAR

should not forget to explicitly confirm the incident with SAP. Nevertheless,

SAP follows automatic closure processes and the incident will be closed if

there has been no action after a specific amount of time.

An incident management process must be in place and documented in alignment with

the incident management system.

3.3 After Office Hours Support Both SAP maintenance offerings, SAP Standard

Support and SAP Enterprise Support, provide 7x24

round-the-clock message processing services globally.

SAP utilizes all major support hubs within Asia, Europe,

and the Americas to allow continuous support to its

customer base everywhere in the world.

VAR Partners are not expected to set up an operation

as vast as SAP, but is enjoined to use SAP’s global

support network to similarly provide 7x24 support to

its local customer base. For VARs supporting either

SAP Business All-In-One and/or SAP HANA, a

connection must be set up between its incident

management system and SAP’s support backbone

using SAP Solution Manager as the interface between

both parties. Outside of this facility, VARs need to offer

after-office hour support through its own resources

VARs are enjoined to utilize the SAP

Support network to provide 7x24 support

for its customer base.


and facilities. The following common strategies could be used for this purpose:

SAP Solution Manager

7x24 support operations

On-call support

SAP SOLUTION MANAGER

SAP encourages its VARs to use the Service Desk functionality within the SAP Solution Manager to allow

automatic forwarding of priority incidents to SAP outside business hours. This is performed through

customization of the Service Desk facility to identify out-of-office hours and to also identify certain

conditions for immediate forwarding such as for components that are mainly processed through SAP

support; i.e. component XX-SER*.

The default and most common set up with the SAP Support network is to only forward incidents under

priority Very High and to do so only outside the VAR’s business hours. Therefore, incidents from other

priorities are not forwarded and could be processed by the VAR support team during their regular

business times.

7X24 SUPPORT OPERATIONS

For some mature and/or larger VARs, a fully-staffed 7x24 operation may already exist with support staff

working beyond office hours on roster or similar to SAP operations, where support could be handed over

to other subsidiaries outside the local business hours. Hence, incidents can be reviewed at all times and

where resolution activities are able to proceed even outside a customer’s normal business hours.

For VARs with a small customer base, this is not a recommended approach due to its cost implications

and the minimal possibility of incidents being posted outside regular hours.

ON-CALL SUPPORT

For VARs who do neither use SAP Solution Manager Service Desk nor have a 7x24 fully staffed support

operation, incidents received after office hours could be routed to an on-duty support staff via its support

hotline. On-duty support staff could determine the urgency of the call and can determine whether further

expertise may be required within the support team or if the incident necessitates referral to SAP Support.

VARs often provide on-call support providing alternate phone numbers to customers that is most often

an individual mobile number of specific support staff. This is not encouraged as this does not allow

permanency and could change as many times as support staff changes. It is not recommended to

consider this strategy during an audit. It is more preferred to utilize the dedicated support hotline which

should automatically route to other numbers as an alternative rather than providing multiple numbers for

customers to remember.

A 7x24 support offering is a mandatory requirement and should normally be

accomplished using the SAP Solution Manager Service Desk functionality for

connectivity with the SAP Support backbone.


3.4 Handling Complaints and Escalations

COMPLAINTS

During the processing of an incident, a customer can contact the support unit if they are, in any way,

displeased with either the progress of resolving an incident or the solution quality. In such cases, the

customer could contact the support organization to address such complaints and these have to be

properly noted and monitored to avoid the complaint from further escalating.

Complaints have to be reviewed and ownership has to be set where an individual takes responsibility for

addressing the complaint and ensuring that a satisfactory response is provided.

The complaint owner has to dutifully monitor that the incident progresses and is resolved to the

customer’s satisfaction and to constantly provide feedback and communication as well.

After a complaint has been resolved, it is a good practice to review the case and to derive possible

lessons that could be gleaned from it as a means to improve the overall support performance and quality.

ESCALATIONS

Escalations would normally be viewed as either a functional escalation or a hierarchical escalation.

A functional escalation is generally executed

within the a normal incident handling process

where an incident could be forwarded

(“escalated”) to the next higher support level if

lower levels are unable to offer a satisfactory

solution.

A hierarchical escalation involves the elevation

of an incident not only through support levels

but also across management or different lines

of business. This involves situations when an

incident may require exceptional processing

and may deviate from the normal support

processing procedures. These situations have to

be properly identified and should have a defined

action plan. Though this can occur in the middle

of incident processing, these can also be identified at the onset of incident receipt. Thus, escalations

could be identified through specific triggers such as:

Severe financial or business impact: This pertains to a significant loss of business or revenue

until an incident is resolved. This would normally merit attention from high-level management

and require immediate resolution and constant monitoring.

Production Down: Though it is not uncommon to have situations when an application goes

down, the situation becomes more critical if it has been clearly identified that the application

may not be brought up within a short period. For example, a customer experiences a hardware

crash and realize that they have no available backup from the past months. System could not be

restored immediately and without prolonged effort which could lead to potential business loss.

Service Level Exceeded: There could be financial aspects to missing service levels which could

necessitate extra attention and faster processing.

Go Live Endangered: Go live is a highly critical phase not only involving the customer, their

business, but other parties as well such as the implementation team. This has the potential to

affect both financial and business aspects, such as added consulting man days, re-adjustment of

resources, activities, and timelines. Thus, incidents contributing to a possible delay in go live

needs to be addressed expediently.

Escalation procedures are triggered by specifically

defined events or situations that would normally merit

expedited processing due to business or financial risks.


Similar to complaints, escalations should have clear ownership for resolution, identified action plans, and

constant monitoring and communication until its resolution.

In cases when SAP becomes involved in an escalation situation, it is important to ensure that SAP has a

clearly identified contact from the VAR side as well as the customer to properly coordinate activities,

plans, and resources. For such situations, it is also a necessary requirement to have remote connectivity

available to ensure that assistance can be provided by the SAP Support network globally and around the

clock.

Support processes should be in place, should be followed in day-to-day operations, and

should be documented clearly and in line with the incident management system.

Chapter 4. Marketing & Communications

Though support primarily keeps a low profile in most cases, a support business is nonetheless a

significant factor for continuing business. VARs have to capitalize on its successful relationships and

achievements, its staff competencies, and its support capabilities should not take a back seat.

For small customers who may hardly have the manpower and infrastructure to build their own application

competencies, a lot rides on its VAR to provide assistance and advise not only on continuing

improvements of its business and productive operations but also on day-to-day incidents that also

contribute to the overall product experience. Having an application that runs seamlessly is a boon and

having immediate support with excellent service and quality is not far behind.

At the onset of the sales cycle, support should be introduced as part of the offering. VARs may have

varied support offerings but this should be complementary to SAP’s support offerings as well. In this, the

VAR should be able to properly communicate and sell their maintenance services clearly outlining their

relationship with SAP as and co-delivery partner of SAP support services.

4.1 Support Presentation VARs should have a compelling

presentation of their support services

and this could be further supplemented

by collaterals. A support presentation

should generally have the following

elements:

Description of competencies

and capabilities

Start the presentation with an

introduction of the support

organization, its structure,

goals, targets, and key

achievements. Capitalize on

resource competencies such as

certifications and experience.

VARs should have available presentation material discussing

various support-specific aspects to set proper expectations

with respect to support operations and delivery.


It is also relevant to showcase the growth of a support organization if it conveys the results of

continuous improvements, maturity, and experience of the organization as a whole. This helps to

advertise to customers/prospects that the organization shows and promotes growth that could

benefit them as well.

Showcase support infrastructure and resources

The customer could be presented with existing applications, systems, hardware to indicate the

VAR’s commitment to invest in the support business. This could also be used to elaborate on key

operations and how the infrastructure integrates with the VAR’s processes.

Infrastructure components that would be of relevance for SAP integration are the following:

- SAP Solution Manager

- Network infrastructure for remote connectivity

- Test systems

- Communications systems

- Incident Management Systems

- Back-up facilities

Discuss support operations, procedures, and activities

A support presentation should provide its audience with an idea of the required tasks and

activities that would also be expected from the customer end user in relation to their interaction

with the support organization. This should already introduce the different means and methods

by which the support unit can be accessed and the different roles that come into play during an

actual incident handling operation.

A brief workflow of the support processes providing an overall view of the support activities

should be available. Different processes and variations in incident handling could be discussed

such as escalation processing, complaint handling, and after-office hour procedures.

Presentation of support offering(s)

VARs could offer either one standard offering while some could offer variations. As customers

come in different sizes, different needs, and orientation, it is also possible that VARs could offer

different levels of support services, while some could offer additional services separately.

At a minimum, VARs should review their duties for SAP and the End Customer as provided in

Exhibit 4 of the SAP PartnerEdge Channel Agreement. Thus, all services delivered through SAP’s

support offering should be clearly packaged into a VAR’s standard offering and these should be

clearly aligned with SAP. For instance, since SAP offers 7x24 support for SAP Enterprise Support

customers, a VAR should not charge extra for providing support after office hours and should

delegate this task to SAP. This is provided that the VAR has set up the appropriate and

recommended infrastructure for connecting their customer to the SAP Support network.

It is also vital that VARs do not forget the different SAP Technical Quality Checks (TQCs) that a

customer can utilize in certain situations from SAP. These have to be clearly provided as a

service and benefit and should be showcased in a VAR’s support offering.

Customer successes and references

A support introduction presentation would be a VAR’s initial gateway to advertise their

capabilities and market themselves as the right choice for lasting relationships. It is important to

earn achievements and highlight actual successes in a presentation material. Actual references

are added advertisements and having good quotes and feedback from existing customers offers

factual and realistic samples that boost the VAR’s credibility with an audience.


SAP ENTERPRISE SUPPORT

Competing in today’s global marketplace increasingly requires organizations to operate IT landscapes

that are shaped by global business networks and innovative business processes. Because of this,

organizations need the proactive expert support that can help them manage the complexity of integrating

solutions across and IT ecosystem and optimizing each application’s life cycle.

The SAP Services organization, with the support of the Partner, can provide the expert support that can

help customers optimize their SAP and non-SAP solutions, minimize risks, accelerate innovation, and

manage the lifecycle of applications.

At a minimum, VARs should look into SAP Enterprise Support offering and build their services,

competencies, and capabilities within this framework.

For more information on SAP Enterprise Support, please visit the Support area through the SAP

PartnerEdge Portal product pages.

STRUCTURING YOUR POTENTIAL SUPPORT OFFER

Although this training module is designed to help you

sell support as part of your offering, it is possible that

your organization has not spent much time in

structuring and formalizing what your offer is in this

area. So let’s explore what support could mean to you

as a VAR.

Support is much more than just maintenance or

reactive incident management.

The support offering from a VAR, as an example, could

be structured in three parts:

Basic services that are required by the majority of your target customers. This also means you

don’t have to ‘negotiate’ what needs to be done to keep a customer’s solution running. For

example, software maintenance which provides for guaranteed response times 24 hours a day

as part of a service level agreement to investigate “breakdown” or critical faults. Remember,

many of your customers have periods when they are working outside normal hours. This is often

when they are busy and therefore these extra hours are the most critical.

Additional services that you can package as an insurance, such as disaster recovery for a

catastrophic incident, sure as a fire, where the servers are lost but a back up held offsite could be

reloaded to a spare server, getting the customer back live in a short period of time. These can be

charged and delivered at a premium, but it is important to ensure there are not too many

‘Premium’ Packaged offers, so that the customer does not constantly find they are not covered.

Ten years ago many insurance companies went down this route of offering a high degree of

choice in extras, but when customers always found the policy didn’t cover the specific incident

they had encountered, they became dissatisfied and went in search of companies offering a

comprehensive base level, with a few, very specific, premium offers. The same is true with

support. 90% of what 90% of your customers want needs to be in the Base Level, with only

highly specific increments falling into the Premium category either because of their unusual

nature or very high cost to provide.

The final category of support service you need to be able to offer is Ad hoc. This usually is

charged to the customer ‘as required’ but may involve a retainer, or a facility where the

customer can, for example, use 5 hours a month for free, but pay thereafter. Ad hoc support

may be used for such things as managing the back-up process when the IT manager is on

holiday, or optimizing the database remotely. Typically not part of a standard support pack, but

something the customer may want, and is best delivered using the support team.


A support-specific presentation package should be prepared and actively used for both

prospects and customers. It should have comprehensive information on support

offerings, support processes, infrastructure, as well as contact methods.

4.2 SAP Communication VARs should always keep abreast of any new strategies, offerings, and events within the SAP community.

Thus, a VAR should have regular and ongoing communication with their different interfaces to SAP.

These regular contact points are the Partner Account Manager and the SAP Partner Service Advisor.

SAP PARTNER ACCOUNT MANAGER

Objective: The Partner Account Manager is tasked to develop and enable the

business of their assigned VARs and help them extend to their fullest

potential, applying mid-long term view. The Channel Manager will support and

drive development of new business areas for partners.

Tasks

Helps VARs to analyze and leverage business potential using available processes and best practices;

ensures partners become self-sufficient in this.

Creates, monitors, and reviews business and marketing plans together with the assigned partners

using standard tools and templates.

Responsible for partner pipeline management, coverage and reporting.

Monitors overall partner performance including partner satisfaction and develops action plans to

correct as necessary.

Communicates SAP support strategy to Partners to ensure Partners understand the services value

proposition as well as requirements and obligations.

Coordinates with Partner Services Delivery organization where appropriate.

Keeps SAP internal teams informed about partner’s service/support requirements,

recommendations, and other general service/support related feedback.

SAP PARTNER SERVICE ADVISOR

Objective: Acts as a trusted advisor to his/her personally assigned

partners, driving the desired objectives while also acting as feedback

channel into SAP to improve our go-to-market strategy to the ecosystem.

Tasks

Develops an ongoing enablement plan for partner organization based on individual targets and

requirements

Provides technical knowledge related to SAP product and solutions, new features, and

information on new releases


Helps coordinate access to many of the benefits that the partner organization is entitled to

according to SAP PartnerEdge program level

Proactively informs partner organization of updates and rollout of SAP initiatives

Helps partner understand the program framework and requirements and identify opportunities

to maximize partner performance in the SAP PartnerEdge program

Connects partner with experts from various SAP organizations, particular with specialized

technical resources in industry business units, solution management, and so on

Acts as another feedback conduit into SAP

VARs should have regular communication with their Partner Account Manager and

Partner Services Advisor.

4.3 Maintenance Agreement While VARs may have presentation material to introduce or explain their support offering, a legal

document exists that cements these provisions and clearly identifies elements that are deliverable

between the VAR and its customer base. This should set proper expectations between both parties to

ensure that support will be available at agreed times and shall be executed through defined methods of

delivery.

A maintenance agreement could solely be a software maintenance agreement or could be extended to

include hardware components and could then be a system maintenance contract. The focus of a PCOE

audit is primarily on the software maintenance component as system maintenance involves firmware and

firmware which is not covered by the standard SAP maintenance.

Elements that could be included in a

maintenance agreement between a VAR and

its customer base are the following:

Availability and accessibility of

software versions / releases

Explains delivery methods for

software upgrades, corrections

and/or updates

Corrective maintenance processes

and procedures

Discuss the different facilities

available for addressing incidents or

problems. This also explains the

standard processes or procedures

for effecting incident or problem

resolution activities.

Preventive maintenance

processes and procedures

Identifies facilities, applications, activities, and services providing aid in ensuring stability and

continuous operation of the customer solution.

Service level agreements, if any

States committed response and resolution times for identified conditions or scenarios.

Identify facilities and/or applications inclusive and in aid to support provision

This could mention accessibility of websites for product or support-related topics, solution

databases, forums, and services to assist in maintenance provision.

All customers should have a valid maintenance

agreement detailing support deliverables and

provisions.


VARs should review basic maintenance offerings from both the SAP Standard Support and SAP

Enterprise Support portfolio and strive to include elements from these offerings into their own basic

support services.

Section 4.1 of this chapter further explains the possibilities of having additional or packaged offerings as

well as ad hoc services that could be provided on top of a general basic offering. These could be

mentioned during the audit interview but are not subject to evaluation or review except in situations

where these are defined as inclusive amongst the SAP standard offers.

Content of maintenance agreements are reviewed with particular attention to the following risk areas:

States provision of services, facilities, or responsibilities that are deemed deliverable through

SAP but are not inclusive within SAP’s maintenance offering

Are not aligned with committed deliverables by the VAR in comparison with current documents

or presentations made available to customers

Has no defined support elements

The audit requires the submission of a maintenance agreement template or any scanned copy of an

existing maintenance agreement signed with an indirect customer with the following conditions:

Submitted template or scanned copy should not contain any price points. These could either be

removed or covered upon submission.

Typifies the basic maintenance coverage for indirect customers.

Between basic maintenance templates with SAP Standard Support and SAP Enterprise Support

scope, do submit the template / copy which includes the SAP Enterprise Support scope.

VARs should provide maintenance agreements for all customers that are in alignment

with their own offering and/or SAP’s.


Chapter 5. Continuous Improvement

“Change is constant” and this is still be true for a support organization. As the industry grows, matures,

and with increasing technology changes, support should not stand idly but should be open to review

existing processes and infrastructure against ongoing trends. Customer feedback is also a strong factor

for promoting changes and improvements.

Whether a support organization improves for its internal benefit or due to customer suggestions, a VAR

should promote a culture of feedback acceptance not only from its customers but also from internal

staff. Thus, it is essential that there are continuous monitoring tasks to determine ongoing performance.

These same monitoring activities should be subject for review to assess alert conditions that could

require more proactive measures or to examine current trends that may trigger added services and

support.

This chapter examines different ways and methods by which a VAR could execute simple monitoring

tasks and utilize results for service improvements.

5.1 Support Reporting Regardless of the size of the support organization or the amount of incidents received from an existing

customer base, reporting on support performance

and trends should be acknowledged as an integral

part of support processing. This requires

frequency, ownership, and an incident

management application that can produce relevant

reports demanded by the business.

Reports have to be distributed to appropriate

individuals who may need statistics and trends

analysis information to recommend or adjust

services and resources where it is needed. This

section tries to cover the more common and

relevant support reporting for VARs such as service

level reporting, customer incident reporting ,

team/processor reporting.

SERVICE LEVEL REPORTING

SAP has provided service levels pertaining to response and processing time targets for VARs based on

priority level. VARs are to consider the availability of regular statistics to document their performance

with respect to these defined targets. A high level overview of overall support performance against

service levels could be created for management review as well.

The following elements can be considered to produce such the required information to evaluate service

level performance:

Incident number

Uniquely identifies an incident when additional review may be needed.

Creation Date/Time

Actual date/time when the incident has been posted by the end customer. This is usually be

used to start calculation for initial response time.

Monitoring of support performance should be a

regular activity supplemented with reports

targeted at measuring identified KPIs.


First Response Date/Time

Actual date/time when incident has been acknowledged and replied to by the support

organization. This would be used for calculating initial response time usually computed as time

elapsed between first response date/time and creation date/time.

Last Change Date/Time

This indicates the period by which the incident has been last replied by either the support unit or

the end customer.

Status

This indicates the current progress of the incident.

Completed Date/Time

Indicates the date/time when an incident has been classified as closed by the support unit. This

may or may not necessarily indicate that the customer has confirmed that the incident could be

closed.

Processing Time

Indicates the amount of time spent by the support team in processing the incident. For some

incident management systems, this could indicate total processing time by the support unit or

could be processing time per group/level within the support unit.

It should be clear that the processing time should not include the amount of time spent while an

incident is pending at the customer end. Though it is also good to have a facility to compute

processing time at the customer side, in cases when a customer complains about the speed by

which an incident is processed.

Service Level Indicators

For easy reference, especially by Management, it is recommended to have a column or any

indicator in the service level reporting that clearly shows whether defined service level targets

have been met. Thus, if a VAR provides service levels for initial response time and processing

time, there should be two separate indicators whether these elements have been met for each

specific incident.

CUSTOMER INCIDENT REPORTING

An incident management system should have a facility by which a customer end user, on their own,

should be able to display, list, or report on their own incidents. This could also be produced by the

support organization as a value-added service or as an ongoing measure for keeping customers informed

of pending incidents while it can also be used as a conversation piece to elicit feedback from a customer.

A good customer incident report would contain the following elements:

Incident number

Uniquely identifies an incident when additional review may be needed.

Creation Date/Time

Actual date/time when the incident has been posted by the end customer. This would usually be

used to start calculation for initial response time.


This would indicate the period by which the incident has been last replied to by either the

support unit or the end customer.

Status


Completed Date/Time



closed.

For VARs with committed service levels, additional data could be provided as with service level

reporting.


TEAM/PROCESSOR REPORTING

Support staff should also monitor their own performance and this should be performed regularly

especially if this involves their individual KPIs. Depending

on performance targets for the support staff, there are

some key elements that should be available in either a

team or processor-specific reporting. Team/Processor

reporting is normally being used by support management

for regular evaluation or assessment of support staff.

For individual reporting, the following elements should be

considered and should be filtered either specific to team or

individual support processor:

Incident number

Uniquely identifies an incident when additional

review may be needed.

Creation Date/Time

Indicates the actual date/time when the incident

has been posted by the end customer. Would

generally have relevance to the report especially

when needed to assess processing time.


This would indicate the period by which the incident has been last replied to by either the

support unit or the end customer.

Status


Completed Date/Time



closed. This information is relevant in conjunction with the status of the incident as the

expectation should be that the incident is confirmed by the end customer. If this has not yet

been performed by the customer, then it would be good practice for the processor to check with

the customer if the incident can be closed or if they are satisfied with the solution.

Processing Time

Indicates the amount of time spent by the support team in processing the incident. For some

incident management systems, this could indicate total processing time by the support unit or

could be processing time per group/level within the support unit. This is relevant since it

indicates the effort utilized for resolving an incident. For team or individual statistics, it would

also be good to note if the Processor/Team has processed the incident efficiently or if the

Processor/Team requires additional training or expertise to resolve incidents faster.

For VAR Partners with service level adherence as a performance indicator, then it is important to include

some elements from the service level reporting within the processor/team reporting as well.

Within an audit exercise, it is expected that VAR Partners are able to demonstrate or produce reports

that are generated out of their primary incident management system.


MANAGEMENT REPORTING

It is also a good practice to have consolidated and

statistical information for support management

or company management on a regular basis. Do

note that support should also be considered as an

avenue for additional business and services, thus,

reporting can also be reviewed or assessed for

indicators that would trigger these.

For management, it could be important to present

the following information in summary:

Number of incidents received

Resolution rate

Number of escalations, its progress, and

lessons learned

Service Level Adherence

Status reporting

Statistical inputs and/or trends analysis would also be welcomed for the following reporting information:

Customer(s) with most number of incidents

Component(s) with most number of incidents

Reporting on support process compliance as well as support performance should be

generated on a regular basis and should be available for support staff, customers, and

management.

Support reports should be aligned with support-specific targets and contractual

commitments.

5.2 Feedback Gathering While it is important to get information from customers on support performance, internal staff could also

provide valuable feedback in their execution of support processes. Thus, there has to be regular

communication with the support organization, its internal staff, and the customer base to determine

areas where services can be improved, what can be removed, or what needs to be changed.

INTERNAL FEEDBACK

Within the support staff itself or within the company, providing avenues for staff to contribute their

experiences and lessons learned on-the-job is

a valuable forum for considering

improvements with support operations. Thus,

having regular meetings with support staff

and encouraging experience sharing as well as

fostering a culture where suggestions are

respected and considered should be available.

Internal meetings could also be used to

discuss improvement areas and obtaining

direct feedback from colleagues on

acceptability or receiving comments on

potential issues that could best be identified

from different perspectives with a larger

group. It would also be easier to gravitate

Regular incident reporting could also show trends

that can be translated to potential services and

offerings.

Regular incident reporting could also show trends

that can be translated to potential services and

offerings.


towards improvements or changes if these have been discussed with staff that will be immediately

affected by these.

Have regular meetings with support staff to discuss experiences, issues, action items,

and on-going performance. All meetings should be properly documented and reviewed.

EXTERNAL FEEDBACK

Customers definitely have a stake in service improvements by the support organization. Thus, there

should be constant and regular communication with customers on improvement areas while also offering

a forum to get their overall experience. Though it is important to get individual feedback per incident, this

might become too redundant and some customer end users would tend to ignore this. However, a regular

survey session, such as one conducted annually for instance, might be more welcome.

For support-specific surveys, it is important to have a minimum amount of questions and to focus on

areas specific to support. These could be any of the following factors:

Response/resolution time

Solution quality

Staff competence and behavior

Auditors can request for the most current survey results if this is conducted on a regular basis by the

VAR Partner. The Partner COE questionnaire should include this information as well.

Regular survey sessions should be conducted with customers at least on an annual

basis. Feedback should be requested for relevant factors such as efficiency, solution

quality, staff competence and behavior.

5.3 Service Improvement Based on feedback from internal and external sources,

the VAR should also review current trends and

technologies as possible indicators for upgrades,

improvements, or process changes.

VARs would generally offer a standard support

package but could potentially offer additional services

or premium offerings depending on need or request.

As customers mature and expand their solutions, it

would also be necessary for a VAR to be aware of these

changes and expand their own offerings to

accommodate changing demands and needs.

Competition would also drive improvements where VARs can also look for offerings that would

differentiate or relegate their maintenance services in a different level from other VARs. Thus, constant

development of support staff is a necessary investment and keeping abreast on strategies related to their

products and support services should be encouraged.

Thus, a VAR’s support offering should evolve and grow not only with its customer base but with emerging

technologies. Though it is a good practice to always be a few steps ahead of others, VARs have to clearly

determine areas of need and ensure alignment with existing resources and infrastructure.


There should be available avenues for process improvement that is regularly reviewed

and discussed with relevant parties. This should generally be spearheaded by Support

Management.

5.4 Support Readiness Activity The VAR Partner has to ensure that its customer has the required knowledge with respect to the VAR

Partner’s support operations and has fulfilled all required infrastructure and activities to ensure that

maintenance services can be delivered seamlessly. Customers should have proper expectations with

respect to services that are delivered within maintenance and how to request for it.

A support readiness activity should be established between the VAR Partner and the Customer to

address the following elements:

Prepare and validate infrastructure required on both parties to ensure seamless communication

and delivery of maintenance services.

Gather information from the customer to identify key contacts for both business and technical

aspects.

Communicate maintenance deliverables both by the VAR Partner and of SAP.

Discuss and clarify support procedures and processes.

Identify action plans for gaps identified where follow-up work needs to be addressed by either or

both parties.

It is expected that a support readiness activity should be completed for all customers, especially for

those under SAP Enterprise Support, at least prior to go live and to ensure a re-visit of this task on an

annual basis.

Within the PartnerEdge exhibit, a support readiness activity is also known as the Initial Assessment

service. This could be fulfilled with the execution of an SAP Enterprise Support Setup Service via SAP

Solution Manager. However, a VAR Partner can define its own activity to render the same content. As this

activity validates the preparedness of both the VAR Partner and the customer with respect to

maintenance delivery, this is a critical element for ensuring that both parties are aligned and informed.

A support readiness activity should be available and conducted for all customers to set

proper expectations with respect to maintenance deliverables and allow a

comprehensive review of support setup between both parties.


Chapter 6. SAP Solution Manager

To deliver first-rate support to their customers VARs require access to knowledge hubs in SAP’s service

infrastructure, transparency on their customer’s solutions, as well as secure remote access to customer

systems. SAP Solution Manager is the adequate tool for VARs to deliver high-quality support to their

customers and to fulfill their daily tasks efficiently.

Figure 6-1. SAP Solution Manager in a Service Provider environment

The VAR is the central contact of indirect customers for questions regarding the SAP solution. Tools are

needed which makes the technical complexity of their customers’ solutions transparent, and supports

the entire SAP solution lifecycle. Integrating VARs into the SAP Global Support Backbone allows SAP and

VARs to support their customers together, leverage valuable synergies, and add value for themselves,

SAP, and customers. There are functionalities which are tailored for VARs such as that for Service Desk.

Where such VAR-specific functionalities exist, this platform is to be used.

VARs sell SAP solutions which are tailored to the requirements of small and medium-sized enterprises, to

which they provide first and second-level support. It is assumed that VAR customers may not have their

own SAP Solution Manager. Thus, the VAR should operate an SAP Solution Manager system for its

indirect customers in the event that SAP requires to deliver services under this platform and where

customers may not be able to set up one on their own

To date, SAP Solution Manager is a mandatory requirement for VARs supporting SAP Business All-In-

One and SAP HANA. It remains highly recommended for other product families. Starting from July 2013,

the SAP Solution Manager 7.1 version is required for VARs as SAP Solution Manager 7.0 ends

mainstream maintenance by end of 2013.

The SAP Solution Manager currently supports VARs in performing the following processes and related

tasks:

Project Administration

Solution Documentation

SAP EarlyWatch® Alert (EWA)

Incident (and Problem) Management

Maintenance Optimizer

Maintenance Certificate

Technical Monitoring


Business Process Monitoring

Root Cause Analysis

6.1 Customer Landscape Validation VAR Partners should ensure that all customers are identified or maintained in their SAP Solution

Manager system. At a minimum, the productive landscape should be defined. This paves the way for

utilizing customer information for various functionalities as mentioned above.

During an audit process, the SAP Auditor may conduct a validation check of the SAP Solution Manager

system with respect to the availability of all maintenance customers. Thus, the VAR Partner should then

ensure that customers are maintained, for instance, within the Technical Monitoring or System

Monitoring areas and especially where the Service Desk functionality is used.

Failure to have customers defined within the SAP Solution Manager can entail delays in provision of

services as most functionalities require this specific information to be available. Thus, where SAP

Auditors may deem that customer data in the SAP Solution Manager system is missing, an audit failure

could result. Thus, as best practice, where new customers are added into the VAR Partner’s customer

list, identification of the customer’s landscape (as soon as it is available) should be defined in the SAP

Solution Manager system.

It should also be noted that, at a minimum, the customer’s productive landscape should be maintained in

the VAR Partner’s SAP Solution Manager system. However, defining other system types is also

encouraged.

All maintenance customers should be identified in the SAP Solution Manager system of

the VAR Partner.

6.1 Project Administration Project Administration allows the definition of various project components such as the system landscape,

roadmap, project standards (such as keywords and document types), scope, persons involved,

accelerators, and critical milestones, among others. VARs should document new implementation

projects or upgrade projects in an SAP Solution Manager system. This is highly encouraged to ensure

that relevant data with respect to project (and later on, solution) components are maintained especially

by people involved in this activity.

Figure 6.2 All Systems defined in the SAP Solution Manager


Amongst the initial preparatory tasks for

starting project administration via the SAP

Solution Manager is the identification of

the project as well as the project type.

Figure 6-2 below shows the initial screen

for identifying key elements in the project.

Amongst the most relevant elements

defined at the initial project creation

activity are the following:

General Data allows the identification of

project management owners, project

language, current status, planned and

actual timelines, planned and actual

resources used.

Scope identifies the functionality or

solution relevant for the project as well as

the roadmap used.

System Landscape identifies the systems relevant for the project

Milestones set specific dates for achieving

defined milestones and also to document

the actual start times when milestones

were achieved.

Organizational Units identifies specific organizations or

units that are affected by the project

Project Standards defines specific keywords,

documentation types, project status values to be used

throughout the project.

After completing these initial definitions for the project, the

Project team can proceed to define the business blueprint,

define business scenarios, processes, process steps and

the upload/import of relevant project documentation,

materials, and templates as the project progresses. Figure

6-3 shows the screen used for during the design stage. The

involved business processes are defined in the left panel

which shows the business process structure. The right panel allows the project team to provide related

documents, transactions and object information, test data, involved roles, configuration data, and even

related incidents where available.

Figure 6-2. Project Administration Work Area


After go live, the project documentation can then be transferred to a solution for maintenance activities

or technical and business process monitoring tasks.

It is highly recommended that customer projects (such as implementation or upgrades)

should be documented via the Project Administration facilities of SAP Solution

Manager.

6.2 Solution Documentation

As defined in SAP’s Support Standards documentation, the solution “is the entirety of all system

components and processes that represent a central function or a business area in an information

system.” A solution includes the technical landscape information via the logical components referenced

by business processes. Implementation project documentation can also be adapted or transferred into a

solution.

VARs should strive to ensure that all customer solutions be made available via an SAP Solution Manager

system, whether this be the customer’s own or hosted by the VAR. At a minimum, the customer’s core

business process(es) should be documented.

Solutions can be manually created from the bottom up, imported from existing documentation (such as

spread sheets), or can be created through solution validation functionalities within SAP Solution

Manager; such as Reverse Business Process Documentation (RBPD).

This chapter identifies three (3) types of documentation in a solution; technical landscape

documentation, business process documentation, and custom code documentation.

Figure 6-3. Business Blueprint Work Area


TECHNICAL LANDSCAPE DOCUMENTATION

The technical landscape documentation is

generally performed within the initial

configuration of the SAP Solution Manager

system. In SAP Solution Manager 7.1, the

Landscape Management Database or LMDB

was introduced which takes system

information from the System Landscape

Directory (SLD) into the SAP Solution

Manager system.

As a prerequisite, all systems (so called

“Managed Systems”) involved in the solution

should be connected to the SAP Solution

Manager. Thus for VAR customers, customer

systems (defined as managed systems) could

be performed within the early stages of the

SAP Solution Manager configuration. This

allows the capture of relevant technical data such as installation numbers, systems ids, hardware

information, and client numbers to be made. The necessary remote links (RFCs) can also be generated

automatically as part of the initial setup phase. These also allow the possibility to connect to customer

systems directly.

Once the technical data of systems are captured, a logical component can be defined which groups

systems that logically belong together. For example, defining which systems are connected to the

production system such as the development, test, or even training systems and grouping them together

as a logical component. This also defines the transport route between systems.

Figure 6-4. Managed Systems Configuration

Customers should document core business

processes in an SAP Solution Manager system.


BUSINESS PROCESS DOCUMENTATION

Following the technical solution landscape documentation, the business processes can then be

documented. These could be defined from existing implementation content from the SAP Solution

Manager business process repository (BPR), importing process documentation from other mediums

where interfaces are available at SAP, or processes manually entered by the customer or a combination

of these options. For customers that are already live and where project information was not documented

via the SAP Solution Manager, a V AR Partner could consider all the options above. It is recommended to

have at least the core business processes defined at the least.

The best option is to build documentation from the Implementation phase is by using the Project

Administration functionality within SAP Solution Manager. Information maintained therein can then be

transferred into a Solution for maintenance, monitoring, and continuous improvement.

With SAP Solution Manager, processes can be documented in three (3) levels; business scenario,

business process, and process steps. A business scenario is a set of processes that define a business

task on a macro-level. A business processes is a set of logically-related activities performed to achieve a

defined business outcome while a business process step is an elementary activity performed to

accomplish a process. As such, documenting business processes could include project information,

business blueprint, configuration, training material, test documents, and transactions.

The same business processes documented in an SAP Solution Manager system can be used to set up

Business Process & Interface Monitoring (BPIAM). This covers monitoring of application-related as well

as technical-related aspects of the business process instead of the classical system monitoring by

components.

CUSTOM CODE DOCUMENTATION

As with documentation of standard SAP business processes, SAP also understands that each customer

has their own specific requirements and unique processes. Thus, the possibility to make custom objects,

programs, reports, etc. These should also be documented especially for the following reasons:

- Modifications could be lost during an upgrade that has not been carried out properly

- Validation of usage to identify modifications that have been unused for a significant period

and could increase maintenance cost and performance losses

Figure 6-5. Business Process Documentation


Figure 6-6. Custom Code Documentation

To learn more about solution documentation from SAP support standards, visit

https://service.sap.com/supportstandards. Learn more about SAP Solution Manager functionality

related to solution documentation at https://service.sap.com/alm Solution Documentation &

Implementation.

You can find detailed information on how you can document your customer solution including a helpful

step-by-step guideline at http://service.sap.com/alm → Application Life-Cycle Management for VARs →

Solution Documentation.

It is highly recommended that customer’s core business processes are documented

and/or maintained in an SAP Solution Manager system.

6.3 Incident Management Incidents during the operations of mission critical applications can cause severe business loss if they are

not properly managed, their root cause identified and their effects minimized by immediate corrective

action. The IT Service Management (ITSM) functionality within SAP Solution Manager helps both

customers and partners to accelerate the resolution of support incidents, to increase the availability of

the IT solution and minimize negative business impacts, and to gain 100% transparency on issues and

challenges.

Figure 6-7. Incident Management for VARs

https://service.sap.com/supportstandards

https://service.sap.com/alm

http://service.sap.com/alm


For VAR Partners, it is highly recommended to use the SAP Solution Manager ITSM for handling the

incident management process. VAR Partners offering support for SAP Business All-In-One and SAP

HANA are mandated to have SAP Solution Manager Service Desk operational regardless of any third

party incident management system used. For SAP Solution Manager Service Desk, the Support Provider

scenario should be used as there are other scenarios available for other user types.

Provided that the SAP Solution Manager system has established an operational connection with the SAP

Support backbone and where appropriate customer authorization are available, VARs can download

information related to its customer systems as defined from the SAP Service Marketplace into their SAP

Solution Manager system. This helps to minimize manual creation and / or update of customer systems

by the VAR Support team.

Within SAP Solution Manager 7.1, VARs have the option to use either the work centers or the ITSM user

interface. SAP Work Centers have been widely used in the previous SAP Solution Manager 7.0 version

where SAP Solution Manager 7.1 offers a few changes which should barely affect customer users who

have been working with the work center interface since.

VAR Partners should ensure that all current maintenance customers are defined in the Service Desk

system. This should allow any customer user to log incidents with their support provider should this be

necessary and critically in urgent situations. SAP Auditors can validate the existence of all customers in

the Service Desk functionality where needed. Thus, completeness in this aspect of the Service Desk

functionality configuration should be ensured.

User Types

There are three user types that echo the authorization profiles that are created for the IT Service

Management in SAP Solution Manager. These are Key User, Processor, and Administrator.

Key Users pertain to customer users and are granted limited authorization to primarily post incidents,

reply to the support unit, and confirm incidents posted. Figure 6-8 shows the basic ITSM interface for a

key user’s Home screen. From this screen, customer users can report incidents to the VAR support

team, display all messages created by the user, and to also have a widget (Figure 6-10) that shows

incidents that requiring user action.

Figure 6-8. Key User ITSM Interface

For creating

incidents

Incident List


A Processor role is expected to be part of the VAR support unit and has required authorizations to view

customer messages for incident processing. Processors could create incidents on behalf of the

customer base, process them, assign incidents across the support organization, forward messages to

SAP as well as to respond to incidents sent to SAP.

Processors could have access to reporting capabilities for ITSM, the capability to build and/or maintain

knowledge articles, maintain time recording, and the possibility to convert incidents to problems and/or

change requests provided these functionalities were set up with ITSM.

Figure 6-9. “Action Required by Me” widget for Key Users

Figure 6-10. User Interface for Processor role


The Administrator is responsible for the maintenance of the IT Service Management functionality. This

could include creation and maintenance of users, configuration, customization and improvement of the

functionality, as well as providing support and resolution efforts for incidents related to the IT Service

Management. Thus, additional authorization is provided to this user for performing stated tasks on top of

those held by a Processor role.

Administrators would be relevant for instances when there are new customers and where these have to

be defined within ITSM along with respective user ids for new customer users.

VARs have to ensure security of its customer data by strictly utilizing the provided authorizations for

specific roles. Using full authorization or Processor authorization for customer users is strictly disallowed

and would result to an audit failure. These could be checked by SAP Auditors to ensure that customer

users have delimited authorizations which prohibit visibility of other customer systems, decrease

authorization to perform tasks that can affect the processing of incidents, and disallow forwarding of

incidents to SAP except for potential Very High priority incidents raised outside business hours.

Amongst the relevant features of the ITSM functionality that can be used are the following:

Service Level Agreements can be set up to trigger specific actions (i.e., sending emails to a

target group / individual) based on a defined set of conditions such as the customer priority,

category.

Multi-level Categorization allows better classification or grouping of incidents relative to

defined criteria. This helps support staff to identify the required expertise for an incident.

Knowledge Articles can be created by a VAR to document incidents and solutions that can be

referenced by other users or by the support staff itself. These articles can include keywords that

could be used when searching for potential solutions to incidents.

Time Recording is essential for situations when effort utilized requires documentation. This

could be for reporting purposes, or in some cases, for potential billing. Times recorded can be

further classified based on work or activity performed.

Access to the SAP Notes Database can be performed directly from ITSM where the user is

redirected to the SAP Service Marketplace where an SAP notes search can be performed. SAP

Notes can be attached to incidents for reference by customer users or other support staff.

Support Reporting has been significantly improved with the availability of either list reporting,

BW reporting, and some pre-defined BI Dashboard applications

Figure 6-11. Home Screen for Processor role


With the integration to the SAP Support backbone, incidents posted via the SAP Solution Manager can be

forwarded seamlessly to SAP Support without having to manually create a separate incident via the SAP

Service Marketplace. To cater for assisting VARs in providing 7x24 support, SAP Solution Manager can

automatically forward Very High incidents to SAP outside defined business hours by the VAR. For such

cases, SAP then relates directly to the customer without the necessity of having VAR support staff

available during those times.

Where VAR Partners offer after-office hours support through SAP via the SAP Solution Manager Service

Desk, an SAP Auditor can validate that business hours are appropriately maintained per customer.

Where this has not been set up for some customers, after-office hours support will not work and, hence,

incidents on Very High that are posted beyond business hours will remain at the VAR Partner’s SAP

Solution Manager system until its next business day / hour. Insufficient setup on this aspect could result

in an audit failure. Thus, this has to be ensured for each customer and any new customer, thereafter.

As an advantage of integration, ITSM can receive incidents from other inbound channels such as

projects, solutions, technical and business process monitoring applications and other functionalities

running within SAP Solution Manager that can either manually or automatically trigger creation of

incidents.


To find setup and usage information on the Service Desk functionality, do visit the VAR-specific partner

pages on SAP Service Marketplace at http://service.sap.com/var-partner . Here you will find information

on e-learning materials, training roadmaps, configuration and setup information, usage information, and

various white papers on the incident management and application life-cycle management topic.

For guided configuration assistance, SAP offers channel partners the Expert Guided Implementation

Session for Incident, Problem, and Request Management (ITSM) for VARs. This is an efficient and

interactive possibility to set up SAP Solution Manager Service Desk in a defined period of time. This

service is designed for VARs to support them during setup and configuration of Service Desk. For

available schedules within your region, please check http://service.sap.com/solutionmanager

Services Expert Guided Implementation Expert Guided Implementation Calendar

The SAP Solution Manager Service Desk functionality is the recommended incident

management system platform for all VARs. It is mandatory for VAR Partners supporting

both SAP Business All-In-One and SAP HANA to maintain all customers in the service

desk functionality to ensure that incidents can be forwarded to SAP through this

medium.


http://service.sap.com/solutionmanager


6.4 Maintenance Optimizer The flexibility of SAP applications and high supportability standards has led to a considerable increase in

the number of software components that are used by individual customers and that

Figure 6-12. Maintenance Optimizer in the SAP Solution Manager

can be installed centrally on one server or distributed over multiple servers. For example, SAP ERP 6.0

contains more than 50 different software components. To efficiently manage the resulting combinations,

professional support is necessary. So far, customers selected the relevant maintenance updates from an

unfiltered list of software packages in the SAP Service Marketplace and downloaded them. Then the

customer had to import the patches into the development system, test them in the quality assurance

system and finally release the patches to the production system. These steps are now simplified by the

SAP Solution Manager Maintenance Optimizer, thus the customer can always have an overview of the

maintenance activities in all systems and solutions.

As part of the SAP Solution Manager, the Maintenance Optimizer offers a comprehensive procedure for

software maintenance, including:

1. Maintenance Optimizer shows relevant maintenance files for the customer’s solution.

2. Select the required packages and approve the download of the maintenance files.

3. Download the software.

4. Import the software (furthermore uses familiar tools such as SPAM, SAINT, …)

5. Close the maintenance procedure.


To find setup and usage information on the Maintenance Optimizer, do visit the SAP Service Marketplace

under http://service.sap.com/mopz.

http://service.sap.com/mopz


Figure 6-13. Maintenance Optimizer interaction with the SAP Global Support Backbone

It is mandatory for all customers supporting SAP Business All-In-One to ensure that the

Maintenance Optimizer functionality is operational at all times.


6.5 Maintenance Certificate It has always been important

to SAP that our customers

receive full support for their

SAP solutions. This includes

the delivery of software

corrections and

improvements that can boost

an IT solution’s performance

and stability. For example,

SAP offers the maintenance

optimizer to support an end-

to-end, fully pre-configured

maintenance management

process. Today, the

maintenance optimizer is

the central application

within SAP Solution

Manager to control and

ease maintenance of your

customer’s SAP solutions.

Maintenance Optimizer was integrated with software lifecycle manager service to further automate the

download of support packages and SAP enhancement packages as well as the deployment of the

packages to satellite systems connected to SAP Solution Manager. The integration with SAP’s

Figure 6-15. Automatic Distribution of the Maintenance Certificate for Customers supported by

a VAR’s SAP Solution Manager system

transport management system makes the management of all software and configuration changes

consistent.

Another improvement was the introduction of a maintenance certificate. The certificate enables software

logistics tools to identify your customers’ system and the exact scope of your customer’s corresponding

SAP maintenance agreement. This will also improve the quality of your customer’s SAP solution by

preventing patches from being deployed to the wrong system accidentally.

Figure 6-14. Automatic Distribution of the Maintenance

Certificate for Customers with their own SAP Solution

Manager system



You can find detailed information how to use the Maintenance Certificate on the VAR pages on SAP

Support Portal at http://service.sap.com/var-partner → Application Life-Cycle Management for VARs →

Maintenance Management. To find general setup and usage information to Maintenance Certificate, do

visit the SAP Service Marketplace under http://service.sap.com/alm SAP Solution Manager in Detail

Maintenance Certificate

6.6 Technical Monitoring The Technical Monitoring work center provides tools and capabilities for monitoring system landscapes

defined in the SAP Solution Manager system or the Landscape Management Database (LMDB). Figure 6-

15 below shows the various features available from this work center the foremost being the centralization

of all alerts via the Unified Alert Inbox.

Within the Technical Monitoring work center, an SAP Auditor can validate whether customers are defined

with their productive solution landscape. This is relevant information for other functionalities within the

SAP Solution Manager system and can also be used for technical landscape information of customer

systems. VAR Partners have to ensure that at least all customer productive systems are maintained in

this section, particularly under System Monitoring.

Figure 6-16. Technical Monitoring and Alerting Capabilities in Detail




The following features describe various capabilities under the

Technical Monitoring work center. These can be implemented

centrally from the VAR Partner’s SAP Solution Manager

system or preferably through the customer’s own SAP

Solution Manager. It is preferred that customers use this

functionality with their own SAP Solution Manager system as a

local network infrastructure is a relevant consideration for

real-time data availability.

Unified Alert Inbox

Central access point to handle all types of alerts

Efficient alert handling based on consolidation of single alerts to alert groups

Integration of most common alert handling mechanism as status tracking, incidents, notifications and 3rd party integration

Drill down from alert type to alert groups, alert instances and single metrics and events

Integration of analysis capabilities as problem context and monitoring applications

System Monitoring

Provide status overview regarding technical system including instances, databases and hosts

Allow to access landscape information and problem context for technical system

Drill down from status information to single metrics and events provided by End-to-End Monitoring and Alerting

Visualize metrics and events including thresholds and current rating / value

Jump-in capability in metric viewer including zoom functionality in detail information Process Integration Monitoring

Growing PI landscape complexity and distribution leads to growing requirements towards a central monitoring approach

Reduce the TCO by providing one central entry point combining monitors for PI overall status with drill-down options

Enable tight integration with: - System Monitoring and Alerting - Root Cause Analysis - Notification and Incident Management

Relieve productive systems from individual monitoring activities by central collection of monitoring data

Reduce time for regular as system health checks and hand-over procedures as well as from incident detection to root cause analysis

End User Experience Monitoring

Automated execution of recorded end user scenarios

Measurement of availability and response times from end user point of view

Client performance data is correlated with server side performance data

Direct access from monitoring to Root Cause Analysis (End-to-End Trace Analysis)

Deep integration in End-to-End Monitoring and Alerting Infrastructure

Support of Metric Reporting, SLA Reporting and Management Dashboards

Figure 6-17. System

Monitoring Views


Business Intelligence Monitoring

Central system status overview for all technical components involved in SAP Business Intelligence Solution

Capability to monitor cross-system SAP Business Warehouse process chains and single process chain steps

Central monitoring of Business Objects specific jobs and correlation to system specific metrics

Central monitoring of SAP BW queries and templates

Integration of Business Intelligence specific alerts in Alert Inbox including Notification Management, Incident Management, Task Assignment and forwarding to 3rd party

Reduce the TCO by providing one central entry point combining monitors for overall status

Connection Monitoring / Interface Channel Monitoring

Central status overview for connections between SAP systems based on pre-selected RFC destination definitions

Support of peer-to-peer connections (two managed systems involved) and scenario specific connections (more than two managed systems involved)

Access to SAP Incident Management and SAP Notification Management

Complete integration in End-to-End Monitoring and Alerting Infrastructure

Interface Channel Monitoring

Provides customers with transparency regarding technical interface landscape covering RFC calls, Web Service calls as well as PI message handling

Allows mapping from technical interface information to human understandable entities by usage of Interface Channels with appropriate attributes

Delivers an unified approach to visualize the different interface types including sufficient monitoring and alerting for performance, usage, availability and exceptions

All customers with productive installations should be defined in the SAP Solution

Manager system, particularly, the Technical Monitoring work center.

6.7 Business Process Monitoring During operations, exceptions may arise from within business applications. Effective and efficient handling of these exceptions is a crucial factor for both: an optimized total cost of operations and smooth business execution. The exception handling standard explains how to define a model and procedures to manage exceptions and error situations during daily business operations. The advent of more complex and diverse business scenarios crossing application borders plus the immense volume of business transactions processed today require an exception handling that is scalable, open and central, and embedded into business operations and sup-port processes. The business process champion and the responsible business process operations team have to define a model and procedures for handling exceptions and error situations during daily business operations.


These procedures describe what proactive monitoring activities have to be executed to detect business-critical exception situations and what corrective actions are required in the given context. The procedures also describe who is responsible for certain activities in the business process operations team or the business unit. The execution of these procedures can be supported by monitoring and alerting tools within the business process and interface monitoring concept. After the exception handling model has been defined, the business process and interface monitoring standard supports the monitoring of the mission critical business processes, enabling customers to identify problems long before typical IT alerts would be triggered.

Business process monitoring includes monitoring activities, alert and problem detection, notification of experts, error handling procedures, and well defined interface towards end-to-end root cause analysis (a separate standard). Today’s system landscapes are often decentralized and consist of various interfaces to different systems, legacy environments, where customers and vendors use different technologies. All those interfaces need to be monitored in terms of processing errors, backlog situations and performance.

Figure 6-18. Business Process Analysis and Monitoring


The Business Process Monitoring functionality within the SAP Solution Manager system offers the

following features:

Business Process Orientation. All alerts are (uniquely) assigned to specific business process

steps and/or to specific interfaces. Subsequent business process steps that might be affected

are immediately visible.

Proactive Alert Monitoring. Early warning of

(technical) incidents before end users report it.

Alert History. Storage of historic alerts, logging

of alert confirmations, comments for problem

resolution.

Auto-reaction Methods. Emails and SMS

messages can be sent to appropriate support or

business employee. Provision of pre-filled alert

information/context.

Service Desk Integration. Service desk

messages can be opened in dialog or background.

Service desk messages can be automatically filled

with meaningful alert information. Messages can

be tracked.

Central Documentation. Facility for central

documentation of business processes, error

handling procedures and escalation paths,

monitoring responsibilities.

Customer-specific Monitoring. Easy integration

of customer-specific monitors via customer

3rd Party Tool Integration. Alert from other

monitoring tools can be brought in business process context via CCMS integration.

Service Level Reporting Integration. Offers pre-configured SL reporting, trend analysis for job

runtimes, trend analysis for throughput & backlog integrators.

BI Integration. Flexible ad-hoc reporting with business process relations, pre-configured web

templates, trend analysis for job runtimes, trend analysis for throughput & backlog indicators

Cross-Application Monitoring

Interface Monitoring

6.8 Root Cause Analysis In today’s distributed, multi-technology customer solutions with multi-channel access through diverse

devices and client applications, analyzing the root cause of an incident requires a systematic top down

approach to finally pinpoint the primary cause. End-to-end root cause analysis offers a systematic

analysis and resolution of incidents for a distributed mission critical customer environment.

For instance, if an end user experiences a performance problem in his browser, the performance hit may

be in the client, in the network or somewhere in the server environment, which itself comprises different

instances of also different technologies. Server-side processing may take place in an SAP Netweaver

Enterprise Portal (based on Java technology), then reach out to an SAP ECC backend (based on ABAP

technology) and finally call the database and the storage subsystem for data retrieval. A performance

problem or functional defect may occur at one or all stages of this round trip launched by the end user

from the browser. Root cause analysis tools help identify the specific component which causes a

performance bottleneck.

Figure 6-19. Business Process

Status Indicators


The standard root cause analysis offers systematic analysis and resolution of incidents for a distributed

mission critical customer environment. The goal is to identify and provide:

o an immediate corrective action (workaround) to restore service operations as quickly as possible with minimal disruption to end users by isolating the area of concern

o a complete solution to the issue at hand

Operationally, root cause analysis tools are designed to work towards reducing the number of resources in each step of the resolution process. A small team of support consultants with technical core competence in root cause analysis and an expert for the specific component who can delve deep into the component is enough to drive the issue and nail it down to a component. Additionally, the root cause analysis infrastructure is

open for fast track integration of new SAP technologies,

applications and also for third-party software.

The following features are offered in the SAP Solution

Manager Root Cause Analysis functionality:

E2E Workload Analysis: General performance overview for heterogeneous solution landscape

E2E Change Analysis: Statistical change data cross all technologies based on daily snapshots

E2E Exception Analysis: Statistical exception data for trend analysis or review exception

E2E Trace Analysis: Identify the problem causing component (performance and functional) and jump-in to detailed component specific trace analysis for single user request

System, Host and Database Analysis: Central, safe and remote access to file system, OS and DB including links to read-only monitoring and administration tools like CA Wily Introscope.

Figure 6-20. Root Cause Analysis for Mobile Applications

Figure 6-20. Root Cause Analysis for

Mobile Applications


ROOT CAUSE ANALYSIS FOR SAP HANA

For VAR Partners supporting SAP HANA, setting up Root Cause Analysis to actively monitor an SAP HANA test system is a mandatory requirement for support authorization. Therefore, during an audit exercise, the VAR has to be able to show that their SAP Solution Manager system is able to show real time data being transmitted from their SAP HANA test system. To ensure that data is current, it is preferred that an SAP HANA test system exists within the VAR Partner’s local area network.

The Root Cause Analysis functionality should be operational and actively monitoring an

SAP HANA Test System for VAR Partners supporting the SAP HANA product family.


Chapter 7. Partner COE Audit Process The primary purpose of this set up guide is to provide ample information to discuss the different

elements required for establishing a Partner Center of Expertise that meets the defined standards by

SAP. It is expected that the previous chapters have been read and clearly understood before a VAR

triggers the audit process.

7.1 Relevant Roles for the Audit Process VAR Partners opting to deliver support for their customer base, or are opting for VAR-Delivered Support,

are required by SAP to certify their Partner COE through a stringent audit process. This process involves

several key personnel working with the VAR to commence, execute, and achieve this certification. The

following roles are relevant for the audit process; Partner Account Manager, Partner Services Advisor,

Partner Certification Auditor, and the Judging Committee. The tasks performed by these roles are further

detailed below.

Partner Account Manager

Works with the Partner to assist and explain the various VAR support delivery models

Receives Partner decision on support model preference; VAR-delivered support or SAP-delivered support

Informs the Partner Services Advisor (PSA) on VAR’s support model preference Partner Service Advisor

Works with the Partner to assist and explain the various VAR support delivery models

Receives Partner decision on support model preference; VAR-delivered support or SAP-delivered support

Informs the Partner Services Advisor (PSA) on VAR’s support model preference Partner Certification Auditor

Conducts audit session with VAR.

Creates audit reports based on audit findings, documentation, and interviews. Submits to PCOE judging.

Participates as VAR Partner interface for Judging

Communicates certification results with VAR Partner and internal SAP relevant personnel Judging Committee

Receives audit report from Auditor.

Reviews audit report findings and recommendations and ascertains compliance against Partner Center of Expertise requirements and standards.

Liaise with the Auditor for clarification and immediate improvements, where necessary.

Communicates audit results to the Auditor. Before and after the audit process, The Partner Account Manager and the Partner Services Advisor

would be the best resources within SAP to assist the VAR Partner with respect to the audit process.

Before an audit, these interfaces can help to clarify the Partner COE requirements at the current period.

After an audit process, these roles can also be referenced for guidance with respect to fulfilling the

recommendations as may be required by the audit report.

The Partner Certification Auditor (PCA) becomes available to the VAR Partner only within the audit

period. The PCA is an SAP employee with extensive experience on the Partner COE audit process and

requirements and, hence, is an invaluable resource to ensure a successful achievement of support

authorization. PCA recommendations are documented in a report which is provided to VAR Partner

where improvements are noted. During the audit process, the PCA can either validate application usage

(such as SAP Solution Manager) directly or conducts an interview process which helps to clarify aspects

of the VAR Partner’s support set up and usage.


The Judging Committee is comprised of senior support employees at SAP Active Global Support with

expert knowledge on PCOE operations. They review audit reports to cross-check compliance areas and

can add improvement suggestions where necessary. In conjunction with the findings from the PCA as

documented in the audit report, an audit result is decided by the Judging Committee which is later

handed over by the PCA to the VAR Partner as either a pass or fail rating.

7.2 Audit Types Depending on the Partner’s current support authorization status, the Partner COE program offer three

(3) audit types; Readiness Audit, Validation Check, and Re-Certification. VAR Partners have to gauge

the appropriate audit requirements by understanding the scenarios where specific audit types are

relevant.

READINESS AUDIT

From February 2014, all new VAR Partners should undergo an audit exercise that would ascertain the

availability of a Partner COE infrastructure and process before customers are acquired. This helps to

ensure that a support operation will be in existence and is readily available to provide maintenance

services for new (or even transferred) customers.

The primary difference between VAR Partners that undergoes a readiness audit exercise with other audit

types is its absence of customers through which delivery if support services and execution of support

operations could not be assessed. Another clear difference is the mandatory interview required between

the Auditor and key support roles within the VAR Partner’s Partner COE such as the Support Manager.

A VAR Partner should commence the setup of a support operation following SAP standards as soon as

possible following its acceptance as a Value-Added Reseller of SAP. The required infrastructure,

processes, and people certification should be completed and application or registration for the readiness

audit can be made thereafter. VAR Partners should ensure that registration is executed well before any

deal is to be signed so as not to hinder or delay deals in cases where the initial certification checks find

gaps in support requirements.

During this audit exercise, the Auditor would evaluate all key components of a Partner COE operation

such as:

Incident Management system with SAP Solution Manager Service Desk being mandatory for

VAR Partners supporting SAP Business All-In-One and/or SAP HANA. Auditors will require a full

demonstration of end-to-end incident handling processes.

Remote connection infrastructure strategies

Full time support staff with required support consultant certification

Test Systems for products supported

SAP Solution Manager functionality knowledge

Support introduction or presentation materials for understanding the VAR Partner’s

maintenance offer.

Customer maintenance agreement

Knowledge of SAP maintenance provisions for both the VAR Partner and indirect customers

Support processes and procedures including documentation available. This includes all key

processes for incident handling, escalation/complaint handling, support readiness activities,

support reporting and feedback gathering.

PCOE requirements may change over time and, thus, it is always a good exercise for the VAR Partner to

have active communication with their Partner Services Advisor and Partner Account Manager for any

new developments on support authorization requirements.


Where a VAR Partner completes the readiness audit successfully, support authorization is granted for a

12 month period commencing from the audit interview date. This allows the VAR Partner time to acquire

customers and implement solutions to yield productive systems.

VALIDATION CHECK

Before the 12 month period allotted for VAR Partners who has successfully achieved support

authorization via the Readiness Audit, a validation check should be conducted. This should be requested

explicitly via a support message (see Section 7.3) with short text “Request for Partner COE: Validation

Check”. The expectation at this stage is that the VAR Partner has acquired a customer and was able to

bring their customer systems into productive operation. Thus, SAP can conduct a short validation

exercise with respect to the integration of customers into the VAR Partner’s execution of its support

services and operations.

Once completed successfully, the support authorization of the VAR Partner is further extended for

another 12 months.

RE-CERTIFICATION

VAR Partners who has achieved support authorization through either a validation check (starting from

February 2014), via a certification exercise (before February 2014) or via a re-certification exercise are

required to re-certify their Partner COE support infrastructure and operations at least three (3) months

before their current support authorization expires.

A Partner COE re-certification activity re-evaluates the VAR Partner’s performance against SAP’s quality

matrix which includes continued maintenance of mission critical elements such as remote connectivity to

SAP and SAP EarlyWatch® Alert data transfers (where applicable), low customer maintenance

termination ratio, low billable messages count, absence of customer complaints, SAP Solution Manager

adoption and usage, as examples. An audit interview may also be conducted where necessary to clarify

support concepts.

A successful re-certification grants the VAR Partner a further two-year extension of their support

authorization.

7.3 Audit Process Between the audit types as mentioned in Section 7.2 of this chapter, the audit processes are generally

similar while the audit content offers differences.

The audit process contains 3 stages; Registration, Audit, Judging. The following sections discuss the

audit process as executed for the different audit types.

REGISTERING FOR AN AUDIT

Step 1. Complete Your Checklist

Prior to Registration, the VAR Partner should download the

latest PCOE Checklist available from the SAP PartnerEdge

Portal. This can be found directly from the “Key Resources”

area. The Partner should fully complete the questions in the

checklist and provide supporting documents, where

applicable.


The checklist itself has the following sections:

1. Confirmation: This requires a valid signatory of the company attesting to the correctness of all

responses provided in the checklist. Where English is not used for either the checklist responses

or submitted documents, the VAR Partner has to provide confirmation that SAP Auditors may

use translation tools and services (private or public) to convert data and information into

English.

2. Supported Products: the VAR Partner needs to confirm products that will be supported by their

Partner COE. It is expected that all products with status “Authorized” shall also be supported by

the VAR Partner unless the corresponding support dimension for the product have been

maintained as “Opted Out”.

3. Current Support Performance Data: Chapter 4 focuses on performance figures as may be

gathered through SAP internal systems and the VAR Partner’s own. This helps SAP to

understand the VAR Partner’s continued commitment for SAP standards by maintaining high

compliance rates and satisfaction levels.

4. Partner Center of Operations Structure: Chapter 5 requires information pertaining to the

physical elements of a Partner COE setup. This includes support staffing, incident management

system used, remote connectivity strategy, test system availability, systems and database used.

5. SAP Solution Manager: Requires details of the SAP Solution Manager installation and

functionality usage where applicable. This section also clearly discusses the remote connection

requirements and necessary authorizations to be provided for an SAP Auditor to validate usage

and set up of the SAP Solution Manager system.

6. Support Processes: Chapter 7 requests for information pertaining to support procedures and

respective documentation.

7. Continuous Improvement: Requests information pertaining to support-specific reporting and

satisfaction surveys used.

8. Combined Certification: Chapter 9 of the checklist should only be answered if the audit request

is by more than one VAR. Further, the VARs involved should be PartnerEdge VARs opting for

VAR-Delivered Support and are related to each other; i.e. subsidiaries.

VARs should endeavour to provide answers to all questions from the checklist and to provide supporting

documents where additional information may be necessary. Documentation submitted should have the

following attributes:

Current and in use by the VAR during the audit period.

Original content created for VAR purposes. It is understood that in some presentation materials

with respect to SAP-related offerings, content could be copied from SAP. However, it is

expected that VARs are able to properly discuss such content should these be requested by the

Auditor.

Content is applicable to answer information required from the checklist question.

Step 2. Register Solution with SAP

This step is only applicable for VARs with SAP Solution Manager installed.

Once the checklist has been fully accomplished, the Partner has to prepare that a Solution has been

created in their SAP Solution Manager system and where data has been forwarded to SAP.

Note: During the basic configuration of the SAP Solution Manager system, a default solution

– SAP Solution – is created. This can be used if no other solution has been created in the SAP

Solution Manager system.


Once a Solution has been identified, this has to be explicitly registered with SAP. To do so, from the SAP

Solution Manager system, access the Solution Manager Administration work center and select

Solutions. Solutions created in your system will be displayed in a table. Verify that the solution for your

SAP Solution Manager system is sending data to SAP. This could be checked from the column ‘Sending

Data’ where a tick mark should be present for your solution.

If no tick mark is present, data is not being sent to SAP. To do

so, select option . Once selected, you

will be prompted to select your data transfer settings.

Choose either ‘Send All Data’ or ‘Send Production Data’

and save your settings. Solution information will then be

transferred to SAP.

Step 3. Log an SAP Support Message

To register for an audit, the VAR Partner should log a

message with SAP Support preferably via the SAP Solution

Manager Service Desk (if being used). The following tasks

should be performed by the VAR Partner:

1. Maintain the secure login details of the SAP Solution Manager system (if used) in the SAP

Service Marketplace.

- It is preferred that default user id SAPSUPPORT is used for the SAP Solution Manager

login.

- Please reference the table below for the required authorizations for the user.

2. Open the connection types R/3 Support, HTTP Connect or SAPGUI+Browser for the next

seven (7) days.

3. Create an SAP Support message under component SV-BO-REQ following short text template

below specific to the audit type requested:

Readiness Audit : Request for Partner COE certification: Readiness Audit

Validation Check : Request for Partner COE certification: Validation Check

Re-Certification : Request for Partner COE certification: Re-certification

4. If SAP Solution Manager is used as the primary incident management system, do provide a

template or reference user id example for a customer user.

5. Except Validation Check requests, the SAP Support message should contain the following

attachments:

- Fully completed and signed Partner COE Checklist

- Supporting Documents

If preferred, the VAR may request for container where all documents can be compiled and sent

to SAP.

As the SAP Auditor can directly validate the set up of the SAP Solution Manager for VAR Partner usage,

the following authorization roles should be available for the user id provided to ensure that the necessary

checks can be performed.

Figure 7-2. Solution Table


User ID Authorization Role

SAPSUPPORT Work Centers:

- SAP_SMWORK_IMPL

- SAP_SMWORK_TECH_MON

- SAP_SMWORK_SYS_MON

- SAP_SMWORK_DIAG

- SAP_SMWORK_BASIC_SM

- SAP_SMWORK_BASIC_INCIDENT

- SAP_SMWORK_INCIDENT_MAN_SPC

- SAP_SMWORK_BPM

Individual Roles:

- SAP_SOLAR_RO

- SAP_SM_SOLUTION_DIS

- SAP_SV_SOLUTION_MANAGER_DISP

- SAP_BI_E2E

- SAP_DBA_DISP

- SAP_EM_DISPLAY

- SAP_RCA_DISP

- SAP_RCA_SAP_DISP

- SAP_BC_SEC_USER_DISPLAY

Composite Roles

- SAP_SM_L2_COMP

- SAP_SUPPDESK_SP_ADMIN_COMP

Stated roles above primarily allow only DISPLAY ONLY privileges to validate the usage of specific

functionalities in the SAP Solution Manager. Provision of SAP_ALL authorization is at the discretion of

the VAR.

The VAR Partner can also opt to request for remote view (such as via SAPConnect) in lieu of actual login

by the SAP Auditor. This can be used for issues with respect to remote connection or authorizations. This

can be requested by the SAP Auditor where delays are incurred due to remote connectivity issues.

CONDUCTING THE AUDIT

For a readiness audit, once the audit request has been received at SAP Support, an SAP Auditor will contact the VAR Partner to arrange a convenient interview schedule. The Auditor will provide a standard audit

agenda which includes the following topics:

Support introduction: The VAR is expected to present how support is generally introduced to customers. The VAR can use materials that are also submitted with the checklist on this topic. The Auditor can use this opportunity to understand the VAR’s support offering and operations and allow clarification of concepts during the audit.

System Demonstrations: VARs are

expected to discuss their incident

handling system and show how this is

performed via their incident

The audit interview requires the availability of key support

staff for various demonstrations and discussions with

respect to general support operations.


management system from creation to closure. Within this section, knowledge of SAP Solution

Manager functionality should also be demonstrated, where applicable.

Remote connectivity is a critical aspect for provision of maintenance services. VARs will also be asked

to show that they are able to access customer systems (only in cases where partner has existing

maintenance customers), test systems, and their own support systems (especially if support systems

are not locally-based) to verify availability, accessibility, and performance.

Random Interviews: the audit also consists of interviews conducted with different support roles to

determine knowledge and consistency of processes and procedures.

In general, within the audit session the following tasks should be performed and completed by the SAP

Auditor:

Validate the completeness of the submitted Partner COE checklist including submitted documents.

Documents submitted can be opened and read. This requires that documents can be opened by commonly used tools and applications and are generally in English.

If SAP Solution Manager is used, conduct a remote login to the system to check for functionalities used.

If SAP Solution Manager Service Desk is used as an incident management system, validate customer user authorizations.

Trigger test calls within and outside business hours for the identified support hotline number(s).

Where necessary, an audit interview and/or demonstration of systems used can be scheduled to clarify and understand support operations.

The audit is usually completed within 5-6 hours. The discussions assist the SAP Auditor to determine

actual support provision and capabilities of the Partner as well as confirm the availability of the Partner’s

support infrastructure and operations.

After the audit session, the SAP Auditor creates a certification report containing findings from the audit

session as well as the VAR’s documents. SAP Auditor recommendations for potential improvement is

also documented in the report.

The audit report is submitted within a few days to a judging panel with the Auditors own recommendation

for either a pass or fail rating.

Where support authorization has been granted from a successful readiness audit exercise, the VAR

Partner has to trigger the validation check to be performed at least two (2) months before expiry.

A validation check offers the shortest audit effort and primarily checks those elements that could not be

assessed during the readiness audit in the absence of a productive customer. These audit activities could

include the following:

Review and assess performance indicators that are available from SAP internal systems such as the SAP Service Marketplace. This would include information such as the customer list, remote connectivity with SAP, SAP EarlyWatch® Alert, among others.

Review and assess improvements from the readiness audit report.

Similar to a readiness audit, the validation check also

produces a report. However, this primarily uses the same

report received from the readiness audit and updates the

information therein with the customer-specific

Re-Certification would focus on validating

actual execution of PCOE requirements

through direct checks into support systems

and applications.


performance checks that were not included from the readiness audit exercise.

For re-certification requests, an SAP Auditor will perform tasks both from the readiness audit and

validation check. In addition, a review of the previous report’s recommendations and its application will

be reviewed. Therefore, a VAR should ensure that it has read the recommendations as provided from its

previous audit report and ensured that suggestions for improvement have been performed and are

visible during the re-certification effort. During the re-certification audit, the Auditor will reference the

VAR’s previous audit report and shall check and assess the VAR’s improvement against previous

recommendations.

Do note that a re-certification has more stringent standards with respect to execution of support services

as it is expected that VARs had utilized the two-year duration to improve its support offering and

operations. SAP Auditors would be geared towards direct checks into systems and infrastructure rather

than requiring VARs for demonstrations. Therefore, it is not expected that previous recommendations

are ignored and no improvement is determined within a re-certification exercise.

A VAR should also ensure that they are familiar with current requirements for Partner Center of Expertise

in the event that existing requirements and standards have been changed. Thus, it is encouraged to liaise

with your Partner Account Manager and Partner Services Advisor on a regular basis to ensure that your

Partner Center of Expertise is continuously operating on SAP recommended infrastructure and

processes.

Apart from reviewing improvements from the previous audit report, the SAP Auditor shall also re-

evaluate the VAR’s compliance against any additional requirements at the time of audit. Therefore, it is

expected that the VAR continues to operate its support functions in congruence with SAP standards.

Though the checks performed may be longer in a re-certification effort, this could be minimized with the absence of an interview session should it be deemed that this task is no longer needed Where no delays are incurred, an audit exercise can normally be completed within 3-5 days. The following

situations may contribute to delays in audit completion:

SAP Auditor encounters problems with remote connection to identified systems.

Documents require translation effort.

Insufficient documents or where documents could not be opened by commonly used tools and

applications.

Over 30 maintenance customers involved.

Information requested by SAP Auditor is not provided in a timely manner.

Increased workload where a high number of audits are performed within the same period.

An audit report is generated for both the readiness audit and re-certification following the activities

mentioned above. The audit report documents relevant findings and compiles recommendations for

improvement. Based on the SAP Auditor’s evaluation of compliance data, an audit result is determined.


JUDGING THE AUDIT RESULT

The judging period starts from receipt of the audit report

until a decision is made that is handed down by the SAP

Auditor to the VAR.

Judging entails a review of the certification report to

validate content, recommendations, and verify

compliance areas. The judging committee constitutes

individuals with significant experience with support

operations as well as a detailed understanding of PCOE

standards and requirements. Judges can additionally

include recommendations or require clarification towards

the Auditor.

Within the judging period, questions could be raised by a

Judge to the SAP Auditor either to clarify findings or to

request additional supporting information or content.

Judges can also require improvements done within a specified deadline where critical. After such time, an

updated report is re-submitted for final review. A final review determines the judging result which is

submitted to the Auditor.

Upon receipt of the Judging result, the SAP Auditor starts the closure process. The audit report is

finalized and attached to an email that is subsequently created and sent to the VAR representative

(typically, the Support Manager). The email clearly states the audit results; pass or fail.

What to do with a PASS result?

VARs who successfully comply with the Partner Center of Expertise requirements and standards are

granted support authorization with a two-year duration starting

from the audit date unless specified otherwise.

Before the two-year duration expires, the VAR is encouraged to

trigger the re-certification registration step at least six months prior

to expiry. This is to ensure that ample time is available for

addressing any critical points that may be found from any initial re-

certification attempt. Note that a VAR who does not successfully re-

certify before the allotted expiry date loses its support authorization

thereby being unable to sell VAR-Delivered Support and also being

subject to delta billing for existing customers.

What to do with a FAIL result?

Within a 12-month period, VARs are allowed two (2) tries only. Therefore, a VAR who fails the first audit

attempt is allowed to register for a second audit within the next six (6) months following the previous

audit date. For example, if a VAR had an audit on March 15, they have to register for their second audit no

later than September 15. Failure to do so within the six (6) month grace period will render the second

audit a failure by default.

A VAR who fails their second audit attempt within the 12-month period can only register for another audit

no earlier than 12 months following the second audit date.

Following are the implications for failing an audit effort:

Deals sold thereafter shall only be under the SAP-Delivered Support model

Maintenance for existing customers shall be delta-billed

Support authorization, if previously granted, shall not be renewed

Judging requires a review of audit findings

to validate content, gap analysis, and

recommendations.


For a Readiness Audit, the audit date represents the date of the audit interview session. For other audit

types and if there is no audit interview conducted, the audit date reflects the certification report creation

date.

7.4 Combined Certification VARs with various subsidiaries could opt to jointly register for the audit process. This is only applicable,

however, to VARs who either follow similar support processes (for example, incident handling process is

the same across all and utilizes the same applications throughout) or those operating under a centralized

support hub. For example, it is not possible for a VAR to request for a combined audit if even one VAR is

using an alternate incident management system. This will deviate from a common process and will

require the SAP Auditor to perform an individual evaluation.

A combined certification request does not change the audit process but would require a few additions in

the following areas:

Chapter 9 of the Partner Center of Expertise Checklist should be completed where the

relationship between participating VARs should be clarified.

The PCOE questionnaire should also include localized information such as support hotlines,

support representatives, localized materials, statistics, where applicable.

A minimal audit interview could be required for random subsidiaries of the SAP Auditor’s

choosing. Therefore, the audit phase could be longer than that of an individual scope.

Identification of the leading support unit representing all other participants in common aspects

or components.

In some cases, support staff may be located in different VAR subsidiaries. Do consider the following

guidelines:

The VAR Partner should ensure that all support locations fulfil the support consultant

requirement which mandates that at least two support staff achieve Q_SUPP certification per

support location.

For each product family supported per support location, the product-specific certification

should be achieved by at least two (2) individuals.

It should also be further noted that there is no guarantee that all VARs participating in this joint exercise

shall have the same results as the execution of support deliverables and compliance elements shall still

be evaluated on a per VAR Partner basis.

Is it expected that VARs who initially certified under a combined scope should also do so upon re-

certification?

No. The audit effort and strategy is dependent on the VAR situation and preference at the time of re-

certification. Therefore, the VAR is free to have the same entities participate in a re-certification effort, to

add more or reduce participants, or to revert to individual audits.


7.5 Global VARs

There are no differences in the audit process delivered for a VAR that is involved within a Global VAR

(gVAR) agreement. As such, a gVAR subsidiary can choose to certify on their own (individually) or to

participate in a combined audit scope as discussed in Section 7.3 of this chapter.

It is advisable for Global VARs to look into the following steps to formalize a Partner Center of Expertise

certification strategy:

a. Identify all subsidiaries that have signed the Country Specific Participation Agreement (CSPA).

Further determine the solution areas supported by each subsidiary and the support model (VAR-

Delivered Support or SAP-Delivered Support) chosen moving forward.

b. Considering all identified subsidiaries, check for similarities in support execution. These could include

the following areas or criteria; geographic location (region), solution areas they support,

infrastructure usage, support model chosen). Thereafter, these common areas should then define

the different variants by which certification can be planned.

c. Determine the certification route for each variant; Individual or Combined.

Further consider timelines for certification and continuous review sessions for additional and/or new

subsidiaries.


Appendix A: Quick Links

Application Lifecycle Management

General Information http://service.sap.com/alm

End to End Solution Operations http://service.sap.com/alm-processes

http://www.youtube.com/runsap

http://service.sap.com/e2e

RunSAP Methodology http://service.sap.com/runsap

Support Standards http://service.sap.com/supportstandards

Tools http://service.sap.com/alm-tools

VAR Partner

General Information http://www.sappartneredge.com

Incident Handling

SAP Notes Database http://service.sap.com/notes

SAP Message Wizard http://service.sap.com/message

Correction Downloads http://service.sap.com/patches

Software Center http://service.sap.com/instguides

SAP Expert Forums http://service.sap.com/request-help

Software Download http://service.sap.com/swdc

Quicklinks http://service.sap.com/quicklinks

Remote Connection http://service.sap.com/remoteconnection

Partner Center of Expertise

General Information http://sappartneredge.com/pcoe

SAP Message Wizard http://service.sap.com/message

SAP EarlyWatch® e

General Information http://service.sap.com/ewa


http://service.sap.com/alm-processes


http://service.sap.com/e2e

http://service.sap.com/runsap

http://service.sap.com/supportstandards

http://service.sap.com/alm-tools

http://www.sappartneredge.com/

http://service.sap.com/notes

http://service.sap.com/message

http://service.sap.com/patches

http://service.sap.com/instguides

http://service.sap.com/request-help

http://service.sap.com/swdc

http://service.sap.com/quicklinks

http://service.sap.com/remoteconnection

http://sappartneredge.com/pcoe

http://service.sap.com/message

http://service.sap.com/ewa


EarlyWatch® Alert Reports http://service.sap.com/inbox

Remote Support Component http://service.sap.com/rsc

SAP Products

General Information http://service.sap.com

Maintenance Information http://service.sap.com/maintenance

Platform Availability Matrix http://service.sap.com/pam

SAP Solution Manager

General Information http://service.sap.com/solutionmanager

VAR specific information http://service.sap.com/var-partner Solution Manager Setup

Functionality http://service.sap.com/alm



Online Help http://help.sap.com SAP Solution Manager

E-Learning http://service.sap.com/rkt-solman

Training Information http://www.sap.com/ education

Maintenance Optimizer http://service.sap.com/mopz

Solution Manager Forum http://scn.sap.com/community/it-management/alm/solution-

manager

Expert Guided Implementation

http://service.sap.com/solutionmanager SAP Solution

Manager Services Expert Guided Implementation Expert

Guided Implementation Calendar

SAP Support Offerings

General Information http://service.sap.com/supportofferings

Maintenance http://service.sap.com/maintenance

SAP Enterprise Support http://www.sappartneredge.com/enterprisesupport

http://service.sap.com/enterprisesupport

SAP Standard Support http://service.sap.com/standardsupport

Technical Quality Checks http://www.sappartneredge.com/enterprisesupport

http://service.sap.com/inbox

http://service.sap.com/rsc

http://service.sap.com/

http://service.sap.com/maintenance

http://service.sap.com/pam






http://help.sap.com/

http://service.sap.com/rkt-solman

http://www.sap.com/%20education/catalog

http://service.sap.com/mopz

http://scn.sap.com/community/it-management/alm/solution-manager?url_id=text-search-best-best-scn-community-it-management-alm-solution-manager

http://scn.sap.com/community/it-management/alm/solution-manager?url_id=text-search-best-best-scn-community-it-management-alm-solution-manager


http://service.sap.com/supportofferings

http://service.sap.com/maintenance



http://service.sap.com/standardsupport

http://www.sappartneredge.com/