PCOE Setup Guide 2014 05

Partner Center of Expertise
Setup Guide
For internal SAP and partner use only
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
Table of Contents
Copyright
Table of Contents
Introduction
Chapter 1. Partner Center of Expertise
1.1 Definition
1.2 Components
1.3 Setup Timeline
Set Up
Deliver
Certify
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
SAP SE 2014
Partner Center of Expertise Setup Guide
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

4.1 Support Presentation
38
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

5.1 Support Reporting
44
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
SAP SE 2014
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
SAP SE 2014
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.
SAP SE 2014
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
A Partner Center of Expertise (Partner
incident or problem management, escalation and
COE) delivers maintenance service to
complaint handling, services delivery
indirect customers through SAP
Marketing and Communications which provides the
recommended infrastructure, processes,
means and visibility through which the support
and offerings.
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.
SAP SE 2014
Figure 1-1. Timelines towards Partner Center of Expertise Certification
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:
SAP SE 2014
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.
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.
SAP SE 2014
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.
SAP SE 2014
10
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 <<company name>> support. How may we help you?
ALTERNATIVE MODES OF COMMUNICATION

Apart from a support hotline, VAR Partners can offer alternative means for accessibility of their support
organization to the customer end users. The following means could also be considered to supplement an
existing support hotline:
Online Support
It is not uncommon for well-established support
businesses to offer online accessibility of their
incident management system or other supportrelated 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 email 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.
SAP SE 2014
11
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
SAP SE 2014
12
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.
SAP SE 2014
13
Figure 2-3.
Remote Connection Page in the SAP Support Portal
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.
SAP SE 2014
14
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.
Test systems can be used to simulate incidents

Based on standard SAP product
that could otherwise not be performed in a
version and release
customers productive environment.
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.
SAP SE 2014
15
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.
SAP SE 2014
16
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.
Figure 2-4. SAP Solution Manager

Service Desk Reporting
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.
SAP SE 2014
17
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.
SAP SE 2014
18
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
SAP SE 2014
19
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
SAP SE 2014
20
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.
SAP SE 2014
21
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:
SAP SE 2014
22
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)
SAP SE 2014
23
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, workaround 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.
SAP SE 2014
24
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
SAP SE 2014
25
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_*

Planning and Consolidation
C_EPMFC_*

Financial Consolidation
C_GRCAC_10
SAP Certified Associate Access Control with SBO GRC 10.0
C_A1LOG_*
SAP Certified Application Associate Logistics with Business All-InOne Solution
C_A1FIN_*
SAP Certified Application Associate Financials with Business AllIn-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
C_AFARIA_01
SAP Certified Application Associate SAP Afaria 7.0 Administrator
Applications
Mobile
SAP SE 2014
26
SAP HANA
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)
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.
SAP SE 2014
27
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
Customers have to be familiar with maintenance

procedures and deliverables. VARs should ensure
that an activity exists where support-specific
topics are clearly discussed.
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.

Incident and Problem Management could be extremely simple or complex usually depending on several
factors such as:
SAP SE 2014
28
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.
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.
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).
SAP SE 2014
29
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.
SAP SE 2014
30
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
SAP SE 2014
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
31
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.
SAP SE 2014
32
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:
SAP SE 2014
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
33
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.
SAP SE 2014
34
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.
VARs are enjoined to utilize the SAP

Support network to provide 7x24 support
for its customer base.
SAP SE 2014
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
35
and facilities. The following common strategies could be used for this purpose:

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.
SAP SE 2014
36
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
Escalation procedures are triggered by specifically
processing procedures. These situations have to
defined
events or situations that would normally merit
be properly identified and should have a defined
expedited processing due to business or financial risks.
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.
SAP SE 2014
37
Similar to complaints, escalations should have clear ownership for resolution, identified action plans, and
constant monitoring and communication until its resolution.
In cases when SAP becomes involved in an escalation situation, it is important to ensure that SAP has a
clearly identified contact from the VAR side as well as the customer to properly coordinate activities,
plans, and resources. For such situations, it is also a necessary requirement to have remote connectivity
available to ensure that assistance can be provided by the SAP Support network globally and around the
clock.
Support processes should be in place, should be followed in day-to-day operations, and

should be documented clearly and in line with the incident management system.
Chapter 4. Marketing & Communications

Though support primarily keeps a low profile in most cases, a support business is nonetheless a
significant factor for continuing business. VARs have to capitalize on its successful relationships and
achievements, its staff competencies, and its support capabilities should not take a back seat.
For small customers who may hardly have the manpower and infrastructure to build their own application
competencies, a lot rides on its VAR to provide assistance and advise not only on continuing
improvements of its business and productive operations but also on day-to-day incidents that also
contribute to the overall product experience. Having an application that runs seamlessly is a boon and
having immediate support with excellent service and quality is not far behind.
At the onset of the sales cycle, support should be introduced as part of the offering. VARs may have
varied support offerings but this should be complementary to 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 Support Presentation

VARs should have a compelling
presentation of their support services
and this could be further supplemented
by collaterals. A support presentation
should generally have the following
elements:
Description of competencies
and capabilities
Start the presentation with an
introduction of the support
organization, its structure,
goals, targets, and key
achievements. Capitalize on
resource competencies such as
certifications and experience.
SAP SE 2014
VARs should have available presentation material discussing

various support-specific aspects to set proper expectations
with respect to support operations and delivery.
38
It is also relevant to showcase the growth of a support organization if it conveys the results of
continuous improvements, maturity, and experience of the organization as a whole. This helps to
advertise to customers/prospects that the organization shows and promotes growth that could
benefit them as well.
Showcase support infrastructure and resources

The customer could be presented with existing applications, systems, hardware to indicate the
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:
Network infrastructure for remote connectivity
Test systems
Communications systems
Incident Management Systems
Back-up facilities
Discuss support operations, procedures, and activities

A support presentation should provide its audience with an idea of the required tasks and
activities that would also be expected from the customer end user in relation to their interaction
with the support organization. This should already introduce the different means and methods
by which the support unit can be accessed and the different roles that come into play during an
actual incident handling operation.
A brief workflow of the support processes providing an overall view of the support activities
should be available. Different processes and variations in incident handling could be discussed
such as escalation processing, complaint handling, and after-office hour procedures.
Presentation of support offering(s)

VARs could offer either one standard offering while some could offer variations. As customers
come in different sizes, different needs, and orientation, it is also possible that VARs could offer
different levels of support services, while some could offer additional services separately.
At a minimum, VARs should review their duties for SAP and the End Customer as provided in
Exhibit 4 of the SAP PartnerEdge Channel Agreement. Thus, all services delivered through 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 their
capabilities and market themselves as the right choice for lasting relationships. It is important to
earn achievements and highlight actual successes in a presentation material. Actual references
are added advertisements and having good quotes and feedback from existing customers offers
factual and realistic samples that boost the VARs credibility with an audience.
SAP SE 2014
39
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,
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 the Support area through the SAP
PartnerEdge Portal product pages.
STRUCTURING YOUR POTENTIAL SUPPORT OFFER

Although this training module is designed to help you
sell support as part of your offering, it is possible that
your organization has not spent much time in
structuring and formalizing what your offer is in this
area. So lets explore what support could mean to you
as a VAR.
Support is much more than just maintenance or
reactive incident management.
The support offering from a VAR, as an example, could
be structured in three parts:
Basic services that are required by the majority of your target customers. This also means you
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 a day
as part of a service level agreement to investigate breakdown or critical faults. Remember,
many of your customers have periods when they are working outside normal hours. This is often
when they are busy and therefore these extra hours are the most critical.
Additional services that you can package as an insurance, such as disaster recovery for a
catastrophic incident, sure as a fire, where the servers are lost but a back-up held offsite could
be reloaded to a spare server, getting the customer back live in a short period of time. These can
be charged and delivered at a premium, but it is important to ensure there are not too many
Premium Packaged offers, so that the customer does not constantly find they are not covered.
Ten years ago many insurance companies went down this route of offering a high degree of
choice in extras, but when customers always found the policy 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.
SAP SE 2014
40
A support-specific presentation package should be prepared and actively used for both
prospects and customers. It should have comprehensive information on support
offerings, support processes, infrastructure, as well as contact methods.
4.2 SAP Communication

VARs should always keep abreast of any new strategies, offerings, and events within the SAP community.
Thus, a VAR should have regular and ongoing communication with their different interfaces to SAP.
These regular contact points are the Partner Account Manager and the SAP Partner Service Advisor.
SAP PARTNER ACCOUNT MANAGER
Objective: The Partner Account Manager is tasked to develop and enable the
business of their assigned VARs and help them extend to their fullest
potential, applying mid-long term view. The Channel Manager will support and
drive development of new business areas for partners.
Tasks
Helps VARs to analyze and leverage business potential using available processes and best practices;
ensures partners become self-sufficient in this.
Creates, monitors, and reviews business and marketing plans together with the assigned partners
using standard tools and templates.
Responsible for partner pipeline management, coverage and reporting.
Monitors overall partner performance including partner satisfaction and develops action plans to
correct as necessary.
Communicates SAP support strategy to Partners to ensure Partners understand the services value
proposition as well as requirements and obligations.
Coordinates with Partner Services Delivery organization where appropriate.
Keeps SAP internal teams informed about partners service/support requirements,
recommendations, and other general service/support related feedback.
SAP PARTNER SERVICE ADVISOR
Objective: Acts as a trusted advisor to his/her personally assigned

partners, driving the desired objectives while also acting as feedback
channel into SAP to improve our go-to-market strategy to the ecosystem.
Tasks
Develops an ongoing enablement plan for partner organization based on individual targets and
requirements
Provides technical knowledge related to SAP product and solutions, new features, and
information on new releases
SAP SE 2014
41
Helps coordinate access to many of the benefits that the partner organization is entitled to
according to SAP PartnerEdge program level
Proactively informs partner organization of updates and rollout of SAP initiatives
Helps partner understand the program framework and requirements and identify opportunities
to maximize partner performance in the SAP PartnerEdge program
Connects partner with experts from various SAP organizations, particular with specialized
technical resources in industry business units, solution management, and so on
Acts as another feedback conduit into SAP
VARs should have regular communication with their Partner Account Manager and
Partner Services Advisor.
4.3 Maintenance Agreement

While VARs may have presentation material to introduce or explain their support offering, a legal
document exists that cements these provisions and clearly identifies elements that are deliverable
between the VAR and its customer base. This should set proper expectations between both parties to
ensure that support will be available at agreed times and shall be executed through defined methods of
delivery.
A maintenance agreement could solely be a software maintenance agreement or could be extended to
include hardware components and could then be a system maintenance contract. The focus of a PCOE
audit is primarily on the software maintenance component as system maintenance involves firmware and
firmware which is not covered by the standard SAP maintenance.
Elements that could be included in a
maintenance agreement between a VAR and
its customer base are the following:
Availability and accessibility of

software versions / releases
Explains delivery methods for
software upgrades, corrections
and/or updates
Corrective maintenance processes

and procedures
Discuss the different facilities
available for addressing incidents or
problems. This also explains the
standard processes or procedures
for effecting incident or problem
All customers should have a valid maintenance
resolution activities.
agreement detailing support deliverables and
provisions.
Preventive maintenance
processes and procedures
Identifies facilities, applications, activities, and services providing aid in ensuring stability and
continuous operation of the customer solution.
Service level agreements, if any

States committed response and resolution times for identified conditions or scenarios.
Identify facilities and/or applications inclusive and in aid to support provision

This could mention accessibility of websites for product or support-related topics, solution
databases, forums, and services to assist in maintenance provision.
SAP SE 2014
42
VARs should review basic maintenance offerings from both the SAP Standard Support and SAP
Enterprise Support portfolio and strive to include elements from these offerings into their own basic
support services.
Section 4.1 of this chapter further explains the possibilities of having additional or packaged offerings as
well as ad hoc services that could be provided on top of a general basic offering. These could be
mentioned during the audit interview but are not subject to evaluation or review except in situations
where these are defined as inclusive amongst the SAP standard offers.
Content of maintenance agreements are reviewed with particular attention to the following risk areas:
States provision of services, facilities, or responsibilities that are deemed deliverable through
SAP but are not inclusive within SAPs maintenance offering
Are not aligned with committed deliverables by the VAR in comparison with current documents
or presentations made available to customers
Has no defined support elements

The audit requires the submission of a maintenance agreement template or any scanned copy of an
existing maintenance agreement signed with an indirect customer with the following conditions:
Submitted template or scanned copy should not contain any price points. These could either be
removed or covered upon submission.
Typifies the basic maintenance coverage for indirect customers.
Between basic maintenance templates with SAP Standard Support and SAP Enterprise Support
scope, do submit the template / copy which includes the SAP Enterprise Support scope.
VARs should provide maintenance agreements for all customers that are in alignment
with their own offering and/or SAPs.
SAP SE 2014
43
Chapter 5. Continuous Improvement

Change is constant and this is still be true for a support organization. As the industry grows, matures,
and with increasing technology changes, support should not stand idly but should be open to review
existing processes and infrastructure against ongoing trends. Customer feedback is also a strong factor
for promoting changes and improvements.
Whether a support organization improves for its internal benefit or due to customer suggestions, a VAR
should promote a culture of feedback acceptance not only from its customers but also from internal
staff. Thus, it is essential that there are continuous monitoring tasks to determine ongoing performance.
These same monitoring activities should be subject for review to assess alert conditions that could
require more proactive measures or to examine current trends that may trigger added services and
support.
This chapter examines different ways and methods by which a VAR could execute simple monitoring
tasks and utilize results for service improvements.
5.1 Support Reporting

Regardless of the size of the support organization or the amount of incidents received from an existing
customer base, reporting on support performance
and trends should be acknowledged as an integral
part of support processing. This requires
frequency, ownership, and an incident
management application that can produce relevant
reports demanded by the business.
Reports have to be distributed to appropriate
individuals who may need statistics and trends
analysis information to recommend or adjust
services and resources where it is needed. This
section tries to cover the more common and
relevant support reporting for VARs such as service
level reporting, customer incident reporting ,
team/processor reporting.
Monitoring of support performance should be a
regular activity supplemented with reports
targeted at measuring identified KPIs.
SERVICE LEVEL REPORTING

SAP has provided service levels pertaining to response and processing time targets for VARs based on
priority level. VARs are to consider the availability of regular statistics to document their performance
with respect to these defined targets. A high level overview of overall support performance against
service levels could be created for management review as well.
The following elements can be considered to produce such the required information to evaluate service
level performance:
Incident number
Uniquely identifies an incident when additional review may be needed.
Creation Date/Time
Actual date/time when the incident has been posted by the end customer. This is usually be
used to start calculation for initial response time.
SAP SE 2014
44
First Response Date/Time

Actual date/time when incident has been acknowledged and replied to by the support
organization. This would be used for calculating initial response time usually computed as time
elapsed between first response date/time and creation date/time.
Last Change Date/Time
This indicates the period by which the incident has been last replied by either the support unit or
the end customer.
Status
This indicates the current progress of the incident.
Completed Date/Time
Indicates the date/time when an incident has been classified as closed by the support unit. This
may or may not necessarily indicate that the customer has confirmed that the incident could be
closed.
Processing Time
Indicates the amount of time spent by the support team in processing the incident. For some
incident management systems, this could indicate total processing time by the support unit or
could be processing time per group/level within the support unit.
It should be clear that the processing time should not include the amount of time spent while an
incident is pending at the customer end. Though it is also good to have a facility to compute
processing time at the customer side, in cases when a customer complains about the speed by
which an incident is processed.
Service Level Indicators
For easy reference, especially by Management, it is recommended to have a column or any
indicator in the service level reporting that clearly shows whether defined service level targets
have been met. Thus, if a VAR provides service levels for initial response time and processing
time, there should be two separate indicators whether these elements have been met for each
specific incident.
CUSTOMER INCIDENT REPORTING

An incident management system should have a facility by which a customer end user, on their own,
should be able to display, list, or report on their own incidents. This could also be produced by the
support organization as a value-added service or as an ongoing measure for keeping customers informed
of pending incidents while it can also be used as a conversation piece to elicit feedback from a customer.
A good customer incident report would contain the following elements:
Incident number
Uniquely identifies an incident when additional review may be needed.
Creation Date/Time
Actual date/time when the incident has been posted by the end customer. This would usually be
used to start calculation for initial response time.

This would indicate the period by which the incident has been last replied to by either the
support unit or the end customer.
Status
Completed Date/Time
closed.
For VARs with committed service levels, additional data could be provided as with service level
reporting.
SAP SE 2014
45
TEAM/PROCESSOR REPORTING
Support staff should also monitor their own performance and this should be performed regularly
especially if this involves their individual KPIs. Depending
on performance targets for the support staff, there are
some key elements that should be available in either a
team or processor-specific reporting. Team/Processor
reporting is normally being used by support management
for regular evaluation or assessment of support staff.
For individual reporting, the following elements should be
considered and should be filtered either specific to team or
individual support processor:
Incident number
Uniquely identifies an incident when additional
review may be needed.
Creation Date/Time
Indicates the actual date/time when the incident
has been posted by the end customer. Would
generally have relevance to the report especially
when needed to assess processing time.

This would indicate the period by which the incident has been last replied to by either the
support unit or the end customer.
Status
Completed Date/Time
closed. This information is relevant in conjunction with the status of the incident as the
expectation should be that the incident is confirmed by the end customer. If this has not yet
been performed by the customer, then it would be good practice for the processor to check with
the customer if the incident can be closed or if they are satisfied with the solution.
Processing Time
Indicates the amount of time spent by the support team in processing the incident. For some
incident management systems, this could indicate total processing time by the support unit or
could be processing time per group/level within the support unit. This is relevant since it
indicates the effort utilized for resolving an incident. For team or individual statistics, it would
also be good to note if the Processor/Team has processed the incident efficiently or if the
Processor/Team requires additional training or expertise to resolve incidents faster.
For VAR Partners with service level adherence as a performance indicator, then it is important to include
some elements from the service level reporting within the processor/team reporting as well.
Within an audit exercise, it is expected that VAR Partners are able to demonstrate or produce reports
that are generated out of their primary incident management system.
SAP SE 2014
46
MANAGEMENT REPORTING
It is also a good practice to have consolidated and
statistical information for support management
or company management on a regular basis. Do
note that support should also be considered as an
avenue for additional business and services, thus,
reporting can also be reviewed or assessed for
indicators that would trigger these.
For management, it could be important to present
the following information in summary:
Number of incidents received
Resolution rate
Number of escalations, its progress, and

lessons learned
Service Level Adherence
Status reporting
Regular incident reporting could also show trends

that can be translated to potential services and
offerings.
Statistical inputs and/or trends analysis would also be welcomed for the following reporting information:
Customer(s) with most number of incidents
Component(s) with most number of incidents

Reporting on support process compliance as well as support performance should be
generated on a regular basis and should be available for support staff, customers, and
management.
Support reports should be aligned with support-specific targets and contractual
commitments.
5.2 Feedback Gathering

While it is important to get information from customers on support performance, internal staff could also
provide valuable feedback in their execution of support processes. Thus, there has to be regular
communication with the support organization, its internal staff, and the customer base to determine
areas where services can be improved, what can be removed, or what needs to be changed.
INTERNAL FEEDBACK
Within the support staff itself or within the company, providing avenues for staff to contribute their
experiences and lessons learned on-the-job is
a valuable forum for considering
improvements with support operations. Thus,
having regular meetings with support staff
and encouraging experience sharing as well as
fostering a culture where suggestions are
respected and considered should be available.
Regular incident reporting could also show trends

that can be translated to potential services and
offerings.
SAP SE 2014
Internal meetings could also be used to

discuss improvement areas and obtaining
direct feedback from colleagues on
acceptability or receiving comments on
potential issues that could best be identified
from different perspectives with a larger
group. It would also be easier to gravitate
47
towards improvements or changes if these have been discussed with staff that will be immediately
affected by these.
Have regular meetings with support staff to discuss experiences, issues, action items,
and on-going performance. All meetings should be properly documented and reviewed.
EXTERNAL FEEDBACK
Customers definitely have a stake in service improvements by the support organization. Thus, there
should be constant and regular communication with customers on improvement areas while also offering
a forum to get their overall experience. Though it is important to get individual feedback per incident, this
might become too redundant and some customer end users would tend to ignore this. However, a regular
survey session, such as one conducted annually for instance, might be more welcome.
For support-specific surveys, it is important to have a minimum amount of questions and to focus on
areas specific to support. These could be any of the following factors:
Response/resolution time
Solution quality
Staff competence and behavior

Auditors can request for the most current survey results if this is conducted on a regular basis by the
VAR Partner. The Partner COE questionnaire should include this information as well.
Regular survey sessions should be conducted with customers at least on an annual

basis. Feedback should be requested for relevant factors such as efficiency, solution
quality, staff competence and behavior.
5.3 Service Improvement

Based on feedback from internal and external sources,
the VAR should also review current trends and
technologies as possible indicators for upgrades,
improvements, or process changes.
VARs would generally offer a standard support
package but could potentially offer additional services
or premium offerings depending on need or request.
As customers mature and expand their solutions, it
would also be necessary for a VAR to be aware of these
changes and expand their own offerings to
accommodate changing demands and needs.
Competition would also drive improvements where VARs can also look for offerings that would
differentiate or relegate their maintenance services in a different level from other VARs. Thus, constant
development of support staff is a necessary investment and keeping abreast on strategies related to their
products and support services should be encouraged.
Thus, a VARs support offering should evolve and grow not only with its customer base but with emerging
technologies. Though it is a good practice to always be a few steps ahead of others, VARs have to clearly
determine areas of need and ensure alignment with existing resources and infrastructure.
SAP SE 2014
48
There should be available avenues for process improvement that is regularly reviewed
and discussed with relevant parties. This should generally be spearheaded by Support
Management.
5.4 Support Readiness Activity

The VAR Partner has to ensure that its customer has the required knowledge with respect to the VAR
Partners support operations and has fulfilled all required infrastructure and activities to ensure that
maintenance services can be delivered seamlessly. Customers should have proper expectations with
respect to services that are delivered within maintenance and how to request for it.
A support readiness activity should be established between the VAR Partner and the Customer to
address the following elements:
Prepare and validate infrastructure required on both parties to ensure seamless communication
and delivery of maintenance services.
Gather information from the customer to identify key contacts for both business and technical
aspects.
Communicate maintenance deliverables both by the VAR Partner and of SAP.
Discuss and clarify support procedures and processes.
Identify action plans for gaps identified where follow-up work needs to be addressed by either or
both parties.
It is expected that a support readiness activity should be completed for all customers, especially for
those under SAP Enterprise Support, at least prior to go live and to ensure a re-visit of this task on an
annual basis.
Within the PartnerEdge exhibit, a support readiness activity is also known as the Initial Assessment
service. This could be fulfilled with the execution of an SAP Enterprise Support Setup Service via SAP
Solution Manager. However, a VAR Partner can define its own activity to render the same content. As this
activity validates the preparedness of both the VAR Partner and the customer with respect to
maintenance delivery, this is a critical element for ensuring that both parties are aligned and informed.
A support readiness activity should be available and conducted for all customers to set
proper expectations with respect to maintenance deliverables and allow a
comprehensive review of support setup between both parties.
SAP SE 2014
49
Chapter 6. SAP Solution Manager

To deliver first-rate support to their customers VARs require access to knowledge hubs in SAPs service
infrastructure, transparency on their customers solutions, as well as secure remote access to customer
systems. SAP Solution Manager is the adequate tool for VARs to deliver high-quality support to their
customers and to fulfill their daily tasks efficiently.
Figure 6-1. SAP Solution Manager in a Service Provider environment

The VAR is the central contact of indirect customers for questions regarding the SAP solution. Tools are
needed which makes the technical complexity of their customers solutions transparent, and supports
the entire SAP solution lifecycle. Integrating VARs into the SAP Global Support Backbone allows SAP and
VARs to support their customers together, leverage valuable synergies, and add value for themselves,
SAP, and customers. There are functionalities which are tailored for VARs such as that for Service Desk.
Where such VAR-specific functionalities exist, this platform is to be used.
VARs sell SAP solutions which are tailored to the requirements of small and medium-sized enterprises, to
which they provide first and second-level support. It is assumed that VAR customers may not have their
own SAP Solution Manager. Thus, the VAR should operate an SAP Solution Manager system for its
indirect customers in the event that SAP requires to deliver services under this platform and where
customers may not be able to set up one on their own
To date, SAP Solution Manager is a mandatory requirement for VARs supporting SAP Business All-InOne and SAP HANA. It remains highly recommended for other product families. Starting from July 2013,
the SAP Solution Manager 7.1 version is required for VARs as SAP Solution Manager 7.0 ends
mainstream maintenance by end of 2013.
The SAP Solution Manager currently supports VARs in performing the following processes and related
tasks:
Project Administration
Solution Documentation
SAP EarlyWatch Alert (EWA)
Incident (and Problem) Management
Maintenance Optimizer
Maintenance Certificate
Technical Monitoring
SAP SE 2014
50
Business Process Monitoring

Root Cause Analysis
6.1 Customer Landscape Validation

VAR Partners should ensure that all customers are identified or maintained in their SAP Solution
Manager system. At a minimum, the productive landscape should be defined. This paves the way for
utilizing customer information for various functionalities as mentioned above.
During an audit process, the SAP Auditor may conduct a validation check of the SAP Solution Manager
system with respect to the availability of all maintenance customers. Thus, the VAR Partner should then
ensure that customers are maintained, for instance, within the Technical Monitoring or System
Monitoring areas and especially where the Service Desk functionality is used.
Figure 6.2 All Systems defined in the SAP Solution Manager

Failure to have customers defined within the SAP Solution Manager can entail delays in provision of
services as most functionalities require this specific information to be available. Thus, where SAP
Auditors may deem that customer data in the SAP Solution Manager system is missing, an audit failure
could result. Thus, as best practice, where new customers are added into the VAR Partners customer
list, identification of the customers landscape (as soon as it is available) should be defined in the SAP
Solution Manager system.
It should also be noted that, at a minimum, the customers productive landscape should be maintained in
the VAR Partners SAP Solution Manager system. However, defining other system types is also
encouraged.
All maintenance customers should be identified in the SAP Solution Manager system of
the VAR Partner.
6.1 Project Administration

Project Administration allows the definition of various project components such as the system landscape,
roadmap, project standards (such as keywords and document types), scope, persons involved,
accelerators, and critical milestones, among others. VARs should document new implementation
projects or upgrade projects in an SAP Solution Manager system. This is highly encouraged to ensure
that relevant data with respect to project (and later on, solution) components are maintained especially
by people involved in this activity.
SAP SE 2014
51
Amongst the initial preparatory tasks for

starting project administration via the SAP
Solution Manager is the identification of
the project as well as the project type.
Figure 6-2 below shows the initial screen
for identifying key elements in the project.
Amongst the most relevant elements
defined at the initial project creation
activity are the following:
General Data allows the identification of
project management owners, project
language, current status, planned and
actual timelines, planned and actual
resources used.
Scope identifies the functionality or
solution relevant for the project as well as
the roadmap used.
System Landscape identifies the systems relevant
for the project
Milestones set specific dates for achieving
defined milestones and also to document
the actual start times when milestones
were achieved.
Figure 6-2. Project Administration Work Area
Organizational Units identifies specific organizations or

units that are affected by the project
Project Standards defines specific keywords,
documentation types, project status values to be used
throughout the project.
After completing these initial definitions for the project, the
Project team can proceed to define the business blueprint,
define business scenarios, processes, process steps and
the upload/import of relevant project documentation,
materials, and templates as the project progresses. Figure
6-3 shows the screen used for during the design stage. The
involved business processes are defined in the left panel
which shows the business process structure. The right panel allows the project team to provide related
documents, transactions and object information, test data, involved roles, configuration data, and even
related incidents where available.
SAP SE 2014
52
After go live, the project documentation can then be transferred to a solution for maintenance activities
or technical and business process monitoring tasks.
Figure 6-3. Business Blueprint Work Area
It is highly recommended that customer projects (such as implementation or upgrades)

should be documented via the Project Administration facilities of SAP Solution
Manager.
6.2 Solution Documentation

As defined in SAPs Support Standards documentation, the solution is the entirety of all system
components and processes that represent a central function or a business area in an information
system. A solution includes the technical landscape information via the logical components referenced
by business processes. Implementation project documentation can also be adapted or transferred into a
solution.
VARs should strive to ensure that all customer solutions be made available via an SAP Solution Manager
system, whether this be the customers own or hosted by the VAR. At a minimum, the customers core
business process(es) should be documented.
Solutions can be manually created from the bottom up, imported from existing documentation (such as
spread sheets), or can be created through solution validation functionalities within SAP Solution
Manager; such as Reverse Business Process Documentation (RBPD).
This chapter identifies three (3) types of documentation in a solution; technical landscape
documentation, business process documentation, and custom code documentation.
SAP SE 2014
53
TECHNICAL LANDSCAPE DOCUMENTATION

The technical landscape documentation is
generally performed within the initial
configuration of the SAP Solution Manager
system. In SAP Solution Manager 7.1, the
Landscape Management Database or LMDB
was introduced which takes system
information from the System Landscape
Directory (SLD) into the SAP Solution
Manager system.
As a prerequisite, all systems (so called
Managed Systems) involved in the solution
should be connected to the SAP Solution
Manager. Thus for VAR customers, customer
Customers should document core business
systems (defined as managed systems) could
processes
in an SAP Solution Manager system.
be performed within the early stages of the
SAP Solution Manager configuration. This
allows the capture of relevant technical data such as installation numbers, systems ids, hardware
information, and client numbers to be made. The necessary remote links (RFCs) can also be generated
automatically as part of the initial setup phase. These also allow the possibility to connect to customer
systems directly.
Once the technical data of systems are captured, a logical component can be defined which groups
systems that logically belong together. For example, defining which systems are connected to the
production system such as the development, test, or even training systems and grouping them together
as a logical component. This also defines the transport route between systems.
Figure 6-4. Managed Systems Configuration
SAP SE 2014
54
BUSINESS PROCESS DOCUMENTATION

Following the technical solution landscape documentation, the business processes can then be
documented. These could be defined from existing implementation content from the SAP Solution
Manager business process repository (BPR), importing process documentation from other mediums
where interfaces are available at SAP, or processes manually entered by the customer or a combination
of these options. For customers that are already live and where project information was not documented
Figure 6-5. Business Process Documentation

via the SAP Solution Manager, a V AR Partner could consider all the options above. It is recommended to
have at least the core business processes defined at the least.
The best option is to build documentation from the Implementation phase is by using the Project
Administration functionality within SAP Solution Manager. Information maintained therein can then be
transferred into a Solution for maintenance, monitoring, and continuous improvement.
With SAP Solution Manager, processes can be documented in three (3) levels; business scenario,
business process, and process steps. A business scenario is a set of processes that define a business
task on a macro-level. A business processes is a set of logically-related activities performed to achieve a
defined business outcome while a business process step is an elementary activity performed to
accomplish a process. As such, documenting business processes could include project information,
business blueprint, configuration, training material, test documents, and transactions.
The same business processes documented in an SAP Solution Manager system can be used to set up
Business Process & Interface Monitoring (BPIAM). This covers monitoring of application-related as well
as technical-related aspects of the business process instead of the classical system monitoring by
components.
CUSTOM CODE DOCUMENTATION

As with documentation of standard SAP business processes, SAP also understands that each customer
has their own specific requirements and unique processes. Thus, the possibility to make custom objects,
programs, reports, etc. These should also be documented especially for the following reasons:
-
SAP SE 2014
Modifications could be lost during an upgrade that has not been carried out properly
Validation of usage to identify modifications that have been unused for a significant period
and could increase maintenance cost and performance losses
55
Figure 6-6. Custom Code Documentation
To learn more about solution documentation from SAP support standards, visit
https://support.sap.com/supportstandards. Learn more about SAP Solution Manager functionality
related to solution documentation under Solution Manager Processes Solution Documentation.
It is highly recommended that customers core business processes are documented

and/or maintained in an SAP Solution Manager system.

Incidents during the operations of mission critical applications can cause severe business loss if they are
not properly managed, their root cause identified and their effects minimized by immediate corrective
action. The IT Service Management (ITSM) functionality within SAP Solution Manager helps both
customers and partners to accelerate the resolution of support incidents, to increase the availability of
the IT solution and minimize negative business impacts, and to gain 100% transparency on issues and
challenges.
Figure 6-7. Incident Management for VARs

For VAR Partners, it is highly recommended to use the SAP Solution Manager ITSM for handling the
incident management process. VAR Partners offering support for SAP Business All-In-One and SAP
HANA are mandated to have SAP Solution Manager Service Desk operational regardless of any third
party incident management system used. For SAP Solution Manager Service Desk, the Support Provider
scenario should be used as there are other scenarios available for other user types.
SAP SE 2014
56
Provided that the SAP Solution Manager system has established an operational connection with the SAP
Support backbone and where appropriate customer authorization are available, VARs can download
information related to its customer systems as defined from the SAP Support Portal into their SAP
Solution Manager system. This helps to minimize manual creation and / or update of customer systems
by the VAR Support team.
Within SAP Solution Manager 7.1, VARs have the option to use either the work centers or the ITSM user
interface. SAP Work Centers have been widely used in the previous SAP Solution Manager 7.0 version
where SAP Solution Manager 7.1 offers a few changes which should barely affect customer users who
have been working with the work center interface since.
VAR Partners should ensure that all current maintenance customers are defined in the Service Desk
system. This should allow any customer user to log incidents with their support provider should this be
necessary and critically in urgent situations. SAP Auditors can validate the existence of all customers in
the Service Desk functionality where needed. Thus, completeness in this aspect of the Service Desk
functionality configuration should be ensured.
User Types
There are three user types that echo the authorization profiles that are created for the IT Service
Management in SAP Solution Manager. These are Key User, Processor, and Administrator.
Key Users pertain to customer users and are granted limited authorization to primarily post incidents,
reply to the support unit, and confirm incidents posted. Figure 6-8 shows the basic ITSM interface for a
key users Home screen. From this screen, customer users can report incidents to the VAR support
team, display all incidents created by the user, and to also have a widget (Figure 6-10) that shows
incidents that requiring user action.
For creating
incidents
Figure 6-8. Key User ITSM Interface

Incident List
A Processor role is expected to be part of the VAR support unit and has required authorizations to view
customer incidents for incident processing. Processors could create incidents on behalf of the customer
base, process them, assign incidents across the support organization, forward incidents to SAP as well as
to respond to incidents sent to SAP.
SAP SE 2014
57
Figure 6-9. Action Required by Me widget for Key Users

Processors could have access to reporting capabilities for ITSM, the capability to build and/or maintain
knowledge articles, maintain time recording, and the possibility to convert incidents to problems and/or
change requests provided these functionalities were set up with ITSM.
Figure 6-10. User Interface for Processor role
The Administrator is responsible for the maintenance of the IT Service Management functionality. This
could include creation and maintenance of users, configuration, customization and improvement of the
functionality, as well as providing support and resolution efforts for incidents related to the IT Service
SAP SE 2014
58
Management. Thus, additional authorization is provided to this user for performing stated tasks on top of
those held by a Processor role.
Administrators would be relevant for instances when there are new customers and where these have to
be defined within ITSM along with respective user ids for new customer users.
VARs have to ensure security of its customer data by strictly utilizing the provided authorizations for
specific roles. Using full authorization or Processor authorization for customer users is strictly disallowed
and would result to an audit failure. These could be checked by SAP Auditors to ensure that customer
users have delimited authorizations which prohibit visibility of other customer systems, decrease
authorization to perform tasks that can affect the processing of incidents, and disallow forwarding of
incidents to SAP except for potential Very High priority incidents raised outside business hours.
Figure 6-11. Home Screen for Processor role
Amongst the relevant features of the ITSM functionality that can be used are the following:
Service Level Agreements can be set up to trigger specific actions (i.e., sending emails to a
target group / individual) based on a defined set of conditions such as the customer priority,
category.
Multi-level Categorization allows better classification or grouping of incidents relative to

defined criteria. This helps support staff to identify the required expertise for an incident.
Knowledge Articles can be created by a VAR to document incidents and solutions that can be
referenced by other users or by the support staff itself. These articles can include keywords that
could be used when searching for potential solutions to incidents.
Time Recording is essential for situations when effort utilized requires documentation. This
could be for reporting purposes, or in some cases, for potential billing. Times recorded can be
further classified based on work or activity performed.
Access to the SAP Notes Database can be performed directly from ITSM where the user is
redirected to the SAP Support Portal where an SAP notes search can be performed. SAP Notes
can be attached to incidents for reference by customer users or other support staff.
Support Reporting has been significantly improved with the availability of either list reporting,
BW reporting, and some pre-defined BI Dashboard applications
With the integration to the SAP Support backbone, incidents posted via the SAP Solution Manager can be
forwarded seamlessly to SAP Support without having to manually create a separate incident via the SAP
Support Portal. To cater for assisting VARs in providing 7x24 support, SAP Solution Manager can
SAP SE 2014
59
automatically forward Very High incidents to SAP outside defined business hours by the VAR. For such
cases, SAP then relates directly to the customer without the necessity of having VAR support staff
available during those times.
Where VAR Partners offer after-office hours support through SAP via the SAP Solution Manager Service
Desk, an SAP Auditor can validate that business hours are appropriately maintained per customer.
Where this has not been set up for some customers, after-office hours support will not work and, hence,
incidents on Very High that are posted beyond business hours will remain at the VAR Partners SAP
Solution Manager system until its next business day / hour. Insufficient setup on this aspect could result
in an audit failure. Thus, this has to be ensured for each customer and any new customer, thereafter.
As an advantage of integration, ITSM can receive incidents from other inbound channels such as
projects, solutions, technical and business process monitoring applications and other functionalities
running within SAP Solution Manager that can either manually or automatically trigger creation of
incidents.
To find setup and usage information on the Service Desk functionality, do visit the VAR-specific partner
pages on SAP Support Portal . Here you will find information on e-learning materials, training roadmaps,
configuration and setup information, usage information, and various white papers on the incident
management and application life-cycle management topic.
For guided configuration assistance, SAP offers channel partners the Expert Guided Implementation
Session for Incident, Problem, and Request Management (ITSM) for VARs. This is an efficient and
interactive possibility to set up SAP Solution Manager Service Desk in a defined period of time. This
service is designed for VARs to support them during setup and configuration of Service Desk. For
available schedules within your region, please check http://support.sap.com/solutionmanager
Services Expert Guided Implementation Expert Guided Implementation Calendar
The SAP Solution Manager Service Desk functionality is the recommended incident
management system platform for all VARs. It is mandatory for VAR Partners supporting
both SAP Business All-In-One and SAP HANA to maintain all customers in the service
desk functionality to ensure that incidents can be forwarded to SAP through this
medium.
SAP SE 2014
60
6.4 Maintenance Optimizer

The flexibility of SAP applications and high supportability standards has led to a considerable increase in
the number of software components that are used by individual customers and that
Figure 6-12. Maintenance Optimizer in the SAP Solution Manager

can be installed centrally on one server or distributed over multiple servers. For example, SAP ERP 6.0
contains more than 50 different software components. To efficiently manage the resulting combinations,
professional support is necessary. So far, customers selected the relevant maintenance updates from an
unfiltered list of software packages in the SAP Support Portal and downloaded them. Then the customer
had to import the patches into the development system, test them in the quality assurance system and
finally release the patches to the production system. These steps are now simplified by the SAP Solution
Manager Maintenance Optimizer, thus the customer can always have an overview of the maintenance
activities in all systems and solutions.
As part of the SAP Solution Manager, the Maintenance Optimizer offers a comprehensive procedure for
software maintenance, including:
1. Maintenance Optimizer shows relevant maintenance files for the customers solution.
2. Select the required packages and approve the download of the maintenance files.
3. Download the software.
4. Import the software (furthermore uses familiar tools such as SPAM, SAINT, )
5. Close the maintenance procedure.
To find setup and usage information on the Maintenance Optimizer, do visit the SAP Support Portal
under Solution Manager Processes.
SAP SE 2014
61
Figure 6-13. Maintenance Optimizer interaction with the SAP Global Support Backbone
It is mandatory for all customers supporting SAP Business All-In-One to ensure that the
Maintenance Optimizer functionality is operational at all times.
SAP SE 2014
62
6.5 Maintenance Certificate

It has always been important
to SAP that our customers
receive full support for their
SAP solutions. This includes
the delivery of software
corrections and
improvements that can boost
an IT solutions performance
and stability. For example,
SAP offers the maintenance
optimizer to support an endto-end, fully pre-configured
maintenance management
process. Today, the
maintenance optimizer is
the central application
within SAP Solution
Manager to control and
ease maintenance of your
customers SAP solutions.
Figure 6-14. Automatic Distribution of the Maintenance

Certificate for Customers with their own SAP Solution
Manager system
Maintenance Optimizer was integrated with software lifecycle manager service to further automate the
download of support packages and SAP enhancement packages as well as the deployment of the
packages to satellite systems connected to SAP Solution Manager. The integration with SAPs
Figure 6-15. Automatic Distribution of the Maintenance Certificate for Customers supported by
a VARs SAP Solution Manager system
transport management system makes the management of all software and configuration changes
consistent.
Another improvement was the introduction of a maintenance certificate. The certificate enables software
logistics tools to identify your customers system and the exact scope of your customers corresponding
SAP maintenance agreement. This will also improve the quality of your customers SAP solution by
preventing patches from being deployed to the wrong system accidentally.
You can find detailed information how to use the Maintenance Certificate on the VAR pages on SAP
Support Portal at Solution Manager Processes Maintenance Management.
SAP SE 2014
63
6.6 Technical Monitoring

The Technical Monitoring work center provides tools and capabilities for monitoring system landscapes
defined in the SAP Solution Manager system or the Landscape Management Database (LMDB). Figure 615 below shows the various features available from this work center the foremost being the centralization
of all alerts via the Unified Alert Inbox.
Within the Technical Monitoring work center, an SAP Auditor can validate whether customers are defined
Figure 6-16. Technical Monitoring and Alerting Capabilities in Detail

with their productive solution landscape. This is relevant information for other functionalities within the
SAP Solution Manager system and can also be used for technical landscape information of customer
systems. VAR Partners have to ensure that at least all customer productive systems are maintained in
this section, particularly under System Monitoring.
The following features describe various capabilities under the
Technical Monitoring work center. These can be implemented
centrally from the VAR Partners SAP Solution Manager system or
preferably through the customers own SAP Solution Manager. It is
preferred that customers use this functionality with their own SAP
Solution Manager system as a local network infrastructure is a
relevant consideration for real-time data availability.
Unified Alert Inbox
Central access point to handle all types of alerts
Efficient alert handling based on consolidation of single

alerts to alert groups
Integration of most common alert handling mechanism as

status tracking, incidents, notifications and 3rd party
integration
Drill down from alert type to alert groups, alert instances

and single metrics and events
Integration of analysis capabilities as problem context and

monitoring applications
SAP SE 2014
Figure 6-17. System

Monitoring Views
64
System Monitoring
Provide status overview regarding technical system including instances, databases and hosts
Allow to access landscape information and problem context for technical system
Drill down from status information to single metrics and events provided by End-to-End
Monitoring and Alerting
Visualize metrics and events including thresholds and current rating / value
Jump-in capability in metric viewer including zoom functionality in detail information

Process Integration Monitoring
Growing PI landscape complexity and distribution leads to growing requirements towards a

central monitoring approach
Reduce the TCO by providing one central entry point combining monitors for PI overall status
with drill-down options
Enable tight integration with:

System Monitoring and Alerting
Root Cause Analysis
Notification and Incident Management
Relieve productive systems from individual monitoring activities by central collection of

monitoring data
Reduce time for regular as system health checks and hand-over procedures as well as from
incident detection to root cause analysis
End User Experience Monitoring
Automated execution of recorded end user scenarios
Measurement of availability and response times from
end user point of view
Client performance data is correlated with server side
performance data
Direct access from monitoring to Root Cause Analysis
(End-to-End Trace Analysis)
Deep integration in End-to-End Monitoring and Alerting
Infrastructure
Support of Metric Reporting, SLA Reporting and
Management Dashboards
Business Intelligence Monitoring

Central system status overview for all technical components involved in SAP Business
Intelligence Solution
Capability to monitor cross-system SAP Business Warehouse process chains and single process
chain steps
Central monitoring of Business Objects specific jobs and correlation to system specific metrics
Central monitoring of SAP BW queries and templates
Integration of Business Intelligence specific alerts in Alert Inbox including Notification
Management, Incident Management, Task Assignment and forwarding to 3rd party
Reduce the TCO by providing one central entry point combining monitors for overall status
Connection Monitoring / Interface Channel Monitoring
Central status overview for connections between SAP systems based on pre-selected RFC
destination definitions
Support of peer-to-peer connections (two managed systems involved) and scenario specific
connections (more than two managed systems involved)
Access to SAP Incident Management and SAP Notification Management
Complete integration in End-to-End Monitoring and Alerting Infrastructure
SAP SE 2014
65
Interface Channel Monitoring
Provides customers with transparency regarding technical interface landscape covering RFC
calls, Web Service calls as well as Very High priority incident handling
Allows mapping from technical interface information to human understandable entities by usage
of Interface Channels with appropriate attributes
Delivers an unified approach to visualize the different interface types including sufficient
monitoring and alerting for performance, usage, availability and exceptions
All customers with productive installations should be defined in the SAP Solution
Manager system, particularly, the Technical Monitoring work center.
6.7 Business Process Monitoring

During operations, exceptions may arise from within business applications. Effective and efficient
handling of these exceptions is a crucial factor for both: an optimized total cost of operations and smooth
business execution. The exception handling standard explains how to define a model and procedures to
manage exceptions and error situations during daily business operations.
The advent of more complex and diverse business scenarios crossing application borders plus the
immense volume of business transactions processed today require an exception handling that is
scalable, open and central, and embedded into business operations and sup-port processes. The
business process champion and the responsible business process operations team have to define a
model and procedures for handling exceptions and error situations during daily business operations.
These procedures describe what proactive monitoring activities have to be executed to detect businesscritical exception situations and what corrective actions are required in the given context. The
procedures also describe who is responsible for certain activities in the business process operations
team or the business unit. The execution of these procedures can be supported by monitoring and
alerting tools within the business process and interface monitoring concept.
After the exception handling model has been defined, the business process and interface monitoring
standard supports the monitoring of the mission critical business processes, enabling customers to
identify problems long before typical IT alerts would be triggered.
SAP SE 2014
66
Figure 6-18. Business Process Analysis and Monitoring

Business process monitoring includes monitoring activities, alert and problem detection, notification of
experts, error handling procedures, and well defined interface towards end-to-end root cause analysis (a
separate standard).
Todays system landscapes are often decentralized and consist of various interfaces to different
systems, legacy environments, where customers and vendors use different technologies. All those
interfaces need to be monitored in terms of processing errors, backlog situations and performance.
SAP SE 2014
67
The Business Process Monitoring functionality within the SAP Solution Manager system offers the
following features:
Business Process Orientation. All alerts are (uniquely) assigned to specific business process
steps and/or to specific interfaces. Subsequent business process steps that might be affected
are immediately visible.
Proactive Alert Monitoring. Early warning of
(technical) incidents before end users report it.
Alert History. Storage of historic alerts, logging
of alert confirmations, comments for problem
resolution.
Auto-reaction Methods. Emails and SMS
messages can be sent to appropriate support or
business employee. Provision of pre-filled alert
information/context.
Service Desk Integration. Service desk incidents
can be opened in dialog or background. Service
desk incidents can be automatically filled with
meaningful alert information. Incidents can be
tracked.
Central Documentation. Facility for central
documentation of business processes, error
handling procedures and escalation paths,
monitoring responsibilities.
Customer-specific Monitoring. Easy integration
Figure 6-19. Business Process
of customer-specific monitors via customer
Status Indicators
rd
3 Party Tool Integration. Alert from other
monitoring tools can be brought in business process context via CCMS integration.
Service Level Reporting Integration. Offers pre-configured SL reporting, trend analysis for job
runtimes, trend analysis for throughput & backlog integrators.
BI Integration. Flexible ad-hoc reporting with business process relations, pre-configured web
templates, trend analysis for job runtimes, trend analysis for throughput & backlog indicators
Cross-Application Monitoring
Interface Monitoring
6.8 Root Cause Analysis

In todays distributed, multi-technology customer solutions with multi-channel access through diverse
devices and client applications, analyzing the root cause of an incident requires a systematic top down
approach to finally pinpoint the primary cause. End-to-end root cause analysis offers a systematic
analysis and resolution of incidents for a distributed mission critical customer environment.
For instance, if an end user experiences a performance problem in his browser, the performance hit may
be in the client, in the network or somewhere in the server environment, which itself comprises different
instances of also different technologies. Server-side processing may take place in an SAP Netweaver
Enterprise Portal (based on Java technology), then reach out to an SAP ECC backend (based on ABAP
technology) and finally call the database and the storage subsystem for data retrieval. A performance
problem or functional defect may occur at one or all stages of this round trip launched by the end user
from the browser. Root cause analysis tools help identify the specific component which causes a
performance bottleneck.
SAP SE 2014
68
Figure 6-20. Root Cause Analysis for Mobile Applications

The standard root cause analysis offers systematic analysis and resolution of incidents for a distributed
mission critical customer environment. The goal is to identify and provide:
o an immediate corrective action (workaround) to restore service operations as quickly as possible
with minimal disruption to end users by isolating
the area of concern
o a complete solution to the issue at hand
Operationally, root cause analysis tools are designed to
work towards reducing the number of resources in each
step of the resolution process. A small team of support
consultants with technical core competence in root
cause analysis and an expert for the specific component
who can delve deep into the component is enough to
drive the issue and nail it down to a component.
Additionally, the root cause analysis infrastructure is
open for fast track integration of new SAP technologies,
applications and also for third-party software.
The following features are offered in the SAP Solution
Manager Root Cause Analysis functionality:
E2E Workload Analysis: General performance overview
for heterogeneous solution landscape
E2E Change Analysis: Statistical change data cross all
technologies based on daily snapshots
E2E Exception Analysis: Statistical exception data for
trend analysis or review exception
E2E Trace Analysis: Identify the problem causing
component (performance and functional) and jump-in to
detailed component specific trace analysis for single
user request
Figure 6-20. Root Cause Analysis for

Mobile Applications
System, Host and Database Analysis: Central, safe and

remote access to file system, OS and DB including links to read-only monitoring and administration tools
like CA Wily Introscope.
SAP SE 2014
69
ROOT CAUSE ANALYSIS FOR SAP HANA

For VAR Partners supporting SAP HANA, setting up Root Cause Analysis to actively monitor an SAP
HANA test system is a mandatory requirement for support authorization. Therefore, during an audit
exercise, the VAR has to be able to show that their SAP Solution Manager system is able to show real
time data being transmitted from their SAP HANA test system. To ensure that data is current, it is
preferred that an SAP HANA test system exists within the VAR Partners local area network.
The Root Cause Analysis functionality should be operational and actively monitoring an
SAP HANA Test System for VAR Partners supporting the SAP HANA product family.
SAP SE 2014
70
Chapter 7. Partner COE Audit Process

The primary purpose of this set up guide is to provide ample information to discuss the different
elements required for establishing a Partner Center of Expertise that meets the defined standards by
SAP. It is expected that the previous chapters have been read and clearly understood before a VAR
triggers the audit process.
7.1 Relevant Roles for the Audit Process

VAR Partners opting to deliver support for their customer base, or are opting for VAR-Delivered Support,
are required by SAP to certify their Partner COE through a stringent audit process. This process involves
several key personnel working with the VAR to commence, execute, and achieve this certification. The
following roles are relevant for the audit process; Partner Account Manager, Partner Services Advisor,
Partner Certification Auditor, and the Judging Committee. The tasks performed by these roles are further
detailed below.
Partner Account Manager
Works with the Partner to assist and explain the various VAR support delivery models
Receives Partner decision on support model preference; VAR-delivered support or SAP-delivered
support
Informs the Partner Services Advisor (PSA) on VARs support model preference
Partner Service Advisor
Works with the Partner to assist and explain the various VAR support delivery models
Receives Partner decision on support model preference; VAR-delivered support or SAP-delivered
support
Informs the Partner Services Advisor (PSA) on VARs support model preference
Partner Certification Auditor
Conducts audit session with VAR.
Creates audit reports based on audit findings, documentation, and interviews. Submits to PCOE
judging.
Participates as VAR Partner interface for Judging
Communicates certification results with VAR Partner and internal SAP relevant personnel
Judging Committee
Receives audit report from Auditor.
Reviews audit report findings and recommendations and ascertains compliance against Partner
Center of Expertise requirements and standards.
Liaise with the Auditor for clarification and immediate improvements, where necessary.
Communicates audit results to the Auditor.
Before and after the audit process, The Partner Account Manager and the Partner Services Advisor
would be the best resources within SAP to assist the VAR Partner with respect to the audit process.
Before an audit, these interfaces can help to clarify the Partner COE requirements at the current period.
After an audit process, these roles can also be referenced for guidance with respect to fulfilling the
recommendations as may be required by the audit report.
The Partner Certification Auditor (PCA) becomes available to the VAR Partner only within the audit
period. The PCA is an SAP employee with extensive experience on the Partner COE audit process and
requirements and, hence, is an invaluable resource to ensure a successful achievement of support
authorization. PCA recommendations are documented in a report which is provided to VAR Partner
where improvements are noted. During the audit process, the PCA can either validate application usage
(such as SAP Solution Manager) directly or conducts an interview process which helps to clarify aspects
of the VAR Partners support set up and usage.
SAP SE 2014
71
The Judging Committee is comprised of senior support employees at SAP Active Global Support with
expert knowledge on PCOE operations. They review audit reports to cross-check compliance areas and
can add improvement suggestions where necessary. In conjunction with the findings from the PCA as
documented in the audit report, an audit result is decided by the Judging Committee which is later
handed over by the PCA to the VAR Partner as either a pass or fail rating.
7.2 Audit Types

Depending on the Partners current support authorization status, the Partner COE program offer three
(3) audit types; Readiness Audit, Validation Check, and Re-Certification. VAR Partners have to gauge
the appropriate audit requirements by understanding the scenarios where specific audit types are
relevant.
READINESS AUDIT
From February 2014, all new VAR Partners should undergo an audit exercise that would ascertain the
availability of a Partner COE infrastructure and process before customers are acquired. This helps to
ensure that a support operation will be in existence and is readily available to provide maintenance
services for new (or even transferred) customers.
The primary difference between VAR Partners that undergoes a readiness audit exercise with other audit
types is its absence of customers through which delivery if support services and execution of support
operations could not be assessed. Another clear difference is the mandatory interview required between
the Auditor and key support roles within the VAR Partners Partner COE such as the Support Manager.
A VAR Partner should commence the setup of a support operation following SAP standards as soon as
possible following its acceptance as a Value-Added Reseller of SAP. The required infrastructure,
processes, and people certification should be completed and application or registration for the readiness
audit can be made thereafter. VAR Partners should ensure that registration is executed well before any
deal is to be signed so as not to hinder or delay deals in cases where the initial certification checks find
gaps in support requirements.
During this audit exercise, the Auditor would evaluate all key components of a Partner COE operation
such as:
Incident Management system with SAP Solution Manager Service Desk being mandatory for
VAR Partners supporting SAP Business All-In-One and/or SAP HANA. Auditors will require a full
demonstration of end-to-end incident handling processes.
Remote connection infrastructure strategies
Full time support staff with required support consultant certification
Test Systems for products supported
SAP Solution Manager functionality knowledge
Support introduction or presentation materials for understanding the VAR Partners
maintenance offer.
Customer maintenance agreement
Knowledge of SAP maintenance provisions for both the VAR Partner and indirect customers
Support processes and procedures including documentation available. This includes all key
processes for incident handling, escalation/complaint handling, support readiness activities,
support reporting and feedback gathering.
PCOE requirements may change over time and, thus, it is always a good exercise for the VAR Partner to
have active communication with their Partner Services Advisor and Partner Account Manager for any
new developments on support authorization requirements.
SAP SE 2014
72
Where a VAR Partner completes the readiness audit successfully, support authorization is granted for a
12 month period commencing from the audit interview date. This allows the VAR Partner time to acquire
customers and implement solutions to yield productive systems.
VALIDATION CHECK
Before the 12 month period allotted for VAR Partners who has successfully achieved support
authorization via the Readiness Audit, a validation check should be conducted. This should be requested
explicitly by the VAR Partner via a support incident (see Section 7.3) with short text Request for Partner
COE: Validation Check. The expectation at this stage is that the VAR Partner has acquired a customer
and was able to bring their customer systems into productive operation. Thus, SAP can conduct a short
validation exercise with respect to the integration of customers into the VAR Partners execution of its
support services and operations.
Once completed successfully, the support authorization of the VAR Partner is further extended for
another 12 months.
RE-CERTIFICATION
VAR Partners who has achieved support authorization through either a validation check (starting from
February 2014), via a certification exercise (before February 2014) or via a re-certification exercise are
required to re-certify their Partner COE support infrastructure and operations at least three (3) months
before their current support authorization expires.
A Partner COE re-certification activity re-evaluates the VAR Partners performance against SAPs quality
matrix which includes continued maintenance of mission critical elements such as remote connectivity to
SAP and SAP EarlyWatch Alert data transfers (where applicable), low customer maintenance
termination ratio, low billable incidents count, absence of customer complaints, SAP Solution Manager
adoption and usage, as examples. An audit interview may also be conducted where necessary to clarify
support concepts.
A successful re-certification grants the VAR Partner a further two-year extension of their support
authorization.
7.3 Audit Process

Between the audit types as mentioned in Section 7.2 of this chapter, the audit processes are generally
similar while the audit content offers differences.
The audit process contains 3 stages; Registration, Audit, Judging. The following sections discuss the
audit process as executed for the different audit types.
REGISTERING FOR AN AUDIT

Step 1. Complete Your Checklist
Prior to Registration, the VAR Partner should download the
latest PCOE Checklist available from the SAP PartnerEdge
Portal. This can be found directly from the Key Resources
area. The Partner should fully complete the questions in the
checklist and provide supporting documents, where
applicable.
SAP SE 2014
73
The checklist itself has the following sections:

1.
2.
3.
4.
5.
6.
7.
8.
Confirmation: This requires a valid signatory of the company attesting to the correctness of all
responses provided in the checklist. Where English is not used for either the checklist responses
or submitted documents, the VAR Partner has to provide confirmation that SAP Auditors may
use translation tools and services (private or public) to convert data and information into
English.
Supported Products: the VAR Partner needs to confirm products that will be supported by their
Partner COE. It is expected that all products with status Authorized shall also be supported by
the VAR Partner unless the corresponding support dimension for the product have been
maintained as Opted Out.
Current Support Performance Data: Chapter 4 focuses on performance figures as may be
gathered through SAP internal systems and the VAR Partners own. This helps SAP to
understand the VAR Partners continued commitment for SAP standards by maintaining high
compliance rates and satisfaction levels.
Partner Center of Operations Structure: Chapter 5 requires information pertaining to the
physical elements of a Partner COE setup. This includes support staffing, incident management
system used, remote connectivity strategy, test system availability, systems and database used.
SAP Solution Manager: Requires details of the SAP Solution Manager installation and
functionality usage where applicable. This section also clearly discusses the remote connection
requirements and necessary authorizations to be provided for an SAP Auditor to validate usage
and set up of the SAP Solution Manager system.
Support Processes: Chapter 7 requests for information pertaining to support procedures and
respective documentation.
Continuous Improvement: Requests information pertaining to support-specific reporting and
satisfaction surveys used.
Combined Certification: Chapter 9 of the checklist should only be answered if the audit request
is by more than one VAR. Further, the VARs involved should be PartnerEdge VARs opting for
VAR-Delivered Support and are related to each other; i.e. subsidiaries.
VARs should endeavour to provide answers to all questions from the checklist and to provide supporting
documents where additional information may be necessary. Documentation submitted should have the
following attributes:
Current and in use by the VAR during the audit period.

Original content created for VAR purposes. It is understood that in some presentation materials
with respect to SAP-related offerings, content could be copied from SAP. However, it is
expected that VARs are able to properly discuss such content should these be requested by the
Auditor.
Content is applicable to answer information required from the checklist question.
Step 2. Register Solution with SAP

This step is only applicable for VARs with SAP Solution Manager installed.
Once the checklist has been fully accomplished, the Partner has to prepare that a Solution has been
created in their SAP Solution Manager system and where data has been forwarded to SAP.
Note: During the basic configuration of the SAP Solution Manager system, a default solution
SAP Solution is created. This can be used if no other solution has been created in the SAP
Solution Manager system.
SAP SE 2014
74
Once a Solution has been identified, this has to be explicitly registered with SAP. To do so, from the SAP
Solution Manager system, access the Solution Manager Administration work center and select
Solutions. Solutions created in your system will be displayed in a table. Verify that the solution for your
Figure 7-2. Solution Table

SAP Solution Manager system is sending data to SAP. This could be checked from the column Sending
Data where a tick mark should be present for your solution.
If no tick mark is present, data is not being sent to SAP. To do
so, select option
. Once selected, you
will be prompted to select your data transfer settings.
Choose either Send All Data or Send Production Data
and save your settings. Solution information will then be
transferred to SAP.
Step 3. Log an SAP Support Incident
To register for an audit, the VAR Partner should log an
incident with SAP Support preferably via the SAP Solution
Manager Service Desk (if being used). The following tasks
should be performed by the VAR Partner:
1.
2.
3.
4.
5.
Maintain the secure login details of the SAP Solution Manager system (if used) in the SAP
Support Portal.
It is preferred that default user id SAPSUPPORT is used for the SAP Solution Manager
login.
Please reference the table below for the required authorizations for the user.
Open the connection types R/3 Support, HTTP Connect or SAPGUI+Browser for the next
seven (7) days.
Create an SAP Support incident under component SV-BO-REQ following short text template
below specific to the audit type requested:
Readiness Audit : Request for Partner COE certification: Readiness Audit
Validation Check
: Request for Partner COE certification: Validation Check
Re-Certification : Request for Partner COE certification: Re-certification
If SAP Solution Manager is used as the primary incident management system, do provide a
template or reference user id example for a customer user.
Except Validation Check requests, the SAP Support incident should contain the following
attachments:
Fully completed and signed Partner COE Checklist
Supporting Documents
If preferred, the VAR may request for container where all documents can be compiled and sent
to SAP.
As the SAP Auditor can directly validate the set up of the SAP Solution Manager for VAR Partner usage,
the following authorization roles should be available for the user id provided to ensure that the necessary
checks can be performed.
SAP SE 2014
75
User ID
Authorization Role
SAPSUPPORT
Work Centers:
SAP_SMWORK_IMPL
SAP_SMWORK_TECH_MON
SAP_SMWORK_SYS_MON
SAP_SMWORK_DIAG
SAP_SMWORK_BASIC_SM
SAP_SMWORK_BASIC_INCIDENT
SAP_SMWORK_INCIDENT_MAN_SPC
SAP_SMWORK_BPM
Individual Roles:
SAP_SOLAR_RO
SAP_SM_SOLUTION_DIS
SAP_SV_SOLUTION_MANAGER_DISP
SAP_BI_E2E
SAP_DBA_DISP
SAP_EM_DISPLAY
SAP_RCA_DISP
SAP_RCA_SAP_DISP
SAP_BC_SEC_USER_DISPLAY
Composite Roles
-
SAP_SM_L2_COMP
SAP_SUPPDESK_SP_ADMIN_COMP
Stated roles above primarily allow only DISPLAY ONLY privileges to validate the usage of specific
functionalities in the SAP Solution Manager. Provision of SAP_ALL authorization is at the discretion of
the VAR.
The VAR Partner can also opt to request for remote view (such as via SAPConnect) in lieu of actual login
by the SAP Auditor. This can be used for issues with respect to remote connection or authorizations. This
can be requested by the SAP Auditor where delays are incurred due to remote connectivity issues.
CONDUCTING THE AUDIT

For a readiness audit, once the audit request has been received at SAP Support, an SAP Auditor will
contact the VAR Partner to arrange a convenient interview schedule.
The Auditor will provide a standard audit
agenda which includes the following topics:
Support introduction: The VAR is

expected to present how support is
generally introduced to customers. The
VAR can use materials that are also
submitted with the checklist on this
topic. The Auditor can use this
opportunity to understand the VARs
support offering and operations and
allow clarification of concepts during
the audit.
System Demonstrations: VARs are

expected to discuss their incident
handling system and show how this is
performed via their incident
SAP SE 2014
The audit interview requires the availability of key support

staff for various demonstrations and discussions with
respect to general support operations.
76
management system from creation to closure. Within this section, knowledge of SAP Solution
Manager functionality should also be demonstrated, where applicable.
Remote connectivity is a critical aspect for provision of maintenance services. VARs will also be asked
to show that they are able to access customer systems (only in cases where partner has existing
maintenance customers), test systems, and their own support systems (especially if support systems
are not locally-based) to verify availability, accessibility, and performance.
Random Interviews: the audit also consists of interviews conducted with different support roles to
determine knowledge and consistency of processes and procedures.
In general, within the audit session the following tasks should be performed and completed by the SAP
Auditor:
Validate the completeness of the submitted Partner COE checklist including submitted documents.
Documents submitted can be opened and read. This requires that documents can be opened by
commonly used tools and applications and are generally in English.
If SAP Solution Manager is used, conduct a remote login to the system to check for functionalities
used.
If SAP Solution Manager Service Desk is used as an incident management system, validate customer
user authorizations.
Trigger test calls within and outside business hours for the identified support hotline number(s).
Where necessary, an audit interview and/or demonstration of systems used can be scheduled to
clarify and understand support operations.
The audit is usually completed within 5-6 hours. The discussions assist the SAP Auditor to determine
actual support provision and capabilities of the Partner as well as confirm the availability of the Partners
support infrastructure and operations.
After the audit session, the SAP Auditor creates a certification report containing findings from the audit
session as well as the VARs documents. SAP Auditor recommendations for potential improvement is
also documented in the report.
The audit report is submitted within a few days to a judging panel with the Auditors own recommendation
for either a pass or fail rating.
Where support authorization has been granted from a successful readiness audit exercise, the VAR
Partner has to trigger the validation check to be performed at least two (2) months before expiry.
A validation check offers the shortest audit effort and primarily checks those elements that could not be
assessed during the readiness audit in the absence of a productive customer. These audit activities could
include the following:
Review and assess performance indicators that are

available from SAP internal systems such as the SAP
Support Portal. This would include information such
as the customer list, remote connectivity with SAP,
SAP EarlyWatch Alert, among others.
Review and assess improvements from the readiness
audit report.
Similar to a readiness audit, the validation check also

produces a report. However, this primarily uses the same
report received from the readiness audit and updates the
information therein with the customer-specific
SAP SE 2014
Re-Certification would focus on validating

actual execution of PCOE requirements
through direct checks into support systems
and applications.
77
performance checks that were not included from the readiness audit exercise.
For re-certification requests, an SAP Auditor will perform tasks both from the readiness audit and
validation check. In addition, a review of the previous reports recommendations and its application will
be reviewed. Therefore, a VAR should ensure that it has read the recommendations as provided from its
previous audit report and ensured that suggestions for improvement have been performed and are
visible during the re-certification effort. During the re-certification audit, the Auditor will reference the
VARs previous audit report and shall check and assess the VARs improvement against previous
recommendations.
Do note that a re-certification has more stringent standards with respect to execution of support services
as it is expected that VARs had utilized the two-year duration to improve its support offering and
operations. SAP Auditors would be geared towards direct checks into systems and infrastructure rather
than requiring VARs for demonstrations. Therefore, it is not expected that previous recommendations
are ignored and no improvement is determined within a re-certification exercise.
A VAR should also ensure that they are familiar with current requirements for Partner Center of Expertise
in the event that existing requirements and standards have been changed. Thus, it is encouraged to liaise
with your Partner Account Manager and Partner Services Advisor on a regular basis to ensure that your
Partner Center of Expertise is continuously operating on SAP recommended infrastructure and
processes.
Apart from reviewing improvements from the previous audit report, the SAP Auditor shall also reevaluate the VARs compliance against any additional requirements at the time of audit. Therefore, it is
expected that the VAR continues to operate its support functions in congruence with SAP standards.
Though the checks performed may be longer in a re-certification effort, this could be minimized with the
absence of an interview session should it be deemed that this task is no longer needed
Where no delays are incurred, an audit exercise can normally be completed within 3-5 days. The following
situations may contribute to delays in audit completion:
SAP Auditor encounters problems with remote connection to identified systems.

Documents require translation effort.
Insufficient documents or where documents could not be opened by commonly used tools and
applications.
Over 30 maintenance customers involved.
Information requested by SAP Auditor is not provided in a timely manner.
Increased workload where a high number of audits are performed within the same period.
An audit report is generated for both the readiness audit and re-certification following the activities
mentioned above. The audit report documents relevant findings and compiles recommendations for
improvement. Based on the SAP Auditors evaluation of compliance data, an audit result is determined.
SAP SE 2014
78
JUDGING THE AUDIT RESULT

The judging period starts from receipt of the audit report
until a decision is made that is handed down by the SAP
Auditor to the VAR.
Judging entails a review of the certification report to
validate content, recommendations, and verify
compliance areas. The judging committee constitutes
individuals with significant experience with support
operations as well as a detailed understanding of PCOE
standards and requirements. Judges can additionally
include recommendations or require clarification towards
the Auditor.
Judging requires a review of audit findings

to validate content, gap analysis, and
recommendations.
Within the judging period, questions could be raised by a

Judge to the SAP Auditor either to clarify findings or to
request additional supporting information or content.
Judges can also require improvements done within a specified deadline where critical. After such time, an
updated report is re-submitted for final review. A final review determines the judging result which is
submitted to the Auditor.
Upon receipt of the Judging result, the SAP Auditor starts the closure process. The audit report is
finalized and attached to an email that is subsequently created and sent to the VAR representative
(typically, the Support Manager). The email clearly states the audit results; pass or fail.
What to do with a PASS result?

VARs who successfully comply with the Partner Center of Expertise requirements and standards are
granted support authorization with a two-year duration starting
from the audit date unless specified otherwise.
Before the two-year duration expires, the VAR is encouraged to
trigger the re-certification registration step at least six months prior
to expiry. This is to ensure that ample time is available for
addressing any critical points that may be found from any initial recertification attempt. Note that a VAR who does not successfully recertify before the allotted expiry date loses its support authorization
thereby being unable to sell VAR-Delivered Support and also being
subject to delta billing for existing customers.
What to do with a FAIL result?

Within a 12-month period, VARs are allowed two (2) tries only. Therefore, a VAR who fails the first audit
attempt is allowed to register for a second audit within the next six (6) months following the previous
audit date. For example, if a VAR had an audit on March 15, they have to register for their second audit no
later than September 15. Failure to do so within the six (6) month grace period will render the second
audit a failure by default.
A VAR who fails their second audit attempt within the 12-month period can only register for another audit
no earlier than 12 months following the second audit date.
Following are the implications for failing an audit effort:
Deals sold thereafter shall only be under the SAP-Delivered Support model
Maintenance for existing customers shall be delta-billed
Support authorization, if previously granted, shall not be renewed
SAP SE 2014
79
For a Readiness Audit, the audit date represents the date of the audit interview session. For other audit
types and if there is no audit interview conducted, the audit date reflects the certification report creation
date.
7.4 Combined Certification

VARs with various subsidiaries could opt to jointly register for the audit process. This is only applicable,
however, to VARs who either follow similar support processes (for example, incident handling process is
the same across all and utilizes the same applications throughout) or those operating under a centralized
support hub. For example, it is not possible for a VAR to request for a combined audit if even one VAR is
using an alternate incident management system. This will deviate from a common process and will
require the SAP Auditor to perform an individual evaluation.
A combined certification request does not change the audit process but would require a few additions in
the following areas:
Chapter 9 of the Partner Center of Expertise Checklist should be completed where the
relationship between participating VARs should be clarified.
The PCOE questionnaire should also include localized information such as support hotlines,
support representatives, localized materials, statistics, where applicable.
A minimal audit interview could be required for random subsidiaries of the SAP Auditors
choosing. Therefore, the audit phase could be longer than that of an individual scope.
Identification of the leading support unit representing all other participants in common aspects
or components.
In some cases, support staff may be located in different VAR subsidiaries. Do consider the following
guidelines:
The VAR Partner should ensure that all support locations fulfil the support consultant
requirement which mandates that at least two support staff achieve Q_SUPP certification per
support location.
For each product family supported per support location, the product-specific certification
should be achieved by at least two (2) individuals.
It should also be further noted that there is no guarantee that all VARs participating in this joint exercise
shall have the same results as the execution of support deliverables and compliance elements shall still
be evaluated on a per VAR Partner basis.
Is it expected that VARs who initially certified under a combined scope should also do so upon recertification?
No. The audit effort and strategy is dependent on the VAR situation and preference at the time of recertification. Therefore, the VAR is free to have the same entities participate in a re-certification effort, to
add more or reduce participants, or to revert to individual audits.
SAP SE 2014
80
7.5 Global VARs
There are no differences in the audit process delivered for a VAR that is involved within a Global VAR
(gVAR) agreement. As such, a gVAR subsidiary can choose to certify on their own (individually) or to
participate in a combined audit scope as discussed in Section 7.3 of this chapter.
It is advisable for Global VARs to look into the following steps to formalize a Partner Center of Expertise
certification strategy:
a. Identify all subsidiaries that have signed the Country Specific Participation Agreement (CSPA).
Further determine the solution areas supported by each subsidiary and the support model (VARDelivered Support or SAP-Delivered Support) chosen moving forward.
b. Considering all identified subsidiaries, check for similarities in support execution. These could include
the following areas or criteria; geographic location (region), solution areas they support,
infrastructure usage, support model chosen). Thereafter, these common areas should then define
the different variants by which certification can be planned.
c. Determine the certification route for each variant; Individual or Combined.
Further consider timelines for certification and continuous review sessions for additional and/or new
subsidiaries.
SAP SE 2014
81
Appendix A: Quick Links

All Quick Links
https://support.sap.com/support-programs-services/about/vanity-linksquicklinks.html
Application
Lifecycle
Management
End to End
Solution
Operations
https://support.sap.com/support-programs-services/solutionmanager/processes.html
http://www.youtube.com/runsap
RunSAP
Methodology
https://support.sap.com/support-programs-services/methodologies.html
Support
Standards
http://support.sap.com/supportstandards
Tools
https://support.sap.com/support-programs-services/solutionmanager/integrated-tools.html
VAR Partner
General
Information
https://partneredge.sap.com/en/partnership/about-sap-partneredge/sellpartners/var.html
Incident
Handling
SAP Notes
Database
http://support.sap.com/notes
SAP Incident
Wizard
http://support.sap.com/incident
Correction
Downloads
http://support.sap.com/patches
Software Center
https://support.sap.com/documentation.html
Software
Download
http://support.sap.com/swdc
Remote
Connection
http://support.sap.com/access-support
SAP SE 2014
82
Partner Center
of Expertise
General
Information
https://partneredge.sap.com/en/partnership/support/pcoe-certi.html
SAP Incident
Wizard
http://support.sap.com/incident
SAP
EarlyWatch e
General
Information
http://support.sap.com/ewa
EarlyWatch
Alert Reports
https://support.sap.com/kb-incidents/inbox.html
Remote Support
Component
https://support.sap.com/support-programs-services/remote-supportcomponent.html
SAP Products
General
Information
http://support.sap.com/
Maintenance
Information
http://support.sap.com/maintenance
Platform
Availability
Matrix
http://support.sap.com/pam
SAP Solution
Manager
General
Information
http://support.sap.com/solutionmanager
VAR specific
information
https://support.sap.com/support-programs-services/solutionmanager/partners/sp/setup.html
Functionality
http://www.youtube.com/runsap
https://support.sap.com/support-programs-services/solutionmanager/integrated-tools.html
Online Help
http://help.sap.com/solutionmanager?current=alm&show_children=false
E-Learning
http://service.sap.com/rkt-solman
SAP SE 2014
83
Training
Information
http://www.sap.com/education
Maintenance
Optimizer
Solution
Manager Forum
http://scn.sap.com/community/it-management/alm/solution-manager
Expert Guided
Implementation
Expert Guided Implementation Portfolio
SAP Support
Offerings
General
Information
https://support.sap.com/support-programs-services/programs.html
Maintenance
http://support.sap.com/maintenance
SAP Enterprise
Support
https://partneredge.sap.com/en/partnership/support/ep-support.html
http://support.sap.com/enterprisesupport
SAP Standard
Support
http://support.sap.com/standardsupport
Technical Quality
Checks
https://partneredge.sap.com/en/partnership/support/ep-support/toolsassets.html
SAP SE 2014
84

PCOE Setup Guide 2014 05

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PCOE Setup Guide 2014 05

Uploaded by

Copyright:

Available Formats

Partner Center of Expertise

Chapter 1. Partner Center of Expertise

1.3 Setup Timeline

Chapter 2. Support Infrastructure

2.1 Dedicated Support Hotline

Alternative Modes of Communication

2.2 Remote Connection

2.2 Test Systems

2.4 Incident Management System

2.5 SAP EarlyWatch Alert

2.6 Support Staff

First Level Tasks

Second Level Tasks

Third Level Tasks (usually SAP Support)

Development and Training

2.7 SAP HANA Test System*

Chapter 3. Support Processes

3.1 Customer On-boarding

3.2 Incident Management

Partner Center of Expertise Setup Guide

3.3 After Office Hours Support

SAP Solution Manager

7x24 Support Operations

3.4 Handling Complaints and Escalations

Chapter 4. Marketing & Communications

SAP Enterprise Support

Structuring Your Potential Support Offer

4.2 SAP Communication

SAP Partner Account Manager

SAP Partner Service Advisor

4.3 Maintenance Agreement

Chapter 5. Continuous Improvement

Service Level Reporting

Customer Incident Reporting

5.2 Feedback Gathering

5.3 Service Improvement

5.4 Support Readiness Activity

Chapter 6. SAP Solution Manager

6.1 Customer Landscape Validation

6.1 Project Administration

6.2 Solution Documentation

Technical Landscape Documentation

Business Process Documentation

Custom Code Documentation

6.3 Incident Management

Partner Center of Expertise Setup Guide

6.4 Maintenance Optimizer

6.5 Maintenance Certificate

6.6 Technical Monitoring

6.7 Business Process Monitoring

6.8 Root Cause Analysis

Root Cause Analysis for SAP HANA

Chapter 7. Partner COE Audit Process

7.1 Relevant Roles for the Audit Process

7.2 Audit Types

7.3 Audit Process

Registering for an Audit

Conducting the Audit

Judging the Audit Result

7.4 Combined Certification

7.5 Global VARs

Appendix A: Quick Links

Partner Center of Expertise Setup Guide

Partner Center of Expertise Setup Guide