Partner Center of Expertise
Setup Guide For internal SAP and partner use only
2
Copyright
2014 by SAP SE. All rights reserved.
Neither this document nor any part of it may be copied or reproduced in any form or by any means, or translated into another language, without the prior consent of SAP Active Global Support.
SAP Active Global Support makes no warranties or representations with respect to the content hereof and specifically disclaim any implied warranties of merchantability or fitness for any particular purpose. SAP Active Global Support assumes no responsibility for any errors that may appear in this document. The information contained in this document is subject to change without notice. SAP Active Global Support reserves the right to make any such changes without obligation to notify any person of such revision or changes. SAP Active Global Support makes no commitment to keep the information contained herein up to date.
These materials are subject to change without notice. These materials are provided by SAP SE and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.
TRADEMARKS
All rights reserved. SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE in Germany and other countries.
Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Business Objects S.A. in the United States and in other countries. Business Objects is an SAP company.
All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.
Please see http://www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices.
DOCUMENTATION VERSION
Date: 17 October 2014
Release: 5.2
SAP SE 2014 Partner Center of Expertise Setup Guide 3
Table of Contents
Copyright 2
Table of Contents 3
Introduction 6
Chapter 1. Partner Center of Expertise 7
1.1 Definition 7
1.2 Components 7
1.3 Setup Timeline 7
Set Up 8
Deliver 9
Certify 9
Chapter 2. Support Infrastructure 10
2.1 Dedicated Support Hotline 11
Alternative Modes of Communication 11
2.2 Remote Connection 12
2.2 Test Systems 14
2.4 Incident Management System 15
2.5 SAP EarlyWatch Alert 17
2.6 Support Staff 21
Support Roles 21
First Level Tasks 23
Second Level Tasks 24
Third Level Tasks (usually SAP Support) 24
Development and Training 25
People Certification 26
Outsourcing or Subcontracting 27
2.7 SAP HANA Test System* 27
Chapter 3. Support Processes 28
3.1 Customer On-boarding 28
3.2 Incident Management 28
Preparing an Incident 29
Reporting an Incident 31
Receiving an Incident 31
SAP SE 2014 Partner Center of Expertise Setup Guide 4
Acknowledging an Incident 32
Assigning an Incident 33
Processing an incident 33
Forwarding an incident 34
Closing an incident 35
3.3 After Office Hours Support 35
SAP Solution Manager 36
7x24 Support Operations 36
On-Call Support 36
3.4 Handling Complaints and Escalations 37
Complaints 37
Escalations 37
Chapter 4. Marketing & Communications 38
4.1 Support Presentation 38
SAP Enterprise Support 40
Structuring Your Potential Support Offer 40
4.2 SAP Communication 41
SAP Partner Account Manager 41
SAP Partner Service Advisor 41
4.3 Maintenance Agreement 42
Chapter 5. Continuous Improvement 44
5.1 Support Reporting 44
Service Level Reporting 44
Customer Incident Reporting 45
Team/Processor Reporting 46
Management Reporting 47
5.2 Feedback Gathering 47
Internal Feedback 47
External Feedback 48
5.3 Service Improvement 48
5.4 Support Readiness Activity 49
Chapter 6. SAP Solution Manager 50
6.1 Customer Landscape Validation 51
6.1 Project Administration 51
6.2 Solution Documentation 53
Technical Landscape Documentation 54
Business Process Documentation 55
Custom Code Documentation 55
6.3 Incident Management 56
SAP SE 2014 Partner Center of Expertise Setup Guide 5
6.4 Maintenance Optimizer 61
6.5 Maintenance Certificate 63
6.6 Technical Monitoring 64
6.7 Business Process Monitoring 66
6.8 Root Cause Analysis 68
Root Cause Analysis for SAP HANA 70
Chapter 7. Partner COE Audit Process 71
7.1 Relevant Roles for the Audit Process 71
7.2 Audit Types 72
Readiness Audit 72
Validation Check 73
Re-Certification 73
7.3 Audit Process 73
Registering for an Audit 73
Conducting the Audit 76
Judging the Audit Result 79
7.4 Combined Certification 80
7.5 Global VARs 81
Appendix A: Quick Links 82
SAP SE 2014 Partner Center of Expertise Setup Guide 6
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 Partner Center of Expertise Setup Guide 7
Chapter 1. Partner Center of Expertise
1.1 Definition To ensure that all indirect customers receive the same high
quality support, VARs are expected to set up a Partner Center of
Expertise (Partner COE) whose primary responsibility is to
deliver defined support processes and services for indirect
customers. A Partner COE should be established with the
recommended infrastructure, people, and processes to ensure
a streamlined and effective delivery of maintenance services by
both the VAR Partner and SAP.
1.2 Components To enable a successful support operation, a Partner COE
requires several components to work seamlessly and efficiently.
These components are grouped into the following areas:
Support staffing considering relevant product and
process certifications
Service desk infrastructure including, among others,
service desk applications, test systems, remote
connectivity tools and strategies
Support processes such as those required for
incident or problem management, escalation and
complaint handling, services delivery
Marketing and Communications which provides the
means and visibility through which the support
operations can be introduced and presented competitively.
Quality assurances strategies including support process monitoring and reporting, feedback
gathering, process documentation
Continuous improvement strategies through regular process reviews and customer feedback.
Detailed information with respect to the expected set up of these various components are discussed
through several chapters in this document.
1.3 Setup Timeline It is expected that from the signing of the PartnerEdge agreement and opting for the VAR-Delivered
Support model, VAR Partners have to start setting up plans and strategies to establish their Partner COE.
Therefore, VARs should carefully go through the maintenance instructions under Exhibit 4 of their
PartnerEdge agreement to determine the requirements and standards for the support organization
tasked to deliver maintenance services to indirect customers.
A Partner Center of Expertise (Partner
COE) delivers maintenance service to
indirect customers through SAP
recommended infrastructure, processes,
and offerings.
SAP SE 2014 Partner Center of Expertise Setup Guide 8
The setup of a Partner COE is dependent on factors such as the size, supported products, experience,
and maturity of the organization. The timelines shown from Figure 2-1 shows the phases of setting up a
Partner COE.
SET UP
During the Set Up stage, VAR Partners should clearly determine the
requirements and standards for the Partner COE. These could be
accomplished by going through the maintenance instructions from the
PartnerEdge contract, attending focus sessions on PCOE enablement, or
utilizing the assistance of both the Partner Account Manager (PAM) and
the Partner Services Advisor (PSA) to ascertain the requirements and get
the best advice with respect to the set up strategies based on the VAR
Partners situation.
Some of the pertinent activities expected during the set up stage are as
follows:
Determine requirements for the Partner COE according to
business goals and strategies.
Plan, design, and set up physical infrastructure components
such as people, hardware, software, networks, communications.
Set up required connectivity infrastructure between SAP,
customer, and VAR Partner.
Activate functionalities or applications required for regular
monitoring of customer systems and to engage proactive
maintenance services.
Ensure availability of product knowledge through continued
development, training, and certification achievements.
Training and documentation of support processes and
procedures.
Definition of support performance targets and measurement
activities.
Figure 1-1. Timelines towards Partner Center of Expertise Certification
SAP SE 2014 Partner Center of Expertise Setup Guide 9
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 Partner Center of Expertise Setup Guide 10
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 Partner Center of Expertise Setup Guide 11
2.1 Dedicated Support Hotline
As clearly stated, a support hotline should be a
dedicated number that can be reached by customer end
users without need for routing, extensions, or
intermediary communication.
It is preferred that the support hotline meets the
following criteria:
Is a dedicated landline number that directly connects to the support organization
Should have automatic call routing with several lines directly linked to the main support hotline.
Rarely returns a busy signal. For such instances, it is expected that the hotline has a voice mail
facility for support staff to return calls as soon as a line becomes available.
Have automated voice recording for out-of-office announcements. For example, when a customer
calls after business hours, recorded instructions or guidelines are available from the support hotline
providing instructions that a customer can clearly follow to secure support out of regular business
hours.
The call is answered by support staff that clearly identifies themselves as a member of the partners
support organization. For example, when the hotline is reached, a support staff member responds
with Good morning! Youve reached support. How may we help you?
ALTERNATIVE MODES OF COMMUNICATION
Apart from a support hotline, VAR Partners can offer alternative means for accessibility of their support
organization to the customer end users. The following means could also be considered to supplement an
existing support hotline:
Online Support
It is not uncommon for well-established support
businesses to offer online accessibility of their
incident management system or other support-
related facilities such as knowledge bases, forums,
or product information and documentation. Online
availability of the incident management system
allows interactive and efficient means of
communicating incident progress and resolution
with the customer base and offers visibility of issues
logged with the VAR.
Dedicated Support Email Address
As an alternative to a direct call, VARs can also offer a dedicated email address which routes to their
support organization. This, however, is not the most efficient process for incident reporting as an e-
mail typically contains unstructured content and there is no guarantee that the email has been
received by the VAR support organization or, depending on network traffic or unforeseen technical
issues may delay receipt at the partner end. This mode could be best used for incidents not requiring
immediate resolution.
SAP SE 2014 Partner Center of Expertise Setup Guide 12
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 Partner Center of Expertise Setup Guide 13
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 Partner Center of Expertise Setup Guide 14
For non-ABAP platforms, customers can use other options available as listed from the SAP Support
Portal pages. One of the more popular and easiest methods is Netviewer. This allows SAP to either view
the customers screen via a Show Only permission or execute transactions via the Full Access privilege
(requires SAProuter). For information on the usage and application of various remote connection
strategies and tools, please visit http://support.sap.com/access-support.
As a key ingredient for certification, remote connectivity is expected to be available for the following:
between SAP and customer production systems
between VAR Partner and customer production systems
between SAP and VAR Partner test systems
between SAP and VAR Partner/Customer SAP Solution Manager systems
between VAR Partner and Customer SAP Solution Manager systems
Remote Connection Exception
It is acknowledged that some customers may have strict policies regarding connectivity outside their
network. These can be mandated by company or even local policies. For such cases, the VAR Partner
should request its customer for documentation of such policies and to present this to the Auditor for
every audit session. The VAR Partner should initially peruse the document and explicitly indicate or
pinpoint the page/chapter/paragraph where such restriction is stated.
Being a mandatory requirement, the VAR Partner should ensure that compliance for
remote connectivity is generally high within its customer base and its own support
infrastructure. An 85% compliance target is required.
2.2 Test Systems Customers reporting incidents may not necessarily welcome the idea of their systems being used as a
test environment for resolving their own issues. Thus, VAR Partners have to set up a necessary back-up
environment to allow simulation of customer issues on a standard SAP system with a similar product
type, release, and version.
Figure 2-3. Remote Connection Page in the SAP Support Portal
SAP SE 2014 Partner Center of Expertise Setup Guide 15
A test system, therefore, should fulfil the
following factors:
Available onsite at VAR Partner
office for immediate use by
support staff
Test systems should be available
at the VAR Partners office and is
not meant to be the customers
own test system. Test systems
should generally not be used
productively nor should be part
of a transport route.
Based on standard SAP product
version and release
Delivered objects, features, and
functionalities could generally
differ between products and release. Thus, it is essential (and to avoid conflicting results) to
have the same product version and release while performing simulation activities.
Has remote connection to SAP
In the event that a VAR Partner should be able to simulate an incident in their own test systems,
this could be used as an alternative system by SAP support in the event that a connection to the
customer is not possible. Thus, a remote connection to SAP is also necessary.
Should use the partners own demo/productive installation numbers
Test systems should use the partners own licensed installation. Thus, it is not expected that a
partner uses the installation number of their customers to be used for their test environment.
Test systems should be available for all products with versions and/or releases used by
the customer base. These should have remote connection established with SAP.
2.4 Incident Management System
It is preferred that VARs should use the SAP Solution Manager Service Desk as the primary incident
management system. For VARs supporting SAP Business All-In-One and/or SAP HANA, this is a
required infrastructure component.
The SAP Solution Manager Service Desk is able to fulfill both first level and second level processing
activities as recommended from the agreement and should be able to cover the following processes:
Receipt and classification
Incidents should be received immediately upon posting by a customer end user. There should be
minimal delay in receipt of the responding support unit so as not to cause any reason for
complaint or frustration on the part of the customer end user.
Test systems can be used to simulate incidents
that could otherwise not be performed in a
customers productive environment.
SAP SE 2014 Partner Center of Expertise Setup Guide 16
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 Partner Center of Expertise Setup Guide 17
Tracking, monitoring, and reporting
To enable the support organization to immediately identify incidents that require processing, it is
strongly required to have an incident management system with flexible monitoring and reporting
capabilities. It is highly required to provide for tracking of pending incidents. This should include
information on the unique incident number, priority, short text, processor name and incident
status. It is also beneficial to have information on last changed date, service level adherence, and
escalation flags (if available).
Monitoring should be conducted several times daily while
reporting can be run periodically depending on business
requirements as well as for performance monitoring.
Online accessibility of an incident management system is
a must and should be fully integrated with SAPs support
network. Partners should ensure that their incident
management systems online address is available for
access through the SAP Support Portal. Please see SAP
Note 1285423 for instructions to accomplish this
integration.
Use SAP Solution Manager Service Desk for incident handling and/or integrate 3rd party
systems, if applicable. Online availability should be possible and is integrated with the
SAP Support Portal.
2.5 SAP EarlyWatch Alert The SAP EarlyWatch Alert is a tool that monitors the essential administrative areas of SAP components
and provides information on their performance and stability. This is a facility that executes automatically
so that customers can react proactively before an issue becomes critical.
VAR Partners are required to activate this functionality for all productive installations of its customer
base. The collected data can then be transferred to the VAR Partners SAP Solution Manager (Scenario A
of Figure 2-5). It is always preferred that customers run their own SAP Solution Manager system
(Scenario B of Figure 2-5) and transfers this data therein but a close alternative is for customers to
transfer data into the VARs SAP Solution Manager system if they have none of their own. VARs should
review the SAP EarlyWatch Alert reports of their customers at least four times a year. Any SAP
EarlyWatch Alert report that receives a critical (red) rating overall should be referred to SAP for further
action.
To activate the SAP EarlyWatch Alert, simply follow the instructions given in the Best Practice:
Activating SAP EarlyWatch Alert in End Customer's System. You can access the Best Practice at the
Solution Manager Setup page for VAR. You can also use the SAP Online Help on SAP Solution Manager.
Figure 2-4. SAP Solution Manager
Service Desk Reporting
SAP SE 2014 Partner Center of Expertise Setup Guide 18
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 Partner Center of Expertise Setup Guide 19
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 Partner Center of Expertise Setup Guide 20
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 Partner Center of Expertise Setup Guide 21
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 Partner Center of Expertise Setup Guide 22
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 Partner Center of Expertise Setup Guide 23
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 Partner Center of Expertise Setup Guide 24
SECOND LEVEL TASKS
Duties
Subsequent to First Level and includes the following tasks:
Searches for errors using the data from end user
Checks customizing settings
Looking for fault through
o system and core dumps
o debugging
o trace analysis
Analyzes technical data and document incident progress
Reproduce and isolate the incident
Decide if incident is due to a defective or non-defective cause
o Propose appropriate system configuration or work-around if the cause is non-defective
o Forward incident to Third Level (SAP) if the cause of the incident is a software defect / fault
and no SAP note is available to correct it
Document the solution approach
Check and test the solution in a test system
Second Level Employee Profile
Finding the solution using their own expertise, solution database, or product documentation
Completing the incident by requesting the missing information from the previous Level or
directly from the reporter
Performing a detailed problem analysis (Customizing, dump, trace, debugging)
Provide direct support to the reporter in complex cases (for example, for importing patches, and
so on)
Training new employees by means of internal courses
Collaborating with the SAP Support Organization
Detailed SAP know-how
Technical know-how
THIRD LEVEL TASKS (USUALLY SAP SUPPORT)
Duties
Detailed analysis of recorded traces and error messages
Creating or modifying SAP Notes regarding
o Identified cause of defect
o Incident resolution process including all material/information (e.g. bug fixes, patches, work-
around description) to update SAPs support system
Specify expected duration to fix defects by patches, bug fixes, or support packages
Recommend workarounds and alternative solutions
Access customer end user systems through the SAP Support network
o to analyze end users system regarding the incident
o assist end user in order to perform the required and applicable incident remedy by using
workarounds or fixes
o change coding, provide fixes, and create patches
A VAR should also clearly determine which product areas will be supported depending on the
products/components installed at their customer base. Foremost amongst these core components for
SAP Business All-In-One are Basis, Financials & Controlling, Sales & Distribution, and Materials
Management. However, VARs should always look into products and/or components installed at
customers to appropriately determine the correct support staffing expertise needed.
SAP SE 2014 Partner Center of Expertise Setup Guide 25
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 Partner Center of Expertise Setup Guide 26
PEOPLE CERTIFICATION
The Partner COE program requires the fulfillment of two people certification variants:
Support-specific qualification and
Product-specific certification
Support-Specific Qualification
Every VAR support unit should have at least two (2) support staff who have completed a support-specific
web-assessment qualification, Q_SUPP_1, as a mandatory requirement. A minimum of two achievements
should be fulfilled regardless of the number of products supported.
C_PXSUP_90 or C_BOSUP_90 certification will continue to be accepted in lieu of Q_SUPP_1, until further
notice.
Product-Specific Certification
In addition to support-specific certification, VAR Partners having support staff providing incident
handling services should have at least two product-specific certificates for each supported product area.
These are equivalent to SAP Associate Certification at a minimum. Examples of these product or
application-related certification are as follows:
SAP Product
Family
Exam ID Exam Description
Analytics C_BOBIP_4* SAP Certified Application Associate SAP BusinessObjects Business Intelligence Platform
C_EPMBPC_* SAP Certified Application Associate SAP BusinessObjects
Planning and Consolidation
C_EPMFC_* SAP Certified Application Associate SAP BusinessObjects Financial Consolidation
C_GRCAC_10 SAP Certified Associate Access Control with SBO GRC 10.0
Applications C_A1LOG_* SAP Certified Application Associate Logistics with Business All-In-One Solution
C_A1FIN_* SAP Certified Application Associate Financials with Business All-
In-One Solution
C_SRM_7* SAP Certified Application Associate Supplier Relationship
Management 7.0
C_TCRM20_7* SAP Certified Application Associate CRM Fundamentals with SAP CRM 7.0
C_TERP10_6* SAP Certified Business Associate with SAP ERP 6.0
C_THR12_6* SAP Certified Application Associate Human Capital Management with SAP ERP 6.0
Mobile C_AFARIA_01 SAP Certified Application Associate SAP Afaria 7.0 Administrator
SAP SE 2014 Partner Center of Expertise Setup Guide 27
C_SUPADM_01 SAP Certified Application Associate Sybase Unwired Platform 2.1 Administrator
C_SMPADM_23 SAP Certified Application Associate - SAP Mobile Platform Native
and Hybrid Application Administration (SMP 2.3)
SAP HANA C_HANASUP_1 SAP Certified Support Associate SAP HANA
OUTSOURCING OR SUBCONTRACTING
It is also not uncommon for some VAR Partners to outsource some components to other parties outside
of their general area of expertise. For instance, some VARs would outsource either the Basis component
or specialized components such as HR, CRM, or some industry solutions. Such situations are considered
as sub-contracting. It is important to note that the PartnerEdge Channel Partner agreement does not
allow sub-contracting of any maintenance service without explicit approval by SAP. Thus, an audit may
not include services provided by third party and could lead to critical gaps in your maintenance provision.
This could ultimately lead to an audit failure. Thus, do contact your Partner Account Manager for current
SAP policies on this arrangement prior to PCOE registration.
Should an explicit approval be available, do expect that the Auditor may request documentation and
participation from the third-party unit to verify support arrangements and integration of support
operations between both parties. The PCOE auditor may also request that a third-party representative be
present during the audit interview should this be deemed necessary.
Support staff available on a full time basis.
People certification (both support-specific and product-specific) requirements should be achieved by VAR Partner support units.
Each VAR Partner with support staff performing incident management processing should have at least two (2) support consultant certificates PER support unit.
2.7 SAP HANA Test System This section is only applicable for VAR Partners providing support for SAP HANA.
It is a mandatory requirement for VAR Partners supporting SAP HANA to have a functioning test system
for this product. This must be in place, even if they have no customers with SAP HANA systems yet.
Partners must demonstrate that they have the knowledge and ability to set up Root Cause Analysis and
perform SAP EarlyWatch Alert data transfers via SAP Solution Manager for their SAP HANA test system.
During the PCOE readiness audit (or recertification audit), the following will be checked:
The partners SAP HANA test system is connected to an SAP Solution Manager system through
which the functionalities for root cause analysis and SAP EarlyWatch Alert should be
operational.
Remote connection types SSH and SAP-DB are established and connected to SAP.
SAP SE 2014 Partner Center of Expertise Setup Guide 28
For VAR Partners supporting SAP HANA, an SAP HANA test system must be available
which fulfils the following requirements:
Has remote connection to SAP including both SAP-DB and SSH connection types.
Is connected to an SAP Solution Manager system.
Root cause analysis via SAP Solution Manager has been set up and is operational.
SAP EarlyWatch Alert reports are available to demonstrate that data transfers have been executed through SAP Solution Manager.
Chapter 3. Support Processes
Within a support operation, there are processes that should be present to ensure that maintenance
services are delivered based on defined strategies and methods. These should include standardized and
streamlined procedures from the introduction of new customers to activities performed for both
corrective and preventive maintenance offerings. Procedures should also be in place for critical situations
which could occur outside of normal scenarios.
The audit process considers the following basic processes that are expected to be available for VAR
support operations:
Customer On-boarding
Incident Management
After-Office Hours Support
Complaint and Escalation Handling
Support Readiness Checks
Every support organization should clearly document their support processes as a general guideline for
new hires, for mentoring purposes, and as reference both for improvement and extraordinary
circumstances. It is a good practice to review existing processes from experience by internal staff and
explicit feedback from the customer base. This helps support organizations focus on areas which need
further development, improvement, or modifications.
3.1 Customer On-boarding Within a support operation, there are processes
that should be present to ensure that
maintenance services are delivered based on
defined strategies and methods. These should
include standardized and streamlined
procedures from the introduction of new
customers to activities performed for both
corrective and preventive maintenance offerings.
Procedures should also be in place for critical
situations which could occur outside of normal
scenarios.
3.2 Incident Management Incident and Problem Management could be extremely simple or complex usually depending on several
factors such as:
Customers have to be familiar with maintenance
procedures and deliverables. VARs should ensure
that an activity exists where support-specific
topics are clearly discussed.
SAP SE 2014 Partner Center of Expertise Setup Guide 29
size of the support organization
incident management system capabilities
organization targets and goals
Differences occur in the execution but should usually follow the same seamless process. An incident
management support process from the VAR support unit has the following basic workflow actions:
Incident Receipt
Incident Acknowledgement
Incident Dispatch
Incident Processing
Incident Forwarding
Incident Closure
Feedback
The Feedback process would be explained further in Chapter 5, Continuous Improvement.
PREPARING AN INCIDENT
Even for the most mature organizations, incidents are not an unlikely event. Thus, it is expected that
customers are dutifully prepared to respond to such situations by appropriately compiling information
necessary to report the occurrence and justify expected outcomes.
Self-Service
Before an incident can be created for the VAR support organization, it is highly recommended that the
customer end user tries to resolve the
incident within their means. This could be
through the use of an available solution
database, help documentation, or training
materials. An end user could also refer the
incident to their own key users, business
process owners, or competence teams.
These individuals or units could perform
initial review of the incident and could
offer potential solutions.
Reporting incidents to a central
competence group within the customer
organization is also a good practice as this
helps to prevent end users from posting the
same incidents to the VAR especially in
cases when the incident occurs with
multiple users within the same period. This
also helps to ensure that expected
outcomes for an incident are correct.
Once the customer has decided that it could not resolve the incident, then it can refer to the VAR support
organization for handling.
Preparing an Incident
It is important for the support organization to have provided clear directions which methods are available
for logging of incidents. Equally important are the details required by a support organization to
immediately process an incident. Following should be mandatory information for an incident to be
processed. Following are some of these relevant details (see also SAP Note 16018).
Customer end users can refer their incidents with
internal key users or business process owners as the
initial resolution step before incidents are raised to
the VAR.
SAP SE 2014 Partner Center of Expertise Setup Guide 30
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 Partner Center of Expertise Setup Guide 31
REPORTING AN INCIDENT
Depending on the setup arranged with the VAR, an incident could be reported by any of the following
individuals:
End User: any end user from the customer could report an incident directly to the VAR
support organization.
Key User: individuals within the customer organization who have in depth knowledge of the
transaction for which an incident is to be reported on.
Business Process Owner: an individual who has detailed knowledge of the business process
for which the incident is related to. This individual could also have been involved in the
implementation process and is aware of the activities, decisions, and execution of the
companys business process.
Competence Team: a group of individuals set up by the customer organization to function as
a support unit for its end users. The team is comprised with individuals experienced in the
implementation and execution of the companys business processes.
Either an individual or unit is responsible for posting an incident, the VAR Support organization should
generally be communicating with an individual which will be herein designated as a Reporter.
A customer would be provided methods and tools by which an incident can be reported to the VAR
support organization. The most popular communication media are either online, phone or email.
Depending on methods used, a customer should be dutifully prepared to provide all relevant details to the
VAR support organization.
RECEIVING AN INCIDENT
There are different methods by which a support organization could receive an
incident from its customer base. This depends greatly on the provided
communications infrastructure as well as the features available from the
incident management system. Information gathered from this process is
significant as it would direct the efficiency by which an incident can be
processed by the support organization.
Execution plans vary depending on the method by which an incident is logged
as discussed in the following topics.
Incident received online
Preferred method
Near real time receipt by the VAR support organization depending on network traffic
Provision of forms for detailing relevant incident information
Depending on incident management system features, can immediately dispatch an incident based on priority and/or component area to a specific support unit or processor
Incident received via phone
Received real time
Requires manual work from the VAR to collect information from the Reporter and post this subsequently to the incident management system
Details can be requested from the Reporter by following a pre-defined form from the incident management system
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
Possible confusion or misunderstanding of Reporters statements which could lead to improper dispatch or delays in processing
SAP SE 2014 Partner Center of Expertise Setup Guide 32
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
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
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 Partner Center of Expertise Setup Guide 33
ASSIGNING AN INCIDENT
Upon receipt and subsequent review, the support staff with the Dispatcher
role can then assign an incident to the relevant consultant. An incident is
dispatched based on the following criteria:
Component/product
Priority
Availability of consultant
Most incident management systems allow for the input of assigned
processors. This could also trigger an automated response through email
upon assignment. Thus, the processor is informed when an incident has been
assigned to him.
There are cases, however, that the Dispatcher role no longer exists. This
could apply to large support organizations where support consultants are
primarily responsible for ensuring that their queues (assigned areas of
responsibility) are properly monitored. Thus, support consultants are
responsible for assigning incidents in their name, ensuring that incidents are
prioritized based on defined criteria, and that incidents that have been
returned for their review and continued processing has been returned to their
specific queues.
PROCESSING AN INCIDENT
Once an incident has been assigned for processing, the Processor reviews the
contents of the incident. This may include the following activities:
Determining whether the component / product have been properly assigned. Otherwise, the processor can change the component and subsequently send it back to the Dispatcher for re-assignment.
Verifying priority setting and adjust as necessary with proper communication to the Reporter.
Determining whether the incident is related to an error or requires consulting work. For the latter case, then it may be necessary to discuss options with the customer.
During processing, a support employee may need to use several sources for responding or verifying their responses to the Reporter. These could be any of the following sources:
Training Materials
Help Documentation
SAP Support Portal
SAP Notes Database
Own Solution Database
Peer Networks
Product Forums
In some circumstances, it may also be necessary for a support employee to
simulate the incident through a test system with the standard SAP product
installed. Simulation is needed in the following cases:
Verify if the steps performed by the end user is correct and conforms to proper procedures
If errors are not received in the standard test system, it can be assumed that the incident is local to the customers solution landscape
SAP SE 2014 Partner Center of Expertise Setup Guide 34
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 Partner Center of Expertise Setup Guide 35
CLOSING AN INCIDENT
An incident can be closed if the customer confirms that the solution proposed
by the VAR has resolved their incident. The VAR can consider the following
strategies for closure:
Allow the customer to close the incident on their own. This could lead to situations when an incident could be left unclosed for a long time unless the customer is constantly reminded to do so.
Conduct follow-up sessions regularly to remind customers of incidents that could be closed. This approach would require a resource and corresponding effort to follow-up with customers. This may not be an acceptable task for VARs with a huge customer base.
Allow for automatic closure after a reasonable period depending on priority level. This should be clearly known by the customer to avoid complaints. This helps eliminate any further manual follow-ups from the support unit.
It is important to ensure that customers have provided either a reply to
confirm that their incident has been resolved or that they explicitly close the
incident.
For incidents that have also been referred to SAP for resolution, the VAR
should not forget to explicitly confirm the incident with SAP. Nevertheless,
SAP follows automatic closure processes and the incident will be closed if
there has been no action after a specific amount of time.
An incident management process must be in place and documented in alignment with
the incident management system.
3.3 After Office Hours Support Both SAP maintenance offerings, SAP Standard
Support and SAP Enterprise Support, provide 7x24
round-the-clock incident processing services globally.
SAP utilizes all major support hubs within Asia, Europe,
and the Americas to allow continuous support to its
customer base everywhere in the world.
VAR Partners are not expected to set up an operation
as vast as SAP, but is enjoined to use SAPs global
support network to similarly provide 7x24 support to
its local customer base. For VARs supporting either
SAP Business All-In-One and/or SAP HANA, a
connection must be set up between its incident
management system and SAPs support backbone
using SAP Solution Manager as the interface between
both parties. Outside of this facility, VARs need to offer
after-office hour support through its own resources
VARs are enjoined to utilize the SAP
Support network to provide 7x24 support
for its customer base.
SAP SE 2014 Partner Center of Expertise Setup Guide 36
and facilities. The following common strategies could be used for this purpose:
SAP Solution Manager
7x24 support operations
On-call support
SAP SOLUTION MANAGER
SAP encourages its VARs to use the Service Desk functionality within the SAP Solution Manager to allow
automatic forwarding of priority incidents to SAP outside business hours. This is performed through
customization of the Service Desk facility to identify out-of-office hours and to also identify certain
conditions for immediate forwarding such as for components that are mainly processed through SAP
support; i.e. component XX-SER*.
The default and most common set up with the SAP Support network is to only forward incidents under
priority Very High and to do so only outside the VARs business hours. Therefore, incidents from other
priorities are not forwarded and could be processed by the VAR support team during their regular
business times.
7X24 SUPPORT OPERATIONS
For some mature and/or larger VARs, a fully-staffed 7x24 operation may already exist with support staff
working beyond office hours on roster or similar to SAP operations, where support could be handed over
to other subsidiaries outside the local business hours. Hence, incidents can be reviewed at all times and
where resolution activities are able to proceed even outside a customers normal business hours.
For VARs with a small customer base, this is not a recommended approach due to its cost implications
and the minimal possibility of incidents being posted outside regular hours.
ON-CALL SUPPORT
For VARs who do neither use SAP Solution Manager Service Desk nor have a 7x24 fully staffed support
operation, incidents received after office hours could be routed to an on-duty support staff via its support
hotline. On-duty support staff could determine the urgency of the call and can determine whether further
expertise may be required within the support team or if the incident necessitates referral to SAP Support.
VARs often provide on-call support providing alternate phone numbers to customers that is most often
an individual mobile number of specific support staff. This is not encouraged as this does not allow
permanency and could change as many times as support staff changes. It is not recommended to
consider this strategy during an audit. It is more preferred to utilize the dedicated support hotline which
should automatically route to other numbers as an alternative rather than providing multiple numbers for
customers to remember.
A 7x24 support offering is a mandatory requirement and should normally be
accomplished using the SAP Solution Manager Service Desk functionality for
connectivity with the SAP Support backbone.
SAP SE 2014 Partner Center of Expertise Setup Guide 37
3.4 Handling Complaints and Escalations
COMPLAINTS
During the processing of an incident, a customer can contact the support unit if they are, in any way,
displeased with either the progress of resolving an incident or the solution quality. In such cases, the
customer could contact the support organization to address such complaints and these have to be
properly noted and monitored to avoid the complaint from escalating any further.
Complaints have to be reviewed and ownership has to be set where an individual takes responsibility for
addressing the complaint and ensuring that a satisfactory response is provided.
The complaint owner has to dutifully monitor that the incident progresses and is resolved to the
customers satisfaction and to constantly provide feedback and communication as well.
After a complaint has been resolved, it is a good practice to review the case and to derive possible
lessons from it as a means to improve the overall support performance and quality.
ESCALATIONS
Escalations would normally be viewed as either a functional escalation or a hierarchical escalation.
A functional escalation is generally executed
within the a normal incident handling process
where an incident could be forwarded
(escalated) to the next higher support level if
lower levels are unable to offer a satisfactory
solution.
A hierarchical escalation involves the elevation
of an incident not only through support levels
but also across management or different lines
of business. This involves situations when an
incident may require exceptional processing
and may deviate from the normal support
processing procedures. These situations have to
be properly identified and should have a defined
action plan. Though this can occur in the middle
of incident processing, these can also be identified at the onset of incident receipt. Thus, escalations
could be identified through specific triggers such as:
Severe financial or business impact: This pertains to a significant loss of business or revenue
until an incident is resolved. This would normally merit attention from high-level management
and require immediate resolution and constant monitoring.
Production Down: Though it is not uncommon to have situations when an application goes
down, the situation becomes more critical if it has been clearly identified that the application
may not be brought up within a short period. For example, a customer experiences a hardware
crash and realize that they have no available backup from the past months. System could not be
restored immediately and without prolonged effort which could lead to potential business loss.
Service Level Exceeded: There could be financial aspects to missing service levels which could
necessitate extra attention and faster processing.
Go Live Endangered: Go live is a highly critical phase not only involving the customer, their
business, but other parties as well such as the implementation team. This has the potential to
affect both financial and business aspects, such as added consulting man days, re-adjustment of
resources, activities, and timelines. Thus, incidents contributing to a possible delay in go live
needs to be addressed expediently.
Escalation procedures are triggered by specifically
defined events or situations that would normally merit
expedited processing due to business or financial risks.
SAP SE 2014 Partner Center of Expertise Setup Guide 38
Similar to complaints, escalations should have clear ownership for resolution, identified action plans, and
constant monitoring and communication until its resolution.
In cases when SAP becomes involved in an escalation situation, it is important to ensure that SAP has a
clearly identified contact from the VAR side as well as the customer to properly coordinate activities,
plans, and resources. For such situations, it is also a necessary requirement to have remote connectivity
available to ensure that assistance can be provided by the SAP Support network globally and around the
clock.
Support processes sh