25. User documentation? If you’re going to do it, do it right: Value-enhancing user documentation – an overall concept

Abstract: There is great potential for companies in increasing the value of user documentation. A comprehensive overall concept can help to increase the effectiveness of documentation and thus boost user productivity.

 

After more than 25 years of consulting and project management in SAP projects, I have come to the conclusion that ERP implementation projects must focus on the final results from the very beginning, ensuring efficient operation of the software throughout its lifecycle.

These are essentially:

1. technical documentation of configuration and developments that is meaningful in ongoing operations and allows the operational team to track configuration and development decisions and keep them up to date in the event of subsequent adjustments, even without major effort – this is solved in most projects today through the use of the Solution Manager and/or documentation in IMG projects.
2. the creation of complete, correct and up-to-date master data and the assurance that this remains in a high-quality state during operation – this point is also given great attention in almost all projects today, and corresponding tool-supported data governance procedures are usually already introduced directly in the implementation project
3. user documentation that is not only up to date at the time of project-specific user training, but also ensures that future user generations are trained just as intensively and in depth as the user community is trained during project-specific training. UNFORTUNATELY, THIS HAS NOT BEEN SOLVED IN MANY CASES TODAY AND THEREFORE LEADS TO CONSIDERABLE CONSEQUENTIAL PROBLEMS AND COSTS:
   1. Often, users or key users create their own quick and dirty documentation because they realize that the documentation created in the project is outdated and file it in their personal folders. As a result, there are often many different documentations for the same process.
   2. But it gets worse: When new employees are trained, this is usually done by the current users/key users, who do not use the original user documentation created in the project, but their individual quick and dirty version and pass it on. This in turn is then continued by the newly trained employees and supplemented with their own individual knowledge…and so the user generation continues after user generation, which leads to the fact that on the one hand new employees are trained individually differently for the execution of the same function in the company and sometimes the same processes are processed completely differently in one department…and finally nobody knows anymore how the process execution in the project was designed and for what reasons. FINALLY THIS LEADS TO THE FACT THAT WITH EVERY NEW GENERATION OF USERS THE KNOWLEDGE OF HOW THE ERP SYSTEM WORKS IS REDUCED FURTHER AND FURTHER TO THE OPERATION OF THE SURFACE, according to the motto: “here you always have to enter this value or do that”. The sense and the use of the ERP system are thereby often led ad absurdum, the functionality of the powerful system is not used rudimentarily and thus many ERP systems wither after a few years to very expensive typewriters.
      Also, the subsequent generations of users trained in this way are often no longer able to participate meaningfully in the new introduction of an ERP system, because the interrelationships of the current system have remained completely closed to them.
   3. In addition, most projects recognize the need to document processes in order to train users accordingly across the board. In most cases, however, the process documentation within the existing business process management (BPM) system, which exists in almost all companies anyway for the necessary process certifications, is not used or built upon; instead, a separate parallel process world is created to compete with it. This redundantly created process model also frequently contributes to user confusion, which should not be underestimated, on the one hand, and frequently also leads to the fact that the handling of the processes does not correspond to the specifications defined in the BPM.
   4. It is obvious that no one can see through all the documentation and, of course, no one is motivated to keep this highly redundant collection of documentation up to date.

In order to remedy these shortcomings, I have developed the concept of value-added application documentation (link to PDF) as part of projects in recent years:

This describes a step-by-step concept by means of which you develop a state-of-the-art application documentation that is characterized by the following advantages:

1. Redundancy-free process documentation, because the process documentation of the BPM is an integral part of the concept
2. Digital application documentation created by means of an authoring tool, which can be recorded by key users to accompany the tests that take place anyway, and which can be used in various modes, ranging from paper printouts, demo and various training modes, to context-sensitive interactive support in productive operation, and can thus form the core content of computer-based training (CBTs), which can be used both for project-related training and for the subsequent induction of new employees with the same depth and quality.
3. In addition, I have received feedback from many users who have created this documentation using an authoring tool that this is not only much more effective than conventional (static file or paper-based) documentation, but that it is also really fun to create the applications using such an authoring tool and that there is corresponding motivation to keep them up-to-date without redundancies.
4. Integration of process documentation in the BPM and application documentation in the authoring tool in such a way that the process documentation in the BPM is independent of the underlying ERP (or other application system) and only the application documentation needs to be adapted when the application system is changed, but not the process documentation in the BPM. This can also make a system change, e.g. from R/3 to S/4 HANA, much easier for the users, because in each process step the current processing can be compared with the future processing – in my opinion, it can therefore be very worthwhile to first document the current R/3 processes accordingly, in order to make the changeover of the end users to S/4 HANA much easier.
5. Simultaneously applying the tests according to the Accelerated Testing Package also results in a complete update cycle for subsequent change requests (CR) including the defined re-tests and elements of the application documentation to be updated:
   1. Already in the CR it is defined which test scripts have to be re-tested or adapted within the scope of the test of the Change.
   2. Based on the adjustments in the test script, it is clear which transaction or FIORI records need to be adjusted
   3. Based on the transaction or FIORI records to be adapted, it is determined which CBTs need to be updated and also whether any adaptations are necessary in higher-level BPM processes.

   This means that when a CR is released/put into production, the respective tested overall package of application changes, including the updated documentation, can always be put live at the same time.

 

This overall concept, as well as the tools used in it, are not limited to use with SAP software, but can be used analogously step by step for all applications used in the company.

You can certainly guess what an immense contribution this can make to knowledge management in your company – start now!

There are now a number of specialized service providers who can provide competent and effective support both in the creation of such a concept and in its implementation, such as training key users in the use of the tools, support in the recording and post-processing of transaction and FIORI processes, and even in the uniform design and preparation of CBTs, and thus help to bridge any existing resource bottlenecks among the company’s own key users.

If you need advice or assistance in this regard or also with regard to the licensing of the tools used in the concept, please contact us at .

Note: The complete collection of S/4 HANA 1909 best practice process flows in BPMN2 format can be downloaded from this link in Digistore24 both in the original SAP format with vertical swimlanes and in a format converted with in horizontal swimlanes (left), e.g. to load them into your BPM as a starting point for process design (if it supports the upload of BPMN2 files).

As a BPM suite we recommend SIGNAVIO, as it was recently acquired by SAP and should therefore be a safe investment; in any case SIGNAVIO is also able to import process flows in BPMN2 format into its suite.