This E-3 Special is available for download at the bottom of the page and was co-authored by KPMG Partner Carsten Lang and Assistant Manager Justina Kurzawa.
With the increasing heterogeneity of the SAP ecosystems used by clients, the often customer-specific use of integrated products and interfaces networked with each other and the creation of total transparency have been gaining in importance for some time now. The reason for the frequent lack of transparency is often simple to explain. While a licence manager today has overall responsibility for any and all software licences and the measurement of their respective use, they are frequently not responsible, or have only very recently been made responsible, for SAP licence cases.
The reason for this can be found in the separation frequently encountered between non-SAP and SAP IT organisational units. From the customer’s point of view, for whom the SAP system provides a business-critical application, this is easy to follow but from the licence management perspective it is a grey area on the map of the applications to be managed.
Understandably, licence measurement and licence purchases in the past were thus also initiated by these SAP organisational units. However, without the establishment of appropriate role concepts and processes which trigger an action, for instance in the event of employees joining or leaving the company, it is virtually impossible to create a cost-efficient position. Despite their undoubtedly profound knowledge of SAP licences, it is difficult for these organisational units to keep pace with current developments in technical possibilities.
Convergent and hyper-convergent IT infrastructures are a necessary evil for guaranteeing fail-safe performance through the use of today’s wide area networks (WANs) and supplement the increasing degree of virtualisation. However, recording the impact of the use of these structures from a licence management perspective often lies outside the relevant scope of responsibility. Under-licensing is inevitable when products dependent on the structure are used. Old software licence contracts that are based on CPU or core licence models are frequently not designed for use in virtual networks.
This can be easily ascertained by reviewing old business object contracts. Furthermore, instead of a physical server on which the software would have been used in the past, the physical server of the virtual environment must now be licensed, and this has generally been configured to be significantly larger in terms of processor cores, CPUs and processing power. Even so, this would be the lesser of two evils. Today’s virtual environments, however, encompass at least several physical servers, over which the workload is distributed in the form of a cluster. So as far as the necessity of licences is concerned, we have already moved from one physical server to a situation involving several. Yet this is still not the worst case scenario.
Worst case scenario?
Using current VMware virtualisation technology, users are also able to distribute the workload across clusters via certain functions (vMotion). Using NSX technology, via convergent and hyper-convergent infrastructures, it is even possible to cover whole data centres with a virtualisation level. The need to acquire the relevant rights of use resulting from the licensing obligation is almost impossible to manage. This has frequently not been incorporated in the business case consideration of the strategic decision to introduce structures of this kind.
Yet there is some doubt about the necessity of this situation if the IT asset management/licence management organisation is furnished with resources, expertise and competencies precisely for evaluating these scenarios in order to serve as a trusted adviser and provide advice and action. Avoiding cases of this kind is one of the reasons why an established governance structure for IT asset management is required.
Licensing models are becoming ever more complex
However, the increasing degree of complexity, in interaction with licence models and licence terms with ever more complex structures, does not only affect a manufacturer’s proprietary products as in the case of SAP. On account of the evolution of the SAP ecosystem described above resulting from the integration and use of non-SAP products, this also has an impact on other areas of licence management. As a result, organisations with a low level of maturity or a lack of governance in licence management face extensive challenges.
To create the greatest possible transparency, it is thus important for companies to identify their own cross-component use and to know on which channels users, systems, bots and other actors communicate with each other. For instance, nowadays, telemetry modules are increasingly being installed in the automotive and mechanical engineering sectors as part of the introduction of Industry 4.0 and IoT structures, where these modules report to the manufacturer with messages about upcoming maintenance or early warnings about a foreseeable probability of becoming defective.
In some cases, integration has reached such an advanced stage that the corresponding support order is generated in SAP and an engineer is sent out without this requiring any further interaction. Yet the absence of any human interaction does not mean that these scenarios are not subject to a licence. Using contract, licence, and technical knowledge it is thus important to analyse how a business case can be designed as cost-efficiently as possible and how the implementation can be mapped in conformity with the licence. In any event, the responsibility for correct licensing data lies with the customer.
The final argument in favour of involving the organisation responsible for licence management from the start of the planning stage can be seen when relevant products are deployed that are installed outside of SAP but which access SAP functions. It is necessary and important to penetrate the management consoles of the external applications or identify relevant user groups down to directory level and analyse their access rights and permissions. As a result of these developments, the introduction of a governance structure, continual involvement of the licence management organisation and constant communication between the relevant stakeholders have become indispensable steps into a future in which ensuring licence compliance is more challenging than ever before.
In addition to the tracking of any communication channels based on RFC technology between SAP and third-party systems, it is important to record and evaluate all non-RFC connections (e.g. HTTP, IDoc, IPSec, etc.) using qualitative and quantitative survey methods (e.g. documentation, system checks, etc.).
The central starting point for the system to collect information on the RFC connections and the SAP systems relevant in terms of measurement is represented ideally by a fully integrated and central administered SAP solution manager instance. If an instance of this kind does not exist, an alternative data source should be found that demonstrates a similarly centralised character. The data and information that has been collected is subsequently consolidated and then classified and prioritised according to its relevance and criticality. The systems and the connections building on them are subsequently preselected based on individual criteria for further analysis.
Continue reading by clicking on the arrow on the right side of the screen.