Motivation

In various customer situations, we assume in the context of process-oriented requirements the responsibility for designing the right solution architecture. For solutions based on the SAP Process Orchestration platform this means for some time to make a decision for or against aBPM. In the following blog we want to share our experiences and introduce typical use cases (project types) and criteria for the use of the aBPM solution.

Typical aBPM use cases (project types)

Our BPM and aBPM project experience result from various industries (e.g. trade, chemicals, utilities, logistics) and business domains (e.g. sales and service, production, finance, human resources). Although the most common answer to the question of the right architecture is almost always “It depends …” the following project types can be defined for which we would definitely recommend the actual use of the aBPM solution:

• Enhancement of standard SAP Business Suite processes with web and rule-based process steps

Often standard processes, e.g. in an ERP solution, should be enhanced/ extended (without modifications if possible) to support a seamless integration of in particular occasional users (e.g. managers, external business partners, …) via web-based user interfaces. Also mobile scenarios for individual process steps are required. Therefor SAP Process Orchestration offers many technical options. With BPM and the solution extension aBPM such requirements can be implemented very easily and efficiently.

Examples:

• Integration of external service or sales representatives into internal business processes
• Implementation of approval processes (e.g. to support a four-eye principle)
• Implementation of individual master data management processes

The power of the ABAP stack for the realization of business objects and relating functionality is unquestionable. For the realization of individual management processes for creating entities or for maintaining and approving changes/deletions aBPM can serve as an ideal base for an easy solution implementation.

Examples:

• Master data maintenance with high demands on governance or data quality
• Distributed master data maintenance, e.g. as a consequence of the introduction of a shared service center organzation

Decision criteria and arguments for aBPM

In the following section we would like to explain our recommendation for aBPM for the above mentioned project types based on different criteria. Our argumentation can be a useful starting point for an individual assessment in each specific project:

• Optimal User Experience

In particular occasional users require a custom, intuitive and tailored user interface (keyword: Fiori-like, Responsive, Mobility). aBPM supports these goals through the use of SAPUI5 as UI technology. The underlying BPM Engine also enables controlled processing in the context of the overall workflow.

• Efficient generation of complex UIs

Often complex user interfaces for data entry and approval are required that have to be closely integrated with the back-end systems (e.g. for input help, validation, internationalization etc.). Usually only few other UI functionalities are needed. The focus of aBPM on an underlying process data model and the declarative definition of views, rights and other UI features simplify the implementation of these requirements through the development of highly homogeneous, form-like user interfaces. In addition this approach supports an easy way of requirements analysis with the business experts. By generating most technical artifacts also the development costs are significantly reduced and no detailed technical UI know-how must be built up.

• Standardized implementation of recurring, generic functionality

With the adoption of aBPM many basic business requirements that apply in almost every process UIs are implemented “out-of-the-box” with a consistent and state of the art user experience. These include generic functions for PDF generation, Excel uploads, feeds, attachments, change log, value and search helps and also process monitoring and analytics that can be automatically and consistently used in an aBPM-based solution.

• Company-specific processes based on BPM/BRM

With the use of the aBPM framework the functionality and power of SAP Process Orchestration is not restricted, but rather expanded seamlessly. Very specific and company-individual requirements to the processes (e.g. due to governance requirements) can still be implemented with the full feature set of e.g. BPM or BRM..

Conclusion

If you are faced with process automation using BPM, then this blog should provide some reference information, under what condition it might be worthwhile for you to consider the use of aBPM. If your planned project looks similar to one of the above mentioned two project types, then we would highly recommend this. The above criteria can provide a useful basis for your discussions and argumentation.

We hope this short insight helps your thoughts, and look forward to your suggestions and feedback.

More informationen on aBPM:

aBPM – a solution extension offered by SAP Consulting