9.2 SAP Business Process Management
SAP BPM provides a complete suite of BPM development and administrative tools to help organizations design, model, execute, monitor, manage, and analyze business processes using one platform. It allows organizations to create new processes based on their existing software and applications, as well as by creating new types of processes that combine different sources of information, technologies, and platforms.
You can improve and enhance existing business processes by reusing existing components or automating certain parts of the process, such as system-to-system and human-to-system information interchange and the execution of complex and general (repetitive) business rules. In fact, we advise our customers who are interested in implementing SAP BPM to start with relatively small BPM initiatives, proactively engage the process stakeholders, demonstrate quick wins, and visualize results to the business before embarking on a full-blown SAP BPM adoption.
Before we proceed with the rest of this chapter, we’ll highlight and explain the purpose and role of SAP BPM within an organization.
Business Process Visibility with SAP BPM
Organizations gain control and overall visibility across their business processes when implemented with SAP BPM. The following list provides an overview of known common aspects of business processes in which stakeholders are interested:
- Who in the organization is responsible for performing a task? This can be a person, a business unit, an external entity, or a system.
- What type of information is flowing through the process? This can be an order, an order confirmation, and so on.
- Which process step is currently being executed?
- When was a certain process step (manual or automatic) executed, who executed it, how long did it take to execute, and what was the result?
As you can see, when wisely implemented, SAP BPM increases the level of control and end-to-end visibility in business processes. It also significantly contributes to improving overall process efficiency, which automatically leads to other business benefits, such as lower cost-to-serve, higher customer satisfaction, and customer retention. The next section will provide some context regarding SAP BPM, including differentiating SAP BPM and SAP Business Workflow.
9.2.1 SAP BPM versus SAP Business Workflow
Often, especially in discussions with traditional SAP consultants, SAP BPM is unfairly compared with other workflow application, such as SAP Business Workflow. This faulty comparison is due to a lack of understanding of the area of application of both tools. Let’s take a look at how they are different from each other.
SAP Business Workflow is an ABAP-based workflow engine that enables you to design, customize, and execute business processes within SAP backend systems—that is, inside one SAP system (see Figure 9.3)—rather than across SAP systems, as SAP BPM allows. SAP Business Workflow processes are often delivered as a business content functionality part of SAP solutions, but SAP BPM processes are rarely delivered as business content as a part of standard SAP solutions. You can also enhance or create your own SAP workflows by using the same tools provided by SAP. Inside SAP business suites, such as SAP Customer Relationship Management (SAP CRM), SAP Supplier Relationship Management (SAP SRM), and SAP ERP, we traditionally encounter SAP Business Workflow (both out of the box and enhanced) supporting approval processes, order processes, processes related to customer interaction, and so on. In contrast, with SAP BPM, most business processes are created either by reusing existing functionality combined with new process components or by creating new services and process functionality.
A second key difference between SAP BPM and SAP Business Workflow is in their underlying technology. As we know, SAP BPM runs on Java, whereas SAP Business Workflow is an ABAP-based workflow engine, which means it can only run on the ABAP stack. Although you can integrate SAP Business Workflow with other SAP and non-SAP systems using different interface technologies, such as IDoc and ABAP proxies, it was never intended to be used for that purpose.
It’s worth mentioning here that SAP Business Workflow focuses primarily on human-centric processes, in which a substantial number of the tasks are performed in a routine and predictable fashion. SAP BPM supports both types of process orchestration: human-centric and system-centric:
-
System-centric processes
The main focus of this type of process is on the integration of information sources, generally between two or more services in an orchestrated fashion. Process logic is applied to the service requests or responses to coordinate the flow of data from the start to the end of the process. -
Human-centric processes
Human-centric processes are business processes in which most process activities are predominately performed as manual activities by humans. The process only provides guidance about the steps to follow and gives an overview of the overall process status. An example of a manual process activity part of an HR recruitment process could be to check the LinkedIn profile of a candidate before inviting him for a job interview.
SAP BPM Isn’t a Reporting Tool
Another common misunderstanding that we hear about SAP BPM is that it’s an alternative to known SAP reporting tools. Just to be clear, SAP BPM isn’t a reporting tool, and it isn’t intended as a replacement for SAP Business Warehouse (SAP BW) or SAP BusinessObjects Business Intelligence (SAP BusinessObjects BI). Instead, it’s complementary to business intelligence tools because it leverages new sources of information that can be used in SAP BW or SAP BusinessObjects BI to deliver more accurate and detailed reports and analysis containing different key performance indicators (KPIs) set to business processes. It’s good to note that SAP BPM delivers standard out-of-the-box data extractors for SAP BW.
9.2.2 BPM before SAP BPM
Before SAP BPM made its entrance almost six years ago as part of SAP Composition Environment 7.1, SAP Process Integration (SAP PI) developers didn’t have many alternatives to choose from in the SAP NetWeaver stack for orchestrating system-centric and human-centric business processes (or a combination of both). Due to the limited BPM functionality available at that time, tight project deadlines and IT budget pressure pushed teams to deliver a solution within the planning and deadlines. Many projects ended up implementing BPM-like solutions that used existing SAP technologies. Some examples of such solutions included cross-component Business Process Management (ccBPM) for system-centric process orchestration, SAP Business Workflow for human-centric and ad hoc task processing, and ABAP custom programming and Z tables for support of business rules on the backend systems.
That was far from an ideal situation, and the pseudo-BPM approach introduced many disadvantages, including the following:
- A considerable amount of custom-built logic was introduced on the backend systems.
- Businesses became even more dependent on IT due to the use of technology-driven instead of process-driven techniques.
- Low flexibility occurred as a result of hard-coded rules programmed in the software instead of configured business rules.
- The “made to fit” approach resulted in even more difficult to maintain and extend business processes because of the “one-purpose, one result” vision.
- This approach provided limited to zero visibility in the process context, result of process steps, and overall process status during and after execution of the process.
SAP BPM provides the functionality needed when implementing system-centric and human-centric processes in an SAP-rich landscape. That doesn’t mean you can’t use it for orchestrating non-SAP processes, but you’ll get more advantage from its overall functionality and tools when used in an SAP-centric landscape. For instance, when modeling new processes in SAP BPM, you can directly access the Enterprise Services Repository (ES Repository) and search for existing services (created by you or by delivered by SAP as business content) that match needed specific functionality by a particular process implemented with SAP BPM.
When applied consistently and seriously adopted by the organization (i.e., not only by IT), SAP BPM closes the gap between business and IT by delivering a platform that enables direct interaction among all process stakeholders, including business, IT, partners, and suppliers. From the start of a BPM project, you already notice the difference from traditional IT projects. As a business, you become aware of how your business processes really look when they are executed; whether that execution is a manual task performed by a customer representative or an automated step executed between two systems, it all becomes clear. For the IT folks, a new world opens as they see for the first time in their lives how their services and mappings are used to create value in real business processes.
We don’t claim that SAP BPM is the next “killer app” of SAP, but it does play an important role in facilitating the evolution of organizations wanting to become more agile and support their business by a process-driven instead of traditional IT project-driven approach. It also eliminates the burden introduced by the disadvantages presented in the preceding list by providing a logical level of abstraction for the execution and management of process logic (i.e., service orchestration, task generation, business rules execution, process monitoring, etc.) right where it belongs—at the process layer.
Figure 9.4 illustrates how SAP BPM can orchestrate processes across different systems and enterprise boundaries.
Traditionally, solutions implemented with SAP BPM tend to reuse existing (functional and technical) capabilities on the application layer. It’s also common to encounter SAP BPM as a replacement of legacy applications that in the past supported some types of activities related to workflow or business rules. SAP BPM applications are by nature process-centric and exist to support and enrich end-to-end business processes. They might involve both manual and automatic tasks, and they can extend beyond enterprise borders.
Note
Here’s a list of a few SAP PO/SAP BPM-supported scenarios:
- Industry-specific or company-specific business processes that aren’t covered by standard (SAP) applications
- Process integration scenarios that involve the interaction of humans, systems, and external parties
- Processes that require approval and decision steps, such as HR-related processes (recruitment, employee onboarding, etc.), and financial requests, such as credit or insurance policy applications
- Enabling and automating procurement processes such as requisition and purchase order authorization rules, but also three-way matching in financial processes
- Business processes with real-time requirements, real-time cockpits or KPI reports, and events-based decision rules
- Integrated processes with both manual and automatically executed activities via services
- End-to-end scenarios that contain considerable amounts of information exchange, orchestration, and collaboration
- Applications that require support for the maintenance and execution of easy-to-maintain (reusable) business rules
9.2.3 SAP BPM Main Components
As explained in Chapter 1, SAP BPM is delivered as part of SAP PO, which is a BPM and application integration suite consisting of the following three core components running under the same Java stack:
-
SAP Process Integration (SAP PI)
Delivers enterprise service bus (ESB) capabilities by means of the Advanced Adapter Engine Extended (AEX) together with its different application and technical adapters, ensuring any-to-any connectivity for SAP and non-SAP systems. -
SAP Business Process Management (SAP BPM)
Provides a complete set of tools for the design, development, execution, monitoring, and management layers for creating human-centric and system-centric business processes. -
SAP Business Rules Management (SAP BRM)
Used for the definition, execution, and management of business rules to be used inside SAP BPM processes or as independent callable web services from other applications.
Depending on the specific requirements of your system landscape, additional components and functionality can be enabled as part of the installation of SAP PO. For example, you can enable support for SAP Composition Environment features, such as Visual Composer or Web Dynpro.
Figure 9.5 depicts how these three components are accommodated within the SAP PO single stack, also known as Java-only architecture.
The single-stack architecture of SAP PO with one single SID has a positive impact on performance and the reduction of overhead during message processing across the different SAP PO components. It also means that the hardware requirements for a single-stack installation are less demanding than for its dual-stack (ABAP/Java) predecessors.