To a service provider, Service Management is a dark art. To them, it’s a bit like the game of Bridge. In Bridge, two players must work together to defeat an opposing partner pair, with the seemingly impossible restriction that any communication is conducted out in the open, also visible to their opponents. So how does this metaphor relate to SAP’s ITSM?
For most organisations, their service provider’s control of incident logging provides them first call on accounting how well they have performed resolving incidents. For the service delivery manager, acutely aware of the limitations of their resources and the probable overselling of the agreed service level, there is an understandable reluctance in being too open an honest about the nature of the errors and their resolution before they can colour it with the “bigger picture” (however one chooses to define that). Inevitably then, service providers acting as the gatekeepers for KPI reporting on performance and to put it bluntly, are very well able to obfuscate their process deficiencies at the monthly service level review meeting.
An organisation taking back direct custody of this raw information is one of the chief benefits having your own ITSM provided by Solution Manager. Let’s have a look at the most important points of SAP’s ITSM (click each toggle to expand):
It’s important when discussing the merits of SAP’s ITSM to be clear that the concept of IT Service Management (ITSM) is an ITIL inspired delivery of a broad IT support service, and SAP’s offering is embedded in SAP Solution Manager. Any definition of ITSM must include
- Incident and problem management
- Change, configuration, and release management
- Service request management and self-service
- Knowledge management
Such inherent close integration with a system dedicated to providing IT system support and itself built from SAP’s Customer Relationship Management (CRM) technology means there are advantages that come naturally with the tool that no other alternative system can match. The following sections explore these synergies in more detail.
SAP ITSM is integrated into both Solution Manager, the central repository for information about the landscape, and in S/4 HANA business applications. There are compelling advantages to this integration
1. Incidents created by SAP’s ITSM have contextual information automatically transferred from the problem application to the incident notification. Such contextual information would include things like the actual error message, the application that was being used, the code of the error, the system it occurred in, the user who had the error, their authorisations, and the exact time it happened. All the essential information for root cause analysis, and something that is all too often not included in the initial report of the problem and left to a now redundant drawn out step of basic data gathering.
2. Having an incident created from an error situation and then routed automatically to wait in someone’s inbox already fast tracks incident management for high expectation service level targets. Even if the incident is not created automatically, in Solution Manager the monitoring log that displays the error will have a conveniently located hyperlink so that an incident can be created from the error with just one click. This functionality to immediate move the process forward answers the very first question always asked when reporting an incident: who is dealing with it, and what is its status?
3. Incidents created in SAP are stored as a class of online forms called transaction types. Different transaction types serve different requirements along the application maintenance lifecycle. One of the great benefits of having uniform storage and presentation for all the transaction types is the way data entered into one transaction type can be automatically copied over into another transaction type that follows on from the previous step. The following “copy controls” are provided as standard:
i. Incident copied to a problem transaction type, where a problem in ITIL parlance is a collection of cause-related incidents.
ii. Incident copied to a message to SAP, for consideration by SAP Active Global Support.
iii. Incident or problem copied to a Request for Change transaction type, which is where the solution to an incident has been identified as requiring a change to a running system and needs approval before creating a change document.
iv. Incident copied to a knowledge-based article (KBA), where the solution is not a one-time only fix, but requires a permanent instruction on how to overcome a recurring problem.
There are three types of incident management reporting, and it’s important not to get confused between them.
1. The first type of reporting supports operational requirements and is provided by the worklist. This is the central tool for incident monitoring providing a picture of where an incident is at any point in the end-to-end process, from creation to closing, and provides list filtering on both who in the team is handling the ticket and also attributes used to describe the nature of the incident.
2. The second type of reporting is used to generate statistics or Key Performance Indicators (KPIs) to measure Service Level Agreements (SLA) compliance. Typical KPIs would be defined as “number and percentage of incidents by reason code” or “number of incidents resolved in a certain time period”. While these statistics are indeed important in establishing compliance to SLAs, they do not on their own point to potential places an incident handling process can be improved.
3. The limitation of the second type of reporting mentioned above is that assumptions are made a priori on what KPIs should be collected. The objective for the third type of reporting is performance monitoring allowing identification of the root causes of errors that can litter the value-chain. Such data mining is only possible when incidents reporting comes from an integrated BW collection system as is found in SAP Solution Manager. All that is needed is for as many data points to be collected as possible, and then ranked by frequency to uncover underlying causes. An example of how this would work in practise is if one could find an uptick in incidents from the time since a workpack was introduced to uncover poor testing, or identify which applications areas or other category are having the most incidents which would indicate quality problems in terms of support or solution.
A very common reservation expressed to using SAP’s ITSM is that there is already in use an existing ticketing system and this is used for multiple systems; for multiple service providers; and provides consolidated reports for support charges. Nevertheless, this should not be a reason to discount implementing SAP’s ITSM. While the advantages of integration with Solution Manager monitoring and contextual information of the S4/HANA errors is compelling reason enough, these benefits can be preserved as the incident created from SAP’s ITSM can be synchronised with an external ticketing system.
ITSM applications are generally not free, or if they are free they are generally not very good. SAP’s ITSM is very good, as powerful as only enterprise software based on CRM can be – and is already paid for through the support contract that provides for use of SAP Solution Manager. This represents a considerable support saving direct to the bottom line even before a single incident is recorded, a saving that can offset the one off configuration and training costs for switching over to a new ITSM system, and continues to deliver bottom line savings continuously thereafter.
If there are lingering doubts about the allowed scope of ITSM to support the customer’s landscape, here SAP has recognised that restrictive rights are counter-productive and have come up with the following formula.
Systems: SAP Enterprise Support customer can use SAP ITSM for both SAP and connected non-SAP components, including non-SAP business applications, management applications, middleware and databases, and hardware such as PCs and printers provided they are operated in conjunction with Enterprise Support Solutions and are required to complete the business processes as documented in the solution documentation in SAP Solution Manager.
Further, it is not expected to sort through which hardware is used for which system. If a non-SAP IT asset, for example a mobile devices or printer is used in conjunction with your SAP environment and are documented in SAP Solution Manager, they are also covered for support with SAP’s ITSM.
Users: Customers don‘t need to license users for the standard usage of SAP Solution Manager. Even external employees working for the customer don‘t need to be licensed. This is valid for Standard Support as well as Enterprise Support and higher.
This insight article started with a declaration. An IT service management tool that merely supplies an input screen front-ending a database of tickets, which so many consider adequate for ITSM, is missing the mark. The capabilities laid out show SAP’s ITSM provides is more than just a reporting tool for your incidents, but an insight at all levels of the business on the vitality of the system being managed.
If you’d like to find out more about SAP’s ITSM solution and how it can help your organisation, why not contact us for a demo.