Best Practices – SAP Documentation

Facebooktwittergoogle_pluslinkedintumblr
SAP Documentation

SAP Documentation

This is part 7 of my Best Practices in SAP PI/PO series. You can read more about the full series on best practices here.

Ever since I got familiarized with SAP XI (eleven years ago), the documentation area of SAP has truly fascinated me. 

 

However, I quickly became frustrated at the fact that people were creating repetitive documentation, without actually considering what they needed, and without looking at the issue from a developer’s perspective, or at least taking support issues into consideration. Support was actually one of the key areas that were missing.

 

Generally, when documentation is needed, a Word document has to be created and saved in the Solution Manager, in some part of the project that correlates with what you have done – you essentially need to save your data where you expect it to be.

In the world of XI 3.0 there were more requirements because there were more objects, whereas now you only have to deal with an ICO (Integrated Configuration Object) and 2 communication channels – these are responsible for your entire configuration.

Automated tools have been around for some time now. I also created some tools because I disliked the fact that the conventional way of creating documentation did not serve its purpose well – it just listed some objects, but this wasn’t of any value from the perspective of support; you basically just had a different method of updating the documentation.

For message mapping, I created a tool that allows you to to export the message mapping from PI, import it into the tool, and get the mapping done. It used to work, but nowadays it is no longer supported by newer PI systems; instead, NetWeaver Developer Studio is used, from which the mappings can be exported as Excel files.

If you wish to document your full landscape, then the best tool I’d recommend is UDO from Arianim. UDO is a tool that connects to the PI system, downloads all the content, and enables you to see what is happening; the entire content is searchable. The tool can be found here: http://www.arianim.com/products/

For your organization, you need to find the right level of documentation in order to achieve success. Whatever is happening, it should be easy to find. Just imagine that you’re doing support somewhere around 3 a.m. – something is not working, and you’re the one who is supposed to fix the issue. You have to find a solution – that’s the kind of information you want in your document.

But let’s say you’re doing support at 8 p.m. and you are facing a strange situation: something’s not working; as soon as you check, you arrive at the conclusion that you must come up with a way of fixing the problem at hand. You need more information about the process, about what you are able to do in certain situations; however, this is more complex than stating that you should do this one particular thing in this one particular case.

Most importantly, the document should not contain too much information, just the vital elements you need. The more you add to it, the more you have to update.

I created some templates just to give you an idea of what’s supposed to be in the documentation. You can find these templates in my SAP PI course. They come as a bonus to the course, and they contain all the necessary information about what needs to be put into the documentation.

For directory objects, using scenarios is of the utmost importance. Scenarios should be named after the real business scenario that is used. This way, it will be easier to find all the different objects, and doing the documentation will also become simpler. You will be able to say “we’re using all the updates in this folder, so just have a look at those”.

I believe these are the most important aspects of SAP PI documentation. Just consider the 3 use cases we discussed: the late-night support, updating, or just trying to figure out what is happening.

Documentation is a part of the regulatory process. Some organizations may require more documentation because it makes sense for their business; you also have to prove that you have created the documentation.

What are your thoughts on SAP documentation? How much information do you like to put into your documentation? Share your opinions in the comments section!

For my previous posts in the Best Practices series, click on the links below:

 

Part 1: http://picourse.com/best-practices-reasons-behind-the-concept/

Part 2: http://picourse.com/the-concept-of-best-practices-is-dead/

Part 3: http://picourse.com/best-practices-naming-conventions/

Part 4: http://picourse.com/best-practices-mapping/   

Part 5: http://picourse.com/best-practice-skills-for-sap-popi-integration/

Part 6: http://picourse.com/best-practices-development-patterns/

 

Facebooktwittergoogle_pluslinkedintumblr

Comments are closed.