Solution Documentation and Hana Readiness

By far not all customers are using the Solution Manager scenarios to their full extent yet. However, those who have the solution documentation in use are having a hard time with the necessary conversions.

Those who already listened to SAP's warnings two years ago and the future wave of conversions are fine. For everyone else, it means redesigning and adapting structures.

There are different scenarios. The scope of the investment, but also the result is closely related.

The simplest variant is to adopt the existing structures as part of the upgrade. However, this is particularly not expedient if a document was created in the past as a Business Blueprint for all processes in the MM module.

Ultimately, everything should be modeled at the process step level in the future and not in a module-oriented view.

For some of my users, it is already a great challenge to carry out modeling at the process level or to document it. With a few exceptions, this is a challenge that IT alone cannot meet.

The approach of migrating documents to a file system repository or even checking them into Sharepoint because it's so easy and wonderfully "collaborative" there is the worst approach you can take strategically.

Many users are not yet aware of what the S/4 migration means.

SAP always makes it clear that this is a new SAP launch, a new product. It cannot be compared with a familiar release upgrade, where an interface was new now and then, but on the whole it was possible to continue working as before.

It is precisely this challenge that leads to the fact that an SAP user must first analyze and record his processes anyway and, in a second step, match them with the scopes delivered in S/4 Hana.

As with a new implementation, the effort and business value must then also be considered and assessed here. Although S/4 Hana is not yet necessarily on the doorstep of the IT manager, it is getting closer.

Therefore, there is no better start than to invest now in good and appropriate process documentation. SolMan 7.2 was deliberately prepared by SAP to provide enterprise support customers with a good process modeling tool.

In addition, a good tool for documentation is now sensibly specified in both directions - from the technology and implementation and also from the process perspective.

With the changeover, solution documentation - as it should be - is also a fundamental part of the change management process in SolMan. Technical changes are always linked to documentation changes and set "productive" together.

On the one hand as a technical object in the productive system, but in parallel also as documentation.

This form of seamless integration has been demanded by customers for years. I find it regrettable that it is often precisely these SAP users who now complain about the integration and lament that it can no longer be used for post-documentation after going live.

It is relatively easy to counter this with the fact that in practical life, an IT employee does not post-document anything after a go-live, but is already working on the next problem or the next project.

The form of tool integration or Swiss Army Knife alone shows that a sharepoint or file repository cannot provide this integration at all.

This continues with topics such as project or test management as well as the necessary cost and activity allocation. Whenever an SAP user opts for external tools here, the decision is also made for a costly interface or a significant loss of functionality.

All in all, SAP has provided excellent tools with SolMan 7.2, which can be used wonderfully as preparation for the S/4 changeover.

The challenge lies in also making the necessary investments and integrating the necessary people into such a preparatory project. A first step is to take the solution documentation - if it already exists - into the new SolMan 7.2 structure in a meaningful way and not to "throw it away" in a file repository.