Recently I watched Senior VP SCN Mark Yolton's discussions (you can watch it here: http://siliconangle.tv/video/mark-yolton-sap-sapphire-2011) on SCN. If you would like to understand what SCN is about, that video is worth watching. In less than 30 minutes, he eloquently explains almost all important and critical aspects of SCN.
In that video, he discusses Social Innovation. As a part of that (timeline in that video from 10:13 to 10.31, for 18 seconds), he explains SAP would like customers help them improve the quality of documentation. It is a great idea. It follows the simple principle that nothing is perfect and that there is room for improvement in everything we do. By seeking customer's help to improve the quality of SAP documentation, SAP demonstrates their commitment to improve the quality of everything they do.
Now let me discuss a few documentation related challenges - that are not in customer's control - impacting the quality of documentation.
Documentation in my opinion can come in several forms and shapes. For example, a person who has been working in SAP would probably immediately understand what "SAPKB70107" means. He/she doesn't need a document to understand the meaning. The meaning/description is implicit based on naming standards followed by SAP. Naming standards would also be easy to teach to those who're new to SAP. In contrast, if I mention SAPHOSTAGENT 75-20003746.SAR, can anyone derive the version/release information from that? I doubt. I can give several examples but the point is why SAP isn't following easy-to-understand naming standards for all products.
Second challenge is with Unicode versus Non-Unicode. Why SAP in some cases releases either Unicode or non-Unicode only products and ask customers to use unicode or non-Unicode versions regardless of whether their system is Unicode or non-Unicode. Instead why SAP doesn't release Code-Independent versions (for kernel, there is a category called DB-Independent. They can follow similar structure for Unicode/Non-Unicode/Code-Independent). This would help both customers and SAP Global Support.
What I mean by Top-Down Approach:
As customers begin updating the documentation based on Social Innovation approach, they would hopefully begin uncovering lower level issues such as the ones listed above. This approach looks like "Top-Down" methodology. I'm wondering instead of top-down approach, would bottom-up approach be more efficient? I see there is room for improvement in four areas:
1) SAP Software Download Center
- This page requires not only overhaul but also continuous monitoring/maintenance. It seems this is maintained by several groups. As a result, I find it very difficult to locate what I'm looking for. I'll provide more details in next blog.
2) Inline Documentation for SAP programs
- SMIGR_CREATE_DDL is very important program for BW based systems. This program is used during system copy and Unicode conversion to retain special DDL features used in BW systems. Recently we upgraded our system to EhP1, ran SMIGR_CREATE_DDL and then performed Unicode Conversion. Shockingly the developers removed very important feature(backbone of the program?) in newer version of SMIGR_CREATE_DDL. As a result, we ran into serious issues. Please read this blog for details:What can skills combo do for you?
- I don't know the root cause why that bug was introduced but I suspect the program lacked inline documentation.
3) Naming Standards
- As I explained already, naming standards would really be helpful.
4) Training
- Whatever developers mention or don't mention in the log might cause a high level of confusion to everyone who uses SAP. Recently I experienced it hard-way. EhP installer log stated "UNICODE" version. However our BW system was Non_Unicode version. I had to explain more than once (including to SAP Global Support) that we were using correct version of EhPi. Could they be trained to add useful comments/information in the logs?
