Manager
See how the configuration of Service Level Agreements (SLA) works in SAP Solution Manager, with a specific focus on how information moves among configuration objects. Knowing how the objects involved interact allows you to not only perform more effective configuration but also solve problems should anything go wrong.
Key Concept
SAP Solution Manager’s Service Desk has a deeply configurable management of Service Level Agreements (SLA). After activating and properly configuring this feature, the system can automatically alert Service Desk employees and managers when service tickets and incidents run out (or are about to run out) of time to be taken (which is called response time) and to be solved (known as solution time). In other words, response time is the amount of time spent between the creation of the document and the first action performed on it, and solution time is the total amount of time spent on the document until it is confirmed or withdrawn.
The configuration of Service Level Agreements (SLA) in SAP Solution Manager is a little tricky. There are several aspects to be considered. By performing a quick search you can find some good articles and papers explaining how to properly configure SLA, including a great one by SAP,
“Advanced Configuration Guide Service Desk for Service Providers SAP Solution Manager” (SAP Marketplace registration required). Unfortunately I figured out that all these documents (including blogs and articles from SDN) are lacking a base explanation of how information flows among the configuration objects, a clear explanation of the utility of each performed configuration, and how they interact with each other. This knowledge is important to perform a smooth configuration but, most important in my opinion, is to know how to get everything working again when something gets out of order. This is the purpose of this article.
SLA management in SAP Solution Manager is driven by escalation management, focusing on moving overdue tickets to upper levels in the Service Desk organization. It helps Service Desk leaders and managers to fulfill their key performance indicators (KPIs) by receiving email notifications alerting them about expiration deadlines. That way, leaders and managers are set free from monitoring Service Desk cockpits and are involved in the ticket management process only when this is really necessary.
To get SLA working, you need to maintain several objects. I’ll explain in detail how these objects interact and what the purpose of each item is for the whole solution.
System Preparation
Before configuring SLA in SAP Solution Manager, you need to activate the SLA feature in the target system. SAP usually delivers systems with some features deactivated to keep unused objects in the background. Most of them can be awakened by activating corresponding Business Configuration Sets (BC Sets).
A BC Set is a package of bundled configurations that can be implemented quickly by activating the package. The BC Set for SLA is SOLMAN40_SDESK_SLFV. You can use transaction SCPR20 to handle BC Sets.
Organizational Structure
The starting point is the creation of an organizational structure that defines the hierarchical chain responsible for solving the Service Desk messages. This structure must have a service organization and a sales organization. These organizations must carry the attributes country, currency, sales division, and distribution channel, because SAP Solution Manager is based on SAP Customer Relationship Management (SAP CRM). These standard configurations must exist for the SLA to function properly. SAP CRM manages the SLA based on service contracts (the SLA is one of the items of the set of agreements established in these service contracts). It needs a service organization to work (the service organization is responsible for fulfilling the agreement established by the contract). A sales organization must exist as well because the support organization is selling a service to the customer. To determine the correct service contract, SAP Solution Manager reads the attributes (mentioned above) from the main business partner assigned to the Service Desk message: the Sold-to Party.
Figure 1 illustrates the relationship among these objects.
Figure 1
How the organizational model interacts with the Service Desk message
SAP Solution Manager identifies people functions (e.g., manager, developer, tester) by means of business partners (the technical name is partner function). The Sold-to Party is the business partner function that identifies the customer in a Service Desk scenario. To automatically determine the Sold-to Party, the system reads the Installed Base (IBase) field, which is filled by the user upon the creation of the Service Desk message.
IBase management allows the assignment of objects to customers and is extensively used in SAP Solution Manager to perform several actions, such as (but not restricted to) document changes to objects, providing details for processes, and identifying the objects involved in a problem being reported. A good practical example of IBase use is Change Request Management (ChaRM), where the IBase identifies the set of systems (e.g., development, test, productive) affected by a change. In this context, the Sold-to Party is one of the objects carried by the IBase.
When a Service Desk message is created, the message processor manually selects the IBase for the message to determine the affected system. SAP Solution Manager assigns the Sold-to Party (that is assigned to the IBase) to the message. It collects the service and sales organization data from this Sold-to Party to determine the service contract that carries the SLA parameters that rule the solution of the message.
It is important to mention that neither of these configurations is transportable, so they must be repeated in the test and productive systems if your SAP Solution Manager landscape is a multi-system one.
Create an Organizational Model
SAP Solution Manager allows the maintenance of an organizational model where, for example, it is possible to configure the Service Desk hierarchy to perform issue escalation. This is configured in the organizational model using transaction PPOMA_CRM.
A good example of an organizational model has a service organization (usually called Service Desk), that leads service teams. This service organization is also defined as a sales organization. Each service team has an incident manager (responsible for the interaction with the customer’s management board), a support leader (responsible for the management of the support team itself), and one or more support team attendees who effectively solve the incidents. Refer back to Figure 1 for an example of the organizational model.
Tip!
Only one service organization and one sales organization must exist. Otherwise SAP Solution Manager won’t be able to automatically determine these when a new Service Desk message is created. Although the system presents a list with the existing service and sales organizations to the user when a message is being maintained, this doesn’t happen when the message is created (automatically or through other transactions than transaction CRMD_ORDER). Keep this in mind when configuring an organizational model.
Assign Organizational Structure Elements to a Sold-To Party
As stated before, Sold-to Party is the partner function that identifies the customer in a Service Desk context. Among the parameters that you can assign to this business partner are the ones needed to help SAP Solution Manager determine the contract that carries the SLA parameters when a Service Desk message is created: the sales organization and the service organization. The transaction to maintain business partners is BP. If this configuration is incomplete, the system raises the error CRM_PRICING101 (Pricing data for partner could not be read) when a service contract is being created.
Tip!
To be able to perform these steps, you must have the authorization CRM_BP_SA in your profile, or the system raises the error CRM_ORGMAN204 (There are no sales areas for maintenance).
According to SAP Notes 558471 and 529653, the system needs two distinct configurations on the sales area to work (one with a sales division and another without it). Otherwise, the error CRM_PRICING101 (Unable to read the price determination data from the business partner) is raised during the creation of a Service Desk message.
Assign a Sold-To Party to the IBase
As already explained, the IBase is used to determine the Sold-to Party. You can maintain the IBase with transaction IB52.
If this configuration is missing (or wrong), SAP Solution Manager is not able to automatically assign a Sold-to Party to the Service Desk message. Without a Sold-to Party, the system cannot determine the information it carries, and several error messages are issued when a Service Desk message is created using transaction NOTIF_CREATE, CRM_DNO_MONITOR, or CRMD_ORDER (
Figure 2).
Figure 2
Errors due to a lack of a Sold-to Party in Service Desk
Product Configuration
SAP Solution Manager uses the SAP CRM approach to manage SLA. This approach uses a service contract to determine the parameters of the agreement. A contract delivers a product that, in SLA context, is the support service. The SLA performance indicators are among the parameters of this product. In SAP CRM, products are organized in product hierarchies.
To have an SLA calculation, you need to configure a product hierarchy. It must contain a product category and this category must be assigned to a service product (
Figure 3). For SLA, one product is enough.
Figure 3
Product assignment to service contracts
Tip!
The SAP system allows only one hierarchy per product type (in this case, service). To check if a category has already been assigned to a product type, use transaction COMM_PRAPPLCAT and select the item Assgmt per Product Type for the application called Product. Check if there is a line to the product type service. If there is, you have to maintain that hierarchy. If no assignment exists, you need to create one. The hierarchy SOL_HIER is created when you install SAP Solution Manager, so you can use that. For more information, check page 12 of the document
CRM E-Service (C74) - Building Block Configuration Guide (no SAP Marketplace registration required).
Product Hierarchy and Support Product
Since SAP CRM uses hierarchies to manage products, the first step of a product configuration is to set up a product hierarchy and then create a service product. As stated earlier, only one product is needed for the SLA to work properly. It is important to categorize this product as a service product. It carries some of the information needed to link the service contract to the Service Desk message, such as Service Category Group, Time Unit (usually hours), and the service and sales organizations already configured for a Sold-to Party. Follow IMG menu path SAP Solution Manager Implementation Guide > Customer Relationship Management > Master Data > Products > Special Settings for Service Processes > Define Service Products and read the information in the Define Service Products node
Preparing Service Desk Messages
The main feature of the SLA in SAP Solution Manager is the definition of due dates to Service Desk messages. To work properly, a few settings must take place in the Service Desk transaction type (which is the technical game for the kinds of documents, or workflows, handled by SAP Solution Manager).
Figure 4 shows which components are assigned to a Service Desk message in an SLA scenario.
Figure 4
Service Desk message composition
Transaction types carry several configurations, most of them organized in profiles. For example, there are text profiles (that manage the texts and strings used by the transaction type), status profiles (defining the statuses of a document that manages the workflow), date profiles (defining all the relevant dates of the document), action profiles (defining the actions that can be executed within the transaction type, such as approve or reject), and organizational data profiles (that manage how the organizational structure is handled together with the document). For the SLA to work, you need to configure a date profile and assign it to the transaction type. Then you need to assign the standard organizational data profile.
Additionally, you need to select a contract determination procedure so SAP Solution Manager can identify from which service contract the SLA parameters have to be gathered. To get a better understanding about contract determination procedures, read chapter 5.1.4 of the SAP document mentioned in the beginning of this article. It is also necessary to set up copying controls from the service contract to the Service Desk message (so the data from the contract is transferred to the message), as well from the item categories to the message itself. Remember — a service contract has items, and items have categories.
The default Service Desk transaction type is SLFN. SAP recommends avoiding the use of the default type to keep a template to use in further configurations. You need to create a copy of the transaction type so you can use it for customers. Use names such as ZLFN and YLFN.
Maintain the Service Desk Transaction Type
For the transaction type to be able to properly calculate and handle SLA, you set the value E to the transaction type’s contract determination. E represents Only at Item Level: Assign Immediately if Unique, which means that the system checks for a matching item from the service contract to determine if it will be assigned to the Service Desk message. The organizational data profile SLFN00000002 (Service Desk Service Procedure) also has to be assigned to the transaction type, so the system uses the organizational structure that has been configured. Pay special attention when selecting the organizational data profile, because there are two distinct profiles with the same SLFN00000002 code (SALE Service Desk Service Procedure and SERVICE Service Desk Service Procedure). You must select the SALE Service Desk procedure instead of the SERVICE one.
Figure 5 shows part of the list of organizational data profiles allowed to be assigned to the transaction type. Use transaction SPRO and follow IMG menu path SAP Solution Manager > Scenario-Specific Settings > Service Desk > Service Desk > General Settings > Define Transaction Types. As mentioned earlier, the Service Desk organization is selling support as a service to the company, so SALE must be selected.
Figure 5
Always select the SALE Service Desk Service Procedure
Configure Item Categories
An item category specifies the properties and attributes of a business transaction item, and therefore controls how the item is processed. An item category is assigned to an object type because the item object type defines the business context in which an item category is used. In an SLA context, SAP Solution Manager uses item category SOL4 to identify the type of service item to be assigned to the contract (in this case, the service product configured earlier).
In addition, the item category SOL4 (support desk service) manages some important configurations for the Service Desk message, such as the date profile, partner schema (where the players of the Service Desk flow are defined), and the action profile. These parameters must be set for SLA to work properly. Ensure that the partner determination procedure is SLFC0001, date profile is SRV_SLA_ITEM_SAP, and action profile is SERVICE_ORDER_ITEM_SLA.
Define Item Category Determination
You can configure SAP Solution Manager to define which item categories are assigned to a business transaction (transaction type) depending on the business transaction category and item category group. For example, if a product with the item category group SOL4 is used in an operation, the SAP system creates the item category allowed by assigning the item categories allowed for business transaction categories to item category groups. In this IMG activity, you inform SAP Solution Manager that the Service Desk will always use the item category SOL4 and, through this item category, the system assigns the correct parameters (shown in the previous paragraph) to the Service Desk message.
Define Copying Control for Transaction Types
SAP Solution Manager uses the concept of copy control to transfer data from a transaction type to another. Service contracts manage several data that must exist in a Service Desk message to allow the SLA calculation (for example, the service product and the SLA parameters). Since these parameters are managed by means of service contracts, and the SLA is calculated from the Service Desk message, it is necessary to transfer the parameters from the contract to the message, which is configured with copy control. The service contract transaction type is SLFV.
Define Copying Control for Item Categories
SAP Solution Manager uses three item categories to manage SLAs: SOL3 (Service Desk contract), SOL4 (support desk service), and SOL5 (support desk configuration). The contract data is copied to the service, and the service data is copied to the configuration.
Enable Item Data Tabs in Service Desk Messages
SAP Solution Manager has default screens to manage documents using transaction CRMD_ORDER. These screens have several components and are organized using tabs. Some unnecessary tabs are not shown by default to give cleaner screens to the users. When the SLA is in place, some information should be available to the customer under the Item Data subscreen. To enable this screen and its tabs, you need to set a configuration in the screen sequence control and then assign it to a screen profile. The transaction to maintain screen sequence controls is CRMV_SSC. Select the transaction type for Service Desk (the standard one is SLFN, but you may have ZLFN or YLFN, as explained earlier) and UI Method ORDER. In the next screen, select the Complete Subscreen Assignment of Panel option for screen profile type SRVO and click the Edit button. Finally, create a line for screen SRVO, the screen profile used for your Service Desk transaction type, panel SRVO_OVVW, item profile <*>, number 15, subscreen 7195, program name SAPLCRM_ACTIVITY_UI and subpanel SRV_HD_01. SAP Notes 605375 and 499650 give a good background on this change.
SLA Service Configuration
As described earlier, SAP Solution Manager uses service contracts to establish the SLA. The parameters of this agreement are defined using two profiles (Figure 6):
- Service profile: defines the service time, or the amount of time available to completely solve a Service Desk message
- Response profile: defines the response time, or the amount of time available to start working on a Service Desk message
Figure 6
SLA profiles
SLA Profiles
The service profile defines the time frame covered by the service contract. For example, the company Service Desk operates on weekdays, from 9 am to 6 pm. The service profile also determines the time zone to calculate the business hours and the official holidays. These parameters are used by the system to calculate the deadlines for solving the Service Desk messages.
The response profile defines parameters to differentiate how long the support team can work in a Service Desk message before the deadline is considered exceeded. SAP Solution Manager offers four parameters to set up the SLA matrix: Priority, Category, Catalog, and Subject.
SAP has four priority levels to group Service Desk messages: Very High Priority, High Priority, Medium Priority, and Low Priority. The definition of what characterizes the priority of a Service Desk message is completely subjective and should be agreed and documented by the Service Desk organization.
Category, Catalog, and Subject are three additional fields that SAP Solution Manager offers to Service Desk organizations to organize the messages. These fields are based on lists of choices that can be configured as part of a standard Service Desk setup. In this example, the Subject field is used to define the nature of the issue being raised by the customer, such as System Error, Enhancement, How To, and Project. The Category field is used to define the business area that is reporting the issue (e.g., payroll, accounts payable, accounts receivable). I’m not using categories or catalogs in my example, but you can use catalogs to group subjects — for example, one catalog for urgent corrections and one for regular corrections. You can configure SLA profiles using transaction CRMD_SERV_SLA.
Service Contract
As mentioned earlier, SAP Solution Manager uses service contracts to assign SLA parameters to Service Desk messages. To determine which parameters are entitled to a specific message, the system checks if some data from the message matches the data in the contract, starting from the IBase, then Sold-to Party, then sales and service organizations, and so on. All these parameters and relationship among them have already been explained in this article. For the SLA to work properly, you need to create and release service contracts. When creating the service contracts, set their status to New. This allows the proper configuration until the contract is ready to be used. Then set the contract to Released.
Email Notification
One of the main features of the SLA management in SAP Solution Manager is the ability to send email notifications when the deadlines are exceeded. This helps the person responsible for solving the issues avoid cumulating tickets in large backlogs.
The best way to create standard notifications is by using SAP Smart Forms. These forms are highly customizable and allow the use of a word processor to format the text, resulting in high-quality documents.
To send the mail notifications, SAP Solution Manager uses actions that are assigned to transaction types through action profiles. These actions are triggered through conditions that read the due dates and statuses of the Service Desk message and define when the notification is allowed to be sent.
Finally, you need to schedule a job to effectively send the notifications that are ready to be delivered. This job must run within an interval that is shorter than the shortest duration of the SLA. The detailed description of how to schedule the job is explained in chapter 5.2.4 of the SAP document mentioned in the beginning of this article.
Figure 7 shows the relationship among the configurations involved in email notifications.
Figure 7
Configure mail notifications
Check the SLA Action Profile
Action profiles are a set of actions that can be executed within a certain transaction type. Examples of actions are the changing of document statuses, the approval or rejection of items, and the creation of objects such as transport requests or subsequent documents.
SAP Solution Manager has a standard action profile that manages SLA actions: SERVICE_ORDER_ITEM_SLA. You should check if this profile is properly configured and, if not, adjust the settings to allow the system to send the notifications. The correct parameters are explained in detail in chapter 5.2.3 of the SAP document mentioned in the beginning of this article. Each action is assigned to the proper condition, which enables the execution of the actions through the configured job.
The Big Picture
Figure 8 shows all the explained objects and configurations and how they interact. When a Service Desk message is created, the user informs the IBase to which the message is related. SAP Solution Manager reads the sold-to party assigned to the IBase and identifies the service and sales organizations assigned to that sold-to party. Then SAP Solution Manager searches for a service contract with a matching service product, service organization, and sales organization and assigns the contract items to which the service and response times are assigned to the Service Desk message. These times are assigned to notification actions that are scheduled through a specific job to send email notifications to the Service Desk responsible, informing it that the SLA time parameters have been exceeded.
Figure 8
The big picture
Cristiano Canzone
Cristiano Canzone is an SAP Solution Manager-certified consultant who has worked at SAP Brazil since 2008. In his 12 years of SAP experience, he has also worked at PricewaterhouseCoopers and IBM as an SAP Basis-certified consultant. Cristiano is currently the SAP resource responsible for the SAP Solution Manager initiatives at Petrobras, the largest oil company in Latin America. He lives in Rio de Janeiro, Brazil with his wife, who is also an SAP consultant (specialized in SAP ERP HCM).
You may contact the author at
cristiano.canzone@sap.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the
editor.