Stones and asphalt don’t make a road by far but you can’t drive over a plan either
With the establishment of SAP Solution Manager 7.2 and its innovative functionalities, the question arises once again as to the structuring of the content. This is because meaningful content is crucial for the usability of the innovations, and this primarily concerns the mapping of the process flows and processing routines within the framework of process management and the solution documentation. If you build a road, it has to do with stones, asphalt and a lot of people to perform the work on the one hand. If you ask an engineer, however, he will immediately comment that it is a matter of the right planning. And this can well be compared with the provision of sophisticated functions. However, there is nothing doing without the constituents of the road – unless you like driving off-road.
A similar discussion also arises when looking at a new application lifecycle management system (ALM). After all, every functional ALM needs one thing above all, namely the right content which fits the respective business activity and which all stakeholders understand. In principle, there is a consensus that meaningful process structures are required as an inherent component of solution or process documentation. After all, a technically focused view of a company’s functional repertoire may well satisfy the IT department but it does not provide any insights whatsoever into the business processes and flows. However, the creation and, above all, the maintenance of comprehensive documentation of the business activities – based on the programs, interfaces and systems used – is time-consuming and thus also costly. Nevertheless, this tool is essential for supporting comprehensive ALM functionalities such as test management, process monitoring or change management.
In this respect, the transition to SAP Solution Manager 7.2 represents a true advance. Thanks to a number of innovations, such as the branch concept, the unrestricted level definition in process management, the library approach for objects of all kinds, the integrated modeling function based on BPMN, as well as the ability to define process variants, many user requirements are fulfilled. At least theoretically. Because all these functionalities are only as good as their content, and precisely this is the weak point of the “new” SAP Solution Manager. Even if current figures verify that more and more companies are migrating to version 7.2. of SAP Solution Manager. It is questionable whether this transition will in any case then bring with it an innovation in terms of content or whether these migrations are primarily technical in nature with a prioritization of the service functions.
Three current application scenarios
This is proven by three at first glance differing discussions from our current customer projects. It is not so much a matter of the size of the company, nor the ultimate degree of progress in terms of ALM implementation. The crucial aspect is the common demand for meaningful content that not only fits the functional possibilities of the ERP systems in use but also the corporate reality of the customer processes.
- A medium-sized company with two ERP systems for largely independent companies commissioned us with building up a comprehensive documentation for future change projects and the associated test scenarios. In addition to adapting the standard SAP processes to individual flows, it was crucial to validate the historically grown programs and modifications and to check their actual utilization.
- A large international company with growth plans asked us to assess the feasibility and implementation of its planned ALM concept. This was not only to be based on an integrative documentation concept but also to take account of the heterogeneous documentation stock collected over the years. Here too, we were of the opinion that the actual usage of the system should be the focus of attention and thus must define the scope and degree of the implementation.
- In the UK, we were commissioned with expediting the ALM-supported harmonization and standardization in a corporate group. For this rollout, we recommended the usage-based comparison with the aid of process templates, based on comprehensive analysis of the process identification, configuration validation and the identification of exceptions.
It is clear that the crucial demand for meaningful content was to be found in all customer scenarios. Sound standards, comprehensive functional templates, interdisciplinary project experience as well as application-specific analysis tools are required in order to create this.
Functionality versus content
Against this backdrop, we have already been concerning ourselves with the question as to what appropriate process content has to look like and how it can be developed meaningfully and affordably, especially with regard to future maintenance. In spite of all differences to be found from company to company, the structure of process content itself is based on very similar issues:
- What process steps are involved in a process?
- What programs and objects are used in a process?
- How often are these executables used at all and in what context?
- How many users are active in a process?
- How many documents or data records are generated and processed in the various processes?
- What organizational or regional differences are there?
- What process variants exist and what differentiates them?
- On what configuration are the processes based?
- What exceptions and errors arise?
What is above all needed in order to find answers to these questions is a comprehensive information basis. It is not sufficient, however, to rely exclusively on the rather subjective experiences of the employees. While playing a decisive role in any process documentation project, they represent only one possible source of input. A comprehensive analysis of all process determinants must take account of all aspects that characterize a business process.
Against the background of these process determinants, it seems far from easy to define well-founded documentation content for an ALM environment. Once again, it shows in this context that its restricted view of a company’s process world cannot meet the set requirements, and the business context gets almost completely lost when the focus is put too one-sidedly on the executables in the form of transactions and programs. In particular in the interests of appropriately integrating existing documentation into the concept, providing the various stakeholders with a targeted view or indeed workflow on the content and in order to create clear delineations such as equivalences of processes, both globally and locally, the use of objective analytics is recommended – this being a tool that has matured in the course of hundreds of customer projects. The RBE Plus analysis products deliver precisely that, namely comprehensive system usage analyses which enable an identification and verification of process contents and thus facilitate a rapid and easy start into producing individual process documentation. A tool-oriented definition process, which allows the desired content to be transferred to the own SAP Solution Manager using existing interfaces, is of help in this context, based on the actual usage of the own SAP systems.
In summary, it can be concluded that a process documentation should meet the following guidelines, depending on the application scenario in question:
- be comprehensive and realistic,
- contain all process-relevant systems,
- be based on standard content and templates,
- be focused on the ALM objectives and utilization,
- be clearly and comprehensibly formulated, and
- open to change and easy to maintain/update.
Taking these criteria as basis, the targeted development of a “process road” is also possible for every engineer and, with the right tools, for example in the form of comprehensive system analyses, this is then also efficient and effective. Without having to worry about the changes and challenges of the future.