Keeping the end-user documentation up-to-date in a SAP Support Environment is a challenge which many find difficult to address. It requires specialized set of skills and dedicated effort.
In my Post Go-Live Knowledge Management blog, I described the steps to set-up & execute the KM strategy. In this blog I have explained the steps to develop an effective user guide which can help its audience in understanding the subject and doing their jobs better.
Before you read it further, let me clarify it’s not only about the procedures that an end-user has to follow to complete an activity, it’s also about its context. For general tips on technical writing, please read From a User “Misguide” to a “Guide” and to learn specific tips on developing the training material to reduce support cost continue reading this blog. So without further ado, here is the detail.
The first page of the user guide is as important as the rest of the document. It has to have certain information such as the
The benefit of having such details is to let the person know if or not the document is of any relevance to him/her. Another thing which can, actually should, be added is a simple statement saying what the document covers and in case of facing any difficulty who should be contacted.
Providing the history of a document can tell a user if it’s a right reference. Usually when a Solution is built and documented, the instructions are clear. Over time, with implementation of Change Requests by internal and external teams, it is possible that respective document isn’t updated. Let’s assume, a productive solution requires implementation of an additional feature. It’s delivered by a Contractor who also provides the written steps on using the functionality. In such a scenario, the original solution implemented earlier and the latest feature implemented recently, have the required documentation. What is missing in this case is a comprehensive guide which covers everything related to particular business process. It can be controlled by maintaining versions of same document. Here is the how.
For instance, the version 1 was developed by System Integrator who delivered the solution, and the version 2 by a Contractor who implemented additional feature. Let’s say the document was reviewed and approved by the Module Consultant and Practice Manager of SAP Customer COE. Now if an end-user looks at the single source of truth, s/he will not be confused.
Since the document is meant to guide an end-user with performing everything correctly, it has to be structured well. Following sections can help in achieving that;
By having such structured documentation, the system users can be guided to the right resources whenever they approach helpdesk for assistance. It can help the Technical Support Team in focusing on resolving Issues & Problems of higher priority or of more value.
While it’s not a guarantee that having such content can cut the support cost completely but it can certainly help the end-users and support staff in performing better at their jobs.
What do you think? Do you see some value in having documentation well-maintained? Please share your thoughts.
In my Post Go-Live Knowledge Management blog, I described the steps to set-up & execute the KM strategy. In this blog I have explained the steps to develop an effective user guide which can help its audience in understanding the subject and doing their jobs better.
Before you read it further, let me clarify it’s not only about the procedures that an end-user has to follow to complete an activity, it’s also about its context. For general tips on technical writing, please read From a User “Misguide” to a “Guide” and to learn specific tips on developing the training material to reduce support cost continue reading this blog. So without further ado, here is the detail.
Document Title
The first page of the user guide is as important as the rest of the document. It has to have certain information such as the
- Process Name in business terms,
- Business Function (and Corresponding SAP Solution), such as Procurement (SAP SRM),
The benefit of having such details is to let the person know if or not the document is of any relevance to him/her. Another thing which can, actually should, be added is a simple statement saying what the document covers and in case of facing any difficulty who should be contacted.
Versioning Details
Providing the history of a document can tell a user if it’s a right reference. Usually when a Solution is built and documented, the instructions are clear. Over time, with implementation of Change Requests by internal and external teams, it is possible that respective document isn’t updated. Let’s assume, a productive solution requires implementation of an additional feature. It’s delivered by a Contractor who also provides the written steps on using the functionality. In such a scenario, the original solution implemented earlier and the latest feature implemented recently, have the required documentation. What is missing in this case is a comprehensive guide which covers everything related to particular business process. It can be controlled by maintaining versions of same document. Here is the how.
- History, providing the Document Version Number, Date of Issue, and Author
- Review and Approval, providing details if the document is endorsed by right people.
For instance, the version 1 was developed by System Integrator who delivered the solution, and the version 2 by a Contractor who implemented additional feature. Let’s say the document was reviewed and approved by the Module Consultant and Practice Manager of SAP Customer COE. Now if an end-user looks at the single source of truth, s/he will not be confused.
Document Content
Since the document is meant to guide an end-user with performing everything correctly, it has to be structured well. Following sections can help in achieving that;
- Overview, providing a quick summary of what the document is all about,
- Purpose, explaining the reasons, such as doing certain tasks,
- Scope, describing what is included and excluded from the document,
- Roles, guiding the user if it is intended for the role s/he has,
- Terminologies, defining the technical terms used throughout the process document,
- Procedures, mentioning the steps of completing the activities within the process in scope,
- Resources, referring to additional useful documentation, if there’s any,
- Process Flow, stating where the role of the user and the activity s/he does fits in overall process.
By having such structured documentation, the system users can be guided to the right resources whenever they approach helpdesk for assistance. It can help the Technical Support Team in focusing on resolving Issues & Problems of higher priority or of more value.
If you are using MS Word to prepare the documents, you can also create table of contents by changing the formatting of the text in the document i.e. marking the headings as level 1, 2, and so on, and choosing its built in feature of generating TOC.
While it’s not a guarantee that having such content can cut the support cost completely but it can certainly help the end-users and support staff in performing better at their jobs.
What do you think? Do you see some value in having documentation well-maintained? Please share your thoughts.
- SAP Managed Tags:
