BPM and Bpel
BPM and Bpel
BPM and Bpel
Agenda
Overview of BPM discipline
Types of processes Standards, Tools & Roles
Overview of BPEL Key Differences - BPM & BPEL Case study of Order-to-Cash process for manufacturing industry like Dell Conclusions & Recommendations Discuss the application of these two technologies for the right business context and requirements.
Type of Processes
Document-centric: Processes revolve around approval, routing and handling of documents. People-centric: Processes revolve around human tasks, refer back or re-execution of tasks, parallel tasks, complex user interactions (loops), escalations, etc. with quick turnaround times. Process-centric: Processes revolve around a core business function/process which has a well defined boundary (within a department like a Warehouse, Finance, etc). System-centric: Processes revolve around the execution of functional workflows/processes in other systems, reexecution of sub-processes, etc. while retaining control of the end-to-end business process at a macro level when work flows across systems (rather than just people)
Process Execution
Process Monitoring
Process Design
Process Execution
Process Monitoring
BPEL is a popular standard for orchestration of composite business processes that span across systems that in turn run atomic & functional sub-processes. Hence is systemcentric Currently the standard is BPEL 1.2 (Oracle supports BPEL 1.1) BPEL is XML based standard and is machinereadable
DELL CONFIDEN TIAL
Overview of BPEL
Overview of BPEL
<variable>
Credit Rating BPEL Flow
<process>
start
10:00am
Get Rating
<partnerLink>
United Loan
<invoke> <receive>
Star Loan
<partnerLink>
<partnerLink>
</flow> <switch>
</process>
? Select Lowest Offer
end
03:00pm
Actors are mostly Systems Human tasks in the processes are mostly reserved for process/business exceptions to be handled by process owners. Open standard BPEL engines do have proprietary extensions Processes can be defined in BPMN and exported to BPEL format
Standards
Structure
Transaction Volume
Fairly un-structured
Cannot handle large volumes Typically support large number of users
Structured
Can handle large transaction processing volumes (millions of processes per day)
Case Study
A Typical End-to-End O2C Process
Order-to-Cash Process
Enquiry & Quote
CustomerRelationship Relationship Customer Management(CRM) (CRM) Management
Order Booking
Order Processing
Shipping
Invoicing
Enquire & Request Quote Receive Invoice Quote Accepted? Y Order Entry Make Payment Soft-copy Receipt
Check in Warehouse
Plan Dispatch Inventory Exists? N Create Work Order Transfer from Storage to Shipping Area
Inventory Update
Reduce Inventory
Produce Product
Increase Inventory
Ship Confirm
Generate AR Invoice
Generate AR Receipt
Invoice Allocation
In the real world, most of these systems will be from different vendors. These core functional systems will have their own proprietary workflow tools Most of these core functional systems are designed from the function and user point of view. BPM cannot orchestrate these E2E and also provide visibility. Process Owner does not have visibility of the E2E process.
Finance Finance
Shipping Shipping
Case Study
A Typical End-to-End O2C Process
Order-to-Cash Process
Enquiry & Quote
CustomerRelationship Relationship Customer Management(CRM) (CRM) Management
Order Booking
Order Processing
Shipping
Invoicing
Enquire & Request Quote Receive Invoice Quote Accepted? Y Order Entry Make Payment Soft-copy Receipt
Check in Warehouse
Inventory Update
Reduce Inventory
Produce Product
Increase Inventory
Most of the atomic and departmental functions/processes are well-defined. If implemented as part of a packaged application, the choice of using BPM for such processes wont be there. If implemented from scratch, such processes are good BPM candidates.
Shipping Shipping
Ship Confirm
Finance Finance
Generate AR Invoice
Generate AR Receipt
Invoice Allocation
Case Study
A Typical End-to-End O2C Process
Inventory Update in WMS
Inventory count and adjustment
Event
WMS Manager
Accept Count?
No
Recount
Yes
WMS Clerk
Physical Count
End Process
In the real world, such functions involve a lot of human tasks that have to be done manually. In the real world, these systems are packaged applications with their own workflows which may or may not be in BPM tools. These core functional systems are designed from the Functional User point of view.
Conclusions
BPM is a discipline for management of atomic business process whose functional boundaries are well-defined rather than management of longrunning end-to-end business processes that fulfil an end-to-end business process that spans across multiple disparate systems. BPEL is a sub-set of the Business Process Management discipline BPEL bridges the gap between BPM and SOA. BPEL does what BPM cannot do on its own i.e. execute/orchestrate processes across department/functional systems in a standard way while at the same time providing Visibility & Control to the Business Process Owner. BPEL is not good at handling complex workflows that involve a lot of human tasks (work-items) and which demand quick turn-around times. EAI can fill in the cross-system workflow gap to some extent but it does not give visibility and control to the Process Owners. BPM tools are not suitable for high-volume transaction processing while most BPEL tools are.
Recommendations
Use BPM for inter-departmental function workflows/processes that are centred around human tasks and documents Orchestrate end-to-end, cross-system processes using a BPEL engine. In a green-field project, if all functional workflows are going to be built from scratch, then BPM can be used for process management and process-integration instead of BPEL but if more than one packaged application/system are going to be used in the project, then using BPEL along with BPM is a better option. Use BAM in tandem with BPM and BPEL for end-to-end process visibility.