Partner Center of Expertise SAP

7/30/2019 Partner Center of Expertise SAP

1/60

SAP AG

August 2010

Setting up a Partner Center of Expertise


2/60

SAP AG 2010 / Setting up a Partner Center of Expertise (Partner Guide) Version 2.7 Page 2

Copyright

2010 by SAP AG.

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.

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.


3/60


Table of Contents

Copyright......................................................................................................................... 2

Chapter 1. Partner Center of Expertise............................................................................ 6

1.1. Definition ................................................................................................................ 6

1.2. Components ........................................................................................................... 6

1.3. Certification............................................................................................................. 6

Chapter 2. Support Infrastructure................................................................................... 9

2.1. Dedicated Support Hotline ....................................................................................... 9

2.2. Remote Connection ............................................................................................... 11

2.3. Test Systems ......................................................................................................... 13

2.4. Incident Management System................................................................................. 14

2.5. SAP EarlyWatch Alert........................................................................................... 16

2.6. Support Staff.......................................................................................................... 17

Chapter 3. Support Processes........................................................................................ 23

3.1. Preparing an Incident ............................................................................................. 23

3.2. Reporting an Incident ............................................................................................. 25

3.3. Receiving an Incident ............................................................................................. 26

3.4. Acknowledging an Incident ..................................................................................... 27

3.5. Assigning an Incident ............................................................................................. 27

3.6. Processing an Incident ........................................................................................... 28

3.7. Forwarding an Incident ........................................................................................... 29

3.8. Closing an Incident................................................................................................. 29

3.9. Handling Complaints and Escalations ..................................................................... 30

Chapter 4. Marketing & Communications ....................................................................... 32

4.1. Presentation of Support .......................................................................................... 32

4.2. SAP Communication .............................................................................................. 35

Chapter 5. Continuous Improvement ............................................................................. 37

5.1. Support Reporting .................................................................................................. 37

5.2. Feedback Gathering............................................................................................... 40

5.3. Service Improvement ............................................................................................. 42

Chapter 6. SAP Solution Manager .................................................................................. 43

6.1. Solution Documentation ......................................................................................... 44

6.2. SAP EarlyWatch Alert........................................................................................... 46


4/60


6.3. Initial Assessment .................................................................................................. 50

6.4. Incident Management............................................................................................. 51

6.5. Maintenance Optimizer........................................................................................... 54

6.6. Maintenance Certificate.......................................................................................... 56

Appendix A Quick Links................................................................................................ 58


5/60


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 Support Desk. The Support

Desk function is one of the key support activities performed by a Value Added Reseller, who has

opted for VAR-delivered support.

SAP PartnerEdge Channel Partners (VARs) are entitled to sell SAP Business All-In-One and SAP

BusinessObjects software 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.

A VAR Support Desk ensures that a defined point of contact is available to customers for any

problems that arise in terms of business processes and system operation. By setting up a Support

Desk, a Value Added Reseller can ensure proximity to its customers and provide tailored support

services. By using clearly defined support structures, as represented by a Support Desk, SAP know-

how can be established and retained more easily within the Value Added Reseller.

Information to set up a VAR-specific support infrastructure can be found via the special home page

http://service.sap.com/var-partner. 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.
http://service.sap.com/var-partnerhttp://service.sap.com/var-partnerhttp://service.sap.com/var-partner


6/60


Chapter 1. Partner Center of Expertise

1.1. Definition

Partner Center of Expertise (PCoE)

To ensure that all indirect customers receive the same high quality support, SAP introduced a

dedicated Partner Center of Expertise (PCoE) certification, which will be exclusively available for SAP

PartnerEdge Channel Partners providing support for SAP Business All-In-One and SAP

BusinessObjects solutions. As a Channel Partner, you will leverage the PCoE certification as a key

differentiator in the marketplace, which will allow you to advertise your support organization as

certified by SAP providing a highly marketable asset to your company.

The PCoE certification validates if defined procedures, guidelines, and templates for support

certification are available to provide excellent support services to your customers. Your support teamshould be familiar with general support operations and should have the latest qualifications to

provide high-quality support. Further, the PCoE certification evaluates that the Channel Partners

support organization fulfills the minimum requirements needed to operate the service and support

infrastructure, namely SAP Solution Manager, for end-to-end interaction with customers and SAP. It

further verifies process compliance with SAP Support standards.

Support Authorization

The PCoE certification is a mandatory requirement for all VARs who choose to deliver support

services to their customer base. Completion of this certification program leads to the provision of

support authorization which then allows the VAR to offer support and maintenance services to their

end customer.

1.2. Components

To enable the successful operation of a full service desk facility, a PCoE requires several components

to work seamlessly and efficiently. These components have been identified in the SAP PartnerEdge

Channel Agreement and is thus grouped into the following areas:

Support Infrastructure: comprises the physical and/or tangible elements of a service desk

operation Support Processes: defines the workflow and procedures to enable the different

infrastructure elements to be used in a seamless and effective manner

Marketing and Communications: provides the means and visibility through which the

support operations can be introduced and presented competitively.

Continuous Improvement: generating consistent feedback and reporting to identify areas of

improvement and evaluate opportunities for optimization of resources and services.

1.3. Certification

Partners opting to deliver support for their customer base, or taking VAR-delivered support, arerequired by SAP to secure support authorization which is achieved through the successful completion


7/60


of a Partner Center of Expertise certification (PCoE). This process involves several key personnel

working with the Partner to commence, execute, and achieve this certification. These are the

Channel Manager, Partner Services Advisor, SAP Auditor, and PCoE Judging.

Channel Manager

Partner Services Advisor

SAP Auditor

PCoE Judging Committee

The certification exercise comprises five (5) steps: Registration, Assessment, Preparation, Audit, and

Judging. It may be possible to repeat some steps if assessments are not favorable.

Works with the Partner to assist and explain 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 Partners support model

preference

Received Partner support model decision from Channel Manager

Explains the PCoE certification process to Partners opting for VAR-delivered

support

Reviews and assesses PCoE checklist

Coordinates audit schedule with Partner and SAP Auditor

Conducts audit session with Partner

Creates certification report based on audit findings, documentation, and interviews.

Submits to PCoE judging.

Participates in PCoE judging

Communicates certification results with Partner and internal SAP relevant personnel

Receives certification report from SAP Auditor

Reviews and assesses certification report

Communicates certification assessment with SAP Auditor


8/60


Figure 1-1. Partner Center of Expertise Process Steps


9/60


Chapter 2. Support Infrastructure

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

human resources that comprise the essential components of a support infrastructure. SAP has clearly

defined such infrastructure requirements in the SAP PartnerEdge Channel Agreement and Partners

are enjoined to complete these essential physical components as a mandatory requirement.

Figure 2-1. Support Infrastructure Components

For partners with an existing support business, compliance with SAP requirements necessitates areview 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

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 clearly defined infrastructure requirements are as follows:

Dedicated Support Hotline

Remote Connection

Test Systems

Incident Management System

SAP EarlyWatch Alert

Support Staff

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.


10/60


It is preferred that the support hotline meets the following criteria:

Singular set of numbers 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, but if it does, provides voice mail facility for support staff to

return the call as soon as a line becomes available.

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

customer calls after 6 PM, a friendly recorded announcement is made 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 who 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 Sir! Youve reached support.

How may we help you?

Alternative Modes of Communication

Apart from a support hotline, 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:

Support Website

It is not uncommon for well-established support businesses to offer online accessibility

of their support operations. This is usually a feature available from incident management

systems. This allows interactive and efficient means of communicating incident progress

and resolution with the customer base and allows visibility of issues logged with the

support partner.

Dedicated Support Email Address

As an alternative to a direct call, Partners can also offer a dedicated email address which

routes to their support organization. This, however, may not always be the most efficient

process for incident reporting as there is no guarantee that the email has been received

by the Partner 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

Outmoded at current times, a fax machine still provides a valuable backup alternative

against electronic means of communication. Thus, having a dedicate fax number for such

emergency situations is always a welcome alternative.

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.


11/60


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

When the individual leaves the company, it is expected that the customer receives 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 will create confusion regarding call hours and

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

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 customersite. 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 Partner is not expected to fulfill service level targets. This could also allow SAP or the

Partner to downgrade priority calls as the expected resolution for incidents without immediate

access would be lowered.

A dedicated support hotline should be a singular set of numbers available for

use 7x24. It is recommended to have phone routing capabilities or voice mail asan alternative.


12/60


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 Partner side from any location at any time.

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

Alert, root cause analysis, or solution assessment.)

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.

Customer can use various encryption methods (such as SNC or VPN) for data protection and

security.

Partners should ensure that their customers are fully aware of these security issues and how they areaddressed with current methods. As SAP mandates this requirement with its customers, Partners

should also 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 underhttp://service.sap.com/remoteconnection. 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 fromhttp://service.sap.com/saprouter.
http://service.sap.com/remoteconnectionhttp://service.sap.com/remoteconnectionhttp://service.sap.com/remoteconnectionhttp://service.sap.com/saprouterhttp://service.sap.com/saprouterhttp://service.sap.com/saprouterhttp://service.sap.com/saprouterhttp://service.sap.com/remoteconnection


13/60


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

between SAP and customer production systems

between Partner and customer production systems

between SAP and Partner test systems

between SAP and Partner/Customer SAP Solution Manager systems

2.3. 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, Partners should 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.

A test system, therefore, should fulfill the following factors:

Available onsite at Partner office for immediate use by support staff

Test systems should be available at the Partners office and is not meant to indicate the

customers own test system. Test systems should offer no critical issue on instances that a

test and/or simulation results in malfunctions or errors in the system.

Based on standard SAP product 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 and

release while performing simulation activities.

Has remote connection to SAP

In the event that a 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 numbers provided within a

demo license or their own productive license. Thus, it is not expected that a partner uses the

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

Being a mandatory requirement, 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 recommended.


14/60


2.4. Incident Management System

Partners should use the SAP Solution Manager Service Desk as the primary incident management

system as required from the SAP PartnerEdge channel agreement, Exhibit 4. 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.

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

Test systems should be available for all products/releases used by the customer

base. These should have remote connection established with SAP.


15/60


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 partiesThere should be interactive exchange of information between the Partner 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 flexiblemonitoring 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).


16/60


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 Service Marketplace. Please seeSAP Note 1285423for instructions to accomplish this integration.

2.5. SAP EarlyWatchAlert

SAP EarlyWatch Alert is an important part of making sure that the customers core business

processes work. It is a tool that monitors the essential administrative areas of SAP components and

keeps customers updated on their performance and stability. SAP EarlyWatch Alert runs

automatically to keep the customer informed, so they can react to issues proactively before they

become critical.

SAP EarlyWatchAlert is most effective when activated for all SAP components in the customers

solution. It is covered by the maintenance agreement with SAP with no extra charge and it is a

technical prerequisite to perform other remote delivery services.

SAP EarlyWatch Alert is processed in an SAP Solution Manager system where it can be similarly

activated and where regular reports can be stored. If there is no local SAP Solution Manager system,

customers can send the data to the Partners SAP Solution Manager system or to SAP for processing.

See Figure 2-3.

SAP Note 207223covers information on the setup and restrictions for SAP EarlyWatch Alert.

Similarly, information is available from the SAP Service Marketplace athttp://service.sap.com/ewa.

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.
https://service.sap.com/sap/support/notes/1285423https://service.sap.com/sap/support/notes/1285423https://service.sap.com/sap/support/notes/1285423https://service.sap.com/sap/support/notes/207223https://service.sap.com/sap/support/notes/207223http://service.sap.com/ewahttp://service.sap.com/ewahttp://service.sap.com/ewahttp://service.sap.com/ewahttps://service.sap.com/sap/support/notes/207223https://service.sap.com/sap/support/notes/1285423


17/60


Figure 2-3 SAP EarlyWatch Alert Data Transfer Setup

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

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

SAP on a weekly basis.


18/60


Help Desk

Dispatcher

Processor

Coordinator

Manager

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.

Monitors support queue for new or unassigned incidents

Reviews incidents received for proper priority setting, component assignment, and

incident details. Can send back incidents to customers if incident details are

incomplete.

May not necessarily have product knowledge but understands key components of

incident posting

Can utilize tools and knowledge base to determine proper component assignment

(such as SAP Notes database, customer problem database, product tools)

Assigns incidents to appropriate support personnel

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.

Takes ownership of an incident to completion.

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)

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


19/60


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 Processorrole can be divided into several levels depending on

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

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

First Level Tasks

Duties

Accepts the incident

Performs translation (if necessary) for incidents sent to SAP

Complete the problem description

o meaningful incident header

o technical information on incident context such as log fileso 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)

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

syntax of the error message

o surrounding factors ( ex. recent upgrades/transports)

o 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


20/60


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 dumps

o core dumpso 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

Test the Solution

o check and test 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


21/60


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. It is also expected that the Basis component

should be amongst those supported even during a start-up phase as production down situations are

generally technical incidents.

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.

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 particular

industry or component areas and has had experience with actual implementation of their product. Itis recommended to supplement existing expertise with SAP classroom training and to evaluate their

knowledge through SAP product certification.

It is also a requirement for PCoE certification to ensure that at least two (2) support staff has

achieved people certification and that support staff with the relevant role equivalents should take

the various e-learning materials as provided in the SAP Channel Partner Portal. 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 through 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 customizingentries or hardware parameters


22/60


o Evaluate problem category and forward to next instance

o If message processor does not find a solution, report errors and forward them to SAP Support

Certification required for the following product areas:

SAP Business All-In-One C_PXSUP_90

SAP BusinessObjects C_BOSUP_90

Support Coordinator

o Plan and coordinate the support center

o Interact with SAP Channel Development Manager regarding specific support topics

o Define new services within your SAP Enterprise Support offering

To view these training curriculums, visit the SAP Channel Partner Portal page with the links provided

for each specific product area.

SAP Business All-In-One

Go tohttp://channel.sap.com Education SAP Business All-In-One Choose Role Training

Support Consultant

SAP BusinessObjects

Go tohttp://channel.sap.com Education SAP BusinessObjects Choose Role Training

Support Consultant

Outsourcing

It is also not uncommon for some VARs 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. For such situations, it is also

important to consider this third-party support during the certification audit. Thus, it is to be expected

that the SAP Auditor may request documentation and participation from the third-party unit to verify

support arrangements and integration of support operations between both parties.

Support staff should be available full time and should be able to show

competencies and skills through experience and continuing education. Support

staff should have SAP Education certification or at least two (2) yearsexperience. Following the support consultant training roadmap, each support

organization should have at least one (1) support staff achieving SAP Support

Consultant certification per solution area.
http://channel.sap.com/http://channel.sap.com/http://channel.sap.com/http://channel.sap.com/http://channel.sap.com/http://channel.sap.com/http://channel.sap.com/http://channel.sap.com/


23/60


Chapter 3. Support Processes

Support processes 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, a support process would generally have a basic workflow. Differences occur in the

execution but should generally follow the same seamless process.

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 whichneed further development, improvement, or modifications.

A 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 Feedbackprocess would be explained further in Chapter 5, Continuous Improvement.

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


24/60


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 alsoSAP 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 databaseand/or the operating system information should be provided.

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 anincident 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
https://service.sap.com/sap/support/notes/16018https://service.sap.com/sap/support/notes/16018https://service.sap.com/sap/support/notes/16018https://service.sap.com/sap/support/notes/16018


25/60


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?

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

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


26/60


3.3. 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 thefeatures 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 Reporterand post this

subsequently to the incident management system

Details can be requested from the Reporterby following a pre-defined form from the

incident management system



Possible confusion or misunderstanding ofReporters 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.

Requires manual work from the VAR to post the emailed incident into the incidentmanagement 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.


27/60


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.

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

3.4. Acknowledging an IncidentOnce an incident has been received by the support organization, it is important to immediately

provide a reply to the Reporterto 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

Reporterto help identify their specific incident amongst others.

It is also during the incident acknowledgement process that the initial reaction time is set.

3.5. Assigning an Incident

Upon receipt and subsequent review, the support staff with the Dispatcherrole can then assign an

incident to the relevant consultant. An incident is dispatched based on the following criteria:

Component/product

Priority

Availability of consultant


28/60


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

3.6. Processing an Incident

Once an incident has been assigned for processing, the Processorsubsequently 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

processorcan change the component and subsequently send it back to the Dispatcherfor 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 customers solution landscape

Confirm that proposed solutions achieve the desired effect on a test system before

recommending to the customer.


29/60


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.

3.7. 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 Processorwill 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.

3.8. 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:


30/60


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

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

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 that could be gleaned from it as a means to improve the overall support performance and

quality.

Escalation

Escalations though sometimes used as a term for forwarding of incidents should be interpreted

differently in the context of incident processing. There are 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:


31/60


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 applicationmay not be brought up within a short period. For example, customer experiences a hardware

crash and realizes 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.

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 exist, is used with day-to-day operations, and should

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


32/60


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 andachievements, 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 SAPs 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. Presentation of Support

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

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 resourcesThe customer could be presented with existing applications, systems, hardware to indicate

the VARs commitment to invest in the support business. This could also be used to elaborate

on key operations and how the infrastructure integrates with the VARs 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


33/60


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 meansand 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. Ascustomers 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

SAPs support offering should be clearly packaged into a VARs 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 VARs support offering.

Customer successes and references

A support introduction presentation would be a VARs initial gateway to advertise theircapabilities 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 boosts the VARs credibility with an

audience.

SAP Enterprise Support

Competing in todays global marketplace increasingly requires organizations to operate IT landscapes

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


34/60


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

integrating solutions across and IT ecosystem and optimizing each applications 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 your SAP Channel Partner Portal at

http://channel.sap.com SAP Business Management Solutions SAP Business All-In-One

Support SAP Enterprise Support. Likewise, information can also be found from the SAP Service

Marketplace athttp://service.sap.com/enterprisesupport.

Structuring Your Potential Support Offer

Although this training module is designed to help you sell support as part of your offer, it is possible

that your organization has not spent much time in structuring and formalizing what your offer is in

this area. So lets explore what support could mean to you as a channel partner.

Figure 4.1 Structure of Support Offering

Support is much more than just maintenance or reactive incident management.

The support offering from an SAP Business All-In-One channel partner should be structured in three

parts:

basic services that are required by the majority of your target customers, that also means

you dont have to negotiate what needs to be done to keep a customers solution running.

For example, software maintenance which provides for guaranteed response times 24 hours
http://channel.sap.com/http://channel.sap.com/http://service.sap.com/enterprisesupporthttp://service.sap.com/enterprisesupporthttp://service.sap.com/enterprisesupporthttp://service.sap.com/enterprisesupporthttp://channel.sap.com/


35/60


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 offsitecould 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. 10 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 didnt 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.

4.2. SAP Communication

VARs should always be kept 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 SAP Channel Manager and the SAP Partner

Services Advisor.

SAP Channel Manager

Objective: The Channel Manager is tasked to develop and enable the

business of their assigned Partners 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.

A support-specific presentation material should exist and is actively used forboth prospects and customers. It should have comprehensive information on

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


36/60


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 partners service/support requirements,

recommendations, and other general service/support related feedback.

SAP Partner Services 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 Get to know their designated partners, understand their business priorities and orchestrate

services to increase Partners productivity

Proactively monitor the Partners business performance and support their business goals. For

selected countries, act as a single point of contact into SAP for channel operational tasks, such as

business planning, lead management, and sales support.

Contribute to overall partner experience and thus improve partner satisfaction.

Orchestrate services and business enablement between SAP and Partners along their lifecycle.

VARs should have regular communication with their Channel Manager and

Partner Services Advisor.


37/60


Chapter 5. Continuous Improvement

Change is constantand 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 monitoringtasks 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

A good service level report contains 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 is usually be

used to start calculation for initial response time. First Response Date/Time


38/60


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