Solution Documentation in Solution Manager 7.2: Expected changes

Solution Manager 7.2 was initially scheduled to be generally available by the end of 2015 (But reportedly postponed to Q2 of 2016) and will introduce big changes. From what we could see in the previews, we get a revamped Solution Documentation. What should we expect exactly? I have tried to synthesize all the information I got from the SAP webinars, with my comments as a Solution Manager consultant.

It would be great to discuss these planned changes. However, keep in mind that this blog entry is based on previews by SAP, and that the finished product might be different.

Pragmatic Business Process Management

Solution Manager 7.2 introduces what SAP calls “Pragmatic Business Process Management”. This is a way to underscore the fact that SolMan 7.2 is more “Business Processes Oriented. 7.1 was IT/Operations focused. 7.2 will try to balance things more, increasing value for Business Processes/Implementation. The goal is to get Business Process Experts more involved… This translates into most of the following items:

Documentation before project start

With more focus on implementation and Business Processes, one major flaw needed to be addressed. In 7.1, you can’t start documenting unless you have a landscape. This means that you business process expert can’t document unless the project actually starts. For 7.2, SAP want to decouple the documentation (or at least, the modelling of processes) from the actual landscape. The link will of course need to be done later on, but at least, there will be  no need to “wait” anymore.

Graphic Business Process Modeling

We gain a business process modeling tool, adapted from Power Designer. SAP is simply using the graphic libraries, so we shouldn’t expect the functionalities of the tool. This modeling environment should be for business processes only (No enterprise architecture, no UML).

Source: SAP

Open interface to other Modelling tools

So far we had an integration with ARIS (that wasn’t made by SAP). We should be getting an open interface that will make things simpler. Bi-directional, it will be possible to use it with any tool. It won’t be part of the ramp-up (but added later).

Analytics extended to business cases

We should be able to relate business cases to KPI and thresholds from Business Processes Analytics Framework. The way to do it: We define this in implementation, store in SolMan, do our project, and in Live phase we can analyse and continuously check how well our KPI are met by the system users.

A new Documentation Lifecycle Model

Projects and Solution are two similar concepts for Solution Documentation in SolMan 7.1.

To document in Solution Manager, you will need to create a Project.

Let’s say you are starting an implementation, but will shift to maintenance after go-live. Then, the proposed model is as follows:

Source: SAP

So, you need to create an implementation project and document. This can be made from scratch, or using  “templates”. Once your project goes live, you need to transfer your documentation to a productive “Solution”, and then create a maintenance project. This maintenance project will be used for documenting your changes to the productive environment.

You end up with documents in double or triple, with different versions. You need to use the “compare and adjust” functionality…

As if this is not enough, projects and Solutions share a lot, but have a few specificities that make both of them necessary. So you should maintain both.

Solution Manager 7.2 will remove this issue by introducing one common directory for Business Process documentation. Projects and Solution are unified. New concepts are introduced. Old ones are rendered obsolete.

No more Reverse Business Process Documentation

We could see this coming. RBPD, or Reverse Business Processing Documentation, is a great functionality of 7.1. It helps you jumpstart your documentation in the less painful way possible. Instead of manually creating your process steps/ Business Processes and Scenarios, or having to choose them in the very dense BPR (Business Process repository), RBPD creates for you, based on your system usage, an almost ready to use Business Process Structure.

The disappearance of RBPD could be foreshadowed with the introduction of SEA, who also creates a ready to use business process structure for you (because SEA needs one). Or, even more so, with the introduction, with note 2061626, of the Blueprint Generator (used by SEA) as a separate functionality. The blueprint generator/SEA analyzes your system usage and create a Solution Documentation Project that contains all transactions and reports structured by the Application Component Hierarchy comparable to what you can already see in the IMG. Objects that are not standard are listed at the end, under “Customer objects”, and it is your responsibility to affect them to the right process step. This blueprint generator becomes standard tool to generate blueprints, and will be used by Solution Documentation.

And no more BPR

It gets replaced by the RDS Content.

A new architecture

New concepts are introduced by 7.2. Layers of libraries are now used to avoid redundancy of objects.

They are of 3 types:

Source:SAP

Objects will be in the TOL only if used, with only one occurrence, and structured according to the application component hierarchy.

The PSL will also be created automatically based on usage. Multiple occurrences (of technical objects) will be allowed.

Process Step Library and Technical Object Library are available by system. E2E business process will be used to document across systems.

The creation of the E2E should be simple (you pull steps from the individual systems in the E2E library) but not required, as the TOL & PSL are enough to work with SolDoc. You can start testing as soon as SolMan is set up.

No more Solar Transactions

If you are somehow familiar with Solution Documentation, then you must know about the SOLAR Transactions. They are used to create, manage and do some reporting on your documentation project.

Those transactions are the heart of solution documentation in SolMan 7.1, and simply disappear in 7.2.

We gain instead, it seems, two mains views: The Solution Landscape UI, and the Solution Documentation UI.

Business Process Hierarchy with unlimited levels

In 7.1, you document with a 3 levels hierarchy: Scenarios, Business Process and Process Steps.

Without Solar transactions anymore, it’s no surprise that the way structures are represented will change considerably. Instead of this 3 levels structure, we are getting boxes representing levels, and the possibility to have as many levels as we want. However, the 3 levels are still there, and will be the core of the documentation. We will simply be able to add as many levels as we want on top of them. This will be very close to the workaround used right now, which consists on coding levels through naming convention (combining levels in Scenarios names, for example).

Lifecycle based on Branches

Among the new concepts introduced, the “branches” hold a significant place. If you want a simple definition for a branch, it is simply, according to SAP, a versioning context for documentation. What this means is while we don’t have the implementation/maintenance projects anymore, you will be able to maintain your different documentations without affecting the one that is productive. It’s based on views that contains only pre selected processes.

Source: SAP

Integration with ChaRM

You have a change document open for some maintenance in your system, tracking your changes. The corresponding documentation is in the maintenance branch of your documentation. When your ticket is productive, you will simply need to make your maintenance documentation productive. And apparently, this is done automatically. So, 7.2 adds a new layer of SolDoc/ChaRM integration, which is great.

Source: SAP

Requirement management

SAP introduces requirement management in Solution Documentation, and in ChaRM. This will be particularly interesting for ChaRM, as It seems we are getting new transactions types for IT and Business Requirements. A workaround so far had been to adapt some of the standard transaction to allow requirement management using some specific statuses.

Logical component group

They get introduced to make logical components management easier and avoid redundancy of documentation. We should end up with much fewer logical components.

This is what I got for the previews. I will update my blog post or create a new one once I get access to SolMan 7.2.

The SAP Solution Documentation webinar can be found here:

https://service.sap.com/sap/bc/bsp/spn/esa_redirect/index.htm?gotocourse=X&courseid=70283905

Some additional information in thewebinar on Solution Manager 7.2:

https://service.sap.com/sap/bc/bsp/spn/esa_redirect/index.htm?gotocourse=X&courseid=70275220