PCOE Setup Guide 2014 05

Partner Center of Expertise

Setup Guide For internal SAP and partner use only

2

Copyright

2014 by SAP SE. 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 SE 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 SE 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: 17 October 2014

Release: 5.2

SAP SE 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 31

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 on the SAP Support Portal under the section for SAP Solution Manager for Partners, as well as on the SAP PartnerEdge Portal. 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.


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

Partners 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 Partners 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 Partners

mutual customers. Any deviations from SAPs 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 partners

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

with Good morning! Youve reached 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 SAPs 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 Support Portal pages

under http://support.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.


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

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

the customers 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://support.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 Support Portal


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 Partners office and is

not meant to be the customers

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 partners own demo/productive installation numbers

Test systems should use the partners 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 cause any reason 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

customers 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 customers 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 SAPs support

network. Partners should ensure that their incident

management systems online address is available for

access through the SAP Support Portal. 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 Support Portal.

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 Partners 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 VARs 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 the

Solution Manager Setup page for VAR. You can also use the SAP Online Help on SAP Solution Manager.

Figure 2-4. SAP Solution Manager

Service Desk Reporting


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 customers 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 an incident 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


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://support.sap.com/access-support.

Knowledge Base and Services Information

To find setup and usage information on SAP EarlyWatch Alert, do visit the SAP Support Portal at

http://support.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.


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 incident. 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 incident 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 SAPs 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 users 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

Incident Processor

o Provide first and second level support by processing customer incidents 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 incidents, documentation or verifying customizing entries or

hardware parameters

o Evaluate problem category and forward to next level of expertise

o If incident processor does not find a solution, incident 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


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_4* SAP Certified Application Associate SAP BusinessObjects Business Intelligence Platform

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 2.1 Administrator

C_SMPADM_23 SAP Certified Application Associate - SAP Mobile Platform Native

and Hybrid Application Administration (SMP 2.3)

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 partners 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:

Customers have to be familiar with maintenance

procedures and deliverables. VARs should ensure

that an activity exists where support-specific

topics are clearly discussed.


size of the support organization

incident management system capabilities

organization targets and goals

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

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).

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.


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.

Priority

Customers should be able to convey the urgency of the incident appropriately. The VAR should

also be clear about their priority definitions and educate customers on the use of priority levels.

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 shouldve

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

companys 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 companys 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 Reporters 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 reviews the

contents of the incident. This may include the following activities:

Determining 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.

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

Determining whether the incident 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 Support Portal

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 customers 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 VARs

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 incident 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 SAPs 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 SAPs 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 VARs 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 customers 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 escalating any further.

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

customers 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 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 sh