Development of a BPMN Model Validation and Automatic Correction Tool for SAP Solution Manager

worked on by: Rainier Raymond Robles

Introduction

SAP Solution Manager (SolMan) is an Application Lifecycle Management (ALM) product used in the organization, maintenance, and optimization of a company's business and IT operations. One feature provided in SolMan is a tool for the visual modelling of business processes. This has the dual purpose of providing a clear representation of said processes as well as a means of documenting its individual steps and, when applicable, linking them to the technical systems and procedures (such as SAP transactions) utilized for that particular activity. The diagrams are modelled using the Business Process Model and Notation (BPMN) standard.

As those tasked with business process modelling within an organization may not necessarily be experts in BPMN, it would be advantageous to provide a means to check the syntactic correctness as well as the readability and usability of the models created. While the availability of an integrated BPMN modelling tool in SolMan has its advantages, it does not include model validation, a feature which can be found in most commercial BPMN modelling software.

Vostura GmbH is a small IT company based in Berlin and Mannheim specializing in SAP consulting, particularly with ALM and SAP Solution Manager. One recommendation that the company makes to its clients is to model its business processes within SolMan using SAP's integrated modelling tool. Vostura offers a training course to its clients in order introduce the basics and conventions of BPMN modelling. The company also occasionally offers additional support in the form of manually checking the created models, or modelling some processes that can serve as examples. Offering an integrated BPMN model validation tool to clients would help reduce the amount of time spent in the manual maintenance and correction of client-created models and aid the clients' understanding of BPMN. In addition, automatic correction would ease some of the burden of having to determine how to fix the issues found in the model.

Planned Course of Action

Requirements Elicitation

The requirements of the tool would be ascertained through review of existing literature, review of existing internal quality assurance guidelines at Vostura, review of existing internally-created BPMN models, and open-ended discussions with relevant persons within the company.

Selection of Guidelines

An analysis would be done to determine which guidelines would be implemented in order to create a prototype that provides the greatest value within a relatively short development time. Criteria for the decision-making process will be created and the guidelines collected in the previous step will be analyzed based on this criteria, resulting in a list of selected guidelines to be implemented in the product during the period of the thesis.

Architecture Definition

Decisions regarding the implementation of the tool would be made, including whether or not to integrate existing tools, as well as in which platform the tool would be implemented in.

Proof-of-Principle Prototype

A prototype of the tool with some basic functionality will be implemented. The prototype should be able to open or read a BPMN model and perform some basic syntactic checks. Should existing tools and libraries need to be integrated into the solution, it would be done at this stage. The goal is to prove that implementation of the product with the chosen architecture is feasible. If major problems arise during this stage, then the architecture would need to be re-evaluated and adjusted.

Iterative Implementation

The selected guidelines for the product will be implemented. An iterative process model would be used in order to provide an overall structure for the thesis while allowing for flexibility during the process. Each iteration is expected to last up to two weeks. At the end of each iteration, the latest version of the tool would be presented to the company and tested by Vostura employees and, if possible, BPMN modellers from the company's clients. This would be done in order to assess the usability of the validation tool, such as whether the support provided can be easily understood by the user, as well as provide insight into what changes need to be made, if any, during the next development iteration.

Weekly Status

Pre-Week 1

Activities

Results

Next Steps

Problems

Week 01 (CW 25)

Activities

Results

Next Steps

Problems

Week 02 (CW 26)

Activities

Results

Next Steps

Problems

Week 03 (CW 27)

Activities

Results

Next Steps

Problems

Week 04 (CW 28)

Activities

Results

Next Steps

Problems

Week 05 (CW 29)

Activities

Results

Next Steps

Problems

Week 06 (CW 30)

Activities

Results

Next Steps

Problems

Week 07 (CW 31)

Activities

Results

Next Steps

Problems

Week 08 (CW 32)

Activities

Results

Next Steps

Problems

Week 09 (CW 33)

Activities

Results

Next Steps

Problems

Week 10 (CW 34)

Activities

Results

Next Steps

Problems

Week 11 (CW 35)

Activities

Results

Next Steps

Problems

Week 12 (CW 36)

Activities

Results

Next Steps

Problems