Chapter 1. Process Modeling

In the first chapter, you will start with laying the foundation for, and demonstrating how to implement the modeling of, business processes for a Use Case of a fictitious organization that needs Oracle BPM to be implemented at their site. Recipes will demonstrate how to create and model business processes using Business Process Management Notation and Modeling (BPMN) within the Oracle Business Process Management Suite and how to create an organizational model that mimics your real-world organization.

In this chapter you will learn the following:

• Modeling business processes with BPM

• Simulating the BPM Application development lifecycle

• Modeling a fictitious organization

• Creating Business Process Flow

• Creating and defining Projects

• Defining Role and Organization Units

• Organizing processes using swimlanes

• Adding user interaction to Process Flow

• Controlling Process Flow—Defining exclusive gateways

• Controlling Process Flow—implementing exclusive gateways

• Controlling Process Flow—Parallel gateways

• Controlling Process Flow—Sequence flows

• Communicating with external processes and services

• Changing the value of Data objects in your process

• Creating Business objects in Business Catalog

• Adding documentation to the Flow Element

• Creating MDS for BPM

• Publishing a BPM Project in BPM Studio to MDS

Introduction

Business Process Management (BPM) is for process transparency, process intelligence, business empowerment, and business alignment. This chapter explores recipes to carry out a model business process, using Oracle BPM Suite 11g. Business Architecture lays the blueprint for operating and transforming the Enterprise. Business Architecture includes various models that define business goals, objectives, initiatives, and metrics. Business Architecture models business functions, both internal and external. They also encompass organizational models to depict roles, responsibilities, and collaborations to define how, and by whom, defined functions will be provided and used. Along with this, Business Architecture defines the business rules and policies to infuse governance, so that stakeholders can adhere and enforce policies. Steps to achieve business transformation objectives are also defined.

However, one Business Architecture element that is of interest for us in this book is, Business Process Models. Business Process Models define the activities, steps, and information flow between processes, to carry out business functions.

As BPM is a part and element of Enterprise architecture, they need to be designed so that the Enterprise can fully reap the rewards of Oracle BPM. While designing business processes, we are not just automating and managing processes; it's more about how an enterprise adapts to a comprehensive view of business processes, where one has to take the overall Enterprise architecture into account and not just automating and managing business processes. Hence, you can look at BPM adoption in an Enterprise as an element of Enterprise architecture.

With BPM, an enterprise can achieve the goal of automation. It can now model a business process, make associations with human workflow and IT applications, and infuse Business Rules Management Systems (BRMS). In combination with SOA and BRMS, enterprises can achieve extremes of agility. Oracle BPM will offer business agility whose process impact is directly proportional to process complexity. BPM is used for continuous process improvement as well.

Oracle BPM methodology is an agile strategy and an iterative approach to Business Process Management. It is well-suited to this era of ever-changing business processes, where there is a demand for continuous incremental improvement. Traditional methodologies were code-centric, rarely Model Driven; they always overlook the KPI, lacked continuous improvement, and had no vision beyond the current single project. For BPM, a methodology was required that could address these inadequacies; that could bridge the gap between IT and Business.

Oracle BPM methodology as a foundation for Business Process Implementation, as an Enterprise element, offers many benefits, such as the following:

• Business-driven: You will witness, in the BPM lifecycle, that business leadership and the Enterprise Architect work closely. This leads to process improvements with continuous alignment with business needs.

• Evaluation: Evaluation of IT assets enables effective planning. Gaps in the IT landscape can be identified and accessed, and required enhancements can be specified.

• Predictability: With simulation and analysis of processes, BPM incorporates predictability, so that results and costs can be determined in advance and with a high degree of accuracy and confidence.

• Bridging the Business-IT gap: Business stakeholders are involved at every step of process design and development. Information is exchanged at every engineering step. A Process or Business Analyst always works with Process Architects. Business Process Analysts, with their process, business and modeling skills, capture and model processes, drive process optimization, recommend changes, incorporate change requests from business, direct UAT, identify rules, define KPI's, and work with Process Architects for technical coordination.

• Traceability: With Process Analysis, you can capture the key decisions and associated motivation artifacts to support impact analysis and enable traceability throughout the business process lifecycle.

• Measurablity: With Process Analysis you can monitor your business processes, which enables a feedback loop, enabling continuous improvement.

• Adaptability: BPM methods and activities can be integrated with existing methods and new methods, with ease.

• Role Definition: Clear definition of duties.

The prerequisites to explore modeling, implementation, and deployments, using Oracle BPM Suite through recipes in this book, are that the following software be installed at your machine/site:

• Oracle Weblogic Server

• Oracle SOA Suite (includes Oracle BPM Suite)—BPM Suite gets installed when you install Oracle SOA Suite.

• Oracle Database

• Oracle Jdeveloper (with updates for SOA and BPM configured)

  Note

  Demos and examples used throughout this chapter and book are created on WebLogic server 10.3.5, SOA Suite 11.1.1.5.0, and JDeveloper 11.1.1.5.0 on a Windows 7, 64-bit machine.

BPM Application development lifecycle

Just as SOA enables IT Agility, BPM enables Business Agility. Process Impact is directly proportional to Process Complexity. BPM allows for continuous process improvement.

It is argued that BPM enables organizations to be more efficient, more effective, and more capable of change than a functionally focused, traditional, hierarchical management approach. It's the BPM that provides Process Management to serve business agility and manage complex business processes. An Oracle BPM Application's development lifecycle has many phases, such as:

• Vision

• Model

• Implementation

• Deployment

• Runtime

This application development lifecycle is equally applicable to any type of BPMN Process, be it a Standard process, Orchestration process, or Choreographic process. Most process modelers, and even you, after reading this book and creating a model, must be more familiar with defining the flow of activities. This is called a Standard process or an Orchestration process. In Choreography processes, the focus is not on orchestrations of work performed by the participants but rather on the exchange of messages/information between participants.

User personas

There are user personas for every phase of the Application Development lifecycle, as different phases require interaction from different types of users.

Vision

Making BPM adoption Enterprise business-driven, is the vision laid by the leadership and coordinated by Enterprise-wide Architects. It brings both business and process agility. As you can see in the preceding diagram for Vision & Mission, the business leadership and Enterprise Architect work closely, and this leads to process improvements with continuous alignment with business needs.

This phase lays the foundation for BPM adoption in the Enterprise with automation and continuous improvement guaranteed, at the same time staying aligned with business needs. You can term it as planning, strategy, analysis, or design. Planning is must for a BPM initiative to succeed. BPM planning needs to go beyond a departmental level and must incorporate a comprehensive view of the entire enterprise—it's goals, operations, processes, and IT Systems.

Alignment with business objectives must be the strategy for a BPM vision. Business leadership, along with process owners, must analyze the processes and find other high-value processes that are amenable to automation and have a high benefit-to-risk ratio. These high-value processes are BPM process candidates.

An Enterprise Architect will then analyze the technical aspects of the BPM process candidates and create a BPM road map. This road map will describe the current state and future vision, and identify the gaps between the two. A road map to get from the current state to the desired state is defined as the mission.

Participants in this phase are—Business leadership and Enterprise Architects.

• Business leadership (Business Participant) will drive the requirements by setting business goals, objectives, and priorities. Business leadership provides initial inputs, such as high-level vision definition and mission statements. They fund the BPM initiative. Business leadership may include many roles, such as Executive Management, Line-of-Business, and so on. However, let's define them as Enterprise Process Officers, who are responsible for developing a process-centric culture, system, and behaviors. They use BPM Analytics to determine business process changes. Business leadership is supported by Enterprise Architects.

• Enterprise Architects ensure that IT strategies and standards are applied. Along with Business Leadership, they identify business architecture inputs to BPM and help determining the needs for major business process changes.

Model

During this stage, a Process Analyst creates process models based on real-world business processes and problems. Oracle BPM provides three distinct tools for modeling business processes. Each tool has a different role within the Oracle BPM Suite. The tool you use depends on your business requirements, the stage of the application development cycle, and your user persona.

• Oracle BPM Studio

• Oracle Business Process Composer

• Oracle Business Process Analysis Suite (BPA)

Models are simply a way for Process Analysts to document processes in a structured way. Process Analysts model the flow of a business process and document its steps. They are assisted by Process Architects with their technical skills. Process Analyst and Process Architect are the critical roles in the automation of business process. One has a greater business focus and the other has a technical orientation.

This bridges the business-IT gap. Business Process Analysts, with their process, business, and modeling skills, capture and model processes, drive process optimization, recommend changes, incorporate change requests from business, direct UAT, identify rules, define KPI, and work with the Process Architect for technical coordination.

The participants in modeling are as follows:

• Process Analysts: They are also termed as Business Process Analysts. They are involved in Process Modeling and have the relevant skills. They are responsible for:

  • Capturing and managing the graphical business process models

  • Driving process optimization

  • Recommending changes

  • Handling process change requests from the business

  • Incorporating incremental process improvements

  • Identifying and coding business rules

  • Working in User Acceptance Testing.

  They work closely with the Process Architect for technical coordination.

• Process Architects: They coordinate with the Process Analysts in Process Modeling. It's a role that we also identify as Solution Architect. However, they have modeling skills and process implementation skills, too.

  They are responsible for:

  • Analysis and design of technical aspects for the process

  • Defining technical integration strategies

  • Technical specification for new IT capabilities

  • Directing system and integration testing

Implementation

After Process Analysts model business processes, Process Developers are responsible for creating business applications based on these models. Using Oracle BPM Studio, Process Developers implement reusable services and integrate other business systems. Implementation may include the following types of tasks, generally performed by Process Developers:

• Refining the process model

• Making technical configurations

They implement defined rules. They can create a user interface and can incorporate Exception management. However, they have secondary developers to perform specialist technical tasks, for example, an Oracle ADF expert can create dynamic ADF pages to be used as Task Forms. Some other developer with Exception Handling expertise can perform that on the process. An integration expert can incorporate SOA stuff into the process, and so on.

After a Process Developer finishes the implementation, the application is compiled and deployed like other SOA composite applications. It can be compiled and deployed using Oracle BPM Studio.

Process Developers: Also termed as Process Designers, they implement the process model to make it executable by configuring data mappings, defining data, and transforming activity input and output. They may not be knowledgeable about business processes, but rely on Process Models for implementations. They have the following responsibilities:

• Rapidly create business processes using tools. Tools Required: BPM Studio

• Creating implementation Artifacts.

• Populating business catalog with rich implementation artifacts.

Deployment

This phase includes testing and deployment. Process Developers or a supporting deployment team can perform process deployment.

For testing, either a developer or a QA can be involved. Different phases involve participation from different people. Generally, developers will perform the Unit testing. System and Integration testing will be performed by the QA and directed by Process Architects. User Acceptance Testing (UAT) will witness involvement of Process Analysts and QAs. Once UAT is completed, the process is deployed to runtime.

Deployment is the process of transferring an Oracle BPM project from the development environment to the runtime environment. This can be either a testing or production runtime environment. After finishing the integration of business processes with backend systems and reusable services, Process Developers create and compile a working, process-based application. This application is then deployed to Oracle BPM Runtime. Oracle BPM Suite contains the following typical scenarios for deploying to Oracle BPM Run Time:

• Deployment directly from Oracle BPM Studio

• Deployment directly from Business Process Composer

• Deployment using an exported SAR file

• Deployment using the WebLogic Scripting Tool (WLST)

Once the process is deployed to runtime, it's available to end users.

Runtime

After an application is deployed, the runtime environment makes the Oracle BPM application available to process participants, based on the roles assigned in the organization where the business processes were deployed. This stage is divided into the following distinct functions:

End user interaction

Process participants and process owners are responsible for interacting with the running application using process workspace. Process Analysts and owners can also monitor the process and revise Oracle Business Rules at runtime.

End user participants: Process participants are the end users or process performers in a business process who perform the human aspects of the business process task and perform interactive activities. They provide task execution details to the Process Analyst and are involved in Acceptance Testing. They should be contacted and interviewed at the time of Process Automation, as it's a must for process design to know what they actually do. They have many roles, such as supervisor, sales manager, sales representative, business analyst, agents, clerks, and so on.

Oracle BPM flow will automatically route these tasks to a participant, based on his/her role, and they have to log in (either to Oracle BPM workspace or Process Spaces) and perform their activity. End user interaction to running process is performed by logging on to either Oracle BPM Workspace or Process Spaces.

Administrators are responsible for maintaining running business applications and the overall runtime infrastructure, using Oracle Enterprise Manager and the Oracle Weblogic Server administration console.

Administrators or Operation Managers are responsible for the following:

• Configuring and Monitoring SOA Infrastructure

• Configuring BPMN Process Service Engine

• Integrating Oracle BPM with External Monitoring, such as Oracle Business Activity Monitoring, and many more.

Process management and monitoring

Process owners are responsible for monitoring and maintaining running processes using process workspace. Process Analysts and owners use Oracle Business Process Analysis to monitor the real-time performance of business processes. The participant is process owner in this phase.

Process owners are the subject matter experts for the business process (es). They own a process or processes. They are responsible for:

• Assisting the Business Process Analyst (B) throughout the modeling

• Assisting the Business Process Administrators (IT) throughout runtime they require considerable business knowledge

• Managing Process flow

• Assigning tasks

• Defining rules and objectives

• Analyzing end-to-end Business Process Performance

• Making process-specific decisions to resolve conflicts like the gap between departmental silos of business process activities where ownership is undetermined and knowledge is sparse. Process owners resolve such issues, as they are the process experts responsible for the end-to-end flow of key business processes.

• Advocating recommendation for Enterprise-wide process improvements.

• They are also responsible for the monitoring business process(es) that they own.