Integrating SAP Signavio with SAP Solution Manager Focused Build: A Practical Approach

[frankschwalb]

1. Introduction

Large-scale SAP S/4HANA transformation projects includes not only the introduction of new systems and processes but often also the extension or modernization of the existing toolchains. In complex project environments, the seamless integration of process modeling and Application Lifecycle Management (ALM) tools is increasingly critical. Since SAP Cloud ALM could not yet provide all required functionalities for complex transformation projects at the project's start, the customer preferred their existing SAP Solution Manager Focused Build environment. Rather than using the well integrated "out-of-the-box" workflow, an enhanced and customer-optimized toolchain was implemented, as previously discussed in the blog post " The Toolchain of a SAP S/4HANA Transformation”.

The existing Solution Manager landscape served multiple purposes, company-wide operations support and other ongoing  projects. This context also influenced our integration strategy.

This article describes a practical integration approach for SAP Signavio with SAP Solution Manager Focused Build using the new Business Process Model Connector for SAP Signavio Solutions. The objective is to examine a simple practical integration and collaboration of both tools in a transformation project, providing insights into the implementation procedure, specific configurations, challenges, and the added value of their combined use.

2. Project Setup and Toolchain

For this project, the existing Solution Manager Focused Build toolchain was enhanced with additional tools to meet evolving customer requirements. The core objective was to integrate new tools in a manner that supports existing processes and governance regulations while optimally fitting into the customer's Requirement-to-Deploy (R2D) process. The following tools comprise the integrated toolchain:

• Existing SAP Solution Manager 7.2 with Focused Build: Fully integrated management of software changes, including transport control to connected systems, test management, and go-live and operation and optimization functionalities. Automatic synchronization of development and test management tasks from Jira. Used to create and manage transports across the system landscape and Test and Defect Management.
• new SAP Signavio: Functions as the leading tool for process modeling and governance. Technical documentation of business processes using BPMN 2.0 models. Provides a scope framework for requirements and discussions about the target state.
• New SAP Signavio Business Process Model Connector: Transfers BPMN-based process models from Signavio to the Solution Manager Business Process Hierarchy (BPH). The latest connector version operates as a standalone cloud application on SAP Business Technology Platform (SAP BTP). Technical implementation details are outside the scope of this article.
• Existing Jira: Project management platform for structuring tasks, deadlines, and workflows. Single source of truth for all pending tasks and topics in the program, Documentation, assignment, and collaboration for task completion. Jira supports requirements management, release and project planning. 
• Existing Confluence: Central and transparent repository/information source for everything. The place to prepare and store results documents, specifications, technical designs, etc. (not the primary focus of this article).
• LeanIX: Supports architecture management. Modeling and recording of the target architecture and the roadmap
  (not the primary focus of this article).

3.   Practical Approach in the Project

3. 1 Procedure and Methods

The customer's Solution Manager had been in use for many years, with an existing solution and branch concept shared across multiple projects. Over time, the Solution Documentation (SolDoc) had become extensive and somewhat unwieldy. To simplify the project setup, a new, separate, empty solution was created specifically for this project, with no dependencies on other projects. Users requiring access to processes or documents from the legacy solution could do so by switching solutions.

Only the new solution is linked to SAP Signavio via the Business Process Model Connector for SAP Signavio Solutions. This approach enables independent operation and clear separation from other ongoing company projects. Any content available within the company or provided by SAP - such as Model Company or Best Practice content - is imported and used exclusively within Signavio.

Process modeling is performed exclusively in Signavio, which serves as the "Single Source of Truth," while Solution Manager functions solely as a repository of processes and process steps for implementation, testing, and deployment. Technical documentation is maintained exclusively in Confluence and linked to processes in Jira. For testing purposes, processes and process steps are used to store and assign test cases, with Signavio serving as the source for creating test cases and variants.

Within the organization, processes are modeled using a value chain approach, with a distinction between as-is and to-be processes. Following modeling and technical/functional release of the to-be processes, they are synchronized with Solution Manager via the Business Process Model Connector for SAP Signavio Solutions at the start of the realization phase, created in the design branch, and made available for further processing in the standard R2D process.

SAP SolDoc (Solution Documentation) and SAP Signavio use hierarchical structures to map processes, with Signavio providing the modeling environment where SAP's standard process levels (like Areas, Groups, Scenarios, Processes, Steps).  Building a 4-tier structure was also not a problem in either world. Other functions in SolDoc, such as executable files/transactions visualized in BPMN, linking business processes with technical details, etc., are handled in Signavio and do not require synchronization with SolDoc.When processes change during the project (e.g., due to new or modified requirements), a new process version (copy) is created in Signavio. Each released process version required for implementing a requirement is then manually synchronized and created in Solution Manager as a separate new version with all process steps. Process steps are created as originals. Visual diagrams are not transferred, and subprocesses are transferred as links but not actively used. Further Attributes from Signavio are currently not transferred. Since executables are not required for the R2D process and testing, this is omitted, eliminating manual post-implementation steps.

A Signavio process version is therefore stored as a version in the Solution Manager SolDoc and utilized in sprints, waves, and releases during requirements implementation. Process steps are not numbered, as this is unnecessary in Signavio and provides no added value in Solution Manager. Given the complexity and nesting of some processes, numbering Signavio activities would be impractical.

Business process modeling and changes occur exclusively in Signavio; no modifications to Signavio content are made within Solution Manager. Only the to-be processes to be implemented for specific requirements, work packages, and work items are synchronized into the design branch of Solution Manager at the start of a Realize phase, then implemented using the standard Focused Build workflow. In Signavio, processes are locked after synchronization and set to final after realization. Further changes are always implemented through new versions

3.2 Governance 

Clear organizational and technical separation of maintenance responsibilities minimizes additional effort and potential errors during tool comparison. Process changes or deletions are performed exclusively in Signavio via versioning. Direct deletion or modification options within the solution documentation are prevented.

Since this procedure was not fully established at the project's start, a deletion flag was created as a custom attribute per the connector documentation. It is used to flag deletions in Signavio within the solution documentation, enabling individual decisions about whether and how deletions can occur in the "SAP world."

Custom Field: Deletion Flag

The search model regeneration in every system is critical here. Since no changes or deletions are currently made to accepted processes, this function has not yet been used.

Role Concept and Authorizations

To prevent manual changes to Signavio processes and process steps in SolDoc, an authorization check was implemented. Changes to Signavio processes or process steps are prevented, while creation or assignment of test cases remains possible.

Only certain roles, such as Test Manager, retain the ability to create and modify manual folders and processes to establish structures outside Signavio processes.

The authorization object for Solution Documentation is SM_SDOC, which controls process documentation maintenance. Beyond the SLAN field (which restricts by solution), other fields enable further restrictions. For this project's purposes, defining the SMUDAUTHGR field was sufficient. This field enables defined authorization groups for grouping objects and attributes. Specific authorization groups can be maintained in view cluster SMUD_AUTHG using transaction SM34.

Additionally, individual solution areas can be restricted using the SBRA field, which was not currently implemented.

The SM_SDOC object is found in SAP_SM_SL_* roles and some role-specific single roles such as SAP_OST_FB_ARCHITECT, SAP_OST_FB_PROJ_M, and SAP_OST_FB_CHANGE_M.

A dedicated authorization group was created for the solution, with only test step-relevant attributes and objects added. Additional documents in SolDoc would require corresponding additions. This configuration is currently sufficient, as all process documentation is stored in Jira & Confluence.

The new authorization group is implemented in the SM_SDOC object in the SMUDAUTHGR field within a customer-specific SAP_SM_SL_* role for developers and business analysts. The solution is also entered in the SLAN field.

In addition to the solution, all relevant change control landscapes should be entered for SLAN. Consistent naming across a Solman landscape with multiple Solution Managers is recommended. The ACTV field can then control permitted activities.

Built into an SAP_SM_SL_* role for developers and business architects, users can view SolDoc structures in their solution, cannot make changes, but can create or assign test cases (and versions).

For architects and stream leads, this would require enhancement in a standard Focused Build workflow, as they also add requirements, work packages, and work items to processes. However, in this project, this was implemented via a Jira interface and could be managed using a technical interface user with required authorizations.

The straightforward authorization check for the relevant solution with described restrictions functions effectively. Unfortunately, Focused Build offers no option to restrict to FOBU projects generally. However, the SLAN object can restrict to solution and change control landscapes across many areas, which is valuable for parallel projects.

4. Advantages and Disadvantages of the Chosen Approach

Advantages

• Modern modeling environment: SAP Signavio provides a significantly more modern and professional modeling environment than solution documentation. 
• Structuring:  The SAP SolDoc structure uses a hierarchical tree that can also be structured in Signavio. (e.g 4 level for Business Area, Scenarios, Processes, and finally granular Process Steps,
• Clear ownership: Signavio leads for processes, eliminating double maintenance.
• Selective transfer: Only processes defined and completed within the scope of a realization phase are transferred to Solution Manager.
• Improved transparency: Simple version management enhances transparency and traceability of changes.
• Reduced complexity: Synchronizing process data is streamlined.
• Role separation: Signavio process consultants do not require Solution Manager access.

Disadvantages & Restrictions

• Integration effort: Initial setup and operation requires generally integration effort.
• Limited data depth: Integration depth for additional Signavio data (e.g., executables, subprocesses) is limited.
• Subprocess limitations: Subprocesses and end-to-end scenarios defined in Signavio can only be synchronized to a limited extent in solution documentation, though this is not necessary.
• Sequencing issues: Process steps in Solution Manager are not created in the correct sequence; test cases should always be created based on Signavio diagrams.
• Versioning: Growing numbers of process versions with original process steps can reduce clarity in Solution Manager and libraries.
• Manual adjustments required: Some manual adjustments in solution documentation are necessary (e.g., creating additional folders and structures for testing or storage of process-independent test cases, folder structure, authorization assignment).
• No automatic sync from the Solution Manager to Signavio once a process has been implemented.

5. Challenges and Lessons Learned

Launching the "new tool" SAP Signavio and achieving simple, meaningful integration with the "legacy"  SAP Solution Manager Focused Build via the Business Process Model Connector for SAP Signavio Solutions required substantial preparation and coordination across project teams.

The primary challenge involved merging and delineating the two tool environments. The "Single Source of Truth" principle for process modeling (Signavio) while avoiding redundant maintenance in Solution Manager proved highly effective. The consistent procedure of handling each process version independently and systematically preventing changes in Solution Manager was particularly valuable.

As in all projects, collaboration and coordination among project members is important. To-be processes modeled in Signavio during the Explore phase must be available in the relevant version in Solution Manager at the latest by the start of the Realize phase.

Limitations were evident in the Focused Build authorization model, which does not enable true project-specific separation. However, workarounds using dedicated solutions, selective roles, specific system authorizations, and systematic assignment of rights to solutions ensure necessary security and controllability.

6. Conclusion

The integration of SAP Signavio with SAP Solution Manager Focused Build via the SAP Business Process Model Connector for Signavio demonstrates a pragmatic approach to bridging modern process modeling capabilities with established ALM tooling. While the integration requires careful planning, clear governance, and specific authorization configurations, the benefits of establishing Signavio as the Single Source of Truth for process modeling while leveraging Solution Manager's mature R2D capabilities provide significant value in complex S/4HANA transformation projects.