Skip to Content

In Karthik SJ‘s insightful – but coy 😉 – blog about the problems of coordinating a common view of an enterprise’s business process Lost in Translation: Business to IT, a passage about the shortcomings of the existing tools available bears a second look.

“The exercise [in documenting existing business processes] not only proves to be time-intensive but produces inaccurate and duplicate content. After several interviews and workshops, the business ends up with a number of processes that are captured and documented a number of times without any consistency or re-use. Besides this, the Business finds it is a major challenge to maintain, synchronize and govern content across the plethora of tools used by analysts.”

While reading that I was reminded of the case for the widespread adoption of SAP Solution Manager and the promise to “provide a single version of the truth”, one place where all landscape description, business processes designs, documentation and test validation can be stored.

For sure, when it comes to documenting business processes, SAP Solution Manager is not the easiest tool to use, but it does have a couple of unique advantages over other tools: it is aligned to business processes as have been defined by SAP and therefore provides a common structure for mutualised support teams; further, it has direct links into all SAP systems, providing a layer of meta-information that enriches and supplements the business process understanding. Where SAP Solution Manager falls down with respect to displaying business processes is with the graphics tab, that allows neither gateways nor an integrated representation of interfaces into the business process. Graphical representation of a process flow is really non-negotiable when it comes to sharing and understanding a previously unseen business process to a new audience.

The absence of a gateway construct is immediately apparent as a limitation, hence the popularity of incorporating tools like ARIS. The challenge of documenting interfaces “the Solution Manager Way” however, are more problematical to explain. This blog is about suggesting ways to meet that challenge. Detailed information on the Solution Manager approach can be found in the SDN article Interface Documentation with SAP Solution Manager. Summarizing the main issue in the Figure 1 below, the left hierarchy represents the business structure, and the right hierarchy represents the structuring of interface information, added to SAP Solution Manager 7.0 since ST SP15 /18 and STSER2008_1.

image

Figure 1: Side-by-side representation of business and interface hierarchies showing the point of interface assignment between two steps.

By way of visual orientation, Figure 2 shows both hierarchies on the left, and the graphical representation of these steps (in the Graphics tab) on the right.

image

Figure 2: Solution Manager Graphic Tab showing linking to business process and interface hierarchies.

There are good and bad parts of the current approach. The good thing about the SAP Solution Manager interface hierarchy is that it provides an almost identical symmetry for mapping between the two sets of hierarchical information. This makes for easier “bolting-on” additional interface-specific attributes to document interfaces for a business process (think: a place for everything and everything in its place). Unfortunately, it has the drawbacks that visually the interface assignment between process steps carries no additional information other than a simple icon indicating that further information is held in the interface hierarchy. It doesn’t even have a name in the graphical diagram. To locate the additional interface information, there is a dependence on a cumbersome cross-referencing process with the interface scenario and adherence to a consistent naming convention.

Lastly, interface specific objects (e.g. ALE function modules etc) can’t be documented in the interface hierarchy. Although they can be mentioned in the interface step attributes, but then special provision has to be remembered to be made in the business process step. Unless that is done, testing management will be incomplete. If it is done, then the business process model becomes very technical indeed, defeating the advantage of having all the information in the separate interface hierarchy!

The solution for SAP to the gateway and interface problems is obvious: to provide a graphical BPMN layer on top of the business process structure in SAP Solution Manager. Such as solution was demonstrated at TechEd ’10 in Berlin and Las Vegas by Wulff-Heinrich Knapp as part of the Business Process Library (BPL) toolset.

Less clear however, is how best to incorporate and represent the message flows between two systems. This blog is about suggesting how interfaces in SAP Solution Manager can be shown accurately in a BPMN modelling tool. Remember that whatever is proposed here must not require changes to the functionality of SAP Solution Manager, while nevertheless providing a framework for enforcing best practice as there is flexibility and ambiguity in how Interface Scenarios are represented for different business processes and types of interfaces. A very good exposition of this can be found in How to Use Interface-Documentation on SAP Solution Manager.

This last reason is why the simplest representation of SAP Solution Manager in a BPMN modelling tool (continuing the separation between interface hierarchies and business process hierarchies) has in some way to be masked or encapsulated in a more coherent and visibly useful form.

 

Mapping a BPMN modelling tool onto Solution Manager Interface hierarchy.

A common artifice for structuring documentation in SAP Solution Manager is the use of a dummy process labelled as a divider e.g. “——–Process 1 ——-” which is a null process without any steps, and only serves to separate one group of processes from another within the same scenario.  This doesn’t map very well to a visual display of the interfaces described in a hierarchy, without generating all sorts of problems. The only way I can see around this is to co-opt the scenario level to become more than a thematic division, and represent either (a) group of interfaces within a process, or (b) all interfaces between two different systems. Lets investigate the pros and cons of each approach.

 

A) Interfaces Scenarios map to a process

Interface Scenario = “BPMN model X”
Pros
  • All message flows listed within a particular business processes
  • Allows unique naming/alignment of message flows between business processes/interface  scenarios
Cons
  • Does not promote re-use of interfaces between business processes

 

B) Interface Scenarios are between logical components

Interface Scenario = “System A -> System B”
Pros
  • Message flows listed across all business processes and business scenarios
  • Promotes re-use of interfaces
Cons
  • Observance of unique naming required across business processes

 

Mapping BPMN interface steps onto Solution Manager Business Process hierarchy.

There now follows three alternatives for representing steps in a process described by BPMN so that Solution Manager can act a back-end repository with corresponding steps.

 

Option1) Using throw/catch events without modelling send/receive steps

image

Message flows between throw/catch intermediate events make the process very clear in BPMN, but these events would not normally appear as business process steps in SAP Solution Manager. This option would be useful for when there are no objects to document separately the send/receive steps.

Option 2) Message flows between send/receive steps.

image
The step ornament would make the throw/catch events unnecessary. Steps for send/receive would be documented in the business step level, allowing for creation of test cases.

Option 3) Use of Data Objects to provide a business step for documenting interface objects

image

The Data Object artefact would appear as business process step associated with message flow to handling objects used in interface. This could be allowed under the bpm.org specification for BPMN 2.0 because “Data Objects provide information about what activities required to be performed”. Also, annotation of message flows is now allowed. Having the same advantages of Option 2, the data object would only be associated with a particular system, meaning it would be limited for interfaces that send or receive from systems where only one of the systems are documented.

Where would this fit in with existing and future BPM modelling tools?

The life cycle of a business process follows the Design, Build and Run path. Design is when novel processes are communicated and recorded, perhaps building on legacy designs. Build integrates the design into the core components using development tools such as NetWeaver BPM. The Run part is where ongoing maintenance, testing occurs, and serves as a starting point for adaption, restarting the lifecycle again.

 

Design

The possibilities currently available to capture a new business process, mentioned at the beginning of this blog, are the plethora of desktop design tools. One of their disadvantages are that they only really only permit collaboration from a shared softcopy or picture, and are generally exacting in adherence to the BPM notation standards, something that is not really conducive to a free-flow of ideas and collaboration between often geographically dispersed business process owners and business analysts.

Currently under beta test the new cloud based Simple way to model processes in the Web using a subset of BPMN 2.0 (common executables) which eases the involvement of genuine business users and not just fully fledged BPM modellers. As it is cloud based, it is ideal for the collaborative design process required. My personal opinion is that Gravity should become a template creation of the process in the design phase.

 

Build

The NetWeaver BPM tool in the NWDS comprises of two perspectives, the Process Modeling perspective to sketch processes, mainly addressed to business analysts, and the Process Development perspective to make the process executable, mainly addressed to developers. My experience is that whatever is created in NWDS stays in NWDS because unfortunately the Process Modeling perspective is embedded in Eclipse, a technocratic development environment originally devised by developers for developers. Having said that, there may be extensions currently under development I know little about to bring the BPM design into SAP Solution Manager.

 

Run

What is also needed is something that merges the capabilities of both the design and build tools, and that would be a graphical Business Process Blueprinting tool. It’s positioning would be to both to document processes for development in the implementation projects and also serves the requirement of maintenance projects.
To report this post you need to login first.

6 Comments

You must be Logged on to comment or reply to a post.

  1. Ryan Wermager
    In my experience, getting the business to document their process flows and process definition documents using Microsoft Visio is a up hill battle.  I haven’t seen any real “long-term” value that can translate into cost savings if we document our interfaces inside of Solution Manager.  Using a tool like ARIS is the ultimate solution and SAP knows that.  They bought the tool and integrated it perfectly and then went one step further with allowing the process diagrams to even create the business process hierarchy in Solution Manager.  The graphics tab in SolMan is terrible.
    (0) 
    1. Philip Kisloff Post author
      I’ve not seen the ARIS tool in detail, but accept it covers much the same ground as a BPB tool.

      My opinion is the proposed Solution Manager process model approach fills a gap created by NetWeaver BPM composites, that whatever was developed was not really well integrated into the SM business side, and so the disparity between the SM graphics tab and NWDS process model was problem. So a small scale SAP solution is needed.

      However, I believe interface monitoring as part of BP&IMon requires details from the Interface process level. I do support interfaces in many systems and they are sometimes the most complex part of the system. If its representation can be improved then that would certainly help mutualise the provision of support services, i.e. reduce the KT needed.

      Anyway greatly appreciate your comments.

      (0) 
      1. Ryan Wermager
        I learned something. I didn’t know that BP and IMon would use the Graphics tab representation to understand the environment.  I assumed that the Business Process Monitoring inside of Solution Manager was transacational based meaning it would only monitor the transaction codes in terms of performance/response times. It makes sense to monitor the interfaces as well but what KPIs would one use?  The amount of data being sent and received?  Have you ever seen a company take the Business Process Hierarchy and Interface Hierarchy that they built during Blueprint and leverage the information to enable Business Process Monitoring?
        (0) 
        1. Philip Kisloff Post author
          Not the graphics tab directly, but the information stored in the interface attributes is used to set up the monitoring. My point was just that if one is setting up IMon, then it’s helpful if the interface documentation is available in Solution Manager also. The detail has to be kept somewhere, and not helpful if everyone documents it differently. Setup_Guide_IFMon on service marketplace gives an idea of the approach, but I’m not suggesting that interface documentation in Solution Manager is essential, only that it’s worth making it more usable.
          (0) 
  2. Marlo Simon
    Hello Phil

    Nice to see some feedback over the integration of tools with SolMan.
    SolMan, NWDS and Aris target different user groups. Currently SolMan is limited to a 3 level hierarchy for process definitions and an Aris modeler would feel handicapped by those limits. In terms of modeling expertise IDS is the industry standard.
    We are currently on the move to a possible SAP only scenario, where we could colaborate over StreamWorks for process definitions, import the model into NW BPM for execution/integration, export monitoring data do BAM/SolMan and update the model back into SolMan’s BPL.
    Everytime we change tools there’s a shift in culture. If we ought to BPP using SolMan ok, but it isn’t quite there yet.

    Best Regards,
    Marlo Simon.

    (0) 
    1. Philip Kisloff Post author
      Hi Marlo,

      Absolutely agree with what you’ve said about targeting different groups, and these groups come to play at different points in the lifecycle.

      I come in at the run phase, having to support very many clients. I cherish standardisation, without special tools or structuring. That’s definitely a lowest common denominator approach, with its acknowledged problems, but it makes economic sense when sharing resources between clients.

      It would be great if everyone adopted the industry best, but in reality, sometimes I’m lucky if I can find any process documentation beyond the original business case, HLD, test cases and user training!

      all the best, Phil

      (0) 

Leave a Reply