What doesn’t fit is made to fit, or documentation of non-ERP systems
Over the past 15 years, there has been a steady penetration of SAP non-ERP systems into system landscapes. What is surprising above all is the variety of the products implemented. Whether it is production shop floor support, customer relationship management, purchasing management or expanded, fully automated warehouse management – possibilities are truly endless. Many attempts to return to the ERP core – e.g. some sector solutions – have been successful. However, if not before, acquisitions in the Cloud area since 2012 have once again increased the number of non-ERP solutions.
In this case, using these “value-added systems” is entirely justified, of course. The type and method of integration, on the other hand is somewhat more complicated. A first step could be SAP non-ERP systems which, ideally, should be compatible with the ERP system of the same manufacturer. So far, so good. However, does this answer every question and also represent every process seamlessly and understandably?
What doesn’t fit is made to fit
There are projects in which people gather round a table to peer at a printout the size of a poster, or look in astonishment at an Excel spreadsheet with rows and columns that are more reminiscent of a cutting pattern than an understandable system overview. However, the amusement usually ends when it becomes clear that the intention is to analyze and document the corresponding company processes showing how this landscape has evolved. Or even improve them.
Up to this point, the attempt has been made to apply the classic philosophy for work on construction sites: What doesn’t fit will be made to fit. Translated into the language of IT, this may well be interpreted as “the process will be tidied up in the course of standardization”.
However, the high level of diversification in these constellations may be entirely justified. Many system landscapes also have a correspondingly high standardization potential – because many upgrades are only carried out for purely technical aspects in any case rather than taking account of the functional innovations – but nevertheless, it would be Utopian to assume that customers’ systems can be standardized to 100%. The question remains, how can these processes be investigated in a targeted way and made to lend themselves to investigation? On a level that can be understood in terms of content and can be used by the IT service processes that are based on them – from test management to Charm?
Below, we will present several examples showing how this can be achieved.
> Example 1: Process analysis of the SAP CRM and SAP EWM systems of a German SME
The task in the stated project was to prepare for upcoming test management activities by creating a comprehensive solution documentation and implementing it in SAP Solution Manager 7.1. As with all documentation projects of this kind, the first step focused on a detailed analysis of the systems involved and processes used. It should be noted in this case that SAP non-ERP systems differ significantly on technical level from the common ERP systems and their ABAP stacks. For example the most important components of SAP Customer Relationship Management (SAP CRM) and SAP Supplier Relationship Management (SAP SRM) systems are web-based, which means it is not possible to track their use in the conventional way using system logs. Specifically, this means that a transactional evaluation is bound to fail, for example because a CRM Interaction Center only appears with configuration transactions. For a user focusing on Interaction Centers, this would be entirely inadequate.
An SAP Extended Warehouse Management System (SAP EWM), on the other hand, may well be identified using its typical transactions. As far as assessing the content of the company processes is concerned, it goes without saying that the way in which these specific aspects work must be known, just as much as the customer-specific possibilities for using them. This applies in particular against the backdrop of “overlapping” processes which are not dealt with encapsulated in one system but rather in several systems.
To sum up: Attempts to achieve system transparency are significantly hampered by the diversity of SAP systems. Only someone who knows the technical components of the SAP non-ERP systems will really be able to judge how they are used.
> Example 2: Integration analysis of cross-system processes at an energy company
The tasks of the first project to be presented provide a consistent indication of the subsequent objective. On behalf of a well known US energy company, we were tasked with creating an integrated and usage-based process documentation showing the connections between a classic SAP ERP system and a non-ERP system (SAP CRM). In additional to the local business transactions which are normally considered, it was also necessary to clarify the step-by-step handling of global, cross-system application processes.
This requirement is typical of SAP non-ERP systems. After all, it is in the nature of bolt-on systems for them to be connected to ERP systems so as to expand the content of certain processes, whether it be having to access the same database or because their functions supplement existing processes. The contents and systems can be synchronized in an extremely diverse range of ways. Accordingly, it becomes necessary to investigate the system-side communication via interfaces and exchange files. Only in this way can the actual process use be detected and assessed with regard to its interactions.
To sum up: Integrated, cross-system processes must be considered against the backdrop of their synchronization. At the same time, this is subject to quite similar rules to those which apply to the isolated consideration of SAP non-ERP systems – it is only possible to do full justice to a process if you take account of its specific technical aspects as well as the step-by-step processing of content.
Only someone who understands the special aspects of these systems and takes account of these aspects in the course of project management will be able to assess and document the process usage. Irrespective of which constituents belong to a system landscape and how they are linked to one another in terms of content at process level. Without having to resort to the classic approach on the construction site – what doesn’t fit is made to fit.