Partner Center of Expertise SAP

Setting up a Partner Center of Expertise
(Partner Guide)
SAP AG August 2010
Copyright
2010 by SAP AG. All rights reserved. SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries. Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Business Objects S.A. in the United States and in other countries. Business Objects is an SAP company. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.
SAP AG 2010 / Setting up a Partner Center of Expertise (Partner Guide) Version 2.7
Page 2
Table of Contents
Copyright......................................................................................................................... 2 Chapter 1. 1.1. 1.2. 1.3. Partner Center of Expertise ............................................................................ 6 Definition ................................................................................................................ 6 Components ........................................................................................................... 6 Certification............................................................................................................. 6 Support Infrastructure ................................................................................... 9 Dedicated Support Hotline ....................................................................................... 9 Remote Connection ...............................................................................................11 Test Systems .........................................................................................................13 Incident Management System.................................................................................14 SAP EarlyWatch Alert ...........................................................................................16 Support Staff..........................................................................................................17 Support Processes ........................................................................................23 Preparing an Incident .............................................................................................23 Reporting an Incident .............................................................................................25 Receiving an Incident .............................................................................................26 Acknowledging an Incident .....................................................................................27 Assigning an Incident .............................................................................................27 Processing an Incident ...........................................................................................28 Forwarding an Incident ...........................................................................................29 Closing an Incident.................................................................................................29 Handling Complaints and Escalations .....................................................................30 Marketing & Communications .......................................................................32 Presentation of Support ..........................................................................................32 SAP Communication ..............................................................................................35 Continuous Improvement .............................................................................37 Support Reporting ..................................................................................................37 Feedback Gathering ...............................................................................................40 Service Improvement .............................................................................................42 SAP Solution Manager ..................................................................................43 Solution Documentation .........................................................................................44 SAP EarlyWatch Alert ...........................................................................................46
Page 3
Chapter 2. 2.1. 2.2. 2.3. 2.4. 2.5. 2.6.
Chapter 3. 3.1. 3.2. 3.3. 3.4. 3.5. 3.6. 3.7. 3.8. 3.9.
Chapter 4. 4.1. 4.2.
Chapter 5. 5.1. 5.2. 5.3.
Chapter 6. 6.1. 6.2.
6.3. 6.4. 6.5. 6.6.
Initial Assessment ..................................................................................................50 Incident Management .............................................................................................51 Maintenance Optimizer...........................................................................................54 Maintenance Certificate ..........................................................................................56 Quick Links ................................................................................................58
Appendix A
Page 4
Introduction
These guidelines are intended for Value Added Resellers (VARs) as participants of the SAP PartnerEdge channel program, who are about to set up and operate a Support Desk. The Support Desk function is one of the key support activities performed by a Value Added Reseller, who has opted for VAR-delivered support. SAP PartnerEdge Channel Partners (VARs) are entitled to sell SAP Business All-In-One and SAP BusinessObjects software including maintenance. They engage with SAP and their customers via a shared support delivery model, called VAR-delivered support. Within this shared support delivery model, Value Added Resellers take care of their customers while providing first and second level support and their related maintenance services. They are the first and single point of contact for their customers concerning the SAP-based solution. A VAR Support Desk ensures that a defined point of contact is available to customers for any problems that arise in terms of business processes and system operation. By setting up a Support Desk, a Value Added Reseller can ensure proximity to its customers and provide tailored support services. By using clearly defined support structures, as represented by a Support Desk, SAP knowhow can be established and retained more easily within the Value Added Reseller. Information to set up a VAR-specific support infrastructure can be found via the special home page http://service.sap.com/var-partner. Further links to relevant items are provided in this document. These guidelines should be used as a basis for building and operating support structures in a Value Added Reseller.
Page 5
Chapter 1.
1.1. Definition
Partner Center of Expertise
Partner Center of Expertise (PCoE) To ensure that all indirect customers receive the same high quality support, SAP introduced a dedicated Partner Center of Expertise (PCoE) certification, which will be exclusively available for SAP PartnerEdge Channel Partners providing support for SAP Business All-In-One and SAP BusinessObjects solutions. As a Channel Partner, you will leverage the PCoE certification as a key differentiator in the marketplace, which will allow you to advertise your support organization as certified by SAP providing a highly marketable asset to your company. The PCoE certification validates if defined procedures, guidelines, and templates for support certification are available to provide excellent support services to your customers. Your support team should be familiar with general support operations and should have the latest qualifications to provide high-quality support. Further, the PCoE certification evaluates that the Channel Partners support organization fulfills the minimum requirements needed to operate the service and support infrastructure, namely SAP Solution Manager, for end-to-end interaction with customers and SAP. It further verifies process compliance with SAP Support standards. Support Authorization The PCoE certification is a mandatory requirement for all VARs who choose to deliver support services to their customer base. Completion of this certification program leads to the provision of support authorization which then allows the VAR to offer support and maintenance services to their end customer.
1.2. Components
To enable the successful operation of a full service desk facility, a PCoE requires several components to work seamlessly and efficiently. These components have been identified in the SAP PartnerEdge Channel Agreement and is thus grouped into the following areas: Support Infrastructure: comprises the physical and/or tangible elements of a service desk operation Support Processes: defines the workflow and procedures to enable the different infrastructure elements to be used in a seamless and effective manner Marketing and Communications: provides the means and visibility through which the support operations can be introduced and presented competitively. Continuous Improvement: generating consistent feedback and reporting to identify areas of improvement and evaluate opportunities for optimization of resources and services.
1.3. Certification
Partners opting to deliver support for their customer base, or taking VAR-delivered support, are required by SAP to secure support authorization which is achieved through the successful completion
SAP AG 2010 / Setting up a Partner Center of Expertise (Partner Guide) Version 2.7 Page 6
of a Partner Center of Expertise certification (PCoE). This process involves several key personnel working with the Partner to commence, execute, and achieve this certification. These are the Channel Manager, Partner Services Advisor, SAP Auditor, and PCoE Judging. Channel Manager
Works with the Partner to assist and explain VAR support delivery models Receives Partner decision on support model preference; VAR-delivered support or SAP-delivered support Informs the Partner Services Advisor (PSA) on Partners support model preference
Partner Services Advisor

Received Partner support model decision from Channel Manager Explains the PCoE certification process to Partners opting for VAR-delivered support Reviews and assesses PCoE checklist Coordinates audit schedule with Partner and SAP Auditor
SAP Auditor
Conducts audit session with Partner Creates certification report based on audit findings, documentation, and interviews. Submits to PCoE judging. Participates in PCoE judging Communicates certification results with Partner and internal SAP relevant personnel
PCoE Judging Committee

Receives certification report from SAP Auditor Reviews and assesses certification report Communicates certification assessment with SAP Auditor
The certification exercise comprises five (5) steps: Registration, Assessment, Preparation, Audit, and Judging. It may be possible to repeat some steps if assessments are not favorable.
Page 7
Figure 1-1. Partner Center of Expertise Process Steps
Page 8
Chapter 2.
Support Infrastructure
A successful support operation could not be possible without the physical applications, tools, and human resources that comprise the essential components of a support infrastructure. SAP has clearly defined such infrastructure requirements in the SAP PartnerEdge Channel Agreement and Partners are enjoined to complete these essential physical components as a mandatory requirement.
Figure 2-1. Support Infrastructure Components
For partners with an existing support business, compliance with SAP requirements necessitates 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 partners mutual customers. Any deviations from SAPs standard requirements have to be clearly explained to an Auditor for clarification and recommendations, when necessary. From the maintenance instructions as provided in Exhibit 4 of the SAP PartnerEdge Channel Agreement, the following clearly defined infrastructure requirements are as follows: Dedicated Support Hotline Remote Connection Test Systems Incident Management System SAP EarlyWatch Alert Support Staff The compliance weight and level for each physical requirement are defined in the succeeding pages.
2.1. Dedicated Support Hotline

As clearly stated, a support hotline should be a dedicated number that can be reached by customer end users without need for routing, extensions, or intermediary communication.
It is preferred that the support hotline meets the following criteria: Singular set of numbers that directly connects to the support organization Should have automatic call routing with several lines directly linked to the main support hotline. Rarely returns a busy signal, but if it does, provides voice mail facility for support staff to return the call as soon as a line becomes available. Have automated voice recording for out-of-office announcements. For example, when a customer calls after 6 PM, a friendly recorded announcement is made from the support hotline providing instructions that a customer can clearly follow to secure support out of regular business hours. The call is answered by support staff who clearly identifies themselves as a member of the partners support organization. For example, when the hotline is reached, a support staff member responds with Good morning Sir! Youve reached <<company name>> support. How may we help you?
Alternative Modes of Communication Apart from a support hotline, Partners can offer alternative means for accessibility of their support organization to the customer end users. The following means could also be considered to supplement an existing support hotline: Support Website It is not uncommon for well-established support businesses to offer online accessibility of their support operations. This is usually a feature available from incident management systems. This allows interactive and efficient means of communicating incident progress and resolution with the customer base and allows visibility of issues logged with the support partner. Dedicated Support Email Address As an alternative to a direct call, Partners can also offer a dedicated email address which routes to their support organization. This, however, may not always be the most efficient process for incident reporting as there is no guarantee that the email has been received by the Partner support organization or, depending on network traffic or unforeseen technical issues may delay receipt at the partner end. This mode could be best used for incidents not requiring immediate resolution. Fax Outmoded at current times, a fax machine still provides a valuable backup alternative against electronic means of communication. Thus, having a dedicate fax number for such emergency situations is always a welcome alternative.
After-Office Hours The support hotline should be available at all times and should be properly set up and/or configured to respond appropriately for calls received outside of regular business hours. In such instances, a support hotline should never return a busy signal but should offer helpful instructions for guiding customers through after-office hours support procedures.
It is expected that a dedicated support hotline should provide any of the following instructions outside business hours: Issue automated voice instructions offering alternative means for reporting incidents Routes to a dedicated mobile number or communications service fully monitored and available for emergency calls It is not recommended to offer alternative numbers to customer end users such as the following: Issuing mobile numbers of specific consultants or other company personnel When the individual leaves the company, it is expected that the customer receives new sets of numbers and names. This does not offer a permanent and standardized solution but will most often confuse customers regarding appropriate contacts for specific situations. Providing a different phone number for after-office calls Offering different support numbers will create confusion regarding call hours and expectations. Calls after office hours are usually made by customers who are in distress and usually in a pressure-specific situation. It cannot be expected that at such situations, customers could remember out-of-ordinary processes (and numbers) which probably occurs infrequently and thus would not be usually accorded due attention.
A dedicated support hotline should be a singular set of numbers available for use 7x24. It is recommended to have phone routing capabilities or voice mail as an alternative.
2.2. Remote Connection

Current communications and networking options offer various means of accessing customer systems in a remote environment. This becomes the most cost-effective means to view, diagnose, analyze, and resolve incidents without necessitating the physical presence of an individual at the customer site. This is, by far, the most feasible alternative for assisting customers quickly and with minimum amount of delay. For SAP customers, remote connectivity with SAPs support backbone is a mandatory requirement for all productive instances. This is a necessary first step for allowing SAP to provide mission critical services when it is sorely needed. Without this infrastructure, a customer should clearly understand that SAP or the Partner is not expected to fulfill service level targets. This could also allow SAP or the Partner to downgrade priority calls as the expected resolution for incidents without immediate access would be lowered.
Page 11
Figure 2-2. Remote Connection Setup
Remote connectivity has to be setup with customer systems for the following purposes: View, analyze, and resolve incidents from SAP or Partner side from any location at any time. Execute SAP and/or Partner services for either proactive monitoring (such as SAP EarlyWatch Alert, root cause analysis, or solution assessment.)
Security Issues Customers do have valid concerns about remote connectivity and its potential risk for uncontrolled or undetected access to their critical systems. Thus, it may be necessary to educate customers on the following aspects: Customer has full control of their connection and has sole capability to open the connection manually from their end at their own time, at their own means. Remote connection need only be set up once and can be opened by a customer only at their preference. Customer can use various encryption methods (such as SNC or VPN) for data protection and security. Partners should ensure that their customers are fully aware of these security issues and how they are addressed with current methods. As SAP mandates this requirement with its customers, Partners should also request their customers to provide this means as a necessary first step for efficient support especially in critical situations. SAP offers extensive information on remote connectivity types through the SAP Service Marketplace pages under http://service.sap.com/remoteconnection. By far, the SAP software program SAProuter is the most popular means for controlling and monitoring communication between SAP servers and frontend computers, as well as enabling RFC access between different servers. SAProuter information can also be taken from http://service.sap.com/saprouter.
Page 12
As a key ingredient for certification, remote connectivity is expected to be available for the following: between SAP and customer production systems between Partner and customer production systems between SAP and Partner test systems between SAP and Partner/Customer SAP Solution Manager systems
Being a mandatory requirement, Partner should ensure that compliance for remote connectivity is generally high within its customer base and its own support infrastructure. An 85% compliance target is recommended.
2.3. Test Systems

Customers reporting incidents may not necessarily welcome the idea of their systems being used as a test environment for resolving their own issues. Thus, Partners should set up a necessary back-up environment to allow simulation of customer issues on a standard SAP system with a similar product type, release, and version. A test system, therefore, should fulfill the following factors: Available onsite at Partner office for immediate use by support staff Test systems should be available at the Partners office and is not meant to indicate the customers own test system. Test systems should offer no critical issue on instances that a test and/or simulation results in malfunctions or errors in the system. Based on standard SAP product and release Delivered objects, features, and functionalities could generally differ between products and release. Thus, it is essential (and to avoid conflicting results) to have the same product and release while performing simulation activities. Has remote connection to SAP In the event that a Partner should be able to simulate an incident in their own test systems, this could be used as an alternative system by SAP support in the event that a connection to the customer is not possible. Thus a remote connection to SAP is also necessary. Should use the partners own demo/productive installation numbers Test systems should use the partners own licensed installation numbers provided within a demo license or their own productive license. Thus, it is not expected that a partner uses the installation number of their customers to be used for their test environment.
Page 13
Test systems should be available for all products/releases used by the customer base. These should have remote connection established with SAP.
2.4. Incident Management System

Partners should use the SAP Solution Manager Service Desk as the primary incident management system as required from the SAP PartnerEdge channel agreement, Exhibit 4. The SAP Solution Manager Service Desk is able to fulfill both first level and second level processing activities as recommended from the agreement and should be able to cover the following processes: Receipt and classification Incidents should be received immediately upon posting by a customer end user. There should be minimal delay in receipt of the responding support unit so as not to brook any cause for complaint or frustration on the part of the customer end user. Incidents should have various classification areas to enable proper determination of expertise requirement and urgency status. The most popular of these from an SAP perspective is the specific SAP component and priority level. These should be made available during incident receipt to allow the support unit to identify the customers needs. It is also possible that some support operations also have further classifications such as for incident type, customer classification, or service levels. Ownership and/or assignment An incident management system should either have the capability to assign an incident automatically based on classification factors or allow manual assignment to appropriate parties.
Progress documentation An essential component of an incident management system is its capability to store information on the following activities: o Communication between support processors and customer end user o Internal documentation on findings, test simulation data and results, and call contents, and discussions o Date and Time stamps on all activities
Page 14
Attachments such as screen shots, error messages, incident details, logs, and communication copies
Documentation should not be modifiable to preserve the integrity of documented processes. Different text types or memos should be available to easily distinguish the documentation type. Examples are Internal Note for discussions exclusively within the support unit and Reply solely for responses to customer end users. Communication across involved parties There should be interactive exchange of information between the Partner support unit and customer end users. Thus, online accessibility of incident management systems play a crucial functionality for this purpose where end users can monitor progress of their reporting incidents online and be able to correspond with the support processor as close to real time as possible. Incident Management systems that can be set up to send automatic emails or phone messages to either the support team members or customer end users are ideal as they offer alternative and supportive communication channels. Tracking, monitoring, and reporting To enable the support organization to immediately identify incidents that require processing, it is strongly required to have an incident management system with flexible monitoring and reporting capabilities. It is highly required to provide for tracking of pending incidents. This should include information on the unique incident number, priority, short text, processor name and incident status. It is also beneficial to have information on last changed date, service level adherence, and escalation flags (if available).
Page 15
Monitoring should be conducted several times daily while reporting can be run periodically depending on business requirements as well as for performance monitoring. Online accessibility of an incident management system is a must and should be fully integrated with SAPs support network. Partners should ensure that their incident management systems online address is available for access through the SAP Service Marketplace. Please see SAP Note 1285423 for instructions to accomplish this integration.
Use SAP Solution Manager Service Desk for incident handling and/or integrate 3rd party systems, if applicable. Online availability should be possible and is integrated with the SAP Service Marketplace.
2.5. SAP EarlyWatch Alert SAP EarlyWatch Alert is an important part of making sure that the customers core business
processes work. It is a tool that monitors the essential administrative areas of SAP components and keeps customers updated on their performance and stability. SAP EarlyWatch Alert runs automatically to keep the customer informed, so they can react to issues proactively before they become critical. SAP EarlyWatch Alert is most effective when activated for all SAP components in the customers solution. It is covered by the maintenance agreement with SAP with no extra charge and it is a technical prerequisite to perform other remote delivery services. SAP EarlyWatch Alert is processed in an SAP Solution Manager system where it can be similarly activated and where regular reports can be stored. If there is no local SAP Solution Manager system, customers can send the data to the Partners SAP Solution Manager system or to SAP for processing. See Figure 2-3. SAP Note 207223 covers information on the setup and restrictions for SAP EarlyWatch Alert. Similarly, information is available from the SAP Service Marketplace at http://service.sap.com/ewa.
Page 16
Figure 2-3 SAP EarlyWatch Alert Data Transfer Setup
All productive systems should have SAP EarlyWatch Alert data transfers sent to SAP on a weekly basis.
2.6. Support Staff

A successful support operation relies heavily on the competencies and expertise of the people responsible for incident resolution. At an early stage, a VAR has to identify critical areas that need to be supported, determine the support structure and roles, formulate basic workflow processes, and identify the infrastructure components required to support operations. Support Roles Within a support organization, there are some roles that are key for seamless operations. Depending on the size of the organization, the roles could either be shared with other roles or could be owned and performed by a single individual. For instance, for a small support operation, the Help Desk staff could perform both the Help Desk role, Dispatcher, and Coordinator roles. There are times also that the Support Manager also performs the Coordinator role. The following are examples of roles that could be identified from any support organization: Help Desk, Dispatcher, Coordinator, and Processor.
Help Desk
Support hotline frontline personnel Receives calls from customers and either (a) creates a new call into the incident management system, (b) for existing incidents, document customer call for processor, (c) for existing incidents with processor, can forward calls to respective processor upon request May not necessarily have product knowledge but understands key components of incident posting.
Dispatcher
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. Takes ownership of an incident to completion.
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 deescalation procedures and activities Evaluation and appraisal of support staff Key decision maker for process improvements
Page 18
Depending on the size of the support staff and/or the customer base, some of the key support roles can be performed by one individual. For some support organizations, the Processor role can be divided into several levels depending on product expertise. Within the SAP PartnerEdge Channel Agreement, support levels are sub-divided into two: First Level and Second Level. Following are the duties attributed to each support level:
First Level Tasks Duties Accepts the incident Performs translation (if necessary) for incidents sent to SAP Complete the problem description o meaningful incident header o technical information on incident context such as log files o technical information on the incident system (system id, system type, system name, installation number, product version and patch levels, database version, OS, GUI version, localization or language settings) o comprehensive problem description; including steps leading to the incident and full syntax of the error message o surrounding factors ( ex. recent upgrades/transports) o incorporate attachments when necessary Checking incident priority Assigning the proper component Ensuring availability of remote connection Searching for previous customer incidents with identical symptoms from various knowledge bases Splitting up incidents that describe more than one incident Summarizing status of incident before forwarding to the next level First Level Employee Profile Excellent ability to communicate directly with the customer Good knowledge of local, country-specific circumstances that may need to be communicated to other support organizations Ability to adapt to different situations (for example, escalations). This enables a relationship to be built with the customer so that his specific requirements can be understood and communicated to the upstream support organizations. Basic understanding of the products supported by the Support Desk so that qualified questions can be asked when entering and completing the message. This includes - Basic desktop know-how General SAP know-how
IT experience and, depending on the Level, detailed knowledge of the supported product or product area. If necessary, project experience
Page 19
Familiarity with the terminology used in the company Readiness to participate in ongoing training measures to further consolidate and update existing know-how Fluency in a foreign language (especially English) Knowledge of the internal communication means (for example, mail program)
Second Level Tasks Duties Subsequent to First Level and includes the following tasks: Searches for errors using the data from end user Checks customizing settings Looking for fault through o system dumps o core 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 Test the Solution o check and test solution in a test system
Second Level Employee Profile Finding the solution using their own expertise, solution database, or product documentation Completing the message by requesting the missing information from the previous Level or directly from the reporter Performing a detailed problem analysis (Customizing, dump, trace, debugging) Provide direct support to the reporter in complex cases (for example, for importing patches, and so on) Training new employees by means of internal courses Collaborating with the SAP Support Organization Detailed SAP know-how Technical know-how
Third Level Tasks (usually SAP Support) Duties Detailed analysis of recorded traces and error messages Creating or modifying SAP Notes regarding
o o
Identified cause of defect Incident resolution process including all material/information (e.g. bug fixes, patches, work-around description) to update SAPs support system Specify expected duration to fix defects by patches, bug fixes, or support packages Recommend workarounds and alternative solutions Access customer end user systems through the SAP Support network o to analyze end users system regarding the incident o assist end user in order to perform the required and applicable incident remedy by using workarounds or fixes o change coding, provide fixes, and create patches
A VAR should also clearly determine which product areas will be supported depending on the products/components installed at their customer base. It is also expected that the Basis component should be amongst those supported even during a start-up phase as production down situations are generally technical incidents.
Development and Training Support staff should not lack in training opportunities and should continue to acquire skills and competencies not only through delta training but also onsite experience and knowledge-sharing from other colleagues. The VAR has to ensure that the support staff has similar expertise as its SAP Global Support Center counterparts in SAP. Thus, it is important that support staff is well-versed with their particular industry or component areas and has had experience with actual implementation of their product. It is recommended to supplement existing expertise with SAP classroom training and to evaluate their knowledge through SAP product certification. It is also a requirement for PCoE certification to ensure that at least two (2) support staff has achieved people certification and that support staff with the relevant role equivalents should take the various e-learning materials as provided in the SAP Channel Partner Portal. The following should be considered: System Administrator o Plan and perform the implementation of SAP Solution Manager across all related IT-components by setting clear objectives for the system infrastructure, implementation process and integration o Optimize technical team infrastructure
Message Processor o Provide first and second level support through processing customer messages on different components o Root cause analysis: analyze root cause of an issue via remote connection and resolve known errors by means of SAP notes, solved customer messages, documentation or verifying customizing entries or hardware parameters
o Evaluate problem category and forward to next instance o If message processor does not find a solution, report errors and forward them to SAP Support Certification required for the following product areas: SAP Business All-In-One C_PXSUP_90 SAP BusinessObjects C_BOSUP_90
Support Coordinator o Plan and coordinate the support center o Interact with SAP Channel Development Manager regarding specific support topics o Define new services within your SAP Enterprise Support offering To view these training curriculums, visit the SAP Channel Partner Portal page with the links provided for each specific product area. SAP Business All-In-One Go to http://channel.sap.com Education SAP Business All-In-One Choose Role Training Support Consultant SAP BusinessObjects Go to http://channel.sap.com Education SAP BusinessObjects Choose Role Training Support Consultant Outsourcing It is also not uncommon for some VARs to outsource some components to other parties outside of their general area of expertise. For instance, some VARs would outsource either the Basis component or specialized components such as HR, CRM, or some industry solutions. For such situations, it is also important to consider this third-party support during the certification audit. Thus, it is to be expected that the SAP Auditor may request documentation and participation from the third-party unit to verify support arrangements and integration of support operations between both parties.
Support staff should be available full time and should be able to show competencies and skills through experience and continuing education. Support staff should have SAP Education certification or at least two (2) years experience. Following the support consultant training roadmap, each support organization should have at least one (1) support staff achieving SAP Support Consultant certification per solution area.
Page 22
Chapter 3.
Support Processes
Support processes could be extremely simple or complex usually depending on several factors such as: size of the support organization incident management system capabilities organization targets and goals However, a support process would generally have a basic workflow. Differences occur in the execution but should generally follow the same seamless process. Every support organization should clearly document their support processes as a general guideline for new hires, for mentoring purposes, and as reference both for improvement and extraordinary circumstances. It is a good practice to review existing processes from experience by internal staff and explicit feedback from the customer base. This helps support organizations focus on areas which need further development, improvement, or modifications. A support process from the VAR support unit has the following basic workflow actions: Incident Receipt Incident Acknowledgement Incident Dispatch Incident Processing Incident Forwarding Incident Closure Feedback The Feedback process would be explained further in Chapter 5, Continuous Improvement.
3.1. Preparing an Incident

Even for the most mature organizations, incidents are not an unlikely event. Thus, it is expected that customers are dutifully prepared to respond to such situations by appropriately compiling information necessary to report the occurrence and justify expected outcomes.
Self-Service Before an incident can be created for the VAR support organization, it is highly recommended that the customer end user tries to resolve the incident within their means. This could be through the use of an available solution database, help documentation, or training materials. An end user could also refer the incident to their own key users, business process owners, or competence teams. These individuals or units could perform initial review of the incident and could offer potential solutions. Reporting incidents to a central competence group within the customer organization is also a good practice as this helps to prevent end users from posting the same incidents to the VAR especially in
Page 23
cases when the incident occurs with multiple users within the same period. This also helps to ensure that expected outcomes for an incident are correct. Once the customer has decided that it could not resolve the incident, then it can refer to the VAR support organization for handling.
Preparing an Incident It is important for the support organization to have provided clear directions which methods are available for logging of incidents. Equally important are the details required by a support organization to immediately process an incident. Following should be mandatory information for an incident to be processed. Following are some of these relevant details (see also SAP Note 16018 ): 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 appropriate relay the urgency of the incident. The VAR should also be clear about their priority definitions and properly educate customers which priority levels to use. Reporter Details The customer should supply contact information of the person who can best discuss and respond to the VAR support processors. For incidents reported with top priority, contact information and personnel from the customer side should be available at all times. Product Area / Component For incidents to be dispatched or routed to the right support team or processor, the reporter should properly identify the specific product/component where the incident occurs. This would help to lessen potential delays with incident handling amongst the support unit. Short Description Most incident management systems provide a facility for describing the context of an incident in a brief one-liner statement. This statement should be as descriptive as possible to indicate transaction codes, error codes, report/program names or other reference terms where readers could immediately discern or perceive the content of an incident. Incident Details Understandably that most reporters want to send an incident off as soon as possible, the speed by which an incident was created and sent to the support organization would be fruitless if the support organization only sends it back with request for additional information that shouldve been included in the first place. Reports of an incident should meticulously prepare their incident providing the relevant details to avoid further ping-pong situations
Page 24
between the customer and the support team for incidents that have unclear or incomplete information. Following information should be included in the incident description: o Steps performed prior to the incident. This should include field values in case such values are significant. o Expected result of the transaction and actual result. This helps the processor to understand what the customer is attempting to perform and to immediately discern if the customer has executed the appropriate steps to arrive at their expected outcome. o Error details including logs, dumps and screen shots o Situation with the system prior to the incident (Has there been a modification? Was there a recent upgrade? Are there any identified changes/improvements on the system? Was this the first time to execute the transaction?) o Can the incident be reproduced? o Is the incident happening with just one user or multiple users? Impact For issues that have serious business or financial impact, it is important for customers to inform the support unit of the consequence(s) to the business so the incident can be appropriate processed with urgency and attention.
3.2. Reporting an Incident

Depending on the setup arranged with the VAR, an incident could be reported by any of the following individuals: End User: any end user from the customer could report an incident directly to the VAR support organization. Key User: individuals within the customer organization who have in depth knowledge of the transaction for which an incident is to be reported on. Business Process Owner: an individual who has detailed knowledge of the business process for which the incident is related to. This individual could also have been involved in the implementation process and is aware of the activities, decisions, and execution of the companys business process. Competence Team: a group of individuals set up by the customer organization to function as a support unit for its end users. The team is comprised with individuals experienced in the implementation and execution of the companys business processes. Either an individual or unit is responsible for posting an incident, the VAR Support organization should generally be communicating with an individual which will be herein designated as a Reporter. A customer would be provided methods and tools by which an incident can be reported to the VAR support organization. The most popular communication media are either online, phone or email. Depending on methods used, a customer should be dutifully prepared to provide all relevant details to the VAR support organization.
Page 25
3.3. Receiving an Incident

There are different methods by which a support organization could receive an incident from its customer base. This depends greatly on the provided communications infrastructure as well as the features available from the incident management system. Information gathered from this process is significant as it would direct the efficiency by which an incident can be processed by the support organization. Execution plans vary depending on the method by which an incident is logged as discussed in the following topics. Incident received online Preferred method Near real time receipt by the VAR support organization depending on network traffic Provision of forms for detailing relevant incident information Depending on incident management system features, can immediately dispatch an incident based on priority and/or component area to a specific support unit or processor Incident received via phone Received real time Requires manual work from the VAR to collect information from the Reporter and post this subsequently to the incident management system Details can be requested from the Reporter by following a pre-defined form from the incident management system Depending on incident management system features, can immediately dispatch an incident based on priority and/or component area to a specific support unit or processor Possible confusion or misunderstanding of Reporters statements which could lead to improper dispatch or delays in processing Incident received via email Received near real time depending on network traffic No guarantee that email is received by VAR support organization pending their acknowledgement. Requires manual work from the VAR to post the emailed incident into the incident management system Depending on incident management system features, can immediately dispatch an incident based on priority and/or component area to a specific support unit or processor Less possibility for confusion if incident reported can be summarily copied into the incident management system Incident received via fax Received near real time depending on network traffic. No guarantee that fax is received by VAR support organization pending their acknowledgement. Fax may not be regularly monitored by the VAR support team.
Requires manual work from the VAR to post the faxed incident into the incident management system Less possibility for confusion as reported incident can be entered verbatim into the incident management system
When a VAR has received the incident and has this subsequently posted in their incident management system, this can then be reviewed by a support staff. The support staff could check the following from an incident: Complete and comprehensive incident details (includes error information, logs, screen shots, steps leading to the incident, expected and actual result) Verify priority setting. If this is set incorrectly, the customer should be informed of any changes Confirm component or product area. Utilize various means to match the incident with its proper product/component. For example, if the transaction code is mentioned, an SAP note search can be performed to verify if most notes received use the same component. Ensure that only one incident has been reported. Otherwise, create additional tickets for other incidents posted.
A support staff can also have a checklist of areas to be reviewed before an incident can be qualified for processing. Once this has been completed, an incident can then be assigned to the appropriate support consultant.
3.4. Acknowledging an Incident

Once an incident has been received by the support organization, it is important to immediately provide a reply to the Reporter to state that the incident has been received. Whether an incident has been logged online, via phone, fax, or email, a unique identifier should be available. This identifier usually comes in the form of a number series. This incident number should be communicated to the Reporter to help identify their specific incident amongst others. It is also during the incident acknowledgement process that the initial reaction time is set.
3.5. 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
Page 27
Most incident management systems allow for the input of assigned processors. This could also trigger an automated response through email upon assignment. Thus, the processor is informed when an incident has been assigned to him. There are cases, however, that the Dispatcher role no longer exists. This could apply to large support organizations where support consultants are primarily responsible for ensuring that their queues (assigned areas of responsibility) are properly monitored. Thus, support consultants are responsible for assigning incidents in their name, ensuring that incidents are prioritized based on defined criteria, and that incidents that have been returned for their review and continued processing has been returned to their specific queues.
3.6. Processing an Incident

Once an incident has been assigned for processing, the Processor subsequently reviews the contents of the incident. At this time, it could also be possible that the support employee may perform the following activities: Determine whether the component / product have been properly assigned. Otherwise, the processor can change the component and subsequently send it back to the Dispatcher for reassignment. Verify priority setting and adjust as necessary with proper communication to the Reporter. Determine whether the inquiry is related to an error or requires consulting work. For the latter case, then it may be necessary to discuss options with the customer.
During processing, a support employee may need to use several sources for responding or verifying their responses to the Reporter. These could be any of the following sources: Training Materials Help Documentation SAP Service Marketplace SAP Notes Database Own Solution Database Peer Networks Product Forums In some circumstances, it may also be necessary for a support employee to simulate the incident through a test system with the standard SAP product installed. Simulation is needed in the following cases: Verify if the steps performed by the end user is correct and conforms to proper procedures If errors are not received in the standard test system, it can be assumed that the incident is local to the customers solution landscape Confirm that proposed solutions achieve the desired effect on a test system before recommending to the customer.
Page 28
Support employees should properly document their findings, simulation efforts, and communication in the incident. This could either be visible or not visible to customers. Information provided therein could be used by succeeding support employees to whom the incident could be forwarded to later on. This information would also be vital to SAP Support in cases when the incident would be forwarded to SAP Support as this would help to lessen the effort in root cause determination and would help SAP Support to focus on other untested areas.
3.7. Forwarding an Incident

After an incident has been reviewed and processed by a Processor, there may be instances that the expertise level of the current processor may not be sufficient and, thus, the incident may need to be referred to someone of additional expertise or experience. The incident can then be forwarded to the next support level in some cases. For some situations, this could be forwarded to SAP. Incidents forwarded to another level should provide for a comprehensive summary on activities performed so that the next Processor will not have to redo the same tasks which would delay the incident resolution process. Before an incident is forwarded to SAP Incident should be written (or translated) into English, if needed Verify that the incident refers to SAP products and/or third party applications supported at SAP otherwise refer the incident to the proper vendor. Remote connection has to be checked and should be available upon request. Contact information completely provided Complete summary of the incident and inclusion of attachments, if necessary, has been provided including detailed information on tasks performed, SAP notes used, and customer situation at current. Appropriate approvals (within the VAR support process) has been received to allow forwarding of the incident to SAP When an incident is forwarded to another Level, it is most prudent to inform the customer that the incident has changed hands. Thus, a reply to the customer should be made to provide information that the incident has been forwarded to the next level of support or to another component as the case may be. For incidents forwarded to SAP, the VAR should decide whether they will act as interface to the customer or if the customer themselves would be responding directly to SAP. It is recommended that the former is used and to use the latter for incidents that are forwarded to SAP after the VARs business hours.
3.8. Closing an Incident

An incident can be closed if the customer confirms that the solution proposed by the VAR has resolved their incident. The VAR can consider the following strategies for closure:
Allow the customer to close the incident on their own. This could lead to situations when an incident could be left unclosed for a long time unless the customer is constantly reminded to do so. Conduct follow-up sessions regularly to remind customers of incidents that could be closed. This approach would require a resource and corresponding effort to follow-up with customers. This may not be an acceptable task for VARs with a huge customer base. Allow for automatic closure after a reasonable period depending on priority level. This should be clearly known by the customer to avoid complaints. This helps eliminate any further manual follow-ups from the support unit.
It is important to ensure that customers have provided either a reply to confirm that their incident has been resolved or that they explicitly close the incident. For incidents that have also been referred to SAP for resolution, the VAR should not forget to explicitly confirm the incident with SAP. Nevertheless, SAP follows automatic closure processes and the incident will be closed if there has been no action after a specific amount of time.
3.9. Handling Complaints and Escalations

Complaints During the processing of an incident, a customer can contact the support unit if they are, in any way, displeased with either the progress of resolving an incident or the solution quality. In such cases, the customer could contact the support organization to address such complaints and these have to be properly noted and monitored to avoid the complaint from further escalating. Complaints have to be reviewed and ownership has to be set where an individual takes responsibility for addressing the complaint and ensuring that a satisfactory response is provided. The complaint owner has to dutifully monitor that the incident progresses and is resolved to the customers satisfaction and to constantly provide feedback and communication as well. After a complaint has been resolved, it is a good practice to review the case and to derive possible lessons that could be gleaned from it as a means to improve the overall support performance and quality.
Escalation Escalations though sometimes used as a term for forwarding of incidents should be interpreted differently in the context of incident processing. There are situations when an incident may require exceptional processing and may deviate from the normal support processing procedures. These situations have to be properly identified and should have a defined action plan. Though this can occur in the middle of incident processing, these can also be identified at the onset of incident receipt. Thus, escalations could be identified through specific triggers such as:
Page 30
Severe financial or business impact. This pertains to a significant loss of business or revenue until an incident is resolved. This would normally merit attention from high-level management and require immediate resolution and constant monitoring. Production Down. Though it is not uncommon to have situations when an application goes down, the situation becomes more critical if it has been clearly identified that the application may not be brought up within a short period. For example, customer experiences a hardware crash and realizes they have no available backup from the past months. System could not be restored immediately and without prolonged effort which could lead to potential business loss. Service Level Exceeded. There could be financial aspects to missing service levels which could necessitate extra attention and faster processing. Go Live Endangered. Go live is a highly critical phase not only involving the customer, their business, but other parties as well such as the implementation team. This has the potential to affect both financial and business aspects, such as added consulting man days, readjustment of resources, activities, and timelines. Thus, incidents contributing to a possible delay in go live needs to be addressed expediently.
Similar to complaints, escalations should have clear ownership for resolution, identified action plans, and constant monitoring and communication until its resolution. In cases when SAP becomes involved in an escalation situation, it is important to ensure that SAP has a clearly identified contact from the VAR side as well as the customer to properly coordinate activities, plans, and resources. For such situations, it is also a necessary requirement to have remote connectivity available to ensure that assistance can be provided by the SAP Support network globally and around the clock.
Support processes should exist, is used with day-to-day operations, and should be documented clearly and in line with the incident management system.
Page 31
Chapter 4.
Marketing & Communications
Though support primarily keeps a low profile in most cases, a support business is nonetheless a significant factor for continuing business. VARs have to capitalize on its successful relationships and achievements, its staff competencies, and its support capabilities should not take a back seat. For small customers who may hardly have the manpower and infrastructure to build their own application competencies, a lot rides on its VAR to provide assistance and advise not only on continuing improvements of its business and productive operations but also on day-to-day incidents that also contribute to the overall product experience. Having an application that runs seamlessly is a boon and having immediate support with excellent service and quality is not far behind. At the onset of the sales cycle, support should be introduced as part of the offering. VARs may have varied support offerings but this should be complementary to SAPs support offerings as well. In this, the VAR should be able to properly communicate and sell their maintenance services clearly outlining their relationship with SAP as and co-delivery partner of SAP support services.
4.1. Presentation of Support

VARs should have a compelling presentation of their support services and this could be further supplemented by collaterals. A support presentation should generally have the following elements: Description of competencies and capabilities Start the presentation with an introduction of the support organization, its structure, goals, targets, and key achievements. Capitalize on resource competencies such as certifications and experience. It is also relevant to showcase the growth of a support organization if it conveys the results of continuous improvements, maturity, and experience of the organization as a whole. This helps to advertise to customers/prospects that the organization shows and promotes growth that could benefit them as well. Showcase support infrastructure and resources The customer could be presented with existing applications, systems, hardware to indicate the VARs commitment to invest in the support business. This could also be used to elaborate on key operations and how the infrastructure integrates with the VARs processes. Infrastructure components that would be of relevance for SAP integration are the following: SAP Solution Manager - Network infrastructure for remote connectivity - Test systems - Communications systems - Incident Management Systems - Back-up facilities
Discuss support operations, procedures, and activities A support presentation should provide its audience with an idea of the required tasks and activities that would also be expected from the customer end user in relation to their interaction with the support organization. This should already introduce the different means and methods by which the support unit can be accessed and the different roles that come into play during an actual incident handling operation. A brief workflow of the support processes providing an overall view of the support activities should be available. Different processes and variations in incident handling could be discussed such as escalation processing, complaint handling, and after-office hour procedures.
Presentation of support offering(s) VARs could offer either one standard offering while some could offer variations. As customers come in different sizes, different needs, and orientation, it is also possible that VARs could offer different levels of support services, while some could offer additional services separately. At a minimum, VARs should review their duties for SAP and the End Customer as provided in Exhibit 4 of the SAP PartnerEdge Channel Agreement. Thus, all services delivered through SAPs support offering should be clearly packaged into a VARs standard offering and these should be clearly aligned with SAP. For instance, since SAP offers 7x24 support for SAP Enterprise Support customers, a VAR should not charge extra for providing support after office hours and should delegate this task to SAP. This is provided that the VAR has set up the appropriate and recommended infrastructure for connecting their customer to the SAP Support network. It is also vital that VARs do not forget the different SAP Technical Quality Checks (TQCs) that a customer can utilize in certain situations from SAP. These have to be clearly provided as a service and benefit and should be showcased in a VARs support offering.
Customer successes and references A support introduction presentation would be a VARs initial gateway to advertise their capabilities and market themselves as the right choice for lasting relationships. It is important to earn achievements and highlight actual successes in a presentation material. Actual references are added advertisements and having good quotes and feedback from existing customers offers factual and realistic samples that boosts the VARs credibility with an audience.
SAP Enterprise Support Competing in todays global marketplace increasingly requires organizations to operate IT landscapes that are shaped by global business networks and innovative business processes. Because of this,
organizations need the proactive expert support that can help them manage the complexity of integrating solutions across and IT ecosystem and optimizing each applications life cycle. The SAP Services organization, with the support of the Partner, can provide the expert support that can help customers optimize their SAP and non-SAP solutions, minimize risks, accelerate innovation, and manage the lifecycle of applications. At a minimum, VARs should look into SAP Enterprise Support offering and build their services, competencies, and capabilities within this framework. For more information on SAP Enterprise Support, please visit your SAP Channel Partner Portal at http://channel.sap.com SAP Business Management Solutions SAP Business All-In-One Support SAP Enterprise Support. Likewise, information can also be found from the SAP Service Marketplace at http://service.sap.com/enterprisesupport.
Structuring Your Potential Support Offer Although this training module is designed to help you sell support as part of your offer, it is possible that your organization has not spent much time in structuring and formalizing what your offer is in this area. So lets explore what support could mean to you as a channel partner.
Figure 4.1 Structure of Support Offering
Support is much more than just maintenance or reactive incident management. The support offering from an SAP Business All-In-One channel partner should be structured in three parts: basic services that are required by the majority of your target customers, that also means you dont have to negotiate what needs to be done to keep a customers solution running. For example, software maintenance which provides for guaranteed response times 24 hours
Page 34
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. 10 years ago many insurance companies went down this route of offering a high degree of choice in extras, but when customers always found the policy didnt cover the specific incident they had encountered, they became dissatisfied and went in search of companies offering a comprehensive base level, with a few, very specific, premium offers. The same is true with support. 90% of what 90% of your customers want needs to be in the Base Level, with only highly specific increments falling into the Premium category either because of their unusual nature or very high cost to provide. The final category of support service you need to be able to offer is ad hoc. This usually is charged to the customer as required but may involve a retainer, or a facility where the customer can, for example, use 5 hours a month for free, but pay thereafter. Ad hoc support may be used for such things as managing the back up process when the IT manager is on holiday, or optimizing the database remotely. Typically not part of a standard support pack, but something the customer may want, and is best delivered using the support team.
A support-specific presentation material should exist and is actively used for both prospects and customers. It should have comprehensive information on support offerings, support processes, infrastructure, as well as contact methods.
4.2. SAP Communication

VARs should always be kept abreast of any new strategies, offerings, and events within the SAP community. Thus, a VAR should have regular and ongoing communication with their different interfaces to SAP. These regular contact points are the SAP Channel Manager and the SAP Partner Services Advisor.
SAP Channel Manager
Objective: The Channel Manager is tasked to develop and enable the business of their assigned Partners and help them extend to their fullest potential, applying mid-long term view. The Channel Manager will support and drive development of new business areas for partners.
Tasks
Helps VARs to analyze and leverage business potential using available processes and best practices; ensures partners become self-sufficient in this. Creates, monitors, and reviews business and marketing plans together with the assigned partners using standard tools and templates. Responsible for partner pipeline management, coverage and reporting. Monitors overall partner performance including partner satisfaction and develops action plans to correct as necessary. Communicates SAP support strategy to Partners to ensure Partners understand the services value proposition as well as requirements and obligations. Coordinates with Partner Services Delivery organization where appropriate. Keeps SAP internal teams informed about partners service/support requirements, recommendations, and other general service/support related feedback.
SAP Partner Services Advisor Objective: Acts as a trusted advisor to his/her personally assigned partners, driving the desired objectives while also acting as feedback channel into SAP to improve our go-to-market strategy to the ecosystem.
Tasks
Get to know their designated partners, understand their business priorities and orchestrate services to increase Partners productivity Proactively monitor the Partners business performance and support their business goals. For selected countries, act as a single point of contact into SAP for channel operational tasks, such as business planning, lead management, and sales support. Contribute to overall partner experience and thus improve partner satisfaction. Orchestrate services and business enablement between SAP and Partners along their lifecycle.
VARs should have regular communication with their Channel Manager and Partner Services Advisor.
Page 36
Chapter 5.
Continuous Improvement
Change is constant and this is still be true for a support organization. As the industry grows, matures, and with increasing technology changes, support should not stand idly but should be open to review existing processes and infrastructure against ongoing trends. Customer feedback is also a strong factor for promoting changes and improvements. Whether a support organization improves for its internal benefit or due to customer suggestions, a VAR should promote a culture of feedback acceptance not only from its customers but also from internal staff. Thus, it is essential that there are continuous monitoring tasks to determine ongoing performance. These same monitoring activities should be subject for review to assess alert conditions that could require more proactive measures or to examine current trends that may trigger added services and support. This chapter examines different ways and methods by which a VAR could execute simple monitoring tasks and utilize results for service improvements.
5.1. Support Reporting

Regardless of the size of the support organization or the amount of incidents received from an existing customer base, reporting on support performance and trends should be acknowledged as an integral part of support processing. This requires frequency, ownership, and an incident management application that can produce relevant reports demanded by the business. Reports have to be distributed to appropriate individuals who may need statistics and trends analysis information to recommend or adjust services and resources where it is needed. This section tries to cover the more common and relevant support reporting for VARs such as service level reporting, customer incident reporting , team/processor reporting. Service Level Reporting A good service level report contains the following elements: Incident number Uniquely identifies an incident when additional review may be needed. Creation Date/Time Actual date/time when the incident has been posted by the end customer. This is usually be used to start calculation for initial response time. First Response Date/Time
Actual date/time when incident has been acknowledged and replied to by the support organization. This would be used for calculating initial response time usually computed as time elapsed between first response date/time and creation date/time. Last Change Date/Time This indicates the period by which the incident has been last replied by either the support unit or the end customer. Status This indicates the current progress of the incident. Completed Date/Time Indicates the date/time when an incident has been classified as closed by the support unit. This may or may not necessarily indicate that the customer has confirmed that the incident could be closed. Processing Time Indicates the amount of time spent by the support team in processing the incident. For some incident management systems, this could indicate total processing time by the support unit or could be processing time per group/level within the support unit. It should be clear that the processing time should not include the amount of time spent while an incident is pending at the customer end. Though it is also good to have a facility to compute processing time at the customer side, in cases when a customer complains about the speed by which an incident is processed. Service Level Indicators For easy reference, especially by Management, it is recommended to have a column or any indicator in the service level reporting that clearly shows whether defined service level targets have been met. Thus, if a VAR provides service levels for initial response time and processing time, there should be two separate indicators whether these elements have been met for each specific incident.
Customer Incident Reporting An incident management system should have a facility by which a customer end user, on their own, should be able to display, list, or report on their own incidents. This could also be produced by the support organization as a value-added service or as an ongoing measure for keeping customers informed of pending incidents while it can also be used as a conversation piece to elicit feedback from a customer. A good customer incident report would contain the following elements: Incident number Uniquely identifies an incident when additional review may be needed. Creation Date/Time Actual date/time when the incident has been posted by the end customer. This would usually be used to start calculation for initial response time. Last Change Date/Time This would indicate the period by which the incident has been last replied to by either the support unit or the end customer.
Status This indicates the current progress of the incident. Completed Date/Time Indicates the date/time when an incident has been classified as closed by the support unit. This may or may not necessarily indicate that the customer has confirmed that the incident could be closed.
For VARs with committed service levels, additional data could be provided as with service level reporting.
Team/Processor Reporting Support staff should also monitor their own performance and this should be performed regularly especially if this involves their individual KPIs. Depending on performance targets for the support staff, there are some key elements that should be available in either a team or processor-specific reporting. Team/Processor reporting is normally being used by support management for regular evaluation or assessment of support staff. For individual reporting, the following elements should be considered and should be filtered either specific to team or individual support processor: Incident number Uniquely identifies an incident when additional review may be needed. Creation Date/Time Indicates the actual date/time when the incident has been posted by the end customer. Would generally have relevance to the report especially when needed to assess processing time. Last Change Date/Time This would indicate the period by which the incident has been last replied to by either the support unit or the end customer. Status This indicates the current progress of the incident. Completed Date/Time Indicates the date/time when an incident has been classified as closed by the support unit. This may or may not necessarily indicate that the customer has confirmed that the incident could be closed. This information is relevant in conjunction with the status of the incident as the expectation should be that the incident is confirmed by the end customer. If this has not yet been performed by the customer, then it would be good practice for the processor to check with the customer if the incident can be closed or if they are satisfied with the solution. Processing Time Indicates the amount of time spent by the support team in processing the incident. For some incident management systems, this could indicate total processing time by the support unit or could be processing time per group/level within the support unit. This is relevant since it indicates the effort utilized for resolving an incident. For team or individual statistics, it
would also be good to note if the Processor/Team has processed the incident efficiently or if the Processor/Team requires additional training or expertise to resolve incidents faster. For VARs 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.
Management Reporting It is also a good practice to have consolidated and statistical information for support management or company management on a regular basis. Do note that support should also be considered as an avenue for additional business and services, thus, reporting can also be reviewed or assessed for indicators that would trigger these. For management, it could be important to present the following information in summary: Number of incidents received Resolution rate Number of escalations, its progress, and lessons learned Service Level Adherence Status reporting Statistical inputs and/or trends analysis would also be welcomed for the following reporting information: Customer(s) with most number of incidents Component(s) with most number of incidents
Reporting on support process compliance as well as support performance should be generated on a regular basis and should be available for support staff, customers, and management. Support reports should be aligned with support-specific targets and contractual commitments.
5.2. Feedback Gathering

While it is important to get information from customers on support performance, internal staff could also provide valuable feedback in their execution of support processes. Thus, there has to be regular communication with the support organization, its internal staff, and the customer base to determine areas where services can be improved, what can be removed, or what needs to be changed.
Page 40
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. Internal meetings could also be used to discuss improvement areas and obtaining direct feedback from colleagues on acceptability or receiving comments on potential issues that could best be identified from different perspectives with a larger group. It would also be easier to gravitate towards improvements or changes if these have been discussed with staff who will be immediately affected by these.
Have regular meetings with support staff to discuss experiences, issues, action items, and ongoing 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
Regular survey sessions should be conducted with customers at least on an annual basis. Feedback should be requested for relevant factors such as efficiency, solution quality, staff competence and behaviour.
5.3. Service Improvement

Based on feedback from internal and external sources, the VAR should also review current trends and technologies as possible indicators for upgrades, improvements, or process changes. VARs would generally offer a standard support package but could potentially offer additional services or premium offerings depending on need or request. As customers mature and expand their solutions, it would also be necessary for a VAR to realize these changes and expand their own offerings to accommodate changing demands and needs. Competition would also drive improvements where VARs can also look for offerings that would differentiate or relegate their maintenance services in a different level from other VARs. Thus, constant development of support staff is a necessary investment and keeping abreast on strategies related to their products and support services should be encouraged. Thus, a VARs support offering should evolve and grow not only with its customer base but with emerging technologies. Though it is a good practice to always be a few steps ahead of others, VARs have to clearly determine areas of need and ensure alignment with existing resources and infrastructure.
There should be available avenues for process improvement that is regularly reviewed and discussed with relevant parties. This should generally be spearheaded by Support Management.
Page 42
Chapter 6.
SAP Solution Manager
To delivery first-rate support to their customers, VARs require on the one hand access to knowledge hubs in SAPs service infrastructure and on the other hand, transparency on their customers solutions as well as secure remote access to customer systems. SAP Solution Manager is the adequate tool for VARs to deliver high-quality support to their customers and to fulfill their daily tasks efficiently.
Figure 6-1. SAP Solution Manager in a service provider environment Service providers are the central contact partners of their customers for questions regarding the SAP solution. They need a tool which makes the technical complexity of their customers solutions transparent, and supports the entire SAP solution lifecycle. Integrating the SAP partners into the SAP Global Support Backbone allows SAP and SAP partners to support their customers together, realize valuable synergies, and add value for SAP, SAP partners, and customers. The VAR will set up the SAP Solution Manager with service provider functionality. 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 customers of a service provider do not have their own SAP Solution Manager, and that the service provider runs an SAP Solution Manager system for all his customers. The SAP Solution Manager currently supports service providers to perform the following processes and related tasks: Solution Documentation SAP EarlyWatch Alert (EWA) Initial Assessment Incident Management - Process support messages from service provider users and service provider customer users
- Remote access to customer systems via SAP infrastructure - Open customer systems for remote access Maintenance Optimizer Maintenance Certification Management for customer systems
6.1. Solution Documentation

The SAP Solution Manager provides a medium by which the technical solution landscape and business processes can be documented. For this purpose, there are three types of documentation: technical landscape documentation, business process documentation, and custom code documentation. You can find detailed information on how you can document your customer solution including a helpful step-by-step guideline at http://service.sap.com/var-partner Application Life-Cycle Management for VARs Solution Documentation. Technical Landscape Documentation The technical landscape documentation is generally performed within the initial configuration of the SAP Solution Manager system. As a prerequisite, all systems (so called managed systems) involved in the solution should be connected to the SAP Solution Manager. This allows the capture of relevant technical data such as installation numbers, systems ids, hardware information, and client numbers to be made. The necessary remote links (RFCs) can also be generated automatically as part of the initial setup phase.
Figure 6-2. Logical Component Definition
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.
Business Process Documentation Following the technical solution landscape documentation, the business processes can then be documented. These could be defined from existing implementation content from the SAP Solution Manager business process repository (BPR) or processes defined by the customer or a combination of both. Business process documentation can include project information, business blueprint, configuration, training material, and test documents. Project information can then be handed over to solutions upon go live and this can then be used for ongoing maintenance and improvement.
Figure 6-3. Business Process Documentation
The same business processes documented in an SAP Solution Manager system can be used to set up Business Process & Interface Monitoring (BPIAM). This covers monitoring of application-related as well as technical-related aspects of the business process instead of the classical system monitoring by components. Custom Code Documentation As with documentation of standard SAP business processes, SAP also understands that each customer has their own specific requirements and unique processes. Thus, the possibility to make custom objects, programs, reports, etc. These should also be documented especially for the following reasons: Modifications could be lost during an upgrade that has not been carried out properly Validation of usage to identify modifications that have been unused for a significant period and could increase maintenance cost and performance losses
Page 45
Figure 6-4. Custom Code Documentation
6.2. SAP EarlyWatch Alert

SAP EarlyWatch Alert is a functionality available within your customers SAP systems. You activate it yourself for each of your SAP components. It is processed in the SAP Solution Manager and it is from here that you activate it and read the weekly reports. To activate the SAP EarlyWatch Alert, simply follow the instructions given in the Best Practice: Activating SAP EarlyWatch Alert in End Customer's System. You can access the Best Practice at http://service.sap.com/var-partner Application LifeCycle Management for VARs Technical Operations. You can also use the SAP Online Help on SAP Solution Manager ( Solution Monitoring SAP EarlyWatch Alert). 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. To learn about the restrictions that apply and to activate SAP EarlyWatch Alert data to be processed at SAP, please follow the instructions from SAP Note 1172939 . SAP EarlyWatch Alert is most effective when activated for the production system of each SAP component in your customers solutions. This gives you a complete overview of all components and their effect on performance and stability. For non-productive systems such as quality assurance, development, training, or test systems the service can be activated as well. As the check thresholds and rating rules are set for production system, some results in the SAP EarlyWatch Alert report do not apply to non-productive systems. E.g. the backup frequency may be of little importance for a training system, and so the rating for backups in the SAP EarlyWatch Alert report can be ignored.
Page 46
Figure 6-5. SAP EarlyWatch Alert Workflow
To create the report, SAP EarlyWatch Alert reads system data and analyzes it against set threshold values. Depending on the analysis, SAP EarlyWatch Alert issues a red, yellow, or green traffic light to indicate to what degree the threshold values are exceeded. The symbols are visible both in the report and as a graphic alert in the system monitoring area of the SAP Solution Manager. Depending on the criticality of the SAP EarlyWatch Alert report, the necessary action is taken by you as a VAR. If the overall rating of the SAP EarlyWatch Alert report is red, SAP strongly recommends partners to contact SAP Partner Support Advisory Center and subsequently open a message to SAP with attached SAP EarlyWatch Alert report within 24 hours. SAP Partner Support Advisory Center will analyze the situation based on the report and decide if a Technical Quality Check (TQC) is required. SAP Partner Support Advisory Center will inform partners on the analysis result and, if required, schedule service delivery of relevant Technical Quality Check session jointly with partner and end customer. For details, see SAP Note 1162164. Figure 6-6 shows further details on the workflow for SAP EarlyWatch Alert data and activities that could be performed depending on the result ratings.
Page 47
Figure 6-6. SAP EarlyWatch Alert Report Analysis
In evaluating SAP components, SAP EarlyWatch Alert monitors the following: General component status System configuration Hardware Performance development Average response times Current workload Critical error messages and process interruptions Database administration The main prerequisites for using SAP EarlyWatch Alert are: A remote connection between your SAP component and your SAP Solution Manager On an ABAP stack system, implement SAP Note 69455, run report RTCCTOOL and follow instructions For a Java stack system or a CRM system: setup of SAP Solution Manager Diagnostics. For Java, SAP Note 976054 describes the prerequisites.
SAP EarlyWatch Alert for Solutions The SAP EarlyWatch Alert for Solutions enables users to gain an overview of the current status of the entire solution landscape within one consolidated system report. This overview includes historical developments, aggregated solution KPIs and detailed statistics about dedicated systems of the solution.
The solution-based report consolidates alerts generated by the regular SAP EarlyWatch Alert (EWA) monitoring services and classifies them in order to identify potential areas for improvement, such as performance or stability. The report tool accesses the Solution Manager Solution Repository and hence provides a link between standard SAP EarlyWatch Alert and individual core business processes with regard to performance evaluations.
Figure 6-7 SAP EarlyWatch Alert for solutions in the SAP Solution Manager
Features SAP EarlyWatch Alert for solutions... is an automated and periodic off-line monitoring service provided by the SAP Solution Manager is solution oriented and comprises all systems relevant to the business processes of production consolidates SAP EarlyWatch Alert reports, focusing on system key performance indicators and SAP EarlyWatch Alert alerts reports on Solution KPIs establishes a relationship between business processes and SAP EarlyWatch Alert alerts facilitates a comparison between system KPIs in order to enable fast detection of main bottlenecks reports on the solution performance as well as the solution stability provides statistics about workload and performance, exceptions and changes each retrieved from the BI of the Solution Manager Diagnostics (SMD) reports the current software and hardware components and tracks changes in the solution landscape The SAP EarlyWatch Alert topic is also covered in section 2.5 of this guide.
Knowledge Base and Services Information To find setup and usage information on SAP EarlyWatch Alert, do visit the SAP Service Marketplace at http://service.sap.com/ewa.
6.3. Initial Assessment

In preparation for SAP Enterprise Support, especially for the delivery of Technical Quality Check delivery with SAP Solution Manager, the VAR should perform one remote setup service (Initial Assessment) for the customer solution. The data collected during this setup service shall be validated by the customer and VAR once every year.
Figure 6-8. SAP Enterprise Support Setup Service
The initial assessment service requires the following information: Customer contacts and roles Upcoming milestones Evaluation of support readiness by assessing the following areas: - Understanding of application lifecycle management - Knowledge of Solution Documentation standards - Knowledge of Technical Quality Checks (TQC) portfolio - Familiarity with SAP Support - Familiarity and usage of SAP Solution Manager Project and Solution Data Usage of SAP EarlyWatch Alert Usage of SAP Solution Manager Service Desk
Proactive/Reactive Services Delivered
A report can be generated that can be reviewed by the customer for improvement of their current set up in preparation for SAP Enterprise Support delivery.
6.4. Incident Management

Incidents during the operations of mission critical applications can cause severe business loss if they are not properly managed, their root cause identified and their effects minimized by immediate corrective action. The Service Desk within SAP Solution Manager helps both, customers and partners, to accelerate the resolution of support incidents, to increase the availability of the IT solution and minimize negative business impacts, and to gain 100% transparency on issues and challenges.
Figure 6-9. Incident Management for VARs
For VARs, it is highly recommended to use the SAP Solution Manager Service Desk for Service Providers for handling the incident management process.
Creating an Incident Accessible either direct from the SAP Solution Manager system or from a provided URL link by the VAR, an incident entry screen contains several key fields that needs to be completed by a customer end user; priority, short text, incident description, component, and attachments if any. Usually, information regarding the end users system id, installation number, and client number has already been automatically assigned as part of the initial configuration on the VARs SAP Solution Manager system.
Page 51
After an end user completes the relevant information, this can be saved and an incident number will be generated automatically to be used as unique identifier.
Figure 6-10. SAP Solution Manager Service Desk Entry Screen
Processing an Incident Support employees can display incidents from the Service Desk and can assign themselves to an incident usually depending on their defined component, category, and/or priority. If the support
Figure 6-11. Service Desk Incident Display employee cannot resolve the incident upon reviewing the content, the next step is to check for any existing solution on the incident posted. The Solution Database can be used for this purpose. This could be either on the customers own solution database or the partners own.
If the incident has not occurred previously, then a support employee can use the SAP Notes Database directly from the incident itself. The Service Desk in the SAP Solution Manager also provides simple status options that can be used for documenting the progress of an incident. This would generally revolve around status options Sent to Support, In Process, and Customer Action during the interaction between support and end customer user.
Forwarding to SAP One of the unique features of the Service Desk in the SAP Solution Manager is the must of collaborating with SAP Active Global Support to achieve shorter solution times, as targeted information allows SAP Active Global Support to better process your message. If the various support levels of the VAR support unit cannot solve the incident, you can forward the incident along with a detailed description to SAP.
Figure 6-12. SAP Data tab for incidents forwarded to SAP
Closing an Incident Whether an incident has been processed by the VAR support organization or by SAP Support, the Service Desk allows closure of incidents via the status options used. Incidents reported to SAP should be separately closed as well. The status options Proposed Solution and Confirmed indicate that the support unit has resolved the incident and provided a solution and that the customer has accepted the solution and permanently closed the incident, respectively.
Page 53
Knowledge Base and Services Information To find setup and usage information on the Service Desk functionality, do visit the VAR-specific partner pages on SAP Service Marketplace at http://service.sap.com/var-partner . Here you will find information on e-learning materials, training roadmaps, configuration and setup information, usage information, and various white papers on the incident management and application life-cycle management topic. As an added service, SAP also offers you the SAP GoingLive Check for VAR Service Desk where an SAP Service Engineer executes proactive remote analysis of the SAP Solution Manager system prior to go live. More information can be found under http://service.sap.com/var-partner VAR Solution Manager Setup. For guided configuration assistance, SAP offers channel partners the Expert Guided Implementation Session for VAR Service Desk (EGI). This is an efficient and interactive possibility to set up SAP Solution Manager Service Desk in a defined period of time. This service is designed for VARs to support them during setup and configuration of Service Desk. For available schedules within your region, please check http://service.sap.com/solutionmanager Application Life-Cycle Management Services Expert Guided Implementation Expert Guided Implementation Calendar
6.5. Maintenance Optimizer

The flexibility of SAP applications and high supportability standards has lead to a considerable increase in the number of software components that are used by individual customers and can be
Figure 6-13. Maintenance Optimizer in the SAP Solution Manager
Page 54
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 Service Marketplace and downloaded them. Then the customer had to import the patches into the development system, test them in the quality assurance system and finally release the patches to the production system. These steps are now simplified by the SAP Solution Manager Maintenance Optimizer, thus the customer can always have an overview of the maintenance activities in all systems and solutions. As part of the SAP Solution Manager, the Maintenance Optimizer offers a comprehensive procedure for software maintenance, including: 1. Maintenance Optimizer shows relevant maintenance files for the customers solution. 2. Select the required packages and approve the download of the maintenance files. 3. Download the software. 4. Import the software (furthermore uses familiar tools such as SPAM, SAINT, ) 5. Close the maintenance procedure.
Figure 6-14. Maintenance Optimizer interaction with the SAP Global Support Backbone
Knowledge Base and Services Information To find setup and usage information on the Maintenance Optimizer, do visit the SAP Service Marketplace under http://service.sap.com/mopz.
Page 55
6.6. Maintenance Certificate

It has always been important to SAP that our customers receive full support for their SAP solutions. This includes the delivery of software corrections and improvements that can boost an IT solutions performance and stability. For example, SAP offers the maintenance optimizer to support an end-toend, fully pre-configured maintenance management process. Today, the maintenance optimizer is the central application within SAP Solution Manager to control and ease maintenance of your customers SAP solutions.
Figure 6-15. Automatic Distribution of the Maintenance Certificate for Customers with own SAP Solution Manager system Maintenance Optimizer was integrated with software lifecycle manager service to further automate the download of support packages and SAP enhancement packages as well as the deployment of the packages to satellite systems connected to SAP Solution Manager. The integration with SAPs
Figure 6-16. Automatic Distribution of the Maintenance Certificate for Customers supported by a VARs SAP Solution Manager system
Page 56
transport management system makes the management of all software and configuration changes consistent. Another improvement was the introduction of a maintenance certificate. The certificate enables software logistics tools to identify your customers system and the exact scope of your customers corresponding SAP maintenance agreement. This will also improve the quality of your customers SAP solution by preventing patches from being deployed to the wrong system accidentally. Knowledge Base and Services Information You can find detailed information how to use the Maintenance Certificate on the VAR pages on SAP Support Portal at http://service.sap.com/var-partner Application Life-Cycle Management for VARs Maintenance Management. To find general setup and usage information to Maintenance Certificate, do visit the SAP Service Marketplace under http://service.sap.com/alm SAP Solution Manager in Detail Maintenance Certificate
An SAP Solution Manager system should be run up to the latest support package level. SAP Maintenance Optimizer should be operational, Service Desk for Service Providers should be used as an incident management system and other functionalities should be considered for various ad hoc and packaged services.
Page 57
Appendix A
Quick Links
Application Lifecycle Management
General Information
http://service.sap.com/alm http://service.sap.com/alm-processes http://www.youtube.com/runsap VAR specific information http://service.sap.com/var-partner ALM for VARs End to End Solution Operations http://service.sap.com/e2e RunSAP Methodology http://service.sap.com/runsap Support Standards http://service.sap.com/supportstandards Tools http://service.sap.com/alm-tools
Channel Partner
General Information
http://channel.sap.com Support Snapshot Page
Incident Handling
SAP Notes Database SAP Message Wizard Incident Handling for VARs Correction Downloads Software Center Installations & Upgrades SAP Expert Forums Online Software Ordering Quick Links
http://service.sap.com/notes http://service.sap.com/message http://service.sap.com/var-partner Getting Started VARs http://service.sap.com/patches http://service.sap.com/swdc http://service.sap.com/instguides http://service.sap.com/request-help http://service.sap.com/swcenter http://service.sap.com/quicklinks
Partner Center of Expertise
General Information SAP Message Wizard Incident Handling for VARs

Partner Services Delivery
http://service.sap.com/var-partner Partner Center of Expertise http://service.sap.com/message http://service.sap.com/var-partner
Page 58
SAP PartnerEdge Contact PSA Contact
http://channelpartner@sap.com http://service.sap.com/sap/bc/bsp/spn/smb_var04
SAP EarlyWatch Alert
General Information VAR-specific information EarlyWatch Alert Reports
http://service.sap.com/ewa http://service.sap.com/var-partner Technical Operations http://service.sap.com/inbox
SAP Products
General Information Maintenance Information Platform Availability Matrix
http://service.sap.com http://service.sap.com/maintenance http://service.sap.com/pam
SAP Solution Manager
General Information VAR specific information Functionality
http://service.sap.com/solutionmanager http://service.sap.com/var-partner VAR Solution Manager http://service.sap.com/alm http://www.youtube.com/runsap http://service.sap.com/alm-tools Online Help http://help.sap.com SAP Solution Manager E-Learning http://service.sap.com/rkt-solman Training Information http://www.sap.com/services/education/catalog /solutionmanager.epx Maintenance Optimizer http://service.sap.com/mopz Solution Manager Forum https://forums.sdn.sap.com/forum.jspa?forumID=351 http://service.sap.com/var-partner Information for VAR VAR Solution Manager Setup Partner Discussion Forum Expert Guided Implementation http://service.sap.com/solutionmanager SAP Solution Manager Services Expert Guided Implementation Expert Guided Implementation Calendar
SAP Support Offerings
General Information VAR specific information
http://service.sap.com/supportofferings http://service.sap.com/var-partner Understand SAP Enterprise Support (for VARs)

Page 59
Maintenance SAP Enterprise Support
SAP Standard Support Technical Quality Checks
http://service.sap.com/maintenance http://service.sap.com/enterprisesupport http://channel.sap.com SAP Business Management Solutions SAP Business All-In-One Support SAP Enterprise Support http://service.sap.com/standardsupport http://channel.sap.com SAP Business Management Solutions SAP Business All-In-One Support Snapshot Service Portfolio
Page 60

Partner Center of Expertise SAP

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Partner Center of Expertise SAP

Încărcat de

Drepturi de autor:

Formate disponibile

Setting up a Partner Center of Expertise

SAP AG August 2010

Chapter 2. 2.1. 2.2. 2.3. 2.4. 2.5. 2.6.

Chapter 4. 4.1. 4.2.

Chapter 5. 5.1. 5.2. 5.3.

Chapter 6. 6.1. 6.2.

6.3. 6.4. 6.5. 6.6.

Partner Center of Expertise

Partner Services Advisor

PCoE Judging Committee

Figure 1-1. Partner Center of Expertise Process Steps

Figure 2-1. Support Infrastructure Components

2.1. Dedicated Support Hotline

2.2. Remote Connection

Figure 2-2. Remote Connection Setup

2.3. Test Systems

2.4. Incident Management System

Figure 2-3 SAP EarlyWatch Alert Data Transfer Setup

2.6. Support Staff

3.1. Preparing an Incident

3.2. Reporting an Incident

3.3. Receiving an Incident

3.4. Acknowledging an Incident

3.5. Assigning an Incident

3.6. Processing an Incident

3.7. Forwarding an Incident

3.8. Closing an Incident

3.9. Handling Complaints and Escalations

Marketing & Communications

4.1. Presentation of Support

Figure 4.1 Structure of Support Offering

4.2. SAP Communication

SAP Channel Manager

5.1. Support Reporting

5.2. Feedback Gathering

5.3. Service Improvement

SAP Solution Manager

6.1. Solution Documentation

Figure 6-2. Logical Component Definition

Figure 6-3. Business Process Documentation

Figure 6-4. Custom Code Documentation

6.2. SAP EarlyWatch Alert

Figure 6-5. SAP EarlyWatch Alert Workflow

Figure 6-6. SAP EarlyWatch Alert Report Analysis

6.3. Initial Assessment

Figure 6-8. SAP Enterprise Support Setup Service

Proactive/Reactive Services Delivered

6.4. Incident Management

Figure 6-9. Incident Management for VARs

Figure 6-10. SAP Solution Manager Service Desk Entry Screen

Figure 6-12. SAP Data tab for incidents forwarded to SAP

6.5. Maintenance Optimizer

Figure 6-13. Maintenance Optimizer in the SAP Solution Manager

6.6. Maintenance Certificate

Application Lifecycle Management

http://channel.sap.com Support Snapshot Page

Partner Center of Expertise

General Information SAP Message Wizard Incident Handling for VARs

http://service.sap.com/var-partner Partner Center of Expertise http://service.sap.com/message http://service.sap.com/var-partner

SAP PartnerEdge Contact PSA Contact

SAP EarlyWatch Alert

General Information VAR-specific information EarlyWatch Alert Reports

http://service.sap.com/ewa http://service.sap.com/var-partner Technical Operations http://service.sap.com/inbox

General Information Maintenance Information Platform Availability Matrix