What has been standard within the classical manufacturing and other producing industries for several decades becomes more important to IT organizations nowadays: tailoring standard processes from best practices and implementing these processes with the help of integrated software.
Many IT organization – independently if internal or external – currently concentrate their strategical activities on adopting and implementing IT processes like those found in the ITIL framework. However, not only the processes itself are introduced, further more tools and software suites are being implemented to support these processes.
These described circumstances lead to several challenges, which can be divided into organizational and technical challenges. On the one hand, changing the processes – and therefore the way people used to act for a certain time – is not always easy. On the other hand, as soon as these processes are agreed upon, the chosen tools or tool suites need to communicate and integrate into the existing landscape. Commonly, this results in integrating a multitude of different platforms, applications and technology components into one leading ITSM tool (suite).
SAP applications – like SAP ERP, SAP BW, SAP CRM etc. – often act as important part of the offered service portfolio, supporting the established business processes and business services. The integration of ITSM processes and SAP ALM processes is therefore an important topic to be discussed. In addition, the concrete integration of ITSM software with SAP software needs to be discussed.
This blog post is not about how to choose ITSM software or what software should be used. Further on, this blog will not give an overview of what ITIL or ITSM and how to implement ITSM processes within organizations. This blog is rather about the integration of SAP solutions into an existing or newly implemented Non-SAP-ITSM software (e.g. like Microsoft System Center Service Manager, ServiceNow, BMC, etc.). It tries to answer questions about what might be suitable for integration and how to integrate it.
First of all, let us have a closer look on possible scenarios, where an integration makes sense. During some customer projects, four main areas emerge as the key points of interest and integration: Change Management, Incident Management, Event/Capacity Management and CMDB design. Within the next few chapters, these scenarios will be detailed and evaluated. Possible solutions will be recommended in the trailing chapters of this blog post.
SAP has its own processes established for a – more or less – technical change management: SAP Transport Management System. The STMS defines transportation routes between SAP systems and “packages” every modified or newly created object into a transport request, which can be transported within the landscape. Further on, SAP delivers Change and Request Management (ChaRM) as part of the SAP Solution Manager. ChaRM implements change request management processes with a tight integration into the underlying SAP technology (e.g. STMS).
So, if SAP offers its own its own implementation of Change and Request Management, why should one think about integration? Wouldn’t it be easier to use SAP’s ChaRM for SAP changes? Indeed – but then there would be at least two entry points: one request entry for SAP changes, one entry point for Non-SAP changes. Moreover, what needs to be done, if the change is for SAP and Non-SAP?
Therefore, the first reason to integrate SAP and Non-SAP ITSM is a central entry point for Change Management. This way, key users and change managers can create and track Change Requests during their way towards becoming a change and being implemented. In addition, this should be possible on a higher level, independent from the application and infrastructure underneath.
The second reason, from the perspective of the application owner, is traceability and auditability of changes made to the offered IT services, especially changes made to critical SAP applications. Even if the application owners use their own software for technical or non-technical change management, redundant maintenance of information should be avoided – as far as possible. An integration between a central ITSM tool and the SAP Change Management would solve this issue by either integrating the process layer from the ITSM tool with SAP ChaRM or directly with the SAP TMS.
The next possible integration scenario is based on the requirements for a central event management. Common organizations have an SAP Basis team, which monitors their SAP systems on a daily basis. By introducing a central management and monitoring system of IT Services and IT Service Management, monitoring of available IT Services and the underlying applications and infrastructure should be done within these central applications. Critical events should be forwarded to the central software for monitoring and event management. For further analysis, it is – as with any other application – required to work with the SAP system itself. Nevertheless, alerting can be done centrally, which also makes it easier to aggregate and report these information. Furthermore, these information can be used as foundation for SLA reporting.
Another example for integrating SAP and a third party ITSM tool is the enrichment of the central CMDB with SAP Applications, SAP Application Components and versions. This way one has a CMDB with all these SAP related information automatically maintained within the central CMDB, which makes the process integration, e.g. within Incident Management, much easier and much more comfortable.
The integration between the Incident Management process and SAP is also a common requirement. Adding additional information for incident tickets is always helpful for solving the incident. Either through adding information directly while creating the incident, or by enriching the incident ticket while working on it, the incident resolution can be accelerated.
As example, an incident ticket could be enriched by general information like the SAP System, the installed application components and versions and further on, additional information about the user could be added. This may include the locked-status of the user or recent authorization issues, which are helpful for processing and solving the incident, but also for using the incident database as Knowledgebase.