Professional Documents
Culture Documents
Setup Guide
For internal SAP and partner use only
Copyright
SAP and other SAP products and services mentioned herein as well as their respective logos ar e trademarks
or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other countries. Please see
http://www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark
information and notices. Some software products marketed by SAP SE and its distributors contain
proprietary software components of other software vendors.
These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without
representation or warranty of any kind, and SAP SE or its affiliated companies shall not be liable for errors or
omissions with respect to the materials. The only warranties for SAP SE or SAP affiliate company 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 warran ty.
In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business outlined
in this document or any related presentation, or to develop or release any functionality mentioned therein.
This document, or any related presentation, and SAP SE’s or its affiliated companies’ strategy and possible
future developments, products, and/or platform directions and functionality are all subject to change and
may be changed by SAP SE or its affiliated companies at any time for any r eason without notice. The
information in this document is not a commitment, promise, or legal obligation to deliver any material, code,
or functionality. All forward-looking statements are subject to various risks and uncertainties that could cause
actual results to differ materially from expectations. Readers are cautioned not to place undue reliance on
these forward-looking statements, which speak only as of their dates, and they should not be relied upon in
making purchasing decisions.
DOCUMENTATION VERSION
Release: 5.4
2
Table of Contents
Copyright 2
Table of Contents 3
Introduction 6
Set Up 8
Deliver 9
Certify 9
Chapter 2. Support Infrastructure 10
2.1 Dedicated Support Hotline 11
Reporting an Incident 31
Receiving an Incident 32
Internal Feedback 48
External Feedback 49
5.3 Service Improvement 49
5.4 Support Readiness Activity 50
Chapter 6. SAP Solution Manager 51
Readiness Audit 72
Validation Check 73
Re-Certification 73
7.3 Audit Process 73
Registering for an Audit 74
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.
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:
Detailed information with respect to the expected set up of these various components are discussed
through several chapters in this document.
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 Business Manager (PBM)
and the Partner Services Advisor (PSA) to ascertain the requirements
and get the best advice with respect to the set up strategies based on
the VAR Partner’s situation.
Some of the pertinent activities expected during the set up stage are
as follows:
CERTIFY
After maintenance services have been delivered to customers and
where Partner COE elements have been tried, tested, and evaluated,
the VAR Partner should be ready for an audit exercise. The Partner
COE questionnaire should be completely filled providing documents
where necessary to better describe and showcase the VAR Partner’s
Partner COE operations.
For VAR Partners with an existing support business, compliance with SAP requirements necessitates a
review of existing tools and systems to ensure that compliance is not compromised and is met as closely
as possible to guarantee that support services are not jeopardized for both SAP and the VAR Partner’s
mutual customers. Any deviations from SAP’s standard requirements have to be clearly explained to an
Auditor for clarification and recommendations, when necessary.
From the maintenance instructions as provided in Exhibit 4 of the SAP PartnerEdge Channel Agr eement,
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.
Apart from a support hotline, VAR Partners can offer alternative means for accessibility of their suppor t
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.
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:
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.
For SAP customers, remote connectivity with SAP’s support backbone is a mandatory requirement for all
productive instances. This is a necessary first step for allowing SAP to provide mission critical services
when it is sorely needed. Without this infrastructure, a customer should clearly understand that SAP or
the VAR Partner is not expected to fulfill service level commitments, where any are made. This could also
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 Citrix GoToAssist or NetViewer, allow
SAP or the VAR Partner to only view customer screens that are
made shown by customers without having an actual physical
connection to customer systems.
VAR Partners should ensure that their customers are fully aware of these security issues and how they
are addressed with current methods. As SAP mandates this requirement with its customers, VAR
Partners have to request their customers to provide this means as a necessary first step for efficient
support especially in critical situations.
SAP offers extensive information on remote connectivity types through the SAP Support Portal pages
under http://support.sap.com/access-support. By far, the SAP software program SAProuter is the
most popular means for controlling and monitoring communication between SAP servers and frontend
computers, as well as enabling RFC access between different servers.
For non-ABAP platforms, customers can use other options available as listed from the SAP Support
Portal pages. One of the more popular and easiest methods is Netviewer. This allows SAP to either view
the customer’s screen via a Show Only permission or execute transactions via the Full Access privilege
(requires SAProuter). For information on the usage and application of various remote connection
strategies and tools, please visit http://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
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.
Based on standard SAP product Test systems can be used to simulate incidents
version and release that could otherwise not be performed in a
Delivered objects, features, and customer’s productive environment.
functionalities could generally
differ between products and release. Thus, it is essential (and to avoid conflicting resul ts) to
have the same product version and release while performing simulation activities.
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.
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:
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
Use SAP Solution Manager Service Desk for incident handling and/or integrate 3 rd
party systems, if applicable. Online availability should be possible and is integrated
with the SAP Support Portal.
VAR Partners are required to activate this functionality for all productive installations of its customer
base. The collected data can then be transferred to the VAR Partner’s SAP Solution Manager (Scenario A
of Figure 2-5). It is always preferred that customers run their own SAP Solution Manager system
(Scenario B of Figure 2-5) and transfers this data therein but a close alternative is for customers to
transfer data into the VAR’s SAP Solution Manager system if they have none of their own. VARs should
review the SAP EarlyWatch® Alert reports of their customers at least four times a year. Any SAP
EarlyWatch® Alert report that receives a critical (red) rating overall should be referred to SAP for further
action.
To activate the SAP EarlyWatch® Alert, simply follow the instructions given in the Best Practice:
Activating SAP EarlyWatch® Alert in End Customer's System. You can access the Best Pr actice at the
Solution Manager Setup page for VAR. You can also use the SAP Online Help on SAP Solution Manager.
The report can be generated and read from the SAP Solution Manager in HTML or Microsoft Word
format. Alternatively, it is possible to automate sending HTML reports per email to assigned recipients.
If SAP EarlyWatch® Alert data cannot be processed in a local SAP Solution Manager system, data from
productive systems can be sent to SAP for processing (Scenario C of Figure 2-5). To learn about the
restrictions and to activate SAP EarlyWatch® Alert data to be processed at SAP, please follow the
instructions from SAP Note 1172939 .
SAP EarlyWatch® Alert is most effective when activated for the production system of each SAP
component in your customer’s solutions. This gives you a complete overview of all components and their
effect on performance and stability. For non-productive systems such as quality assurance,
development, training, or test systems the service can be activated as well. As the check thresholds and
rating rules are set for production system, some results in the SAP EarlyWatch® Alert report do not apply
to non-productive systems. E.g. the backup frequency may be of little importance for a training system,
and so the rating for backups in the SAP EarlyWatch® Alert report can be ignored.
To create the report, SAP EarlyWatch® Alert reads system data and analyzes it against set threshold
values. Depending on the analysis, SAP EarlyWatch® Alert issues a red, yellow, or green traffi c 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.
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.
SAP Note 1257308 provides information with respect to SAP products and components for which SAP
EarlyWatch® Alert is available.
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
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.
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.
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.
Dispatcher
Monitors support queue for new or unassigned incidents
Reviews incidents received for proper priority setting, component
assignment, and incident details. Can send back incidents to customers
if incident details are incomplete.
May not necessarily have product knowledge but understands key
components of incident posting
Can utilize tools and knowledge base to determine proper component
assignment (such as SAP Notes database, customer problem database,
product tools)
Assigns incidents to appropriate support personnel
Processor
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
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:
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
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
Duties
Detailed analysis of recorded traces and error messages
Creating or modifying SAP Notes regarding …
o Identified cause of defect
o Incident resolution process including all material/information (e.g. bug fixes, patches, work-
around description) to update SAP’s support system
Specify expected duration to fix defects by patches, bug fixes, or support packages
Recommend workarounds and alternative solutions
Access customer end user systems through the SAP Support network
o to analyze end user’s system regarding the incident
o assist end user in order to perform the required and applicable incident remedy by using
workarounds or fixes
o change coding, provide fixes, and create patches
A VAR should also clearly determine which product areas will be supported depending on the
products/components installed at their customer base. Foremost amongst these core components for
SAP Business All-In-One are Basis, Financials & Controlling, Sales & Distribution, and Materials
Management. However, VARs should always look into products and/or components installed at
customers to appropriately determine the correct support staffing expertise needed.
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
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.
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.
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 Business Manager regarding specific support topics
o Define new services within your SAP Enterprise Support offering
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:
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_TCRM20_7* SAP Certified Application Associate – CRM Fundamentals with SAP CRM
7.0
C_TSCM42_6* SAP Certified Application Associate - Prod. Planning & Manuf. w. ERP
6.0
C_TSCM52_6* SAP Certified Application Associate - Procurement with SAP ERP 6.0
C_TSCM62_6* SAP Certified Application Associate - Sales and Distribution, ERP 6.0
Mobile C_AFARIA_* SAP Certified Application Associate – SAP Afaria 7.0 Administrator
C_SMPADM* SAP Certified Application Associate - SAP Mobile Platform Native and
Hybrid Application Administration
SAP HANA C_HANATEC151 SAP Certified Technology Associate - SAP HANA (Edition 2015)
SAP CEC H_SUP_5 hybris Product Support V5 Certification (only available from
Commerce PearsonVue)
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 Business 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.
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, e ven 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 via
SAP Solution Manager for their SAP HANA test system. During the PCOE readiness audit (or
recertification audit), the following will be checked:
The partner’s SAP HANA test system is connected to an SAP Solution Manager system through
which the functionalities for root cause analysis should be operational.
Remote connection types SSH and SAP-DB are established and connected to SAP.
For VAR Partners supporting SAP HANA, an SAP HANA test system must be
available which fulfils the following requirements:
Has remote connection to SAP including both SAP-DB and SSH connection
types.
Is connected to an SAP Solution Manager system.
Root cause analysis via SAP Solution Manager has been set up and is
operational.
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.
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
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 Customer end users can refer their incidents with
materials. An end user could also refer the internal key users or business process owners as the
incident to their own key users, business process initial resolution step before incidents are raised to
owners, or competence teams. These individuals the VAR.
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 informa tion for an incident to be
processed. Following are some of these relevant details (see also SAP Note 16018).
System identification
This would include the system id, system type and client number as basic information. For
incidents of a technical nature, information on lower-level components such as the database
and/or the operating system information should be provided.
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.
Short Description
Most incident management systems provide a facility for describing the context of an incident in
a brief one-liner statement. This statement should be as descriptive as possible to indicate
transaction codes, error codes, report/program names or other reference terms where readers
could immediately discern or perceive the content of an incident.
Incident Details
Understandably that most reporters want to send an incident off as soon as possible, the speed
by which an incident was created and sent to the support organization would be fruitless if the
support organization only sends it back with request for additional information that should’ve
been included in the first place. Reports of an incident should meticulously prepare their incident
providing the relevant details to avoid further ping-pong situations between the customer and
the support team for incidents that have unclear or incomplete information. Following
information should be included in the incident description:
o Steps performed prior to the incident. This should include field values in case such values
are significant.
o Expected result of the transaction and actual result. This helps the processor to understand
what the customer is attempting to perform and to immediately discern if the customer has
executed the appropriate steps to arrive at their expected outcome.
o Error details including logs, dumps and screen shots
o Situation with the system prior to the incident (Has there been a modification? Was there
a recent upgrade? Are there any identified changes/improvements on the system? Was
this the first time to execute the transaction?)
o Can the incident be reproduced?
o Is the incident happening with just one user or multiple users?
Impact
For issues that have serious business or financial impact, it is important for customers to info rm
the support unit of the consequence(s) to the business so the incident can be appropriate
processed with urgency and attention.
REPORTING AN INCIDENT
Depending on the setup arranged with the VAR, an incident could be reported by any of the following
individuals:
End User: any end user from the customer could report an incident directly to the VAR
support organization.
Key User: individuals within the customer organization who have in depth knowledge of the
transaction for which an incident is to be reported on.
Business Process Owner: an individual who has detailed knowledge of the business process
for which the incident is related to. This individual could also have been involved in the
implementation process and is aware of the activities, decisions, and execution of the
company’s business process.
Competence Team: a group of individuals set up by the customer organization to function as
a support unit for its end users. The team is comprised with individuals experienced in the
implementation and execution of the company’s business processes.
Either an individual or unit is responsible for posting an incident, the VAR Support organization should
generally be communicating with an individual which will be herein designated as a Reporter.
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.
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
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:
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.
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
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
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:
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
Verify if the steps performed by the end user is correct and conforms to
proper procedures
If errors are not received in the standard test system, it can be assumed
that the incident is local to the customer’s solution landscape
Confirm that proposed solutions achieve the desired effect on a test
system before recommending to the customer.
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
For incidents forwarded to SAP, the VAR should decide whether they will act
as interface to the customer or if the customer themselves would be
responding directly to SAP. It is recommended that the former is used and to
use the latter for incidents that are forwarded to SAP after the VAR’s
business hours.
CLOSING AN INCIDENT
An incident can be closed if the customer confirms that the solution proposed
by the VAR has resolved their incident. The VAR can consider the following
strategies for closure:
Allow the customer to close the incident on their own. This could lead to
situations when an incident could be left unclosed for a long time unless
the customer is constantly reminded to do so.
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.
The default and most common set up with the SAP Support network is to only forward incidents under
priority Very High and to do so only outside the VAR’s business hours. Therefore, incidents from other
priorities are not forwarded and could be processed by the VAR support team during their regular
business times.
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.
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 a nd 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
customer’s satisfaction and to constantly provide feedback and communication as well.
After a complaint has been resolved, it is a good practice to review the case and to derive possible
lessons 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.
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.
For small customers who may hardly have the manpower and infrastructure to build their own application
competencies, a lot rides on its VAR to provide assistance and advise not only on continuing
improvements of its business and productive operations but also on day-to-day incidents that also
contribute to the overall product experience. Having an application that runs seamlessly is a boon and
having immediate support with excellent service and quality is not far behind.
At the onset of the sales cycle, support should be introduced as part of the offering. VARs may have
varied support offerings but this should be complementary to SAP’s support offerings as well. In this, the
VAR should be able to properly communicate and sell their maintenance services clearly outlining their
relationship with SAP as and co-delivery partner of SAP support services.
Description of competencies
and capabilities
Start the presentation with an
introduction of the support
organization, its structure,
goals, targets, and key
achievements. Capitalize on VARs should have available presentation material discussing
resource competencies such as various support-specific aspects to set proper expectations
certifications and experience. with respect to support operations and delivery.
It is also relevant to showcase the growth of a support organization if it conveys the results of
continuous improvements, maturity, and experience of the organization as a whole. This helps to
advertise to customers/prospects that the organization shows and promotes growth that could
benefit them as well.
Infrastructure components that would be of relevance for SAP integration are the following:
- SAP Solution Manager
- Network infrastructure for remote connectivity
- Test systems
- Communications systems
- Incident Management Systems
- Back-up facilities
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.
At a minimum, VARs should review their duties for SAP and the End Customer as provided in
Exhibit 4 of the SAP PartnerEdge Channel Agreement. Thus, all services delivered through SAP’s
support offering should be clearly packaged into a VAR’s standard offering and these should be
clearly aligned with SAP. For instance, since SAP offers 7x24 support for SAP Enterprise Support
customers, a VAR should not charge extra for providing support after office hours and should
delegate this task to SAP. This is provided that the VAR has set up the appropriate and
recommended infrastructure for connecting their customer to the SAP Support network.
It is also vital that VARs do not forget the different SAP Technical Quality Checks (TQCs) that a
customer can utilize in certain situations from SAP. These have to be clearly provided as a
service and benefit and should be showcased in a VAR’s support offering.
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.
Basic services that are required by the majority of your target customers. This also means you
don’t have to ‘negotiate’ what needs to be done to keep a customer’s solution running. For
example, software maintenance which provides for guaranteed response times 24 hours a day
as part of a service level agreement to investigate “breakdown” or critical faults. Remember,
many of your customers have periods when they are working outside normal hours. This is often
when they are busy and therefore these extra hours are the most critical.
Additional services that you can package as an insurance, such as disaster recovery for a
catastrophic incident, sure as a fire, where the servers are lost but a back-up held offsite could
be reloaded to a spare server, getting the customer back live in a short period of time. These can
be charged and delivered at a premium, but it is important to ensure there are not too many
‘Premium’ Packaged offers, so that the customer does not constantly find they are not covered.
Ten years ago many insurance companies went down this route of offering a high degree of
choice in extras, but when customers always found the policy didn’t cover the specific incident
they had encountered, they became dissatisfied and went in search of companies offering a
comprehensive base level, with a few, very specific, premium offers. The same is true with
support. 90% of what 90% of your customers want needs to be in the Base Level, with only
highly specific increments falling into the Premium category either because of their unusual
nature or very high cost to provide.
The final category of support service you need to be able to offer is Ad hoc. This usually is charged
to the customer ‘as required’ but may involve a retainer, or a facility where the customer can, for
example, use 5 hours a month for free, but pay thereafter. Ad hoc support may be used for such
things as managing the back-up process when the IT manager is on holiday, or optimizing the
database remotely. Typically not part of a standard support pack, but something the customer
may want, and is best delivered using the support team.
Objective: The Partner Business Manager is tasked to develop and enable the
business of their assigned VARs and help them extend to their fullest
potential, applying mid-long term view. The Channel Manager will support and
drive development of new business areas for partners.
Tasks
Helps VARs to analyze and leverage business potential using available processes and best practices;
ensures partners become self-sufficient in this.
Creates, monitors, and reviews business and marketing plans together with the assigned partners
using standard tools and templates.
Responsible for partner pipeline management, coverage and reporting.
Monitors overall partner performance including partner satisfaction and develops action plans to
correct as necessary.
Communicates SAP support strategy to Partners to ensure Partners understand the services value
proposition as well as requirements and obligations.
Coordinates with Partner Services Delivery organization where appropriate.
Keeps SAP internal teams informed about partner’s service/support requirements,
recommendations, and other general service/support related feedback.
Tasks
Develops an ongoing enablement plan for partner organization based on individual targets and
requirements
Provides technical knowledge related to SAP product and solutions, new features, and
information on new releases
Helps coordinate access to many of the benefits that the partner organization is entitled to
according to SAP PartnerEdge program level
Proactively informs partner organization of updates and rollout of SAP initiatives
Helps partner understand the program framework and requirements and identify opportunities
to maximize partner performance in the SAP PartnerEdge program
Connects partner with experts from various SAP organizations, particular with specialized
technical resources in industry business units, solution management, and so on
Acts as another feedback conduit into SAP
Elements that could be included in a maintenance agreement between a VAR and its customer base are
the following:
Availability and accessibility of software versions / releases
Explains delivery methods for software upgrades, corrections and/or updates
Corrective maintenance processes and procedures
Discuss the different facilities available for addressing incidents or problems. This also explains
the standard processes or procedures for effecting incident or problem resolution activities.
Preventive maintenance processes and procedures
Identifies facilities, applications, activities, and services providing aid in ensuring stability and
continuous operation of the customer solution.
Service level agreements, if any
States committed response and resolution times for identified conditions or scenarios.
Identify facilities and/or applications inclusive and in aid to support provision
This could mention accessibility of websites for product or support-related topics, solution
databases, forums, and services to assist in maintenance provision.
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:
The audit requires the submission of a maintenance agreement template or any scanned copy of an
existing maintenance agreement signed with an indirect customer with the following conditions:
Submitted template or scanned copy should not contain any price points. These could either be
removed or covered upon submission.
Typifies the basic maintenance coverage for indirect customers.
Between basic maintenance templates with SAP Standard Support and SAP Enterprise Support
scope, do submit the template / copy which includes the SAP Enterprise Support scope.
VARs should provide maintenance agreements for all customers that are in
alignment with their own offering and/or SAP’s.
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.
For VARs with committed service levels, additional data could be provided as with service level
reporting.
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.
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
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.
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.
Competition would also drive improvements where VARs can also look for offerings that would
differentiate or relegate their maintenance services in a different level from other VARs. Thus, constant
development of support staff is a necessary investment and keeping abreast on strategies related to their
products and support services should be encouraged.
Thus, a VAR’s support offering should evolve and grow not only with its customer base but with emerging
technologies. Though it is a good practice to always be a few steps ahead of others, VARs have to clearly
determine areas of need and ensure alignment with existing resources and infrastructure.
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.
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 Des k.
Where such VAR-specific functionalities exist, this platform is to be used.
VARs sell SAP solutions which are tailored to the requirements of small and medium-sized enterprises, to
which they provide first and second-level support. It is assumed that VAR customers may not have their
own SAP Solution Manager. Thus, the VAR should operate an SAP Solution Manager system for its
indirect customers in the event that SAP requires to deliver services under this platform and where
customers may not be able to set up one on their own
To date, SAP Solution Manager is a mandatory requirement for VARs supporting SAP Business All-In-
One and SAP HANA. It remains highly recommended for other product families. Starting from July 2013,
the SAP Solution Manager 7.1 version is required for VARs as SAP Solution Manager 7.0 ends
mainstream maintenance by end of 2013.
The SAP Solution Manager currently supports VARs in performing the following processes and related
tasks:
Project Administration
Solution Documentation
SAP EarlyWatch® Alert (EWA)
Incident (and Problem) Management
Maintenance Optimizer
Maintenance Certificate
Technical Monitoring
During an audit process, the SAP Auditor may conduct a validation check of the SAP Solution Manager
system with respect to the availability of all maintenance customers. Thus, the VAR Partner should then
ensure that customers are maintained, for instance, within the Technical Monitoring or System
Monitoring areas and especially where the Service Desk functionality is used.
Failure to have customers defined within the SAP Solution Manager can entail delays in provision of
services as most functionalities require this specific information to be available. Thus, where SAP
Auditors may deem that customer data in the SAP Solution Manager system is missing, an audit failure
could result. Thus, as best practice, where new customers are added into the VAR Partner’s customer
list, identification of the customer’s landscape (as soon as it is available) should be defined in the SAP
Solution Manager system.
It should also be noted that, at a minimum, the customer’s productive landscape should be maintained in
the VAR Partner’s SAP Solution Manager system. However, defining other system types is also
encouraged.
All maintenance customers should be identified in the SAP Solution Manager system
of the VAR Partner.
VARs should strive to ensure that all customer solutions be made available via an SAP Solution Manager
system, whether this be the customer’s own or hosted by the VAR. At a minimum, the customer’s core
business process(es) should be documented.
Solutions can be manually created from the bottom up, imported from existing documentation (such as
spread sheets), or can be created through solution validation functionalities within SAP Solution
Manager; such as Reverse Business Process Documentation (RBPD).
This chapter identifies three (3) types of documentation in a solution; technical landscape
documentation, business process documentation, and custom code documentation.
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.
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.
- Modifications could be lost during an upgrade that has not be en 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
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.
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.
Within SAP Solution Manager 7.1, VARs have the option to use either the work centers or the ITSM user
interface. SAP Work Centers have been widely used in the previous SAP Solution Manager 7.0 version
where SAP Solution Manager 7.1 offers a few changes which should barely affect customer users who
have been working with the work center interface since.
VAR Partners should ensure that all current maintenance customers are defined in the Service Desk
system. This should allow any customer user to log incidents with their support provider should this be
necessary and critically in urgent situations. SAP Auditors can validate the existence of all customers in
the Service Desk functionality where needed. Thus, completeness in this aspect of the Service Desk
functionality configuration should be ensured.
User Types
There are three user types that echo the authorization profiles that are created for the IT Service
Management in SAP Solution Manager. These are Key User, Processor, and Administrator.
Key Users pertain to customer users and are granted limited authorization to primarily post incidents,
reply to the support unit, and confirm incidents posted. Figure 6-8 shows the basic ITSM interface for a
key user’s Home screen. From this screen, customer users can report incidents to the VAR support
team, display all incidents created by the user, and to also have a widget (Figure 6-10) that shows
incidents that requiring user action.
For creating
incidents
Incident List
A Processor role is expected to be part of the VAR support unit and has required authorizations to view
customer 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.
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.
The Administrator is responsible for the maintenance of the IT Service Management functionality. This
could include creation and maintenance of users, configuration, customization and improvement of the
functionality, as well as providing support and resolution efforts for incidents related to the IT Service
Management. Thus, additional authorization is provided to this user for performing stated tasks on top of
those held by a Processor role.
VARs have to ensure security of its customer data by strictly utilizing the provided authorizations for
specific roles. Using full authorization or Processor authorization for customer users is strictly disallowed
and would result to an audit failure. These could be checked by SAP Auditors to ensure that customer
users have delimited authorizations which prohibit visibility of other customer systems, decrease
authorization to perform tasks that can affect the processing of incidents, and disallow forwarding of
incidents to SAP except for potential Very High priority incidents raised outside business hours.
Amongst the relevant features of the ITSM functionality that can be used are the following:
Service Level Agreements can be set up to trigger specific actions (i.e., sending emails to a
target group / individual) based on a defined set of conditions such as the customer priority,
category.
Multi-level Categorization allows better classification or grouping of incidents relative to
defined criteria. This helps support staff to identify the required expertise for an incident.
Knowledge Articles can be created by a VAR to document incidents and solutions that can be
referenced by other users or by the support staff itself. These articles can include keywords that
could be used when searching for potential solutions to incidents.
Time Recording is essential for situations when effort utilized requires documentation. This
could be for reporting purposes, or in some cases, for potential billing. Times recorded can be
further classified based on work or activity performed.
Access to the SAP Notes Database can be performed directly from ITSM where the user is
redirected to the SAP 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
automatically forward Very High incidents to SAP outside defined business hours by the VAR. For such
Where VAR Partners offer after-office hours support through SAP via the SAP Solution Manager Service
Desk, an SAP Auditor can validate that business hours are appropriately maintained per customer.
Where this has not been set up for some customers, after-office hours support will not work and, hence,
incidents on Very High that are posted beyond business hours will remain at the VAR Partner’s SAP
Solution Manager system until its next business day / hour. Insufficient setup on this aspect could result
in an audit failure. Thus, this has to be ensured for each customer and any new customer, thereafter.
As an advantage of integration, ITSM can receive incidents from other inbound channels such as
projects, solutions, technical and business process monitoring applications and other functionalities
running within SAP Solution Manager that can either manually or automatically trigger creation of
incidents.
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.
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 customer’s solution.
2. Select the required packages and approve the download of the maintenance files.
3. Download the software.
4. Import the software (furthermore uses familiar tools such as SPAM, SAINT, …)
5. Close the maintenance procedure.
It is mandatory for all customers supporting SAP Business All-In-One to ensure that
the Maintenance Optimizer functionality is operational at all times.
Figure 6-15. Automatic Distribution of the Maintenance Certificate for Customers supported by
a VAR’s SAP Solution Manager system
transport management system makes the management of all software and configuration changes
consistent.
Another improvement was the introduction of a maintenance certificate. The certificate enables software
logistics tools to identify your customers’ system and the exact scope of your customer’s corresponding
SAP maintenance agreement. This will also improve the quality of your customer’s SAP solution by
preventing patches from being deployed to the wrong system accidentally.
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.
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
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.
The advent of more complex and diverse business scenarios crossing application borders plus the
immense volume of business transactions processed today require an exception handling that is scalable,
open and central, and embedded into business operations and sup-port processes. The business process
champion and the responsible business process operations team have to define a model and procedures
for handling exceptions and error situations during daily business operations. These procedures describe
what proactive monitoring activities have to be executed to detect business-critical exception situations
and what corrective actions are required in the given context. The procedures also describe who is
responsible for certain activities in the business process operations team or the business unit. The
execution of these procedures can be supported by monitoring and alerting tools within the business
process and interface monitoring concept.
After the exception handling model has been defined, the business process and interface monitoring
standard supports the monitoring of the mission critical business processes, enabling customers to
identify problems long before typical IT alerts would be triggered.
Business process monitoring includes monitoring activities, alert and problem detection, notification of
experts, error handling procedures, and well defined interface towards end-to-end root cause analysis (a
separate standard).
Today’s system landscapes are often decentralized and consist of various interfaces to different
systems, legacy environments, where customers and vendors use different technologies. All those
interfaces need to be monitored in terms of processing errors, backlog situations and performance.
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
3 Party Tool Integration. Alert from other
rd
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
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.
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:
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.
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.
The Partner Certification Auditor (PCA) becomes available to the VAR Partner only within the audit
period. The PCA is an SAP employee with extensive experience on the Partner COE audit process and
requirements and, hence, is an invaluable resource to ensure a successful achievement of support
authorization. PCA recommendations are documented in a report which is provided to VAR Partner
where improvements are noted. During the audit process, the PCA can either validate application usage
(such as SAP Solution Manager) directly or conducts an interview process which helps to clarify aspects
of the VAR Partner’s support set up and usage.
The Judging Committee is comprised of senior support employees at SAP Active Global Support with
expert knowledge on PCOE operations. They review audit reports to cross-check compliance areas and
can add improvement suggestions where necessary. In conjunction with the findings from the PCA as
documented in the audit report, an audit result is decided by the Judging Committee which is later
handed over by the PCA to the VAR Partner as either a pass or fail rating.
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 he lps 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 a udit
types is its absence of customers through which delivery if support services and execution of support
operations could not be assessed. Another clear difference is the mandatory interview required between
the Auditor and key support roles within the VAR Partner’s Partner COE such as the Support Manager.
A VAR Partner should commence the setup of a support operation following SAP standards as soon as
possible following its acceptance as a Value-Added Reseller of SAP. The required infrastructure,
processes, and people certification should be completed and application or registration for the readiness
audit can be made thereafter. VAR Partners should ensure that registration is executed well before any
deal is to be signed so as not to hinder or delay deals in cases where the initial certification checks find
gaps in support requirements.
During this audit exercise, the Auditor would evaluate all key components of a Partner COE operation
such as:
Incident Management system with SAP Solution Manager Service Desk being mandatory for
VAR Partners supporting SAP Business All-In-One and/or SAP HANA. Auditors will require a full
demonstration of end-to-end incident handling processes.
Remote connection infrastructure strategies
Full time support staff with required support consultant certification
Test Systems for products supported
SAP Solution Manager functionality knowledge
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 Business Manager for any
new developments on support authorization requirements.
Where a VAR Partner completes the readiness audit successfully, support authorization is granted for a
12 month period commencing from the audit interview date. This allows the VAR Partner time to acqu ire
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 Partner’s execution of its
support services and operations.
Once completed successfully, the support authorization of the VAR Partner is further extended for
another 12 months.
RE-CERTIFICATION
VAR Partners who has achieved support authorization through either a validation check (starting from
February 2014), via a certification exercise (before February 2014) or via a re-certification exercise are
required to re-certify their Partner COE support infrastructure and operations at least three (3) months
before their current support authorization expires.
A Partner COE re-certification activity re-evaluates the VAR Partner’s performance against SAP’s quality
matrix which includes continued maintenance of mission critical elements such as remote connectivity to
SAP and SAP EarlyWatch® Alert data transfers (where applicable), low customer maintenance
termination ratio, low billable 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.
The audit process contains 3 stages; Registration, Audit, Judging. The following sections discuss the
audit process as executed for the different audit types.
1. Confirmation: This requires a valid signatory of the company attesting to the correctness of all
responses provided in the checklist. Where English is not used for either the checklist responses
or submitted documents, the VAR Partner has to provide confirmation that SAP Auditors may
use translation tools and services (private or public) to convert data and information into
English.
2. Supported Products: the VAR Partner needs to confirm products that will be supported by their
Partner COE. It is expected that all products with status “Authorized” shall also be supported by
the VAR Partner unless the corresponding support dimension for the product have been
maintained as “Opted Out”.
3. Current Support Performance Data: Chapter 4 focuses on performance figures as may be
gathered through SAP internal systems and the VAR Partner’s own. This helps SAP to
understand the VAR Partner’s continued commitment for SAP standards by maintaining high
compliance rates and satisfaction levels.
4. Partner Center of Operations Structure: Chapter 5 requires information pertaining to the
physical elements of a Partner COE setup. This includes support staffing, incident management
system used, remote connectivity strategy, test system availability, systems and database used.
5. SAP Solution Manager: Requires details of the SAP Solution Manager installation and
functionality usage where applicable. This section also clearly discusses the remote connection
requirements and necessary authorizations to be provided for an SAP Auditor to validate usage
and set up of the SAP Solution Manager system.
6. Support Processes: Chapter 7 requests for information pertaining to support procedures and
respective documentation.
7. Continuous Improvement: Requests information pertaining to support-specific reporting and
satisfaction surveys used.
8. Combined Certification: Chapter 9 of the checklist should only be answered if the audit request
is by more than one VAR. Further, the VARs involved should be PartnerEdge VARs opting for
VAR-Delivered Support and are related to each other; i.e. subsidiaries.
VARs should endeavor 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:
Once the checklist has been fully accomplished, the Partner has to prepare that a Solution has been
created in their SAP Solution Manager system and where data has been forwarded to SAP.
Note: During the basic configuration of the SAP Solution Manager system, a default solution
– SAP Solution – is created. This can be used if no other solution has been created in the SAP
Solution Manager system.
Once a Solution has been identified, this has to be explicitly registered with SAP. To do so, from the SAP
Solution Manager system, access the Solution Manager Administration work center and select
Solutions. Solutions created in your system will be displayed in a table. Verify that the solution for your
SAP Solution Manager system is sending data to SAP. This could be checked from the column ‘Sending
Data’ where a tick mark should be present for your solution.
As the SAP Auditor can directly validate the setup 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.
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 Auditor will provide a standard audit agenda which includes the following topics:
Support introduction: The VAR is expected to present how support is generally introduced to
customers. The VAR can use materials that are also submitted with the checklist on this topic. The
Auditor can use this opportunity to understand the VAR’s support offering and operations and allow
clarification of concepts during the audit.
System Demonstrations: VARs are expected to discuss their incident handling system and show how
this is performed via their incident management system from creation to closure. Within this section,
knowledge of SAP Solution Manager functionality should also be demonstrated, where applicable.
Remote connectivity is a critical aspect for provision of maintenance services. VARs will also be asked
to show that they are able to access customer systems (only in cases where partner has existing
maintenance customers), test systems, and their own support systems (especially if support systems
are not locally-based) to verify availability, accessibility, and performance.
Random Interviews: the audit also consists of interviews conducted with different support roles to
determine knowledge and consistency of processes and procedures.
In general, within the audit session the following tasks should be performed and completed by the SAP
Auditor:
Validate the completeness of the submitted Partner COE checklist including submitted documents.
Documents submitted can be opened and read. This requires that documents can be opened by
commonly used tools and applications and are generally in English.
If SAP Solution Manager is used, conduct a remote login to the system to check for functionalities
used.
If SAP Solution Manager Service Desk is used as an incident management system, validate customer
user authorizations.
Trigger test calls within and outside business hours for the identified support hotline number( s).
Where necessary, an audit interview and/or demonstration of systems used can be scheduled to
clarify and understand support operations.
The audit is usually completed within 5-6 hours. The discussions assist the SAP Auditor to determine
actual support provision and capabilities of the Partner as well as confirm the availability of the Partner’s
support infrastructure and operations.
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 performance checks that were not included from the readiness audit exercise.
For re-certification requests, an SAP Auditor will perform tasks both from the readiness audit and
validation check. In addition, a review of the previous report’s recommendations and its application will
be reviewed. Therefore, a VAR should ensure that it has read the recommendations as provided from its
previous audit report and ensured that suggestions for improvement have been performed and are
visible during the re-certification effort. During the re-certification audit, the Auditor will reference the
VAR’s previous audit report and shall check and assess the VAR’s improvement against previous
recommendations.
Do note that a re-certification has more stringent standards with respect to execution of support services
as it is expected that VARs had utilized the two-year duration to improve its support offering and
operations. SAP Auditors would be geared towards direct checks into systems and infrastructure rather
than requiring VARs for demonstrations. Therefore, it is not expected that previous recommendations
are ignored and no improvement is determined within a re-certification exercise.
A VAR should also ensure that they are familiar with current requirements for Partner Center of Expertise
in the event that existing requirements and standards have been changed. Thus, it is encouraged to liaise
with your Partner Business Manager and Partner Services Advisor on a regular basis to ensure that your
Partner Center of Expertise is continuously operating on SAP recommended infrastructure and
processes.
Apart from reviewing improvements from the previous audit report, the SAP Auditor shall also re -
evaluate the VAR’s compliance against any additional requirements at the time of audit. Therefore, it is
expected that the VAR continues to operate its support functions in congruence with SAP standards.
Though the checks performed may be longer in a re-certification effort, this could be minimized with the
absence of an interview session should it be deemed that this task is no longer needed
An audit report is generated for both the readiness audit and re-certification following the activities
mentioned above. The audit report documents relevant findings and compiles recommendations for
improvement. Based on the SAP Auditor’s evaluation of compliance data, an audit result is determin ed.
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.
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.
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.
A combined certification request does not change the audit process but would require a few additions in
the following areas:
Chapter 9 of the Partner Center of Expertise Checklist should be completed where the
relationship between participating VARs should be clarified.
The PCOE questionnaire should also include localized information such as support hotlines,
support representatives, localized materials, statistics, where applicable.
A minimal audit interview could be required for random subsidiaries of the SAP Auditor’s
choosing. Therefore, the audit phase could be longer than that of an individual scope.
Identification of the leading support unit representing all other participants in common aspects
or components.
In some cases, support staff may be located in different VAR subsidiaries. Do consider the following
guidelines:
It should also be further noted that there is no guarantee that all VARs participating in this joint exercise
shall have the same results as the execution of support deliverables and compliance elements shall still
be evaluated on a per VAR Partner basis.
Is it expected that VARs who initially certified under a combined scope should also do so upon re -
certification?
No. The audit effort and strategy is dependent on the VAR situation and preference at the time of re -
certification. Therefore, the VAR is free to have the same entities participate in a re -certification effort, to
add more or reduce participants, or to revert to individual audits.
There are no differences in the audit process delivered for a VAR that is involved within a Global VAR
(gVAR) agreement. As such, a gVAR subsidiary can choose to certify on their own (individually) or to
participate in a combined audit scope as discussed in Section 7.3 of this chapter.
It is advisable for Global VARs to look into the following steps to formalize a Partner Center of Expertise
certification strategy:
a. Identify all subsidiaries that have signed the Country Specific Participation Agreement (CSPA).
Further determine the solution areas supported by each subsidiary and the support model (VAR-
Delivered Support or SAP-Delivered Support) chosen moving forward.
b. Considering all identified subsidiaries, check for similarities in support execution. These could include
the following areas or criteria; geographic location (region), solution areas they support,
infrastructure usage, support model chosen). Thereafter, these common areas should then define
the different variants by which certification can be planned.
c. Determine the certification route for each variant; Individual or Combined.
Further consider timelines for certification and continuous review sessions for additional and/or ne w
subsidiaries.
Application
Lifecycle
Management
RunSAP
https://support.sap.com/support-programs-services/methodologies.html
Methodology
Support
http://support.sap.com/supportstandards
Standards
https://support.sap.com/solution-manager/integrated-tools.html
Tools
VAR Partner
General https://partneredge.sap.com/en/partnership/about-sap-partneredge/sell-
Information partners/var.html
Incident
Handling
SAP Notes
http://support.sap.com/notes
Database
SAP Incident
http://support.sap.com/incident
Wizard
Correction
http://support.sap.com/patches
Downloads
Software
http://support.sap.com/swdc
Download
Remote
http://support.sap.com/access-support
Connection
General
https://partneredge.sap.com/en/partnership/support/pcoe -certi.html
Information
SAP Incident
http://support.sap.com/incident
Wizard
SAP
EarlyWatch® e
General
http://support.sap.com/ewa
Information
EarlyWatch®
https://support.sap.com/kb-incidents/inbox.html
Alert Reports
SAP Products
General
http://support.sap.com/
Information
Maintenance
http://support.sap.com/maintenance
Information
Platform
Availability http://support.sap.com/pam
Matrix
SAP Solution
Manager
General
http://support.sap.com/solutionmanager
Information
VAR specific
https://support.sap.com/solution-manager/partners/sp.html
information
Functionality https://support.sap.com/solution-manager/processes.html
http://www.youtube.com/runsap
https://support.sap.com/solution-manager/integrated-tools.html
E-Learning http://service.sap.com/rkt-solman
Training
http://www.sap.com/education
Information
Maintenance https://support.sap.com/solution-manager/processes/maintenance-
Optimizer management.html
SAP Support
Offerings
General
https://support.sap.com/support-programs-services/offerings.html
Information
Maintenance http://support.sap.com/maintenance
SAP Enterprise
https://partneredge.sap.com/en/partnership/support/ep-support.html
Support
http://support.sap.com/enterprisesupport
SAP Standard
http://support.sap.com/standardsupport
Support