Post Go-Live Knowledge Management
One of the issues which many businesses have, after going live with SAP (or for that matter any other IT) Solution, is keeping the end-user documentation up-to-date.
The solution delivery comes with the required training content but as time passes by the gap between the solution and related instructions to use it widens, due to the changes in the original design. The change in business requires corresponding technology solutions to accommodate new scenarios and therefore Change Requests are raised by relevant business functions and implemented by their counterparts in IT support.
Mismatch between instructions and actual steps of using the solution
In absence of a dedicated knowledge management role/team/repository, chances are quite high to omit the need to update/create & maintain the end-user training material. The result is unpleasant; when an end-user tries to follow the instructions, to complete certain process in the system, stated in the respective guide, s/he finds it misleading.
Read From a User “Misguide” to a “Guide” for few tips on writing effective instructions.
There’s a problem and it can’t be fixed by finger pointing; instead of focusing on “who was supposed to do” and “why it wasn’t done” type of questions, it could be solved somehow. The “how” is what I’ve figured out and I’m writing it here to
- share what I think is one way to solve the problem, and
- get your opinion if the approach is good or needs more steps to follow.
Knowledge Management and Change Management
As a Change Manager, working with SAP Support and helping business teams in adopting SAP based solutions for their day-to-day transactions, I also regularly seek feedback on the applications in use and the technical support being provided. The response I receive varies from time to time, however, a common concern shown by almost everyone using the system, in any capacity, is about lack of (complete) procedures on completing tasks.
“What steps are needed (and in which sequence) to address such an issue?” was a question bothering me for quite some time and I was thinking for possible solutions. When Former Member mentioned the subject again, 2 months ago, in response to my earlier blog Change Management Lessons Learned in a Year and on Different Projects, it triggered my mind not to wait for the gap to be addressed by someone else but to take it as a challenge for myself.
I started working on the idea and finally have devised the strategy to overcome this issue as well. However, since one person can’t think of all aspects, I’m describing it here to have your feedback. If you think there could be additional steps/points which are necessary to ensure the solution’s viability, please comment.
Here’s how I’ve organized the whole plan.
I’ve categorized audience in 3 different groups
- Employees, using ESS, FIORI and SuccessFactors for general and common SAP features,
- Managers, using MSS, Workflow and SuccessFactors for specific processes / approvals,
- End Users, using specific SAP components to perform particular jobs,
B. Learning Needs
In terms of learning needs of each group I could think of their ability to
- Maintain / view personal, time, travel and payment related information self-sufficiently, using ESS and FIORI
- Set performance goals, book self and subordinates in required training courses for professional development, using SF,
- Provide (time/travel/training) approvals, set goals for subordinates, and access reports to analyze data, using MSS, SF, BI etc.
- Use system transactions, independently, in the individual areas of responsibilities, using different modules.
1. Identification of User Roles per module
Each SAP module, being used by a customer, serves a particular group of processes and ultimately the roles. Such groups should be identified and listed down as a first step.
2. Organization of Processes within Roles
Each role, identified in step 1, performs certain actions in SAP system and as such complete some processes. Each of the processes should be categorized to continue with the rest of the work.
3. Gap Analysis of Individual Processes
The processes, grouped in step 2, may have gaps (if they exist), in terms of steps to complete activities in the system. The gaps should be analyzed to assess the volume of work required to update the processes.
4. Update / Creation of Documentation
The gaps, figured out in step 3, require the update of existing and creation of new user manuals. The most important aspect of such activity is to ensure that the end-users can follow the steps, precisely, to do what s/he is supposed to do in the system.
5. Communication of Updates
The documents, created in step 4, should to be circulated as soon as they are ready, without waiting for the complete project of documentation to be finished. The communication frequency may highlight its importance.
6. Maintenance of Content & Repository
The material can also be used to create course in Learning Management System, if it’s available. The benefit of doing so is to facilitate new joiners on certain roles in learning what they need to learn, without having a need to rerun the courses for
Do you think, starting the project with such steps could result better knowledge management?
I always loved the idea of the users themselves being responsible for the documentation. In old SAP - we could link it into our system->help and let them make changes.
The good thing with that is that if the user kept the documentation current, we could see what issues there were with the current process. It would show how they were working around the system.
However, they aren't any better than we are at keeping up with the documentation.
So because I write the documentation and the code. At one of my companies that was very regulated the function specifications and technical specifications had to be updated with any changes. <Sigh> that worked. But the end user documentation wasn't required. Perhaps we could add that. It just means adding time into any project.
I really I'm not sure how to keep them current. At go-live time it is really crazy. And usually the end-users do NOT look at documentation - they call.
I'll be interested to see other comments,
Thanks Michelle Crapo for your comment.
At time of going live everyone, end-users and consultants, are busy in shifting to and supporting new solution. However, after sometime (say a year later) when the solution is being used for day-to-day business, chances are quite high it not to be the same as it was at time it went live; business may have changed and so the solution. The Change Requests are raised by business teams, implemented by their colleagues in technical support, and in between required documentation is missed. Both parties don’t see the long-term value of keeping it up-to-date; the knowledge of changes remain with the user and implementer, and if a new person joins the organization s/he doesn’t know (at least completely) where to start…
I was thinking no change request should be marked completed until the related documentation is verified to be complete from all aspects. Hope we get more suggestions from others as well to know the best possible solution to such an issue.
Perfect! That will make us address the documentation when the system is stable. I like it!