- What are Key Figures?
- What are the common problems with technical documentation on SAP projects?
- What is the best way to manage configuration (and other) types of project documentation?
- What does this case study say about the importance of solution documentation?
I recently went through an interesting experience at a client which provided an example of another area that must be checked for those looking to troubleshoot SNP and DP and to ensure that all the bases are covered.
What I will be discussing below requires some explanation of terminology. I will be discussing Key Figures in SAP APO and categories. Key Figures are the rows that show up on the planning interface. Categories are order types and stock that publish to the Key Figure. Key Figures can be made up of categories and macros. Macros are calculations normally based on other Key Figures. It is also important to know that Key Figures are encapsulated, so it takes some effort to determine what they Key Figures are made up of.
At this client, little of the documentation of the configuration details had been performed. For this reason, I never knew that the Key Figures that the company had been using had not been changed to meet the new requirements. This means that categories that should have been added to the Key Figure had not been. This was figured out months after I had been on the project by another consultant, and it got me thinking of how deep the verification must go into APO on every project I work. One of the reasons for this is that most of those who work in this area don’t like doing documentation, and many companies don’t check documentation that is performed by their configurators. However, in addition to people forgetting what they have done, people come and go on projects, and the lack of documentation in this case, and that I have witnessed in other cases, ends up creating land mines for the project, because nothing is worse that something you think you know, that has in fact been changed or not been changed.
Key Figure Evaluation and Documentation
SAP has an enormous number of categories and category types, in addition to macros that can populate any macro. A single addition or subtraction of a category changes the planning result. Every project needs to have the updated Key Figure documented, even if there have been no changes to the standard Key Figures, just so the planners know what each Key Figure represents. It is in fact uncommon that no changes would be made to the Key Figure, that is categories or category groups would be changed and no macros added or adjusted. (see this post to learn more about category groups) To learn more about macros in SAP APO, see this post. I performed this work at one client, but it was over a year after the project had kicked off, and I was not on the project from the beginning.
How to Manage Project and Configuration Content
Poor documentation and poor documentation tools permeate SAP projects. This ends up costing the client quite a bit in the long run and companies do not seem to be learning from past mistakes. Poor documentation is a major reasons for project mixup, and for lack of transparency on the project. Secondly, the main configuration individuals on the project are often too overloaded and are not naturally interested in documentation. Most companies do not recognize that not every system’s person is good at documenting, and should do more to provide technical writers to their implementation team. Asking the technical resources to try harder and coming up with a new template for them to use is not the answer. Finally, the content management solution (often SharePoint) and document selection (Microsoft Word) are not good methods for creating and maintaining project documentation. SharePoint is essentially a file management system which encapsulates documents and most people disdain using. Word promotes the creation of long documents that require the individual to search through to find the information they are looking for. The fact is that Word was never designed to form the basis of content management system. Both SharePoint and Word promote the development of “dead documents” that are not updated and fall out of consistency with the project state and configuration. I have had much more success using WordPress, which is blog, site and content management software which is mostly free. I have created blogs which have increased the transparency on the projects I have created them for significantly. Word 2007 and 2010 can publish directly to a WordPress blog, so companies can, with some effort, convert all of their Word documents to become part of a WordPress blog. There is knowledge required to determine how many blogs to create for the project, the tagging and categories to be applied, and this requires a person experienced in this technology and in content origination. However this easily pays off in the improvement in efficiency of the entire implementing team, and in the improvement in the ability to transfer knowledge to the system users. I know this from both the public supply chain blogs/sites I have created and for those I have created for clients in the course of consulting work.
There are so many changes that project managers and executive decision makers can do to increase the effectiveness of their projects. However, so I generally see the same ineffective techniques applied at company after company without much questioning as to whether there are better ways to improve everyone’s understanding of the solution.