Do you have documentation that you practically never use and that is no longer up to date? You are not alone on this!
My experience is that more or less all solution documentation is inadequate, full of downright errors and also that it rarely helps understand any of the design decisions that were taken to begin with. This is not a problem in simple SAP BI solutions without business logic. There are just not too many of these solutions around!
Most implementation projects spend a lot of time on preparing documentation, which therefore claims a significant part of the project budget. The documentation is extensive and thereby heavy to maintain, which quickly makes it deficient.
Finding a smarter way to do things is a must.
Typical questions when the project starts include:
- Who are the users of the documentation?
- Why is the need there?
- What are the users of the documentation familiar with already?
- Where are they looking for information?
- What should be documented?
However, before we prepare our good documentation guides, there are two questions that are at least just as important:
- How should things be documented?
- How should the documentation be published?
Most people agree that it is important to document important design choices as well as technical setup. And it is here where the typical challenge lies when it comes to deficient documentation. A SAP BW system allows you to create tables and define fields, i.e. at a completely different level than what is done in SAP ECC (which is where the documentation guide is inherited from). This significantly raises the documentation load and shifts the developer’s focus from “why” / “why not” to copying definitions from outside the system.
This suddenly leaves us with documentation that is heavy to maintain and is more or less never correctly updated. As a result of the heavy workload associated with copying definitions, the reason for the solution design is de-emphasised or disappears completely.
Wouldn’t it be smart if all documentation were handled automatically?
Most people agree on this – and this is actually done in SAP BW in the Metadata Repository. However, the standard solution is not good enough at handling changes and not good at all at relating these to change requests.
To gain actual value, you must be able to link changes in the documentation to change requests in a “before” and “after” image. And this is actually possible!
In my time as a consultant, I have seen a lot of documentation which, in my opinion, does not create sufficient value. Fortunately, this is over now. Innologic has extended the Metadata Repository so that objects which are transported are saved as a “before” and “after” image, and the “after” image is also stamped with the change request number. It is that easy to do it!
This allows you to see the “before” and “after” definition of an object for all change requests the object is part of. So now it is possible to create statistics of how many times an object has been changed or how many changes are made to individual solutions.
This saves you a lot of time and produces usable documentation:
- Less documentation review in cases where there are only technical updates.
- The technical documentation is always available where it is used – in the system
- The technical documentation is always updated and is therefore correct
- It is possible to prepare statistics of changes of objects and solutions
- Design decisions are documented better
Projects get even cheaper, and the solution takes away the focus from copying/pasting documentation, which makes it possible for you to spend your energy on knowledge that is important – namely on documenting design decisions that are not visible in the system.
If you are interested in hearing more about how this works in practice, contact Innologic at +45 31 63 41 00 or firstname.lastname@example.org